取引条件に「セキュリティ格付け」が入る時代｜経産省 SCS評価制度（★3・★4）を情シスが制度開始前に準備する実務 2026

こんにちは、ひろかずです。

経産省・内閣官房が2026年3月27日に公表した「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」を一次情報に基づいて解説します。★3・★4の違い、評価スキーム、NIST CSF対応、情シスが制度開始前に着手すべき棚卸しとチェックリストを実務目線で整理します。

エグゼクティブサマリー

• 経済産業省と内閣官房国家サイバー統括室は2026年3月27日、「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」を公表し、★3・★4について2026年度末頃の制度開始を目指すとしました。運営はIPAが担います。
• 評価は重要性・影響度に応じた段階制で、★3は専門家の確認を経た自己評価、★4は評価機関による第三者評価（技術検証を含む）が前提です。★5は今後具体化を検討する段階です。
• 要求事項は NIST CSF（ガバナンス・特定・防御・検知・対応・復旧）の考え方に沿って整理されており、ISMSやPマークと地続きで取り組めます。
• 現時点で取得は義務ではありませんが、今後、大企業が取引条件や入札要件に組み込む見通しで、ISMS・Pマークに加えて「星」を問われる場面が増えると考えられます。
• 制度開始を待たずに、まずは自社IT基盤・資産・取引先・外部サービスの棚卸しから着手するのが現実的です。要求事項の具体的な実装例をまとめた評価ガイドは2026年秋頃の公表が予定されています。

本文

1. 何が起きているのか（最新の公開情報に基づく）

SCS評価制度とは、サプライチェーンを構成する各企業に必要なセキュリティ対策を提示し、その対策状況を共通のものさしで「見える化」する国の制度です。

経済産業省（以下、経産省）と内閣官房国家サイバー統括室（NCO）は、2025年4月の「中間取りまとめ」を経て、2025年12月26日に「制度構築方針（案）」を公表してパブリックコメントを実施しました。意見募集には93者から569件の意見が提出され、それを踏まえて2026年3月27日に「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」を公表しています。この方針に基づき、2026年度末頃の制度開始を目指した取組が進められています。

制度の運営は、経産省およびNCOの監督のもとで独立行政法人情報処理推進機構（IPA）が担います。より具体的な実施内容は2026年度に詳細化される予定で、要求事項・評価基準を満たす具体的な実装例をまとめた評価ガイド等は、2026年秋頃を目途に公表するとされています。

評価は、企業やシステムの重要性・影響度に応じた段階で行われます。方針では対策の段階を ★3・★4（★5は今後検討）に区分し、★3の要求事項・評価基準を基礎として、★4ではより広い範囲・対策を含む要求事項に基づいて評価を行う、という構造が示されています。

• ★3：一般的なサイバー脅威に対処しうる、すべてのサプライチェーン企業が最低限実装すべき基礎的な水準。評価方法は専門家の確認を経た自己評価（専門家確認付き自己評価）。
• ★4：初期侵入の防御にとどまらず、被害拡大の防止や取引先のデータ・システム保護に寄与する、標準的に目指すべき包括的な水準。評価方法は評価機関による第三者評価（技術検証を含む）。
• ★5：未知の攻撃を含む高度な攻撃に対応する到達点。対策基準・評価スキームを今後具体化する段階。

なお重要な前提として、IPAは「上位の段階はそれ以下の段階で求められる事項を包括するため、例えば★3を事前に取得していなければ★4を取得できないという関係とはならない」と説明しています。

2. なぜ情報システム・セキュリティ担当者に関係するのか（実務影響）

この制度が情シス・セキュリティ担当者に直結するのは、「自社を守る話」から「取引を続ける話」へと軸足が移るからです。

制度の背景には、取引先のセキュリティ対策状況を外部から判断しにくいという発注元側の課題と、複数の取引先からバラバラに対策を要求されるという受注側の課題があります。SCS評価制度は、この双方の非効率を共通のものさしで解消することをねらっています。

現時点では取得は義務ではありません。しかし、「サプライチェーン強化に向けたセキュリティ対策評価制度」では、2社間の取引契約等において、委託元が、委託先に適切な段階（★）を提示し、示された対策を促すとともに実施状況を確認することを想定していることから、政府調達や重要インフラ分野のサプライチェーンに連なる企業では、今後★3・★4等の取得が取引要件や入札条件に組み込まれる見通しだと整理する解説も出ています。これまで、ISMS（ISO/IEC 27001）やPマークを求められてきた場面で、これからは「星いくつか」を問われる——その入口に立っていると捉えるのが実務的です。

つまり情シスにとっては、(1) 自社が受注側として評価を求められる可能性、(2) 自社が発注側として取引先に評価を求める側になる可能性、(3) いずれにせよ要求事項に沿った自社対策の棚卸しが必要、という3つの実務影響が同時に発生します。

3. よくある誤解

• 「義務化されたから今すぐ認証が必要」：誤解です。現時点で取得は義務ではありません。ただし取引条件化の見通しがあるため、早期の準備が推奨されています。
• 「★3から順に取らないと★4に進めない」：誤解です。上位段階は下位段階の事項を包括しますが、★3取得が★4取得の前提条件ではありません。
• 「特定の製品を買えば達成できる」：誤解です。評価基準の達成にあたり、特定のセキュリティ対策製品の導入が必須とされているわけではありません。
• 「格付けで企業を順位づけする制度」：制度の目的は対策状況の可視化であり、企業のセキュリティ対策を競わせる格付けを目的としたものではない、と整理されています。
• 「OTや自社製品も評価対象」：評価対象はサプライチェーンを構成する企業のIT基盤（オンプレミス／クラウド環境のシステム）で、製造環境等の制御（OT）システムや発注元へ提供する製品等は直接の対象とはされていません。

4. 実務で問題になりやすいポイント（公開可能な一般論）

多くの企業で論点になりやすいのは、対策そのものの有無よりも「運用と証跡（エビデンス）」の継続性です。

• エビデンス管理の手作業負荷：★3の段階から求められる自己評価・証跡の整備、★4の第三者評価対応は、IT部門だけでなく管理部門にも経営層への説明や予算承認に係わる工数を要するとの指摘があります。対策を「やったか」よりも「継続的に・効率的に証跡を残し、状況をモニタリングできるか」が成否を分けやすい論点です（出典：コニカミノルタジャパン（外部サイト））。
• 取引先・外部サービスの把握不足：要求事項には取引先管理や接続している外部情報サービスの把握が含まれます。SaaSやOAuth連携が増えた組織ほど、誰がどこに何を許可しているかの台帳が追いついていないことが多く、ここが実務上見落とされがちです。
• 既存制度との重複と再利用：ISMSやPマーク、SECURITY ACTIONなどで整備済みの規程・台帳をSCS評価制度の要求事項にマッピングし直せば、ゼロからやり直す必要はありません。要求事項はNIST CSFの考え方に沿うため、既存の枠組みと地続きで整理できます。
• 中小企業のリソース不足：中小企業向けには「サイバーセキュリティお助け隊サービス」の新類型創設や「中小企業の情報セキュリティ対策ガイドライン」の改訂など、★3・★4取得を安価・簡便にするための支援策が進められています。自社単独で抱え込まず、支援策の活用を前提に計画する余地があります。

5. 技術的・運用的な確認ポイント（具体的に）

要求事項はNIST CSFの機能（統治・識別・防御・検知・対応・復旧）に対応づけて整理されています。制度開始前でも着手できる、代表的な確認ポイントを機能別に挙げます。

• ガバナンス（統治）／取引先管理：セキュリティ責任者と対応方針が明確か。取引先に課すルール、機密情報の取扱い、接続している外部情報サービスを把握しているか。★4では取引先の対策状況把握やインシデント時の役割分担まで求められます。
• 識別（リスクの特定）：情報資産・ネットワークの一覧化、外部サービスの管理ができているか。★4では脆弱性管理の体制・プロセスが明確か。
• 防御：ID管理・アクセス権限設定、パスワードの安全な管理、内外ネットワーク境界の分離、端末・サーバへのアップデート適用とマルウェア対策が基礎。★4では重要データの暗号化、ログ収集・分析、社内のネットワーク分離、出口対策（不正通信の遮断）まで。
• 検知：ネットワーク接続・データの基礎的な監視。★4では機器の状態・挙動の監視と異常の迅速な検知。
• 対応・復旧：インシデント対応手順の整備、復旧ポイント・復旧時間を満たす復旧手順の整備。

評価スキーム面では、★3はセキュリティ専門家が自己評価の内容を確認・助言し、署名のうえ経営層の自己適合宣誓を含めて事務局へ提出、台帳に登録・公開という流れです。★4は、取得を希望する組織が自ら実施した評価の結果について、指定された評価機関による審査と技術検証を経て登録されます。

なお、解説によっては★3の有効期間を1年、★4を3年とし、★4は更新時に第三者評価を必須とする案が紹介されています（出典：SS1LAB）が、確定値は今後の評価ガイド等で要確認です。

6. 対応方針の比較表

※2026/06/24時点で、要求事項数は★3が約26項目（小項目81）、★4が約31項目（小項目72）ですが、最終的な確定値は評価ガイドでの確認を待ちたいところです。

7. SCS評価制度の取得を目指す際の事前チェックリスト

本節では、SCS評価制度の要求事項の中から★4を目指す上で、準備に時間がかかり、事前にある程度用意ができていると取得支援や相談、対応がスムーズに行える項目をピックアップし、チェックリストにしました。項目は多いですが、これらは遅かれ早かれ行う必要があることです。

• セキュリティに関連して、自社に関連する法令（事業法、個人情報保護法など）や所管省庁および関係団体のおける基準、取引先が提示する制限事項および要求事項を整理した
• セキュリティと統括する役員とセキュリティを担当する部署の役割と責任を定めた
• セキュリティリスクへの対応について、経営層が参加する情報セキュリティ委員会等の経営判断ができる体制を設置した
• サイバー攻撃および予兆を監視する体制について、内製で対応する領域と外注で対応する領域の方向性を定めた
• 役職員と派遣社員および受入出向者を対象とした、自社の守秘義務ルールを定めた
• 自社の機密情報を取り扱う役職員から、守秘義務の誓約書を取得した
• 派遣社員および受け入れ出向者を受け入れる際に、派遣元および出向元企業と守秘義務契約を締結した
• 自社のセキュリティ対応方針を定め、役職員と派遣社員および受入出向者が参照できる場所に保存した
• 自社以外の組織（顧客、関係会社、取引先、クラウドサービス事業者）が管理・提供し、自社の資産が接続しているシステムを把握した
• 自社の機密情報を定義し、関係会社や取引先と取り交わす手段と使用する情報資産とその取扱について整理・把握した
• 自社の機密情報を共有する関係会社や取引先との間で、セキュリティインシデント発生時の役割および責任を定めた
• 情報資産・ネットワーク・端末・サーバの一覧（台帳）を最新化した
• 端末・サーバで使用しているソフトウェアの一覧（台帳）を最新化した
• ネットワーク構成図（物理・論理）を最新化した
• 自社の機密を特定し、機密区分レベルの判定方法や表示方法、区分に応じた取扱い方法や取扱いエリアの区分と制限について整理した
• 重要な機密情報について、管理者・管理部署、保管場所、保管期限、開示制限について整理した
• リモートワークで使用する情報機器および機密情報について、使用申請と許可の方法と個人所有機器にダウンロード可能な機密区分やデータの種類を定めた
• 脆弱性情報や脅威情報を収集し、対応する担当部署の役割と責任を定めた
• ユーザーIDと管理者IDの発行・変更・削除の手続きがどのように定められているか確認した
• 業務で取り扱っているシステムや情報資産へのアクセスに必要な認証の強度や実装方式を確認し、整理した
• システムやデータ、執務エリアへのアクセス権の付与・変更・削除がどのように行われているかを確認し、整理した
• 役職員、派遣社員および受入出向者を対象に、新規受け入れ時かつ年一回以上の頻度でセキュリティインシデント発生時の対応について、教育・訓練を実施した
• ネットワークに接続している全てのパソコンおよびサーバに、マルウェア対策ソフトウェアを導入した
• インシデント対応手順と復旧手順（RPO/RTO）の整備状況を確認した
• 既存のISMS・Pマーク・SECURITY ACTIONの成果物を要求事項にマッピングした
• 中小企業向け支援策（お助け隊サービス新類型・改訂ガイドライン）の活用可否を確認した
• SCS評価制度の動向および評価ガイド（2026年秋頃公表予定）の公開を追う担当を決めた

8. 経営層・監査部門への説明ポイント

• これは「コスト」ではなく「取引継続の前提条件」になりうる：取得は現時点で義務ではないが、取引要件・入札条件に組み込まれる見通しがあるため、対応の遅れは商談機会の損失に直結しうる、と説明できます。
• 既存投資を無駄にしない：要求事項はNIST CSFに沿い、ISMS等と地続きです。ゼロからの追加投資ではなく、既存の規程・台帳・ツールの再利用で多くをカバーできる、と整理できます。
• 製品を買えば終わりではない：特定製品の導入が必須ではなく、評価の本質は運用と証跡の継続性にある。だからこそ体制・プロセスへの投資が要る、と説明します。
• スケジュール感：★3・★4は2026年度末頃の制度開始目標、評価ガイドは2026年秋頃公表予定。逆算すると棚卸しの着手は早いほど有利、と数字で示せます。

9. 実務担当者が次に取るべき対応ステップ（優先順位つき）

1. 【最優先】立場の整理と情報源の固定：自社が受注側か発注側かを整理し、経産省・IPAの一次情報（制度構築方針・SCSページ）を定点観測する担当を決める。
2. 【高】資産・取引先・外部サービスの棚卸し：台帳を最新化し、外部SaaS・OAuth連携を可視化する。ここはどの★でも土台になる。
3. 【高】既存制度とのギャップ分析：ISMS・Pマーク・SECURITY ACTIONの成果物をNIST CSFの機能にマッピングし、不足を洗い出す。
4. 【中】証跡運用の仕組み化：エビデンスを継続的に残す運用を設計し、手作業依存を減らす。
5. 【中】支援策の検討：中小企業はお助け隊サービス新類型・改訂ガイドラインの活用を前提に計画する。
6. 【継続】評価ガイドの反映：2026年秋頃公表予定の評価ガイドで要求事項・項目を確定し、計画を更新する。

10. まとめ（次に取るべき行動）

SCS評価制度は、セキュリティ対策を「自社防御」から「取引の信頼を可視化する共通言語」へと押し上げる制度です。★3・★4の制度開始は2026年度末頃が目標で、評価ガイドは2026年秋頃の公表が予定されています。制度の詳細が固まる前でも、資産・取引先・外部サービスの棚卸しと、既存制度とのマッピングは今日から始められます。義務化を待つのではなく、取引条件化を見据えて自社の現在地を測ること——それが、慌てない準備の第一歩です。

FAQ

Q1. SCS評価制度とは何ですか？

A. 正式名称は「サプライチェーン強化に向けたセキュリティ対策評価制度」です。サプライチェーンを構成する企業に必要なセキュリティ対策を提示し、その対策状況を共通基準で可視化する、経産省・内閣官房国家サイバー統括室主導の制度で、IPAが運営します。

Q2. いつから始まりますか？

A. 2026年3月27日に制度構築方針が公表され、★3・★4については2026年度末頃の制度開始が目指されています。

Q3. ★3と★4の違いは？

A. ★3は社内外の専門家の確認を経た自己評価で、広く認知された脆弱性等を悪用する一般的なサイバー攻撃に対して、最低限実装すべき基礎水準。★4は自己評価の結果に対する評価機関による第三者評価（技術検証を含む）で、組織ガバナンスや取引先管理、防御・検知による被害拡大防止、インシデント対応等まで含む包括的な標準水準です。

Q4. ★3を取らないと★4は取得できませんか？

A. いいえ。上位段階は下位段階の事項を包括しますが、★3の事前取得は★4取得の前提条件ではない、とされています。

Q5. 取得は義務ですか？

A. 現時点では義務ではありません。ただし大企業が取引条件や入札要件に組み込む見通しがあり、企業戦略としての早期準備が呼びかけられています。

Q6. 特定のセキュリティ製品を買う必要がありますか？

A. いいえ。評価基準の達成にあたり、特定の製品導入は必須ではありません。要求事項を満たす実装例は2026年秋頃公表予定の評価ガイドで示される予定です。

Q7. ISMSやPマークを持っていれば対応できますか？

A. 要求事項はNIST CSFの考え方に沿っているため、既存のISMS等の成果物を再利用しやすい構造です。ただし制度独自の要求事項・評価スキームがあるため、ギャップ分析は必要です。

Q8. 中小企業向けの支援はありますか？

A. 「サイバーセキュリティお助け隊サービス（新類型）」の創設や「中小企業の情報セキュリティ対策ガイドライン」の改訂など、★3・★4取得を安価・簡便にするための支援策が進められています。

おわりに

「取引先からセキュリティ水準の提示を求められたが、自社の現在地が分からない」「ISMSはあるが、SCS評価制度の要求事項にどうマッピングすればいいか整理できていない」——制度開始前のいまは、対策の有無よりも“棚卸し”の精度が成否を分けます。クラウドネイティブでは、資産・取引先・外部SaaS連携の可視化、NIST CSFに沿ったギャップ分析、ゼロトラスト設計やID・ログ・インシデント対応の運用見直しまで、現役エンジニアが直接ご相談に対応します。自社の現在地整理から、まずはお気軽にご相談ください。

参考情報

• 経済産業省／内閣官房国家サイバー統括室「『サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針』を取りまとめました」｜発行元：経済産業省｜種類：一次（政府発表・プレスリリース）｜公開日：2026年3月27日｜URL：https://www.meti.go.jp/press/2025/03/20260327001/20260327001.html
• 「SCS評価制度の詳細情報」｜発行元：独立行政法人情報処理推進機構（IPA）｜種類：一次（制度運営機関ページ）｜公開日：2026年4月21日｜URL：https://www.ipa.go.jp/security/scs/details.html