医療機器ソフトウェアを「安全に育て続ける」ための考え方

なぜ医療機器ソフトウェアに専用の規格が必要なのか

医療機器ソフトウェアの不具合は、常に同じ形で現れるとは限りません。特定のデータの組合せ、通信状態、機器の設定又は操作の順序が重なったときにだけ発生する場合があります。画面や装置が正常に動作しているように見えても、内部では古い情報や別の患者に関する情報を参照している可能性があります。

完成した製品に対する試験で確認できる条件には限りがあります。想定していなかった使用状況、外部機器との組合せ、通信の途絶や復旧、データ更新のタイミングまでを、出荷前の試験だけで網羅することは困難です。試験に合格したという結果だけでは、確認していない条件に安全上の問題が残っていないことまで説明できません。

さらに、医療機器ソフトウェアは市場投入後も変化します。OS、外部サービス、脆弱性情報及び使用環境の変化に対応するため、修正や更新が行われます。一つの変更が別の機能やリスクコントロールへ影響し、新たな危険を生じさせる可能性もあります。安全性の説明は、出荷時の一度だけで完了するものではありません。

このため、医療機器ソフトウェアでは、完成品が動作したという結果に加えて、どのような危険を想定し、どの要求と設計で対処し、どの試験で確認したのかを継続的に説明できる仕組みが必要になります。要求、リスクコントロール、設計、実装、試験、構成及び変更の関係を記録し、市場投入後も更新することが、その仕組みの中心です。

IEC 62304／JIS T 2304は、この管理を開発者個人の経験だけに委ねず、組織のプロセスとして実施するための枠組みです。特定の設計手法やテスト技法を指定するのではなく、必要な活動、責任、判断基準及び記録を開発から保守まで一貫して管理します。医療機器ソフトウェアに専用の規格が設けられている理由は、このライフサイクル全体の説明責任にあります。

日本では、この考え方が規制上の要求にも位置付けられています。医療機器の基本要件基準第12条第2項は、プログラムを用いた医療機器について、開発のライフサイクル、リスクマネジメント、確認及び検証の方法を考慮し、品質及び性能を検証することを求めています。厚生労働省通知（平成29年5月17日 薬生機審発0517第1号）では、対象となる医療機器について、JIS T 2304への適合をもって同項への適合を確認したものとする取扱いが示されています。

一般的なソフトウェア開発との主な違いは、リスクの検討をISO 14971／JIS T 14971に沿って明文化すること、要求と製品版の双方から設計・実装・試験記録を追跡できるようにすること、各活動の責任者、承認及び証跡を残すことです。審査及び監査では、計画、判断、実施及び結果の記録が、安全性及び性能を説明するための根拠となります。

IEC 62304とJIS T 2304の概要

IEC 62304は、医療機器ソフトウェアの開発から保守までのライフサイクルプロセスを定める国際規格です。日本では、対応する国内規格としてJIS T 2304が発行されています。実務では、製品に必要な承認・認証・届出、組織に必要な品質マネジメントシステム、ソフトウェア開発に必要なライフサイクル管理を区別したうえで、相互の関係を整理します。2026年7月時点の現行発行版はIEC 62304:2006+A1:2015（Edition 1.1）で、国内規格はJIS T 2304:2017です。

なお、「ライフサイクル」という用語自体は、IEC 62304では定義されていません。JIS T 81001-1:2022（3.3.12）は、製品又はシステムの初期構想から最終的な使用停止及び廃棄に至るまでの一連の全ての段階と定義しています。IEC 62304が規定するのは、このうち開発及び保守のプロセスです。

• 現行発行版はIEC 62304:2006+A1:2015（Edition 1.1）。第2版は策定中です。
• 日本ではJIS T 2304、基本要件基準、QMS省令、製品別要求との関係を確認します。
• ソフトウェア安全クラスA・B・Cは、医療機器クラスI～IVやFDA Basic／Enhancedとは別の分類です。
• 要求、リスク、設計、試験、構成、問題、保守を双方向にたどれることが実務の要です。

製品、組織、ソフトウェア開発の三つの観点

医療機器の製品化では、規格適合だけで販売要件が完結するわけではありません。必要な対応は、製品、組織及びソフトウェア開発の三つの観点に整理できます。

製品：医療機器への該当性、一般的名称、医療機器クラス、承認・認証・届出のどの経路に当たるかを確認する。

会社：製造販売業者、製造業者、開発委託先などの役割を整理し、QMS省令に基づく責任と手順を定める。

ソフトウェア開発：JIS T 2304／IEC 62304を軸に、要求、リスク、設計、試験、構成、問題解決、保守の記録をつなぐ。

PMDAは、厚生労働大臣の承認が必要な品目について審査を行います。認証基準のある品目は登録認証機関による認証、一般医療機器は届出となる場合があります。製品の医療機器該当性、一般的名称及び手続の経路を確認したうえで、JIS T 2304に基づく開発記録を申請、認証及びQMSの説明へ関連付けます。

図1 製品、組織、ソフトウェア開発の三つの観点

この記事で説明する内容

• 規格の位置付けと日本での扱い
• 五つのプロセス、ソフトウェア安全クラス、V&V
• 成果物とトレーサビリティの具体例
• SOUP、SBOM、脆弱性監視、レガシー
• FDA、アジャイル、クラウド、AI
• 導入ステップ、失敗例、FAQ、次に読むページ

日本の規制とJIS T 2304の位置付け

日本では、IEC 62304と内容が一致する国内規格としてJIS T 2304:2017が発行されています。国内の規制対応ではJIS T 2304を参照し、海外市場向けの技術文書ではIEC 62304との対応関係を確認します。対象には、ソフトウェア自体が医療機器となる医療機器プログラムと、医療機器へ組み込まれるソフトウェアの両方が含まれます。

IEC 62304は特定の開発手法を指定していません。組織は、計画、要求、リスク、設計、試験、構成、問題解決及び保守について、責任者、実施時期、判断基準及び記録方法を定めます。これにより、品質マネジメント及びリスクマネジメントの中で必要な活動が欠落することを防ぎます。

IEC 62304への適合は、ソフトウェアに不具合が存在しないことを証明するものではありません。想定した用途とリスクに対し、必要な活動を計画・実施し、その判断と結果を追跡できる状態を示します。

日本における主な要求事項

日本では、医療機器の基本要件基準と「医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令」（QMS省令）の枠組みの中で、医療機器ソフトウェアのライフサイクルを管理します。日本医療研究開発機構（AMED）の公式掲載ページでは、経済産業省との連名文書「医療機器ソフトウェアの品質管理システム確立に必要なソフトウェアライフサイクルプロセスの考え方を理解するためのガイダンス」を「令和8年7月公表」としています。一方、公開PDFの版識別子は「Ver.20260327」です。本記事では、2026年7月を一般公開時期、Ver.20260327を公開文書に表示された版識別子として区別します。このガイダンスは、JIS T 2304／IEC 62304を中心とするライフサイクルプロセスを、製造販売業者の品質マネジメントシステム（Quality Management System：QMS）へ組み込む考え方を説明しています。

日本向け製品に、FDAのBasic／Enhanced Documentation Levelをそのまま適用する必要はありません。一方、日本の申請でも、要求、リスク、設計、検証、構成、変更及び保守を説明する資料が必要です。開発情報を一元管理することで、海外展開時にも同じ記録を日本、米国、EUそれぞれの提出構成へ再編集しやすくなります。

IEC 62304の適用範囲に含まれない主な事項

• 医療機器全体の最終的な妥当性確認と市場への最終リリース判断
• 臨床的な有効性・性能の評価と、患者アウトカムに関するエビデンス
• 使用エラーを含むユーザビリティエンジニアリングの全活動
• サイバーセキュリティに固有の脅威分析、脆弱性管理、SBOM提供
• 製品表示、使用説明、販売後安全管理など、市場ごとの規制要求

なお、品質マネジメントシステム（QMS）は適用範囲外ではありません。IEC 62304／JIS T 2304は箇条4.1で、ISO 13485（JIS Q 13485）又はQMS省令に基づく品質マネジメントシステムを前提として要求しています。本規格は、その枠組みの中でソフトウェア開発・保守のプロセスを具体化するものであり、QMSそのものを詳細に規定する規格ではありません。

IEC 62304第2版の検討状況

IECでは第2版の検討が進められており、設計仕様書や委員会ドラフトに関する資料が公開されています。ただし、これらは策定中であり、現行の正式要求ではありません。正式発行まではEdition 1.1及び対象市場の規制要求が基準となり、第2版の資料は将来の変更を把握するための参考情報に位置付けられます。

関連サービス 製品の医療機器該当性、申請経路、QMS体制又はPMDA相談に関する支援内容は、医療機器認証・PMDA相談支援で確認できます。

規格本文を確認する際の留意点

• 本文の要求事項と、参考情報である附属書・注記との区別
• 成果物に加え、責任者、実施時期、判断の入力及び記録内容の確認
• ISO 13485、ISO 14971などの引用規格・関連規格との対応関係

規格本文にはshall、should、mayなど意味の異なる表現があります。正式規格の用語と、自社のQMS文書で使用する用語の対応関係を定める必要があります。

IEC 62304が定める五つのプロセス

IEC 62304は、ソフトウェア開発、ソフトウェア保守、ソフトウェアリスクマネジメント、ソフトウェア構成管理及びソフトウェア問題解決の五つのプロセスで構成されます。各プロセスを別々に運用すると情報が部門間で分断されるため、共通の識別子、変更管理及びレビューを用いて関連付けます。

• ソフトウェア開発プロセス：計画、要求分析、アーキテクチャ、詳細設計、実装、結合、システム試験、リリースをつなぐ。
• ソフトウェア保守プロセス：市場に出た後のフィードバック、変更、修正版のリリースを管理する。
• ソフトウェアリスクマネジメントプロセス：ソフトウェアが危険状態にどう関与するかを分析し、リスクコントロールを要求・設計・試験へ落とす。
• ソフトウェア構成管理プロセス：何を、どの版として、どの組合せでリリースしたかを識別する。ソースコードだけでなく、SOUP、ツール、設定、ビルド条件、配布物を含むスナップショットを残し、必要なときに同じ状態を再現できるようにする。
• ソフトウェア問題解決プロセス：問題を記録し、調査し、影響を評価し、解決と検証まで閉じる。

五つのプロセスは相互に関連します。市場で確認された問題は、問題解決プロセスで評価し、必要に応じて変更要求、リスクの再評価、構成の更新、回帰試験及び再リリースへ展開します。IEC 62304対応では、この一連の記録を追跡できる状態にします。

ソフトウェア開発プロセスの構成

開発計画には、その製品で適用する開発ルールを定めます。対象となる成果物、識別方法、レビュー担当者、合格基準、構成管理の開始時点、問題解決及び変更管理の手順を明確にします。これらが未定義の場合、設計及び試験に関する判断の再現性を確保できません。

• 開発計画：適用するプロセス、役割、成果物、レビュー、ツール、構成管理、問題解決、保守との接続を決める。
• 要求分析：意図する使用、システム要求、リスクコントロール、インターフェース、データ、性能、セキュリティなどを検証可能な要求へ落とす。
• アーキテクチャ設計：ソフトウェアアイテム、外部インターフェース、SOUP、データフロー、安全性に関わる分離を示す。
• 詳細設計と実装：ソフトウェアユニットの責務、入出力、アルゴリズム、エラー処理を明確にし、実装・レビュー・ユニット検証を行う。
• 結合と結合試験：ソフトウェアアイテムを組み合わせ、インターフェース、データの受け渡し、タイミング、異常時動作を確認する。
• ソフトウェアシステム試験：ソフトウェア要求が実装されているか、意図した環境と構成で確認する。
• ソフトウェアリリース：未解決異常、残留リスク、試験結果、全体版、構成要素、ビルド条件及び配布物を確認し、システムレベルで使用できる状態として管理する。リリース時点のスナップショットを保存し、必要に応じてハッシュ値などにより配布物の完全性を確認できるようにする。

開発計画に含める作業と関係者

医療機器ソフトウェアの工数は、実装と試験だけでは見積もれません。医療機器該当性・申請方針の確認、リスクマネジメント、文書化、レビュー・承認、構成管理、設計開発バリデーション、市販後体制の準備が並行します。コード量だけを基準に見積もると、これらの作業と部門間調整が不足しやすくなります。

計画時には、品質、安全管理、薬事、開発、製造、販売及び外部専門家などの関係者と判断時期を明確にします。申請方針又は意図する使用に未確定事項がある場合は、前提、保留事項、確認方法及び変更が生じた際の影響分析を記録します。

JIS T 2304／IEC 62304のソフトウェア安全クラスA・B・C

IEC 62304 Edition 1.1は、ソフトウェアシステム又はソフトウェアイテムをソフトウェア安全クラスA、B、Cに分類し、想定される危害に応じて必要な活動を定めています。この分類は、医療機器のクラスI～IV及びFDAの基本文書化レベル／拡張文書化レベルとは目的と判定方法が異なります。

分類では、危害の重大さだけでなく、ソフトウェア故障から危険状態までの因果関係、外部のリスクコントロール、アーキテクチャ上の分離及びソフトウェアアイテムへの分解を評価します。判断はISO 14971に基づくリスクマネジメントと関連付け、根拠を記録します。安全関連機能を分離しただけで、他の部分を自動的に低いクラスへ分類することはできません。

ソフトウェア安全クラスAであっても、製品に適用されるQMS省令、リスクマネジメント、ユーザビリティ及びサイバーセキュリティなどの要求は別に評価します。安全クラスはJIS T 2304／IEC 62304内の活動の適用範囲を決める分類であり、設計資料や検証記録を一律に省略できることを意味しません。

アーキテクチャ分離の成立条件

安全性に関係する機能と関係しない機能を分ければ、自動的に低いクラスへ分類できるわけではありません。分離が故障の伝播を防げること、共有資源、通信、メモリ、タイミング、共通サービス、SOUPなどを介した干渉が管理されることを、設計と検証で示す必要があります。

検証（Verification）と妥当性確認（Validation）の違い

検証（Verification）は、各開発成果が、その入力となった要求を正しく満たしているかを確認する活動です。要求レビュー、設計レビュー、静的解析、ソフトウェアユニット試験、結合試験、ソフトウェアシステム試験などが含まれます。実施記録には、確認対象、入力、判定基準及び結果を明示します。

一方、妥当性確認（Validation）では、完成した医療機器が、意図する使用及びユーザーニーズを実際又は模擬した使用環境で満たすことを確認します。検証と妥当性確認はV&Vと総称されますが、対象と目的が異なります。それぞれの入力、実施条件、判定基準及び結果を記録します。

IEC 62304対応で管理する主な成果物

IEC 62304は、すべての組織に同じ文書名や冊数を指定しているわけではありません。主な成果物は次の情報で構成されます。一つの管理システム又は文書で複数の要求に対応する場合も、適用範囲、版、承認及び相互参照を明確にします。

トレーサビリティと変更影響分析

要求仕様書、設計書及び試験結果が存在していても、相互の対応関係が不明確であれば、変更の影響範囲を判断できません。トレーサビリティは、要求、リスクコントロール、設計、実装、試験及びリリース判断を関連付け、変更影響分析に利用します。

トレーサビリティには、大きく二つの用途があります。要求のトレーサビリティは、意図する使用、リスクコントロール、ソフトウェア要求、設計、実装及び検証の関係を示します。製品のトレーサビリティは、出荷又は提供した製品版から、ソースコード、ビルド条件、SOUP、設定、試験記録、承認及び配布先をたどれる状態を示します。両者を組み合わせることで、変更の影響と市場への影響範囲を同じ情報から判断できます。

図2 要求のトレーサビリティと製品のトレーサビリティ

このつながりがあれば、要求が変わったときに影響する設計、コード、リスク、試験を見つけられます。試験が失敗したときには、どの要求と危険状態に関係するかをたどれます。未解決の異常を残してリリースするときも、患者や使用者への影響を説明できます。

文書の冊数が多くても、識別子、版及び相互参照が一致していなければ、変更の影響を判断できません。次の記載例では、一つの要求をリスク、設計、試験、構成及び保守へ関連付ける方法を示します。

要求から試験結果までのトレーサビリティ記載例

以下は、トレーサビリティの構成を説明するための一般化した記載例です。特定の製品又は実在案件を示すものではありません。識別子、機能名及び試験条件も説明用の例です。

ケースの前提

クラウド型の医用画像・検査結果ビューアで、利用者が患者と検査を選択し、外部の結果サーバーから取得した確定済みの検査結果を確認する機能を対象とします。画面、アプリケーション・プログラミング・インターフェース（API）、一時キャッシュ及び結果サーバーが連携する構成です。

利用者の要求は「選択した患者の確定済み結果を確認できること」です。ただし、この表現だけでは、患者切替え中、応答の遅延、複数要求の応答順序の逆転、再接続及びキャッシュ利用時の動作を一意に検証できません。

起点となる事象

ソフトウェアシステム試験で、患者Aの結果を表示した直後に患者Bへ切り替えると、遅れて到着した患者Aの応答が患者Bの画面へ反映される事象が確認されたとします。画面の患者名は患者Bへ切り替わっており、通信エラーも表示されないため、利用者が表示内容の不一致に気付けない可能性があります。

1. 患者Aの画面で結果取得を要求し、応答を待つ。
2. 応答が届く前に、利用者が患者Bへ表示対象を切り替える。
3. 患者Bの取得要求より後に、患者Aの古い応答が到着する。
4. 画面側が応答と現在の患者コンテキストを照合せず、患者Aの結果を患者Bの表示領域へ反映する。

この例では、別患者又は古い検査結果の表示が誤った診療判断につながる可能性をリスクとして扱います。危害の重大さ、発生確率及び受容基準は、意図する使用、使用環境、製品全体のリスクコントロールを踏まえて製品ごとに評価します。ここでは架空の点数を置かず、記録同士のつながりを示します。

リスクから検証可能な要求へ

リスク分析では、この事象列をRISK-021として記録し、応答を画面へ反映する直前に患者、検査、確定状態及び要求世代を照合することをリスクコントロールとして定めます。上位の要求REQ-DSP-014は、次のように個別に判定できる要求へ分解します。

REQ-DSP-014-1 表示対象の患者ID及び検査IDと、応答に含まれる識別子が一致する場合だけ結果を表示する。

REQ-DSP-014-2 確定状態の結果だけを結果値として表示し、未確定状態では「結果未確定」と表示する。

REQ-DSP-014-3 患者又は検査を切り替えた時点で、前の表示内容を消去し、新しい取得処理の状態を表示する。

REQ-DSP-014-4 現在の要求より古い応答又は識別子が一致しない応答を破棄し、調査可能なログを残す。

REQ-DSP-014-5 通信断又は再接続時に、現在の患者・検査との一致を確認できないキャッシュ結果を表示しない。

各要求には、入力条件、期待する画面状態、許容しない動作及び記録するログを定めます。「安全に表示する」のような抽象表現を避けることで、設計レビューと試験の双方で同じ合否基準を使用できます。

設計で責任を分ける

アーキテクチャARC-07では、患者選択、結果取得、キャッシュ及び画面表示の責任を分けます。詳細設計DES-042では、要求を次のソフトウェアユニットへ割り当てます。

PatientContext 現在の患者ID、検査ID及び要求世代を一つのコンテキストとして管理する。

ResultGateway API要求へコンテキストを付与し、応答と要求元を対応付ける。

ResultViewModel 画面反映の直前に識別子、確定状態及び要求世代を照合し、不一致の応答を破棄する。

ResultCache 患者ID、検査ID、結果版及び確定状態をキーとして保存し、別コンテキストの値を返さない。

この分担により、REQ-DSP-014の各要求がどの設計要素で実現され、どのソフトウェアユニットを検証すべきかを追跡できます。共有メモリ、非同期処理、キャッシュ及び外部APIを介して分離が崩れないことも設計レビューの対象になります。

試験条件と期待結果を先に結び付ける

試験仕様は、操作手順だけでなく、応答順序、通信状態、初期キャッシュ及び期待するログを含めて作成します。次はソフトウェアシステム試験の例です。下位では、同じ要求に対してソフトウェアユニット試験UT-204～211及びソフトウェア結合試験IT-087～092を関連付けます。

不具合を変更とリリースまで閉じる

SYS-119が初回実施で不合格になった場合は、問題報告PR-033を起票します。原因分析で、ResultViewModelが応答先のAPIだけを確認し、PatientContextの要求世代を比較していなかったことを特定したとします。問題報告はRISK-021、REQ-DSP-014-4、DES-042及び失敗した試験結果へ関連付けます。

変更要求CHG-019では、要求世代の照合と不一致ログを設計・実装へ追加します。変更影響分析では、患者切替え、同一患者での連続取得、キャッシュ、再接続及びログ出力を対象とし、UT-204～211、IT-087～092、SYS-118～123を再実施します。修正によって正しい応答まで破棄される可能性も評価し、取得中表示と再取得手順を確認します。

再試験が合格し、残留リスク、未解決異常及び構成を確認した後、REL-2.4.0としてリリースを承認します。これにより、問題報告から変更理由、要求、設計、コード、試験結果及び出荷した版までを双方向に追跡できます。

この記録で答えられること

• なぜこの要求が必要なのかを、利用者要求とRISK-021から説明できる。
• 要求をどの設計要素とソフトウェアユニットで実現したかを確認できる。
• 正常系だけでなく、遅延、応答逆転、再接続及び識別子不一致をどの試験で確認したかを示せる。
• 不合格となった試験が、どの問題報告と変更要求によって解決されたかをたどれる。
• 修正を含む製品版と、使用した構成、試験結果及びリリース承認を特定できる。

トレーサビリティマトリクスは、後から作る対応表ではありません。開発中のレビュー、試験不合格の処理、変更影響分析及びリリース判定で同じ識別子を使用し、判断のたびに更新することで、実務上の管理情報になります。

開発過程が不明なソフトウェア（SOUP）の管理

医療機器ソフトウェアでは、外部のOS、ライブラリ及び市販ソフトウェアが使用されることがあります。IEC 62304は、既製又は開発記録を十分に取得できないソフトウェアをSoftware of Unknown Provenance（SOUP）として識別し、使用目的、既知の異常、リスク及び更新方法を管理することを求めています。JIS T 2304:2017における定義語は「開発過程が不明なソフトウェア」です。オープンソース又は商用という区分だけでSOUP該当性を判断するものではありません。

1. 名称、供給元、版、使用目的、依存関係を識別する。
2. 必要な機能・性能と動作環境を明確にする。
3. 既知の異常、変更履歴、サポート状況を評価する。
4. 故障や脆弱性が危険状態へつながる経路を分析し、必要なリスクコントロールを置く。
5. 更新又は置換時の影響分析、回帰試験、再リリース手順を決める。

SOUP一覧とソフトウェア部品表（SBOM）の違い

SOUP管理とSoftware Bill of Materials（ソフトウェア部品表：SBOM）は、目的が異なります。SOUP管理は、IEC 62304上の使用目的、機能、既知の異常及びリスクとの関係を扱います。SBOMは、製品を構成する部品と依存関係を一覧化し、透明性と脆弱性対応を支えます。共通のコンポーネント台帳からSOUP評価、SBOM、構成管理及び脆弱性監視へ情報を展開することで、版や供給元情報の不一致を抑制し、脆弱性の影響を受ける製品版を特定できます。

2026年のAMEDガイダンスは、SOUPの重要性やソフトウェア安全クラスなどを踏まえて脆弱性監視頻度を設定する考え方を例示しています。例示された頻度は一律の必須値ではなく、製品のリスク、更新頻度、外部への露出及び供給元情報を踏まえた監視計画の参考となります。

コンポーネント情報の一元管理

画像処理ライブラリを採用する場合、SOUP評価では製品安全への影響、SBOMでは構成の透明性、脆弱性監視では市販後の対応を管理します。共通のコンポーネント台帳から目的別の情報を参照することで、版及び供給元情報の不一致を抑制できます。

SOUP評価、SBOM及び脆弱性監視で同じ版情報を参照することにより、新たな脆弱性が公表された際に、影響を受ける製品版を速やかに特定できます。

レガシーソフトウェアへの対応

既に市場で使用されているソフトウェアや、IEC 62304に沿った開発記録が十分でない既存資産を、新製品又は変更製品へ組み込む場合があります。Edition 1.1にはレガシーソフトウェアを扱う考え方がありますが、市場での使用期間だけで安全性を判断するものではありません。

1. 既存ソフトウェア、残っている記録、既知の問題、市場実績、変更履歴を特定する。
2. 現在の意図する使用とアーキテクチャに対するリスクを評価する。
3. 不足する活動や証拠を洗い出し、追加試験、文書化、リスクコントロールを計画する。
4. 計画した活動を実施し、残留する問題をリリース判断につなげる。
5. 以後の変更を通常の保守・構成管理・問題解決プロセスへ取り込む。

市販後の保守と変更管理

医療機器ソフトウェアでは、リリース後もOS、外部サービス、脆弱性情報、苦情及び使用環境が変化します。保守では、問題の修正だけでなく、影響範囲、リスク、回帰試験、リリース構成及び利用者への情報提供を管理します。保守、構成管理及び問題解決を開発プロセスと接続することが重要です。

市場投入後も、使用環境、OS、外部サービス及び脆弱性情報は変化し、苦情、インシデント又は機能改善への対応が発生します。このため、製品のリリース後も安全性に関する判断と記録の更新が続きます。IEC 62304は、この継続的な管理を保守、構成管理及び問題解決の各プロセスに位置付けています。

保守計画は、市場投入後に作り始める資料ではありません。収集する情報、評価基準、部門間の役割並びに規制当局、販売業者、製造業者、供給者及び利用者への連絡経路を、市場投入前に定めます。ソフトウェアの修正が必要な問題は、開発部門だけで完結せず、品質、安全管理、薬事、製造及び販売を含む判断になるためです。

図3 市販後情報の収集から変更、再リリースまで

保守プロセスでは、問題の再現、影響範囲、リスクの変化、修正の妥当性、回帰試験、リリース対象の構成及び利用者への情報提供を、一つの変更として管理します。セキュリティパッチにも機能安全への影響評価が伴い、更新を行わない場合には脆弱性リスクの評価が必要です。製品全体の品質、ユーザビリティ及びサイバーセキュリティは、IEC 62304と関連規格を組み合わせて管理します。

製造販売業者の責務は、出荷後の不具合対応にとどまりません。厚生労働省通知「医療機器のサイバーセキュリティ導入に関する手引書の改訂について」（令和5年3月31日 薬生機審発0331第11号）は、製品ライフサイクル全体（Total Product Life Cycle：TPLC）における考慮事項として、サポート終了（End of Support：EOS）の段階まで計画しておくことを製造販売業者の責務の範囲としています。サポートの終了予定、利用者への告知及び終了後の取扱いは、市場投入前のセキュリティ計画で検討します。

IEC 62304と関連規格の組合せ

実務では、要求、リスク、設計、試験及び変更に関する共通情報を管理し、各規格や申請目的に応じて構成する方法が有効です。規格ごとの資料を個別に作成する場合と比べ、情報の重複や不整合を抑制できます。

米国食品医薬品局（FDA）への申請とIEC 62304の関係

IEC 62304に基づく開発記録はFDA申請へ再利用できますが、そのまま提出資料になるわけではありません。米国食品医薬品局（Food and Drug Administration：FDA）はIEC 62304 Edition 1.1を認知コンセンサス規格として掲載する一方、2023年ガイダンスで市販前申請のソフトウェア文書を基本文書化レベルと拡張文書化レベルに区分しています。この区分は、IEC 62304のソフトウェア安全クラスA、B、Cとは目的と判定方法が異なります。

FDAの基本文書化レベルと拡張文書化レベル

FDAのDocumentation Levelは、対象となるソフトウェア機能ごとに評価し、その根拠を記載します。Enhancedとなる代表的な条件には、リスクコントロール前のソフトウェア故障又は欠陥が死亡又は重大な傷害につながり得る場合、特定の高リスク機器区分に該当する場合などがあります。最終判断は、製品、機能、申請経路及び意図する使用に基づきます。

IEC 62304に沿って作成した成果物の多くはFDA申請へ再利用できます。ただし、FDAガイダンスA～Jの各要素、申請対象版、対象ソフトウェア機能及び申請経路に合わせて、共通の設計履歴を市場別の提出構成へ再編集します。基本文書化レベルであっても、審査中に追加情報を求められる可能性を考慮した記録管理が必要です。

日本向け申請とFDA Documentation Level

日本国内だけを対象とする申請で、FDA独自のBasic／Enhanced判定を行う義務は通常ありません。日本ではJIS T 2304への適合、ソフトウェア安全クラス、基本要件、QMS省令、製品別要求に基づいて説明します。ただし、FDA向けにしか使えない別資料を作るのではなく、共通の設計履歴を基に各市場の提出構成へ変換することが、重複作業と矛盾を減らします。

アジャイル開発・DevOpsにおけるIEC 62304対応

IEC 62304は特定の開発モデルを要求していないため、アジャイル開発及びDevOpsにも適用できます。各反復で、要求、リスク、設計、試験、構成及び変更の記録を更新し、レビューと承認の証跡を残す運用が必要です。

短い期間で開発を反復するスプリント、要求を利用者視点で表すユーザーストーリー、自動テスト、継続的インテグレーション／継続的デリバリー（Continuous Integration／Continuous Delivery：CI/CD）は、それ自体が適合又は不適合を決めません。ユーザーストーリーを要求として使うなら、曖昧さを解消し、識別し、リスクコントロールや受入基準へ追跡できる必要があります。自動テストなら、どの要求をどの環境・構成・版で確認したかを再現できる必要があります。

クラウド型医療機器プログラム（SaMD）の構成管理

クラウド型の医療機器プログラムでは、ソースコードに加えて、アプリストアの登録版、サーバー環境、コンテナ、設定値、外部API、モデル、データベース移行及び段階的リリースの条件が製品構成へ影響します。提供環境全体を構成として識別し、承認した手順でデプロイすることで、障害調査及び回帰試験に必要な環境を再現できるようにします。

人工知能（AI）・機械学習を使用する場合の追加事項

AIモデルもソフトウェア構成の一部として、要求、設計、検証、版、変更及びリリースの管理対象となります。AIを使用する場合は、コードの変更がなくても、学習データや再学習によって性能や挙動が変化する点を考慮します。データの代表性、バイアス、学習・評価データの分離、性能ドリフト、再学習及び臨床的な有効性には、IEC 62304以外の管理も必要です。

将来の性能変更を予定する製品では、変更範囲、検証方法、合格基準及びリスクマネジメントを事前に設計します。日本の「医療機器の特性に応じた変更計画の事前確認制度」（IDATEN）や、FDAのPredetermined Change Control Plan（事前に定めた変更管理計画：PCCP）など、市場ごとの制度との整合も必要です。ソフトウェアの版だけでなく、データ、性能及び臨床的意味の変化を評価します。

IEC 62304対応を始めるときの7ステップ

1. 製品の意図する使用、使用者、使用環境、ソフトウェアの範囲を明確にする。
2. 適用市場の規制要求と、ISO 13485／QMS省令を含む品質システム上の責任を確認する。
3. ISO 14971のリスク分析と接続し、IEC 62304のソフトウェア安全クラスを決定して根拠を残す。
4. 規格の活動を自社の開発プロセス、役割、ツール、成果物へ割り当てる。
5. 要求、リスクコントロール、設計、コード、試験、問題を識別子で追跡できるようにする。
6. リリース判定、構成識別、未解決異常、配布・デプロイの受容条件を定義する。
7. 苦情、脆弱性、変更、回帰試験、市販後監視、再リリースを含む保守のループを運用する。

導入時には、対象製品の一機能を選び、意図する使用、リスク、要求、設計、試験、構成及びリリースの対応関係を確認する方法があります。追跡できない箇所を特定し、識別、版管理、レビュー及び変更管理の手順を段階的に整備します。

IEC 62304対応で発生しやすい問題

• 規格の条文番号ごとに文書を作り、同じ情報を何度も転記する。
• ソフトウェア安全クラスを決めたものの、その根拠がリスクマネジメントファイルとつながっていない。
• 要求仕様書とテスト仕様書はあるが、どの試験がどの要求とリスクを確認したか分からない。
• アーキテクチャ図はあるが、ソフトウェアアイテム、SOUP、外部インターフェース、分離の根拠がない。
• SOUP一覧やSBOMはあるが、版、既知の異常、脆弱性、使用目的、更新判断が統合されていない。
• リリース時点の構成を再現できず、ソース、ライブラリ、設定、クラウド環境を特定できない。
• 開発プロセスは整っているが、市場投入後の問題解決、市販後監視、保守が別運用になっている。
• 規格適合と、医療機器全体のバリデーション、臨床評価、申請を同じものだと考える。

これらの問題の多くは、文書数ではなく、要求、リスク、設計、試験、構成及び変更記録の不整合に起因します。識別子、版及び相互参照を統一することで、記録を変更影響分析とリリース判断へ利用できるようになります。

関連ページ

ソフトウェア安全クラスごとの活動は、IEC 62304の安全性クラス別・要求事項一覧で確認できます。個別論点については、IEC 62304 FAQを参照できます。

IEC 62304対応で重要となる管理体制

JIS T 2304／IEC 62304は、設計手法やプログラミング技法そのものを指定する規格ではありません。組織が定めた品質及び安全性を計画したプロセスで実現し、検証し、変更後も説明できる状態にするための規格です。要求、使用環境又は既知の問題が変化した場合も、リスク、設計、試験、構成及びリリース判断を継続して更新します。

IEC 62304対応を、変更の影響把握、レビュー基準の統一及びリリース判断に利用できる業務プロセスとして実装することで、規格対応の記録を開発及び保守の実務に活用できます。

対応範囲の確認では、一つの機能について、意図する使用、リスク、要求、設計、試験、構成及びリリースを双方向に追跡します。追跡できない箇所を特定することで、優先して整備するプロセス及び記録を明確にできます。

リベルワークスのIEC 62304対応支援

リベルワークスでは、医療機器ソフトウェアの企画、開発、規格適合、QMS構築及び承認・認証に向けた技術文書の整備を支援しています。プロトタイプの医療機器化、既存ソフトウェアの再設計、開発プロセスのギャップ分析など、製品の段階に応じて対応範囲を整理します。

関連サービス IEC 62304対応サービス ／ 医療機器ソフトウェア開発 ／ 医療機器認証・PMDA相談支援

ご相談 IEC 62304対応に関するお問い合わせから、製品の状況と検討中の支援範囲をご連絡いただけます。

用語集

本文で使用する主な専門用語をまとめています。規制上の定義及び適用判断については、正式規格、法令及び最新のガイダンスを優先します。

関連規格名の確認

公式情報・参考資料

PMDA 医療機器 — 医療機器クラスと届出・第三者認証・大臣承認の関係

PMDA 承認審査業務（申請・審査等） — 品質、有効性、安全性の承認審査とQMS適合性調査

IEC 62304:2006+AMD1:2015 CSV（IEC公式） — 現行発行版、適用範囲、Edition 1.1、Stability date 2028

JIS T 2304:2017プレビュー（日本規格協会） — IEC 62304 Edition 1.1との一致規格

AMED 医療機器ソフトウェアのライフサイクルプロセスを理解するためのガイダンス — 2026年7月公表。日本のQMS、SaMD、SOUP、AI、市販後等

厚生労働省 プログラム医療機器の承認・開発ガイダンス — JIS T 2304への適合説明、ソフトウェア安全クラス

厚生労働省 基本要件基準第12条第3項の適用 — JIS T 2304とJIS T 81001-5-1の関係

厚生労働省 医療機器サイバーセキュリティ導入手引書 — SBOM、レガシー、脆弱性、ライフサイクル

FDA Content of Premarket Submissions for Device Software Functions — Basic／Enhanced Documentation Level

FDA Recognized Consensus Standards: IEC 62304 Edition 1.1 — FDAの認知状況

IEC 62304 Edition 2 Design Specification（策定資料） — 未発行の第2版に関する動向確認用

JEITA IEC 62304実践ガイドブック — 日本語の実務ガイド

免責 本原稿は一般的な情報提供を目的としており、法的助言、規制当局の判断又は適合性を保証するものではありません。実際の製品では、正式規格、対象市場の最新法令・通知・ガイダンス及び規制当局・認証機関との合意を優先する必要があります。

よくある質問（FAQ）

JIS T 2304／IEC 62304に関する個別の疑問は、専用のFAQページに集約しています。本記事で全体像を確認した後、具体的な判断や運用上の論点をFAQで確認できる構成としています。

FAQで確認できる主なテーマ

• JIS T 2304とIEC 62304の関係、日本国内の申請及びPMDA審査との関係
• ソフトウェア安全クラスA・B・C、必要な成果物、試験及びトレーサビリティ
• SOUP、オープンソースソフトウェア、SBOM、外部委託、保守、クラウド及びAI／機械学習

個別の疑問を確認する：JIS T 2304／IEC 62304 FAQ

ソフトウェア安全クラスごとの適用活動を確認する：IEC 62304要求事項対照表