あの事故はなぜ起きたのか!! （3） ―― エビデンスとしての文書

●○●　Column　●○●
こうしておけば事故は防げた

吉岡 律夫

　ここでは制御やコンピュータに関する主な事故例を取り上げ，これらの事故の原因は全安全ライフ・サイクルのどのフェーズが良くなかったのか，あるいは抜けていたのか，について評価をしてみました．なお，取り上げた事故例，特に事故原因は，筆者の独断と偏見によることを最初にお断りしておきます．

1. 株式の大量誤発注事件

　みずほ証券は2005年12月8日，東京証券取引所（東証）に上場したジェイコムの株式について，「61万円で1株売る」とすべきところを，誤って「1円で61万株売る」と注文してしまいました．みずほ証券は直後に注文取り消しの手続きを取りましたが，東証のシステム障害で取り消し指示が受け付けられず，損失が膨らむ結果となりました．みずほ証券は注文取り消し指示を出した後に発生した分の損失は東証に責任があると主張し，2006年9月8日，400億円の損害賠償を請求しています^（1）．

　東証が本件のような注文取り消しが起きた場合を想定して，メーカ側（F社）に仕様書で明記していたかどうかは不明ですが，まずは，システムのリスク評価フェーズを着実に実行すべきでした．IEC 61508では，システムのリスク評価を誰が実施すべきかを規定していません．つまり，発注者自らが実施してもよいし，受注者に実施させてもよいわけです．しかし，調達時にリスク評価をどちらかが実施することを明記していれば，過去の誤発注事件を調査分析して対策を取り入れていたでしょうから，本事件は防げた可能性が高いでしょう．一方，仕様書に明記されていたにもかかわらず，そのように製作していなければ，製作フェーズの着実な実行がなされていなかったのでは，と疑われます．

2. 東海道新幹線ATCのプログラム・ミス

　新型ATC（列車自動制御装置）のコンピュータが東海道新幹線を緊急停止させた事件が2006年3月18日以来，19件発生しました．そのうちの12件は，各新幹線に搭載したATC用コンピュータのメモリ不足が原因でした．先行している新幹線の速度が相対的に速いと，自列車のATCの取得する相手位置の情報が増えていきます．その際に，この情報を格納しておく領域が不足した結果，コンピュータが異常と判断し，列車を緊急停止させました．そのほかの3件は，ATC用コンピュータの処理能力の問題で，0.1秒以内に先行列車と自列車の位置情報を（線路上のトランスポンダから）同時に受け取ると，コンピュータが処理しきれずに異常と判断したものです^（2）．

　本件はATCの故障（ソフトウェアの不具合）によって列車が停止したわけで，機能安全からすると，人身事故につながる危険側故障ではなく，安全側故障に分類されます．しかし，社会的影響の大きい事象を防ぐために機能安全を適用することは適切であると，IEC 61508でも規定しています．また，本件のソフトウェア欠陥は，場合によっては，コンピュータのフリーズや暴走につながりかねない危険な事象であることを考えると，ソフトウェア設計製作段階でのライフサイクルの仕組み（フォールト・アボイダンス技法とフォールト・トレランス技法）を採用していれば防ぐことができたでしょう．

3. エレベータ死亡事故

　2006年6月3日，エレベータから自転車に乗ったままの高校生が降りようとしたとき，突然，上昇したS社製エレベータに挟まれて死亡する事故がありました．事故の直接の原因は特定されていませんが，本来，扉が開いたままでは上下動しないように，コンピュータが監視制御していなければならないはずでした^（3）．

　この事故の後に，同社のほかのエレベータを調査した結果，過去のプログラム欠陥が明らかになりました．扉が閉まった瞬間から0.25秒以内に「開」ボタンを押した場合，扉が開いた状態でカゴが昇降してしまう，という欠陥でした．この欠陥は既に1993年に判明しており，同社はプログラムを修正したのですが，3基が修正リストから漏れ，6基は別の改修をした際に，欠陥プログラムを誤って再び搭載してしまっていました^（4）．

　上記のように，死亡事故の直接原因は特定されていませんが，扉が開いたまま上昇したわけですから，安全系を構成するセンサ，コンピュータ，アクチュエータ（ブレーキなど）の組み合わせのいずれかの欠陥と考えられます．特に機能安全の点からは，現場の劣悪な環境で使用されるセンサやブレーキの故障や異常を監視制御すべきコンピュータに対して，要求機能とその信頼度（安全度水準）を明示すれば，事故防止の一助となったでしょう．

　一方，適切な保守がなされていなければ事故につながる場合もあります．とりわけ保守は人間が関与する部分なので，悪意がなくてもヒューマン・エラーは起こり得ます．従って，保守段階でのヒューマン・エラーを想定し，これを防衛するという機能安全に基づいた設計を採用すべきでした．

　なお，別のエレベータで起きたプログラム欠陥については，保守フェーズにおける部分改修での機能安全管理がなされれば，適切な処理となったはずです．また今後，制御系と安全系を分離し，制御系の欠陥や暴走に対して防護できる安全系を設置するという機能安全管理の設計を取り入れるべきでしょう．

　エレベータは，明治以来100年以上使われ，落下による死亡事故は例を聞かず，S社もいうように「エレベータは世界中で最も安全な乗り物」です．事故に至る前の事象を「インシデント」といいますが，いくつかのインシデントが重なってアクシデントになるというわけです．だからインシデントの段階で対策すればいいわけですが，そもそも「事故は起きない」という信念・誤解・妄想を持ってしまうと，そのインシデントが無視されてしまうことになります．そういえば，2004年の森ビルにおける回転ドア事故も同じ状況でした．リスク評価を始めるまでに困難があるのです．事故を防ぐには，着実な安全ライフサイクルの実行しかありません．