Azure REST APIのMicrosoft.Cdn 2026-04-01-preview更新点｜WAF Security Policyの影響と確認手順

Azure REST APIでMicrosoft.Cdn、特にAzure Front Door Standard/PremiumのWAFセキュリティポリシーをREST APIやIaCで管理している場合は、2026-04-01-preview API versionの追加予定を確認しておくべきです。今回の要点は、すぐ全環境を移行することではありません。まずは、securityPoliciesを作成・更新する自動化でapi-versionを固定しているか、WAFポリシーの適用範囲をドメイン単位・ルート単位・プロファイル単位のどれで管理しているかを棚卸しすることが重要です。

GitHub上のAzure REST API仕様更新PRでは、Microsoft.Cdnに2026-04-01-previewを追加し、Security Policy関連でisProfileLevelとroutesを扱えるようにする変更が示されています。対象は主に、Azure Front Door/CDNのWAFポリシー関連付けをAPIで制御している開発者、SRE、クラウド運用担当者、IaCテンプレート管理者です。(GitHub)

今回のAzure REST API更新で何が変わるのか

今回の変更は、Microsoft.Cdn名前空間のAzure REST API仕様に、プレビューAPI versionである2026-04-01-previewを追加する内容です。PRの説明では、主な変更点として次の4つが挙げられています。(GitHub)

変更点	内容	実務上の意味
API versionの追加	v2026_04_01_previewをVersions enumに追加	SDK生成、REST呼び出し、IaCスキーマで新バージョンを参照できる可能性がある
isProfileLevelの追加	SecurityPolicyWebApplicationFirewallParametersにbooleanプロパティを追加	WAFポリシー関連付けがプロファイル既定レベルかどうかを表す
routesの追加	SecurityPolicyWebApplicationFirewallAssociationにResourceReference[]として追加	セキュリティポリシーをルート単位で関連付ける表現が可能になる
サンプルとOpenAPIの追加	2026-04-01-preview向けのexample filesとopenapi.jsonを生成	実装時のリクエスト形式やレスポンス形式を確認しやすくなる

特に重要なのは、domainsとpatternsToMatchだけでなく、routesをセキュリティポリシーの関連付けに含められる点です。既存の公開REST APIドキュメントでは、Security Policy Web Application Firewall Associationの主な要素はdomainsとpatternsToMatchとして説明されており、routesやisProfileLevelは現在の2025-04-15ページには出ていません。(Microsoft Learn)

まず押さえるべき結論

今回のAzure REST API更新は、すべてのAzure利用者に即時対応を求めるものではありません。影響が出やすいのは、次のような環境です。

対象者・環境	対応優先度	確認すべきこと
Azure Front DoorのWAF Security PolicyをREST APIで作成・更新している	高	api-version、リクエストボディ、レスポンス解析処理
Terraform AzAPI、ARMテンプレート、BicepでMicrosoft.Cdn/profiles/securityPoliciesを管理している	高	API version固定、スキーマ検証、差分検出
Azure SDKを自動生成・更新して使っている	中〜高	Versions enum更新、モデル追加、互換性テスト
Azure Portal中心で手動運用している	低	仕様変更の把握と将来の運用設計
WAFポリシーの適用範囲を厳密に分けている大規模サイト	高	プロファイル単位、ドメイン単位、ルート単位の整理

運用上の判断基準はシンプルです。securityPoliciesをコードで触っていないなら、今すぐ変更する必要性は高くありません。一方、WAFポリシーの作成・更新・差分管理を自動化している場合は、プレビューAPIを使うかどうかに関係なく、既存コードが新しいプロパティに耐えられるか確認しておくべきです。

isProfileLevelとは何か

isProfileLevelは、SecurityPolicyWebApplicationFirewallParametersに追加されるbooleanプロパティです。仕様上の説明では、WAFポリシーの関連付けが「既定のProfileレベル」であるかを示すフラグとされています。(GitHub)

実務では、次のように理解すると判断しやすくなります。

isProfileLevelの考え方	想定される使い分け
true	プロファイル全体に対する既定のWAFポリシー関連付けを表す場合
false	特定のドメイン、ルート、パスパターンに限定してWAFポリシーを関連付ける場合
未指定	既存APIや既存テンプレートとの互換性を維持したい場合。ただし新APIでの既定動作は実環境で確認が必要

注意したいのは、isProfileLevelが追加されたからといって、既存のdomainsやpatternsToMatchの設計が不要になるわけではない点です。むしろ、プロファイル全体に適用するのか、特定ルートだけに絞るのかを明示しやすくなる変更と考えるべきです。

routesの追加で何が便利になるのか

これまでのSecurity Policy関連付けでは、主にカスタムドメインとパスパターンを組み合わせてWAFの適用範囲を表現していました。2026-04-01-previewの仕様では、SecurityPolicyWebApplicationFirewallAssociationにroutesが追加され、ルートリソースへの参照を含められるようになります。(GitHub)

サンプルでは、domains、routes、patternsToMatchを同じassociation内に含める形が示されています。routesのIDは、Microsoft.Cdn/profiles/{profileName}/afdEndpoints/{endpointName}/routes/{routeName}形式のリソース参照として扱われています。(GitHub)

{
  "properties": {
    "parameters": {
      "type": "WebApplicationFirewall",
      "wafPolicy": {
        "id": "/subscriptions/subid/resourcegroups/RG/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/wafTest"
      },
      "isProfileLevel": false,
      "associations": [
        {
          "domains": [
            {
              "id": "/subscriptions/subid/resourcegroups/RG/providers/Microsoft.Cdn/profiles/profile1/customdomains/testdomain1"
            }
          ],
          "routes": [
            {
              "id": "/subscriptions/subid/resourcegroups/RG/providers/Microsoft.Cdn/profiles/profile1/afdEndpoints/EndpointName2/routes/RouteName2"
            }
          ],
          "patternsToMatch": [
            "/*"
          ]
        }
      ]
    }
  }
}

この変更が役立つのは、1つのAzure Front Doorプロファイル内で複数のアプリケーションやルートを管理しているケースです。たとえば、同じカスタムドメイン配下でも、/api/*、/admin/*、/static/*で異なるWAF運用をしたい場合、ルート単位の関連付けを明示できると設計やレビューがしやすくなります。

現時点で注意すべき公開状況

2026年5月時点のAzure REST API Specifications一覧では、Microsoft.Cdn/Cdnの安定版として2025-06-01、プレビューとして2025-09-01-previewが表示されています。一方、今回の2026-04-01-previewはGitHub PR上の変更として確認できるため、利用前にはMicrosoft Learn、Azure REST APIリファレンス、SDKリリース、実際のARMエンドポイントでの受け付け状況を確認する必要があります。(Azure)

プレビューAPIは、仕様確認や検証には有用ですが、本番環境へ即投入する前提で扱うべきではありません。特にAzure Front DoorのWAFはセキュリティ境界に関わるため、「APIが呼べる」だけでなく、「期待した範囲にだけWAFポリシーが適用される」ことを必ず検証してください。

影響範囲を確認するチェックリスト

自社環境で影響があるかを判断するには、次の順で確認します。

確認項目	見る場所	判断ポイント
securityPoliciesを使っているか	RESTクライアント、IaC、CI/CD、運用スクリプト	使っていなければ直接影響は小さい
api-versionを固定しているか	URL、テンプレート、SDK設定	固定しているなら既存動作は急に変わりにくい
レスポンスを厳密に検証しているか	JSON Schema、独自バリデーション、型定義	未知のisProfileLevelやroutesで失敗しないか
WAFの適用範囲をどう管理しているか	Azure Front Door設計書、WAF運用ルール	プロファイル・ドメイン・ルート・パスのどれを基準にするか
SDKを自動更新しているか	Dependabot、Renovate、CIのコード生成	enum追加やモデル追加で差分が出る可能性
本番と検証でAPI versionが違うか	環境変数、設定ファイル	検証だけプレビュー、本番は安定版などの切り分けが必要

特に見落としやすいのは、レスポンス処理です。サンプルでは、作成・更新・取得の例にisProfileLevelやroutesが含まれるケースがありますが、ステータスコードや操作によって返却例の形が完全に同じとは限りません。自動化では、PUT/PATCHの直後のレスポンスだけで判断せず、最終的にGETで状態を確認する運用にしておくと安全です。(GitHub)

既存環境から移行する場合の進め方

2026-04-01-previewを検証する場合は、いきなり本番テンプレートのAPI versionを書き換えるのではなく、段階的に進めます。

既存のAPI versionを棚卸しする

まず、リポジトリや運用端末でMicrosoft.CdnとsecurityPoliciesを検索します。

rg "Microsoft.Cdn|securityPolicies|api-version" .

IaCを使っている場合は、次のような指定も探します。

rg "Microsoft.Cdn/profiles/securityPolicies@" .

この時点で確認したいのは、「どのAPI versionで」「どの環境に」「どのWAFポリシーを」適用しているかです。コード上でapi-version=2025-04-15などを明示しているなら、今回のプレビュー追加によって既存呼び出しがただちに変わるわけではありません。

検証環境で新旧のリクエスト差分を見る

次に、検証環境で現在のリクエストボディと2026-04-01-preview向けのリクエストボディを比較します。

項目	既存の考え方	新APIで確認したい点
WAFポリシー参照	wafPolicy.idで指定	変更なし。ただし関連付け範囲との整合性を確認
ドメイン指定	associations[].domains	既存どおり利用可能か確認
パス指定	associations[].patternsToMatch	routesと併用した場合の適用範囲を確認
ルート指定	なし	associations[].routesで意図したルートだけに適用されるか確認
プロファイルレベル	明示しにくい	isProfileLevelのtrue/falseで期待通りになるか確認

検証では、WAFが「効かない」ことだけでなく、「効きすぎる」ことにも注意が必要です。たとえば、管理画面向けルートだけに厳しいWAFポリシーを当てるつもりが、プロファイル全体に適用されると、一般ユーザー向けページまで誤検知の影響を受ける可能性があります。

GETで最終状態を確認する

PUTやPATCHの成功だけで移行完了と判断しないようにします。Azure Front DoorのSecurity Policy操作は、作成時に200、201、202などのレスポンスが返る可能性があり、202 Acceptedでは非同期処理になることがあります。現在のREST APIドキュメントでも、Security Policyの作成は202 Acceptedを返し、操作が非同期で完了する場合があると説明されています。(Microsoft Learn)

実務では、次の流れにするのが安全です。

手順	内容
1	PUTまたはPATCHでSecurity Policyを作成・更新する
2	非同期操作の場合は完了を待つ
3	GETでSecurity Policyを再取得する
4	isProfileLevel、routes、domains、patternsToMatchを確認する
5	実際のリクエストでWAFログ・アクセス結果を確認する

実装時に失敗しやすいポイント

api-versionだけを変更して安心してしまう

Azure REST APIでは、URLのapi-versionを変えるだけで利用する仕様が変わります。しかし、API versionを変えても、リクエストボディ、レスポンス処理、SDKの型、IaCのスキーマが追従していなければ失敗します。

特に次のようなコードは注意が必要です。

PUT .../securityPolicies/securityPolicy1?api-version=2026-04-01-preview

このURLだけを変えても、routesを使う設計になっていない、レスポンスの新プロパティを無視できない、SDKがまだ対応していない、といった問題が残ります。

domainsとroutesの関係を曖昧にする

domains、routes、patternsToMatchを併用する場合、WAFポリシーがどのトラフィックに適用されるのかを運用チーム全員が同じように理解している必要があります。

おすすめは、設定前に次のような表を作ることです。

対象	設定値	期待するWAF適用範囲
カスタムドメイン	testdomain1	対象ドメインに来たリクエスト
ルート	RouteName2	指定ルートに一致するリクエスト
パス	/*	ルート配下の全パス
プロファイルレベル	isProfileLevel: false	プロファイル全体ではなく個別関連付けとして扱う

この表を作らずにテンプレートだけ更新すると、「なぜこのルートにWAFが当たっているのか」「なぜこのドメインには当たらないのか」を後から追跡しにくくなります。

プレビューAPIを本番の標準にしてしまう

previewを含むAPI versionは、検証や先行確認には便利ですが、安定版と同じ扱いにするのは避けるべきです。特にセキュリティポリシーは、誤設定が可用性やセキュリティに直結します。

本番では、次のようなルールを決めておくと安全です。

ルール	理由
本番は安定版APIを基本にする	予期しない仕様変更を避ける
プレビューAPIは検証環境でのみ使う	新機能の挙動を確認する
API versionを環境変数で分ける	本番・検証の切り替えを明確にする
GET結果を監査ログに残す	変更後の実状態を追跡できる
ロールバック用の既存テンプレートを保存する	WAF誤適用時に戻せるようにする

SDKやIaC利用者が確認すべきこと

Azure SDKを使っている場合、REST API仕様にVersions enumが追加されても、すぐに手元のSDKで使えるとは限りません。SDKパッケージのリリース、生成コード、依存関係の更新タイミングが必要です。PRではv2026_04_01_previewの追加が示されていますが、実際に利用するSDKで該当バージョンが選択できるかは個別に確認してください。(GitHub)

Terraform AzAPIやARMテンプレートを使う場合は、typeやapiVersionの指定だけでなく、スキーマ検証の有無も確認します。新しいプロパティを先行利用する場合、ツール側のスキーマが追いついていないと、Azure側では受け付け可能でもローカル検証で失敗することがあります。

対応の優先順位

今回の更新に対して、現実的な対応順は次のとおりです。

優先度	対応
1	Microsoft.Cdn/profiles/securityPoliciesをコードで管理している箇所を洗い出す
2	現在使っているapi-versionを一覧化する
3	WAFポリシーの適用範囲を、プロファイル・ドメイン・ルート・パスで整理する
4	検証環境でisProfileLevelとroutesを含むリクエストの挙動を確認する
5	SDK、IaC、CI/CDのスキーマや型定義が新プロパティに対応できるか確認する
6	本番適用する場合は、安定版APIとの使い分けとロールバック手順を用意する

すぐにやるべき最小アクションは、リポジトリ内のMicrosoft.CdnとsecurityPoliciesの検索です。該当がなければ、今回の更新は当面ウォッチで問題ありません。該当がある場合は、WAFの適用範囲とAPI version固定の有無を確認してください。

まとめ

今回のAzure REST API更新は、Microsoft.CdnのSecurity Policy、特にAzure Front DoorのWAFポリシー関連付けをより細かく扱うためのプレビューAPI追加と捉えると分かりやすいです。重要な変更は、2026-04-01-preview API versionの追加、isProfileLevelによるプロファイルレベル判定、routesによるルート単位の関連付けです。

対応が必要なのは、Azure Front DoorやCDNのWAF Security PolicyをREST API、SDK、IaCで管理している環境です。まずは既存のapi-versionとsecurityPolicies利用箇所を棚卸しし、検証環境で新プロパティの挙動を確認しましょう。本番適用は、Microsoft LearnやSDKの公開状況、実際のARMエンドポイントでのサポート状況を確認したうえで、段階的に進めるのが安全です。