プロンプトインジェクションとは？間接注入と対策を解説

プロンプトインジェクションは、AI（大規模言語モデル）に読ませる文章の中に指示を紛れ込ませ、開発者が意図した動作を乗っ取る攻撃です。利用者が直接入力する「直接注入」だけでなく、AI が読み込む Web ページ、メール、ファイル、ツールの説明文に仕込まれた指示が実行される「間接注入」があり、AI が自律的にツールを使うエージェントの時代には後者が主戦場になっています。この記事では、OWASP の定義と分類、コーディングエージェントや MCP に特有の新しい入口、なぜ完全には防げないのか、モデル・アプリケーション・運用の 3 層で何ができるか、各社の実装、そして gaipack 自身がどこに線を引いているかを、一次情報にもとづいて解説します。攻撃の再現手順や具体的な注入文は扱いません。

プロンプトインジェクションとは何か：定義と OWASP の位置づけ

プロンプトインジェクションの定義として最も参照されているのは、OWASP（Open Worldwide Application Security Project）が公開する Top 10 for LLM Applications 2025 の第 1 項目 LLM01 です。そこでは「ユーザーのプロンプトが LLM の振る舞いや出力を意図しない形で変えてしまう脆弱性」と定義されています。2023 年の初版から 2025 年版まで一貫して第 1 位に置かれており、LLM を組み込んだアプリケーションで最も基本的なリスクと位置づけられています。

仕組みは単純です。LLM は「開発者が書いた指示」と「処理対象の文章」を、どちらも同じ自然言語のトークン列として受け取ります。人間なら「この部分は上司の指示、この部分は顧客からのメール」と区別しますが、モデルにはその境界が構造的には存在せず、文章の中に命令文があれば、それに従う確率が生まれます。SQL インジェクションが「データとして渡した文字列が命令として解釈される」問題だったのと同じ構図で、違いは、SQL には引用符のエスケープという確実な対処があるのに対し、自然言語には「ここから先は命令ではない」を確実に伝える構文が無いことです。

似た言葉に「ジェイルブレイク」があります。OWASP はジェイルブレイクを、攻撃者がモデルの安全対策を丸ごと無視させる「プロンプトインジェクションの一形態」と説明しています。実務上は、利用者本人がモデルの制限を外そうとするのがジェイルブレイク、第三者が仕込んだ文章でアプリケーションの動作を乗っ取るのがプロンプトインジェクション、と分けて考えると対策の主体が見えやすくなります。この記事は後者を扱います。

日本でも、総務省のサイバーセキュリティタスクフォースに置かれた AI セキュリティ分科会が 2025 年 10 月 9 日の第 2 回会合で「プロンプトインジェクションの事例」と対策の資料を公開しており、公的な検討の対象になっています。

2025 年 12 月には、OWASP が自律的に動く AI エージェント向けの Top 10 for Agentic Applications を公開しました。100 人以上の研究者と実務者が 1 年以上かけてまとめたもので、第 1 項目 ASI01 は「エージェントのゴール乗っ取り」です。「エージェントが読む内容を通じて、攻撃者がエージェントの目的や判断の経路を書き換える」と説明されており、プロンプトインジェクションが「出力を変える」問題から「行動を変える」問題へ広がったことを表しています。

直接と間接：プロンプトインジェクションとは何が違う攻撃なのか

OWASP は注入の経路で 2 つに分けています。

直接注入は、利用者がアプリケーションの範囲を超えた出力を引き出す問題で、被害者は主に運営側です。間接注入は、利用者が何も悪いことをしていないのに、AI が読んだ第三者のコンテンツによって利用者自身が被害を受ける問題で、被害者は利用者です。対策の設計で先に考えるべきなのは間接注入のほうで、理由は、利用者の入力は運営側が見張れても、AI が読みに行く世界中のコンテンツは見張れないからです。

OWASP はさらに、文章以外の経路にも言及しています。画像に指示を隠して、無害な文章と一緒に渡す「マルチモーダル注入」で、「モダリティ間の相互作用を悪用し、良性の文章に添えられた画像に指示を隠す」といった手口が挙げられています。画像や音声を読めるモデルが増えるほど、検査すべき入力の種類も増えます。

エージェント時代の入口：ファイル・Issue・Web・ツール記述

チャットボットの時代の間接注入は「要約させたページに変な指示が書いてあった」で済みましたが、コーディングエージェントや業務エージェントは、読んだ内容にもとづいてファイルを書き換え、コマンドを実行し、外部サービスへリクエストを送ります。入口も増えました。

リポジトリの中身そのものが入口になるのがコーディングエージェント特有の点です。README、コードのコメント、テストデータ、そして AGENTS.md や CLAUDE.md のような指示ファイルは、エージェントがそのまま文脈として読み込みます。他人のリポジトリをクローンして「このコードを説明して」と頼んだ時点で、そこに書かれた指示はエージェントに届いています。GitHub の Issue や PR コメントを読んで修正するエージェントなら、誰でも書き込める Issue の本文が入口になります。

MCP（Model Context Protocol）にはさらに固有の経路があります。MCP サーバーは各ツールの「説明文」をクライアントに渡し、モデルはその説明文を読んでツールの使い方を決めます。Invariant Labs は 2025 年 4 月 1 日に、この説明文に利用者には見えずモデルには見える指示を仕込む「ツール汚染攻撃（Tool Poisoning Attack）」を報告しました。派生として、いったん承認されたあとで説明文を書き換える「ラグプル」、悪意あるサーバーの説明文が別の信頼済みサーバーに対するモデルの振る舞いまで変える「サーバー間シャドーイング」も挙げられています。MCP の仕様そのものにも Security Best Practices の文書があり、2026 年 7 月 28 日版では、OAuth プロキシの混乱した代理人問題、トークンの素通し、SSRF、ローカルサーバーの侵害などが、クライアントとサーバーそれぞれの「MUST」「SHOULD」つきで整理されています。MCP の仕組み自体は MCP とはの記事で解説しています。

エージェントを拡張する「スキル」も同じです。2026 年 2 月に公開された論文 Skill-Inject は、第三者が配布するスキルファイルに仕込んだ指示への耐性を 202 件のテストで測り、最前線のモデルでも最大 80% の攻撃成功率で、データの持ち出し、破壊的な操作、ランサムウェアに似た挙動が引き起こされたと報告しています。同月の OWASP エージェント版 Top 10 で「エージェント型サプライチェーンの脆弱性」（ASI04）と「メモリとコンテキストの汚染」（ASI06）が独立項目になったのは、こうした経路が現実の攻撃面になったからです。スキルの仕組みは Agent Skills とはの記事で扱っています。

なぜ完全には防げないのか：致命的な三要素

対策の前に、限界を先に押さえておく必要があります。OWASP は LLM01 の中で「モデルの動作の核にある確率的な性質を考えると、プロンプトインジェクションを完全に防ぐ方法があるかどうかは不明である」と明記しています。Anthropic の Claude Code のドキュメントも、防御策を列挙したうえで「これらの保護はリスクを大きく減らすが、すべての攻撃に完全に免疫のあるシステムは無い」と書いています。ベンダー自身が「防げる」と言っていない、という事実が出発点です。

この限界を設計に落とすうえで最も引用されている枠組みが、Simon Willison 氏が 2025 年 6 月 16 日に示した「致命的な三要素（lethal trifecta）」です。AI システムが次の 3 つを同時に持つと、攻撃者は「不審な文章を読ませるだけで」データを盗み出せる、という整理です。

• 私的なデータへのアクセス（ファイル、メール、データベースを読める）
• 信頼できないコンテンツへの接触（第三者が書いた文章や画像がモデルに届く）
• 外部への通信手段（Web へのリクエスト、メール送信、リンクの表示）

3 つが揃うと、信頼できないコンテンツに「私的なデータを取り出して、この URL に送れ」という指示が含まれていた場合に、モデルがそれに従う確率がゼロにならない、というのが問題の本質です。Willison 氏は「LLM はコンテンツの中の指示に従う」と述べ、95% の攻撃を止めると謳う防御製品について「Web アプリケーションのセキュリティで 95% は落第点だ」と評しています。利用者にできる唯一の実効的な対策は「三要素の組み合わせを避けること」で、つまり、信頼できないコンテンツを読むエージェントには私的データか外部通信のどちらかを渡さない、という設計上の割り切りです。

プロンプトインジェクション対策の 3 層：モデル・アプリ・運用

完全には防げない前提に立つと、対策は「1 つの決定打」ではなく「層を重ねて被害を小さくする」形になります。OWASP が LLM01 で挙げる 7 つの緩和策を、どこで実装するかで 3 層に分けると次のようになります。

モデル層は利用者側で手を出せる範囲が狭く、提供者の改善を待つ層です。アプリケーション層は、三要素のどれを切るかを決める層で、対策の効果が最も大きく出ます。運用層は、アプリケーション層の判断が守られ続けているかを確かめる層です。

アプリケーション層で特に効果が高いのは、「外部コンテンツを読む処理」と「権限を持つ処理」を分けることです。Web ページの要約は権限の無い別のコンテキストで行い、その結果を本体が「データ」として受け取る構成にすれば、ページの中の指示が本体の権限で実行される経路を断てます。もう 1 つは、外部への送信、ファイルの削除、決済といった取り消せない操作の直前に人間の確認を置くことで、これは OWASP の「高リスクな操作には人間の承認を要求する」に対応します。権限の絞り方と確認の置き方はコーディングエージェントの権限設計の記事で具体的に扱っています。

各社の実装で見る防御：Claude Code・Gemini・Claude for Chrome

3 層の考え方は、主要な製品の公開情報にそのまま現れています。2026 年 9 月時点の公式ドキュメントから、対策を「どの層で何をしているか」で並べます。優劣ではなく、それぞれの製品が置かれた前提の違いとして読んでください。

3 つの読み取りができます。第 1 に、どの製品も「検知」だけに頼らず、権限の分離と人間の確認を同時に置いています。第 2 に、Claude for Chrome の数字が示すように、対策後も攻撃成功率はゼロではなく、ベンダーはその数字を公開したうえで「対策を重ねる」と述べています。第 3 に、Claude Code の「Web 取得を隔離したコンテキストで行う」設計は、前の章の「外部コンテンツを読む処理と権限を持つ処理を分ける」をそのまま製品にしたものです。

Claude Code のドキュメントには、信頼できないコンテンツを扱うときの利用者側の実践も 5 項目で示されています。提案されたコマンドを承認前に確認する、信頼できないコンテンツを直接パイプで渡さない、重要なファイルへの変更を確認する、外部の Web サービスとやり取りするときは仮想マシンで動かす、不審な挙動を報告する、の 5 つです。ツール側の対策と利用者側の実践が揃って初めて、3 層のうちのアプリケーション層と運用層が埋まります。

gaipack の実践：防ぎきれない前提で線を引く

gaipack は AI 駆動開発（AIDD）を自社の開発プロセスに組み込んでいます。プロンプトインジェクションへの対策も特別な製品ではなく、ここまで整理した 3 層をそのまま自分たちの運用に落とした線引きとして持っています。

運用層では、使ってよい AI ツールと外部サービスとの接続を承認制で管理しています。三要素のうち「私的データへのアクセス」と「外部への通信」にあたるのが接続の設定なので、どこに何がつながっているかを把握できる状態を保ち、定期的に見直すことが土台になります。アプリケーション層では、エージェントが加えた変更を必ず人のレビューに通す構造にしています。変更はプルリクエスト経由に限定し、レビューを通らなければ反映されません。注入を「検知する」よりも「注入されても取り返しがつく構造にする」ほうが、効果が安定して出ました。

指示ファイルにも同じ考え方を適用しています。AI の作業ルールを書いた AGENTS.md のようなファイルは外部の目に触れることがあるため、載せてよい情報の範囲をあらかじめ決めておき、逆に外部から持ち込んだ指示ファイルはコードと同じ基準でレビューします。入力元が信頼できる相手であっても、入力の中身をそのまま指示として実行させない、というのが間接注入への一番安い保険だと考えています。こうした AI 利用の統制を ISO/IEC 42001 の枠組みで組織に定着させる支援は gaipack ガバナンスで、ガバナンスの考え方は ISO/IEC 42001 で回す AI ガバナンスの記事で扱っています。

プロンプトインジェクションとは何かに関するよくある質問

AI エージェントの導入をご検討中のお客様から、実際にいただくことの多い質問をまとめました。

プロンプトインジェクションとジェイルブレイクの違いは何ですか？

OWASP はジェイルブレイクをプロンプトインジェクションの一形態と位置づけています。実務上は、利用者本人がモデルの安全対策を外そうとするのがジェイルブレイク、第三者が仕込んだ文章でアプリケーションの動作を乗っ取るのがプロンプトインジェクション、と分けると対策の主体がはっきりします。

間接プロンプトインジェクションとは何ですか？

AI が処理する外部コンテンツ（Web ページ、メール、PDF、リポジトリ内のファイル、ツールの説明文）に仕込まれた指示によって動作が変わる攻撃です。利用者が何も悪いことをしていなくても成立し、AI がツールを使うエージェントでは、読んだ内容にもとづいてファイル操作や外部送信まで行われる点が直接注入との違いです。

プロンプトインジェクションは完全に防げますか？

現時点では防げません。OWASP は「完全に防ぐ方法があるかは不明」と述べ、Anthropic も「すべての攻撃に免疫のあるシステムは無い」と明記しています。対策は検知だけに頼らず、権限の分離、人間の確認、被害が出ても取り返せる構造を重ねることになります。

プロンプトインジェクションは違法ですか？

日本にプロンプトインジェクションそのものを直接規定する法律はありませんが、行為の態様によっては不正アクセス禁止法や業務妨害、個人情報保護法などに該当し得ると解説されています。自社システムへのテストであっても、対象と範囲を明記した許可のもとで行い、法的な判断は法務や専門家に確認してください。

実際の事例はありますか？

OWASP のエージェント向け Top 10 は ASI01 の例として、メールに仕込んだ指示で企業向け AI アシスタントから情報を持ち出せた 2025 年の事例（EchoLeak として報告されたもの）を挙げています。MCP のツール説明文経由の注入は 2025 年 4 月に Invariant Labs が、スキルファイル経由の注入は 2026 年 2 月の Skill-Inject 論文が実証しており、総務省の AI セキュリティ分科会も 2025 年 10 月に事例集を公開しています。

まとめ

• プロンプトインジェクションは、AI に読ませる文章の中の指示が意図しない動作を引き起こす脆弱性で、OWASP の LLM 向け Top 10 で 2023 年から第 1 位、2025 年 12 月のエージェント向け Top 10 でも第 1 項目です
• 直接注入より間接注入のほうが設計上の課題で、エージェント時代にはリポジトリ内のファイル、Issue、Web ページ、MCP ツールの説明文、スキルファイルが入口になります
• 完全に防ぐ方法は無いと OWASP とベンダー自身が述べており、「私的データ・信頼できないコンテンツ・外部通信」の三要素を同時に持たせない設計が最も再現性の高い対策です
• 対策はモデル・アプリケーション・運用の 3 層で重ね、外部コンテンツを読む処理と権限を持つ処理の分離、危険な操作前の人間の確認、ツールとコネクタの台帳管理を組み合わせます
• gaipack 自身も、AI ツールと外部接続の承認制、変更を人のレビューに通す構造で、注入されても取り返しがつく状態を先に作っています

gaipack では、AI 利用の統制体制を ISO/IEC 42001 の枠組みで構築する gaipack ガバナンスと、シャドー AI を抑止しつつ安全に生成 AI を使える環境を提供する gaipack セキュアをご用意しています。AI 駆動開発の全体像は AI駆動開発の記事にまとめていますので、あわせてご覧ください。