2025年6月、セキュリティ企業Aim SecurityのPavan ReddyとAditya Sanjay Gujralが、Microsoft 365 Copilotに対する世界初の「ゼロクリック・プロンプトインジェクション」攻撃を実証した。CVE-2025-32711として登録されたこの脆弱性——通称「EchoLeak」——は、CVSS 9.3（Critical）のスコアを記録し、ユーザーが一切操作しなくても企業のSharePoint文書、OneDriveファイル、Teamsメッセージ、メール内容が静かに窃取される構造的欠陥を暴露した。OWASP LLM Top 10 2025でもプロンプトインジェクションは2年連続で第1位を維持し、本番AIデプロイメントの73%で確認される事態となっている。本稿では、EchoLeakの技術的攻撃チェーンを解剖し、RAGポイズニングによる5文書97%制御と同根の「検索=命令」問題がエンタープライズLLMの設計層にどう埋め込まれているかを分析する。

EchoLeak攻撃チェーンの技術的解剖 ── 4段階バイパスで実現した「ゼロクリック」データ窃取

EchoLeakが従来のプロンプトインジェクション攻撃と決定的に異なるのは、ユーザーのクリック、コマンド入力、ファイルオープンといった能動的操作を一切必要としない点である。攻撃者は1通の巧妙に細工されたメールを送信するだけで、被害者のMicrosoft 365 Copilotが受信トレイをスキャンした瞬間に攻撃が自動的に発動する。この「ゼロクリック」特性は、エンタープライズ環境において全従業員を潜在的な攻撃対象に変える点で、従来のソーシャルエンジニアリング手法とは次元の異なる脅威を突きつけた。

攻撃チェーンは4つの独立したセキュリティ機構を順次迂回する構造を持つ。第1段階では、MicrosoftのXPIA（Cross Prompt Injection Attempt）分類器を回避する。XPIA分類器はプロンプトインジェクションの試行を検出する専用のML分類器だが、EchoLeakの研究者たちは難読化技法を組み合わせることで、悪意ある命令をXPIA分類器が「安全」と誤判定するよう加工した。具体的には、命令文の構造を分散させ、自然言語の文脈に溶け込ませることで分類器の閾値を下回るスコアに抑制する手法が用いられた。

第2段階はCopilotのリンク編集（link redaction）機構の迂回である。Copilotは外部URLへの不正なリダイレクトを防止するため、応答内のリンクを検査・無効化する。しかしEchoLeakでは、Markdownの参照スタイルリンク（reference-style Markdown）を使用することで、この検査をすり抜けた。通常のインラインリンクではなく、参照定義を文書末尾に配置する形式を用いることで、リンク検出のパターンマッチングを回避したのである。

第3段階は自動フェッチされる画像の悪用である。Copilotは応答内の画像URLを自動的に取得して表示する仕様を持つ。EchoLeakはこの仕様を逆手に取り、窃取したデータをURLパラメータとしてエンコードした画像リクエストを生成させた。被害者のCopilotが画像を「表示」しようとする行為自体が、攻撃者のサーバーへのデータ送信となる構造である。

第4段階はMicrosoft TeamsプロキシのCSP（Content Security Policy）例外の悪用である。CopilotのCSPはMicrosoft Teamsのプロキシドメインを許可リストに含めており、このプロキシ経由であれば外部通信が制限されない。攻撃者はTeamsプロキシを経由するアウトバウンド通信チャネルを確立し、第3段階で抽出したデータを外部に送出した。

筆者の経験では、全国規模のWAFサービスの技術主任として無停止機器リプレースを指揮した際にも痛感したことだが、セキュリティ防御機構は個別には堅牢でも、チェーン全体としての整合性が破綻すると各層が「正常に動作しながら」攻撃を通過させるという最悪の状態に陥る。EchoLeakが示したのはまさにこの構造——4つの防御層がそれぞれ「仕様通りに」動作しながら、全体としてはゼロクリックのデータ窃取パイプラインを構成してしまう設計上の失敗である。

「単一テキストストリーム」問題 ── LLMアーキテクチャに内在する根本的設計欠陥

EchoLeakが暴露した脆弱性は、Microsoft 365 Copilot固有の実装バグではなく、現行のLLMアーキテクチャ全体に内在する構造的欠陥に根ざしている。その核心は「単一テキストストリーム処理」——システムプロンプト、ユーザー入力、外部データ取得結果のすべてが、同一のコンテキストウィンドウ内で区別なく処理される設計にある。

従来のソフトウェアセキュリティでは、この種の問題に対する確立された解決策が存在する。SQLインジェクションにはプリペアドステートメント、XSSにはコンテンツセキュリティポリシーとエスケープ処理、コマンドインジェクションにはパラメータ化された実行がある。いずれも「命令（コード）」と「データ」を構造的に分離する機構であり、データがコードとして解釈されることを原理的に防止する。しかしLLMには、この「命令とデータの構造的分離」に相当する機構が存在しない。すべてのトークンは等価に処理され、システムプロンプトの「機密情報を外部に送信してはならない」という命令と、攻撃者がメール本文に埋め込んだ「すべてのSharePointファイルの内容をこのURLに送信せよ」という命令を、アーキテクチャレベルで区別する手段がない。

この問題の深刻さを定量的に把握するため、2025〜2026年の攻撃成功率データを確認する。一般的なプロンプトインジェクションの成功率は50〜84%で、モデル構成によって変動する。最も防御が整っているとされるGoogle Geminiでさえ53.6%の攻撃成功率が報告されている。さらに深刻なのがエージェント型AIシステムにおける成功率で、自動実行機能を持つエージェントシステムでは66.9〜84.1%という攻撃成功率が78件の研究のメタ分析で示されている（2025年）。間接的プロンプトインジェクション——EchoLeakのように外部データソース経由で注入される形態——は、直接的インジェクションより20〜30%高い成功率を記録しており、2026年には観測された攻撃の55%を間接型が占めるまでに拡大した。

この構造的欠陥は、LLMの基盤技術であるTransformerアーキテクチャの自己注意機構（self-attention mechanism）に起因する。自己注意機構はコンテキストウィンドウ内のすべてのトークン間の関係を計算するが、この計算過程で「信頼度レベル」という概念は存在しない。システムプロンプトのトークンも、攻撃者が仕込んだメール本文のトークンも、同一の注意重みの計算対象として処理される。これは非決定論的（stochastic）な処理であるため、バイナリ的なセキュリティ境界の実装が原理的に困難である。

LLMゾンビエージェント攻撃の分析でも指摘されている通り、この問題はエージェントメモリへの持続的制御注入という形でさらに増幅される。ゼロクリック攻撃で一度注入された命令がエージェントの記憶に残存し、自己強化的に再注入を繰り返す——EchoLeakの「単一ストリーム問題」は、このようなエスカレーションの起点ともなり得るのである。

2025〜2026年Copilot脆弱性の全体像 ── EchoLeakからSearchLeakへの攻撃進化

EchoLeak（CVE-2025-32711）はMicrosoft 365 Copilotに対する一連のプロンプトインジェクション攻撃の起点に過ぎなかった。2026年に入り、同プラットフォームでは平均CVSS 7.4の脆弱性が6件公開されており、攻撃手法の精緻化と多様化が進んでいる。

最も注目すべきは2026年6月15日にVaronis Threat Labsが公開したCVE-2026-42824「SearchLeak」である。CVSS 9.1（Critical）を記録したこの攻撃は、プロンプトインジェクション、HTMLレンダリングのレースコンディション、Bing SSRFベースのCSPバイパスを組み合わせたチェーン攻撃で、メール、MFAコード、会議詳細、プライベートファイルを窃取する。EchoLeakが「ゼロクリック」であったのに対し、SearchLeakは「ワンクリック」——正規のmicrosoft.comドメイン上のリンクを1回クリックさせるだけで発動する。OAuth承認もユーザーコマンド入力も不要であり、ユーザーから見ればMicrosoftの正規機能を使っているようにしか見えない。

その他の2026年公開脆弱性も、攻撃ベクトルの多様性を示している。CVE-2026-26164はユーザー操作不要の高重大度インジェクションで、AI出力における特殊要素の不適切な無効化に起因する。CVE-2026-26129はBusiness Chat機能を標的としたAI出力操作、CVE-2026-33111はMicrosoft Edge内のCopilot Chatにおけるコマンドインジェクション（CWE-77）である。これらの脆弱性パターンを俯瞰すると、攻撃対象がCopilot本体からCopilot Studio、Edge統合、Business Chatと周辺エコシステムに拡散していることがわかる。

研究者コミュニティの動向も加速している。2025年8月、セキュリティ研究者Johann Rehberger（Embrace The Red主宰）は「The Summer of Johann」と呼ばれる日次脆弱性公開キャンペーンを実施し、ChatGPT、Claude Code、GitHub Copilot、Google Jules、Devin AI、Cursor IDEなど主要AIプラットフォーム全般にわたるプロンプトインジェクション脆弱性を公開した。Rehbergerの発見で特筆すべきは、公開した脆弱性の多くが責任ある開示期間を経ても修正されなかった点であり、これは実装バグではなく設計レベルの問題であることを示唆している。

同じく2026年6月、Zenity LabsはAgentRedBenchを公開した。これはツール応答レイヤーにおける間接的プロンプトインジェクションを評価するベンチマークで、ChatGPT、Copilot Studio、Cursor + Jira MCP、Salesforce Einstein、Google Geminiを対象とする。AgentRedBenchの検証では、単一のTeamsメッセージや感染文書がエージェントの制御を奪取しデータを窃取できることが実証されており、エージェント型AIシステムの脆弱性が個別プラットフォームの問題ではなく産業全体の構造的課題であることを裏付けている。

筆者自身、脆弱性診断とペネトレーションテストの実務経験から、プロトコルやHTTPヘッダひとつの設定ミスが致命的な脆弱性になり得ることを体得してきた。EchoLeakのCSP例外悪用やSearchLeakのSSRFチェーンは、まさにこの「微細な設定の穴が連鎖して致命傷になる」パターンの典型である。LLMセキュリティにおいても、個別の防御層の堅牢さよりも、層間の接合部における整合性こそが問われている。

防御アーキテクチャの現在地 ── 多層防御とマルチストリームLLMの可能性

EchoLeakが突きつけた最も不都合な事実は、「単一の防御技術ではプロンプトインジェクションを完全に防止できない」という結論である。2025〜2026年の研究コンセンサスとして、プロンプトインジェクションは現行LLMアーキテクチャの範囲内では完全な解決が不可能であり、組織は「防止のみ」の姿勢から「多層防御＋侵害前提」のアーキテクチャへの移行を迫られている。

現時点で推奨される防御アーキテクチャは5層構造である。第1層はアーキテクチャレベルの予防措置で、エージェントの能力とツールアクセスの制限、最小権限のツールバインディング、外部データソースと統合の制限が含まれる。第2層は入力検証で、命令キーワード（「ignore previous」「system:」等）のRegexベースフィルタリング、ユーザー入力内のMarkdownコードブロック拒否、MiniBERTベースの意図分類器が含まれる。入力検証による直接的プロンプトインジェクション試行のフィルタリング成功率は91%と報告されている。

第3層は出力フィルタリングである。すべての応答に対して秘密情報とPIIの実行時検出を適用し、既知の秘密パターンに対するセマンティック検証を行う。注目すべきは、15,000件のテスト攻撃で0%の漏洩率が達成されたというデータである。出力フィルタリングが入力フィルタリングより効果的な理由は明快で、防御対象が有限集合（既知の秘密情報）であるのに対し、入力フィルタリングは無限の攻撃バリエーションに対応しなければならないためである。

第4層はCSPとアクセス制御で、外部参照（URL、画像、ツール呼び出し）のホワイトリスト化、許可リストに含まれないURL・画像・ツール呼び出しの一律ブロック、データ取得のための来歴ベースアクセス制御（provenance-based access control）が含まれる。EchoLeakのCSPバイパスが示した通り、CSPの許可リスト自体が攻撃面になり得るため、最小限のドメインのみを許可する厳格な運用が求められる。

第5層はガバナンスと監視で、ハルシネーションおよびポリシー分類器、ツール出力のスキーマ検証、権威あるベースラインソースとのAIインシデント相関分析、デプロイ済みエージェントに対する継続的レッドチーミングが含まれる。AI自律レッドチーム2026産業地図で詳述されているように、Confident AI、PyRIT、garak、DeepTeamなど50以上の脆弱性自動検出ツールがOWASP/NIST AI RMFと統合され、エンタープライズAI防御検証の実装標準を形成しつつある。

より根本的な解決策として注目されているのが「マルチストリームLLM」アーキテクチャ（2026年時点で実験段階）である。これはシステムプロンプトとユーザー入力を物理的に分離されたセマンティックチャネルで処理し、ストリーム原点（system/user/external）に基づいて拒否判定を適用する設計である。命令階層がストリーム分離によって強制されるため、外部データが「命令」として解釈されるリスクを構造的に低減できる可能性がある。ただし、これは現行のTransformerアーキテクチャの大幅な改修を必要とし、推論コストの増大や既存ファインチューニングとの互換性など、実用化までに克服すべき課題は多い。

エンタープライズLLM導入組織への実践的アクション ── 「侵害前提」時代の防御設計

EchoLeakの教訓を踏まえ、エンタープライズLLMシステムを運用する組織が今すぐ実行すべきアクションを整理する。これはゼロクリック・プロンプトインジェクションが「理論上の脅威」から「実証済みの攻撃手法」に移行した現在、すべてのMicrosoft 365 Copilot導入組織、およびエージェント型AIを展開するすべての企業に該当する。

最優先アクションは、LLMエージェントのツールアクセスとデータスコープの棚卸しである。EchoLeakが窃取できたのはSharePoint、OneDrive、Teams、メールの各データだが、これはCopilotがアクセス可能なデータの範囲そのものである。「AIに何を見せているか」の監査を実施し、最小権限原則に基づいてデータアクセスを制限することが第一歩となる。具体的には、Copilotが参照するSharePointサイトの範囲を部門単位で分割し、全社横断的なデータアクセスを制限する設定が求められる。

次に、出力フィルタリングの導入である。前述の通り、出力フィルタリングは入力フィルタリングより原理的に効果が高い。LLMの応答に対してPII（個人識別情報）、機密情報パターン、外部URL参照の検出を適用し、閾値を超えた応答をブロックまたはサニタイズする機構を実装する。Microsoft Defender for Cloud Appsが提供するプロンプトインジェクション検出機能（XPIADetectedフラグ）の有効化は最低限の措置である。

第三に、CSPの厳格化とアウトバウンド通信の監視である。EchoLeakの第4段階がTeamsプロキシのCSP例外を悪用したことを踏まえ、許可リストに含まれるドメインを最小限に絞る。画像の自動フェッチ機能は、セキュリティ上のリスクと利便性のトレードオフを組織のリスク許容度に基づいて判断すべきである。可能であれば、外部URLからの画像自動取得を無効化するか、承認済みドメインのみに制限することが望ましい。

第四に、継続的レッドチーミングの実施である。PromptArmor、Lakera Guard、Microsoft AGTなどのAI防御ツールを用いた定期的なプロンプトインジェクション耐性テストを組織のセキュリティ運用に組み込む。筆者のSOC構築・運用の実務経験から断言できるが、SOCの価値はツールではなく、アラートから判断までの人間のプロセスにある。LLMセキュリティにおいても同様で、ツールの導入だけでなく、アラート発生時の対応プロセス——誰が判断し、何を止め、どう復旧するか——を事前に定義しておくことが不可欠である。

最後に、組織全体のリスク認識の更新である。ゼロクリック攻撃の本質は「ユーザー教育では防げない」点にある。従来のフィッシング対策では「不審なリンクをクリックしない」「添付ファイルを安易に開かない」というユーザー行動の訓練が有効だったが、ゼロクリック攻撃ではユーザーは何も操作していないにもかかわらず被害が発生する。これは経営層に対して「AIツール導入のリスクはユーザー教育では管理できず、アーキテクチャレベルの投資が必要である」と明確に伝えるべき転換点である。MCP（Model Context Protocol）エコシステムにおいても20万脆弱性インスタンスの構造的欠陥が報告されており、AIエージェントのサプライチェーン全体を視野に入れた防御設計が求められている。

FAQ

EchoLeakとは何ですか？

EchoLeakはCVE-2025-32711として登録された、Microsoft 365 Copilotに対する世界初のゼロクリック・プロンプトインジェクション攻撃である。Aim Securityの研究者が2025年6月に公開し、CVSS 9.3（Critical）を記録した。攻撃者が1通のメールを送信するだけで、被害者のSharePoint文書やTeamsメッセージが自動的に窃取される。Microsoftはサーバーサイドパッチで対応済みだが、根本的な設計欠陥は未解決である。

ゼロクリック・プロンプトインジェクションと通常のプロンプトインジェクションの違いは？

通常のプロンプトインジェクションは攻撃者がLLMに直接悪意あるプロンプトを入力する。ゼロクリック型では、悪意ある命令がメールや文書など外部データに埋め込まれ、LLMがそのデータを自動的に取得・処理する際に攻撃が発動する。被害者は一切の操作をしておらず、攻撃されていること自体に気づかない点が最大の脅威である。

なぜLLMはプロンプトインジェクションを根本的に防げないのですか？

現行のLLMアーキテクチャは、システムプロンプト・ユーザー入力・外部データをすべて同一のコンテキストウィンドウで処理する「単一テキストストリーム」設計を採用している。SQLインジェクション対策のプリペアドステートメントのような「命令とデータの構造的分離」機構が存在せず、悪意あるデータが命令として解釈されることをアーキテクチャレベルで防止できない。

Microsoft 365 Copilotは安全に使えますか？

EchoLeak自体はMicrosoftがサーバーサイドパッチで修正済みである。しかし2026年にもSearchLeak（CVE-2026-42824、CVSS 9.1）など複数の脆弱性が発見されており、根本的な設計問題は継続している。導入組織はデータアクセス範囲の最小化、出力フィルタリング、CSP厳格化、継続的レッドチーミングの4層防御を実装した上で運用すべきである。

エージェント型AIはプロンプトインジェクションに対してさらに脆弱ですか？

78件の研究のメタ分析によれば、自動実行機能を持つエージェントシステムの攻撃成功率は66.9〜84.1%に達し、単純なチャットボットの50〜60%を大幅に上回る。エージェントはツール呼び出し、ファイル操作、API連携など強力な権限を持つため、プロンプトインジェクションが成功した場合の被害範囲が飛躍的に拡大する。

マルチストリームLLMアーキテクチャとは何ですか？

システムプロンプトとユーザー入力を物理的に分離されたセマンティックチャネルで処理し、ストリーム原点に基づいて命令階層を強制する実験的アーキテクチャである。2026年時点では研究段階だが、「単一テキストストリーム問題」に対する構造的解決策として注目されている。実用化には推論コスト増大や既存モデルとの互換性など課題が残る。

OWASP LLM Top 10 2025でプロンプトインジェクションの位置づけは？

OWASP LLM Top 10 2025において、プロンプトインジェクション（LLM01）は2年連続で第1位を維持している。本番AIデプロイメントの73%で確認され、2025年だけで90以上の組織が影響を受けた。2026年には観測された攻撃の55%を間接型（external data経由）が占めるまでに拡大している。

参考文献