業務委託の情報漏洩リスクと対策｜許容範囲の見極め方

「外部のエンジニアにソースコードや顧客データを渡して、もし漏れたらどうするのか」。業務委託やフリーランスエンジニアの活用を起案したとき、社内からこう問われて言葉に詰まった経験はないでしょうか。開発リソースは足りていない、外注すれば解決できそうだ。それでも、情報漏洩への漠然とした不安が稟議の前に立ちはだかります。

このとき難しいのは、「情報漏洩リスクがある」という指摘そのものに反論できないことです。リスクはたしかに存在します。だからといって、リスクがゼロでないことを理由に外部人材の活用をすべて止めてしまえば、人材不足という別の経営課題が放置されたままになります。問題は「リスクがあるか・ないか」ではなく、「どのリスクは対策でコントロールでき、どこまでは許容できるのか」を判断できていないことにあります。

判断軸さえあれば、稟議の場で「情報漏洩したらどうするのか」という問いに、感覚ではなく根拠を持って答えられます。漏洩リスクは、外注を諦める理由ではなく、見える化して管理する対象に変えられるのです。

本記事では、業務委託やフリーランスエンジニアの活用に伴う情報漏洩リスクを4つのパターンに整理したうえで、漏洩が起きた場合に委託元（発注企業）が負う責任の範囲、リスクを「許容できるもの」と「対策が必要なもの」に分類する判断軸、契約・技術・運用の3層からなる具体的な対策、そしてフリーランスエンジニアへのアクセス権設計の実務までを、情シスや法務の専任者がいない企業の担当者にも使える形で解説します。

業務委託で情報漏洩が起きる主要リスクパターン

漠然とした不安を判断可能なものに変える第一歩は、「何が起きうるのか」を具体的なパターンに分解することです。業務委託に伴う情報漏洩は、大きく次の4つのパターンに整理できます。

まず統計で全体像を確認しておきましょう。個人情報保護委員会の「令和6年度 年次報告」によると、2024年度の漏えい等報告の処理件数は19,056件で、前年度の12,120件から大きく増え過去最多となりました（個人情報保護委員会 令和6年度年次報告）。同報告では、委託先からの漏えい2,248件のうち最も多い原因が不正アクセスで1,429件（62.8％）、一方で報告者本人からの漏えいでは誤交付・誤送付・誤廃棄といったヒューマンエラーが83.5％を占めています。原因が「人の過失」と「外部からの攻撃」に大きく分かれていることが分かります。

過失による漏洩（誤送信・紛失・設定ミス）

最も発生頻度が高いのが、悪意のない過失による漏洩です。委託先の担当者がメールの宛先を間違える、共有設定を「全員に公開」のままにしてしまう、ファイルを保存したノートPCを紛失する、といったケースが該当します。

フリーランスエンジニアへの発注では、ソースコードの扱いに固有の注意点があります。本来は社内の限定リポジトリに置くべきコードを、エンジニアが個人のGitHubアカウントの公開リポジトリに誤ってプッシュしてしまう、というインシデントは珍しくありません。コードの中にAPIキーやデータベース接続情報がハードコードされていれば、漏洩の影響はコードそのものにとどまりません。

不正アクセス・マルウェア経由の漏洩

外部の攻撃者による不正アクセスやマルウェア感染を経由した漏洩です。委託先のPCがマルウェアに感染し、保存されていたデータや認証情報が窃取される、フィッシング詐欺でアカウントが乗っ取られる、といったパターンが含まれます。

IPAの「情報セキュリティ10大脅威 2025（組織編）」では、「サプライチェーンや委託先を狙った攻撃」が2位に挙げられています（IPA 情報セキュリティ10大脅威 2025）。攻撃者は、セキュリティ対策が手厚い発注元を直接狙うのではなく、相対的に対策が手薄になりがちな委託先を踏み台にして侵入を試みます。フリーランスエンジニア個人に発注する場合、業務に使うのが個人所有のPC・個人契約の回線になることが多く、法人ベンダーのような統一されたセキュリティ管理が及びにくい点がこのパターンのリスクを高めます。

意図的な持ち出し・契約終了後の情報残存

頻度は高くないものの、影響が大きいのが、委託先の関係者による意図的な情報の持ち出しです。あわせて注意したいのが、悪意がなくても起きる「契約終了後の情報残存」です。

業務委託契約が終了したにもかかわらず、エンジニアに付与したクラウドサービスのアカウントが有効なまま残っている、共有ストレージのリンクが失効していない、貸与した認証トークンが無効化されていない、という状態は実務でしばしば発生します。契約が切れた後もアクセスできる経路が残っていれば、それは「いつ漏洩が起きてもおかしくない穴」を放置していることになります。意図的な持ち出しと残存リスクは、後ほど解説するアクセス権の回収によって大きく減らせます。

再委託・多段階委託による管理の空白

委託先がさらに別の事業者や個人へ業務を再委託すると、発注元が直接把握・監督できない領域が生まれます。「誰がどこまで情報に触れているのか」が見えなくなると、漏洩が起きたときに原因の特定も対応も難しくなります。

再委託の有無は、契約段階で必ず確認すべき論点です。再委託を一律に禁止するのか、事前承認制にするのか、再委託先にも同等のセキュリティ義務を課すのか。この扱いを曖昧にしたまま発注すると、管理の空白がそのままリスクとして残ります。

これら4つのパターンを把握すると、「情報漏洩が怖い」という漠然とした不安が、「どのパターンに、どんな対策が必要か」という具体的な検討課題に変わります。

情報漏洩時に委託元（発注企業）が負う責任の範囲

「漏洩したら自社の責任はどこまでなのか」。これは発注判断を止めてしまう大きな要因です。ここでは法律論を最小限にしながら、責任の構図を整理します。

個人情報保護法上の委託先監督義務

個人情報保護法は、個人データの取り扱いを外部に委託する事業者に対して、委託先を適切に監督する義務を課しています。これを委託先監督義務といいます。簡単に言えば、「外部に任せたら終わり」ではなく、「任せた相手がきちんと情報を扱っているかを発注元が見ておく責任がある」というルールです。

個人情報保護委員会のガイドラインでは、この監督義務を果たすために必要な取り組みとして、おおむね「適切な委託先の選定」「委託契約での安全管理措置の明記」「委託先における取扱状況の把握」が示されています。つまり、選定・契約・把握という3つの段階それぞれで委託元が果たすべきことが定められているということです。

監督を怠った場合に問われる委託元固有の責任

ここが重要なポイントです。委託先で情報漏洩が起きたとき、漏洩させた委託先だけでなく、委託元にも責任が生じる可能性があります。

ただし、委託元の責任は無限ではありません。委託元固有の責任が重く問われるのは、「適切な監督を怠っていた」と評価される場合です。逆に言えば、選定・契約・把握という監督義務を相応に果たしていれば、委託元が問われる責任は軽減されます。「外注すると責任が際限なく自社に降りかかる」という不安は、正確ではありません。責任の重さは、自社の監督体制によってコントロールできるのです。

この事実は、後ほど解説する対策の意味づけを変えます。NDAの締結も、アクセス権の設計も、定期的な確認も、単に漏洩を防ぐためだけの作業ではなく、「適切な監督を果たした」という事実を積み上げ、自社の責任を軽減する取り組みでもあるのです。委託元の監督義務の具体的な実務については、個人情報保護法 委託先義務｜フリーランス発注時の判断基準と3つの実務で詳しく解説しています。

賠償責任と委託先への求償の現実

漏洩によって被害者（情報の本人）から損害賠償を請求された場合、まず矢面に立つのは発注元の企業であることが多いのが現実です。被害者から見れば、契約の相手は発注元企業だからです。

発注元がいったん賠償に応じたうえで、漏洩を直接引き起こした委託先に対して、その負担分を後から請求すること（求償）は理屈の上では可能です。しかし、相手がフリーランスエンジニア個人の場合、十分な賠償資力がなく、求償しても回収しきれないという現実的な制約があります。だからこそ、漏洩を「起こさせない」事前対策と、起きたときの被害を小さくする備えの両方が重要になります。賠償リスクの一部を損害賠償保険でカバーするという選択肢も、後で触れる「残存リスクの扱い方」の一つです。

リスクを「許容できるもの」と「対策が必要なもの」に分ける

ここが本記事の中心です。情報漏洩リスクは、すべてを同じ重さで恐れる必要はありません。リスクを評価し、振り分けることで、稟議で使える判断軸ができあがります。

リスクの大きさを「影響度×発生可能性」で評価する

リスクの大きさは、「漏洩が起きたときの影響度」と「漏洩が起きる発生可能性」の2つの軸で評価します。この2軸でリスクを並べると、4つの領域が見えてきます。

たとえば「顧客の個人情報が外部に流出する」のは影響度が大きく、扱う情報や体制によっては発生可能性も無視できないため、最優先で対策すべき領域に入ります。一方、「公開予定のプレスリリース原稿が予定より早く外部に知られる」は、影響度が限定的であれば、過剰な対策をかけずに許容できる領域に入ります。

重要なのは、すべてのリスクを「最優先で対策する」領域に押し込まないことです。リソースは有限であり、影響度の小さいリスクにまで重い対策をかけると、対策コストが外注のメリットを上回り、本末転倒になります。

対策で消す／軽減する／許容する の3区分

評価したリスクは、次の3つに振り分けます。

• 対策で消す（回避）：そもそもリスクの発生源を作らない選択。たとえば「最も機密性の高いデータには外部エンジニアを一切アクセスさせず、社内メンバーだけで扱う」と決めれば、そのデータに関する委託経由の漏洩リスクは発生源ごと消えます。
• 対策で軽減する（低減）：契約・技術・運用の対策によって、発生可能性や影響度を下げる選択。本記事の対策の大半はこの区分に入ります。アクセス権を最小限にする、ログを取る、NDAを結ぶ、といった打ち手です。
• 残存リスクとして許容する（保有）／保険でカバーする（移転）：対策をしてもゼロにはならない部分を、許容範囲内のリスクとして受け入れる、あるいは損害賠償保険などでカバーする選択。

リスクをゼロにすることはできません。だからこそ、「ここまでは対策する」「ここからは残存リスクとして許容する」というラインを意識的に引くことが、判断を前に進める鍵になります。「リスクがゼロにならないから外注しない」のではなく、「残存リスクを許容できる水準まで下げたから外注する」という論理に切り替えるのです。

扱う情報の機密度で発注可否ラインを引く

3区分の振り分けを実務に落とすとき、最も使いやすい基準が「扱う情報の機密度」です。委託する業務で外部エンジニアが触れる情報を、機密度で段階分けします。

このように整理しておくと、「この業務はどの機密度の情報を扱うか」を確認するだけで、必要な対策水準と発注可否がほぼ決まります。稟議では「本案件で外部エンジニアが触れるのは社内限定情報までであり、個人情報・本番データへのアクセスは付与しません」と説明できれば、漠然とした不安に対する具体的な回答になります。

情報漏洩を防ぐ契約・技術・運用の3層対策

リスク評価で「対策が必要」と分類したリスクには、具体的な打ち手を用意します。対策はばらばらに並べると抜け漏れが起きやすいため、契約・技術・運用の3層フレームで整理します。各層について「最低限やること」と「機密度が高い場合の追加策」に分けて見ていきます。

契約層：NDA・再委託の扱い・情報の取扱範囲の明文化

契約層は、情報の取り扱いに関するルールを書面で取り決める層です。

最低限やることは、秘密保持契約（NDA）の締結と、業務委託契約への安全管理に関する条項の盛り込みです。NDAは、業務を通じて知り得た情報を外部に漏らさない・目的外に使わないことを書面で約束させるものです。あわせて契約書には、再委託の可否（禁止するか、事前承認制にするか）、契約終了時の情報の返却・消去義務、漏洩が起きた場合の報告義務を明記します。NDA締結の実務的な進め方はフリーランスエンジニアとのNDA締結ガイドで、秘密保持の範囲をどこまで設定するかは業務委託の秘密保持はどこまで設定すべきか？で詳しく扱っています。

機密度が高い場合の追加策としては、取り扱える情報の範囲を契約書で具体的に限定すること（「本番データベースへのアクセスは行わない」など）、私物デバイスの業務利用に関するルール（持ち出し禁止データの指定など）の明文化が挙げられます。

技術層：アクセス権最小化・専用アカウント・ログ取得

技術層は、システム的な仕組みで漏洩を防ぐ層です。

最低限やることは、専用アカウントの貸与とアクセス権の最小化です。専用アカウントとは、外部エンジニア用に個別に発行するアカウントのことで、誰がいつ何にアクセスしたかを記録でき、契約終了時にそのアカウントだけを停止すれば足ります。アクセス権の最小化とは、業務に必要な範囲のシステム・データにだけアクセスできるよう権限を絞ることです。あわせて、アクセスログの取得を有効にしておきます。

機密度が高い場合の追加策には、データのダウンロード・コピーを制限する設定、IPアドレスによるアクセス元の制限、多要素認証の必須化などがあります。アクセス権の設計はフリーランスエンジニア活用において特に重要なため、次の章で実務手順を詳しく解説します。

運用層：権限の棚卸し・モニタリング・教育

運用層は、設定した対策が形骸化しないよう、継続的に回す層です。

最低限やることは、付与した権限の定期的な棚卸し（「今も必要な権限か」を見直す）と、ログの定期確認です。「最初に設定して終わり」では、業務内容が変わって不要になった権限がいつまでも残り、リスクの温床になります。

機密度が高い場合の追加策には、アクセスログの能動的なモニタリング、委託先への情報セキュリティに関する説明や注意喚起、漏洩を想定した初動対応手順の事前共有などが含まれます。委託先への教育は、本記事冒頭で見た「過失による漏洩」を減らすうえで効果的です。

3層で整理しておくと、「契約はあるが技術的な制限をしていない」「技術設定はしたが運用で見直していない」といった抜け漏れに気づきやすくなります。この3層をそのままチェックリストとして使えば、対策の網羅性を担保できます。

フリーランスエンジニアへのアクセス権設計の実務

3層対策のうち技術層は、フリーランスエンジニアへの発注において特に丁寧な設計が必要です。法人ベンダーと違い、個人への発注では「契約終了時に誰がどの権限を持っていたか」を発注元自身が管理しなければならないからです。ここでは実務手順に踏み込みます。

最小権限の原則（Principle of Least Privilege）の考え方

最小権限の原則とは、「ある人やシステムには、その業務を遂行するのに必要な最小限の権限だけを与える」という情報セキュリティの基本的な考え方です。英語ではPrinciple of Least Privilegeと呼ばれます。

なぜ最小限に絞るのかというと、万一そのアカウントが乗っ取られたり、担当者が誤操作をしたりしても、被害が「そのアカウントが触れる範囲」に限定されるからです。フロントエンドの改修だけを依頼したエンジニアに本番データベースの全権限を渡していれば、何か起きたときの被害範囲は本番データベース全体に広がります。逆に必要な範囲だけに絞っておけば、被害は局所的にとどまります。最小権限は、漏洩の「発生可能性」と「影響度」の両方を同時に下げる対策です。

権限付与の実務フロー（棚卸し→ロール設計→期限付き付与）

最小権限を実務に落とすには、次の流れで権限を付与します。

1. 必要な権限の棚卸し：委託する業務の内容から、外部エンジニアが「実際に必要とする」システム・データ・操作を洗い出します。「念のため」で広げないことが要点です。
2. ロール設計：洗い出した権限をロール（役割）としてまとめます。たとえば「フロントエンド改修用ロール」のように、業務に対応した権限のセットを定義しておくと、付与と回収が一括ででき、付与漏れ・回収漏れを防げます。
3. 期限付き・スコープ限定での付与：ロールを割り当てる際、可能であれば有効期限を設定します。契約期間に合わせて期限を切っておけば、回収を忘れても期限切れで自動的にアクセスができなくなり、残存リスクの保険になります。
4. 定期的な見直し：業務内容の変化に応じて、不要になった権限を外します。これは運用層の棚卸しと連動します。

契約終了時のアクセス権回収チェックリスト

最も漏れが起きやすく、かつ重大なのが契約終了時のアクセス権回収です。本記事の冒頭で挙げた「契約終了後の情報残存」のリスクは、ここを仕組み化することで大きく減らせます。契約終了時には、次の項目を一つずつ確認します。

• 貸与した専用アカウントを停止・削除した
• クラウドサービス・各種ツールのアクセス権を取り消した
• 共有ストレージ・ドキュメントの共有リンクを失効させた
• SSHキー・APIトークン・アクセストークンを無効化した
• 付与していたロールの割り当てを解除した
• 私物デバイス上に残った業務データの消去を依頼・確認した
• ソースコードリポジトリのアクセス権限（コラボレーター登録等）を削除した
• 契約書に基づく情報の返却・消去が完了したことを書面等で確認した

このチェックリストを契約終了時の標準手順として定めておけば、回収漏れによる「気づかないうちに残っていた穴」をなくせます。私物デバイス上のデータ消去は発注元から直接コントロールしにくい部分ですが、契約書の消去義務（契約層）と組み合わせ、完了の報告を受ける運用にすることで実効性を高められます。

情報漏洩が発生した場合の初動対応フロー

どれだけ対策をしても、残存リスクはゼロにはなりません。だからこそ、「起きたときにどう動くか」を事前に決めておくことが、リスクを許容して発注を進める判断の裏付けになります。「起きても対応できる」状態が、許容判断を支えるのです。

発覚から初動でやること（封じ込め・事実確認）

漏洩の疑いが発覚したら、まず行うのは被害の拡大を止める封じ込めです。漏洩元と疑われるアカウントを停止する、影響範囲のシステムへのアクセスを一時遮断する、といった措置を速やかに取ります。

並行して事実確認を進めます。何の情報が、どの範囲に、どれだけ漏れた可能性があるのか。原因は何か。委託先と連携して状況を把握します。この段階の動きを速くするためにも、前述のアクセスログの取得が効いてきます。ログがなければ「何が起きたか分からない」状態に陥り、後の報告も対応も滞ります。

個人情報保護委員会・本人への報告義務

漏洩した情報に個人データが含まれる場合、個人情報保護法に基づく報告義務が生じることがあります。報告は「速報」と「確報」の2段階です。速報は事態を知ってから速やかに（概ね3〜5日以内が目安）、確報は事態を知ってから30日以内（不正の目的によるおそれがある漏洩等の場合は60日以内）に行う必要があります（個人情報保護委員会 漏えい等報告・本人への通知の義務化について）。

あわせて、漏洩した情報の本人への通知も、事態の状況に応じて速やかに行う必要があります。報告・通知の要否や具体的な手続きは個別の事案で判断が分かれるため、不安がある場合は早い段階で弁護士などの専門家に相談することをおすすめします。重要なのは、こうした義務が発生しうることを事前に知っておき、初動で慌てないことです。

委託先との連携と再発防止

封じ込めと報告のめどが立ったら、原因究明と再発防止に移ります。漏洩がどの対策層の不備で起きたのか（契約の取り決めが不十分だったのか、技術的な制限が甘かったのか、運用の見直しが滞っていたのか）を特定し、対策を更新します。

業務委託先とのトラブルへの向き合い方や、具体的な事例ごとの対処はフリーランスエンジニアのトラブル事例5選と発注者のための初動対処法も参考になります。漏洩を一度経験したら、その教訓を契約・技術・運用の3層対策に反映し、次の発注に活かすことが、リスク管理を前に進めることにつながります。

まとめ

業務委託やフリーランスエンジニアの活用に伴う情報漏洩リスクは、本記事で見てきたとおり、見える化して管理できる対象です。流れを振り返ります。

• 漏洩リスクは「過失」「不正アクセス」「意図的な持ち出し・契約終了後の残存」「再委託の空白」の4パターンに整理でき、漠然とした不安を具体的な検討課題に変えられます。
• 委託元の責任は無限ではなく、選定・契約・把握という監督義務を果たしていれば軽減されます。対策は漏洩防止であると同時に、自社の責任を軽くする取り組みでもあります。
• リスクは「影響度×発生可能性」で評価し、「対策で消す／軽減する／許容する」の3区分に振り分けます。扱う情報の機密度で発注可否ラインを引けば、稟議で使える判断軸になります。
• 対策は契約・技術・運用の3層フレームで整理すると、抜け漏れを防げます。フリーランスエンジニアへのアクセス権設計は、最小権限の原則に基づき「棚卸し→ロール設計→期限付き付与→契約終了時の回収」の手順で実務化します。
• 残存リスクに備え、初動対応フローを事前に決めておけば、「起きても対応できる」状態が許容判断を支えます。

情報漏洩リスクは、外部人材の活用を諦める理由ではありません。リスクを4パターンで把握し、3区分で振り分け、3層対策で備える。この一連の見える化ができれば、「情報漏洩したらどうするのか」という問いに、感覚ではなく判断軸で答えられるようになります。

次のアクションとして、まずは検討中の委託業務で外部エンジニアが触れる情報の機密度を整理し、本記事の3層対策をチェックリストとして自社の対策状況を点検してみてください。外部人材活用の進め方やリスク管理の判断材料をさらに体系的に整理したい方に向けて、発注前の検討に役立つお役立ち資料も用意しています。リスクを管理可能なものに変え、安心して外部人材の活用を進める一助としてご活用ください。