99年3月23日（火曜日）
バイアグラで騒いでいるかと思ったら、もうスーパー・バイアグラですか（笑）。
何でも効果が24時間も持続するとか。むぅ、24時間耐久レースに挑戦しようと言うおじさんもいるのだろうか(^_^;)。
私？ 冗談じゃない、齢二十歳ちょいで必要だなんて事になったら、洒落にならないじゃないですか(;_;)/。
日付け別indexに戻る
最初のページに戻る
まるのみに戻る
2000年問題
ジャンル：フリートーク
危険度：大（危機感を感じなさい）
今年一年の最大の課題。人類の運命の山場。文明の微妙な歪み。どうやっても普通には解決できない問題。「うっかり」では済まされない過ち。気がつくのがあまりにも遅すぎた出来事。そして、事の甚大さが未だに把握しきれていない、平和で愉快な人達。
はぁはぁ。
どのくらい重たい言葉を重ねれば、人々は振り向いてくれるのだろうか。
2000年問題がどれだけ甚大で難儀な問題であるのかを理解するには、まず今の世の中のどこまでにコンピューターが組み込まれているのかを知る必要があり、次にそのコンピューターと日付・時計システムがいかに密接に関わっているかを理解する必要がある。
まずコンピューターが現代社会にいかに浸透しているかについて。
例えば銀行。今の銀行はどこもみな顧客の貯蓄金額などの情報をすべてコンピューターで管理している。しかも銀行の場合、データ処理の迅速さよりもむしろデータ保存の確実性、安全性の方が重視されるため、古いシステムがそのまま継承されて使われているケースが非常に多い。
それからあらゆる中・大規模販売店及びチェーン店、コンビニエンスストアーなどでは、販売・顧客管理にやはりPOSと呼ばれるコンピューターシステムを使っている。
公共機関でも至る所でコンピューターは使われている。発電所の発電制御、ダムの水門制御、電話のパケット交換網、信号機、鉄道、気象観測所、etc...数え上げたらきりがない。
コンピューターと日付・時計システムがいかに密接に関わっているかについて。
それは、コンピューターを扱うのがあくまで人間であることを考えれば容易に想像がつくだろう。
例えば人間が書類を管理する場合、必ずその書類には発行された日付が必ず刻印されている。それは、同じ情報を扱う書類が２つ存在する場合、どちらがあとから発行されたものであるかによってどちらの書類が優先であるかを決められるようにするためである。もし人間がこれまで、書類に日付を付けると言うことをしなかったならば、とんでもない間違いが社会のあちこちで起こっていたことであろう。
それだけではない。人間は物事の量や速度を測るのにも時間を利用する。例えば人の足の速さを比べるために、同じ距離を走ったときのタイムを計る。あるいは商売において、１週間を通してどれだけの売り上げを上げたかをはかり、そこから今後の売り上げの目標額の設定や、商品の入荷本数の調整、値段の設定などが行われる。
コンピューターの場合、まず前者に当てはまるのがファイルのタイム・スタンプである。コンピューターはデータの内容が更新される際、必ずそのデータの一式（ファイル）に更新した日時を刻印する。これはデータの安全性を保つためで、例えば同じファイル名のファイルが送られようとしているときに、通常であれば同一ファイル名のファイルを２つ同じ場所においておくことは出来ないので、どちらか一方のファイルを残すことになる。単純なシステムでは外から送られてきたファイルに更新するかどうかをユーザーに確認を取り、それに応じるという形になるが、タイムスタンプの日付を参照し、どちらか新しいファイルを残すようにプログラムすることも可能になるわけである。
それから後者に当てはまるのはリアルタイムに行われる制御機能のことになる。例えばエアコンの場合、時間ごとの温度の推移から動作を制御している。時間を計るには時刻を単純に数値として扱い、現在の時刻を表す値から計り始めの時刻のそれを引いた差を使うのが普通である。つまり、１秒ごとに時刻を管理する予約変数が１増加するシステムであれば、２分という時間を得るために計り始めからその予約変数が１２０増加されるのを待ち、それから温度を測って、などと言うことになる。
さて、西暦2000年を迎えたとき、これがどんな症状を引き起こすのか。
多くのシステム、古いシステムをそのまま継承したシステムの場合、年号の管理に西暦の下２桁のみを使っている。１５年以上昔の８ビット時代を知っている人なら理解に難しくはないと思うが、かつてはシステムメモリーが64KBのパソコンが20万円以上していたくらいで、メモリーというのは本当に高価で貴重な資源だったのである。もちろん、年号を管理するために、たった１バイトのメモリーをケチることもないじゃないかという意見もあるだろうが、先程も言ったように日付はコンピューターの動作に密接に関わっており、１つのプログラムの中にも日付を扱う部分は頻繁に出てくることになる。そうなれば日付を扱うために要するメモリーも多くなり、そのたびにそのたった１バイトが重くのしかかるのである。
もしもLSIの技術がもっと早くから発達していて、始めからコンピューターが３２ビット処理系で作られていたならば、西暦もおそらく始めから４桁で対応していたであろう。現に富士通の独自パソコンであるFM-TOWNSシリーズは、全機種を通してハードウェア的に西暦４桁で対応している。これはFM-TOWNSという機種そのものが、始めから３２ビットパソコンとして開発されたものであるからに他ならない。
根拠のない余談はこのぐらいにして（笑）。
結局の所、西暦2000年問題とは西暦2000年を迎えたときにコンピューターがそれを1900年だと勘違いすることにあり、その時にコンピューターがどのような誤動作をするかということが、分野によっては容易に予想が出来、分野によってはまったく予想がつかないと言うことにある。
例えばデータの管理において、データを更新したいときに正常に更新されないなどと言った誤動作は容易に想像できる。銀行で例を挙げるなら、2000年に入ってから履歴が更新できず、預金も引き出しもできない、利子も増えない振り込みも出来ないという事態に陥ることになる。
逆に、制御コンピューターの場合2000年問題が引き起こす誤動作はまったく予想だに出来ないものである。なぜなら制御コンピューターの2000年問題におけるバグとは時間を計る上でその瞬間の「計算ミス」であり、そのような計算ミスが起こる可能性などまったく想定されていない場合がほとんどだからである。
当ホームページでもリンクコーナーなどで紹介している竹林政行氏の「１００％真実の告発」というメールマガジンがあるが、このメールマガジンの中で特別号として、非常に興味深い投稿が寄せられていた。それは原子力発電所における2000年問題についての記事であり、これを読めばこの問題がいかに深刻な問題であるか、目が覚めるように理解していただけるであろう。
ここにその記事の一部を抜粋し紹介しよう。
カレン・シルクウッドが２８歳の時にアメリカのオクラホマで原発に
殺されてから２５年経ちました。
今日、オーストラリア発の下記のニュースを読みました。
---------------------------------------------------------
オーストラリア原子力科学技術機構 (ANSTO, 連邦政府の機関、
日本の原子力委員会にあたる) は、豪州でただひとつの原子炉
であるシドニー郊外のルーカツハイツ炉（研究および医療放射
性物質生産用の小型黒鉛炉）について、ニューサウスウェール
ズ州の電気・ガス供給に関する「コンピューター2000年問題」
の対策が（今年10月までに）完了しない限り、不測の事態が発
生するのを避けるため99年12月31日以前に原子炉を停止する、
と発表した。
(３月１５日付、シドニー・モーニング・ヘラルド紙の報道
http://www.smh.com.au/news/9903/15/national/national4.html)
---------------------------------------------------------
オーストラリアでは、２０００年問題対策が６箇月後までに完了しない
限り、原子炉を停止するのです。
日本の原発は安全なのか？
３月１３日午前１０時２５分から放送のテレビ東京の「大前研一のガラ
ポン道場」で大前研一が「２０００年問題では原発は電力供給停止の恐
れがあるだけで原発は脅威では無い。私は原発の専門家だからよく解っ
ている。」と発言していました。
大前研一の主張が正しいのか？
放送法に「真実を保障する」「公平」「事実をまげない」「意見が対立
している問題については、できるだけ多くの角度から論点を明らかにす
ること」と定められています。
また、放送法 第４条に、「訂正又は取消しの放送」を求める事が出来
ると定められています。
それで３月１４日、テレビ東京のＨＰの送信フォームに下記のように書
いて送りました。
（ここから）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ノーニュークス・アジア・フォーラム・ジャパン
NoNuke ML 世話人 : とーち（奥野 律也）さんの
NoNuke ML への投稿を以下に転載します。
大前研一の「２０００年問題で原発は脅威では無い。」という
見解は事実では無いです。
訂正又は取消し放送をして下さい。
-----Original Message-----
差出人 : Toach
宛先 : NoNuke ML
日時 : 1999年3月14日 0:48
件名 : [NoNuke:00745] 2000 年問題について
とーちです。
2000年問題はけっこう報道されてはいますが、わかったようなわから
んような説明が多いので、基本的な部分をちょっと詳しく説明してみま
す。ご参考になれば幸いです。できるだけ、原発関連のことを例にして
みます。
ちなみに、私の文章は断りがない限り常に、原発を止める趣旨に基づ
くあらゆる転載・再利用を歓迎します。
■■■問題の基本
★そもそも
コンピュータのプログラムの世界では昔から年を２桁で表していまし
た。これをメモリを節約するため、といった説明をしている場合もあり
ますが、極めて初期のころは別として、私の実感では近年では「慣習」
だったと思います。
そもそも人間自身、年を ２桁で書くことが多く（西洋人にさらに多い
ように思う。年号と混同するおそれがないからか？）その慣習を引きず
っていたという気もします。また、人間に入力させる場合に４桁で入力
させると、ユーザがめんどくさいと嫌がるといったこともあります。
私自身、１０年ほど前には年を２桁で表すプログラムを書きましたが、
その場合は以下のような対処を入れました。
・70より小さければ2000を足して処理する。
・70以上ならば1900を足して処理する。
・以上の処理をしてから年の処理を開始する。
これで、2069年までこの部分は延命できるわけです。
しかし、ここで延命できたのは「この部分」でしかありません。この
ケースの場合、日付はハードディスクに記録されるのですが、そこには
２桁で記録されることになっていました。このため、せっかく正確に４桁
で表していた年をふたたび２桁に戻して記録していました。したがって、
再びそのデータを読み取って処理する場合は私が行ったような対処を再び
行う必要があります。
このように、ハードディスクに年を２桁で格納することにしてしまった
システムではそのデータを読み出す個所すべてで対処する必要があるわけ
です。プログラムは多い場合には数十名で作成するものですから、すべて
の人がきちんと対応しているかどうかは極めて疑わしいといわざるを得ま
せん。
★どうなるのか？
もし、対応していなければどうなるでしょうか。たとえば、単純に２桁
の年に1900を足して処理していた場合のことを具体的に例を示してみます。
まず、考えられるのは印刷される帳票に「1900年」などと出てしまうこ
とです。しかし、これはそれほど緊迫した問題ではありません。が、同時
に１時間あたりの発電電力量を印刷するとしましょう。しかし、１時間ご
とにデータが採取されるわけではなく、一定時間経過するとその間の総発
電量が採取されることにします。
たとえば、
１９９９年１２月３１日２３：２０〜２０００年１月１日０１：１０
の間の総発電量が230万KWだったとします。このような場合、プログラム
では特定の時間からの経過時間に日付を直して計算します。最近ポピュラ
ーなマイクロソフトのVisualBasicという言語では1899/12/30 00:00を0と
して日を整数部で時刻を小数部で計算します。この方式ですと
１９９９年１２月３１日２３：２０は 36525.9722222222 となります。
２０００年１月１日０１：１０は 36526.0486111111 となりますが二桁で
処理していたため
１９００年１月１日０１：１０とみなしてしまうと 2.04861111111111 と
なります。
１時間あたりの発電量は
230 / (36526.0486111111 - 36525.9722222222) * (1/24)
となり、125.45454545189 となります。
が、１９００年とみなしてしまっていると
230 / (2.04861111111111 - 36525.9722222222) * (1/24)
となり、-0.000262385099568491などという数値になってしまいます。もう、
この時点で計算はボロボロになっているわけですが、このように極めて小
さい値は要注意です。というのもこの値を小数点以下２桁で取り扱ってい
た場合には０と見なされてしまうからです。
そしてこの間の二次冷却水の流量が２００万リットルだったとして、１
万KWあたりの二次冷却水流量をさらに計算しているとします。
本来ならば、
200万KW / 125.45454545189
となりますが、０と見なされている場合は
200万KW / 0
となります。
「この０で割る」というのが曲者です。お手元の電卓で２００割る０を
計算してみてください。エラーマークが表示されたと思います。０に何を
掛け算しても０ですから、０で割るという計算は少なくとも有限の数を扱
っている限り計算不能なのです。
コンピュータのソフトウェアも一般に有限の数しか扱いませんから、電
卓と同様に０で割る計算はできません。では、どうするのか？「そうなら
ないようにする」というのが一般的な答えです。たとえば、割り算を行う
場合で０になる可能性のある場合はあらかじめ値をチェックして０ならば
割り算を行わず処理するようにプログラムします。しかし、今回のような
ケースは０になるはずがない値だとしてそのような対応をしていない場合
がほとんどです。
では、０で割る計算を行ってしまったらどうなるのか。通常のコンピュ
ータでは CPUレベルで０除算割込みというものが発生し、プログラムの実
行を中断し、もし設定してあれば特別な処理を実行します。画面表示がで
きるプログラムであればそのような場合には「0除算が発生しました。管
理者に連絡してください。」というようなメッセージを出してプログラム
を停止するのが普通です。C言語やBasicなどの言語であれば言語側で同じ
ようなメッセージを出してプログラムは停止します。
しかし、画面表示などを持たないプログラムではわかりやすく人間に通
知する方法がありませんので、プログラムを止めて、LEDなどを点滅させて
通知する、といった状態になるのが一般的です。
このように2000問題は年の値の大小関係が逆転するために０になるはず
のない値が０とみなされる、または負の数になるはずのない値が負になる、
といった現象に起因して致命的な問題となるものが代表的です。
★試験していない
一般的には、2000年問題以外にもこのように問題となる個所は多数存在
します。原子炉を停止しているので本来動作させないはずの発電量を監視
するプログラムを誤って動作させると、発電量が０となってしまう、など
のケースです。
しかし、こういったケースは予測がつきますのであらかじめテストして
いるものですが、2000年問題はなぜかテストケースに入れる慣習がないま
までした。このため、2000年に関するテストを行っていないことがけっこ
うあります。また、個々のプログラムごとにテストはしていても、全シス
テムを組み合わせたテスト時には実現が困難なため、わざわざ2000年対応
についてテストすることはまれです。ましてやいったん稼動させてしまっ
た原発のシステムすべてを総合的に2000年問題についてテストすることは
非常に困難です。
しかし、現実には個々のプログラムごとでは対処してあるつもりでも、
システム総体として稼動させた場合に問題が発生するケースはめずらしい
ことではありません。
★ファームウェアの問題
特に対応が困難だといわれているものに、ファームウェアの問題があり
ます。ファームウェアとはハードウェア機器に組み込まれて動作するソフ
トウェアのことで、一般にはROMと呼ばれる内容が変化しないメモリに格
納されています。
ファームウェアがやっかいな理由は外部からみるとどこに問題のありそ
うなソフトウェアが格納されているかわからないことです。
たとえば、排気弁に電源を供給している電源卓には実は電源供給をスケ
ジューリングする機能があり、簡単なLED表示とボタンがついていたものだ
とします。しかし、実際には供給電源電圧が低下した場合にアラームを発
生し、別系統の電源につなぎ変える機能のみを使用するため、そのLED表示
とボタンを取り除いてしまっていたとします。
すると、外見からは単なる電源監視のための機械にしか見えませんが、
内部的には日付を管理しており2000年を過ぎると問題が発生し、誤動作し
てしまうかもしれません。
もちろん、この電源卓の基盤を眺めればバッテリバックアップ用の電池
やカレンダ機能のICが乗っていますので、見る人がみれば「どうしてこん
なところにカレンダのチップがあるのだ？」と気づきますが筐体の中に格
納されているとわざわざ蓋をあけて中をみてみないとわからない、という
ことになります。
このように、ファームウェアの場合、使っている側からは思いもよらな
いところで2000年問題が発生する可能性があるわけで対応はますます困難
になります。
■■■そもそもどうしてコンピュータに年が必要か
少し、理論的な話をします。コンピュータの中で「時」を扱うことはよ
くあります。大きくわけると二つのケースがあります。
★時を扱うケース１：内部的なタイミングを計るため
ひとつは、何かを制御する場合にタイミングを計るケースです。燃料棒
が挿入完了してから２秒後とか、温度が500度に達した後、10秒間500度を
保っていた場合、などといったタイミングをとるために使用される「時」
です。
このような場合、一般に年の問題などは出てきません。物事が生じた時
を相対的に扱えばいいわけですから人間の都合で出来ている暦を使用する
必要がないからです。制御部分には 2000年問題が発生しない、というのは
こういうことを指しています。
★時を扱うケース２：人間とのインターフェースを取るため
ケース１は人間よりも「現象」が主役のケースといえますが、逆に人間
を主役とするケースがあります。たとえば、１年間の稼動時間合計とか1ヶ
月に排出された放射性ガスの平均値といったものです。この場合は人間の
都合による時に合わせたデータが欲しいため、年の概念抜きに処理はでき
なくなります。
この分け方では前者が制御部分、後者が統計・分析部分といえそうです。
そして、「後者では問題が起きるかもしれないが、前者では問題は生じ得
ないため、原子炉そのものの運転制御などが危険な状態になることはない」
おそらく、電力会社の偉いさんたちは、このように説明を受けて、ひょ
っとすると本当に信じているのかもしれません。
が、問題はそう簡単ではありません。
★複合するケース
たしかに、短い時間を扱う場合には、年の問題など出てこないのです
が、時間のオーダが長くなった場合には人間とのインターフェースのため
に日などの概念を使用するのが一般的です。
たとえば「15552000秒連続運転したら定期点検に入る」といわれても
よく分かりませんから人間向けに表示する際は「180日連続運転したら定
期点検に入る」と表示するでしょう。そして、10月20日18:00に運転を始
めた場合に、いつ点検に入るのか、といった事柄を表示する場合にはやは
り年の処理が必須になります。
そして、たとえ短い時間のタイミングをはかる場合であってもそれが
長い時間と連動する場合にはやはり年の処理を持ったまま扱うケースが
存在します。
本来相対的な時間のみを管理すればよい場合であっても、年月日を持
った時間で処理しておけば、人間とのインターフェースをとる場合にも
便利です。
もし、燃料制御棒の制御に年月日を使用していたケースを考えてみま
しょう。制御棒を１秒間に１cmづつ降ろしていくために、制御棒の位置
を計測するたびにコンピュータに通知するシステムになっていたとしま
す。このため、コンピュータのプログラムは位置を知らされるたびに、
今回の時刻および前回の位置と時刻からどのくらいの速度で制御棒が動
作したかを計算し、より遅く、またはより速く動くように指示をだします。
通常の動作は以下のようになります。
○前回の位置 15.583cm 時刻 1999/10/05 10:10:10.2385
○今回の位置 16.432cm 時刻 1999/10/05 10:10:11.2346
前回から今回の移動速度は以下のようになります。
今回の移動距離：16.432 - 15.583 = 0.849 cm
今回の計測時間間隔：1999/10/05 10:10:11.2346 - 1999/10/05 10:10:10.2385
= 0.9961 sec
今回の移動速度：0.849 / 0.9961 = 0.852324063 cm/sec
これにより、本来の速度より遅いことが検出されたので、移動速度を速
めるよう駆動装置に信号を出す、といった処理になります。
ここで、2000年問題が発生し、2000年を1900年と処理してしまったらど
うなるでしょうか。
○前回の位置 15.583cm 時刻 1999/12/31 23:59:59.2385
○今回の位置 16.432cm 時刻 1900/01/01 00:00:00.2346
前回から今回の移動速度は以下のようになります。
今回の移動距離：16.432 - 15.583 = 0.849 cm
今回の計測時間間隔：1900/01/01 00:00:00.2346 - 1999/12/31 23:59:59.2385
= -3155673598.9961 sec
今回の移動速度：0.849 / -3155673598.9961
= -0.0000000026903923151941 cm/sec
移動速度が負の数となり、かつ極めて小さい数になってしまいます。事
実上これは燃料棒が停止していると判断されるでしょう。このため、さら
に燃料棒を動かそうとするなど誤った信号が出てしまう可能性があるわけ
です。
■■■原発における特殊性
★制御プログラムでは停止が基本
制御プログラムでは一般に非常事態が起これば、「停止」するのが基本
です。想定外のことが起これば、まずは機械を停止させて、アラームを出
し、人間に対処してもらう、というのが一般に安全だからです。旋盤の機
械や自動車の組み立てロボットなど、ほとんどの制御においてこの概念は
当てはまります。
よく機械のそばには赤いエマージェンシーボタンが付いています。これ
を押すとなにはともあれ、機械が停止するようになっています。これは指
が挟まれそうになったり、服のすそが挟まれたりした場合に緊急停止させ
るために設けられているわけです。
同じように、2000年問題においてもプログラムが実行不能になればおそ
らく多くの場合において停止するケースがもっとも多いと思われます。
★停止は危険
多くの制御動作において安全な「停止」が原発の場合には必ずしも安全
でないことはお察しの通りです。制御棒のコントロール、冷却水循環ポン
プなど停止することが危険に直結する部分が原発には多く存在します。
2000年問題が原発においてとりわけ大きな問題となるゆえんです。
まだ、説明し足りないところもあるように思えますが、いったんこれで
終りとします。質問等ございましたら、ご連絡ください。
***************************************************************
とーち（奥野 律也） toach@e-mail.ne.jp
WebList http://toach.kmis.co.jp/list.htm
PGP Key F.P. = 0F AA 06 7B 35 38 F2 B9 E0 0A E9 5D 91 D2 04 93
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
（ここまで）
現在日本には、この問題を解決できるだけの十分なプログラマー人員が完全に不足しているのだそうだ。
上に上げた記事は、もちろん憶測にすぎない部分もいくつかある。しかし上の記事が、2000年問題において「原発は安全だ」と言い切っている専門家達の言葉も憶測にすぎないことを十分に証明しているのも確かだ。
大惨事を招く前に、危険を回避するためにも、是非とももっと真剣に警鐘を鳴らしていただきたい！