間接プロンプトインジェクション（カンセツプロンプトインジェクション）
攻撃者がLLMが参照する外部データソース（Webページ・メール・PDF・データベース検索結果など）に悪意あるプロンプトを埋め込み、LLMの動作を間接的に操作する攻撃手法。RAGパイプラインやプラグインシステムが主な攻撃面となり、直接プロンプトインジェクションより検出が困難で影響範囲が広い。
間接プロンプトインジェクション
間接プロンプトインジェクション（Indirect Prompt Injection）とは、攻撃者がLLMと直接対話するのではなく、LLMが処理する外部データソース（Webページ・メール・PDF・RAG検索結果・API応答など）に悪意あるプロンプトを事前に埋め込み、LLMがそのデータを読み込んだ際に攻撃が発動する手法である。2023年2月にSaarland大学のKai Greshake et al.が論文「Not What You've Signed Up For」（arXiv:2302.12173）で体系的に定義し、以降LLMセキュリティの最重要課題の一つとなった。
攻撃メカニズムの詳細
間接プロンプトインジェクションの攻撃フローは以下の段階で構成される：
- ペイロード配置: 攻撃者がLLMがアクセス可能な外部ソースに攻撃テキストを埋め込む
- トリガー: 正規ユーザーがLLMアプリケーションを使用し、LLMが攻撃テキストを含むデータを取得する
- 実行: LLMが外部データ内の攻撃テキストを「命令」として解釈し、意図しない動作を行う
- 影響: データ漏洩・不正操作・マルウェア配布URLの提示など
直接プロンプトインジェクションとの根本的な違いは、攻撃者と被害者が異なることにある。攻撃者はペイロードを配置するだけで、実際の攻撃は正規ユーザーの通常操作を通じて発動する。これはXSS（Cross-Site Scripting）の攻撃モデルに類似している。
| 比較軸 | 直接プロンプトインジェクション | 間接プロンプトインジェクション |
|---|---|---|
| 攻撃者のアクセス | LLMへの直接入力 | 外部データソースへの書き込み |
| 攻撃の発動者 | 攻撃者本人 | 正規ユーザー（無自覚） |
| 検出難易度 | 比較的容易 | 困難（正規データに混入） |
| 影響範囲 | 攻撃者のセッション | 全ユーザーに波及可能 |
| 類似する従来型攻撃 | SQLインジェクション | Stored XSS |
| 攻撃のスケーラビリティ | 低（1対1） | 高（1対多） |
主要な攻撃ベクトル
間接プロンプトインジェクションの攻撃ベクトルは多岐にわたる。
RAGパイプライン汚染
RAG（Retrieval-Augmented Generation）システムでは、ベクトルデータベースに格納されたドキュメントチャンクがLLMのコンテキストに挿入される。攻撃者がインデックス対象のドキュメントに攻撃テキストを埋め込むと、そのチャンクが検索結果に含まれた際に攻撃が発動する。
具体的な攻撃シナリオ：
- 社内ナレッジベースのWikiページに不可視テキスト（白文字・CSSで非表示）として攻撃ペイロードを埋め込む
- PDF文書のメタデータフィールドに攻撃テキストを仕込む
- Webスクレイピング対象のページにHTMLコメントとして攻撃を埋め込む
メール・メッセージ経由
LLMがメール要約・自動応答を行うシステムでは、受信メールの本文に攻撃ペイロードを含めることで攻撃が成立する。2024年8月のSlack AI脆弱性では、Slackチャンネルのメッセージ経由で同様の攻撃が報告された。
Webブラウジング経由
LLMエージェントがWeb検索結果やWebページの内容を読み込む際、攻撃者が管理するWebページに攻撃テキストを配置する。HTMLのhiddenテキスト・コメント・metaタグなどに埋め込むことで、人間のユーザーには見えない形で攻撃が成立する。
プラグイン・ツール出力経由
LLMが外部APIやツールの出力を処理する際、API応答に攻撃テキストが含まれていれば攻撃が成立する。特にサードパーティのAPIを信頼して処理する設計は危険である。
実被害と研究事例
| 時期 | 事例 | 攻撃ベクトル | 影響 |
|---|---|---|---|
| 2023年3月 | Bing Chat Web検索経由攻撃 | Web検索結果 | システムプロンプト漏洩 |
| 2023年11月 | ChatGPT Pluginsへの攻撃実証 | プラグインAPI応答 | データ窃取の可能性 |
| 2024年3月 | Google Bard メール要約攻撃 | Gmail本文 | 個人情報の外部送信（PoC） |
| 2024年8月 | Slack AI API キー漏洩 | Slackメッセージ | プライベートチャンネルのデータ漏洩 |
| 2024年12月 | Microsoft Copilot RAG汚染 | SharePointドキュメント | 社内機密情報の漏洩（研究報告） |
| 2025年6月 | RAGベースチャットボットへの大規模攻撃 | Webスクレイピング | フィッシングURLの挿入 |
防御策と緩和手法
間接プロンプトインジェクションの防御は直接攻撃より困難であるが、以下の多層的アプローチが推奨される：
データ層の対策
- 外部データの信頼度スコアリング（ソースの信頼性評価）
- 取得データのサニタイズ（制御文字・不可視テキストの除去）
- ドキュメントチャンクの来歴（provenance）追跡
アーキテクチャ層の対策
- 権限分離: データ読み取り用LLMとアクション実行用LLMの分離
- サンドボックス: 外部データ処理時のツール呼び出し制限
- ヒューマンインザループ: 重要操作（送金・データ削除等）に人間の承認を要求
モデル層の対策
- Spotlightマーキング（Google DeepMind 2024年）: 外部データにデリミタを付与しLLMに「これはデータでありユーザー命令ではない」と認識させる
- Instruction Hierarchy（OpenAI 2024年）: システムプロンプト > ユーザープロンプト > 外部データの優先順位を強制
よくある質問（FAQ）
Q1: RAGシステムを使っている場合、間接プロンプトインジェクションは必ず対策が必要ですか？
はい。RAGシステムでは外部データがLLMのコンテキストに直接挿入されるため、間接プロンプトインジェクションの攻撃面が構造的に存在する。特にインデックス対象が外部ユーザーの投稿（Wiki・フォーラム・チケットなど）を含む場合は高リスクである。最低限、取得チャンクのサニタイズとLLMの権限最小化を実装すべきである。
Q2: CSSで非表示にしたテキストはLLMに見えるのですか？
見える。LLMはHTML/CSSのレンダリングを行わず、テキストとして全内容を処理する。display:none・visibility:hidden・白文字（color:#fff）・極小フォントサイズ・HTMLコメント（<!-- -->）など、人間には見えない手法で埋め込まれたテキストもLLMは通常通り読み取る。Webスクレイピング時のHTMLパース段階でこれらを除去することが対策の第一歩である。
Q3: 間接プロンプトインジェクションの検出に使える自動化ツールはありますか？
2026年時点で以下のツール・フレームワークが利用可能：Rebuff（LLMファイアウォール）、NeMo Guardrails（NVIDIA）、Lakera Guard（SaaS）、LLM Guard（オープンソース）。これらは入力・出力の両方向で攻撃パターンを検出するが、新規の攻撃パターンに対する検出率は限定的であり、定期的なルール更新と多層防御の組み合わせが必要である。