Azure SDK documentation updateとは？Go armcdn v3 betaの変更点と移行確認ポイント

2026年5月19日にマージされた Azure SDK documentation update: [Refresh sdk-resourcemanager/cdn/armcdn]-generated-from-SDK Generation – Go-6034386 は、Go向けの Azure CDN 管理SDK armcdn を更新するPRです。結論から言うと、これは単なるドキュメント修正ではなく、sdk/resourcemanager/cdn/armcdn を TypeSpec ベースの生成物へ刷新し、armcdn/v3 の beta へ進める変更を含みます。既存の本番コードをすぐ置き換えるより、まず検証ブランチで v2 から v3 への import path、Delivery Rule 周辺の型変更、テスト資産への影響を確認するのが安全です。(GitHub)

特に、Azure CDN や Azure Front Door 関連のリソースを Go の Azure SDK で管理している開発者、CIでSDK更新を自動化しているチーム、管理プレーン操作を内製ツール化している管理者は確認が必要です。SDKを更新しなければ既存コードへ即時影響は限定的ですが、go get -u や依存関係の一括更新で beta 版を取り込む運用では、コンパイルエラーやテスト失敗が起きる可能性があります。

Azure SDK documentation updateで何が変わったのか

今回の更新は、Azure SDK for Go リポジトリの sdk/resourcemanager/cdn/armcdn を対象にしたRefresh PRです。PRは2026年5月19日に main へマージされ、16コミットを含みます。初期コメントでは specification/cdn/resource-manager/Microsoft.Cdn/Cdn/tspconfig.yaml、API Version 6/1/2025、SDK Release Type beta、SpecRepo の CommitSHA aa822c9... が示されていますが、後続コミットでは API Version が 2025-06-01 と表記され、別の生成パイプラインとSpecRepoコミットも反映されています。(GitHub)

実務上は、PR名に含まれる Go-6034386 だけを見て判断しないことが重要です。PRの途中で再生成やテスト修正が入り、最終的な生成元は tsp-location.yaml に記録された Azure/azure-rest-api-specs の specification/cdn/resource-manager/Microsoft.Cdn/Cdn と commit eb08171... を参照する形になっています。再現性を確認する場合は、初期コメントのSHAだけでなく、最終的にマージされた生成物と tsp-location.yaml を確認してください。(GitHub)

項目	内容
対象SDK	Azure SDK for Go の `sdk/resourcemanager/cdn/armcdn`
対象領域	Azure CDN / Azure Front Door 関連の管理プレーン
API Version	主に `2025-06-01` ベース
Release Type	beta
主な変更	TypeSpecベース生成、`armcdn/v3`、型・enum・テスト資産の更新
影響を受けやすいコード	Delivery Rule、Rules、Routes、Origins、AFD Profile、WAF、CDNからAFDへの移行操作を扱うコード

変更点の中心は「armcdn/v3 beta」とTypeSpec生成への移行

PRの概要では、CDN ARM API version 2025-06-01 に対して、新しい TypeSpec ベースの Go コードジェネレーターで sdk/resourcemanager/cdn/armcdn を再生成し、major version を v3 beta に上げる変更だと説明されています。変更内容には、新しい生成ヘッダー、tsp-location.yaml、メタデータ、モジュールパスの .../armcdn/v3 化、依存関係の更新、fake serverやlive testの更新が含まれます。(GitHub)

READMEのインストール例も、従来の armcdn/v2 から armcdn/v3 へ変更されています。つまり、既存コードで v2 を使っている場合、単にSDKを更新するだけではなく、import pathと型定義の差分を確認する必要があります。(GitHub)

// 変更前の例
import armcdn "github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/cdn/armcdn/v2"

// 変更後の例
import armcdn "github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/cdn/armcdn/v3"

ただし、v3 は beta です。本番環境での全面採用は、必要な新機能がある場合や、次期移行に備えた検証目的に限定し、安定運用中のコードでは v2 継続も現実的な選択肢です。

管理者・開発者が特に見るべき影響範囲

今回のAzure SDK documentation updateで注意すべき点は、配信中のCDNやFront Doorがすぐ停止するようなランタイム変更ではなく、Go SDKで管理操作を行うコードの互換性です。Azure Portal、Azure CLI、Terraformなど別経路で管理しているだけなら直接影響は小さい一方、Goで管理ツールや自動化ジョブを作っている場合は影響が出ます。

確認対象	起きやすい影響	実務での対応
import path	`v2` と `v3` の混在、コンパイルエラー	`grep` で利用箇所を洗い出し、検証ブランチで置換
Delivery Rule関連	`Actions` や `Name`、`TypeName` の型変更	ルール作成・更新コードを重点的にテスト
enumの変更	削除・名称変更でビルド失敗	CHANGELOGのBreaking Changesを見て置換
fake server / recording	テスト録画、Acceptヘッダー、応答形状の差分	CIのSDKテスト、録画再生成ルールを確認
AFD移行API	新しい操作を誤って本番に向けるリスク	検証環境で `CanMigrate` 系から確認
Go toolchain	`go.mod` のGoバージョン指定差分	CIイメージ、ローカル開発環境を確認

PRの変更ファイルは .go が大半で、README.md、CHANGELOG.md、go.mod、go.sum、tsp-location.yaml、testdata、fake serverなど広範囲に及びます。生成コードだけでなく、テスト補助コードも更新されているため、ライブラリ利用側のユニットテストやrecordingテストにも影響する可能性があります。(GitHub)

Breaking Changesで確認したい代表的な型変更

CHANGELOGでは 3.0.0-beta.1 のBreaking Changesとして、多数の型変更、enum削除、関数削除が列挙されています。特に影響が大きいのは、Delivery RuleのActionやCondition周辺です。(GitHub)

代表例は以下です。

変更前の考え方	変更後の考え方	影響
`DeliveryRuleActionAutoGeneratedClassification`	`DeliveryRuleActionClassification`	Delivery RuleやRule更新処理の型修正が必要
`DeliveryRuleAction`	`DeliveryRuleActionName`	`Name` に指定するenumを置き換える
`HeaderActionParametersTypeName`	`DeliveryRuleActionParametersType`	`TypeName` の指定を新しいenumへ変更
`RequestMethodMatchConditionParametersMatchValuesItem`	`RequestMethodMatchValue`	HTTPメソッド条件のMatchValuesを修正
`IdentityType`	`CreatedByType`	`SystemData` 周辺を参照するコードに影響

たとえば、レスポンスヘッダーを書き換えるDelivery Ruleを作るコードでは、Actions、Name、TypeName の指定が変わる可能性があります。

// v3向けの書き換えイメージ
Actions: []armcdn.DeliveryRuleActionClassification{
    &armcdn.DeliveryRuleResponseHeaderAction{
        Name: to.Ptr(armcdn.DeliveryRuleActionNameModifyResponseHeader),
        Parameters: &armcdn.HeaderActionParameters{
            HeaderAction: to.Ptr(armcdn.HeaderActionOverwrite),
            HeaderName:   to.Ptr("X-CDN"),
            TypeName:     to.Ptr(armcdn.DeliveryRuleActionParametersTypeDeliveryRuleHeaderActionParameters),
            Value:        to.Ptr("MSFT"),
        },
    },
}

ここで重要なのは、機械的に文字列置換しないことです。Delivery RuleはCDNやFront Doorのルーティング、キャッシュ、ヘッダー制御、リダイレクト、URL rewriteに関わるため、コンパイルが通っても挙動確認が必要です。特に本番のRules Engineを操作する管理ツールでは、検証用プロファイルで作成・更新・削除まで確認してください。

新しく使えるようになる機能

3.0.0-beta.1 のFeatures Addedには、TLS 1.3関連、cipher suite設定、origin authentication、CDNからAzure Front Doorへの移行操作などが含まれます。たとえば AfdMinimumTLSVersionTLS13、AfdCipherSuiteSetType、AfdCustomizedCipherSuiteForTls12、AfdCustomizedCipherSuiteForTls13、OriginAuthenticationType、ProfilesClient.BeginCdnCanMigrateToAfd、ProfilesClient.BeginCdnMigrateToAfd、ProfilesClient.BeginMigrationAbort などが追加されています。(GitHub)

実務で注目すべきなのは、以下の3つです。

TLSや暗号スイート設定をコード管理しやすくなる

Azure Front Door関連のHTTPS設定で、TLS 1.3やcipher suiteの指定をSDKから扱う場面が増える可能性があります。セキュリティ基準に応じて、ポータル操作ではなくコードレビュー可能な形で設定を管理したいチームにはメリットがあります。

ただし、暗号スイートはセキュリティと互換性の両方に関わります。古いクライアント、社内プロキシ、組み込み端末からのアクセスがある場合は、設定変更前にアクセスログや利用端末の棚卸しを行ってください。

CDNからAzure Front Doorへの移行操作がSDKから扱える

BeginCdnCanMigrateToAfd や BeginCdnMigrateToAfd は、CDNからAzure Front Doorへの移行を自動化する用途で注目されます。移行可否チェックを先に実行し、結果を人間がレビューしてから移行を進めるワークフローに向いています。

本番では、いきなり移行操作を実行するのではなく、次の順序で進めるのが安全です。

手順	実施内容	失敗しやすいポイント
事前調査	対象CDN profile、endpoint、custom domain、WAF設定を一覧化	使われていないように見えるendpointが実は参照されている
可否確認	`CanMigrate` 系の操作を検証環境で確認	権限不足、SKUや設定差分で失敗
差分確認	ルール、証明書、origin、route、WAFの移行後状態を比較	custom domainと証明書の確認漏れ
本番計画	DNS TTL、切り戻し、監視、メンテナンス時間を決める	SDK操作だけで移行計画が完結すると誤解する
実行後確認	応答ヘッダー、キャッシュ、リダイレクト、WAFログを確認	200応答だけ見てキャッシュ挙動を見落とす

fake serverやテスト資産の更新によりCIの見直しが必要

PRではfake server、live test、recording関連の更新も行われています。特に、テストでは v3 へ移すだけでなく、既存録画資産やヘッダーの差分により失敗するケースがあります。PR内でもlive testのimportやAcceptヘッダー方針、playback cleanupに関する修正が入っています。(GitHub)

SDK利用側のCIでAzure SDKのfakeやrecordingに依存している場合は、以下を確認してください。

grep -R "sdk/resourcemanager/cdn/armcdn" -n .
go list -m all | grep "armcdn"
go test ./...

v3 を検証する場合は、依存更新を小さなPRに分け、CDN操作コードとテスト録画の変更を同時に混ぜすぎないことが大切です。コンパイル修正、単体テスト修正、実Azure環境での検証を分けると、問題の切り分けがしやすくなります。

go.modとCI環境で確認すべきこと

マージ後の go.mod では、module path が github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/cdn/armcdn/v3 になっており、azcore v1.21.1、azidentity v1.13.1、sdk/resourcemanager/internal/v3 v3.2.0 などの依存関係が示されています。また、Goバージョン指定も確認対象です。(GitHub)

検証ブランチでは、次のように依存を明示して作業します。

go get github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/cdn/armcdn/[email protected]
go mod tidy
go test ./...

ただし、beta版の公開状況やタグの反映タイミングによっては、取得できるバージョンが変わることがあります。CIでは go get -u ./... のような一括更新に任せず、go.mod と go.sum の差分をレビューしてください。

特に企業環境では、以下の点を確認しておくとトラブルを避けられます。

確認項目	判断基準
Goバージョン	CIイメージ、開発者PC、コンテナビルド環境で同じ結果になるか
依存ライブラリ	`azcore`、`azidentity`、`resourcemanager/internal` の更新が他SDKに影響しないか
module path	`v2` と `v3` が混在して意図しない二重実装になっていないか
private proxy	社内Go proxyや依存キャッシュにbeta版が取り込めるか
リリース手順	問題発生時に `v2` へ戻せるブランチ・タグ運用があるか

v2からv3へ移行するべきかの判断基準

今回の更新は、すべてのチームがすぐ採用すべきものではありません。判断は「新機能の必要性」と「betaを受け入れられる運用体制」で分けると明確です。

判断	向いているケース	注意点
`v2` を継続	本番運用が安定しており、新しいAFD/CDN機能が不要	セキュリティ・機能要件が変わった時に再評価
`v3 beta` を検証	AFD移行、TLS 1.3、origin authenticationなどをコード管理したい	betaのため破壊的変更や再生成差分に備える
採用を延期	厳格な変更凍結期間、SDK更新の影響調査が未完了	依存更新の自動化で誤取り込みしないよう固定
段階導入	社内ツールや検証環境から先に試す	本番profileを操作しない権限設計が必要

実務では、まず v2 のまま現行コードを固定し、別ブランチで v3 へのコンパイル確認を行うのがおすすめです。v2 と v3 はGoのmajor version suffixにより別import pathとして扱えるため、段階的な比較検証がしやすい構成です。

移行時に失敗しやすいポイント

依存更新だけで移行したつもりになる

go get が成功しても、Delivery RuleやWAF関連のコードが正しく動くとは限りません。型名やenumが変わるとコンパイルエラーで気づけますが、リクエスト形状や既定値の違いはテストしないと見落とします。

自動生成コードの差分を人間が読み飛ばす

生成コードは量が多く、PRでも多くのファイルが更新されています。すべてを読む必要はありませんが、自社コードが使っているclient、model、options、responseだけは差分を追うべきです。たとえば profiles_client.go、rules_client.go、routes_client.go、origins_client.go、securitypolicies_client.go など、利用箇所に絞って確認します。

テスト録画やfakeの失敗をSDKの不具合と決めつける

今回のPRではfake serverやrecording behaviorも更新されています。既存のテスト資産が古いリクエスト形状を前提にしている場合、SDK本体ではなくテスト側の更新が必要です。Acceptヘッダーやpolling、Retry-Afterの扱いなど、管理プレーンSDKではテストが実通信と録画再生で微妙に変わることがあります。

AFD移行APIを本番操作として軽く扱う

CDNからAzure Front Doorへの移行は、SDKで呼べるようになっても、運用上はDNS、証明書、WAF、キャッシュ、監視、切り戻しを含む変更です。SDK更新の検証と本番移行計画は分けて管理してください。

管理者・開発者向けの確認チェックリスト

公開・更新情報を見た後に、まず次の順で確認すると効率的です。

チェック	コマンド・確認方法	完了条件
利用有無の確認	`grep -R "armcdn" -n .`	対象リポジトリと担当者が分かる
現行バージョン確認	`go list -m all \| grep armcdn`	`v2` 利用中か、未利用かを把握
beta取り込み防止	`go.mod`、Renovate、Dependabot設定を確認	自動PRで不用意にv3へ上がらない
検証ブランチ作成	`armcdn/v3` へimportを変更	コンパイルエラー一覧を取得
型変更の修正	Delivery Rule、Condition、SystemDataを中心に確認	`go test ./...` が通る
実環境検証	検証用CDN/AFD profileで作成・更新・削除	期待する設定差分のみ発生
リリース判断	beta採用可否を記録	本番適用・延期・継続検証を決定

今回の更新で取るべき次の行動

このAzure SDK documentation updateは、Go向けAzure CDN管理SDKの将来版を検証するうえで重要な更新です。一方で、Release Typeは beta であり、Breaking Changesも多いため、既存の本番コードを急いで armcdn/v3 に置き換える必要はありません。

まずは、自社コードが github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/cdn/armcdn/v2 を使っているかを確認してください。使っている場合は、v2 を固定したまま、別ブランチで v3.0.0-beta.1 のコンパイル検証を行います。Delivery Rule、WAF、Routes、Origins、AFD Profile、CDNからAFDへの移行操作を扱っているコードは優先的にテストし、CIや録画テストの更新も同時に確認します。

新機能が必要なチームは、検証環境で CanMigrate 系やTLS関連設定から試すのが現実的です。安定運用を優先するチームは、今すぐ移行せず、Azure SDK for Goの正式リリース情報とCHANGELOGを追いながら、次回のSDK更新サイクルで再評価するのが安全です。

この記事を書いた人

佐藤健司

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