2000年問題
2000年問題(にせんねんもんだい、Year 2000 problem)とは、西暦(グレゴリオ暦)2000年になるとコンピュータが誤作動する可能性があるとされた年問題である。Y2K問題(ワイツーケイもんだい、Y は年 (year) 、K はキロ (kilo。千) )、ミレニアム・バグ(millennium bug)とも呼ばれた。
西暦2000年であることをコンピュータが正常に認識できなくなるという問題が主に取り上げられるが、グレゴリオ暦における置閏法を誤解して生じる問題もある。
Contents
原因
コンピュータシステムの内部で、日付を扱う際に西暦の下2桁のみを取り扱い、上位2桁を省略しているのが原因で問題が生じる。この他に、置閏法に対する誤解から西暦2000年を「平年」として扱ったことが原因で、西暦2000年2月29日に誤動作する問題が生じる。
年表示を2桁に限っている場合
直接の原因は、プログラム内で日付を扱う際に西暦の4桁のうち、上位2桁を省略し、下位2桁だけを処理対象にしたことである。
古い電算システムを構築するのに用いられたCOBOLやFORTRANのような古いプログラミング言語では、データ型に「日付型」が用意されていない。従って、プログラム内では、年を表現するために2桁の文字型を割り当てて、西暦表示4桁のうち下位2桁を記録・処理した。この方式では2000年が内部で00年となるので、これを1900年と見なしてしまい、例えば「レコードを日付順に並べ替える処理をすると、順序が狂う」などの誤作動を起こす可能性があるとされた。
4桁で表現される西暦年数を格納するには4桁の文字列を確保するのが妥当であるが、初期のコンピュータシステムでは、磁気テープ等のリソース、特にメモリは高価で貴重であり、できるだけメモリを節約するプログラミングが要求された。年を下位2桁で表すことによってリソースを節約をするのは、当時のプログラマの間では当然の技法であった。そのようなプログラムの多くは、1960年代から1980年代にかけて開発された。当事者は「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年に突入するタイミングに合わせて、Y2K問題にかこつけて故意にミサイルを発射する国家が出るのではという懸念もあった。
- 銀行、株式市場など金融関連の機能停止
- 通信機能の停止
従って、1990年代末期に使用していたコンピュータプログラムの訂正が世界規模で行われた。この修正作業に費用と期間が取られてしまい、中小企業などにおいて大きな打撃となった。
結果
総括
結果としては直前にマスメディアで騒がれていたような生活に直結するほどの大きな混乱は一切起きずに終わった。
元々2000年問題の深刻さと対処については疑問の声も多くあり、例えば元日(1月1日)よりも閏日(2月29日)の方が大きな騒ぎとなったことを理由に、そもそも重大な危険が存在しなかったという意見がある。これに対しては情報システムエンジニア等の努力の結果であり、危機管理の成功例として混乱回避の努力を正しく評価すべきであるとの意見もある[1]。
2000年問題は、発生時期が明確であったこと(そのため責任の所在が予め明確であったこと)や、企業間連鎖による影響を防ぐため相互監視が働いたこと(経営者は自社が加害者となることを防ぐ必要があり、同時に株主などからは自社が被害者とならないよう対策を求められたこと)などの要素が混乱回避への対策につながったと考えられている[1]。
日本
日本においては、消費税の導入や、元号が昭和から平成に変わるという、プログラムの全面的な見直しを要求される問題が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桁になる日 |
2000年1月3日(月曜日) | 海外市場取引開始日(シドニー市場) |
2000年1月4日(火曜日) | 金融機関営業開始日 |
2000年1月8日(土曜日) | 最初のATM土曜稼働日 |
2000年1月10日(月曜日) | 日付の桁数が初めて7桁になる日(成人の日) |
2000年1月15日(土曜日) | 通常営業日(成人の日ではない) |
2000年2月28日(月曜日) | 翌日が閏日(月末ではない) |
2000年2月29日(火曜日) | 400年に1回ある世紀末の閏日 |
2000年3月31日(金曜日) | 期末日 |
2000年10月9日(月曜日) | 体育の日 |
2000年10月10日(火曜日) | 日付の桁数が初めて8桁になる日(体育の日ではない) |
2000年12月31日(日曜日) | 2000年末日 |
2000年1月1日
1999年12月31日から2000年1月1日に跨がって運行するJR東日本、JR西日本などのJR、私鉄各社は、全ての列車を最寄りの駅に臨時停車して運転を見合わせ、航空便はシステムの不測の事態に備えて欠航したり、年が明けてからの出発に変更したりした。
2000年になった時点では、一部のシステムに不具合は出たものの、致命的な問題は生じなかった。尚、システムによっては時刻を協定世界時(UTC)で取り扱うものがあり、そのようなシステムでは日本時間の2000年1月1日午前9時に不具合が生じることも懸念されたが、午前9時を迎えてもそれほど重大な問題には至らなかった。具体的な例としては、女川原子力発電所、福島第二原子力発電所および志賀原子力発電所で、警報装置が誤報を発したり一部のデータ管理が不能になったが、発電、送電や放射性物質管理に問題は発生しなかった[2]。
身近な例として、当時NTTドコモが販売していた携帯電話「ムーバN206」(NEC製)のショートメール機能において、「既読メールが容量オーバーで受信できなくなった場合、古いメールから自動削除する」機能が誤作動した[3]。また、2000年を想定した設計がされていない旧いビデオデッキの予約録画、ワープロ機の文書管理機能などに影響が出た。
2000年2月29日
2000年2月29日に、当日を閏日として処理せず「日付誤り」として取り扱ったり処理に障害が出る事例が発生した[4]。
- 郵便貯金ATMのうち、約1,200台が停止。富士通製のLSIに不具合があり、1996年から1999年にかけて製造された同社製および沖電気工業製の一部ATMが停止したことが、同日深夜に郵政省と富士通から発表された。
- 札幌市交通局の路線バスから地下鉄への乗継ぎができなくなった。バスで発行される「乗継ぎ券」の日付が2月28日となってしまい、地下鉄の自動改札機を通過できなかった。
- 気象庁のアメダスが誤作動。長崎県平戸市では降雨がないにもかかわらず、1時間に973mmの降雨量を記録した。