秘密保持契約(NDA)とは？エンジニアが押さえる条項と AI 時代の罠

一方向 NDA (One-way NDA)

「 片方だけが秘密情報を開示する場合」。発注側から受注側へシステム要件や顧客データを開示するときに使う。受託開発の発注時の典型。受注側だけが守秘義務を負う形。

双方向 NDA (Mutual NDA)

「 両者が秘密情報を開示する場合」。業務提携・ジョイントベンチャー・M&A 検討 など、双方の情報を交換するときに使う。両者が同じ守秘義務を負う対称な構造。

いつ結ぶか

「 具体的な業務委託や契約交渉の前」 に結ぶのが基本。契約検討フェーズで開示する情報 を守るため。「本契約(業務委託契約や開発契約)とは別の独立した契約」 として結ぶケースが多い。

本契約と一体化するパターン

「業務委託契約書の中に秘密保持条項として組み込まれる」 こともある。「本契約 + NDA 条項」「NDA + 業務委託契約」 のどちらの形式でも実質は同じ。「どの文書のどの条項に書いてあるか」 を必ず確認する。

受託開発・業務委託の発注

クライアント(発注者)が自社のテンプレ NDA を持っていて、開発会社や個人エンジニアに「契約検討の前にこれにサインして」と渡してくる。エンジニア側はほぼ常に受領者として、受け取った文書をレビューしてサインするフロー。スタートアップなど自社にひな型を持たないクライアントだと、こちらに「サンプルくれませんか」と聞かれることも稀にある。

副業・スポット案件

副業先・依頼元が NDA を用意してくることがほとんど。個人副業者は受領者の立場でサインを求められる。本業の就業規則で「副業時の追加契約締結には会社の承認が必要」と決まっているケースもあるので、「副業先からの NDA を本業に確認なしでサインしていいか」も判断ポイント。

転職面談

採用企業側が候補者に NDA を求めることがある(面談で開示する戦略情報を守るため)。候補者(エンジニア)は受領者として、面談前にサインを求められる。「内定前のサインを断ったら不利になるのでは」と感じやすいが、内容は冷静に読む。明らかに広すぎる範囲や、転職後の競業まで縛る条項が混ざっていれば交渉対象。

業務提携・M&A 検討

両者が秘密情報を出し合う双方向 NDA(Mutual NDA)では、どちらかが叩き台を作って両者で詰める形になる。実務慣行では「自社にひな型がある会社が出すことが多い」「相手の方が大企業ならその社内テンプレで進める」のような流れ。最終的には両者の代表者がサインする。

受領者として読むときの姿勢

「自社にとって厳しすぎる条項を交渉する」のが基本姿勢。定型文だと思って 1 分でサインしない。違約金が高額固定、有効期間が無期限、競業避止が広すぎる、AI 利用が一切禁止 — これらは 必ず交渉する 候補。

開示者として作るときの姿勢

「自社が守りたい範囲が十分にカバーされているか」「除外事項が広すぎないか」を確認。テンプレを使い回す場合も、案件ごとに対象情報の特定方法と有効期間を見直す。「全件無期限」のような乱暴な書き方は相手から拒否されやすい。

テンプレートをそのまま使わない

ネットや書籍のテンプレを そのまま使うのは危険。「業種・取引の性質・自社の立場」で適切な条項が違うので、必ず弁護士または法務担当にレビューしてもらう。NDA は 後から `テンプレに書いてあったから』 は通じない。

サインの方法

紙の押印 / 印鑑、PDF にサイン、クラウドサイン / DocuSign / Adobe Acrobat Sign のような電子契約サービス のいずれかが主流。電子契約は「いつ誰が署名したか」のログが自動で残るので、近年は多くの企業で標準化している。サイン方法に応じた本人確認(2FA、メール認証)もチェック。

広すぎる定義の例

「 本契約に関連して開示される一切の情報」 「 当社の事業に関する情報」 のような 無限定の表現。「これだと事実上何でも秘密扱い」になり、後から 「この発言は秘密だった」 と主張される リスクがある。

適切な定義の例

` 書面で 「秘密」 と明示された情報」 「 口頭開示時に 「秘密」 と告げ、後日書面で確認した情報」 のような 明確な特定基準。「何が秘密で、何がそうでないかが客観的に分かる」状態。

通常含まれる除外事項

「 受領前から既に保有していた情報」 「 公知の情報」 「 受領後に正当に取得した情報」 「 独自開発した情報」 は 秘密情報から除外するのが一般的。「除外事項が無い NDA はサインしない」 のが鉄則。

残存知識の扱い

「 担当者が業務を通じて自然に身につけた知識(Residual Knowledge)」 を 「秘密情報」 に含めるかどうか。「 含めない条項」 を入れてもらうと、エンジニアの汎用スキルが将来の仕事で使えなくなるリスクが減る。

短期(2〜3 年)

「 一般的なビジネス情報」 「 短期プロジェクト」 では 2〜3 年が標準。IT 業界では 「3 年経てば技術的価値が大きく変わる」 ので、合理的な期間。

中期(5 年)

「 戦略的に重要な情報」 「 製品開発に関わる情報」 では 5 年程度が多い。「長すぎず短すぎず」 で実務的には許容範囲。

長期(10 年以上 / 無期限)

「 個人情報」 「 ノウハウ」 「 営業秘密」 では 10 年以上や 「無期限」 が出ることがある。「 無期限の守秘義務」 は実質的に永遠の縛りになるので、サイン前に必ず期間を区切る交渉をする。

交渉のコツ

「 業界水準が 3〜5 年なので、それに合わせたい」 と伝えるのが定石。`相手が 「業界によっては無期限が普通」 と主張」 してきたら、情報の種類別に期間を分ける 提案(例: 個人情報は無期限、その他技術情報は 5 年)が現実的な落としどころ。

伝統的な目的外利用

「 受託開発で受け取った要件定義書を、別の案件の提案に流用する」 「 顧客リストを自社の営業に使う」 のような典型例。「これらは明確に NG」。

AI 時代に増えた新パターン

「 受け取った機密データを ChatGPT / Claude に貼り付けて分析させる」 「 ソースコードを Copilot や Cursor に学習させる」 「 議事録を AI で要約させる」 のような行為。厳密には目的外利用や第三者開示に該当する可能性 がある。

企業の AI 利用ポリシー

「 受託先・顧客の AI 利用ポリシーを確認」 してから NDA を結ぶのが安全。顧客が 「AI への入力禁止」 を NDA で明示している ケースが増えており、「サインしたら AI ツールが使えなくなる」 事態に陥る。

明示的に許可する交渉

「 開発に必要な範囲で、エンタープライズ契約の AI サービス(Bedrock / Vertex AI / Azure OpenAI など、データを学習に使わない契約)を利用してよい」 という条項を入れる交渉ができれば理想。「AI を使えない案件」 は現代では実務的に非効率なので、最初に握っておく。

伝統的な例外(開示してよい第三者)

「 業務遂行に必要な範囲で、社内の関係者・下請け業者・弁護士・税理士・公認会計士に開示できる」 のような例外規定。これらは 同等の守秘義務を負わせること が条件となる。

クラウドサービスの扱い

「 AWS / Google Cloud / Azure 上にデータを置く」 ことが 「 第三者開示」 に該当するか。一般的には 「クラウドプロバイダは情報を見ないので問題なし」 と解釈されるが、「明示的に契約に書いておく」 とトラブルが防げる。

AI サービスの扱い

「 OpenAI / Anthropic / Google」 などへの入力は 明確に 「第三者開示」 とみなされる可能性が高い。「データを学習に使われる無料プラン」 と 「エンタープライズ契約(学習に使わない)」 で扱いが違うので、契約内容を NDA 当事者に開示してから利用可否を決めるのが安全。

下請け開発体制

「 受託案件を一部下請けに出す」 ケースでは、「下請け業者にも同等の NDA を締結させる義務」 が課されるのが一般的。下請けが情報を漏らした責任は元請けも連帯する設計になっていることが多い。

実損害賠償型

「 違反によって相手が被った実損害を賠償」 する一般的な形式。「実際の損害額を立証する必要」 があるので、「小さな違反では金額が小さい」。

違約金固定型

「 違反 1 件につき 100 万円」 「 違反 1 件につき 1,000 万円」 のような 事前固定の違約金。実損害より遥かに高額 に設定されているケースがあり、個人エンジニアにとっては致命的になる可能性。サイン前に必ず金額を確認。

差止請求

「 違反行為を強制的に停止させる」 法的措置。「違反コンテンツの削除」 「 違反者の業務停止」 を裁判所経由で求められる。「金銭賠償だけで済まない」 のが NDA の重要な性質。

刑事罰

「 不正競争防止法」 の 「営業秘密侵害罪」 に該当すると、刑事罰(10 年以下の懲役 + 2,000 万円以下の罰金)のリスクもある。「民事の損害賠償だけでなく刑事責任も」 を意識する。

物理データの返還・破棄

「 紙の資料」 「 USB / DVD などの物理媒体」 を 「返還または破棄」 するのは比較的簡単。「破棄証明書」 を出せと要求されることも。

電子データの完全削除

「 バックアップを含めて完全削除」 は 実務上非常に難しい。「クラウドストレージのバージョニング」 「 メールサーバのアーカイブ」 「 開発環境のスナップショット」 など、「完全削除を保証できない場所」 が多数ある。

合理的な落としどころ

「 業務遂行に通常用いられる範囲で削除し、自動バックアップやアーカイブに残るものは別途速やかに削除に努める」 のような 努力義務の形に交渉する。「100% 完全削除義務」 はサインしないのが安全。

クライアント側でも難しい

「 100% 完全削除はクライアント側も実は難しい」 ことが多く、「お互いに合理的な努力義務」 にするのが現実的。AI 時代では 学習データに混入したものは削除できない のような新しい論点もある。

過去案件の知見が次で使えなくなる

「 業界特有のドメイン知識」 「 アーキテクチャパターン」 「 失敗体験」 を、「相手の秘密情報」 として広く定義されると、次の似た案件で当然のように使う知見が違反扱いになる 恐れ。Residual Knowledge 条項(担当者が自然に身についた一般知識は秘密情報から除外)の追加を交渉する。

GitHub に成果物を公開できない

「 自分が書いたコード」 を ポートフォリオとして公開できない ケース。「コード自体が顧客の秘密情報」 と扱われていると、「書いた本人でも公開不可」。「公開不可の部分」 と 「汎用ライブラリ」 を切り分ける合意ができるとよい。

転職時の競合業務制限

「 退職後 N 年は競合企業で働かない」 のような 競業避止義務が紛れていることがある。「NDA とは別文書(雇用契約や別途の覚書)で出てくる」 ことも多い。「 競業の範囲」 「 期間」 が広すぎないか必ず確認。

SNS / ブログでの言及

「 案件で得た技術的気づきをブログに書く」 「 X(Twitter)で技術ネタとして共有」 が、` 秘密情報の開示にあたる可能性。「抽象化して書けば OK」 と思いがちだが、「どこまで抽象化すれば OK か」 の線引きを事前に確認する。

LLM への入力 = 開示か?

「 ChatGPT に貼り付けたら、それは OpenAI への開示か?」 の論点。学習に使われる契約のサービスに入力すれば、明確に第三者開示。エンタープライズ契約(「OpenAI Enterprise / Azure OpenAI / Bedrock / Vertex AI」)では 「データが学習に使われない」 設計だが、`それでも 「第三者の処理を経由した」 ことに変わりはない」 と慎重に解釈する組織もある。

企業の AI 利用ポリシー

` 大手企業の NDA は 「AI ツールへの入力禁止」 「 認可された AI サービスのみ利用可」 を明示するケースが急増。受託先のポリシーを事前確認 し、「必要な AI 利用が NDA で禁止されていないか」 を確かめる。

Copilot / Cursor のコード補完

「 GitHub Copilot / Cursor / Claude Code」 のような AI コーディング補助は、プロジェクトのコード全体を AI に送る 仕組み。「Business / Enterprise プラン」 では学習に使われない契約だが、「NDA 契約下のコードを AI に渡して大丈夫か」 を事前に確認する。

AI 議事録 / 文書要約

「 Zoom / Microsoft Teams / Otter」 などの AI 議事録ツールが 会議内容を自動でクラウド送信。「NDA で守るべき会議の内容を AI 議事録に取らせていいか」 は議論の的。AI 議事録の機密リスク も参考に。