Azure REST APIのMicrosoft.Cdn 2026-04-01-preview更新まとめ｜WAF SecurityPolicyの確認ポイント

Azure REST APIでMicrosoft.Cdnを自動化している場合、今回まず確認すべき点は 2026-04-01-preview APIバージョンが追加され、SecurityPolicyのWAF関連付けにisProfileLevelとroutesが加わったことです。特にAzure Front Door Standard/PremiumやCDNのWAF設定を、REST API、Bicep、ARMテンプレート、Terraform AzAPI、独自スクリプトで管理しているチームは、既存の設定取得・差分比較・生成コードが新しいプロパティをどう扱うか確認しておく必要があります。

一方で、これはpreview APIバージョンに関する変更です。すぐに本番環境のapi-versionを切り替えるべき、という話ではありません。既存の安定版APIや現在利用中のAPIバージョンで動いている構成は、まず影響範囲を棚卸しし、検証環境でSecurityPolicyのレスポンスとテンプレート差分を確認するのが安全です。

Azure REST APIのMicrosoft.Cdn 2026-04-01-previewで何が変わったのか

今回の更新は、Azure REST API仕様リポジトリのMicrosoft.Cdn向けPull Request「Add 2026-04-01-preview API version for Microsoft.Cdn with SecurityPol…」に関するものです。PRの説明では、v2026_04_01_previewをVersions enumに追加し、SecurityPolicyまわりに新しいWAF関連プロパティを追加する内容が示されています。(GitHub)

変更の中心は、Azure Front Door/CDNのSecurity Policy、特にWeb Application Firewallの関連付けです。従来はWAFポリシーをドメインやパスパターンに関連付ける観点が中心でしたが、今回の仕様では「プロファイルレベルのWAF関連付けかどうか」と「ルート単位での関連付け」を表現できるようになります。OpenAPI上でもSecurityPolicyWebApplicationFirewallAssociationにroutes、SecurityPolicyWebApplicationFirewallParametersにisProfileLevelが定義されています。(GitHub)

変更点	追加先	意味	確認すべき利用者
`2026-04-01-preview` APIバージョン	Microsoft.CdnのAPIバージョン	新しいプレビューAPIとして呼び出し可能な仕様が追加	REST APIを直接呼ぶ開発者、SDK生成担当
`isProfileLevel`	`SecurityPolicyWebApplicationFirewallParameters`	WAFポリシーの関連付けが既定のプロファイルレベルかどうかを示すboolean	WAF関連付けを自動化している運用担当
`routes`	`SecurityPolicyWebApplicationFirewallAssociation`	WAF関連付けの対象としてルートのリソース参照を指定	Azure Front DoorのRoute単位で制御したいチーム
2026-04-01-previewのサンプル追加	exampleファイル群	新APIバージョン用の要求・応答例	IaCテンプレートや検証コードの作成者
`openapi.json`生成	preview配下	SDK生成やAPI差分確認に使う仕様ファイル	SDK、CLI、コード生成パイプライン担当

影響を受けやすいのは「SecurityPoliciesをコードで管理している環境」

AzureポータルでWAFを手動設定しているだけであれば、今回の変更をすぐに反映する作業は少ないでしょう。影響を受けやすいのは、Azure REST APIやIaCでMicrosoft.Cdn/profiles/securityPoliciesを作成・更新・取得している環境です。

Microsoft Learnの既存テンプレート参照では、Microsoft.Cdn/profiles/securityPoliciesはBicep、ARMテンプレート、Terraform AzAPIでデプロイ対象として扱われ、parameters内にtype: WebApplicationFirewall、wafPolicy、associationsなどを指定する構造が示されています。既存の公開ドキュメントでは、少なくとも確認時点で最新表示は2025-09-01-preview系が中心で、associationsはdomainsとpatternsToMatchを持つ例になっています。(Microsoft Learn)

今回の2026-04-01-previewでは、同じSecurityPolicyでも関連付けの表現力が増えます。たとえば、次のような用途が考えられます。

プロファイル全体に既定WAFポリシーを適用するかを明示したい
特定のRouteだけに異なるWAFポリシーを関連付けたい
カスタムドメイン単位ではなく、ルーティング単位でWAFの適用範囲を整理したい
構成管理ツールで「プロファイルレベル」「ルートレベル」の差分を検出したい

ここで注意したいのは、routesが追加されたからといって、既存のdomainsやpatternsToMatchが不要になるとは限らない点です。今回の仕様ではdomains、routes、patternsToMatchが同じ関連付けオブジェクト内に並びます。実際の組み合わせ可否やサービス側の挙動は、プレビュー仕様・公式ドキュメント・実環境の検証結果をもとに判断する必要があります。(GitHub)

`isProfileLevel`はWAF適用範囲の判定に使える可能性が高い

isProfileLevelはboolean型で、OpenAPI上では「WAFポリシーの関連付けが既定のProfileレベルかどうかを示すフラグ」と説明されています。つまり、SecurityPolicyを取得したときに、そのWAF関連付けがプロファイル全体に対する既定適用なのか、より限定的な関連付けなのかを判定する材料になります。(GitHub)

運用上は、次のような場面で重要です。

利用シーン	`isProfileLevel`を確認する理由
監査	重要なFront Doorプロファイルに既定WAFが設定されているか確認できる
差分検出	意図せずプロファイル全体のWAF関連付けが外れていないか検出できる
移行作業	ドメイン単位・ルート単位の設定と、プロファイル既定設定を分けて整理できる
自動修復	プロファイルレベルWAFがない場合にアラートや再適用処理を実装しやすい

ただし、boolean型の追加プロパティは既存コードで意外な不具合を起こすことがあります。たとえば、独自ツールがレスポンスJSONを厳密なスキーマで検証している場合、新しいisProfileLevelを「未知のプロパティ」として弾く可能性があります。Go、TypeScript、C#などで生成したクライアントや、社内で定義したDTOを使っている場合は、追加フィールドを無視できる設計になっているか確認してください。

`routes`の追加でRoute単位のWAF関連付け確認が重要になる

routesはSecurityPolicyWebApplicationFirewallAssociationに追加されたResourceReference[]型のプロパティです。OpenAPI上では「List of routes」と説明され、各要素はリソースID参照として扱われます。(GitHub)

Azure Front Door Standard/Premiumでは、エンドポイント配下にRouteを作成し、カスタムドメイン、オリジングループ、ルールセットなどと組み合わせてトラフィックを制御します。既存ドキュメントでもSecurity Policyのサンプルは、WAFポリシー、カスタムドメイン、patternsToMatchを関連付ける構成になっています。(Microsoft Learn)

今回routesが追加されることで、今後は次のような設計確認が必要になります。

確認項目	具体的な確認方法
RouteごとのWAF適用範囲	SecurityPolicy取得結果に`routes`が含まれるか確認する
カスタムドメインとの整合性	`domains`と`routes`の組み合わせが想定した公開経路と一致するか見る
パスパターンとの整合性	`patternsToMatch`が広すぎないか、狭すぎないか確認する
IaCとの差分	Bicep、ARM、Terraform AzAPIで管理している宣言と実リソースを比較する
既存Route追加時の漏れ	新規Route作成時にWAF関連付けが自動で追従するか運用ルールを決める

失敗しやすいのは、ドメイン単位ではWAFが設定されているように見えるのに、新しく追加したRouteが想定どおり保護対象に入っていないケースです。Route単位の指定が可能になるほど、構成は柔軟になりますが、同時に「どの経路がどのWAFポリシーに守られているか」を一覧化しないと見落としが増えます。

すぐにAPIバージョンを切り替えるべきではない

今回のAPIバージョンは2026-04-01-previewです。プレビューAPIは検証や早期利用には有用ですが、本番運用に組み込む際は慎重に扱うべきです。

特に今回のPull Requestは、確認時点でGitHub上ではOpen状態で、ARMレビューやBreaking Change Reviewに関するラベル・コメントも表示されています。PRコメントには、mainブランチへマージされるとAPIがAzure顧客向けに出荷済みとみなされる旨や、 breaking change reviewに関する案内が含まれています。(GitHub)

そのため、実務では次の順番で判断するのが安全です。

判断ポイント	推奨アクション
既存APIで問題なく運用できている	すぐに切り替えず、影響調査だけ行う
Route単位のWAF関連付けが必要	検証環境で`2026-04-01-preview`を試す
生成SDKを使っている	対象SDKが新APIバージョンに対応した後で検証する
Terraform AzAPIで直接指定している	`type = "Microsoft.Cdn/profiles/securityPolicies@2026-04-01-preview"`を検証環境で試す
本番のWAF設定を自動更新している	変更前にGET結果、PUT/PATCH本文、差分検出ロジックをレビューする

「previewが追加されたから最新版に追従する」ではなく、「新しいプロパティが自社のWAF管理に必要か」「既存の自動化が新しいレスポンスで壊れないか」を基準に判断しましょう。

既存環境で確認すべきチェックリスト

今回のAzure REST API更新に対して、運用担当者が最初に行うべきことは大きく5つです。

REST APIを直接呼んでいるスクリプトを確認する

api-versionを固定しているスクリプトを洗い出してください。特に次のようなURLを呼んでいるコードが対象です。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cdn/profiles/{profileName}/securityPolicies/{securityPolicyName}?api-version={apiVersion}

Microsoft LearnのREST APIリファレンスでは、Security Policies – Getはプロファイル内の既存Security Policyを取得する操作として説明され、api-versionが必須のクエリパラメータになっています。(Microsoft Learn)

確認すべきポイントは、api-versionを変えたときにレスポンスのproperties.parameters配下を既存コードが処理できるかです。JSONをそのまま保存・比較するだけなら影響は小さいかもしれませんが、型付きオブジェクトに変換している場合は追加プロパティ対応が必要になることがあります。

IaCテンプレートのSecurityPolicy定義を確認する

Bicep、ARMテンプレート、Terraform AzAPIでMicrosoft.Cdn/profiles/securityPoliciesを定義している場合は、現在のAPIバージョンとparametersの構造を確認しましょう。

既存の例では、associations内にdomainsとpatternsToMatchを指定し、wafPolicy.idでWAFポリシーを参照する構成が使われています。(Microsoft Learn)

今後routesを使う場合は、RouteのリソースIDを正しく指定する必要があります。IDの組み立てを手書きしているテンプレートでは、プロファイル名、エンドポイント名、Route名の取り違えが起きやすいので、可能であれば既存リソース参照やテンプレート関数から生成する設計にした方が安全です。

差分検出ツールが追加プロパティを誤検知しないか確認する

構成監査ツールや自社スクリプトでAzureリソースのJSONを比較している場合、新しいisProfileLevelやroutesが追加されたことで差分が発生する可能性があります。

よくある失敗は次の3つです。

失敗パターン	起きる問題	対策
未知のプロパティをエラー扱いする	取得処理やCIが失敗する	追加プロパティを許容するスキーマにする
すべての差分を変更扱いする	意図しない再デプロイが発生する	比較対象を管理対象プロパティに絞る
null・未指定・空配列を同一視しない	無意味な差分が出続ける	正規化処理を追加する

特にroutesは配列です。順序の違いで差分が出るツールでは、リソースIDをソートして比較するなどの工夫が必要になります。

SDKやクライアント生成のタイミングを確認する

今回のPRでは、2026-04-01-previewのopenapi.jsonも生成されています。OpenAPIのinfo.versionには2026-04-01-previewが設定され、タグとしてSecurityPolicies、Routes、Profilesなどが含まれています。(GitHub)

AutoRestや独自のOpenAPI生成パイプラインを使っている場合は、次の点を確認してください。

新しいAPIバージョンを生成対象に含めるか
既存SDKと別バージョンとして扱うか
isProfileLevelのnullable/optional扱い
routes配列の要素型が既存のResourceReferenceと一致するか
生成後のモデル名やメソッド名が既存コードと衝突しないか

Preview版のSDKや生成コードを本番の自動デプロイに直接組み込む前に、読み取り専用のGET処理から検証するのが現実的です。

WAF適用範囲を棚卸しする

今回の変更をきっかけに、Azure Front Door/CDNのWAF適用範囲を棚卸ししておくと、今後の移行や監査が楽になります。

最低限、次の情報を一覧化してください。

項目	記録する内容
Profile	Front Door/CDNプロファイル名、SKU
SecurityPolicy	SecurityPolicy名、WAFポリシーID
適用レベル	プロファイルレベルか、ドメイン/Route単位か
Domains	関連付けられているカスタムドメイン
Routes	関連付けられているRoute
Patterns	`/*`などのパスパターン
管理方法	Portal、Bicep、ARM、Terraform、REST API、独自ツール

この一覧がない状態でAPIバージョンを切り替えると、設定変更後に「どの公開経路がWAFで保護されているか」を確認するだけで時間を使ってしまいます。

検証環境での確認手順

本番反映前の検証では、いきなりPUTやPATCHを実行するのではなく、GETと差分確認から始めるのが安全です。

手順	作業	目的
1	既存APIバージョンでSecurityPolicyをGETする	現在のレスポンス構造を保存する
2	`2026-04-01-preview`でGETできるか試す	新APIバージョンの利用可否を確認する
3	`parameters`配下の差分を見る	`isProfileLevel`や`routes`の出方を確認する
4	IaCテンプレートと実リソースを比較する	管理対象外の差分を把握する
5	読み取り系スクリプトを更新する	追加プロパティで壊れないようにする
6	検証用SecurityPolicyでPUT/PATCHを試す	書き込み時の仕様とサービス挙動を確認する
7	本番適用基準を決める	いつ、どの環境から切り替えるか判断する

GETの結果だけで判断せず、WAFの実際の適用範囲も確認してください。たとえば、Routeを追加した後にSecurityPolicy側のroutesへ反映されるのか、手動関連付けが必要なのか、IaC再適用でどう差分が出るのかを検証します。

移行時に避けたい失敗

`api-version`だけを変えて既存本文をそのまま流用する

REST APIのプレビュー版では、既存本文が受け入れられる場合もありますが、レスポンスやサーバー側の既定値が変わることがあります。api-versionだけを差し替えて本番PATCHを実行すると、予期しない差分が出る可能性があります。

移行時は、まずGET結果を保存し、PUT/PATCH本文に含めるプロパティを明示的に確認してください。特にWAF関連はセキュリティ境界に関わるため、テンプレートの自動生成や丸ごと上書きには注意が必要です。

`routes`を指定したつもりでリソースIDを間違える

RouteのリソースIDは、プロファイル、エンドポイント、Route名を含む階層構造になります。ドメインIDやエンドポイントIDと取り違えると、設定が失敗するか、意図しない対象に関連付けようとする可能性があります。

テンプレートでは、文字列連結よりも既存リソース参照を使う方が安全です。手書きする場合は、少なくとも検証環境でGET結果に表示されるRoute IDと一致するか確認しましょう。

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

2026-04-01-previewは名前のとおりプレビューAPIです。新機能の検証には向いていますが、すべての本番自動化を即座に切り替える判断は慎重に行うべきです。

本番で使う場合は、次の条件を満たしてからにしてください。

既存APIとのレスポンス差分を確認済み
IaCツールやSDKが新プロパティを扱える
ロールバック時に戻すAPIバージョンが決まっている
WAF適用範囲の検証手順がある
セキュリティ担当と運用担当が変更内容を把握している

今回の更新をどう活用すべきか

今回のAzure REST API更新は、単なるAPIバージョン追加ではなく、Microsoft.CdnのSecurityPolicy管理をより細かく扱うための下地と見ておくとよいでしょう。特にisProfileLevelとroutesは、WAF適用範囲を「プロファイル全体」「ドメイン」「Route」「パスパターン」のように整理するうえで重要な情報になります。

今すぐ取るべき行動は、次の3つです。

1つ目は、Microsoft.Cdn/profiles/securityPoliciesを使っているコードやテンプレートを洗い出すことです。REST API、Bicep、ARM、Terraform AzAPI、独自監査ツールのどれで管理しているかを確認します。

2つ目は、検証環境で2026-04-01-previewのGET結果を確認し、isProfileLevelとroutesが既存ツールに与える影響を見ることです。未知プロパティで壊れる処理があれば、本番移行前に修正します。

3つ目は、WAFの適用範囲を一覧化することです。プロファイル、SecurityPolicy、WAFポリシー、ドメイン、Route、パスパターンを対応付けておけば、今後のAPIバージョン移行や監査対応が楽になります。

2026-04-01-previewは、すぐに全環境へ適用するものではなく、Azure Front Door/CDNのWAF関連付けをより正確に管理したいチームが検証を始めるべきAPIバージョンです。まずは読み取り系の確認から始め、差分検出とIaCの対応状況を整えたうえで、必要な環境だけ段階的に採用しましょう。

この記事を書いた人

佐藤健司

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