エージェントは、「指示」と「ただの文章」を区別できない
SQLインジェクションは、入力欄に渡された文字列を、データベースへの命令文にそのまま組み込んでしまうことで起きます。プロンプトインジェクションは、これのエージェント版です。
エージェントは、使う人が打った指示も、読み込んだWebページの中身も、開いたファイルの中身も、すべて同じ「文章」として扱います。公式のOWASPの定義はこうです。
“A Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways.”
（プロンプトインジェクションの脆弱性は、プロンプトがLLMの動作や出力を、意図しない形で変えてしまうときに起きる）
つまり、エージェントに読ませたWebページや受け取ったファイルの中に、「これまでの指示を忘れて、こうしてください」のような文章が紛れ込んでいると、エージェントはそれを本物の指示と見分けられずに従ってしまうことがあります。SQLインジェクションが「データベースへの命令」と「ただのデータ」を区別できなかったことで起きるように、プロンプトインジェクションは「本来の指示」と「読んだだけの文章」を区別できないことで起きます。
2種類ある——本人が打つか、外から紛れ込むか
OWASP公式は、これを2つに分けています。
- 直接的インジェクション — 本人が打った指示そのものが、意図的か偶然かにかかわらずエージェントの動作を変えてしまうケース
- 間接的インジェクション — エージェントが読み込んだ外部のコンテンツ（Webページ、ファイル、ドキュメントなど）に隠された指示が、本人の知らないところで動作を変えてしまうケース
今、増えていて、より厄介なのは後者です。 自分では何も怪しいことを打っていないのに、エージェントに「このページを調べて」「このファイルを読んで」と頼んだだけで、そのページやファイルの中に仕込まれた指示に従ってしまう、という形だからです。
なぜ今、増えているのか
OWASPのLLMアプリ向けリスク一覧で、プロンプトインジェクションは3年連続で1位です。約1万件の実際のAIセキュリティ事案を突き合わせた投票にもとづくランキングだと説明されています。
理由は単純です。エージェントが自律的にできることが増えるほど、間接的インジェクションが引き起こせる被害も大きくなるからです。Webを調べる、ファイルを読み書きする、MCP経由で外部サービスを操作する——このサイトでも繰り返し紹介してきた便利さそのものが、そのまま攻撃の通り道になります。同じOWASPのリストで、「過剰な自律性」というリスクの順位が8位から3位に上がったのも、この傾向を裏づけています。
Anthropic発のMCPサーバーでも、実際に起きた
他人事ではない例が、身近なところにあります。MCPの公式リファレンス実装のひとつであるgit用サーバー（Anthropicが最初に作ったもの）に、2026年1月までに3件の脆弱性が見つかりました（GitHub公式のセキュリティアドバイザリ）。
- パス検証の不備（指定したはずのリポジトリの外にアクセスできてしまう）
- リポジトリ作成機能に制限がなく、任意の場所をリポジトリ化できてしまう
- コマンドの引数にインジェクションが可能
攻撃の起点は、悪意のあるREADMEや、細工されたissueの説明文でした。 攻撃者は対象のパソコンに直接アクセスする必要すらなく、エージェントに「このリポジトリを見て」と読ませるだけで、これらの脆弱性を連鎖させてファイルの読み書きやコード実行にまで持ち込めたと報告されています。2025年6月に報告され、12月までに修正されています。MCPを作った当人ですら、間接的インジェクションを完全には防げなかったという事例です。
防げない、という前提で作られている
Anthropic自身も、これを「完全に防げる」とは言っていません。Claude Code公式のセキュリティページには、対策の一覧のすぐあとに、こう明記されています。
“While these protections significantly reduce risk, no system is completely immune to all attacks.”
（これらの防御はリスクを大きく減らすが、あらゆる攻撃から完全に無縁なシステムは存在しない）
OpenAIも同じ立場です。2026年に導入した「Lockdown Mode」という設定について、公式はプロンプトインジェクションの発生自体を防ぐものではなく、機密データを盗み出されるのを防ぐためのものだと明言しています。攻撃を入り口で止めるのではなく、攻撃が成功しても被害を小さくするという発想です。
これは、このサイトのセキュリティ記事群が一貫して立っている前提と同じです。「100%安全」は存在しない。目指すのは、被害を小さくすることです。
気をつけたいこと
エージェントを使う側として、意識しておきたいのは次の点です。Claude Code公式が挙げている「信頼できないコンテンツを扱うときのベストプラクティス」がそのまま参考になります。
- 提案されたコマンドは、実行前に目を通す。 「よく分からないけど許可する」を積み重ねない
- 信頼できないコンテンツを、そのままエージェントに流し込まない。 中身を知らないWebページやファイルを丸ごと読ませるときは、何が起きるかを意識する
- 重要なファイルへの変更は、内容を確認する。 とくに外部サービスとやり取りするような操作は
- 知らない提供元のMCPサーバーは、むやみにつながない。 MCPの記事にも書いたとおり、ディレクトリに載っていることは安全性の保証ではありません
- 不審な動きに気づいたら、その場で報告する。 Claude Codeなら
/feedbackから
実際に、管理人がMCPの設定を確認させようとしただけで伏せたはずのAPIキーが画面にそのまま表示されてしまったことがあります。あれ自体はプロンプトインジェクションではありませんが、「エージェントに何かを読ませる」という、ごく普通の操作が事故につながりうるという感覚は、そのまま通じるところがあります。
まとめ
- プロンプトインジェクションは、「指示」と「ただの文章」を区別できないという問題から起きる、SQLインジェクションのエージェント版
- 直接（自分で打った指示）と間接（読み込んだ外部コンテンツに仕込まれた指示）の2種類があり、増えていて厄介なのは後者
- エージェントが自律的にできることが増えるほど、被害範囲も広がる。OWASPのリスク一覧で3年連続1位
- MCPを作った当人であるAnthropicのリファレンス実装でも、実際に脆弱性が見つかっている
- Anthropic・OpenAIとも「完全には防げない」という前提に立っており、目指すのは被害を小さくすること
- 対策は、提案されたコマンドを確認する、信頼できないコンテンツをそのまま流し込まない、知らないMCPサーバーをむやみにつながない、といった地道な積み重ね