SBOMとは？意味・メリット・作り方と経済産業省の手引き、SPDXとCycloneDXの違いを解説

📖 読了時間：約11分

SBOMとは、ソフトウェアを構成する部品（コンポーネント）を一覧にした「ソフトウェアの部品構成表」のことです。Software Bill of Materials の略で「エスボム」と読みます。どの部品を誰が作り、どのバージョンが含まれ、どのような構成になっているかを示します。

今のソフトウェアの多くは、オープンソースのライブラリなど多くの部品を組み合わせて作られています。SBOMがあれば、ある部品に脆弱性が見つかったとき、自社のどのソフトウェアに影響があるかをすぐに調べられます。経済産業省も手引きを公表し、企業での活用を進めています。

以下では、SBOMの意味、メリット、記載する項目、SPDXとCycloneDXの違い、導入の流れ、脆弱性対応での使い方、よくある誤解の順に解説します。

この記事を読めば、SBOMの基本と、自社で導入するときの進め方が分かります。まずは無料でスキルログに登録し、これまでに担当したソフトウェアの管理やセキュリティの仕事を案件ごとに記録しておきましょう。

経済産業省の手引きでは、SBOMを「ソフトウェアの部品構成表」とし、ソフトウェアを構成する各部品を誰が作り、何が含まれ、どのような構成になっているかなどを示すものと説明しています。製造業で使われる部品表（BOM）の考え方を、ソフトウェアに当てはめたものです。

注目されている理由

ソフトウェアの部品の調達先が複雑になり、オープンソースの利用が当たり前になる中で、自社のソフトウェアに何が入っているかを把握しにくくなっています。IPAの「情報セキュリティ10大脅威 2026」（組織編）でも、「サプライチェーンや委託先を狙った攻撃」が2位、「システムの脆弱性を悪用した攻撃」が4位に挙げられており、部品の把握はその両方の備えになります。

分野	主なメリット（経済産業省の手引きより）
脆弱性管理	脆弱性が残るリスクの低減、対応にかかる期間の短縮、管理にかかるコストの低減
ライセンス管理	ライセンス違反のリスクの低減、管理にかかるコストの低減
開発生産性	開発の遅れの防止、開発のコストの低減、開発期間の短縮

脆弱性が見つかったときに差が出る

ある部品に脆弱性が公表されたとき、SBOMがなければ、どの製品にその部品が使われているかを一つずつ調べる必要があります。SBOMがあれば、部品の名前とバージョンで検索するだけで、影響のある製品を絞り込めます。

米国商務省の電気通信情報局（NTIA）が2021年7月に示した最小要素では、次の7つの項目が挙げられました。

項目	内容
サプライヤー名	その部品を作った個人や組織
コンポーネント名	部品の名前
バージョン	部品のバージョン
その他の一意の識別子	部品を特定するための識別子
依存関係	どの部品がどの部品に含まれているか
SBOMの作成者	SBOMのデータを作った者
タイムスタンプ	SBOMのデータを作った日時

2026年に米国で改訂版が公表された

米国CISAは2026年7月29日に、2021年の最小要素をもとにした改訂版を公表しました。部品のハッシュ値のアルゴリズム、ライセンス、SBOMを作ったツールの名前、作成時の状況などが新たに加わっています。海外の取引先とやり取りする場合は、最新の要件を確かめましょう。

観点	SPDX	CycloneDX
生まれ	Linux Foundationが運営するオープンソースのプロジェクト	OWASP（Webアプリのセキュリティのコミュニティ）
標準化	ISO/IEC 5962:2021として国際標準に	ECMA-424としてEcma Internationalの標準に
特徴	ライセンスを守るための取り組みから生まれ、現在はセキュリティの情報も扱う	サプライチェーンのサイバーリスクを減らすことを目的に設計された

どちらを選ぶかは取引先と用途で決める

SBOMを作るツールには、両方の形式に対応したものも多くあります。取引先から形式を指定されている場合はそれに合わせ、指定がなければ、ライセンス管理を重視するか、脆弱性管理を重視するかで選ぶとよいでしょう。

フェーズ	主な実施事項
1. 環境構築・体制整備	SBOMを適用する範囲の明確化、ツールの選定・導入・設定、ツールに関する学習
2. SBOM作成・共有	コンポーネントの解析、SBOMの作成、SBOMの共有
3. SBOM運用・管理	SBOMにもとづく脆弱性管理・ライセンス管理などの実施、SBOM情報の管理

ver2.0で追加された内容

経済産業省は2023年7月28日に手引きのver1.0を、2024年8月29日にver2.0を公表しました。ver2.0では、SBOMを脆弱性管理に生かす具体的な手順と考え方、導入の効果とコストから導入範囲を検討する「SBOM対応モデル」、委託先との契約で決めておくべき事項を示した「SBOM取引モデル」が加わっています。

SBOMの導入や運用に関わった経験は、取り組んだ範囲を具体的に示せる、経歴の中で伝えやすい強みになります。スキルログに案件として記録しておくと、担当した範囲や工夫を後から説明できます。

• 脆弱性情報の部品名とバージョンを、自社のSBOMで検索する
• 該当する製品と、その製品を使っている顧客や部署を洗い出す
• 深刻度と悪用の状況を確かめ、対応の優先順位を決める
• 修正版への更新や回避策を実施し、SBOMを新しい構成に更新する

脆弱性対応の全体の流れは脆弱性対応の進め方で、深刻度の見方はCVSSとは？スコアの見方と深刻度の目安で解説しています。

SBOMはよく誤解される

SBOMを作るだけで脆弱性がなくなるわけではありません。SBOMは「何が入っているか」を把握するための道具で、脆弱性の情報と照らし合わせ、更新を続けて初めて役に立ちます。経済産業省の手引きも、SBOMに関する誤解と事実を整理しています。

SBOMやセキュリティの経験をスキルログで残す理由

SBOMの導入や脆弱性の管理は、取り組んだ範囲や工夫が人によって大きく違う仕事です。ExcelやWordで経歴を書き足していくと、どの製品を対象に、何をどこまで担当したかが抜けやすくなります。スキルログで記録すると、次の点で楽になります。

• 項目がそろう：案件ごとに期間・役割・プロジェクト規模・チーム規模・業種・担当工程・成果を同じ項目で入力するので、書き漏れがなく、案件どうしを比べやすい
• 体裁を整える手間がない：入力した内容はPDF出力で体裁の整ったスキルシートになり、新しい案件を足したらそのまま出し直せる
• 伸びたスキルが見える：スキルごとにS・A・Bなどの自己評価と経験年数を並べて確認でき、次に伸ばすところが分かる

登録した経歴をもとに、セキュリティや開発の経験で狙える求人や案件、年収や単価の目安を転職・案件相談で一緒に確かめることもできます。

SBOMとは、ソフトウェアを構成する部品を誰が作り、どのバージョンが含まれているかを一覧にした部品構成表です。経済産業省の手引きでは、脆弱性管理、ライセンス管理、開発生産性の面でのメリットが示されています。

形式はSPDXとCycloneDXが代表的で、どちらも国際的な標準になっています。導入は、環境構築・体制整備、SBOM作成・共有、SBOM運用・管理の3つのフェーズで進め、作った後も更新を続けることが大切です。

SBOMの読み方は何ですか？

「エスボム」と読みます。経済産業省の手引きでも、この読み方が示されています。

SBOMの作成は必ず必要ですか？

すべての企業に一律で作成を義務づけるものではありませんが、分野や取引先によっては提出を求められることがあります。海外の取引先や規制の要件もあわせて確かめましょう。

SBOMは手作業で作れますか？

小さなソフトウェアなら作れますが、部品の数が多いと現実的ではありません。ソースコードや成果物を解析してSBOMを作るツールを使うのが一般的です。

SBOMを作れば脆弱性はなくなりますか？

いいえ、なくなりません。SBOMは中身を把握するための道具で、脆弱性の情報と照らし合わせて対応することで初めて役に立ちます。

SBOMとCVEはどう関係しますか？

SBOMに書かれた部品の名前とバージョンを、CVEなどの脆弱性情報と照らし合わせることで、影響の有無を調べます。CVEについてはCVEとは？CVE番号の読み方とCVSS・CWEとの違いで解説しています。

ここまでの内容を踏まえて、まずはスキルログに無料で登録し、ソフトウェアの管理やセキュリティに関わった案件を1件、対象と担当した範囲まで入力してみましょう。セキュリティの経験を生かした仕事を探したい場合は、転職・案件相談で一緒に確かめられます。