30秒で分かる要点

• 何の制度？
  サプライチェーン取引において「どの程度のセキュリティ対策ができているか」を、共通の物差し（★）で可視化し、発注側・受注側双方が判断しやすくする仕組みです。
• どう使う？
  2社間の取引契約等で、発注側が受注側に★の段階を提示し、対策を促し、実施状況を確認する運用が想定されています。
• いつから？
  ★3・★4は 2026年度末頃の制度開始が予定（予定であり変更可能性あり）。
• 準備のキーポイントは？
  対策そのものだけでなく、「実施している」と説明できる証跡（エビデンス）を揃えること。要求事項・評価基準案は、その説明材料に直結する項目で構成されています。

1. SCS評価制度（セキュリティ対策評価制度）とは
2. ★3 / ★4 / ★5 の違い
3. 対象は誰？どんな企業が準備すべきか
4. 何が見られるのか？要求事項（案）から読み解く観点
5. 何を準備すればいい？90日ロードマップ
6. 実務でつまずく4つのポイント
7. よくある誤解（セキュリティ格付け制度との付き合い方）

1. SCS評価制度（セキュリティ対策評価制度）とは

サプライチェーンは、1社の侵害が取引先へ連鎖しやすい一方で、現場では次のような課題があります。

• 対策状況は外部から判断しづらい
• 取引先ごとに要求がバラバラで、対応負担が増える
• 結果として「どこまでやればいいか」が定まらず、確認が形骸化する

SCS評価制度は、こうした課題に対して、サプライチェーンにおける重要性を踏まえた「満たすべき対策」を示しつつ、その状況を★で可視化する仕組みを構築する、という整理です。

また、制度構築方針（案）では、対象とするリスクとして、機密性・完全性・可用性（CIA）への影響だけでなく、製品・サービス提供の途絶（事業継続）や、取引ネットワークを通じた不正侵入等も想定されています。

2. ★3 / ★4 / ★5 の違い

※以下は、経産省の公表資料（中間取りまとめ・制度概要）に基づく整理です。詳細は今後の検討で変更される可能性があります。

段階	位置づけ（要旨）	評価スキーム（公表資料の表現）	主に厚くなる観点（例）
★3 Basic	全てのサプライチェーン企業が最低限実装すべき、基礎的な防御策＋体制整備	専門家確認付き自己評価（25項目）	体制整備、基礎的防御、最低限の運用がある状態
★4 Standard	標準的に目指すべき、ガバナンス・取引先管理・防御/検知・対応まで含む包括的対策	第三者評価（44項目）※	取引先管理、検知・対応、復旧まで回る状態
★5 （検討中）	リスクベースで改善プロセスを整備し、ベストプラクティスで対策を実行（具体は今後検討）	第三者評価（対策項目は今後検討）	継続的改善（経営レベル）、高度攻撃も見据えた運用

※第三者評価を原則としつつ、評価コストの負担軽減の観点で詳細検討予定、という注記があります。

さらに、段階（★3/★4/★5）の考え方として、ビジネス観点（データ保護・事業継続の重要度）とシステム観点（接続の有無）の2点で区分を整理する方針が示されています。（この2軸は、後述の「対象・目標★の決め方」の判断材料として使えます）

3. 対象は誰？どんな企業が準備すべきか

受注側だけの制度ではありません

制度の想定ユースケースは、発注側が受注側に★を提示し、対策を促し、実施状況を確認するというものです。
つまり、準備が必要なのは受注側だけでなく、発注側も「求める★の決め方」「確認の運用」を設計しておく必要があります。

何が評価対象になる？

制度概要の注記では、対象はサプライチェーン企業等のIT基盤である旨が示されています。
また、主要製造業（例：自動車・半導体）、流通、金融などで優先的に利用促進、という記載もあります（※優先促進であり、対象の限定ではありません）。

まず★いくつを目標にすべきか

※ここは「制度の要件」ではなく、前述の2軸（ビジネス/システム）を実務で使うための目安です。

【受注側】目標★の目安

• 取引で扱うデータが重要（機密情報・個人情報・重要設計情報など） または 事故時の停止影響が大きい（納期・提供停止が致命的）
  → ★4を視野（検知・対応・復旧まで回せる説明材料が必要になりやすい）
• まずは基礎対策と体制整備を整え、説明できる状態にしたい
  → ★3から着手（最小セットを固めるのが現実的）

【発注側】★を求めるかの目安

• 取引先の停止が自社の供給・サービス提供に直撃する
• 接続（ネットワーク/API連携等）がある／委託範囲が広い
• 重要情報を扱う（漏えい・改ざんの影響が大きい）
  → 上記が強いほど、より高い段階（★）を求める判断がしやすくなります（ただし過剰要求は交渉・コストの問題もあるため、運用設計が重要です）。

4. 何が見られるのか？要求事項（案）から読み解く観点

要求事項・評価基準案一覧を見ると、評価は「ツールの有無」ではなく、ルール・体制・一覧・運用（記録）といった説明材料で確認される構造になっています。

例として、次のような項目が並びます（抜粋）

• 法令や契約等を考慮した社内ルール策定、教育・周知、年1回以上/必要に応じた見直し
• セキュリティを担当する部署/従業員の決定、責任・権限の割当、連絡先リスト整備

これらから逆算すると、つまずきやすいのは「対策はしているが、説明できる形にまとまっていない」状態です。次の章では、これを避けるために証跡を成果物として残すロードマップに落とします。

5. 何を準備すればいい？90日ロードマップ

※本章は、要求事項・評価基準案の論点を「着手しやすい順」に並べ替えた進め方の例です。制度がこの順番を強制する、という意味ではありません。

0〜30日：範囲決めと棚卸し（説明の土台）

ゴール：対象・責任・棚卸しが言える/示せる

• 対象範囲（部署・システム・取引）を定義する
• セキュリティの責任者／窓口／緊急連絡先リストを整備する（役割と連絡網）
• 取引先（委託先）と、接続している外部サービス／外部システムを一覧化する（粗くてOK）
• ユーザID／管理者IDの棚卸し（共有IDがあるなら利用範囲を把握）

31〜60日：ルールと手順の文書化（曖昧さを潰す）

ゴール：ルールがある/手順があるを証跡として出せる

• 関連法令・契約・取引先要求などを踏まえた社内ルールを策定し、教育・周知する
• ルールの改定状況確認と見直し（年1回以上または必要に応じて等）を決める
• インシデント対応手順（連絡→初動→調査→復旧→報告）とエスカレーションを固定する
• ログ/記録の扱い方針を決める（何を残し、どう守り、誰が確認するか）
  ※要求事項案・別添案では、調査を円滑にするためのログ取得・保管等が論点として提示されています

61〜90日：運用を回して記録を残す（評価に耐える形へ）

ゴール：運用していることを記録で示せる

• 棚卸し・見直しを実施し、結果（チェック記録）を残す
• 取引先・接続先・ID一覧を更新し、更新履歴（いつ/誰が/何を）を残す
• ログの確認（レビュー/モニタリング）を定義どおり実施し、記録を残す（後述のチェックリスト参照）
• 不足は是正計画として明文化（次の90日で直すことも証跡になる）

成果物チェックリスト（簡易版）

A. 体制・ルール

□ 対象範囲（部署・システム・取引）の定義
□ 責任者／窓口／緊急連絡先リスト（役割と連絡網）
□ 社内ルール（法令・契約・取引先要求等を踏まえた版）＋教育・周知の記録
□ ルールの見直し手順（頻度・責任者・更新方法）

B. 棚卸し

□ 取引先（委託先）一覧（重要度の区分つき）
□ 接続している外部サービス／外部システム一覧
□ ユーザID一覧／管理者ID一覧（共有IDの有無・利用範囲の把握）

C. インシデント対応・復旧

□ インシデント対応手順書（連絡→初動→調査→復旧→報告）
□ エスカレーション（誰が判断し、どこへ報告するか）
□ 復旧に関する最低限の方針・手順（例：バックアップ、復旧優先度の考え方）

D. 記録（運用の証跡）

□ 定期点検（棚卸し・見直し）の実施記録（結果と是正）
□ ログの取得・保管の方針（対象ログの考え方、保管、保護）
□ ログの確認定義（頻度・担当・観点・エスカレーション）＋レビュー実施記録

6. 実務でつまずく4つのポイント

制度の目的は、発注側・受注側の双方が、必要なセキュリティ対策を判断しやすくし、対策状況を説明・確認しやすくすることにあります。
そのうえで、実務でつまずきやすいポイントが次の4つです。

1. ルールはあるが、周知・教育・見直しが記録として残らない

ルールを作っただけでは、「運用されている」と説明できません。教育・周知の記録や、見直し手順（頻度・責任者・更新方法）が欠けると、評価の場面で説明材料が足りなくなります。要求事項・評価基準案でも、社内ルールの策定や教育・周知、見直しといった論点が示されています。

2. 一覧が古い（取引先／接続先／IDが更新されない）

取引先（委託先）や接続している外部サービス、ユーザID・管理者IDの一覧は、作って終わりではありません。更新されないまま放置されると、いざ確認が必要になったときに「最新の状況が示せない」状態になります。要求事項・評価基準案では、取引先や接続先、IDの把握に関する論点が示されています。

3. インシデント対応が担当者依存で、手順化・連絡ルートが曖昧

「有事にどう動くか」が担当者の経験頼りだと、初動が遅れやすく、被害拡大にもつながります。連絡→初動→調査→復旧→報告の流れと、エスカレーション（誰が判断し、どこへ報告するか）を固定し、文書として残しておくことが重要です。要求事項・評価基準案でも、体制整備やインシデント対応に関する論点が示されています。

4. 「ログは取っている」だけで、監視・確認（レビュー）の定義がない

ログを取得していても、何をもって監視・確認とするのか（頻度／担当／見る観点／異常時のエスカレーション）が定義されていないと、運用としては“回っていない”状態になりがちです。さらに、レビューを実施した記録が残っていなければ、説明材料として提示しにくくなります。要求事項・評価基準案や別添案では、調査を円滑にするためのログ取得・保管、ログの保護、モニタリング等が論点として提示されています。

ここまで挙げた4つは、いずれも「対策をしているか」ではなく、「対策状況を説明・確認できるか」という観点でつまずきやすいポイントです。制度の狙い自体が、発注側・受注側の双方にとって、対策水準の判断や説明・把握をしやすくすることに置かれています。
とくに★4を見据える場合は、運用（記録）と証跡（エビデンス）の作り方がボトルネックになりやすいため、具体的な考え方については、以下のコラムで解説しています。

⇒ セキュリティ対策評価制度「★4」獲得の鍵は「証明」にあり

7. よくある誤解（セキュリティ格付け制度との付き合い方）

誤解①：企業同士を競わせる「格付け制度」である

「セキュリティ格付け制度」という呼ばれ方をすることがありますが、本制度は、サプライチェーンにおける求められる対策水準を定め、対応状況を可視化することで、取引における判断や確認をしやすくする目的で整理されています。

誤解②：★を取れば安全が保証される

★は「対策状況を外部に説明・確認しやすくする」ための目安であり、ゼロリスクや完全な安全を保証するものではありません。目的は、発注側が適切な★を提示し、受注側の対策実施を促し、状況を確認する運用を成立させることにあります。

誤解③：受注側だけが頑張ればよい

制度の想定ユースケースは、2社間の取引契約等で「発注側が受注側に★を提示し、対策を促し、実施状況を確認する」運用です。つまり発注側も、何を基準に★を求め、どう確認するか（運用）を設計する必要があります。

FAQ

Q1. SCS評価制度とは？
A. サプライチェーン取引で「満たすべき対策」を示しつつ、その対応状況を★で可視化し、発注側・受注側が判断・説明・確認をしやすくする制度として整理されています。

Q2. 「セキュリティ対策評価制度」と同じですか？
A. 経産省の公表資料では「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」として示されています。

Q3. セキュリティ対策評価制度の対象は？
A. 公表資料では、サプライチェーン企業等のIT基盤を対象とする整理が示されています。加えて、制度の使い方としては「発注側が受注側に★を提示し、実施状況を確認する」運用が想定されているため、受注側だけでなく発注側にも関係します。

Q4. ★4は何が必要ですか？
A. 公表資料では、★4は第三者評価を基本とし、ガバナンス・取引先管理・防御/検知・対応までを含む対策項目が整理されています。実務上は「運用が回っていることを示す証跡（記録）」がボトルネックになりやすい点が重要です。

Q5. いつから始まりますか？
A. ★3・★4については、2026年度末頃の制度開始を予定、とされています（予定のため変更可能性はあります）。

Q6. 「ログは取っていればOK」ですか？
A. 取得だけでは不十分になりやすく、何を・どの期間保管し、どう保護し、どの頻度で確認（レビュー）し、異常時にどうエスカレするか、まで定義と記録が求められる方向で論点が整理されています（別添案では取得ログ例や保管期間の例示もあります）。

まとめ：最短で準備を進めるなら「証跡」を成果物として揃える

SCS評価制度への備えは、「対策をしているか」だけでなく、「対策状況を説明・確認できるか」に直結する 証跡（エビデンス） を揃えることが鍵になります。
まずは、体制／一覧／ルール／手順／記録 を提出・提示できる形に整えるところから始めるのが現実的です。

タイプ別：次のアクション

• 発注側：取引の重要度（データ保護・停止影響・接続の有無）に応じて、委託先に求める★と確認方法を決める
• 受注側：まず★3相当の最小セット（体制・一覧・ルール・手順・記録）を整え、必要に応じて★4の運用（取引先管理・検知/対応）へ拡張する
• 情シス/監査：ログの「取得」だけでなく「保護」「確認定義」「レビュー記録」まで含めて、説明できる状態を作る