- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- コンピュータ2000年問題 へ行く。
- 1 (2008-12-10 (水) 11:21:58)
- 2 (2008-12-10 (水) 23:05:33)
- 3 (2008-12-13 (土) 11:02:03)
- 4 (2009-02-18 (水) 00:41:50)
- 5 (2009-06-13 (土) 06:38:01)
- 6 (2010-05-01 (土) 11:38:21)
- 7 (2010-05-02 (日) 09:02:43)
- 8 (2010-05-07 (金) 20:29:41)
- 9 (2010-11-02 (火) 22:40:20)
- 10 (2011-08-11 (木) 06:58:38)
- 11 (2012-09-17 (月) 06:44:16)
- 12 (2014-03-22 (土) 15:29:42)
- 13 (2014-12-20 (土) 08:49:14)
- 14 (2017-03-09 (木) 19:47:57)
- 15 (2017-03-10 (金) 02:53:16)
- 16 (2017-03-10 (金) 18:05:50)
- 17 (2017-03-11 (土) 16:07:11)
- 18 (2017-04-10 (月) 14:19:12)
- 19 (2017-04-12 (水) 00:12:48)
- 20 (2017-04-12 (水) 17:58:18)
- 21 (2017-08-17 (木) 21:04:26)
- 22 (2020-12-13 (日) 12:20:30)
- 23 (2021-03-12 (金) 11:56:54)
- 24 (2021-03-13 (土) 09:15:37)
- 25 (2021-08-12 (木) 18:15:09)
- 26 (2022-01-14 (金) 22:13:54)
- 27 (2022-01-15 (土) 07:02:40)
- 28 (2022-02-16 (水) 09:30:53)
- 29 (2022-02-17 (木) 17:39:57)
- 30 (2022-11-03 (木) 06:45:19)
- 31 (2023-02-09 (木) 13:15:18)
- 32 (2023-02-25 (土) 12:06:22)
- 33 (2024-03-09 (土) 16:46:43)
【コンピュータ2000年問題】 †
1990年代末期から世界各地で顕在化した技術的問題。
西暦2000年になった瞬間*1に世界中のコンピュータが誤作動するという危惧。
概要 †
黎明期のコンピュータは、日付を扱う際に「年」を西暦の下2桁のみで表現するのが一般的であった。
この仕様は当時の技術的限界によるものだったが、技術上の問題が克服された以降も慣習的に2桁表記が続いていた。
だが、年号を2桁の数で表現すると、西暦2000年を示す「00」を西暦1900年と誤認する可能性がある。
実際に2000年になった時に何が起こるかは未知*2であったため、考え得る最悪の事態に対する警鐘が何度となく指摘された。
重篤な社会的混乱を引き起こす危険性があるとなればさすがに放置も許されず、その確認と修正が全世界規模で行われた。
技術的背景 †
何故、たかが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桁での表記が続いていた。
実際、日付の表記方法を変えるとなれば、当時存在していたほぼ全てのコンピュータが仕様変更や機種交換を余儀なくされる。
今日の高度情報社会の基盤となるコンピュータシステムは当時すでに普及しており、既存の端末の数はすでに膨大であった。
事前に予想されていた通り、これらの確認・修正作業は困難を極めた。
完全に修正不可能になっていたためゼロから新規設計でシステムを構築し直すしかなかった事例も少なくない*3。
航空・軍事分野に関連する問題点 †
…等々。
その後 †
1999年12月31日〜2000年1月1日にかけて、公共交通機関が日付をまたぐ運行を自粛するなどして不測の事態に備えていた。
実際に2000年になった際、一部の機械に小さなトラブルが出たものはあったが、重篤な被害には至らなかった。
結果として、この問題は人類史上において特筆に値する出来事には発展せず、いわゆる「世紀末カルト」の一種として急速に忘れ去られつつある。
当時のコンピュータ技術者たちがどのような問題を検知し、どのような対策を採っていたかについて全貌は明らかでない。
そして、今となっては調べるのも容易ではない。
とはいえ、2000年代になってから以後も類似の問題は(局地的ながら)たびたび生じている。
コンピュータの誤作動にまつわる問題は「2000年問題」という枠を越えていつでも起こり得る普遍的な現象と化しつつあるのが現状である。
2000年2月29日、「閏年」の認識*4を誤っていた事が原因で各所にトラブルが生じていた。
また、オーストラリアの銀行システムが、何故か「2010年」を「2016年」と誤認してトラブルを起こした。
今後予想される類似の問題として、GPS衛星の原子時計の桁あふれが生じた際や、UNIXシステムにおいて時刻を扱う数値が桁あふれした際*5にもトラブルの発生が予告されている。
*1 実際の発生予想時刻は各端末の内部時計に依存するので、実際には24時間に渡る。
*2 「データを日付順に並び替える処理をしても本来あるべき順序にならない」など、純機械的にどんなトラブルが起きるかは予期されていた。
未知だったのは、世界中あらゆる端末が同時並行的にトラブルを起こした時に実社会が被る被害である。
*3 稼働開始から10年・20年も経てば、開発当時の技術者が社内に一人もいなくなっていても驚くには値しない。
*4 グレゴリオ暦では「西暦の数字が4で割り切れる」「西暦の数字が100及び400で割り切れる」年を「閏年」とするが、「100で割り切れるが400で割り切れない年」は閏年としない。
*5 UNIXの内部時間は「1970年1月1日0時0分0秒(協定世界時)」を基準として定められているが、現在の書式では2038年1月19日3時14分7秒(同左)までしか扱えず、この時間を過ぎると数値がマイナスになってしまう。