「SBOMと脆弱性対応 ― SaMD時代の保守運用 ― SBOM作成・更新／PSIRT体制／脆弱性情報のモニタリングと報告」 医療機器ソフトウェア開発 スタートアップのための“後悔しない”実践ガイド第7回
はじめに 「医療機器ソフトウェアは、出荷した瞬間から“運用フェーズ”に入る」
医療機器ソフトウェア、とりわけSaMDは、出荷した時点で完成する製品ではありません。
OS
OSS（オープンソースソフトウェア）
ミドルウェア
ライブラリ
これらは市販後も更新され、
脆弱性は必ず“後から”見つかります。
第6回では、「安全性」と「セキュリティ」を分けて考える重要性を整理しました。
第7回ではさらに一歩踏み込み、
市販後に発生する脆弱性に、どう備え、どう対応するか
そのための実務的な考え方を解説します。
１．なぜ今、SBOMが重視されているのか
近年、医療機器分野で
SBOM（Software Bill of Materials）が強く注目されています。
SBOMとは、
「この製品は、どのソフトウェア部品で構成されているか」
を示す部品表です。
重要なのは、
SBOMが「新しい規制文書」だからではありません。
規制当局や医療機関が本当に知りたいのは
脆弱性が見つかったとき、
どの製品に
どのバージョンで
影響があるのか
を、合理的に説明できるかどうかです。
※SBOMの例（Visual C++, Visual Studio, Windows, Microsoftはマイクロソフトグループ企業の商標です。Adobe, AcrobatはAdobeの登録商標です。その他、各社の商標が含まれている場合があります。）
２．SBOMは「作ること」自体が目的ではない
SBOMという言葉が独り歩きすると、
「専用ツールが必要」
「完璧な形式で作らなければならない」
と考えがちです。
しかし実務の本質は、そこではありません。
SBOMとは本来、
・OS
・OSS
・ライブラリ
・そのバージョン
といった構成情報を日常的に把握・管理している結果として自然に整理されるものです。
言い換えると、
ソフトウェアの構成管理ができていれば、
SBOMは“あとから作れる”
SBOMは単体で価値を持つのではなく、
構成管理という土台があって初めて意味を持ちます。
３．ソフトウェアは必ず変わる
― だから「構成」を管理しなければならない
ソフトウェア開発では、
不具合修正・仕様変更・機能改善
が必ず発生します。
特にプログラムは、
変更頻度が最も高く
同時に影響範囲も最も大きい構成要素です。
そのため、
①どの時点の構成か
②その構成は、どのテストを通過しているか
を明確に特定できなければ、
市販後の対応は成立しません。
４．不具合・脆弱性は「構成をさかのぼって」判断する
市販後に問題が発覚した場合、対応の考え方は共通しています。
不具合の場合
不具合を含む構成要素を特定する
その誤りが
いつ
どのバージョンから作り込まれたかを追跡する
該当する製品・リリースを洗い出す
脆弱性の場合
例：暗号ライブラリに脆弱性が発覚
影響を受けるバージョン範囲を確認
SBOMと構成管理情報を突き合わせる
該当製品・該当リリースを特定する
ここで重要なことは、
SBOMだけでは足りない、
構成管理があって初めて“影響評価”ができる
という点です。
５．PSIRT体制は「最小構成」でも成立する
脆弱性対応というと、
大規模な PSIRT（Product Security Incident Response Team）を
想像するかもしれません。
しかしスタートアップに必要なのは、
大きな組織ではなく、明確な役割分担です。
最低限、次の点を決めておく必要があります。
脆弱性情報をどこから収集するか
誰が影響評価を行うか
判断結果をどう記録するか
医療機関・規制当局へどう説明するか
この体制があって初めて、
SBOMと構成管理情報は実際に機能する道具になります。
６．「報告」とは、脆弱性の有無を伝えることではない
市販後対応で求められるのは、
脆弱性があったかどうかではありません。
重要なのは、
・影響範囲をどう評価したか
・リスクをどう判断したか
・どの対応方針を選んだか
という判断のプロセスです。
「何が起きたか」より
「どう考え、どう決めたか」
これを説明できるかどうかが、
市販後対応の品質を左右します。
まとめ 「SBOMは“保守運用の入口”にすぎない」
SBOMは構成管理の結果である
構成管理があるから影響評価ができる
影響評価ができるから適切な判断ができる
SaMD時代の品質とは、
「安全に作ったか」だけではなく
「問題が起きたときに、どう対応できるか」
で評価される時代に入っています。
次回予告
第8回 「一変申請・改訂対応 “規制を味方にする”アップデート計画」
第7回では、SBOMと構成管理を軸に、市販後の脆弱性対応の考え方を整理しました。
次回 第8回では、その先に多くの開発チームが直面するテーマ、「変更」と「規制対応」に焦点を当てます。
脆弱性対応や不具合修正は、どこから「一変申請」になるのか
軽微変更や改訂で対応できるケースとは何か
なぜ「変更が怖い」状態に陥るのか
SBOMや構成管理は、一変判断にどうつながるのか
規制に縛られるのではなく、規制を味方につけてアップデートを進めるための考え方を解説します。
執筆・監修：酒井 由夫（Medical Software Consulting / xCAREエキスパート）
医療機器ソフトウェア開発コンサルタント／xCAREエキスパート
医療機器メーカーでのソフトウェア開発、規格対応支援経験を経て、外資系企業・医療スタートアップにて医療機器ソフトウェア（SaMD）の製品企画・規制対応・QMS運用の支援をはじめる。クラスII・III機器の開発～市販後に関するISO 13485、IEC 62304、ISO 14971、FDA対応、薬機法承認申請などの支援を専門とする。現在は医療機器ソフトウェア専門のコンサルタントとして独立し、国内外のスタートアップ・製販企業に対して、開発プロセス設計やチーム育成、技術文書の作成支援など、実行支援を提供中。
🔗 詳細プロフィール・個別相談をご希望の方は：
👉 酒井さんのコンサルティング会社サイトはこちら
医療機器ソフトウェア開発でお困りの方へ
「自社の開発体制、このままで本当に大丈夫だろうか？」
「海外規制も見据えた設計・文書化ができているか不安…」
そんな医療機器スタートアップ・開発チームの皆さまへ。
xCAREでは、実務経験豊富なエキスパートが並走し、後悔しない開発体制づくりを支援しています。
まずはお気軽に、現在の課題や懸念をお聞かせください。
👉 xCAREへのご相談はこちら（無料個別相談あり）
