MENU

Azure REST APIにCross-Tenant Restore追加へ：2026-03-31-previewの変更点と確認ポイント

Azure

2026年5月5日に更新確認が行われた「Add Cross-Tenant Restore (CTR) feature – API version 2026-03-31-preview」は、Azure REST APIでRecovery Services Backup向けのCross-Tenant Restore、つまり異なるテナントのバックアップ元Vaultから復元するためのプレビューAPIを追加する更新です。結論から言うと、既存の安定版APIをすぐ置き換える変更ではありません。対応すべきなのは、Azure Backupの復元自動化、Azure REST APIの直接呼び出し、AutoRest/SDK生成、IaCや運用ツールでRecovery Services Backupを扱っているチームです。PRはRecoveryServicesBackupに2026-03-31-previewを追加し、CTR関連のVaultマッピング、保護アイテム、復旧ポイント、復元、検証、資格情報生成の操作例を含めています。(GitHub)

重要なのは、これは「テナントをまたぐ復元」を扱うAPI仕様のプレビュー更新であり、Cross Subscription RestoreやCross Region Restoreとは確認すべき観点が異なる点です。既存の復元スクリプトをそのまま流用するのではなく、api-version=2026-03-31-previewを使う箇所、長時間実行操作のポーリング、Vaultマッピング名、ソースVault ID、テナント権限、削除ではなくremoveCrossTenantVaultMappingアクションを使う点を個別に確認してください。(GitHub)

目次

Azure REST APIのCTR更新でまず押さえるべきポイント

今回のAzure REST API documentation updateは、Recovery Services Backupの既存APIに単純なパラメーターを1つ足す更新ではありません。backupCrossTenantVaultMappingsというCTR用のマッピングリソースを中心に、別テナントのソースVaultから保護アイテムや復旧ポイントを参照し、復元処理を実行するための操作群が追加されています。PR概要でも、2026-03-31-previewの新しいARM APIバージョンを追加し、Cross-Tenant Restoreをサポートすることが説明されています。(GitHub)

確認項目変更内容実務で見るべきポイント
APIバージョン2026-03-31-previewが追加本番処理全体を置き換えず、CTR検証用のコードパスだけで使う
対象リソースMicrosoft.RecoveryServices/vaults/backupCrossTenantVaultMappingsターゲットVaultとソースVaultの関係をAPI上で管理する
操作の種類マッピング作成、一覧、取得、状態確認、削除相当のremove、保護アイテム一覧、復旧ポイント取得、復元、検証、Vault資格情報生成単発APIではなく一連の復元フローとして設計する
実行方式一部操作は長時間実行操作として202 Accepted、Location、Azure-AsyncOperation、Retry-Afterを使う固定のsleepではなく、レスポンスヘッダーに従ってポーリングする
SDK生成PR上ではSDK Validationに関する課題やレビューコメントも見られるREST仕様の更新と各言語SDKの利用可能時期を分けて確認する

特に注意したいのは、PRが「ARM、つまりControl Plane API」の仕様更新として扱われている点です。データプレーンAPIの変更ではないため、Azure Resource Managerの認証、RBAC、サブスクリプション、リソースグループ、Recovery Services Vaultの権限設計が影響範囲になります。PR説明にもARM関連仕様の変更であることが示されています。(GitHub)

Cross-Tenant Restoreとは何か

Cross-Tenant Restore、略してCTRは、名前の通り「異なるMicrosoft Entraテナントに属するソースVaultのバックアップデータを、ターゲット側のVault経由で扱う」ための復元シナリオです。今回の仕様では、ソースVaultをsourceVaultIdとしてマッピングし、そのマッピング配下で保護アイテム、復旧ポイント、ジョブ、復元処理を扱う形になっています。作成例では、リクエストにproperties.sourceVaultIdを指定し、レスポンスにsourceTenantId、mappingName、createdTime、provisioningStateが返る例が示されています。(GitHub)

既存のCross Subscription Restoreと混同しやすいので、違いを整理しておきます。Microsoft Learnでは、Cross Subscription Restoreは「同じテナント内の別サブスクリプション」へのAzure VMまたはディスク復元として説明されています。一方、今回のCTRはAPI仕様上、ソースVaultが「different tenant」にある前提の操作群として定義されています。(Microsoft Learn)

機能主な目的テナントの扱い確認すべき設定
Cross-Tenant Restore異なるテナントのソースVaultから復元するテナントをまたぐソースVault ID、ソーステナント、ターゲットVault、CTRマッピング、権限
Cross Subscription Restore同一テナント内の別サブスクリプションへ復元する同一テナント内VaultのCSR設定、復旧ポイント層、RBAC
Cross Region Restoreペアリージョンなど別リージョンへ復元するテナントではなくリージョンが主軸Vaultの冗長性、セカンダリリージョン、ステージングストレージ
Cross Zonal Restore同一リージョン内の別Availability Zoneへ復元するテナントではなくゾーンが主軸ZRS/CRR、復旧ポイント層、暗号化やVM条件

この違いを押さえないと、運用手順で「別サブスクリプションへ復元できるから別テナントも同じ」と誤解しやすくなります。CTRでは、サブスクリプションやリージョンだけでなく、テナント境界をまたぐ権限、監査、承認フローを設計に入れる必要があります。

追加されたAPIでできること

今回の2026-03-31-previewでは、CTRの復元フローに必要な複数のREST APIがまとまって追加されています。単に「復元APIが1つ増えた」と見るのではなく、マッピング作成、状態確認、対象データの探索、検証、復元実行、ジョブ確認、後片付けまでを一連の運用として捉えるのが実務的です。

操作カテゴリ主なAPI/操作何に使うか
Vaultマッピング状態確認backupCrossTenantVaultMappingStatusターゲットVaultがCTR操作に利用できる状態か確認する
Vaultマッピング管理backupCrossTenantVaultMappingsのGET/PUT/LISTソースVaultとターゲットVaultの関連付けを作成・確認する
マッピング削除相当removeCrossTenantVaultMapping標準DELETEではなく、removeアクションでマッピングを解除する
保護アイテム参照backupProtectedItems別テナントのソースVault側にある保護アイテムを一覧する
復旧ポイント参照recoveryPoints復元対象となる復旧ポイントを一覧・取得する
復元実行recoveryPoints/{recoveryPointId}/restore指定した復旧ポイントから復元を開始する
検証backupValidateOperation、backupTriggerValidateOperation復元前の検証を同期または非同期で実行する
ジョブ確認backupJobs、backupJobs/{jobName}CTR関連のバックアップ/復元ジョブを追跡する
Vault資格情報生成vaultCredentials/{certificateName}/generateクロステナント復元シナリオ用のVault資格情報を生成する

仕様上、CTR用のルートは/vaults/{vaultName}/backupCrossTenantVaultMappings/{crossTenantVaultMappingName}配下に展開されます。保護アイテムや復旧ポイントを取得するAPIでは、fabricName、containerName、protectedItemName、recoveryPointIdなど、Azure Backup特有の階層的な識別子を扱います。復元処理は非同期操作として定義されており、例ではLocation、Azure-AsyncOperation、Retry-Afterが返されています。(GitHub)

誰が対応すべきか

この更新は、Azure Backupをポータルから手動操作しているだけの利用者よりも、REST APIやSDK、運用自動化を使っているチームへの影響が大きい更新です。

対象者対応の必要性具体的に確認すること
Azure REST APIを直接呼び出している開発者高api-versionの切り替え、LRO処理、CTR用エンドポイント、エラーハンドリング
Azure BackupのDR運用担当者高別テナント復元の承認フロー、復旧ポイント選定、復元先リソース設計
SDKやAutoRestを使う開発チーム中〜高package-preview-2026-03-31-previewタグ、SDK生成結果、言語別の対応状況
IaC/運用ツールの保守担当中既存のRecovery Services Backup管理コードがプレビューAPIに依存しないか
セキュリティ・監査担当高テナント境界、Vaultアクセス、復元操作の監査ログ、権限分離
Azure Backupを通常の同一テナント復元だけで使うユーザー低すぐに変更する必要はないが、将来のDR要件として把握する

プレビューAPIは検証価値が高い一方で、本番運用の標準APIとして採用するには慎重さが必要です。PR上では2026年5月5日に更新確認の依頼とレビューが行われ、レビューコメントも残っています。記事執筆時点では、仕様のレビュー状況やSDK生成状況を確認しながら扱うべき段階と見るのが安全です。(GitHub)

既存環境への影響範囲

既存のRecovery Services Backup APIを使っているすべての処理が壊れる、という種類の変更ではありません。2026-03-31-previewを明示的に指定しない限り、通常は既存のAPIバージョンで動く処理が自動的にCTR仕様へ切り替わるわけではありません。

ただし、次のような環境では影響確認が必要です。

APIバージョンを自動で最新化している

運用ツールやSDK生成パイプラインで「最新のpreviewタグを使う」設定にしている場合、意図せず2026-03-31-previewの仕様を取り込む可能性があります。今回のreadmeでは、package-preview-2026-03-31-previewタグがpreview/2026-03-31-preview/bms.jsonを参照するよう追加されています。(GitHub)

安定運用では、次のように用途別に分けるのがおすすめです。

用途推奨する扱い
既存の本番復元処理既存の安定版APIバージョンを固定する
CTR検証2026-03-31-previewを明示的に指定する
SDK生成検証previewタグ専用のCIジョブで生成・差分確認する
本番導入判断Azure公式ドキュメント、SDKリリース、サポート条件を別途確認する

復元処理を単発APIとして実装している

CTRでは、復元前にマッピング状態確認、保護アイテム一覧、復旧ポイント取得、検証、復元実行、ポーリングという流れが必要になります。既存の「復旧ポイントIDを指定して復元するだけ」の実装に近い作りだと、途中のCTRマッピングやジョブ監視が抜けやすくなります。

LROポーリングを固定秒数で処理している

復元や資格情報生成の例では、202 Acceptedに対してLocation、Azure-AsyncOperation、Retry-Afterが返ります。サンプルではRetry-Afterが60ですが、実装では固定値に決め打ちせず、レスポンスヘッダーを優先してください。復元処理の例、Vault資格情報生成の例のどちらも、非同期操作としてポーリングURLが示されています。(GitHub)

マッピング削除をDELETEで実装しようとしている

CTRのマッピング解除は、通常のDELETEではなくremoveCrossTenantVaultMappingアクションとして定義されています。例では、resourceGuardOperationRequestsを含むボディを渡し、202または204を受ける形です。削除処理の自動化では、RESTメソッドとエンドポイントを間違えないようにしてください。(GitHub)

移行・設定確認のチェックリスト

CTRを検証または導入候補にする場合は、API仕様だけでなく、運用設計まで含めて確認します。

チェック項目確認内容見落としやすい点
APIバージョン2026-03-31-previewを使う箇所を限定したか既存処理までpreviewに切り替えない
ソースVault IDsourceVaultIdが完全なARM IDかサブスクリプション、リソースグループ、Vault名の誤り
テナント情報ソーステナントとターゲットテナントを識別できるか同一テナントのCSRと混同する
マッピング名crossTenantVaultMappingNameの命名規則を満たすか数字始まりや記号入りの自動生成名
権限復元操作、Vault参照、ストレージ、VM作成に必要なRBACがあるかソース側とターゲット側の承認が分断される
復旧ポイント復元対象のprotectedItemNameとrecoveryPointIdを取得できるか表示名ではなくAPI上の識別子が必要
LROLocationまたはAzure-AsyncOperationを追跡する実装か202を成功完了と誤判定する
監査誰が、どのVaultから、どこへ復元したか記録できるかテナント跨ぎの証跡が片側にしか残らない
後片付け不要なマッピングや一時資格情報を解除できるかremoveアクションや資格情報の扱いを手順化していない

REST APIで確認する基本フロー

以下は、検証時に考えやすい流れです。実際の本番適用では、Microsoftの正式ドキュメント、サポート条件、組織の変更管理手順に従ってください。

アクセストークンを用意する

Azure REST APIとして呼び出すため、Azure Resource Manager向けのBearerトークンを使います。

az account get-access-token \
  --resource https://management.azure.com/ \
  --query accessToken \
  -o tsv

取得したトークンは、以降のリクエストで次のように指定します。

Authorization: Bearer <access-token>
Content-Type: application/json

Vaultマッピング状態を確認する

最初に、ターゲット側のRecovery Services VaultがCTRマッピングとして扱える状態か確認します。

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{vaultName}/backupCrossTenantVaultMappingStatus?api-version=2026-03-31-preview

レスポンス例では、mappingNameとmappingStateが返り、mappingStateはActiveとして示されています。(GitHub)

Cross-Tenant Vault Mappingを作成する

次に、ターゲットVault配下にCTRマッピングを作成します。ボディでは、ソースVaultのARM IDをsourceVaultIdとして指定します。

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{vaultName}/backupCrossTenantVaultMappings/{crossTenantVaultMappingName}?api-version=2026-03-31-preview
{
  "properties": {
    "sourceVaultId": "/subscriptions/{sourceSubscriptionId}/resourceGroups/{sourceResourceGroup}/providers/Microsoft.RecoveryServices/vaults/{sourceVaultName}"
  }
}

作成例では、成功レスポンスにsourceTenantId、mappingName、createdTime、provisioningStateが含まれています。ここでprovisioningStateがSucceededになっているかを後続処理の条件にしてください。(GitHub)

保護アイテムと復旧ポイントを取得する

マッピング作成後、ソースVault側の保護アイテムを取得します。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{vaultName}/backupCrossTenantVaultMappings/{crossTenantVaultMappingName}/backupProtectedItems?api-version=2026-03-31-preview

例では、protectedItemType、virtualMachineId、protectionState、lastBackupTimeなどが返っています。復元対象を選ぶときは、VM名だけで判断せず、virtualMachineIdとprotectedItemNameを必ず対応させてください。(GitHub)

復旧ポイントは、保護アイテム配下で取得します。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{vaultName}/backupCrossTenantVaultMappings/{crossTenantVaultMappingName}/backupFabrics/{fabricName}/protectionContainers/{containerName}/protectedItems/{protectedItemName}/recoveryPoints?api-version=2026-03-31-preview

例では、IaasVMRecoveryPoint、recoveryPointType、recoveryPointTime、isSourceVMEncrypted、recoveryPointTierDetailsなどが返ります。復元先の要件に合う復旧ポイントか、暗号化、復旧ポイント階層、時刻を確認してください。(GitHub)

復元を実行する

復元は、復旧ポイントに対してrestoreアクションを実行します。

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{vaultName}/backupCrossTenantVaultMappings/{crossTenantVaultMappingName}/backupFabrics/{fabricName}/protectionContainers/{containerName}/protectedItems/{protectedItemName}/recoveryPoints/{recoveryPointId}/restore?api-version=2026-03-31-preview
{
  "properties": {
    "objectType": "IaasVMRestoreRequest",
    "recoveryPointId": "{recoveryPointId}",
    "recoveryType": "RestoreDisks",
    "sourceResourceId": "/subscriptions/{sourceSubscriptionId}/resourceGroups/{sourceResourceGroup}/providers/Microsoft.Compute/virtualMachines/{vmName}",
    "storageAccountId": "/subscriptions/{targetSubscriptionId}/resourceGroups/{targetResourceGroup}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}",
    "region": "{targetRegion}"
  }
}

例では、復元リクエストのrecoveryTypeにRestoreDisksが使われ、sourceResourceId、storageAccountId、regionが指定されています。レスポンスは202または204の形で、202の場合はポーリングURLを追跡します。(GitHub)

実装時に失敗しやすいポイント

CTRのような復元系APIは、成功時だけでなく、途中失敗や承認不足、対象不一致が起きたときの設計が重要です。

失敗しやすいポイント起きる問題対策
api-versionを全処理でpreviewに変更する既存処理に想定外の影響が出るCTR専用処理だけ2026-03-31-previewにする
ソースVault IDを短い名前で渡すマッピング作成に失敗する完全なARM IDを使う
202 Acceptedを完了扱いする復元が終わる前に後続処理が走るLocationまたはAzure-AsyncOperationで完了まで追跡する
Retry-Afterを無視する過剰なポーリングや制限に繋がるヘッダー値を優先して待機する
CSRとCTRを同じ権限設計にする別テナント側の承認・監査が抜けるソース/ターゲットの両テナントで権限と証跡を確認する
マッピング名を自由形式で生成する名前規則違反で失敗する英字始まり、英数字のみなど仕様上のパターンを満たす
removeをDELETEで実装するマッピング解除処理が通らないremoveCrossTenantVaultMappingを使う
復元対象をVM表示名だけで選ぶ同名リソースや誤対象復元のリスクがあるprotectedItemName、sourceResourceId、recoveryPointIdで照合する

特に、復元は「失敗しても再実行すればよい」だけでは済まない運用です。ターゲット側のリソースグループ、ストレージアカウント、ネットワーク、ディスク、暗号化、監査ログまで含めて、事前検証とロールバック手順を用意しておくべきです。

SDK・AutoRest利用者が確認すべきこと

AutoRestや各言語SDKを使っている場合は、REST仕様が更新されたことと、すぐに利用中SDKで呼び出せることを分けて考えてください。readmeではpackage-preview-2026-03-31-previewタグが追加され、preview/2026-03-31-preview/bms.jsonを入力にする設定が示されています。(GitHub)

検証の流れは次の通りです。

手順確認内容
仕様差分の確認既存APIバージョンとの差分、追加されたoperationId、レスポンス型を確認する
生成コードの確認使う言語のSDK生成が成功するか、CTR関連モデルが過剰に公開されないか確認する
LROクライアントの確認202、204、Location、Azure-AsyncOperationへの対応を確認する
ページングの確認nextLink、$skipToken、$filterの扱いをテストする
本番SDKとの差分管理preview生成物を本番SDKに混ぜず、検証用パッケージとして分離する

PR上では、.NET SDK Validationに関する課題や、TypeSpec上のパラメーターモデルをalias化するレビューコメントも出ています。SDK利用者は、REST API仕様だけでなく、利用する言語の生成状況・公開パッケージ・既知の制約を確認してから採用判断をしてください。(GitHub)

セキュリティと運用で確認すべき観点

Cross-Tenant Restoreは、技術的には復元APIの追加ですが、運用上は「別テナントのデータをどこへ復元できるか」を扱う高リスク領域です。便利さだけで導入すると、権限過多や監査不足につながります。

権限はソース側とターゲット側に分けて設計する

ターゲット側で復元を実行できるユーザーが、ソース側Vaultのバックアップデータを参照・復元できるとは限りません。CTRマッピングを作る担当者、復旧ポイントを選ぶ担当者、復元先リソースを作る担当者、承認者を分ける設計が現実的です。

復元先のストレージとネットワークを事前に決める

VM復元では、ストレージアカウント、リソースグループ、リージョン、仮想ネットワーク、サブネット、ディスク暗号化などが実務上の詰まりどころになります。Microsoft Learnでも、通常のVM復元では復元方式によってストレージアカウントやテンプレート、サブスクリプション、ゾーンの扱いが変わることが説明されています。(Microsoft Learn)

監査ログを片側テナントだけで完結させない

テナントをまたぐ復元では、ソース側で「どのバックアップデータが参照されたか」、ターゲット側で「どこへ復元されたか」を両方確認できるようにする必要があります。インシデント対応や内部監査では、復元の実行者、承認者、対象Vault、復旧ポイント、復元先リソース、ジョブIDを一連の証跡として残すのが望ましいです。

すぐに取るべきアクション

今回のAzure REST API documentation updateを受けて、まずやるべきことは次の3つです。

まず、Recovery Services Backup APIを使っているコード、SDK生成、IaC、運用スクリプトを棚卸しし、api-versionを固定しているか確認してください。既存の安定運用にpreview APIが混ざらないようにすることが最優先です。

次に、CTRを検証する必要があるチームだけ、2026-03-31-previewを使った専用の検証環境を作ります。Vaultマッピング作成、保護アイテム一覧、復旧ポイント取得、検証、復元、LROポーリング、マッピング解除までを一通りテストしてください。

最後に、テナントをまたぐ復元の承認・監査・権限設計をドキュメント化します。CTRはAPIを呼べるだけでは安全に運用できません。ソースVaultとターゲットVaultの関係、誰が復元を許可するか、どの復元先を許可するか、復元後に何を削除・記録するかまで決めておくことで、プレビューAPIの検証を本番導入判断につなげやすくなります。

Azure
Azure Backup Azure REST API Cross-Tenant Restore Recovery Services

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次