「Azure REST API documentation update: Shai/waf changes on 2025 11 01 for reference」は、Azure REST API全体の仕様変更ではなく、Azure Front Door Service の Web Application Firewall（WAF）向け REST API仕様、とくに Managed Rule Sets 周辺の更新です。結論から言うと、すぐに本番のWAFポリシーを書き換える案件ではありません。まず確認すべきなのは、Front Door WAFのマネージドルールセット一覧をREST APIで取得している監視ツール、棚卸しスクリプト、SDK生成、OpenAPI/TypeSpec連携です。
今回のポイントは、PR名に「2025 11 01 for reference」とありますが、差分の中心は 2026-04-01 APIバージョンの追加 と、マネージドルールセットの状態や表示名、ルール単位の paranoiaLevel を扱えるようにする変更です。一方で、PRはDraftとして表示されており、マージ条件やレビューに関する自動コメントも確認できます。正式なAPIとして扱う前に、PRがマージ済みか、Microsoft LearnのREST APIドキュメントに反映されているかを必ず確認してください。(GitHub)
Azure REST API documentation updateの概要
この更新は、Azure REST API仕様リポジトリ Azure/azure-rest-api-specs の PR #42663「Shai/waf changes on 2025 11 01 for reference」として確認できます。対象ファイルは、Front Door WAFのTypeSpec定義である main.tsp、models.tsp、および生成された stable/2026-04-01/openapi.json です。PRのファイル差分では、main.tsp に v2026_04_01: "2026-04-01" が追加され、models.tsp にManaged Rule Set関連の新しい読み取り専用プロパティが追加されています。(GitHub)
現行のMicrosoft Learnでは、Front Door WAFのManaged Rule Sets List APIとして、api-version=2025-11-01 のエンドポイントが公開されています。このAPIは、サブスクリプション内で利用可能なすべてのマネージドルールセットを一覧表示するためのものです。(Microsoft Learn)
| 確認項目 | 内容 | 実務上の見方 |
|---|---|---|
| 対象サービス | Azure Front Door Service / Web Application Firewall | WAFポリシー、Managed Rule Sets、ルール棚卸しに関係 |
| 対象API領域 | Managed Rule Sets List、関連するOpenAPI/TypeSpec定義 | 監視・自動化・SDK生成で影響しやすい |
| 追加されるAPIバージョン | 2026-04-01 | すぐ本番で使うのではなく、正式公開後に検証 |
| 主な追加項目 | displayName、status、ManagedRuleSetStatus、paranoiaLevel | ルールセットの状態管理や可視化に使える |
| 注意点 | PRはDraft表示 | マージ前提で本番コードを変更しない |
何が変わるのか
今回のAzure REST API documentation updateで注目すべき変更は、WAFルールセットを「設定する」ための項目というより、ルールセットやルールの状態を「把握する」ためのメタデータ追加です。
2026-04-01 APIバージョンが追加される
main.tsp の Versions enumに、既存の 2025-10-01、2025-11-01 に続いて 2026-04-01 が追加されています。PR名だけを見ると2025-11-01向けの参照変更に見えますが、実際の差分では2026-04-01のOpenAPI生成が含まれている点が重要です。(GitHub)
実務では、次のようなコードや設定を確認します。
grep -R "frontDoorWebApplicationFirewallManagedRuleSets" .
grep -R "api-version=2025-11-01" .ここで該当するスクリプトやIaC、独自ツールが見つかった場合は、2026-04-01が正式公開された後に比較検証できるよう、現行レスポンスのスナップショットを残しておくと移行が楽になります。
ManagedRuleSetStatus が追加される
models.tsp には、マネージドルールセットのライフサイクル状態を表す ManagedRuleSetStatus が追加されています。定義されている値は Preview、GA、Deprecated、Supported です。生成されたOpenAPI JSONでも、同じ列挙値が確認できます。(GitHub)
この追加により、セキュリティ運用チームは「このルールセットは本番利用してよいのか」「非推奨になっていないか」を機械的に判定しやすくなります。ただし、値を固定的に決め打ちしすぎるのは危険です。Azure REST APIの仕様では将来的に状態値が増える可能性があるため、未知の値はエラーではなく Unknown や ReviewRequired として扱う設計が安全です。
displayName と status がManaged Rule Set Definitionに追加される
ManagedRuleSetDefinitionProperties には、読み取り専用の displayName と status が追加されています。displayName は人間が読みやすい表示名、status はルールセットのライフサイクル状態を表すプロパティです。(GitHub)
これまでの2025-11-01ドキュメントでは、Managed Rule Set Definitionの主なプロパティとして ruleSetId、ruleSetType、ruleSetVersion、ruleGroups などが示されていました。新しいプロパティが正式反映されれば、管理画面やレポートで「Microsoft_DefaultRuleSet 2.2」のような内部的な識別子だけでなく、より分かりやすい表示名や状態を併記できるようになります。(Microsoft Learn)
注意したいのは、displayName を識別子として使わないことです。表示名は人間向けのラベルであり、将来的に表記が変わる可能性があります。自動化では引き続き ruleSetType、ruleSetVersion、必要に応じて ruleSetId をキーにしてください。
paranoiaLevel がManaged Rule Definitionに追加される
ManagedRuleDefinition には、読み取り専用の paranoiaLevel が追加されています。説明では、DRSルールにのみ適用され、Bot Manager、DDoS、AIルールでは省略されるとされています。生成されたOpenAPI JSONでも、paranoiaLevel は integer / int32 の読み取り専用プロパティとして確認できます。(GitHub)
これは、WAFのチューニングに関わる担当者にとって有用です。たとえば、誤検知の多いルールを棚卸しするとき、ルールID、ルールグループ、既定アクション、感度に加えて、DRSのparanoia levelを並べて確認できるようになります。
ただし、paranoiaLevel が存在しないことをエラー扱いしてはいけません。仕様上、DRS以外の一部ルールでは省略されます。JSONパーサーやダッシュボードでは、null または未定義を「対象外」として扱うのが安全です。
影響範囲は「WAFの動作変更」より「管理・可視化・自動化」
この更新で最も影響を受けるのは、WAFポリシーの作成・更新処理そのものよりも、WAFルールセットを参照している管理系の処理です。
| 影響を受ける可能性が高いもの | 具体例 | 確認すべきこと |
|---|---|---|
| REST APIでルールセット一覧を取得するツール | az rest、独自の棚卸しスクリプト、監査レポート | 追加フィールドが来ても壊れないか |
| OpenAPI/TypeSpecから生成するSDK | 社内SDK、型定義、クライアントコード | 新しい読み取り専用プロパティを反映するか |
| セキュリティ運用ダッシュボード | ルールセットのバージョン一覧、非推奨検知 | status をどのように表示・警告するか |
| WAFチューニング運用 | 誤検知対応、除外設定、ルールID管理 | paranoiaLevel を参考情報として扱うか |
| IaCの検証パイプライン | Bicep、ARMテンプレート、Terraform周辺の検証 | APIバージョンを固定していないか |
逆に、現行のWAFポリシーJSONをそのままPUT/PATCHする処理では、すぐに入力項目が増えるとは限りません。2025-11-01のPolicies APIでは、WAFポリシーの properties.managedRules はManaged Rule Set Listとして定義され、ruleSetType、ruleSetVersion、ruleSetAction、ruleGroupOverrides などが管理対象です。今回の追加は、主にManaged Rule Set Definition側の読み取りメタデータとして理解するのが自然です。(Microsoft Learn)
対応すべき人
Azure Front Door WAFをREST APIで管理している開発者
frontDoorWebApplicationFirewallManagedRuleSets を直接呼び出している場合は、最も優先して確認すべきです。現行の2025-11-01 APIでは、次のようなGETリクエストで利用可能なマネージドルールセットを取得します。(Microsoft Learn)
SUBSCRIPTION_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
az rest --method get \
--url "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/providers/Microsoft.Network/frontDoorWebApplicationFirewallManagedRuleSets?api-version=2025-11-01"正式に2026-04-01が公開された後は、同じ環境でレスポンス差分を比較します。PR段階では、まだ本番処理に api-version=2026-04-01 を固定しないでください。
az rest --method get \
--url "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/providers/Microsoft.Network/frontDoorWebApplicationFirewallManagedRuleSets?api-version=2026-04-01"比較するときは、単に成功・失敗を見るだけでなく、properties.displayName、properties.status、ruleGroups[].rules[].paranoiaLevel が返るか、既存フィールドの意味が変わっていないかを確認します。
セキュリティ運用・SOC担当者
WAFのルールセットは、新しい攻撃に対応するため継続的に更新されます。Azure Advisorでも、Front Door WAFでは最新のDRSルールセットへのアップグレードが推奨されており、保護性能や誤検知低減の観点で重要度が高いとされています。(Microsoft Learn)
今回の status 追加は、こうした運用判断を自動化する材料になります。たとえば、次のようなルールをダッシュボードに組み込めます。
status | 運用上の扱い例 |
|---|---|
GA | 本番利用候補として扱う |
Supported | 利用可能だが、GAとの違いをドキュメントで確認する |
Preview | 検証環境のみ許可し、本番適用はレビュー必須 |
Deprecated | 移行計画を作成し、期限や代替バージョンを確認する |
| 未知の値 | 自動ブロックせず、レビュー対象として通知する |
ポイントは、Deprecated を検知した瞬間に自動で設定変更しないことです。WAFのルールセット変更は、誤検知やブロック挙動に影響する可能性があります。まずはDetectionモードや検証環境でログを確認し、必要に応じて除外設定を見直します。
SDK・型定義を生成しているプラットフォームチーム
OpenAPIやTypeSpecをもとにクライアントコードを生成している場合、今回の変更は型定義に反映されます。読み取り専用プロパティが増えるため、多くのケースでは後方互換的に扱えますが、次のような実装では注意が必要です。
| 実装パターン | 起きやすい問題 | 対応 |
|---|---|---|
| レスポンスJSONを厳密なスキーマで検証している | 未知のプロパティで検証エラーになる | 追加フィールドを許容する |
| enumを固定値だけでswitchしている | 新しい状態値で処理が落ちる | default分岐を用意する |
displayName を主キーに使う | 表示名変更で紐付けが壊れる | ruleSetType と ruleSetVersion を主キーにする |
paranoiaLevel を必須扱いする | DRS以外のルールでnullエラーになる | nullableとして扱う |
TypeScriptで扱うなら、status は厳密な固定enumよりも、将来の値を受け止められる型にしておくと安全です。
type ManagedRuleSetStatus = "Preview" | "GA" | "Deprecated" | "Supported" | string;
type ManagedRuleSetDefinitionProperties = {
ruleSetId?: string;
ruleSetType?: string;
ruleSetVersion?: string;
displayName?: string;
status?: ManagedRuleSetStatus;
};
type ManagedRuleDefinition = {
ruleId?: string;
defaultAction?: string;
defaultState?: string;
description?: string;
paranoiaLevel?: number | null;
};移行・設定確認の手順
今回の更新は、いきなり移行作業を始めるよりも、まず「影響を受ける箇所の棚卸し」と「正式公開後に差分を確認できる準備」を進めるのが現実的です。
| 手順 | 作業 | 具体的な確認ポイント |
|---|---|---|
| 現行利用の棚卸し | APIバージョン固定箇所を探す | api-version=2025-11-01、Managed Rule Sets Listの呼び出し |
| レスポンス保存 | 現行APIのJSONを保存する | ruleSetType、ruleSetVersion、ruleGroups、rules |
| パーサー確認 | 未知フィールドを許容する | displayName や status が増えても失敗しないか |
| enum処理確認 | 未知のstatusを扱えるようにする | default分岐、監査ログ、通知 |
| null処理確認 | paranoiaLevel を任意項目にする | 未定義を「対象外」として扱う |
| 検証環境で比較 | 正式公開後に2026-04-01を試す | 2025-11-01との差分、SDK生成差分 |
| 運用ルール化 | セキュリティ判断基準を決める | Preview、Deprecated、GA、Supportedの扱い |
| 本番反映 | 影響確認後にAPIバージョンを更新 | ロールバック手順も用意する |
現場で特に見落としやすいのは、レスポンスをCSVやBIツールに変換している処理です。たとえば、ruleGroups[].rules[] を展開してルールID単位で一覧化している場合、paranoiaLevel を新しい列として追加できます。ただし、Bot ManagerやDDoS、AIルールでは省略される前提で、空欄を許容してください。
WAFチューニングでの活用例
displayName、status、paranoiaLevel が使えるようになると、WAF運用のレポートを次のように改善できます。
| レポート項目 | 従来の見え方 | 更新後に期待できる見え方 |
|---|---|---|
| ルールセット一覧 | ruleSetType と ruleSetVersion 中心 | 表示名とライフサイクル状態も表示 |
| 非推奨検知 | 手動でドキュメント確認 | status=Deprecated を検知して通知 |
| 検証環境の管理 | Preview利用の判定が属人的 | status=Preview を本番適用前レビューに回す |
| 誤検知調査 | ルールIDとグループ中心 | DRSのparanoia levelも参考にする |
たとえば、誤検知が発生した場合、まずWAFログからルールIDとルールグループを確認します。その後、Managed Rule Sets Listのレスポンスから該当ルールの paranoiaLevel を参照し、除外設定やルールオーバーライドの判断材料にします。
Azure Front Door WAFでは、正当なリクエストがWAFにブロックされる場合、除外リストを設定して特定のリクエスト属性を評価対象から外す運用が可能です。Microsoftのドキュメントでは、Azure portal、PowerShell、Azure CLI、REST API、Bicep、ARMテンプレートで除外設定を構成できると説明されています。(Azure中国ドキュメント)
ただし、除外設定は「便利な回避策」ではなく「最小範囲で適用する安全策」です。paranoiaLevel が高いルールで誤検知が出たからといって、ルールセット全体を無効化するのは避けてください。まずは対象ルール、対象ヘッダー、対象パス、対象パラメーターを絞り込みます。
失敗しやすいポイント
PR名だけで2025-11-01の小変更だと判断する
今回のPR名には「2025 11 01 for reference」とありますが、差分では 2026-04-01 APIバージョンとOpenAPI生成が含まれています。2025-11-01ドキュメントの確認だけで終わらせず、2026-04-01に追加されるモデル差分まで見る必要があります。(GitHub)
Draft PRを正式リリースとして扱う
PRページではDraftとして表示されています。また、自動コメントでは、mainブランチにマージされるAPIはAzure顧客に出荷済みと見なされること、ARMレビューやTypeSpec Validationなどのマージ条件が示されています。PR段階の情報は、実装準備や影響調査には使えますが、本番APIバージョンの切り替え判断には使わないでください。(GitHub)
displayName を安定したIDとして使う
displayName は人間が読みやすい表示名です。ダッシュボードの表示には便利ですが、API連携やデータベースの主キーには向きません。自動化では、引き続き ruleSetType、ruleSetVersion、ruleId を中心に扱うべきです。
status の値を固定しすぎる
現時点で確認できる値は Preview、GA、Deprecated、Supported ですが、クラウドサービスのライフサイクル状態は将来的に増える可能性があります。未知の値で処理を止めるのではなく、レビュー対象として扱う設計にしておくと、API更新に強くなります。
paranoiaLevel がないルールを異常扱いする
paranoiaLevel はDRSルールにのみ適用され、Bot Manager、DDoS、AIルールでは省略される説明になっています。未設定を 0 とみなしたり、必須チェックで落としたりすると、正しいレスポンスを誤って異常扱いしてしまいます。(GitHub)
いま取るべきアクション
まず、Front Door WAFのManaged Rule Sets List APIを使っている箇所を洗い出してください。次に、現行の2025-11-01レスポンスを保存し、追加フィールドを許容できるようにパーサーやダッシュボードを調整します。PRが正式にマージされ、Microsoft Learnや利用環境で 2026-04-01 が確認できるようになったら、検証環境でレスポンス差分を比較します。
本番での判断基準は、次の順番で整理すると安全です。
| 優先度 | やること | 目的 |
|---|---|---|
| 高 | API呼び出し箇所と固定バージョンを棚卸し | 影響範囲を特定する |
| 高 | JSONパーサーを追加フィールドに強くする | 将来のAPI更新で壊れにくくする |
| 中 | status の運用ルールを決める | PreviewやDeprecatedを見逃さない |
| 中 | paranoiaLevel をレポートに追加する | 誤検知調査の材料を増やす |
| 低 | SDKや型定義を更新する | 正式公開後に開発体験を改善する |
今回のAzure REST API documentation updateは、WAFの防御挙動を直接変えるというより、WAFルールセットの状態をより正確に把握するための更新です。対応の第一歩は、APIバージョンを急いで変えることではありません。現行利用箇所を洗い出し、追加フィールドに強い実装へ整え、正式公開後に検証環境で比較することです。
コメント