受託開発をしていると、顧客と交わした秘密保持契約（NDA）が常に頭の片隅にある。そして生成 AI は、その NDA と静かに衝突する。
「このコードのバグを直して」——AI エージェントにそう指示しただけのつもりが、エージェントは文脈を理解するためにリポジトリ内のファイルを次々と読み込み、顧客の DB スキーマや業務ロジックごとクラウドに送信しているかもしれない。ブラウザでファイルをドラッグ＆ドロップするのと違い、自分が「外部に送っている」という自覚すら持てないまま、大量の機密が外へ出ていく。これが AI エージェント時代の新しい落とし穴だ。
本記事は、受託開発者が直面する「AI の生産性 × NDA 遵守」のジレンマを、法的な核心から整理し、よくある対策がなぜ根本解決にならないのかを見たうえで、では何が要るのかを設計の言葉で考える。（法的な記述は一般的な整理であり、個別の法的助言ではない点はご了承いただきたい。）
NDA 違反の核心は「学習されたか」ではない
多くの開発者は「API 経由で使い、学習をオプトアウトすれば NDA 違反は避けられる」と考えている。しかしこの認識は危うい。
NDA が禁じているのは通常、「秘密情報を第三者に開示・提供すること」と「目的外に利用すること」だ。ここで重要なのは、 論点が「学習に使われたか」ではなく「第三者の管理下に情報を置いたか（＝開示したか）」 である、という点だ。電子データを外部サーバーに送る行為は、広く「開示」に含まれうる。そしてクラウド AI の提供元は、契約当事者ではない明確な「第三者」だ。
つまり、顧客から預かったソースコードやスキーマをクラウド AI に送信した時点で、たとえそれが機械的な処理目的でも、形式的に「第三者への開示」と評価されうる。学習に使われたかどうかは、本質ではない。
「対策したつもり」が崩れる三つの場面
DPA・オプトアウト
エンタープライズ契約を結び DPA（データ処理契約）を締結し、学習利用をオプトアウトする——これは重要だが、「NDA 上のリスクを消す免罪符」ではない。前述の通り、争点は「学習に使われたか」ではなく「外部に開示したか」だ。顧客から「クラウドへの送信自体」を禁じられていれば、DPA の有無にかかわらず送信した時点で問題になりうる。さらに DPA は「事後の責任の所在」を定める契約であって、AI 事業者側のシステムバグによる漏洩を技術的に防ぐものではない（実際、過去にはインフラのバグで他ユーザーの履歴が見えてしまった事例も報告されている）。
顧客の API キーを借りる（BYOK）
では、顧客が契約・管理しているクラウド AI の API キーを提供してもらい、その範囲で使えばどうか。これは法的にはかなり有効だ。顧客がその AI 事業者を正規の利用先として指定・承諾したことになり、「受託側が独断で第三者に渡した」という構図を避けられる。
ただし、これでも残る課題がある。第一に、データがクラウドに送られる物理的な事実は変わらず、事業者側のバグによる漏洩リスクは消えない。第二に、AI エージェントによる無自覚な過剰送信（別プロジェクトの機密まで巻き込む）は防げない。第三に、借りた API キーそのものが極めて重要な機密であり、PC がマルウェアに感染すれば致命的な漏洩に直結する。加えて、API キーがあっても「どのレベルの情報まで送ってよいか」の線引き（データ分類）は依然として必要だ。BYOK は法的な土台にはなるが、現場の制御を肩代わりしてはくれない。
一律禁止・DLP／マスキング
「AI に顧客情報を入れるのは一律禁止」——最も厳格だが、生産性の誘惑が強すぎて、結局は個人アカウントでこっそり使う「シャドー AI」を生みやすい。監査もログも取れず、かえってリスクが増す。
技術的な対策として DLP（データ損失防止）やマスキングもあるが、開発特有の難しさがある。固有名詞を動的にマスクすると AI が文脈を見失い、出力品質が落ちる。そして正規表現で捕まえられるのはクレジットカード番号やメールアドレスのような定型情報まで。NDA で最も守りたい「独自アルゴリズム」や「未公開の業務ロジック」のような非定型の機密は、機械的には捕捉しきれない。
→ つまり、契約（DPA／BYOK）でも、人間の注意力でも、根本解決にはならない。
では、何が要るのか
ここまでの行き詰まりは、対策を「契約」と「人の注意」に頼っていることに起因する。残る道は、構造（仕組み）で解くことだ。その仕組みの「かたち」を、原則として描いてみる。
- 外に出さない設計を軸にする（ローカルファースト）。機密性の高い処理は手元（ローカル LLM）で完結させ、機密でないものだけクラウドの高性能モデルに任せる。「止める」のではなく、機密度に応じて送り先を振り分ける。
- AI に判断を委ねない。これが要だ。AI（機械学習モデル）の役割を、リスクを測る「評価（センサー）」に限定する。その評価値に対して、顧客ごとの NDA 要件を書き下した「ポリシー（ルール）」で判定し、重い最終的な判断は人間が下す。こうすれば「AI が勝手に決めた」というブラックボックスを避け、組織のルールに基づく説明責任が残る。
- ルールをコード化する（Policy as Code）。NDA 要件をプログラムに埋め込むのではなく、独立した設定（例：YAML）として持つ。顧客プロジェクトを切り替えれば、その NDA のルールに沿った運用へ自動的に切り替わる。「何がセーフで何がアウトか」という現場のノウハウが、そのまま資産として積み上がっていく。
- すべてを証跡に残す。入出力、送り先の判断、そして「送らなかった事実とその理由」を、時系列のログとして手元に記録する。これにより、顧客に対して「機密情報をクラウドに出していない」ことを、後から検証可能な形で示せる（主張するのではなく、記録で見せる）。レポートに本文や顧客名を含めず、件数とレベルだけにすれば、レポート自体が漏洩源になることも避けられる。
（誤解のないように言えば、手元で動かせる AI は最先端のクラウドモデルと同じ賢さではない。だからこれは「ローカルだけで何でもやる」話ではなく、「機密の局面はローカル、それ以外は最良のクラウド」を使い分ける話だ。そして手元の環境がどの程度のことをできるかは、使う前に正直に把握しておくのがいい。）
おわりに——契約にサインするだけでは、守れない
AI の便利さと NDA の板挟みは、もう「使うな」という通達や、現場のモラルへの依存では乗り越えられないところまで来ている。DPA を結ぶこと、オプトアウトすること、顧客の API キーを借りること——どれも土台としては大事だが、それ「だけ」では守りきれない。
本当に必要なのは、機密は手元に置き、外への送信を仕組みで統制し、その挙動を証跡で示せる基盤だ。AI に判断を委ねず、人間のルールで制御し、後から検証できる。そういう思想を備えたツールが、セキュリティ要件の厳しい顧客とも妥協せずに付き合っていくための、受託開発の標準になっていくはずだ。
次に読む
- クラウド生成 AI に会社の機密を入れて大丈夫か — 各社が既定でデータをどう扱うか (本記事の前提になる事実の整理)
- 「探して」は断られ、「直して」は通った — AIの安全装置を「モデルの中」だけに置くことの限界 — なぜ制御を「モデルの外側」に置く必要があるのか
- LLM ルーティングはどう動くのか — 「仕組みで統制する」を具体化すると何が起きるか
- Ollama と LM Studio で「機密は手元」を実現する — ローカル LLM 実務入門 — 「手元に置く」側の実装
関連リンク
筆者は、まさにこの「機密は手元で仕分ける」という思想のツールづくりに関わっている。だからこそ、契約だけでは埋まらない現場の隙間を、日々痛感している。
AI を制御するのは、人間の規範つまり、AI のポリシー設計である。AIを活用した業務で、機密分類 (DLM)、検証可能透明性 、説明責任 をどのように実現するのか、開発の現場から発信する Exapolicyの技術 Publication
Discussion