SBOMとは？義務化の対象・作成ツール・脆弱性管理の進め方【2026年版】

SBOM（Software Bill of Materials、ソフトウェア部品表）は、製品やシステムを構成するソフトウェアと、その依存関係を機械で扱える形にした一覧です。脆弱性が公表されたときに「自社のどの製品・版に関係するか」を調べる基礎になります。ただし、一覧を出力するだけで安全性や法令適合が保証されるわけではありません。

本記事では2026年10月時点で確認できる一次資料をもとに、導入目的、国・分野ごとの要件、形式と作成ツール、脆弱性対応へつなぐ運用を整理します。市場予測の大きさより、対象製品と対応責任を明確にして使い続けられるかが導入の判断軸です。

SBOMとは何か：部品、依存関係、対象バージョンをそろえる

ソフトウェアは自社で書いたコードだけで動いているとは限りません。利用するライブラリが別のライブラリに依存し、配布物にはOSのパッケージや実行環境が含まれることもあります。SBOMは、こうした構成を確認するための情報です。対象はOSSだけでなく、商用の部品や自社のソフトウェアも含めて検討します。経済産業省の手引も、部品の名称・バージョン・開発者等と依存関係を扱っています。経済産業省「SBOMの導入に関する手引ver2.0」で定義と基本的な考え方を確認できます。

最初に決めるのは「どの製品の、どの版の、何を調べるか」です。ソースコードの依存ファイル、ビルド時の情報、配布用コンテナ、稼働環境では確認できる部品が異なります。開発用ツールだけを含む一覧を本番の構成だと思い込んだり、納品した版と別の版のSBOMを照合したりすると、対応対象を誤る原因になります。製品のリリース番号、成果物の識別情報、作成日時、作成方法を結び付けて保存する設計が必要です。

管理する項目には、部品名とバージョンに加え、供給者、識別子、依存関係、作成者、作成時点などがあります。これは単に列を増やす話ではありません。同じような名前の別パッケージを取り違えず、後から対象の成果物へ戻れることが目的です。経産省の手引が紹介する2021年の米国NTIAの最小要素にも、データ項目と並んで作成頻度、依存関係の深さ、共有、アクセス管理等の運用が含まれています。この過去の基礎整理を、あらゆる現行契約の必須項目と同一視せず、実際の要求仕様と照らし合わせます。

直接利用している部品の一覧だけでは、その先の依存関係を調べられない場合があります。一方で、ツールが発見できない部品まで「含まれていない」と断定することもできません。未確認の範囲を記録し、取得できない供給者の情報や動的に読み込む部品をどう補うかを決めます。部品一覧、既知の脆弱性との照合結果、製品への実際の影響判断は、それぞれ役割が異なる情報として管理すると、担当者間の受け渡しが明確になります。

SBOMの義務化はどこまでか：日本・EU・米国・医療機器を区別する

「SBOMが世界で義務化された」というまとめ方では、自社が準備すべき内容を判断できません。法令の適用対象、政府調達の条件、取引先の契約、推奨される実務を分けて確認します。特に、作成する義務、要求された相手への提供、一般利用者に公開することは別です。対象製品、販売地域、調達先、契約条項、適用日を表にし、技術担当と調達・法務の担当が同じ前提で確認することを勧めます。

地域・分野	確認できる位置付け	実務で確認する点
日本	経産省は2024年8月29日に導入手引ver2.0を公表	手引の公表自体を全企業への一律の法的義務としない。取引・分野別の要件を別途確認
EUのCRA	対象となるデジタル要素を備えた製品について、脆弱性の取扱要件にSBOMを規定	製品の適用範囲・除外、製造者の義務、各条項の適用日を確認
米国連邦政府調達	2026年のOMB M-26-05がリスクに応じた管理へ更新	古い覚書だけで断定せず、各機関の方針・要求・契約条件を確認
米国の医療機器	FDAがFD&C法524Bの対象となるサイバー機器の申請要件を説明	すべての医療機器へ一括適用せず、機器と申請・変更の条件を確認

日本の手引は、導入から脆弱性管理、費用対効果、供給者と調達者の取引モデルまでを支援する資料です。経産省の改訂発表を起点に、自社の利用目的と取引条件へ落とし込みます。

EUのCyber Resilience Act（規則2024/2847）は、対象製品の脆弱性取扱要件に、少なくとも最上位の依存関係を含む、一般的に用いられる機械可読形式のSBOMを定めています。主な適用日は2027年12月11日ですが、第14条の報告義務は2026年9月11日から先行して適用されます。SBOMを作成する要件を、すべての企業が部品情報をインターネットへ公開する義務と読み替えないことが重要です。市場監視当局への提供要求と、製造者が利用者へ公開する場合の案内も分けて規定されています。

米国では2026年1月23日のOMB M-26-05がM-22-18とM-23-16を撤回しています。各機関が必要に応じ、要求時に最新SBOMを提供させる契約条件等を採用できるという整理を、全調達への一律提出義務とは区別します。また、FDAのFAQは対象となるサイバー機器と申請について、商用・OSS・既製のソフトウェア部品を含むSBOMの要件を説明しています。規制名だけで結論を出さず、対象となる製品と申請条件から確認します。

SPDX・CycloneDXと作成ツール：受け渡し先が使える形式を選ぶ

代表的なSBOM形式にSPDXとCycloneDXがあります。前者をライセンス専用、後者を脆弱性専用と決め付ける必要はありません。用途に関係する項目、生成側と受領側が扱える版、依存関係や識別子の表現を確認して選びます。SPDXの仕様案内は3.0と過去の仕様を公開し、CycloneDXの仕様概要は1.7を案内しています。番号が新しいだけで既存の管理基盤へ取り込めるとは限りません。取引先が指定する形式・版・必要項目を先に確かめます。

作成ツールの候補にはSyftやTrivyがあります。Syftの出力形式の公式説明では、SPDXやCycloneDXを含む形式と、形式ごとの対応版を確認できます。TrivyのSBOMの公式説明でも、生成とSBOMを入力にした検査が分けて案内されています。TrivyではCycloneDX形式の通常出力に脆弱性を含めない設定があるため、ファイルが生成されたことと脆弱性検査が行われたことを同じ成功条件にしないようにします。

比較では、ツール名の多さより、自社の言語・パッケージ管理・成果物に合うかを見ます。試験対象を一つ選び、既知の直接・間接依存が出力されるか、社内製部品や取得できない部品を区別できるか、管理基盤で読み込めるかを確かめます。同じ形式名でも、生成方法や独自の追加情報、対応する版の違いで後段の検査結果が変わる可能性があります。形式の変換だけで情報が完全に維持されるとも決め付けず、必要な項目と関係が残ったかを確認します。

経産省の手引も、SBOMツールによる誤検出・検出漏れや、実行時に動的に追加される部品の扱いに注意を促しています。したがって「ツールを実行したので全構成を把握した」という完了条件は適切ではありません。生成ツールと版、入力となる成果物、対象外の範囲、確認方法を記録しておくと、結果の違いを再調査できます。ビルドごとの生成と保管を自動化する考え方は、CI/CDの仕組みと導入手順にもつながります。自動化に組み込む前に、誰が結果を受け取り、失敗や未確認範囲を扱うかを決めます。

脆弱性管理へつなぐ：影響判断、VEX、修正後の確認を回す

SBOMを使う目的は、脆弱性が公表されたときの調査と対応を進められる状態をつくることです。まず、対象製品のSBOMを信頼できる脆弱性情報と照合し、候補を確認します。その際、同名の別部品、バージョン表記、供給者が提供する修正状況などを確かめます。照合結果は調査の入口であり、名前が一致しただけで製品が必ず攻撃可能になるとは限りません。逆に、一致がないことも、独自コードや設定・認証の問題まで含めた安全性の証明にはなりません。

対応順位は、深刻度の数値だけで固定せず、実際の利用箇所、外部から到達できるか、必要な権限、保護策、業務への影響、修正版の有無を踏まえて決めます。部品が含まれていても対象機能を使っていない場合と、公開APIから利用される場合では、確認すべき条件が異なります。判断に必要な情報がないものは、根拠を作らず「調査中」として担当と次の確認事項を残します。検知件数を自動的に減らすことだけを成果にすると、未調査を安全扱いする運用になりかねません。

VEX（Vulnerability Exploitability eXchange）は、部品の脆弱性が、使われている製品の文脈で影響するかを伝えるための情報です。CycloneDXのVEX説明も、この文脈に応じた影響の共有を目的にしています。「影響なし」の記録だけを受け取って永久に除外するのではなく、対象の製品・版、判断根拠、発行元、判断時点を確認します。設定や利用方法が変わったとき、あるいは新しい情報が出たときに再評価できる扱いが必要です。具体的な項目名や状態値は、採用する形式の仕様と受領側の実装に合わせます。

修正するときは、依存部品の更新、ビルド、動作確認、配布、稼働環境への反映までをつなぎます。SBOMだけ新しくても古い成果物が動いていれば対策は完了していません。修正後の成果物とSBOMを対応させ、再検査と必要な動作確認の結果を記録します。直ちに更新できない場合は、代替策の範囲、承認者、期限、見直す条件を残します。開発工程全体への組込みはDevSecOpsと継続的なセキュリティ対策、コード・構成・認証の弱点を合わせて検証する考え方は脆弱性診断とペネトレーションテストで整理しています。SBOMから得た情報を、修正の実行と確認まで運べることが運用の到達点です。

導入の進め方と費用：共有条件と対応責任まで決める

導入は、重要な製品や顧客から要求のある製品など、目的が明確な対象から始めます。対象の選び方を決め、現状の構成と供給者の情報を調べ、生成・受領・照合・影響判断・修正の一連の流れを小さく試します。ツールの導入だけを別の作業に切り離すと、警告が出ても誰も対応しない状態が生まれます。製品の責任者、開発担当、セキュリティ担当、調達担当の役割を決め、判断が止まった場合の引き取り先を明確にします。

費用は「無料ツールか有料製品か」だけでは比較できません。初期の対象調査、生成基盤への組込み、保管とアクセス制御、照合結果の確認、供給者への問い合わせ、修正と検証などに作業が発生します。商用製品の価格も対象や契約条件によるため、一律の月額や開発者単価を置かず、自社の対象数・更新頻度・必要な支援範囲で見積もります。評価時には、部品の件数だけでなく、対象製品への到達時間、未確認範囲、担当への受渡し、期限内の修正・再確認など、目的に沿った指標を設定します。

外部へ共有する場合は、形式、対象となる版、更新頻度、提供方法、閲覧できる相手、二次利用の条件、問い合わせ先を合意します。SBOMはソースコードそのものではありませんが、製品の構成に関する情報を含みます。公開が必要な情報と契約に基づき限定共有する情報を区別し、保存先やアクセス権を決めます。供給者に依存する製品では、SBOMが取得できない場合の代替情報、脆弱性通知、保守終了時の対応も確認します。こうした取引先との責任分担は、サードパーティリスク管理と合わせて整理できます。

ライセンス情報も活用できますが、部品一覧があるだけで利用条件への対応が完了するわけではありません。検出した情報の根拠や不足を確認し、具体的な利用・配布方法に応じて必要な確認を行います。AIを使って情報を整理する場合も、根拠資料、対象の版、担当者の確認を残し、未確認の影響判定や修正を自動で確定させない設計が必要です。

renueは、SBOMを受領した後の脆弱性調査や、保守終了の部品を含むシステムの見直しを、業務と構成の把握から考えます。AI脆弱性診断支援サービスでは、合意した対象について、コード分析・既知の脆弱性の確認・認証や外部接点の検証を組み合わせ、改善点と優先順位を整理します。診断後の改修・刷新も、範囲を合意して進めます。SBOMの自動生成製品や法令適合の認証として扱わず、「どの部品を使い、何を調べ、誰が直すか」を具体化する相談先としてご活用ください。