-製造業が今すぐ取るべき次の一手-

世界が動くSBOM義務化の波

  • 2025-11-17

はじめに

いま、IoT機器を製造している企業の経営層が注目すべきキーワードの一つがSBOM(Software Bill of Materials:ソフトウェア部品表)です。SBOMは、製品やシステムに含まれるソフトウェア部品を可視化する仕組みで、近年増加しつつあるサプライチェーン攻撃の拡大を防ぐことや既知脆弱性の連鎖的な波及を早期に特定・対処するための手段の一つとして注目されています。また昨今は国際的な動きが活発化しており、調達要件としてSBOMの義務化が現実視される状況です。

本稿は、「SBOMに関して理解しておくべき国内外の動向」と、「なぜ今SBOMを経営課題として捉え、早急に取り組む必要があるのか」について解説します。

※SBOMについては、SBOM普及の本格化~ソフトウェアサプライチェーンの構造的な課題と解決策~を参照ください。

1章:日本政府の動向

2025年9月、経済産業省(METI)は内閣官房国家サイバー統括室(NCO)とともに、ソフトウェアの脆弱性管理等におけるSBOM(ソフトウェア部品表)の活用の重要性を示す国際ガイダンスである「A Shared Vision of Software Bill of Materials(SBOM)for Cybersecurity」へ共同署名を行いました※1。この国際ガイダンスは、米国を含めた15カ国のサイバーセキュリティ当局等が参加し、SBOMの活用の重要性を広く国際的に発信するとともに、SBOM運用上の国際共同ガイダンスを整備することを目的として作成されています。今後は、より技術的な内容の具体化に向け国際議論を継続すると公表しており、技術要件での意見が分かれるSBOMの領域において注目が集まっています。

これは、SBOMが国際的な標準として位置付けられ、政府調達や重要インフラあるいは民間の取引上の製品の調達条件にSBOMが組み込まれる可能性を示唆しています。またMETIが本取り組みを推進していることから、日本企業においてもSBOMはもはや他人事ではなく、自社のこととして義務化を見据えた準備を始める必要があります。

2章:CISAによる最小要素の引き上げ

SBOMの「構成要素」は、ソフトウェアコンポーネントの情報として記載すべき内容を示すものですが、これまでは米国大統領令(Executive Order 14028)の下、NTIA(National Telecommunications and Information Administration)が策定したガイドラインである「The Minimum Elements For a Software Bill of Materials(SBOM)」※2が国際的な1つの指標とされていました。しかし2025年8月、NTIAから本取り組みに関する役割を引き継いだ米国CISA(Cybersecurity and Infrastructure Security Agency)は「2025 Minimum Elements for a Software Bill of Materials(SBOM)」※3の草案を公表し、その水準を引き上げる方向性を示しました(併せてパブリックコメントの受付を実施)。この草案では、従来の要素に加え、以下図表1の4つの情報を新たに含めることとしています。

図表1:2025 Minimum Elements for a Software Bill of Materials(SBOM)で新たに追加された要素

追加された要素 説明
Component Hash
コンポーネントのハッシュ値
ソフトウェアコンポーネントのハッシュを取得して生成される暗号学的な値
License
ライセンス
ソフトウェアコンポーネントが提供される際のライセンス情報
Tool Name
ツールの名称
SBOMを生成するために作成者が使用したツールの名称
Generation Context
生成コンテキスト
ソフトウェア製造者がSBOMを生成した時点における、ソフトウェアのライフサイクル上の相対的なフェーズ(ビルド前、ビルド中、ビルド後)およびその時点で利用可能なデータ

なかでも特筆すべきは、SBOMの構成要素に「ライセンス情報」が追加されたことです。これは単なる技術的な拡張ではなく、法務・収益リスクの管理についてもSBOMによって対応する必要性があることを意味します。従来のSBOM、つまりNTIAの最小要素は、セキュリティの文脈である「脆弱性管理」を主な目的としていましたが、ライセンス情報の追加により、知的財産リスクやコンプライアンス違反の予防がSBOMの役割に加わることとなります。

さまざまな製品のソフトウェア開発におけるOSS(オープンソースソフトウェア)の利用が増える中、ライセンス違反は、訴訟・製品回収・輸出停止といった重大な経営リスクを招きます。今後SBOMを製品の安全性だけでなく、合法性を証明する台帳としても利用することが、世界的な潮流となるかもしれません。

3章:SBOM義務化の波が意味するところ

METIが国際ガイダンスに共同署名し、CISAがSBOMの最小要素を引き上げたことは、グローバル全体でSBOMに対する注目・関心が高まっていることを意味しています。これはつまり、欧州CRA(EU Cyber Resilience Act※4)のような法令による明確なSBOMの義務化が、調達・輸出・認証などの要件としてグローバル全体に波及していく可能性があることを示唆します。

さらに重要なのは、義務化の波が単なる規制対応にとどまらず、企業の競争力やブランド価値にも影響する可能性を帯びている点です。SBOM義務化への企業の対応が問われますが、その対応の違いによって生じる影響は図表2のとおりです。

図表2:SBOM義務化への対応の違いによる影響のまとめ

義務化に対応できた場合の効果 義務化に対応できなかった場合のリスク
市場への参入権の獲得 受注機会の逸失
ブランド価値の強化 説明責任の欠如
自社製品リスクの低減 現場オペレーションの混乱と品質低下

義務化に対応できた場合の効果

  • 市場への参入権の獲得:日本および世界各国において、将来的に調達要件にSBOMが含まれた場合も即座に対応が可能となり、入札等での「不戦敗」を回避できます。また、調達要件に含まれていない場合でも、対応していない企業と比較して、自社製品の透明性と安全性を担保していることをアピールポイントして打ち出すことができ、結果として競争優位性を高めます。
  • ブランド価値の強化:SBOMについて誠実に対応を行い、透明性と安全性を説明できる企業は、顧客や規制当局から信頼を獲得し、ブランドイメージを向上します。
  • 自社製品リスクの低減:SBOM対応により社内の脆弱性対応プロセスやライセンス管理が向上することで、自社製品に含まれるソフトウェアを起因とした回収・訴訟・罰金のリスクが低減します。

義務化に対応できなかった場合のリスク

  • 受注機会の逸失:調達要件等でSBOM提出が前提・標準化すれば、未対応企業は主要市場への参入権そのものを失います。結果として、売上の柱となるグローバルマーケットや公共調達などの市場での後れを取り、長期的な収益基盤が崩れる可能性があります。
  • 説明責任の欠如:SBOM未対応の製品は、サイバーインシデントやライセンス違反が発覚した際、それらの対処・対応に後れを取るだけでなく、製品の透明性と安全性を担保する企業責任を怠ったとして、罰則が発生する可能性があります。また、これらの事実が発覚後、顧客・取引先からの信用を失い企業の競争力が低下するおそれがあります。
  • 現場オペレーションの混乱と品質低下:義務化が進んだ後に慌ててSBOM対応を始めると、開発現場は既存プロセスを急いで変更することになります。ツール導入・契約見直し・人材教育等を短期間で詰め込む結果、現場が混乱し、納期遅延や品質低下を引き起こす可能性があります。

以上のように、SBOM義務化に対応することは、市場・説明責任・競争力の観点からも重要だと考えるべきでしょう。

4章:義務化に対応するには

ここまで、SBOM対応の重要性について説明しました。一方で、その重要性は認識しつつも、「本格的な対応はまだ先のこと」と考えている方も多いのではないでしょうか。しかし、その「様子見」は、将来のビジネスにおける致命的な足かせとなりかねません。なぜなら、SBOM対応とは、単にツールを導入すれば解決するものではなく、「開発プロセス」と「サプライチェーン」への対応が必要となり、中長期的な時間を要するためです。

SBOM対応の核心は「開発プロセス」への組み込みに

まず認識すべきは、SBOMは単に作成すればよいという成果物ではないという事実です。SBOMはむしろ、製品のライフサイクル全体を通じてソフトウェアの構成要素を継続的に管理し、リスクを監視するための「仕組み」だと言えます。

そのためには、ソフトウェアに用いられている部品を設計段階から正確に把握して開発を行うこと、またそれらのライセンスや脆弱性に関する情報まで整理して可視化することが求められます。さらにこの作業を既存の開発プロセスに組み込んでいくことも必要です。

これは、単に新しいツールを導入すれば済むという話ではありません。開発者の意識改革、プロセスの標準化など全社的にガバナンスを利かせていくことが不可欠です。具体的な施策としては、ツールの選定・導入にはじまり、開発チームへのトレーニング、そして新たな業務を加えた新プロセスの定着などがあり、少なくとも1~2年の期間を要すると理解しておく必要があります。

また、さまざまな社内関係者がSBOMにアクセス・活用できる仕組みを構築することも重要です。脆弱性管理の文脈であれば、セキュリティを担当している部門、もしくは製品を開発している部門がSBOMを管理・運用していれば問題ありませんでした。しかしライセンス管理までを含めた対応を行う場合には、法務や知的財産部門のような組織もSBOMについて理解し、活用できる環境・体制を整える必要があります。このような社内での部門間の連携体制および環境構築に期間を要することは言うまでもありません。

障壁は「サプライチェーン」との調整

また対応を進めていく上での大きな障壁は、サプライチェーンです。企業の製品は、自社で開発した部分だけでなく、多数のサプライヤーから供給される部品やソフトウェアの集合体で成り立っています。つまり、自社のソフトウェア構成を完璧に把握するのはもちろんのこと、サプライヤーから提供される部品のSBOMを収集することが、製品全体の透明性を担保する上では不可欠なのです。

しかし、サプライヤーからSBOMを集めるにあたっては、次のようなことを実施しなければなりません。

  • SBOM提出を義務付ける契約見直し・調整
  • 提出してほしいSBOMの形式・フォーマットの検討
  • 提出されたSBOMを確認し、部品に問題がないか検証する方法の確立

特に、SBOM対応が困難な中小サプライヤーや、商習慣の異なる海外サプライヤーにまで対応を徹底させるには、粘り強い交渉と、時には支援が必要になる場合もあります。サプライチェーン全体の調整を行うには、腰を据えた時間投資が不可欠なのです。

まとめ

米国CISAによる最小要素の引き上げや日本政府の国際ガイダンス共同署名は、SBOMが「任意」ではなく「必須」へと移行する流れを示しています。特にライセンス情報の追加は、セキュリティにとどまらず、製品の法務・コンプライアンスリスクの管理までを企業全体として取り組まなければならないことを示した大きな転換点です。この流れを理解し、開発プロセスへの組み込みとサプライチェーンへの調整などの対応を早期に開始することで、調達要件への即応、ブランド価値の強化、リスク低減という競争優位性を獲得することが可能です。

自社製品のソフトウェア構成管理の棚卸し、小規模でのSBOMの生成、フォーマットやツール選定を含む概念実証(PoC)の更新、サプライヤーとの調整など、実施しなければならないことは多岐にわたりますが、SBOM対応を加速するためには、まず経営層が旗を振り、全社的な優先課題として位置付けることが不可欠です。その上で、製品セキュリティ・品質保証・法務・調達を横断する責任者を指名し、推進体制を整備することこそ、SBOM対応への第一歩です。

参考文献

※1 経済産業省,2025,「サイバーセキュリティのためのソフトウェア部品表(SBOM)の共有ビジョンに関する国際ガイダンスに共同署名しました」
https://www.meti.go.jp/press/2025/09/20250904001/20250904001.html

※2 NTIA, 2021, 「The Minimum Elements For a Software Bill of Materials (SBOM)」
https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf

※3 CISA,2025 「2025 Minimum Elements for a Software Bill of Materials (SBOM)」https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom

※4 European Union, 2024, 「Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)」
https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

執筆者

大西 功輝

マネージャー, PwCコンサルティング合同会社

Email

桑尾 将史

シニアアソシエイト, PwCコンサルティング合同会社

Email

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

本ページに関するお問い合わせ