2000年問題

2000年問題（にせんねんもんだい、）は、西暦（グレゴリオ暦）2000年になるとコンピュータが誤作動する可能性があるとされた年問題である。Y2K問題（ワイツーケイもんだい、"Y" は年（"year"）、"K" はキロ（"kilo"＝千））、ミレニアム・バグ（millennium bug）とも呼ばれた。
西暦2000年であることをコンピュータが正常に認識できなくなるという問題が主に取り上げられるが、グレゴリオ暦における置閏法を誤解して生じる問題もある。
原因.
当時、多数のコンピュータシステムの内部で日付を扱う際に西暦の下2桁だけを表示しており、上位2桁を省略していることが原因で問題が生じると言われた。この他に、置閏法に対する誤解から西暦2000年を「平年」として扱ったことが原因で、西暦2000年2月29日に誤動作する問題が生じる。
年表示を2桁に限っている場合.
直接の原因はプログラム内で日付を扱う際、西暦の4桁のうち上位2桁を省略し下位2桁だけを処理対象にしたことである。("yy-mm-dd"や"dd-mm-yy"など)
古い電算システムを構築するのに用いられたCOBOLやFORTRANのような古いプログラミング言語では、データ型に「日付型」が用意されていない。従ってプログラム内では年を表現するために2桁の文字型を割り当てて、西暦表示4桁のうち下2桁だけを記録・処理した。この方式では2000年が内部で「00年」となるので、これを「1900年」と見なしてしまい、例えば「レコードを日付順に並べ替える処理をすると、順序が狂う」などの誤作動を起こす可能性があると指摘された。
4桁で表現される西暦年数を格納するには、4桁の文字列 ("yyyy")を確保するのが妥当であるが、当時コンピュータが2000年まで長きにわたって運用されるとは予想されていなかっただけでなく、初期のコンピュータシステムでは、磁気テープなどのリソース、特にメモリの容量が極めて少ない上、高価な貴重品であるため、できるだけメモリを節約するプログラミングが要求された。
年数を下2桁 ("yy")に縮めてリソースを節約をするのは、当時のプログラマの間では当然の技法であった。そのようなプログラムの多くは、1960年代から1980年代にかけて開発された。当事者は「2000年までには、何らかの改良が加えられるか、全く新しいシステムに更新されているだろう」という前提でいたので、2000年問題には充分な対策が施されていなかった。2000年問題が表面化した際は、プログラムを作成した技術者の死亡や退職などもあり、手作業でのプログラムの確認と修正が必要とされた。
これらのプログラムが作成された時点で既に、多くの国で様々な領域や分野でコンピュータが使用されていたので、思わぬ所での機能停止や誤作動の危険が起こり得ると指摘された。物流その他の社会運営上の不具合の発生などが予想され、国際経済が深刻な不況に陥る可能性を指摘する声もあった。一部には、カレンダーを持たない独立した組み込みシステムの誤作動の不安を煽るなど、あたかもフェイルセーフで設計された物がこの世にないかのように騒ぐなどの過剰反応も見られた。
置閏法を誤解している場合.
1996年など平常の「閏年」とは異なり、2000年は「400年に1回」の特殊な閏年で閏日（2月29日）があるのに、その処理をしていないプログラムもあった。なお、土曜日から始まる閏年は、1972年以来28年ぶりであった。現行のグレゴリオ暦では、閏年について次の規則がある。
従って、1900年は平年（100で割り切れても400で割り切れない）であったが、2000年は閏年であった。しかし、誤って1. と2. だけを適用し、2000年を閏年としないプログラムがあったので、この対応も併せて必要とされた。前述のように年の下位2桁しか処理しないシステムでは、「400で割り切れる年」と「400で割り切れない年」を区別できず、1. 2. の規則のみに沿って年表示が00である年を平年として扱うようにプログラムすると、この問題が生じる。
偶々 2. 3. の規則を知らずに1. の規則のみに則るか、1. 2. 3. の規則を全て承知で西暦2099年までは4で割り切れる判定で充分と認識し、単純に4で割り切れるかどうかで閏年を判定するシステムでは、2000年を閏年として扱って問題は起きない。
事前対策.
当時、想定された問題には、次のようなものがあった。
従って、1990年代末期に使用していたコンピュータプログラムの訂正が世界規模で行われた。この修正作業に費用と期間が取られてしまい、中小企業などにおいて大きな打撃となった。
結果.
総括.
結果としては直前にマスメディアで騒がれていたような生活に直結するほどの大きな混乱は一切起きずに終わった。
元々2000年問題の深刻さと対処については疑問の声も多くあり、例えば元日（1月1日）よりも閏日（2月29日）の方が大きな騒ぎとなったことを理由に、そもそも重大な危険が存在しなかったという意見がある。これに対しては反対意見があり、情報システムエンジニアの努力の結果であり、危機管理の成功例として混乱回避の努力を正しく評価すべきであるとの意見もある。
2000年問題は、発生時期が明確であったこと（そのため責任の所在が予め明確であったこと）や、企業間連鎖による影響を防ぐため相互監視が働いたこと（経営者は自社が加害者となることを防ぐ必要があり、同時に株主などからは自社が被害者とならないよう対策を求められたこと）などの要素が混乱回避への対策につながったと考えられている。
日本.
日本においては、1989年から消費税の導入や、「昭和」から「平成」への改元など、プログラムの全面的な見直しを要求される問題が発生しており、その際に2000年問題への対処も併せて行うことが多かった。
危険日までの対策.
1998年7月15日に、財務局から各金融機関に対して「コンピュータ2000年問題対応に関する資料の提出について」という通達が出された。
これらの資料の3か月ごとの提出を命じ、1999年10月からは毎月の提出を命じた。内容は、あらゆる機器のリストアップ、問題判別の実施、対応マニュアルの作成・配布、一斉テストの実施、顧客・取引先に対しての周知徹底などである。
金融機関は政府と一体となって取り組み、サービスが停止することのないよう万全の体制を取った。1998年12月には小渕恵三が自らテレビCMに出演し、2000年問題への注意を促した。
2000年1月1日.
1999年12月31日から2000年1月1日にまたがって運行するJR東日本・JR西日本などのJRや私鉄各社は、全ての列車を最寄りの駅に臨時停車して運転を見合わせ、航空便はシステムの不測の事態に備えて欠航したり、年が明けてからの出発に変更したりした。
2000年になった時点では、一部のシステムに不具合は出たものの、致命的な問題は生じなかった。なお、システムによっては時刻を協定世界時 (UTC)で取り扱うものがあり、そのようなシステムでは日本時間の「2000年1月1日午前9時」に不具合が生じることも懸念されたが、午前9時を迎えてもそれほど重大な問題には至らなかった。具体的な例としては、女川原子力発電所、福島第二原子力発電所および志賀原子力発電所で、警報装置が誤報を発したり一部のデータ管理が不能になったが、発電、送電や放射性物質管理に問題は発生しなかった。
身近な例として、当時NTTドコモが販売していた携帯電話「ムーバN206」（NEC製）のショートメール機能において、「既読メールが容量オーバーで受信できなくなった場合、古いメールから自動削除する」機能が誤作動した。また、2000年を想定した設計がされていない古いビデオデッキの予約録画、ワープロ機の文書管理機能などに影響が出た。
2000年2月29日.
2000年2月29日に、当日を閏日として処理せず「日付誤り」として取り扱ったり処理に障害が出る事例が発生した。
2020年問題.
2000年問題への対応として、年の内部表現が十進2桁のまま、ある数値までは20XX年とすることで1900年以降のある年から100年間を表せるようにするがあるが、UNIXエポックの1970年1月1日±50年である1920 - 2019年をwindowとしたシステムが多く、2020年の到来により誤動作を起こしている。
KDDI/auのフィーチャーフォンのうちKCPを採用しているモデルにて、2020年になると同時に表示が"0/0(SUN)0:00"となり時計が機能しなくなる。発売当時から2019年までという仕様だったことが指摘されている。
この他、米国ニューヨーク市でのパーキングメーターシステム、ポーランドのキャッシュレジスター、ドイツのハンブルク地下鉄でトラブルが報告されている。