経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度」解説 第1回【制度解説】制度の要点と「対応のヒント」

なぜ今、サプライチェーンのセキュリティ対策が急務なのか

近年、取引先への攻撃を起点として、サプライチェーン全体の事業継続に深刻な影響を与えるサイバー攻撃事案が頻発しています。大手企業や重要インフラを直接狙うのではなく、その取引先（サプライヤー）を侵入経路として悪用する、いわゆる「サプライチェーン攻撃」のリスクが顕在化しています。

こうした状況を受け、経済産業省（METI）は2025年12月26日、サプライチェーン全体のセキュリティ水準を底上げするための「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針（案）」（SCS評価制度の構築方針（案））^*1)を公表しました。

これまで、発注元企業にとっては「取引先のセキュリティの対策状況が外部から判断しづらい」という課題があり、一方で受注側企業にとっては「複数の取引先からバラバラな基準でセキュリティ対策を要求される」という負担が課題となっていました。本制度は、こうした課題を解消するため、国が共通の「物差し」を提示し、対策状況を客観的に可視化する仕組みとして設計されています。

本制度は、2社間の取引契約等において、発注側が適切なランク（★）を提示し、受注側がその要件を満たしているかを確認する「要求事項」として機能することを想定しています。本記事では、この最新の構築方針案に基づき、制度の目的や具体的な評価スキームの要点を解説します。

*1) https://www.meti.go.jp/press/2025/12/20251226001/20251226001.html

評価レベル（★）の段階設定と評価スキーム

本制度の設計上のポイントは、一律の基準を全企業に求めるのではなく、「属するサプライチェーンの属性」や「個別取引の契約条件」に応じて、段階的な評価（★）を適用する仕組みにあります。また、本制度はサイバーセキュリティ対策の水準として、★3から★5までの段階的な要件が想定されています。上位の段階はそれ以下の段階で求められる事項を包括するため、★3を取得していなくても、直接★4の評価を受けることが可能です。

１．各段階（★）が目指すセキュリティ水準の定義

各段階では、具体的に以下の対策水準が想定されています。

• ★3（Basic）： 一般的なサイバー脅威に対処しうる基礎的な水準。
• ★4（Standard）： 初期侵入の防御にとどまらず、被害拡大防止やリスク低減を図ることで、取引先の資産保護やサプライチェーンの強靭化に寄与する水準。
• ★5（Advanced）： リスクを適切に把握・マネジメントした上で、ベストプラクティスに基づく対策を実行する高度な水準（2026年度以降に詳細を具体化予定）。

２．対象範囲による区分

本制度は以下の2つの異なるサプライチェーンを対象範囲としており、それぞれに段階的な評価制度（★3・★4）が整備されます。

• ビジネスサプライチェーン： 物資や役務の調達等に関わる取引（主に★3・★4が対象）
• ITサービスサプライチェーン： MSPやクラウドサービス等、IT基盤の提供に関わる取引（★4、および将来的な★5が対象）

ここで重要なのは、評価の具体的な対象範囲です。今回の構築方針案では以下のように定義されました。

「本制度は、サプライチェーンを構成する企業等のIT基盤（クラウド環境で運用するものも含む。）を対象とする。」

具体的には、メールや認証基盤、エンドポイント等の「組織のIT基盤」が評価の対象となります。一方で、一般的にIT基盤には該当しないと考えられる製造環境等の制御 (OT) システム、発注元等に提供する製品等については求められる対応が基本的に異なることから直接の対象とはせず、他の制度・ガイドライン等に基づき対策を行うことを想定すると明示されています。

スコープの境界線と『責任』の範囲

この適用範囲を検討する際、技術的に留意すべき2つの指針が示されています。

• 責任共有モデルに基づく対策
  クラウド環境を利用している場合、事業者が提供する基盤側の安全性（SOC2等の認証）を活用しつつも、その上の「利用者側での適切な設定・対策実装」については、自社の責任として評価の対象となります。「クラウドだから大丈夫」ではなく、自社が管理すべき設定（セキュリティグループやID管理等）を適切に運用していることが求められます。 ここで言う責任共有モデルとは、サービスを提供する事業者とサービス利用者との間で、サービスのセキュリティに関する責任を共有し合うための考え方のことを指します。
• 技術的なネットワーク分離
  製造環境（OT）や製品開発環境などを本制度の「対象外」として定義する場合、それらが本制度の適用範囲（IT基盤）に影響を及ぼさないよう、VLANやファイアウォール等によって「技術的に分離」されていることが条件となります。

クラウド・SaaS利用時の適用範囲

資料の定義にある「Web・メールサーバ」や「IT基盤」には、クラウド環境で運用されるものも含まれると明記されています。ここで一点、実務者が留意しておくべきなのが、この資料に記載された「責任共有モデル」の考え方です。一般的に、メール環境等をSaaSで利用している場合、インフラ側の安全性は事業者の認証（SOC2等）で担保されますが、一方で「多要素認証の設定」や「権限管理」といった利用者側の設定は、責任共有モデルにおいて「自社の責任範囲」と定義されます。本制度の評価において、これらSaaS上の設定状況が「IT基盤の対策」としてどの程度具体的に確認されるのかは、今後の詳細な評価基準の発表に注目したいポイントです。

３．取引ごとの要求水準の決定 ～ 制度が想定する3つのリスクシナリオ

対策レベル（★）は、企業が自動的に決めるものではなく、「2社間の取引契約等において、発注元企業が適切な段階（★）を提示する」というプロセスが想定されています。発注者がこのランクを判断する基準として提示されているのが、以下の3つのリスク分類です。これは、過去に発生した主要なインシデント事例に基づき、波及経路を形式的に整理したものです。

【SCS制度が想定するリスク分類の要約】

• 提供途絶（事業継続）： 調達部品の供給停止やクラウドサービスのダウン
• 漏えい・改ざん（データ保護）： BPOやITベンダーからの情報流出
• 不正侵入（不正アクセス）： 委託先の環境を踏み台とした発注者への侵入

ここで留意すべきは、上記の分類はあくまで制度運用上の「想定シナリオ」であり、各企業が本来実施すべきリスクアセスメントの代替にはならないという点です。本来、サイバーセキュリティにおけるリスクは、企業が保有する「資産」の特定から始まります。

特定の資産が侵害された場合、それは単一のリスクに留まらず、「事業継続の停止」と「他組織への不正侵入」の起点が同時に発生するなど、複合的な影響を及ぼすのが実態です。制度上の「ビジネス」「ITサービス」といった形式的な属性区分に頼りすぎると、要求されるべき真の水準を見誤るリスクがあります。

制度上の「★」の数はあくまで目安に過ぎません。「2社間の取引における提示」において、自社のインフラ構成や接続実態、および保有する資産がどのようなリスクを内包しているかを検証し、実態に即した対策を検討しておくべきでしょう。

４．評価スキーム ～ 適合性確認のプロセスと評価手法

本制度では、選択した段階（★）に応じて、その適合性を証明するためのプロセスが明確に分かれています。特に★4においては、書類上の審査にとどまらず、システムの技術的側面まで踏み込んだ確認が行われることが規定されています。

4－1.　段階別の評価ルート

• ★3（Basic）：セキュリティ専門家による確認・助言
  • 企業が行った自己評価に対し、国が認定した「セキュリティ専門家」が内容を確認し、適切な対策への助言等を行うプロセスです。
• ★4（Standard）：評価機関による第三者評価
  • 独立した評価機関が、客観的なエビデンスに基づき対策状況を直接評価します。後述する技術的な検証が含まれるなど、より厳格な適合証明が求められます。

4－2.　評価の物差し ～「要求事項」と「評価基準」

では、具体的に何を評価するのかですが、本制度は「要求事項（あるべき姿）」を、より具体的な「評価基準（判定の物差し）」でチェックする階層構造になっています。

ここで重要なのが、★4は★3の内容をすべて包含した上で、さらに厳しいチェック項目が追加される積み上げ方式である点です。

例として『1 ガバナンスの整備体制整備』に定義されている要求事項1-2-1を見ていきます。

同じ要求事項であっても、★3までは「現場の責任者（CISO等）が誰か決まっているか」という「役割（Role）」の話ですが、★4になると「会社としてどう経営判断を下すか」という「機能（Function）」の話に格上げされています。具体的には次の3つの観点が追加されています。

1. 「個人の責任」から「合議制の経営判断」へ

• ★3の観点：
  • 1-2-1-1（役割・責任の定義）：　役割の定義
  • 1-2-1-2（連絡先の整備）：　平時や有事に「誰に連絡すべきか」の通信経路の確保
  • 1-2-1-3（年1回以上の点検）：　役割の定義や通信経路の確保が実態とあっているかの確認
• ★4で追加された観点：
  • 「情報セキュリティ委員会等」の設置を求めています。重大なリスクが発生した際、CISO一人の判断ではなく、経営層を巻き込んだ「組織としての意思決定（経営判断）」ができる体制を作る必要があるということです。

2. 「平時の運用」から「有事の経営レジリエンス」へ

• ★3の観点： 平時のセキュリティ活動や点検ができているのかをチェックします。
• ★4で追加された観点： セキュリティリスクが「経営に重大な影響を及ぼす」ことを前提としています。つまり、単なる「ITの不具合」ではなく「事業継続の危機」として捉え、経営課題として優先順位をつける体制があるかをチェックします。

3. 「実行」から「監督と承認」へ

• ★3の観点： 実務を推進する部署や役員がいれば、形式上の要件は満たせます。
• ★4で追加された観点： 「経営判断ができる体制」とは、多額の投資判断や、有事の際のサービス停止といった、現場レベルでは下せない重い決断をバックアップする仕組みを指します。

★4では、経営に直結するリスクとして捉え、迅速にリソースを割く、あるいは事業継続の是非を判断できる体制があるかどうかが、評価の大きなポイントになります。

4－3.　評価を担う「セキュリティ専門家」の要件

★3の確認者も、★4の評価員も、本制度に関わる「セキュリティ専門家」には高度な専門性が共通して求められます。

1. 認められる専門資格
   • 情報処理安全確保支援士やCISSP、CISA、公認情報セキュリティ監査人、ISO27001主任審査員など、高度な専門性を証明する特定の資格を保有していることが必須です。
2. 「力量の保有」と「力量の維持」
   • 力量の保有：IT・セキュリティに関する高度な知見（ITSSレベル4以上又はそれに相当する力量）を保持していること。
   • 力量の維持：年次研修の受講や、継続的専門能力開発（CPD/CPE）の実績提出などを通じ、常に知識を更新していること。

セキュリティ専門家及び作業従事者を対象とした研修やスキームなどについては今後具体化されていくようです。

4－4.　★3の評価スキーム ～ 専門家確認付き自己評価

★3の適合証明は、企業自らが行う「自己評価」をベースに、専門家の知見を添えて信頼性を担保するスキームです。ここで、公式資料から非常に重要な定義を抜粋します。

「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針（案）」（SCS評価制度の構築方針（案））3.5 制度における評価スキーム 3.5.1 各段階の評価スキームの概要 -★3(P.18)より抜粋

★３は、セキュリティ専門家による確認を経た取得希望組織による自己評価^*1)(専門家確認付き自己評価)を求めるスキームとする。

*1) 経営層による自己適合宣言を経た取得希望組織として実施する評価のことを指し、組織内のセキュリティを担当する担当者や部門が独自に実施する評価は含まれない。

次のステップが具体的な手順です。

このプロセスを成立させるには、具体的に以下の3つの条件を満たす必要があります。

1. 「会社としての公式な意思表明」であること

「組織内のセキュリティ担当者や部門が独自に実施する評価は含まれない」という部分は、「現場が勝手にやったこと」にさせないという意図があります。 担当者がチェックシートを埋めたとしても、最終的にそれを経営層（社長や役員）に見せ、「我が社はこの内容で間違いありません」と承認というプロセスが必須となります。

2. 「自己適合宣言」という重み

経営者が「もし嘘があれば会社として責任を取る」と公に宣言することを指します。これにより、万が一の事故時に「担当者が勝手にやったことで、私は知らなかった」という経営層の言い逃れを封じ、組織全体のガバナンスを担保します。

3. 「専門家の署名」と「経営層の自己適合宣誓」の組み合わせ

専門家による「妥当性の確認（署名）」と、経営層による「実態の保証（宣誓）」が揃って初めて、公式な書類として受理されます。

これは、情報システム部門が自分の判断だけでチェックを付けて終わり、という進め方ではなく、「現場が評価した内容を、経営層が『これが我が社の実態である』と正式に承認（自己適合宣誓）する」というステップです。つまり、★3であっても「経営陣のコミットメント」がスタートラインになっています。

4－5.　★4の評価スキーム ～ 評価機関による第三者評価と「技術検証」

★4の認定を受けるには、独立した評価機関による客観的な審査をクリアしなければなりません。★3との最大の違いは、経営層の宣言だけでなく、「対策が技術的に正しく実装されているか」を直接チェックされる点にあります。公式資料では次のように定義されています。

「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針（案）」（SCS評価制度の構築方針（案））3.5 制度における評価スキーム 3.5.1 各段階の評価スキームの概要 -★4(P.19)より抜粋

★４は第三者評価(要求事項について評価機関による審査(取得希望組織へのヒアリング、規程の確認等)）及び技術検証(後述)の実施を求めるスキームとする。

次のステップが具体的な手順です。

評価の信頼性を担保する「責任者」の存在

★4の評価と技術検証作業は、前述した「セキュリティ専門家」の要件を満たした者の責任のもとで行われます。

評価責任者による監督
評価プロセス全般を統括し、自らの責任において最終的な評価を行います。評価は、前述の専門家要件を満たした者が自ら実施するか、あるいはその監督のもとで作業従事者が実務（ヒアリングや証跡確認など）にあたります。最終的な評価結果については、責任者が内容を了承し、自らの責任において署名を実施します。

技術検証責任者
技術検証プロセス全般を統括し、自らの責任において検証結果を了承します。 この役割には、原則として「情報セキュリティサービス基準適合サービスリスト（脆弱性診断サービス）」における技術責任者と同等の、高度な技術的力量が求められます。具体的な役割は、「専門家」としての知見を活かし、収集された技術的エビデンス（証跡）が、制度の要求事項を正しく満たしているかを厳格に判定することにあります。

4－6.　評価の実施内容

★3や★4の認定を取得・維持するためには、どのような評価を受け、どのような手続きを継続する必要があるのかについてです。資料では次のように書かれています。

• ★3では、セキュリティ専門家が、取得希望組織が作成した書類の確認を行う。
• ★4では、評価機関・技術検証事業者が、文書確認に加え、実地審査及び技術検証(脆弱性検査等)を行う。
  ※ 以下の評価プロセスでは、各取得希望組織で決定した適用範囲の中から対象をサンプリングの上、評価等を実施することを想定。
  ※ より具体な実施内容を、本方針に基づき、令和８年度に検討・詳細化予定。

4－7.　評価の有効期間

★3や★4の認定を取得後、取得した評価はどのくらいの期間有効なのか、この評価を維持するために必要な手続きはどのようなものが必要かについてです。資料では次のように書かれています。

• ★３は有効期間を１年とし、対策状況を年次で点検し、基準全体の遵守を改めて確認している場合に更新可能とする。
• ★４は３年の有効期間とし、有効期間内は年次での自己評価(結果は評価機関に提出)をもって更新可能とすることを想定。
• ★３・★４のいずれにおいても、前回取得時に設定した適用範囲や要求事項・評価基準の遵守状況に影響を及ぼす変更*がある
  場合は、再度セキュリティ専門家又は評価機関の確認・評価を受ける。

★5の展望と国内外制度との連携

本制度は、国内の限定的なルールに留まるものではありません。今後、より高度なセキュリティレベルの定義や、国際的な基準との整合性が図られていくことが示されています。

★5（より高度なレベル）の検討

現在、★4（Standard）を超える段階として、「★5」の検討が進められています。

• ★3（Basic）：基礎的な組織的対策とシステム防御策
• ★4（Standard）：包括的・標準的なセキュリティ対策
• ★5：現時点でのベストプラクティスに基づく対策

★5については令和8年度以降に検討される予定となっており、その時点での最新かつ最高水準のセキュリティ対策が求められる段階になると予想されます。

国内外の関連制度との連携・整合

本制度は、既存のセキュリティ評価制度や国際的な動向との整合性を図りながら構築されています。

• 自工会・部工会ガイドライン、ISO/IEC 27001（ISMS）との関係
  本制度は、「相互補完的な制度として両輪で発展させていく」事を目指しています。
• 国内の業界ガイドラインとの連携
  技術情報管理認証制度等と今後連携の可能性を模索しています。
• 海外制度との相互承認に向けた検討
  英国 Cyber Essentialsに関しては将来的な相互認証等の可能性も念頭に、引き続き調査・意見交換を継続していく方針です。

評価制度のロードマップ

経済産業省は、令和8年度下期の制度開始を目指しています。現在はそれに向けて、制度の運営基盤の整備や利用促進などの準備が進められている状況です。

直近では、令和7年12月26日（金曜日）から令和8年1月24日まで、本制度の構築方針案に対するパブリックコメントが実施されていました。広く一般から意見を募ることで、より実効性の高い制度への最終調整が行われることが期待されます 。

制度の全貌が見えてきた一方で、企業が直面する最大の課題は、これらの評価を維持するための「継続的な対策と評価の負荷」です 。

そこで次回は、この「継続的な対策と評価の負荷」という、企業が直面する最大の課題を解決するセキュリティ自動化プラットフォーム『Vanta』を具体的に取り上げます 。

Vantaを活用し、サプライチェーン強化に向けたセキュリティ対策評価制度への対応を効率化するアプローチを解説します。ぜひご期待ください！

2025年11月20日に公開した「サプライチェーン強化に向けたセキュリティ対策評価制度構築に向けた中間取りまとめ（2025/4/14公表）」に関する記事はこちらです。