【連載】医療機器のQAは、なぜこんなに“面倒”なのか？ ——規制は「お作法」ではなく、過去の犠牲から生まれた知恵である（第1回）

実例を通して考察していきましょう。1985年から1987年にかけて、北米でひとつの医療機器が6人の患者に重大な被害をもたらしました。放射線治療装置「Therac-25」です。

Therac-25は、カナダの原子力公社AECLが開発した放射線治療装置で、PDP-11コンピューターによるソフトウェア制御を採用していました。エックス線と電子線を切り替えて照射できる高機能な装置でしたが、その安全管理をハードウェアのインターロックではなく、ほぼソフトウェアだけに依存していました。これが後に命取りになります。

「Therac-25」（2026年6月3日 08:30JST）『 Wikipedia』。
https://en.wikipedia.org/wiki/Therac-25

事故の原因は複数ありましたが、ひとつはソフトウェアの並行処理において競合状態が発生したことによるバグでした。100ミリ秒ごとにインクリメントされる内部カウンターが25.6秒に一度ゼロになる瞬間に、熟練したオペレーターが素早くキー操作を行うと、安全確認処理がスキップされてしまうものでした。ターゲットが正しく位置に収まる前に高エネルギーの電子線が直接患者の体に照射され、通常の100倍を超える放射線量が降り注ぎ被ばくしました。6件の事故のうち少なくとも3名が死亡し、生存した患者も深刻な放射線障害を負いました。

そして重要なのは、このソフトウェアは「テストを通っていた」という事実です。開発チームはテストを実施し、動作を確認していました。しかし、特定の操作手順とタイミングが重なったときにだけ顕在化するバグを、そのテストでは発見できなかったのです。

テストが通っていることと、患者が安全であることは、同じではない。

この教訓が、現代の医療機器ソフトウェア規制の出発点のひとつになっています。

Therac-25の事故について詳しく知りたい方は、筆者の解説動画をご覧ください：
https://youtu.be/VWi-FsDC9TQ

Therac-25の事故が示すのは、テストの限界だけではありません。「変更管理の失敗」もまた、この事故を深刻化させた重要な要因です。

最初の事故報告を受けたAECLは、問題を十分に調査することなく部分的な修正を加えました。ところがその修正が、根本原因を解消するどころか、別の問題を引き起こしたり、バグの存在をさらに見えにくくする結果になりました。また、Therac-25のソフトウェアはそもそも前モデル（Therac-6・Therac-20）からの流用でしたが、ハードウェアの安全インターロックを省略するという設計変更が行われたにもかかわらず、その変更がソフトウェアの安全性に与える影響が十分に分析・評価されていませんでした。

問題の連鎖を整理すると、こうなります。「変更によって影響を受ける範囲を正しく特定しない」→「変更後の再テストが不十分」→「修正がさらなる問題を生む」。この問題パターンは、現代の医療機器開発でも繰り返されています。

FDAのリコールデータベースを分析した結果によれば、ソフトウェア起因リコールの約15%が変更管理の失敗に起因し、設計変更時の不具合混入（約10%）を合算すると、全ソフトウェアリコールの約4分の1が変更に関わる問題から発生しています。変更は、新規開発と同じくらい慎重に扱われなければならないのです。

IEC 62304がソフトウェア保守プロセス（§6）と構成管理（§8）として変更管理を厳格に要求しているのは、Therac-25のような失敗の再発を防ぐためです。「変更要求の影響分析」「変更後の回帰テスト戦略」「リリースバージョンの管理」——これらは形式的な手続きではなく、変更が新たな危害を生み出さないことを確認するための仕組みなのです。

医療機器のQAに関わっていると、規制当局の要求が「厳しすぎる」「形式的すぎる」と感じる場面があります。しかし規制当局の本質的な役割を理解すると、その見方が変わります。

日本では厚生労働省（厚労省）が薬機法に基づく医療機器の規制当局であり、独立行政法人医薬品医療機器総合機構（PMDA)はその審査業務を受託する機関です。米国のFDAと同様に、これらの仕組みはその国の国民の命と安全を守るために存在しています。FDAは特にその意思が明確で、「米国の国民に危害をもたらす可能性」をできる限り排除しようという強い姿勢が、規制の厳しさに現れています。FDAのClass Iリコール（重篤なリスクを伴う最高水準の分類）が2024年に15年間で最高水準に達したことは、この問いが今も現在進行形であることを示しています。

医療機器規制の中核にある概念が「基本安全（Basic Safety）」と「基本性能（Essential Performance）」です。基本安全とは、機器が患者や使用者に直接危害を与えないことです。基本性能とは、その機器が治療・診断・予防という意図する目的を果たすために欠かせない動作が、正しく行われることです。

医療機器は、患者の命や健康に直接関わる道具です。人工呼吸器が誤作動すれば患者は呼吸できなくなり、放射線治療装置が誤動作すれば致死的な線量が照射され被ばくする。その機器が意図通りに動かないことは、患者危害に直結します。規制当局が求める文書や手続きは、その機器が「意図通りに動くことを、どのように確認したか（＝バリデーション）」を示すための証拠です。

FDAのリコールデータが示すもうひとつの重要な事実があります。ソフトウェア起因リコールの約55%は「ソフトウェア設計」に分類されますが、その主因はコーディングのバグではありません。IEC 62304が要求する上流工程——ソフトウェア要求事項分析（§5.2）、アーキテクチャ設計（§5.3）、そしてISO 14971に基づくハザード分析との連携——の不備が根本原因とされています。

言い換えると、テスト工程に入った時点ですでに問題は「設計に埋め込まれて」いるのです。テストはその設計の問題を発見することができません。テストは「設計通りに動くか」を確認する手段ですが、「その設計が患者の安全を守るために正しいか」を検証するものではないからです。

「そのテストは、何を保証しているのか？」 「テストしていない状況で、患者に何が起きるか？」

テストは品質保証の重要な一部ですが、テストを通過させることが品質保証の目的ではありません。目的は、その機器が意図通りに動き、患者に危害をもたらさないことを確認することです。テストはそのための手段の一つにすぎません。

Therac-25の事故が明らかにした問いに向き合うことで、IEC 62304やISO 14971といった国際規格が生まれました。規格が要求するソフトウェアのリスク分析、トレーサビリティ、変更管理——これらは全て、Therac-25のような事故を二度と起こさないための仕組みです。

IEC 62304がSOUP（既製品ソフトウェアコンポーネント）の管理を要求し、変更後の影響範囲の再評価を求めるのは、Therac-25で起きた「前バージョンからの安易な流用」と「変更が生んだ新たなバグ」への直接の応答です。規格の条項を読んで「なぜこんなことが必要なのか」と思ったとき、その背景には必ず実際の事故や失敗の歴史があります。

規格は「守らなければならないルール」ではなく、「過去の犠牲から学んだ知恵」の集積です。そしてソフトウェア工学の知見も積極的に取り込みながら、進化し続けています。QAエンジニアも開発エンジニアも、そのことを理解した上で仕事に臨んでほしいと思っています。

ドキュメントを書くとき、規制要求を満たすために書くのか、それとも「なぜこの設計が患者の安全を守ると言えるのか」を記録するために書くのか。この違いは、最終的には患者の安全に直結します。

医療機器QAが「面倒」に見える理由は、要求が高いからです。そしてその要求の高さには、理由があります。

Therac-25の6人の患者。安易なソフトウェア変更が生んだ負の連鎖。「テストが通っていた」にもかかわらず起きた痛ましい死。そこから生まれた規格が、今日の医療機器開発者に多くの作業を課しています。それは形式ではなく、過去の犠牲が私たちに残した問いへの答えです。

「何のためにこのドキュメントを書いているのか」。その問いの答えは、規制要求でも審査の通過でもありません。この機器を使う患者が、意図通りの診断や治療を受けられるようにするためです。

この連載を通じて、医療機器QAの「面倒さ」の正体と、その背景にある思想を一緒に解きほぐしていければと思います。

次回予告

第2回は「テストしても品質は保証できない」をテーマに、QAが最初に直面する誤解を掘り下げます。「テスト」と「品質保証」はどう違うのか、医療機器規制が求める証明の構造に迫ります。

【参考サイト】

ポータルサイト：https://www.medicalsoftwareconsulting.com/
規格解説動画：https://www.youtube.com/@MedicalSoftwareConsulting
医療機器ソフトウェア 規制・規格 知識データベース：https://watch.medicalsoftwareconsulting.com/