SBOM運用コストの現実
Excel管理・半自動化・自動化の工数比較

SBOM運用コストを決めるのは「生成」ではなく5つの反復作業

SBOM運用の工数は、主に次の5つで決まります。

1. 部品・依存関係の把握とSBOM生成
   NTIAのSupplier Playbookでは、SBOM生成を「対象コンポーネントの特定」「構成データの取得」「構造化フォーマットへの取り込み」「妥当性確認」という流れで整理しています。
2. 更新
   NTIAのFormats and Standards調査では、SBOMはソフトウェアやその基盤コンポーネントが更新されたら、それに合わせて更新されるべきだとされており、さらにコードが変わっていなくても、宣言情報の修正や誤り訂正でSBOMを更新する場合があると説明されています。つまり、運用負荷はリリース回数だけでは決まりません。
3. 配布と履歴管理
   SBOMは製品と一緒に渡すだけでなく、サプライヤーポータル、事前合意した保管場所、第三者管理領域など、複数の配布形態がありえます。過去時点の構成確認が必要になる場面も想定されており、履歴をどう残すかも運用コストに入ります。
4. 消費側の突合と再利用
   NTIAのConsumer PlaybookやFormats and Standards調査では、SBOMの実運用には、取得、解析、エンティティ解決、他システムへのデータ連携、継続監視が含まれ、資産管理、脆弱性管理、構成管理、インシデント対応などに接続されることが前提になっています。しかも、効果的に使うには machine-readable で、機械同士の自動処理に組み込めることが重要だとされています。
5. 顧客提出と社内承認
   SBOMは調達前、納入時、更新時に提供されることがあり、契約や要求仕様によって提出タイミングや粒度が変わります。実務では、ここにOEMごとの整形、差分確認、承認が乗るため、単純なファイル生成以上に手間がかかります。

3つの運用パターンを先に定義する

この記事では、SBOM運用を次の3つに分けます。

比較の前提条件

以下の工数は、10〜30製品程度のソフトウェア/ファームウェア搭載製品を持ち、月2回前後の更新または再ビルドがあり、OEMや顧客から月2〜4回程度のSBOM提出・再提出・差分確認依頼がある中小サプライヤーを想定した実務上の目安です。

※深いフォレンジック調査や大規模インシデント対応は含めていません。

Excel管理・半自動化・自動化の工数比較

この表で重要なのは、Excelが必ず悪いわけではないという点です。
Excel管理は、最初の棚卸しや、対象製品がごく少ない段階では十分に機能します。問題は、SBOMが「更新され続ける文書」になった瞬間に、手間が指数的に増えやすいことです。

Excel管理が一番高くつく理由

Excel運用は、見た目には安く始められます。ですが、運用負荷は次の4点で急に上がります。

• 更新のたびに人が触る箇所が多い
  SBOMはソフト更新時だけでなく、依存関係の追加、宣言情報の修正、誤り訂正でも更新が発生します。そのたびにExcelで転記、整形、確認をしていると、件数が少なくても毎月の固定負荷になります。
• 旧版との比較が重い
  差分確認は、OEMから「前回版から何が変わったか」を聞かれた時に必ず発生します。機械可読フォーマットを原本として持っていないと、バージョン差分は目視または関数頼みになり、品質保証担当や情シス担当の時間を食います。
• 提出のたびにファイルが増殖する
  提出先ごとに列を隠す、備考を加える、日付を直す、といった作業が起きると、「どれが原本か」が曖昧になります。履歴管理が難しくなり、監査や再照会で逆に時間がかかります。
• 属人化
  更新ルール、命名規則、提出手順がExcelファイルの中に埋まるため、担当者が休むだけで止まりやすくなります。

つまり、Excel管理の本当の問題はライセンス費用ではなく、更新・差分・提出の反復作業を人力で抱え込むことです。

---

半自動化が中小サプライヤーの現実解になりやすい理由

半自動化では、SBOMの原本生成と保管を機械可読で行い、提出・承認・例外判断だけを人が持ちます。

この形にすると、少なくとも次の3つが楽になります。

• 更新時に原本を作り直す手間が減る
• 旧版との差分を取りやすくなる
• OEM提出用の加工を「原本から作る」前提にできる

NTIAのFormats and Standards調査でも、SBOMの利用価値を最大化するには machine-readable であること、消費側が自動処理に組み込めることが重要だとされています。また、SBOMツールの分類では、生成、比較、取り込み、変換、マージ、他ツール連携といった機能群が整理されており、実務上はこのうち全部を一気に導入しなくても、生成・保管・比較の3つを押さえるだけで工数はかなり下がります。

半自動化が向いているのは、次のような会社です。

中小サプライヤーでは、ここを飛ばして最初から完全自動化を狙うより、半自動化で原本管理を整え、提出や突合の痛い部分から順に自動化する方が成功しやすいです。

自動化で下がるのは「更新工数」だけではない

自動化の価値は、単にSBOMを早く作れることではありません。
本当に効くのは、更新、比較、再利用、監視がつながることです。

NTIAのConsumer Playbookでは、SBOMの利用は取得して終わりではなく、解析、エンティティ解決、CMDB・SOC・SAMへのデータ連携、継続監視へ進む流れが示されています。SBOMを脆弱性管理や資産管理に組み込むなら、ファイルを保管するだけでは足りず、継続的に再利用できる状態で持つ必要があります。

自動化のROIが出やすいのは、次のような状態です。

• 製品更新や再ビルドが毎月ある
• 同じ製品を複数OEMや顧客に出している
• 「このバージョンは影響を受けるか」の再照会が多い
• 過去版のSBOMをすぐ出せる必要がある
• SBOMを脆弱性管理やインシデント対応へつなげたい

ただし、自動化してもゼロ工数にはなりません。
製品の対象範囲判断、秘匿情報の扱い、提出先ごとのアクセス制御、例外承認、誤記修正は残ります。NTIAの minimum elements でも、practices and processes の中に、frequency、distribution and delivery、access control、accommodation of mistakes が含まれています。つまり、自動化の本体はツール導入だけではなく、運用ルールの標準化です。

どこで移行を判断するか

判断基準は、難しく考えなくて大丈夫です。
次の4つが増えてきたら、Excelから移るタイミングです。

この状態でExcelを続けると、表面的なツール費用は安くても、実際には品質保証、情シス、設計の兼務工数が積み上がります。
逆に、まだ製品数が少なく、提出も年に数回で、まず構成の見える化をしたいだけなら、Excelで始めても問題ありません。ただし、その場合でも原本をどこで持つか、命名規則をどうするか、旧版をどう残すかは最初に決めておくべきです。

まとめ

SBOM運用コストを比較するときに見るべきなのは、ツールの価格表ではありません。
本当に見るべきなのは、更新、提出、差分確認、履歴管理、再利用を毎月どう回すかです。

SBOMは「あるかどうか」よりも、いつでも更新できるか、すぐ提出できるか、過去版と比較できるかで価値が決まります。

その意味では、運用設計ができていない状態でツールだけ入れても成果は出ませんし、逆に原本管理と差分管理の設計ができていれば、半自動化だけでもかなり戦えます。