IEC 62304とは

IEC 62304は、医療機器ソフトウェアの安全性・信頼性を確保するために、ソフトウェアライフサイクルに必要なプロセスと要求事項を定めた国際規格です。なお「ISO 62304」と表記されることがありますが、正式名称はIEC（国際電気標準会議）が発行するIEC 62304であり、ISO 62304という規格は存在しません。

本記事では、適用範囲やJIS規格との関係、プロセス全体像、クラス分類、開発・保守で求められる具体的な要求、必要ドキュメントと進め方のポイント、そして開発を外部委託する場合の考え方までを体系的に整理します。

医療機器開発支援のお問い合わせはこちら

要求レベルの高い医療機器の開発を、ソフトウェアとハードウェアの両面からワンストップで支援

IEC 62304が求められる背景と適用範囲

医療機器の機能・性能がソフトウェアに大きく依存する中で、開発の標準化と安全性担保の枠組みとしてIEC 62304の重要性が高まっています。

医療機器ソフトウェアは、誤作動や仕様の取り違えがそのまま患者の危害につながり得ます。しかもソフトウェアは変更が容易で更新頻度も高いため、場当たり的な開発・修正では安全性を継続的に担保できません。IEC 62304は、開発と保守を「やり方」と「記録」の両面で揃え、再現性のある安全確保を実現するための共通言語になります。

適用対象は、医療機器に組み込まれたファームウェアだけでなく、PCやスマートフォンで動作する医療機器ソフトウェア、ネットワーク越しに提供されるサービス形態のソフトウェアも含み得ます。重要なのは実装形態よりも、医療目的で使用され、医療機器としての機能を担うかどうかという点です。

またIEC 62304は、単にテストを増やす規格ではありません。要件、設計、実装、検証、変更、問題対応が一本の線でつながり、リスクに基づいて重点が置かれていることが本質です。結果として、審査対応のためだけでなく、不具合の混入と市場トラブルを減らす実務的な効果も得られます。

弊社の医療機器開発支援の詳細はこちら

要求レベルの高い医療機器の企画・要件定義から製品化、市場参入までワンストップで支援

IEC 62304とJIS T 2304の関係

日本ではIEC 62304を整合規格として取り込み、JIS T 2304として発行しているため、国内対応では両者の位置づけを理解することが近道になります。

IEC 62304は国際規格で、日本国内では同等内容としてJIS T 2304が整備されています。実務では、顧客要求や審査の参照規格として「IEC 62304」または「JIS T 2304」のどちらが指定されているかを確認し、版（改訂・追補の取り込み状況）まで含めて整合させることが重要です。

混乱しやすいのは、規格番号が違っても求める考え方は同じで、違いの多くは言語・発行体系・改訂の反映タイミングにある点です。したがって「IECでやっているからJISは不要」「JISだけ見ればIECは不要」と切り分けるより、参照される版に対して不足がないかをギャップで見た方が確実です。

なお冒頭でも触れたとおり、「ISO 62304」は誤記で、正しくはIEC 62304です。ISO（国際標準化機構）は品質マネジメントのISO 13485やリスクマネジメントのISO 14971など、IEC（国際電気標準会議）はソフトウェアライフサイクルのIEC 62304や電気的安全性のIEC 60601など、医療機器の規格は発行団体ごとに役割が分かれています。

国内の申請・監査では、開発組織のプロセスが規格要求に沿って運用されていること、そしてその証跡が説明できることが問われます。規格の名称よりも、計画からテスト、変更管理までが整っているかが評価の中心になるため、JIS/IECの表記の違いに振り回されず、要求事項に対する実装状況を揃えることがポイントです。

IEC 62304の全体像：5つのプロセスグループ

IEC 62304は、開発だけでなく保守・運用を含むライフサイクル全体を複数のプロセスグループとして整理し、各プロセスに要求事項を割り当てています。

IEC 62304は、ソフトウェアを作る工程だけでなく、リリース後の変更や不具合対応までを含む「ライフサイクルプロセス」を規定します。一般に、ソフトウェア開発プロセスを中心に、保守プロセス、リスクマネジメントプロセス、構成管理プロセス、問題解決プロセスという形で全体が整理されます。

この分け方の狙いは、開発の成果物が出た時点で終わらせず、安全性を維持する活動を恒常業務として組み込むことです。医療機器ソフトウェアでは、販売後のフィールド不具合、OS更新やライブラリ更新、サイバーセキュリティ上の脆弱性対応など「変更前提」のイベントが必ず発生します。

そのため、プロセス群は互いに独立ではなく連動します。例えば、問題解決で見つかった原因は変更管理に入り、変更の影響はリスクマネジメントで評価され、必要な再検証が開発プロセスのテストに戻ります。この循環を回せるようにしておくことが、IEC 62304対応の実力になります。

ソフトウェア安全性分類（クラスA・B・C）

IEC 62304ではソフトウェアの危害の重大性に応じてクラスA/B/Cに分類し、分類結果に基づき求められる活動の厳密さや証跡レベルが変わります。3つのクラスの違いは次のとおりです。

クラス危害の重大性求められる活動の厳密さクラスA危害が起こり得ない、または無視できる最小限（開発計画、要件、構成管理、問題解決など基本的な活動）クラスB非重篤な傷害につながり得る中程度（Aに加え、アーキテクチャ設計、統合テストなどの活動と証跡）クラスC死亡または重篤な傷害につながり得る最も厳密（Bに加え、詳細設計の文書化など、全活動を最も高い粒度で実施）

分類の本質は、ソフトウェアの重要度に応じて「どこまで厳密にやるか」を合理化する点にあります。全機能を最大厳密で扱うとコストが膨らみ、逆に軽く扱うと事故リスクが上がります。クラス分類は、レビューの深さ、テストの網羅性、独立性の確保、記録の粒度などを適切に配分するための土台です。

注意したいのは、クラスはソフトウェア全体に一律ではなく、構成要素やアイテムごとに安全性への寄与を見て切り分ける発想が重要なことです。安全要求に直接関わる部分は高い厳密さで、周辺の利便機能は適切に範囲を限定して扱うことで、過不足のない適合と開発効率の両立が可能になります。

ソフトウェア開発プロセスの要求事項

開発プロセスでは、計画から要件・設計・実装・検証までを段階的に進め、各段階で成果物とレビュー・テストの整合を示すことが求められます。

IEC 62304の開発プロセスは、工程を進めること自体よりも、各工程の成果物が次工程に正しく受け渡され、検証で裏付けられていることを重視します。つまり、要件が設計に反映され、設計が実装され、テストが要件に対して実施されているという一貫性を示すことが中心です。

この一貫性を支えるのがレビュー、テスト、そしてトレーサビリティです。特に医療機器では、リスクコントロールに由来する安全要求が「どの要件に落ちているか」「どのテストで確認したか」を説明できないと、審査での説明が破綻しやすくなります。

また、クラス分類により要求される厳密さが変わるため、計画段階で活動と成果物の粒度を決めておくことが大切です。後から帳尻を合わせようとすると、設計根拠やテストの意図が不明確になり、手戻りのコストが一気に増えます。

ソフトウェア開発計画

開発計画では、何をどの範囲で作り、誰が責任を持ち、どの成果物を残すかを最初に固定します。体制・役割分担、適用範囲、成果物一覧、レビュー方針、検証戦略（どのレベルで何をテストするか）を明文化しておくと、後工程で判断がぶれません。

外部供給品（OS、ミドルウェア、OSS、外注モジュールなど）の扱いも計画に入れる必要があります。医療機器では「使っているだけ」で免責されず、バージョン固定、評価観点、受入基準、脆弱性や不具合情報の監視方法まで含めて管理する設計が現実的です。

さらに、リスクマネジメントとの連携と構成管理方針を計画に埋め込みます。安全性分類（クラスA/B/C）に応じて、レビューの独立性や証跡の粒度、静的解析の適用範囲などを事前に決め、プロジェクト都合で安全活動が削られないようにします。

ソフトウェア要件分析

要件分析では、意図する使用やユーザニーズ、上位のシステム要件との関係を踏まえて、ソフトウェアが満たすべき要求を定義します。ここで曖昧な表現を残すと、設計で解釈が分岐し、テストで合否が決められなくなるため、可能な限り検証可能な形に落とし込みます。

特に重要なのが、安全要求の明確化です。リスクコントロールで必要になった要求は、一般機能要件と同じ文書に混在させるだけでなく、由来（どの危険源・ハザードに対する制御か）をたどれるようにしておくと、変更時の影響分析が速く正確になります。

トレーサビリティはこの段階から仕込みます。要件に一意のIDを付け、設計要素、実装、テストケースへ確実にリンクできる構造にすると、後で「作ったが確認していない」「確認したが何に効くか不明」という状態を防げます。

ソフトウェアアーキテクチャと詳細設計

アーキテクチャ設計では、要件を満たすための構造を定義します。コンポーネント分割、インタフェース、データや制御の流れ、依存関係を明らかにし、どこが安全上クリティカルかを設計上の境界として表現します。

リスクコントロールの割当や分離の検討は、実装の工夫というより設計の仕事です。例えば、危険状態を検出する監視機能を別コンポーネントに分ける、フェイルセーフの経路を主経路と独立させるなど、独立性の考え方を設計に落とすことで、テスト設計も合理化できます。

詳細設計ではユニットレベルの仕様を明確にし、入力・出力、例外、境界値、タイミング条件などを定義します。ここまで具体化しておくと、ユニットテストの観点が自然に導け、後からの仕様補完による手戻りを抑えられます。

実装とユニット検証

実装では、設計どおりに作るだけでなく、欠陥混入を抑える仕組みが必要です。医療機器では「個人の注意」より「プロセスの再現性」が問われるため、コーディング規約、コードレビュー、静的解析、ビルドの自動化などを組み合わせ、品質が偶然に依存しない状態を作ります。

ユニット検証は、詳細設計やユニット要件を満たしていることを確認し、結果を記録します。単にカバレッジ数値を追うのではなく、リスクに結びつく分岐や例外処理、数値計算の境界など、故障モードに直結する観点が網羅されているかが重要です。

また、レビューや解析の指摘をどうクローズしたかも証跡になります。指摘の重篤度、対応方針、修正内容、再確認の結果が追えると、後から同種問題が出たときに再利用でき、保守コストも下がります。

統合とソフトウェアシステムテスト

統合では、コンポーネントを段階的に組み合わせ、インタフェース不整合や依存関係の問題を早期に発見します。統合順序を計画し、スタブやシミュレータの使い方を決めておくと、後半で大きな結合不具合が噴出するリスクを減らせます。

ソフトウェアシステムテストでは、ソフトウェア要件に対して最終的な検証を行います。ここで大切なのは、要件に対する合否だけでなく、安全要求の検証が十分か、想定外の使用や異常条件への振る舞いがリスクコントロールの意図どおりかを確認することです。

変更が入る前提で、回帰試験を計画的に行えるようにすることも実務上の要点です。全数再実施ではなく、影響分析に基づき再試験範囲を合理的に決められるよう、テストケースと要件・リスクの結びつきを明確にしておきます。

医療機器開発支援のお問い合わせはこちら

要求レベルの高い医療機器の開発を、ソフトウェアとハードウェアの両面からワンストップで支援

リスクマネジメント（ISO 14971）との統合

IEC 62304は単体では完結せず、ISO 14971のリスクマネジメントと結びつけて、安全要求の導出から検証までを一貫させることが実務上の要点です。

IEC 62304はソフトウェア開発のプロセス規格であり、何が危険で何を許容するかはISO 14971のリスクマネジメントで決めます。実務では、リスク分析で特定したハザードや危険状態に対し、ソフトウェアが担うリスクコントロールを要求として落とし込む流れを作ることが出発点です。

重要なのは、リスクコントロールを「実装したつもり」で終えず、検証可能な要求に変換することです。例えば、アラームを出すという方針だけでは不十分で、条件、閾値、遅延、優先度、抑制条件、ユーザー操作の誤りへの耐性などを要件化し、テストで確認できる形にします。

また、変更時に最も効くのが統合運用です。変更要求が出たら、影響分析でリスクファイルに戻り、安全要求・検証・ラベリングやユーザー文書への影響までを一度に評価します。これにより、変更が安全性の穴を開けることを防ぎ、審査時の説明も一貫します。

構成管理と変更管理

医療機器ソフトウェアでは変更が安全性に直結するため、成果物の版管理・変更影響分析・承認・リリース管理を仕組みとして運用する必要があります。

構成管理は、どの版の要件・設計・コード・テストが製品のどのリリースに対応しているかを特定できる状態を保つ活動です。医療機器では、再現性のない状態（誰かのローカル環境だけでビルドできる、どの設定で出荷したか分からない）は重大なリスクになるため、識別・保管・変更履歴・ビルド手順まで含めて管理します。

変更管理では、変更の正当性、影響範囲、必要な検証、承認、リリース判断を定型化します。特に影響分析は、機能影響だけでなくリスク影響（安全要求が崩れないか）、トレーサビリティ影響（リンクが切れないか）、既存の回帰試験範囲への影響まで含めて評価します。

運用のコツは、軽微変更でも最低限のゲートを通すことです。例外を作りすぎると現場は短期的に楽になりますが、後で製品の状態が説明できなくなります。逆に、手続きが重すぎると抜け道が増えるため、クラスや影響度に応じた手続きの階層化が現実的です。

問題解決プロセス（不具合対応・CAPA）

不具合の検知から原因分析、是正・予防（CAPA）、影響範囲の評価、再発防止、回帰試験までを定型プロセスで回し、記録として残すことが求められます。

問題解決プロセスは、不具合を単に直すのではなく、安全性と品質を守るために再発防止まで含めて扱う枠組みです。市場や評価試験での検知、一次切り分け、影響評価、原因分析、対策、検証、クローズという流れを定義し、誰がどの基準で判断するかを明確にします。

医療機器では影響評価が特に重要です。同じ不具合でも、ユーザーが検知できるか、危険状態に至るか、既存のリスクコントロールが機能するかで重大性が変わります。技術的な再現手順だけでなく、使用状況や発生頻度の仮説、既出荷品への波及を含めて評価し、必要ならフィールドアクションも検討します。

CAPAとしては、修正パッチだけで終えず、なぜ混入したか（要件の曖昧さ、設計レビュー不足、テスト観点不足、ツール設定ミスなど）を特定し、プロセス改善に落とします。この記録が蓄積すると、次の開発での予防策が具体化し、品質が組織能力として伸びます。

必要なドキュメントとトレーサビリティ

監査・審査に耐えるためには、計画・要件・設計・実装・テスト・リスク・変更・不具合対応の証跡を揃え、相互のトレーサビリティを確立することが鍵になります。

IEC 62304対応で求められるのは、立派な文書量ではなく「説明できるつながり」です。代表的には、開発計画、ソフトウェア要件、アーキテクチャ/設計、実装の識別、各レベルのテスト仕様と結果、リスクマネジメント関連の記録、構成管理・変更管理の記録、問題解決（不具合・CAPA）の記録が核になります。

トレーサビリティは、要件からテストへだけでなく、リスクコントロールから要求・設計・テストへ、さらに変更要求から影響・再検証へと双方向に追えることが重要です。これができると、審査では「この安全要求はどこで実装され、どう確認したか」を短時間で示せますし、実務では変更時の再試験範囲を根拠付きで絞れます。

運用面では、最初からツールで完全自動化を狙うより、ID設計とテンプレート、最小限のリンクルールを決めて崩れない運用を作ることが現実的です。リンクの品質を維持するために、レビューでトレーサビリティの欠落をチェック項目に入れると、後工程での穴が激減します。

IEC 62304対応を進める手順とポイント

IEC 62304対応は、現状ギャップの把握からプロセス整備、成果物テンプレート化、教育、運用定着までを段階的に進めると失敗しにくくなります。

最初に行うべきは、現状の開発・保守のやり方を可視化し、IEC 62304要求とのギャップを洗い出すことです。ここで重要なのは、文書の有無ではなく、実際に回っている活動（レビュー、承認、テスト、変更影響分析など）が要求を満たす形で再現できるかを確認することです。

次に、プロセスと成果物を最小構成で整備します。テンプレート、チェックリスト、定義済みの成果物一覧、役割と承認者のルールを用意し、クラス分類に応じた深さを最初から織り込みます。プロジェクトごとにゼロから作る運用は品質がぶれやすく、審査でも説明が難しくなります。

最後に、教育と運用定着です。医療機器ソフトウェアは、個人のスキルより組織の仕組みが問われます。小さな案件で回して不具合対応や変更管理まで含めて一周させ、記録の取り方と判断基準をチームの共通理解にします。その上で継続的に改善し、監査で指摘されにくい形に成熟させます。

開発を外部委託する場合のIEC 62304対応の考え方

医療機器ソフトウェアの開発を外部に委託する場合でも、IEC 62304への適合責任は製造販売業者（委託元）にあります。「委託先がやってくれるはず」では審査で説明が破綻するため、委託時には規格対応の役割分担を最初に設計することが不可欠です。

委託元と委託先の間で決めておくべき代表的な事項は次のとおりです。

• 成果物の分担：要件定義、設計書、テスト仕様・結果、レビュー記録のうち、どこまでを委託先が作成し、どの形式・粒度で納品するか
• トレーサビリティの接続：委託先の成果物が、委託元のリスクマネジメントファイルや上位要件とリンクできる構造になっているか（ID体系や管理ツールの整合）
• クラス分類の共有：対象ソフトウェアの安全性分類（A/B/C）を委託先に明示し、分類に応じた活動の厳密さを仕様として合意する
• 変更管理・問題解決の窓口：開発中および納品後の不具合対応・変更依頼を、どのプロセスで受け渡すか

この観点から見ると、委託先の選定基準も明確になります。単にソフトウェアが作れるだけでなく、IEC 62304が求めるプロセス（要件から検証までの一貫性、レビューと証跡、トレーサビリティの維持）を理解し、規格対応を前提とした成果物を作成できる開発パートナーであるかどうかが重要です。医療機器分野での開発経験の有無、設計書やテスト記録の作成粒度、トレーサビリティ管理の方法を、契約前に確認することをおすすめします。

医療機器開発支援のお問い合わせはこちら

要求レベルの高い医療機器の開発を、ソフトウェアとハードウェアの両面からワンストップで支援

まとめ

IEC 62304は医療機器ソフトウェアのライフサイクルを通じた安全性確保の基盤であり、クラス分類に応じた開発活動、ISO 14971との統合、変更・問題解決、ドキュメントとトレーサビリティの運用が成功の要点です。

IEC 62304は、医療機器ソフトウェアの開発から保守までを一貫したプロセスとして定義し、安全性を継続的に担保するための国際規格です。適用範囲を正しく理解し、国内ではJIS T 2304との関係や版の整合も踏まえて運用することが現実的です。

実務の中心は、クラスA/B/Cの安全性分類に基づき、要件・設計・実装・検証の厳密さと証跡の粒度を最適化することにあります。特に安全要求はISO 14971のリスクマネジメントと統合し、導出から検証までが追えるようにしておくことが不可欠です。

さらに、構成管理・変更管理と問題解決（CAPA）をライフサイクルに組み込み、必要ドキュメントとトレーサビリティを維持できれば、審査対応だけでなく品質と開発効率の両方が改善します。開発を外部委託する場合も、規格対応の役割分担とトレーサビリティの接続を設計したうえで、医療機器ソフトウェアの開発プロセスを理解したパートナーと進めることが、IEC 62304対応の近道です。

ゼネテックは、医療機器をはじめとする要求レベルの高い分野で、ハードウェアに密着した組込みソフトウェア開発を手がけてきました。測定・制御ソフトウェア、画像処理、組込みLinuxまで、医療機器の開発をワンストップでご支援します。開発体制やご依頼範囲のご相談は、お気軽にお問い合わせください。

当社の医療機器開発支援の詳細はこちら

要求レベルの高い医療機器の企画・要件定義から製品化、市場参入までワンストップで支援