2026.09.23

サプライチェーン・サイバーセキュリティ対策促進事業｜SCS評価制度と準備の進め方を確認

Q: ★1〜★5は中小企業でも達成できますか？

中小企業でも、段階的に達成する設計が現実的です。重要なのは「高度な対策を一気に入れる」より、評価で問われる基本事項を運用証跡として残せる状態にすることです。例えば経産省・IPAの実務資料で示される範囲でも、まずはIT資産の洗い出し（シャドーIT確認を含む）と、脆弱性情報の収集・パッチ適用・記録保存のサイクルを回すことが出発点になります。特に、外部公開機器（VPN装置等）を放置しない、予備機もアップデートする、といった基本の徹底は規模に関わらず実装可能です。

経営リスクナビ編集部

サプライチェーン・サイバーセキュリティ対策促進事業やSCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）の検討が進む中、発注側・受注側のどちらにとっても「評価をどう調達・契約・運用に組み込むか」が差し迫った実務論点になっています。基準やチェックリスト対応を場当たりに続けると、証跡不足のまま監査・審査直前で詰まりやすく、取引継続判断や投資判断が止まる不利益につながります。2021年の日本国内のランサムウェア被害確認事例が58件と整理されている状況も踏まえ、制度理解を「体制・証跡・契約」まで落とす準備が必要です。以下では、促進事業とSCS評価制度の判断材料として実務の論点を示します。

事業とSCS評価制度の全体像
- 促進事業と評価制度の位置づけ
- 制度創設の背景と事業目的
サプライチェーンリスクの現状
SCS評価制度の基本構造
関連制度と支援策の整理
発注側の実務と調達対応
受注側の準備とロードマップ
よくある質問
サプライチェーン・サイバーセキュリティ対策促進事業への対応で次にすべきこと

事業とSCS評価制度の全体像

促進事業と評価制度の位置づけ

サプライチェーン全体のセキュリティ水準をそろえるために、経済産業省・IPA（独立行政法人情報処理推進機構）で「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」の構築が検討されています。発注側が取引先へ個別のチェックリスト配布や現地訪問での目視確認を行うケースが増える一方、受注側は類似の問診票に繰り返し対応するなど、双方に大きな事務負担が生じてきました。

SCS評価制度は、こうしたばらつきを是正し、事業者の対策状況を共通の尺度で可視化して相互に使える状態にすることを狙うものです。行政・支援機関による「サプライチェーン・サイバーセキュリティ対策促進事業」等の支援策と組み合わせることで、対策の実装（規程整備、運用証跡の蓄積、ツール導入等）を現場で進めやすくします。

実務での捉え方（発注側・受注側共通）

発注側は取引先の評価結果を調達判断に再利用し、個別監査・個別問診の回数を減らす設計にします。
受注側は「依頼されたからやる」だけでなく、評価結果を自社の信頼性の説明資料（取引継続・新規受注の根拠）として位置付けます。
経営者がサイバーセキュリティを「わからない」状態だと投資判断が止まりやすいため、評価制度を意思決定の共通言語として使います（IPAの問題提起）。

制度創設の背景と事業目的

近年、攻撃者は本体企業を直接狙うだけでなく、対策が相対的に弱い委託先・関連会社を起点に侵入し、サプライチェーン全体へ影響を広げる手口を強めています。ランサムウェアでは、データ暗号化で業務停止に追い込むだけでなく、ダークウェブ上のリークサイト等で窃取データの一部公開を示唆して脅迫する「二重脅迫」が増えていることが指摘されています。

一次情報に基づく被害把握として、日本プライバシー認証機構が2022年1月に公開したレポート「拡大するランサムウェアビジネス」では、2021年の日本国内の被害確認事例は58件と整理されています。また同レポートの集計では、製造業が最も多く、次いで流通サービス業が多い傾向が示されています。製造業では、部品供給が止まるなどで操業が停止しうるため、上位企業が下位企業へチェックリスト配布や実態調査（現地訪問・目視確認）に踏み込む動きが出ています（IPAの記述）。

SCS評価制度の目的は、企業ごとに乱立した評価基準を統一し、

制度が狙う成果（目的の分解）

評価尺度をそろえて確認作業を標準化し、同種の回答作業の反復を減らすこと。
サプライチェーン全体の最低ラインを引き上げ、取引継続・操業継続の確度を高めること。
対策が極めて脆弱で改善が進まない場合に、上位企業側で取引見直しが検討され得るという現実（優先順位低下・業績影響）を、制度設計と支援策で「改善へ向かう動機」に転換すること。

サプライチェーンリスクの現状

サイバー攻撃の傾向と経営影響

攻撃は、単一組織の侵害にとどまらず、委託関係を介して連鎖しやすい構造になっています。ランサムウェアでは、リークサイトで窃取データの一部公開を示して脅迫する手口が多くなっているとされ、業務停止と情報漏えいの両面で損害が拡大します。

被害後は技術対応だけでなく、関係者対応が経営課題として顕在化します。JPCERT/CCの整理（インシデント対応状況の解説）でも、サイバー攻撃による混乱が、被害企業と取引先のシステム会社との関係悪化など次の問題を引き起こし得る点が示されています。さらに、情報漏えいのおそれがある場合、被害企業が個人情報保護委員会や警察へ相談する場面が想定されることも、実務上の対応イメージとして示されています。

経営インパクトとして押さえる論点

自社だけでなく取引先へ提供した情報が漏えいすると、提供元にも責任追及が及ぶ可能性が高まります（IPAの注意喚起）。
製造業では部品が届かない等で操業が止まり得るため、サプライチェーン途絶が売上に直結します（IPAの記述）。
事故後は技術復旧に加え、取引先への報告、契約確認、再発防止説明が必要になり、平時の契約・証跡整備の差が顕在化します。

主なリスク要因と典型課題

リスク要因は「接続点の増加」だけではなく、把握できていない資産・委託範囲が侵入口になりやすい点にあります。経済産業省・IPAの実務資料では、ネットワーク構成把握と合わせて、社内の機器・ソフトウェア等のIT資産を漏れなく把握し、許可されていない回線・端末・ITサービス（シャドーIT）の存在を確認する必要があるとされています。IaaS/PaaSなどクラウド環境も含め、意図せず公開されたサービスがないか確認すること、またパスワード認証で公開されたSSHやリモートデスクトップ経由で侵入された事例があることも示されています。

脆弱性対応では「稼働優先で放置する」こと自体が攻撃者の的になりやすいとされ、特に外部からアクセスするネットワーク機器（例：VPN装置）が侵入の糸口になりやすい点が強調されています。さらに、冗長化のための予備機のアップデート放置が、障害時の切替を契機に侵入につながり得るという注意点もあります。

典型的に詰まりやすいポイント（委託管理を含む）

シャドーITの存在により「管理外の入口」が残り続けます（経産省・IPAの指摘）。
脆弱性情報の収集とパッチ適用が遅れると、外部公開機器が優先的に狙われます（経産省・IPAの指摘）。
外部ベンダー委託で「構築のみ契約」だと、保守・アップデートが範囲外となり脆弱性が放置されます（経産省・IPAの注意喚起）。

認知度調査から見る企業の課題

中堅・中小企業では、対策の必要性を理解していても、投資と体制整備が進みにくい現実があります。実務者側の見立てとして、「日本の民間企業はサイバー投資を嫌っている」のではなく、経営者がサイバーセキュリティを「わからない」ため投資のしようがないという指摘があります。つまり、意思決定者が納得できる形で論点が整理されると、企業規模にかかわらず投資が進み得る一方、知識不足が投資停滞の根本原因になり得ます。

また、取引先からの要請は、経営者の意思決定を高める現実的な契機にもなります。上位企業がチェックリスト配布や現地での目視確認に踏み込むケースがあること、対策が極めて脆弱で改善依頼に応じない場合は、取引先見直しにより優先順位が下がり業績に直接影響し得ることが指摘されています（IPAの記述）。

社内でボトルネックになりやすい構造

経営層が判断材料を持てず「わからない」状態のまま、予算化と優先順位付けが止まります。
情報システム担当が「社長、強化しましょう」と提案すること自体が心理的に重く、提案が通らないと対策が進みません（IPAの指摘）。
取引先要請に受動的に応じるだけでは、証跡や委託管理が後追いになり、審査・監査の直前で詰まります。

SCS評価制度の基本構造

評価段階と評価領域の考え方

SCS評価制度は、事業者の取組状況を共通の尺度で示すために、段階（レベル）を設け、領域を分けて評価する設計が想定されます。制度設計においては、等級ごとに求められる能力・行動・成果を測るという考え方が示されており、定量評価は客観性を高める一方、定性評価も含めて納得感を持たせる工夫が必要とされています。また、単なる査定機能だけでなく、評価結果のフィードバックを通じた育成機能（改善につなげる機能）を併せ持つことが重要と整理されています。

評価領域は、組織・技術・物理・人のように多面的に捉え、特定分野だけ強くても他が弱いという「穴」を残さないことが要点です。

領域別に「証跡」として残しやすい例

組織的対策：基本方針、規程、役割分担、委託管理ルール、例外承認の記録。
技術的対策：資産台帳、パッチ適用記録、ログ取得・点検記録、C2（C&C）サイト遮断の設定方針。
物理的対策：入退室管理、機器保管ルール、持出申請・点検表。
人的対策：教育受講履歴、誓約書、理解度確認（テスト等）の実施記録。

評価対象の範囲と適用イメージ

評価制度を実務に落とす際は、最初に「どこまでを評価対象にするか」を定義し、対象範囲に対して証跡が残る運用を設計します。経済産業省・IPAの実務観点では、ネットワーク構成とIT資産の把握が侵入経路の想定に直結するとされ、IaaS/PaaSを含むクラウド環境や、意図せず公開されたサービスの確認も範囲に含めて検討することが推奨されています。

範囲定義の方法は、全社一律ではなく、受託業務・取り扱い情報・接続形態に応じて切り分けるのが現実的です。

範囲定義で最初に合意しておく観点

対象業務：発注側から受託しているどの業務・どの拠点を対象にするか。
対象データ：顧客情報、設計情報など、取り扱う情報資産の種類と保管場所（オンプレ・クラウド）。
対象接続：SSHやリモートデスクトップ、VPN装置など外部公開・遠隔接続の有無（侵入経路になりやすいとの指摘）。
対象資産：許可端末だけでなくシャドーITの洗い出しを評価対象の前提作業に含めるか（経産省・IPAの指摘）。

OT・製品セキュリティ・子会社管理はSCS評価対象か――IT基盤との線引きを先に決める

OT（工場制御）や製品セキュリティ、子会社・委託先管理をどこまで含めるかは、評価の実装可能性に直結します。特にOTは可用性（止めないこと）が強く求められ、ITと同じ更新手順をそのまま当てると現場混乱を招き得ます。

また、サプライチェーンの上位企業が、下位企業に対してチェックリスト配布や現地訪問による目視確認に踏み込む例がある一方で、下位企業側が改善依頼に応じない場合、優先順位の低下や取引見直しによって業績に影響し得るという指摘もあります（IPAの記述）。この現実を踏まえると、「何をSCSで担保し、何を別枠の基準で担保するか」を先に決め、説明できる形にしておくことが重要です。

線引きを決めるときの実務ポイント

まずは社内IT基盤・情報管理（資産管理、脆弱性管理、ログ、委託管理）をSCSの中心に据えます。
OTや製品領域は、更新停止が許されない設備や開発プロセスの特性を踏まえ、別のガイドライン・基準で補完し、接点（ネットワーク分離、例外運用、遠隔保守の管理）を文書化します。
子会社や再委託先まで含む場合は、「把握できないものには投資できない」という前提で、まず可視化（対象の特定と契約関係の整理）を優先します。

発注側の実務と調達対応

調達に評価制度を組み込む方法

発注側は、評価制度を「調達の入口」に組み込みつつ、現場運用としては既存のチェックリスト運用や現地確認が発生してきた背景を踏まえ、重複を減らす設計にします。IPAの記述でも、上位企業が下位企業に対しチェックリスト配布や、場合によって現地訪問で目視確認する実態調査に乗り出すケースがあるとされています。

調達プロセスへの組込み手順（例）

調達カテゴリ別に、取り扱い情報と接続形態（VPN・リモート接続・クラウド利用）からリスク区分を定義します。
RFP・公募要領に、SCS評価の扱い（参加資格／加点／契約後の取得計画）を明記します。
既存の個別問診票・現地確認を、評価結果と突合して最小化し、追加確認が必要な場合の条件（例外）を決めます。
取引開始後は、委託範囲（再委託含む）と公開サービス有無など、侵入経路になり得るポイントの変更を申告させ、証跡を管理します。

契約条項と独禁法下請法への配慮

契約では、インシデント時の連絡・報告だけでなく、平時の責任分界と運用記録の扱いを具体化することが重要です。実務資料でも、より厳しい取引先へ報告する場合、事前に「情報の取り扱いに関する契約書」に目を通すことが望ましいとされ、契約条項が責任追及の根拠として提示され得る点が示唆されています。

契約で明確化しておきたい事項（例）

セキュリティ水準の維持義務と、変更時の通知・承認プロセス。
事故時の一次報告期限・連絡先・証拠保全（ログ等）の協力義務。
再委託・再々委託の条件（事前承認、同等水準の義務付け、把握・可視化）。
ベンダー委託の場合の責任分界（構築のみか、パッチ適用・アップデート等の保守まで含むかは特に要確認：経産省・IPAの注意喚起）。

一方で、要求水準やコスト負担の一方的転嫁は、取引適正の観点からリスクがあります。下請法に該当しない程度の圧力（強制力）がないと着手しにくい現実があるという指摘もあるため、発注側は「必要性の説明」と「移行設計」をセットで運用し、優越的地位の濫用や買いたたき等の疑義が生じないよう配慮します（法令名として独占禁止法・下請法）。

新規調達と既存取引で要求水準を分ける基準――一律に★を求めず業務重要度で決める

要求水準を一律にすると、現実には対応不能な取引先が増え、供給途絶や価格高騰を招きます。特に製造業では部品供給の途絶が操業停止につながり得るため、重要業務の見極めが不可欠です（IPAの記述）。

区分	取り扱い・接続の特徴	要求水準の考え方
高	基幹系に接続、機密情報を継続的に取り扱い、遠隔接続（VPN等）や外部公開要素がある	高い評価レベルを求め、委託範囲・保守範囲（アップデート含む）を契約で厳密化します。
中	限定された情報・限定された期間の取扱い、クラウド利用があるが公開設定は統制可能	段階的な取得計画を条件化し、資産台帳・脆弱性対応台帳の整備を重視します。
低	機密情報を扱わず、ネットワーク接続も限定的	基礎的な自己宣言と最低限の運用（教育・誓約等）を中心にし、過剰要求を避けます。

業務重要度に基づく要求水準の考え方（例）

既存取引先には、改善依頼をしても対策を行わない場合に取引見直し・優先順位低下で業績影響が出得るという現実（IPAの指摘）も踏まえつつ、いきなりの排除ではなく、改善計画と猶予期間、必要な支援（情報提供、テンプレート提供）を組み合わせた運用が望まれます。

受注側の準備とロードマップ

IT資産管理と脆弱性対応の進め方

受注側の出発点は、IT資産管理と脆弱性対応の「回る仕組み」を作ることです。経済産業省・IPAの実務資料では、ネットワーク構成の把握と同時に、機器・ソフトウェア等のIT資産を漏れなく把握する必要があること、また許可されていない回線・端末・ITサービス（シャドーIT）が侵入に悪用され得ることが示されています。さらに、IaaS/PaaS等のクラウド環境を含め、不用意に公開されたサービスがないか確認すること、パスワード認証で公開されたSSHやリモートデスクトップ経由の侵入事例があることも示されています。

脆弱性対応については、稼働優先で放置すると攻撃者の的になりやすく、外部公開機器が侵入の糸口になりやすいとされています。加えて、冗長化の予備機もアップデートを怠ると、障害時の切替で侵入され得るという注意点があります。パッチ適用の影響が懸念される場合、テスト環境を用意して影響有無を確認する方法が示されています。

資産管理・脆弱性対応を評価に耐える形にする手順

IT資産を洗い出し、シャドーITの有無を確認して台帳化します（端末・サーバ・ネットワーク機器・クラウド・公開サービス）。
脆弱性情報の収集ルートを決め、影響評価→パッチ適用または緩和策→記録保存の流れを定義します。
外部公開機器（VPN装置等）と遠隔接続（SSH・RDP等）を優先して点検し、公開設定の棚卸しを行います。
予備機・冗長構成も含めてアップデート方針を適用し、障害時切替が新たな侵入口にならないようにします。
パッチ適用の影響が懸念される場合はテスト環境で影響確認を行い、その結果を証跡として残します（経産省・IPAの推奨）。

申請直前で詰まりやすい証拠資料の不足とは――誰がいつ何を残すかを部門別に決める

申請直前に詰まりやすいのは、「規程はあるが運用証跡がない」状態です。評価・監査では、文書の有無だけでなく、日常運用で守られていることを示す客観的証拠が求められます。

また、事故時には取引先への報告が必要になり、より厳しい取引先への報告では契約書を示されて責任追及され得るため、事前に情報取扱い契約を確認しておくことが望ましいとされています。したがって、証跡は「審査のため」だけでなく、事故時の説明責任のための基盤でもあります。

部門別に割り当てる証跡（例）

情報システム：資産台帳、パッチ適用ログ、外部公開設定の点検記録、アクセスログ取得・点検記録。
総務・人事：誓約書、教育受講履歴、入退室記録、端末持出申請・返却確認。
現場部門：外部媒体利用申請、例外運用の承認記録、委託先への指示・確認記録。
経営層：リスク受容（例外承認）や投資判断の議事録・決裁記録（「わからない」状態を解消し意思決定を示す：IPAの指摘に対応）。

外部ベンダー任せで不合格になりやすい会社の特徴――委託契約・運用記録・責任分界の見落とし

外部ベンダーに委託している企業ほど、責任分界と保守範囲の確認が甘いと評価で不利になり得ます。経済産業省・IPAの実務資料でも、VPN装置等のネットワーク機器やシステム構築を外部に委託した場合に、パッチ適用やアップデート等の製品保守まで対応してくれるかをサービス仕様として確認すべきこと、構築のみの契約で脆弱性が放置されたまま攻撃を受けたケースがあり得ること、そしてアウトソーシングでは自組織とベンダー側の責任範囲を明確にする重要性が示されています。

さらに、侵害時の初動対応では、C2（C&C）サイト遮断や不正通信端末の隔離などの対応が必要になり得るため、誰がどこまで対応し、どの報告書・ログを残すかを契約と運用で決めておく必要があります。

ベンダー任せで見落としやすい確認事項

委託範囲が「構築のみ」か「保守（パッチ適用・アップデート）まで含む」かを契約上明確にします（経産省・IPAの注意喚起）。
ログの取得・保管・点検の実施主体と、報告書の受領・承認フローを決めます。
外部公開機器（VPN装置等）や遠隔接続（SSH・RDP等）の設定変更時に、ベンダー側の作業記録と自社側の承認記録が残るようにします。
不正通信が疑われる場合の端末隔離・調査・復旧の手順と、ベンダーの支援条件（時間帯、費用、連絡経路）を合意します。

よくある質問

対象企業はどのような条件で決まりますか？

対象は特定業種に限定されず、上位企業・委託元の調達基準と、取り扱う情報・接続形態によって実質的に決まります。IPAの記述でも、上位企業が下位企業へセキュリティチェックリスト配布や、場合によって現地訪問での目視確認を行うケースがあるとされており、調達実務の要請が対象範囲を具体化していく構造です。

また、情報提供先で漏えいが起きると提供元にも責任が及ぶ可能性があるため（IPAの注意喚起）、機密情報や基幹系に関係する委託では、一次委託先だけでなく再委託先まで含めた可視化が重要になります。

自社が対象になりやすい条件（棚卸し観点）

取引先からチェックリスト回答や現地確認を求められている。
顧客情報等を預かり、事故時に個人情報保護委員会や警察への相談が想定される。
VPN装置、SSH、リモートデスクトップなど遠隔接続・外部公開要素がある（侵入経路になり得るとの指摘）。

★1〜★5は中小企業でも達成できますか？

中小企業でも、段階的に達成する設計が現実的です。重要なのは「高度な対策を一気に入れる」より、評価で問われる基本事項を運用証跡として残せる状態にすることです。

例えば経産省・IPAの実務資料で示される範囲でも、まずはIT資産の洗い出し（シャドーIT確認を含む）と、脆弱性情報の収集・パッチ適用・記録保存のサイクルを回すことが出発点になります。特に、外部公開機器（VPN装置等）を放置しない、予備機もアップデートする、といった基本の徹底は規模に関わらず実装可能です。

SECURITY ACTION二つ星があると有利ですか？

有利になり得ます。二つ星の過程で基本方針や体制の整備に着手していることを示せるため、評価制度への移行で「ゼロから作る」負担を減らせます。

ただし、IPAの指摘のとおり、経営者がサイバーセキュリティを「わからない」状態だと投資判断が止まりやすい点は残ります。二つ星を単なる宣言で終わらせず、資産台帳や脆弱性対応台帳、委託範囲（保守の有無を含む）を含めた運用設計に進めることで、実際の審査・監査で説明できる状態に近づきます。

発注側が★評価を求めると問題になりますか？

求めること自体が直ちに問題になるとは限りませんが、運用次第で法的・実務的リスクが高まります。IPAの記述でも、日本では下請法に該当しない程度の圧力（強制力）がないと着手しにくい面があるという指摘があり、現場要請が強まりやすい構造があります。

一方で、準備期間やコスト負担への配慮なく一方的に高い水準を強制したり、改善余地があるのに取引打切りを示唆して不当に不利益を与えたりすると、独占禁止法や下請法の観点で問題視され得ます（法令名として独占禁止法・下請法）。取引の適正を確保しつつ、チェックリスト配布・目視確認など既存の確認実務を評価制度へ整理統合し、段階的移行と伴走支援を設計することが重要です。

サプライチェーン・サイバーセキュリティ対策促進事業への対応で次にすべきこと

本稿で扱った促進事業とSCS評価制度は、単なる制度理解にとどまらず、調達判断・契約条項・日常運用の証跡を同じ軸でそろえることに実務上の意味があります。特に、評価対象範囲（IT基盤／OT／子会社・再委託先）を先に定義し、資産台帳・脆弱性対応台帳・委託管理台帳などの証跡が部門横断で残る設計にすると、チェックリストや目視確認の重複を減らしやすくなります。判断の軸は「業務重要度に応じて要求水準を分けること」と「責任分界（構築のみか保守まで含むか等）を契約で説明できること」であり、これが不足すると事故時の説明責任にも波及します。次アクションとしては、発注側はRFP・契約・運用変更申告の流れに評価結果の再利用を組み込み、受注側は外部公開機器や遠隔接続を優先して点検・記録し、2021年に被害確認事例が58件と整理されている現実に照らして優先順位を付けることが現実的です。個別案件での要求水準や法令（独占禁止法・下請法）との関係は事情により変わるため、必要に応じて法務・情報システム・経営層で早めに相談し、専門家の助言も踏まえて整理してください。