NDAの例外条項とは？秘密保持義務から除外される情報を実務整理｜Legal GPT
契約審査・承認・監査・稟議を、ひとつのOSで。
属人化しがちな契約レビューを、誰でも同じ品質で処理できる仕組みに。法務・営業の現場でそのまま使えます。
読了時間の目安： 約8分 ｜ 最終更新： 2026年4月
NDAの核心は「何を秘密にするか」だが、それと同じくらい重要なのが「何を秘密にしなくてよいか」だ。
これを定めるのが例外条項（Exceptions to Confidentiality Obligations）である。
例外条項は、定型NDAにほぼ必ず入っているため、存在自体は見落とされにくい。一方で、「いつもの条項」として読み流されやすい。担当者が「ああ、いつものやつ」と流した結果、微妙な文言の差が後になって重大な差を生む。
公知になった情報を巡る争い、独自開発を証明できない紛争、立証責任を巡る主張の食い違い――その多くは、例外条項の詰めの甘さに端を発している。
本記事では、例外条項の四類型それぞれの意味・落とし穴・修正文言の考え方を、秘密情報の定義条項と対照させながら整理する。
1. 例外条項の役割──なぜ「除外」が必要か
秘密情報の定義を広くすれば、相手方の保護は厚くなる。しかしその裏で、受領した自社担当者が「これは秘密か否か」を常に判断しなければならない状態が生じる。
適切な例外条項は、この判断負荷を合理的に下げる安全弁として機能する。
- 業務自由の確保：社外で独自に入手・開発した情報まで縛られることを防ぐ
- 不要な情報管理コストの排除：誰でも知っている情報を秘密管理する無駄をなくす
- 紛争時の証明可能性の担保：除外事由を明文化することで、事後に主張・立証しやすくする
逆に言えば、例外条項が曖昧・欠落していると、開示された情報と独自開発情報の境界が不明確になり、受領側が不当に広い義務を負うリスクが生じる。
2. 四つの例外類型
| 例外類型 | 要件の骨格 | 実務上の留意点 |
|---|---|---|
| ① 公知情報 | 開示時点で既に公知の情報（受領者の帰責なく公知となった場合を含む） | 「受領後に公知になった」場合の扱いを別途規定する必要 |
| ② 受領前保有情報 | 開示を受ける前から保有していた情報 | 記録・台帳による事前証明がないと事後に争われる |
| ③ 第三者正当取得情報 | 秘密保持義務のない第三者から正当に取得した情報 | 「正当に」の解釈が曖昧になりやすい。経路の文書化が肝要 |
| ④ 独自開発情報 | 開示情報を使用せずに独自に開発・取得した情報 | クリーンルーム開発等の記録が不可欠。最も争いになりやすい |
① 公知情報（Public Domain）
最も基本的な類型。特許公報に記載された情報、刊行物・Webサイトで公表された情報、業界慣行として広く知られた情報などが該当する。
「開示時点で公知であるか、またはその後受領者の責めに帰さない事由によって公知となった情報」という書き方が実務標準だ。
② 受領前から保有していた情報
開示を受ける前から自社がすでに保有していた情報は、相手方の秘密情報として保護する必要がない。ただし、これを事後に主張するためには、保有時期を証明できる記録が必要だ。
※ 記録がなければ、相手方から「受領後に流用した」と疑われても反論できない
実務上は情報管理台帳・社内Wikiのタイムスタンプ・開発ログなどを証拠として備えておく。NDA締結前に「当社はすでに○○の情報を保有している」旨を相手方に通知しておくことも有効だ。
③ 正当に第三者から取得した情報
NDA上の秘密情報ではない別の第三者から、秘密保持義務なしに適法に入手した情報は除外される。典型例は、業界団体の公開資料、コンサルタントの一般的な知見、他の取引先からNDA不要で共有されたデータなどだ。
「秘密保持義務を負わない第三者から、当該第三者自身が守秘義務なく取得した」という二重の要件を確認すること。
- 第三者自身が開示者に対して秘密保持義務を負っていないか
- 受領した情報の取得経路を記録しているか
- 取得時に「秘密性なし」の確認をメール等で残しているか
④ 独自開発情報（Independent Development）
相手方から開示された秘密情報を使用せずに、独自の努力によって自社が開発・取得した情報は除外される。四類型のうち、最も争いになりやすいのがこれだ。
開示者側は「うちが教えたから開発できたはずだ」と主張し、受領者側は「それとは無関係に自力で開発した」と反論する。この争いで決め手になるのは、開発プロセスの記録に他ならない。
- NDA締結前から存在する開発ロードマップ・研究日誌
- 担当エンジニアが秘密情報にアクセスしていないことを示す権限ログ
- 「クリーンルーム」方式を採用した場合のチーム分離記録
- 成果物（コード・設計書）のバージョン管理履歴
- 開発会議の議事録・メール（秘密情報を参照した記述がないことの確認）
3. 立証責任の問題
例外条項を巡る紛争で必ず問題になるのが、「誰が証明責任を負うか」だ。
日本法の一般原則では、義務の不履行を主張する側（＝開示者側）が秘密情報であることを証明し、義務を免れると主張する側（＝受領者側）が例外事由を証明する、という整理になりやすい。しかし契約上の規定が曖昧だと、この負担配分も争点になる。
| 例外類型 | 証明主体（契約上の原則） | 証明が困難になるケース |
|---|---|---|
| ① 公知情報 | 受領者 | 公知の時期・範囲が争われる場合 |
| ② 受領前保有 | 受領者 | 事前保有の記録がない場合 |
| ③ 第三者取得 | 受領者 | 第三者の守秘義務有無が不明な場合 |
| ④ 独自開発 | 受領者 | 開発プロセスの記録がない場合（最多） |
4. 修正文言の考え方
基本形（受領側有利版）
各号の修正ポイント
| 号 | 弱い書き方（要修正） | 望ましい書き方 |
|---|---|---|
| 一号（公知） | 「開示時点で公知であった情報」のみ | 「開示時点で公知であった、または受領者の帰責なく公知となった」 |
| 二号（受領前） | 「受領前から保有していたことを証明できる情報」 | 「受領前から保有していた情報」とシンプルに書く。「証明できる場合に限る」を入れると受領側が自ら権利を狭める結果になる。証明手段は社内記録で担保するのが正解 |
| 三号（第三者） | 「第三者から取得した情報」のみ | 「当該第三者自身が守秘義務を負わず取得した情報」と二段の要件。善意・無過失の文言を検討することも選択肢 |
| 四号（独自開発） | 「独自に開発した情報」のみ | 「秘密情報を参照・利用せずに独自に開発」と非参照を明示 |
| 五号（法令開示） | 規定なし（欠落） | 裁判所・行政命令による開示を明記。事前通知義務と開示最小化の努力義務をセットで規定する |
このような条項がない状態で行政調査・訴訟対応が発生した場合、「NDA違反では」という余計な争点を生む可能性がある。単に「開示できる」と書くだけでなく、①開示者への事前通知、②開示範囲の最小化をセットにするのが実務の定石だ。
開示側が求めるカウンター修正
開示者の立場でNDAを見る場合、例外条項を狭くする方向で交渉する。主な修正要求の類型は以下のとおりだ。
- 「書面による証明ができる場合に限り」除外とする
- 独自開発の場合、「開発完了を書面で通知」することを除外の条件に加える
- 「公知」の定義に「業界内での周知」は含まないと明記する
- 除外主張は「NDA締結後○日以内に書面で申し出ること」と期限を設ける
どこまで受け入れるかは交渉力と情報の重要度次第だが、書面通知義務や期限設定は実務負担が大きく、実態に合わないことも多い。盲目的に受け入れず、必要性を吟味すること。
定義を広く設定するほど、例外条項の精度が重要になる。両条項を切り離してレビューするのではなく、定義→例外→目的外利用禁止の流れで一貫してチェックすること。
詳しくは→ 「NDAの秘密情報の定義とは？」
5. まとめ：例外条項の実務チェックリスト
- 四類型（公知・受領前保有・第三者取得・独自開発）がすべて列挙されているか
- 「受領後に公知になった」ケースが一号でカバーされているか
- 三号で「第三者自身の守秘義務」に言及しているか
- 四号で「秘密情報を参照せず」の要件が明示されているか
- 法令・裁判所・行政機関の命令に基づく開示（Mandatory Disclosure）の規定が独立して置かれているか
- 法令開示の際に「事前通知義務」と「開示範囲の最小化」がセットになっているか
- 二号の文言が「証明できる場合に限り」等の制限を受領側自ら課していないか
- 開示者側の追加要件（書面通知・期限）が実務上過重でないか確認したか
- 社内で受領前保有・独自開発の記録体制が整っているか
- 定義条項と矛盾がないかセットで確認したか
📋 NDAレビューをAIプロンプトで効率化する
NDA全条項のチェック・修正案生成・相手方への交渉文面作成まで、実務で使えるプロンプトを「契約書AIレビュープロンプト集（全10STEP）」に収録しています。
例外条項の問題点の洗い出しから修正文言の提案まで、ひとつのプロンプトで対応可能な設計です。
🔍 関連ガイドへ進む
この記事と関連度の高い実務ガイドをまとめています。次に読むならこちら。
一次整理／マスキング／論点チェック／運用引継ぎ／稟議一枚化まで、
個別課題から少しずつ軽くしていく入口です。
