日本の規制当局が見ている「次の論点」─医療機器サイバーセキュリティの本当の課題 第1回（前編）─

執筆者：酒井 由夫　Medical Software Consulting（MSC）

はじめに：「規制対応」から「規制戦略」へ

前シリーズ（Lean-QMS連載）では、
IEC 62304・ISO 14971・変更管理など、
医療機器ソフトウェア開発の基盤となるプロセスと品質管理の実装を扱いました。

今シリーズでは、視点を大きく変えます。
テーマは「規制対応」から「規制戦略」への転換です。

医療機器サイバーセキュリティの規制は、現在、世界的に急速に強化されています。

日本では基本要件基準第12条第3項、
米国ではFDA Omnibus法Section 524B、
EUではMDR/サイバーレジリエンス法が並走しています。

しかし重要なのは、
「法律が要求しているから対応する」という後追い型の発想では、
今後の競争環境では通用しなくなるということです。

第1回は、その出発点として、
「今、規制当局が医療機器メーカーに本当に求めていること」
を具体的に提示します。

基本要件基準第12条第3項の実質的な意味、
監査現場で見られ始めている論点、
そして既存メーカーが抱える構造的弱点
――この3つの視点を軸に説明します。

1. 基本要件基準第12条第3項の「実質的意味」

1-1 条文は何を求めているのか

医療機器の基本要件基準¹ 第12条第3項は、
ネットワーク接続などの外部インターフェースを持つ医療機器に対し、
サイバーセキュリティ上のリスクを許容可能なレベルに低減するための措置を講じることを実質的に求めています。

条文の読み方として、多くのメーカーが陥りやすい誤解があります。

「市販前にセキュリティ対策を詳述していれば良い」
という理解です。

しかし実際に規制当局が要求しているのはそれではありません。

この4つの問いに「はい」と答えられる体制を求めているのが、
基本要件基準第12条第3項の本質です。

準拠は市販前申請のやり取りだけでなく、
市販後も継続的に製品安全性を維持する能力があるか否か、
ということです。

1-2 「アップデートできる」ことと「アップデートする」ことの根本的な違い

規制当局が問題にしているのは、技術的なアップデート能力の有無だけではありません。

「アップデートを届けるかどうかの判断を、誰が、どんな根拠で、どのようなプロセスで行うか」です。

具体的には、
ISO 14971のリスクマネジメントの枠組みに基づき、
新たな脆弱性が製品にとって好ましくない状況の変化に当たるかどうかを評価し、
その結果に応じた対応の判断と実行が組織的に行われていること。

これが規制当局の求める
「市販後のサイバーセキュリティライフサイクル管理」の核心です。

そしてその判断と実行の前提条件となるのが、
「自社製品のソフトウェア構成を常時適切に把握していること」です。

ここに、SBOM（ソフトウェア部品表）の整備が話題になる理由があります。
SBOMは次回以降で詳しく扱いますが、最小限、
「自社製品に何のアプリケーションやライブラリが入っているか」を適切に管理する文化とプロセスが整っていなければ、
第12条第3項への実質的な対応は完結しないということです。

2. 監査で見られ始めている論点

2-1 「どう作ったか」から「なぜそう作ったか」へ

市販前申請や監査の現場で、
サイバーセキュリティ関連の指摘はここ数年で質を変えています。

以前は「セキュリティ対策の有無」が問われていましたが、
今は「その対策の根拠とプロセス」が問われるようになっています。

たとえば、以下は監査・書面審査で実際に用いられる問いかけの底流にある論点です。

これらは「セキュリティ一変」が必要かどうか、という問題ではありません。
「脆弱性対応が組織的プロセスとして機能しているか」という問題です。

単に文書があるかどうかではなく、実際にそのプロセスが回っているかどうかが見られています。

2-2 「レガシー医療機器」への視線が厳しくなっている

IMDRF（国際医療機器規制当局フォーラム）が2023年に発行した
N70ガイダンス（レガシー医療機器の原則・実践）は、
日本の規制対応にも少なからぬ影響を与えています。

そこで定義される「レガシー医療機器」とは、
販売開始からの年数の問題ではなく、
「現在のサイバーセキュリティの脅威に対してアップデートまたは補完的対策等の合理的な手段で保護できない」機器です。

この定義に照らすと、最新製品であっても、
設計思想やアーキテクチャの問題からアップデートが実質的に困難な製品はレガシーに分類され得るということになります。

規制当局は、新旧製品かどうかにかかわらず、
市販中の全製品についてこの視点での確認を求めはじめています。

これらの問いかけに共通するのは、
「市販後にも規制当局に説明できる体制があるか」という視点です。
市販前申請だけを見ていた時代は終わりました。

2-3 2026年度の動き：日本版SBOMガイドラインのパブコメ化

この文脈で、今タイムリーな動きがあります。
2026年5月、厚生労働省の令和7年度医療機器サイバーセキュリティ推進事業が産出した「医療機器におけるSBOM導入・運用ガイドライン（第1版）」がパブリックコメントに付されました。

規制当局が
「ソフトウェア構成要素の把握や更新履歴の管理が十分とは言えないメーカーが多い」と明示している点、
さらに医療現場から
「インシデント発生時にどの製品が影響を受けるか迅速に知りたい」という強い要請がある点が、
このガイドラインの制定背景として明記されています。

第2回以降でSBOMの具体的な実装論に入りますが、第1回の時点で重要なのはこの事実が示すメッセージです。
「規制当局は、市販後のソフトウェア構成管理能力を、今までの監査項目に正式に加えようとしている」
ということです。

後編はこちらから

《著者プロフィール》酒井 由夫｜Medical Software Consulting（MSC）

IEC 62304・ISO 14971・IEC 81001-5-1・FDAサイバーセキュリティ規制・SaMD規制を専門とする医療機器ソフトウェア規制コンサルタント。日本のスタートアップから大手医療機器メーカー、海外展開を目指す企業まで、規制対応と製品戦略の統合支援を行う。

🔗 詳細プロフィール・個別相談をご希望の方は：
👉 酒井さんのコンサルティング会社サイトはこちら

医療機器ソフトウェア開発でお困りの方へ

「自社の開発体制、このままで本当に大丈夫だろうか？」
「海外規制も見据えた設計・文書化ができているか不安…」
そんな医療機器スタートアップ・開発チームの皆さまへ。
xCAREでは、実務経験豊富なエキスパートが並走し、後悔しない開発体制づくりを支援しています。
まずはお気軽に、現在の課題や懸念をお聞かせください。
👉 xCAREへのご相談はこちら（無料個別相談あり）

脚注

1. 平成17年厚生労働省告示第122号