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分）

参照情報

• 【FDA公式】Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions（2025年6月改訂版）
• 【FDA公式】Content of Premarket Submissions for Device Software Functions
• 【IMDRF】Principles and Practices for Medical Device Cybersecurity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ざっとこんな感じだ。