LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

SBOMとは——ソフトウェア部品表によるサプライチェーンリスク管理の基礎

SBOMとは、Software Bill of Materialsの略称で、ソフトウェアを構成するコンポーネント（部品）の一覧表を指します。製造業における部品表（BOM）をソフトウェアに応用したものであり、使用しているOSS（オープンソースソフトウェア）やサードパーティライブラリの名称・バージョン・ライセンス・依存関係などを機械可読な形式で記録します。

SBOMが必要とされる背景——脆弱性管理・ライセンス管理・義務化動向

SBOMへの関心が高まった直接のきっかけは、2021年に発生したLog4Shell（Apache Log4jの深刻な脆弱性）です。多くの組織が自社システムのどこでLog4jを使っているかを即座に把握できず、対応に遅れが生じました。

日本では、経済産業省が2023年7月に「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver.1.0」を公表し、2024年8月には改訂版となる「手引 ver2.0」を公開しました^*1。ver2.0では脆弱性管理プロセスの具体化・SBOM対応モデル・取引モデルが追加されており、ソフトウェアを調達・供給する企業の双方に向けた実務指針が示されています。

IPA（独立行政法人情報処理推進機構）も2024年12月に「SBOM導入・運用の手引き」を公開し、環境構築・SBOM作成・継続運用の3フェーズに分けた実施手順を整理しています^*2。義務化については現時点（2026年6月）で日本国内の法令上の義務はありませんが、政府調達や重要インフラ分野での要件化が議論されており、主要取引先から提出を求められるケースが増えています。

SBOMに記載される情報——コンポーネント名・バージョン・依存関係・ライセンス

SBOMに記録する最低限の要素は、経産省の手引きでも整理されています。主な記載項目は次の通りです。

• コンポーネント名・バージョン：使用しているOSSやライブラリの名称と正確なバージョン番号
• サプライヤー名：コンポーネントを提供している組織または個人
• 依存関係：コンポーネント同士の依存ツリー（直接依存・間接依存）
• ライセンス：GPL・MIT・Apache 2.0など、各コンポーネントに適用されるライセンス種別
• ハッシュ値：改ざん検知に使用する暗号学的ハッシュ（SHA-256等）
• 固有識別子：PURL（Package URL）やCPE（Common Platform Enumeration）などの一意識別子

フォーマットとしては、OWASP主導のCycloneDX（セキュリティリスク管理向け）とLinux Foundation主導のSPDX（ライセンスコンプライアンス向け・ISO/IEC 5962:2021として国際標準化済み）の2つが主流です。どちらを採用するかは、脆弱性管理とライセンス管理のどちらを優先するかによって異なります。

SBOM作成・管理の3つのアプローチ——ツール自動生成・外注・ハイブリッド

SBOMの作成・管理には、大きく「ツールによる自動生成（内製）」「外注・支援サービスへの委託」「ツールと外注を組み合わせたハイブリッド」の3つのアプローチがあります。どのアプローチが適切かは、自社のソフトウェア構成の複雑さ・セキュリティ担当者のスキル・SBOM運用の継続体制によって変わります。

ツール（Syft・CycloneDX・SPDX形式対応ツール）による自動生成——内製の前提スキルと工数

OSS製のSBOM生成ツールとしては、Anchore製のSyftが広く使われています。Dockerイメージや言語パッケージマニフェスト（package.json・go.sum等）を解析し、CycloneDX・SPDX・JSON形式でSBOMを出力できます。ツール自体は無償ですが、導入・設定・CI/CDパイプラインへの組み込みにはコンテナ技術・パッケージマネージャー・セキュリティの知識を持つエンジニアが必要です。

内製でSBOM管理を継続するには、ツールのセットアップだけでなく、CVE（共通脆弱性識別子）データベースとの定期照合・アラート対応・ライセンス問題の法務確認・フォーマット更新への追随といった継続運用が伴います。これらを適切に行うには、セキュリティエンジニアリングとOSS法務の両方に知見を持つ担当者が継続的に関与できる体制が前提となります。

外注・支援サービスへの委託——委託範囲と費用の考え方

外注できる範囲は、初回のSBOM作成のみのスポット委託から、継続的な脆弱性監視・アップデート対応まで多岐にわたります。委託範囲が広いほど費用は増加しますが、社内に専任担当者を置くコストや対応漏れによるリスクと比較して判断する必要があります。

外注先としては、セキュリティ専業ベンダー・IT系SIer・ソフトウェア開発会社などが対応しています。対象システムを開発・保守しているSIerに同時依頼するケースでは、システム構成の把握コストが削減でき、見積もり精度も高まります。

ハイブリッド運用——ツール＋ベンダー支援の組み合わせ

実務上多いのは、SBOM生成ツールを自社で導入・運用しつつ、脆弱性対応の判断・ライセンス法務確認・レポーティングをベンダーに委託するハイブリッド型です。ツールの初期セットアップやCI/CDパイプラインへの組み込みをベンダーに依頼し、日常の自動スキャンは内製で回すという分担も選択肢の一つです。

IPA「SBOM導入・運用の手引き」（2024年12月）でも、導入フェーズを「環境構築・体制整備」「SBOM作成・共有」「SBOM運用・管理」の3段階に分けており、フェーズごとに内製と外注の組み合わせを検討することが推奨されています^*2。

SBOM外注費用の市場参考値と費用に影響する要素

SBOM外注費用に関する公的な統計や標準的な費用調査は現時点では存在しないため、以下は市場に流通している公開情報をもとにした参考値です。一次資料による費用相場ではありません。実際の費用は対象システムの規模・複雑さ・委託範囲によって大幅に変わります。

初期導入費・月額管理費・スポット作成費の目安（市場参考値）

上表はAGESTが2025年に発表した国産SBOMツール・支援サービスの価格を参考に整理した市場参考値です^*3。一次資料に基づく業界標準費用ではありません。大規模システムや複数プロダクトを対象とする場合、個別見積もりが基本になります。

費用を左右する5つの要素——システム規模・フォーマット・更新頻度・対応ツール・契約形態

外注費用に影響する主な要素を以下に整理します。事前にこれらを把握しておくと、複数ベンダーへの見積もり依頼時に条件を統一できます。

• システム規模・コンポーネント数：依存ライブラリが多いほどスキャン・検証コストが増加します
• SBOMフォーマット：CycloneDX・SPDX・独自形式など、取引先が求めるフォーマットへの変換対応が必要な場合は費用が上乗せされます
• 更新頻度：リリース都度の更新か、月次・四半期更新かで月額費用が変わります
• 対応ツール・環境：既存の開発環境（GitHub Actions・Jenkins等のCI/CD）への組み込み難易度によって初期費用が変動します
• 契約形態：準委任・請負・SaaS型サービスの月額利用など、契約形態によって費用精算の仕組みが異なります

外注委託先の選定基準——経産省手引きを踏まえたチェックポイント

委託先を選ぶ際は、費用だけでなく技術・体制・契約の3つの軸で評価することが大切です。経産省「SBOM手引き ver2.0」（2024年8月公表）では、SBOM取引時に発注者・受注者間で確認・合意すべき事項が整理されており、委託先選定の判断基準として活用できます^*1。

経産省手引きが示す「発注者が確認すべき事項」

経産省手引き ver2.0では、SBOMを外部調達・外注する場合の契約上の確認事項として次の点が挙げられています。

• SBOM要件の明示：どのフォーマット（CycloneDX/SPDX）・どの粒度（直接依存のみ/推移的依存を含む）のSBOMを求めるかを契約時に明記する
• 責任分担の明確化：SBOM作成・更新の責任範囲（発注者・受注者のどちらが担うか）を契約に明記する
• 費用負担の合意：SBOM対応に伴う追加費用の負担先を事前に取り決める
• 知的財産権の帰属：生成されたSBOMデータの権利がどちらに帰属するかを明確にする
• 継続更新の義務：ソフトウェアのバージョンアップ・コンポーネント変更時のSBOM更新を受注者に義務づけるかを定める

委託先ベンダーに確認すべき技術・体制・契約の3点

上記の経産省手引きの観点に加え、委託先候補に対して次の3点を確認することを推奨します。

（1）技術面：対応可能なSBOMフォーマット（CycloneDX/SPDX）と生成ツール（Syft・Trivy・Black Duck等）を明示できるか。CVEデータベース（NVD・JVN等）との自動照合に対応しているか。対象システムの開発言語・ビルド環境（Java/Node.js/Python/Goなど）に対応実績があるか。

（2）体制面：SBOMを専門とするエンジニアが在籍しているか。脆弱性が検出された際の報告・エスカレーション経路が整備されているか。ライセンス問題が発生した際に法務的な助言ができる体制があるか。

（3）契約面：SBOM作成・更新の成果物の定義と納期が明確か。脆弱性発見時の対応SLAが設定されているか。機密情報を含むソースコード・依存情報の取り扱いについてNDA（秘密保持契約）が締結できるか。

内製か外注かを判断するフレームワーク

SBOMを内製するか外注するかは、コストだけでなくリスクとリソースのバランスで判断します。以下に、外注を検討すべき状況と内製が現実的な状況を整理します。

外注を検討すべき5つのケース

次のいずれかに該当する場合は、外注または支援サービスの活用を検討する価値があります。

• セキュリティ担当者が不在・兼務：SBOM作成・管理を専任で担える人材がおらず、他業務との並走で対応漏れが生じる可能性がある場合
• 対象システムが複数・多言語：Java・Python・Node.js・Goなど異なる言語・ビルドシステムが混在しており、ツールの設定・検証に工数がかかる場合
• 取引先・顧客からSBOM提出を求められた：特定のフォーマット・粒度・納期でSBOMの提出を求められており、即座に対応できない場合
• 脆弱性対応の優先順位付けが難しい：CVEスコアだけでは対応優先度が判断できず、コンテキストに応じたトリアージが必要な場合
• ライセンスコンプライアンスへの不安：GPLなどのコピーレフトライセンスの取り扱いが自社では判断しきれない場合

LASSICのSBOM支援——元請（プライムベンダー）として対応できる範囲

LASSICは、元請（プライムベンダー）としてシステム開発・保守・運用を受託しており、対象システムのコード構成・ビルド環境・リリースプロセスを把握した状態でSBOM作成・管理支援に対応できます。開発・保守と同一ベンダーがSBOMを担うことで、コンポーネント変更時の即時更新やトリアージ精度の向上が期待できます。

SBOM支援の範囲や費用については、対象システムの規模・現在の開発環境・求められるフォーマットによって個別に異なります。まずはお問い合わせフォームからご状況をお知らせください。

まとめ——SBOM外注判断の3つの軸

本稿では、SBOMの基礎から作成・管理のアプローチ・外注費用の市場参考値・委託先選定基準・内製か外注かの判断フレームワークまでを整理しました。要点を3つにまとめます。

第一に、SBOMは経産省・IPAの両機関が手引きを整備するほど実務上の重要性が高まっており、取引先からの提出要請も増えています。現時点で日本国内の法令義務はありませんが、先行対応が取引上のリスク回避につながります。

第二に、外注費用は対象システム数・フォーマット・更新頻度・委託範囲によって大きく変わります。公的な費用相場データは現時点では存在しないため、複数ベンダーに要件を揃えた上で見積もりを取り、比較することが現実的です。

第三に、委託先は費用だけでなく技術・体制・契約の3軸で評価します。経産省手引き ver2.0が示す契約時の確認事項（フォーマット要件・責任分担・継続更新義務など）を発注側が把握した上で交渉に臨むことで、後のトラブルを防ぐことができます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0（プレスリリース）」（2024年8月）
2. *2　出典：IPA 産業サイバーセキュリティセンター「SBOM導入・運用の手引き」（2024年12月）
3. *3　出典：IT Leaders「AGEST、日本語に対応した国産のSBOM管理ツールを発表、2026年1月より月額5万円で提供」（2025年）— 市場参考値・一次資料ではありません

Tweet