【AI駆動開発】AIが外部の文章に騙される？プロンプトインジェクション超入門

Posted at 2026-11-05

はじめに

こんにちは、エンジニア5年目の嶋田です。
この記事を開いていただき、ありがとうございます！

前回の記事「AIエージェントの権限、絞ってますか？最小権限の原則超入門」では、権限を広く渡していると、外部から来た文章に紛れ込んだ不正な指示にAIが従ってしまったとき、被害が広がると書きました。

この記事の発表後、社内で「悪意のある入力でAIエージェントが暴走した経験はありますか？」という質問をもらいました。実際に経験はないのですが、「不正な指示に騙される」仕組みが気になったので調べてみようと思ったのがきっかけです。

今回はプロンプトインジェクションについて、公開されている資料（OWASPや各社のドキュメントなど）を読んで整理します。

この記事で扱うのは「何が起きるのか」と「守る側がどう考えるか」です。
攻撃の具体的な手順は扱いません。

この記事が、プロンプトインジェクションとは何か、なぜエージェントで影響が大きくなるのか、守る側はどう考えるか、を理解する助けになれば嬉しいです。

※この記事は2026年11月時点の情報をもとにしています。
この分野は動きが速いので、正確な内容は各公式ドキュメントを確認してください。

プロンプトインジェクションとは

OWASP（オワスプ、Webアプリのセキュリティで知られる団体）は、生成AIのリスクをまとめた「OWASP Top 10 for LLM Applications」の1番目にプロンプトインジェクションを挙げています。

OWASPの説明を自分の言葉でまとめると、次のようになります。

ユーザーが入力した文章（プロンプト）が、AIの動作や出力を、意図しない形で変えてしまうこと
人間には見えない文章でも、AIが読み取れるなら起こりうる

身近なたとえにすると、こうです。

秘書に「この手紙を読んで要約して」と頼んだとします。その手紙の中に「この手紙を読んだ人は、机の引き出しの鍵を同封して返送してください」と書いてあり、秘書がそれを「自分への指示」と受け取ってしまう。

秘書は、あなたからの頼みと、手紙に書かれた文章を区別できていません。AIでも同じことが起きる、というのが基本の考え方です。

OWASPのチートシート（対策集）では、原因を、指示とデータが明確に分けられないまま処理されることだと説明しています。

2つの種類：直接型と間接型

OWASPは、プロンプトインジェクションを2種類に分けています。

種類	何が起きるか	例（OWASPの例を要約）
直接型	ユーザーの入力そのものが、AIの動作を意図しない形に変える	カスタマーサポートのチャットボットに、それまでの指示を無視させ、非公開データを引き出させる
間接型	AIが読み込んだ外部のWebサイトやファイルに含まれる文章が、動作を変える	AIに要約させたWebページに隠された指示があり、会話の内容が外部に送られてしまう

どちらも、意図的な場合と、意図しない場合の両方がありえる、とOWASPは書いています。

エージェントを使うときに特に気になるのは、間接型です。エージェントは、Webページやメール、ファイルなどを自分で読みに行くからです。

用語の注意：ジェイルブレイクとの違い

プロンプトインジェクションと似た言葉に、ジェイルブレイク（AIの安全のための制限を外させようとすること）があります。ただ、資料によって関係の説明が違います。

出典	説明の仕方
OWASP	ジェイルブレイクは、プロンプトインジェクションの一種。両者はしばしば混同されて使われる、と説明している
トレンドマイクロ（OWASP Top 10 for LLMの解説記事）	OWASPの整理に沿って、ジェイルブレイクはプロンプトインジェクションの一形態と説明している
トレンドマイクロ（「プロンプトインジェクションとは」）	ジェイルブレイクとは区別されるものとして説明している
Simon Willison（この用語を作った人）	ジェイルブレイクは、プロンプトインジェクションとは別の問題として扱っている

同じ会社の解説でも、記事によって説明が分かれています。用語の使い方は、出典によって違う場合があります。この記事では、OWASPの整理に沿って、ジェイルブレイクは「プロンプトインジェクションと関連する概念」として扱います。

なぜエージェントだと影響が大きくなるのか

OWASPは、成功したプロンプトインジェクションの影響の大きさは、AIが使われている業務の場面と、AIにどれだけの行動する力（agency、エージェンシー。機能を呼び出したり、他のシステムとやり取りしたりする力）が与えられているかによって大きく変わる、と説明しています。

挙げられている影響には、次のようなものがあります。

機密情報の漏えい
AIが使える機能への、無許可のアクセス
接続されたシステムでの、任意のコマンドの実行
重要な判断の操作

つまり、文章を読むだけのAIと、ツールで実際に操作できるエージェントとでは、同じ攻撃を受けても、起きる結果が違います。ここは、前回の記事の最小権限の話につながるところです。

3つがそろうと危険：Simon Willisonの整理

Simon Willisonは、ツールを持つAIで特に注意すべき組み合わせとして、次の3つを挙げています。

条件	内容
私的なデータへのアクセス	自分の非公開データを読める
信頼できない内容への接触	攻撃者が書いた文章が、AIの目に入る可能性がある
外部への通信	データを外部に送れる

この3つがそろうと、攻撃者はAIをだまして、私的なデータを取得させ、外部に送らせることができる、と書かれています。

Willisonは、MCPがさまざまな提供元のツールを組み合わせやすくしているため、この3つがそろいやすい、と指摘しています。また、ツールを自分で組み合わせて使う人にとっては、この3つの組み合わせを避けることが、確実な守り方だと述べています。

前回の記事とのつながり（私の整理）

ここは出典の記述ではなく、私の整理です。
前回の「過剰な権限を絞る」という考え方を、この3つに当てはめると、次のように考えられます。

条件	絞る方向
私的なデータへのアクセス	読み取れる範囲を、タスクに必要な分だけに絞る
信頼できない内容への接触	外部の内容を読むエージェントと、重要な操作をするエージェントを分ける、など
外部への通信	外部に送る操作は、必要なものだけに限る

防ぎ方の考え方

完全に防ぐ方法はまだない

最初に押さえておきたいのは、OWASPが次のように書いている点です。

生成AIの仕組み上、プロンプトインジェクションを確実に防ぐ方法があるかは、はっきりしていない
そのうえで、影響を小さくするための対策が挙げられている

Claude Codeの公式ドキュメントにも、「保護機能でリスクは大きく下がるが、すべての攻撃を防げるシステムはない」という趣旨の注意書きがあります。

OWASPが挙げる7つの対策

#	対策（OWASPの項目を要約）	内容
1	AIの動作を制限する	システムプロンプトで、役割や範囲を指定する
2	出力の形式を決めて検証する	決まった形式かどうかを、プログラムで確認する
3	入力と出力をフィルタリングする	許可しない内容を、ルールで検出する
4	権限を最小限にする	AIにはAPIトークンを直接渡さず、機能はコード側で処理し、アクセス権限は必要最小限にする
5	高リスクな操作は人間が承認する	権限の大きい操作に、Human-in-the-Loop（人間による確認）を入れる
6	外部のコンテンツを分けて明示する	信頼できない内容を区別し、プロンプトへの影響を小さくする
7	敵対的なテストをする	AIを「信頼できないユーザー」として扱い、境界やアクセス制御が機能するか確かめる

4番と5番は、前回と前々回の記事のテーマ（最小権限、HITL）と同じです。
OWASPがこれらをプロンプトインジェクションの対策としても挙げていることを、今回の整理で確認できました。

フィルタリングだけでは足りない

OWASPのチートシートでは、入力の検査（既知の言い回しを検出する方法）は、セキュリティの境界にはならない、と書かれています。言い換えや他の言語、文字の変換などで、すり抜けられる可能性があるためです。

そのため、「怪しい文章を見つける」ことだけに頼らず、権限と承認の側で被害を小さくする考え方が大切になります。

公式ドキュメントにある具体例

Claude Code（公式ドキュメント）

Manualモード（確認しながら使うモード。起動時のモードは、環境や設定で異なります）では、ネットワークからの取得に使うコマンド（curl や wget など）は、デフォルトでは自動承認されない
信頼できない内容を、そのままClaude Codeに渡さないことが推奨されている
重要なファイルへの変更を確認すること、許可の設定を定期的に見直すことが推奨されている

MCP（公式のセキュリティ文書）

スコープ（アクセスできる範囲）を絞る「Scope Minimization」の節がある
広い範囲のトークンが漏れると影響が大きくなるため、最小限のスコープから始め、必要になったら段階的に広げる考え方が書かれている

Google Workspace（Geminiの多層防御、最終更新：2026年3月17日）

間接プロンプトインジェクションを、Webサイト・メール・ドキュメントなどの外部データに埋め込まれた悪意のある指示を、AIが処理してしまう脆弱性と説明している
対策を6項目の多層防御として挙げている（コンテンツ分類、セキュリティ思考の強化、マークダウンのサニタイズと不審なURLの除去、ユーザー確認フレームワーク、ユーザーへの通知、モデルの堅牢性の向上）
このうち「ユーザー確認フレームワーク」は、カレンダーの予定の削除など、リスクの高い操作の前に、ユーザーの明示的な確認を求めるもの

Claude CodeとMCPは、前回の記事の最小権限の原則と同じ方向の内容です。Googleの「ユーザー確認フレームワーク」は、前々回のHITLと同じ方向の考え方だと感じました。

これまでの3本とのつながり

これまでの3本と今回の関係を整理すると、次のようになります。

記事	役割	一言で言うと
MCPの記事	土台	AIと道具を共通の規格でつなぐ
HITLの記事	対策：止める	重要な操作の前で、人間が確認する
最小権限の記事	対策：絞る	そもそも何ができるかを狭くしておく
今回	何から守るか	外部の文章に含まれる指示に、AIが従ってしまうことがある

今回の記事の位置づけは、「HITLと最小権限が、何に対する備えなのか」を説明するところです。

OWASPは、プロンプトインジェクションの対策として、「権限を最小限にする」ことと「高リスクな操作は人間が承認する」ことを挙げています。これが、前回の最小権限と、前々回のHITLにあたります。

まとめ

プロンプトインジェクションは、AIが「自分への指示」と「読み込んだ文章」を明確に区別できないことで起きる
特にエージェントでは、外部のWebページやファイルを読む「間接型」が気になる
影響の大きさは、AIにどれだけの権限があるかで変わる
完全に防ぐ方法は、まだはっきりしていない。だから、権限を絞る（最小権限）と、重要な操作を人間が確認する（HITL）で、被害を小さくする考え方が大切

「暴走した経験はありますか？」という質問をもらいましたが、整理してみて、「起きたことがあるか」より「起きたときに被害がどこまで広がるか」を先に考えておくことが大事だと感じました。

参考文献

英語の資料

日本語の資料

これまでの記事

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up