セラック25

セラック25：ソフトウェアの欠陥が招いた悲劇

セラック25は、カナダ原子力公社(AECL)とフランスCGR-MeV社が共同開発した、コンピュータ制御による放射線治療機器です。しかし、1985年から1987年にかけて、この機器は6件の過剰被曝事故を引き起こし、少なくとも5人の患者が命を落とすという、深刻な事態を招きました。

これらの事故の根本的な原因は、セラック25の制御ソフトウェアに潜む並行プログラミングのバグ、いわゆる競合状態でした。このバグにより、患者は意図された量の数百倍もの放射線を浴びてしまい、重傷を負ったり、命を落としたりしたのです。この悲劇は、生命に関わるシステムにおけるソフトウェア制御の危険性を強く示唆し、医療情報学やソフトウェア工学における標準的な事例研究として、今もなお教訓を伝えています。

また、技術者の過信や、報告されたソフトウェアのバグに対する適切な対応の欠如も、事故の大きな要因として挙げられます。技術者たちは、自分たちの初期の作業を過信し、エンドユーザーからの主張を十分に検証しなかったのです。

開発の背景

セラック25は、AECLとCGR社によって、医療用線形加速器セラック6とセラック20の後継機として開発されました。セラック6は6MeVまでのX線を、セラック20は20MeVのX線と電子線を生成できました。一方、セラック25は、AECLが新たに開発したダブルパス技術を採用し、よりコンパクトなサイズで25MeVまでのX線と電子線を生成することが可能になりました。

これらの機器は、PDP-11というコンピュータによって制御されていましたが、セラック25は、従来の機器とは異なり、最初からコンピュータ制御を前提に設計されていました。また、従来機ではハードウェアで実装されていた監視装置が、セラック25ではソフトウェアで実装され、メンテナンス性が向上しました。しかし、ソフトウェアにはCGR社が開発したセラック6用のコードが多く流用され、セラック20用のコードも混入していました。このセラック20のコードにはバグが含まれており、後の事故を引き起こす要因の一つとなりました。セラック20にはハードウェアによる安全装置があったため事故は発生しませんでしたが、このバグはセラック25の事故調査で明らかになりました。

1976年にはプロトタイプ機が製造され、1982年には商業的に販売が開始されました。1983年には危険性分析が行われましたが、これはソフトウェアのバグの存在を仮定しない、不十分なものでした。

セラック25の設計

セラック25には、2つの主要な放射線治療モードがありました。

直接電子線治療モード: 5MeVから25MeVの高エネルギーの電子線を、磁石で治療部位全体をスキャンします。
超高圧X線治療（または光子）モード: 25MeVの電子線をターゲットに衝突させ、放出されるX線を平坦化フィルターとコリメータに通し、照射します。

さらに、「フィールドライト」モードも搭載されており、可視光で治療領域を照らすことで、患者の位置決めを正確に行うことができました。

問題の発生

記録された6件の事故は、X線モードで発生させた大電流の電子線を患者に直接照射した際に発生しました。これらの事故の原因は、2つのソフトウェアの不具合にありました。

1. オペレータがX線モードを誤って選択し、すぐに電子モードに切り替えた場合、X線ターゲットが配置されていない状態で電子線が照射されてしまう。
2. ビームスキャナが作動していないフィールドライトモード中に電子線が作動してしまい、ターゲットが配置されていない状態で電子線が照射されてしまう。

従来のモデルでは、このような欠陥を防ぐためのハードウェアによるインターロックが存在しましたが、セラック25ではそれらが取り除かれ、ソフトウェアによる安全チェックに依存していたのです。

大電流電子線は、意図された線量の約100倍の放射線量で、より狭い範囲に照射され、致死量の可能性のあるベータ線を患者に浴びせました。患者の一人は、この感覚を「強烈な電気ショック」と表現し、悲鳴を上げて治療室から飛び出したと言います。数日後、放射線熱傷が現れ、患者は放射線中毒の症状を示しました。3つのケースでは、負傷した患者は過剰照射の結果として死亡しました。

根本原因の解明

調査委員会は、事故の主な原因を、特定のコーディングエラーではなく、ソフトウェアの設計と開発の仕方の悪さにあると結論付けました。特に、セラック25のソフトウェアは、クリーンで自動化された方法でテストすることが現実的に不可能だったのです。

事故を調査した研究者たちは、以下のような制度的な原因を発見しました。

AECLは、ソフトウェアコードを独立してレビューせず、オペレーティングシステムを含む社内のコードに依存していた。
AECLは、機械の故障モードを評価する際に、ソフトウェアの設計を考慮せず、ソフトウェアにはバグがないと主張していた。
機械オペレータは、過剰照射は不可能であるとAECLの担当者から説明を受けており、セラック25が事故の原因であるとは考えなかった。
AECLは、セラック25が病院で組み立てられるまで、ソフトウェアとハードウェアを組み合わせたテストを実施していなかった。

さらに、研究者たちは、以下のような技術的な問題点も発見しました。

エラーメッセージは、単に「MALFUNCTION」という単語の後に数字が表示されるだけで、ユーザーマニュアルにはエラーコードの説明や対処法が記載されていなかった。
システムは、マシンを停止させて再起動する必要があるエラーと、一時停止させるだけのエラーを区別していたが、患者を危険にさらすようなエラーも一時停止させるだけであり、オペレータは機械の一時停止を解除することに慣れてしまっていた。
PDP-11コンピュータを制御するVT-100端末で特定のキーストロークシーケンスを入力すると、誤ったモードで電子線が照射される可能性があった。
この設計には、ターゲットが設置されていない状態で電子線が照射されるのを防ぐためのハードウェアインターロックがなかった。
技術者は、ハードウェアのインターロックに依存していたセラック6とセラック20のソフトウェアを再利用し、既存のエラーを見落としていた。
ハードウェアは、ソフトウェアがセンサーの動作をチェックする方法を提供していなかった。
* ソフトウェアは、フラグ変数を設定する際にインクリメントを使用しており、算術オーバーフローによってフラグがゼロに戻り、安全チェックがバイパスされることがあった。

この事件から、ソフトウェアの再利用が必ずしも安全性を保証するものではないこと、ソフトウェアにコード化された思考体系を盲信することが危険であることが教訓として示されました。この事件を受けて、医療機器ソフトウェアの開発ライフサイクル標準を導入したIEC 62304規格が作成されました。

セラック25の事故は、ソフトウェアの安全性に対する意識を高め、より厳格な開発プロセスとリスク管理の重要性を認識させるきっかけとなりました。この悲劇を繰り返さないために、私たちは過去の教訓から学び続ける必要があります。

もう一度検索