ソフトウェアの特性を考慮せず事故が起きた事例

【1985年～1987年に起こった放射線治療器 Therac 25（セラック25）の事故】

Therac-25は高エネルギーの透過性放射線を患者の身体の奥に照射し、周囲の組織を傷つけることなくがん細胞を破壊する装置で、巨大なアームの照射口からは、電子線とX線の二種類の放射線が照射される。

 透過性の高いX線を生成するときは、高エネルギーの電子の流れを金属製のターゲットにぶつけ、電子線生成モードのときは、金属のターゲットを自動的に移動して電子線のエネルギーレベルを下げ、直接腫瘍にビームを送る。低エネルギーの電子線はX線より透過性が低いため、皮膚の表層に近いがんの治療に使われた。Therac-25はいわゆる組込みソフトウェアで動く機器だが、1980年台の装置でソフトウェアはPDP-11（※1） というミニコンピュータを使って制御を行っていた。

※1 PDP-11 は、ディジタル・イクイップメント・コーポレーション(DEC)が1970年代から1980年代に販売した16ビットミニコンピュータシリーズ。

Therac-25 の事故では複数の医療機関で放射線治療装置が誤動作し、過大な放射線を浴びた患者に死傷者（6名）がでた。この事故はソフトウェアの不具合が原因であり、見えないソフトウェアのせいで再発防止が進まない中、ナンシー・レブソン（現マサチューセッツ工科大学教授）らの努力により事故原因が詳細に調査され、レポートが発表されており、このレポートは20年以上たった今でも、ソフトウェアエンジニアにとって深い教訓として伝えられてる。（※『セーフウェア』 翔泳社 2009 に詳細が記載されている。インターネット上ならば、こちらでも英文でレポートを読むことができる）

Therac-25 の事故は20年以上も前に起こった事例だが、ナンシー・レブソンの詳細な調査により現代にいろいろな教訓を残した。

【Therac-25 は Therac-20 の後継機だった】

普通、後継機種の場合「枯れた」ソフトウェアを再利用できるため、安全や信頼は増す。実際、ソフトウェアの大半は　Therac-20のソースが使われていた。

それなのに何故事故が起きたのか。誤解されたくないので、ここで注釈を入れておく。ソフトウェアが絡んだ事故は「○○だから××である」といったように簡単には語れない。プリウスのブレーキソフト改変に関する分析だって結構な時間と労力をかけて書いた。（しかも、本当のことは分かっていないし、ソフトウェアの問題ではないかもしれない。）だから、本当に Therac-25 による事故の原因を知り、自分達のドメインの再発防止に利用したいのなら、必ず原本を読んでいただきたい。ここでは、あえて、複雑な問題発生の原因のうちの一端のみを紹介する。努々ここで紹介したことだけで6名もの犠牲者がでるような事故に発展したのではないことを理解していただきたい。20年も前のソフトウェアエンジニアだって、そこまでいい加減ではないということを強調しておく。

さて、枯れたソフトウェア資産を再利用しているのになぜ事故が起こったのかの。そもそも Teharc-20 のソフトウェアに混入していた不具合をハードウェアの安全装置でブロックしていたが、Therac-25 でその安全装置を取ってしまったことが原因の一端となっている。（実際、この安全装置が Therac-25 にも付いていれば最悪の事故は免れたと考えられている）

Therac-6 や Therac-20 では独立した安全装置が異常エネルギーの出力をブロックしていた。

そして、Therac-25 の開発をする際に、経済性の理由（たぶんコストダウンだろう）から、このハードウェアの安全装置をソフトウェアに置き換えた。そして、それによってもともと Therac-20 に内包していた不具合が表面化してしまった。（実際にはそんな簡単な話ではないがここでは簡略化して書いている）

当然のことながら、機器の品質保証担当は「そんなことして大丈夫か？」と思っただろう。そこで、Therac-25 の製造もとである AECL は1983年3月に Therac-25 に対する安全解析を実施した。

この分析は FTA（フォールトツリー解析）で行われた。FTA と FEMA は非常に有名な安全解析の手法なので、初めてこの言葉を聞いた方は インターネットでどんなものか理解しておいて欲しい。

この安全解析の結果 AECL は次のような報告を出した。

【『セーフウェア』 Appendix A.2 より引用】

1. ハードウェアエミュレータ上と遠隔治療装置の照射野条件の下で大規模な試験を行うことにより、プログラミングエラーは減少していた。未解決のソフトウェアエラーは分析には含まない。
   
2. 
   ソフトウェアは長期使用、疲労、あるいは再生産プロセスが原因で品質が低下することはない。
   
3. 
   コンピュータの実行エラーは、ハードウェアコンポーネントの欠陥や、α粒子や電磁ノイズによって引き起こされる「ソフト」（ランダム）エラーが原因である。
   

このレポートは複雑なソフトウェアを作ったことがない人が書いたのだろう。解説すると、1は、「ハード・ソフト込みのシステム（ハードウェアはエミュレータ）でさんざんいろいろな試験を行ったのでバグはほとんど潰した」ということだ。ハードウェアはエミュレータを使っているので異常状態、故障状態も再現できているので心配ないという主張だ。

残念ながらTherac-25 の事故から20年以上たった現在でも、ほとんどの機器がこの方法でシステムの安全を確認している。そして、そこにソフトウェアが絡んでおり、ソフトウェアの規模が大きく、複雑であればあるほど、そのやり方では漏れが生じる。

ちなみに、1で「未解決のソフトウェアエラーは分析には含まない。」は正直な申告だと思う。日本人ならこの一文は削除して報告しただろう。なぜなら、未解決のソフトウェアエラーが既存のシステムに影響を与えないという根拠は何もないからだ。そして、この安全解析報告の作成から実際の製品のリリースまでの間にソフトウェアが改変されたらその改変がデグレードを誘発しない保証はない。

2の「ソフトウェアは長期使用、疲労、あるいは再生産プロセスが原因で品質が低下することはない。」はハード屋さんがソフトウェアをどう見ているか端的に表している。ようするにハードウェアでは部品の故障や生産時のさまざまな問題があり、品質保証の活動とはこれらの問題をいかに押さえ込むかが我々の仕事なのだ、その点ソフトウェアは何回コピーしても品質が劣化しない、すばらしい、品質は完璧だと考えているのだろう。今となってはソフトウェアの不具合で商品をリコールすることは日常茶飯事になっているから、QA担当もそうは思っていないだろうが、多くのQAはソフトウェアは分からない、自分では品質を保証できないから誰かお墨付きをくれ！と考えているような気がする。

3は笑ってしまうが、ソフトウェアの実行エラーは放射線などでメモリーのデータ化けなどが原因であり、バグは1で潰しているから、ハードウェアや外部環境の影響からプログラムやデータを守れば大丈夫だと言っているのだ。

実際この安全分析の FTA には障害を発生させる原因コンポーネントとして、「コンピュータの故障」も含まれている。そして、「コンピュータが誤ったエネルギーを選択する」が発生する確率は 10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっている。

この発生確率は後にナンシー・レブソンらの分析によって何の根拠もないと結論づけられたが、その当時はおそらく　PDP-11 がハードウェア部品として故障する確率を示したのだろうと予想される。

このことから安全解析実施者はソフトウェアやソフトウェアの不具合についてほとんど知識がなくブラックボックスとして分析をしていることが分かる。

ソフトウェアの恐いところは、どんなに難しいオペレーションでなければ発生しない不具合でも、その通りに操作すると100%確実のその不具合は発生するということだ。その結果、Therac-25の場合は約3年間の間に 6名の犠牲者を出してしまった。

現在、トヨタのリコール問題でアメリカが騒いでいるのは、犠牲者が増えることをできるだけ抑えるための手順、プロセスを組織が定めて、それを確実に実施しなさい、また、その手続きの間に隠蔽や怠慢などがあったら絶対に許さない、責任はトップにあると言っているのだと思う。

事故が発生したときのオペレーションはその通りなのだが、ソフトウェアが絡んでいるときは困ってしまう。原因が簡単にはわからないし、事故の発生確率をはじき出すのが難しいからだ。だから、ソフウェアがらみのときは、事故の重大性だけでランクを判定する。例えば

※仮にソフトが関係していたと仮定して

・アクセルペダルが戻らない→重大

・低速でブレーキが抜ける感覚がある→軽微

・アクセルが急加速する→重大

といった具合だ。（ソフトウェアが原因だった場合は発生する確率は考慮できない）
国際安全規格のリスク(risk)の定義は危害(harm)の発生確率×危害の重大(severity)である。しかし、ソフトウェアに起因するリスクにおいては発生確率はハードウェアの部品故障率のようなものにはできない。原因が分かってしまうと直せるなら直せと言われてしまう。

今後、ソフトウェアをブラックボックスにしかとらえられないハードウェア出身の組織上位層や品質保証担当が、自組織や協力会社が作ったソフトウェアの安全性や信頼性について第三者に安全性や信頼性についてお墨付きを付けてもらおうという動きが増えることが目に見えているが、ここではっきり言っておくがその考え方では絶対に安全は確保できない。

なぜなら、大規模複雑化したソフトウェアの各サブシステムの統合時のわずかな検証漏れ、設計コンセプトの考え方の違いなど、設計者達のヒューマンエラーに起因した問題は、設計サイドの技術者がアーキテクチャを可視化して、自分達で問題点を見つけないと見つからない可能性が高いからである。