SBOMツールの比較と選び方｜生成・管理・SCAのタイプ別に選定基準を解説

SBOMツールを探すと、部品表を吐き出すコマンドラインツール、数千件のコンポーネントを継続監視するサーバ製品、脆弱性とライセンスを判定する商用SCAが同じ名前で並びます。担当する工程が違うため、1本選べば済むという前提の比較では抜けが出ます。この記事では3つの製品タイプの担当範囲を切り分け、開発体制の規模別にどの組み合わせを選ぶか、2026年7月公表の国際ガイダンスとEU CRAが選定要件をどう変えたか、導入を見送るべき条件までを整理しました。SBOMの定義やフォーマットの読み方は別記事に譲り、発注側の判断材料に絞ります。

まとめ：SBOMツール選定を分ける生成・管理・SCAの役割分担と判断軸

SBOMツールは、部品表を出力する「生成ツール」、出力された部品表を蓄積して脆弱性と突き合わせ続ける「管理プラットフォーム」、依存関係を解析して脆弱性とライセンス違反を判定する「SCAツール」の3タイプに分かれます。生成ツールだけを入れても、翌月に公表されたCVEには気づけません。管理プラットフォームだけを契約しても、入力する部品表を作る手段がなければ箱が空のままです。

判断軸は3つです。第一に、出力したSBOMの提出先が社内運用のみか、納品先や当局か。第二に、対象がアプリケーションの依存パッケージだけか、コンテナイメージやOSパッケージ、組み込み機器のファームウェアまで含むか。第三に、検知結果を誰が捌くか。3つ目を決めずに製品を選ぶと、導入後に警告の山が放置されて運用が止まります。

10人未満のチームなら、Syft系の生成ツールとOWASP Dependency-Trackの2本構成から始めるのが妥当な出発点です。納品先へSBOMを提出する受託開発や、医療機器・車載などの規制対象では、署名と形式指定に対応した商用SCAを最初から候補に入れます。脆弱性対応に人を割けない体制では、SBOMツールより先に依存パッケージの更新頻度を上げるほうが被害の低減に効きます。

SBOMツールが生成・管理・SCAの3タイプに分かれる構造と担当範囲

カタログ上は横並びに見えても、3タイプは入力と出力が異なります。取り違えたまま相見積もりを取ると、機能表の丸の数で比較してしまい、実際には埋まらない工程が残る形です。SBOMの定義・記載項目・フォーマットの基礎はSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断で扱っています。

生成ツールの担当範囲とSyft・Trivyが出力するCycloneDX形式

生成ツールは、ソースコードのロックファイルやコンテナイメージのレイヤを走査し、コンポーネント名・バージョン・ライセンス・ハッシュ値を機械可読ファイルに書き出します。代表格のSyftは30を超えるパッケージエコシステムに対応し、npm・PyPI・Maven・GoモジュールとOSパッケージを同一の部品表に載せられます。

出力形式はCycloneDXとSPDXの2系統。CycloneDXは2026年8月時点で1.7系が最新の系列にあたり、ECMA-424として標準化されています。SPDXは3.0系が公開済みです。どちらを出すかは提出先の指定で決まるため、両形式に対応した生成ツールを選ぶと後戻りが減ります。

コンテナ主体の環境なら、SBOM生成と脆弱性スキャンを1つのバイナリで済ませる選択肢もあります。対応範囲はTrivy（トリビー）とは｜使い方・インストール・読み方の入門ガイドにまとめました。生成ツール自体はOSSが主流で、費用はCIへの組み込み工数だけです。

管理プラットフォームの担当範囲とDependency-Trackの継続監視

生成した部品表は、そのままでは静的なファイルにすぎません。管理プラットフォームは複数プロジェクトのSBOMを取り込み、脆弱性データベースの更新があるたびに再照合します。昨日まで無害だったライブラリが今日CVEを付与された、という変化を拾えるのはこの層だけです。

OSSではOWASP Dependency-Trackが事実上の標準です。CycloneDX形式のSBOMとVEX文書を取り込み、プロジェクト単位でリスクスコアを継続表示します。バージョンはv5系が現行の開発ラインで、v4系は2026年12月までメンテナンスモードとされています。新規導入でv4系を選ぶ理由はありません。

自社で立てる場合はサーバとデータベースの運用が発生します。SaaS型の管理サービスと運用コストを比べる分岐点は、監視対象50前後です。

SCAツールの担当範囲と生成ツール単体では代替できない検知の深さ

SCAツールは依存ツリーを解析し、直接依存だけでなく推移的依存に潜む脆弱性まで辿ります。同じコンポーネントでも、脆弱な関数が実際に呼ばれているかを判定する到達可能性解析を備えた製品があり、これが誤検知の量を大きく変えます。生成ツールの出力を眺めるだけでは、この判定はできません。

商用製品ではBlack Duck、Snyk、Mend、FOSSAが比較対象に挙がり、国内ではYamoryのように日本語サポートと国内脆弱性情報に強い製品もあります。GPL系の混入検知といったライセンスコンプライアンス判定を求めるなら、OSSの組み合わせでは手当てしにくい領域です。

SCAとSBOMは重なりつつ目的が違い、SCAは「解析して判定する手法」、SBOMは「その結果を含む成果物の形式」にあたります。両者の関係と検出の仕組みはSCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違いで解説しました。

製品タイプ別の機能比較と自社の開発体制に合う組み合わせの見極め

3タイプの比較は、機能の有無ではなく「誰が何時間使うか」で見ると差が出ます。商用製品の年額が高く見えても、脆弱性トリアージの人件費を織り込むと逆転する場合があります。

生成・管理・SCAの3タイプを対応形式・費用・運用負荷で並べた比較表

下表は3タイプの担当工程と費用構造を整理したものです。商用製品の見積もりは開発者数・リポジトリ数で変動します。

生成ツールと管理基盤は補完関係にあり、片方だけでは工程が閉じません。商用SCAは3工程を一体で提供する製品が多く、その分だけ移行時のロックインが強くなります。

OSS中心構成と商用SCA導入で分かれる初期費用と運用人員の目安

OSS中心の構成は、ライセンス費用が発生しない代わりに構築と運用を自前で持ちます。Dependency-Trackをコンテナで立て、CIからSBOMをアップロードする仕組みを整えるまで、経験のあるエンジニアで数日、初見なら2週間程度の規模。以降は月に数時間の保守と、検知結果を捌く時間が継続します。

商用SCAは構築工数が小さい代わりに、開発者数やリポジトリ数に比例した年額が発生します。ポリシー設計や例外承認のワークフローが製品側に用意されているため、監査対応の証跡を残しやすい構造です。

費用比較で落ちやすいのが、脆弱性トリアージの人件費です。プロジェクトが10を超えると検知件数は月あたり数百件規模に達し、優先度付けの仕組みがない構成では担当者の時間が先に枯渇します。

CI/CD組み込みの可否とコンテナ・組み込み機器での検出精度の差

パッケージ管理ファイルを読む方式は、ロックファイルが存在する言語では精度が高く出ます。一方、コンテナイメージのOSパッケージや、組み込み機器のファームウェアのようにパッケージ管理を経ないバイナリでは検出漏れが起きる構造です。組み込み分野ではYocto Projectのビルドメタデータから部品表を起こす方式が使われます。

CI/CDへの組み込みは、ビルドごとにSBOMを生成してアーティファクトとして保存する形が扱いやすい構成です。リリース時だけ生成すると、どのビルドの部品表かを後から特定できず、インシデント時の影響調査で足を引っ張ります。

コンポーネントの同定にはCPEとPURLの2系統の識別子があり、OSSパッケージではPURLのほうが誤マッチが少なく出ます。CPE中心の突き合わせは製品名の表記ゆれで別コンポーネントを拾う事故が起きるため、識別子の扱いも比較項目に入れてください。

2026年版SBOM最小要素とEU CRAが選定要件に加えた必須項目

SBOMツールの選定要件は、ここ2年で制度側から書き換えられました。2024年までの「作れれば良い」という水準では、2027年以降の提出要求に応えられません。

2026年7月公表の国際ガイダンスで新設された10項目と対応確認

米国CISAが2025年8月に草案を公表し、14か国のサイバーセキュリティ当局の議論を経て、2026年7月末に「2026 Minimum Elements for a Software Bill of Materials」が国際ガイダンスとして公表されました。経済産業省は2026年7月30日に共同署名を発表しています。

2021年版からの差分は、新設10項目・更新7項目・削除1項目。新設された項目には、SBOM作成主体の署名、SBOMデータフォーマット名とバージョン、SBOM生成コンテキスト、SBOMツール名とバージョン、SBOMバージョン、コンポーネントのハッシュ値とハッシュアルゴリズム、コンポーネントライセンスが含まれます。削除は「アクセス制御」の1項目です。

この差分は、そのまま機能要件になります。生成ツールがハッシュ値とライセンスを出力するか、署名を付与できるか、生成コンテキスト（どのビルド段階で作られた部品表か）を記録するか。3点を満たさない製品は、提出用途で作り直しが発生します。部品表の差し替えを防ぐ観点は、サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位で扱った攻撃経路の議論と直結します。

EU CRAの2027年12月11日適用に向けた機械可読SBOMの要件

EUサイバーレジリエンス法（CRA）は、主要な義務が2027年12月11日から適用され、報告義務は2026年9月11日に先行適用されます。報告義務では、悪用が確認された脆弱性を認知してから24時間以内に、各国のCSIRTとENISAへ通知する必要があります。

SBOMに関する要求は、少なくとも最上位の依存関係を含む機械可読形式の部品表を作成し、最新の状態に保ち、市場監視当局の求めに応じて提出すること。「最上位の依存関係」が下限であって推移的依存まで必須ではない点が、実務上の作業量を左右します。

期日の並びから逆算すると、SBOMの整備は2027年ではなく2026年内に前倒しになります。24時間以内の報告は、自社製品にどのコンポーネントが入っているかを即座に引ける状態が前提で、部品表なしでは期限内の判断ができません。EU域内へ製品を出荷する予定があるなら、選定要件に署名と機械可読形式を明示してください。

経済産業省の手引ver2.0が示す導入範囲の絞り込みと契約条項

経済産業省は2024年8月29日に「ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0」を公開しました。ver1.0からの追加点は、脆弱性管理プロセスでSBOMをどう扱うかの具体手順、導入の効果とコストを勘案して対象範囲を決めるためのフレームワーク、委託先との契約で規定すべき事項の3点です。

実務で効くのは2つ目。全システムに一律導入すると工数が跳ね上がるため、外部公開・個人情報の取り扱い・長期保守といった条件で対象を絞ります。ツール選定の規模も、この範囲に合わせて決められます。

3つ目の契約条項は、受託開発の発注側・受注側の双方に関わります。納品物にSBOMを含めるか、形式はCycloneDXかSPDXか、更新の責任期間はいつまでか。契約書に書かないまま「SBOMを出してほしい」と依頼すると、納品直前に形式の不一致が判明します。

開発体制の規模別に見る選定の判断軸とSBOMツールを見送る条件

比較表を眺めても決まらないのは、判断が体制の規模と提出先で決まるためです。以下の3パターンに当てはめれば、候補は2〜3製品に絞れます。

10人未満の開発チームでOSS 2本に絞る判断と切り替えの目安

開発者10人未満、リポジトリ20本以下、提出先は社内のみ。この条件では商用SCAを入れません。SyftまたはTrivyでビルドごとにCycloneDXを出し、Dependency-Trackへアップロードする2本構成で足ります。年額ゼロで、構築は数日から2週間の範囲です。

切り替えの目安は明確。監視対象プロジェクトが50を超える、ライセンスコンプライアンスの判定が契約上必要になる、監査で例外承認の証跡を求められる。このいずれかに触れた時点で、商用SCAの見積もりを取る段階に入ります。触れていないうちに商用契約を結ぶと、機能の大半が使われないまま更新を迎えます。

OSS構成で妥協する点は、サポートの不在と到達可能性解析の欠如です。検知件数が多くても優先度を機械的に下げられないため、トリアージの時間は商用より長くなります。人が空いていないなら、この構成は成立しません。

受託開発で納品先にSBOMを提出する場合の署名・形式の指定方法

納品先へSBOMを渡す受託開発では、社内運用向けの構成をそのまま流用できません。提出物としての要件が加わるためです。契約時に確認するのは、形式（CycloneDXかSPDXか、バージョン系列まで）、署名の要否、更新の頻度と責任期間、推移的依存を含めるかの4点。

2026年版の最小要素で署名が新設された以上、署名に対応しない生成ツールは提出用途から外れます。生成後に別ツールで署名を付ける運用も取れますが、生成コンテキストの記録と合わせてビルドパイプライン内で完結させるほうが、証跡として整合します。

形式の指定がない案件では、CycloneDXを既定にしてSPDXも出せる構成にしておくと後からの要求に応えられます。両形式の出力可否は、相見積もりの必須項目に入れてください。

SBOMツールの導入を見送るべき条件と先に手をつけるべき対策

次の条件に当てはまる場合、導入は見送るべきです。第一に、脆弱性の検知結果を判断する担当者が社内に1人もおらず、外部委託の予算も無い場合。第二に、依存パッケージの更新が年1回以下で止まっており、検知しても直す工程が存在しない場合。この2つでは、部品表を作っても警告一覧が増えるだけで、リスクは1件も減りません。

先に手をつけるのは、依存パッケージの自動更新（Dependabot等によるプルリクエスト自動生成）と、ビルドの再現性確保です。更新を回す土台ができてからSBOMを載せる順序なら、検知が修正につながります。逆順で入れた現場が、次章で述べる「6か月で止まる」典型例です。

迷う場合は、自社のリスクの所在を先に洗い出す手もあります。脆弱性診断・セキュリティ診断で依存関係と公開資産を棚卸ししたうえで、ツール導入の要否と範囲を決める順序なら、使われない製品を抱え込まずに済みます。

SBOMツール導入後6か月で運用が止まる原因と検知結果を回す体制

導入までは進むのに、半年後には誰もダッシュボードを開いていない。この失敗は製品の性能ではなく、除外判断・更新頻度・担当分担の3点を決めていないことから起きます。

誤検知と未修正CVEの山を減らすVEXでの除外判断の記録方法

検知された脆弱性のうち、実際に影響するものは一部にとどまります。脆弱な関数を呼んでいない、該当機能を無効化している、といった理由で影響しない場合、その判断を記録しないと毎回同じ調査を繰り返す羽目になります。

VEX（Vulnerability Exploitability eXchange）は、この「影響あり／なし」の判断を機械可読で残す文書です。Dependency-TrackはCycloneDX形式のVEXを取り込み、判定済みの項目を一覧から外せます。除外の理由と判断者を残す運用にしておけば、監査でも説明が通ります。

記録せずに手作業で無視し続ける運用は、担当者の交代で崩れます。

SBOM更新頻度をビルド単位に固定する運用とストレージの試算

SBOMは作った時点のスナップショットです。リリースのたびに手動で作る運用にすると、更新が滞った瞬間に部品表と実物がずれます。ビルドごとに自動生成し、成果物と同じ場所に保存する設計へ固定してください。

ストレージは想像より軽く済みます。中規模アプリケーションのCycloneDXは数百KBから数MBの範囲に収まり、1日20ビルドを1年保存しても数GBから十数GBの規模。保存期間はサポート契約の責任期間に合わせるのが分かりやすく、5年保守の製品なら5年分を残します。

容量を切り詰めて古いビルドの部品表を消すと、稼働中の旧バージョンで脆弱性が出たときに調査ができません。

脆弱性対応の担当を開発チームと情報システム部で分ける責任範囲

検知結果の宛先が決まっていない構成は、必ず滞留します。実務では、依存パッケージの更新は開発チーム、インフラとOSパッケージは情報システム部、優先度の最終判断はセキュリティ担当という3分割が回りやすい形です。担当が1人しかいない組織なら、その1人が捌ける件数まで検知対象を絞ります。

対応期限は深刻度で分けておきます。悪用が確認された脆弱性は24時間以内に影響有無を判定、CVSS 9.0以上は7日以内、7.0以上は30日以内。基準を先に置けば、届いた通知ごとに議論せずに済みます。EU CRAの報告義務は2026年9月11日から適用されるため、24時間の枠は制度側の要求とも整合する設定です。

月次で未対応件数の推移を見る場を作ります。増え続けているなら、対象範囲か人員のどちらかが釣り合っていません。ツールを入れ替えても、この不均衡は解消しません。

よくある質問

SBOMツールの選定で問い合わせの多い論点を5つ挙げます。

SBOMツールは無料のOSSだけで運用できますか？

社内運用が目的なら可能です。SyftまたはTrivyで生成し、OWASP Dependency-Trackで継続監視する構成なら、ライセンス費用は発生しません。ただしサーバの構築・運用と、検知結果のトリアージに人の時間がかかります。ライセンスコンプライアンスの判定や、脆弱な関数が呼ばれているかを判定する到達可能性解析はOSSでは手薄なため、納品先への提出や監査対応が絡むならば商用SCAを候補に入れてください。

SBOMツールとSCAツールはどちらを先に導入すべきですか？

提出先が社内だけなら、生成ツールと管理基盤の組み合わせから始めます。SCAツールは3工程を一体で提供する製品が多く、後から入れても生成側を置き換える形で移行が可能です。契約でSBOMの納品が決まっている、あるいはライセンス違反の検知が先に必要という状況なら、商用SCAを先に選ぶほうが手戻りがありません。分かれ目は費用ではなく提出先です。

SBOMの形式はCycloneDXとSPDXのどちらを選べばよいですか？

提出先の指定が最優先です。指定がない場合、脆弱性管理との連携ではCycloneDXが扱いやすく、OWASP Dependency-TrackもCycloneDXを前提としています。SPDXはライセンス情報の記述が細かく、OSSコンプライアンスの文脈で使われる形式。2026年8月時点でCycloneDXは1.7系、SPDXは3.0系が公開済みです。両形式を出力できる生成ツールを選べば、後からの指定変更にも対応できます。

SBOMツールの導入にはどれくらいの期間と費用がかかりますか？

OSS構成の場合、Dependency-Trackの構築とCI組み込みで数日から2週間、ライセンス費用はゼロです。以降は月数時間の保守と、検知結果を捌く時間が継続します。商用SCAは開発者数やリポジトリ数に応じた年額契約で、構築期間は短い代わりにポリシー設計へ時間を使う配分。費用比較の際は、ライセンス費用だけでなくトリアージの人件費を同じ表に並べてください。

組み込み機器やファームウェアでもSBOMツールは使えますか？

汎用のスキャナはパッケージ管理ファイルを前提とするため、そのままでは検出漏れが出ます。組み込み分野ではYocto Projectのビルドメタデータから部品表を起こす方式が使われ、ビルドシステム側での対応が必要です。医療機器や車載など規制の対象となる領域では、提出先の指定する形式と署名の要件を先に確認し、それに対応できる生成手段から逆算して選定してください。

関連記事

• SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説：本記事が前提とする定義・記載項目・フォーマットの基礎。
• SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説：SCAの検出原理とSASTとの役割の違い。
• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位を解説：SBOMで備える攻撃経路と対策の優先順位。
• Amazon Inspector SBOM Exportの主要な機能と特長：AWS環境の稼働リソースからSBOMを書き出す方法。
• CPEとは？セキュリティ識別子・ネットワーク機器・CPEクレジットの違いと使い分け：識別子の仕組みと誤マッチが起きる理由。