SBOMに必ず入れるべき項目
（どこまで固めればいい？）
OEMからSBOM提出や脆弱性（CVE）照会を求められたとき、最初に詰まるのがここです。
- SBOMって「項目を全部埋めないとダメ」なの？
- SPDX/CycloneDXみたいな標準フォーマットが必須？
- どこまで固めれば、OEM照会に“根拠付き”で答えられる？
結論から言うと、最初から“全部入りSBOM”を目指すほど失敗します。
Tier2〜Tier4の現場で最優先なのは、「製品版数×部品版数が切れる」＋「判断の根拠が残る」 ことです。
この記事では、SBOMに「必ず」入れるべき項目を最小セットに絞り、どこまで固めればいいかの線引きと、現場で回る固め方（手順）をまとめます。
先に結論：「必須」と「後回し」を分けると回り始める
SBOMの項目は、目的別に増やしたくなります。だからこそ最初にこう線引きします。
必須（まず固める）
OEM照会に“対象版数”で答えるための項目
推奨（次に足す）
ノイズ（不要対応）を減らすための項目
拡張（必要になったら）
監査・契約・顧客指定で求められた項目
SBOMは“作ること”より、“更新できること”が価値です。
更新できないSBOMは監査でも照会でも使えません。
SBOMに「必ず」入れるべき項目（最小セット）
最低限、以下の7つの項目があれば、SBOMとしての初期目的（照会への回答）は果たせます。
1) 製品名
提出や照会は「どの製品の話か」で始まります。製品名（SKUやECU名でも可）を固定します。
2) 製品バージョン（最重要）
OEM照会で追加質問が止まらない最大原因が「どの版まで影響？」です。
製品バージョンがないSBOMは、実務上“SBOMとして機能しません”。
3) コンポーネント名
OSS/商用/自社を問わず、構成要素を一意に識別できる名前（パッケージ名、モジュール名）を入れます。
4) コンポーネントバージョン
CVEはバージョンで刺さります。
OSSならバージョン、商用品なら型番/リビジョン、自社ならコミット/ビルド番号など、比較可能な識別子に揃えます。
5) 種別（OSS/商用/自社）
「どこに問い合わせるか」「誰が直すか」が変わるので、種別は早めに固定します。
6) 搭載箇所/モジュール（1列でOK）
“影響なし”を説明するときに効きます。
粒度は細かくなくて良いので、まずは「どのモジュールに入っているか」を1列で持ちます。
7) 更新日・更新者（またはSBOMスナップショットID）
監査で効くのは「最新版が管理されていること」です。
最低限、更新日と更新者（できればスナップショットID）を残します。
推奨：次に足すと強くなる項目（ノイズ削減・監査で効く）
上記の最小セットが運用に乗り始めたら、以下の項目を足すとさらに対応が楽になります。
- 供給元/取得元： 取引先・ベンダー・上流など（照会時の“問い合わせ先”になる）
- 備考（根拠の一言）： 外部IFなし／機能無効／実行経路なし 等
- ライセンス： 提出先要件がある場合のみでOK（最初から必須にしない）
ここまで来ると、「影響なし」の説明が強くなり、追加質問が減ります。
どこまで固めればいい？（現場で迷わない3段階）
レベル1：OEM照会に“対象版数”で答えられる
- 必須項目（上の7つ）が埋まっている
- 対象製品を絞って運用できている（全部やらない）
レベル2：CVE突合・トリアージで“ノイズを減らせる”
- 搭載箇所/備考が育っている（影響なし根拠が残る）
- 更新トリガー（リリース時/部品更新時/照会時）が決まっている
レベル3：監査・提出で“証跡が揃う”
- 正本（社内版）と提出版の切り分けができている
- 提出履歴、参照元、承認線が説明できる
最初にやるべきは、レベル1の完成です。
レベル1が回っていないのに、レベル3の項目を増やすと更新が止まります。
手順：SBOM項目を“固める”5ステップ（手作りでも迷わない）
Step 1：目的を1つに絞る（まずは照会対応）
最初の目的は「CVE照会に答える」で十分です。目的が増えるほど項目が増えて運用が止まります。
Step 2：対象製品を絞る（全部やらない）
OEM照会が多い／外部IFがある／売上影響が大きい製品から着手します。
Step 3：最小カラム（必須7）を固定する
列を固定し、表記ゆれを禁止します（製品名・版数のゆれは後で地獄になります）。
Step 4：版数の“切り方”を決める（製品版数×部品版数）
「製品の版数」と「部品の版数」を必ず分けて持ちます。ここが決まると照会対応が速くなります。
Step 5：更新トリガーを3つだけ決める
- 製品リリース（版数変更）
- 部品更新（供給元更新含む）
- OEM照会（調査結果の追記）
OEM監査対応・出荷を止めないための“SBOMの項目設計と更新ルール”から整備しましょう。まずはご相談ください。
【無料】オンライン相談を予約する監査で見られるのは「項目の多さ」より「証跡と再現性」
監査・照会で突っ込まれるのは、SBOMの網羅性よりも次のような「運用の実態」です。
- そのSBOMは どの製品版数 のものか？
- いつ誰が更新 したか？更新は止まっていないか？
- “影響なし”の根拠（到達性/条件）を説明できるか？
- 提出版は、正本から再現可能 か？（その場しのぎではないか）
よくある失敗（項目を増やす前に避ける）
- 製品バージョンがない（＝照会で必ず詰む）
- “最新版SBOM”しかなく、過去版数が再現できない
- 正本が複数に散らばって矛盾する
- 便利そうな項目を増やしすぎて更新が止まる
FAQ：SBOMの項目について
最小は「製品名」「製品バージョン」「コンポーネント名」「コンポーネントバージョン」「種別（OSS/商用/自社）」「搭載箇所」「更新日/更新者」です。まず“版数で答えられる”状態を作るのが優先です。
まずはレベル1（照会に対象版数で答えられる）です。提出・監査（レベル3）は段階的に。項目を増やすより、更新が回ることが評価されやすいです。
必須ではありません。Excelで最小項目＋更新運用が回ってから標準化した方が成功率が高いです（作った瞬間に古くなるのが一番まずい）。
コミットID、ビルド番号、リリースタグなど、比較可能な識別子に統一します。OEM照会は“どれが対象か”を切れることが最重要です。
最小は「製品リリース（版数変更）時」です。照会が増えてきたら、部品更新や供給元通知も更新トリガーに追加します。
Excel SBOMから、自動トリアージへ
Auto PSIRT Cloudなら、最小項目で作ったExcelの部品表をアップロードするだけで、日々の脆弱性（CVE）チェックを自動化できます。
OEM回答書（レポート）作成までの流れを、実際の画面で確認してみませんか？