プロンプトインジェクションは、WAFやガードレールで防げますか？
従来のWAFルールだけでは、プロンプトインジェクションを十分に防げません。LLM向けの検知を使い、アプリの権限と出力の扱いを別に制限します。
プロンプトインジェクションは、利用者の入力や、AIが読む文書・メールに命令を混ぜる攻撃です。通常の文章として成立するため、SQLやscriptタグのような構文だけを探す防御では取りこぼします。
WAFにLLM向けの検知機能を追加した製品もあります。「WAFなら原理的に検知できない」と一括りにはしません。ただし、入力を検知したことと、その利用者に操作権限があること、出力が安全に表示されることは別です。
この記事は、LLMを組み込んだアプリの開発責任者向けです。検知、toolの認可、送信前の承認、表示処理を、それぞれどこへ置くかを説明します。
攻撃には、どんな類型がありますか？
入力欄への直接注入、参照文書への間接注入、機密情報の持ち出しを分けて確認します。
直接注入は、利用者が悪意ある指示を入力する経路です。間接注入は、Webページ、メール、RAGの参照文書へ攻撃者が命令を埋める経路です。利用者が入力していない文章も、モデルが読む以上は検査対象になります。
2026年10月3日に確認したOWASP公式の一覧は2025版です。Prompt InjectionはLLM01、Sensitive Information DisclosureはLLM02です。出力の扱いはLLM05、Excessive AgencyはLLM06、Unbounded ConsumptionはLLM10として掲載されています。
ここでの経路分けは説明のための分類です。リスクの順位をそのまま自社の優先度にせず、参照できる文書、呼べるtool、送信先を見て被害範囲を決めます。
導入と運用は、どんな手順で進めますか？
ログ、フラグ、ブロックの順に段階を踏み、アプリ側の権限設計を並行して進めて、4つの指標を見ます。
いきなり全カテゴリをブロックに設定すると、正当な業務利用まで止まります。現場の反発で、運用ごと形骸化しやすくなります。段階を踏むのが現実的です。
- 観察します。GuardrailsとAI Security for Appsを、「ログ・フラグ」設定で先に有効化します。既存トラフィックの検知パターンを、1〜2週間観察します。ブロックする前に、自社の正常な利用パターンと誤検知の傾向を把握するためです。
- 段階的にブロックします。誤検知が少ないカテゴリから、順にブロックへ引き上げます。明確な攻撃文言や、既知のPIIパターンなどです。業務を止めずに、検知の効き目を確かめながら強度を上げます。
- アプリ側の権限設計を並行して見直します。ゲートウェイの導入と並行して、ツール実行の権限、承認フロー、出力のエスケープを見直します。ゲートウェイ側は後からいつでも足せます。権限設計は、後回しにするほど手戻りが大きくなります。
- 運用では、ブロック件数だけを追いません。見る指標は、次の4つです。
- カテゴリ別の検知件数を、週次で見ます。合計だけを見ると、急増している特定カテゴリを見逃します。
- 誤検知率を、週次から月次で見ます。ブロックされたリクエストのうち、正当な業務利用だった割合です。計測しないと、厳しくしすぎて業務が止まっていることに気づけません。
- レート制限の発動状況を、週次で見ます。429で弾かれた量と発生元です。正規ユーザーが誤って引っかかっていないか確かめます。
- インシデント対応までの時間を、発生の都度見ます。検知から、調査、遮断、関係者への共有までの所要時間です。見る担当と手順を決めておかないと、初動が遅れます。
ブロックへ寄せすぎると業務が止まり、緩めすぎると意味がなくなります。ログで正当な利用と誤検知を確かめてから、遮断する基準を決めます。
うまくいかない例には、どんなものがありますか？
ゲートウェイの導入で片づけること、権限設計の後回し、出力の鵜呑み、ブロック数だけの報告が典型です。
ゲートウェイは、テキストとして流れる入力と出力を、外側から観察して判定します。ゲートウェイが原理的に知り得ないことがあります。そのリクエストを送ったユーザーが、どこまでの操作を許されているかです。モデルの応答を、アプリ側がどう扱うかも知り得ません。
ここで効くのが、OWASPのLLM06:2025 Excessive Agency（過剰な操作権限）です。LLM05:2025 Improper Output Handling（不適切な出力の取り扱い）も同じです。どちらも、入出力の検知では埋められない、アプリ自身の設計の話です。
- 製品を入れれば片づくと考えます。権限設計とツール実行の承認は、自社の仕事です。
- ツールに広い権限を渡します。プロンプトインジェクションが成功したときの被害の大きさは、ツールに与えた権限の大きさで決まります。読み取り専用のDBユーザーしか渡していなければ、乗っ取られても情報を書き換えられません。送信先メールアドレスを許可リストで縛れば、任意の宛先への情報送出は起きません。
- 取り消せない操作を、モデルに単独で実行させます。影響範囲の大きい操作には、人の承認を挟みます。
- LLMの応答を鵜呑みにして、次の処理へ渡します。報告されている経路があります。応答をエスケープせずHTMLへ差し込めば、XSSになります。応答をSQLやシェルコマンドの一部に使えば、下流のインジェクションになります。ターミナルへそのまま表示すると、ANSI制御文字を悪用した表示の偽装が起きます。応答中のURLを自動でフェッチするMarkdownレンダラーでは、画像読み込みを経由した情報の持ち出しが起きます。OWASPの不適切な出力処理の項目は、ANSI・ターミナルへの出力や自動フェッチするレンダラーまで、説明を広げました。被害の実例が増えていることの裏返しです。
- 自社のプロンプトの安全性だけを見ます。LLMが読みに行くWebページやメールの中身も、すべて入力です。
- ブロック率だけを報告します。誤検知率とインシデント対応の時間を見ないと、運用が回りません。
Cloudflareの機能は、何を見ていて、どう違いますか？
Guardrailsはモデル呼出しの入出力、AI Security for Appsは自社エンドポイントへの入力を検査します。どちらも業務の認可を代わりに判断する機能ではありません。
2026年10月3日に公式資料を確認しました。AI Gateway Guardrailsは、アプリとモデル提供元の間でpromptと応答を検査し、設定に応じて記録やブロックを行います。対応するモデルと評価料金は導入前に確認してください。
AI Security for AppsはWAFへ統合されたLLM向け検知です。現在の公式資料では、対象はcf-llmとラベル付けされたエンドポイントへ届くJSON入力です。エンドポイントの発見は全プラン、検知フィールドとLog Mode RulesetはEnterpriseの有償追加機能です。
前者を通したからといって、外部ページに埋められた命令を必ず発見できるわけではありません。後者は入口の入力を検査しますが、取得後の文書やtool結果など、別の経路も残ります。自社で実際に通る経路を試験してください。
よくある質問
いいえ。ガードレールは統計的なモデルによる検知にもとづく緩和策で、100%の検知率を保証するものではありません。未知の言い回しや巧妙な難読化はすり抜ける可能性があります。正当な問い合わせを誤ってブロックすることもあります。権限設計や出力の扱いといったアプリ側の対策を重ねる多層防御が前提になります。
見ている方向が異なります。Guardrailsは、自社アプリからモデル提供元へ向かう出口側で、プロンプトと応答の有害コンテンツを検知します。AI Security for Appsは、外部から自社のLLMに向かう入口側で検知します。対象は、プロンプトインジェクションやPII(個人を特定できる情報)の混入です。多くの構成では両方を組み合わせて使います。
完全には防げません。LLMが読み込む外部コンテンツ(Webページ・ドキュメント・メールなど)は、無限に近いバリエーションがあります。ゲートウェイ側の検知をすり抜ける文面も出てきます。実行できるツールを最小権限に絞り、影響の大きい操作には人の承認を挟むアプリ側の設計が、実質的な防御線になります。
利用する機能と評価モデルで異なります。AI Security for Appsの検知フィールドは、2026年10月3日に確認した公式資料ではEnterpriseの有償追加機能です。Guardrailsの評価料金も、対応モデルと契約条件を確認してください。
次の一歩は何から始めればよいですか？
対象機能の契約と対応範囲を確認し、まず検知を記録し、アプリ側の権限設計の見直しも始めます。
- 対象機能の契約と対応範囲を確認し、まず検知を記録し、1〜2週間観察します。
- LLMエージェントに渡しているツールの権限と、承認が必要な操作を洗い出します。
- LLMの応答を、次の処理へ渡している箇所を確認します。
この記事は、どの資料をもとにしていますか？
2026年10月3日に掲載分類、検査対象、提供条件を確認しました。自社アプリでの検知率や導入効果を測定した記事ではありません。1〜2週間の観察期間は編集部の運用提案です。