- 追加された行はこの色です。
- 削除された行はこの色です。
*&ruby(こんぴゅーたにせんねんもんだい){【コンピュータ2000年問題】}; [#cfd5971e]
1990年代末期、世界各地で顕在化した~
「西暦2000年になると世界各地のコンピュータが誤作動し、それによって社会に重篤な混乱がもたらされる」~
という危惧のこと。~
1990年代末期から世界各地で顕在化した技術的問題。~
西暦1999年末日から2000年元旦にかけて世界中のコンピュータが一斉に誤作動するという危惧。
**概要 [#nf393743]
かつてのコンピュータは、プログラムやデータで日付を扱う際「年」を西暦の下2桁のみで表現するのが一般的であった。~
これは、黎明期のコンピュータが「4桁の数字で済むデータを2桁に省略しなければならない」ほど記憶容量や計算能力に余裕がなかったためであり、これらの問題が克服された後も慣習的に2桁での表記が続いていた。~
実際、日付の表記方法を変えるとなれば、当時存在していたほぼ全てのコンピュータが仕様変更や機種交換を余儀なくされることになり、膨大な手間と予測不能なトラブルを招くため放置されていた。~
黎明期のコンピュータは、日付を扱う際に「年」を西暦の下2桁のみで表現するのが一般的であった。~
この仕様は当時の技術的限界によるものだったが、技術上の問題が克服された以降も慣習的に2桁表記が続いていた。~
~
だが、そうしたシステムでは西暦2000年を示す「00」を西暦1900年と誤認する可能性があり、それによってシステムが誤作動する((一例を挙げると「データを日付順に並び替える処理をしても本来あるべき順序にならない」など。))恐れが指摘された。~
今日の高度情報社会の基盤となるコンピュータシステムは当時すでに普及しており、放置すると重篤な社会の混乱を引き起こすとされ、その確認と修正が全世界規模で行われた。~
だが、年号を2桁の数で表現すると、西暦2000年を示す「00」を西暦1900年と誤認する可能性がある。~
純機械的には単純なトラブルだが、これが全世界のあらゆる端末で同時並行的に生じた時に実社会に何を引き起こすかは未知であった。~
このため、考え得る最悪の事態に対する警鐘が何度となく指摘され、重篤な社会的混乱を避けるための確認と修正が全世界規模で行われた。
**技術的背景 [#s8b692e0]
何故、たかが4桁の数字を2桁まで省略しなければならなかったのか？~
答えは、その2桁の差が、かつてのコンピュータ科学における重大な課題であったからだ。~
~
コンピュータの計算は、多数の『ビット』を機械的に操作する事によって処理されている。~
1個の『ビット』は論理的には一桁の二進数（0/1）であり、物理的には電気回路のスイッチ（ON/OFF）である。~
そして、コンピュータのCPU（中央処理装置）が1回の演算で操作できるビットの数は有限である。~
~
1980年代に存在した端末の大半は、一度に8ビットまでしか制御できなかった。~
つまり、数値が8ビットで表現できる数（0〜255）である事が保証されていないと、あらゆる操作・演算の所要時間が2倍以上に増えるのだ。~
これに加えて計算内容を記憶するメモリも極めて限られていたため、データの節約は死活問題だった。
>例えば、任天堂の「ファミリーコンピュータ（1983年）」は作業用の記憶領域を2キロバイト持っていた。~
1バイトは8ビットで構成されるので、つまり2桁の数値2000種類、または4桁の数字1000種類で完全にメモリを使い果たす。~
不用意に数字の桁数を増やすような余裕がなかった事は疑いない。
1990年代には、32ビットを制御できるCPUと1メガバイト以上の一時記憶装置が登場していた。~
つまり日付の年数を正規の西暦表記に変える事が可能になっていたのだが、慣習的に2桁での表記が続いていた。~
実際、日付の表記方法を変えるとなれば、当時存在していたほぼ全てのコンピュータが仕様変更や機種交換を余儀なくされる。~
今日の高度情報社会の基盤となるコンピュータシステムは当時すでに普及しており、既存の端末の数はすでに膨大であった。~
~
事前に予想されていた通り、これらの確認・修正作業は困難を極めた。~
対象となるシステムの中には、開発当時の技術者が世代交代して現役を退くほど長期稼動していたものもあり、修正不可能なため新規設計のシステムに交換されてしまった事例も少なくない。
完全に修正不可能になっていたためゼロから新規設計でシステムを構築し直すしかなかった事例も少なくない。
> 稼働開始から10年・20年も経てば、開発当時の技術者が社内に一人もいなくなっていても驚くには値しない。
**航空・軍事分野に関連する問題点 [#y2f87e21]
[[航空]]・[[軍事]]の分野では次のような問題が危惧されていた。
-[[航空管制>航空交通管制]]や[[アビオニクス]]の誤作動・機能停止による[[ニアミス]]・空中衝突・[[墜落]]事故などの多発
-[[弾道ミサイル]]などの[[不時発射>誤射]]による偶発的な[[核戦争]]の勃発
-[[弾道ミサイル]]などの[[不時発射>誤射]]による偶発的な（または[[奇襲]]効果を狙った意図的な）[[核戦争]]の勃発
…等々。
**その後 [#v7eb2f3f]
日本では1999年12月31日〜2000年1月1日にかけて、通常ダイヤでは飛行中に午前0時(日本時間)を迎える国際線の[[フライト]]を「年明け以後の出発」や「欠航」としたり、[[鉄道]]においても、午前0時直前に最寄り駅で臨時停車させたりして不測の事態に備えていた。~
1999年12月31日〜2000年1月1日にかけて、公共交通機関が日付をまたぐ運行を自粛するなどして不測の事態に備えていた。~
実際に2000年になった際、一部の機械に小さなトラブルが出たものはあったが、重篤な被害には至らなかった。~
~
結果として、この問題は人類史上において特筆に値する出来事には発展せず、いまではいわゆる「世紀末カルト」の一種として急速に忘れ去られつつある。~
当時のコンピュータ技術者たちがどのような問題を検知し、どのような対策を採っていたかについて全貌は明らかでなく、いまとなっては調べるのも容易ではない。~
とはいえ、2000年代になってから以後も類似の問題((「閏年」の認識を誤っていた事が原因で起きた2000年2月29日のトラブル、オーストラリアの銀行システムが何故か「2010年」を「2016年」と誤認したトラブルなど。))はたびたび生じており、コンピュータの誤作動にまつわる問題は「2000年問題」という枠を越えていつでも起こり得る((今後起こり得るとされるものには「[[GPS衛星>ナブスター]]に搭載された原子時計の桁あふれ」や「UNIXにおける『2038年問題』」などがある。))普遍的な現象と化しつつあるのが現状である。
結果として、この問題は人類史上において特筆に値する出来事には発展せず、いわゆる「世紀末カルト」の一種として急速に忘れ去られつつある。~
当時のコンピュータ技術者たちがどのような問題を検知し、どのような対策を採っていたかについて全貌は明らかでない。~
そして、今となっては調べるのも容易ではない。~
~
とはいえ、2000年代になってから以後も類似の問題は（局地的ながら）たびたび生じている。~
コンピュータの誤作動にまつわる問題は「2000年問題」という枠を越えていつでも起こり得る普遍的な現象と化しつつあるのが現状である。~
***類例 [#i391ec42]
:閏年|現在一般に使われているグレゴリオ暦の暦法では、1年の日数を365.2425日としている(実測と異なる近似値）。~
通常は1年365日としつつ、端数（400年ごとに97日）を処理するため、平年より1日長い366日ある閏年を設けている。~
時計とカレンダーを実装する際にこの閏年について誤解があったらしく、平年と閏年を間違えるトラブルが生じた事がある。
:原子時計の桁あふれ|[[全地球測位装置]]（GPS）に用いられる[[ナブスター]][[衛星>人工衛星]]に搭載の原子時計は、年・月・日・時・分の概念を使わず、週と秒の概念で時刻を表現する。~
このうち「週」には10ビット（0〜1023）しか割り当てられておらず、1024週ごと（1999年8月21日と2019年4月7日）に桁あふれを起こして0週目に戻っていた。~
なお、現行最新のGPSは「週」に13ビット（0〜8191）を割り当てる規格に更新されており、2137年までは桁あふれを起こさない。
:UNIX内部時計|業務用システムとして使われるUNIX系列のソフトウェアでは、時刻を1970年1月1日0時0分0秒（協定世界時）からの経過秒数で表現している。~
古いシステムではこの時刻表現に32ビットを割り当てており、その種のシステムでは2038年1月19日3時14分7秒（同上）に桁あふれを起こす。~
現行端末のほとんどは時刻表現に64ビットを割り当てており、2262年4月11日までは桁あふれを起こさない。
