プロンプトインジェクションは、LLM（大規模言語モデル）アプリの最重要リスクです。OWASP Top 10 for LLM Applications でも堂々の第1位（LLM01）。当サイトで解説してきた MCP・ AIブラウザ・ Langflow の脆弱性は、いずれも根っこにこの問題を抱えています。本記事はそれらを束ねる総論として、なぜ防ぎにくいのか、直接／間接の違い、実例、そして防御とその限界までを整理します。
被害は理論上の話ではありません。2025〜2026年のAI関連データプライバシー事故の約60%がプロンプト操作に起因し、社内文書を扱うAIコパイロットの75%に情報漏えいリスクが確認されたという分析もあります。AIをアプリに組み込むなら避けて通れないテーマです。
プロンプトインジェクションとは
ひとことで言えば、「攻撃者が紛れ込ませた指示を、LLMが正規の命令として実行してしまう」攻撃です。Webの XSS が「データのつもりの入力がコードとして実行される」問題であるのと、構造はよく似ています。
根本原因は明快です。LLMは「開発者のシステム指示」と「外部から来たデータ」を区別できません。両方とも同じコンテキスト（プロンプト）に文字列として流し込まれ、モデルから見ればすべてが同じ重みの「指示」になります。この信頼境界の欠如が、あらゆる派生攻撃の出発点です。
直接と間接 — そして間接へのシフト
直接プロンプトインジェクション（約45%）
利用者自身がモデルへの入力で挙動を変えさせるタイプ。「これまでの指示を無視して…」と命じる、いわゆるジェイルブレイクが代表例です。ガードレールの回避やシステムプロンプトの抽出を狙います。
間接プロンプトインジェクション（2026年は55%超）
より深刻なのがこちら。LLMが読み込む外部コンテンツ（Webページ・メール・ファイル・ツールの出力）に指示を仕込む手口です。攻撃者は利用者と直接やり取りせず、AIが“ついでに”読むデータに罠を埋めるだけ。2026年には観測される攻撃の55%超を占め、信頼できる情報源を経由するステルス性ゆえに成功率が20〜30%高いとされます。企業環境での成功事例の62%が間接経路でした。
AIブラウザがWebページの隠し指示に操られる のも、 MCPのツール説明文に悪意の指示が仕込まれる のも、すべてこの間接型です。AIエージェントが外部とやり取りするほど、攻撃面は広がります。
危険な組み合わせ「Lethal Trifecta」
間接プロンプトインジェクションが「実害」に変わる条件を、端的に示した考え方が Lethal Trifecta（致命的な三要素） です。AIエージェントが次の3つを同時に持つと危険、というものです。
- 機微データへのアクセス（メール、社内文書、認証情報など）
- 信頼できないコンテンツへの曝露（外部Web、受信メール、アップロード文書など）
- 外部へ送信する能力（メール送信、API呼び出し、Web取得など）
この3つが揃うと、「②に仕込まれた指示が、①のデータを③で持ち出す」という攻撃が成立します。逆に言えば、どれか1本を断てば致命傷は避けられる——これが設計上の重要なヒントになります。
実際の攻撃事例
- EchoLeak（CVE-2025-32711）：Microsoft 365 Copilot のゼロクリック間接プロンプトインジェクション。細工したメール1通を送るだけで、Copilotがそれを処理する際に隠し指示へ従い、OneDrive/SharePoint/Teamsのデータを未認証で外部に持ち出せた。本番のAIシステムで具体的なデータ漏えいに兵器化された初の既知ケースとされ、まさに Lethal Trifecta が成立した例。
- MCP経由のゼロクリックRCE：研究者が、 MCP を通じた間接プロンプトインジェクションで、エージェント型IDEに対するゼロクリックのリモートコード実行を実証。2025年で最も技術的に重大な攻撃の一つ。
- KYC（本人確認）パイプラインの汚染：パスポート画像の隠しテキストに指示を埋め込み、OCR結果を無検査で処理するAI抽出エージェントを操作。1枚のアップロードで、他の20人の顧客のPIIが読み取られ攻撃者の項目に書き込まれた。
図解案：間接インジェクションとLethal Trifecta
[攻撃者] 指示を仕込む
│ （Webページ/メール/文書/ツール説明文の中に隠す）
▼
[②信頼できないコンテンツ] ── AIが読み込む
│ 「指示」と「データ」を区別できない
▼
[AIエージェント] ──┬─ ①機微データにアクセス
└─ ③外部へ送信
│
▼
攻撃者へデータ流出（=実害）
★ ①②③が揃う＝Lethal Trifecta。1本断てば致命傷を回避防御策とその限界
重要な前提として、OpenAIですら「プロンプトインジェクションは完全には解決できないだろう」と述べています。万能の特効薬はなく、多層防御で成功率を下げるのが現実解です（ある研究では層を重ねて成功率を73.2%→10%未満に低減）。
入力・プロンプト側
- ユーザー入力にシステム指示を上書きさせない：プロンプトの足場（scaffolding）を固め、信頼境界を明示する。
- Spotlighting：信頼できないデータを
<<<DATA>>>のような区切りで囲み「これは指示ではなくデータ」と示す。実験では成功率を50%超→2%未満に低減。ただし区切りを偽装・無視させる回避も示されており、単独では不十分。
ガードレール（入出力検査）
- 専用のガードレールモデルで悪意ある入力や逸脱した出力を検出・フィルタする。
- 注意点として、ガードレールは過剰防御（over-defense）に陥りやすい。トリガー語に反応して正常な入力まで弾く問題があり、InjecGuard 等が偏り低減を研究している。安全性と実用性のトレードオフは依然大きい。
アーキテクチャ側（より本質的）
- CaMeL（Defeating Prompt Injections by Design, 2025）：制御フロー（ユーザーの意図）とデータフロー（外部の内容）を構造的に分離し、値に権限（capability）メタデータを付与。専用インタプリタでポリシーを強制し、LLM自体を変えずに保証を与える設計アプローチ。
- 最小権限：エージェントに渡す権限・トークン・ツールを絞る。 Langflow のように、寛容な設定が被害を増幅する。
- 人間による承認（Human-in-the-loop）：外部送信・コード実行・送金など不可逆な操作は実行前に人間が確認する。
- Lethal Trifecta を崩す：機微データ・未信頼コンテンツ・外部送信のうち少なくとも1本を構造的に断つ（例: 外部送信先を許可リストに限定）。
まとめ
プロンプトインジェクションは、「LLMが指示とデータを区別できない」という設計上の本質に根ざすため、入力フィルタだけでは塞ぎきれません。とくに間接型がいまの主戦場で、EchoLeak のようにゼロクリックで実害に至ります。守りの要点は——システム指示を上書きさせない、Spotlightingやガードレールで層を重ねる、CaMeLのように制御とデータを分離する、最小権限と人間の承認を組み込む、そしてLethal Trifectaのどれか1本を断つこと。
個別の現れ方は MCP・ AIブラウザ・ Langflow の各記事で、AIが攻撃に使われる側面は Claude Mythos で、Webアプリ全体のリスクは OWASP Top 10 で扱っています。あわせて読むと、AI時代のセキュリティの全体像がつかめます。
※ 本記事の統計値・研究・CVEは、OWASP／Microsoft／Lakera／各研究者の公表内容および論文・報道に基づきます。研究と対策は急速に進展するため、実装時は最新の情報をご確認ください。