|
|
|
|
|
|
|
|
|
第二次世界大戦後に開発されて以来、コンピュータは驚異的な進歩を遂げている。最近では、大ヒット映画『タイタニック』に見られるように実写とほとんど区別が付かないようなＣＧが作成され、モチーフだけを入力すればコンピュータが自動的にアレンジして音楽を演奏してくれる。かつては専門技術者が職人芸を駆使して十日以上掛けて製作していた金型も、コンピュータ制御の工作機械で数時間で作れるようになっている。こうした状況を見ると、コンピュータは、人間の願いを自由に叶えてくれる魔法の箱のように思えるかもしれない。
しかし、もちろん、コンピュータは魔法の箱などではなく、きわめて単純な作業を命令されたとおりに実行しているだけの愚直な機械でしかない。音楽を奏でているのは、コンピュータではなくシンセサイザーという機械であり、コンピュータは、与えられた計算法によって求められた数値を、音色や音の高さ・強さ・持続時間などを表すデータとして送っているだけである。さまざまなグラフィックスを描けるのもコンピュータに絵画の才能があるからではなく、色調や輝度を表すデータを人間の指示通りに処理しているからにすぎない。また、熟練工の技が必要だった金型の製作をコンピュータに肩代わりさせられるまでには、技術者がどのような工程で作業しているかを調査するのに、２年間を要したという。
コンピュータは、それを動かすプログラムがなければ「ただの箱」である。ＩＴの導入によって生産性を上げるといっても、適切なプログラムがなければ、かえってメンテナンスなどの作業が繁雑になるだけである。そして、プログラムは人間が作るものである以上、さまざまなトラブルの種を抱えていることを忘れてはならない。
1946年に作られた世界最初の実用コンピュータＥＮＩＡＣは、配線の仕方によって実行できるアルゴリズムが決まるという代物で、使い勝手がきわめて悪かった。これを改良したのが数学者ノイマンのアイデアに基づくノイマン型のコンピュータで、はじめに「プログラム」を読み込み、これに従って逐次的にさまざまな作業を実行していく。コンピュータが、あたかも万能マシンのように多彩な機能を実現できるのは、グラフィクスや音声など多様な出力を持つプログラムを走らせているからである。
プログラムは、入力・変数代入・各種演算（+-*/など）・流れ制御〔条件分岐(if… else…)・繰り返し(for… )・ジャンプ(goto… )〕・出力を行う。出力をグラフィック画面やシンセサイザーに設定することにより、画像や音楽を扱うこともできる。
下に、きわめて簡単なＣ言語プログラムの例を示しておこう。
これは、２項の足し算・引き算が入力されたときに計算を行うだけのプログラムで、次の手順で作業を行う。
このプログラム（keisanと命名しておく）を実行すると、次のように出力される。
このように、足し算・引き算を行うだけの単純なプログラムでも、見た目にわかりにくい表記が20行ほども続く。１箇所でもカンマを打ち忘れたり、括弧の対応がとれていなかったりすると、プログラムは全く動かないか、適切に動作しない。
事務で使用されるプログラムは短いものでも数百行に及び、その中には「判断」が数十個、「分岐パス」が数千通りもある。分岐パスが膨大になるのは、それぞれの判断の組み合わせが爆発的に増えるからである。プログラミングするときには、どのパスを通ってもコンピュータが正常に動作することを目指さなければならない。このことが、プログラマにとって悩みの種となる。
「バグを抹消することは難しい。ソフトウェアの規模がますます巨大化・複雑化し、すべての可能性をプログラムすることが不可能になってきたからである。ある研究報告によれば、5000年間プログラムを実行して１回しか障害を起こさないような小さなバグがシステムの安全性を損ねている。さまざまな角度から検査を行うのだが、米国の民間航空機のように１時間当たり10億分の１以下の障害発生率が要求されるシステムでは、こうしたバグを除去するには数十万年間も検査をし続けなければならない」（「巨大ソフトウェアに潜む危険性」(日経サイエンス1993.1.)）
こんにち、コンピュータなくしては、高度に技術化されたシステムの運用は困難である。膨大な装置群をリアルタイムで制御することは、もはや人間の能力を超えており、あらかじめ作成しておいたプログラムに基づくコンピュータの支援を受けて、はじめて可能になる。こうして、人類は大型旅客機や原子力発電所のような巨大システムを扱えるようになったが、その一方で、コンピュータの誤作動によるトラブルに見舞われることになった。
コンピュータの場合、ハードウェアそのものが故障する確率は、可動部がある機械と比べるとかなり小さい。むしろ、広義のプログラム（ＯＳ・アプリケーション・通信プロトコル・ＬＳＩのマイクロコードなど）にバグ（プログラムのミス）があり、それが原因となってコンピュータが誤作動する方が多い。バグ(bug)という語はもともとは「虫」の意味で、初期のコンピュータに蛾が飛び込んで故障させたという事実が語源になっている。実際の虫が入り込んだ訳でもないのにコンピュータがうまく動かなくなったとき、プログラムの中に「虫（バグ）」がいると洒落て言ったのが、いつの間にか、技術用語として定着したものである。
数万行以上の巨大なプログラムになると、（上の引用文にあるように）バグが全くないプログラムを開発したり、すでに存在するバグを完全に取り除くことは、ほとんど不可能とも言える。Windows95/98のように普及しているパソコン用ＯＳや一太郎（ジャストシステム社製ワープロ）などのベストセラーソフトにも多くのバグが存在しており、しばしばユーザーを悩ませる。
単なる論理的命令の集まりでしかないプログラムのミスが取り除けないことは、一般の人には不思議に思えるかもしれない。しかし、多くの状態変数を取り扱う場合、いわゆる 「組み合わせの爆発（combinatorial explosion）」が起きて、完全なバグ取りが技術的に困難になってしまう。一般に、プログラミングを行うときには、（ある変数がどの範囲にある、ウェイティング・リストがどれだけある──などの）コンピュータの内部状態に応じて次に行うべき作業を決める。ところが、独立変数が増えるにつれて内部状態は指数関数的に増大するため、全ての可能な状態を調べ尽くすことは困難になる。例えば、0と1の２値をとる変数10個によって状態が定まる場合、可能な状態数は、各変数が0ないし1を取っているときの組み合わせの総数なので、210＝1024となる。巨大なプログラム（市販のアプリケーションは最大数百万行になる）では、変数の個数も各変数が取り得る値域もはるかに多いので、考慮しなければならない状態数は、天文学的なものになる。特に、連続的に入力される信号にリアルタイムで応答していくことが要求されるシステムでは、入力ミスも可能な状態の中に含まれるため、いかなる状況に置かれても誤作動を起こさないプログラムを作成するのは、もはや人間にできる作業ではない。
こうして、故障したわけでもないのにコンピュータが誤作動してトラブルを引き起こすケースが跡を絶たない。いくつか、事例を挙げておこう。
バグのためにコンピュータ利用者が損害を被った場合、ソフトウェア制作者に賠償請求することは可能だろうか。“不良品による損害”なのだから、当然請求できると思いきや、これが意外と難しい。その理由は、ソフトウェアの利用契約書に免責条項が盛り込まれているからである。
一般のユーザはあまり意識していないかもしれないが、購入したソフトには必ず契約書が（紙の書類あるいは電子文書の形で）添付されており、ソフトを使用する際に（押印やサインをしなくとも）この契約に同意したことになっている。この契約書の中には、通常、次のような条項が含まれている。
「弊社は、…本製品の品質および機能がお客様の使用目的に適合することを保証するものではなく、また本契約書に明示的に記載された以外(*)、一切本製品についての瑕疵（カシ）担保責任および保証責任を負いません。本製品の選択導入はお客様の責任で行っていただき、本製品の使用およびその結果についても同様とします」（ジャストシステム社製ワープロソフト一太郎に同梱されていた使用許諾契約書より）
(*)「購入された日から90日間に限り、メディアやマニュアルに物理的な欠陥があった場合には無料で交換」「購入された日から１年以内に弊社がソフトウェアの誤り（バグ）を修正したときは、かかる誤りを修正したソフトまたはそれに関する情報をお客様に提供」
法律用語が含まれていかにも晦渋な文章だが、要は、「製品にバグがあったとしても、会社は（バグのない製品と交換したりバグによる損害を弁償するなどの）責任をいっさい負わない。それが嫌なら、このソフトは使わないでくれ」ということだ。内容的には、次のような平明な文章と同じである。
「このプログラムを使用した事によって生じたトラブルや障害・災害などに対して作者は一切の責任を持たないものとします。このプログラムの利用はすべて利用者の責任において行ってください」（あるオンラインソフトのマニュアル）
いかにも無責任な条項に思えるかもしれないが、ソフトの制作者がこうした「予防線」を張るのは、先にも述べたように、プログラムのバグを完全に抹消することが現実問題として不可能だからである。コンピュータといっても、さまざまなメーカーから多くの機種が販売され、あるマシンではうまく動作しても別のマシンでは動作がおかしくなることは日常茶飯事である。したがって、限られた環境でしかプログラムの動作を確認できない制作者が、予想される全てのケースに対して責任を負わなければならないとするのは、あまりに酷である。バグに関する責任問題を全て回避しようというのが、この免責条項の狙いである。
現在、日本ではＰＬ（製造物責任）法が施行されており、製造物の欠陥が原因で被害が発生した場合には、過失があるか否かを問わず、メーカーに賠償責任が発生することが明記されている。このため、プログラムに関しても、バグが原因となって損害を被った人は、ＰＬ制度に準拠して何らかの賠償を受けられると期待できるかもしれない。実際、アメリカでは、社員の給与計算に表計算ソフトを使用していた経営者が、プログラムのバグが原因で給料を払いすぎてしまったとしてＰＬ訴訟を起こしたこともある（ただし、このケースは、入力ミスが過払いの原因であることが判明して原告側が敗れている）。しかし、ソフトウェアは、（法律制定の際に衆院の専門部会で明言されたとおり）ＰＬ法の適用対象外になっており、バグによって損害が発生したとしても、ソフト制作者に製造物責任が認められることはない。
しかし、その一方で、パッケージ・ソフトとして販売されているものについては、「製造物」としてＰＬ法が適用されるべきであり、バグが原因でユーザーが（通常予想されないような）損害を被ったときには、ソフト制作者が賠償すべきだとの見解もある。一部のソフト会社は、アプリケーションの販売で莫大な利潤を得ており、企業として当然の社会的責任を負うというのだ。この考えを採用する学者の中には、契約書に含まれる免責条項自体が、「公序（公の秩序）」に反するものとして民法上無効だと主張する人もいる。現段階では、ソフトに関するＰＬ訴訟の判例がないこともあって、どの見解が正当かを明確に主張することは難しいが、今後とも考えていかなければならないテーマである。
1986年3月21日、Ｂ.コックス（男性，38歳）は、東テキサスがんセンターで背中にできた腫瘍を治療するため放射線照射を受けることになっていた。使用される放射線治療機は、アトミック・エナジー社製のセラック25というマシンで、数千人の患者に対する治療実績があり、信頼性が高いと言われていた。コックス自身、すでに放射線治療を経験しており、このときも、所定の寝台の上に横になっていた。ところが、スイッチが入れられた途端に肩に激痛を感じて、ベッドから転げ落ちるようにして、隣室でモニターを見ながら操作していた医者に助けを求めた。治療機のモニター表示では放射線量に異常がなかったので、担当医は緊急措置を執らなかったが、数日後にはコックスの体に放射線障害の兆候が現れ、半年後に死亡した。同様の事故が他に６件（うち死亡１件）報告されている。
事故の原因は、セラック25を制御するプログラムにバグがあったため。この機械では、大きなエネルギーで発生させたＸ線を間接的に照射する方法と、小さなエネルギーで作った電子線を直接的に照射する方法を選択することができる。ここで、オペレータが「電子線」を表す“ｅ”キーを押すべきところを間違えて「Ｘ線」の“ｘ”キーを押し、これをカーソルキーを使って８秒以内に修正すると、プログラムが正常に動作せず、Ｘ線を発生させるのに必要な高エネルギーの放射線を、電子線の場合と同様に直接患部に照射してしまう。放射線量は、致死量の25倍以上の2万5000ラドになったと推定される。問題の８秒間は、放射線発生装置がエネルギーを蓄えている時間で、この間はコンピュータからの制御指令が適切に伝達されていなかった。入力ミスの修正には、通常のオペレータは８秒以上要するが、何度も同じような操作を行って手慣れているオペレータは、８秒以内で速やかに行うことができた。
この放射線治療機の事例は、かなり重要な問題を含んでいる。問題となった治療機は、専用の治療室を必要とするために設置には数百万ドルを要する高価な装置であるため、合衆国では数ヶ所の専門病院でしか使われていないが、同種の機械の中では信頼性が高いものとされていた。実際、トータルで数千件の治療を行ったうち、問題を起こしたのは上記の６件だけであり、この機械で延命できたガン患者も多い。しかし、制御用のプログラムは、アトミック・エナジー社に以前在籍していたプログラマが単独で数年をかけて開発したもので、この種のプログラムにありがちなことだが、きわめて見通しが悪くデバッグ（バグの修正）が困難な代物であった。プログラムのバグは特定の操作を行ったときにコンピュータが誤作動することで発見されるが、誤作動を引き起こす操作が、このケースのように（「入力ミスを行って８秒以内に修正」という）稀にしかなされないタイプのものであるときには、バグの発見が遅れて、重大な帰結をもたらすことがある。この事故は、繰り返し試運転を行っても取り除くのが難しいバグが存在するという教訓を与えてくれる。
特に議論を要するのは、事故の責任の所在である。被害を受けた患者や家族からすると、病院での治療中に傷害を受けたことになるので、医療ミスとして担当医や病院を訴えがちだが、こうしたケースでは、事故の原因は、治療機を操作したオペレータや治療に当たった担当医にはなく（操作ミスは過失とは言い難い軽微なものである）、マシンを製作したメーカーにあるので、損害賠償請求もアトミックエネジー社に対して行うべきだろう。ただし、制御用プログラムを制作したのが（この例のようにメーカーに在籍したプログラマでなく）外注のソフト会社だった場合は、問題は錯綜してくる。メーカー側は、事故は機械の故障ではなくプログラムの不良によって引き起こされたものとして、責任をソフト会社に転嫁しようとするだろう。一方、ソフト会社は、プログラム開発を受注するに当たって免責条項を含む契約を交わしていることが多く、これを盾に損害賠償に応じないと予想される。一般論では、放射線治療機のように装置自体に危険なファクターが存在している製品については、安全性に関する最終責任は、製品を出荷する（組み立て）メーカーが負うべきだと考えられる。しかし、今後は、バグのあるプログラムを内蔵した制御ユニットを部品メーカーが納入したようなケースで、賠償負担を巡って裁判が紛糾することもあり得るだろう。
プログラムの不良が原因となってコンピュータが誤作動するケースとして、1999年末に大きな騒動を巻き起こしたのが、いわゆる「2000年問題」である。これは、本来は（19XX年という）４桁の西暦年号を、コンピュータ内部で「下２桁」だけで（XX年というように）扱ってきたことが原因で発生するトラブルである。コンピュータの利用が進んだ1960〜70年代当時は、ハードウェアが非常に高価だったため、メモリやディスクの使用量を削減することが重要課題であり、年号の表記に常に伴う「19」を省略することが習慣化された。その後は、プログラムやデータの変更に多大なコストが必要になる、ソフト資産の継承のため仕様を変更できない──などの理由で対応が遅れていたものである。古いプログラムを修正しないまま使い続けて、2000年の1月1日以降に日付データを使った計算（利息計算や年次集計）を行うと、処理結果に誤りが生じ、内容によっては企業に多大な損害を与える危険性が懸念された。
2000年問題への対応は1998年頃から慌ただしく進められ、そのために要した費用は、アメリカで約2000億ドル、日本で2兆数千億円に上った。電気・ガス・通信・交通・金融部門では1999年末までに対応を終えていたので大きな混乱はなかったが、福島第２原発で制御棒の位置が表示されないなど、軽微なトラブルが多発した。また、中小企業の8.5％で何らかの問題が発生したと報告されたが、実数はそれよりもかなり多いと推定される。
2000年問題についての詳細は、「科学の回廊」−「2000年問題」参照。
このセクションの内容は、
巨大システムの危機−日本におけるシステム危機−コンピュータ・システム障害
と重複するので省略します。
このセクションの内容は、
巨大システムの危機−コンピュータ・クライシス−反抗するコンピュータ
と重複するので省略します。
©Nobuo YOSHIDA