間接プロンプトインジェクションとは？攻撃経路や2026年事例、多層防御の実装まで徹底解説

間接プロンプトインジェクション（Indirect Prompt Injection）とは、Webページ・メール・PDF・MCPツール応答など、AIが処理する外部データに悪意ある命令を仕込み、AIがそれを指示と誤認して従ってしまう攻撃です。

2026年前半のOWASP GenAI Q1 Round-upでは8件の主要AI関連インシデントが整理され、LLM01（プロンプトインジェクション）が明示されているのはGrafanaGhost等に限られるものの、権限悪用・サプライチェーン・コード注入RCEと複合的に成立する全体像が示されました。OpenAIも「完全には解決されない可能性が高い」と表明しつつ対策投資を継続しています。

本記事では、攻撃経路の全体像、2026年の実例、CLI型コーディングエージェント/ブラウザエージェント/MCPエコシステムの固有リスク、主要防御アーキテクチャの比較と多層防御の実装まで、2026年11月時点の公式一次情報をもとに体系的に解説します。

間接プロンプトインジェクションとは——外部データ経由でLLMを乗っ取る攻撃

間接プロンプトインジェクション（Indirect Prompt Injection、IPI）とは、AIが処理する外部データ（Webページ・メール・PDF・MCPツール応答など）に悪意ある命令を仕込み、AIがそれを指示と誤認して実行してしまう攻撃です。攻撃者はAIのシステムや入力画面に直接触れる必要がなく、第三者コンテンツに命令を埋め込むだけで成立します。

LLMには「ユーザーの指示」と「ユーザーが読み込ませたデータ」を構造的に区別する仕組みがありません。システムプロンプトでどれだけ注意書きを増やしても、自然言語の命令文がデータ内に紛れ込めば、モデルはそれを従うべき指示として扱ってしまいます。

直接プロンプトインジェクションとの入口の違い

プロンプトインジェクションには直接型と間接型があり、違いは「命令がどこから入るか」という入口の位置にあります。

• 直接プロンプトインジェクション
  攻撃者が自分でチャット画面やAPIから命令を送り込む。
  システムプロンプトを開示させる、ジェイルブレイクする、禁止された情報を引き出すといった用途が典型。
  
  

• 間接プロンプトインジェクション
  攻撃者はAIを直接操作しない。
  Webページ・メール・ドキュメント・RAGソース・MCPツール応答など、AIが後から参照する外部データに命令を仕込む。
  AIがそれを読んだ瞬間に命令として実行してしまう。
  
  

両者の違いは「命令がどこから流入するか」という経路の違いに集約されます。直接型は攻撃者自身がチャット画面やAPIから命令を入力する形式で、典型用途はシステムプロンプト開示・ジェイルブレイク・禁止情報の引き出しです。

ただし直接型でも、エージェント経由なら接続先の機密データや第三者に影響が波及し得るため、「攻撃者自身のセッションに閉じる」とは言い切れません。

間接型はさらに難しく、社内のユーザー・顧客・開発者が善意で触った外部データ経由で発火し、エージェントが外部送信・ファイル操作・コード実行の権限を持っていれば現実世界のアクションにまで広がります。

プロンプトインジェクション全体の体系（直接・間接・マルチモーダルの3類型とLethal Trifectaの詳細）は、プロンプトインジェクションとは？攻撃3類型やLethal Trifecta、対策を徹底解説で整理しています。本記事はこのうち間接型にフォーカスし、攻撃経路・実例・防御の各論を深掘りします。

---

間接プロンプトインジェクションの6つの攻撃経路

間接プロンプトインジェクションの攻撃面は、AIエージェントが読み込むあらゆる外部データに広がります。本セクションでは、2026年に実際に悪用が確認された経路を6つに分類し、それぞれの典型的な埋め込み手口を整理します。

Cloud Security Allianceが2026年4月に公開したIPI分析レポートが引用するUnit 42の実測では、85.2%のケースでソーシャルエンジニアリング的な文脈偽装（権威偽装やルーチンタスク装い）が使われていたと報告されています。

視覚的隠蔽と併用されるケースも多く、経路を単独で潰す発想ではなく「どの経路から来ても止める」多層防御の前提として読んでください。

Webページに埋め込まれるHTML/CSS隠蔽命令

AIブラウザ・ブラウザエージェントがWebページを要約・閲覧する場面で最も頻出する経路です。攻撃者はページ内に人間の目には見えないテキストで命令を仕込みます。

Cloud Security Allianceの実測レポートでは、以下の手口が確認されています。

隠蔽手口	全ケースに占める割合
Visible plaintext（Web本文に平文として配置される注入）	37.8%
HTML属性（data-* 等）でのペイロード埋め込み	19.8%
CSSによる非表示（display: none・visibility: hidden）	16.9%
エンコーディング・難読化（XML/SVG・CDATA・Unicode tag）	残り

この経路の厄介さは、ユーザーが人間の目で開いてもほぼ気づけない点にあります。HTMLソース全体をそのままLLMに渡す実装のブラウザエージェントでは、本文と隠された命令の区別がモデル側に残りません（スクリーンショット経由で画面を解釈する実装では別の経路に化けます）。

メールと受信トレイ経由の命令

Microsoft 365 CopilotやGmail連携エージェントなど、受信メールを要約・ドラフト作成するAIが対象です。攻撃者は犠牲者が受信するメール本文・件名・ヘッダーに命令を埋め込みます。

Microsoft 365 CopilotのEchoLeak脆弱性（CVE-2025-32711）は、ユーザー操作を一切要さないゼロクリック型でこの経路から成立しました。

攻撃者が特殊な1通のメールを送り、Copilotがそれを読んだ時点でデータ外部送信が発動する仕組みです。社内のCopilot利用者が「特に何もしていない」のに情報が流出するため、検知と帰責が極めて難しい攻撃形態です。

PDF・ドキュメント・画像の中に潜ませる命令

ファイル要約・OCR・画像解析を担うエージェントが対象です。PDFの透明レイヤー、Wordのテキストボックス、画像のEXIFメタデータ、画像ピクセルに埋め込まれた視覚的指示まで、埋め込みポイントは多岐にわたります。

マルチモーダル対応エージェントが広がったことで、2026年版OWASPでは画像・音声・動画を跨ぐクロスモーダル攻撃も明示的にスコープに入りました。「ファイルを渡して要約してもらう」という業務動作が、そのままエージェント乗っ取りの入口になる構造です。

MCPサーバーのツール定義・応答に仕込まれる命令

MCP（Model Context Protocol）が開発現場で主流化した2026年後半、攻撃面として急浮上しているのがこの経路です。MCPサーバーが提供するツールdescriptionやツール呼び出しの戻り値に命令を仕込む「ツールポイズニング」が典型です。

米NSA AI Security Centerが2026年5月20日に公表したMCPセキュリティCSIでは、MCPの設計・実装・運用面のギャップ（シリアライゼーションリスク・信頼境界・エージェント誤用）が整理されています。

別の独立研究であるMCPTox系の7クライアント実験（arXiv:2603.22489）は、Claude Desktop・Claude Code・Cursor・Cline・Continue・Gemini CLI・Langflowでプロンプトインジェクションとツールポイズニング耐性を攻撃ごとにSafe/Partial/Unsafeで比較しており、クライアントごとに保護機構の差が大きいと報告しています。この経路はデータポイズニングの文脈でも扱われます。

ユーザー投稿・共有データ経由の命令

社内Wiki・Confluence・Salesforce・CRMレコード・共有Notionなど、複数ユーザーが書き込める社内データソースを経由する経路です。悪意ある外部者が直接書き込めなくても、善意のユーザーが外部のWebページをコピー&ペーストした時点で命令が社内の信頼境界内に入り込みます。

RAG構築時にベクトルDBのソースに制限をかけていないと、社内Wikiに貼られた1つのページがエージェント全体を汚染します。

RAGの情報源として一次公開情報を取り込む場面では特に注意が必要です。

Issue・コミット・コードコメントへの埋め込み

GitHub Issue・Pull Request本文・コミットメッセージ・README・パッケージ説明文など、開発フロー内に埋め込まれる経路です。CLI型コーディングエージェントがIssueやREADMEを読むとき、そこに紛れた命令が実行されます。

後述する「Clinejection」事例は、GitHub Issueのタイトル1行で検知元のStepSecurityが約4,000ダウンロードを報告しました。端末数と直接一致する指標ではありませんが、開発者視点では「自社の信頼できるリポジトリだから安全」が通用しない構造になっています。

---

2026年に公表された間接プロンプトインジェクション実例

攻撃経路を理解したうえで、2026年に実際に公表されたインシデントを時系列で整理します。本セクションのホーム論点は「IPIがPoCではなく operational threat へ移行した」事実と、その数値的根拠です。

OWASP GenAI Security Projectは2026年4月14日公開のQ1 Exploit Round-up Reportで、2026年1月1日〜4月11日の主要AI関連セキュリティインシデント8件を整理しています（Cloud Security Allianceの前述レポートはOWASPの整理を引用した二次整理）。

OWASP GenAIがまとめた2026年Q1の8件のインシデント

以下の表で、2026年1〜4月に公表された主要AI関連インシデントを整理しました。

8件のうちLLM01（プロンプトインジェクション）が明示されているのはGrafanaGhostで、Flowiseは古典的なコード注入によるRCE（LLM03）、Vertex AI "Double Agent" はデフォルト権限スコープ悪用（LLM06）、OpenClawのメール削除は過剰エージェンシー（LLM06）と、それぞれ異なる失敗モードが主因です。

公表日	インシデント名	主な分類	被害の中核
2026-02-23	OpenClaw inbox deletion	LLM05/LLM06	停止命令を無視したエージェントが利用者のメールを削除
2026-02-25	Mexican Government breach via Claude	LLM02/LLM06/LLM10	税務・有権者データ約150GBがAI補助侵入で流出
2026-03-20	Meta internal AI agent leak	LLM02/LLM05	社内AIエージェントの機密データに約2時間アクセス可能に
2026-03-31〜04-01	Vertex AI「Double Agent」	LLM02/LLM03/LLM06	デフォルト権限スコープを悪用した資格情報の窃取
2026-03-31〜04-02	Claude Code source map leak	LLM02/LLM03/LLM05	公開パッケージに約59.8MBのソースマップが混入
2026-04-03	Mercor/LiteLLM supply-chain breach	LLM02/LLM03/LLM04	AI採用サービスとLLM中継層の連鎖侵害
2026-04-07	Flowise CVE-2025-59528 active exploitation	LLM03/LLM05/LLM06	CustomMCP設定経由のJavaScriptコード注入RCE、約1万2,000〜1万5,000の露出インスタンス
2026-04-07	GrafanaGhost IPI	LLM01/LLM02/LLM05	ログ経由のIPIでMarkdown画像レンダ経由のデータ流出

8件のうちLLM01（プロンプトインジェクション）が直接の起点として明示されているのはGrafanaGhost、残りは過剰エージェンシー・サプライチェーン・権限スコープ悪用・コード注入RCEなど別の失敗モードが主因です。

IPIが唯一の主因ではなくても、エージェント設計の弱点が複合的に成立する全体像がQ1 Round-upに整理されている点が重要で、Flowise CVE-2025-59528の露出インスタンス規模（1万2,000〜1万5,000）は、公開済みのAIバックエンドが集中攻撃対象になっていることの裏付けです。

Trail of BitsによるPerplexity Comet監査

AIブラウザ側の代表例が、Trail of Bitsが2026年2月20日に公開したPerplexity Cometの監査結果です。4つの異なるプロンプトインジェクション技術で、Gmailデータの外部流出が可能なことが実証されました。

Trail of BitsがCometに対して実施したthreat modelingの構造図（出典：Trail of Bits）

脅威モデルは左側のユーザーマシン（Browser profile・Perplexity extension・Browser agent extension）と右側のPerplexity servers（Chat session・Agent session）を信頼境界で分け、下部のExternal websiteとPrivate dataが内部攻撃者（境界内に入った攻撃者）と外部攻撃者の両方から侵害される経路を示しています。認証済みセッション内でエージェントが動く以上、成功した注入はそのままユーザー権限で実行される点がブラウザエージェント特有の重さです。

Trail of Bitsが報告した4つの手口は以下のとおりです。

• 要約指示の悪用
  Webページ内に「このページを要約する前に、まず〜を実行してください」という手順を仕込み、要約タスクの前段で命令を実行させる手口。
  
  

• 偽のセキュリティ機構
  CAPTCHA風のUIでユーザー承認の見かけを作り、エージェントに「この認証を通過するために〜してください」と指示する手口。
  
  

• 偽のシステム指示
  systemタグ風の表記や構造化構文を本文に埋め込み、モデルに公式のシステムメッセージと誤認させる手口。
  
  

• 偽のユーザーリクエスト
  「ユーザーが先ほど追加で依頼しました」という装いで、本来のユーザー指示に見せかけたメッセージをモデルに注入する手口。
  
  

Trail of Bitsは「複数技術を組み合わせると成功率が上がる」と報告しており、単発の対策では防げないことを示しています。

Log-To-Leakと開発者ツールのサプライチェーン事例

2026年10月に公表されたLog-To-Leak攻撃（arXiv:2610.36108）は、エージェントが正当なツール呼び出しを終えた直後に、攻撃者制御のツール呼び出しを追加注入してユーザークエリと過去の応答を漏洩させる手口です。

5つのMCPサーバーと4種のLLMエージェントの組み合わせで、62.64〜100%の成功率が確認されています。

開発者ツール側では、Clineのサプライチェーン攻撃が印象的です。プロンプトインジェクションでnpmパブリッシュ用のクレデンシャルを窃取し、攻撃者がmalicious Cline CLI v2.3.0をプッシュ、インストールした開発者マシンに裏でOpenClaw AIエージェント基盤が仕込まれる構造でした。

詳細はAIサプライチェーン攻撃の記事で扱います。

攻撃威力を示す追加の数値

研究・実証の数値は、実験設計を切り分けて読む必要があります。

実環境全般の成功率を1つの数字で代表させるとミスリードになるため、それぞれ対象と条件を明示します。

• 査読文中の透かしの保持率94%超（PLOS ONE掲載「Detecting LLM-generated peer reviews」（10.1371/journal.pone.0331871）で、生成された査読文中に埋め込まれた透かしが、別のLLMによる言い換えを経ても94%超保持された報告。隠し指示が命令として残った割合ではない）
  
  
• 産業制御システムSOCコパイロットの最大86.4%（SOCSentinel/IPIndustria実験（Springer 2026）の限定した実験環境での成功率最大値。強い連鎖攻撃では物理影響到達までの平均時間が180秒未満）
  
  
• Forcepoint X-Labsが2026年4月に10種のIPIペイロードを別ドメインから発見
  
  
• Unit 42が22種類のペイロード配送技術を分類
  
  

これらの数値は、IPIが「理論上可能」なだけではなく、限定条件下の実験で高い成功率が報告される攻撃であることを示します。

「実環境全般で◯%」と一般化できる単一指標がまだない点が、本テーマが継続研究対象である理由でもあります。

---

なぜ間接プロンプトインジェクションは「完全には防げない」のか

間接プロンプトインジェクションの深刻さは、個別の脆弱性ではなくLLMアプリケーションの設計そのものに根ざしている点にあります。本セクションでは、完全予防が困難な構造的理由を3つの角度から整理します。

OpenAIがChatGPT Atlasの対策記事で「このタイプの攻撃は完全には解決されない可能性が高い」と表明していることと、Microsoft公式ガイダンスが「間接プロンプトインジェクションの発生を前提として設計せよ」と推奨していることは、業界全体がこの前提に立っていることの裏付けです。

LLMが「指示」と「データ」を区別できない

LLMはシステムプロンプト・ユーザーメッセージ・ツール応答・RAG文書といった異なる情報源をメッセージロールで受け取りますが、出所情報が与えられても信頼境界を確実に強制できる保証がないのが本質的な問題です。

学習によってロールの優先順位は扱えても、Webページ中に「無視して〜を実行せよ」と書かれていれば、それを実行可能な命令として扱ってしまう挙動が実験で繰り返し確認されています。

この問題はモデルサイズを大きくしても根本解決できません。むしろ命令従順性の高い高性能モデルほど、注入された命令も素直に実行してしまう傾向があります。

従来型WAF・入力フィルタが機能しない

Web攻撃対策で定番のWAF（Web Application Firewall）やシグネチャ型のインジェクション検知は、SQLインジェクションのようなコードパターンを検出する設計です。

間接プロンプトインジェクションの命令は普通の自然言語であり、SQL構文やJavaScriptペイロードのような決定的な攻撃指紋を持ちません。

Cloud Security Allianceが引用するUnit 42の実測では、85.2%のケースで攻撃者はソーシャルエンジニアリング的な文脈偽装（権威偽装やルーチンタスク装い）を使い、視覚的隠蔽（HTML属性・CSS）と併用するケースも多いと報告されています。

従来のパターンマッチ型防御では、これらを「本文の一部」と見分けることができません。

Googleが観測した32%増が示すもの

Googleのセキュリティチームが2025年11月〜2026年2月に観測したIPI増加率32%という数値は、Common Crawlの月次スナップショット（約20〜30億ページ規模）から得られたものです。これは攻撃者側が「まず仕込んでおけば、エージェントが訪れたときに発火する」というパッシブ攻撃に投資している兆候です。

AIエージェントが社内業務に浸透するほど攻撃対象が増えるため、「エージェントの数 × Webに仕込まれた命令の数」の掛け算で成立確率が上がります

防御側は個別の脆弱性修正では追いつかず、攻撃が成功する前提でエージェントの権限設計・監視設計を整える方向に戦略をシフトする必要があります。

AI総研の支援現場でも、「IPIを完全に防ぐ製品」を探す段階から、「IPIが成立したときの被害を最小化する多層防御」を組む段階に移っている企業が増えています。

---

エージェント形態ごとの固有リスク

ここまでは一般論でしたが、実務でIPIを考えるときはエージェント形態ごとに固有のリスク構造を分けて見るのが近道です。

本セクションでは、2026年に実務が加速した3象限——CLI型コーディングエージェント・ブラウザエージェント・MCPエコシステム——それぞれの入口と被害パターンを整理します。

CLI型コーディングエージェント——WebFetch経由と設定ファイル経由

Claude Code、Codex CLI、Cursor、Cline、Aiderといった開発者PCで動くコーディングエージェントは、業務上外部コンテンツを頻繁に読むことが前提です。

README・GitHub Issue・パッケージ説明・WebFetchで取得した技術ブログ・Stack Overflow回答など、信頼境界の外から入る情報が実行権限と地続きになります。

2026年には複数のインシデント・研究報告が公表されました。

• Claude Code CLIの3つのCVE申請履歴（CVE-2026-35020/35021/35022）
  2026年前半にコマンドインジェクション系CVEとして申請されましたが、いずれも2026年5月29日にREJECTEDされ、現時点で正式な脆弱性認定には至っていません。
  
  履歴として押さえておく価値はありますが、「未修正の脆弱性」としての引用は不適切です。
  
  

• Codex CLIのWebFetch経由RCE
  Cymulateの公表によれば、Web検索結果に仕込まれたプロンプトインジェクションからWindows上のバイナリハイジャックまでチェーンし、リモートコード実行に到達する手順が実証されました。
  
  

• Clinejection（GitHub Issueタイトル1行）
  GitHub Issueのタイトル1行に仕込まれた命令で、StepSecurityが検知した時点で約4,000ダウンロードが報告されています。端末数と直接一致する指標ではない点に注意が必要です。
  
  

• コーディングエージェント横断の論文評価
  エージェント型コーディングアシスタント向けのSoK論文「Prompt Injection Attacks on Agentic Coding Assistants（arXiv:2601.17548）」のTable IV総合評価では、Cursorが「Critical」、Claude Codeが「Low」等の総合評価として整理されています（評価範囲が限定されたスナップショットであり、現在の製品選定を一般化する根拠には使えない点に注意）。
  
  

関連のコード脆弱性スキャン情報はClaude Code Securityで、Cursor OriginのようなGit forgeエージェントの登場文脈も合わせて参照できます。いずれもIPI視点では攻撃面の拡張として読むべきです。

ブラウザエージェント——認証済みセッション内での実行

Perplexity Comet・Claude in Chrome・Manus Browser Operatorといったブラウザエージェントは、ユーザーの認証済みセッション内で動作します（なおOpenAIのChatGPT Atlasは同社の案内で公開終了・更新終了が明示されているため、現行の運用候補からは外して扱います）。

Perplexity Cometの脆弱性が示すように、1枚のWebページに仕込まれた命令が、そのままGmail・Google Drive・SNSアカウントへのアクセスに化けます。

OpenAI公式も過去のAtlas対策記事で「完全には解決されない可能性が高い」と表明しつつ対策投資を継続していた経緯があり、ブラウザエージェントの運用は権限分離と限定運用が前提になります。

具体的には、エージェント用に利用するブラウザ（Chromeなら専用プロファイル、Cometのような独立ブラウザならCometの専用プロファイル機能）を日常用途から切り離し、金融・業務システム・個人情報へのログインを分けるのが現実的な打ち手です。

MCPエコシステム——ツール定義と戻り値の両方が攻撃面

MCPサーバーは「ツールの定義（description・引数スキーマ）」と「ツール呼び出しの戻り値」の両方がクライアントのLLMコンテキストに流れ込みます。悪意あるMCPサーバーを一度接続してしまうと、description経由でもレスポンス経由でも命令注入が可能になります。

2026年にはCVE-2026-13341（Kong Konnect MCP）が間接プロンプトインジェクションとして公表されたほか、MCPTox（arXiv:2508.14925）では実MCPサーバー群へのツールポイズニング耐性が広く不足していることが示されました。

開発者が「野良MCPサーバー」を気軽に追加する運用は、MCPエコシステム全体の脆弱性になります。MCP提供側の統制についてはAIエージェントのセキュリティリスクと対策で深掘りしています。

---

間接プロンプトインジェクション対策の主要防御アーキテクチャ

攻撃経路が広い以上、防御も単一手法では成立しません。
本セクションでは、2026年時点で主要ベンダーが提供する防御アーキテクチャを設計思想別に整理し、それぞれが得意とする局面を明示します。

重要なのは、どれか1つを選ぶのではなく、確率的検知・決定論的統制・データ境界・運用統制の4系統を組み合わせる発想です。

AIガードレールの総論として捉えると見通しが立ちます。

Microsoft Prompt Shields——確率的検知の主要層

Microsoft Learnの公式ガイダンスによれば、Prompt ShieldsはAzure AI Content Safetyの一部として、入力プロンプトと参照コンテンツを解析してインジェクション試行を検出します。

遮断・置換・警告といった処理の判断は呼び出し側アプリケーションの実装に任されるため、製品単体で「サニタイズまで完結する」訳ではありません。defense-in-depthの第一層として位置づけられており、Microsoft 365 Copilot・Azure OpenAI Service・Azure AI Foundry上のエージェントに統合可能です。

確率的検知のため完全な防御ではありませんが、既知パターンへの追従速度が速く、単一アプリへの導入ハードルが低いのが強みです。

Google DeepMind CaMeL——決定論的ケーパビリティ制御

CaMeL（CApabilities for MachinE Learning）は、2025年3月にDeepMind発表論文で公開された設計思想で、「LLMに入ってくる信頼できないデータが、実行可能なプログラムフローに影響しない」ことを設計レベルで保証します。

エージェント実行の制御フロー（指示分解）とデータフロー（外部データ流入）がどちらもIPIで侵害され得るという問題構造を示した概念図（出典：Defeating Prompt Injections by Design (arXiv:2503.18813)）

上の図は、CaMeLの防御アーキテクチャそのものではなく、CaMeLが解こうとしている問題を示す概念図です。
「Can you send Bob the document he requested in our last meeting?」というユーザー指示を、①直近の議事録ノートを探す、②メールアドレスと文書名を抽出する、③クラウドストレージから文書を取得する、④Bobにメール送信する の4ステップに分解する過程で、制御フロー（どのツールをどの順で呼ぶか）とデータフロー（議事録本文やドライブ上のメタデータ）のいずれも注入で侵害され得ることが示されています。

CaMeLの防御の肝は、この両方を設計レベルで分離することで、ユーザー指示をP-LLMが制限付きPythonサブセットに変換し、信頼できないデータは常に純粋な「値」として扱って制御フローの分岐判断には使わない、という設計に落ちています。

AgentDojoベンチマークではセキュリティ保証付きで77%のタスクを解決（防御なしで84%）し、実用性能と決定論的安全性を両立しました。決定論的な安全性が欲しい局面では第一候補になります。

Anthropic Constitutional Classifiers++——Jailbreak耐性の深掘り

Anthropicが2026年1月9日に公開したNext-generation Constitutional Classifiersは、入力と出力の両方に分類器カスケードを組み、万能ジェイルブレイクを狙う攻撃を抑え込む設計です。2025年12月1日〜2026年1月1日のSonnet 4.5本番トラフィックに対して1か月間シャドウ評価が実施され、無害クエリへの拒否率0.05%、Opus 4.0適用換算で計算オーバーヘッド約1%という性能が報告されています。

1,700時間超の人間レッドチーム（19.8万回の攻撃試行）で検出された高リスクの脆弱性は1件、universal jailbreakはゼロでした。

主眼はjailbreak（直接型・システムプロンプト破り）で、間接プロンプトインジェクションそのものを狙った設計ではない点は注意が必要です。公式が示しているのはシャドウ評価の結果までで、全モデルへの本番遮断運用としての展開範囲や料金内包については明示されていません。

Spotlighting——データマーキングで注入の視認性を上げる

Spotlightingは、外部データに特殊なマーカー（データタグ・エンコーディング）を付与することで、モデル側がユーザー指示と外部データを区別しやすくする手法です。

Microsoft Researchの2024年論文が発端で、Microsoft Prompt Shieldsのドキュメントガードにも実装されています。

実装は比較的軽く、既存プロンプト設計に差し込める点が強みです。ただし「モデルが完全にマーカー境界を尊重する保証」がないため、単体では過信禁物の補助層です。

IFC（Information Flow Control）——情報の流れを制御する

IFCの研究論文が示すように、情報フロー制御は「信頼できないデータから来た指示が、信頼が必要な出力・アクションに到達しない」ことをメタデータタグとポリシーで強制するアプローチです。CaMeLと設計思想が近く、デフォルト拒否・明示許可の方向性を持ちます。

MicrosoftはIFCをdefense-in-depth戦略の重要コンポーネントに挙げており、金融・医療など監査要件が強い業界での採用が進む見込みです。

製品比較と料金目安

以下の表で、2026年11月時点の主要対策製品の位置づけと料金目安を整理しました。提供形態やリージョン対応は製品ごとに大きく異なるため、価格条件は各製品の公式ページで最新値を確認してください。

製品	設計思想	提供形態	料金目安
Microsoft Prompt Shields	確率的検知＋Spotlighting	Azure AI Content Safety（Azureリージョン単位の従量課金）	公式pricing参照
Google DeepMind CaMeL	決定論的ケーパビリティ	OSS（google-research/camel-prompt-injection）	無償（自社運用コストのみ）
Anthropic Next-gen Constitutional Classifiers	入出力分類器カスケード	Claudeモデル統合（Sonnet 4.5でシャドウ評価実施済み）	公式では明示なし
Check Point AI Guardrails（旧Lakera Guard）	API型ガードレール	SaaS＋Self-hosted	Enterpriseは個別見積り
NVIDIA NeMo Guardrails	OSS実装フレームワーク	OSS	無償（自社運用コストのみ）
Meta LlamaFirewall（PurpleLlama傘下）	OSS防御フレームワーク（PromptGuard 2・AlignmentCheck・CodeShieldの3コンポーネントで構成）	OSS	無償（モデル推論コストのみ）

料金の読み解きとしては、「決定論的安全性が必要な社内エージェント」にはCaMeL・IFCのOSSベース、「Microsoft 365 Copilot統合済みの既存環境」はPrompt Shields、「汎用SaaSで速く入れたい」ならCheck Point AI Guardrails（旧Lakera Guard）が現実的な第一候補です。

AnthropicのConstitutional ClassifiersはClaudeモデル利用者が間接的に恩恵を受ける位置づけで、単独製品として契約する対象ではありません。

---

間接プロンプトインジェクション対策の多層防御レイヤー

防御アーキテクチャを個別に理解したうえで、実装時に組むべきレイヤーを整理します。

本セクションのホーム論点は、Microsoftの公式defense-in-depthガイダンスが示す10の実装要素を、現場で組みやすい6レイヤーに再編することです。

入力層——Prompt ShieldsとSpotlightingで注入試行を検出

ユーザーからの入力プロンプトと、エージェントが引き込む外部コンテンツを解析し、インジェクション試行を検出・サニタイズする層です。Microsoft Prompt Shields・Lakera Guard・OSS実装のNeMo Guardrails等が該当します。

この層は確率的なため、素通り率をゼロにはできません。ただし入口での検出は後続レイヤーの負担を軽くする効果があるため、defense-in-depthでは最初のゲートとして置くのが定石です。

添付・外部参照データ層——信頼境界の明示とIFC

RAG・Web取得・ファイルアップロード・MCPツール応答など、外部から流入するデータに「出所タグ」を付与する層です。情報フロー制御（IFC）の実装で、信頼レベルの違うコンテキストが相互汚染しないように隔離します。

実装の中核は、各データに信頼レベルのラベルを付与して追跡・伝播させ、実行時にポリシーで強制することにあります。プロンプト設計レベルで「このブロックは外部データ、このブロックはユーザー指示」と構造化表示するのは補助的な手段で、IFC本体は実行基盤・インタプリタ側で強制される点を混同しないことが重要です。Spotlightingによるマーキングを併用すると、モデル側の尊重度が上がります。

ツール実行層——Tool chain分析とPlan drift検出

エージェントがツール連鎖を組むとき、途中で計画が本来のタスクから逸脱していないかを監視する層です。Microsoftガイダンスで言う「Plan drift detection」と「Tool chain analysis」が該当します。別のエージェント（Critic agent）が計画を監査する構成や、Azure AI Foundryのプレビュー機能「Task Adherence」のように、ツール操作とユーザー意図のずれを検出して遮断や人間確認に繋ぐシグナルを提供する実装もあります。

Log-To-Leak型の「正規のツール呼び出しの直後に攻撃者のツール呼び出しを割り込ませる」手口は、ホスト側の認可や送信制限と組み合わせつつ、この層で計画の逸脱として検出・遮断するのが実効的です。

出力層——スキーマ強制と外部送信経路の制限

モデル出力をJSONスキーマで強制し、構造的に逸脱したレスポンスを拒否する層です。OWASP Top 10 for LLM 2026では出力検証と外部送信経路の制限を対策候補として挙げていますが、同時に「形式に適合した悪意ある内容は通り得る」とも明記されており、スキーマ強制だけに依存するのは不十分です。

加えて、出力に含まれる外部URL・リダイレクト先・画像マークダウンのようなexfiltrationチャネルを制限することが、EchoLeak系のゼロクリック流出を抑える鍵になります。

権限層——最小権限と短命権限

エージェントに渡す権限をタスクに必要な最小単位まで絞り、かつタスクごとに発行・破棄する短命トークンで与える層です。

Microsoftガイダンスは「Non-Human Identity（NHI）」としてエージェント専用アカウントの運用も推奨しています。

この層は「IPIが成立しても被害範囲を局所化する」ことに本質的に効きます。最小権限が徹底されていれば、エージェントが命令に従って「全顧客データを削除」という指示を受け取っても、そもそも削除権限を持たないため実行不能です。

監視層——不変監査ログとHITLによる最終承認

エージェントの意思決定・ツール呼び出し・外部送信をすべて不変ログに記録し、取り返しのつかない操作（決済・メール送信・ファイル削除・契約変更）はHuman-in-the-Loop（HITL）で人間の最終承認を挟む層です。

「Agents Rule of Two」——外部文書を読む・機密データにアクセスできる・外部送信や操作ができる の3条件を同時に持たせない——は、監視層とセットで考えるべき運用原則です。実務では「3条件のうち1つを削る」より「HITLで最後に人間を挟む」ほうが現実的な打ち手になります。

---

ケース別対策の優先順位——RAG・ブラウザ・社内Bot・CLIコーディング・MCP提供側

多層防御レイヤーを全部一度に実装するのは現実的ではありません。本セクションでは、エージェント形態別に最優先で入れるべき対策を整理します。AI総研の支援現場で採用しているケース別の判断軸に沿って、SIerの立場で推奨順を示します。

RAG構築時の優先順位

RAGシステムでは、ベクトルDBに取り込むドキュメントそのものが攻撃面です。以下の順で対策を入れるのが実務的です。

まずソース制限として、外部Webの無審査取り込みを禁止し、社内Wiki・SharePoint等の内部ソースだけに限定します。

次にインジェスト時のサニタイズとして、HTML/CSS隠蔽・制御文字・base64ペイロードを事前にスクリーニングします。そして検索結果の権限フィルタとして、ユーザーの役職・部署に応じて検索可能ドキュメントを絞ります。

社内チャットボット・AIアシスタント運用の文脈では、取り込んだドキュメントが誰でも閲覧可能だった場合に「社内Wikiに貼られた1つの悪意ある外部ページがBot全体を汚染」する構造的リスクが残る点に注意が必要です。

ブラウザエージェント運用の優先順位

Perplexity Comet・Claude in Chromeなどのブラウザエージェントを業務で使うなら、利用するブラウザの専用プロファイルを業務分離し、金融・業務システムから切り離すのが最優先です（Chromeベースなら専用プロファイル、Cometのような独立ブラウザならCometの専用プロファイルで分離）。

OpenAI公式も完全解決を困難としている以上、権限分離が最後の砦になります。

高リスク操作（決済・外部送信・SNSへの投稿・個人情報編集）は必ずユーザーが手で実行するルールにし、ブラウザエージェントには閲覧・要約・下書き作成までを任せる運用が現実的です。

社内チャットボット・AIアシスタントの優先順位

社内で広く使うチャットボットでは、会話ごとに短命権限を発行する仕組みと監査ログの不変保管を優先してください。社内で誰かが外部Webページをコピペした瞬間、Bot全体が汚染リスクを抱えるため、個別会話で権限が漏れても組織横断では止まる構造が必要です。

総務省のAIセキュリティガイドラインはプロンプトインジェクション・DoS対策の要点を整理しており、国内企業のコンプライアンス文脈で参照する一次情報として押さえておく価値があります。

CLI型コーディングエージェントの優先順位

Claude Code・Codex CLI・Cursor・Clineを業務利用する開発者は、WebFetchの許可リスト運用・MCPサーバーの信頼評価・設定ファイル経由の自動実行を無効化の3点が最優先です。

自動実行の便利さを維持したまま、取り込む外部データを信頼できるドメインに絞る運用が落としどころです。

arXiv:2601.17548のTable IV総合評価でCursorが「Critical」・Claude Codeが「Low」等と整理されたのは特定スナップショット時点の結果であり、現在の製品選定を一般化する根拠には使えません。

各エージェントのIPI耐性は実装更新で変動するため、導入時点のベンダー公表情報と自社の脅威モデルで都度評価するのが実務の軸です。

MCPサーバー提供側の優先順位

自社がMCPサーバーを公開する側なら、ツールdescriptionと戻り値の両方に対して、クライアント側が安全に取り扱えるメタデータを明示するのが最優先です。

MCPのセキュリティ文脈では、認証不備・権限過大・悪意あるサーバーの3リスクに対する対策が必要になります。

提供側でできるのは「クライアントが信頼境界を保ちやすくする」ところまでで、最終的な実行判断はクライアント側のエージェント設計に依存します。クライアント開発者と公式ドキュメントで信頼モデルを共有しておくことが、エコシステム全体の堅牢性につながります。

---

請求書を読む業務エージェントは、Rule of Twoの3条件を分けて持たせる

Agents Rule of Twoの3条件は、経理の業務エージェントで一度にそろいやすい組み合わせです。取引先から届く請求書のPDFを読み、支払データに触れ、会計への計上まで1つのエージェントに任せると、PDFに紛れた1文が計上の操作に届きかねません。読む役割と書き込む役割を分け、戻せない操作の手前に人の確認を置いておくことが、IPIが成立する前提での備えになります。

この分担を最初から組めるのが、業務ごとに専用のAgentをそろえてつなぐ、AI Agent内製化の仕組みです。AI総合研究所のAI Agent Hubでは、請求書の読み取り、承認ルートの判定、基幹システムへの書き込みを、別々のAgentが受け持ちます。

• 外部の書類を読む段に、書き込みの権限を持たせない
  PDFから値を読み取るAI-OCR Agentと、基幹システムへ入力する自動入力Agentを分けておくことで、文面に紛れた命令が読み取りの段から直接書き込みへ進む経路を残さずに済みます。
  
  
• 戻せない操作は、担当者の返事を待って進める
  支払や計上の手前でフロー判定Agentが承認者を決めてTeamsに通知を送り、承認か差し戻しの返事があるまで処理を止めておきます。
  
  
• 命令を紛れ込ませた書類で、使い始める前に試す
  サンドボックス環境なら実際の基幹システムを動かさずに済むため、隠し文字を入れた試験用の請求書を流し、値だけが抜き出されるかを事前に確かめておけます。

AI総合研究所の専任チームが、請求書や経費の処理で外部の書類を受け取る段を洗い出し、3条件がそろわない分担を組むところまで支援します。

---

まとめ

本記事では、間接プロンプトインジェクションを「AIが処理する外部データに命令を仕込み、AIがそれを指示と取り違えて実行してしまう攻撃」として整理し、攻撃経路・公表事例・完全には防げない理由・エージェント形態別のリスク・防御の設計思想・多層防御の組み方・ケースごとの対策の優先順位を解説しました。

2026年11月時点で押さえておくべきポイントは次の3つです。

• LLMは指示とデータを構造的に区別できないため、ふつうの文章で書かれた命令はWAFやシグネチャ型の検知に引っかからず、完全に防ぐ手段はまだない
• MCPではツールの定義と戻り値の両方が命令の入口になり、出どころを確かめずにサーバーを追加する運用が、エコシステム全体の弱点になる
• 防御は単独の製品に頼らず、性質の違う手法を重ねて組み、決定論的な安全性が要る社内エージェントにはCaMeLやIFCのような設計が合う
  
  

社内文書をRAGで参照させる場合、AI総合研究所の支援では、対策を入れる順番が決まっています。

まずは、RAGに入れるソースを社内Wikiなどの内部の情報源に限り、外部Webを審査なしで取り込む運用を止めます。
続いて、取り込む時点でHTMLやCSSで隠した記述や制御文字をふるい落とし、検索結果には部署や役職に応じた権限のフィルタをかけます。

入口の検知を通ってしまった命令に備えて、外部URLや画像の埋め込みといった持ち出しの経路を出口で絞っておくと、ゼロクリック型の流出に歯止めがかかります。

間接プロンプトインジェクションは、外のデータをエージェントに読ませる限り付いて回るため、導入を決める段階で設計に織り込みたい脅威です。