Azure SDK の「Azure SDK documentation update: [AutoPR Azure.ResourceManager.ComputeSchedule]-generated-from-SDK Generation – .NET-6207979」は、.NET 向けの管理ライブラリ Azure.ResourceManager.ComputeSchedule を使っている開発者が確認すべき更新です。結論から言うと、最初に見るべきポイントは、API Version が 2026-04-15-preview に進んだこと、VM 関連モデルが再生成されていること、baseProfile や resourceOverrides 周辺の型・命名変更をビルドとリクエスト payload の両面で確認することです。ComputeSchedule は VM の Start、Deallocate、Hibernate などの操作をスケジュールまたは即時実行する用途で使われるため、該当する運用コードや自動化処理がある場合は、早めに差分確認を行いましょう。(GitHub)
Azure SDK documentation updateの要点
今回の更新は、Azure.ResourceManager.ComputeSchedule の SDK 生成に関する AutoPR です。PR #58666 は main ブランチへマージされ、PR 本文では specification/computeschedule/ComputeSchedule.Management/tspconfig.yaml、API Version 2026-04-15-preview、SDK Release Type beta、生成元 CommitSHA f12c7de832ff09ca5a6a1fbcd5c9b49b09c10903 が示されています。CHANGELOG では 1.2.0-beta.3 の Release History として、ComputeSchedule RP の api-version 更新と、baseProfile、resourceOverrides の型変更が記載されています。(GitHub)
| 確認項目 | 内容 | 実務での見方 |
|---|---|---|
| 対象SDK | Azure.ResourceManager.ComputeSchedule | .NET で ComputeSchedule の管理 API を使うプロジェクトが対象 |
| 更新種別 | SDK 生成による beta 更新 | GA 前のため、型名・プロパティ名が今後変わる可能性を見込む |
| API Version | 2026-04-15-preview | 既存テストが 2026-03-01-preview などを前提にしていないか確認 |
| 設定ファイル | specification/computeschedule/ComputeSchedule.Management/tspconfig.yaml | SDK 生成元の TypeSpec 設定として確認 |
| 主な変更 | VM 関連モデル、プロパティ名、プロパティ型 | コンパイルエラーだけでなく、送信される JSON の差分も見る |
| リリース履歴上の版 | 1.2.0-beta.3 | NuGet や社内フィードで実際に取得できる版は別途確認 |
何が変わったのか
API Versionが2026-04-15-previewへ更新された
大きな変更点は、ComputeSchedule の既定 API Version が 2026-04-15-preview に進んだことです。PR のレビュー概要では、生成クライアントと metadata の既定 API Version が 2026-04-15-preview に更新され、VM 関連のモデルが広く追加されたことが説明されています。metadata 側でも Microsoft.ComputeSchedule の API Version は 2026-04-15-preview として記録されています。(GitHub)
実務上は、SDK のバージョンを上げるだけで終わらせず、次の点を確認してください。
- 結合テストで期待している
api-versionが変わるか - Azure 側に送信されるリクエスト payload が既存の検証ルールと合うか
- 既存のログ、監査、アラートが旧 API Version を前提にしていないか
- プレビュー API を本番運用に使う場合、ロールバック手順を用意しているか
特に、API Version の変更は「C# のコンパイルが通るか」だけでは判断できません。REST API 側の受け取り方、必須項目、既定値、バリデーションが変わる可能性があるため、実際の VM 操作を検証環境で流すことが重要です。
baseProfileとresourceOverridesの扱いが変わる
CHANGELOG では、baseProfile が virtualMachineBaseProfile に、resourceOverrides が virtualMachineOverrides に変更され、検証のために強く型付けされたモデルへ更新されたと説明されています。関連する Azure REST API specs 側の PR でも、virtualMachineBaseProfile と virtualMachineOverrides について、従来のメッセージ形式を模倣するための flatten や、HardwareProfile などのモデル追加が触れられています。(GitHub)
この変更で注意したいのは、単純な文字列置換では不十分な可能性があることです。たとえば、従来は匿名オブジェクトや BinaryData、独自 DTO で payload を組み立てていた場合、新しい SDK モデルに合わせて初期化方法を見直す必要があります。
| 旧来の確認ポイント | 新しい確認ポイント |
|---|---|
baseProfile を直接組み立てていないか | virtualMachineBaseProfile 相当のモデルで表現できているか |
resourceOverrides に任意の JSON を渡していないか | virtualMachineOverrides の型に合う値を渡しているか |
| payload 比較をしていないか | SDK 更新前後で送信 JSON を比較する |
| 既存テストがプロパティ名だけを見ていないか | 型、ネスト、必須項目、null の扱いまで見る |
プロパティ名と型変更で確認すべきコード
今回の PR では、ComputeSchedule SDK の命名を Azure Compute SDK の慣例に寄せるため、TypeSpec の @clientName や @@alternateType による調整が説明されています。PR コメントには、C# プロパティ名の変更と、string から ResourceIdentifier や Uri への型変更が具体的に列挙されています。(GitHub)
C#プロパティ名の主な変更
以下のプロパティをコード内で使っている場合は、コンパイルエラーや IntelliSense の候補から変更後の名前へ置き換えます。
| モデル | 旧C#プロパティ | 新C#プロパティ |
|---|---|---|
AdditionalCapabilities | UltraSSDEnabled | UltraSsdEnabled |
LinuxConfiguration | ProvisionVMAgent | ProvisionVmAgent |
WindowsConfiguration | ProvisionVMAgent | ProvisionVmAgent |
UefiSettings | SecureBootEnabled | IsSecureBootEnabled |
UefiSettings | VTpmEnabled | IsVirtualTpmEnabled |
LinuxConfiguration | DisablePasswordAuthentication | IsPasswordAuthenticationDisabled |
LinuxConfiguration | EnableVMAgentPlatformUpdates | IsVmAgentPlatformUpdatesEnabled |
WindowsConfiguration | EnableAutomaticUpdates | IsAutomaticUpdatesEnabled |
StorageProfile | OsDisk | OSDisk |
OSDisk | OsType | OSType |
ScheduledEventsProfile | OsImageNotificationProfile | OSImageNotificationProfile |
検索するときは、古いプロパティ名だけでなく、VM と Vm、SSD と Ssd、OS と Os のような略語の揺れも見ると見落としを減らせます。
Get-ChildItem -Recurse -Filter *.cs |
Select-String -Pattern 'UltraSSDEnabled|ProvisionVMAgent|VTpmEnabled|SecureBootEnabled|OsDisk|OsType|OsImageNotificationProfile'stringからResourceIdentifierやUriへ変わる箇所
id や URL 系プロパティが string のままだと思っているコードは、型変更で修正が必要になる可能性があります。
| モデル | プロパティ | 旧型 | 新型 |
|---|---|---|---|
ApiEntityReference | id | string | Azure.Core.ResourceIdentifier |
SubResource | id | string | Azure.Core.ResourceIdentifier |
VirtualHardDisk | uri | string | System.Uri |
BootDiagnostics | storageUri | string | System.Uri |
KeyVaultSecretReference | secretUrl | string | System.Uri |
KeyVaultKeyReference | keyUrl | string | System.Uri |
WinRMListener | certificateUrl | string | System.Uri |
VaultCertificate | certificateUrl | string | System.Uri |
修正の考え方はシンプルです。ARM リソース ID は ResourceIdentifier、URL は Uri として扱います。ただし、値が null になり得る箇所や、相対 URL を渡していた箇所は、単純に new Uri(value) へ置き換えると実行時例外につながることがあります。
using Azure.Core;
ResourceIdentifier resourceId = new ResourceIdentifier(vmResourceId);
Uri storageUriValue = new Uri(storageUri, UriKind.Absolute);この変更は、コードの安全性を高める一方で、既存のテストデータやモックが文字列前提だと失敗しやすいポイントです。特に単体テストで "id": "/subscriptions/..." のような文字列だけを比較している場合は、SDK モデルのシリアライズ結果まで確認してください。
影響を受けやすい開発者とシステム
| 対象 | 影響度 | 対応方針 |
|---|---|---|
Azure.ResourceManager.ComputeSchedule の beta 版を使っている | 高 | 旧プロパティ名と型変更をすぐ確認 |
| VM の即時実行、スケジュール実行、作成系処理を自動化している | 高 | 検証環境で実操作を流し、payload と結果を比較 |
baseProfile、resourceOverrides を直接組み立てている | 高 | 新しい強く型付けされたモデルへ移行できるか確認 |
安定版 1.1.0 のみを本番利用している | 中 | すぐ移行しなくてもよいが、GA 前の変更予定を追う |
| REST API や IaC のみを使っている | 低〜中 | SDK 由来の変更ではないが、API Version と payload 名は確認 |
| 社内ライブラリで ComputeSchedule の DTO をラップしている | 高 | ラッパー側の型定義、変換処理、テストデータを更新 |
PR のレビューでは ApiCompat が 1.1.0 に対して実行され、netstandard2.0、net8.0、net10.0 でエラー・警告なし、破壊的変更は検出されなかったとされています。ただし、これは「すべてのアプリケーションコードに修正が不要」という意味ではありません。beta 版や preview API を使っているコード、モデル初期化を細かく書いているコードでは、コンパイルや実行時の差分確認が必要です。(GitHub)
移行前に確認する手順
使用中のパッケージバージョンを確認する
まず、プロジェクトがどの版の Azure.ResourceManager.ComputeSchedule を参照しているか確認します。
dotnet list package --include-transitiveCentral Package Management を使っている場合は、.csproj だけでなく Directory.Packages.props も確認します。
<PackageVersion Include="Azure.ResourceManager.ComputeSchedule" Version="..." />注意点として、GitHub の PR や CHANGELOG の更新と、NuGet や社内フィードで取得できるパッケージの反映タイミングは一致しないことがあります。NuGet のパッケージページにはバージョン一覧とプレリリースの表示があるため、実際にインストールできるバージョンを確認してから作業してください。([NuGet][3])
旧プロパティ名を検索する
次に、古い C# プロパティ名を検索します。特に ProvisionVMAgent、UltraSSDEnabled、VTpmEnabled、OsDisk のような略語を含む名前は、レビュー時に見落としやすい箇所です。
grep -R "UltraSSDEnabled\|ProvisionVMAgent\|VTpmEnabled\|OsDisk\|OsType\|baseProfile\|resourceOverrides" .検索でヒットした箇所は、単に名前を置き換えるだけでなく、周辺の型も確認してください。string から Uri に変わった箇所では、テストデータの値が絶対 URI になっているかも確認します。
送信payloadを比較する
SDK 更新で最も見落としやすいのは、C# コード上の変更ではなく、実際に Azure に送信される JSON の差分です。次のような操作を検証環境で実行し、更新前後の payload を比較します。
| 検証対象 | 確認内容 |
|---|---|
| VM の Start、Deallocate、Hibernate | 既存操作が同じ対象 VM に対して成功するか |
| Submit 系操作 | 予約日時、タイムゾーン、対象リソース ID が正しく送られるか |
| Execute 系操作 | 即時実行時のレスポンスとステータス取得が変わらないか |
| VM 作成・Flex 作成系 | virtualMachineBaseProfile、virtualMachineOverrides の形が想定通りか |
| エラー取得・キャンセル | Operation ID やエラー詳細の扱いが変わっていないか |
ログを比較するときは、api-version、プロパティ名、ネスト構造、null の有無を見ます。特に preview API では、SDK 側のモデルが正しくても、サービス側のバリデーションで差分が出ることがあります。
本番適用の判断基準
今回の更新は beta 扱いです。PR のコメントでは、beta を早く出すために一部の重複名を維持し、GA 前に Azure.ResourceManager.Compute への依存や型名・パラメーター名の調整を検討すべきという趣旨のコメントも残されています。つまり、今すぐ全環境へ広げるより、必要なチームが検証目的で取り込むのが現実的です。(GitHub)
採用判断は次のように分けると安全です。
| 状況 | 判断 |
|---|---|
2026-04-15-preview の新機能や検証が必要 | 検証環境で導入し、バージョンを固定する |
| beta2 以前の ComputeSchedule を使っている | コンパイルと payload の差分確認をしてから更新 |
| 本番で安定稼働しており、新 preview API が不要 | 急いで更新せず、GA または次の安定版を待つ選択も妥当 |
| パートナー連携や外部システム連携がある | 連携先と payload 名、API Version、ロールバック手順を共有する |
| 社内共通 SDK ラッパーを提供している | ラッパー側で新旧プロパティを吸収できるか検討する |
よくある失敗と回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| PR の「No breaking changes」を見て無検証で更新する | アプリ側の beta 利用コードでコンパイルエラーや実行時差分が出る | ApiCompat の結果とアプリ影響を分けて判断する |
string から Uri への変更を機械的に置換する | 相対 URL や空文字で例外が出る | UriKind.Absolute と null チェックを入れる |
ResourceIdentifier に任意文字列を渡す | ARM ID として不正な値が混入する | /subscriptions/... 形式の実データでテストする |
| C# プロパティ名と JSON フィールド名を混同する | REST payload を誤って変更する | SDK のシリアライズ結果を確認してから修正する |
| NuGet 反映前にバージョンを固定する | CI で restore に失敗する | NuGet または社内フィードで取得可能な版を確認する |
| preview API を本番だけで試す | サービス側変更時に影響範囲が読めない | 検証環境、ステージング、本番の順に進める |
次にやるべきこと
まず、コードベース内で Azure.ResourceManager.ComputeSchedule の利用箇所を洗い出します。次に、旧プロパティ名、baseProfile、resourceOverrides、URL 系文字列、ARM リソース ID 文字列を検索し、ビルドとテストを通します。最後に、実際の VM 操作で送信 payload とレスポンスを比較してください。
今回の Azure SDK documentation update は、単なるドキュメント追記ではなく、ComputeSchedule SDK の生成面、API Version、モデル型に関わる更新です。beta を取り込む価値があるチームほど、早い段階で検証しておくと、GA 前の命名変更や型変更にも落ち着いて対応できます。
[3]: https://www.nuget.org/packages/Azure.ResourceManager.ComputeSchedule/ “
NuGet Gallery
| Azure.ResourceManager.ComputeSchedule 1.1.0
“
コメント