【ITニュース解説】Excelの“うるう年バグ”は仕様だった？　1900年2月29日の謎

私たちが日常業務で頻繁に利用する表計算ソフト、Microsoft Excelは、数値計算やデータ管理において非常に強力なツールである。しかし、その内部には一見するとバグのように思える、興味深い仕様が存在する。その一つが、日付の扱いで、実はExcelは、歴史上存在しなかったはずの「1900年2月29日」を有効な日付として認識している。これは、システムエンジニアを目指す上で、コンピュータがどのようにデータを扱っているのか、そしてソフトウェアの互換性がいかに重要かを理解する上で格好の題材となる。

コンピュータが日付を扱う際、単に「2024年5月10日」のような文字列として記憶しているわけではない。計算を容易にするため、特定の日を基準とした通し番号に変換して管理するのが一般的である。Excelもこの方式を採用しており、この通し番号を「シリアル値」と呼んでいる。Excelでは、1900年1月1日を基準日とし、この日をシリアル値「1」としている。そして、1日経過するごとにシリアル値は1ずつ加算されていく。例えば、1900年1月2日は「2」、1900年1月3日は「3」となり、1900年1月31日は「31」というシリアル値で内部的に管理されている。この仕組みにより、「特定の日から何日後か」といった日付の加算や、二つの日付間の日数を計算することが、単純な数値の足し算や引き算で高速に実行できる。

ここで問題となるのが「うるう年」の扱いである。うるう年は通常4年に1度訪れるが、西暦が100で割り切れる年はうるう年とせず、さらに400で割り切れる年はうるう年とする、という例外ルールがある。このルールに従うと、1900年は100で割り切れる一方で400では割り切れないため、うるう年ではない。したがって、1900年2月は28日までしかなく、「1900年2月29日」という日は存在しないのが正解である。しかし、Excelは1900年をうるう年であると誤って解釈し、存在しないはずの「1900年2月29日」を有効な日付として扱っている。具体的には、1900年2月28日のシリアル値は「59」だが、その翌日として「1900年2月29日」にシリアル値「60」を割り当てている。その結果、本来であれば59の次に来るはずだった1900年3月1日のシリアル値は「61」となり、これ以降のすべての日付のシリアル値が、本来あるべき正しい値よりも1だけ大きい状態で管理されることになった。

この奇妙な挙動は、単なるプログラミングミスによるバグではない。これは、歴史的な経緯から意図的に残された「仕様」なのである。Excelが市場に登場した1980年代、表計算ソフトの分野では「Lotus 1-2-3」というソフトウェアが圧倒的なシェアを誇っていた。そして、このLotus 1-2-3には、プログラムを簡素化するためか、1900年をうるう年として扱ってしまうというバグが存在した。後発であったExcelが市場シェアを獲得するためには、当時すでに広く普及していたLotus 1-2-3で作成された膨大な量のファイルを、問題なく開いて利用できる互換性が不可欠であった。もしExcelが日付を正しく処理してしまうと、Lotus 1-2-3から移行したデータの日付が1日ずれてしまい、大きな混乱を招く。そこでMicrosoftは、ユーザーの利便性とスムーズな移行を最優先し、あえてLotus 1-2-3のバグをそのままExcelに実装するという決断を下した。つまり、Excelのうるう年問題は、市場競争の中で生まれた「互換性のための仕様」なのである。

シリアル値が1日ずれていると聞くと、「Excelでの日付計算はすべて不正確になるのではないか」と心配になるかもしれない。しかし、ほとんどの日常的な利用シーンでは問題は発生しない。その理由は、Excel内で行われる日付計算の仕組みにある。例えば、あるプロジェクトの開始日と終了日を入力し、その期間日数を算出する場合を考えてみよう。Excelはそれぞれの日のシリアル値を取得し、その差を計算する。開始日も終了日も、共にシリアル値が本来より1だけ大きくなっている。そのため、引き算を行うと、この「1のズレ」が互いに相殺され、結果として正しい期間日数が算出されるのである。このように、Excelの内部で完結する計算においては、全体が一律にずれていることが逆に幸いし、計算結果の正確性が保たれる仕組みになっている。

ただし、システムエンジニアとしては、この仕様が潜在的なリスクとなりうるケースを理解しておく必要がある。Excelで管理されているデータを、データベースや自作のプログラムなど、他のシステムと連携させる際には注意が必要である。多くのプログラミング言語の標準ライブラリやデータ変換ツールは、このExcelの仕様を認識しており、データのインポート・エクスポート時に自動で日付を正しく補正してくれる。しかし、そのような機能を持たないシステムと連携したり、自前で日付変換処理を実装したりする場合には、この「1日のズレ」を開発者自身が意識して対処しなければ、データの不整合を引き起こす原因となる。特に、1900年3月1日より前の日付を厳密に扱う必要がある歴史的なデータ分析や、特殊な要件を持つシステム開発では、この問題が顕在化する可能性がある。Excelの「1900年2月29日」問題は、単なるトリビアではなく、ソフトウェア開発における互換性の重要性や、過去の技術的負債が現代に与える影響を示す好例である。一見不可解なシステムの挙動も、その背景にある歴史や設計思想を理解することで、より深く本質を捉えることができる。これは、将来システムを設計・開発する上で、非常に重要な視点と言えるだろう。