フリーランスへの業務委託を進めようとしたとき、こんな壁にぶつかったことはありませんか。
「NDAを結ぼうとしているが、どの情報をどこまで秘密保持の対象にすればいいか分からない」「とりあえず"全ての情報"と書いておけばいいのか、それとも具体的に列挙すべきか」「範囲を広くしすぎてフリーランスに反発されるのも困るが、狭すぎて情報が漏れたら困る」
これは、法務専任者のいない中小企業の担当者が特に陥りやすい悩みです。NDAの必要性は分かっていても、「秘密情報の範囲をどう設定するか」という実務的な判断基準を持っていないため、手が止まってしまう状況です。
本記事では、業務委託における秘密保持の対象を情報の種類ごとに整理し、「何を含めるべきか・含めなくていいか」の実務的な判断フレームを発注者視点でご説明します。過剰設定・不足設定のよくある失敗パターンや、業種・プロジェクト別の考え方も合わせて解説しますので、ぜひ実際の委託契約に役立ててください。
なお、本記事では「範囲設定の考え方」に絞って解説します。NDA締結の全体的な手順・条項についてはフリーランスエンジニアとのNDA締結ガイド｜必要条項と実務手順を発注者視点で解説をご参照ください。
業務委託で秘密保持の範囲設定が重要な理由
範囲が曖昧なまま委託するとどうなるか
業務委託においてNDA（秘密保持契約）を結ぶことの重要性は広く認識されていますが、「秘密情報の範囲」を適切に設定しないと、契約があっても保護されないケースがあります。
具体的なトラブルとして、次のようなケースが報告されています。
- ソースコードの流用: フリーランスが受託した案件で得たソースコードや設計仕様書を、別の案件で利用された。しかし、秘密情報の定義が曖昧で、「公式に開示した文書のみ」という限定的な条項しかなかったため、法的措置が取れなかった
- 顧客情報の漏洩: 顧客管理システムの開発を委託した際、顧客データベースへのアクセス権限を与えたが、秘密情報の定義に「顧客情報」が明示されていなかったため、損害賠償の交渉で困難を生じた
- 業務ノウハウの持ち出し: 業務改善コンサルティングを委託した際、社内の業務プロセスを詳細に開示したが、同業他社への転売・活用を防ぐ条項がなかった
2024年11月に施行されたフリーランス保護法（フリーランス・事業者間取引適正化等法）により、発注者は取引条件の書面明示義務などが課されています。秘密保持の範囲設定も含め、契約書の整備が以前にも増して重要になっています。
秘密保持の対象として「含めるべき」情報の種類
秘密保持の範囲設定で最も重要なのは、「業務で開示・共有する情報の種類ごとに判断する」という視点です。一律に「全て」または「文書のみ」と設定するのではなく、情報の性質に応じた判断が実務上有効です。
ソースコード・技術情報
含めるべき情報:
- ソースコード本体（未リリース含む）
- システム設計書・アーキテクチャ設計図
- API設計・データベース設計仕様書
- セキュリティ設計・脆弱性情報
設定の考え方:
ソースコードや技術情報は、漏洩した場合に競合他社が同等のシステムを短期間で開発できる可能性があります。秘密情報の定義は「本業務に関して開示した技術情報一切（書面・口頭・電磁的方法を問わない）」のように広めに設定することが推奨されます。
ただし、ソースコードの「秘密保持」と「著作権帰属」は別の問題です。著作権の帰属については業務委託契約書側で明記し、秘密保持契約と役割を分けて整理することが重要です。
顧客情報・個人情報
含めるべき情報:
- 顧客氏名・連絡先・住所など個人情報
- 顧客の購買履歴・利用履歴
- 会員情報・アカウント情報
- 決済情報（クレジットカード情報等）
設定の考え方:
個人情報を含む業務を委託する場合、発注者（委託元）は個人情報保護法上、委託先を「適切に監督する義務」を負います。委託先が情報を漏洩させた場合でも、委託元が損害賠償責任を問われる可能性があります。
秘密情報の定義には「本業務を通じて知り得た顧客情報および個人情報保護法上の個人情報一切」を明示してください。
業務要件・設計仕様書
含めるべき情報:
- 要件定義書・業務要件書
- ワイヤーフレーム・画面設計書
- 業務フロー図・ユースケース記述
- 機能仕様書・非機能要件書
設定の考え方:
要件定義書や業務フロー図には、自社固有のビジネスプロセスやサービス設計が含まれます。競合他社に流れた場合、サービスの競争優位性が失われる可能性があります。「本業務のために開示した一切の情報（書面・口頭を問わない）」という包括的な定義に含める必要があります。
特に口頭での会議やミーティングで共有した情報についても、「口頭で開示した情報も含む」と明示することが重要です。
内部システム構成・インフラ情報
含めるべき情報:
- クラウドインフラ構成図
- ネットワーク設計・セキュリティ構成
- サーバー環境・ミドルウェア構成
- 内部ツール・管理画面の仕様
注意事項:
認証情報（パスワード・APIキー・接続文字列など）は、原則として外部委託先と共有しない設計が最善です。どうしても共有が必要な場合は、専用の一時的な認証情報を発行し、業務終了後に無効化する運用を取ることを推奨します。その上で、秘密情報として「本業務に関して開示した認証情報・システム構成情報一切」と明示してください。
業務プロセス・ノウハウ
含めるべき情報:
- 社内の業務プロセス・手順書
- 独自の業務ノウハウ・運用フロー
- 経営戦略・事業計画（開示が必要な場合）
- 取引先・パートナー情報
設定の考え方:
業務改善やDXプロジェクトでは、社内業務プロセスの詳細を外部に開示することがあります。これらは公開すると競合他社に利用される可能性がある情報であり、秘密保持の対象として明示することが重要です。
秘密情報の範囲設定で陥りやすい2つの失敗
失敗1: 「全ての情報」と広く設定しすぎるデメリット
「情報漏洩リスクを最小化するため、全ての情報を秘密保持の対象にする」という発想は理解できますが、実務上いくつかの問題を引き起こします。
フリーランス側から反発されやすい: フリーランスは複数のクライアントを抱えて働くことが多く、「全ての情報」を秘密保持の対象にすることは、他の仕事への支障を心配させます。秘密情報の範囲が無制限に広い契約への署名を拒否されたり、交渉が長引いたりするケースがあります。
公開情報まで保護対象になるリスク: すでに公知・一般公開されている情報や、受託者が独自に開発した技術を「全ての情報」に含めてしまうと、後々の紛争の原因になります。秘密保持義務の「例外規定」（既に公知の情報、独自に開発した情報など）を明示することが重要です。
実務上の推奨: 「本業務のために秘密である旨を明示して開示した情報、および業務を通じて知り得た顧客情報・技術情報」のように、業務との関連を明確にした定義を用いる方が合理的です。
失敗2: 「秘密と表示した文書のみ」と狭く設定しすぎるリスク
「秘密情報は書面に"社外秘"と記載したものに限る」という定義は、管理が容易ですが、業務実態と乖離するリスクがあります。
口頭情報が保護されない: 会議やミーティングで口頭で共有した業務要件・設計方針・顧客情報が保護されません。システム開発の現場では、口頭でのやり取りが多く、全ての情報を事前に書面化することは現実的ではありません。
未ラベルの資料が漏洩しても無効: 「社外秘」ラベルを貼り忘れた設計書や仕様書が流出しても、秘密情報として認定されないリスクがあります。
実務上の推奨: 「書面・口頭・電磁的方法を問わず開示した情報で、秘密である旨を開示時または開示後7日以内に書面で通知したもの」という定義や、「本業務に関する技術情報・顧客情報・業務情報一切（書面・口頭を問わない）ただし公知情報を除く」という包括的な定義が現実的です。
業種・プロジェクト別の範囲設定の考え方
個人情報を扱うシステム開発（ECサイト・予約システム等）
個人情報を含むシステム開発を委託する場合、個人情報保護法上の「委託先監督義務」への対応が必要です。
- 秘密情報の定義に「個人情報保護法上の個人情報一切」を明示する
- 個人情報の取り扱いに関する別途の規定（個人情報取扱委託契約書）を締結することも検討する
- 秘密保持の範囲：「業務上知り得た個人情報および本業務に関する技術情報・設計情報一切」
SaaS・自社プロダクト開発
SaaSや自社プロダクトの開発を外部委託する場合、技術資産の保護が最重要になります。
- ソースコード・設計仕様書の包括的な秘密保持
- 「未公開機能・ロードマップ情報」も秘密情報として明示する
- 競合他社への転職・業務委託を制限する競業避止義務の設定も検討（フリーランス保護法の趣旨に反しない範囲で）
業務改善・DXプロジェクト
社内業務プロセスを外部のコンサルタントやエンジニアに開示するプロジェクトでは、業務ノウハウの保護が重要です。
- 「社内業務プロセス・手順書・業務改善の知見一切」を秘密情報として明示する
- 秘密保持期間を「契約終了後3〜5年」と設定する（ソフトウェア情報は陳腐化が早いため3年、業務ノウハウは5年が目安）
- プロジェクト終了後の情報返還・廃棄義務を明記する
フリーランス保護法（2024年11月施行）と秘密保持の関係
2024年11月に施行されたフリーランス保護法（正式名称：フリーランス・事業者間取引適正化等法）は、フリーランスへの業務委託における発注者の義務を定めた法律です。
この法律では、発注者は取引条件（業務内容・報酬・支払条件・契約期間など）を書面または電磁的方法で明示することが義務付けられています。秘密保持の条件も「取引条件」の一部として書面明示が求められる場合があります。
また、NDA（秘密保持契約）が不当にフリーランスの業務を制限する内容になっている場合（例: 競業避止義務を不当に広く設定する）、同法の「不当な行為の禁止」規定に抵触する可能性があります。
実務上のポイント:
- 秘密保持の範囲は「業務に必要な最小限の情報保護」を基本とし、フリーランスが他の仕事に支障をきたさない範囲に設定する
- 業務委託契約書とNDAをセットで整備し、取引条件として明示する
- 既存のNDA雛形がある場合、フリーランス保護法施行後の最新の実務に対応しているか確認する
まとめ：秘密保持の範囲設定 実務チェックリスト
業務委託における秘密保持の範囲設定を行う際は、以下のチェックリストを活用してください。
設定すべき秘密情報の種類:
- ソースコード・技術情報（設計仕様書・API設計など）を含めているか
- 顧客情報・個人情報を明示しているか
- 業務要件・設計仕様書を含めているか
- 内部システム構成（必要最小限）を含めているか
- 業務プロセス・ノウハウを含めているか
定義方法の確認:
- 書面だけでなく口頭情報も対象としているか
- 例外規定（公知情報・独自開発情報）を明示しているか
- フリーランスの他業務を不当に制限していないか
その他の重要項目:
- 秘密保持期間（契約終了後○年）を定めているか
- 秘密情報の返還・廃棄義務を規定しているか
- フリーランス保護法への適合性を確認したか
秘密保持の範囲設定は「広すぎず・狭すぎず」が基本です。業務で実際に開示する情報の種類を事前に整理し、それぞれの保護の必要性を判断した上で設定することが、実効性のある秘密保持契約につながります。
業務委託における契約書全般のリスクチェックや、フリーランス保護法への対応について、より詳しく知りたい方は「フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド」を無料でダウンロードいただけます。発注実務に役立つチェックリストと契約書の確認ポイントをまとめています。
秘密保持契約の全体的な手順についてはフリーランスエンジニアとのNDA締結ガイド｜必要条項と実務手順を発注者視点で解説もあわせてご覧ください。
