SBOM生成の自動化
（どれだけ情報を増やすか）
SBOMを作り始めると、必ずぶつかる壁があります。
- 「SBOMを“自動で作る”って、どこまで自動化すればいいの？」
- 「情報を増やすほど正確になりそう。でも運用が死ぬ…」
- 「OEM照会（CVE影響有無）に答えられる最低ラインはどこ？」
結論から言うと、SBOMの自動化は ツール選びより“情報量の設計”が9割です。
項目を増やすほど“良いSBOM”に見えますが、更新できないSBOMは提出にも照会にも使えません。大事なのは、目的に対して必要十分な情報を、継続的に更新できる形で持つことです。
まず決める：SBOMで「何に答えたいか」（目的が先）
SBOMを“自動化したい”と言うとき、実務で求められる答えは主にこの3つです。
- どの製品／どの版数が対象か
- 影響あり・なしの根拠（到達性/設定/実行経路）
- 対象範囲、更新履歴、責任者
- 必要な範囲だけ開示できる（機密管理）
- リリースごとの差分、修正対応の追跡
ここが決まると、増やすべき情報（カラム）と、自動化の範囲が決まります。
「情報を増やす」と何が起きるか（SBOMのコスト構造）
SBOMの情報量は、ざっくり次の3方向で増えます。
- 粒度を増やす： 依存関係の深掘り、ファイル単位、関係性（どこで使うか）
- 属性を増やす： 供給元、ライセンス、ハッシュ、ビルド条件、搭載箇所…
- 頻度を増やす： 毎リリース生成、日次生成、CIで自動生成…
このうち現場で破綻しやすいのは、属性 × 頻度 です。
「属性が多いのに更新頻度が高い」SBOMは、だいたいメンテ不能になります。
だから、最初はこう割り切るのが現実解です。
・まず“照会に答える最小項目”だけ
・その後、必要になった属性だけ足す（足す理由があるものだけ）
自動化は3段階で考える（手作業→半自動→自動）
SBOM生成の自動化は、いきなり100点を狙うより 段階的に“手戻りを減らす” のが最短です。
レベル0：手作業（Excel）—「答えられる状態」を作る
- 目的： OEM照会に“対象版数”で答えられる
- 手段： Excelで最小項目（製品版数／コンポーネント名・版数／搭載箇所）を埋める
- 使いどころ： 立上げ、対象製品の絞り込み、現場の棚卸し
レベル1：半自動 —「拾える情報はツールで拾う」
- 目的： 人手入力を減らし、更新の抜け漏れを減らす
- 手段： パッケージ管理（依存一覧）やビルド成果物から、OSS情報だけ自動抽出。商用/自社/バイナリは手作業で補完。
- 使いどころ： 最終的には“1つの台帳”に集約する（正本を1つにする）
レベル2：自動（CI生成）—「リリースのたびに勝手に残る」
- 目的： 更新運用を“プロセス化”し、監査・照会に強くする
- 手段： ビルド/リリース工程でSBOM（SPDX/CycloneDX等）を自動生成。製品バージョンと紐づけて保存（アーティファクト管理）。
- 使いどころ： 差分（diff）を見て「何が変わったか」を説明できるようにする
比較表：どこまで自動化するべきか（目安）
| 観点 | レベル0：手作業（Excel） | レベル1：半自動 | レベル2：自動（CI生成） |
|---|---|---|---|
| 目的 | まず答えられる | 手戻り削減 | 更新を仕組みにする |
| 初期工数 | 低〜中 | 中 | 中〜高 |
| 維持工数 | 中〜高（属人化しやすい） | 中 | 低（仕組み化できれば） |
| 更新頻度 | 月次/提出前 | リリースごと（部分自動） | リリースごと（自動） |
| 向く組織 | 兼務・小規模 | 兼務〜中規模 | CI/リリース運用がある組織 |
| 失敗しがち | 更新が止まる | 正本が複数になる | 作るが“使わない” |
ポイント：多くのTier2〜Tier4は、まず レベル0→レベル1 が最短で効きます。
レベル2は「更新の仕組み（リリース運用）が回っている」組織ほど強いです。
やり方：SBOM生成の自動化を“止まらずに”進める5ステップ
Step1：対象製品を絞る（全部やらない）
まずは「OEM照会が多い」「外部IFがある」「売上影響が大きい」製品から。対象を絞るだけで、SBOM運用は一気に現実的になります。
Step2：最小項目を固定する（増やすのは後）
最初に固定すべき最小項目はこれです。
- 製品名 ／ 製品バージョン
- コンポーネント名 ／ コンポーネントバージョン
- 搭載箇所/モジュール（1列でOK）
- 備考（外部IFなし、機能無効、など根拠の一言）
- 更新日／更新者
Step3：半自動化の“入口”を決める（どこから抽出できるか）
半自動化は、まず「拾えるところから拾う」でOKです。
- パッケージ管理の依存一覧（OSSを拾いやすい）
- ビルド成果物・コンテナ（どの版が入ったかを拾いやすい）
- 供給元（Tier上位）からSBOM提供を受ける（商用/バイナリの穴埋め）
重要なのは、自動抽出の結果を“正本（1つの台帳）”に統合することです。正本が複数になると、照会時に必ず矛盾します。
Step4：「製品版数との紐付け」を壊さない（ここが自動化の肝）
SBOMは“コンポーネント一覧”ではなく、どの製品版に入っているかが本体です。自動抽出しても、製品版数に紐づけて保管できないと価値が激減します。
- 生成したSBOMを「製品名×製品版数」で保存
- リリースのたびに“差分”が追える（変更説明ができる）
Step5：更新トリガーをルール化する（運用に落とす）
自動化の最後はツールではなくルールです。最低限この3つを決めます。
- リリース時（製品版数が変わる時）
- OSS更新/供給元更新が入った時
- OEM照会が来た時（影響調査後に備考・根拠を追記）
よくある落とし穴（自動化が失敗する典型）
- SBOMを生成しただけで「運用に入っていない」（更新されない）
- 自動抽出はできたが「製品版数と紐づかない」
- 商用/バイナリ部品が抜けていて、監査で突っ込まれる
- 正本が複数になり、照会のたびに数字が変わる
- “情報量を増やしすぎて”入力が止まる（属性過多）
FAQ：SBOM生成の自動化について
必須ではありません。まずはExcelで「対象製品・版数に答えられる」状態を作り、拾える部分から半自動化するのが現実的です。
目的次第です。CVE照会が目的なら「製品版数×コンポーネント名/版数＋搭載箇所＋根拠（備考）」が最小セットです。属性を増やすほど維持コストが上がるため、必要になったものだけ追加するのがおすすめです。
“正本を1つにすること”と、“製品版数に紐づけて保管すること”です。ここが崩れると照会対応で矛盾が出ます。
自動抽出が難しいことが多いので、供給元からSBOM提供を受けるか、手作業で補完し、正本に統合する設計が必要です。
OEM要求やツール連携次第です。ただし、最初から標準化に寄せて止まるより、Excel→半自動→必要に応じて標準化、の順の方が成功率が高いケースが多いです。
SBOM整備のステップ、一緒に整理しませんか？
自社の体制に合わせたSBOM整備や、ツールの投資範囲をどこから始めるべきか分からない方は、まずは設計パートナー向け説明をご利用ください。