- Therac-25医療用放射線機器で致命的な事故が発生
- ソフトウェア欠陥により、複数の患者が深刻な過剰被ばく
- 既存の安全システムをデジタル制御システムに置き換えた結果、問題が発生
- 欠陥診断とコミュニケーションの欠如により、事故原因の特定が遅延
- 安全上の重要な教訓として、アルゴリズムの信頼性と徹底したテストの重要性が強調された
Therac-25事件の概要
- Therac-25は治療用放射線医療機器として広く使用されていた
- この装置は、がん患者に対して高線量の放射線を照射する役割を担っていた
- 過去の機械式インターロック（interlock）安全装置をソフトウェアベースの制御システムに置き換えた
- しかし、この変化によってソフトウェアエラーが生じるリスクが高まった
事故発生の経緯
- 特定の作業手順や高速な連続入力の際に、プログラムに欠陥が発生
- その結果、安全装置が正常に作動せず、患者が設計値を超える強度の放射線を照射された
- 1985〜1987年の間に複数の患者に深刻な過剰照射事故が発生し、一部は死亡した
- 当初は、放射線機器の欠陥原因としてソフトウェアの問題が見過ごされる傾向があった
問題の原因
- 信頼性検証の過程で、実際の臨床環境を反映していない単純なテストしか行われなかった
- エラー処理とインターロック管理の不備により、極端な状況でアルゴリズムエラーが発生
- 製造元と病院の間に明確な問題報告およびコミュニケーションシステムの不在があり、欠陥の認識と解決が遅れた
- この事件は、安全中心のソフトウェア設計の失敗と評価されている
主な教訓
- 安全に直結するアルゴリズムを設計する際には、徹底した検証と防御的プログラミングが必要
- テストケースの多様化と、実使用シナリオに基づくシミュレーションが必須
- 各種エラー処理ループとログシステムの体系的な実装の重要性が強調された
- 高い信頼性が求められる分野では、ソフトウェアのみに制御を依存することの危険性を認識すべき
- この事件は、世界のソフトウェア工学と医療機器産業において、アルゴリズムの信頼性、安全性管理、コミュニケーション体制の重要性を再認識させた代表的な事例である
1件のコメント
Hacker Newsの意見
ソフトウェア品質は、単に優れた開発者がいるから生まれるものではなく、組織全体にまたがるプロセスの最終成果物であることを強調している。このプロセスは開発慣行だけでなく、テスト、経営陣、さらには営業やサービスにも影響する。Therac-25事件から学ぶべき点は、型システムや単体テスト、防御的なコード記述だけでは問題はすべて解決しないということだ。本当の失敗は、事故の報告、調査、修正までにあまりに長い時間がかかったことにあると思う。最近のCautionary Talesポッドキャストでも取り上げられていたが、Therac-25では利用者が継続的に正体不明のエラーを経験していたにもかかわらず、それが修正できる人にきちんと伝わっていなかった点が印象的だった。(ポッドキャストのリンク)
この意見には同意しない。長年、航空機部品の設計に携わってきたが、核心となる原則はただ一つ、単一障害で事故につながってはならないということだ。これを実現する方法は、「質の高いソフトウェアを書くこと」や「十分なテスト」ではなく、「ソフトウェアが最悪の動作をしてもそれを防げる独立したシステム」を置くことだ。Therac-25の場合、安全しきい値を超えたら自動遮断される放射線検知装置、そして物理的に過剰な放射線放出が不可能になるような設計が必要だった。
私もそのポッドキャストを勧めようとしていたところだった。特にソフトウェアバグに関心があるなら聴く価値がある。興味深い事実として、初期に手動で運用されていた機器にも同じ欠陥があったが、ヒューズが切れたことで欠陥が現実化しなかったという点がある。これはSwiss Cheese Modelの優れた例だと言える。(Swiss Cheese Model参考)
ほとんどのソフトウェアは生死に直結しないという点を強調したい。多くの場合、失敗してもページの表示が遅くなる、レポートがNaNだらけになる、バッチ処理を手動で開始しなければならない、といった程度だ。ソフトウェア品質の問題で人が実際に死亡するケースはまれであり、そうしたソフトウェアを作る開発者は自分の責任をよく理解しているはずだと思う。
私が働いていた会社は、最高品質を誇る写真機器および科学機器を作っていた。非常に高価だったが、顧客はその価値を認めていた。品質は単なるプロセスの結果ではなく、究極的には「文化」から生まれるものだと実感した。
多くの開発者は、高信頼システムを扱っていなければ品質問題は自分とは無関係だと考えるが、それはまったくの誤りだ。一見ささいに見えるソフトウェア障害でも、誰かの人生や会社に甚大な影響を及ぼしうる。たとえば重要なフローを止めたり、人生や医療記録のデータを壊したり、絶対に必要な商品の決済をできなくしたりする。
記事コメントのひとりは、80〜90年代当時、医療分野ではコンピュータは危険だという認識が強かったと述べていた。2000年代前半から半ばごろまでは、カルテを手で紙に書いていた。ICUの電子患者記録の実験プロジェクトに少し参加したとき、私はサーバー管理の役割をしていたが、医療スタッフは全員このシステムをひどく嫌っていた。当時はタブレットすらない時代で、コンピュータで記録を確認したり修正したりするのは不便だった。薬の処方はすべてベッド脇のチャートに直接書くのが普通で、即座に確認・修正できた。情報の損失やアクセス遅延は致命的になりうるので、医師たちは根拠なくコンピュータを嫌っていたのではなく、実際にペンと紙より危険だと感じていた。その後、状況は改善したのだろうと思うが、それでもなお留意すべき点だ。
今ではChipsoftのような会社が病院IT業界をほとんど独占している。非常に高い費用を取りながらソフトウェア品質はひどく、会社が大きくなるほど代替手段も減っていく。なぜこんな敵対的な業者を私たちが許しているのか理解できない。
今でも、電算システムのダウンによって医療スタッフがペンと紙に戻る事例がある。こうしたシステムに冗長性がないのが理解できない。しかもこれが今まさに商用製品だという事実に驚く。
アメリカとヨーロッパでは、EMR（電子カルテ）は医療機器に分類されていないため、多くの規制を免れている。関連記事リンク
英国郵便局スキャンダルと比べると興味深い。まったく別の事件だが、両者に共通しているのは「ソフトウェアは間違えない」という誤った前提だ。開発者からすればあまりに滑稽な考えだが、非専門家にはソフトウェアの脆さは理解しにくい。ソフトウェアに欠陥があるはずがないと決めつけ、テストすらろくにしない風潮があった。
実際には、開発者でさえソフトウェアを過信することが多い。自分が開発したあらゆるシステムは、いつでも崩壊しうると思っている。だから私は自動運転車には絶対に乗らない。HNユーザーは新技術のベータテスターになるのが本当に好きなようで不思議だ。もちろん自動運転車のほうが統計的には安全だと主張されるが、その理由のひとつは周囲のドライバーが慎重に運転してくれているからだ。しかも自動運転車は、人間による監督や直接介入の機能、あるいは厳格な基準が適用されない新しいシステムであり、その点が問題だと思う。
ほとんどの従来型の電気・機械式機械では、部品の摩耗が主要な故障原因だった。ソフトウェアは摩耗しないので、当然より信頼できるはずだと誤って信じるようになった経緯があるのだと思う。
郵便局スキャンダルは、はるかに悪質だったと思う。上級幹部たちは店舗主から取り立てた金額に応じてインセンティブを受け取り、裁判所や大臣に対してソフトウェアの信頼性について嘘もついていた。Therac-25はそれに比べれば、正直なミスに近い。
Therac-25のような事件が近いうちに起きそうな気がする。YOLOモードでAIエージェントをどんどん動かしている人が多すぎて、ClaudeやGeminiのようなモデルが実機ハードウェアに誤って接続されたら、いつか事故につながるのではないかと思う。エージェント型AIは組み込みシステムの分野ではまだ未熟で、放射線機器のような領域にAIを無責任に適用する状況を想像すると恐ろしい。
英国郵便局のHorizon事件では、複数の店舗主が自殺し、何十人もの人生が壊された。Therac-25事件を通じて、あらゆるソフトウェアが重要だという事実を学ぶべきだと思う。すべてのソフトウェアは誰かに害を与える危険を持つのだから、常に慎重であるべきだ。
非エージェント型AIも、すでに一部の定義では「人を殺している」。最近ではAIチャットボットが自殺につながった事例が話題になったし、今後、医療保険など重要な意思決定の領域にAIが使われれば、「AIのせいで死亡する」ケースはさらに増える可能性が高い。自動運転車など、すでに複数の分野でAIが人命事故を起こしている。Excelのエラーのような些細なバグが、何万、何十万人規模で社会に影響した例もある。しかしAIもまた、責任の所在が曖昧なため、Horizon事件のように責任回避できる余地が大きいだろう。AIコパイロット系ツールも、組み込み分野ではまだ不十分だと感じる。
737 MAXのMCAS問題はシステムレベルの失敗ではあるが、この種の大規模なソフトウェア品質問題の代表例だ。将来もこうした災厄は繰り返されると思う。
ボーイング737 MAX墜落事故も、品質の低いソフトウェアがおよそ350人の命を奪った代表的な事例だ。(MCAS情報リンク)
私が最新のAIエージェントで組み込み作業を試したとき、性能は期待以下だった。単純なCRUD Webアプリですら、データモデルが複雑になると、2〜3段階の変換だけでLLMが混乱する場面を何度も見た。たとえば入力では
created_at、保存時はcreated_on、外部システム送信時はlast_modifiedのようにフィールド名が異なると問題になる。Therac-25機で、VT100ターミナルから特定のキー入力を行うと一瞬で過剰被曝が発生しうるという逸話が印象的だった。熟練したユーザーなら8秒以内に素早くキー入力できるが、その場合入力が正常に反映されず、致命的事故につながりえた。こうした問題を見ると、いま産業用や車載インターフェースまでタッチスクリーン化している流れに不安を覚える。
UIではユーザー体験向上のために主にoptimistic updateという方式を使い、その結果、画面への反映は速いが実際の反映は後で同期する場合が多い。この方式がどこでは不要なのかを、きちんと認識してほしい。
iOS 11の電卓で、素早く「1+2+3」を入力すると正しく計算されない事例があった。(関連HN事例) 些細に見える電卓ですら、これと同じ失敗モードが存在する。
大学でこのようなTherac-25や安全・倫理の事例を学んだ経験があるか気になる。自分は一般工学の授業で、バスタブ曲線や冗長冷却ポンプの算定法などと一緒にこの事件を学んだが、今でもこうした内容がカリキュラムに含まれているのか知りたい。
パデュー大学の90年代初頭の機械インターフェースの授業では、「ヒステリシス」（遅れ応答）の概念が強調されていた。アナログシステムはコンピュータのように即座に停止せず、動作範囲内で多様な挙動を取りうるため、その点を必ず考慮しなければならなかった。
システムエンジニアリングの授業でこれに類するテーマを扱った。(MIT授業リンク)
大学レベル以上のコンピュータサイエンス課程でこうした事件を学んだ。その後メドテックで働く中でも、ずっと思い出されてきた。
工学倫理の授業で、実際にTacoma NarrowsとTherac-25だけを学んだ記憶がある。しかも1時間の講義で終わりだった。
気になって自分でアンケートを作ってみた。こうした授業の経験があるか知りたい。(アンケートリンク)
既存の機器にはハードウェアインターロックがあった。ソフトウェアに問題が起きても、単に不便になるだけで済んでいたが、ソフトウェアは安定しているという過信から、ハードウェアインターロックがコスト削減のために取り外され、ソフトウェアのみで監視するようになった。結局、些細な問題が致命的な惨事につながった。それぞれ異なる立場で不協和音が生じた典型例だ。
記事の最初のコメント投稿者は医師でありコンピュータサイエンス専攻者で、児童虐待予防に関する専門学会の会長でもある。(経歴リンク) しかし児童虐待の医療判定には、今なお誤ったデータや根拠、探索的な循環論法などによる欠陥が多い。客観的な真実を見つけるのは難しく、現場ではいくつかの所見だけで「疑いの余地のない児童虐待」とみなす傾向がある。最近では、こうした不完全なデータをもとに高精度検出をうたうブラックボックス型AIまで登場しているが、誤ったデータから正しい予測は得られない（garbage in, garbage out）。不正確なAI診断が、児童虐待の冤罪、家族の破壊、誤った処罰など深刻な結果を招くのではないかと懸念している。(関連参考資料, 臨床論文, AIとデータ問題, 研究リンク)
1993年の報告書には、安全クリティカルなソフトウェアエンジニアの資格の必要性が言及されている。数回のプログラミング教育を受けただけで安全クリティカルソフトウェア開発者を名乗ることはできず、今後Therac-25のような事件が繰り返されれば、関連認証が必須になるだろうと予測していた。英国ではすでに必須教育課程の設計が議論されていた。しかし32年が経った今、現実はその期待とは異なる。
カナダで登録済みのプロフェッショナル・ソフトウェアエンジニアとして15年間活動してきたが、実質的な利点を感じられなかったので、近く資格更新をやめる予定だ。ソフトウェア開発をもっと構造化された工学分野にしようという議論はあったが、今ではほとんど消えてしまったようだ。
安全クリティカルソフトウェアは教室で学ぶものではなく、長い実務経験と訓練の中で身につくものだ。航空（Do-178）や産業界（IEC 61508）のような標準はあっても、実際の適用レベルは予算とスケジュールによって変わる。しかし事故が起きれば、どれだけ監査結果が残っていても、被害者の立場からは無意味だ。すべての規制やルールは、結局は誰かが犠牲になった後に生まれる。
Therac-25のソフトウェアは、たった一人の開発者がすべてを書いており、1986年に彼が会社を去った後、その身元は明らかにされていない。多くの読者は「開発者がこの悲劇で大金を稼ぎ、豪華な引退生活を送った」と想像するかもしれないが、当時は今と違って開発者は低賃金で、あまり評価もされていなかった時代だ。80年代のテック企業で主役だったのは営業担当であり、Therac-25の販売手数料が開発者の年収を上回っていた可能性が高い。特にAECLの所在地、時代背景、政府系、組み込みソフトウェアという特性はすべて低賃金に結びつく。1986年当時でカナダドル3万〜5万程度であり、現在価値に換算しても米ドル7.8万〜12.9万の間で、ストックオプションもなかった。