AIエージェントによるデータ漏えいのほとんどは、モデルがこっそりあなたの会社を記憶してしまうことが原因ではありません。原因は、名前を挙げて修正できる設定とアーキテクチャ上の過ちです。大きなものは次の通りです。デフォルト設定があなたの入力で学習してしまうコンシューマー層のアカウントで運用すること、エージェントに一個人の広範な権限を引き継がせること、一般公開向けのエージェントを社内システムに接続すること、そして「致命的なトリオ」(プライベートデータ、信頼できないコンテンツ、外部への送信経路)をそのまま放置し、たった1つのプロンプトインジェクションであなたのデータを読み取って外へ送り出せる状態にしておくことです。最後のパターンこそ、EchoLeak(CVE-2025-32711)が、ユーザーのクリックなしに、巧妙に作られたメールを通じてMicrosoft 365 Copilotから機密データを露出させた、まさにその手口です。対処法は特殊なものではなく、そのほとんどは何かが漏れた後に手渡されるチェックリストではなく、エージェントのローンチ前に下される判断です。
これは、私たちが構築したエージェントを他社のスタックの内側に組み込む前に検討するリストであり、技術に詳しくないオーナーでも自社の構成やベンダーの構成で同じ過ちを見抜けるように書いています。この一線をあなたのために本来あるべき位置に保ってほしいという場合は、私たちがどのように責任あるAIガバナンスとリスク管理を運用しているかをご覧ください。以下のすべては、どちらにしてもあなたが自由に使えるものです。
まず、このテーマを扱うほぼすべての記事が曖昧にしている区別を述べます。これを取り違えることこそ、過ち「ゼロ」だからです。エージェントを通じてデータが漏れる経路にはまったく異なる2つがあり、それぞれの対処法もまったく異なります。
- プロバイダーのデータ取り扱い。 モデルプロバイダーはあなたの入力を保存したり学習に使ったりするのか?これはあなたが署名する契約と、あなたが選ぶアカウント層の問題です。規約と設定で解決します。
- 実行時の流出。 エージェントは実行のまさにその瞬間に、本来送るべきでない場所へあなたのデータを送るよう仕向けられないか?これは契約ではなく、アーキテクチャで解決します。
調査の数字は、買い手がこれを言葉にできなくても感じ取っていることを示しています。Clouderaが14か国の上級ITリーダー約1,500人を対象に行った調査では、96%が今後1年でAIエージェントの利用を拡大する計画である一方、53%(半数以上)が導入の最大の障害としてデータプライバシーを挙げています。以下の7つの過ちこそ、その不安が現実の漏えいへと変わる地点であり、対処法が存在する地点です。
過ち1:本番のエージェントをコンシューマー層のアカウントで運用する
これは最も安価に犯せる過ちであり、最も簡単に直せる過ちです。誰かが、すでにそこにあるからという理由で、個人のChatGPTやコンシューマー版のGeminiアカウントにワークフローを接続してしまう。すると、あなたのビジネスデータは、それ向けに作られたわけでもないコンシューマー規約に支配されることになります。
コンシューマー層とエンタープライズ層の差は明確です。エンタープライズ側のパターンは各プロバイダーで一貫しています。デフォルトであなたのデータで学習しないこと、不正利用監視のための短い保持期間、そして要求に応じてより強力なオプションが用意されていることです。OpenAIのAPIは不正利用監視のためにデータを30日間保持してから削除し、デフォルトで学習には使いません。2025年9月14日付で、AnthropicはAPIログの保持期間を30日から7日へ短縮し、APIの入力と出力は学習に使われることが一切ありません。GoogleのVertex AI(エンタープライズ層)は学習に使わない設定が可能です。コンシューマー側ではデフォルトが逆転します。コンシューマー版ChatGPTは、あなたが削除しない限り会話を無期限に保存し、コンシューマー版Geminiの保持期間は最長36か月に及び、製品改善に使われる場合があります。
対処法: すべての本番エージェントを、個人ログインではなくエンタープライズのAPIまたはビジネスアカウントに載せてください。技術は同一です。違うのは規約であり、そしてその規約こそが、統制下にとどまるデータと、ひそかに学習素材になってしまうデータとを分ける、すべての違いなのです。
過ち2:エージェントが引き継ぐ過度に広範な権限
最もよくある実行時の漏えいは、巧妙なものではありません。エージェントに一従業員のアクセス権、さらに悪い場合は管理者キーが渡され、技術的にはその人が見られるものすべてを見られるようになる。そして、その役割をはるかに超える質問を投げかけられる、あるいは仕向けられるのです。
MicrosoftのCloud Adoption Frameworkはこのルールを明快に述べています。「エージェントには、その機能に必要な特定のデータソースだけにアクセスを許可しなさい。組織のすべてのデータへの広範なアクセスを与えてはならない。」サポートエージェントにあなたの給与システムは不要です。スケジューリングエージェントに顧客データベースは不要です。エージェントが人の代わりに動作するときは、その人のアイデンティティを安全に受け渡すことでその人の権限を引き継ぐべきです。そうすればヘルプデスクエージェントは、従業員に全員の人事記録ではなく、その人自身の記録だけを見せます。
対処法: 各エージェントに最小権限へスコープされた独自のアイデンティティを与え、固定的な上位権限の集合を持たせるのではなく、動作中のユーザーの権限を引き継がせてください。テストは単純です。明日エージェントが仕向けられても、被害は、過度に権限を持った1つのアカウントが到達できるすべてではなく、付与された狭い範囲に限定されます。
過ち3:一般公開向けエージェントを社内データに接続する
あなたのウェブサイト上のチャットボットと、社内レポートを起草するエージェントは、2つの異なるセキュリティの世界です。そして漏えいは、誰かがそれらにバックエンドを共有させた瞬間に起こります。一般公開向けエージェントは、インターネット上の誰からでも入力を受け付けます。もし同じエージェントが社内のビジネスデータも照会できるなら、あなたは公開ウェブからプライベートシステムへまっすぐ通じる扉を作ってしまったのです。
Microsoftのフレームワークはここで最も厳しい一線を引いています。「一般公開向けエージェントは社内のビジネスデータにアクセスしてはならない。」機密と公開を、物理的または論理的な境界で分けて保ってください(彼らの例では、別々の「corp」と「online」の管理グループを使っています)。要点は、境界が構造的なものであり、プロンプトが持ちこたえてくれるという願望ではない、ということです。
対処法: 信頼できない公開入力を受け取るエージェントと、機密データに触れるエージェントとの間に、本物の境界を置いてください。もし単一のエージェントが本当に両方をこなさなければならないなら、それはあなたが選べる中で最もリスクの高い設計であり、慎重なシステムプロンプトだけではなく、次の過ちで述べるトリオを断つ制御が必要です。
過ち4:致命的なトリオを無視する
これは、最初の3つを実際の流出へと変えてしまう過ちです。「プロンプトインジェクション」という用語を生み出した独立系の専門家Simon Willison氏は、AIエージェントの「致命的なトリオ」を名付けました。それは、組み合わさったときに、注入された1つの命令だけであなたのデータを盗めるようにする3つの条件です。
| 3つの脚 | その意味 | 例 |
|---|---|---|
| プライベートデータへのアクセス | エージェントが機密情報を読める | 受信トレイ、CRM、社内文書 |
| 信頼できないコンテンツへの接触 | 自分が書いていないテキストを処理する | 受信メール、ウェブページ、ファイル |
| 外部への通信 | データを外へ送れる | 返信、API呼び出し、取得したURL |
3つすべてが揃うと、攻撃者は信頼できないコンテンツの中に命令を隠します。モデルは、Willison氏の言葉を借りれば、「運用者からのものであろうと、他の何らかのソースからのものであろうと、モデルに届いた命令を喜んで何でも実行する」のです。エージェントはあなたのプライベートデータを読み取って外へ送り出し、そのメールを信用するなとはプロンプトのどこにも書かれていませんでした。
身も蓋もない部分、そしてこれがプロンプトエンジニアリングの問題ではなくアーキテクチャの問題である理由はこうです。「これが起きるのを100%確実に防ぐ方法は、私たちにはまだ分かっていない。」記録に残る悪用は、Microsoft 365 Copilot、GitHubのMCPサーバー、そしてGitLab Duoに及んでいます。2026年1月のある1週間には、間接プロンプトインジェクションの脆弱性が4つのAI生産性ツールで開示され、そのすべてが同じトリオのパターンでした。
対処法: 一脚を断ってください。盗まれたデータの行き場がなくなるよう外部への送信経路を遮断するか、信頼できないコンテンツを読むエージェントに同じコンテキスト内でプライベートデータへのアクセスを決して持たせないかです。あらゆるインジェクションを捕まえるという勝てない戦いに勝つ必要はありません。必要なのは、たとえインジェクションが成功しても外への出口がない状態を確実にすることです。
過ち5:EchoLeakを他人事として扱う
ここで実際のインシデントを1つ名指しする価値があります。なぜなら「致命的なトリオ」は、それが実行されるのを見るまで抽象的に聞こえるからです。EchoLeak(CVE-2025-32711)はMicrosoft 365 Copilotに対するゼロクリック攻撃でした。攻撃者は巧妙に作られたメールを送りました。Copilotは通常の仕事をこなす中で、そのメールを処理し(信頼できないコンテンツ)、ユーザーの社内データへのアクセスを持ち(プライベートデータ)、情報を外へ送る手段を持っていました(外部への通信)。隠された命令は、ユーザーの操作を一切伴わずに機密データの露出を完了させました。誰も何もクリックしていません。
ここでの過ちは、漏えいには不注意な従業員が必要だと思い込むことです。EchoLeakには誰も必要ありませんでした。重要だった防御は「フィッシングを見抜くよう社員を訓練する」ことではありませんでした。なぜなら、人間が見抜くべきものは何もなかったからです。重要だった防御はアーキテクチャ上のものでした。攻撃者が操作するコンテンツを読むことと流出させることの両方ができないエージェントは、この方法であなたに牙を向けることができません。
対処法: ゼロクリックを例外ではなく脅威モデルそのものだと想定してください。もしあなたのエージェントが、外部の者が影響を及ぼせるもの(メール、ウェブコンテンツ、アップロードされたファイル、チケット)を読み、かつデータを外へ送れるなら、その2つの能力のいずれかを閉じるか送信経路を固く封じない限り、あなたにはEchoLeak型の穴があります。
過ち6:データ所在地や保持期間の境界がない
漏えいの中には、劇的な流出ではなく、ゆっくりとした漂流であるものもあります。誰も境界を設定しなかったというだけの理由で、データが合意した覚えのないリージョンに保存されたり、ポリシーが許す以上に長くログの中に残り続けたりするのです。Microsoftのフレームワークは、これをガバナンスの中核として挙げています。各データソース、エージェントの実行環境、出力の保存場所の所在地を特定し、データをあなたの所在地ポリシーに合うリージョンまたはオンプレミスに保ち、保存時に暗号化して保つ、ということです。
ほぼどの記事も明言しない、安心できる事実があります。それは、どれだけ多くを確定できるかということです。各プロバイダーに共通するエンタープライズのパターンは、デフォルトで学習なし、加えて短い保持期間、加えて要求に応じたより強力な保証です。Anthropicは、対象となるエンタープライズにZero Data Retention(ZDR)契約を提供しており、その下では入力と出力は不正利用のスクリーニングに必要な範囲を超えて保存されません。OpenAIは交渉による契約でZDRとデータ所在地を提供しています。どちらもデータの所在地をあなたが選べます。オープンモデルを自己ホスト(例えばOllamaで)すれば、第三者による保持ゼロでデータを完全にローカルに保てます。
対処法: ローンチ前に境界を決めて文書化してください。どのリージョンがデータを保持するのか、ログがどれだけの期間残るのか、ZDRが必要か、そして機密の取得を自社のVPCまたはオンプレミスで実行すべきか、です。ZDRは通常API限定かつ交渉制で、追加しない限りすべての製品を自動的にカバーするわけではないので、細部が重要です。
過ち7:プライバシーを手渡すチェックリストとして扱う
最後の過ちは構造的なものです。優れたMicrosoftのフレームワークを含むほとんどのガイダンスは、あなたが自分でエージェントを構築し統制することを前提としているため、Entraのアイデンティティ、Purviewのラベル、管理グループといった3,000語の山があなたに手渡されます。それは大規模なITチームにとっては正しい答えです。しかしほとんどの企業にとっては、それを完全に実装する時間も専門スキルも誰も持たないチェックリストであり、だから中途半端に出荷され、そしてその隙間こそ、まさにデータが漏れる場所なのです。
過ちは、これらの制御を、誰かが端から端まで責任を持つアーキテクチャとしてではなく、ドキュメントとして扱うことです。「機密データを分離する」「外部統合を信頼できるMCPサーバーに限定する」と並べたチェックリストは、それを実際に組み込み、すべての外部通信を検証し、何かが起きたときにエージェントを素早く無効化するためのインシデント対応計画を立ち上げる人の質に、どこまでも左右されます。
対処法: 文書だけでなく、境界そのものに実際に責任を持つ当事者が必ず1つあるようにしてください。あなたがフルスタックを実装・維持する社内能力を構築するか、あるいは運用者にこれらの障害モードをアーキテクチャレベルで取り除いて運用してもらい、あなたが指し示せる公開された境界を持つか、です。間違った中間地点は、制御のリストはあるのに、それが持ちこたえることに責任を持つ者が誰もいない、という状態です。
7つの過ちと対処法の対応関係
ここに、対処法が「あなたが署名する契約」なのか「あなたが構築するアーキテクチャ」なのかで分類して、7つすべてを一か所にまとめます。この区分は、それぞれをどのチームが担うのかを知る最速の方法です。
| # | 過ち | 対処法 | 種類 |
|---|---|---|---|
| 1 | 本番でのコンシューマー層アカウント | エンタープライズAPIまたはビジネスアカウント、学習なし | 契約 |
| 2 | 引き継いだ過度に広範な権限 | 最小権限のアイデンティティ、ユーザーのアクセスを引き継ぐ | アーキテクチャ |
| 3 | 社内データに触れる一般公開向けエージェント | 公開と機密の間の固い境界 | アーキテクチャ |
| 4 | 致命的なトリオの無視 | 一脚を断つ:信頼できないコンテンツとプライベートデータと送信経路を揃えない | アーキテクチャ |
| 5 | 漏えいには不注意なクリックが必要だという思い込み | ゼロクリックを前提に設計する、流出経路を封じる | アーキテクチャ |
| 6 | 所在地や保持期間の境界がない | リージョンを固定し、保持期間を設定し、ZDRに署名し、境界でマスキングする | 契約 |
| 7 | 手渡されたチェックリストとしてのプライバシー | 境界が持ちこたえることに責任を持つ1人のオーナー | オーナーシップ |
7つのうち契約で解決するのは2つだけだということに注目してください。残りの5つはアーキテクチャとオーナーシップであり、それはベストプラクティスのPDFがあなたの代わりにはできない部分です。これはまた、権威ある情報源が隙間を残してしまう正直な理由でもあります。彼らは何を構築すべきかは教えてくれますが、あなたの特定のシステムの内側で誰がそれを正しく構築するのかは教えてくれないのです。
境界が正しく構築されたとき、実際に決して漏れないもの
7つの過ちを読んで、AIエージェントはプライバシーの地雷原だと結論づけるのは簡単です。しかし、その一線が意図的に引かれていれば、そうではありません。エンタープライズ規約の下では、あなたの入力は学習データではなく、保持期間は永遠ではなく日単位です(AnthropicのAPIは7日、OpenAIは30日、その後削除されます)。ZDRがあれば、不正利用のスクリーニングを超えて保存されることはありません。データ所在地が固定されていれば、データはあなたのリージョンにとどまります。VPCまたはオンプレミスでの取得があれば、機密データは決してあなたの境界の外へ出ません。境界でのマスキングがあれば、決して移動すべきでないフィールドは、何かが送られる前に取り除かれます。ユーザーの権限を引き継ぐ最小権限のスコープ設定があれば、エージェントは動作中の人がすでに到達できたものにしか到達できません。
それは具体的で弁護可能な境界であり、それを明快に述べられること自体が、すべての要点です。危険は、決してモデルがこっそりあなたの会社を吸収することではありませんでした。それは上記の設定とアーキテクチャ上の7つの過ちであり、そのどれもが、最初のエージェントが稼働する前に防止できるものです。
これこそ、私たちが他社のスタックの内側で行う仕事です。規約を選び、アイデンティティをスコープし、公開と機密を分離し、トリオを断ち、そして境界が持ちこたえるよう責任を持つ、ということです。これらの過ちが何か本物に触れる前に、あなたのエージェントからアーキテクチャレベルで取り除かれることをお望みなら、以下から無料相談を予約してください。一緒にあなたの境界を描き出しましょう。
