ホーム > blog > SCS制度・SBOMとサイバーDDの実務解説｜契約・保険・企業価値への影響【2026年最新版】

SCS制度・SBOMとサイバーDDの実務解説｜契約・保険・企業価値への影響【2026年最新版】

2026.05.07UP!

• blog
• M&A法務
• SBOM
• SCS制度
• サイバーデューデリジェンス
• サイバー保険
• サプライチェーンリスク
• 経済安全保障

この記事では、SCS制度、SBOM、サイバーDDが企業の契約実務や企業価値評価にどのような影響を与えるかについて、法律等の側面から解説する。

「Trust me」から「Verify me」へ。サイバーセキュリティは、努力目標としての「防御」から、契約・DD・保険引受で再利用される「検証可能なリスク情報」へと変質しつつあります。SCS制度はその日本版シグナルといえる。

サイバーセキュリティは、努力目標としての「防御」から、契約・DD・保険引受で再利用される「検証可能なリスク情報」へと変質しつつある。SCS制度はその日本版シグナルである。

記事全体の構造（最重要）

この記事は、以下の三層構造で読む。

レイヤー	役割	位置づけ
契約・DD・保険	「説明しろ」という圧力	説明責任を要求する側
SCS	要求水準を共有する契約言語	標準化された共通言語
SBOM	実態を立証する技術証跡	技術的立証を担う

つまり、契約・DD・保険が「説明責任」を要求し、SCSが「要求水準」を標準化し、SBOMが「技術的立証」を担う。

第1章　はじめに——「Trust me」では足りない時代になる。

【結論】現代のサイバーセキュリティは、自己申告型の信頼（Trust me）から、客観的な証拠に基づく検証（Verify me）へと移行しています。複雑化したサプライチェーンにおいて、第三者が検証可能な形で対策状況を示すことが、取引継続や企業価値維持の必須条件となっています。

サイバーセキュリティの歴史は、「Trust me（信頼して）」から「Verify me（証明して）」への移行として捉えると理解しやすい。従来は「対策しています」という自己申告でも一定の信頼が成立した。SOC2 Type2、ISMS、ISOといった認証も、その信頼を補強する手段として機能してきた。

もっとも、複雑化したサプライチェーン、OSSやクラウドへの依存拡大、AIエージェントや外部APIの利用増加によって、単発の認証や年次監査だけでは実態を把握しきれなくなっている。加えて、M&A、サイバー保険、重要インフラ規制、経済安全保障政策の強化によって、「本当に管理できているのか」「事故発生時に迅速に修復可能か」を継続的に説明する必要性が高まった。

その結果、企業は単に「認証を持っているか」ではなく、「どのソフトウェアを使い、どの脆弱性に晒され、どの程度の証跡を提示できるか」を第三者が検証可能な形で示すことを求められるようになっている。

しかし現在

以下の環境変化により、「第三者が検証可能か」が決定的に重要になった。

• サプライチェーンの複雑化
• OSS依存の深化
• AIエージェントの台頭
• M&Aの増加
• サイバー保険の厳格化

この変化を日本で制度化する動きが、SCS（サプライチェーン強化に向けたセキュリティ対策評価制度）制度である。

第2章　SCS制度は「評価制度」ではなく「契約言語」となる

【結論】SCS制度（サプライチェーン強化に向けたセキュリティ対策評価制度）の本質は、企業間の取引において「どの程度の管理水準を求めるか」を標準化する契約言語です。これにより、委託元と委託先の双方が同じ物差しでセキュリティ要件を合意することが可能になります。

SCSの本質は「格付」ではなく、契約で要求水準を共有することにある。

IPA/METIの想定運用は、委託元が委託先に対して要求水準を提示する形だ。つまりSCSは、「どのレベルの管理と証跡を要求するか」を標準化するツールである。

SCS制度は「あなたの会社は何点か」を示す制度ではない。むしろ、「この取引では、どの程度の管理・証跡・確認可能性を求めるのか」を、委託元と委託先が共有するための標準言語である。

従来、委託元は「委託先のセキュリティが十分か」を外部から判断しづらく、委託先は複数の取引先からバラバラのチェックリストや要求事項を求められるという問題を抱えている。IPAも、委託元側の課題として「委託先のセキュリティ対策が可視化しづらいこと」、委託先側の課題として「様々な委託元から様々な要求事項を求められ、過度な負担につながること」を挙げている。

その混乱を整理するのがSCS制度である。

SCSは単なる認証マークではなく、2社間契約や調達の場面で、委託元・発注者と委託先・受注者が求める管理水準を共有し、実施状況を確認するための共通物差しとして設計されている。こうした評価情報は、制度上の直接目的ではないものの、実務上はサイバーDDや保険引受においても、対象企業の管理水準を確認する参照情報となり得る。なお、現時点で制度の中心は★3・★4であり、★5は今後さらに具体化される予定である。

ここでいう契約言語とは、契約書に直接「★4を取得せよ」と書くという狭い意味だけではない。委託元が委託先に対して、どの水準のサイバーセキュリティ対策を求めるのか、その水準をどう確認するのか、どの程度の証跡を提出させるのかを、取引関係の中で共有するための標準化された言葉である。

経済産業省・IPAが想定している運用も、まさにこの構造である。SCS制度は、2社間の取引契約等において、委託元が委託先に適切な段階、すなわち★を提示し、示された対策を促すとともに、実施状況を確認することを想定している。したがって、SCSは「企業を上から評価する制度」ではなく、「取引に必要な管理水準をそろえる制度」と理解した方が実務に近い。

ポイントは、★が高いほど「偉い会社」という話ではない。IPAは、上位段階は下位段階の事項を包括するものの、★3を先に取らなければ★4を取れない関係ではないと説明している。これは、SCSが企業の序列化ではなく、取引リスクに応じた要求水準の選択制度であることを示している。

契約条項チェックリスト（SCS対応必須項目）

契約時に何を示し合意するか

• 要求水準提示（★3〜★5の明確な指定）
• 証跡提出義務
• 再委託フローダウン
• インシデント通知義務
• 是正計画の提出・実施義務
• 監査対応（リモート/オンサイト）
• 重要変更時再評価

SCSは「★4を取ったから安心」というものではない。「この契約では★4相当の管理と証跡を要求する」と明記し、双方が同じ言語で合意するための装置である。

第3章　SBOMは技術文書ではなくDD資料となる

【結論】SBOM（ソフトウェア部品表）は、開発者のためのメモではなく、買主や監査者に対して「ソフトウェアの構成とリスク」を説明するための証跡台帳です。M&A実務においては、ソフトウェアにおける「簿外債務調査」と同様の役割を担います。

SBOMが「何を使っているか」を説明する資料だとすれば、SCS制度は「どの水準で管理しているべきか」を示す契約言語である。両者は、制度紹介として並列に置くものではない。契約・DD・保険で説明を求められる時代に、企業がその説明責任を果たすための道具として理解すべきである。

政策の時系列 vs 実務の因果（重要ブリッジ）

政策の時系列だけを見ると、SBOMが先に見える。経済産業省は、SBOMをソフトウェア管理や脆弱性管理のための手段として「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を整理し、2024年の手引ver.2.0では、SBOMに関する要求事項、責任、コスト負担、権利などを契約に規定するための「SBOM取引モデル」も追加している。つまり、制度・政策の公表順としては、まずSBOMという技術的・管理的な概念が整備され、その後、SCS制度のようなサプライチェーン全体の評価・可視化制度が整備されているように見える。サイバーセキュリティのためのソフトウェア部品表（SBOM）の共有ビジョンに関する国際ガイダンス

しかし、実際は逆である。

企業の現場では、まず契約、サイバーDD、保険、調達審査の場面で、次のような問いが突きつけられることになる。
「このシステムには、どのOSSが使われているのか」「既知の脆弱性は残っていないのか」「脆弱性が見つかった場合、誰が、いつ、どの範囲で修復するのか」「委託先・再委託先を含めて、どこまで把握できているのか」「事故が起きた場合、説明できる証跡は残っているのか」。

これらの問いに答えるための重要な証跡の一つがSBOMである。SBOMは、単なる開発者向けの部品表ではない。CISAもSBOMを、ソフトウェア・セキュリティおよびソフトウェア・サプライチェーン・リスク管理における重要な構成要素と位置づけている。

したがって、SBOMの実務的意味は、「何を使っているか」を第三者に説明するための証跡台帳にある。具体的には、ソフトウェア構成、OSS依存、ライセンス、既知脆弱性への露出、影響範囲、対応履歴を説明するための基礎資料である。ただし、修復責任、対応期限、委託先管理、事故時の説明責任までを示すには、SBOMに加えて、脆弱性管理プロセス、契約条項、ログ、IR手順、委託先管理台帳と接続する必要がある。

この意味で、SBOMはサイバーDDにおいて、ソフトウェア版の簿外債務調査に近い役割を持つ。財務DDでは、貸借対照表に明示されていない偶発債務、保証債務、未認識リスクを確認する。同じように、サイバーDDでは、ソースコードや利用システムの中に埋め込まれているOSS、古いライブラリ、未修復の脆弱性、ライセンス違反リスク、保守不能な依存関係を確認する。

つまり、SBOMがない状態とは、ソフトウェアの中にどのようなリスクが眠っているかを、買主・委託元・保険者・監査者に説明できない状態である。逆にSBOMが整備されていれば、企業は「このソフトウェアには何が含まれ、どのリスクがあり、どこまで対応済みか」を一定の形式で説明できる。

SCS制度とSBOMの役割分担

ここでSCS制度との役割分担が明確になる。SBOMが「何を使っているか」を説明する資料だとすれば、SCS制度は「どの水準で管理しているべきか」を示す契約言語である。SCS制度について、経済産業省・IPAは、2社間の取引契約等において、委託元が委託先に適切な段階、すなわち★を提示し、示された対策を促し、実施状況を確認する運用を想定している。また、同制度は企業のセキュリティ対策レベルを競わせる格付け制度ではないと明記されている。

したがって、両者は並列に置くものではない。SCS制度は、委託先にどのレベルの管理体制・証跡・確認可能性を求めるかを共有するための言語である。SBOMは、その要求に対して、ソフトウェア構成・脆弱性・修復状況を具体的に示すための証拠である。

実務上の問いと必要になる道具

実務上の問い	必要になる道具	役割
どの水準の対策を求めるのか	SCS制度	要求水準の共有
何を使っているのか	SBOM	構成要素の可視化
どこに脆弱性があるのか	SBOM＋脆弱性管理	リスクの特定
直したのか、放置しているのか	SBOM＋対応履歴	修復状況の説明
契約上、誰が責任を負うのか	契約条項	責任・費用・報告義務の分配
DD・保険で説明できるのか	SBOM＋SCS＋証跡	第三者説明

要するに、SCS制度は「要求水準」、SBOMは「技術立証」である。この2つがそろって初めて、企業は契約・DD・保険の場面で、サイバーセキュリティについて説明可能になる。

SBOMの実務的意味とDDでの役割

SBOMの実務的意味

• ソフトウェア構成の可視化
• OSS依存の把握
• 脆弱性露出の特定
• 修復状況の追跡

DDでの役割：SBOMは「ソフトウェア版の簿外債務調査」に近い。

AI時代への拡張：

SBOMの考え方は、AI時代にはさらに拡張される。従来のSBOMが、ソフトウェア部品、ライブラリ、OSS、依存関係を可視化するものだとすれば、AI-BOMやML-BOMは、そこにモデル、学習データ、データ由来、モデルの系譜、設定、評価指標、外部依存コンポーネントを加えて管理する方向に進む。

今後のDDは、単に「どのソフトウェアを使っているか」を見るだけでは足りない。AIを組み込んだシステムでは、次のような問いが追加される。

従来のSBOMで問うこと	AI-BOM / ML-BOMで追加されること
どのOSS・ライブラリを使っているか	どのモデルを使っているか
バージョンは何か	モデルのバージョン・由来は何か
既知脆弱性はあるか	モデルリスク・プロンプト攻撃・データ汚染リスクはあるか
ライセンス違反はないか	学習データ・利用データの権利処理はどうなっているか
パッチ適用済みか	再学習・評価・モニタリングはされているか
依存関係は何か	外部API、基盤モデル、RAGデータソース、エージェント連携先は何か

つまり、AI時代には、SBOMはAI局面へ拡張される。そしてDDの対象も、ソフトウェア構成から、モデル、データ、外部API、RAG、エージェント、評価ログ、ガバナンス証跡へ広がっていく。

第4章　サイバーDDが価格・補償・ディール構造を変えていく

【結論】サイバーDD（デュー・デリジェンス）は単なる技術監査ではなく、M&Aにおける「価格調整装置」です。発見されたリスクは、直接的にバリュエーションの減額や表明保証保険の除外項目に反映されます。

DD所見がディールに与える影響

• バリュエーション：是正コストや停止損失を積算し、価格減額を検討。
• 表明保証：重要なサイバー管理事項を真実表明の対象とし、違反時の補償を設計。
• PMI予算：クロージング後に直すべき欠陥を100日計画に落とし込み、予算化する。

Plan-Do-Check-Actのフレームワーク

• Plan：どの資産・システム・委託先・製品が企業価値毀損の起点になるかを仮説設定する。
• Do：IAM、ログ、クラウド設定、委託先、インシデント履歴、SBOM、脆弱性管理の証跡を回収する。
• Check：所見を「重大性」「再発可能性」「是正コスト」「顧客・規制・停止影響」で評価し、価格・補償・条件にマッピングする。
• Act：契約条項、価格調整、補償キャップ、表明保証、PMI計画に落とし込み、クロージング後の是正項目として管理する。

確認対象など

確認対象は、IAM、ログ、クラウド設定、委託先、インシデント履歴、SBOM、脆弱性管理にとどまらない。実務上は、未承認SaaSや野良クラウドといったシャドーIT、生成AIや外部APIの無統制利用といったシャドーAI、データ分類、学習投入ルール、開発環境と本番環境の分離まで確認して、初めて企業価値毀損リスクを把握できる。

シャドーIT・シャドーAIのPDCA

シャドーIT・シャドーAIは、単なる技術統制上の問題にとどまらない。

会社が明示した禁止事項に反して、顧客情報、個人情報、営業秘密、ソースコード等を未承認SaaSや外部AIサービスに入力・保存・送信していた場合には、情報セキュリティ規程、秘密保持義務、服務規律違反として、人事上の措置や懲戒処分の検討対象となり得る。

ディール構造への出力（バリュエーション〜PMI予算）

出力先	Plan	Do	Check	Act
バリュエーション	是正コスト・停止損失仮説を置く	想定損失と修補費を積算	EV/EBITDA調整要否を判断	価格減額
表明保証	何を真実表明させるか決める	DD所見を条項案に落とす	空文化していないか確認	個別表明、開示資料添付
表明保証保険	保険付保前提を設計	所見をアンダーライターに提示	除外対象・保険料を確認	除外補完の特別補償を入れる
補償キャップ	一般補償と特別補償を分ける	論点別の上限案を作る	リスクに対し低すぎないか確認	個別キャップ、ミニバスケット調整
PMI予算	是正優先順位を決める	100日計画と予算化を行う	実行可能性・担当を確認	クロージング後の改善管理に移す

 

出力先	DD所見の翻訳	バイサイドのAction
バリュエーション	是正コスト、停止損失、将来事故リスクを金額化する	価格減額等
表明保証	重要なサイバー管理事項を真実表明の対象にする	個別表明、開示資料添付、違反時の補償接続等
表明保証保険	DD所見を保険引受上のリスクとして提示する	除外確認、保険料調整、特別補償での補完等
補償設計	一般リスクと特定サイバーリスクを切り分ける	特別補償、個別キャップ等
PMI予算	クロージング後に直すべき項目を優先順位化する	100日計画、是正予算、責任者・期限の設定等

サイバーDDの価値は、脆弱性を見つけること自体にはない。IAM、ログ、クラウド設定、委託先、インシデント履歴、SBOM、脆弱性管理に関する所見を、どこまで企業価値の毀損可能性として評価し、価格、表明保証、表明保証保険、補償キャップ、PMI予算に変換できるかにある。

したがって、DDはクロージング前の点検で終わらない。DDで発見された欠陥は、契約条件に反映され、クロージング後は是正計画、予算、責任者、期限、証跡を伴う改善管理に移されて初めて、ディール全体のPDCAが閉じる。

第5章　保険会社が求めるのは「安全」ではなく「立証可能性とその責任（アカンタビリティ）」になる

【結論】サイバー保険の引き受けにおいて、保険会社は単なる「安全宣言」ではなく、P・D・C・Aが回っていることの「証跡」を求めます。申告内容と実態が不一致の場合、保険金の支払いが拒絶されるリスクがあります。

保険会社は「安全」ではなく、「予測可能性・説明可能性に基づく信頼性」を求める。具体的には、事前準備、迅速な修復可能性とユーザーへの信頼回復、影響の縮減性、それらの説明可能性を求めている。

引受要件の現実

MFA、EDR、バックアップ、IR計画、権限管理、ログ、パッチ管理などが考えられるが、運用まで踏み込むと、これだけでは足りない。実務では、認証・アクセス制御、端末・ネットワーク防御、復旧可能性、監視と初動対応、脆弱性管理、SBOMを含む開発・変更管理、委託先管理、教育、経営ガバナンスまでを、P・D・C・Aで回せる形で整備して初めて、説明可能な管理水準になる。

主に以下の者がチェックされる。

領域	見られるポイント
認証・権限管理	MFA、特権ID、退職者アカウント、共有ID、最小権限
端末・メール・ネットワーク	EDR、MDM、メール防御、リモートアクセス、未管理端末
バックアップ・復旧	RTO/RPO、オフライン保管、復元テスト、対象漏れ
IR・監視・ログ	初動体制、ログ保存、検知遅延、机上演習、証跡欠落
脆弱性・変更管理	パッチSLA、重大CVE対応、例外管理、変更承認
開発・SBOM	SBOM更新、OSS管理、既知脆弱性、変更記録、真正性
委託先管理	再委託把握、証跡提出、通知義務、改善要請
組織・ガバナンス	責任者、教育、役員報告、監査、KPI

重要ポイント：申告と実態の不一致は、引受拒否および保険金支払拒否になる可能性がある。

第6章　結語——セキュリティは企業価値を支える情報インフラへになる

サイバーセキュリティは、もはやIT部門だけの内部管理ではない。契約では、委託先にどの水準の対策を求めるのかが問われる。サイバーDDでは、対象会社やシステムの中にどのような脆弱性や依存関係が存在するのかが検証される。保険では、事故発生時の損害だけでなく、平時からどこまで管理・記録・説明できているかが問われる。

つまり、サイバーセキュリティは、防御技術から、契約・DD・保険・企業価値を支える情報インフラへと変質しつつある。

この変化の中で、SCS制度とSBOMの役割は明確である。SCS制度は、取引当事者の間で「どの水準の管理を求めるのか」を共有するための契約言語である。一方、SBOMは、「何を使い、どこに脆弱性があり、どこまで修復しているのか」を説明するための技術的立証資料である。

したがって、SCS制度とSBOMは、制度紹介として並列に扱うべきものではない。実務の出発点は、契約・DD・保険の場面で「説明しろ」と求められることにある。その説明責任に応えるために、要求水準を共有するSCS制度が必要になり、技術的な証跡としてSBOMが必要になる。

これからの企業に求められるのは、単に「守っている」と主張することではない。どの水準で守っているのかを契約上説明できること、何を使っているのかを技術的に立証できること、そしてその情報をDD・保険・取引先管理・企業価値評価に再利用できる形で整備しておくことである。

サイバーセキュリティは、ITの問題から、取引と資本市場の問題へ移りつつある。その意味で、SCS制度とSBOMは、企業が自らの信頼を説明するための新しいインフラになる。

ご相談はこちらから