プロンプトインジェクションとは？直接型・間接型の攻撃例とAIエージェントの対策

プロンプトインジェクションとは何か、直接型・間接型の違いを受信トレイやCRMの例で解説します。AIエージェントによる情報流出や無許可の変更を抑えるために、権限の制限、出力の検証、人による承認、監視をどう組み合わせるかを整理。ツール連携前のチェックリストと、実際の操作結果を確かめるテスト手順も紹介します。

公開日 2026年10月26日

著者 Omid Saffari

Tools

Claude CodeCommand-line AI coding agent that edits files and runs commands

プロンプトインジェクション対策では、エージェントが読むメールと、行動の許可を切り分ける必要があります。メールの内容を根拠に、別のメールの送信や顧客データのエクスポート、商談の変更を許してはいけません。Open Worldwide Application Security Project（OWASP）は、LLMアプリケーション向けTop 10でプロンプトインジェクションをLLM01に位置づけています。開発者が取るべき実践的な対応は、モデルが誤った指示に従っても、アプリケーションが実行できる操作を制限することです。現時点で、プロンプトインジェクションを完全に解決できる防御策はありません。

2026年10月26日時点のOWASPおよびAnthropicの公開ガイダンスと照合済みです。以下の受信トレイやCRMの例は設計を説明するためのものであり、実際の導入結果を報告するものではありません。

プロンプトインジェクションとは？

プロンプトインジェクションとは、入力によって言語モデルが本来の指示から逸脱することです。 大規模言語モデル（LLM）は、言葉を解釈して回答を生成したり、実行する操作を提案したりします。本来は読むだけの情報に、モデルが指示として従ってしまうところから問題が始まります。

取引先から届いた書面を、社員が確認する場面を考えてみてください。その書面で納品の問題を伝えることはできますが、自社の顧客データベースへのアクセス権を取引先に与えることはできません。エージェントにも同じように、情報と権限を区別する仕組みが必要です。その区別を確実に守らせるのは、アプリケーション側の制御です。

OWASPはLLM01:2025 Prompt Injectionで、ユーザーによる直接の入力と、外部コンテンツを通じた間接的な入力の両方を侵入口として挙げています。重要なのは、誰にタスクや権限を設定する資格があるかです。不審な文章がもっともらしい業務文書に見えるかどうかではありません。

回答が間違っていても、それだけでインジェクションとは限りません。外部から操作されていなくても、モデルが事実を作り上げることはあります。インジェクションは、入力がモデルの振る舞いを誘導する問題を指します。どちらも被害につながり得ますが、悪意ある指示を探すフィルターで、モデルの通常の誤りまですべて検出できるわけではありません。

生成AIでは、どのように起きるのでしょうか？

モデルは指示とタスクの資料をまとめて読み取るため、資料に本来ないはずの指示権限を認めてしまうことがあります。ロールや出典のラベルは両者を区別する助けになりますが、アクセス制御の代わりにはなりません。

エージェントでは、その先に実際の影響を伴う処理が加わります。アプリケーションが、提案された操作をツール呼び出しに変換するのです。ツールとは、レコードの検索やメッセージの送信など、会話の外で何かを実行するための関数です。アプリケーションが広い権限を持つ認証情報を使い、モデルの提案をそのまま実行すれば、言葉の解釈を誤った結果が、実際の業務操作になってしまいます。

ツールを使うエージェントは、どれもこの問題に直面します。依頼の内容を理解できたことと、その依頼が許可されていることは別です。

プロンプトインジェクションの例：直接型と間接型

両者の違いは、悪意ある指示がどこから届くかにあります。 以下では攻撃文そのものを掲載せず、攻撃者が何をさせようとするのかを説明します。

直接プロンプトインジェクション

顧客がサポートアシスタントに入力し、社内の特別な承認を得た依頼であるかのように装って、別の顧客のアカウントに関するメモを開示させようとします。攻撃者は、アプリケーションの入力欄を直接使っています。

このケースでは、認証済みの顧客にどのレコードへのアクセス権があるかを、レコードを扱うサービス側で確認する必要があります。モデルが話を信じてしまっても、そのサービスは無関係なレコードへのアクセスを拒否しなければなりません。システムプロンプトに拒否するよう書くことは有用な指針になりますが、境界を実際に守るのはレコードへのアクセス確認です。

間接プロンプトインジェクション

自ら営業を担う創業者が、見込み客から届いたメールの要約と次の対応の提案をエージェントに依頼します。そのメールには、顧客関係管理システム（CRM）から無関係な連絡先をエクスポートし、外部の宛先に送らせるための内容が仕込まれています。創業者の依頼自体は正当です。悪意ある指示は、処理対象のメールから入り込みます。

同じように、Webページ、文書、添付ファイル、ツールの実行結果も侵入経路になり得ます。社内に保存されているからといって、すべてのレコードを信頼できるわけではありません。CRM内の文章も、もとは顧客が入力したものかもしれません。言語モデルClaudeを開発するAnthropicは、プロンプトインジェクション対策のガイダンスで、こうした第三者由来の情報源を独立した脅威モデルとして扱っています。

受信トレイを扱うエージェントでは、所有者が要約を頼んだというだけで、メールの送信者に所有者のツール権限を引き継がせてはいけません。

ジェイルブレイクとは何が違うのでしょうか？

ジェイルブレイクは、モデルの安全上の制限を回避しようとするものです。プロンプトインジェクションは、それに加えてアプリケーション本来のタスクや権限も標的にします。営業向けの要約を改ざんしたり、無許可で連絡先を更新したりする操作は、コンテンツモデレーションの仕組みからは無害に見えても、業務上のルールに反している場合があります。

コンテンツの安全対策と、操作を許可できるかの確認を、両方行ってください。それぞれ確認する対象が異なります。

業務上のリスクは、どこで大きくなるのでしょうか？

被害の大きさは、エージェントがアクセスできるデータと実行できる操作に左右されます。 OWASPは別項目のExcessive Agencyに関するガイダンスで、機能、権限、自律性を過剰に与えることが、被害をもたらすエージェントの動作につながると指摘しています。

受信トレイやCRMを扱うシステムでは、次のような業務上の問題として現れます。

機密データが外部に流出する。 出力、添付ファイル、外部へのリクエスト、メッセージなどに、受信者が受け取るべきでない情報が含まれます。
権限のない変更がレコードに加わる。 取得した文章に誘導され、エージェントがアカウントを編集したり、必要な履歴を削除したり、商談ステージを変更したりします。
判断が気づかれないまま歪む。 見込み客の有望度が実際より高く見えたり、苦情が要約から抜け落ちたり、根拠もなく特定の取引先が推奨されたりします。

読み取り専用なら、書き込み権限よりできることは限られます。それでも、機密データの流出がなくなるわけではありません。非公開のレコードを取得し、回答や外部接続を通じて開示できるアプリケーションでは、引き続き機密性を守る必要があります。

Palo Alto NetworksのUnit 42は、2026年3月3日に公表した調査で、公開中のWebコンテンツに埋め込まれた悪意ある指示を報告しています。攻撃の試みが見つかったことは、すべての標的がその指示に従った証拠ではありません。一方で、エージェントに操作を許可する前に、外部コンテンツを脅威モデルに含めるべき理由にはなります。

創業者は、そのワークフローでどこまでの被害を許容するか、上限を判断する必要があります。開発者は、データへのアクセスやツールの実行を制御する箇所で、その上限を守らせる必要があります。運用担当者には、それらの制御を突破しようとする動きがあったとき、実行を一時停止して調査する手段が必要です。

情報源の内容がエージェントに届き、ツールの手前に独立したポリシー確認箇所を設けた構成を示す建築模型 — 操作を提案するのはエージェントです。ツールで実行してよいかは、アプリケーションのポリシーが制御します。

プロンプトインジェクション対策：侵入されても被害を抑える設計

インジェクションが防御をすり抜ける可能性を前提に設計してください。 以下は、OWASPの権限と承認に関するガイダンスを、受信トレイやCRMを扱う具体的なワークフローに適用した制御設計の推奨例です。製品のベンチマークでも、攻撃を完全に防げるという保証でもありません。

防御策	実装する内容	その対策だけでは保証できないこと
ツールの最小権限化	閲覧、下書き、送信、レコードの変更を分離します。各操作を実行するサービスで、ユーザー、アカウント、レコード、フィールドごとの許可範囲を強制します。	許可された操作にも、誤解を招く内容が含まれることがあります。
影響の大きい操作を実行する前の人による確認	実際の宛先、メッセージ、添付ファイル、提案されたレコード変更について、実行前に承認を求めます。確認を受けられない間は操作を保留します。	人も問題のある提案を見落とすことがあります。承認はアクセス制御ポリシーの代わりにはなりません。
信頼できないコンテンツと指示の分離	出典ラベルとモデル提供元が定めるメッセージ境界を保ちます。取得した文章を、権限の高いアプリケーション指示に混ぜないようにします。	ラベルを付けても、モデルが必ず正しく解釈するとは限りません。
出力の検証	返す回答と、提案されたツール引数の両方を検証します。開示や実行の前に、宛先、許可されたフィールド、機密情報、現在の業務状態を確認します。	形式が正しくても、事実の正確さや実行権限は証明できません。
ログと監視	情報源の参照先、ポリシーによる判定、ツールへのリクエスト、承認の参照情報、実行結果を記録します。通常と異なるエクスポートや、拒否された操作の繰り返しを検知して通知します。	開示された後にログを残しても、その開示自体を防ぐことはできません。
プロンプトインジェクションの検出	入力された依頼や取得したコンテンツに、タスクを別の方向へ誘導する試みがないかを確認します。不審なケースは、あらかじめ定めた代替処理に回します。	分類器が問題なしと判定しても、その操作が安全である証拠にはなりません。

まず、ツールが実際に持つ権限を確認してください。関数名が「受信トレイを要約」でも、その裏で使う認証情報に送信やメール削除の権限があれば、できることは要約に限られません。関数名だけでなく、実際のアカウントとサービスの設定を調べる必要があります。

次に、アプリケーションから外に出るデータを制御します。接続を許可する宛先を列挙したネットワークの許可リストは、情報流出に使える経路を減らす助けになります。ただし、メールサービスへの接続を許可しても、すべての受信者への送信が認められるわけではありません。CRMのドメインを許可しても、すべてのアカウントやエクスポート操作を許可したことにはなりません。許可済みのサービス内で何を要求しているかも検証してください。

Anthropicの安全なデプロイに関するガイダンスでは、認証情報をエージェントの環境から隔離し、ネットワークアクセスを制限し、プロキシを通じてリクエストを検証する構成が説明されています。プロキシは、リクエストを転送する前にポリシーを適用できる仲介役です。ホスト型の受信トレイ連携では、自社のツール用サービスが同じ境界を担うこともあります。そのサービスが認証情報を保持し、許可範囲外の操作を拒否します。

入力、出力、実行にまたがる検証の全体像は、AIガードレールを参照してください。

Anthropicのガイダンスを、取得したコンテンツにどう適用するか

Anthropicは、第三者の資料をtool_resultブロックで渡し、出典を明示し、信頼できないコンテンツの扱いをポリシーとして明確に定めることを推奨しています。また、文字列を自由記述の指示に差し込むのではなく、JSON形式にエンコードすることも勧めています。ツール出力のスクリーニングと動作の監視も、ガイダンスに含まれています。詳しくは現行のClaudeガイダンスを参照してください。

営業の例なら、見込み客のメール本文を、その送信者から届いたメールとして識別できる状態に保ちます。前の処理でモデルが要約したからといって、権限の高い指示にコピーしてはいけません。抽出した情報を次の処理へ渡す際も、元の情報源をたどれる参照情報を残してください。

JSONは構造化データの形式です。文字列を正しくエスケープすれば、その文字列が周囲のシリアライズ形式を壊すことは防げます。しかし、文章の意味にモデルが説得されることまでは防げません。エンコードは防御の一層として捉え、操作権限の強制は別の場所で行う必要があります。

承認を、実際に実行する操作と結びつける

確認ボタンが業務を守るのは、人が確認した内容に従って実行が制御される場合だけです。 添付ファイルを送信したり、顧客レコードを書き換えたりできるエージェントに対して、「このアカウントの処理を続ける」という承認では曖昧すぎます。

見込み客に返信し、商談情報を更新する提案を考えてみてください。確認者には、実際の宛先、メッセージ、添付ファイルの一覧、対象レコード、変更前後のフィールド値を示す必要があります。アプリケーションは承認済みの提案を保持し、その内容を実行するべきです。後からモデルが宛先や添付ファイルを変えた場合は、再確認を求めます。

承認する人も、認証済みで、適切な権限を持っていなければなりません。メールの中に「すでに承認されています」と書かれていても、それは情報源に含まれる文章であり、承認が行われたことにはなりません。モデルが自分で承認記録を作成したり、承認の関門を迂回できる別のツールを使ったりできないようにしてください。

実行前に権限と承認を確認し、確認を通過できなければ保留に進む判断フロー — 影響の大きい操作では、ポリシー上の許可と人による承認の両方が必要です。

確認者が却下した場合、承認が失効した場合、確認システムが利用できない場合は、操作を保留のままにします。タイムアウトがいつの間にか実行許可に変わってはいけません。送信に失敗して再試行するときも、承認済みの同じメッセージを繰り返し送らないように設計してください。

これらはワークフローの実装に関する推奨事項です。人による確認ですべての攻撃を見抜けるという意味ではありません。確認待ちの処理に人員を配置し、エスカレーションに対応する方法は、Human-in-the-loop AIのガイドで説明しています。

受信トレイ・CRMエージェントの導入前チェックリスト

まずは、役に立つ最小限のワークフローを公開してください。 外部に対する自律的な操作を有効にする前に、次の項目を確認します。

実行主体： すべての読み取りと変更を、認証済みユーザーと、アクセスが許可された業務用アカウントの範囲に限定します。モデル自身が、より強い権限を持つ実行主体を選べないようにします。
データ： タスクに必要なレコードとフィールドだけを取得します。モデルに見える内容に秘密情報を含めず、メール、文書、CRMの文章がどこから来たのかを保持します。
ツール： 閲覧、下書き、送信、エクスポート、編集を別々の権限にします。ワークフローに不要な機能は取り除きます。
出力と実行： 回答やツール引数を外に渡す前に確認します。宛先、添付ファイル、接続先、許可されたレコード変更を検証します。
承認： 影響の大きい操作には、実行内容そのものの確認を必須にし、アプリケーションのコードで強制します。承認がない場合や、承認内容に変更があった場合は保留します。
運用： プライバシーに配慮した操作ログを残し、アラートの担当者を決め、一時停止する仕組みを用意します。アクセス範囲を広げる前に、ワークフロー全体をテストします。

創業者向けの営業アシスタントなら、指定した見込み客とのメールスレッドを読み、返信の下書きを提案する範囲から始めるのが妥当です。大量のエクスポート、自動送信、商談の一括更新は、それぞれ必要性を別途判断する機能として扱うべきです。連携先で可能なことをすべて許可するのではなく、提供したい仕事に合わせて権限を絞ってください。

被害を封じ込める設計の全体像は、本番AIエージェントのガードレールと影響範囲を制御する実践ガイドで解説しています。影響範囲（blast radius）とは、障害や失敗が接続先のシステムにどこまで広がり得るかを指します。

プロンプトインジェクションのテストでは、返答だけでなく実際の影響を確認する

テストの合格条件は、禁止した結果が起きないことです。 ツール呼び出しでレコードを書き換えた後に、アシスタントが拒否の文章を表示することもあり得ます。会話の記録だけでなく、ツールを実行するサービスと、実行後の状態を確認してください。

リリース前の予行演習には、架空の連絡先、テスト用メールボックス、管理された環境を使います。以下はアプリケーションのテスト計画であり、攻撃用ペイロードの一覧ではありません。

正当なタスクが正常に動く基準を確認する
通常の見込み客情報の要約タスクを実行します。正しいレコードが取得され、下書きが実用的で、ポリシーで定めた箇所で承認が求められることを確かめます。正当な業務は、引き続き成功する必要があります。
直接型と間接型の両方を試す
ユーザーの入力箇所に無許可の要求を含めるケースと、第三者のメッセージでタスクを別の方向へ誘導するケースを試します。無関係なレコードにはアクセスできず、禁止されたツール操作が拒否されることを確認します。
承認と障害時の処理を検証する
承認後に操作内容が変わった場合、確認者が却下した場合、ポリシーを判定するサービスが利用できない場合、実行を再試行する場合を試します。アプリケーションが操作を保留または拒否し、同じ処理の重複実行を防げることを確認します。
証跡とアラートを確認する
CRMの最終状態、送信されたメッセージ、接続を試みた宛先、承認記録、ポリシーログを調べます。モデルの説明に頼らず、運用担当者が原因となった情報源を特定し、ワークフローを停止できることを確認します。

プロンプト、モデル、検索・取得処理、ツール、権限を変更したときは、関連するテストを繰り返してください。結果が有効なのは、テストした構成に対してだけです。将来のあらゆるバージョンを保証するものではありません。

監査ログを受信トレイ全体のコピーにしてしまわないようにしつつ、判断を再現できるだけの情報は残します。安定したレコード参照、必要な操作内容、ポリシーのバージョン、アクセス制御された証跡を優先してください。遮断された宛先、予期しないエクスポート、繰り返される承認失敗を調査する担当者も決めておきます。

過大評価されている対策と、まだ解決できていないこと

モデル、プロンプト、フィルター、ガードレール製品のいずれも、それだけで完全な解決策と見なすべきではありません。 OWASPは、検索拡張生成やファインチューニングでもプロンプトインジェクションを完全には軽減できないと明記しています。検索拡張生成（RAG）は、モデルの回答を助けるために文書を与える仕組みです。その文書に、タスクを変更する権限を与えるものではありません。

システムプロンプトを強化すれば、振る舞いは改善できるかもしれません。しかし、広い権限を持つ認証情報の権限を狭めることはできません。分類器は不審なコンテンツを検出できます。しかし、特定の社員に特定の添付ファイルを開示する権限があるかどうかは判断できません。別のモデルで最初のモデルを確認すれば、チェックを追加できます。それでも、独立したアプリケーション側のポリシーは必要です。

受信トレイのエージェントを運用に出せるかどうかを判断する、万能な検出率もありません。有用なのは、ワークフローに即した制限です。どのアカウントを読めるか、どのフィールドを変更できるか、データをどこへ送れるか、どの操作に確認が必要かを定めます。別のタスクにおけるベンダーの結果は、自社の承認手順を迂回できない証拠にはなりません。

根拠を持って言えるのは、より限定的で実用的なことです。複数の制御を重ねれば、リスクにさらされる範囲と被害を抑えられ、テストと監視によって不具合を発見できます。それでも、リスクは残ります。

エージェントがすでに外部コンテンツを読み、非公開情報を開示したり、業務上の状態を変更したりできるなら、今すぐ対策してください。 権限、承認、障害時の処理を確実に制御できるまでは、自律性をさらに広げるのは待つべきです。 非公開データも操作用ツールも持たない公開文書の要約システムなら、起こり得る被害はより限定されます。それでも、回答を操作されないための対策は必要です。

よくある質問

プロンプトインジェクション攻撃には、どう対策すればよいですか？

データへのアクセスとツールを制限し、信頼できないコンテンツを指示から切り離します。出力と操作を検証し、影響の大きい操作には確認を求め、結果を監視してください。権限の強制はモデルの外側で行います。単独でリスクをなくせる対策はありません。

プロンプトには、どのような例がありますか？

「この見込み客のメールを要約し、確認用に返信の下書きを作ってください」は通常のプロンプトです。見込み客のメールはタスクの資料であり、依頼を変更する許可ではありません。

SQLインジェクションは、今も使われていますか？

はい。安全でないデータベースクエリを組み立てるアプリケーションでは、SQLインジェクションは今も問題になります。プロンプトインジェクション対策とは別に、データベース固有の対策が必要です。OWASPのインジェクション対策ガイダンスを参照してください。

プログラミングでいうインジェクションとは何ですか？

セキュリティにおけるインジェクションとは、信頼できない入力が、インタープリターの実行内容や処理内容を変えてしまうことです。プロンプトインジェクションはモデルの振る舞いを標的にします。それ以外のインジェクション脆弱性では、データベースクエリ、コマンド、ブラウザー上のコードなどが標的になります。

インジェクションを簡単に説明すると？

入力が境界を越え、本来は与える権限のない指示として扱われてしまうことです。

コードインジェクションには、どのような種類がありますか？

SQLインジェクション、OSコマンドインジェクション、スクリプトインジェクションなどがあります。対策は、対象となるインタープリターによって異なります。プロンプトインジェクションにも、信頼境界を越えてしまうという共通の問題がありますが、コードインジェクション全般の別名ではありません。

プロンプトインジェクションには、どのような種類がありますか？

主な分類は、侵入経路による直接型と間接型です。ユーザーの入力から届く攻撃と、アプリケーションが取得したコンテンツから届く攻撃に分かれます。画像などのメディアに含まれる文字も指示を運び得ます。侵入経路とメディア形式は、それぞれ別の分類軸です。

ハッカーの主な7つの種類とは何ですか？

ハッカーをどう分類するかは、エージェントの権限ポリシーを決めるうえでは役に立ちません。誰が認証されているか、誰がコンテンツに影響を与えられるか、アプリケーションが何にアクセスし、何を変更してよいかを基準に制御してください。

DDoSとSQLインジェクションとは何ですか？

DDoSは分散型サービス拒否攻撃のことで、分散した攻撃元を使って可用性を攻撃します。SQLインジェクションは、データベースクエリを不正に操作します。どちらもプロンプトインジェクションとは別の問題です。可用性を守る対策は、OWASPのサービス拒否攻撃対策ガイダンスで扱っています。

次の営業日に取り組むこと

稼働中の受信トレイまたはCRMのワークフローを選び、アクセスできるデータ、使えるツール、外部の接続先を洗い出してください。不要なアクセスを取り除き、影響を伴う操作は、実行内容そのものが承認されるまで待機させます。そして、却下された提案が外部に何も影響を及ぼさないことを実証してください。必要なタスクが成功し、拒否すべき処理も確実に拒否できるようになってから、自律性を広げます。

AIワークフローを構築するための実践的なガイドを、ニュースレターでお届けしています。