秘密情報の定義 — NDAで何を守るか

NDA（秘密保持契約）のトラブルのほとんどは、秘密情報の定義が不明確なことに起因する。「何が秘密か分からない」という状態では、受託者は何を守るべきか判断できず、発注者は情報漏洩の主張さえ困難になる。

Webシステム開発を受託したフリーランスエンジニアのAさんは、クライアントX社と「業務上知り得た一切の情報を秘密情報とする」旨のNDAを締結した。半年後、Aさんは別クライアントから類似の管理システム開発を受注した。X社は「秘密情報 定義」条項を根拠に、「自社の業務フローを参考にした」と主張して開発中止を求めた。Aさんが使用したのはいずれも汎用的な設計パターンだったが、条項の範囲が広すぎたため、交渉コストと精神的負担を強いられた。

発注者側も「定義の曖昧さ」から不利益を被る。マーケティング会社Y社は外部ライターに新サービスのコンセプトを共有してコピーを依頼した。NDAを締結していたが、秘密情報の定義は「口頭・書面を問わず開示した一切の情報」とされていた。ライターがSNSで「次世代型サービスのコピーを書いた」と投稿した際、Y社は損害賠償を請求しようとしたが、投稿内容が「秘密情報」に該当するかの立証が困難で、結果的に請求を断念した。

これらの問題に共通するのは、秘密情報の定義が法的な保護手段として機能していないという点だ。定義が広すぎれば受託者の正当な業務活動を不当に制約し、逆に抽象的すぎれば発注者が実際に守りたい情報を保護できない。

NDAにおける秘密情報の定義は、「何を守るか」を具体化する行為であり、その精度が契約全体の実効性を左右する。NDA 秘密情報 範囲の設計は、署名前に双方が真剣に向き合うべき核心条項である。

秘密情報の定義方式には大きく3つのアプローチがあり、それぞれの特徴を理解した上で取引の性質に応じて選択することが重要だ。

1. 列挙型（具体的列挙方式）

守るべき情報の種類を具体的に列挙する方式だ。例えば、「顧客名簿、価格設定情報、未発表の製品仕様書、財務データ、システム設計書」と明示する。

この方式の利点は明確性にある。何が秘密情報かを双方が一読して把握でき、実務上の判断が容易になる。また、列挙されていない情報は原則として秘密保持義務の対象外となるため、受託者の活動範囲が明確に保護される。

一方で、想定外の情報が列挙から漏れるリスクがある。取引開始時には想定していなかった重要情報が後から開示されるケースでは、列挙範囲外として保護されない可能性がある。発注者側にとっては保護の網の目が粗くなるリスクがある。

2. 包括型（一般条項方式）

「本契約に関連して一方当事者が他方当事者に開示した情報であって、開示時に秘密である旨を明示したもの」という形で、情報の種類を問わず包括的に定める方式だ。多くの標準テンプレートで採用されている。

この方式の利点は網羅性だ。取引が進む中で新たに生じる情報にも対応でき、情報の種類による抜け漏れが生じにくい。発注者にとっては保護の範囲が広い。

ただし、受託者にとっては「どこまでが秘密情報か」という判断が難しくなる。また、「業務上知り得た一切の情報」という極めて広い定義は、裁判所でも一部無効と判断されるリスクがあり、過度な包括定義は実務上の機能不全を引き起こしやすい。

3. マーキング型（指定方式）

書面での開示時に「秘密」「Confidential」等の表示を付すことで秘密情報として指定し、口頭開示の場合は一定期間内（例：7日以内）に書面で確認する方式だ。

この方式の利点は、秘密情報の境界線が明確になることだ。開示側が秘密として扱いたい情報を意識的に選別し、マーキングすることで管理コストを合理化できる。

課題は、マーキングを忘れた場合に保護が失われる点だ。口頭での議論内容や非公式な共有情報は見落とされやすく、「うっかりマーキングしなかった重要情報」が無防備になるリスクがある。

実務上は、これら3つの方式を組み合わせることが多い。「別表に記載の情報を秘密情報とし、それ以外でも秘密として開示された情報（書面による指定または開示後5営業日以内の書面確認による）も秘密情報に含む」という複合型が、保護の確実性と実務的明確性のバランスを取りやすい。

機密情報 契約における除外事由とは、たとえ秘密情報の定義に該当する形で開示されたとしても、秘密保持義務が生じない情報の類型だ。適切な除外事由の設計は、受託者の正当な業務活動を守り、発注者にとっても実際に保護可能な情報に集中できるという意味で双方にとって合理的である。

標準的な除外事由として国際的にも広く認められているのは以下の4類型だ。

① 公知情報（公知の事実）

「受領時にすでに公知となっていた情報」または「受領後に受領者の責めによらず公知となった情報」は、秘密保持義務の対象外とする。すでに世の中に出回っている情報を秘密として拘束することは実態に即さず、法的にも正当化しにくい。

② 受領前から保有していた情報

「受領者が開示者から受領する以前から適法に保有していた情報」は除外される。この除外事由がないと、受託者は既存の知識・経験・技術ノウハウさえ使えなくなるという不当な結果を招く。

③ 独自開発情報

「開示された情報によらず受領者が独自に開発・創出した情報」は秘密保持義務を負わない。受託者が独立した開発活動の成果を、たまたま類似の情報を受け取ったという理由で秘密扱いにされることを防ぐための条項だ。

④ 第三者から適法に取得した情報

「正当な権限を有する第三者から秘密保持義務を負わずに取得した情報」も除外される。守秘義務のない第三者ルートで入手した情報まで拘束するのは過剰だ。

加えて実務上重要なのが、法令・行政機関・裁判所による開示命令への対応だ。法的義務として情報開示が求められた場合は秘密保持義務が免除されることを明記し、その際は事前に開示者へ通知する旨を定めておくことが望ましい。

除外事由の主張は受領者（受託者）側が立証責任を負うのが原則だ。「この情報は公知だった」「独自に開発した」と主張するには、それを裏付ける記録が必要になる。受託者は、契約開始時点での保有技術・知識の記録、独自開発の経緯ドキュメント、公知情報のソース保存などを習慣的に行っておくことが自己防衛として有効だ。

秘密情報の定義は、取引の内容・業態によって適切な設計が異なる。画一的なテンプレートを使い回すと、実態に合わない保護になりがちだ。

Webサイト制作・グラフィックデザイン

この業態では、クライアントのブランド戦略・未発表キャンペーン情報・社内使用のデザインシステムが主な機密情報となる。一方で、配色・フォント選択・レイアウトの基本パターンは汎用的なデザイン知識であり、秘密情報として拘束するのは不適切だ。

定義条項では「クライアントから提供された資料・データおよびそこから直接導かれる情報」を中心に列挙し、「一般的なデザイン手法・ツールの使用方法・業界慣行は秘密情報に含まない」と除外を明示することが実務上有効だ。

システム開発・プログラミング

システム開発では、業務フロー・データ構造・API仕様・セキュリティ設計が守られるべき機密情報の核心となる。対して、一般的なアーキテクチャパターン・フレームワークの使用方法・汎用アルゴリズムは、受託者の技術知識の一部として保護すべきだ。

よくあるトラブルは、クライアントの業務フローを学習した受託者が、類似業界の別クライアントにその経験を活かした際に「秘密情報の利用」と主張されるケースだ。「特定のクライアントの業務に固有の情報・ノウハウ」と「一般的な業界知識・技術知識」を明確に分ける定義が必要だ。

コンサルティング・調査

コンサルティング業務では、クライアントの経営課題・財務状況・未発表の事業計画が機密の中核となる。この業態では口頭での情報共有が多いため、マーキング型単独での運用は難しく、「コンサルティング業務の目的で共有された情報はすべて秘密情報とみなす」という実質的な包括定義と、詳細な除外事由の組み合わせが現実的だ。

採用・人事情報を含む業務

採用コンサルティング・研修設計など人事情報を扱う業態では、個人情報保護法との重複に注意が必要だ。秘密保持義務と個人情報取扱いに関する義務は別個の法的根拠を持つため、NDA条項に「個人情報については別途個人情報保護法および関連規程に従う」と明記し、混在を避ける。

受託者（フリーランス・受託会社）が確認すべき事項

第一に、「秘密情報の定義が自分の既存スキル・知識・他社での経験に過度な制限を与えていないか」を確認する。定義が「業務上知り得た情報の一切」という形になっている場合は、除外事由として「受領前から保有していたスキル・知識・経験」「一般的な技術知識・業界慣行」を明示的に追加するよう交渉する。

第二に、秘密保持期間の長さを確認する。5年・10年・無期限の秘密保持は、フリーランスの事業継続性を著しく制約する可能性がある。情報の性質によって差別化し（例：個人情報は5年、その他の技術情報は2年）、妥当な期間設定を求める。

第三に、損害賠償額の予定条項に上限が設定されているかを確認する。秘密情報の漏洩に対して「実損害全額」という条項は、業務委託の対価規模と不釣り合いになりうる。責任上限額を設定した賠償条項への修正を検討する。

発注者（企業・発注者）が確認すべき事項

第一に、「実際に守りたい情報が定義に含まれているか」を検証する。列挙型を採用している場合は、取引過程で開示する可能性のある情報種別をプロジェクト開始前にリストアップし、定義の網羅性を確認する。

第二に、「守れる情報しか守らない」という視点で定義を精査する。過度に広い定義は、紛争時の立証を困難にし、受託者の不満を高め、最終的には信頼関係を損なう。守ることの合理的な必要性がある情報に絞り込むほうが実効性は高い。

第三に、情報管理の社内体制が定義に追いついているかを確認する。「システム設計書はすべて秘密情報」と定義したとして、社内でその資料が適切に管理されていなければ、そもそも保護の実態がない。定義した情報の管理方法・アクセス制限・廃棄ルールが整備されているかを同時に点検する。

双方共通の確認事項

契約書に記載された秘密情報の定義を、署名前に声に出して読み上げ、「自分が実際に開示する/受け取る情報に照らして納得できるか」を確認する習慣をつける。法務部門がない小規模事業者の場合、定義条項だけでもリーガルチェックを外部弁護士に依頼することは、コスト対効果の高い投資だ。

秘密情報の定義は、NDA全体の実効性を左右する基礎条項だ。「とりあえず署名」ではなく、「何を、なぜ、どう守るか」を双方が確認してから契約するプロセスが、長期的な信頼関係の構築にも寄与する。定義を曖昧にしたまま締結したNDAは、守るためではなく争うために使われるリスクを内包している。