Azure REST API documentation update: Adds new version 2026-05-01 は、Azure REST API全体の一括変更ではなく、主に Microsoft.DataReplication/DataReplication、つまり Recovery Services Data Replication 系の管理APIに新しい 2026-05-01 バージョンを追加する更新です。結論から言うと、Microsoft.DataReplication を REST API、ARM/Bicep、Terraform相当の自動化、または生成SDKで利用しているチームは確認対象です。既存の api-version=2024-09-01 などを使い続ける環境では即時変更は不要ですが、2026-05-01 へ移行する場合は、APIバージョン指定、生成SDKの差分、列挙値の扱いを必ずテストしてください。PR上では stable/2026-05-01 の仕様ファイルとサンプルが追加され、readme.md の既定タグも package-2026-05-01 に更新されています。(GitHub)
Azure REST API 2026-05-01更新で何が変わったのか
今回の更新は、Azure REST API仕様リポジトリの PR #42847「Adds new version 2026-05-01」として確認できます。PRは Azure/azure-rest-api-specs の main へマージするためのもので、対象パスは specification/recoveryservicesdatareplication/resource-manager/Microsoft.DataReplication/DataReplication 配下です。ファイル差分には .json、.md、.tsp、.yaml が含まれ、examples/2026-05-01 と stable/2026-05-01 が追加されています。(GitHub)
| 確認項目 | 内容 | 実務で見るべきポイント |
|---|---|---|
| 対象サービス | Microsoft.DataReplication/DataReplication | Azure REST API全体ではなく、Data Replication系の管理APIが中心 |
| 新APIバージョン | 2026-05-01 | REST呼び出し、ARM/Bicep、SDK生成で api-version を固定している箇所を確認 |
| 仕様ファイル | stable/2026-05-01/recoveryservicesdatareplication.json | 既存の stable/2024-09-01 との差分を比較 |
| サンプル | examples/2026-05-01 と stable/2026-05-01/examples | 自動テストや社内Runbookのリクエスト例を更新する際の参考にする |
| TypeSpec | main.tsp、models.tsp | Versions enumと追加モデルを確認 |
| SDK影響 | Go、JavaScript、PythonでAPIレビューやBreakingChangeラベルあり | SDK利用者はREST仕様だけでなく生成SDKの公開タイミングと差分を確認 |
main.tsp では、利用可能なAPIバージョンとして v2024_09_01 に加えて v2026_05_01: "2026-05-01" が追加されています。サービス定義のタイトルは「Azure Site Recovery Management Service API」で、名前空間は Microsoft.DataReplication です。(GitHub)
影響を受ける可能性が高い利用者
対応が必要になる可能性が高いのは、Azure Site Recoveryやデータレプリケーション関連の管理操作を、ポータルだけでなくAPIや自動化コードから実行しているチームです。
具体的には、次のような利用がある場合に確認してください。
Microsoft.DataReplication/replicationVaultsをARMテンプレート、Bicep、社内デプロイスクリプトで扱っている- REST APIで vault、fabric、protected item、recovery point、job、event、private endpoint connection を取得・更新している
- Azure SDK for Go、JavaScript、Pythonで Data Replication 系の管理APIを利用している
- DR訓練、フェールオーバー、レプリケーション監視を自動化している
- API仕様からクライアントコードを自動生成している
PRのファイルツリーには、CheckNameAvailability、DeploymentPreflight、EmailConfiguration、Event、Fabric、FabricAgent、Job、Policy、PrivateEndpointConnections、PrivateLinkResources、ProtectedItem、RecoveryPoint、ReplicationExtension、Vault などのサンプルが並んでいます。これらの操作を運用コードで使っている場合は、2026-05-01 の仕様追加を単なるドキュメント更新として見過ごさない方が安全です。(GitHub)
一方で、Microsoft.DataReplication を使っていないWebアプリ、VM、Storage、Network、Azure OpenAIなどの一般的なAzure REST API利用者が、今回の更新だけで何かを変更する必要はありません。対象リソースプロバイダーを切り分けることが、最初の判断基準です。
既存環境への影響は「api-versionを変えるか」で大きく変わる
Azure REST APIでは、多くの管理APIがリクエストURLの api-version クエリパラメーターでバージョンを指定します。つまり、既存コードが api-version=2024-09-01 のように固定されている場合、通常はそのまま旧バージョンの契約で呼び出されます。
例として、Vault取得系の呼び出しでは次のような形になります。
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DataReplication/replicationVaults/{vaultName}?api-version=2026-05-01注意すべきなのは、「新しいバージョンが追加された」ことと「既存環境が自動的に新バージョンへ移る」ことは別だという点です。既存APIバージョンが削除されたとは読み取れず、readme.md には package-2021-02-16-preview、package-2024-09-01、package-2026-05-01 のタグが並んでいます。(GitHub)
ただし、次のような運用では影響が出やすくなります。
| 利用パターン | 影響の出やすさ | 確認ポイント |
|---|---|---|
REST URLに api-version を固定 | 低〜中 | 新バージョンへ変更するまで挙動は変わりにくい |
| SDKを最新版へ更新 | 中〜高 | 生成SDKのメソッド名、型、enum、戻り値の差分を確認 |
| OpenAPI/TypeSpecから社内SDKを生成 | 高 | 2026-05-01 の仕様で生成したコードを既存コードと比較 |
ARM/Bicepで apiVersion を更新 | 中〜高 | デプロイ前に検証環境でWhat-ifやドライランを実行 |
| レスポンス値を厳密にenum分岐 | 高 | 新しい値や未知の値を落とさない実装にする |
注目すべきモデル変更: SecurityOption と HostType
models.tsp では、2026-05-01 で追加された型として SecurityOption と HostType が確認できます。SecurityOption には None、SecureBootEnabled、EnablevTPM、TrustedLaunch が含まれ、HostType には VMWare、HyperV、AzLocal、ALRS、ALM、ALDO、ALADLess などが含まれています。(GitHub)
この変更は、単に選択肢が増えたというだけではありません。DRや移行の自動化では、ホスト種別やセキュリティ設定に応じて処理を分岐していることがあります。たとえば、VMware、Hyper-V、Azure Local系の環境を同じRunbookで扱っている場合、HostType の値を前提にした条件分岐が古いままだと、新しい値を「未知のホスト」として誤処理する可能性があります。
特に注意したいのは、enum値の表記です。VMWare、HyperV、EnablevTPM、ALADLess などは大文字・小文字が混在しています。文字列比較で VMware や EnableVTPM のように書いていると一致しません。APIレスポンスを処理するコードでは、大文字小文字を安易に補正するのではなく、仕様上の値を定数化し、未知の値をログに残して安全側に倒す実装にしておくと運用トラブルを避けやすくなります。
switch (hostType) {
case "VMWare":
case "HyperV":
case "AzLocal":
case "ALRS":
case "ALM":
case "ALDO":
case "ALADLess":
// 既知のホスト種別として処理
break;
default:
// 未知の値。失敗させる前にログ・通知・安全側の分岐を用意する
console.warn(`Unknown hostType: ${hostType}`);
}SDK利用者はBreakingChangeラベルを軽視しない
今回のPRでは、APIViewがAPIレベルの変更を検出し、Swagger、TypeSpec、Go、Python、JavaScript向けのAPIレビューが作成されています。また、PR上では Go SDK、JavaScript SDK、Python SDK に関する BreakingChange ラベルも確認できます。(GitHub)
ここで重要なのは、BreakingChangeラベルを「REST APIが必ず破壊的変更をした」と短絡的に読むのではなく、「生成SDKの公開APIに影響する可能性がある」と捉えることです。RESTのリクエスト・レスポンス契約、TypeSpec、OpenAPI、生成SDKは近い関係にありますが、影響の出方は同じではありません。
SDKを使っている場合は、次の観点で確認してください。
| 確認対象 | 見るべき内容 | 失敗しやすいポイント |
|---|---|---|
| パッケージ更新 | 利用中のSDKに 2026-05-01 対応が含まれるか | SDK更新だけでAPIバージョンも変わったと思い込む |
| 型定義 | enum、union、モデル名、プロパティ名 | 厳密な型変更でコンパイルエラーになる |
| 戻り値 | 新しいフィールドや値の追加 | 既存のJSONパーサーが未知フィールド・未知値を拒否する |
| CI | 生成コードの差分、スナップショットテスト | 自動生成差分をレビューせずに取り込む |
| 実行時 | 認可、リージョン、LROの完了待ち | 認可エラーやポーリング処理を仕様変更と誤認する |
SDK利用者は、まず本番コードのパッケージバージョンを固定し、検証環境だけで新SDKまたは新APIバージョンを試すのが現実的です。DR関連のAPIは障害対応や移行作業と結びつきやすいため、平常時に通る単体テストだけでなく、ジョブ取得、イベント一覧、レプリケーション状態取得、フェールオーバー前後の確認まで含めたテストを用意してください。
移行前に確認すべきチェックリスト
2026-05-01 を採用するかどうかは、機能要件と運用リスクの両方で判断します。新しいAPIバージョンが追加されたからといって、すぐに全コードの api-version を置換する必要はありません。
まず利用箇所を洗い出す
リポジトリやCI/CD定義で次の文字列を検索します。
Microsoft.DataReplication
recoveryservicesdatareplication
replicationVaults
replicationFabrics
protectedItems
api-version=2024-09-01
apiVersion: 2024-09-01
package-2024-09-01ARMテンプレートやBicepでは、REST URLではなく apiVersion として指定されている場合があります。アプリケーションコード、IaC、Runbook、GitHub Actions、Azure DevOps Pipeline、社内CLIを横断して確認してください。
仕様差分を比較する
確認の中心は、既存の stable/2024-09-01/recoveryservicesdatareplication.json と新しい stable/2026-05-01/recoveryservicesdatareplication.json の比較です。PR上では stable/2026-05-01/recoveryservicesdatareplication.json と多数の stable/2026-05-01/examples が追加されています。(GitHub)
比較では、次の順序で見ると効率的です。
| 順序 | 確認内容 | 理由 |
| -: | —————- | ————————— |
| 1 | 対象パスとoperationId | 使っているAPIが変更対象かを最短で判断できる |
| 2 | request body | 送信パラメーターの必須化・型変更が最も障害になりやすい |
| 3 | response body | パーサー、監視、ログ整形への影響を確認できる |
| 4 | enum・定数 | SDKや条件分岐の破壊的変更につながりやすい |
| 5 | examples | 実際の呼び出し例をRunbookやテストに反映しやすい |
検証環境で読み取りAPIから試す
移行テストでは、最初から作成・更新・削除系APIを叩かない方が安全です。まずは読み取り系から試します。
GET .../replicationVaults/{vaultName}?api-version=2026-05-01
GET .../replicationVaults/{vaultName}/events?api-version=2026-05-01
GET .../replicationVaults/{vaultName}/jobs?api-version=2026-05-01読み取り結果で問題がなければ、CheckNameAvailability や DeploymentPreflight のような事前確認系を試し、その後に作成・更新系へ進みます。PRのサンプルにも CheckNameAvailability_Post や DeploymentPreflight_Post が追加されているため、検証順序を組む際の参考になります。(GitHub)
本番反映時の安全な進め方
2026-05-01 へ移行する場合は、APIバージョンだけを一括置換するのではなく、段階的に進めます。
| フェーズ | やること | 合格条件 |
|---|---|---|
| 調査 | 利用API、SDK、IaC、Runbookを洗い出す | Microsoft.DataReplication の利用箇所が一覧化されている |
| 差分確認 | OpenAPI/TypeSpecとサンプルを比較する | 使っているoperationIdの差分が説明できる |
| 検証 | 開発・検証環境で 2026-05-01 を指定する | 読み取り、作成、更新、ジョブ確認が通る |
| SDK確認 | 生成SDKまたは公式SDKをテストする | コンパイルエラー、型変更、未知enumの扱いが解消されている |
| 段階適用 | 一部ワークロードや非本番Runbookから反映する | 監視・ログ・アラートに異常がない |
| 本番適用 | 変更履歴とロールバック手順を残して反映する | 旧 api-version に戻せる手順がある |
ロールバック手順も忘れないでください。REST呼び出しであれば、まずは api-version を旧バージョンへ戻す方法を残しておくのが基本です。SDKの場合は、パッケージバージョンの固定とロックファイルの管理が重要になります。
ありがちな誤解と注意点
「Azure REST API全体が2026-05-01になった」と考えない
今回の更新対象は Microsoft.DataReplication/DataReplication 配下です。Azure REST APIには多数のリソースプロバイダーがあり、APIバージョンはサービスごと、場合によってはリソース種別ごとに管理されます。すべてのAzure管理APIに 2026-05-01 が使えるわけではありません。
PRの情報と公開ドキュメントの反映タイミングを混同しない
PR #42847 は新バージョン追加の仕様変更として確認できますが、PR、ドキュメント、SDK、各種リリース一覧への反映にはタイムラグが出ることがあります。実装前には、PRの状態、生成SDKのリリース、Microsoft LearnやAzure SDK側の参照情報をセットで確認してください。
BreakingChangeラベルを無視しない
Go、JavaScript、Pythonの生成SDKに関するBreakingChangeラベルがあるため、SDK利用者は特に注意が必要です。既存コードがREST APIを直接呼んでいる場合と、SDKの型やメソッドに依存している場合では、影響の出方が異なります。(GitHub)
enumを完全一致で固定しすぎない
SecurityOption や HostType のような値は、将来さらに増える可能性があります。default 分岐で即エラーにするより、ログを残し、処理を止めるべきか安全側で継続すべきかを運用要件に合わせて決めてください。
DR関連APIは「成功レスポンス」だけで判断しない
Data Replication系のAPIは、ジョブ、イベント、ヘルスエラー、フェールオーバー状態など、運用中の状態確認と強く結びつきます。APIが200を返しても、Runbook、監視、通知、障害時手順まで含めて動かなければ本番運用では不十分です。
まず取るべき行動
今回の Azure REST API documentation update: Adds new version 2026-05-01 を確認したら、最初にやることは「自社環境で Microsoft.DataReplication を使っているか」を調べることです。使っていなければ、今回の更新はウォッチ対象に留めて問題ありません。
使っている場合は、次の順序で進めてください。
- コード、IaC、Runbookから
Microsoft.DataReplicationと既存のapi-versionを検索する stable/2026-05-01の仕様ファイルとサンプルを既存バージョンと比較するSecurityOption、HostType、SDK生成差分を確認する- 検証環境で読み取りAPIから
api-version=2026-05-01を試す - SDK利用者はパッケージ更新を本番へ入れる前にCIと型差分を確認する
- 本番反映時は旧APIバージョンへ戻す手順を残す
新APIバージョンの追加は、機能拡張のチャンスである一方、DR運用では小さな型変更やenum追加が自動化の失敗につながることがあります。2026-05-01 を採用する場合は、仕様、SDK、Runbook、監視を同じタイミングで見直すことが、最も安全な移行方法です。
コメント