第1回でSBOMとは何かを、第2回で規制上の位置づけを整理しました。最終回となる今回は、実際に手を動かす段階で必ず出てくる、より実務的な疑問に答えます。
SBOMは機微な情報。機密は守られるのか
結論から言うと、SBOMは無条件に外部へ出してよい情報ではありません。SBOMには、社内でのみ通用してきたプロジェクト名やバージョン表記、使用しているOSSライブラリの詳細な構成が含まれます。これがそのまま外部に渡ると、次のようなリスクがあります。
- 社内プロジェクト名など、本来社外に出す想定のなかった情報が意図せず開示される
- 攻撃者にとって、狙うべき脆弱性の「地図」を渡すことになりかねない
そのため実務では、開示レベルを分けるという考え方が基本になります。社内向けにはすべての情報を保持しつつ、取引先向けには抜粋・加工した版を用意し、規制当局向けには全量を用意する——というように、渡す相手に応じて出す情報の粒度を変える設計です。生成ツールがそのまま吐き出したSBOMを、確認・加工せずに外部へ渡すことは避けるべきです。
SBOMをExcelで提出するのはダメなのか
禁止されているわけではありませんが、実務上は破綻しやすい方法です。理由は主に3つあります。第一に、日本のガイドラインも米国のFDAガイダンスも、機械可読フォーマット(SPDX・CycloneDX)を前提にした運用を求めています。第二に、コンポーネント数が数百〜数千に及ぶ製品では、Excelでの手作業更新は現実的な運用コストを超えます。第三に、推移的依存関係(部品の部品)まで含めると、表計算ソフトでの一覧管理そのものが構造的に難しくなります。ごく小規模な製品や、SBOM整備の初期段階であれば、Excelから始めること自体は問題ありません。ただし、それを最終形として運用し続けることは推奨できません。
LinuxやWindowsのSBOMはどうやって作るのか
OS自体のSBOMを作る場合、多くのツールはOSのパッケージ管理システム(Linuxであればdpkgやrpmなど)から情報を抽出する方式を取ります。オープンソースのSBOM生成ツールがこうした抽出を自動化しており、比較的整った形でSBOMを得られます。Windowsについては、パッケージ管理の仕組みがLinuxほど統一されていないこともあり、ツールによってカバーできる範囲に差があるのが実情です。「これを使えば万全」という決定版のツールがあるわけではなく、対象とする製品の構成に応じてツールを選び、生成結果を確認する工程が必要になります(この確認工程の必要性は第1回・第2回で触れたとおりです)。
OTSのSBOMを供給元に提出を求めたら出してもらえるのか
「求めれば必ず出てくる」というものではありません。供給元がSBOMを整備しているか、契約上の力関係、相手の対応体制によって結果は変わります。取引の力関係が強い大口顧客であれば出てくる可能性は高まりますが、そうでない場合は難航することもあります。
供給元からSBOMが得られない場合の代替策としては、自社側で解析ツールを使って構成を推定する、あるいは「不明な部品が存在する」ことをKnown Unknowns(未特定コンポーネント)として明示するという方法があります。SBOMは完全である必要はなく、「わからない部分をわからないと正直に書く」ことも、正しい運用の一部です。
供給元からSBOMが得られない場合の代替策としては、自社側で解析ツールを使って構成を推定する、あるいは「不明な部品が存在する」ことをKnown Unknowns(未特定コンポーネント)として明示するという方法があります。SBOMは完全である必要はなく、「わからない部分をわからないと正直に書く」ことも、正しい運用の一部です。
ビルドごとに自動生成できるのか
技術的には可能です。CI/CD(継続的インテグレーション・継続的デリバリー)のパイプラインにSBOM生成ツールを組み込み、ビルドのたびに自動的にSBOMを出力する構成は、すでに多くの開発現場で実践されています。
ただし、ここで重要な注意点があります。「自動生成すれば、その内容が正しい」わけではありません。生成ツールには検出漏れ・誤検出・バージョン情報の誤りが一定の確率で発生します。自動生成はあくまで「たたき台を効率的に作る」工程であり、その後に人の目による確認・補正のプロセスを挟むことが、医療機器ソフトウェアの品質保証の観点からは求められます。自動化は工程を減らす道具であって、確認工程そのものを不要にする道具ではない、という理解が大切です。
ただし、ここで重要な注意点があります。「自動生成すれば、その内容が正しい」わけではありません。生成ツールには検出漏れ・誤検出・バージョン情報の誤りが一定の確率で発生します。自動生成はあくまで「たたき台を効率的に作る」工程であり、その後に人の目による確認・補正のプロセスを挟むことが、医療機器ソフトウェアの品質保証の観点からは求められます。自動化は工程を減らす道具であって、確認工程そのものを不要にする道具ではない、という理解が大切です。
注意:本記事の内容は2026年9月時点の一般的な整理であり、個別の製品・案件に対する助言ではありません。実際の運用設計にあたっては、対象製品の特性や契約関係を踏まえた個別の検討をお願いします。
おわりに
全3回を通じて、SBOMの基本的な考え方から、規制上の位置づけ、そして実務上の疑問までを整理してきました。SBOMは一度作って終わりのものではなく、製品のライフサイクルを通じて継続的に更新・確認していく性質のものです。本シリーズが、その第一歩を踏み出す際の一助になれば幸いです。
SBOM解説シリーズ(全3回)
本記事は一般的な情報提供を目的としたものであり、個別の製品・案件に対する法的助言ではありません。規制上の判断が必要な場合は、該当するガイドライン原文および所轄当局への確認をお願いします。