医療機器ソフトウェア開発に関する規制要件について

医療機器ソフトウェアの開発に「規制要件」が存在するのか、という問いは、2026年8月現在すでに過去のものである。日本では基本要件基準第12条第2項により、平成29年11月25日以降に製造販売されるプログラムを用いた医療機器はJIS T 2304への適合が求められ、令和5年からは第12条第3項によりサイバーセキュリティも要件に加わった。本稿では、医療機器ソフトウェア開発に課される規制要件を、日本・米国それぞれについて根拠通知レベルまで下ろして整理する。

1．なぜソフトウェアが規制の焦点になったか

医療機器の回収・不具合において、設計に起因するものの比率は高く、そのうちソフトウェアの欠陥が占める割合はさらに高い。ハードウェアの不具合が個体に留まりやすいのに対し、ソフトウェアの欠陥は同一バージョンを搭載した全出荷品に同時に現れる。この「欠陥が水平展開する」という性質が、当局がソフトウェアのライフサイクルプロセスそのものを規制対象に据えた理由である。

加えて、プログラム単体が医療機器となったこと（2014年11月25日の薬機法施行）により、物理的な製造工程を持たない事業者が製造販売業者・製造業者になるケースが生まれた。設計プロセスの妥当性以外に品質を担保する手段がない以上、プロセス規格への適合が事実上唯一の入口となる。

2．日本の規制要件 ― 基本要件基準第12条

旧来の解説記事では「医薬品医療機器等法第12条第2項」と書かれていることがあるが、これは誤りである。根拠は法律の条文ではなく、基本要件基準（平成17年3月29日厚生労働省告示第122号）第12条第2項である。

第2項について通知は、JIS T 2304のほかに国際的に用いられている適切な規格等がある場合は、それらへの適合性の確認をもって代えて差し支えないとしている。ただしその場合、承認申請または認証申請に際して当該規格を用いることの妥当性を説明することが求められる。IEC 62304の英語版で運用している企業は、この説明を申請資料に用意しておく必要がある。

3．IEC 62304 / JIS T 2304 が要求していること
IEC 62304の現行版はIEC 62304:2006+AMD1:2015（第1.1版）であり、国内版はJIS T 2304:2017である。第2版の開発は進行しているが、2026年8月時点で適用すべきは第1.1版である。

この規格は特定のソフトウェア開発方法論を要求していない。ウォーターフォールでもアジャイルでも、規格が定めるプロセス・アクティビティ・タスクをライフサイクルモデルに割り付けられていればよい。要求されているのは方法論ではなく、プロセスの存在と、その実施記録である。

3-1．ソフトウェア安全クラス

IEC 62304 / JIS T 2304 のもっとも特徴的な要素は、ソフトウェアシステムを安全性の観点でクラスA・B・Cに分類し、クラスに応じて実施すべきアクティビティの範囲を変える点である。クラスが上がるほど、アーキテクチャ設計・詳細設計・ユニット検証まで要求が及ぶ。逆に言えば、分類を誤ると必要な設計文書が丸ごと欠落する。

4．米国の規制要件

米国側の文書は、2023年から2026年にかけて大きく入れ替わっている。古い記事に載っているガイダンス名やURLはほぼ失効しているため、そのまま社内資料に転記しないよう注意が必要である。

なお「ISO 13485認証を取得しているのでFDA査察は免除される」という理解は誤りである。FDAは適合証明書を発行せず、認証書の提出も求めていない。QMSRがISO 13485:2016を参照取り込みしたことは、査察が不要になることを意味しない。

5．ソフトウェア開発を取り巻く周辺規格

リスクマネジメントについては、JIS T 14971:2020で「誤使用」が「使用エラー」に改められ、「合理的に予見可能な誤使用」の定義が新設されている。ソフトウェアのリスク分析でFMEAを用いること自体は差し支えないが、FMEAは単一故障の影響を追う手法であり、ユーザーインタフェースに起因する使用エラーや、複数条件の組合せで顕在化するソフトウェア固有の危険状態を拾いきれない。ハザード分析やフォールトツリー解析と組み合わせる設計が実務的である。

6．2026年時点で取るべき対応