2000年問題【Y2K】 Year 2000 Problem

概要

2000年問題（Y2K）とは、西暦2000年以前に開発・運用されていたコンピュータシステムの一部が日付データの年号部分を西暦の下二桁で管理しており、1999年から2000年になると同時に一斉に異常が生じ社会を混乱させるとされた問題。日本では西暦2000年1月1日午前0時および同午前9時(協定世界時における1月1日午前0時)が問題の瞬間だった。

1960年代や70年代などに開発されたソフトウェアの中には当時極めて高価で容量の少なかった記憶装置を少しでも効率的に利用するため、1975年1月31日を「750131」とするなど、年号部分を西暦の最後の2桁のみで記録しているものがあった。当時は数十年先の西暦2000年まで同じソフトウェアやデータ形式が使われ続けるとは想定していなかった。

1990年代後半になり、コンピュータの利用開始が早かった先進各国ではそのような旧式の設計のままのシステムが社会の至るところに残存していることが明らかになり、2000年になると同時に一斉に機能を停止したり誤作動するなどして使用できなくなることが懸念された。事前には生じる事態や影響範囲が正確には予想できず、社会インフラや官公庁、交通システム、金融システムなどに深刻な影響が出ることも想定された。

かくして西暦2000年を迎えたが、事前に警鐘が鳴らされ対応が急ピッチで進められたことや、各企業や官庁などで年越しに際し通常より手厚い体制でシステム監視や緊急対応が行われたこともあり、小規模なトラブルは起きたものの深刻な社会的影響が出るには至らなかった。

ちなみに、「K」は「キロメートル」などと同じ「キロ」の意味で、2000年（year 2000）=2キロ年（year 2k）という連想から「Y2K」という略称が定着した。

閏年の例外規定による混乱

西暦2000年は閏年の計算ルールが400年に一度の例外に当たる稀な年であったため、2月の日数や日付の処理が誤っているコンピュータシステムがあり、小規模なトラブルとなった。これも西暦2000年問題に含める場合がある。

2月が29日間になる閏年のルールとして、「4の倍数の年」というものが有名だが、正確にはそのうち「100の倍数の年は閏年とはならない」例外があり、さらにそのうち「400の倍数は閏年とする」例外の例外がある。すなわち、1996年や2004年は「4年ルール」により閏年、1900年や2100年は「100年ルール」により閏年ではないが、2000年は「400年ルール」により閏年となる。

このため、100年ルールには対応していたが400年ルールは未実装だったシステムは誤って西暦2000年を閏年ではないと判定してしまい、誤動作した。皮肉なことに例外規定を知らず機械的に4年ルールを適用していたシステムは結果的に正しく2000年を閏年として処理した。

名称	問題の日付・時刻	要因	主な対象
2000年問題	2000年1月1日～	西暦の下2桁で表した年データが十進数2桁の上限を超える	メインフレーム / COBOLプログラム等
昭和100年問題	2025年1月1日～	昭和に換算した年データが十進数2桁の上限を超える	メインフレーム / COBOLプログラム等
2036年問題	2036年2月6日6:28:15(UTC)～	1900年1月1日午前0時からの経過秒数が32ビット符号なし整数の上限を超える	NTPで時刻合わせしているシステム等
2038年問題	2038年1月19日3:14:08(UTC)～	1970年1月1日午前0時からの経過秒数が32ビット符号付き整数の上限を超える	UNIX系システム等