株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
IEC 62304とは:医療機器ソフトウェアライフサイクルの国際標準
IEC 62304 は、医療機器ソフトウェア(SaMD、embedded software、製造支援ソフトウェア)のライフサイクル全体に要求事項を定める国際標準です。国際電気標準会議(IEC)と ISO の共同制定で、現行版は IEC 62304:2006+AMD1:2015。ソフトウェアの安全性を確保するため、開発・検証・保守・廃止の各段階で実施すべき活動を体系化しています。
FDA は認定コンセンサス標準として採用、EU は EU MDR 2017/745 の整合規格として EN 62304 を Official Journal 掲載。日本は JIS T 2304:2017 として同等採用、中国は YY/T 0664-2020 として等同採用し NMPA 審査の前提規格となっています。AI/ML 医療機器、サイバーセキュリティ、Software as a Medical Device(SaMD)、クラウド医療ソフトウェアの普及により、IEC 62304 への適合は今や医療機器業界の必須リテラシーです。
本記事では、IEC 62304 の対象範囲、安全クラス A/B/C、ソフトウェア開発プロセス、保守・構成管理・リスクマネジメント・問題解決の 5 活動、2015 年改訂の主要変更、SaMD・AI/ML 機器での適用、ISO 14971・IEC 62366-1・ISO/IEC 81001-5-1 との統合、多地域整合を体系的に解説します。
IEC 62304の適用対象
以下のすべてのソフトウェアが適用対象です。
- 独立した医療機器として機能するソフトウェア(Software as a Medical Device, SaMD)
- 医療機器の組込み部品(Embedded Software)
- 医療機器の製造・管理に使用するソフトウェア(Manufacturing Software)
- 医療機器が依存する IT インフラの一部
一方、以下は対象外:
- ソフトウェア開発ツール(コンパイラ、IDE、バージョン管理)
- ヘルスケア IT 情報システム単体(EMR・PACS 等、医療機器分類されない範囲)
安全クラス(Safety Classification)A / B / C
IEC 62304 の中核概念は、ソフトウェアの失敗が患者に及ぼす影響の深刻度で 3 段階に分類することです。
| クラス | 定義 | 要求プロセスの厳格さ | 典型例 |
|---|---|---|---|
| Class A | 傷害や健康被害の可能性なし | 軽度 | 情報参照のみのデータベースソフトウェア |
| Class B | 非重篤な傷害の可能性あり | 中程度 | 血圧モニターソフトウェア |
| Class C | 死亡または重篤な傷害の可能性あり | 最も厳格 | 除細動器制御、放射線治療計画、AI 癌診断 |
ソフトウェアアイテム単位での分類
IEC 62304 はソフトウェア全体ではなく、ソフトウェアアイテム(software item)単位で安全クラスを決定します。これにより:
- リスクの低い部分は Class A/B で効率的に開発
- 重大リスクを担う部分のみ Class C で厳格対応
- Segregation(分離)により下位クラスのアイテムを分離管理
Segregation(分離)の概念
2015 年改訂で重要視された論点。低い安全クラスのアイテムが高い安全クラスのアイテムに影響を与えないよう分離する要件。重要なのは:
- 物理的分離だけでなく論理的分離でも受容可能
- 独立性の根拠を文書化(メモリ保護、権限管理、プロセス分離等)
- Segregation の有効性を検証
IEC 62304 の 5 主要プロセス
プロセス1:ソフトウェア開発プロセス(Clause 5)
- ソフトウェア開発計画(Software Development Plan)
- ソフトウェア要求分析(Software Requirements Analysis)
- ソフトウェアアーキテクチャ設計(Software Architectural Design)
- ソフトウェア詳細設計(Software Detailed Design) - Class B/C のみ
- ソフトウェアユニット実装(Software Unit Implementation)
- ソフトウェアユニット検証(Software Unit Verification) - Class B/C のみ
- ソフトウェア統合(Software Integration)と統合試験(Integration Testing)
- ソフトウェアシステム試験(Software System Testing)
- ソフトウェアリリース(Software Release)
プロセス2:ソフトウェア保守プロセス(Clause 6)
- 保守計画の策定
- 問題・修正分析
- 修正の実装(Problem Report、Modification、Verification)
- 保守リリース
プロセス3:ソフトウェアリスクマネジメントプロセス(Clause 7)
ISO 14971 と連携し、ソフトウェア固有のハザードを分析:
- ソフトウェア障害によるハザードの分析
- リスクコントロール措置の実装
- 残存リスクの評価
- 変更時のリスク影響分析
- SOUP(Software of Unknown Provenance)のリスク評価
プロセス4:ソフトウェア構成管理プロセス(Clause 8)
- 構成アイテムの識別
- 変更管理(Change Control)
- 構成ステータスの記録
- ビルド管理・リリース管理
プロセス5:ソフトウェア問題解決プロセス(Clause 9)
- 問題レポートの受付・記録
- 根本原因分析(Root Cause Analysis)
- 修正の計画と実装
- 検証と影響分析
- CAPA(Corrective Action Preventive Action)連携
SOUP(Software of Unknown Provenance)
SOUP はサードパーティソフトウェア(商用ライブラリ、OSS、OS、COTS 等)で、製造業者が完全には開発履歴を把握していないソフトウェアです。IEC 62304 では:
- SOUP の機能・性能要件を文書化
- 安全なシステムレベル性能の決定
- SOUP のハードウェア・ソフトウェア要件の確認
- 既知の異常(bug tracker レビュー)の評価
- SOUP 検証記録の維持
昨今の OSS 依存増加・SBOM(Software Bill of Materials)要件と密接に関連します。FDA の Premarket Cybersecurity 2025-06-27 以降新ガイダンスも SBOM の提出を要求しており、SOUP 管理と SBOM は統合的に運用する必要があります。
2015 年 Amendment 1 の主要変更
- Legacy Software(既存ソフト)の取扱い:IEC 62304 公布前の既存ソフトの適合化手順を明示
- Segregation(分離)の柔軟化:物理分離だけでなく論理分離を認容
- リスクベース検証:リスクに応じた試験量の調整
- 保守プロセスとリスクマネジメントの連携強化
- SOUP 評価の深化
AI/ML 医療機器への適用
AI/ML 医療機器では IEC 62304 に以下の特殊考慮が必要です:
- 訓練データ・検証データ・テストデータの管理(データ構成管理)
- モデル学習アルゴリズム自体の SOUP 的取扱い(PyTorch、TensorFlow 等)
- モデル性能評価(感度・特異度・AUC)の検証
- モデルドリフト監視と再学習時の再検証
- 継続学習(Continuous Learning)対応の PCCP 連動
- 説明可能性(Explainability)の実装
- Good Machine Learning Practice(GMLP)10 原則との整合
FDA 2024 年 12 月 3 日付 AI PCCP 最終ガイダンスと IEC 62304 を組み合わせた運用が、2026 年の AI 医療機器開発の必須要素となっています。
サイバーセキュリティ:ISO/IEC 81001-5-1 との統合
IEC 62304 本体はサイバーセキュリティを直接扱いませんが、2021 年発行の ISO/IEC 81001-5-1(Health software and health IT systems safety, effectiveness and security - Part 5-1: Security for product life cycle activities)が、IEC 62304 のライフサイクルにセキュリティ要求事項を重ねて統合する規格として位置づけられています。
FDA は premarket cybersecurity 要件(2023 年以降強化、2025 年改訂)で、製造業者に以下を要求:
- Secure Product Development Framework(SPDF)
- Threat Modeling(STRIDE 等)
- SBOM 提出
- 脆弱性管理計画
- セキュリティテスト結果
- ラベリングでのセキュリティ情報
IEC 62366-1:ユーザビリティとの連携
医療機器のソフトウェア UI は IEC 62366-1(ユーザビリティエンジニアリング)とも連動し、Use Error・Use-related Risk の評価をライフサイクル全体で実施。AI/ML 機器では「AI 結果の表示方法」「誤判定時の人間介入」「ユーザー教育」などが Use-related Risk の重点領域となります。
多地域整合
FDA(米国)
- IEC 62304 を認定コンセンサス標準として採用
- FDA ソフトウェア文書レベル(Basic / Enhanced、2023 年以降 Documentation Level と呼称)との対応
- 510(k)・De Novo・PMA 申請で IEC 62304 への適合宣言が事実上必須
- 21 CFR Part 820(2026-02-02 以降 QMSR)の Design Control と統合運用
EU(EU MDR 2017/745)
- EN 62304 を整合規格として Official Journal 掲載
- MDR General Safety and Performance Requirements(GSPR)の要件を満たす前提規格
- Notified Body 監査での必須確認項目
- MDCG ガイダンス(MDCG 2019-16 Cybersecurity、MDCG 2020-1 Software Qualification 等)との連携
日本(PMDA)
- JIS T 2304:2017 が IEC 62304:2006+AMD1:2015 の同等採用
- PMDA QMS 適合性調査で JIS T 2304 への適合を確認
- プログラム医療機器(SaMD)の承認審査で前提規格
中国(NMPA)
- YY/T 0664-2020 が IEC 62304 を等同採用(2008 年版から 2020 年版へ更新)
- NMPA 審査で YY/T 0664 への適合とネットワークセキュリティテストが要求
- 2026 年 NMPA 医療機器ネットワーク・データ安全管理通則との連動
Design Controls(21 CFR 820.30)との統合
FDA の Design Controls は以下の要素:
- Design Input
- Design Output
- Design Review
- Design Verification
- Design Validation
- Design Transfer
- Design Changes
- Design History File(DHF)
IEC 62304 のソフトウェア開発プロセスは、Design Controls のソフトウェア領域実装と見なされ、トレーサビリティマトリクス(Software Requirements → Architecture → Detailed Design → Code → Test)を通じて DHF 内に統合されます。
IEC 62304 実装でよくある落とし穴
落とし穴1:安全クラス判定の甘さ
「重篤な傷害はないだろう」と判断して Class A/B に分類した結果、監査で Class C 相当と指摘される事例が頻発。リスクコントロール措置がない場合の危害で判定する点に注意が必要です。
落とし穴2:SOUP 管理の不十分
OSS・商用ライブラリ・OS を「単に使っているだけ」と記録せず放置すると、監査時に SOUP 評価記録が求められて手戻り。早期の SBOM 整備と継続管理が必要です。
落とし穴3:トレーサビリティ不備
要求 → 設計 → 実装 → テストのトレーサビリティが切れると、Design Controls・QMS・IEC 62304 のすべてで不適合。ALM(Application Lifecycle Management)ツールの導入が有効です。
落とし穴4:AI/ML 機器の継続学習対応
モデル再学習時の安全クラス再評価・検証・リリースプロセスを IEC 62304 のフレームワークで設計しないと、PCCP 運用と整合しません。
落とし穴5:サイバーセキュリティの後付け
ISO/IEC 81001-5-1・FDA サイバーガイダンスを開発の後半で統合すると大幅な手戻り。Secure by Design として開発初期から組み込む必要があります。
AI活用による IEC 62304 対応効率化
- 安全クラス判定支援:ソフトウェアアイテムの機能・影響範囲からリスクベースで安全クラスを提案
- トレーサビリティ生成:要求・設計・実装・テスト文書間の関係を自動抽出してマトリクス化
- SOUP 分析:依存関係ファイルから SOUP 候補を自動同定、既知脆弱性・ライセンスをチェック
- SBOM 自動生成:ビルドアーティファクトから SPDX/CycloneDX 形式の SBOM 出力
- テストケース生成:要求仕様から境界値・異常系テストケースを自動提案
- 変更影響分析:コード変更がソフトウェア全体・安全性に及ぼす影響を解析
- 監査レビュー支援:IEC 62304 各条項への適合性を自動点検しギャップリスト化
よくある誤解
誤解1:IEC 62304 は大規模医療機器向けのみ
誤りです。単純な SaMD(スマートフォンアプリ等)でも適用対象で、安全クラスに応じた柔軟な運用が可能です。
誤解2:Agile 開発は IEC 62304 と相容れない
誤りです。2019 年以降、AAMI TIR45 ガイダンス(Guidance on the use of AGILE practices in the development of medical device software)で Agile 実践と IEC 62304 の両立が整理されました。
誤解3:Class A は文書化不要
誤りです。Class A でも計画・要求・リリース記録・問題解決・構成管理・リスクマネジメントが必要です。必要な活動がクラス B/C より軽減されるだけで、ゼロにはなりません。
誤解4:IEC 62304 と ISO 14971 は独立
誤りです。IEC 62304 第 7 章はソフトウェアリスクマネジメントを扱い、ISO 14971 の枠組み下で運用することが前提です。ソフトウェア固有ハザードを機器全体のリスクマネジメントファイル(RMF)に統合します。
まとめ
IEC 62304 は医療機器ソフトウェアライフサイクルの国際標準であり、SaMD・embedded software・製造支援ソフトウェアのすべてに適用されます。安全クラス A/B/C の段階的厳格化、5 主要プロセス(開発・保守・リスク・構成・問題解決)、SOUP 管理、2015 年改訂の Segregation 柔軟化が主要構成要素です。
2024-2026 年は AI/ML 医療機器の継続学習対応、サイバーセキュリティ ISO/IEC 81001-5-1 との統合、SBOM 必須化、FDA PCCP との連動、CSA(Computer Software Assurance)GAMP 5 Second Edition との整合が主要論点。FDA・EU MDR・PMDA・NMPA のすべてが IEC 62304 を前提規格としており、医療機器ソフトウェア開発企業は ISO 14971・IEC 62366-1・ISO/IEC 81001-5-1・AAMI TIR45・FDA Design Controls との統合運用を求められます。
AI 活用は安全クラス判定・トレーサビリティ・SOUP/SBOM 管理・テストケース生成・変更影響分析に有望で、ALM ツールと組み合わせた自動化が IEC 62304 対応の効率化と品質向上を両立します。医療機器メーカーは、Agile 実践と IEC 62304 の両立、早期からのセキュア設計、AI/ML 特殊リスクの体系的管理を通じて、グローバル市場での競争力を確保することが重要です。