- プロンプトインジェクションは、命令とデータを構文で区別できないというLLM特有の弱さを突く攻撃で、既存のWAFのシグネチャ検知では原理的に防げない。OWASP Top 10 for LLM Applications 2026でも1位に位置づけられる。
- Cloudflareは、有害コンテンツを検知するAI Gateway の Guardrailsと、プロンプトインジェクション・PII混入を検知するAI Security for Apps（旧Firewall for AI）という、見ている方向が異なる2つの機能を提供する。
- ガードレールは確率的な緩和策であり、完全な防御ではない。権限設計・ツール実行の承認・出力の扱いといったアプリ側の設計と組み合わせる多層防御が前提になる。
なぜプロンプトインジェクションは、既存のWAFでは防げないのか？
命令とデータを構文で区別できないLLM特有の構造ゆえに、危険な記号やパターンを検知するという既存WAFの発想が原理的に通用しないから。
顧客対応チャットや社内ナレッジ検索など、LLM（大規模言語モデル）を組み込んだアプリケーションを公開する企業が増えている。同時に増えているのが、想定していない指示をLLMに送り込んで挙動を乗っ取る「プロンプトインジェクション」への懸念だ。情シスやセキュリティ担当からは「既存のWAF（Web Application Firewall）で防げないのか」という質問がまず出るが、答えは否である。理由は攻撃の成り立ちそのものにある。
SQLインジェクションやXSS（クロスサイトスクリプティング）への対策は、入力に含まれる特定の構文——引用符やセミコロン、scriptタグといった「命令として解釈されうる記号」を検知・無害化することで機能する。命令（コード）とデータ（値）が構文的に区別できるからこそ、WAFはパターンマッチングで両者を切り分けられる。
ところがLLMには、この構文的な境界がない。開発者が設定する「システムプロンプト」も、ユーザーが入力する質問も、外部から読み込んだWebページの本文も、すべてが同じ自然言語のテキストとしてモデルのコンテキストウィンドウに流し込まれる。モデルの内部では、「これは信頼できる開発者の指示」「これは信頼できないユーザー入力」という区別が構造的に保証されていない。攻撃者が送り込む指示は、特殊な記号を使う必要すらなく、ごく普通の日本語や英語の文章として成立する。だから「危険な記号をブロックする」という発想のシグネチャは、原理的にプロンプトインジェクションを検知できない。
この構造的な弱さは業界でも共通認識になっており、生成AIセキュリティの標準的な参照軸であるOWASP（The Open Worldwide Application Security Project）の「Top 10 for LLM Applications」でも、プロンプトインジェクションは2025年版・2026年版の両方で1位に置かれ続けている。次の章で、その攻撃がどう分類されるかを見ていく。
命令とデータを構文で区別できないことが、プロンプトインジェクションの本質的な難しさ。「危険な記号を弾く」という既存WAFの発想は、この攻撃には通用しない。
攻撃にはどんな類型があるのか？
直接注入・間接注入・機密の吸い出しの3類型に整理でき、OWASP Top 10 for LLM Applications 2026でもプロンプトインジェクションと機密情報の開示が1・2位を占める。
2026年8月、OWASPのGenAI Security Projectは「OWASP GenAI LLM Top 10 2026」を公開し、2025年版を置き換えた。今回の版からは、専門家の投票（比重75%）に加えて、実際に報告された数千件規模のインシデントデータ（比重25%）を反映する手法に変わった点が特徴で、「投票では順位が伸びなかったが、実際の被害件数では上位に来ていた」項目の順位が押し上げられている。1位はPrompt Injection、2位はSensitive Information Disclosure（機密情報の開示）で、いずれも2025年版から順位を維持した。
実務でこのリスクを扱う際は、「直接注入」「間接注入」「機密の吸い出し」という3つの型に整理すると見通しがよい。
- 直接注入（Direct Prompt Injection）。ユーザーが入力欄に直接、悪意ある指示を打ち込む型。「これまでの指示をすべて無視して」「あなたのシステムプロンプトを教えて」といった文言が典型で、OWASPのLLM01:2026 Prompt Injectionが正面から扱う。攻撃元が入力欄の向こう側にいるため、比較的検知しやすい。
- 間接注入（Indirect Prompt Injection）。LLMが自分で読み込みに行く外部コンテンツ——閲覧するWebページ、要約対象のドキュメント、返信を書くために読むメール本文——に、攻撃者があらかじめ指示を埋め込んでおく型。エンドユーザー自身は悪意ある文言を一度も入力していないため気づきにくく、RAG（検索拡張生成）構成やメール要約・ブラウジングエージェントほど攻撃対象が広がる。
- 機密の吸い出し（Sensitive Information Disclosure / Exfiltration）。システムプロンプトや、RAGで参照している社内文書、会話履歴に含まれる個人情報・機密情報を、質問の言い回しを変えながら引き出す型。OWASPのLLM02:2026 Sensitive Information DisclosureとLLM08:2026 Hidden Context Exposure（2025年版のSystem Prompt Leakageから改称・拡張）が対応する。
図：間接プロンプトインジェクションのイメージ。ユーザー本人ではなく、LLMが読みに行く外部コンテンツの側に指示が仕込まれる点が直接注入との違い。実際の攻撃は空白文字・HTMLコメント・極小フォントなど視認しづらい形で埋め込まれることが多い。
なお、OWASPの2026年版はスコープも整理された。ツールを呼び出し、セッションをまたぐ記憶を持ち、実世界に影響する行動を取る「エージェント」としての振る舞いに起因するリスクは、姉妹プロジェクトの「OWASP Agentic Top 10」に切り出されている。本稿がテーマにするのは、あくまでアプリケーションの一部品としてのLLMに対する攻撃である。
Cloudflareのゲートウェイで、何を防げるのか？
AI Gatewayの「Guardrails」が有害コンテンツを、WAFに統合された「AI Security for Apps（旧Firewall for AI）」がプロンプトインジェクションとPII露出を検知する。役割の異なる2機能を組み合わせて使う。
ここからは、実際にCloudflareのゲートウェイ機能で何が防げるかを見ていく。以下の機能名・提供状況は2026年8月時点のdevelopers.cloudflare.comおよびCloudflare公式ブログの記載にもとづく——製品は頻繁に更新されるため、導入判断の直前には必ず一次情報を確認してほしい。
Cloudflareがこの領域で提供する機能は、大きく2つに分かれる。どちらも「LLMアプリの前段に立つゲートウェイ」という点は共通だが、見ている方向が異なる。
AI Gateway の Guardrailsは、自社のアプリからOpenAI・Anthropic・Gemini・Workers AIといったモデルプロバイダへ向かうリクエストの間に挟まる形で動作する。ユーザーのプロンプトとモデルの応答の両方を、Meta社のLlama Guard 3（8B）モデルでリアルタイムに評価し、暴力・ヘイト・性的コンテンツ・自傷といった有害カテゴリごとに「無視・フラグ・ブロック」を個別に設定できる。検知結果はAI Gatewayのログにシールドアイコン付きで記録され、後から監査できる。利用自体に追加料金はかからないが、評価にはWorkers AIのトークン量に応じた従量課金が発生する。
AI Security for Apps（旧称 Firewall for AI）は、Guardrailsとは向きが逆の機能だ。CloudflareのWAF（Web Application Firewall）に統合されており、外部から自社の公開LLMエンドポイントに送られてくる入力を対象に、プロンプトインジェクションの兆候、電話番号やメールアドレス・クレジットカード番号といったPII（個人を特定できる情報）の混入、不適切なトピックを検知する。まずLLMを提供しているエンドポイントを自動発見し、検知結果はWAFのルールとして「ブロック・ログ・カスタムレスポンス」に振り分けられる。2026年に一般提供（GA）へ移行したが、本格的な検知・緩和機能はEnterpriseプランの有償アドオンで、Free・Pro・Businessプランではエンドポイントの自動発見のみが無料で使える（全プランへの展開は「近日対応」とアナウンスされている）。
つまり、Guardrailsは「自社→モデル提供元」への出口を、AI Security for Appsは「外部→自社のLLMエンドポイント」への入口を見ている。両者は代替関係ではなく補完関係にあり、どちらか一方で事足りる構成は多くない。
| 機能 | 見ている方向 | 主な検知対象 | 2026年8月時点の提供条件 |
|---|---|---|---|
| AI Gateway Guardrails | 自社アプリ→モデル提供元 | 暴力・ヘイト・性的表現など有害コンテンツ | 利用は無料、評価分はWorkers AIの従量課金 |
| AI Security for Apps（旧Firewall for AI） | 外部→自社のLLMエンドポイント | プロンプトインジェクション・PII混入・不適切トピック | エンドポイント発見は全プラン無料／検知・緩和はEnterpriseの有償アドオン |
| レート制限 | 両方向に設定可 | 単位時間あたりのリクエスト数超過 | AI Gatewayのコア機能として無料（固定・スライディングウィンドウ） |
| ログ／Analytics | 両方向 | プロンプト・応答・プロバイダ・トークン数・コスト・所要時間 | 全プランで利用可（保持期間はプランにより異なる） |
レート制限は、AI Gatewayのコア機能として無料で使え、一定時間内のリクエスト数を「固定ウィンドウ」（例：10分ごとに区切る）か「スライディングウィンドウ」（直近10分を常に見る）のどちらかで制限し、超過時はHTTP 429を返す。OWASPが2026年版でLLM06:2026 Unbounded Consumptionとして再定義した——大量リクエストによるコスト急増や、推論モデル特有の長い思考過程を悪用した資源の浪費——への直接的な緩和策になる。加えて、Cloudflareのゾーン全体にかける汎用のレート制限ルールを併用すれば、AI Gatewayを経由しないエンドポイントにも同様の制限を敷ける。
ログとAnalyticsは、AI Gatewayのダッシュボードで個々のリクエストのプロンプト・応答・プロバイダ・タイムスタンプ・トークン数・コスト・所要時間を確認できる。攻撃の検知そのものより、「何が起きたかを後から再構成できる」という監査証跡としての価値が大きい。
ガードレールは、統計的なモデルによる検知にもとづく緩和策であって、暗号のように数学的な正しさを保証する防御ではない。未知の言い回しや巧妙な難読化はすり抜けうるし、逆に正常な問い合わせを誤って止めることもある。「導入すれば安全になる」ではなく「検知率と誤検知率を運用しながら上げていくもの」と捉えるのが実務上の前提になる。
ガードレールは検知の確率を上げる仕組みであって、検知率100%を保証する仕組みではない。
ゲートウェイで防げるものと、アプリ側の設計でしか防げないものはどう違うのか？
入力の検知はゲートウェイで肩代わりできるが、権限設計・ツール実行の承認・出力の扱いはアプリ自身の設計でしか担保できない。
ゲートウェイでの検知は、テキストとして流れる入力と出力を外側から観察して判定する。裏を返せば、ゲートウェイが原理的に知りえないこともある——それは、そのリクエストを送ってきたユーザーがどこまでの操作を許されているか、モデルの応答をアプリ側がどう扱うか、という自社の設計そのものだ。
ここで効いてくるのが、OWASPが2026年版で3位に押し上げたLLM03:2026 Excessive Agency（過剰なエージェンシー）と、10位のLLM10:2026 Improper Output Handling（不適切な出力の取り扱い）という2つの項目だ。どちらも、ゲートウェイでの入出力検知では原理的に埋められない、アプリケーション自身の設計の話をしている。
権限設計とツール実行の承認。LLMエージェントにメール送信・DB参照・ファイル削除といった「ツール」を持たせるアプリが増えているが、プロンプトインジェクションが成功した場合の被害の大きさは、突き詰めればそのツールに与えた権限の大きさで決まる。読み取り専用のDBユーザーしか渡していなければ、乗っ取られても情報を書き換えられない。送信先メールアドレスを許可リストで縛っていれば、任意の宛先への情報送出は起きない。取り消せない操作・影響範囲の大きい操作は、モデルに単独で実行させず人の承認を挟む。これはゲートウェイが代行できない、アプリ側の権限設計そのものだ。
出力の扱い。LLMの応答は、鵜呑みにして次の処理に渡した瞬間にリスクになる。応答をエスケープせずにHTMLへ差し込めばXSS（クロスサイトスクリプティング）、応答をそのままSQLやシェルコマンドの一部として使えば下流のインジェクション、応答をターミナルにそのまま表示すればANSI制御文字を悪用した表示の偽装、応答中のURLを自動でフェッチするMarkdownレンダラーを使っていれば画像読み込みを経由した情報の持ち出し——といった経路が現実に報告されている。OWASPのLLM10:2026がこの項目の説明をANSI・ターミナルへの出力や自動フェッチするレンダラーまで明示的に広げたのも、被害の実例が増えていることの裏返しだ。
導入はどう進め、運用では何を見ればよいのか？
検知はログ→フラグ→ブロックの順に段階を踏んで慣らし、運用ではブロック件数だけでなく誤検知率とインシデント対応の速度を見る。
最後に、実際の導入手順と運用で見るべき指標を整理する。いきなり全カテゴリをブロックへ設定すると、正当な業務利用まで止めてしまい、現場の反発で運用ごと形骸化しやすい。段階を踏むのが現実的だ。
| 段階 | やること | ねらい |
|---|---|---|
| ① 観察 | GuardrailsとAI Security for Appsを「ログ・フラグ」設定で先に有効化し、既存トラフィックの検知パターンを1〜2週間観察する | ブロックする前に、自社の正常な利用パターンと誤検知の傾向を把握する |
| ② 段階的なブロック | 誤検知が少ないカテゴリ（明確な攻撃文言、既知のPIIパターンなど）から順にブロックへ引き上げる | 業務を止めずに検知の効き目を確認しながら強度を上げる |
| ③ アプリ側の権限設計 | ゲートウェイの導入と並行して、ツール実行の権限・承認フロー・出力のエスケープを見直す | ゲートウェイ側は後からいつでも足せるが、権限設計は後回しにするほど手戻りが大きい |
運用に入ってからは、ブロックした件数だけを追ってもあまり意味がない。見るべき指標は次の4つだ。
| 指標 | 何を見るか | 見る頻度 | 落とし穴 |
|---|---|---|---|
| カテゴリ別の検知件数 | プロンプトインジェクション・PII・不適切トピックなど、どの類型がどれだけ検知されているか | 週次 | 合計件数だけ見ると、急増している特定カテゴリを見逃す |
| 誤検知率 | ブロックされたリクエストのうち、正当な業務利用だった割合 | 週次〜月次 | 計測していないと「厳しくしすぎて業務が止まっている」ことに気づけない |
| レート制限の発動状況 | 429で弾かれたリクエストの量と発生元 | 週次 | 正規ユーザーの多用途アプリが誤って制限に引っかかっていないか |
| インシデント対応までの時間 | 検知から調査・遮断・関係者への共有までの所要時間 | インシデント発生都度 | ログを取っていても、見る担当と手順を決めていないと初動が遅れる |
導入初期にブロックへ寄せすぎると業務が止まり、緩めすぎると導入した意味がなくなる。ログで自社の実態を見てから閾値を決める——遠回りに見えて、この順番が一番早い。
よくある質問
いいえ。ガードレールは統計的なモデルによる検知にもとづく緩和策であり、100%の検知率を保証するものではありません。未知の言い回しや巧妙な難読化はすり抜ける可能性があり、正当な問い合わせを誤ってブロックすることもあります。ゲートウェイでの検知に加えて、権限設計や出力の扱いといったアプリ側の対策を重ねる多層防御が前提になります。
見ている方向が異なります。Guardrailsは自社アプリからモデル提供元へ向かう出口側で、プロンプトと応答に含まれる有害コンテンツを検知します。AI Security for Appsは外部から自社の公開LLMエンドポイントに向かう入口側で、プロンプトインジェクションやPII(個人を特定できる情報)の混入を検知します。多くの構成では両方を組み合わせて使います。
完全には防げません。LLMが読み込む外部コンテンツ(Webページ・ドキュメント・メールなど)は無限に近いバリエーションがあり、ゲートウェイ側の検知をすり抜ける文面も出てきます。実行できるツールやアクションを最小権限に絞り、影響の大きい操作には人の承認を挟むというアプリ側の設計が、実質的な防御線になります。
機能によって異なります。AI Gatewayの基本機能とGuardrailsの利用自体は無料ですが、Guardrailsの評価にはWorkers AIのトークン量に応じた従量課金が発生します。AI Security for Appsは、2026年8月時点ではエンドポイントの自動発見は全プラン無料である一方、プロンプトインジェクションやPIIの本格的な検知・緩和機能はEnterpriseプランの有償アドオンです。正確な金額とプラン条件は、必ず公式サイトの最新の料金ページで確認してください。