プロンプトインジェクションとは？直接・間接攻撃の仕組みと企業の対策|セキュリティ対策Lab

投稿日時: 2026年09月29日更新日時: 2026年09月29日

プロンプトインジェクションとは、生成AIや大規模言語モデル（LLM）へ与えられる入力を悪用し、本来の指示とは異なる動作を引き起こす攻撃です。米国NISTは、信頼できない入力と、アプリケーション設計者など高い信頼度を持つ主体が作成したプロンプトが連結される構造を悪用する攻撃として定義しています。

企業で問題になるのは、生成AIが回答するだけでなく、社内文書の検索、メールの処理、Web閲覧、API呼び出し、SaaS操作などを行うようになっているためです。プロンプトインジェクションが成立した場合の影響は、誤回答だけではなく、情報の外部送信や意図しない操作まで広がります。

AIセキュリティ全体のリスクと対策については別記事で整理しています。本稿では、プロンプトインジェクションに絞り、直接型・間接型の違い、実際に報告された事例、企業側で確認したい対策を整理します。

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

プロンプトインジェクションでは、AIへ与えられる入力の中に、本来のシステム指示やユーザーの目的と競合する指示が混入します。

従来のWebアプリケーションでは、命令とデータを構造的に分離できます。一方、LLMは自然言語として与えられた「指示」と「参考情報」を同じ文脈の中で処理します。英国NCSCは、現在のLLMでは指示とデータを確実に区別できないことが、プロンプトインジェクションの根本的な課題になると説明しています。

主な攻撃経路は直接型と間接型に分けられます。

種類	入力経路	例	主なリスク
直接プロンプトインジェクション	利用者がAIへ直接入力	本来の制約と競合する指示を入力する	安全機能の回避、意図しない回答、内部指示の露出
間接プロンプトインジェクション	Webページ、メール、文書、RAGの参照データ、ツール出力など	外部コンテンツ内にAI向けの指示が埋め込まれる	情報漏洩、外部送信、ツールの誤操作、AIエージェントの乗っ取り

直接型では、攻撃者自身がAIへ入力できるケースが中心です。

間接型では、AIが読み込む外部データに攻撃者の指示が含まれます。AIエージェントやRAGでは、利用者自身が攻撃用の指示を入力していなくても、検索結果、メール、共有文書、Webページなどを処理した結果として攻撃が成立する可能性があります。

NISTは2025年の「Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations」で、間接プロンプトインジェクションが可用性、完全性、プライバシーの侵害につながり得ると整理しています。

プロンプトインジェクションとジェイルブレイクの違い

プロンプトインジェクションとジェイルブレイクは重なる部分がありますが、同じ概念ではありません。

ジェイルブレイクは、モデルに設定された安全上の制約や拒否動作を回避させることを主な目的とする手法です。一方、プロンプトインジェクションは、アプリケーションやAIシステムが本来想定していた指示系統を外部入力によって変えることが中心です。

たとえば、AIに禁止された回答を出させることが目的ならジェイルブレイクに近く、業務用AIエージェントに外部コンテンツを読ませ、利用者が意図していない処理を実行させる場合はプロンプトインジェクションとして捉える方が実態に合います。

NISTも、間接プロンプトインジェクションの中でジェイルブレイクに類似した手法が利用される場合があると整理しており、両者は排他的な分類ではありません。

なぜ企業で問題になるのか

プロンプトインジェクションの影響は、AIへ与えた権限と接続先によって変わります。

社内FAQを回答するだけのAIであれば、攻撃が成立しても主な影響は誤回答や不適切な出力にとどまる可能性があります。一方、メール、ファイルサーバー、CRM、クラウドストレージ、コードリポジトリ、決済機能などへ接続されたAIエージェントでは、同じプロンプトインジェクションでも影響範囲が広がります。

英国NCSCは2026年5月、AIエージェントについて、外部システムやデータ、ツールへのアクセス範囲が広がるほど攻撃面も拡大すると説明しています。同ガイダンスでは、最小権限、短期間の認証情報、操作範囲の制限、監視、人による責任と統制を挙げています。

つまり、プロンプトインジェクション対策を「悪意ある文章を検出する問題」だけにすると不十分です。AIが侵害された前提でも、機密情報へ自由にアクセスできないこと、外部送信や高リスク操作を単独で実行できないことまで設計に含める必要があります。

実際に確認されたプロンプトインジェクション事例

セキュリティ対策Labでも、間接プロンプトインジェクションを使った複数の事例を取り上げています。

2026年7月に紹介したAIエージェントを狙う間接的プロンプトインジェクションでは、Zscaler ThreatLabzがWebコンテンツ内へAI向けの指示を埋め込む2件のキャンペーンを報告しました。ThreatLabzの検証では26種類のLLMが評価され、一部のモデルは検証環境で決済を実行したり、偽サイトを正規サイトと誤認したりしました。

この事例では、利用者が攻撃用プロンプトを入力したわけではありません。AIエージェントが外部Webページを読み込み、人間の画面では見えにくい情報も含めて処理したことが攻撃経路になっています。Web閲覧機能を持つAIでは、参照先そのものを信頼境界の外側として扱う必要があることを示しています。

また、2025年11月に紹介したChatGPTに7つの抜け道―間接プロンプトインジェクションでメモリや会話履歴が漏えいする恐れでは、Tenableが報告した複数の攻撃手法を整理しました。外部コンテンツを経由した指示によって、メモリや会話履歴などの情報が外部へ送信される可能性が検証されています。

いずれも、「モデルが不適切な回答をする」だけではなく、AIが接続しているデータや外部機能が攻撃の影響範囲を決める事例です。

プロンプトインジェクションで起こり得る影響

企業環境では、次のような影響を想定します。

影響	具体的に起こり得ること
機密情報の漏洩	AIが参照できる社内文書、メール、会話履歴などを意図しない宛先へ出力・送信する
AIの判断改変	外部コンテンツを正規情報と誤認し、誤った回答や推奨を返す
ツールの誤操作	メール送信、ファイル変更、API実行などを利用者の意図と異なる形で行う
詐欺・フィッシングへの誘導	偽サイトや攻撃者が用意した情報源を正規サービスとして案内する
可用性への影響	不正な指示によってAIサービスや後続処理を正常に利用できなくする
監査・説明責任の問題	AIがなぜ操作を実行したか追跡できず、インシデント調査が難しくなる

NISTは、間接プロンプトインジェクションの影響を可用性、完全性、プライバシーの観点から分類しています。特にAIエージェントでは、情報へのアクセスだけでなく「何を実行できるか」を確認する必要があります。

プロンプトインジェクション対策

現在のところ、プロンプトインジェクションを単一の対策で完全に防ぐ方法は確認されていません。NISTは、入力処理、検知、モデル側の学習など複数の緩和策を挙げていますが、すべての攻撃手法に対する完全な防御にはならないとしています。英国NCSCも、確実にリスクを除去できる単一の対策はないとの前提でシステム設計を行うよう示しています。

企業では、以下を組み合わせて影響を限定します。

外部データを信頼しない前提で処理する
Webページ、メール、添付ファイル、RAGの検索結果、外部ツールの応答は、AIへの命令ではなく「信頼されていないデータ」として扱います。システムプロンプトと外部データの境界を設計上明示し、外部コンテンツから直接、高権限の処理へ到達できる構成を避けます。
AIエージェントを最小権限にする
AIへ付与する権限は業務に必要な範囲へ限定します。参照だけでよい業務に書き込み権限を与えない、全社ファイルへアクセスできる認証情報を共有しない、管理者権限を常時付与しない、といった制御が該当します。
高リスク操作には人の承認を入れる
送金、契約、アカウント変更、権限付与、外部メール送信、ソースコード変更などは、AIの判断だけで完結させない設計にします。承認者はAIが生成した説明だけでなく、実際に実行される操作内容と対象を確認できる状態にします。
外部接続先と実行可能な操作を制限する
AIエージェントがアクセスできるドメイン、API、SaaS、ファイル領域を限定します。外部ネットワークへの通信やツール呼び出しを無制限に許可せず、用途ごとに許可されたインターフェースを用意します。
入力・出力を検査し、決定的なルールを併用する
プロンプトインジェクションの検出機能は補助策として利用できます。ただし、モデルやフィルターの判定だけに依存せず、機密情報の外部送信禁止、送金額上限、許可されていないAPIの拒否など、通常のアプリケーションロジックでも制御します。
プロンプトとツール実行を記録する
利用者の入力だけでなく、AIが参照した外部データ、呼び出したツール、実行結果、外部通信先を追跡できるログを残します。英国NCSCのSecure AI System Developmentガイドラインも、入力の監視・記録と、システム挙動の継続的な監視を挙げています。
導入前に攻撃を想定した評価を行う
通常利用のテストだけでなく、外部文書やWebページへ不正な指示が含まれている場合、権限外の操作を要求された場合、複数ツールを連続して利用する場合などを評価します。モデル変更、RAGの変更、新しいSaaS連携の追加時にも再評価します。

既存事例から見える3つの実務上の論点

セキュリティ対策Labで取り上げた事例を横断すると、モデル単体の安全性だけを比較しても、企業のリスクを判断しにくいことが分かります。

第一に、同じモデルでも与えられる文脈によって結果が変わります。Zscalerの検証では、正規サイトの情報を追加した場合と、偽サイト側の情報だけを与えた場合で判定結果が変化しました。AIの評価では「どのモデルか」だけでなく、「どのデータを、どの順序で、どの権限とともに与えるか」まで確認する必要があります。

第二に、攻撃の被害規模はAIエージェントの権限に依存します。読み取り専用のAIと、決済や外部送信まで実行できるAIでは、同じプロンプトインジェクションでも結果が異なります。AIエージェント導入時は、機能一覧より先に、実行可能な操作と認証情報の範囲を棚卸しした方が管理しやすくなります。

第三に、人間が見て安全なコンテンツでもAIには別の情報が見えている場合があります。HTMLの非表示領域、構造化データ、検索結果、メール本文、ツール応答など、AIが取得する入力は人間の画面表示と一致するとは限りません。レビュー画面だけで安全性を確認せず、AIへ実際に渡されるコンテキストを監査対象に含める必要があります。

米国・英国・イスラエルの資料から確認できる対策の方向性

米国NISTは、プロンプトインジェクションを敵対的機械学習の分類に含め、間接型では入力処理、信頼できるデータと信頼できないデータの分離、検知、モデル学習などの緩和策を整理しています。同時に、現在の対策ではすべての手法を完全に防げないため、信頼できない入力へ接続することを前提にシステムを設計する考え方を示しています。

英国NCSCは、AIシステムのSecure by Designを設計・開発・展開・運用の全工程へ適用するよう求めています。2026年のAIエージェント向けガイダンスでは、最小権限、操作範囲の制限、長期間有効な認証情報を避けること、監視、脅威モデリング、インシデント対応を具体策として挙げています。

イスラエル国家サイバー局（INCD）の「Israel National Cybersecurity Strategy 2025」は、安全なAI導入を国家戦略の一項目に置き、AIシステムをライフサイクル全体でサイバー脅威から保護する方針を示しています。また、イスラエルのCheck Point Researchは「AI Security Report 2026」で、AIエージェントが外部コンテンツを処理する環境では間接プロンプトインジェクションが現実的な攻撃経路になると報告しています。同社の観測では、長い悪意あるプロンプトインジェクションの検知が2026年3月から5月にかけて約5倍に増加したとしています。これはCheck Pointの観測環境に基づく数値であり、市場全体の発生率を示すものではありません。

各資料で表現は異なりますが、モデルの拒否性能だけに依存せず、権限、接続先、監視、ログ、承認、インシデント対応を含むシステム全体で被害を限定する方向性は共通しています。