SPDX vs CycloneDX：
SBOMはどっち？違いと選び方
SBOMに取り組み始めた部品メーカーが、ほぼ必ずぶつかるのがこの疑問です。
- 「SBOMって SPDX と CycloneDX、結局どっちで作るの？」
- 「OEM提出で通るのはどっち？」
- 「脆弱性（CVE）突合やトリアージを回すならどっちがラク？」
結論から言うと、“どちらが正解”ではなく、用途で最適が変わります。しかも現実には、社内運用と対外提出で“求められる姿”が違うことも多いです。
この記事では、Tier2〜Tier4の実務（兼務で回す、提出と監査がある、脆弱性照会が来る）に合わせて、SPDXとCycloneDXの違いと選び方を比較で整理します。
先に結論：迷ったら“この順”で考える
比較記事ではありますが、最初に「迷いを減らす結論」を置きます。
1 OEMがフォーマット指定しているなら、それが最優先
OEM指定（Excel、独自様式、SPDX、CycloneDX等）がある場合は、まずそれに合わせるのが最短です。フォーマットより「期限内に、根拠付きで返せること」の方が重く見られます。
2 指定がないなら、運用目的で選ぶ
- 脆弱性突合・自動トリアージ・ツール連携を最優先 → CycloneDX寄り
- 提出・説明性・ライセンス情報の整理を最優先 → SPDX寄り
3 実務では「両方出す」設計が一番ラクなこともある
社内ではCycloneDXで自動化しつつ、提出はSPDX（またはOEM指定）に寄せる、のように “内部の正本（カノニカル）”と“外部出力”を分ける と、現場が破綻しにくいです。
SPDXとCycloneDXは、何が違うのか（ざっくり定義）
SPDX（エスピーディーエックス）
- もともとライセンス情報やソフトウェア部品情報を整理する文脈が強い
- 人が読める文書としても扱いやすく、説明性・標準性の安心感がある
- 「提出物として整ったSBOM」に寄せやすい
CycloneDX（サイクロンディーエックス）
- SBOMを“運用データ”として扱い、脆弱性管理や自動化とつなげやすい
- 依存関係やセキュリティ運用（例：VEX）を視野に入れた設計
- 「CVE突合→トリアージ→回答書」へつなげやすい
※どちらも「SBOMとして成立」します。差は“得意領域”です。
比較表：SPDX vs CycloneDX（部品メーカー視点）
| 観点 | SPDXが向く | CycloneDXが向く |
|---|---|---|
| 目的 | 提出・説明・標準性重視 | 運用・自動化・突合重視 |
| 現場の使い方 | 「提出物の整形」に寄せやすい | 「日々の脆弱性対応」に寄せやすい |
| ライセンス/コンプライアンス | 強い文脈で扱いやすい | もちろん可能だが運用寄り |
| 脆弱性（CVE）突合 | 可能（ツール次第） | 突合・拡張・運用連携に寄せやすい |
| “兼務が回す”観点 | 文書的で分かりやすい | 自動化できると負荷が落ちる |
| OEM提出の現実 | OEM側が求めることが多い | OEMが指定するケースも増える （ただし様式はまちまち） |
この表を見て分かる通り、「運用」ならCycloneDX、「提出」ならSPDXに寄りがちです。ただし、最初から完璧な標準化に寄せようとすると止まるので、次の判断フローで“落としどころ”を作ります。
選び方：5つの質問で決める（判断フロー）
次の質問に「はい」が多い方へ寄せると、失敗しにくいです。
いいえ → SPDX寄り
いいえ → SPDX寄り（またはExcel）
いいえ → CycloneDX寄り
いいえ → SPDX/CycloneDXを検討
ない → Excel→CycloneDX→SPDX
そもそも：最初はExcelで始めていい（現場が止まらないやり方）
比較の話をしても、現場ではこうなりがちです。
- 「どっちを選べばいいか分からない」→ 何も進まない
- 「標準化から始めよう」→ 更新が回らず形骸化する
そこで、最初の現実解は「Excelで“答えられる状態”を作る」です。
重要なのはフォーマットではなく、対象製品・対象版数・コンポーネント版数が追えることです。
運用のコツ：どちらを選んでも、ここを外すと破綻する
-
製品バージョンとコンポーネントバージョンを分ける
CVE照会で詰む最大原因です。「どの製品版まで影響するか」を切れないと、結局人手調査に戻ります。 -
“社内版”と“提出版”を分ける
SBOMは機密（設計情報に近い）なので、全部出せないのが普通です。社内完全版→提出版→照会回答版、のように粒度を分けると止まりません。 -
更新責任者・更新タイミングを決める
SBOMは「作成」より「更新」が本番です。更新しないSBOMは、提出にも照会にも使えません。 -
内部の正本（カノニカル）と外部出力を分ける
「社内運用：CycloneDXで自動突合」「外部提出：SPDX（またはOEM指定）」のように割り切ると、運用の手戻りが減ります。
よくある失敗（比較で迷っている間に起きる事故）
- フォーマット議論だけ進み、棚卸し（実データ）がない
- SBOMはあるが、対象版数が追えず照会に答えられない
- 「影響なし」を返すが、根拠（証跡）がなく追加質問で炎上する
- 更新責任者がいなくて、すぐ古くなる
- OEM様式に合わせるだけで、社内運用に繋がっていない
比較の最終目的は、「どっちが上か」ではなく
“自社が期限内に根拠付きで返せる運用を作る”ことです。
FAQ：SPDXとCycloneDXの違いと選び方
どちらもSBOMですが、SPDXは提出・説明・標準性に寄せやすく、CycloneDXは脆弱性対応や自動化など運用連携に寄せやすい、という得意領域の違いがあります。
OEMが指定する形式が最優先です。指定がない場合は、提出物として整った形にしやすいのはSPDX寄りですが、実務ではExcel指定や独自様式も多いので、まずは要求に合わせるのが現実的です。
“両方を人手で管理”はおすすめしません。内部の正本（カノニカル）を1つ決め、外部提出は変換・出力で対応する設計にすると破綻しにくいです。
ダメではありません。まずExcelで棚卸し→更新運用→その後に標準化、の順の方が現場で回りやすいケースが多いです。
ツール連携・運用データとしての扱いやすさの観点ではCycloneDX寄りになりやすいです。ただし最終的には「対象版数が追える」「根拠が残る」運用ができているかが重要です。
自社のSBOM運用、どう設計するか迷っていませんか？
SPDX/CycloneDXの選び方、提出版/社内版の切り分け、更新運用などを自社向けに整理したい方はご相談ください。
Auto PSIRT Cloudなら、既存のExcel部品表を取り込むだけで、CVE突合・トリアージ・提出用レポート出力までを一気通貫で自動化できます。