Azure WAF Exceptionsとは？Application Gateway・Front Doorの変更点と導入判断

Azure Application GatewayやAzure Front DoorのWAFで、正常なAPIリクエストまで遮断され、ルール全体の無効化や広範囲なAllowルールで対処している場合、今回のAzure WAF Exceptionsは検証する価値があります。

Azure WAF Exceptionsでは、リクエストURI、送信元IPアドレス、リクエストヘッダーを条件に、特定のルール、ルールグループ、マネージドルールセットに限ってWAF検査を回避できます。既存のExclusionsよりリクエスト単位で制御しやすく、Custom Allowルールよりも残す保護範囲を細かく指定できる点が最大の変更です。(Microsoft Learn)

ただし、2026年7月8日時点ではパブリックプレビューです。Application Gateway v2やAzure Front Door Premiumなどの提供条件があり、既存環境で自動的に有効になる機能でもありません。まずWAFログから誤検知の原因を特定し、対象ルールを限定したうえで非本番環境から検証する必要があります。

Azure WAF Exceptionsのパブリックプレビューで何が変わるのか

MicrosoftはAzure Updatesで「Public Preview: Exceptions in WAF for Azure Application Gateway and Azure Front Door」を公開しました。Azure Updates上の表示日は2026年7月7日で、日本時間では7月8日に確認された更新です。(Microsoft Azure)

従来のAzure WAFにも、誤検知を減らすためのExclusionsやCustom Rulesはありました。しかし、次のようなケースでは調整が難しいことがありました。

特定のURIに対して、特定のWAFルールだけを適用したくない
固定された送信元IPからの通信に限り、誤検知するルールを回避したい
特定のリクエストヘッダーを持つ通信だけ、特定のルールグループから除外したい
Custom Allowで全マネージドルールを回避するのは範囲が広すぎる
Exclusionsで一部フィールドだけを検査対象外にしても問題を解消できない

Azure WAF Exceptionsは、こうしたケースに対して「どのリクエストを」「どのルールから例外にするか」を分けて設定できる仕組みです。

項目	従来の課題	Exceptionsで可能になること
対象リクエスト	正常通信と不正通信を切り分けにくい	URI、送信元IP、ヘッダーで対象を特定する
適用範囲	Allowでは保護を広く回避しやすい	特定ルール、ルールグループ、ルールセットに限定する
誤検知対応	ルール全体の無効化に発展しやすい	問題のあるリクエストだけを例外にする
既存の保護	必要以上に検査が停止することがある	対象外のルールによる検査を継続できる

重要なのは、Exceptionsが単純な「アクセス許可リスト」ではない点です。例外の対象に指定したルールやルールグループでは検査を回避しますが、それ以外のWAFルールは引き続き動作します。(Microsoft Learn)

Exclusions、Exceptions、Custom Allowの違い

Azure WAFの誤検知対応では、Exclusions、Exceptions、Custom Rulesを混同しないことが重要です。

Exclusionsはリクエストの一部分を検査対象外にする

既存のExclusionsは、リクエストヘッダー、Cookie、クエリ文字列、フォームやJSON内の特定フィールドなど、リクエストの一部分をWAF評価から除外する機能です。

例えば、認証用トークンに含まれる特殊文字がSQLインジェクションとして誤検知される場合、そのトークンを格納するヘッダーだけを検査対象外にできます。ほかのヘッダー、URI、本文などは引き続き検査されます。(Microsoft Learn)

Exceptionsは条件に一致したリクエストを特定範囲のルールから外す

Exceptionsは、URI、送信元IP、ヘッダーなどに一致するリクエストについて、指定したルール、ルールグループ、マネージドルールセットの評価を回避します。

例えば、/login.phpへの正常なPOSTリクエストが特定のSQLインジェクションルールに誤検知される場合、次のように限定できます。

条件：Request URIが/login.phpと一致
適用範囲：誤検知した特定ルール
結果：そのルールだけを回避
継続する保護：ほかのSQLインジェクションルール、XSSルール、Bot Protectionなど

Custom Allowはリクエスト全体を広く許可する

Custom RuleでAllowアクションを設定すると、条件に一致したリクエストはDRS、CRS、Bot Protectionの評価を回避します。公式ドキュメントによると、HTTP DDoS保護ルールセットによる処理は継続しますが、一般的なマネージドルールによる検査は広く停止します。(Microsoft Learn)

機能	検査を省略する範囲	適したケース	主な注意点
Exclusions	ヘッダーやCookieなど、リクエストの一部分	特定フィールドの値だけが誤検知される	問題がリクエスト全体に及ぶ場合は解消できない
Exceptions	条件に一致するリクエストに対する特定ルールやルールセット	特定URIやIPで一部ルールだけ誤検知する	適用範囲を広げすぎない
Custom Allow	リクエスト全体に対する多くのマネージドルール	完全に信頼できる通信を広く許可する	シグネチャ検査や異常検知を大幅に回避する
ルール無効化	対象ルールをすべての通信で無効化	ルール自体が環境に不要と判断できる	他のURIや利用者に対する保護も失われる

判断の基本は、一部分だけ除外するならExclusions、リクエスト単位で特定ルールを回避するならExceptions、すべてのマネージドルールを回避する必要がある場合に限りCustom Allowです。

対象サービスと提供条件

Azure WAF Exceptionsは、すべてのApplication GatewayやAzure Front Doorで利用できるわけではありません。

対象サービス	対応する構成	必要なルールセット
Azure Application Gateway	Application Gateway v2でWAFポリシーを利用する構成	CRS 3.2、DRS 2.1、またはそれ以降
Azure Front Door	Azure Front Door Premium	DRS 2.1、またはそれ以降

どちらも次世代WAFエンジンが前提です。Application Gateway v1や古いCRSを使用している環境、Azure Front Door StandardやFront Door classicを使用している環境は、公式ドキュメント上の対象に含まれていません。(Microsoft Learn)

Application Gatewayで確認する項目

Application Gatewayでは、次の項目を確認します。

Application Gateway v2を使用しているか
WAFポリシーが関連付けられているか
CRS 3.2、DRS 2.1以降を使用しているか
古いWAF configurationではなく、WAFポリシーで管理しているか
使用しているAzure CLI、Azure PowerShell、IaCツールがExceptionsに対応しているか

Application Gatewayの公式ドキュメントでは、Azure portalに加え、Azure PowerShellのNew-AzApplicationGatewayFirewallPolicyExceptionやAzure CLIの例外追加コマンドが案内されています。(Microsoft Learn)

Azure Front Doorで確認する項目

Azure Front Doorでは、次の項目を確認します。

StandardではなくPremiumを使用しているか
WAFポリシーにDRS 2.1以降が設定されているか
対象ドメインにWAFポリシーが関連付けられているか
複数のドメインやポリシーへの影響範囲を把握しているか
利用するAPIやIaCプロバイダーがプレビュー機能に対応しているか

Azure Front DoorのWAFポリシーは複数のエンドポイントやドメインに影響することがあります。設定前に、どのセキュリティポリシー、ドメイン、パスへ適用されるかを確認してください。

Exceptionsで指定できる条件

例外対象となるリクエストは、次の属性で識別できます。

属性	主な用途	注意点
Request URI	特定の画面、API、アップロード先を対象にする	広い部分一致は意図しないURIにも一致しやすい
Remote IP address	固定された連携先や管理拠点を対象にする	共有NATや変動IPでは対象が広がる、または一致しなくなる
Request header name and value	特定クライアントや通信種別を識別する	利用者が自由に送信できるヘッダーだけを信頼条件にしない

値の判定には、次の演算子が用意されています。

Equals
Starts with
Ends with
Contains
IP Match

公式ドキュメントでは完全一致と部分一致の両方をサポートしています。セキュリティ上は、可能な限りEqualsを使用し、Containsは必要な場合だけ利用するのが安全です。(Microsoft Learn)

例えば、Request URIに対してContainsでadminを設定すると、管理画面以外のURIにも一致する可能性があります。/admin/importだけを対象にしたい場合は、完全一致または十分に限定された前方一致を検討してください。

大文字と小文字、URLエンコード、末尾のスラッシュ、クエリ文字列を含むリクエストなどは、実環境のWAFログとテストリクエストを使って一致結果を確認する必要があります。

Exceptionsの適用範囲

Exceptionsは、次の3段階で適用できます。

特定のルール
ルールグループ
マネージドルールセット全体

最も安全なのは、誤検知している特定のルールだけを対象にする方法です。

例えば、SQLインジェクション関連の1ルールだけが正常なJSONを誤検知しているのに、SQLインジェクションのルールグループ全体を例外にすると、同じURIに対する別のSQLインジェクション攻撃を見逃す可能性があります。

適用範囲は、次の順序で検討します。

特定ルールで解消できるか
複数ルールが同じ理由で誤検知する場合のみルールグループを検討する
ルールセット全体の例外は、設計上の理由が明確な場合に限る

Microsoftも、Exceptionsは可能な限り狭く設定し、できるだけルール単位で使用するよう案内しています。(Microsoft Learn)

利用上限を導入前に確認する

Exceptionsには件数上限があります。

上限項目	上限値
WAFポリシーごとのExceptions	60件
Application Gateway全体	関連付けられた全WAFポリシーの合計で60件
Azure Front Door全体	関連付けられた全WAFポリシーの合計で60件
1つのExceptionに登録できるIPアドレス	600件
1つのExceptionに登録できるURI	10件
1つのExceptionに登録できるリクエストヘッダー	10件

複数のWAFポリシーを作成しても、Application GatewayやAzure Front Door単位の合計上限が増えるわけではありません。複数サイトや多数のAPIを同じ基盤で保護している場合は、例外件数を事前に見積もる必要があります。(Microsoft Learn)

同じルール、同じ条件種別、同じ管理責任者を持つURIは、1件のExceptionにまとめられる場合があります。ただし、まとめすぎると変更理由や影響範囲が分かりにくくなるため、件数削減だけを目的に統合しない方が安全です。

対応を検討すべきユーザー

WAFの誤検知により正常通信が遮断されている

Preventionモードで、正常なログイン、ファイルアップロード、API連携などが403エラーになる環境は優先的な検討対象です。

ただし、403が発生しただけではWAFが原因とは断定できません。次のような原因も考えられます。

Custom RuleによるBlock
バックエンドアプリケーションの認可エラー
Application GatewayやFront Doorのルーティング設定
API ManagementやWebサーバー側のアクセス制御
Entra IDなどの認証失敗

まずWAFログで、マネージドルールのID、ルールグループ、アクション、対象リクエストを特定してください。

Custom Allowの範囲が広すぎる

固定IPや特定URIをCustom Allowで許可している場合、DRS、CRS、Bot Protectionなどの検査を広く回避している可能性があります。

誤検知の原因が一つのルールに限定できるなら、Custom AllowからExceptionsへ置き換えることで、ほかのWAF保護を残しやすくなります。

誤検知対策としてルールを無効化している

特定のAPIで発生する誤検知を理由に、そのルールをWAFポリシー全体で無効化している場合も見直し対象です。

Exceptionsを利用すれば、問題のあるURIや送信元だけを対象にし、ほかのサイトやAPIではルールを有効なまま維持できる可能性があります。

現在問題が発生していない環境

WAFログに誤検知がなく、ルール無効化や広範囲なAllowも設定していない場合は、急いでExceptionsを追加する必要はありません。

Exceptionsは有効化するだけで保護が強化される機能ではなく、検査を回避するためのチューニング機能です。必要のない例外を作ると、保護範囲を狭める結果になります。

実務での導入手順

WAFログから対象ルールを特定する

最初に、誤検知した通信について次の情報を整理します。

確認項目	確認する内容
対象サービス	Application GatewayかAzure Front Doorか
WAFポリシー	どのポリシーがリクエストを処理したか
ルールセット	CRSまたはDRSの種類とバージョン
ルール	ルールID、ルールグループ、検知内容
リクエスト	URI、HTTPメソッド、送信元、ヘッダー
影響	失敗件数、対象利用者、業務への影響
再現性	同じ条件で毎回発生するか

「正常なリクエストだから例外にする」のではなく、「どのルールが、どの部分を、なぜ誤検知したか」まで確認することが重要です。

最適な調整方法を選ぶ

原因に応じて、次のように判断します。

誤検知の状況	推奨する方法
特定のCookieやJSONフィールドだけが誤検知する	Exclusions
特定URIで一つのルールだけが誤検知する	Exceptionsを特定ルールに適用
特定IPからの通信で同じルールグループが誤検知する	Exceptionsをルールまたはルールグループに適用
完全に信頼できる通信を全ルールから許可したい	Custom Allow。ただしリスクを承認した場合のみ
ルールが全アプリケーションで不要	ルール無効化を検討。ただし影響評価が必要

対応条件を確認する

Application Gatewayではv2、Azure Front DoorではPremiumであることを確認します。併せて、ルールセットのバージョンと次世代WAFエンジンの利用可否を確認してください。

古いルールセットからDRSへ更新する場合は、Exceptionsの導入とルールセット更新を同時に行わない方が原因を切り分けやすくなります。先にルールセット更新を検証し、ログが安定した後でExceptionsを追加する方法が安全です。

最小範囲のExceptionを作成する

Azure portalでは、概ね次の流れで設定します。

対象のWAFポリシーを開く
「Managed rules」を開く
「Exceptions」タブを選択する
対象のマネージドルールセットを選択する
特定ルール、ルールグループ、ルールセット全体から適用範囲を選ぶ
Request URI、Remote IP、Request headerなどの条件を設定する
一致演算子と値を設定する
追加後にWAFポリシーを保存する

Application Gatewayでは、Azure PowerShellやAzure CLIによる設定例も公式ドキュメントに掲載されています。(Microsoft Learn)

最初の設定では、次の組み合わせを優先してください。

適用範囲：Specific rule
条件：Request URI
演算子：Equals
値：問題が発生している単一のURI

ルールグループ全体、Containsによる広いURI条件、大量のIPアドレス登録から始めるのは避けた方がよいでしょう。

非本番環境または限定範囲でテストする

パブリックプレビューは、GA済みの本番向け機能とは扱いが異なります。Azure Updatesでは「In preview」を、Azure顧客が非本番利用やテストに利用できる段階として説明しています。公式ドキュメントにもAzureプレビュー補足条項への案内があります。(Microsoft Azure)

テストでは、少なくとも次の3種類を実行します。

これまで誤検知していた正常リクエスト
同じURIに対する不正な入力を含むリクエスト
Exception条件に一致しない通常リクエスト

正常リクエストが通ることだけでなく、対象外のWAFルールが引き続き攻撃パターンを検知できることを確認してください。

導入後もログを監視する

Exceptionsを追加した後は、次の変化を監視します。

対象URIの403エラーが解消したか
バックエンドで4xx、5xxエラーが増えていないか
ほかのWAFルールによる検知件数が変化していないか
Exception対象への不審なアクセスが増えていないか
対象IPやヘッダーの条件が想定外の通信にも一致していないか

Azure WAFでは、診断設定を有効にし、Log AnalyticsなどへWAFログを保存することが推奨されています。ログを定期的に確認することで、誤検知の調整と攻撃状況の把握が可能になります。(Microsoft Learn)

導入前に注意すべきポイント

条件とルールの両方を狭くする

Exceptionsの安全性は、次の二つで決まります。

どのリクエストを対象にするか
どのルールを回避するか

特定URIを条件にしていても、ルールセット全体を例外にすれば保護範囲は大きく低下します。反対に、特定ルールだけを対象にしていても、Containsで広いURI条件を設定すれば多くのリクエストに適用されます。

「条件」と「適用範囲」の両方を最小化してください。

ヘッダーを信頼しすぎない

リクエストヘッダーはクライアント側から任意に設定できる場合があります。

例えば、X-Trusted-Client: trueというヘッダーだけを条件にExceptionsを設定すると、攻撃者が同じヘッダーを付けて送信できる可能性があります。ヘッダー値を条件にする場合は、その値が第三者に偽装されにくいか、アプリケーション設計を含めて確認してください。

また、アクセストークンやAPIキーなどの秘密情報そのものを例外条件として登録する運用は避けるべきです。

Remote IPの共有範囲を確認する

企業ネットワーク、クラウドサービス、モバイルキャリアなどでは、多数の利用者が同じ送信元IPを共有することがあります。

「取引先のIPだから安全」と判断する前に、次を確認します。

専用の固定IPか
複数顧客で共有されるNAT IPではないか
IPv4とIPv6の両方を考慮できているか
IP変更時の連絡、更新、削除手順があるか

1つのExceptionで複合条件を作れると決めつけない

公式の設定例では、1つのExceptionに一つのmatchVariableと複数の値を設定しています。

「特定IPかつ特定URI」のようなAND条件が必要な場合、現在利用するポータル、APIバージョン、CLI、IaCプロバイダーで意図した複合条件を表現できるか、事前に検証してください。IPとURIを別々のExceptionとして登録すると、ANDではなく、それぞれ独立して適用される可能性を考慮する必要があります。

ルールセット更新時に再検証する

DRSやCRSのバージョン更新では、ルール内容、ルールID、検知傾向などが変わる可能性があります。既存のExceptionsがそのまま適切に機能する前提にせず、ルールセット更新のたびに回帰テストを実施してください。

Microsoftは、WAF設定をAzure CLI、Azure PowerShell、Bicep、Terraformなどのコードで管理することを推奨しています。手作業だけで管理すると、ルールセット更新時の再設定漏れや環境差異が発生しやすくなります。(Microsoft Learn)

例外の所有者と終了条件を決める

例外設定には、最低限次の情報を残します。

作成理由
対象ルールID
対象URI、IP、ヘッダー
影響するシステム
承認者
管理責任者
作成日
見直し日
削除条件
関連する障害番号や変更管理番号

アプリケーション改修で誤検知原因が解消した後もExceptionsを残し続けると、不要な検査回避が恒久化します。四半期ごとなど、定期的な棚卸し対象に含めることが重要です。

対応要否を判断するチェックリスト

次の質問に当てはまるほど、Azure WAF Exceptionsの検証優先度は高くなります。

正常なリクエストがマネージドルールで繰り返し遮断されている
WAFログから誤検知したルールIDを特定できている
特定のURI、IP、ヘッダーで対象を限定できる
現在はルール全体の無効化で回避している
現在はCustom Allowで多数のマネージドルールを回避している
Application Gateway v2またはAzure Front Door Premiumを利用している
対応するルールセットと次世代WAFエンジンを利用できる
非本番環境や限定的なテスト経路を用意できる
WAFログを保存し、導入後の監視ができる
例外の所有者、見直し日、削除条件を管理できる

反対に、誤検知の根拠がない、WAFログを保存していない、条件を広くしなければ通信を識別できない場合は、Exceptionsを追加する前に監視やアプリケーション設計を見直すべきです。

まず実施すべき対応

Azure WAF Exceptionsへの対応は、すべての利用者が直ちに設定を変更するものではありません。

最初に行うべきことは、現在のWAFポリシーを確認し、次の設定が存在するかを洗い出すことです。

無効化しているマネージドルール
広い範囲に設定しているExclusions
Allowアクションを持つCustom Rules
誤検知対応として登録したIP許可
業務影響が発生しているWAFのBlockログ

該当する設定がある場合は、その理由と対象通信を再確認し、Exceptionsへ置き換えることで保護範囲を戻せないか検討します。

Azure WAF Exceptionsの価値は、正常通信を単に許可できることではありません。誤検知した通信だけを限定的に例外とし、それ以外のWAF保護を維持しやすくなることにあります。

一方で、パブリックプレビュー段階であり、適用条件やツール対応にも制約があります。まず非本番環境で、特定URIと特定ルールを組み合わせた最小構成から検証し、ログ、変更管理、定期見直しを含む運用ルールを整えてから本番利用を判断してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure WAF Exceptionsとは？Application Gateway・Front Doorの変更点と導入判断

Azure WAF Exceptionsのパブリックプレビューで何が変わるのか