2000年問題（にせんねんもんだい、英語: Year 2000 problem）は、西暦（グレゴリオ暦）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桁の文字列 ("yyyy")を確保するのが妥当であるが、初期のコンピュータシステムでは、磁気テープなどのリソース、特にメモリの容量が極めて少ない上、高価な貴重品であるため、できるだけメモリを節約するプログラミングが要求された。
年数を下2桁 ("yy")に縮めてリソースを節約をするのは、当時のプログラマの間では当然の技法であった。そのようなプログラムの多くは、1960年代から1980年代にかけて開発された。当事者は「2000年までには、何らかの改良が加えられるか、全く新しいシステムに更新されているだろう」という前提でいたので、2000年問題には充分な対策が施されていなかった。2000年問題が表面化した際は、プログラムを作成した技術者の死亡や退職などもあり、手作業でのプログラムの確認と修正が必要とされた。
これらのプログラムが作成された時点で既に、多くの国で様々な領域や分野でコンピュータが使用されていたので、思わぬ所での機能停止や誤作動の危険が起こり得ると指摘された。物流その他の社会運営上の不具合の発生などが予想され、国際経済が深刻な不況に陥る可能性を指摘する声もあった。一部には、カレンダーを持たない独立した組み込みシステムの誤作動の不安を煽るなど、あたかもフェイルセーフで設計された物がこの世にないかのように騒ぐなどの過剰反応も見られた。
置閏法を誤解している場合
1996年など平常の「閏年」とは異なり、2000年は「400年に1回」の特殊な閏年で閏日（2月29日）があるのに、その処理をしていないプログラムもあった。なお、土曜日から始まる閏年は、1972年以来28年ぶりであった。現行のグレゴリオ暦では、閏年について次の規則がある。
- 西暦年数で4で割り切れる年は閏年とする。
- 1.のうち、100で割り切れる年は平年とする。
- 2.のうち、400で割り切れる年は閏年とする。
従って、1900年は平年（100で割り切れても400で割り切れない）であったが、2000年は閏年であった。しかし、誤って1. と2. だけを適用し、2000年を閏年としないプログラムがあったので、この対応も併せて必要とされた。前述のように年の下位2桁しか処理しないシステムでは、「400で割り切れる年」と「400で割り切れない年」を区別できず、1. 2. の規則のみに沿って年表示が00である年を平年として扱うようにプログラムすると、この問題が生じる。
偶々 2. 3. の規則を知らずに1. の規則のみに則るか、1. 2. 3. の規則を全て承知で西暦2099年までは4で割り切れる判定で充分と認識し、単純に4で割り切れるかどうかで閏年を判定するシステムでは、2000年を閏年として扱って問題は起きない。
事前対策
当時、想定された問題には、次のようなものがあった。
- 発電・送電機能の停止や誤作動とそれに伴う停電
- 医療関連機器の機能停止
- 水道水の供給停止
- 鉄道・航空管制など交通機能の停止
- 弾道ミサイルなどの誤発射。2000年に突入するタイミングに合わせて、2000年問題にかこつけて故意にミサイルを発射する国家が出るのではという懸念もあった。
- 銀行・株式市場など金融関連の機能停止
- 通信機能の停止
従って、1990年代末期に使用していたコンピュータプログラムの訂正が世界規模で行われた。この修正作業に費用と期間が取られてしまい、中小企業などにおいて大きな打撃となった。
結果
総括
結果としては直前にマスメディアで騒がれていたような生活に直結するほどの大きな混乱は一切起きずに終わった。
元々2000年問題の深刻さと対処については疑問の声も多くあり、例えば元日（1月1日）よりも閏日（2月29日）の方が大きな騒ぎとなったことを理由に、そもそも重大な危険が存在しなかったという意見がある。これに対しては反対意見があり、情報システムエンジニアの努力の結果であり、危機管理の成功例として混乱回避の努力を正しく評価すべきであるとの意見もある。
2000年問題は、発生時期が明確であったこと（そのため責任の所在が予め明確であったこと）や、企業間連鎖による影響を防ぐため相互監視が働いたこと（経営者は自社が加害者となることを防ぐ必要があり、同時に株主などからは自社が被害者とならないよう対策を求められたこと）などの要素が混乱回避への対策につながったと考えられている。
日本
日本においては、1989年から消費税の導入や、「昭和」から「平成」への改元など、プログラムの全面的な見直しを要求される問題が発生しており、その際に2000年問題への対処も併せて行うことが多かった。
危険日までの対策
1998年7月15日に、財務局から各金融機関に対して「コンピュータ2000年問題対応に関する資料の提出について」という通達が出された。
- 経営における2000年問題対応の位置付けに関する資料
- 総費用見積りに関する資料
- 対応体制に関する資料
- 対応スケジュールに関する資料
- 進捗状況に関する資料
- 危機管理計画に関する資料
- 対応状況の開示に関する資料
これらの資料の3か月ごとの提出を命じ、1999年10月からは毎月の提出を命じた。内容は、あらゆる機器のリストアップ、問題判別の実施、対応マニュアルの作成・配布、一斉テストの実施、顧客・取引先に対しての周知徹底などである。
金融機関は政府と一体となって取り組み、サービスが停止することのないよう万全の体制を取った。1998年12月には小渕恵三が自らテレビCMに出演し、2000年問題への注意を促した。
| 日付 | 事象 |
|---|---|
| 1999年9月9日（木曜日） | 9が5つ並ぶ日 |
| 1999年12月30日（木曜日） | 金融機関の最終営業日 |
| 1999年12月31日（金曜日） | 1999年末日（大晦日） |
| 2000年1月1日（土曜日） | 2000年初日（元日）、日付の桁数が初めて6桁（200011）になる日 |
| 2000年1月3日（月曜日） | 海外市場取引開始日（シドニー市場） |
| 2000年1月4日（火曜日） | 金融機関の営業開始日 |
| 2000年1月8日（土曜日） | 最初のATM土曜稼働日 |
| 2000年1月10日（月曜日） | ("yyyymd"表記で)日付の桁数が初めて7桁 (2000110)になる日（成人の日） |
| 2000年1月15日（土曜日） | 通常営業日（成人の日ではない） |
| 2000年2月28日（月曜日） | 翌日が閏日（月末ではない） |
| 2000年2月29日（火曜日） | 「400年に1回」ある、世紀末の閏日 |
| 2000年3月31日（金曜日） | 1999年度の末日 |
| 2000年10月9日（月曜日） | 体育の日 |
| 2000年10月10日（火曜日） | ("yyyymd"表記で)日付の桁数が初めて8桁になる日（体育の日ではない） |
| 2000年12月31日（日曜日） | 2000年末日（20世紀の最終日） |
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日に、当日を閏日として処理せず「日付誤り」として取り扱ったり処理に障害が出る事例が発生した。
- 郵便貯金ATMのうち、約1,200台が停止。富士通製のLSIに不具合があり、1996年から1999年にかけて製造された同社製および沖電気工業製の一部ATMが停止したことが、同日深夜に郵政省と富士通から発表された。
- 札幌市交通局の路線バスから地下鉄への乗継ぎができなくなった。バスで発行される「乗継ぎ券」の日付が2月28日となってしまい、地下鉄の自動改札機を通過できなかった。
- 気象庁のアメダスが誤作動。長崎県平戸市では降雨がないにもかかわらず、1時間に973 mmという尋常でない降雨量が記録された（ちなみに2022年時点では千葉県香取市で1999年10月27日に観測された153mmが実際の1時間最多降水量である）。
2020年問題
2000年問題への対応として、年の内部表現が十進2桁のまま、ある数値までは20XX年とすることで1900年以降のある年から100年間を表せるようにするdate windowがあるが、UNIXエポックの1970年1月1日±50年である1920 - 2019年をwindowとしたシステムが多く、2020年の到来により誤動作を起こしている。
KDDI/auのフィーチャーフォンのうちKCPを採用しているモデルにて、2020年になると同時に表示が"0/0(SUN)0:00"となり時計が機能しなくなる。発売当時から2019年までという仕様だったことが指摘されている。
この他、米国ニューヨーク市でのパーキングメーターシステム、ポーランドのキャッシュレジスター、ドイツのハンブルク地下鉄でトラブルが報告されている。
脚注
関連項目
外部リンク
- 日本首相官邸「コンピュータ西暦2000年問題」 at the Wayback Machine (archived 2022-05-18)
- 文部省「コンピュータ西暦2000年問題」 at the Wayback Machine (archived 2000-08-16)
- テレビ東京「2000年問題」 at the Wayback Machine (archived 2000-01-18)
- 私にも2000年問題 at the Wayback Machine (archived 1998-01-10)
- yahoo!検索サイト at the Wayback Machine (archived 1999-04-28)
- 『2000年問題』 - コトバンク
- 『2020年問題』 - コトバンク