医療機器の SBOM 時代：FDA「受理拒否」以後の世界

医療機器は、SBOM を上市の絶対条件に書き込んだ世界で最初の業界である。2023 年 3 月以降、FDA は連邦法に新設された 524B 条項に基づき、ネットワーク機能を持つ医療機器に「受理拒否（refuse-to-accept）」ポリシーを適用している。上市前申請に SBOM とサイバーセキュリティ文書がなければ、実質審査に入る前に差し戻される。ガイドラインでも推奨でもなく、受付窓口での強制チェック項目だ。海外展開する機器メーカーが最初にその温度を感じ、同じロジックが世界の規制当局の共通言語になりつつある。

三極の規制要求

米国 FDA：524B 条項は「サイバーデバイス」に対し、SBOM の提供、脆弱性監視・開示プロセスの運用、ライフサイクル全体のセキュリティ更新能力を要求する。上市前サイバーセキュリティガイダンスは、要求を脅威モデリング、セキュリティアーキテクチャ文書、ペネトレーションテスト証跡にまで具体化した。中国 NMPA：「医療機器サイバーセキュリティ登録審査指導原則」は登録申請時のサイバーセキュリティ記述文書の提出を求め、その中に既製ソフトウェア（オープンソースコンポーネント含む）の一覧と保守計画を含める——実質的に中国の規制文脈における SBOM 要求であり、上市後のセキュリティ更新にも明確な変更管理経路が定義されている。EU：医療機器は MDR/IVDR 体系がカバーし（それゆえ CRA から除外されるが要求は収斂している）、MDCG サイバーセキュリティガイダンスも第三者ソフトウェアコンポーネントのリスク管理を求める。

三極の共通項は明快だ。規制当局が審査するのは「オープンソースを使ったか」ではなく、「何を使い、どう継続保守しているかを明確に把握しているか」である。

医療業界固有の 3 つのジレンマ

超長期ライフサイクルと「化石コンポーネント」。画像診断装置の稼働期間は 10 年から。一方でそのソフトウェアスタック内の OS、ミドルウェア、オープンソースライブラリは稼働の途中で次々と保守を終える——レガシーシステムで動く院内機器は今も珍しくない。保守終了コンポーネントはこの業界では技術的負債ではなく、時間とともに拡大する患者安全上のエクスポージャーである。

「パッチを恐れる」ジレンマ。ソフトウェア変更は登録変更手続きを誘発しうるため、メーカーは「動かさずに済むなら動かさない」に傾く。だが規制当局の立場はすでに明確だ。通常のサイバーセキュリティパッチは再登録を要する重大変更に通常該当せず、FDA も NMPA もセキュリティ更新のための迅速な経路を残している。真のボトルネックは規制ではなく、「この脆弱性はどの型番に影響し、パッチは何を変えるのか」を迅速に判断する能力の欠如であることが多い——それこそコンポーネント台帳が解決する問題だ。

外部調達ソフトウェアの比率の高さ。機器メーカーは商用 SDK、アルゴリズムライブラリ、購買モジュールを大量に統合し、ソースコードが手に入らないのが常態である。SBOM の完全性はバイナリ成分分析で調達部分を補って初めて成立し、内製コードだけを覆う一覧は FDA の審査照会に耐えられない。

実装の要点

第一に、SBOM を登録資料のパイプラインへ。SCA プラットフォームで全ソフトウェア資産（内製＋既製＋調達バイナリ）から機械可読 SBOM（SPDX/CycloneDX）を生成し、ソフトウェアバージョンごとに自動更新して申請資料と年次報告から直接参照する——形式と深度の選択は SBOM 完全ガイドを参照。第二に、脆弱性監視プロセスを規制の期待に整合させる。新しいインテリジェンスを販売中の型番に自動照合し、「影響型番一覧＋リスク評価＋処置計画」の三点セットを出力する——これが FDA の脆弱性管理審査が求める証跡の形である。第三に、「既製ソフトウェア保守計画」を実体化する。NMPA の保守計画はテンプレート文書ではない。審査のトレンドは計画と実際のバージョン状態の一致確認であり、台帳と計画の乖離は頻出の指摘事項だ。

医療機器業界は数十年をかけて品質システムで物理的リスクを管理する術を学んだ。規制当局はいま、同じ体系化の要求をソフトウェアサプライチェーンに複製している。SBOM は入場券にすぎない。その先で審査されるのは、ソフトウェアリスクを継続的に管理する組織能力である。