ハクソク

世界を動かす技術を、日本語で。

セラック25事件 (2021)

271日前原文(thedailywtf.com)

概要

Therac-25事件は、 放射線治療機器 のソフトウェア不具合による 死傷事故 として有名。 1985年から1987年 にかけて合計6件の事故が発生し、 複数の死者・重傷者 を出した。 原因はソフトウェア設計・運用上の重大な問題 であり、業界全体に大きな教訓を与えた。 安全対策 や テスト体制の不備 が事故を招いた経緯が明らかになった。 本記事では、事件の詳細・背景・教訓を解説する。

Therac-25事件の詳細

  • Therac-25 はAtomic Energy Canada Limited（AECL）製の 放射線治療装置

  • 完全ソフトウェア制御 が特徴で、従来の ハードウェアインターロック を省略

  • 1985年6月～1987年7月 までに 6件の過剰被曝事故 発生

  • 患者への致死的な放射線照射 による死亡・重傷事故

  • 東テキサス癌センター（ETCC） でも1986年3月に重大事故発生

    • 技師が ビーム種別入力ミス →素早く訂正し治療開始
    • 「Malfunction 54」エラー 表示、手順通り再開→患者が激痛を訴え
    • 本来180ラッドの処方に対し 16,000～25,000ラッドの過剰照射
    • 初期診断は電気ショック、実際は 重度の放射線障害

  • 機械は「アンダードーズ」と誤表示 し、被害の発覚が遅延

  • AECL は当初「過剰照射は不可能」と回答、安全神話が崩壊

  • FDAやマスメディア が介入し、事件が社会問題化

技術的背景と根本原因

  • Therac-25 は PDP-11 上のアセンブリ言語で制御

  • 複数プロセス（ユーザー入力・ビーム制御・線量管理など） を一人の開発者が実装

  • ソフトウェアの再利用 （Therac-6, Therac-20から流用）に過度な信頼

  • AECL内部の安全評価 では「ソフトウェアに残存バグなし」と仮定

    • 「プログラムエラーはハードウェア起因のみ」と誤認
    • 「長年使っているから安全」との過信

  • ハードウェアインターロックの省略 による致命的設計ミス

  • ソフトウェアレースコンディション が主因

    • 入力ミス訂正時に 高速入力 で再計算が飛ばされ、誤ったビーム設定で過剰照射
    • タイミング依存の不具合 で、再現性が低く発見が困難

事故調査・対応と組織的問題

  • ETCC物理学者 が再現実験を行い、AECLに報告

  • AECLは当初「再現できない」と回答、 「It works on my machine」現象

  • FDAが是正措置計画（CAP） を要求、AECLはテスト計画の不備を指摘される

    • FDA「全ソフトウェア改修ごとに厳格なテストが必要」と要求
    • AECL側は「長年の運用実績」で済ませようとした

  • 暫定的な運用対策 は実施されたが、1987年1月に 別のソフトウェアバグ による事故再発

  • 複数プロセス間で共有する変数管理の不備 が新たなバグを生む

教訓と現代への影響

  • ソフトウェア安全性 の過信が大事故を招いた実例

  • ハードウェアインターロック など 物理的安全装置の重要性 を再認識

  • ソフトウェアテスト・検証プロセスの厳格化 が業界標準となる契機

  • 単独開発・属人化 によるリスクの顕在化

  • レースコンディション・並行処理バグ の危険性の啓蒙

    • 実運用速度でしか発生しない不具合の存在
    • 経験豊富なオペレータほどリスクが高まる逆説

  • 医療機器ソフトウェア規制 や 安全文化 の発展に大きな影響

ソフトウェア開発者へのメッセージ

  • Therac-25事件 は、 技術者倫理 ・ 安全設計 ・ テスト体制 の重要性を強く示す
  • 「長年使っているから安全」 という思い込みの危険性
  • 設計・実装・運用・検証 すべての段階で 多重防御と透明性 が不可欠
  • 過去の失敗例から学び、同じ過ちを繰り返さない 姿勢が求められる

Hackerたちの意見

ソフトウェアの品質は、優れた開発者がいるから生まれるわけじゃないよ。プロセスの結果なんだ。そのプロセスは、ソフトウェア開発のやり方だけじゃなく、テストや管理、さらには営業やサービスにも影響を与える。この記事から一つだけ覚えて帰るなら、これを覚えておいてほしい！テラク-25の事件は、ソフトウェアの歴史において恐ろしいけど重要な部分だ。型システムやユニットテスト、ディフェンシブコーディングがすべてのソフトウェアの問題を解決できると思いがちだけど、確かに役立つけど、テラク-25の話から私が理解しているのは、事件が報告され、調査され、修正されるまでに時間がかかりすぎたことが本当の失敗だと思う。最近、あのデバイスについての素晴らしい「Cautionary Tales」ポッドキャストがあったんだけど[0]、そこで言及されていたのは、壊滅的な事故とは別に、テラク-25の機械がユーザーによって説明のつかないエラーを頻繁に示していたことだけど、そういう問題は修正できる人のデスクに届くことはなかったってことだね。

└

それはその通りだけど、優れた開発者も必要だよ。素晴らしいプロセスだけじゃダメで、質の低い開発者のやり方ではいけない。必要なのは、1/ 高品質な個々のプロセス（開発もその一つ）、2/ 高品質なデリバリーメカニズム、3/ その質を向上させるためのフィードバックループ、4/ 質を検査して改善するためのバンド外メカニズムだね。

└

そのポッドキャストのエピソードを勧めようと思ってたけど、先に言われちゃったね。ソフトウェアのバグに興味があるなら、絶対聞く価値あるよ。ポッドキャストで言及されてた面白い事実の一つは、以前の（手動で操作する）バージョンにも同じ欠陥があったってこと。でも、故障を防ぐためのフェイルセーフヒューズがあったから、実際には問題にならなかったんだ。スイスチーズモデルの素晴らしいデモだね。 https://en.wikipedia.org/wiki/Swiss_cheese_model

└

なんでこの記事がソフトウェア開発にそんなに焦点を当てているのか分からない。それは問題の一部に過ぎない。製品全体に設計上の欠陥があったんだ。FDAが関与したとき、会社はただソフトウェアの更新をするように言われたわけじゃないよ。

└

正直なところ、Therac-25の代わりに、ユニットテストや防御的コーディングを使っているシステムについて議論していたらよかったのに、と思う。それでも失敗したなら、もっと教育的だっただろう。Therac-25を見て「こんなメチャクチャなコードは絶対に書かない」と思うのは簡単すぎるから。

└

一番ひどいのは、多くの開発者が高い信頼性のシステムを使わないことで、そういう品質レベルは自分たちには関係ないと思っていることだよ。間違ってる、ソフトウェアの失敗は誰かの人生や会社に大きな影響を与える可能性があるからね。重要なフローが止まったり、誰かの生活や職業、医療記録に関するデータが壊れたり、特定の商品の支払いができなくなったりすることがあるんだ。

└

私は、最高品質の写真機器や科学機器を製造している会社で働いていたんだ。めちゃくちゃ高かったけど、顧客はそれに見合う価値があると思っていたみたい。> 「それはプロセスの最終結果だ。」 私の経験では、それ以上のものだと思うよ。文化なんだ。

みんなが大学の倫理や安全性、信頼性の授業でこういうことを教わっているか知りたいな。私は工学部で、一般的な工学の授業の一環として教わったんだ。バスタブの信頼性曲線や、原子力発電所に必要な冗長冷却ポンプの数を計算する方法も含まれていた。でも、大学を卒業してからかなり時間が経ったから、今のエンジニアや開発者たちにもこういうことは教えられているのかな？

└

大学でコンピュータサイエンスの学部生として教わったことがあって、医療技術の仕事に就いたから、よく考えるようになったよ。

└

これは私たちのシステム工学の授業の一部だった。こんな感じのやつだよね。 https://web.mit.edu/6.033/2014/wwwdocs/assignments/therac25....

└

なんか気になっちゃって、アンケート作っちゃった。コンピュータサイエンスの大学には絶対行ってなかったし、ネットでなんとなく聞いたことがあるくらいだよ。 https://strawpoll.com/NMnQNX9aAg6

└

コンピュータサイエンスのプログラムで、1年生のソフトウェア倫理の授業で教わったよ。2010年の話だけど、今もやってるのかな。

└

デザインを勉強してたけど、こういう事例を扱うデザイン倫理の授業があったらよかったな。

近い将来、テラク-25に似た事件が起こると思う。YOLOモードで動かしているエージェントがたくさんいるから、クロードやジェミニが誰かを殺すことになるような本物のハードウェアに接続されることになるだろう。個人的には、最新のエージェントでも組み込みシステムにはあまり向いていないと感じているし、放射線治療機器にその鍵を渡すことを考えるとゾッとするよ。

└

737 MAXのMCAS問題は、その一例だね。広範なシステムの失敗が絡んでいて、単なるソフトウェアの問題じゃなかったけど。未来については同意だけど、結局そこに向かっていたと思う。

└

個人的には、最新のエージェントでも組み込みシステムにはあまり向いていないと感じている。例えば、データモデルがもっと複雑なシンプルなCRUDウェブアプリでも、同じデータに複数の構造があると、LLMは2回目のデータ変換の後に混乱しちゃうんだよね（多くても）。例えば、created_atというフィールドのデータを受け取って、created_onとして保存し、last_modifiedとして別のシステムに送信するみたいな感じ。

└

ホライゾン（UKのロイヤルメールの会計ソフト）事件は、複数の郵便局長が自殺する結果を招いて、さらに数十人、数百人の生活を破壊した。開発者がテラク25から学ぶべき核心的なことは、「本当に重要な」ソフトウェアだけでなく、すべてのソフトウェアが重要で、すべてのソフトウェアが人を殺す可能性があるということ。常に気を配る必要があるんだ。

└

医療や重要なインフラのデバイスについて「自動化」について話すと、みんなNOって言うよ。自分たちのデバイスに触れるなって。確信してるけど、決定論的な自動化すら動かさせないのに、クラウドに触らせるわけがない。とはいえ、場所によってはあるかもしれないけど、私が感じたのはいつもそうだった。自動化もスキャンもパッチもなし。デバイスは認証済みで、改造するとその認証が無効になる。変更はすべて検証されて認証される必要がある。アプリを作るのとは全然違う世界だよ。間違いが起こらないわけじゃないし、変化がないわけでもないけど、医療デバイスの設計をしている人たちがすぐに開発サイクルで「YOLOモード」になるとは思えない。安全クリティカルなシステムエンジニアリングの人たちにも少しは評価してあげてほしいな。

└

非エージェントAIは、定義によってはすでに人を「殺している」よ。一つの投稿では、誰かが自殺に追い込まれた話が今、トップページに載ってるし、健康保険や福利厚生に使われる可能性が高いから、避けられる死が起こるかもしれない。自動運転車も「AI」が満載で、すでに人を殺していることは間違いない。ソフトウェアが人を殺したことがないわけじゃないし（HorizonやBoeing、たぶん多くの産業事故や間接的なプロセス制御の失敗など）、厳しい財政政策がバグのあるExcelスプレッドシートに基づいているという疑いもある。ある国では10年間で約20万人の過剰死亡があったし（Covidを含まない10年間）、その中のほんの一部がソフトウェアのせいだとしたら、Theracの数が多いことになる。AIは、Horizonと同じように責任を逃れやすいと思う。十分に距離があって、因果関係があいまいだから、「まあ、バグだったけど、彼らが自殺したのはこっちのせいじゃない」と言えるんだ。AIのコパイロット的なものは、組み込みソフトウェアとうまくいかないことが多いと思う。人々が組み込みをYOLOするのは新しいことじゃないけど、状況が悪化するかもしれないね。

記事のコメント欄にこんなことを書いてる人がいたよ：> 80年代と90年代を通じて、医学の中ではコンピュータが危険だという感覚があった。だから、2002年から2006年にかけて研修医だったとき、私たちはまだすべてのオーダーやメモを紙に書いてたんだ。2000年代初頭にICUで電子患者記録の実験にちょっと関わったことがあるけど、私の仕事はその記録を処理するサーバーを見守ることだった。スタッフ全員がそのシステムを嫌ってた。記録を確認したり更新したりするのにコンピュータに切り替えるのが嫌だったんだ（これはiPadやそれに似たスリムなタブレットが出るずっと前の話）。彼らはベッドサイドチャートに薬の情報（何を、いつ、どの量で、など）を書くのに慣れていて、それがすごく簡単に参照できて更新も楽だった。記録のデータロスは致命的な結果を招く可能性があったし、情報にアクセスするのが遅れるのも良くなかった。これは医者たちが根拠のない「感情」でコンピュータが危険だと思っていたわけじゃない。コンピュータはペンと紙よりもずっと危険だったんだ。その業界にはそれ以来関わってないけど、今は改善されてると思う。でも、心に留めておく価値はあるよ。

└

今はチップソフトがあって、病院向けITでほぼ独占的な存在（私の周りではね）で、最悪のプレイヤーの一つだと思う。めちゃくちゃ高い料金を取って、クソみたいなソフトを作って、彼らが大きくなるほど、残りの選択肢が減っていくのが理解できない。

└

まだ問題があるよね。EMRシステムがダウンして、スタッフがペンと紙を使わざるを得なかったって話を聞いたことがある。そんなシステムに冗長性がないなんて、信じられないよ。商業用の製品なのに。

僕の「お気に入り」の部分: >「ある失敗は、PDP-11コンピュータを制御するVT100端末で特定のキー入力のシーケンスが入力されたときに発生しました。オペレーターが誤って25 MeVフォトンモードを選択するために「X」を押し、その後「カーソルアップ」を使って入力を「E」に編集して25 MeV電子モードを正しく選択し、「Enter」を押した場合、最初のキー入力から8秒以内、かつその機械の経験豊富なユーザーなら十分に可能な範囲内で、編集は処理されず、過剰投与が行われる可能性がありました。これらの編集はスタートアップに8秒かかるため気づかれず、デフォルト設定で進んでしまいました。最近は車のインターフェースから業界の重要なソフトウェアまで、すべてがタッチスクリーンになっているのを思い出させるね。」

└

それに、楽観的アップデートという概念があって、UIをレスポンシブに見せながら、バックグラウンドでアップデートを行い、後で調整するんだ。彼らがそれを使うべきでないタイミングを理解していることを願うよ。

これをイギリスの郵便局スキャンダルと比較するのは面白いね。全然違う事件だけど、これを読むと両方のケースに共通する根本的な仮定があると思う。「ソフトウェアは間違っていない」という考え方だ。開発者にとっては、これは本当に馬鹿げたことだけど、外から見ている非開発者には、ソフトウェアがこんなに脆弱であることを理解する能力や訓練がない。郵便局のスキャンダルのような状況を見て、「数百万かけて開発されたこのソフトウェアが間違っているか、これらの人たちが私たちを騙しているかのどちらかだ」と考えるんだ。同じことがTherac-25にも言える。このソフトウェアは以前のモデルで動いていたし、会社の他の人たちはそれに何も問題があるとは思っていなかったから、特にテストする必要がないと考えていたんだ。

└

いや、これは開発者にとって「馬鹿げたこと」じゃないよ。実際、ほとんどの開発者はソフトウェアに過剰な信頼を置いていると思う。僕も開発者だけど、触るソフトウェアはひどく壊れる。家族がATMを使いたいときは、僕から離れて立っててくれって言われるんだ。僕のオーラが壊すから。だから、近い将来、自動運転車には乗りたくない。これらの複雑なソフトウェアシステムに過信しすぎていると思う。でも、HNの読者の大多数は、このソフトウェアのベータテスターとして交通に参加することに喜んでいるし、その車に乗ることにも満足している。新しくて複雑で、理解が不十分でテストも不十分なソフトウェアシステムに命を預けることにOKだと思っている。周りのソフトウェアが壊れたり崩れたりしているのにね。 [即座に予想される一般的な反応: 1) 自動運転車の会社が自分たちの車が人間の運転手よりも統計的に安全だと主張しているのは知っているけど、ここではそれがポイントじゃない。まず、彼らは「安全」なのは、運転が下手すぎて他の道路利用者が特に注意を払ってその奇妙さに対応しているからで、次に、まだ新しくて複雑で理解が不十分なシステムだから。2) 「すでにソフトウェアシステムに命を預けている」 — これもポイントを外れているし、あまり正確ではない。多くのソフトウェアシステムは人間の監視やオーバーライド機能を持つように作られている（飛行機を考えてみて）、他のものは厳しい工学的要件に基づいて作られている（車のブレーキを考えてみて）けど、自動運転車はそういう風には作られていない。]

└

「両方のケースに共通する根本的な仮定があると思う。それは『ソフトウェアは間違っていない』ということだ。」この場合、考え方は古い電気機械式の機械の経験に基づいていると思う。最も一般的な故障は部品の劣化だったから。ソフトウェアは「劣化」しないから、誰かがそれが本質的により信頼性が高いと仮定したんだ。

TL;DR テラック25は1980年代にカナダ原子力公社が製造した放射線治療機器で、完全にソフトウェアに依存した安全制御を行っていたんだ。ハードウェアのインターロックはなかった。1985年から1987年の間に、少なくとも6人の患者がソフトウェアの欠陥によって致命的な放射線過剰投与を受けた。1986年3月にイーストテキサス癌センターで起きた大きな事件では、技術者が治療タイプを誤って入力し、すぐに修正してビームを開始したんだけど、レースコンディションのせいで修正が完全に反映されなかった。処方された180ラッドの代わりに、患者は最大25,000ラッドを受けた。機械は過少投与を報告したため、スタッフは後になってから被害に気づいた。他の病院でも似たような事件が報告されたけど、AECLは過剰投与が可能だとは認めなかった。彼らの安全分析はソフトウェアが失敗することはないと仮定していたんだ。FDAが調査したとき、AECLは適切なテスト計画を提示できず、「上矢印」キーを無効にするような粗雑な修正を出した。根本的な問題は単一のバグではなく、安全クリティカルなソフトウェアのための厳格なプロセスが欠けていたことだった。AECLは一人の開発者が書いた古いコードに依存していて、適切なテスト手法を構築していなかった。結局、このスキャンダルは規制当局に基準を厳しくするよう促した。テラック25は、悪いソフトウェアプロセスと組織の盲点がどれだけ危険かを示すケーススタディとして残っていて、ボーイング737 MAXのような失敗が何十年も後にその警告を再確認させているんだ。

└

コンピュータサイエンスの教授がこのことについて話していたのを覚えてる。ソフトウェアの安全性がどれほど重要かっていうことだね。彼が挙げた別の例は、原子力発電所の給油機で、ソフトウェアのバグでレールから外れて、反応炉を通るパイプを壊したことだった。それに、彼のペースメーカーのソフトウェアについても言及していた。別の分野のエンジニアは設計にサインをしなければならず、何かがうまくいかなかった場合には責任を問われることもある。ソフトウェアはまだそこまで追いついていないんだ。

記事にリンクされている1993年の報告書には、「教訓」としてソフトウェア開発者の認証に関する興味深い記述があるよ。> 「プログラミングのコースをいくつか受けたり、家庭用コンピュータをプログラムしたりするだけでは、安全クリティカルなソフトウェアを作る資格はない。」ソフトウェアエンジニアの認証はまだ必須ではないけど、テラック25に関連するような事件が増えれば、認証は避けられなくなるだろうね。イギリスでは、クリティカルなソフトウェアに関わる人たちのための必要なコースを指定する動きがあるんだ。エンジニアは自動的にソフトウェアエンジニアとして資格があるわけじゃなくて、広範な学習プログラムと経験が必要なんだ。安全クリティカルなソフトウェアエンジニアリングには、非クリティカルなソフトウェアに必要なものに加えて、トレーニングと経験が求められる。32年経っても、報告書の著者たちが期待した通りには進まなかったね。

└

追加すると、安全クリティカルなソフトウェアは教室で学ぶものじゃなくて、何年もかけて鍛錬されたものなんだ。航空機用のDO-178や産業システム用のIEC 61508のような基準はあるけど、それがどれだけ厳格に適用されるかは、コストやプロジェクトの制約に依存することが多いんだ。とはいえ、失敗が起きたとき、監査の履歴なんて被害を受けた人には関係ないよ。安全工学の歴史を見れば、ほとんどのルールは誰かがまず傷ついたから存在するんだ。

AECLが自社のデバイスのテスト方法を説明できないままでいる。 できないんだ。開発者は一人だけで、その人は去ってしまったし、テストも存在しなかった。誰もその混乱を理解していなくて、自信を持って変更を加えることができなかった。今の時点では、規制当局を欺くか、製品を完全に廃棄するかのどちらかだよ。こういう開発者や会社が、テラック事件のような規制のある業界でソフトウェアを運用しているのを見てきたけど、今は2025年だよ。私は、これは犯罪に繋がると理解して辞めたんだ。

彼の非公式な調査結果にはちょっとショックを受けたよ。大学の倫理の授業でこれが大きなテーマだったからね。多くの開発者はコンピュータサイエンスの学位を持ってなかったり、学位プログラムに倫理の授業が含まれてなかったのかな。