2025-07-11

FDA公開「AI 搭載医療機器リスト」最新アップデートを読み解く

FDA公開「AI 搭載医療機器リスト」最新アップデートを読み解く― 2025年7月版 ―

1️⃣ はじめに｜なぜ “いま” このリストなのか

米FDAの 「Artificial Intelligence-Enabled Medical Devices List」 は、AIを組み込んだ医療機器（SaMD／医療機器ソフトウェアを含む）の承認・認可済み製品を一括把握できる公的データベース です。開発企業・臨床現場・投資家が同じテーブルで議論できる “共通言語” を提供するという点で、極めて重要なリソースになっています。U.S. Food and Drug Administration

2️⃣ 2025年5月30日更新：リストはついに1,000件超え

最新エントリー日時：2025年5月30日付の複数機器（Aidoc BriefCase-Triage ほか）が追加。U.S. Food and Drug Administration
件数の急増：2024年8月時点で903件だった登録数が、2025年6月には1,000件を突破。わずか10ヵ月で+100件以上と、成長曲線はなお加速中です。ラップスSTAT

ポイント
放射線科系が依然トップシェアですが、心血管・眼科・生殖医療や病理分野などへも裾野が拡大。いまや「AI = 画像診断専用」という常識は過去のものになりつつあります。

3️⃣ FDAが強調する “AI 搭載医療機器リストの使い方”

リストの機能	実務への応用ヒント
CSV/Excel 形式でダウンロード可	市場分析や競合調査に活用。社内BIツールへ取り込み、デバイス種別・企業国籍・審査ルート（510(k)／De Novo／PMA）別トレンドを可視化すると示唆が得やすい。U.S. Food and Drug Administration
各機器の決定概要へ直リンク	“何が評価され、どこまで詳細を開示しているか” を逆算し、自社の PCCP（事前定義変更計画）設計や営業資料のエビデンス強化に利用。
AI関連用語ベースの抽出	公開サマリーに AIモデル構造／学習データ概要／バージョン管理などを明示すると、FDAが次回更新でタグ付けしやすくなる → 透明性＝PR効果に直結。

2025-07-05

FDAサイバーセキュリティガイダンス2025年6月改訂版解説

速報 FDAサイバーセキュリティガイダンス2025年6月改訂版

医療機器サイバーセキュリティ：品質システムの考慮事項と市販前申請の内容

概要

FDAは2025年6月、医療機器サイバーセキュリティガイダンス「Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions」の改訂版を発行しました。2023年版（最終化ガイダンス）からの主な変更点として、AI/ML搭載デバイス向け要件の拡充、SBOMの詳細化、サプライチェーンリスク管理の強化などが挙げられます。

主な変更点

✅AI/ML搭載デバイス向け要件を拡充

AI/MLを活用する医療機器ソフトウェアにおけるサイバーリスクへの対応について、AIモデルや学習データ管理の脆弱性も含めたリスク評価が必須となりました。脅威モデリングでもAI特有の攻撃シナリオ（例：モデル逆流攻撃）を考慮することが明記されています。

✅SBOMにAIモデル情報の追加を義務化

SBOM（ソフトウェア部品表）に、デバイスに搭載するAIモデルや外部AIライブラリの以下の情報を含めるよう更新されました：

バージョン
トレーニングデータ概要
ベンダー情報

✅ソフトウェア・サプライチェーンリスク管理の詳細化

サプライチェーンリスク管理を強化し、第三者ソフトウェアやクラウドサービスの脆弱性対応計画を脆弱性管理計画に組み込むことが必須化されました。

✅脆弱性開示・対応スケジュールの具体化

脆弱性発見から公表、パッチ提供までのタイムライン目安（例：重大度Criticalなら60日以内）を設定するよう推奨され、管理計画に明記することが求められるようになりました。

✅多拠点連携を想定したマルチペイシェントハーム評価

複数施設に配備される機器を想定し、同時多発的に複数患者へ影響を及ぼすリスクへの設計対応を明記するよう更新されました。

✅規格参照の更新

FDAが推奨するセキュリティ関連規格リストに以下が追加されました：

IEC 81001-5-1:2024（医療機器ソフトウェアのセキュリティライフサイクル規格最新改訂版）
ANSI/AAMI SW96（SBOM標準化仕様）

✅人材・体制強化を推奨

設計・リスク管理に携わる組織に対して、サイバーセキュリティ専任者配置やトレーニング実施をガイダンス上で推奨されました。

まとめ

2023年版ガイダンスから2年を経て、AI/MLの台頭とサプライチェーン脅威の深刻化を反映した内容に進化しました。医療機器メーカーは、AI・クラウドを活用したソフトウェアの脆弱性管理を含め、開発初期から詳細な文書化・体制整備を徹底する必要があります。

Medical Software Consulting では Youtube公式チャネルにて、2023年版のガイダンスの解説動画は下記にて解説していますので、今回の改定内容と合わせてご覧下さい。

✅FDA 医療機器サイバーセキュリティガイダンス(2023年版）解説（10分）

なお、本ガイダンスでも AI/ML を考慮した内容が追加されています。FDAの医療機器AI系ガイダンスについても解説動画をご覧下さい。

✅FDA AI医療機器ライフサイクルガイダンス（12分）

✅FDA PCCPガイダンス（AI医療機器向け変更計画の戦略的活用）（11分）

参照情報

2025-07-04

医療機器ソフトウェアのリファクタリング

『医療機器ソフトウェアのリファクタリング』という動画を作った。

この動画を作成するにあたっては、第8回組込みシステム開発技術展（ESEC）　2005年6月29日～7月1日専門セミナーで『高信頼性を確保するソフトウェア開発手法と実践』という講演をしたときのスライドを使った。

20年前に作ったスライドだが、このときのスライドが今でも使えるということは、ソフトウェア開発の世界はそんなに進化していないのかもしれない。

この動画を作ったきっかけは、医療機器ソフトウェア（SaMD）を新規に開発しようとするスタートアップ企業は、まず、フィージビリティスタディとしてソフトウェアを作ってしまい、いざ、薬機法申請するために規制要件である IEC 62304（医療機器ソフトウェアーソフトウェアライフサイクルプロセス）に適合しようとするという話しを聞いたからである。

IEC 62304 は、リスクベースアプローチなので、そのものが不具合を起こしたときに患者危害に至るようなソフトウェアモジュールはリスクレベルが高い（ソフトウェア安全クラスC）とし、もっとも厳しいアクティビティ、タスクを課す。

だから、ソフトウェアのアーキテクチャを設計する際に、リスクが高いモジュールとリスクが低いモジュールを分離しておかないといけない。リスクが高いモジュールとは、多くの場合、診断や治療を担うソフトウェアモジュールのこととなる。診断や治療を担うソフトウェアが期待通りに働かないと、誤診したり、意図しない出力を患者に与えたりするからだ。

また、例えば、意図しない出力を出していないかどうかを判定するリスクコントロール手段としてのソフトウェアや、セルフチェック機能が誤動作して、医療機器の機能が使えなくなるような場合のソフトウェアもソフトウェア安全クラスはBやCとなる。

だから、医療機器ソフトウェアを開発するときは、フィージビリティスタディ（要素技術開発やコンセプト開発）のフェーズでも、リスクの高いモジュールは、リスクの低いモジュールと分離して、高凝集、疎結合にしておかないといけないのだが、医療機器できるかどうか、臨床的に効果が見込めるかどうか分からない段階では、まず、どんなものでもいいから、動くソフトウェアが欲しくて、医療機器ソフトウェアの開発経験が無い、IEC 62304 の規格要求も知らないソフトウェアハウスに、とりあえずソフトウェアを作ってもらってしまう。

実際、臨床効果が見込めなければ、資金調達も難しいだろうし、最初から完璧な規格適合ができるようなリソースも用意できない状況では、取りあえず動くソフトウェアを作るというアプローチを取るのも仕方がないだろう。

しかし、臨床的にも「これはいける」となって、資金も調達できる見込みが立ったときに、CEOはソフトウェアを作り直すという決断はしないだろう。おそらく、動いているんだから、試作レベルで作ったソフトウェアをそのまま製品にしろ、テストでバグが見つかったら修正すればよいと考えるはずだ。

でも、そんな考えでは、IEC 62304 の規格には適合できないし、そもそも、市場に出したときに患者危害に至るような障害が発生する危険性が高まる。本当に障害が発生すれば、リコールになって膨大な回収費用を被ることになる。1回も痛い目にあっていない経営者には、その痛みは分からないかもしれない。

リコールのコストもさることながら、患者危害に至れば、国民の安全を守ることはできないから、各国の規制当局は医療機器ソフトウェアの市販前申請の際に、キチンと規格に適合しているかどうかをチェックする。

ソフトウェアは中身が見えないから、チェックするレビューワーの技量にもよってしまうが、まともにアーキテクチャ図が描けていないような場合は、米国FDAなら、まず、申請は通らない。

じゃあ、どうすればよいかを解説したのが今回の動画になる。

ソフトウェアの詳細な技法のことを説明してもピンとこないと思ったので、紙芝居風にしてイメージを掴んでもらうことにした。

ざっとこんな感じだ。