【専門家監修】IEC 62304とは？医療機器ソフトウェア開発の実務

医療機器にソフトウェアを搭載する、あるいはソフトウェアそのものを医療機器として承認申請する場合、IEC 62304（国内ではJIS T 2304）への適合が求められます。ただし規格の目次を読んでも、自社が何をどこまでやればよいのかは見えてきません。作業量を左右するのは安全クラスの判定であり、実務で最も詰まるのはSOUP（開発過程が不明なソフトウェア）の管理です。

この記事では、安全クラスA・B・Cの判定と格下げの条件、クラス別に要求されるプロセスの違い、SOUP管理の要求事項、QMS省令の設計開発プロセス（第30条〜第36条の2）への載せ方を、箇条番号と条文に沿って整理します。

IEC 62304とは？対象範囲と規格の版

IEC 62304は、医療機器ソフトウェアの開発と保守について、ライフサイクル全体で実施すべきプロセス・アクティビティ・タスクを規定した国際規格です。国内ではJIS T 2304として制定されており、現行版はJIS T 2304:2017（IEC 62304:2006およびAmendment 1:2015に一致）です。

規定しているのは製品の性能ではなく開発のプロセスです。適合とは「ソフトウェア安全クラスに従って、この規格で特定した全てのプロセス、アクティビティ及びタスクを実行すること」（箇条1.4）であり、成果物の記録がなければ適合を主張できません。

対象になるソフトウェアと、対象にならないソフトウェア

適用範囲は「ソフトウェアそれ自体が医療機器である場合、又はソフトウェアが完成品である医療機器に組み込まれているか若しくは不可欠な部分となっている場合」（箇条1.2）で、プログラム医療機器（SaMD）と組込みソフトウェアの両方が対象です。医療機器としての妥当性確認と最終的なリリースは対象外で、JIS T 0601-1やIEC 82304-1といった製品規格が担います。

一方、QMSの運用に使うソフトウェアはIEC 62304の対象ではありません。文書管理システム、製造設備の制御ソフト、測定機器の解析ソフトなどは、QMS省令（医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令。平成16年厚生労働省令第169号）第5条の6（ソフトウェアの使用）、第45条（製造工程等のバリデーション）、第53条（監視及び測定に係る設備及び器具の管理。第8項が監視及び測定に使用するソフトウェアの適用のバリデーション、第11項がその結果の記録を要求）が求めるバリデーションの対象で、要求の性質が異なります。「医療機器そのものを作る話」か「QMSを回すために導入した道具の話」かで、参照すべき規格も条文も変わります。

IEC 62304とJIS T 2304の版の対応

古い解説はJIS T 2304:2012を前提にしている場合があります。安全クラスAの定義はAmendment 1:2015で変更されているため、参照する版を必ず確認してください。

日本でJIS T 2304への適合が必要になる法的根拠

国内での根拠は、医療機器の基本要件基準（平成17年厚生労働省告示第122号）第12条第2項です。同項は平成29年11月25日から適用され、厚生労働省通知「医療機器の基本要件基準第12条第2項の適用について」（平成29年5月17日 薬生機審発0517第1号）により、JIS T 2304への適合をもって同項への適合を確認したものとされています。

確認が求められるタイミングは「製造販売」ではなく「申請」です。経過措置期間終了日（平成29年11月24日）の翌日以降に承認申請又は認証申請を行う製造販売業者等が対象で、通知には高度管理医療機器・管理医療機器が明示されたうえで、一般医療機器についても同様に確認が必要と記載されています。

また、確認の対象はJIS T 2304に限られません。通知は一貫して「JIS T 2304等」と記載し、プログラムを用いた医療機器のライフサイクルプロセスについて国際的に用いられている適切な規格等がある場合は、それらへの適合性を確認することをもって第12条第2項への適合を確認したものとするとしています。IEC 62304の原文やそのAAMI版で運用している場合、JIS版に置き換える必要はありません。

基本要件基準は、薬機法（医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律）第41条第3項に基づき厚生労働大臣が定める医療機器の基準で、第12条は「プログラムを用いた医療機器に対する配慮」を定めています。承認・認証申請では適合性チェックリストに適合状況を記載しますが、「適合しています」と書くだけでは足りず、安全クラスの分類根拠とクラスに応じたプロセスの実施記録を提示できる状態が必要です。なお第12条第3項（サイバーセキュリティ）には別途「医療機器の基本要件基準第12条第3項の適用について」（令和5年3月31日 薬生機審発0331第8号）が発出されており、JIS T 81001-5-1が関係します。

すでに販売中のソフトウェアはどうするか

箇条3.36は、レガシーソフトウェアを「法規制に適合して市場に出荷され、現在も市販されているが、この規格の現行版に適合して開発されたという客観的な証拠が不十分な医療機器ソフトウェア」と定義しています。該当する場合は箇条4.4により、箇条5〜箇条9をすべて適用する代わりに、4.4.2（リスクマネジメントアクティビティ）、4.4.3（ギャップ分析）、4.4.4（ギャップ解消アクティビティ）、4.4.5（レガシーソフトウェアを使用する根拠）で適合性を実証できます。ギャップ分析は安全クラスに基づき、5.2、5.3、5.7および箇条7の要求事項に対して行います。過去の製品を今から全工程やり直す必要はない、という逃げ道がここにあります。

国内でも同様の措置が用意されています。薬生機審発0517第1号は、経過措置期間終了日（平成29年11月24日）までに設計が完了している医療機器について、JIS T 2304等の要求事項と当該医療機器に関して利用可能な情報等との差分を分析し、リスクが受容可能になるようリスクマネジメントの中で対応して必要な記録を残すことを求めています。箇条4.4のギャップ分析と実質的に同じ作業です。

QMS省令とIEC 62304は相互に参照し合う

見落とされがちですが、IEC 62304の側もQMSを前提にしています。箇条4.1は製造業者が要求事項に適合する能力をもつことの実証を求め、その手段としてJIS Q 13485（ISO 13485）と並んで「医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令」、すなわちQMS省令を挙げています。独立した62304対応プロジェクトを立てるのではなく、既存の設計開発プロセスに組み込むのが本来の姿です。規制とQMS構築の全体像はSaMD（プログラム医療機器）の規制とQMS対応ガイドで整理しています。

ソフトウェア安全クラスA・B・Cの判定手順

ソフトウェア安全クラスは、ソフトウェアシステムに起因する危険状態が最悪の場合にもたらす危害のリスクに応じてA・B・Cに分類します（箇条4.3 a）。この判定で実施すべきプロセスの数が大きく変わるため、62304対応の作業量を決める最大の分岐点です。

BとCの境界は「重傷の可能性があるかどうか」です。ソフトウェアの故障の発生確率が低いことを根拠にクラスを下げることはできません。

判定で外してはいけない3つの前提

前提となる危険状態の特定とリスク評価は、JIS T 14971（ISO 14971）のリスクマネジメントプロセスに従います（箇条4.2）。IEC 62304は単独では完結せず、その成果物を入力として受け取る構造です。手順は医療機器QMSにおけるリスクマネジメント実践ガイドを参照してください。

安全クラスを下げられる2つのルート

安全クラスの引き下げには規格が認めるルートが2つあり、どちらも根拠の文書化が条件です。

1. external toのリスクコントロール手段を追加する — 当初B又はCに分類したソフトウェアシステムについて、そのソフトウェアシステム以外で実施するリスクコントロール手段（システムアーキテクチャの改善など）を追加で実施し、新しい安全クラスに分類し直すことができます（箇条4.3 a）。
2. ソフトウェアアイテムを分離する — ソフトウェアシステムをソフトウェアアイテムに分割した場合、各アイテムは元のクラスを継承します。別のクラスに分類するには正当な根拠を文書で示す必要があり、その根拠には新しいソフトウェアアイテムをどのように分離するのかの説明が必要です（箇条4.3 d、e）。

分離は物理的な分離に限られず、あるソフトウェアアイテムが他のアイテムに悪影響を及ぼさないためのあらゆるメカニズムを含みます。ただしクラスCでは、リスクコントロールに必要なアイテム間の分離を特定し、分離が有効であることを確実にする方法を明示することが別途要求されます（箇条5.3.5）。「モジュールを分けたのでこちらはクラスAです」と主張するには、その分離が破れないことの説明まで求められます。なお分類を確定できるのはアーキテクチャが固まった時点以降で、それ以前の分類をプロセスの省略の正当化に使わないことが望ましいとされています（附属書B.4.3）。

安全クラス別に要求されるプロセス

クラスAで要求されないのは、アーキテクチャの設計（5.3）、詳細設計（5.4）、結合及び結合試験（5.6）と、リスクマネジメントプロセス（箇条7）の大部分です。逆に開発計画・要求事項分析・システム試験・リリース・保守・構成管理・問題解決は、クラスAであっても実施しなければなりません。規格では各要求事項の末尾に適用クラスが記載されています。

（JIS T 2304:2017 の各細分箇条に付記された適用クラスをもとに作成）

クラスBとCの差は詳細設計まわりに集中しています。クラスBで要求されるのは5.4.1（ソフトウェアユニットへの分解）までで、5.4.2〜5.4.4（詳細設計の開発と検証）はクラスC限定です。ほかにクラスC固有の要求として5.1.4（開発規格・方法・ツールの計画）、5.3.5（分離の特定）、5.5.4（追加のユニット合否判定基準）があります。

一方、箇条7（リスクマネジメント）にクラスC限定の要求事項はありません。クラスAで要求されるのは7.4.1（医療機器ソフトウェアの安全性に関わる変更の分析）だけで、クラスB・Cでは箇条7の全項目が要求されます。リスクコントロール手段の選択と文書化（7.2.1）もクラスBで要求されるため、クラスBだからと省略することはできません。

ソフトウェアライフサイクルプロセスの実務

IEC 62304は、開発プロセス（箇条5）、保守プロセス（箇条6）、3つの支援プロセス（箇条7 リスクマネジメント、箇条8 構成管理、箇条9 問題解決）で構成されます。開発プロセスだけを整備して支援プロセスを落とすのが典型的な失敗パターンです。

5.8.2（既知の残留異常の文書化）はクラスAでも要求されます。「既知の不具合を残したままリリースしてよいか」ではなく、「残したものを文書化し、受容できないリスクにならないことを確認したか」（5.8.3、クラスB・C）が問われます。

保守プロセスと支援プロセスはクラスAでも省略できない

保守プロセス（箇条6）は保守計画の確立（6.1）、フィードバックの監視・文書化・評価（6.2.1）、変更要求の評価・承認（6.2.4）、5.8に従った再リリース（6.3.2）で構成され、すべてクラス共通の要求です。支援プロセスのうち、構成管理（箇条8）と問題解決（箇条9）も全項目がクラスAで要求されます。箇条7で例外的にクラスAに適用されるのは7.4.1（安全性に関わる変更の分析）だけです。

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

SOUPは「既に開発されていて一般に利用できるが、医療機器に組み込むことを目的に開発したものではないソフトウェアアイテム、又は以前開発されたソフトウェアアイテムでその開発プロセスについての十分な記録が利用できないもの」と定義されています（箇条3.29）。OSS、商用ライブラリ、OS、既製品（OTS）が該当し、自社の過去資産でも開発記録が不十分なものはSOUPです。なお医療機器ソフトウェアシステム全体をSOUPであると主張することはできません（箇条3.29 注記）。

SOUP管理でやることチェックリスト

• [ ] SOUPアイテムを洗い出し、名称・製造業者・SOUPを特定する識別子を文書化する（8.1.2、クラスA・B・C）
• [ ] 識別子にバージョン、リリース年月日、パッチ番号、アップグレードの識別子を含める（8.1.2 注記）
• [ ] 標準ライブラリもSOUP構成アイテムに含める（8.1.2）
• [ ] 各SOUPアイテムの、意図する使用に必要な機能・性能要求事項を明確にする（5.3.3、クラスB・C）
• [ ] 各SOUPアイテムの正常な動作に必要なシステムハードウェア・ソフトウェアを明確にする（5.3.4、クラスB・C）
• [ ] 医療機器アーキテクチャが全SOUPアイテムの正常な動作を支援していることを検証する（5.3.6、クラスB・C）
• [ ] SOUPを含む結合・結合試験の計画を開発計画書に示すか引用する（5.1.5、クラスB・C）
• [ ] SOUPに起因する故障・予期せぬ結果を危険状態の潜在的原因として検討する（7.1.2、クラスB・C）
• [ ] SOUPアイテムの供給者が公開している異常リストを評価する（7.1.3、クラスB・C）

既知の異常リストの評価が最大の関門

実務で最も詰まるのが7.1.3（公開されたSOUP異常リストの評価）です。SOUPに起因する故障又は予期せぬ結果が危険状態の一因となるソフトウェアアイテムの潜在的原因になっている場合、当該医療機器に使用しているSOUPアイテムのバージョンに関係する、供給者が公開している異常リストを最低限度として評価し、既知の異常によって危険状態の原因となる一連の事象が生じるかを判断しなければなりません。

つまり「このライブラリのこのバージョンについて、公開されている既知の不具合をすべて確認し、自社機器で危害につながるかを一件ずつ判断した記録」が必要です。依存パッケージが数百に及ぶ開発では、バージョンを固定して依存関係と評価結果を継続的に管理する仕組みがなければ運用が破綻します。SBOM（ソフトウェア部品表）の整備は、この要求への実務的な回答です。

QMS省令・ISO 13485の設計開発への組み込み方

IEC 62304のライフサイクルは、QMS省令第5節「製品実現」の設計開発プロセス（第30条〜第36条の2）に載せるのが正しい実装です。62304用の手順書を独立して作るのではなく、既存の設計開発手順にソフトウェア固有のアクティビティを組み込みます。

（ISO 13485:2016の箇条番号は、施行通知（令和3年3月26日 薬生監麻発0326第4号。令和7年1月31日一部改正）の各条の解説に示された対応関係による）

リスクマネジメントと使用性は省令側でも要求されている

QMS省令第31条第1項第1号は工程入力情報として「意図した用途に応じた機能、性能、使用性及び安全性に係る製品要求事項」を、第3号は「第26条第3項に規定するリスクマネジメントに係る工程出力情報たる要求事項」を挙げています。リスクマネジメントの成果物を設計開発の入力にすることは、規格の要請である以前に日本の省令の要求です。第1号の「使用性」は、施行通知38．第31条関係（3）が「IEC 62366-1のUsabilityに相当するもの」と明記しています（医療機器のユーザビリティとは？）。

トレーサビリティも同様で、第30条第4項第5号が設計開発計画において「工程入力情報から工程出力情報への追跡可能性を確保する方法」の文書化を求めています。IEC 62304側では、5.1.1 c)がシステム要求事項・ソフトウェア要求事項・ソフトウェアシステム試験・ソフトウェアに実装するリスクコントロール手段の間のトレーサビリティを開発計画に含めるよう求め、7.3.3が危険状態からソフトウェアアイテム、ソフトウェアの原因、リスクコントロール手段、その検証までのトレーサビリティの文書化を求めています。両者は同じトレーサビリティマトリクスで満たせます。設計開発プロセス全体の要求事項はQMSの設計開発とは？を参照してください。

設計開発に係る記録簿に何を綴じるか

QMS省令第36条の2は、製品又は類似製品グループごとに、設計開発に係る要求事項への適合を証明する記録、変更の記録、参照した資料に係る記録簿の作成と保管を求めています。施行通知45．第36条の2関係（3）は、この記録簿に含まれうるものとして「ソフトウェアの検証及びバリデーション結果」を明示しています。

IEC 62304の成果物、すなわち開発計画書、要求事項仕様、アーキテクチャ設計、トレーサビリティマトリクス、SOUP一覧、各試験の記録、既知の残留異常の一覧、問題報告と解決の記録は、そのまま記録簿の中身になります。これらがリポジトリや課題管理ツールに散在していると、適合性調査で「記録簿として提示してください」と言われた時点で行き詰まります。

開発チームの成果物を開発ツールに置いたままにせず、QMSの文書・記録管理の版管理下に置くことが必要です。どの版が承認済みで、いつ誰が改訂し、どの製品バージョンに対応するのかを、開発部門と品質保証部門が同じ台帳で追える状態にしておくと、設計変更のたびに記録簿を作り直す手間がなくなります。

よくある質問

ソフトウェア安全クラスは誰がどうやって決めるのですか？

製造業者が、JIS T 14971に基づくリスク分析の結果をもとに分類します（箇条4.3 a）。判定はソフトウェアの故障の発生確率を1とし、そのソフトウェアシステム以外（external to）で実施するリスクコントロール手段だけを考慮して行います。分類した安全クラスはリスクマネジメントファイルへの文書化が必要で（箇条4.3 c）、分類が終わるまではクラスCの要求事項が適用されます（箇条4.3 g）。

クラスAならほとんど何もしなくてよいのですか？

いいえ。クラスAでも、開発計画（5.1）、要求事項分析（5.2）、ユニットの実装（5.5.1）、システム試験（5.7）、リリース（5.8）、保守（箇条6）、構成管理（箇条8）、問題解決（箇条9）は要求されます。省略できるのはアーキテクチャの設計（5.3）、詳細設計（5.4）、結合及び結合試験（5.6）と箇条7の大部分です。SOUPの特定（8.1.2）もクラスAで要求されます。

OSSを使うと承認は通らなくなりますか？

なりません。OSSはSOUPとして扱い、規格が求める管理を実施すれば問題ありません。名称・製造業者・識別子の文書化（8.1.2）、意図する使用に必要な機能・性能要求事項の明確化（5.3.3）、必要なシステムハードウェア・ソフトウェアの明確化（5.3.4）、公開されている異常リストの評価（7.1.3）などです。管理されていないOSSが混入している状態が問題になります。

QMSで使う業務システムのバリデーションとIEC 62304は何が違うのですか？

対象物が違います。IEC 62304は医療機器そのもの、または医療機器に組み込まれたソフトウェアの開発ライフサイクルを規定する規格です。一方、文書管理システムや製造設備の制御ソフトのようにQMSの運用に使用するソフトウェアには、QMS省令第5条の6（ソフトウェアの使用）、第45条（製造工程等のバリデーション）、第53条（設備及び器具の管理）が導入時・変更時のバリデーションを求めています。詳しくはQMSのソフトウェアバリデーションとは？を参照してください。

IEC 62304は改訂される予定がありますか？

2026年8月時点で発行されていません。「2026年8月発行予定」とする情報が流通していますが、実際の進捗はそれより後ろです。2025年の委員会原案（CD1）に約1,500件のコメントが寄せられ、IEC SC62A/MT49は第2版ではなく第2次委員会原案（CD2）を出す段階にあります。FDISは2028年、発行は2029年になる可能性があり、IECが示す発行予測も2028年10月です。

議論されている主な変更は、安全クラスA・B・Cを2段階のプロセス厳格度レベル（I・II）に置き換えること、適用範囲をヘルスソフトウェア全般へ拡大すること、AI/MLライフサイクルの要求追加、レガシーソフトウェアの参考附属書化です。旧クラスAがレベルI、旧クラスB・CがレベルIIに相当するとされており、影響が最も大きいのは現在クラスBの製品です。

内容は発行まで確定せず、JIS T 2304の改正時期も未定です。当面はJIS T 2304:2017への適合を前提に整備してください。ただしクラスBの製品は、将来レベルII（現行クラスC相当）へ引き上げられる前提で詳細設計とその検証の記録を残しておくと、移行時のギャップが小さくなります。

まとめ

IEC 62304対応は、安全クラスの判定に始まり、クラスに応じたプロセスを実行し、その成果物を設計開発に係る記録簿（QMS省令第36条の2）として維持するところまでが一続きです。クラスの分類根拠、SOUP一覧、トレーサビリティマトリクスの3点が揃っていない状態は、審査や適合性調査で必ず指摘されます。

とくにSOUP一覧とトレーサビリティマトリクスは、製品のバージョンが変わるたびに版が動き、承認者と改訂履歴を伴う文書です。設計開発ファイルを電子的に管理する場合、QMS省令第8条第2項が求める文書の版管理・改訂状況の識別と、第9条第2項が求める記録の完全性の確保を同時に満たす必要があります。医療機器QMSに特化した電子QMSであるQMSmartのように、これらを標準機能として備えた基盤の上に設計開発ファイルを載せておくと、開発部門と品質保証部門が同じ版を参照したまま設計変更を回せます。

まずは自社ソフトウェアが適用対象かを切り分け、JIS T 14971に基づくリスク分析から安全クラスを分類するところに着手してください。