SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説

SBOM（Software Bill of Materials／ソフトウェア部品表）は、あるソフトウェアがどんな部品（OSSやサードパーティ製ライブラリ）で組み立てられているかを、名称・バージョン・供給元・ライセンス・依存関係まで機械可読な形で一覧化した構成表です。製造業の部品表（BOM）をソフトウェアに持ち込んだもので、脆弱性が公表されたときに「自社製品のどこに、どの版が入っているか」を即座に照合できる状態を作ることが目的です。この記事では、SBOMに記録する項目、SPDX・CycloneDX・SWIDという標準フォーマットの違い、SCAツールによる生成の実務、CVEデータベースと突き合わせる脆弱性管理の運用、そして「作って終わり」にせず運用に載せるための内製と委託の判断基準までを、導入を検討する技術選定者の視点で整理します。

まとめ：SBOMは部品表の作成より継続運用と契約設計で価値が決まる

SBOMの本質は、生成そのものではなく「変わり続けるソフトウェアに追従して更新し、脆弱性やライセンスの問題に結びつける運用」にあります。一度きりのスナップショットを作っても、依存ライブラリは日々更新され、新しい脆弱性は毎日公表されます。ビルドのたびにSBOMを自動生成し、脆弱性データベースと突き合わせ、影響範囲を即座に洗い出す。この循環を回せて初めて、Log4Shellのような緊急事案で「どの製品のどこを直すか」を数時間で答えられます。

経済産業省は2023年7月にSBOM導入の手引ver1.0を、2024年8月にver2.0を公表し、後者では委託先との契約で規定すべき事項（要求内容・責任分界・コスト負担）まで踏み込みました。受託開発では、納品物にSBOMを添えるだけでなく、納品後もSBOMを更新し続ける運用を誰が担うかが論点になります。継続生成と脆弱性追従の体制が自社に無い段階では、保守運用・内製化支援のように監視と運用自動化の基盤づくりから外部の手を借りる選択が現実的です。以下、定義から運用判断まで順に解説します。

SBOM（ソフトウェア部品表）の定義と記録される主要な構成項目

まず言葉の輪郭を押さえます。SBOMが表現するのは「完成したソフトウェアの成分表示」です。自作したコードそのものではなく、その中に取り込まれた外部部品の素性を一覧化する点に主眼があります。

SBOMの定義と部品表に記録する主要項目（名称・版・供給元・依存関係）

SBOMは、ソフトウェアを構成するコンポーネントの一覧と、それぞれの識別情報・依存関係を機械可読形式で記述したものです。米国のNTIAが示した最低限の記載項目を土台に、実務では次の項目を含めて扱います。

• コンポーネント名と供給元（サプライヤ）：どの組織が提供した部品か
• バージョン：脆弱性の影響有無を分ける最重要の識別子
• 一意識別子：CPEやPURLなど、部品を機械的に照合するためのID
• 依存関係：どの部品がどの部品を内部で呼んでいるか（推移的依存を含む）
• ライセンス情報とハッシュ値、SBOM自体の作成者・作成日時

とりわけバージョンと依存関係の精度が運用の質を決めます。直接依存だけでなく、ライブラリがさらに内部で読み込む「推移的依存」まで捉えられないと、Log4jのように深い階層に潜む部品を取りこぼします。SBOMが手作業では回らないと言われるのは、この推移的依存が数百〜数千件に膨らむためです。

SBOMが求められる背景：OSS依存の拡大とサプライチェーン攻撃

現在のソフトウェアは、コード量の大半をOSSやサードパーティ部品が占めます。自社が書いた行より、取り込んだ部品の行のほうが桁違いに多い。この構造が、部品の脆弱性を経由して製品全体が侵害される「ソフトウェアサプライチェーン攻撃」の温床になりました。2021年末のLog4Shell（Apache Log4jの脆弱性）では、多くの組織が「自社のどの製品にLog4jが入っているか」を即答できず、調査だけで数週間を溶かしています。

SBOMは、この「どこに何が入っているか分からない」状態を解消するための土台です。米国では2021年の大統領令で政府調達ソフトへのSBOM提出が方向づけられ、日本でも経済産業省が手引を整備しました。規制対応というより、脆弱性対応の初動を速くするための実務基盤として位置づけると理解が進みます。

SBOMの標準フォーマット（SPDX・CycloneDX・SWID）の違いと選び方

SBOMは自由記述のメモではなく、機械が読める標準フォーマットで作ってこそ意味を持ちます。ツール間で受け渡すには規格の統一が前提になるためです。主要な標準は3つあり、成り立ちと得意分野が異なります。

SPDX・CycloneDX・SWIDタグの特徴と目的別の使い分け

3規格は競合というより出自が違います。用途で選ぶのが実務的で、どれか1つに寄せる必要はありません。生成ツールが対応するフォーマットに合わせるのが最も摩擦が少ない選び方です。

実務の目安はシンプルです。脆弱性管理を主目的にするならOWASP発のCycloneDXが扱いやすく、ライセンス順守やOSSガバナンスまで含めて包括的に管理するならSPDXが向きます。SWIDタグは資産管理側の識別規格で、単独でSBOMを組むより既存の資産管理と接続する場面で登場します。迷ったら、使うSCAツールが標準対応する形式に合わせれば問題ありません。

SBOMの作成方法とSCAツールによるビルド時の自動生成の実務

SBOMは、いつ・どうやって作るかで精度が大きく変わります。理想はビルドの一部として自動生成し、成果物と同じ鮮度でSBOMを揃えることです。ここを手作業に頼ると、更新が止まり形骸化します。

手動での作成とSCAツール自動生成のコスト・精度・網羅性の違い

小規模なライブラリなら手動でも部品表は書けます。ただし推移的依存まで正確に追い、版が変わるたびに更新する作業は現実的ではありません。実務では、依存関係を解析して自動でSBOMを吐き出すSCA（Software Composition Analysis）ツールを使います。SyftやTrivyといったOSSツール、あるいは商用のSCA製品が候補です。

自動生成でも万能ではない点は押さえておきます。パッケージマネージャの管理下にない部品（手動で配置したバイナリ、静的リンクされたライブラリ）では検出漏れが起きる点に注意が必要です。SBOMは「生成方法によって網羅範囲が変わる」ものだと理解し、ソースコード段階・ビルド段階・成果物段階のどこで作ったかを記録しておくと、後から精度を評価できます。

ビルド・CI/CDパイプラインへのSBOM生成の組み込みと実装例

SBOMを鮮度良く保つ勘所は、CI/CDパイプラインに生成ステップを組み込むことです。ビルドが走るたびにSBOMを自動生成し、成果物と一緒に保存すれば、リリースごとの部品表が自動で蓄積されます。手動更新を前提にすると、必ずどこかで止まります。

クラウド環境では、この仕組みをマネージドサービスで肩代わりできます。たとえばAWSでは、コンテナイメージやLambda関数をスキャンしてSBOMを出力する機能があり、その具体的な機能と出力の扱いはAmazon Inspector SBOM Exportの主要な機能と特長で解説しています。自前でTrivyやSyftをCIに組み込む方式と、マネージドサービスに寄せる方式のどちらが合うかは、既存の開発基盤しだいです。

SBOMを使った脆弱性管理とライセンス管理の実際の運用の流れ

SBOMは作った時点では、ただの部品リストです。価値が出るのは、そのリストを脆弱性データベースやライセンス規約と突き合わせ、対応すべき対象を浮かび上がらせる運用に載せたときです。ここが導入の成否を分けます。

SBOMとCVE・脆弱性DBの突合による脆弱性の検知とVEXの役割

SBOMに記録した各部品のバージョンを、CVE（共通脆弱性識別子）やNVDなどの脆弱性データベースと機械的に照合すると、「自社製品に影響する既知の脆弱性」が自動で洗い出せます。新たな脆弱性が公表されるたびに全製品を手で調べる作業が、SBOMがあれば照合クエリ1回に置き換わります。この突合の考え方は、露出を継続的に洗い出すCTEM（継続的脅威エクスポージャー管理）の枠組みのDiscovery段階と地続きです。

ただし、SBOMが「その部品を含む」ことと「その脆弱性の影響を実際に受ける」ことは別です。呼び出していない関数の脆弱性なら実害が無い場合もあります。この差を埋めるのがVEX（Vulnerability Exploitability eXchange）で、検出された脆弱性が「影響あり／調査中／対策済み／影響なし」のどれかを供給側が表明する仕組みです。SBOMで機械的に拾い、VEXで実際の影響有無を絞り込む。この二段構えが誤検知への現実的な対処になります。

ライセンス違反とサプライチェーンリスクの可視化と是正判断の基準

SBOMはセキュリティだけの道具ではありません。各部品のライセンスを一覧化すれば、GPLのようなコピーレフト条項の混入や、商用配布と両立しないライセンスの取り込みを早期に検知できます。ライセンス違反は、発覚が製品出荷後になるほど是正コストが跳ね上がります。

是正の判断軸は「事業への影響の大きさ」で置くのが実務的です。外部に配布する製品に含まれる問題は優先度が高く、社内限定の内部ツールなら許容範囲が広がります。SBOMで問題を一覧化したうえで、配布形態・契約条件・代替部品の有無を掛け合わせて優先順位を付ける。全件を同じ緊急度で扱おうとすると、対応が回りません。外部診断を組み合わせて是正の妥当性を確かめる進め方は、脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準の観点と併せて検討すると整理できます。

SBOMを「作って終わり」にしない運用体制と委託契約での判断

ここは製品ベンダーの解説が手薄になりがちな論点です。SBOMは生成ツールを入れれば完成、ではありません。回し続ける運用と、外部委託時の契約設計が本体で、ここを詰めないとSBOMは棚に置かれた古い部品表になります。玉虫色を避け、条件を切って結論を示します。

SBOM運用を内製で回せる企業の条件と、外部委託を選ぶべき場面

内製でSBOM運用を回せるのは、次を満たす組織です。CI/CDパイプラインが整備され自動生成を差し込める、脆弱性情報を継続的に監視する担当が置ける、そして検知した脆弱性を修正まで運ぶ変更管理のフローが既にある。この3つ、とくに最後の「直すところまで運ぶ体制」が欠けていると、SBOMで脆弱性を見つけても放置され、リストだけが積み上がります。

逆に、外部委託や支援を選ぶべき場面もはっきりしています。開発を外部に委託していて自社に生成基盤が無い、担当が兼任1名で脆弱性の常時監視まで手が回らない、といった段階でフルスコープのSBOM運用を掲げるのは過剰です。この状態でまず要るのは、継続生成と監視の土台づくりで、SBOMという看板より前に自動化された運用基盤が来ます。継続監視と運用自動化の立ち上げは、保守運用・内製化支援のように監視・運用自動化・内製化を支援する外部の手を組み合わせて始める選択が現実的です。委託開発では、経済産業省の手引ver2.0が契約で規定すべきとした「SBOMの要求内容・責任分界・コスト負担」を発注時に明文化しておくと、納品後の更新責任が曖昧になる事態を避けられます。

スモールスタート：単一プロダクトの継続生成から始める運用の広げ方

SBOM導入を全社プロジェクトとして構えると、対象範囲の合意だけで時間を溶かします。現実的な入り方は逆で、外部に配布している主力プロダクトを1つだけ選び、そのビルドにSBOM自動生成を組み込んで「毎回更新される部品表」を先に作ることです。

1製品でCI連携・脆弱性突合・是正フローを1周させ、運用の型を作ってから次の製品へ横展開する。最初から全プロダクト網羅を狙わない、この一点が形骸化を避ける最大のコツです。範囲を絞れば、限られた人員でも循環を体験でき、経営や顧客への説明材料も揃います。経産省の手引ver2.0が導入妥当範囲を検討するフレームワークを載せたのも、全部を一度に対象化しない前提に立っているからです。

SBOM導入でよくある質問：義務化・作成コスト・運用体制への疑問

SBOMの導入検討でよく挙がる疑問に、実務の観点から簡潔に答えます。

SBOMは日本で義務化されているのですか？

2026年7月時点で、民間全般に一律で義務づける法律はありません。ただし経済産業省が2023年7月に手引ver1.0、2024年8月にver2.0を公表し、政府調達や医療機器などの分野では実質的な要求が進んでいます。米国では政府調達ソフトへの提出が方向づけられており、海外向けに製品を出す企業は取引先からの要求に備える意味で、早めの整備が現実的です。

SBOMは手作業でも作成できますか？

小規模なソフトウェアなら手作業でも作れますが、推移的依存まで正確に追い、版が変わるたびに更新する運用は現実的ではありません。実務ではSyftやTrivyといったSCAツールでビルド時に自動生成するのが定石です。手作業は初回の把握には使えても、鮮度を保つ継続運用には向きません。

SBOMを導入すれば脆弱性は自動で防げますか？

防げません。SBOMは「どこに何が入っているか」を可視化する台帳で、脆弱性を検知しやすくする土台にすぎません。実際の防御は、検知した脆弱性を修正まで運ぶ変更管理や、VEXで実害を絞り込む判断とセットで初めて機能します。SBOM単体は地図であって、対処そのものではありません。

SBOMとCTEMや脆弱性診断はどう使い分けるのですか？

役割が異なります。SBOMは部品構成の台帳、脆弱性診断はある時点の露出を深く調べる手段、CTEMはそれらを継続的に回す枠組みです。SBOMはCTEMのDiscovery（資産・露出の発見）を支えるデータ源にあたり、診断結果と組み合わせて脆弱性管理の全体像を作ります。競合ではなく、階層の違う道具立てです。

どのフォーマットで作れば取引先とやり取りしやすいですか？

脆弱性管理が主目的ならCycloneDX、ライセンス管理まで含めるならSPDXが扱いやすい形式です。取引先が特定フォーマットを指定する場合はそれに合わせ、指定が無ければ使うSCAツールが標準対応する形式で問題ありません。多くのツールは複数フォーマットへの変換に対応しています。

関連記事

• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：SBOMをデータ源とする継続的な脅威エクスポージャー管理の全体像を解説しています。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：SBOMで検知した脆弱性を実地で検証する外部診断の選び方・費用感を整理しています。
• Amazon Inspector SBOM Exportの主要な機能と特長：AWS環境でSBOMを自動生成・出力するマネージドサービスの実装例を扱っています。
• ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説：ソフトウェアサプライチェーンの信頼を前提にしない、露出を減らす側の設計思想を解説しています。