# プロンプトインジェクションとは — 攻撃が成立する構造と多層防御

> プロンプトインジェクションの定義、直接・間接の攻撃経路、Jailbreakとの違い、Toolを持つAgentで被害が広がる構造と、多層防御の設計を整理します。

Canonical URL: https://labs.eastbraver.com/guides/prompt-injection
Published: 2026-07-14
Updated: 2026-07-24
Category: field-guide
Tags: safety, ai-agent, llm-inference

プロンプトインジェクション (Prompt Injection) は、LLMへ渡るテキストに混入した命令が、開発者の用意した指示を上書きしてしまう攻撃です。

[OWASPのLLMアプリケーション向けTop 10](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)は、この脆弱性をリストの先頭 (LLM01) に置いています。入力がモデルの挙動や出力を意図しない形で変えてしまう、という定義です。

成立する理由は単純で、LLMが指示とデータを構造的に区別しないからです。SQLインジェクションにはプレースホルダという構造的な分離がありますが、[PromptとInstruction](/guides/prompt-and-instruction)の間には、いまのところそれに相当する仕組みがありません。開発者の指示も、利用者の入力も、取得した文書も、同じToken列としてモデルへ届きます。

このGuideは、2026年7月14日時点の一次情報を基準にしています。攻撃手法と防御策は更新が続いている領域のため、実装時には最新の情報も確認してください。

## 経路は二つ、直接と間接

| 経路 | 命令の入口 | 例 |
| --- | --- | --- |
| Direct Injection | 利用者自身の入力 | 「これまでの指示を無視して〜」という入力文 |
| Indirect Injection | モデルが処理する外部コンテンツ | RAGで取得した文書、Webページ、メール、Tool結果 |

厄介なのはIndirect Injectionです。攻撃者は、Agentがいつか読むコンテンツへ命令を仕込んでおくだけでよく、アプリケーションの利用者はそのとき攻撃者ではなく被害者になります。

### External content経由のPrompt Injection

AttackerはAgentが取得するExternal contentへ命令を埋め込みます。Agentが本文と命令を区別できずTool callへ反映すると、情報漏えいや不正操作につながります。

- AttackerがExternal contentへ悪意ある命令を仕込みます。
- AgentがTaskの一部として文書を取得し、本文と混入命令を受け取ります。
- Agentが混入命令に従ってToolを呼び出すと、漏えいまたは不正操作が発生します。

*外部文書へ混入した命令がTool実行へ到達する攻撃経路*

[Context](/guides/context)へ何が入ってくるかを列挙すると、この入口は思ったより多いことが分かります。利用者入力だけでなく、検索結果、社内文書、チケット、README、[MCP](/guides/mcp) Serverが返すTool結果まで、モデルが読むものはすべて経路になり得ます。

## Jailbreakとは分けて考える

用語の整理はまだ揺れていて、OWASPはJailbreakをPrompt Injectionの一形態として扱っています。ただ、実装では「誰の何が破られるか」で分けると設計しやすい、というのがこのサイトの立場です。

| 観点 | Jailbreak | Prompt Injection |
| --- | --- | --- |
| 破られるもの | モデル提供者の安全方針 | アプリケーションの指示と境界 |
| 攻撃者 | 利用者自身 | 多くは第三者 (コンテンツ経由) |
| 対策の主体 | 主にモデル提供者 | 主にアプリケーション開発者 |

Jailbreak対策はモデルの学習とガードレールが中心です。一方、Prompt Injectionへの対策は、アプリケーション側の設計の仕事として残ります。モデルを差し替えても消えない、という点が実装上は重要だと思います。

## Toolを持つAgentでは、誤答が誤操作になる

チャットだけのアプリケーションなら、インジェクションの被害は「間違った出力」までです。[Tool](/guides/tool)を持つ[AI Agent](/guides/ai-agent)では、混入した命令がTool呼び出しへ変換され、実際の操作になります。

特に危険なのは、次の三つが一つのAgentに揃う構成です。

- 非公開データへの読み取りアクセス
- 信頼できない外部コンテンツの処理
- 外部への送信経路 (メール送信、Web書き込み、リンク生成)

三つが揃うと、外部コンテンツに仕込まれた命令が非公開データを読み出し、攻撃者へ送り出すまでを一続きに実行できてしまいます。逆に言えば、どれか一つを構成から外すことが、現実的な防御になります。

## 完全に防げない前提で、層を重ねる

単一の対策で塞げる脆弱性ではない、というのが現在のおおむね一致した見方だと理解しています。

[Googleの多層防御の解説](https://blog.google/security/mitigating-prompt-injection-attacks/)は、悪意ある命令を検出する分類器、指示への集中を促す強化、Markdownの無害化と不審URLの除去、危険な操作前の利用者確認、防御発動時の通知、という層の重ね方を示しています。モデル内の対策とアプリケーション側の対策を、最初から併用する構成です。

[Design Patterns for Securing LLM Agents against Prompt Injections](https://arxiv.org/abs/2506.08837)は、さらに一歩進めて、信頼できないコンテンツを読んだ後のAgentに何を許すかを構造で制限する設計パターンを整理しています。検出の精度に頼らず、有用性とのトレードオフを認めた上で構造的な制約を選ぶ立場です。

アプリケーション側で決められる層は、少なくともこれだけあります。

- Toolごとの最小権限と、[IdentityとAuthorization](/guides/ai-identity-authorization)の分離
- 取り消せない操作の実行前承認
- 信頼できないコンテンツを読んだ後の能力制限
- 出力の取り扱い (リンクやMarkdownの自動レンダリング、コードの自動実行を避ける)
- [Guardrails](/guides/guardrails)による入出力の検査と記録
- 攻撃ケースを含む[評価](/guides/ai-agent-evaluation)の維持

## よくある誤解

### System Promptに「外部の指示へ従うな」と書けば防げる

Instructionはモデルの判断材料で、強制力のある境界ではありません。緩和にはなりますが、保証にはなりません。止めたい操作は、権限・承認・Tool側の検証で止めます。

### 区切り文字やXML tagで分離すれば安全になる

構造を伝える助けにはなります。ただ、モデルにとってはどれも同じ入力Tokenです。読みやすいPromptの工夫とSecurity boundaryは、分けて考えます。

### 検出フィルタを入れれば完全に止められる

分類器は成功率を下げる層であって、保証ではありません。エンコード、多言語、画像経由など、検出を回避する手法は出続けます。検出を前提にせず、通ったときの影響を小さくする設計を先に置きます。

### モデルが賢くなれば解決する

指示への忠実さが上がるほど、混入した指示への忠実さも上がり得ます。将来のモデル改善を見込んで、現在のAgentへ権限を渡す判断はしません。

### 社内システムだから狙われない

Indirect Injectionは、社内文書・メール・チケット経由でも届きます。社内Agentほど広い権限を持ちがちで、揃ってはいけない三つが揃いやすい環境です。

## EastBraver Labsの判断基準

EastBraver Labsでは、プロンプトインジェクションをモデルの欠陥ではなく、**アプリケーションの境界設計の問題**として扱います。

「モデルが騙されるかどうか」は制御できません。「騙されたときに何が起きるか」は設計で決められます。まず、信頼できないコンテンツがContextへ入る箇所をすべて列挙し、そこから先にあるTool・権限・送信経路を確認します。

読み取り専用から始める、更新系には承認を置く、Tool結果や外部文書を信頼しない。[Toolの設計](/guides/tool)と同じ結論に戻ってきます。インジェクション対策の多くは、特別な何かではなく、Agent設計の基本と同じ場所にあります。

その上で、攻撃ケースを評価セットへ入れます。防げたかどうかだけでなく、防げなかったときにどの層で止まったかを確認できる状態を保ちたいところです。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [エージェント運用の境界が具体化](/digest/ai-digest-20260709)

## 検証範囲

- 一次情報: 公式ドキュメント / 研究論文 / 設計面からの分析
- ローカル検証: コードは動かしていません
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-14: 初版公開