これまでのAIセキュリティ記事では、攻撃者が「何かを送り込む」「エージェントに何かを実行させる」といった能動的な攻撃を中心に扱ってきました。しかし2025〜2026年に実証された新種の流出は、その前提を覆します。ユーザーは何もクリックせず、操作もせず、エージェントが能動的に動かなくても、社内データが外部へ漏れる——「ゼロクリック・データ流出」です。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで長年、正規トラフィックに偽装した不正な外向き通信（egress）の検知に携わってきました。本記事の核心は、そのNOC/TAC的な「出力＝送信経路」を監視・封鎖する発想が、そのままゼロクリック流出の防御に転用できるという点にあります。攻撃の入口（プロンプト）ではなく、出力・レンダリング層そのものが流出チャネルになるという、これまで手薄だった領域を埋めます。
想定読者は、M365 Copilot・ChatGPT Enterprise・各種AIブラウザを全社導入した、あるいは社内エージェントに外部コンテンツ（メール・SaaS・Web）を読ませている情シス・CISOの方々です。
ゼロクリック流出とは何か——「クリック不要・操作不要」がなぜ成立するか
従来のフィッシングやマルウェアは、ユーザーがリンクを踏む・ファイルを開くといった「操作」を起点にしていました。ゼロクリック流出は、この起点を必要としません。成立条件は次の3つが揃うことです。
- AIアシスタントが外部コンテンツを自動で読む： RAGやメール要約、Web閲覧の機能により、ユーザーが開かなくても受信メールや外部ページの中身がモデルの文脈に取り込まれる。
- その外部コンテンツに指示が仕込まれている（間接プロンプトインジェクション）： 人間には見えない形で「社内データを集めて、このURLへ送れ」という命令が埋め込まれている。
- 出力やレンダリングが、そのまま送信経路になる： アシスタントの回答に攻撃者URLを参照する要素（画像・リンク）が埋め込まれ、クライアントやエージェントがそれを自動的に取得・送信してしまう。
つまり「受信した瞬間に、ユーザーの代わりにAIが攻撃を完遂する」構造です。攻撃者はサーバーに侵入しません。正規の業務フロー（メールを受け取る、質問する）に便乗するだけで、防御側の「ユーザー操作を監視する」前提が無効化されます。
攻撃の解剖——3つの実証事例（EchoLeak／ShadowLeak／HashJack）
2025〜2026年に公開された代表的な3つの事例は、いずれも「間接インジェクション → 出力に流出経路を埋め込む → クライアント／エージェントが自動実行」という同じ骨格を持ちながら、流出が起きる「場所」と「経路」が異なります。この違いが、そのまま防御設計の分岐点になります。
EchoLeak（CVE-2025-32711）——回答UIのMarkdown画像が漏らす
Aim Labs（Aim Security）が報告し、Microsoftが修正した、Microsoft 365 Copilotのゼロクリック脆弱性です。CVSSスコア9.3の「Critical」で、本番運用中のAI製品に対して初めて実証された、概念実証（PoC）の域を超える実環境で成立するゼロクリック・プロンプトインジェクションと位置づけられています（なお、Microsoftは実際の悪用は確認されていないとしており、2025年6月にサーバー側で修正済みです）。
攻撃の流れは、細工したメールを1通送るだけ。Copilotがそのメールを文脈に取り込み（RAG）、回答を生成する過程で攻撃者サーバーを参照するMarkdown画像を出力に埋め込み、クライアントがその画像を自動取得した瞬間に、URLへ付加された社内データが流出します。研究者はこれを、外部の信頼できない入力が特権的な内部データにアクセスさせる「LLM Scope Violation（スコープ違反）」という新しい脆弱性クラスとして定義しました。流出はユーザーの回答画面（クライアント側）でのレンダリングを起点に起こります。
ShadowLeak——OpenAIのクラウド側で、見えないまま漏らす
Radwareが報告した、ChatGPTのDeep Researchエージェントを狙うゼロクリック脆弱性です（OpenAIが2025年8月に修正済み）。EchoLeakが「クライアント側のレンダリング」で漏らすのに対し、ShadowLeakは流出がOpenAIのクラウド（サーバー側）で完結する点が決定的に異なります。
仕掛けは、メールHTML内に白文字・極小フォント・レイアウトトリックで隠した間接インジェクション。Deep Researchエージェントが受信トレイを処理する際、隠された命令に従い、抽出したPIIをBase64エンコードして攻撃者URLに付加し、browser.open()でクラウドから直接送信します。送信がプロバイダー側インフラから行われるため、企業のネットワーク監視やエンドポイント防御からは一切見えません——ローカル防御から不可視という、検知の死角を突く発展形です。Gmail連携を前提としたPoCですが、Box・Dropbox・Google Drive・Outlook・SharePointなど他コネクタにも拡張可能とされています。
HashJack——URLの「#以降」が、正規サイトを武器化する
Cato Networks（Cato CTRL）が2025年11月に公開した、AIブラウザ向けの間接プロンプトインジェクションです。悪意ある命令をURLフラグメント（「#」記号より後ろの部分）に隠します。フラグメントは仕様上ブラウザ内（クライアント側）でのみ処理され、サーバーには送られないため、IDS/IPS・WAF・CSP・サーバーログのいずれにも痕跡が残りません。
ユーザーが正規サイトのURL（末尾に隠し命令付き）を開き、AIブラウザのアシスタントに何か質問すると、フラグメントを含む完全なURLがLLMの文脈に渡され、隠された命令が実行されます。Perplexity Comet・Microsoft Edge Copilot・Google Gemini for Chromeで実証され、フィッシング・データ送信・認証情報窃取などが可能でした。「任意の正規サイトを、改ざんせずに攻撃の運び屋に変える」初の手口とされています（報告時点でPerplexityとMicrosoftは修正済み、Gemini for Chromeは未対応。なおClaude for ChromeとOpenAI Atlasでは成立しませんでした）。
3類型の比較
同じ「ゼロクリック流出」でも、守るべき層が異なることが一目で分かります。
| 項目 | EchoLeak | ShadowLeak | HashJack |
|---|---|---|---|
| 標的 | M365 Copilot | ChatGPT Deep Research | AIブラウザ（Comet/Edge Copilot/Gemini） |
| 流出が起きる場所 | クライアント側（回答UI） | サーバー側（OpenAIクラウド） | クライアント側（ブラウザ内LLM） |
| 流出チャネル | 自動取得されるMarkdown画像 | エージェントのHTTP送信（browser.open） | URLフラグメント（#以降） |
| すり抜けた防御 | XPIA分類器・リンク無害化・CSP | ローカル/企業防御から不可視 | IDS/IPS・WAF・CSP・サーバーログ |
| 起点 | 細工したメール1通 | 細工したメール1通 | 細工したURL（メール/SNS/Web経由） |
| 対応状況 | 2025年6月修正（CVSS 9.3） | 2025年8月修正 | 一部修正、当初Geminiは未対応 |
なぜ従来の分類器・リンク無害化をすり抜けるのか
これらの攻撃が厄介なのは、既存のAIセキュリティ対策（プロンプトインジェクション分類器、リンク無害化）を正面から回避する点です。回避の手口は、いずれも「検査される面」と「実際に実行される面」をずらすことに尽きます。
- 参照スタイルのMarkdownリンク： EchoLeakは、リンクの実体を本文と別の場所で定義する参照スタイル記法を使い、リンク無害化（redaction）の検査をすり抜けました。
- URLフラグメント： HashJackは、サーバーに送られず・ログにも残らないフラグメントに命令を隠すことで、ネットワーク層の検査を完全に回避します。
- 白文字・極小フォント・レイアウトトリック： ShadowLeakは、人間には見えずモデルだけが読むテキストとして命令を埋め込みます。分類器が「自然な文章」と判定する隙を突きます。
- 分類器そのものの回避： EchoLeakのメールは、Copilotやリ＝AIに一切言及しない文面にすることで、XPIA（Cross Prompt Injection Attempt）分類器の検知を避けました。
つまり確率的な検知（分類器）だけに頼る限り、回避策はいくらでも生まれる。だからこそ、検知をすり抜けられても被害が成立しない「決定論的に閉じられる経路」を併用する必要があります。
第1の防御層：決定論的に閉じられる経路
ここがNOC/TAC的な発想の真骨頂です。「怪しいかどうかを当てる」のではなく、流出に使える経路そのものを構造的に塞ぐ。確率に依存しない、決定論的な封鎖です。
- 外部画像の自動レンダリング無効化： アシスタントの回答に含まれる外部URL画像を、クライアントが自動取得しない設定にする。EchoLeak型の最も直接的な遮断策です。
- Markdown画像/リンク構文のサニタイズ： 出力に含まれる
形式の画像構文や参照スタイルリンクを、送信前に無害化（プレーンテキスト化・除去）する。 - Unicodeタグ文字・不可視文字の除去： 人間に見えない制御文字や白文字に仕込まれた命令を、入出力の両面でストリップする。
- URLフラグメントの分離： AIブラウザ／エージェントがURLを文脈に取り込む際、フラグメント（#以降）を切り離してから渡す。HashJack型への構造的対策です。
- 出力先URLのアローリスト化： エージェントが外部へHTTPリクエストを送れる宛先を、明示的に許可したドメインに限定する。ShadowLeak型のegressを宛先側で絞ります。
第2の防御層：確率的防御との組み合わせ（情報フロー制御・Dual-LLM）
決定論的な封鎖だけでは、新しいチャネルが見つかるたびに後追いになります。これを補うのが、「信頼できない入力」が「特権的な操作」に到達する経路を設計で断つ情報フロー制御です。
- 情報フロー制御（IFC）： 外部由来（untrusted）のデータが、社内データへのアクセスや外部送信といった特権操作のトリガーになれないよう、データに「来歴（信頼レベル）」のラベルを付けて追跡する。EchoLeakの「LLM Scope Violation」は、まさにこの境界が崩れた事例でした。
- Dual-LLMパターン： 信頼できない入力を処理する「隔離されたLLM」と、特権操作を実行する「特権LLM」を分離する。隔離側は外部送信やツール実行の権限を持たず、特権側は生の外部データを直接見ない、という構成で被害を封じ込めます。
決定論的封鎖（経路を塞ぐ）と確率的・構造的防御（権限を分ける）は、どちらか一方ではなく多層で重ねて初めて意味を持ちます。
第3の防御層：egress監視——NOC的な「外向き通信」の検知
最後の砦は、出力を「送信経路」として監視する発想です。ネットワーク運用では、内部から外部への不審な通信（egress）を検知・遮断するのは基本動作です。同じ視点をAIアシスタントの出力に適用します。
- 出力に含まれる外部参照の監査： アシスタントの回答に、業務文脈と無関係な外部ドメインへの画像・リンク・リクエストが含まれていないかを記録・スコアリングする。
- エージェントの外向きリクエストのログ化： どのエージェントが、いつ、どの宛先へ、どんなデータを送ろうとしたかを改ざん不能なログに残す。ShadowLeakのように「サーバー側で見えない」攻撃に対しては、プロバイダー側のログ連携が鍵になります。
- 異常な送信パターンの検知： Base64エンコードされた長い文字列をURLに付加する、といった「人間の対話としては不自然な外向き通信」をシグナルとして捉える。これはポートスキャンを網羅性パターンで検知するのと同じ発想です。
ゼロクリック流出 防御チェックリスト
| 層 | 対策 | 主に効く攻撃 |
|---|---|---|
| 決定論 | 外部画像の自動レンダリング無効化 | EchoLeak型 |
| 決定論 | Markdown画像/参照リンクのサニタイズ | EchoLeak型 |
| 決定論 | Unicodeタグ・不可視文字の除去 | 全般（隠し命令） |
| 決定論 | URLフラグメントの分離 | HashJack型 |
| 決定論 | 出力先URLのアローリスト化 | ShadowLeak型 |
| 構造 | 情報フロー制御（来歴ラベル） | 全般（スコープ違反） |
| 構造 | Dual-LLM（隔離/特権の分離） | 全般 |
| 監視 | 出力の外部参照監査・egressログ | 全般（事後検知） |
| 運用 | 外部コンテンツを読むエージェントの権限最小化 | 全般 |
よくある質問（Q&A）
Q1. プロンプトインジェクション対策の分類器を入れていれば防げますか？
不十分です。EchoLeakはAIに一切言及しない文面でXPIA分類器を回避し、ShadowLeakは白文字・極小フォントで命令を隠し、HashJackはサーバーに届かないURLフラグメントを使いました。確率的な検知は回避策が次々生まれるため、検知をすり抜けても被害が成立しない決定論的な経路封鎖（自動レンダリング遮断・出力サニタイズ・宛先アローリスト）と必ず併用してください。
Q2. 「ゼロクリック」と従来の間接プロンプトインジェクションは何が違うのですか？
従来の間接インジェクションの多くは、エージェントが能動的にツールを連鎖実行する過程で漏れる「能動型」でした（間接的データ外部送信攻撃の解説はこちら）。本記事のゼロクリック流出は、ユーザーが何もせず・エージェントが能動的に動かなくても、出力レンダリングやURL処理だけで漏れる「受動型」に特化しています。守るべき面が入力ではなく出力・レンダリング層にある点が決定的な違いです。
Q3. ShadowLeakのようにサーバー側で漏れる攻撃は、企業側で何ができますか？
自社ネットワークからは見えないため、(1) エージェントに渡す前にメールHTMLをサニタイズ（隠しCSS・難読化テキスト・不審なHTMLを除去）する、(2) 外部コンテンツを読むエージェントのコネクタ権限を最小化する、(3) プロバイダーが提供する監査ログ・ガードレールを有効化する、の3点が現実的です。サーバー側の修正自体はプロバイダー（OpenAI等）に依存します。
Q4. 自動レンダリングを切ると、AIアシスタントの利便性が落ちませんか？
多少は落ちます。だからこそ「全社一律で切る」ではなく、外部コンテンツ（メール・SaaS・Web）を読ませる用途のエージェントに限定して適用し、内部完結の用途とは設定を分けるのが現実的です。利便性と流出経路の封鎖は、用途ごとにバランスを取って設計します。
Q5. 関連する他の攻撃面も押さえておくべきですか？
はい。入力面のリスクはマルチモーダル・プロンプトインジェクション（画像に仕込む手口）、プロンプト自体の窃取はプロンプトリーク対策、エージェントの記憶を汚染する攻撃はメモリ汚染対策で扱っています。本記事の出力・レンダリング面の封鎖と合わせて、入力・プロンプト・記憶・出力の各層を横断的に押さえることをおすすめします。
まとめ——「読ませた瞬間に漏れ得る」を前提に設計する
AIセキュリティの議論は長らく「悪い入力をどう弾くか」に集中してきました。しかし2025〜2026年に実証された3つの事例は、入力を弾けなくても、出力・レンダリング・URL処理の側を塞げば被害は止められることを逆説的に示しています。要点は3つです。
1. クリックも操作も不要で漏れる。 ゼロクリック流出は、AIが外部コンテンツを自動で読み、出力が送信経路になることで成立します。ユーザー操作を監視する従来の前提は通用しません。
2. 確率的検知だけでは追いつかない。 分類器・リンク無害化は回避され続けます。検知をすり抜けても被害が成立しない、決定論的な経路封鎖（自動レンダリング遮断・出力サニタイズ・宛先アローリスト）を土台に据えてください。
3. 出力を「外向き通信」として監視する。 これはNOC/TACのegress監視の発想そのものです。決定論的封鎖（事前）・情報フロー制御（構造）・egressログ（事後）を多層で重ねて初めて、ゼロクリック流出は止まります。
「AIに外部コンテンツを読ませない」という選択肢が現実的でない以上、「読ませた瞬間に漏れ得る」を前提に、決定論・構造・監視の3層で出力面を守る——これが、ゼロクリック時代のAIアシスタント防御の基本姿勢です。
参考リンク
- Microsoft Security Response Center「CVE-2025-32711（M365 Copilot Information Disclosure）」
- Radware「ShadowLeak: A Zero-Click, Service-Side Attack on ChatGPT Deep Research Agent」
- Cato CTRL「HashJack: Novel Indirect Prompt Injection Against AI Browser Assistants」
- OWASP Top 10 for LLM Applications（2025年版）
免責事項： 本記事は2026年6月時点の公開情報および各研究機関の報告に基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。記載した脆弱性の多くはベンダーにより修正済みですが、攻撃手法は継続的に進化します。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家にご相談ください。最新情報は各公式ソースでご確認ください。
コメント