1980年代、医療の現場に登場した最先端の放射線治療器『Therac-25（セラック25）』。がん治療の希望となるはずだったこの機器は、後に一部で「殺人バグ」と呼ばれるソフトウェアの欠陥によって、複数の患者に致死量を超える放射線を浴びせるという悲惨な事故を引き起こしてしまいました。事故の原因はソフトウェアの想定外の動作でした。この事件は、単なるプログラミングミスに留まらず、ハードウェアの安全装置をソフトウェアで代替することのリスクとテストの重みを、エンジニアに伝える事例となりました。今回は、Therac-25事件を振り返り、その教訓を探ります。
- もくじ
1. 医療機器Therac-25で「殺人バグ」？
1-1. 安全な放射線治療器が凶器に
『Therac-25（セラック25）』は、カナダ原子力公社（AECL）とフランスの企業が共同で開発し、1982年頃に市場に投入された、コンピュータ制御の放射線治療器です。がん治療に使われる最先端の医療機器でした。
特徴は、当時、最先端だったコンピュータ制御を全面的に採用した点にあります。先行するモデル『Therac-6』や『Therac-20』の後継機として、コンパクトな設計でありながら、強力なX線（身体の深部にある腫瘍用）と電子線（身体の表面に近い腫瘍用）の両方を、1台の機器で生成できることが強みでした。医師や技師は、この機器を使うことで、より柔軟で精密な治療が可能になることを期待していました。
しかし、その高度な機能の陰には、致命的な欠陥が潜んでいました。1985年から1987年にかけて、アメリカとカナダの医療機関で、Therac-25による治療を受けた患者が、異常な痛みや火傷を訴える事故が相次いで報告されたのです。患者らが受けたのは、治療に必要な線量を遥かに超える、通常の100倍から数百倍もの放射線でした。調査の結果、少なくとも6件の重大な過剰被ばく事故が発生し、その結果、少なくとも5人もの患者が命を落とすという、医療機器としては決してあってはならない最悪の事態となってしまいました。
1-2. 被ばく事故の原因
なぜ、人命を救うはずの医療機器が、患者の命を奪う凶器に変わってしまったのでしょうか。その核心は、「殺人バグ」と称されたソフトウェアの欠陥にありました。
事故調査が進むにつれ、その原因はTherac-25の制御ソフトウェアに潜む、特定の条件下でだけ発生するバグにあることが突き止められました。このバグは「レースコンディション（競合状態）」と呼ばれる種類の問題です。少し難しく聞こえるかもしれませんが、これは複数の処理が「よーいドン」で同時に動いたとき、処理の実行される順序やタイミングのわずかなズレによって、予期しない、あるいは間違った結果が生じてしまう不具合のことです。
Therac-25のケースでは、オペレーター（放射線技師）が放射線のモードやエネルギーレベルを設定する際、非常に素早くキーボード操作を行った場合に、このレースコンディションが発生していました。
Therac-25には、X線を照射する高エネルギーモードと、電子線を照射する低エネルギーモードがありました。X線モードでは、まず高エネルギーの電子線ビームを生成し、それを金属製ターゲットと呼ばれる部品にぶつけることでX線に変換し、患者に照射します。一方、電子線モードでは、このターゲットは使われず、電子線ビームのエネルギーを下げて、そのまま患者に照射します。
金属製ターゲットを正しい位置に動かしたり、電子線のエネルギーを調整したりする作業は、すべてソフトウェアが制御していました。
事故を引き起こしたバグは、オペレーターが設定値を入力し、それを修正するためにカーソルキーで画面を移動させ、再び設定を確定する一連の操作を、わずか数秒という短時間で行ったときに発生したとされています。皮肉なことに、機器の扱いに慣れた熟練のオペレーターが、治療を効率よく進めようとして行った、素早い操作によって発生していました。
想定外の速さの入力にソフトウェアが追随できなくなった結果、システムは高エネルギーの電子線ビームを発射する準備を進めているにもかかわらず、X線に変換するために不可欠な金属製ターゲットが所定の位置にない致命的な状態に陥っていました。
結果、変換されるはずだった高エネルギーの電子線ビームが、そのまま直接患者の身体に照射されてしまったのです。これが、通常の治療線量の数百倍もの過剰被ばくをもたらした直接の原因でした。
1-3. 事件の社会的・法律的な反響
一連の事故は、医療現場はもちろん、社会全体に大きな衝撃を与えました。がん治療のために病院を訪れた患者が、信頼していた最先端の医療機器によって深刻なダメージを受け、命まで奪われたのですから、当然のことです。一部で「殺人バグ」といわれてしまうのも仕方ない面があります。
被害を受けた患者やその遺族は、製造元であるAECL社に対して、損害賠償を求める訴訟を起こしました。これらの訴訟の多くは、法廷外での和解（示談）によって決着したと報告されています。しかし、この事件が社会に与えた影響は、個別の訴訟問題だけに留まりませんでした。
事故の報告を受け、アメリカ食品医薬品局（FDA）をはじめとする各国の規制当局は、このTherac-25を「欠陥製品」であると宣言しました。そして、製造元であるAECL社に対し、すべての購入者への通知、問題の徹底調査、そしてFDAの承認を得るための是正措置計画の提出を命じました。
この事件をきっかけに、当局は医療機器、とくにソフトウェアによって制御される機器の安全性に対する審査基準を、根本から見直すことになりました。それまでは、どちらかというと機械としてのハードウェアの安全性が議論の中心でしたが、この事件によって、ソフトウェアの品質保証とテストという概念が、人命に直結する重い現実として、規制当局や開発者に突きつけられることになったのです。
Therac-25事件は、ソフトウェア工学の世界、とくに人命に関わる「セーフティクリティカル（安全第一）」なシステムの開発とテストにおいて、世界で最もよく知られた失敗事例（ケーススタディ）の一つとなりました。
2. Therac-25の欠陥とはソフトウェアが招いたインシデントの全貌
2-1. 『Therac-25』とは？
Therac-25がなぜこれほど深刻な事故を引き起こしたのか、その根本的な原因を探るには、先行機との設計思想の違いにまで遡る必要があります。
Therac-25の前身であるTherac-6やTherac-20といったモデルは、当時としては標準的でしたが、非常に堅牢な安全設計がなされていました。それはハードウェア・インターロックと呼ばれる、物理的な、言い換えると機械的な安全装置がありました。
これは、例えば「X線用の金属製ターゲットが所定の位置にセットされていなければ、高エネルギーの電子線を発射するための回路自体を、物理的に遮断する」といった、機械的な仕組みによる安全機能でした。仮にソフトウェアが「照射しろ」という誤った命令を出したとしても、このハードウェアの安全装置が「最後の砦」として働き、危険な状態になることを物理的に防いでいたのです。これらの先行機は、このハードウェアの安全装置のおかげで、優れた安全記録を持っていました。
しかし、Therac-25の開発にあたり、AECL社は大きな、そして結果として致命的となる設計変更を行いました。それは、これらのコストのかかるハードウェア・インターロックを撤廃し、安全確認の機能のほぼすべてをソフトウェアによるチェックに置き換える、という判断でした。
なぜ、彼らはそのような判断を下したのでしょうか。背景には、当時の技術的な風潮であったソフトウェアへの過信があったと指摘されています。コンピュータによる制御は柔軟性が高く、信頼性も高い、あるいはハードウェアと同等以上にできるという考えです。ハードウェアの安全装置は、もはや冗長であり、洗練されたソフトウェア制御に取って代わられるべき古い仕組みだと考えられたのかもしれません。
また、ハードウェア部品を削減すれば、機器本体の製造コストを下げることができ、同時に構造をシンプルにしてメンテナンスもしやすくなる、という商業的なメリットも大きかったと考えられます。
さらに問題を深刻にしたのは、Therac-25のソフトウェアがゼロから新しく開発されたものではなく、先行機であるTherac-20などのコードが流用されていた点です。驚くべきことに、後に事故の原因となったレースコンディションのバグは、実は先行機であるTherac-20のソフトウェアにも既に存在していたといわれています。
しかし、Therac-20には、先ほど述べたハードウェア・インターロックがありました。そのため、たとえソフトウェアがバグによって誤った命令を出しそうになっても、ハードウェアがそれを物理的に防いでいたため、事故には至っていなかったのです。よって不具合は表面化せず、誰もその存在に気づいていなかったのです。
つまり、開発者たちは「ハードウェアの安全装置によって守られていたから、たまたま問題を起こさなかったバグ」が潜んだコードを、安全装置のない新しい機器（Therac-25）にそのまま移植してしまっていたことになります。結果として、これは極めて危険な判断だったことになります。
2-2. 1/60秒の油断
事故の直接的な引き金となったレースコンディションは、なぜ、そしてどのようにして発生したのでしょうか。それは、ソフトウェアが設計されたときの「想定」と、実際のオペレーターの「操作」との間にあった、わずかな時間のズレに起因します。
Therac-25の制御ソフトウェアは、複数のタスク（処理）が同時に動くマルチタスク方式で書かれていました。例えば、「オペレーターからのキー入力を受け付けるタスク」「放射線の設定値をチェックするタスク」「照射の準備をするタスク」などが、目まぐるしく切り替わりながら並行して動いていたのです。
問題となったのは、オペレーターが入力した設定値を内部的にチェックし、機器の各部（電子銃や金属製ターゲットなど）を設定するプロセスでした。通常、オペレーターが設定をゆっくり入力し、「Enter」キーを押せば、ソフトウェアは順番通りに値をチェックし、安全を確認してから次のステップに進みます。
しかし、事故を起こした熟練のオペレーターは、例えば「X」キーでX線モードを選択した後、すぐにカーソルキーで別の項目に移動し、わずか数秒のうちに設定を確定して照射準備に入ろうとしました。この高速な入力の連鎖によって、ソフトウェア内部で混乱が生じたのです。
この結果、ソフトウェアは設定値の変更できないまま、次の処理に進んでしまうケースがありました。さらに、設計上の別のミスも重なり、X線モードに必要な準備がされていないにもかかわらず、「準備完了」と判断し、高エネルギーの電子線を照射してしまったのです。
このバグは、タスクが切り替わるタイミング、それこそ1/60秒といったごくわずかな時間のズレによって発生したり、しなかったりしました。そのため、再現性が非常に低く、やっかいな問題だったといわれています。
事故後、病院の物理学者が技師と協力して原因を突き止めようとした際も、マニュアル通りにデータをゆっくり入力しても、何も問題は発生しませんでした。バグは、高速入力という特定の条件下でしか姿を現さなかったのです。
2-3. なぜテストで発見できなかったのか？
これほど致命的な欠陥が、なぜ製品が出荷される前、あるいは最初の事故が報告された段階で発見できなかったのでしょうか。この問いこそが、ソフトウェア開発に携わるエンジニアが学ぶべき教訓を含んでいます。
調査報告書や専門家の分析によれば、Therac-25の失敗の根本原因は、単なる一つのコーディングミスではなく、ソフトウェアの設計と開発プロセス、そして品質保証に対する組織全体の文化にあったとされています。
第一に、根本的な危険性分析の不備があげられます。1983年に行われた危険性分析は、驚くべきことにソフトウェアのバグの存在を仮定しない前提で進められていました。ソフトウェアは常に正しく動作するものとされ、リスクはハードウェアの故障やオペレーターのミスにのみある、と想定されていたのです。ハードウェアの安全装置を撤廃し、その代わりをソフトウェアに任せたにもかかわらず、そのソフトウェア自体の欠陥を考慮しないという見落としがありました。ある意味、致命的といってもよい気がします。
第二に、テストの設計と思想が決定的に不十分でした。AECL社は、ソフトウェアの個々の部品（モジュール）をテストする単体テストは行っていたと主張しています。しかし、それらの部品をすべて結合し、実際の治療器本体と組み合わせてシステム全体として動かす「結合テスト」や「システムテスト」が、極めて不十分だったと指摘されています。
とくに、先ほどから触れている「熟練オペレーターによる高速なキー入力」といった、実際の使用状況（ユースケース）を想定したテストや、想定外の操作を試す異常系テストは行われていませんでした。通常のテスト計画では、高速な連続操作によるレースコンディションの検出は困難だったと報告されています。開発時のテストでは、おそらくオペレーターはもっとゆっくり、一つ一つの設定を確認しながら操作していたのでしょう。
第三に、組織の過信と対応の遅れです。最初の事故が報告され、現場のオペレーターや物理学者が異常を報告しても、AECL社はすぐにはソフトウェアの欠陥を認めませんでした。AECLは原因を機器の設置ミスやオペレーターの操作ミスにあると考えていたようです。
装置の画面に不可解なエラーメッセージが表示されても、それは一時的なもの、あるいはオペレーターが操作を続行しても問題ないものとして扱われました。「問題ないはず」という過信こそが、テスト部門のチェックを形骸化させ、被害を拡大させた最大の要因の一つとなっていたのかもしれません。
3. 事件の教訓を今に活かす
3-1. 「正常」だけでは不十分
Therac-25の悲劇から私たちがまず学ぶべき教訓は、正常系テストだけでは全く不十分であるという、当たり前でありながら見過ごされがちな事実です。
開発者が想定する「正しい使い方」でシステムが動くことを確認するのは、テストの第一歩に過ぎません。Therac-25の事故は、システムが「正常に動いているように見える」裏で、いかに致命的なリスクが潜んでいるかを示しました。
重要なのは、システムの「想定の範囲外」を突くテスト、すなわち「エッジケース」と「異常系テスト」です。エッジケースとは、システムの限界値（例えば、最大同時接続数、最速の入力速度、最小のメモリ容量など）を試すテストのことです。Therac-25でいえば、「オペレーターが理論上可能な最速のスピードでキー入力を行う」ことが、まさにこのエッジケースでした。
異常系テストとは、システムが予期しない入力や状況に直面したときに、いかに安全に停止するか（あるいは復旧するか）を試すテストです。例えば、ネットワークが瞬断した場合、ユーザーが意図的に無効なデータを入力した場合、あるいはTherac-25のように、ありえないはずの内部状態（ターゲットがないのに高エネルギーモード）になりかけた場合などです。
「さっと使ってみて問題ない」では、決して済まされません。とくに人命や社会インフラに関わるシステムにおいて、テストエンジニアは「いかにしてこのシステムを壊すか」「設計者が思いもよらない使い方は何か」を常に考える、いわば「良識ある破壊者」としての視点を持つ必要があります。
3-2. 「ヒューマンファクター」を考慮
Therac-25の事故を引き起こした「熟練者の高速操作」は、果たして異常な（想定外の）使われ方だったのか？ という議論も残ります。システムを使う人間の特性、すなわちヒューマンファクターを開発者が見落としていたという指摘もあります。
人間は、作業に習熟すればするほど、より効率的に、より速く操作しようとします。これは人間のごく自然な行動特性です。毎日同じ機器を操作するオペレーターが、まどろっこしい入力を省略し、ショートカットや最速の手順を見つけ出すのは当然のことです。
システムを設計する際、「ユーザーは常に合理的で、ゆっくりと、指示通りに操作する」という暗黙の前提に立ってしまいがちです。しかし、現実は異なります。ユーザーは疲れ、焦り、苛立ち、そしてときに効率化のために開発者の想定を超えた操作を試みるのですソフトウェアテストにおいては、この「ヒューマンファクター」を常に考慮に入れる必要があります。
「ボタンがずっと連打されたらどうなるか？」
「入力欄に、マニュアルとは違う形式で文字列を入れたらどうなる？」
「複数の操作を同時に行ったらどうなるか？」
これらは「意地悪なテスト」ではなく、実際の人間がとる可能性のある行動をシミュレートする、極めて重要なテストといってよいでしょう。
3-3. フェイルセーフとフールプルーフ
Therac-25の設計は、フェイルセーフとフールプルーフという、安全設計の基本原則が欠落していたと考えられる点でも教訓を残しました。
フェイルセーフ（Fail-safe）とは、システムに何らかの故障やエラー（Fail）が発生したときに、必ず安全（Safe）な側に倒れる（動作する）ように設計するという思想です。例えば、踏切は、停電したり制御装置が故障したりした場合、遮断桿が「上がる（危険）」のではなく、必ず「下がる（安全）」ように設計することが挙げられます。
Therac-25において、フェイルセーフが徹底されていれば、ソフトウェアが内部的に矛盾した状態（レースコンディション）を検出した瞬間、あるいはハードウェアの状態とソフトウェアの命令が一致しない場合に、動作を停止してオペレーターに明確な警告を発するべきでした
フールプルーフ（Fool-proof）とは、使う人（Fool）が誤った操作をしても、それが危険な結果につながらないように、あらかじめシステム側で防ぐ（Proof）という設計思想です。例えば、電子レンジは、ドアが開いている状態では絶対にマイクロ波が出ないように設計されています。
Therac-25でいえば、オペレーターがいかに高速な入力を行っても、システムがレースコンディションのような危険な状態に陥らないように対策しておくべきでした。一例をあげれば、高速すぎる入力自体を受け付けないような設計も可能だったかもしれません。
想定外の使われ方や故障は「起こりうるもの」として、それが最悪の事態につながらないように、多重の防御（フェイルセーフとフールプルーフ）を組み込むこと。これは、Therac-25が残した重い教訓だと思います。
3-4. 悲劇を繰り返さないために
Therac-25事件は、単なる一企業の失敗談ではなく、ソフトウェア開発に関わるすべてのエンジニア、マネージャー、そして組織全体が共有すべき普遍的な教訓を含んでいます。エンジニアとして目を向けておきたいのはテスト文化の醸成です。
第一は「品質はテスト部門だけのものではない」という認識です。品質は、設計の段階からコードの一行一行にまで組み込まれるべきものであり、開発プロセス全体に関わる全員の責任です。
第二に「バグ報告は宝である」という姿勢です。健全なテスト文化を持つ組織は、バグ報告を「非難」ではなく「改善の機会」として歓迎します。
第三は「独立した品質保証（QA）」の力です。テスト部門やQA部門が、開発スケジュールやコストの圧力から独立し、「NO（出荷できない）」といえる強い権限を持つことが不可欠です。
現代において、私たちはAI、IoT、自動運転など、Therac-25の時代よりも遥かに複雑で、社会に大きな影響を与えるソフトウェアを開発しています。システムが複雑になればなるほど、私たちが「想定」できる範囲は狭くなります。だからこそ、「ソフトウェアは間違える」「人の操作は想定を超える」「組織は過信する」という教訓を謙虚に受け止め、それを前提とした堅牢なテストプロセスと、テスト文化を築き上げることこそが大切です。
4. まとめ
1980年代に発生したTherac-25の過剰被ばく事故は、ソフトウェアのバグがハードウェア安全装置の撤廃と組み合わさって引き起こされた最悪の悲劇の一つです。この事件は、技術的な教訓以上に、バグ報告を軽視する組織の過信や、形骸化したテストプロセスといった文化の欠如が、いかに致命的な結果を招くかを浮き彫りにしました。悲劇を繰り返さないためにも、エンジニアは、謙虚に想定外を追求するテスト文化を守ることが大切だと感じさせられます。
