SaMD vs SiMD：FDAおよびEU MDRにおける医療機器としてのソフトウェア

要約

Software as a Medical Device（SaMD）は、ハードウェア医療機器の一部となることなく、医療目的を果たすソフトウェアです。Software in a Medical Device（SiMD）は、ハードウェア機器を駆動する、またはハードウェア機器に組み込まれているソフトウェアです。国際的な定義は、国際医療機器規制当局フォーラム（IMDRF）によるものです。IMDRFでは、SaMDを「ハードウェア医療機器の一部となることなく、1つまたは複数の医療目的のために使用されることを意図した、それらの目的を果たすソフトウェア」と定義しています。¹

この区別によって、ソフトウェアがどのようにクラス分類され、申請されるかが決まります。EUでは、SaMDはそれ自体で分類され、主にMDR規則11に基づいて分類されます。機器を駆動するソフトウェアは、その機器と同じクラスに分類されます。米国では、FDAが510(k)、De Novo、またはPMAを通じて機器のソフトウェア機能を認可しています。FDAのAI搭載医療機器リストはその傾向を示しています。リストに掲載されている1,614件の機器のうち、96.2%が510(k)を経て上市されました。年間認可数は、2016年の18件から2025年には335件へと増加しました。²

2026年にはいくつかの変化がありました。FDAは1月に臨床意思決定支援および一般ウェルネスに関するガイダンスを、2月にはサイバーセキュリティに関するガイダンスを改定しました。EUは、AI搭載医療機器に対するAI法の高リスク義務の適用時期を2028年8月2日に延期しました。本ガイドでは、定義をはじめ、ソフトウェアがそもそも医療機器に該当するかどうかの判断方法、FDAおよびEUにおけるクラス分類方法、申請に必要な構成要素、ならびにその他の主要市場における取り扱いについて解説します。

SaMD、SiMD、MDSW：各用語の意味

​SaMDは定義された用語です。SiMDは法的拘束力のある定義を持たない記述的な呼称です。EUでは、これら双方を網羅する第3の用語であるMDSWを使用しています。​

IMDRFはその境界を明確に示しています。「意図された使用目的がハードウェア医療機器を駆動することである場合、そのソフトウェアはSaMDの定義を満たさない。」また、「上記の定義を満たすモバイルアプリはSaMDとみなされる」とも述べています。機器ソフトウェア機能に関するFDAの2022年ポリシーでは、これらには「『Software as a Medical Device（SaMD）』および『Software in a Medical Device（SiMD）』が含まれ得る」と記載されています。³

EUでは、MDCG 2019-11 Rev.1において「スタンドアロンソフトウェア」がMDSWに置き換えられ、旧用語は「医療機器規則の文脈ではもはや使用されない」と記されています。MDRの適用規則（implementing rule）3.3では、クラス分類に関する帰結を次のように定めています。「機器を駆動するソフトウェア、または機器の使用に影響を与えるソフトウェアは、その機器と同じクラスに分類される。ソフトウェアが他のいかなる機器からも独立している場合は、それ自体で分類される。」^{4 5}

オーストラリアのTGAは、最も実践的な表現でSiMDを説明しています。そうしたソフトウェアは「通常、ハードウェア機器に事前インストールされた状態で供給」され、「SiMDはそれがインストールされている機器の一部として規制」されます。⁶

最初の問い：そのソフトウェアはそもそも医療機器に該当するのか？

​健康関連ソフトウェアの多くは医療機器に該当しません。使用目的、そして米国における5つの法定適用除外によってそれが判断されます。​

米国では、21世紀治療法（21st Century Cures Act）によって追加されたFD&C Act第520条(o)により、5種類のソフトウェア機能が医療機器の定義から除外されています：

• 管理・事務支援；
• 疾病とは無関係な、健康的なライフスタイルの維持または促進；
• 電子患者記録（当該機能がそれらを解釈または分析する場合を除く）；
• データの転送、保存、変換、または表示（当該データを解釈または分析する場合を除く）；
• 特定の臨床意思決定支援（CDS）。⁷

CDSの適用除外は、ソフトウェアが医用画像や信号（シグナル）を分析しない場合にのみ適用されます。ソフトウェアは医療情報を表示または分析し、医療従事者の推奨を支援し、かつ当該医療従事者がその根拠を独自に確認できるようにするものでなければなりません。

FDAは2026年1月に2つの主要なポリシーを改定しました：

• ​臨床意思決定支援。​ 本ガイダンスは2026年1月6日に再発行され、2026年1月29日に訂正されました。具体的な診断または治療の指示を出すソフトウェアは、第3の基準を満たしません。臨床的に適切な選択肢が1つしかなく、ソフトウェアがそれ以外の基準を満たしている場合、FDAは執行裁量を行使する方針です。医療従事者ではなく患者や介護者に推奨を提供するソフトウェアは、引き続き医療機器に該当します。⁸
• ​一般ウェルネス。​ 2026年1月6日の改定ポリシーでは、血圧、酸素飽和度、血糖値などの生理学的パラメータを推定するために「非侵襲的センシングを用いる特定の製品」について、FDAは一般ウェルネス製品と「みなす場合がある」とされています。ただし、これには条件があります。製品は非侵襲的でなければならず、FDAの認可を受けた機器の代替となるものであってはならず、かつ具体的な臨床的行動を促すような出力を提供してはなりません。⁹

EUでは、MDCG 2019-11 Rev.1において判断フローが示されています。「たとえヘルスケア環境で使用される場合であっても、一般的な目的」のソフトウェア、または「ライフスタイルおよびウェルビーイング目的」のソフトウェアは、MDR前文19に基づき医療機器には該当しません。個々の患者のために医療情報を作成または修正するソフトウェアは、通常、医療機器に該当します。2025年6月の改定では、明確に記載された使用目的、ならびに一部のモジュールのみが該当するモジュール式ソフトウェアに対する強調が追加されています。

SaMDはどのようにリスク分類されるか

​IMDRFのフレームワークは共通言語です。各規制当局はそれを独自の法的クラスへと変換しています。​

N12におけるIMDRFフレームワークは、2つの要因によってSaMDをランク付けしています。1つ目は医療状況の状態（危機的〔critical〕、重大〔serious〕、または非重大〔non-serious〕）です。2つ目は医療上の決定に対する情報の重要度（治療または診断、臨床管理の誘導、または臨床管理への情報提供）です。¹⁰

IMDRFは、これが「規制上の分類ではない」と警告しています。2025年1月、IMDRFはN81を発行しました。これは、ハードウェアの一部であるソフトウェアを含むすべての医療機器ソフトウェアを対象に、ソフトウェア特有のリスク検討事項をN12に補足するものです。¹¹

​EU MDR 規則11​は、同じ論理を法制化したものです。

「診断または治療目的の決定を下すために使用される情報を提供することを意図したソフトウェアは、クラスIIaに分類される。ただし、当該決定が以下を引き起こす可能性のある影響を及ぼす場合を除く。— 死亡または人の健康状態の不可逆的な悪化。この場合はクラスIIIに分類される。あるいは — 人の健康状態の深刻な悪化または外科的介入。この場合はクラスIIbに分類される。生理学的プロセスをモニタリングすることを意図したソフトウェアは、クラスIIaに分類される。ただし、生命に関わる生理学的パラメータのモニタリングを意図しており、当該パラメータの変動の性質上、患者に対する差し迫った危険をもたらす可能性がある場合は除き、その場合はクラスIIbに分類される。その他すべてのソフトウェアはクラスIに分類される。」

MDCG 2019-11 Rev.1には、IMDRFカテゴリをMDRクラスに対応付けた例示表が含まれています。クラスIを除くと、危機的な状況はクラスIII（治療または診断）、IIb（誘導）、およびIIa（情報提供）に対応します。重大な状況はIIb、IIa、およびIIaに対応し、非重大な状況は一貫してIIaに対応します。規則11があるため、EUにおける意思決定支援SaMDの大部分は認証機関を必要とします。欧州委員会による2025年12月のMDRおよびIVDR改正提案は、規則11をIMDRFマトリクスに沿って書き換えることを提案しています。その提案は依然として保留中であるため、現行の規則11が適用されます。¹² EUのクラス分類システムの全容については、当社のEU MDR分類ガイドをご覧ください。

​米国では​、ソフトウェアは他の機器と同様に、製品コードと分類規則に基づいて分類されます。ほとんどのSaMDはクラスIIに該当します。放射線画像処理ソフトウェア（製品コードQIH、21 CFR 892.2050）や放射線コンピュータ支援トリアージ・通知ソフトウェア（QAS、21 CFR 892.2080）がその典型です。適切なコードを特定する方法については、当社のFDA分類ガイドで解説しています。

米国市場データが示すもの

​AI搭載ソフトウェアは、FDAの医療機器認可において最も急成長している分野であり、そのほぼすべてが510(k)を経由しています。​

FDAのAI搭載医療機器リストは、2026年9月の更新時点で1,614件の登録があり、2026年6月29日までの最終決定が含まれています。そのうち1,553件（96.2%）が510(k)クリアランス、40件がDe Novo付与、21件がPMA承認でした。それらのうち1,230件（76.2%）で放射線科が主審査パネルを務め、循環器科（154件）、神経科（73件）がそれに続きました。FDAは、このリストが「AI搭載医療機器の網羅的なリソースではない」と注記しています。

もう1つの指標は、Pure GlobalによるopenFDA 510(k)エクスポートの分析から得られたものです。FDAの機器名称に「software」を含む製品コードに基づくクリアランス件数は、2016年の7件から2025年には187件へと増加し、全510(k)クリアランスに占める割合も0.2%から5.8%へと拡大しました。2025年には、その187件のうち94件が自動放射線画像処理ソフトウェア（QIH）でした。¹³ 名称に「software」を含まない製品コードに該当するソフトウェア機器も多数存在するため、この集計はSaMDを過小にカウントしています。それでも、一貫した傾向線を示しています。

FDAがSaMD申請において求めるもの

​申請経路はハードウェアと同じです。提出資料はソフトウェア特有のものであり、4つのガイダンスがその要件を形作っています。​

1. ​ソフトウェア文書レベル。​ FDAの2023年6月のガイダンスは、従来の「懸念レベル」を2つの文書レベルに置き換えました。強化文書（Enhanced Documentation）は、「機器ソフトウェア機能の不具合または欠陥によって、死亡または重傷の起こりうるリスクを伴う危険な状況が生じる可能性がある場合」に適用されます。この評価は、リスクコントロールが適用される前に行われます。それ以外の場合は基本文書（Basic Documentation）が適用されます。¹⁴
2. ​サイバーセキュリティ。​ 2023年3月29日に発効したFD&C法第524B条は、「サイバーデバイス」に適用されます。これらは、ソフトウェアを含み、インターネットに接続可能で、サイバーセキュリティ上の脅威に対して脆弱である可能性がある機器を指します。申請資料には、脆弱性監視計画、更新およびパッチ適用プロセス、ならびにソフトウェア部品表（SBOM）を含める必要があります。¹⁵ QMSRとの整合性を図るため、FDAのサイバーセキュリティガイダンスは直近では2026年2月3日に改定されました。¹⁶
3. ​事前決定変更管理計画（PCCP）。​ 第515C条により、FDAは計画された将来の変更を事前に認可することができ、その計画内で行われる変更には新たな申請が不要となります。AI搭載機器ソフトウェア機能に関するFDAのPCCPガイダンスは、2024年12月4日に最終化され、2025年8月18日に改定されました。これは510(k)、De Novo、およびPMAを対象としています。¹⁷ すべての機器を対象とした一般的なPCCPガイダンスは、2024年8月時点の草案のままとなっています。¹⁸
4. ​AIライフサイクル。​ AI搭載機器ソフトウェア機能に関するFDAの2025年1月7日付ドラフトガイダンスは、ライフサイクルおよび市販申請に関する推奨事項を定めています。これらはデータ管理、モデルの記述、性能バリデーション、バイアス、透明性、および市販後モニタリングを網羅しています。2026年10月時点でも依然としてドラフトのままです。¹⁹ また、FDAは生成AIに関するディスカッションペーパーについて、2026年10月19日を期限として意見を募集しています。²⁰

QMSRのもとでは、設計・開発（ISO 13485 箇条7.3）は、すべてのクラスIIおよびIII機器、ならびにソフトウェアによって自動化されたクラスI機器に適用されます。したがって、ソフトウェアバリデーションは市販申請だけでなく、品質システム内にも組み込まれることになります。当社の21 CFR 820からISO 13485への対照表をご覧ください。

規則11を超えるEUの要求事項

• ​臨床エビデンス。​ MDCG 2020-1は、すべてのMDSWに対して3つの要素を要求しています。妥当な臨床的関連性（科学的妥当性）、技術的または分析的性能、および臨床性能です。これらはIMDRF N41に準拠しています。²¹
• ​一般安全性・性能要件17。​ 附属書Iでは、ソフトウェアについて「開発ライフサイクルの原則、情報セキュリティを含むリスク管理、検証および妥当性確認を考慮し、最新の技術水準に従って」開発することを要求しています。
• ​AI法。​ 規則 (EU) 2024/1689は、認証機関による適合性評価を必要とする医療機器におけるAIシステムを高リスクとして扱っています。2026年7月24日にEU官報で公布されたデジタル・オムニバス（規則 (EU) 2026/1744）は、それらの義務の適用開始を2028年8月2日に延期しました。²² MDCG 2025-6は、MDRとAI法がどのように相互作用するかを説明しています。同ガイダンスは、AI法が「医療機器のリスク分類に影響を与えない」と明記しています。そこで言及されている2027年8月という日付は、オムニバス前の情報に基づいています。²³

その他の主要市場におけるSaMDの取り扱い

情報源：²⁴、²⁵、²⁶。30を超える国におけるAI特有の市場アクセスについては、弊社の医療機器としてのAI調査レポートをご覧ください。

SaMD申請資料を支える規格

• ​IEC 62304:2006+A1:2015​は、ソフトウェアライフサイクルプロセス、およびソフトウェア安全性クラスA、B、Cを規定しています。第2版は依然として委員会原案の段階であり、IECは2028年10月の発行を予測しています。2015年の統合版を前提に計画を立ててください。²⁷
• ​IEC 82304-1:2016​は、SaMDで典型的である、専用ハードウェアを持たず汎用コンピューティングプラットフォーム上で動作するヘルスソフトウェア製品を対象としています。²⁸
• ​IEC 81001-5-1:2021​は、ヘルスソフトウェアのライフサイクル全般にわたるセキュリティ活動を規定しています。²⁹
• ​ISO 14971​のリスクマネジメントおよび​IEC 62366-1​のユーザビリティエンジニアリングは、他のあらゆる医療機器と同様にSaMDにも適用されます。弊社のISO 14971ガイドではリスクファイルについて解説しています。

SaMDとSiMD：申請資料における主な相違点

よくある誤り

• ​使用目的の作成を後回しにすること。​ クラス分類、臨床エビデンス、ウェルネス機器またはCDS（臨床意思決定支援）への該当性は、すべて使用目的に基づいて決まります。最初に使用目的を起草し、マーケティング上の主張（クレーム）はその範囲内に留めてください。
• ​「意思決定支援」なら「非医療機器」と思い込むこと。​ 米国では4つのCDS基準をすべて満たす必要があります。EUでは、規則11により、ほとんどの意思決定支援ソフトウェアがクラスIIa以上に分類されます。
• ​モバイルアプリを下位区分として扱うこと。​ SaMDの定義を満たすアプリはSaMDです。
• ​従来の「懸念度（level of concern）」を引用すること。​ FDAは2023年6月にこれを基本文書（Basic Documentation）および強化文書（Enhanced Documentation）へと置き換えました。
• ​2027年のAI法適用日に向けて計画を立てること。​ AI搭載医療機器に対する高リスク義務は、現在2028年8月2日から適用されます。
• ​事前の計画なしにアルゴリズムの更新版をリリースすること。​ PCCPがない場合、重大な変更には通常、新たな申請が必要です。

Pure Globalによる支援

弊社は、ソフトウェアが医療機器に該当するかどうかを判断し、使用目的を作成します。FDA、EU MDR規則11、およびその他の制度に基づいてソフトウェアをクラス分類し、基本文書（Basic Documentation）または強化文書（Enhanced Documentation）、サイバーセキュリティ、ならびにPCCPの内容を含む510(k)およびDe Novoの申請資料を作成します。また、弊社のチームはEU認証機関への申請や、30を超える市場における登録もサポートしています。弊社のSaMD規制ページをご覧いただくか、弊社チームまでお問い合わせください。

数値の算出方法

• ​AI搭載機器：​ 2026年9月に更新されたFDAのAI搭載医療機器リスト（CSV）を弊社が集計した数値です。審査決定は2026年6月29日までを対象としており、2026年は年の一部のデータです。申請経路（パスウェイ）の割合は、申請番号のプレフィックス（K、DEN、またはP）に基づいています。
• ​名称に「ソフトウェア」を含む製品コード：​ 2026年10月12日付のFDAの製品コードファイルのうち機器名に「software」を含む製品コードを、2026年10月12日付のopenFDA 510(k)エクスポートと照合したものです。Pure Globalはこれら双方を自社のデータレイクに保持しています。集計は審査決定の暦年に基づいています。

参考文献

1. IMDRF — 医療機器としてのソフトウェア（SaMD）：主要な定義、N10、2013年12月9日。 imdrf.org ↩
2. 米国FDA — 人工知能搭載医療機器リスト。 fda.gov ↩
3. 米国FDA — 機器ソフトウェア機能およびモバイル医療アプリケーションに関する方針、2022年9月28日。 fda.gov ↩
4. 欧州委員会 — MDCG 2019-11 Rev.1、ソフトウェアの該当性判断およびクラス分類、2025年6月。 health.ec.europa.eu ↩
5. EUR-Lex — 医療機器に関する規則 (EU) 2017/745（MDR）、附属書VIII 規則11を含む。 eur-lex.europa.eu ↩
6. 豪州治療製品管理局（TGA） — ソフトウェアベースの医療機器に対する規制の理解。 tga.gov.au ↩
7. 合衆国法典 — 21 U.S.C. 360j(o)、医療機器の定義から除外されるソフトウェア機能。 govinfo.gov ↩
8. 米国FDA — 臨床意思決定支援ソフトウェア、2026年1月29日発出のガイダンス。 fda.gov ↩
9. 米国FDA — 一般ウェルネス：低リスク機器に関する方針、2026年1月6日発出のガイダンス。 fda.gov ↩
10. IMDRF — 医療機器としてのソフトウェア：リスク分類の枠組みの検討およびそれに対応する考慮事項、N12、2014年9月18日。 imdrf.org ↩
11. IMDRF — 医療機器ソフトウェアおよびソフトウェア特有のリスクの特性評価に関する考慮事項、N81、2025年1月27日。 imdrf.org ↩
12. 欧州委員会 — MDRおよびIVDRの改正提案、COM(2025) 1023、附属書、2025年12月16日。 health.ec.europa.eu ↩
13. openFDA — 医療機器510(k) APIおよび一括エクスポート、2026年10月12日付のエクスポート。 open.fda.gov ↩
14. 米国FDA — 機器ソフトウェア機能に関する市販前申請の内容、2023年6月14日発出のガイダンス。 fda.gov ↩
15. 合衆国法典 — 21 U.S.C. 360n-2、機器のサイバーセキュリティ確保（FD&C法第524B条）。 govinfo.gov ↩
16. 米国FDA — 医療機器におけるサイバーセキュリティ：品質マネジメントシステムの考慮事項および市販前申請の内容、2026年2月3日発出のガイダンス。 fda.gov ↩
17. 米国FDA — AI搭載機器ソフトウェア機能のための事前決定変更計画に関する市販申請の推奨事項、最終ガイダンス、2025年8月18日改訂。 fda.gov ↩
18. 米国FDA — 医療機器のための事前決定変更計画、ドラフトガイダンス、2024年8月22日。 fda.gov ↩
19. 米国FDA — 人工知能搭載機器ソフトウェア機能：ライフサイクルマネジメントおよび市販申請の推奨事項、ドラフトガイダンス、2025年1月7日。 fda.gov ↩
20. 米国FDA — 生成AI搭載医療機器の規制に関する考慮事項、ディスカッションペーパーおよび意見募集、2026年8月18日。 fda.gov ↩
21. 欧州委員会 — MDCG 2020-1、医療機器ソフトウェアの臨床評価、2020年3月。 health.ec.europa.eu ↩
22. EUR-Lex — 人工知能法を改正する規則 (EU) 2026/1744（AIに関するデジタルオムニバス）。 eur-lex.europa.eu ↩
23. 欧州委員会 — MDCG 2025-6、MDRおよびIVDRと人工知能法との相互関係、2025年6月。 health.ec.europa.eu ↩
24. 英国MHRA — 医療機器としてのソフトウェアおよび人工知能（AI）。 gov.uk ↩
25. カナダ保健省 — 機械学習搭載医療機器に関する市販前ガイダンス。 canada.ca ↩
26. PMDA — 医療機器としてのソフトウェア（SaMD）審査サービス。 pmda.go.jp ↩
27. IEC — IEC 62304:2006+AMD1:2015、医療機器ソフトウェアライフサイクルプロセス。 webstore.iec.ch ↩
28. IEC — IEC 82304-1:2016、ヘルスソフトウェアの製品安全。 webstore.iec.ch ↩
29. IEC — IEC 81001-5-1:2021、ヘルスソフトウェアのセキュリティライフサイクルアクティビティ。 webstore.iec.ch ↩