AIエージェントに、メールの送信やファイルの操作、社内システムへの登録といった「実際に手を動かす権限」を渡す動きが広がっています。それと同時に最大の懸念になっているのが「プロンプトインジェクション」です。Webページやメール、ツールの説明文など、エージェントが読み込むデータの中に指示を紛れ込ませ、本来の依頼とは別の行動を取らせる攻撃のことです。
やっかいなのは、利用者が直接入力しなくても、エージェントが読みに行った先に指示が仕込まれていれば攻撃が成立する点です。「検知を1つ挟めば安心か」「どこまで権限を渡してよいか」の判断材料が足りず、PoCから先に進めないという声も少なくありません。とはいえ「怖いから権限を絞る」だけでは、エージェントの価値も一緒に小さくなってしまいます。
この記事では、OWASP や英国の国家サイバーセキュリティセンター（NCSC）、各社の公式ドキュメントをもとに仕組みと対策の全体像を整理し、「検知で防ぐ」「検知の限界」「設計で閉じ込める」「ツール経由の新しい攻撃」を扱った論文4本を紹介します。結論を先に言うと、検知は「確率を下げる網」と割り切り、騙されても被害が出ないように権限と処理の流れを設計するのが基本です！
プロンプトインジェクションとは何か：「データ」と「指示」の区別がつかない
OWASP による定義
OWASP は、LLMアプリケーションのリスク一覧（2025年版）の1番目にプロンプトインジェクションを挙げ、入力によってLLMの振る舞いや出力が意図しない形で変わる脆弱性と定義しています。人間の目に見えない形でも、モデルが読み取れば効果を持ちます（OWASP「LLM01:2025 Prompt Injection」）。
直接型と間接型
OWASP は、プロンプトインジェクションを2つの型に分けています。
| 型 | 指示がどこから入るか | 想定する相手 |
|---|---|---|
| 直接型 | 利用者が入力する文そのもの | 利用者自身が攻撃者になる場合 |
| 間接型 | Webサイトやファイルなど外部から取り込む内容 | 利用者は正当で、読み込む先に仕込まれている場合 |
Anthropic の公式ドキュメントも同じ分け方で、間接型の例に受信メール、取得したWebページ、ツールの実行結果などを挙げています（Anthropic「Mitigate jailbreaks and prompt injections」）。エージェントにとって問題が大きいのは間接型です。Microsoft も、報告を受けるAIの脆弱性で最も多い手法の1つだと述べています（Microsoft「How Microsoft defends against indirect prompt injection attacks」）。
なお、検索して取り込む文書に指示を仕込むRAGの「毒入れ」については、RAGの実務×論文4選で扱っています。
なぜ根本的には防げないのか
英国 NCSC は2025年12月のブログで、プロンプトインジェクションを SQL インジェクションと同じように考えるのは危険だと指摘しています。SQL インジェクションはデータと命令を分けて扱う仕組みで根本から防げますが、LLMの内部には「データ」と「指示」の区別がなく、あるのは「次に来る言葉の予測」だけです。そのため同じ意味で完全に防げるようにはならない可能性が高い、としています（NCSC「Prompt injection is not SQL injection (it may be worse)」）。
OWASP も確実な防ぎ方があるかは分からないとし、OpenAI も対策でリスクは大きく下がるがなくならないと書いています（OpenAI「Safety in building agents」）。NCSC は、残るリスクを前提に設計と運用で管理すべきで、それを許容できないならLLMに向いた用途ではないかもしれない、とまで述べています。
対策の全体像：「起きにくくする」「見つける」「被害を小さくする」
Microsoft は対策を「予防」「検知」「影響の軽減」に分け、攻撃の可能性を下げるだけの確率的な対策と、設計で特定の攻撃が成功しないことを保証する決定的な対策を区別しています。すべてに決定的な対策は使えないので、組み合わせる考え方です。
| 層 | 主な対策 | 性質 |
|---|---|---|
| 起きにくくする | 外部の内容を指示と分けて渡す、システムプロンプトで扱いを明示する | 確率的 |
| 見つける | 小型モデルなどで入力やツールの結果を事前に判定する、ログを残す | 確率的 |
| 被害を小さくする | 最小権限、重要な操作の前の人の承認、データの流れの制限 | 決定的にできる |
起きにくくする
各社に共通するのは、外部から来た内容を開発者の指示と混ぜないことです。Anthropic は外部の内容をツールの結果として出どころとともに渡し、それが信頼できないデータだとシステムプロンプトに明記するよう勧めています。OpenAI も、信頼できない入力を開発者向けの指示に入れないこと、処理の間を決まった形式の出力でつなぐことを挙げています。
見つける
入力やツールの結果を、本体に渡す前に小型のモデルで判定させる方法も紹介されています（Anthropic）。ただし NCSC は、既知の危険な言い回しを拒否リストで止める方法には、言い換えが無限にあるため注意が必要だとしています。
被害を小さくする
OWASP は、最小権限と、権限の大きい操作に人の承認を挟むことを挙げています。同じ一覧の「過剰な権限（Excessive Agency）」の項目では、被害の根本原因を「機能が多すぎる」「権限が強すぎる」「自律性が高すぎる」の3つに整理しています（OWASP「LLM06:2025 Excessive Agency」）。NCSC は、LLMを使わない仕組みで行動を縛る対策を重視すべきだとしています。ここからは、それぞれの層に取り組んだ論文を見ていきます。
研究で見る「検知」の実力と限界
📄 論文: 既製のLLMに「紛れ込んだ指示」を見つけて取り除かせる
PromptArmor: Simple yet Effective Prompt Injection Defenses（Tianneng Shi ほか、2025年7月、arXiv:2507.15219）は、査読前の論文（プレプリント）です。
評価は、銀行・メッセージ・旅行・業務の4種類の模擬環境でエージェントの作業を再現するベンチマーク AgentDojo 上で、検知役には主に OpenAI のAPIのモデルを使っています。
市販のLLMに工夫したプロンプトを与え、エージェントが読む前のツールの結果から紛れ込んだ指示を見つけて取り除かせる方法です。検知役に GPT-4o、GPT-4.1、o4-mini を使うと、ベンチマーク付属の定型的な手口に対して誤検知と見逃しがともに1%未満で、防御なしでは約55%だった攻撃成功率も1%未満に下がりました。防御を知ったうえで自動で手口を変えて試す攻撃（1手法）でも、攻撃成功率は0.34%でしたが、見逃しは約2%と通常の評価より増えています。古いモデル（GPT-3.5）を検知役にすると、誤検知・見逃しとも1割を超えました。
運営者にとっての意味は、性能の高いモデルを検知役にすれば手軽な「1枚目の網」として有力だが、評価の範囲外の攻撃にも同じ数字が出るとは限らない、ということです。
📄 論文: 「ほぼ完璧な検知」が構造的に崩れるケース
How Not to Detect Prompt Injections with an LLM（Sarthak Choudhary ほか、2025年7月投稿・2025年12月改訂、arXiv:2507.05630）は、査読前の論文（プレプリント）です。
評価の対象は、KAD を強化した代表的な防御（検知役を追加学習したもの）1つで、感情分析や要約など7種類の文章処理の課題に、本体のモデルとして GPT-4.1 や Claude 4 Sonnet など4つを組み合わせて測っています。エージェントでの評価ではありません。
「既知回答検知（KAD）」は、検知役のLLMに答えの分かっている確認用の課題を出し、入力に指示が紛れ込んでいれば検知役がそちらに引っ張られて正しく答えられなくなる、という性質を利用する方式で、「ほぼ完璧」と報告されていました。著者らはこの前提そのものの構造的な弱点を突く攻撃を設計しました。モデルの内部へのアクセスも、攻撃文の最適化計算も使っていません。検知率はほとんどの課題で0%まで下がり、攻撃の成功率は課題とモデルによっては9割前後に達しました（1割未満の組み合わせもあります）。
運営者にとっての意味は、検知の数字は「攻撃者が仕組みを知らない」前提のことが多く、検知だけに頼るのは危険だということです。
研究で見る「設計で閉じ込める」
📄 論文: 信頼できないデータが「処理の流れ」を変えられない構造にする
Defeating Prompt Injections by Design（Edoardo Debenedetti ほか、2025年3月投稿・2025年6月改訂、arXiv:2503.18813）は、査読前の論文（プレプリント）です。
評価は AgentDojo の模擬環境で、o3、Claude 4 Sonnet、Gemini 2.5 Pro など各社のモデルを使っています。
「LLMが騙されても被害が出ない」構造を目指した「CaMeL」で、NCSC のブログでも設計で防ぐ主要な研究として紹介されています。利用者の依頼から先に処理の手順とデータの流れを組み立て、外部のデータは中身の読み取りにしか使わせません。さらにデータごとに「どこへ渡してよいか」を表す権限情報（ケイパビリティ）を付け、ツールを呼ぶ直前にルールと照合して持ち出しを止めます。o3 を使った場合、普通にツールを呼ばせる方式の84%に対してタスクの77%を解きましたが、この差はモデルによって3ポイント程度から30ポイント以上まで開きます。著者ら自身も、ルールを保守する手間や、データの流れに関わらない攻撃は対象外であることを挙げ、「完全に解決したわけではない」と明言しています。
運営者にとっての意味は、「どのデータをどのツールに渡してよいか」をLLMの外で決めておけば、モデルが騙されても重大な操作を止められるということです。下がる成功率が許容できるかは、使うモデルで確かめます。
📄 論文: ツールの「説明文」が他のツールの使い方をねじ曲げる
Think Twice Before You Act: Protecting LLM Agents Against Tool Description Poisoning via Isolated Planning（Shanghao Shi ほか、2026年6月、arXiv:2606.20922）は、ICML 2026 採録（abs のコメント欄の記載）です。
評価は AgentDojo と、10種類の業務場面を模した ASB という2つのベンチマーク上で、GPT-4o などのAPIのモデルを使って行ったものです。
ツールの説明文（何ができるかを書いたメタデータ）は、エージェントが計画を立てるたびに読み込まれます。あまり使われないツールの説明文を書き換えるだけで、送金など別の重要なツールを呼ばせる脅威で、書き換えられたツール自体が選ばれなくても成立します。既存の対策5種では、一部は攻撃を減らすものの成功率は高いまま残りました。提案手法「Tool-Guard」は、呼び出しが依頼内容とかみ合わないと判定されたツールを「影響を受けた可能性があるもの」の一覧に移し、その一覧と残りのツールとで計画を別々に立てさせます。移されたツールは悪者扱いではなく、引き続き使えます。AgentDojo で GPT-4o を使うと、攻撃成功率は防御なしの約43%から約2%に下がり、ASB でも低い水準に抑えられました。
運営者にとっての意味は、つないだツールの説明文も「信頼できない入力」として扱う必要がある、ということです。
現場でやること
まず「何を読ませて、何をさせているか」を一覧にする
エージェントごとに、読み込む外部の内容と、使えるツールや権限を書き出します。外部の内容を読む処理と、送信・削除・支払いのような重要な操作が同じエージェントにあれば、最初に見直す対象です。
権限は「機能・権限・自律性」の3つで絞る
- 業務に要らないツールはつながない（機能）
- 読み取りだけでよいなら書き込み権限を渡さない（権限）
- 送信・削除・外部への共有など取り消しにくい操作の前に、人の承認を挟む（自律性）
外部の内容は「指示と分けて」渡し、検知は網として使う
外部の内容は出どころを明示してツールの結果として渡し、性能の高いモデルによる事前の判定を1枚目の網として入れます。ただし、どちらも防げることを保証するものではないので、前の項目の権限の絞り込みと必ず組み合わせます。コード生成エージェントのように、リポジトリの中身を読んで書き込む使い方なら、コード生成エージェント×論文4選で扱ったレビュー体制も合わせて考えます。
ログを残し、追加するツールを審査する
LLMの入出力とツールの呼び出しを記録しておけば、攻撃者が試行錯誤している段階で気づける可能性があります（NCSC）。新しいツールの説明文に他のツールの使い方を指図する記述がないかを確認し、出どころの分からないツールは重要な操作のあるエージェントと一緒にしないようにします。
エージェントに権限を渡すための鍵は次の3点です
- 検知は「確率を下げる網」と割り切る
既製のLLMによる検知は手軽で効果も高い一方、仕組みを知った攻撃者に崩される方式もあります。検知だけに頼らない構成にします。 - 権限とデータの流れを「LLMの外」で縛る
最小権限、取り消しにくい操作の前の承認、データを渡してよい先のルールを、モデルの判断に任せずに決めておきます。下がる成功率が許容できるかも確かめます。 - ツールの説明文も「信頼できない入力」として扱う
つなぐツールを審査し、ツール同士の影響を切り分けられるようにしておきます。
まとめ：エージェントの安全は「見抜く」だけでなく「騙されても壊れない」設計で！
プロンプトインジェクションは、LLMがデータと指示を区別できないことから生まれる問題で、公的機関も各社も「完全には防げない」という立場です。だからこそ2026年現在は、検知で攻撃の可能性を下げる対策と、騙されても被害が出ないように権限と処理の流れを設計する対策を、組み合わせる考え方が重視されています。
まずは自社のエージェントが「何を読み、何をしているか」を一覧にしてみてください。外部の内容を読む処理と重要な操作が同じ場所にあれば、そこが最初に手を入れるところです！
参考文献
- OWASP「LLM01:2025 Prompt Injection」（https://genai.owasp.org/llmrisk/llm01-prompt-injection/）2026-10-01 確認
- OWASP「LLM06:2025 Excessive Agency」（https://genai.owasp.org/llmrisk/llm062025-excessive-agency/）2026-10-01 確認
- 英国 NCSC「Prompt injection is not SQL injection (it may be worse)」（https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection）2026-10-01 確認
- Microsoft Security Response Center「How Microsoft defends against indirect prompt injection attacks」（https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks）2026-10-01 確認
- Anthropic「Mitigate jailbreaks and prompt injections」（https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks）2026-10-01 確認
- OpenAI「Safety in building agents」（https://developers.openai.com/api/docs/guides/agent-builder-safety）2026-10-01 確認
- Tianneng Shi ほか「PromptArmor: Simple yet Effective Prompt Injection Defenses」arXiv:2507.15219（https://arxiv.org/abs/2507.15219）2026-10-01 確認
- Sarthak Choudhary ほか「How Not to Detect Prompt Injections with an LLM」arXiv:2507.05630（https://arxiv.org/abs/2507.05630）2026-10-01 確認
- Edoardo Debenedetti ほか「Defeating Prompt Injections by Design」arXiv:2503.18813（https://arxiv.org/abs/2503.18813）2026-10-01 確認
- Shanghao Shi ほか「Think Twice Before You Act: Protecting LLM Agents Against Tool Description Poisoning via Isolated Planning」arXiv:2606.20922（https://arxiv.org/abs/2606.20922）2026-10-01 確認
2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、既知回答検知を破る攻撃の成功率、CaMeLのタスク成功率の比較、Tool-Guardが隔離するツールの記述の誤りを修正しました
