プロンプトインジェクションとは｜攻撃例と対策

完全防御は難しい

プロンプトインジェクションは、モデルへ与える「命令」と「処理対象のデータ」が同じ自然言語で届くことを悪用します。文書を要約するAIに、文書内から「別の操作を実行せよ」と働きかける構図です。

前提となるモデルの仕組みは、LLMとは何かを解説した記事で整理しています。

利用者の依頼 ─┐
               ├─ 同じコンテキスト → AI → 回答・ツール操作
外部の文書 ───┘
        ↑
  不正な指示が混ざる

OpenAIは、プロンプトインジェクションを、第三者が会話の文脈へ指示を混ぜ、利用者が頼んでいない行動へAIを誘導する問題と説明しています。モデル学習、監視、リンク検査、サンドボックス、重要操作前の確認を重ねていますが、単一の対策で十分とはしていません。

防御の目的を「攻撃成功率を0にする」だけに置くと、モデルや攻撃手法が変わるたびに前提が崩れます。モデルが誤判断しても、アクセスできるデータと実行できる操作を制限する設計が必要です。

直接型と間接型

直接型は、利用者入力として不正な指示が入ります。間接型は、AIが読むWebページ、メール、文書、検索結果、MCPツールの出力などに指示が埋め込まれます。MCPの仕組みでは外部ツールやデータをモデルへ接続するため、接続先から戻る内容も信頼境界の外側として扱います。ジェイルブレイクは、安全方針を回避して禁止出力を得ようとする行為を指すことが多く、外部データから利用者の意図を乗っ取る間接型とは焦点が違います。

種類	指示が入る場所	例	主な危険
直接型	利用者の入力	貼り付けた手順に別操作が混ざる	本人の依頼に見える
間接型	Web、メール、文書、ツール出力	要約対象に操作指示が隠れる	信頼できないデータを命令として扱う
ジェイルブレイク	利用者とモデルの対話	安全方針の回避を試みる	禁止出力や制約回避

Anthropicの解説は、AIが閲覧するWebページを攻撃経路として挙げています。通常のマルウェア検査を通った接続先でも、ページやREADMEの文章がAI向けの不正な指示を含む可能性は残ります。

攻撃元を「怪しい利用者」だけに絞らないことが重要です。正規のSaaS、社内Wiki、取引先メールから取得したデータも、内容までは信頼できない場合があります。

被害は権限で決まる

同じプロンプトインジェクションでも、要約しかできないAIと、送金、メール送信、本番更新までできるAIでは被害が違います。危険度は、攻撃が通る確率と、通った後に届く範囲の掛け算です。

AIが持つ権限	起こり得る影響	初期設計
公開文書の読取のみ	誤要約、偏った推薦	出典表示、複数資料確認
社内データ読取	情報漏えい、検索範囲外の取得	行単位権限、目的別データ分離
メール・チャット送信	なりすまし、誤送信	下書きまで、送信前確認
ファイル・DB書込	削除、改ざん、二重処理	サンドボックス、操作allowlist、冪等性
決済・本番操作	金銭損失、サービス障害	AI単独実行を避け、別経路で承認

Anthropicのcontainment解説は、モデル、実行環境、外部コンテンツの3層を分けています。モデル側の防御には見逃しが残るため、ファイル境界、仮想環境、ネットワーク送信先、ツール権限で到達範囲を制限する考え方です。

「高性能なモデルを使う」だけでは、権限設計の代わりになりません。モデル更新後も残る強制境界を、アプリケーション側に置きます。

安全な模擬テスト

TechCreateでは、実アカウント、実秘密情報、外部通信を使わず、文書要約を頼まれた模擬エージェントがread_documentと架空のsend_emailを提案するケースを作りました。コードは操作を実行せず、ポリシーが許可するかだけをJSONへ出力します。

シナリオ	ポリシー	文書読取	メール送信
利用者入力	境界なし	許可	許可
利用者入力	読み取り専用	許可	拒否
外部文書	境界なし	許可	許可
外部文書	読み取り専用	許可	拒否

このテストは、LLMが攻撃へ従う確率を測っていません。モデルがメール送信を提案したと仮定したとき、実行前の許可リスト（allowlist）で止められるかを確認しています。読み取り専用ポリシーでは、入力元に関係なく書き込み操作を拒否しました。

結果の意味は単純です。AIが不正な指示を見抜けなかったとしても、持っていない権限は使えません。検出器の改善と並行して、決定論的な実行制御を置く理由がここにあります。

防御を6層に分ける

対策は、入力フィルターだけでなく、信頼境界から監視まで重ねます。一つが失敗しても次の層で止める設計です。

層	実装すること	防げないもの
1. データ分離	外部文書を「命令」ではなく型付きデータとして渡す	内容を理解するモデルの誤判断
2. 最小権限	読取専用、対象行、対象フォルダ、操作別スコープ	許可範囲内の悪用
3. 実行ポリシー	ツール、引数、送信先、金額をコードで検査	正規に見える悪意ある操作
4. 人の確認	重要操作の対象と共有情報を具体的に表示	承認疲れ、見落とし
5. 隔離	サンドボックス、短命な資格情報、外向き通信制限	隔離環境内の損害
6. 監視	操作ログ、異常検知、停止スイッチ、再テスト	未観測の経路

外部コンテンツをXMLタグで囲む、システムプロンプトで「従うな」と書く、といった手法は補助になります。ただし、自然言語の優先順位をモデルが必ず守る保証にはなりません。OWASP LLM01:2025も、入力制限、出力検証、最小権限、人の承認を組み合わせる方向を示しています。

ツール実行の直前には、モデルとは別のコードで検査します。たとえば、メール送信なら宛先ドメイン、添付ファイル、本文に含まれる機密区分、利用者が確認した操作IDを照合します。

承認画面も設計する

「実行しますか」という確認だけでは、利用者は内容を判断できません。操作回数が多いと、確認を反射的に通す承認疲れも起こります。

悪い確認
  実行しますか [はい]

判断できる確認
  操作: 取引先へメール送信
  宛先: example.co.jp 1件
  添付: 見積書.pdf
  外部共有: 顧客名・金額を含む
  理由: 利用者が「下書きを送信」と指示
  [戻る] [送信]

承認へ出す情報は、モデルが作った要約だけに依存させません。実際のツール引数から宛先、対象、金額、共有データを表示し、表示した内容と実行内容を同じ操作IDで結びます。

低リスク操作まで毎回確認すると、重要な確認が埋もれます。読み取り専用の検索は自動化し、外部送信、削除、購入、本番変更だけを明確に止めるなど、リスク別に設計します。

残るリスクを測る

多層防御を入れても、プロンプトインジェクションは終わりません。許可済みツールの悪用、正規送信先への過剰共有、画像やPDF内の指示、複数ターンでの誘導、接続先自体の侵害が残ります。

継続テスト	確認すること
直接型	利用者の依頼に不要な操作を混ぜたとき止まるか
間接型	Web、メール、PDF、MCP出力の指示をデータとして扱えるか
権限	読取専用の資格情報で書込が物理的に拒否されるか
出力	ツール引数に秘密情報や許可外の宛先が入らないか
承認	画面表示と実際の操作が一致するか
障害	異常時に資格情報を失効し、操作を止められるか

モデルや接続先を更新したときは、同じテストセットを再実行します。攻撃文のコレクションだけでなく、権限と送信先の不変条件を自動テストへ置くと、モデル変更に左右されにくくなります。

まとめ

• プロンプトインジェクションは、命令とデータが同じ自然言語でモデルへ届く構造を悪用します。フィルターやプロンプトだけで完全防御するのは難しい問題です
• 被害の大きさはAIへ渡した権限で変わります。読み取り専用、操作allowlist、隔離、具体的な承認画面が、モデルの誤判断後にも残る防御になります
• 安全性は一度の攻撃成功率だけでなく、許可外操作が実行層で拒否されるか、監査と停止が機能するかを継続的に測る必要があります

出典・参考

• OpenAI: Understanding prompt injections
• OpenAI: Designing AI agents to resist prompt injection
• Anthropic: Mitigating the risk of prompt injections in browser use
• Anthropic: How we contain Claude across products
• OWASP LLM01:2025 Prompt Injection
• OWASP LLM Prompt Injection Prevention Cheat Sheet
• TechCreate編集部による実行境界の模擬検証（2026年8月31日実施）