AIアプリケーションをプロンプトインジェクション攻撃から守るには、プロンプトに「この指示には従わない」と書くだけでは十分ではありません。ユーザー入力や外部データを信頼しない設計にし、AIに与える権限を必要最小限に抑え、出力を検証し、重要な操作には独立した認証や人間による承認を組み合わせることが重要です。さらに、実際の攻撃を想定したセキュリティテストを繰り返し行う必要があります。
プロンプトインジェクションは、LLMが処理する入力と、アプリケーション側が設定した高い信頼度の指示が同じコンテキスト内で扱われることで発生します。NISTも、信頼されていない入力とアプリケーション設計者などが作成したプロンプトの連結を悪用する攻撃として定義しています。
生成AIの利用が広がるにつれて、この問題はAI開発者だけのテーマではなくなっています。社内文書を検索するRAGシステム、メールを処理するAIアシスタント、外部サービスを操作するAIエージェントなど、AIが外部データやツールにアクセスするほど、プロンプトインジェクションによる影響も大きくなります。
プロンプトインジェクションとは何か
プロンプトインジェクションとは、攻撃者がLLMへの入力を操作し、本来想定されていない動作や出力を引き起こす攻撃です。
たとえば、カスタマーサポート用のAIに「問い合わせ内容を回答する」という役割を与えていたとします。そこへ攻撃者が、通常の質問に加えてシステムの指示を無視するような命令を入力すると、AIが本来の目的から外れた回答を生成する可能性があります。
問題は、LLMが「これはユーザーからのデータ」「これはシステムからの指示」という区別を、一般的なプログラムのアクセス制御と同じ方法で保証できるわけではないことです。
NISTはプロンプトインジェクションを、信頼されていない入力と、より高い信頼度を持つ側が構築したプロンプトの組み合わせを悪用する攻撃として説明しています。
プロンプトインジェクションの定義と概要も確認しておくと、この問題を従来のインジェクション攻撃とは異なるLLM固有のリスクとして理解しやすくなります。
直接的プロンプトインジェクションと間接的プロンプトインジェクション
プロンプトインジェクションを理解するときは、攻撃経路を分けて考えることが大切です。
直接的プロンプトインジェクション
直接的プロンプトインジェクションでは、攻撃者がAIアプリケーションに直接入力を送ります。
たとえば、文章作成AIに対して、本来の処理とは関係のない指示を入力し、設定された制約を無視させようとするケースです。
攻撃の目的はさまざまです。
- 本来表示されない情報を取得する
- システム指示を推測させる
- セキュリティ制御を回避する
- AIの回答内容を意図的に変更する
- 接続されている機能を不正に利用する
NISTでは、ユーザーから直接与えられた入力を利用するタイプを「direct prompt injection」として整理しています。
間接的プロンプトインジェクション
間接的プロンプトインジェクションは、さらに注意が必要です。
この場合、攻撃者がAIに直接悪意のある指示を入力するとは限りません。AIが読み込むWebページ、メール、PDF、社内文書、データベースなどに悪意のある指示を仕込んでおき、それをAIに処理させます。
たとえば、次のような流れです。
ユーザー → AIアシスタント → 外部文書を取得 → 悪意のある指示を含む文書を読み込む → AIが指示を処理する
ユーザー自身は通常の質問をしているだけでも、AIが取得した情報の中に攻撃者が用意した命令が存在すれば、AIの動作に影響する可能性があります。
NISTも、ユーザー入力ではなくリソースを介して実行されるタイプを「indirect prompt injection」として区別しています。
日本のIPAも、RAGなどを通じてAIに取り込まれるデータへ悪意のある指示を混入させる間接的なプロンプトインジェクションについて取り上げています。
なぜプロンプトインジェクションが危険なのか
単純なチャットボットであれば、攻撃によって回答が変わるだけで終わるケースもあります。
問題が大きくなるのは、AIアプリケーションが社内データや外部システムと接続されている場合です。
機密情報が漏れる可能性がある
AIアプリケーションが社内文書、顧客情報、メール、データベースなどを参照できる場合、プロンプトインジェクションによって本来アクセスすべきではない情報を回答に含めてしまう可能性があります。
たとえば、社内ナレッジを検索するAIにアクセス権限のないユーザーが質問した場合、AIだけでアクセス制御を判断している設計は危険です。
「AIが答えたから表示してよい」という考え方ではなく、データへのアクセス権限はAIとは別の仕組みで確認する必要があります。
AIが外部システムを操作する可能性がある
AIエージェントがAPIやツールを利用できる場合、影響は回答の誤りだけでは済みません。
たとえばAIに次のような権限があるとします。
- メールを送信する
- 顧客データを取得する
- ファイルを変更する
- チケットを更新する
- 外部APIを呼び出す
この状態でプロンプトインジェクションが成功すると、AIの出力が実際のシステム操作につながる可能性があります。
OWASPのLLMセキュリティガイドでも、プロンプトインジェクションによって不正アクセスや重要な意思決定への影響、外部システムとの連携を通じた問題が発生する可能性が指摘されています。
AIアプリケーションの攻撃パターンを整理する際は、OWASPのLLM01:2025「Prompt Injection」が信頼できる基準の一つになります。
AIアプリケーションを守るための7つの対策
プロンプトインジェクションを完全に防ぐための単一の対策はありません。アプリケーション全体に複数の防御層を設けることが現実的な方法です。
1. ユーザー入力を信頼しない
まず、ユーザーが入力する内容はすべて信頼できないものとして扱います。
これは一般的なWebアプリケーションでも重要な考え方ですが、LLMアプリケーションでは特に注意が必要です。
ユーザーの入力をそのままシステムプロンプトに追加したり、AIの判断をそのままアプリケーションの権限判断に使ったりすると、攻撃の影響を受けやすくなります。
AIが生成した文章と、アプリケーション側で実行してよい処理は分けて考える必要があります。
2. 外部データとシステムの指示を分離する
RAG、Web検索、メール処理、ドキュメント分析などでは、AIが外部から取得したデータを読み込みます。
このデータを「信頼できる指示」として扱わないことが重要です。
たとえば社内文書に次のような文章が含まれていたとしても、それはAIへの命令ではなく、あくまで取得したデータとして扱う設計が必要です。
データとして読むことと、指示として実行することは別の処理にする。
この区別が曖昧だと、間接的なプロンプトインジェクションが成立しやすくなります。
3. AIに与える権限を最小限にする
AIに必要以上の権限を与えないことも重要です。
たとえば、社内FAQを検索するAIに顧客データを削除する権限まで与える必要はありません。
AIが利用できる機能を必要最小限に制限すれば、仮にプロンプトインジェクションが成功した場合でも被害範囲を小さくできます。
これは「攻撃を100%防ぐ」という発想とは少し違います。
攻撃が成功しても重大な操作につながらない設計にすることがポイントです。
4. AIの出力をそのまま実行しない
LLMの出力は、アプリケーション側で検証してから利用する必要があります。
特に注意したいのは、AIが生成した内容をそのまま次の処理へ渡すケースです。
たとえば、
LLM → API実行
ではなく、
LLM → 出力検証 → 権限確認 → 実行
という流れを設けます。
SQL、APIリクエスト、HTML、ファイル操作、メール送信など、外部システムへ影響する処理ほど、この考え方が重要です。
OWASPでもLLMの出力を適切に検証・処理しないことを独立したセキュリティリスクとして扱っています。
5. 高リスク操作には人間の承認を入れる
すべてのAI操作に人間の確認を求める必要はありません。
一方で、次のような処理には人間による確認を入れる価値があります。
- 金銭に関係する処理
- 顧客アカウントの変更
- データの削除
- 外部へのメール送信
- 権限変更
- 機密情報の外部送信
AIが「実行してよい」と判断したことと、アプリケーションが「実行を許可する」ことは別にするべきです。
6. ログと監視を設計する
攻撃を防ぐだけでなく、攻撃を受けたことを把握できる状態にしておく必要があります。
確認したい情報には、次のようなものがあります。
- 不審な入力
- 繰り返されるプロンプトインジェクション
- 異常なツール呼び出し
- 権限エラー
- 大量のデータ取得
- 通常とは異なるAIの操作
特にAIエージェントでは、最終的な回答だけでなく、どのツールを呼び出したか、どのデータにアクセスしたかを記録することが重要です。
7. 実際の攻撃を想定してテストする
セキュリティ設定を書くだけでは十分ではありません。
実際に攻撃者の立場からAIアプリケーションを試し、どこまで操作できるのかを確認する必要があります。
テスト対象としては、次のような項目が考えられます。
- 直接的プロンプトインジェクション
- 間接的プロンプトインジェクション
- 機密情報の漏えい
- システムプロンプトの情報開示
- 不正なツール呼び出し
- RAGデータの悪用
- AIエージェントの権限悪用
OWASPも、AIシステムを信頼できないユーザーとして扱い、侵入テストや侵害シミュレーションを定期的に行うことを推奨しています。
RAGを利用するAIアプリケーションで注意すべきこと
RAGは、LLMに社内文書などの外部情報を参照させるための便利な仕組みです。
一方で、RAGを導入しただけでプロンプトインジェクションの問題がなくなるわけではありません。
むしろ、AIが参照する情報源が増えることで、新しい攻撃経路が生まれることがあります。
たとえば、次のような構成を考えてみます。
ユーザー → AIアプリケーション → 検索 → ベクトルデータベース → 文書取得 → LLM
ここで取得された文書に悪意のある指示が含まれていた場合、その内容がLLMのコンテキストに入ります。
そのため、RAGでは「検索結果だから安全」と考えず、取得データも信頼できない入力として扱う必要があります。
RAGで確認したいポイント
- 文書ごとのアクセス権限
- データソースの信頼性
- 検索結果の境界
- 機密情報の分類
- 外部データとシステム指示の分離
- AI出力の検証
- 検索・回答・ツール利用のログ
RAGを利用したAIアプリケーションのセキュリティ設計を確認するときは、AIアプリケーション向けのセキュリティチェックリストも参考になります。
このチェックリストでは、プロンプトインジェクション、RAG、出力検証、AIエージェントなど、LLMアプリケーションを設計するときに確認したい複数のセキュリティ領域が扱われています。
AIエージェントでは何が変わるのか
AIエージェントは、単純なチャットボットとは異なります。
通常のチャットボットが、
質問 → LLM → 回答
という流れで動くのに対して、AIエージェントは、
目的 → LLM → ツール選択 → APIや外部サービス → 結果確認 → 次の処理
という複数のステップを実行することがあります。
この違いによって、プロンプトインジェクションの影響も大きくなる可能性があります。
たとえば、AIエージェントがメール、社内データベース、チケット管理システムなどに接続されている場合、悪意のある入力が単なる誤回答ではなく、実際の操作につながる可能性があります。
IPAが2026年のAIレッドチーミングに関する取り組みで、プロンプトインジェクションだけでなく、AIエージェント間通信、外部ツールの偽装、連鎖的なプロンプトインジェクションなどを扱っていることからも、この領域が実践的なセキュリティ課題になっていることが分かります。
そのため、AIエージェントでは「プロンプトを安全にする」だけでなく、「AIが何を実行できるか」を設計段階から確認する必要があります。
プロンプトインジェクション対策でよくある間違い
システムプロンプトで禁止すれば十分だと考える
「機密情報を公開しない」「以前の指示を無視しない」とシステムプロンプトに書くことは一定の意味があります。
ただし、それだけをセキュリティ境界として扱うべきではありません。
AIの判断に依存するのではなく、重要なデータへのアクセスや操作についてはアプリケーション側でも制御する必要があります。
キーワードフィルターだけに依存する
特定の文字列を検出してブロックする方法もありますが、それだけでは不十分です。
攻撃者は表現を変えたり、別の言語を使ったり、文章の中に指示を隠したりできます。
攻撃方法が変われば、固定された文字列リストでは対応できない可能性があります。
RAGのデータをすべて信頼する
社内データベースだから安全とは限りません。
文書の編集権限、データ取り込み経路、外部から取得した情報なども確認する必要があります。
AIに広すぎる権限を与える
AIに多くのツールを接続すると便利になります。
同時に、プロンプトインジェクションが成功した場合の影響も大きくなります。
AIに必要な機能だけを与え、重要な操作には別の認証や承認を設ける方が安全です。
セキュリティテストを一度だけ行う
AIアプリケーションは、モデル、プロンプト、RAGデータ、ツール、権限などが変更されることがあります。
そのため、リリース前の一度だけではなく、重要な変更があったときに再テストすることが重要です。
プロンプトインジェクション対策の実践チェックリスト
AIアプリケーションを公開する前に、次の項目を確認してみてください。
- ユーザー入力を信頼できないデータとして扱っている
- 外部データとシステム指示を分離している
- RAGのデータに適切なアクセス制御がある
- AIに与える権限を最小限にしている
- AIの出力をそのまま実行していない
- APIやツールの呼び出しを独立して認証している
- 高リスク操作に承認プロセスがある
- AIの操作ログを記録している
- 異常なツール呼び出しを検知できる
- 直接的プロンプトインジェクションをテストしている
- 間接的プロンプトインジェクションをテストしている
- 機密情報の漏えいをテストしている
- RAGの取得データを攻撃経路として確認している
- AIエージェントの権限とツールを確認している
- アプリケーション変更後にセキュリティテストを再実施している
このチェックリストで特に重要なのは、「プロンプトを安全にする」だけで終わらないことです。
AIアプリケーション全体の入力、データ、権限、出力、ツール、監視を確認する必要があります。
AIセキュリティでは攻撃と防御の両方を理解する
AIセキュリティを実際の開発やセキュリティ業務に取り入れる場合、攻撃手法だけを知っていても十分ではありません。
反対に、防御策だけを学んでも、攻撃者がどのようにAIアプリケーションを悪用するのかを理解していなければ、適切なテストケースを作ることが難しくなります。
特に実務では、次の流れを理解することが役立ちます。
AIアプリケーションを構築する
↓
攻撃経路を特定する
↓
脅威モデルを作る
↓
実際に攻撃を試す
↓
問題を修正する
↓
防御策を再テストする
AIやLLMの基礎から、RAG、ベクトルデータベース、AIエージェント、MCP、プロンプトインジェクション、セキュリティレビュー、脅威モデリング、防御技術まで実践的に学びたい場合は、AIセキュリティ認定コースのように、攻撃と防御を両方扱うトレーニングが参考になります。実際のカリキュラムでも、直接的・間接的プロンプトインジェクション、RAG、AIエージェント、MCP、脅威モデリング、LLMファイアウォールやガードレールなどが扱われています。
実際のAIアプリケーションで考えるプロンプトインジェクション対策
ここまでの内容を、社内情報を検索できるAIアシスタントで考えてみましょう。
システムが次のような構成だとします。
ユーザー
↓
AIアシスタント
↓
RAG検索
↓
社内文書
↓
LLM
↓
回答
ある文書に、通常の業務情報と一緒にAIへの悪意のある指示が含まれていたとします。
AIがその文書を単なる情報ではなく命令として処理すると、回答内容が意図せず変更される可能性があります。
さらにAIが社内APIを呼び出せる場合、問題は回答の変更だけではありません。
そのため、次のような防御を組み合わせます。
1. 文書を信頼できない入力として扱う
2. 文書内の命令をシステム指示と区別する
3. AIのデータアクセス権限を制限する
4. ツール利用時に独立した権限確認を行う
5. 高リスク操作には承認を求める
6. AIの操作をログに記録する
7. 悪意のある文書を使って実際に攻撃テストを行う
このように考えると、プロンプトインジェクション対策は単純なプロンプト設計の問題ではないことが分かります。
プロンプトインジェクション対策は一つの防御策では完成しない
プロンプトインジェクションへの対策を考えるとき、最も避けたいのは「この方法を導入すれば安全になる」と考えることです。
実際には複数の防御層が必要です。
入力の制御
↓
信頼データと外部データの分離
↓
最小権限
↓
出力検証
↓
ツール実行時の認証
↓
高リスク操作の承認
↓
ログと監視
↓
攻撃シミュレーション
この構造なら、仮に一つの防御策を突破された場合でも、次の層で攻撃の影響を止められる可能性があります。
重要なのは、プロンプトインジェクションを「絶対に起こさない問題」としてだけ考えないことです。
攻撃が成功したとしても、それだけで機密情報の漏えいや不正操作につながらない設計にすること。
これがAIアプリケーションのセキュリティ設計で重要な考え方です。
継続的なAIセキュリティテストが必要な理由
AIアプリケーションは、一度完成したら変更されないシステムではありません。
次のような変更が行われることがあります。
- 使用するLLMを変更する
- システムプロンプトを変更する
- RAGのデータソースを追加する
- 新しいAPIをAIに接続する
- AIエージェントに新しいツールを与える
- ユーザー権限を変更する
- 新しいワークフローを追加する
こうした変更によって、以前は存在しなかった攻撃経路が生まれる可能性があります。
そのため、AIセキュリティテストはリリース前の一回だけで終わらせるのではなく、アプリケーションの構成が大きく変わったタイミングでも実施することが望まれます。
まとめ
プロンプトインジェクションは、AIに悪意のある文章を入力するだけの単純な問題ではありません。RAG、AIエージェント、外部ツール、社内データなどが組み合わさることで、情報漏えいや不正操作につながる可能性があります。
AIアプリケーションを守るためには、次のポイントを押さえることが重要です。
- ユーザー入力を信頼しない
- 外部データとシステム指示を分離する
- AIの権限を最小限にする
- 出力を検証してから実行する
- 高リスク操作には独立した承認を設ける
- ログと監視によって異常を把握する
- 直接的・間接的プロンプトインジェクションを実際にテストする
特にAIエージェントやRAGを利用する場合は、LLMそのものだけではなく、AIがアクセスできるデータ、ツール、API、権限、実行フローまで含めてセキュリティを考えることが重要です。
AIセキュリティを実践的に学ぶ際には、攻撃手法だけでなく、脅威モデリング、セキュリティテスト、アプリケーションレベルの防御まで一連の流れで理解することが役立ちます。
Modern Securityでは、AI/LLMアプリケーションの構築から攻撃、脅威モデリング、防御までを実践形式で扱うAI Security Certificationを提供しています。