Therac-25：放射線治療器が患者を殺した並行処理バグ

何が起きたか

横にスクロール

Therac-25は、カナダ原子力公社AECL（Atomic Energy of Canada Limited）が開発した医療用の放射線治療器である。がん治療のために、低出力の電子線と高エネルギーのX線という二つのモードを一台で切り替えられる装置として、1980年代前半に北米の複数の医療機関へ導入された。コンピュータ制御によって操作を簡便にした、当時としては先進的な設計だった。

しかし1985年から1987年にかけて、この装置は少なくとも6件の重大な過剰照射事故を引き起こす。処方された線量の数十倍から百倍ともいわれる放射線を浴びた患者が相次ぎ、複数の患者が死亡、あるいは深刻な後遺症を負った。がんを治すための装置が、人の命を奪う結果となったのである。

当初、製造元は装置が過剰照射を起こしうること自体を否定し、原因の特定は難航した。ある物理士が現場で操作を辛抱強く再現して初めて、問題の存在が具体的に示されたという。事故が孤立した機器の不良ではなく設計に根ざすものだと認められるまでには時間を要し、その間にも被害は繰り返された。

事故の多くに共通していたのは、装置の挙動と表示の食い違いだった。患者は照射の瞬間に激しい灼熱感や電撃のような痛みを訴えたが、オペレータの画面には「線量が不足している」といった趣旨の表示が出ることがあった。装置は日常的に多数のエラーで停止しており、その一つが意味の読み取れないエラーコード「Malfunction 54」だった。

日々頻発する無害な停止に慣れたオペレータが、警告そのものを軽視するようになっていたことも被害を広げた。装置からの信号は「いつもの誤作動」と区別がつかず、本当に危険な状態を伝える役目を果たせなかったのである。

技術的な根本原因

Therac-25には、出力の全く異なる二つの動作モードがあった。一つは低出力の電子線を直接照射するモード、もう一つは高出力の電子ビームを金属製のターゲットに当て、X線に変換して照射するモードである。X線モードでは変換の過程で大半のエネルギーが失われるため、電子ビームそのものの出力は電子線モードの百倍近くに達する。この高出力ビームは、ターゲットとフィルタを備えたターンテーブルが正しい位置にあることを絶対の前提としていた。

事故の中核にあったのが、オペレータの高速な入力操作で顕在化するレース条件、すなわち並行処理のバグである。装置の内部では、オペレータの入力を受け付けるタスクと、治療の物理設定を準備するタスクが並行して動いていた。両者は共有変数を介して「入力が完了したか」といった状態を受け渡していたが、この受け渡しには時間的な隙があった。並行処理の難しさはOSのプロセス管理にも通じる、普遍的な課題である。

熟練したオペレータが、モード指定を入力した直後にごく短い時間内で設定を編集し直すと、二つのタスクの認識がずれる。装置は「X線用の高出力」という設定を保持したまま、ターンテーブルは電子線モードの位置、すなわちターゲットが挿入されていない状態のままビームを発射してしまう。ターゲットで減衰されるはずの高出力ビームが、そのまま患者の体に届いたのだ。

さらに、状態を管理する共有変数の扱いにも欠陥があった。ある内部カウンタが一定回数ごとにオーバーフローしてゼロに戻る瞬間、本来行われるべき安全確認の一部が飛ばされる経路が存在した。オペレータの操作がその瞬間と偶然重なると、位置の検査をすり抜けてしまう。いずれも、タイミングが噛み合ったときにだけ牙をむく、再現のきわめて難しい不具合だった。

そして最大の設計判断の誤りは、安全の拠りどころをソフトウェアだけに置いたことだった。前世代のTherac-20やTherac-6には、危険な状態でビームが出ないよう物理的に阻止するハードウェアの安全インターロックが備わっていた。Therac-25はこれを撤去し、同種の安全確認をソフトウェアへ肩代わりさせた。しかも旧機種から流用されたコードは、もともとハードウェアに守られていることを暗黙の前提としており、その前提が外れた新しい文脈での安全性は検証されていなかった。しかもTherac-25には、ターンテーブルの位置とビーム出力の食い違いを独立に検知して照射を止める仕組みが存在しなかった。ソフトウェアが誤れば、それを覆す最後の砦がどこにもなかったのである。

加えて、開発体制そのものにも問題があった。安全に関わるソフトウェアが実質的に少人数で作られ、第三者による独立した安全性レビューや、システム全体を対象とした危険分析が十分に行われなかった。個々の部品の信頼性は評価されても、部品を組み合わせた全体が危険な状態へ陥る筋道は見落とされていたのである。

教訓

Therac-25が残した教訓は、今日のソフトウェア工学にそのまま通じる。

第一に、安全を単一の仕組みに依存させてはならない。ソフトウェアは必ず欠陥を含みうるという前提に立ち、物理インターロックのような独立した防護のレイヤーを重ねる多重防護（多層防御）が要る。ソフトが誤っても、最後にハードが致命的な出力を止める構えである。

第二に、並行処理の検証は本質的に難しい。レース条件は、テストで「動いた」ことが正しさを意味しない領域だ。共有状態への安易な依存を避け、競合が起こりうる箇所を設計の段階で洗い出し、レビューやモデル検査で潰しておく必要がある。

第三に、エラーメッセージは安全機構の一部である。「Malfunction 54」のような意味の乏しいコードの乱発は、オペレータを警告に鈍感にさせ、危険を伝える最後の砦を崩す。異常時には安全側に倒れ（フェイルセーフ）、何が起きているのかを人間へ正しく伝える設計が欠かせない。

第四に、独立した安全性レビューと、全体を見る危険分析が不可欠だ。作った本人には見えない前提の穴を、外部の視点とシステム全体の視野が埋める。流用したコードの安全性の前提が新しい文脈でも成り立つかを問い直す姿勢も、ここに含まれる。

まとめ

Therac-25の事故は、単なるプログラムのバグではなく、安全をソフトウェアだけに委ねた設計思想、検証しにくい並行処理、人を欺くエラー表示、そして独立レビューの不在が重なって起きた複合的な失敗だった。技術は人の命を救いもすれば、奪いもする。だからこそ、犠牲となった患者への敬意とともに、その原因を正確に語り継ぐことに意味がある。ソフトウェアの安全設計を考えるうえで、この事故は今なお最重要の教材であり続けている。自動運転車や医療機器など、ソフトウェアが人命を直接左右する領域が広がる今日ほど、その重みは増している。関連する障害の分析はインシデント事例、他の事故の解説は工学の大惨事から辿れる。