システム開発依頼の情報漏洩対策｜発注側が確認すべき対策と委託先の選び方

発注後になってから、こんな不安を感じたことはないでしょうか。

「本当に適切に管理されているのか」 「どこまで扱われているのか把握できているのか」

システム開発を外部に依頼すると、 要件定義書や設計書、ソースコードだけでなく、顧客の個人情報も委託先に渡ります。

実際、委託開発を経験した多くの担当者が、同じ不安を口にします。

厄介なのは、その不安に対して何を確認すればいいのか分からない点です。

委託開発に潜む情報漏洩リスクと、発注側が押さえるべきポイントを見ていきましょう。

システム開発を依頼する際の6つの情報漏洩対策

発注側として「何を確認しておけば安心か」を、6つの観点で整理しました。

それぞれ詳しく解説します。

①情報の取り扱いルールと責任範囲を明確にする

「何をお願いしているか」を書面で整理しておくのが出発点です。

口頭での合意や汎用的な雛形だけでは、後から「誰がどこまで対応するのか」が曖昧になりがちです。委託先に渡す情報の範囲、使っていい目的、開発終了後の扱い方——これらを契約書やNDA（秘密保持契約）に書いておくだけで、認識のずれを防ぎやすくなります。

最低限確認しておきたいのは次の点です。

「契約書があるから大丈夫」ではなく、「何が書かれているか」が重要です。

特に再委託の可否は見落とされやすい点なので、最初に確認しておきましょう。

②アクセス権限を最小限に設定し、ログで監視する

委託開発では、プロジェクトに関わる人数が増えるほど、情報にアクセスできる人も増えます。

そのため、役割ごとに「見ていい情報の範囲」を分けておくことが基本の考え方です。開発担当者・PM・テスト担当者など、担当別にアクセスできる範囲が分かれているかを確認しておきましょう。

見落とされがちなのが、プロジェクト終了後のアカウントの扱いです。

開発が完了しても、委託先スタッフのアカウントが残ったままになっていることも珍しくありません。終了後は速やかに削除するよう、契約で取り決めておきましょう。

もう一点確認しておくと安心なのが、アクセスの記録（ログ）です。

「誰が、いつ、どの情報にアクセスしたか」を記録する体制があれば、何か問題が起きたときの原因確認が格段にしやすくなります。「ログは取っていますか?」と一声かけてみるだけで、委託先の管理意識がある程度わかります。

③テスト環境でのデータマスキングを徹底する

開発中のテスト作業で本番データ（実際の顧客情報など）を使うと、開発担当者全員がその情報を目にすることになります。関わる人数が増えるほど、誤送信や設定ミスのリスクも上がります。

対策として有効なのが「データマスキング」です。

本番データをそのまま使わず、氏名・住所・電話番号などをダミー値に置き換えてからテストに使う方法です。

「テスト時に本番データを使わないようにしているか」「使わない場合、どんなデータを代わりに使っているか」を事前に聞いておくと、委託先の取り組み姿勢がよくわかります。本番データを使わせない方針を契約書に一文書いておくと、より安心です。

④ソースコードとドキュメントの管理を徹底させる

ソースコードや設計書には、システムの仕組みが詰まっています。

管理が曖昧なまま開発が進むと、「誰がいつ変更したか分からない」「データがどこかに残っている」という状況が生まれやすくなります。委託先と共有する前提で、保管場所・変更履歴の記録・開発終了後の消去や返却方法を事前に決めておきましょう。

特に気をつけておきたいのが、プロジェクト終了後のデータの残り方です。

ソースコードや設計書はコピーしやすく、回収が難しい情報です。「どのデータを、いつ、どの方法で消去するか」を契約書に書いておき、完了の確認を取り交わす仕組みを整えておきましょう。

⑤開発環境のセキュリティを本番と同等にする

本番環境は厳重に管理していても、開発・テスト環境の対策が甘いまま、という状況は珍しくありません。

委託先の開発環境にも、基本的なセキュリティ対策が取られているかを確認しておきましょう。

「どんな体制で管理していますか?」とひとこと聞いてみると、対応状況が把握しやすくなります。「開発環境でも本番と同等の対策を求める」旨を契約書に盛り込んでおくと、より明確です。

⑥委託先との定期報告・確認体制を構築する

技術的な対策は整えても、委託先の状況を継続的に把握できなければ意味がありません。報告・確認の仕組みを最初から設計しておくことが大切です。

定例の報告機会には、進捗だけでなく「セキュリティ上の気になること・ヒヤリハット」も共有してもらいましょう。小さなトラブルが報告されないまま放置されると、それが漏洩の引き金になることがあります。

確認しておくと安心な内容は次の3点です。

また、何が「機密情報」に当たるかを要件定義の段階で書面にまとめ、委託先と共有しておきましょう。「これは機密です」と事前に伝えておかないと、委託先が判断できず意図しない流出につながることがあります。

問題が発生したときの連絡先と対応タイミングも、あらかじめ決めておくと安心です。

コミュニケーション品質が情報漏洩リスクにどう影響するか、より詳しく知りたい方はこちらもあわせてご覧ください。

あわせて読みたい

システム開発会社のコミュニケーション品質は重要？失敗を防ぐ判断基準と見極め方

「開発会社に質問しても、返信が3日も来ない」「進捗報告をこちらから催促しないと状況が分からない」 システム開発を進める中で、こうした違和感を覚えた経験がある方も多いのではないでしょうか。ただ、この違和感は「相手が忙しいだけ」「自分の期待が高すぎるだけ」と片付けられがちです。 しかし、システム開発

情報漏洩はなぜ起きる？委託特有の3つの原因

個人情報保護委員会の年次報告（令和6年度）によると、漏洩原因の過半は人的ミスで、不正アクセスが約3割という構図です。

委託に伴い情報の関与者が増えるほど、どの原因も発生しやすくなります。

外部からの攻撃（不正アクセス・マルウェア）

外部からの攻撃は、委託特有のリスクを抱えています。

委託先は、発注者の代替実装者であるだけでなく、攻撃者から見れば「本命（発注者）へ到達するための入口」でもあります。

IPA「情報セキュリティ10大脅威（2026）」でも、「サプライチェーンや委託先を狙った攻撃」が組織向け脅威の上位に位置付けられています。

個人情報保護委員会の年次報告（令和6年度）によると、委託先が漏えい元とされた2,248件のうち1,429件、割合にして約63.6%が不正アクセスによるものです。

攻撃手法の代表例はランサムウェア、SQLインジェクションなどのWebアプリ脆弱性悪用、フィッシングなどです。

開発・テスト環境が特に狙われやすいです。

内部不正（委託先による情報の持ち出し）

内部不正の発生件数は全体の中では小さな割合ですが、「一撃の重さ」が問題です。

委託開発ではソースコード・設計書・認証情報など、システム全体の構造を把握できる情報を扱うため、悪意のある内部者が存在した場合の被害は甚大になり得ます。

実際、ルールの不徹底や誤操作・誤認など、内部不正に相当する漏洩は多くの調査で上位を占めており、委託開発では特に注意が必要です。

委託開発で内部不正リスクが高まる最大の要因は、多重下請け構造です。

委託先がさらに外部委託する場合、「誰が情報にアクセスしているか」が発注元から見えなくなります。

個人情報保護法上は委託元が同様の監督義務を負うものの、関与者が増えるほど実態の把握は難しくなります。

退職時のデータ持ち出しや競合他社への情報提供といった典型的なパターンも、関与者が限定されていれば発見しやすくなります。

再委託先が増えるほど情報の管理は複雑になります。開発体制が見えやすい会社のほうが、発注側として状況を確認しやすくなります。

人的ミス（誤送信・設定ミス）

漏洩原因の過半を占めるのが人的ミスです。

個人情報保護委員会の年次報告（令和6年度）では、誤交付・誤送付が約4割、誤送信が2割強と、外部攻撃を上回っています。

委託開発でこのリスクが高まる理由は、ドキュメントの往来が増えるからです。

仕様書・設計書・テストデータをメールでやり取りする機会が多く、添付ファイルの誤送信リスクはその都度発生します。

また、開発環境・テスト環境・本番環境という複数の環境を同時に扱うため、アクセス権限の設定ミスも起きやすい構造です。

個人情報保護委員会の年次報告には、ベンダーとのやり取りで「口頭による引き継ぎのみ」「チェック体制が不十分」が背景となり、Webサイト上で個人情報が誤って公開された事案が記録されています。

これは技術的なミスというより、合意・手順・確認の不足、つまりコミュニケーション不全とプロジェクト管理の甘さが原因です。

自社内の対策だけでは防ぎきれないことが多いのは、これらの原因を見ればわかります。

人的ミスへの対策は当然必要ですが、それ以前に委託先そのものの情報セキュリティ意識と管理体制が問われます。

だからこそ、会社選びの段階での見極めがもっとも重要なのです。

安全な委託先を選ぶときに確認すべき5つのポイント

どれほど開発中の管理を徹底しても、委託先の体制が不十分であれば限界があります。

発注前の段階で、次の5点を確認しておきましょう。

セキュリティ認証の取得状況と社内体制を確認する

プライバシーマークやISMSは、第三者機関の審査を通過した情報管理体制の証明です。

取得していること自体が一定の基準を満たしている証ですが、「適用範囲」の確認も忘れずに。

「全社で取得している」と言われても、実際に依頼する部門・拠点が対象に含まれているかが重要です。

自社開発か、外部に再委託しているかを確認する

多重下請け構造の委託先では、情報が複数の会社を経由し、「誰がアクセスしているか」が発注元から見えなくなります。

内製開発体制の委託先であれば、情報の管理範囲が委託先企業内に限定され、情報拡散リスクを本質的に低減できます。

「誰が、どこで開発しているのか」を具体的に確認しましょう。

たとえば、内製率を具体的に開示している会社は、どこまでを自社で管理しているか把握しやすく、再委託の有無や情報の流れも確認しやすくなります。選定時にこの数字を具体的に出してもらえるか確認してみてください。

NDAを締結し、契約形態を確認する

NDA（秘密保持契約）は委託開発で必ず締結すべき契約です。

ソースコード・設計書・テストデータが対象に含まれるか、再委託先への同等義務があるか、開発終了後のデータ消去まで明記されているかを確認しましょう。

契約形態（準委任か請負か）によって発注側の関与度が変わる点も押さえておく必要があります。

事故歴より「再発防止を制度化できるか」を見る

過去の漏洩事故の有無を確認することも大切ですが、より重要なのは「事故後に何を変えたか」です。

原因を説明でき、再発防止を制度化できる委託先かどうかを見極めましょう。

長期取引の実績が多い会社は、それだけ信頼が積み重なっている証でもあります。

漏洩発生時の対応体制を事前に確認する

万が一のとき、委託先がどう動いてくれるかを事前に確認しておくことも選定基準の一つです。

確認しておきたいのは、初動連絡の速さ・被害範囲の特定サポート・個人情報保護委員会への報告対応の3点です。

委託先の選び方についてさらに詳しく知りたい方はこちらもご覧ください。

あわせて読みたい

システム開発業者の選び方｜業者選びの判断軸と「ディレクション力」で見極める方法

Excelが限界、業務が属人化、既存システムが老朽化——「そろそろシステム化しよう」と動き出したとき、最初にぶつかるのが「どの会社に頼めばいいか分からない」という壁です。 検索すれば会社は山ほど出てくるのに、どこも「実績○○件」とアピールしていて違いが分からない。 知名度や実績数だけで選ぶと、担

まとめ：委託先の選定こそ、情報漏洩対策の核心

この記事では、委託開発に特有の情報漏洩リスクと、発注側として確認しておきたいポイントを整理しました。

「何を確認すればいいか」さえわかっていれば、発注前の準備はそれほど複雑ではありません。この記事で整理したポイントを手がかりに、委託先との最初の会話を始めてみてください。

レブクリエイトは内製率94%の純国内体制で開発支援を行っています。6年以上の長期取引が6割超、保守契約継続率92%。長く任せてもらえる関係が、ここに表れています。