「2000年問題」の版間の差分

削除された内容 追加された内容
編集の要約なし
タグ: モバイル編集 モバイルウェブ編集
問題が2つあることを明示して構成を整理
1行目:
'''2000年問題'''(にせんねんもんだい)は、[[西暦]]([[グレゴリオ暦]])[[2000年]]になると[[コンピュータ]]が誤作動する可能性があるとされた[[年問題]]である。'''Y2K問題'''(ワイツーケイもんだい:'''Y''' は[[年]] ('''''y'''ear'') 、'''K''' は[[キロ]] ('''''k'''ilo'') )、'''ミレニアム・バグ''' (''millennium bug'') とも呼ばれた。西暦2000年であることをコンピュータが正常に認識できなくなるという問題が主に取り上げられるが、グレゴリオ暦における置閏法を誤解して生じる問題もある
 
== 原因 ==
コンピュータシステムの内部で、日付を扱う際に西暦の下2桁のみを取り扱い、上位2桁を無視しているのが原因で問題が生じる。この他に、置閏法に対する誤解から西暦2000年を「平年」として扱ったことが原因で、西暦2000年2月29日に誤動作する問題が生じる。
直接の原因は、[[プログラム (コンピュータ)|プログラム]]内で[[日付]]を扱う際の年数の表現を下2桁だけにしたことである。[[COBOL]]や[[FORTRAN]]のような古いプログラミング言語では[[データ型]]に「日付型」が用意されていない。従って、プログラム内では、年数を[[グレゴリオ暦]]の下2桁だけの「文字型」で表現していることがある。この方式では[[2000年]]が内部で00年となるので、これを[[1900年]]と見なしてしまい、例えば「[[データベース]]を日付順に並べ替える処理をすると、順序が狂う」などの誤作動を起こす可能性があるとされた。
 
===年表示を2桁に限っている場合===
また、[[1996年]]など平常の[[閏年]]とは異なり、2000年は400年に1度の特殊な閏年であって[[閏日]]([[2月29日]])があるのに、その処理をしていないプログラムもあった。現行の[[太陽暦]]である[[グレゴリオ暦]]では、閏年について次の規則がある。
直接の原因は、[[プログラム (コンピュータ)|プログラム]]内で[[日付]]を扱う際に西暦年数4桁表現うち、上位2桁無視し、下2桁だけを処理対象にしたことである。古い電算システムを構築するのに用いられた[[COBOL]]や[[FORTRAN]]のような古いプログラミング言語では[[データ型]]に「日付型」が用意されていない。従って、プログラム内では、年[[グレゴリオ暦]]の下表現するために2桁だけ文字型」でを割り当てて、西暦示4桁のうち下2桁を記録・処理ていることがある。この方式では[[2000年]]が内部で00年となるので、これを[[1900年]]と見なしてしまい、例えば「[[デレコタベース]]を日付順に並べ替える処理をすると、順序が狂う」などの誤作動を起こす可能性があるとされた。
 
初期のコンピュータの初期システムでは、[[計算資源|リソース]]特に[[記憶装置|メモリ]])の費用負担が大きくは高価で貴重であり、できるだけメモリを節約するプログラミングが要求された。年を下2桁で表すことによってリソースを節約をするのは、当時の[[プログラマ]]の間では当然の技法であった。そのようなプログラムの多くは[[1960年代]]から[[1980年代]]にかけて開発された。当事者は「2000年までには、何らかの改良が加えられるか、全く新しいプログラシステが運用に更新されているだろう」との前提でいたので、特にこの問題に対する対策を施していないことが多かった。2000年問題が表面化した際は、プログラムを作成した技術者の退職などもあり、手作業でのプログラムの確認と修正が必要になることが多かった。
 
これらのプログラムが作成された時点で既に、多くの国で様々な領域や分野でコンピュータが使用されていたので、思わぬところでの機能停止や誤動作の危険が起こり得ることが指摘されていた。これらの問題によって、[[物流]]その他の社会運営上の不具合の発生などが予想され、国際経済が深刻な[[不況]]に陥る可能性を指摘する声もあった。一部には、[[カレンダー]]を持たない独立した[[組み込みシステム]]の誤動作の不安を煽るなど、あたかも[[フェイルセーフ]]で設計されたものがこの世にないかのように騒ぐなどの過剰反応も見られた。
 
===置閏法を誤解している場合===
また一方、[[1996年]]など平常の[[閏年]]とは異なり、2000年は400年に1度の特殊な閏年であって[[閏日]]([[2月29日]])があるのに、その処理をしていないプログラムもあった。現行の[[太陽暦]]である[[グレゴリオ暦]]では、閏年について次の規則がある。
 
# 4で割り切れる年は閏年とする。
10 ⟶ 18行目:
# 2.のうち、400で割り切れる年は閏年とする。
 
従って、1900年は平年(100で割り切れても400で割り切れない)であったが、2000年は閏年であった。しかし、誤って1.と2.だけを適用し、2000年を閏年としないプログラムがあったので、この対応も併せて必要とされた。尚、前述の様に年の下2桁のみを処理するシステムでは、100で割り切れる年と400で割り切れる年の区別ができず、年表示が00である年を平年として扱う様にプログラムするとこの問題が生じる。単純に4で割り切れるかどうかで閏年を判定するシステムでは2000年を閏年として扱って問題は起きない
 
コンピュータの初期は、[[計算資源|リソース]](特に[[記憶装置|メモリ]])の費用負担が大きく、できるだけメモリを節約するプログラムが要求された。年号を下2桁で表すことによってリソースを節約をするのは、当時の[[プログラマ]]の間では当然の技法であった。そのようなプログラムの多くは[[1960年代]]から[[1980年代]]にかけて開発された。当事者は「2000年までには、何らかの改良が加えられるか、全く新しいプログラムが運用されるだろう」との前提でいたので、特にこの問題に対する対策を施していないことが多かった。2000年問題が表面化した際は、プログラムを作成した技術者の退職などもあり、手作業でのプログラムの確認と修正が必要になることが多かった。
 
これらのプログラムが作成された時点で既に、多くの国で様々な領域や分野でコンピュータが使用されていたので、思わぬところでの機能停止の危険が起こり得ることが指摘されていた。これらの問題によって、[[物流]]その他の社会運営上の不具合の発生などが予想され、国際経済が深刻な[[不況]]に陥る可能性を指摘する声もあった。一部には、[[カレンダー]]を持たない独立した[[組み込みシステム]]の誤動作の不安を煽るなど、あたかも[[フェイルセーフ]]で設計されたものがこの世にないかのように騒ぐなどの過剰反応も見られた。
 
== 事前対策 ==
91 ⟶ 95行目:
[[1999年]][[12月31日]]([[金曜日]])から2000年[[1月1日]]([[土曜日]])に跨がって運行する[[東日本旅客鉄道|JR東日本]]、[[西日本旅客鉄道|JR西日本]]などのJR、私鉄各社は、全ての列車を最寄りの駅に臨時停車して運転を見合わせ、航空便はシステムの不測の事態に備えて欠航したり、年が明けてからの出発に変更したりした。
 
2000年になった時点では、一部のシステムに不具合は出たものの、大部分が致命的な問題至ら生じなかった。また、システムによっては時刻を[[協定世界時]](UTC)で取り扱うものがあり、そのようなシステムでは[[日本時間]]の2000年1月1日午前9時に不具合が生じることも懸念されたが、午前9時を迎えてもそれほど重大な問題には至らなかった。具体的な例としては、[[女川原子力発電所]]、[[福島第二原子力発電所]]および[[志賀原子力発電所]]で、警報装置が誤報を発したり一部のデータ管理が不能になったが、発電、送電や[[放射性物質]]管理に問題は発生しなかった<ref>[[電気事業連合会]] 2000年1月21日報道発表資料</ref>。
 
身近な例として、当時[[NTTドコモ]]が販売していた[[携帯電話]]「ムーバN206」([[日本電気|NEC]]製)の[[ショートメール]]機能において、「既読メールが容量オーバーで受信できなくなった場合、古いメールから自動削除する」機能が誤作動した<ref>『[[産経新聞]]』 2000年1月3日東京朝刊26面</ref>。また、2000年を想定した設計がされていない旧い[[ビデオテープレコーダ|ビデオデッキ]]の予約録画、[[ワードプロセッサ|ワープロ]]機の文書管理機能などに影響が出た。