プロンプトインジェクションとは？RAG・MCP時代の情報漏洩リスクと対策

公式情報の確認：2026.10.22。公式文書に基づく整理で、個別アカウントの設定確認や攻撃の実機検証は行っていません。

プロンプトインジェクションとは、AIへの入力に含まれる指示が、本来の方針や依頼とは違う回答・操作へ誘導する問題です。直接入力だけでなく、Webページ・PDF・メール・RAGの参照文書・ツールの返答も入口になります。

対策はプロンプトの工夫だけでは足りません。特に、読み取り専用でも、読んだ機密情報がURLや検索語句などを通じて外へ出る可能性があります。読める情報、変更できる対象、送信先、承認を分けて整理します。

先に確認すること：①機密情報を必要以上に渡さない → ②読取・変更・外部送信を別々に制限する → ③影響の大きい操作は内容を見て承認する。すでに不審な操作がある場合は、処理を止めて実行結果を確認してください。

01プロンプトインジェクションの意味と種類

プロンプトインジェクションは、AIへの入力に含まれる指示によって、本来の方針や依頼とは違う回答・操作へ誘導される問題です。被害は誤った要約だけとは限りません。秘密の開示、不適切なツール利用、ファイルの変更などにつながる可能性があり、影響はAIが扱うデータと権限によって変わります。

用語の使い方には資料ごとの差があります。この記事ではOWASPの整理に沿い、直接型・間接型は「命令が入る入口」、ジェイルブレイクは「安全上の制約を回避する狙い」として分けます。別々で重ならない三種類という意味ではありません。

直接型・間接型とジェイルブレイクの整理
用語	何を表すか	例の考え方
直接型	ユーザー入力など、AIへ直接渡される入力から意図しない動作へ誘導される。	公開チャットボットへの入力で、許可されない情報や操作を求める。
間接型	Webページ、PDF、メール、RAG文書、ツールの返答などから命令が入り込む。	資料の要約中に、資料内の文が別の操作をする指示として扱われる。
ジェイルブレイク	モデルの安全制約を回避させようとする。OWASPはプロンプトインジェクションの一形態として説明する。	安全上の制約を無視させる狙いに着目した分類で、入口の分類とは軸が違う。

根拠：OWASP｜LLM01:2025 Prompt Injection

普通の指示ミスやハルシネーションとの違い

依頼が曖昧で希望と違う文章が出ることは、通常の指示設計の問題です。AIがもっともらしい誤情報を生成するハルシネーションも、必ずしも命令混入が原因ではありません。プロンプトインジェクションでは、入力の中の指示が本来の方針や目的を変える点に注目します。誤った出力だけを見て、原因をプロンプトインジェクションと断定しないでください。

外部資料に命令らしい文があるだけで、必ず攻撃が成功するわけでもありません。読ませた内容、モデル、権限、ツールの制御などによって結果は変わります。この記事の例は構造を説明するもので、各製品で攻撃が成功したという実測結果ではありません。

根拠：OpenAI｜Understanding prompt injections: a frontier security challenge

02RAG・Web検索・ファイル読取で起きること

間接型では、利用者が「この資料を要約して」と普通に依頼していても、AIが読む側の資料に別の指示が含まれます。本文だけでなく、コメント、メール、添付ファイル、画像から読み取った文字、検索結果、ツールの説明や返答も、AIに渡れば入力になり得ます。

資料の内容と、操作を許可する指示を分けます

例えば、資料に「要約の前に別の情報を確認して送る」という趣旨の文があっても、その文は利用者の許可ではありません。資料の引用や手順説明として分析することと、AI自身がその操作を実行することを分けます。社内資料や有名サイトであっても、その中の文章に権限を追加する力を持たせないことが重要です。

入力を区切り、出所を示し、「参照データとして扱う」と伝える方法は補助になります。ただし、ラベルや区切り文字だけで命令混入を強制的に防ぐことはできません。モデルが誤って扱った場合にも、権限外の取得や送信を実行側が止める設計が必要です。

根拠：OWASP｜LLM Prompt Injection Prevention Cheat Sheet

ベクトル検索の関連度は、安全性の判定ではありません

RAGは、質問に関係する文書を検索し、回答の材料としてAIへ渡します。ベクトルデータベースで意味が近い文書が見つかっても、その文書が正確・最新・安全か、利用者に閲覧権限があるかは別の確認です。社内に保存した文書にも、外部由来の内容や後から編集された内容が含まれます。

登録時：出所、担当者、変更履歴、情報の分類を確認し、文書を更新できる人も制限します。
検索時：利用者ごとの閲覧権限を、元文書から切り出した断片にも適用します。許可されない情報は、AIに渡す前に除外します。
更新・削除時：元文書だけでなく、検索用の断片、索引、回答キャッシュにも変更を反映します。
回答時：出典をたどれるようにし、重要な内容は原文と照合します。引用が付いているだけで安全と判断しません。

根拠：OWASP｜RAG Security Cheat Sheet

出所や更新日の確認は、誤情報や改ざんの発見に役立ちます。ただし、正確な資料の中に命令が紛れ込むこともあるため、情報の正確さの点検と命令混入への対策は併用します。

03読み取り専用でも情報漏洩は起こり得る

読み取り専用にすれば、対象データの書き換えや削除のリスクは減らせます。しかし、機密情報を取得できること自体が重要な権限です。元データを一切変更しなくても、読み出した内容が外へ送られれば情報漏洩になります。

「ページを読む」「画像を表示する」も通信です

Webページや画像を取得するとき、接続先にはURLなどのリクエスト情報が渡ります。AIが秘密の内容をURLのパスやクエリへ含めて取得してしまうと、その内容が相手側へ送られ得ます。検索語句や外部ツールの引数に機密情報が入る場合も、どこへ送信されるかを確認する必要があります。

AIが、許可された範囲の社内資料やメールを読みます。
別の外部コンテンツに含まれる指示が、AIの次の動作へ影響します。
AIが、読んだ情報を含むURLや検索語句などを組み立てます。
外部取得や検索が実行されると、機密情報がその送信先へ渡る可能性があります。

これは流出経路の説明例です。特定の製品で現在この操作が無条件に通ることや、すべての読み取りで流出することを示していません。

根拠：OpenAI｜Preventing URL-Based Data Exfiltration in Language-Model Agents（2025年1月20日）

Microsoftの公式資料には、2023年にBing Chatが画像取得のURLを通じて会話データを送ってしまう事例が説明されています。同じ資料は、その特定の問題は修正済みと明記しています。過去の事例を、現行製品の未修正の脆弱性として扱わないでください。

根拠：Microsoft｜Prompt Injection（Direct / Indirect）

注意「読取は自動、書込だけ承認」では、機密情報の外部送信を見落とします。操作名だけでなく、読む情報・渡すデータ・送信先の組み合わせで判断してください。

別々に確認する読み取りと送信
確認対象	問い	制御の例
データの取得	AIは誰の、どの情報まで読めるか。	文書・フォルダ・組織ごとの閲覧権限を実行側で適用する。
取得した情報の行き先	回答、検索、URL、画像、ツール引数のどこへ入るか。	機密情報を外部へ渡す経路を分け、必要な送信先と内容だけ許可する。
実際の通信	何に接続し、どのデータが送信されるか。	送信前に完全な宛先と引数、リダイレクト先を検査し、許可しない出口をネットワーク側で止める。

ドメインの許可リストも一つの対策ですが、それだけで十分とは限りません。許可したドメインに、利用者が内容を置ける場所や別サイトへの転送経路がある場合もあります。取得先の名前だけでなく、URL全体と送信データ、実際の接続先まで含めて判断します。

根拠：OpenAI｜Preventing URL-Based Data Exfiltration in Language-Model Agents（2025年1月20日）、OWASP｜AI Agent Security Cheat Sheet

04MCP・API・サンドボックスで確認する境界

MCPは、AIアプリと外部のデータ・ツールをつなぐための仕組みです。APIやMCPを使っただけで、安全性が保証されたり、必ず危険になったりするわけではありません。接続先が何者で、どのデータと操作にアクセスできるのかを確認します。

ツールの説明と実際の権限は同じではありません

ツールが「読み取り専用」と説明していても、その表示だけを権限設定の代わりにはできません。MCP仕様でも、信頼できるサーバーからでないツール注釈は信頼しないよう求めています。実際のAPI権限、接続アカウント、ファイルやネットワークの制限を確かめる必要があります。

根拠：MCP｜Tools（2025-06-18版仕様）

接続前に確認する4つの境界
境界	確認すること	避けたい設定
閲覧	誰の権限で、どのデータを読めるか。	全員が同じ管理者アカウントで、全資料へアクセスできる。
変更	どのファイル・記録を、どの操作で変更できるか。	要約だけの作業に、編集・削除・権限変更も許可する。
外部送信	メール、URL、検索、API呼出しで、何をどこへ送れるか。	「GETだから安全」「読取ツールだから承認不要」と一括で扱う。
実行環境	コードやツールが、どの環境・資格情報・通信範囲で動くか。	隔離の対象外のツールや、広い秘密へのアクセスを見落とす。

APIキーは、モデルへ見せずに接続側で管理します

コード相談のために秘密のキーやトークンを貼る必要はありません。認証情報は接続側の安全な保管機構で扱い、モデルへ渡す説明やツール結果には実際の値を含めない構成を選びます。環境変数に保存していても、AIがそのファイルやプロセスの値を読めるなら、文脈へ入る可能性を別途考える必要があります。

すでにキーの露出が疑われる場合は、会話やファイルを消すだけで終えず、提供元の手順で失効・交換と利用履歴確認を行います。詳しい対応はAIセキュリティ入門のAPIキー漏洩対応で整理しています。

根拠：OWASP｜Secrets Management Cheat Sheet、OpenAI｜Best practices for API key safety、GitHub｜Remediating a leaked secret

サンドボックスは、設定された範囲に効く対策です

サンドボックスは、プログラムがアクセスできるファイルや通信先などを隔離・制限する仕組みです。OSなどで強制される制限は有用ですが、隔離を有効にしただけで、AIのすべての操作や情報漏洩を防げるわけではありません。何を隔離しているか、秘密を読めるか、外部通信を許しているか、例外や対象外のツールがあるかを確認します。

例えばClaude CodeのBashサンドボックスはシェルコマンドが対象で、公式資料はファイルツール、MCPサーバー、フックがその外で動くことを説明しています。これは製品固有の範囲の例であり、他のサンドボックスが同じ仕様という意味ではありません。

根拠：Anthropic｜Configure the sandboxed Bash tool

05対策はデータ・権限・承認・記録を組み合わせる

プロンプトを強く書くことだけに頼らず、AIが誤った提案をしても、そのまま実行されない構成を目指します。最新の承認済みモデルや検知機能への更新も役立ちますが、それだけで安全と判定せず、利用するデータとツールの条件で確認します。

入れる情報を減らします。秘密の値を除き、個人情報・未公開情報は必要範囲へ絞ります。閲覧権限は、検索や取得の段階で適用します。
外部コンテンツを参照データとして扱います。出所を記録し、操作を許可する指示と分離します。フィルターや検知モデルは補助とし、見逃しと誤検知を想定します。
ツールの実行側で許可を確認します。利用者、対象、操作、引数、送信先が許可範囲内かを検査します。形式が正しいJSONでも、実行してよい内容とは限りません。
影響の大きい操作は、内容を見て承認します。送信・公開・削除・購入・権限変更のほか、機密情報の新しい送信先への転送も対象にします。
記録と停止手段を用意します。実行結果、承認、拒否、送信先を追えるようにし、異常時に連携や実行を止められるようにします。

根拠：OpenAI｜Understanding prompt injections: a frontier security challenge、OWASP｜LLM Prompt Injection Prevention Cheat Sheet、OWASP｜AI Agent Security Cheat Sheet

承認画面で確認するのは、AIの説明だけではありません

「安全なので実行します」という説明ではなく、実際の宛先・対象・内容・添付・変更差分を確認します。承認はその操作と引数に結び付け、実行直前に一致を検証する設計が必要です。資料やツールの返答に「ユーザー承認済み」と書かれていても、それを本人の承認として受け入れないようにします。

実行前の確認メモ

元の依頼：
実行する操作：
対象ファイル／データ：
外部の送信先・宛先：
送る情報・添付・URLや検索語句に入る情報：
変更・削除・費用の影響：
この操作を許可できる本人／担当者：
承認した内容と実行内容が同じか：
取り消し・停止方法：

コピー後、手元のメモに貼り付けて使えます。

利用場面ごとの始め方

個人利用：必要なメールやファイルだけを読ませ、無関係な連携を外します。返信案の作成と送信を分け、宛先と本文を確認します。
ブログ運営：参考ページやコメント内の指示を、公開操作の許可にしません。記事の下書きと公開を分け、リンク・引用・埋め込み・コードの内容を確認します。APIキーや未公開の顧客情報をコード相談へ混ぜないでください。
業務利用：利用者・部署・組織ごとの閲覧権限を維持し、送信先と承認範囲を決めます。操作ログには必要な記録を残しつつ、キーの全文や不要な機密本文を記録しないようにします。

不審な動きがあったとき

処理を止め、読ませた資料、提案された操作、実際に完了した操作を分けて確認します。ツールの完了記録や送信履歴を見て、提案だけだったのか、外部へ送信されたのかを切り分けます。機密情報が含まれる記録を公開の問い合わせや別のAIへそのまま貼らず、組織の担当者や公式サポートへ必要な範囲で相談してください。

自作システムの検証は、許可されたテスト環境とダミーデータで行います。通常の入力と不審な入力の両方について、権限外の読取・外部送信・承認前の操作が実行側で止まるかを確かめます。単に「AIが拒否と答えた」ことだけを成功条件にせず、実際のツール実行結果を確認します。

根拠：OWASP｜AI Agent Security Cheat Sheet、OWASP｜LLM Prompt Injection Prevention Cheat Sheet

本文の点検表は設計を整理するための例です。個別システムの安全性を認定したものではなく、テストを実施済みという意味でもありません。

06プロンプトインジェクションのよくある質問

普通にChatGPTやClaudeを使うだけでも危険ですか？

一般的な質問をしただけで、直ちに被害が起きるという意味ではありません。外部文書を読む機能、参照できる機密情報、外部へ送る経路、実行できる操作が増えるほど、確認する範囲も広がります。

RAGやMCPを使わなければ防げますか？

それだけでは防げません。直接入力や、貼り付けたメール・Webページ・ファイルも入口になり得ます。RAGやMCPを一律に避けるより、用途に必要な情報と権限、送信先を絞ることが重要です。

ジェイルブレイクとは別の攻撃ですか？

用語の整理には違いがありますが、本記事ではOWASPに沿って重なりのある概念として扱います。直接型・間接型は入力の入口、ジェイルブレイクは安全制約を回避する狙いという別の軸で整理できます。

読み取り専用なら、人の確認は不要ですか？

一律には判断できません。機密情報を読める範囲と、その内容が回答やURL・検索・外部APIなどへ出る経路を確認します。読取専用は書き換えの制限であって、情報漏洩しない保証ではありません。

プロンプトやガードレールで完全に防げますか？

完全に防げるとは言えません。指示、入力の分離、検知モデルなどは補助になりますが、権限と送信先の制御、承認、実行内容の検証を別の層で設けます。サンドボックスも、対象と設定された範囲を確認して使います。

命令らしい文を見つけたら、情報漏洩したということですか？

その文があることと、AIが従って外部送信したことは別です。読んだ内容、出力、ツールの引数、実行結果、送信先を確認して判断します。秘密の露出が疑われる場合は、処理を止め、担当者と提供元の手順に沿って対応してください。

07まとめ｜読める情報と、送れる先を別に絞る

プロンプトインジェクションの対策では、AIが読む内容を選ぶだけでなく、誤った指示に影響された場合に何を実行できるかまで確認します。読み取り専用という一つの表示だけで、安全性を判断しないことが重要です。

入口：直接入力、Web・PDF・メール・RAG・ツールの返答を区別し、参照データを権限付与の指示にしません。
出口：回答だけでなく、URL、画像、検索語句、APIの引数へ出る情報と送信先を確認します。
実行：最小権限、内容に結び付いた承認、実行側の検査と記録を組み合わせます。

読み取りと外部送信の確認に戻る →まず一つの連携について、読める情報と送れる先を書き出してみてください。

参考引用元・公式情報

2026年10月22日確認。提供元の公式文書とOWASPの一次資料を使用しています。本文の点検表と記入例は、それらをもとにした本記事の整理です。ユーザー報告を公式仕様として扱っていません。