委託先のセキュリティをどう確認？SCS評価制度で変わる発注実務

この記事のポイント

• 委託先の確認は個別の調査票から共通の基準★へ移る
• ★だけで判断せず、コード・データ・AIの扱いを個別に確認
• セキュリティ要件はモック段階の要件定義で決めておく

システム開発やSaaS、クラウドを外部に頼むとき、委託先のセキュリティをどこまで確かめればよいのか迷う方は多いはずです。取引先ごとに違う形式のセキュリティチェックシート（委託先に対策状況を答えてもらう調査票）を送り、回答を読み比べる作業は、発注側にも受注側にも大きな負担になっています。

経済産業省は、サプライチェーン全体のセキュリティを共通の基準で確かめられるようにする「SCS評価制度」の準備を進めています。この記事では、発注側の立場から、制度で委託先の確認がどう変わるか、開発会社に何を確認し、契約や発注の手続きにどう組み込むかを整理します。

サプライチェーン攻撃で問われる発注側の責任

委託先が攻撃の入口になった場合でも、情報漏えいや業務停止の影響を受けるのは発注側の事業であり、委託先を選んで管理する責任は発注側にあります。サプライチェーン攻撃とは、守りの固い大企業を直接狙わず、取引先や委託先など比較的対策の手薄な組織を足がかりにして侵入する攻撃のことです。KDDIのコラムでも、取引先を経由した侵入のリスクと、自社だけでなく取引先を含めた対策の必要性が解説されています。

システム開発の委託では、開発会社がソースコードや本番環境の認証情報、場合によっては顧客データに触れます。委託先の端末やアカウントが乗っ取られれば、そのまま自社のシステムに入られるおそれがあります。自社側の備えについては【2026年版】能動的サイバー防御とは？中小企業の取引先に求められる備えも参考にしてください。

SCS評価制度で委託先チェックはどう変わる？

SCS評価制度によって、取引先ごとにばらばらだった調査票を、★（星）で示す共通の基準に置き換えられるようになります。経済産業省のページでは、サプライチェーンを構成する企業のセキュリティ対策を段階的に評価する制度として、★3・★4の評価基準などが公開されています。2026年10月28日には★3・★4の評価基準Ver1.1が公開され、制度開始に向けた具体化が進んでいます。

個別の調査票の課題

セキュリティチェックシートに関する解説記事でも触れられているように、チェックシートは発注元ごとに項目や形式が異なり、回答する側の負担が重くなりがちです。発注側にとっても、回答の質がばらつき、比較しにくいという問題があります。

共通の基準に置き換える考え方

★を使えば「基本的な対策ができているか」を共通の物差しで確認でき、自社の調査票はその上乗せ部分だけに絞れます。つまり、調査票を「★で確認できる部分」と「自社の案件固有の部分」に分けて考えるのが実務の第一歩です。制度の細かな運用や評価の方法は今後も更新される可能性があるため、最新の内容は経済産業省のページで確認してください。

★を求める取引先・求めない取引先の線引き

すべての取引先に一律で★を求めるのではなく、扱う情報とシステムへの接続の深さで線引きするのが現実的です。小さな取引先にまで高い水準を求めると、取引そのものが成り立たなくなるおそれがあります。

どの★を求めるかは、制度の基準内容を確認したうえで、自社のリスクに見合う水準を選びます。線引きの基準を社内で文書にしておくと、調達担当者ごとの判断のぶれを防げます。

開発会社に確認すべきセキュリティ項目

開発会社には、★の有無に加えて「ソースコード」「本番データ」「脆弱性への対応」の3点を必ず個別に確認してください。★は組織全体の対策水準を示すものであり、自社の案件でどう情報が扱われるかまでは分からないためです。

• ソースコードの扱い：保管場所（リポジトリ）、アクセスできる人の範囲、退職者のアカウント削除の手順
• 本番データの扱い：開発や試験で本番データを使うか、使う場合の匿名化（個人が分からないよう加工すること）、作業端末への保存の可否
• 認証情報の管理：本番環境のパスワードやAPIキーの保管方法、多要素認証の利用
• 脆弱性への対応体制：使っているライブラリの脆弱性（セキュリティ上の欠陥）をどう把握し、どの期間で修正するか
• 再委託：作業の一部を別会社に再委託するか、その場合の管理方法
• 事故時の連絡：インシデント発生時に誰が、どの期間内に発注側へ報告するか

開発会社の選び方全般はAI時代のシステム開発で大事なこと｜失敗しない進め方と開発会社の選び方で解説しています。

AI駆動開発の委託で確認したいAIツールの扱い

AI開発ツールを使う開発会社には、「どのツールに、どの情報を入力してよいか」というルールがあるかを確認してください。AIを使った開発は効率が上がる一方、ソースコードや仕様書をAIサービスに入力する場面が増えるため、情報の扱いが新しい確認項目になります。

• 利用しているAIツールと、入力したデータが学習に使われない設定になっているか
• 顧客のソースコードや本番データをAIに入力してよい範囲の社内ルール
• AIが生成したコードを人がレビューする手順と、脆弱性の確認方法
• 担当者が会社の許可していないAIツールを使わないための管理

最後の点は、社員が許可なくAIを使う「シャドーAI」の問題と同じです。詳しくはシャドーAIとは？中小企業に潜むリスクと今すぐできる5つの対策をご覧ください。AIの利用そのものを禁じるのではなく、ルールの有無と運用の実態を確かめることが大切です。

契約書・発注仕様書に盛り込むポイント

確認した内容は口頭の約束で終わらせず、契約書と発注仕様書に書き込んでおくことが欠かせません。書面にないことは、事故が起きたときに求めにくいためです。

1. 求めるセキュリティ水準：★の取得状況、または同等の対策を求める旨
2. 情報の取り扱い：本番データ・ソースコードの保管、持ち出し、契約終了時の返却や削除
3. AIツールの利用条件：利用してよいツールの範囲と、入力してはいけない情報
4. 再委託の条件：事前承認の要否と、再委託先にも同じ水準を求めること
5. インシデント時の報告：報告の期限と連絡先、調査への協力
6. 脆弱性対応：納品後に見つかった脆弱性の扱いと保守契約での対応範囲

契約の具体的な文言は、自社の法務担当や専門家と相談して決めてください。

モック段階でセキュリティ要件を決める進め方

セキュリティ要件は、開発が始まってからではなく、要件定義の段階、特に動くモック（画面や操作を試せる試作品）を作る段階で決めておくのが効果的です。後から認証方式やデータの持ち方を変えると、設計のやり直しになり費用も期間もふくらむからです。

モックを見ながら次の点を発注側と開発会社で確認すると、要件が具体的になります。

• 誰がどの画面・データにアクセスできるか（権限の設計）
• ログイン方式と多要素認証の要否
• 個人情報など重要なデータをどこに保存し、誰が見られるか
• 操作履歴（ログ）をどこまで残すか
• 開発中に本番データを使うか、試験用データで進めるか

モック先行の進め方そのものはモック先行開発とは｜要件定義の失敗を防ぐ「動くモック」の進め方と依頼のコツで詳しく解説しています。

axflow の視点

株式会社axflowはAI駆動開発とAX（AIトランスフォーメーション）支援の会社として、中小〜中堅企業の業務システムやWebシステムの開発を行っています。私たちは動くモックを最短1〜2週間で無料で作り、そこから要件を固めて開発する「モック先行」の進め方をとっており、このモックの段階で権限やデータの扱いといったセキュリティ要件を発注側と一緒に確認するのが自然な流れです。画面を見ながら話すことで、「この画面は誰が見てよいか」といった判断を早く具体的に決められます。また、既存システムを残したまま業務改革を進める支援も行っているため、既存システムとの接続部分で生じるリスクも含めて相談いただけます。

よくある質問

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

経済産業省が準備を進める、サプライチェーンを構成する企業のセキュリティ対策を★で段階的に評価する制度です。発注元が共通の基準で取引先の対策状況を確かめられるようにすることをねらっています。

★を取得している委託先なら追加の確認は不要ですか？

不要とは言えません。★は組織全体の対策水準を示すもので、自社の案件でソースコードや本番データ、AIツールがどう扱われるかは個別に確認し、契約に盛り込む必要があります。

セキュリティチェックシートはもう使わなくてよいですか？

すぐに廃止するより、★で確認できる共通部分を省き、案件固有の項目だけに絞る形への見直しが現実的です。制度の運用は今後も更新される可能性があるため、最新情報を確認してください。

AI駆動開発の会社に委託するときの注意点は？

利用しているAIツールと学習設定、AIに入力してよい情報の範囲、生成コードのレビュー手順を確認しましょう。許可外のAIツールを使わない管理があるかも重要な確認点です。

セキュリティ要件はいつ決めるべきですか？

要件定義の段階、できれば動くモックを作る段階で決めるのが効果的です。後から権限設計やデータの持ち方を変えると、やり直しで費用と期間がふくらみやすくなります。

まとめ

SCS評価制度により、委託先の確認は取引先ごとの調査票から、★という共通の基準へ移っていきます。発注側は、取引先の重要度で求める水準を線引きし、★で確認できない案件固有の項目（ソースコード、本番データ、AIツール、脆弱性対応）を個別に確認して契約に盛り込むことが大切です。そしてセキュリティ要件は、モック段階の要件定義で早めに決めておくと手戻りを防げます。axflowでは、動くモックを使った要件定義から、セキュリティ要件を含めた業務システム開発までご相談を承っています。無料相談・資料請求はこちらからお気軽にお問い合わせください。

参考

• サプライチェーン強化に向けたセキュリティ対策評価制度（経済産業省）
• サプライチェーン攻撃に関するコラム（KDDI）
• セキュリティチェックシートに関する解説記事（Secure Navi）