2026年5月1日に確認すべき Azure の公式ドキュメント更新「Update application-gateway-limits.md」は、Azure Application Gateway の制限値が変更された更新ではありません。今回の差分は、HTTP リスナー制限の注記から参照している FAQ リンクのアンカー修正です。とはいえ、運用担当者や設計者にとっては、HTTP リスナー 200、アクティブリスナー 100という上限を改めて棚卸しする良いタイミングです。
特に、マルチテナント SaaS、複数ドメインのホストベースルーティング、WAF 付き Application Gateway、Terraform や Bicep による IaC 管理をしている環境では、「総リスナー数」と「アクティブリスナー数」を分けて確認する必要があります。リンク修正だけに見えても、見落とすと新規ドメイン追加や移行時のデプロイ失敗につながります。
Azureの公式ドキュメント更新「Update application-gateway-limits.md」で何が変わったか
今回の MicrosoftDocs/azure-docs のコミットは、includes/application-gateway-limits.md に対する 1 ファイル、1 行追加・1 行削除の更新です。差分の対象は Azure Application Gateway limits の HTTP listeners 行で、制限値そのものではなく、FAQ へのリンク先アンカーが変更されています。(GitHub)
| 確認項目 | 更新前 | 更新後 | 実務上の意味 |
|---|---|---|---|
| 対象ファイル | includes/application-gateway-limits.md | 同左 | Azure の制限表で使われる include ファイル |
| 対象行 | HTTP listeners の注記 | HTTP listeners の注記 | リスナー上限の説明部分 |
| 変更内容 | #what-is-considered-an-active-listener-versus-an-inactive-listener | #what-is-an-active-listener-versus-an-inactive-listener | FAQ の正しい見出しに誘導するためのアンカー修正 |
| 制限値 | 変更なし | 変更なし | 上限緩和や新機能追加ではない |
つまり、今回の Azure documentation update は「Application Gateway の制限が増えた」という話ではありません。ドキュメント上の参照先を正しくする修正です。
ただし、この修正が触れているのは、Application Gateway 設計でトラブルになりやすい HTTP listeners の上限です。リンク修正だからといって読み飛ばすのではなく、自社環境のリスナー構成を確認するきっかけにするのが実務的です。
まず確認すべき制限値は「HTTPリスナー200」と「アクティブリスナー100」
Microsoft Learn の Azure Application Gateway limits では、Application Gateway limits の表が v1、v2、Standard、WAF SKU に適用されると説明されており、HTTP listeners は 200、ただしトラフィックをルーティングするアクティブリスナーは 100 に制限されています。(Microsoft Learn)
| 項目 | 現在確認すべき値 | チェックポイント |
|---|---|---|
| HTTP listeners | 200 | リダイレクト専用も含めた総リスナー数 |
| Active listeners | 100 | バックエンドへトラフィックを送るリスナー数 |
| HTTP load-balancing rules | 400 | ルール追加で上限に近づいていないか |
| Backend HTTP settings | 100 | アプリ単位・ポート単位で増えすぎていないか |
| Backend address pools | 100 | テナント別・サービス別に分割しすぎていないか |
| Backend targets per pool | 1,200 | VM、IP、FQDN の登録数が過剰でないか |
| Host names per listener | 5 | 1 リスナーにまとめられるホスト名数を超えていないか |
| Maximum path-based rules per URL map | 100 | パスベースルーティングで細分化しすぎていないか |
ここで重要なのは、200 と 100 は別の上限だという点です。
例えば、以下のような構成では、総リスナー数が 200 未満でも、アクティブリスナーが 100 に近づく可能性があります。
| 構成例 | 起きやすい問題 |
|---|---|
| 顧客ごとに独自ドメインを割り当てる SaaS | テナント増加に伴い HTTPS リスナーが増える |
| ブランド別・国別にホスト名を分ける EC サイト | ドメイン追加のたびにリスナーと証明書管理が複雑化する |
| 旧 URL から新 URL へのリダイレクトを大量に持つ環境 | アクティブではなくても総リスナー数 200 に近づく |
| WAF ポリシーやバックエンド設定を細かく分ける環境 | リスナー以外の関連リソース上限にも近づく |
| Blue/Green や移行期間中に新旧構成を並行稼働する環境 | 一時的に上限を超えるリスクがある |
アクティブリスナーの数え方を誤解しない
Application Gateway の FAQ では、アクティブリスナーは「ルールに関連付けられ、バックエンドプールへトラフィックを送るリスナー」と説明されています。リダイレクトのみを行うリスナーはアクティブリスナーとは見なされません。また、パスベースのリダイレクトルールでは、すべてのパスがリダイレクトしている場合を除き、リスナーはアクティブと見なされます。(Microsoft Learn)
実務では、次のように整理すると判断しやすくなります。
| リスナーの状態 | アクティブ扱い | 理由 |
|---|---|---|
| バックエンドプールへルーティングする | はい | 実際にアプリへトラフィックを転送するため |
| ルール内の既定構成がバックエンドへルーティングする | はい | デフォルト構成もリスナーとしてカウントされる |
| HTTP から HTTPS へリダイレクトするだけ | いいえ | バックエンドへ送らないため |
| パスベースルールの一部だけバックエンドへ送る | はい | すべてがリダイレクトではないため |
| どのルールにも関連付かない未使用リスナー | 通常はアクティブではない | ただし総リスナー数には含まれるため削除候補 |
失敗しやすいのは、Azure Portal で見えるリスナー数だけを見て「まだ 200 まで余裕がある」と判断するケースです。実際には、バックエンドへ送るリスナーが 100 に近づいていると、新しいアプリや独自ドメインを追加する段階で制約にぶつかります。
WAFを使っている場合は脚注の条件も確認する
Application Gateway limits の表では、^1 が付いたリソースについて、Standard SKU および CRS 3.2 または DRS を使う WAF-enabled SKU では表の数値が適用されます。一方、CRS 3.1 以前を使う WAF-enabled SKU では、サポートされる数が 40 とされています。(Microsoft Learn)
この脚注は見落とされがちです。HTTP listeners、Frontend ports、Backend HTTP settings、SSL certificates、Number of sites、Redirect configurations など、設計に関わる複数の項目に影響します。
確認すべき観点は次のとおりです。
| 確認対象 | 見るべきポイント |
|---|---|
| WAF SKU を使っているか | Standard_v2 なのか WAF_v2 なのかを確認する |
| CRS / DRS のバージョン | 古い CRS のまま運用していないかを確認する |
| リスナー数 | 200 だけでなく、WAF 条件による制約も見る |
| 証明書数 | 独自ドメインごとに証明書を分けている場合は注意 |
| 移行計画 | CRS 更新、WAF ポリシー変更、検証環境での動作確認を含める |
「HTTP listeners は 200」とだけ覚えていると、WAF 構成によっては実際の運用可能数とのズレが生じます。セキュリティポリシーの都合で古い CRS を使い続けている環境では、Application Gateway の設計レビュー時に必ず脚注まで確認してください。
運用チームが取るべき確認手順
今回の Update application-gateway-limits.md を受けて、運用チームが最初に行うべきことは、ドキュメント差分の確認ではなく、自社環境のリスナー構成の棚卸しです。
Azure CLIで総リスナー数を確認する
まずは、Application Gateway ごとの総リスナー数、ルール数、バックエンドプール数を一覧化します。
az network application-gateway list \
--query "[].{resourceGroup:resourceGroup,name:name,sku:sku.name,httpListeners:length(httpListeners),rules:length(requestRoutingRules),urlPathMaps:length(urlPathMaps),redirects:length(redirectConfigurations),backendPools:length(backendAddressPools),backendSettings:length(backendHttpSettingsCollection)}" \
-o tableこのコマンドで分かるのは、主に「総数」です。アクティブリスナー数は、単純に httpListeners の数を数えるだけでは正確に判断できません。
個別のApplication Gateway構成をJSONで確認する
アクティブリスナーの判定には、ルールとリダイレクト構成の関係を見る必要があります。
az network application-gateway show \
-g <resource-group-name> \
-n <application-gateway-name> \
-o json > appgw.jsonそのうえで、次の観点で確認します。
| 確認するJSON要素 | 見る内容 |
|---|---|
httpListeners | 総リスナー数 |
requestRoutingRules | リスナーがどのルールに紐づくか |
backendAddressPool | バックエンドへ送っているか |
backendHttpSettings | HTTP 設定と関連付いているか |
redirectConfiguration | リダイレクト専用か |
urlPathMap | パス単位でバックエンド送信とリダイレクトが混在していないか |
実務では、次のような棚卸し表を作るとレビューしやすくなります。
| リスナー名 | ホスト名 | ポート | ルール | バックエンド送信 | リダイレクトのみ | アクティブ判定 |
|---|---|---|---|---|---|---|
| listener-app-a | app-a.example.com | 443 | rule-app-a | あり | なし | アクティブ |
| listener-old-http | old.example.com | 80 | redirect-to-https | なし | あり | 非アクティブ |
| listener-mixed-path | service.example.com | 443 | path-rule | 一部あり | 一部あり | アクティブ |
ポイントは、リダイレクトが含まれているかどうかではなく、バックエンドへ送る経路が残っているかです。
IaC管理では「デプロイ前の上限チェック」を入れる
Terraform、Bicep、ARM テンプレートで Application Gateway を管理している場合、上限超過はレビュー時よりもデプロイ時に発覚しがちです。特に、ドメイン追加やテナント追加を定型作業にしている組織では、CI/CD パイプラインに簡易チェックを入れておくと事故を減らせます。
確認対象は次の4つです。
| IaCで確認する項目 | 理由 |
|---|---|
httpListeners の定義数 | 総リスナー数 200 に近づいていないか確認する |
| バックエンドへ送るルール数 | アクティブリスナー 100 の目安にする |
redirectConfigurations の数 | リダイレクト専用でも総数には影響する |
urlPathMaps と path rules | パスベースルールで意図せずアクティブ扱いにならないか確認する |
目安としては、上限ぎりぎりまで使い切る設計は避けるべきです。以下のように、運用上のしきい値を社内基準として持つと判断しやすくなります。
| 使用率の目安 | 状態 | 推奨アクション |
|---|---|---|
| 60%未満 | 余裕あり | 通常運用でよい |
| 60〜80% | 増加傾向を監視 | 新規ドメイン追加時にレビューする |
| 80〜90% | 設計見直しが必要 | リスナー統合、ゲートウェイ分割、Front Door 併用を検討する |
| 90%以上 | 追加作業にリスクあり | 新規追加を止め、移行計画を優先する |
この表のしきい値は Azure の公式上限ではなく、運用上の安全マージンです。特に本番環境では、移行作業や障害対応時に一時的なリスナー追加が必要になることがあります。常に 10〜20% 程度の余力を残す設計が現実的です。
影響を受けやすい構成パターン
今回のドキュメント更新でサービス挙動が変わるわけではありません。ただし、次のような構成では、Application Gateway limits の再確認を優先すべきです。
顧客ごとに独自ドメインを持つSaaS
B2B SaaS では、顧客ごとに customer-a.example.com や portal.customer-b.com のような独自ドメインを割り当てることがあります。
この場合、顧客追加のたびにリスナー、証明書、ルール、バックエンド設定が増えます。初期段階では問題なくても、数十〜百単位の顧客に拡大した時点で Application Gateway の制限に近づきます。
対策としては、次のような設計を検討します。
| 対策 | 向いているケース |
|---|---|
| ワイルドカード証明書を使う | サブドメイン体系を統一できる場合 |
| 1リスナーに複数ホスト名をまとめる | 同じバックエンド・同じルールで処理できる場合 |
| Application Gatewayを分割する | テナント群、地域、サービス単位で分離できる場合 |
| Azure Front Doorと組み合わせる | グローバル配信やエッジ側ルーティングを使いたい場合 |
旧URLからのリダイレクトを大量に持つ環境
リダイレクト専用リスナーはアクティブリスナーには数えられない場合がありますが、総リスナー数には含まれます。
そのため、旧ブランド、旧サービス名、旧キャンペーン URL などを長期間残している環境では、アクティブリスナー 100 よりも先に HTTP listeners 200 の制限に近づく可能性があります。
リダイレクトが多い場合は、Application Gateway だけで抱え込まず、DNS、アプリケーション側、CDN、Front Door など、どこでリダイレクトを処理するのが適切かを見直してください。
WAFポリシーを細かく分けている環境
WAF_v2 を使っている場合、セキュリティ要件に応じてポリシーや除外設定を細かく分けることがあります。これはセキュリティ上は妥当ですが、リスナー、サイト、証明書、バックエンド設定の増加とセットになりやすい構成です。
特に、古い CRS バージョンを維持している場合は、Application Gateway limits の脚注の影響を受ける可能性があります。リスナー数だけでなく、WAF エンジンやルールセットのバージョンも同時に確認してください。
移行準備で確認すべきポイント
Application Gateway v1 SKU は 2026年4月28日に廃止され、現在はサポート対象外とされています。FAQ でも、残っている v1 ゲートウェイについて v2 への移行が推奨されています。(Microsoft Learn)
そのため、今回のドキュメント更新を確認する際に v1 環境が残っている場合は、単なるリンク修正として扱わず、移行リスクの確認も行うべきです。
| 移行時の確認項目 | 内容 |
|---|---|
| SKU | v1 から Standard_v2 または WAF_v2 への移行方針 |
| リスナー数 | 現在の総数とアクティブ数 |
| 証明書 | Key Vault 連携、証明書形式、有効期限 |
| WAF | CRS / DRS、除外ルール、カスタムルール |
| サブネット | Application Gateway 用サブネットの空き IP |
| DNS | CNAME、TTL、切り替え手順 |
| 監視 | メトリック、ログ、アラートの再設定 |
| IaC | Terraform、Bicep、ARM テンプレートの更新 |
移行で失敗しやすいのは、「同じ設定を v2 に移せば終わり」と考えることです。実際には、証明書管理、WAF ポリシー、スケーリング、監視、DNS 切り替えまで含めて確認しないと、本番切り替え時に想定外の停止や 502 エラーにつながることがあります。
内部ドキュメントと運用手順書も更新する
今回の変更は FAQ アンカーの修正なので、外部仕様だけでなく、社内ドキュメントへの影響もあります。
次のような場所に古いアンカーリンクを貼っている場合は、リンク切れや意図しない位置への遷移が起きる可能性があります。
| 確認場所 | 具体例 |
|---|---|
| 社内Wiki | Application Gateway 設計ガイド |
| 運用手順書 | ドメイン追加手順、証明書更新手順 |
| IaCリポジトリ | README、設計コメント、レビュー観点 |
| 障害対応Runbook | リスナー上限、502調査、WAF切り分け |
| アーキテクチャレビュー資料 | SaaS拡張時の制限確認表 |
古いアンカーを使っている場合は、次の新しいアンカーに更新します。
#what-is-an-active-listener-versus-an-inactive-listener小さな修正に見えますが、運用チームがトラブル時に参照するリンクが正しくないと、調査の初動が遅れます。特にグローバルチームで英語版 Microsoft Learn を基準にしている場合は、ドキュメントリンクの更新も変更管理に含めておくと安全です。
よくある誤解と注意点
「リスナー200まで使えるから安全」と考える
HTTP listeners の総数は 200 ですが、トラフィックを送るアクティブリスナーは 100 に制限されています。バックエンドへルーティングする構成が多い場合、先に 100 の制限に到達する可能性があります。
「リダイレクトだけなら無制限」と考える
リダイレクト専用リスナーはアクティブリスナーではない場合がありますが、総リスナー数の上限からは逃れられません。古い URL や一時的なキャンペーン URL を残し続けると、総数の制限に近づきます。
「パスベースルールならリスナーを節約できる」と単純に考える
パスベースルーティングはリスナー削減に有効ですが、すべての問題を解決するわけではありません。URL map あたりの path-based rules にも上限があり、バックエンドや HTTP settings の数も増えます。
「WAFでも同じ上限」と考える
WAF-enabled SKU では、CRS / DRS の条件によって一部リソースのサポート数が変わります。WAF を使っている環境では、リスナー数だけでなく、ルールセットのバージョンも確認してください。
「公式ドキュメント更新は開発者だけが見ればよい」と考える
Application Gateway limits は、開発者だけでなく、クラウド管理者、ソリューションアーキテクト、技術意思決定者にも関係します。上限に近づいてから構成変更を考えると、移行期間、DNS 変更、証明書発行、WAF 検証の時間が足りなくなります。
次に取るべきアクション
今回の Azure 公式ドキュメント更新「Update application-gateway-limits.md」は、制限値の変更ではなく FAQ 参照リンクの修正です。ただし、対象が Application Gateway limits の HTTP listeners であるため、運用上は軽視すべきではありません。
まずは、次の3つを実施してください。
| 優先度 | アクション | 目的 |
|---|---|---|
| 高 | Application Gateway ごとの総リスナー数とアクティブリスナー数を棚卸しする | 上限接近リスクを把握する |
| 高 | WAF SKU と CRS / DRS のバージョンを確認する | 脚注条件による制約を見落とさない |
| 中 | 社内Wiki、Runbook、IaC README の FAQ リンクを更新する | 古いアンカーによる参照ミスを防ぐ |
制限表の数値が変わっていない場合でも、ドキュメント更新が「どの項目に触れているか」を見ることで、次に点検すべき運用リスクが分かります。今回の場合は、Application Gateway のリスナー設計、WAF 条件、v1 から v2 への移行状況を確認するのが最も実務的です。
コメント