システム開発を外注するときのセキュリティリスクとは？発注側が契約前に確認すべきポイントを解説

「セキュリティは開発会社に任せておけば、問題ないだろうか」

外注でシステム開発を依頼するとき、こんな不安を感じたことがある方は多いはずです。

開発会社への確認の仕方がわからない。

どこまで要件として指定すればいいかわからない。

何かあったとき誰が責任を取るのかも、曖昧なまま進んでいる。

こうした状態のまま進めることは、リスクを丸ごと発注側が引き受けることと変わりません。

セキュリティ要件が厳しい案件にも対応してきた経験をもとに、発注担当者の方に向けて整理しました。

読み終えると、次の発注前に確認すべき項目が具体的に洗い出せます。

システム開発の外注で起きやすい4つのセキュリティリスク

システム開発を外注するとき、セキュリティ面で問題が起きやすいのは4つの領域です。

これらは個別に発生するのではなく、セキュリティ要件の不明確さや確認不足をきっかけに連鎖する構造を持っています。

IPAが公表する「情報セキュリティ10大脅威 2026（組織編）」では、ランサム攻撃による被害が1位、サプライチェーン（委託先・関係会社など）の弱点を突いた攻撃が2位に位置づけられています。

「自社の外側にある委託先も含めて守る」という前提が、今やセキュリティの常識になっているのです。

データ管理不備が引き起こす情報漏えい・データ流出

外注先の情報管理体制が不十分だと、顧客情報や機密データの漏えいに直結します。

開発・テスト環境でのデータ管理の不備、担当者のPC紛失、アクセス権限の設定ミスなど、漏えいの経路は一つではありません。

「外注先の担当者が自社のデータを扱っている」という事実を、発注側は常に意識しておく必要があります。

事故規模の実態として参考になるのが、個人情報保護委員会の令和6年度年次報告です。

個人情報取扱事業者等からの漏えい等報告は1年間で19,056件にのぼり、そのうち1,000人以下の規模が88.3%を占めています。

「大規模な事故だけを警戒すれば十分」という考えは通じません。

日常的に起きる小さな事故まで想定した管理体制が必要です。

外注先に自社データを預ける以上、「うちは大丈夫」という前提は成り立ちません。

また同報告では、不正アクセス等「悪意ある行為が疑われるもの」が一定割合を占めることも示されており、誤操作だけを防げばいいわけでもないことがわかります。

法的にも、発注側は無関係ではありません。

個人情報保護法では、個人データの取扱いを委託する場合、委託元が「必要かつ適切な監督」を行う義務を負うと定められています（法第25条）。

「委託先に任せたから発注側は関係ない」という考えは、法的に通用しないのです。

脆弱性テストなしの本番移行が招く不正アクセス

システムに脆弱性が残ったまま本番環境へ移行すると、第三者による不正アクセスを招きます。

脆弱性とは、攻撃者にとっての「入口」となる弱点のことです。

ランサムウェアによるデータ暗号化、サービス停止、マルウェア感染。

こうした被害は、テスト不足や設計上の考慮不足が原因で生じます。

発注側が確認しなければ、脆弱性テストなしで納品が完了することもあります。

統計データを見ると、脅威の規模感がわかります。

IPAが運営するJVN iPedia（脆弱性対策情報データベース）によると、2025年に登録された脆弱性のうち、深刻度が「緊急」のものは14.7%、「重要」は35.5%です。

また、同データベースでは「既知の脆弱性回避のためアップデート等を速やかに行うべき」と明記されており、脆弱性対応は開発時だけでなく運用フェーズを通じて継続して発生する課題であることがわかります。

「セキュリティのチェックを行うこと」と「問題が見つかったときの対応手順」を発注前に決めておかないと、いざ問題が起きたとき誰が何をすべきか分からないまま対応が遅れます。

セキュリティ設計の抜け漏れ

発注側が「当然やってくれるはず」と思っている間に、開発会社は「指示がないので最低限で対応する」と判断する。

この認識のすれ違いが、セキュリティ設計の抜け漏れを生むもっとも多い原因です。

具体的には、次のような流れで抜け漏れが生じます。

心当たりのある流れではないでしょうか。気づいたときには本番稼働後、という状況は珍しくないのです。

問題は、セキュリティは後付けがもっとも困難な要素の一つだということです。

初期段階で組み込まなければ、後から追加しようとするだけで、設計の根本的な見直しが必要になります。

「企画工程からセキュリティを組み込む」という考え方は、開発工程に限らず運用フェーズも含めた一貫した対策を前提にしています。

「まず機能を作り、セキュリティは後で」ではなく、目的と機能が決まった段階で守り方もセットで定義する発想の転換が必要です。

インシデント対応の遅延

セキュリティインシデントが発生したとき、「誰が対応するのか」「損害賠償の範囲はどこまでか」が契約で明確になっていないと、初動が遅れて被害が拡大します。

外注では、この責任の所在が曖昧になりやすいです。

特に問題になりやすいのが、再委託が絡む場合です。

個人情報保護法の解釈上、委託元は委託先が再委託先を適切に監督しているかも含めて監督義務を負います。

「契約で委託先に任せた」としても、発注者が完全に無関係になるわけではないのです。

「セキュリティ対策を行う」と契約書にあっても、インシデント発生時の対応フローや連絡体制が記載されていないケースが多く見られます。

問題発生時の対応フローと責任範囲は、契約前に明確に合意しておく必要があります。

「開発会社に任せれば大丈夫」は通用しない。その理由

「セキュリティは専門的な領域だから、開発会社に任せておけばいい」という考え方は、法制度の建て付けとも、実務的な契約構造とも食い違っています。

2つの観点から、その理由を整理します。

契約書だけでは実装レベルを担保できないから

「暗号化を実施」「アクセス制御を設定」と契約書に記載されていても、実際の実装レベルが十分かどうかは別問題です。

契約書の文言は「何をするか」を定めるものであり、「どのレベルでやるか」は設計書・仕様書で確認するしかありません。

「契約書があれば安心」という認識では、実装レベルの確認が抜け落ちるのです。

契約上、受注者には「仕様書に記載されたセキュリティ仕様に従って対策を講じる義務」しか発生しません。

つまり、仕様書に具体的な基準が書かれていなければ、開発会社は最低限の対応をしても義務を果たしたことになります。

仕様（設計書・仕様書）の側にセキュリティを落とし込むことが、実装レベルを担保するための手段です。

重要なのは、設計書・仕様書レベルで確認できる体制を持つ会社かどうかです。

「セキュリティ設計書を確認させてください」と依頼したとき、具体的に開示できる会社は透明性が高いと判断できます。

法律上、再委託先への管理責任も発注側が負うから

依頼した会社が、実際の開発を別の会社に再委託している場合があります。

この場合、再委託先がどのようなセキュリティ管理体制を持っているか、発注側には確認できません。

自社のデータを、セキュリティ基準が不明な第三者が扱う可能性があるのです。

委託の連鎖が深まるほど、情報漏えいリスクの追跡も難しくなります。

「再委託しているかどうか」「再委託先のセキュリティ管理体制はどうなっているか」を事前に確認することは、リスク管理の基本です。

こうした再委託リスクを構造的に防ぐには、内製率の高い開発会社を選ぶことが一つの方法です。

開発を依頼する前に、発注側が決めておくべきこと

といっても、専門的なセキュリティ設計書を作る必要はありません。

「うちのシステムに何が入っていて、何を守りたいか」を自社なりに整理しておく。それだけで、開発会社とのやりとりが格段にスムーズになります。

3つの観点で考えてみましょう。

何を守るか：扱うデータの棚卸し

まず「このシステムで扱う情報の中で、守るべきものは何か」を確認することから始めます。

保護対象が曖昧なままでは、開発会社も「どこを重点的に守るか」を判断できません。

主な保護対象の例として、次のようなものがあります。

「顧客情報は扱う。カード情報は扱わない。社内用のデータは○○がある」という程度の整理でも、開発会社にとっては大きな判断材料になります。

「個人情報を扱うか」という確認だけでも早めにしておくと、後から「対応が必要だった」と気づくケースを減らせます。

どのレベルで守るか：最低限の希望を伝える

「セキュリティ対策をお願いします」だけでは、開発会社はどのレベルで対応すればいいか判断できません。

すべてを仕様書に落とし込む必要はありませんが、要望の方向性だけでも伝えておくと認識のすれ違いを防げます。

たとえば、次のような点を箇条書きでメモしておくだけでまずは十分です。

細かい仕様は開発会社と一緒に詰めていけます。「こういう方向性で進めたい」という意思表示があると、見積もりの精度も上がります。

見積もり前の段階で「標準対応に含まれるもの」と「追加費用になるもの」を確認しておくと、後から想定外の費用が発生するリスクも下がります。

開発後のセキュリティ維持：保守の範囲を確認する

システムは納品して終わりではありません。

OSのアップデートや脆弱性の修正など、リリース後も継続的なメンテナンスが必要です。発注前に「保守契約に何が含まれているか」を確認しておきましょう。

特に以下の点は、早めに確認しておくと安心です。

「納品したら終わり」の保守契約だと、問題が起きてから自分たちで対応業者を探すことになります。

開発会社に頼む際は、セキュリティ対応まで含めてどこまで面倒を見てもらえるか、契約前に確認しておくのが得策です。

レブクリエイトでは、仕様設計フェーズから伴走し、ビジネス要件・使いやすさ・将来の拡張性・セキュリティ面・工数など複数の側面を検討してベストな仕様をクライアントと共に作り上げます。

「書いてあることだけを作る」のではなく、要件の妥当性から一緒に考える体制を整えています。

不具合発生時の平均復旧時間は5分〜1時間以内で、障害が検知された場合は稼働時間内は即時対応・完了連絡まで行う体制を整えています。

セキュリティに対応できる開発会社か、依頼前に何を確認すればいい？

セキュリティリスクを理解し、発注側の整理もできました。

最後は「その会社が、基本的なセキュリティ対応まで含めて一緒に考えてくれる会社かどうか」を見極めることです。

難しく考えすぎる必要はありません。商談や問い合わせの場で、以下のような質問を一声かけてみるだけで、会社の姿勢はある程度わかります。

1 セキュリティ対応の実績・認証の有無

プライバシーマーク・ISMS（ISO/IEC 27001）といった第三者認証や、情報処理安全確保支援士（登録セキスペ）という国家資格を持つ担当者の在籍は、客観的な安心材料になります。

ただ、こうした証明がなければNGというわけではありません。

「個人情報を扱うシステムを作ったことがあるか」「セキュリティ面で気をつけている点は何か」と聞いてみて、具体的に答えてくれる会社かどうかのほうが、実際の対応力を見極めるには参考になります。

「対策はやっています」という一言で終わらせず、実際の経験を話してくれる会社は信頼しやすいです。

2 セキュリティの方針を説明してもらえるか

「暗号化やアクセス制御はどのように対応していますか」と聞いてみてください。

口頭でも文書でも、開発方針として具体的に説明できる会社は実装の透明性が高いです。逆に「標準的な対応をしています」という曖昧な答えしか返ってこない場合は、後から認識のずれが生じやすくなります。

仕様書レベルで確認させてもらえるかどうかも、ひとつの判断材料になります。

3 問題が起きたときの連絡体制があるか

「何かトラブルが起きた場合、どのように対応してもらえますか」と一声かけてみましょう。

問い合わせ窓口や対応の流れを具体的に説明できる会社は、問題が起きたときの動き方が決まっています。「そのときに考えます」という答えが返ってくる会社は、実際の対応が後手になりやすいです。

4 社内のデータ管理について話してもらえるか

自社のデータを扱う会社の社内体制も、確認しておいて損はありません。

「開発中、うちのデータはどのように管理されますか」という形で聞いてみると、担当者のデータへの意識が伝わります。「各担当者のアクセス権限は分けています」「開発用端末の管理ルールがあります」と具体的に答えられる会社は、内部のデータ管理もしっかりしている可能性が高いです。

5 納品後の保守に何が含まれるか

「保守契約ではセキュリティ対応も含まれますか」と確認しておきましょう。

OS・ミドルウェアのアップデート対応や、脆弱性が発見されたときの修正が保守範囲に含まれているかどうかは、会社によって異なります。

納品後のことまで面倒を見てもらえる体制が整っているかを確認しておくと、後から「どうすればいいかわからない」という状況を防げます。

まとめ：発注前に整理しておくこと

難しく考えすぎる必要はありません。

「何を守りたいか」「どんな対応を希望するか」「納品後も面倒を見てもらえるか」。この3点を事前に整理しておくだけで、開発会社との認識のずれはかなり減ります。

ポイントを整理すると、次の4点です。

「セキュリティのことは詳しくないから、どこまで聞いていいかわからない」という段階からでも、遠慮なくご相談ください。

何を確認すればいいかの整理段階から、一緒に進めていきます。

レブクリエイトはプライバシーマーク取得・内製率94%の純国産体制。

開発案件でも、セキュリティ面の整理から保守まで一貫して対応します。