プロンプトインジェクション対策とは？攻撃の種類と多層防御の実装手順

プロンプトインジェクションとは何か、なぜ防ぎにくいのか？

プロンプトインジェクションとは、入力に紛れ込ませた指示でLLMの挙動を乗っ取る攻撃です。命令とデータを区別できない構造上の弱点を突くため、完全に防ぐ方法はまだありません。

生成AIを業務に組み込む企業が増え、社内チャットボットやRAG（検索拡張生成）、AIエージェントが本番環境で動くようになりました。これに伴い、プロンプトインジェクションは研究上のテーマから運用上のリスクに変わっています。AX推進の現場で問われるのは「防げるかどうか」ではありません。「突破されたときに被害をどこで止めるか」を設計できるかどうかです。

攻撃の定義とOWASPでの位置づけ

OWASPは、LLMアプリケーションの脆弱性の第1位にプロンプトインジェクションを挙げています。セキュリティ業界でも最優先のリスクとして扱われています。

OWASPが公開している「OWASP Top 10 for LLM Applications 2025」では、プロンプトインジェクションが「LLM01:2025」に分類されています。同じリストには、関連の深いリスクも並んでいます。

米国NISTも、敵対的機械学習の分類体系「NIST AI 100-2 E2025」で、プロンプトインジェクションを生成AIへの主要な攻撃クラスとして整理しています。

命令とデータを分離できない構造的な弱点

LLMは、システムプロンプトも利用者の入力も参照文書も、同じテキストの並びとして処理します。そのため、どれが「従うべき命令」かを確実には判別できません。

SQLインジェクションは、プレースホルダ（パラメータ化クエリ）を使えば命令とデータを構文レベルで分けられ、対策がほぼ確立しています。一方、LLMでは自然言語そのものが命令にもデータにもなります。そのため、同じ発想の決定的な対策がありません。「以下の指示を無視して…」のような典型的なフレーズを検知しても、言い換えや多言語化、文字の装飾で簡単にすり抜けられます。

現場でPoCを見ていると、最初は「システムプロンプトに『指示を無視しないこと』と書けば十分」と考えているケースが少なくないように感じます。しかし、プロンプトでの防御は確率的に効きやすくなるだけです。保証にはならない、という前提から設計を始める必要があります。

直接型と間接型のプロンプトインジェクションにはどんな違いがあるのか？

直接型は利用者自身が悪意ある指示を入力する攻撃で、間接型は外部コンテンツに仕込まれた指示が実行される攻撃です。業務利用でより警戒すべきなのは間接型です。

直接型：利用者が入力欄から指示を上書きする

直接型は、チャット欄などに攻撃者が直接指示を書き込み、制約の解除や内部情報の取り出しを狙う攻撃です。いわゆる「ジェイルブレイク」もここに含まれます。

代表的な狙いは次の3つです。

1. システムプロンプトの内容を出力させる
2. 利用ポリシーで禁止されている出力を引き出す
3. 社内向けボットに、本来の用途と異なる処理をさせる

攻撃者が利用者本人なので、影響は基本的にそのセッション内に限られます。ただし、社外公開のチャットボットでは不適切な回答のスクリーンショットが拡散するなど、ブランド面のリスクにつながります。

間接型：外部コンテンツに埋め込まれた指示が発火する

間接型は、Webページ、メール、PDF、社内文書などに隠された指示を、LLMが参照するときに読み込んでしまう攻撃です。利用者に悪意がなくても成立します。

この攻撃類型は、Greshakeらの論文「Not what you’ve signed up for」（2023年）で体系的に示されました。白い文字やHTMLコメント、画像内のテキストなど、人間には見えにくい形で指示を埋め込めるのが厄介な点です。

プロンプトインジェクション対策の多層防御とは？

多層防御とは、入力・モデル・出力・権限の各層に独立した対策を重ね、どれか1層が破られても被害を限定する考え方です。どの層も単独では十分ではありません。

入力・モデル・出力・権限の4層で考える

対策は4つの層に分けて整理すると、抜け漏れを点検しやすくなります。重要なのは、下の層ほど「突破された後」の被害を決める点です。

OpenAI、Anthropic、Microsoft、Googleといった主要ベンダーは、いずれもプロンプトインジェクション対策をモデルの学習や安全機能に組み込んでいます。ただし、ベンダー各社もリスクが残ることを前提にした設計を推奨しています。①②をベンダー任せにする場合でも、③④は自社のシステム設計として責任を持つ範囲だと考えるのが現実的です。

単一の対策に頼らない理由

検知の精度を上げるより、「検知が外れても致命傷にならない設計」にするほうが費用対効果が高い場面が多いです。

入力フィルタの精度をいくら上げても、攻撃側はすり抜ける表現を探し続けます。一方、「LLMが外部にデータを送信できない」「メール送信の前に必ず人が確認する」といった制約は、攻撃の文面に関係なく機能します。Google DeepMindが2025年に発表した「CaMeL」も、同じ方向の研究です。信頼できない入力を扱う処理と、制御を担う処理を分離し、設計によって防ぐアプローチを示しています。

実務では、セキュリティ部門が「検知ツールを入れたか」を確認項目にしがちです。しかし、レビューで本当に見るべきなのは④の権限設計だと感じます。

AIエージェントやRAGではどこを重点的に守るべきか？

RAGでは取り込むデータの信頼境界を、AIエージェントではツール権限と外部への送信経路を重点的に守るべきです。後者は被害が実行にまで及ぶためです。

RAGでは取り込み元と参照範囲を管理する

RAGでは、検索対象に入れた文書がそのまま攻撃経路になります。まず、どの文書をどの権限で取り込むかを管理することが対策の出発点です。

• 取り込み元の区分：社内で作成した文書、取引先から受け取った文書、外部Webの文書を分けて管理し、信頼度の低いソースには出典を表示する
• アクセス権の継承：利用者が本来閲覧できない文書を、検索結果に含めない
• コンテキストの明示：検索で得た文書は「参照情報であり指示ではない」ことを、区切り記号などで構造的に示す
• 回答の根拠表示：回答とともに参照元を示し、利用者が誘導に気づけるようにする

社内ナレッジ検索のように「社内文書だけだから安全」と見なされやすい用途でも、外部から受け取った提案書やメールが混ざっていることはよくあります。取り込みパイプラインの棚卸しは、早い段階でやっておく価値があります。

AIエージェントでは「危険な3条件」の同時成立を避ける

AIエージェントでは、機密データへのアクセス、信頼できないコンテンツの読み込み、外部への送信手段の3つが揃うと、情報漏えいが成立しやすくなります。

この3条件は、Simon Willison氏が2025年に「lethal trifecta」と呼んで注意を促した組み合わせです。設計時には、この3つを同時に満たすエージェントを作らないことが基本方針になります。

MCP（Model Context Protocol）などでツール連携が簡単になったことで、エージェントに付与される権限はつい増えがちです。PoCの段階では「とりあえず全部つなぐ」構成になりやすいため、本番移行の前に権限を見直す工程を、あらかじめ計画に組み込んでおくことをおすすめします。

自社でプロンプトインジェクション対策を進める実装手順は？

対策は、利用中の生成AIの棚卸しから始め、リスクの高いユースケースから権限設計とテストを進め、継続評価の仕組みに乗せるのが現実的です。

ステップ1〜3：現状把握と脅威モデリング

最初の3ステップでは、どの生成AIがどのデータと権限に触れているかを洗い出し、守る優先順位を決めます。

1. ユースケースの棚卸し：社内チャット、RAG、AIエージェント、SaaSに組み込まれたAI機能まで含めて一覧にする
2. データと権限の可視化：ユースケースごとに、参照するデータ、読み込む外部コンテンツ、実行できるツールを記録する
3. リスク評価：前述の3条件の成立状況と、被害が起きたときの影響度から優先順位を付ける

ステップ4〜6：対策の実装と継続評価

後半の3ステップでは、多層防御を実装し、攻撃テストで検証し、運用の中で改善を続ける仕組みを作ります。

4. 多層防御の実装：権限・実行層の対策を最優先にし、そのうえで入力・出力のフィルタやベンダーのガードレール機能を組み合わせる
5. レッドチーミングによる検証：直接型・間接型の両方の攻撃シナリオでテストする。国内では、AIセーフティ・インスティテュート（J-AISI）が2024年9月に公開した「AIセーフティに関するレッドチーミング手法ガイド」が参考になる
6. 監視と更新：プロンプトとツール呼び出しのログを残し、異常なパターンを検知する。モデルの更新やツールの追加のたびに再テストする

ガバナンスの面では、経済産業省・総務省の「AI事業者ガイドライン」も、AIを利用する事業者に対してセキュリティ確保とリスク管理を求めています。社内規程に落とし込む際の拠り所になります。

実務の感覚としては、ステップ5のテストを一度で終わらせず、モデルやプロンプトを変更したときに回す回帰テストとして定着させられるかどうかで、運用の質が大きく変わると考えています。AX推進チームとセキュリティ部門が早い段階から同じ表（ユースケース×権限×リスク）を共有しておくと、本番移行の判断がスムーズになりやすいでしょう。

参考資料

• OWASP「OWASP Top 10 for LLM Applications 2025」
• NIST「AI 100-2 E2025: Adversarial Machine Learning – A Taxonomy and Terminology of Attacks and Mitigations」
• Greshake et al.「Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection」（2023年）
• Hines et al.「Defending Against Indirect Prompt Injection Attacks With Spotlighting」（Microsoft、2024年）
• Debenedetti et al.「Defeating Prompt Injections by Design」（Google DeepMind ほか、2025年、CaMeL）
• Simon Willison「The lethal trifecta for AI agents」（2025年）
• AIセーフティ・インスティテュート「AIセーフティに関するレッドチーミング手法ガイド」（2024年9月）
• 経済産業省・総務省「AI事業者ガイドライン」

姉妹メディアの関連記事