プロンプトインジェクションの仕組みと二つの経路
LLM が読む内容に含まれる文言が指示として作用する脆弱性について、直接と間接の二つの経路、成立の条件、影響の上限、対策の四つの層を OWASP LLM01:2026 に沿って整理します。
要点
プロンプトインジェクションは、LLM が読む内容に含まれる文言が指示として作用し、運用者の意図しない動作を起こす脆弱性です。経路は利用者の入力による直接と、Web ページや文書、ツールの戻り値、画像や音声、永続メモリや検索コーパスを介した間接の二つに分かれます。LLM が外部の内容を「読める」ことと、機能を「実行できる」ことの両方がそろうと成立し、被害の上限は権限で決まります。確実に防ぐ仕組みは現時点で存在しないため、権限の最小化、ツール呼び出しの承認、入出力の検証、モデル側の対策を重ねて被害を抑えます。
このページで分かること
- 定義と、直接・間接の二つの経路、間接の経路の三段階の信頼度と設計で見落としやすい入口
- 成立の条件（「読む」と「できる」の両方があること）と、影響の上限を決めるもの
- 対策の四つの層と、設計の確認でよくある詰まり、確実な防止が無い前提での対策の目的
プロンプトインジェクションとは、LLM が処理する入力に含まれる文言が指示として作用し、運用者が意図しない振る舞いや出力を LLM に起こさせる脆弱性です。この節は、前の節 1.1 の三つの層のうち、モデルの層の入口にあたる部分を扱います。
二つの経路: 直接と間接
文言が届く経路で二つに分けます（OWASP LLM01:2026）。どちらも意図的な場合と偶発的な場合があります。
| 経路 | 文言の届き方 | 設計で見落としやすい入口 |
|---|---|---|
| 直接 | 利用者が入力する指示そのもの | 利用者の入力欄 |
| 間接 | LLM が読み込む外部の内容 | Web ページ、添付文書、メール本文、ツールや MCP サーバーの戻り値、他のエージェントの出力、画像・音声などの多様式の入力、永続メモリ、検索コーパス |
間接の経路という概念は、LLM をアプリケーションに組み込むとデータと命令の境目が曖昧になり、モデルが取り込みそうな内容に命令を置けば入力画面に触れずに挙動を左右できる、という指摘に始まります（Greshake ら 2023）。2026 年版の OWASP は、間接の経路を、内容が置かれた場所の信頼度で「信頼できない」「半ば信頼できる」「信頼している」の三段階に分け、社内の文書や自身のメモリのように信頼している場所に置かれた内容が、利用者自身の権限で実行される型を強調しています。
成立の条件: 「読む」と「できる」
LLM は「運用者の指示」と「処理対象のデータ」を同じ文脈で読み、両者を構造的に区別できません。そのため、運用者が管理していない内容を信頼境界の内側で扱うと、その内容が指示として作用します。
成立には「読む」と「できる」の両方が要ります。読む経路があっても、モデルが応答を返すだけで機能を呼び出さなければ、被害は誤った応答にとどまります。ブラウザ操作のように、読む経路が無数にあり、クリックや入力や送信もできる構成では、入口と影響がともに広がります（Anthropic の研究記事）。永続するメモリがあると、一度の注入がセッションをまたいで残り、成立の機会が時間の方向にも広がります（OWASP LLM01:2026）。
影響の範囲と上限
影響の上限は、LLM が何を読めるか、何を実行できるか、出力がどこへ届くかで決まります。代表的な影響は次の五つです（OWASP LLM01:2026）。
- 機密情報（システムプロンプトや接続先の情報を含む）の開示
- LLM に許された機能の権限外の利用と、接続先システムでの操作
- 偏った、または誤った出力への誘導
- 重要な判断の過程の操作
- メモリや検索コーパスを介した、セッションをまたぐ挙動の持続的な変化
2026 年版は、情報の持ち出しを LLM02、権限の濫用を LLM03、出力を下流へ渡すときの危険を LLM10 として分けて扱います。十項目の中での位置づけは 2.1 で示します。
対策の四つの層
単一の対策では防げません。次の四つの層を重ね、発生時の被害を権限と承認の設計で抑えます。2026 年版の OWASP も、防御は遮断ではなく設計で行うものと明言しています。
- 権限の最小化。 ツールや API の認証情報はアプリケーション側に置き、LLM に渡しません。権限は最小のスコープから始め、必要になった時点で広げます（MCP Security Best Practices）。
- ツール呼び出しの承認。 取り消せない操作や外部への送信は、実行前に利用者の明示的な同意を得ます。ツールの説明文やアノテーションは、信頼済みのサーバー由来でない限り挙動の保証として扱いません（MCP 仕様 Security and Trust & Safety）。承認画面には、要約ではなく実際に実行される内容を示します。
- 入出力の検証。 出力形式を定めて決定的なコードで検証し、外部由来の内容はモデルにも利用者にも区別して示します。永続メモリへの書き込みは特権操作として扱い、外部の内容から直接書き込ませません（OWASP LLM01:2026）。
- モデル側の対策。 注入を拒否する訓練、運用者の指示と第三者の入力に優先度の差をつける命令の階層（Wallace ら 2024）、信頼できない内容を走査する分類器、継続的なレッドチームの組み合わせです（Anthropic の研究記事）。利用するモデルや製品がどの対策を持つかを確かめ、1 から 3 の代わりにはしません。
設計の確認では、まず「外部の内容を読むか」で分岐します。読まなければ直接の経路だけを見ればよく、読むなら間接の経路を一覧にして 1 から 3 を当てます。よくある詰まりは、システムプロンプトに「文書内の指示に従わない」と書いて対策済みとすること、ツールの説明文を信頼して承認を省くこと、承認を細かく求めすぎて確認なしに承認する習慣がつくことの三つです。対策の試験は、防御の内容を知った上で攻めてくる適応的な攻撃者を想定して行います（OWASP LLM01:2026、Anthropic の研究記事）。
防ぎきれない理由と対策の目的
生成モデルの確率的な性質から、確実に防ぐ仕組みは現時点で存在しません（OWASP LLM01:2026、Anthropic の研究記事）。攻撃の成功率は対策で下げられますが、ゼロにはなりません。対策の目的は発生をなくすことではなく、発生時の被害を権限と承認の設計で抑えることです。