Azure REST APIを使ってAzure NetworkのDDoS protection planを管理している場合、今回まず確認すべき点はシンプルです。2026年5月5日にマージされた仕様更新では、Networkの2025-07-01 stable specにあるvirtualNetwork.jsonから、DDoS protection planのtags定義が一部削除されました。これはDDoS保護プランのタグ機能そのものが廃止されたという意味ではなく、主にREST API仕様・生成SDK・スキーマ検証に影響する修正です。(GitHub)
特に対応が必要なのは、Azure REST API仕様からSDKを生成しているチーム、OpenAPI/Swaggerを使ってリクエストやレスポンスを検証しているチーム、DDoS protection planのモデルに対してtagsの位置を厳密に扱っているチームです。通常のAzure Portal操作や、既存のタグ運用だけを見ている場合は影響が小さい可能性がありますが、CIや型定義の差分で失敗するケースは確認しておくべきです。
Azure REST API documentation updateで何が変わったのか
今回の変更は、Azure REST API specsリポジトリのPR「[Network] Remove unsupported tags field from DDoS protection plan properties」で行われました。対象ファイルはNetworkのstable/2025-07-01/virtualNetwork.jsonで、差分としては7行の削除です。削除されたのは、DDoS protection planモデル内に直接定義されていた次のようなtagsフィールドです。(GitHub)
"tags": {
"type": "object",
"description": "Resource tags.",
"additionalProperties": {
"type": "string"
}
}この変更を一言で言えば、DDoS protection planのREST APIスキーマにあった、サポートされない、または重複していたtags定義を削除した修正です。
重要なのは、変更対象がDDoS防御機能そのものではなく、REST API仕様ファイル内のモデル定義だという点です。DDoS保護プランの有効・無効、仮想ネットワークとの関連付け、DDoS検知や防御ロジックが変わる更新ではありません。
「tagsが削除された」だけでタグ機能廃止と判断しない
この更新で最も誤解しやすいのは、「DDoS protection planでタグが使えなくなった」と受け取ってしまうことです。
実際には、削除されたのはDdosProtectionPlan定義のローカルなproperties一覧にあったtags定義です。一方で、同じ仕様内のDdosProtectionPlanは共通リソース表現であるTrackedResourceWithOptionalLocationを参照しており、その共通リソース表現側にはid、name、type、location、tagsが含まれています。(GitHub)
つまり、実務上は次のように考えると分かりやすいです。
| 観点 | 今回の変更で確認すべきこと |
|---|---|
| DDoS protection planのタグ運用 | すぐに「廃止」と判断しない。トップレベルのtagsとして扱われるか確認する |
| REST API仕様 | DdosProtectionPlanモデルに直接書かれていたtags定義が削除された |
| 生成SDK | モデルの型やプロパティ生成結果が変わる可能性がある |
| スキーマ検証 | 古いOpenAPI定義に依存していると差分検出やバリデーションで失敗する可能性がある |
| IaC・運用スクリプト | properties.tagsのような誤った位置でタグを扱っていないか確認する |
現時点のMicrosoft Learn上のDDoS Protection Plans REST APIでは、Update Tags操作があり、PATCHリクエストの本文でトップレベルにtagsを送る例が掲載されています。また、Create Or Updateのリクエスト本文にもtagsがリソースタグとして示されています。(Microsoft Learn)
そのため、今回の変更は「タグを一切使わないようにする」対応ではなく、タグをどのモデル、どの階層、どの生成コードで扱っているかを確認する対応だと捉えるのが適切です。
影響を受けやすいケース
今回のAzure REST API documentation updateは、すべてのAzure利用者に同じ大きさの影響がある変更ではありません。影響が出やすいのは、Azure REST APIの仕様ファイルを開発プロセスに組み込んでいるケースです。
| 利用形態 | 影響度 | 確認ポイント |
|---|---|---|
| Azure PortalでDDoS保護プランを管理している | 低 | 通常は直接影響しにくい。タグ表示や更新が通常通りできるか確認する程度 |
| REST APIを直接呼び出している | 中 | リクエスト本文でtagsをトップレベルに置いているか確認する |
| OpenAPI/Swaggerからクライアントを生成している | 高 | 再生成後にモデル差分、コンパイルエラー、シリアライズ結果を確認する |
| Go SDKなど生成SDKに依存している | 高 | PRではGo SDKの破壊的変更ラベルが付いているため、型変更を重点確認する |
| 独自のJSONスキーマ検証をCIに組み込んでいる | 高 | 古いvirtualNetwork.json前提の検証ルールを更新する |
| タグ管理を監査・棚卸ししている | 中 | properties.tagsではなく、リソース直下のtagsを参照しているか確認する |
PR上では、APIViewがGoとJavaのAPIレベル変更を検出しており、Go SDKについてはBreakingChange-Go-Sdkラベルも付いています。SDKを直接使っている場合、REST APIの挙動が大きく変わっていなくても、生成された型やメソッドの差分でビルドが失敗する可能性があります。(GitHub)
実務で確認すべき変更点
APIリクエストでtagsの位置を確認する
DDoS protection planのタグは、リソースのトップレベルに置くのが基本です。次のようにproperties配下へ入れているコードがある場合は、誤った実装として見直す必要があります。
{
"location": "japaneast",
"properties": {
"tags": {
"env": "prod",
"owner": "network-team"
}
}
}確認すべき形は、次のようなトップレベルのtagsです。
{
"location": "japaneast",
"tags": {
"env": "prod",
"owner": "network-team"
},
"properties": {}
}ただし、実際に送る本文は利用しているAPIバージョン、SDK、操作種別によって変わることがあります。Create Or Update、Update Tags、Get、Listでそれぞれ期待するレスポンス形が一致するかを確認してください。
生成SDKのモデル差分を確認する
OpenAPI仕様からSDKを生成している場合、今回のような数行のスキーマ修正でも影響が出ます。
特に確認すべきなのは、次のような差分です。
| 確認対象 | 見るべきポイント |
|---|---|
DdosProtectionPlanモデル | Tagsまたはtags相当のプロパティがどこに生成されるか |
DdosProtectionPlanPropertiesFormatモデル | タグが誤ってproperties側に生成されていないか |
| シリアライズ結果 | JSON出力時にtagsがリソース直下に出るか |
| デシリアライズ結果 | GET/Listのレスポンスでタグを読み取れるか |
| コンパイル結果 | 削除されたプロパティ参照でビルドが落ちないか |
GoやJavaのように型の差分が明確に出る言語では、モデルのプロパティ削除や移動がコンパイルエラーとして表面化しやすくなります。逆にJavaScriptやPythonでは実行時まで気づきにくい場合があるため、APIレスポンスを使ったテストを追加しておくと安全です。
古いスキーマを前提にしたバリデーションを更新する
CIでAzure REST API仕様を取り込み、リクエストやレスポンスを検証している場合は、stable/2025-07-01/virtualNetwork.jsonの更新を反映する必要があります。
確認すべきパターンは次の通りです。
DdosProtectionPlan.tags
DdosProtectionPlanPropertiesFormat.tags
properties.tags
ddosProtectionPlan.properties.tags特にDdosProtectionPlanPropertiesFormat.tagsやproperties.tagsを前提にしたルールがある場合は注意が必要です。今回の変更を「タグが不要になった」と解釈して検証から完全に外すのではなく、リソース直下のタグとして扱うか、利用中のAPI仕様に合わせて検証対象を整理することが重要です。
移行・設定確認の進め方
今回の変更に対しては、慌てて全システムを修正するより、利用状況を切り分けて確認する方が安全です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | 利用中のAPIバージョンを確認する | 2025-07-01のNetwork specを取り込んでいるか |
| 2 | DDoS protection planの操作箇所を洗い出す | Create、Update、Update Tags、Get、Listを対象にする |
| 3 | tagsの参照位置を確認する | リソース直下か、誤ってproperties配下か |
| 4 | SDKを再生成または更新する | 型差分とコンパイルエラーを確認する |
| 5 | タグ更新の実APIテストを行う | PATCHまたはPUT後にGET/Listでタグを確認する |
| 6 | CIのスキーマ検証を更新する | 古いvirtualNetwork.json前提のルールを削除・修正する |
| 7 | 運用ドキュメントを直す | 「DDoS保護プランはタグ不可」と誤記しない |
開発チームでは、まずコード検索でDDoS protection planとタグの参照箇所を確認すると効率的です。
grep -R "DdosProtectionPlan" .
grep -R "ddosProtectionPlans" .
grep -R "properties.tags" .
grep -R "DdosProtectionPlanProperties" .生成SDKを使っている場合は、旧版と新版のモデル差分をレビューします。レビューでは「プロパティが消えたか」だけでなく、「同じ意味のプロパティが共通リソース側に残っているか」まで確認してください。
APIレスポンスで見るべきポイント
DDoS protection planのGETまたはListレスポンスを確認するときは、次のような構造を意識します。
{
"id": "/subscriptions/xxxx/resourceGroups/rg-network/providers/Microsoft.Network/ddosProtectionPlans/plan-prod",
"name": "plan-prod",
"type": "Microsoft.Network/ddosProtectionPlans",
"location": "japaneast",
"tags": {
"env": "prod",
"owner": "network-team"
},
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "..."
},
"etag": "..."
}見るべきポイントは、tagsがpropertiesの中ではなく、locationやpropertiesと同じ階層にあることです。
タグ監査やコスト配賦、リソース所有者管理を行っている場合、取得処理で次のような参照をしていないか確認してください。
// 避けたい例
const tags = plan.properties.tags;
// 確認したい例
const tags = plan.tags;この違いは小さく見えますが、監査ツールでは大きな問題になります。plan.properties.tagsを見に行く実装では、タグが存在するリソースでも「タグなし」と誤判定する可能性があります。
よくある失敗パターン
「tags削除」を見てタグ運用を止めてしまう
今回削除されたのは、仕様上の特定位置にあったtags定義です。DDoS protection planのタグ操作全体を止める判断は早計です。Microsoft Learn上でもDDoS protection planのUpdate Tags操作は案内されています。(Microsoft Learn)
対応としては、タグが使えるかどうかではなく、どのAPIバージョン、どの操作、どのJSON階層でタグを扱うかを確認します。
SDKの破壊的変更を軽視する
REST APIの実体が大きく変わらない場合でも、生成SDKでは型の差分が破壊的変更として扱われることがあります。今回のPRでもGo SDKに破壊的変更ラベルが付いているため、GoでAzure Network SDKを利用しているチームは特に注意が必要です。(GitHub)
確認せずにSDKだけ更新すると、ビルドエラーやJSON変換の差分がリリース直前に見つかる可能性があります。
2025-05-01の公開ドキュメントだけで判断する
今回のPRはNetworkの2025-07-01 stable specに対する変更です。一方、Microsoft Learn上で確認できるDDoS Protection Plansのページは、記事執筆時点では2025-05-01のビューが中心です。既存ドキュメントでタグが見えるから問題なし、またはPRで削除されたからタグ不可、と片方だけで判断しない方が安全です。(Microsoft Learn)
APIバージョンをまたいで比較する場合は、使用しているSDK、REST APIのapi-version、CIで参照しているOpenAPIファイルをそろえて確認してください。
具体的な対応方針
今回のAzure REST API仕様更新に対して、実務では次の方針で進めるのがおすすめです。
| 状況 | 対応 |
|---|---|
| DDoS protection planをREST APIで直接操作している | リクエスト本文とレスポンス処理でtagsがトップレベル扱いか確認する |
| OpenAPIからSDKを生成している | virtualNetwork.json更新後に再生成し、モデル差分をレビューする |
| Go SDKを利用している | 破壊的変更の可能性を前提に、コンパイルと単体テストを先に実行する |
| タグ監査ツールを運用している | properties.tags参照がないか検索し、tags直下参照に統一する |
| ドキュメントを整備している | 「タグ削除」ではなく「サポートされないtags定義の削除」と表現する |
| 影響が不明な場合 | GET/List/Update Tagsの最小テストを行い、実レスポンスで確認する |
特に社内ドキュメントでは、「DDoS protection plan propertiesからtagsが削除」とだけ書くと誤解を招きます。読み手がREST APIのJSONペイロードにおけるpropertiesと、OpenAPIスキーマ上のpropertiesを混同しやすいためです。
おすすめの表現は次のようなものです。
Network 2025-07-01のREST API仕様で、DdosProtectionPlanモデルに直接定義されていた未サポートのtagsフィールドが削除された。タグ運用を廃止する変更ではないため、リソース直下のtagsおよびUpdate Tags操作の扱いを確認する。まず実行すべきチェックリスト
最後に、今回の更新を受けてすぐ確認すべき項目を整理します。
| チェック項目 | 完了の目安 |
|---|---|
利用中のapi-versionを確認した | Network 2025-07-01 specを使うかどうか分かっている |
| DDoS protection plan関連コードを検索した | Create、Update、Get、List、Update Tagsの処理が洗い出せている |
properties.tags参照がないか確認した | タグはリソース直下のtagsとして扱っている |
| SDK更新時のモデル差分を確認した | 生成コードの型変更をレビュー済み |
| CIのスキーマ検証を更新した | 古いtags定義に依存した検証が残っていない |
| タグ更新テストを実施した | 更新後のGET/Listでタグが取得できる |
| 社内ドキュメントの表現を修正した | 「タグ廃止」と誤解されない説明になっている |
今回の変更は、DDoS protection planの運用を大きく変えるものではありません。影響の中心は、Azure REST API仕様を使った型生成、スキーマ検証、タグ参照位置の扱いです。まずは自社のコードとCIでDdosProtectionPlanおよびtagsを検索し、タグがリソース直下で扱われているか、生成SDKの差分でビルドやテストが失敗しないかを確認しましょう。
コメント