同一テナント内でAzureリソースをサブスクリプションA→Bへ移動する作業は、単なる「引っ越し」ではなく、依存関係の束ね方と移動後の参照更新が勝負です。本記事ではAction Group／APIM／API Connection／VM／Disk／Storageを例に、影響範囲の洗い出しから移行順序、当日Runbookまで実務目線で整理します。
サブスクリプション間移動の基本：最初に知っておくべき挙動
Azureの「リソース移動（Move）」は、同一リージョンのままリソースの所属（サブスクリプション／リソースグループ）を付け替える操作です。重要なのは、移動によりリソースIDが変わること、そして移動中は移動元・移動先のリソースグループがロックされることです。ロック中は作成・削除・更新ができませんが、既存ワークロード自体は稼働し続けるケースが多く、計画停止の有無は依存関係次第で決まります。
また、Moveで指定できるのは原則として「親（トップレベル）リソース」で、子リソースは親と一緒に移動します（例：VM本体を移動すると拡張機能などの子は追随）。ただし、親子関係は保たれても、他リソースとの参照（依存関係）は壊れる可能性があるため、「移動できる＝移行完了」ではありません。
| 観点 | 移動で変わる | 移動で変わらない（ことが多い） | 実務上の注意 |
|---|---|---|---|
| 識別子 | リソースID（/subscriptions/… がBに変化） | リソース名、リージョン | IDをハードコードしている箇所（アラート、スクリプト、IaC、ダッシュボード）を更新する |
| 操作制限 | 移動中はRGがロックされ更新不可 | 既存の処理自体は稼働し続ける場合が多い | ロックは最長4時間の猶予枠がある前提で、変更凍結と関係者周知を行う |
| 権限 | サブスクリプション境界の継承RBAC、ポリシー影響 | 一部のリソース単体に付いた設定は維持 | 移動によりロール割り当てが孤立（orphan）するケースがあるため再付与計画が必須 |
共通チェックリスト：移行前に必ず潰す項目
| チェック項目 | 具体的な確認内容 | 引っかかりやすいポイント | 対策 |
|---|---|---|---|
| 同一テナント | 移動元・移動先が同じMicrosoft Entra ID（テナント） | テナントが違うとMove自体が不可 | 事前にtenantIdを確認してから計画を立てる |
| 移動サポート | 対象リソース種別が「サブスクリプション移動」に対応しているか | SKUや構成により例外がある | 公式の対応一覧で種別と注意事項を確認し、例外は再構築案を用意 |
| 権限（RBAC） | 移動元RGでmoveResources/action、移動先RGでwriteが可能 | 当日はContributorで足りず止まるケースがある | 事前に最小権限ではなく「当日の移行用ロール」を一時付与する運用も検討 |
| リソースロック | ReadOnlyロックがソース／ターゲットRGやサブスクにないか | ReadOnlyがあるとMove不可 | 移行ウィンドウ前に解除、復旧も手順化 |
| リソースプロバイダー登録 | 移動先サブスクで該当プロバイダーがRegisteredか | 移動先で未使用のプロバイダーだとエラーになりやすい | Microsoft.ApiManagement / Microsoft.Insights / Microsoft.Web / Microsoft.Compute / Microsoft.Storage などを事前登録 |
| ポリシー／クォータ | ポリシーで作成禁止・SKU禁止になっていないか、クォータ超過しないか | RequestDisallowedByPolicyなどで検証段階から失敗 | Validateで先に潰し、必要なら例外申請・クォータ申請 |
| 依存関係の同居 | 跨ぎ移動では「依存リソースは同一RGに集めて一括移動」が求められる | VMとNICが別RGなど、バラバラ配置が多い | 必要に応じて「同一サブスク内でRG集約」→「サブスク跨ぎMove」の2段階に分ける |
| 運用準備 | 変更凍結、メンテ時間周知、バックアップ、DNS/証明書/接続文字列の棚卸し | 「移動はできたがつながらない」が一番危険 | 移動後チェックとロールバック条件を先に合意しておく |
対象6リソースは移動できる？まずは公式一覧で「種別」と「例外」を確認
Azureでは「リソース種別ごと」にMove可否が定義されています。以下は今回対象に挙がっている代表種別の整理です（実際は環境内の付随リソースも必ず確認します）。
| 対象 | 代表的なリソースタイプ | サブスク間Move | 要注意ポイント |
|---|---|---|---|
| Action Group | Microsoft.Insights/actionGroups | 対応 | 参照側（アラート等）が古いIDを握るため更新が必要 |
| API Management（APIM） | Microsoft.ApiManagement/service | 対応 | Consumption SKUはMove不可。構成によっては再構築案が必要 |
| API Connection | Microsoft.Web/connections | 対応 | OAuth系は移行後に再認証（再作成/reauthorize）が必要になりやすい |
| Virtual Machine | Microsoft.Compute/virtualMachines | 対応 | 暗号化・Marketplaceプラン・Backupなど特殊ケースは追加手順が必要 |
| Managed Disk | Microsoft.Compute/disks | 対応 | 通常はVMと一緒に移す。単体移動はデタッチ設計が必要 |
| Storage Account | Microsoft.Storage/storageAccounts | 対応 | 診断ログ／APIMログ／アプリ接続先など参照箇所が多く、棚卸しが重要 |
依存関係の洗い出し：現場で漏れを減らす5ステップ
ステップ1：対象リソースのインベントリを「リソースID付き」で作る
最初に、移動対象を「名前」ではなくリソースIDで一覧化します。Moveの成否も参照更新も、最終的にIDが軸になるためです。移動後はIDが変わるので、移動前後の対応表（旧ID→新ID）もセットで管理します。
az resource list -g <sourceRG> --query "[].{name:name,type:type,id:id}" -o table
ステップ2：Portalの「Move」画面で依存リソースをあぶり出す
Azure portalのMove操作には検証（validation）フェーズがあり、依存関係の不足がある場合はエラーとして提示されます。ここで出る依存不足は「最低限一緒に動かすべきもの」なので、まずはこれをベースラインにします。
ステップ3：Validate APIで「本番前に」移動可否を機械的にチェックする
本番当日に初めてMoveを試すのはリスクが高いので、Azure CLI / PowerShellのValidate（validateMoveResources）を事前に回して、MissingMoveDependentResourcesやPolicy系のエラーを潰します。
# Azure CLI（validateMoveResources）
az resource invoke-action --action validateMoveResources \
--ids "/subscriptions/<sourceSubId>/resourceGroups/<sourceRG>" \
--request-body "{ \"resources\": [\"<resourceId1>\",\"<resourceId2>\"], \"targetResourceGroup\":\"/subscriptions/<targetSubId>/resourceGroups/<targetRG>\" }"
# Azure PowerShell（validateMoveResources）
$sourceRg = Get-AzResourceGroup -Name "<sourceRG>"
$targetRg = Get-AzResourceGroup -Name "<targetRG>"
$resources = Get-AzResource -ResourceGroupName "<sourceRG>"
Invoke-AzResourceAction -Action validateMoveResources `
-ResourceId $sourceRg.ResourceId `
-Parameters @{
resources = $resources.ResourceId
targetResourceGroup = $targetRg.ResourceId
}
ステップ4：参照（ハードコードID）を「全文検索」で拾う
Moveで壊れやすいのは「依存」ではなく「参照」です。例えば、アラート、ダッシュボード、スクリプト、IaC、アプリ設定、Logic Apps定義などに旧IDが埋め込まれていると、移動後に静かに壊れます。
実務では、以下のように旧サブスクリプションID（/subscriptions/旧ID）をキーにしてJSON全文検索をかけ、「どこに参照が残っているか」を先にリストアップすると漏れが減ります。
// Azure Resource Graphの例（概念例：properties内に旧サブスクIDが含まれるものを抽出）
Resources
| where tostring(properties) has "/subscriptions/<oldSubId>/"
| project name, type, resourceGroup, subscriptionId
ステップ5：依存関係マトリクスを作り、移行順序とロールバックを決める
最後に「土台→実行基盤→入口→接続→監視」の順で並べ替えます。依存関係が見えれば、移行順序は自然に決まります。加えて、各ステップで「成功条件」と「切り戻し条件」を明文化しておくと、当日の判断がブレません。
リソース別：依存関係・影響範囲・移行の勘所
Storage account：参照が最も散らばる“土台”
よくある参照元
- VMのブート診断／診断ログ出力先
- APIMやアプリのログ出力（Storageへの保存）
- アプリ設定の接続文字列、SAS、ストレージキー
- 各種バッチ（AzCopy、Functions、スクリプト）が直アクセス
移行時のポイント
- Moveできる場合、ストレージアカウント名やエンドポイントは基本的に維持されるため、アプリ側変更が最小化しやすい（ただしRBACやポリシーは別途確認）。
- Moveが難しい（ポリシーや構成、設計都合）場合は、移行先に新規作成→データコピー（AzCopy等）→参照先を切替、の順で進めます。
- 重要コンテナやBlobは、移行方式に関係なく「復旧できるバックアップ」を先に用意してから触ります。
| チェック項目 | 確認例 | 失敗しやすい症状 | 対処 |
|---|---|---|---|
| 診断/ログ出力先 | VM診断、各種診断設定 | 移行後にログが欠落 | 出力先を新サブスク側のStorage/LAへ再設定 |
| ネットワーク制御 | ファイアウォール、プライベートエンドポイント | アプリからアクセス不可 | 移行先ネットワーク/IDの到達性・許可を再確認 |
| 権限 | RBAC、キー運用 | 403/認証失敗 | Managed Identityや利用者に再付与、キー更新の運用化 |
Virtual Machine + Disk：ネットワークと運用機能で“例外”が出やすい
VM移動は「VMだけ」では完結しません。最低でもNIC、VNet、NSG、Public IPなどネットワーク系の依存が絡みます。特にStandard SKU Public IPに紐づく構成は跨ぎ移動で制約があり、事前にPublic IPの切り離しが必要になるケースがあります。
VM移動で追加手順になりやすい代表例
- ディスク暗号化：サブスクリプション跨ぎでは暗号化を無効化してから移動が必要になるケースがある
- Marketplaceプラン付きVM：跨ぎ移動ができないケースがある（再デプロイが必要）
- Azure Backup：インスタント復旧ポイント（restore point collections）の整理が必要になるケースがある
- 可用性セット：単体で動かせない（セット単位の考慮）
ネットワーク側で見落としがちな代表例
- VNetピアリング：VNet移動が必要な場合、ピアリングの無効化→移動→再有効化が必要
- サブネットのリソースナビゲーションリンク：存在するとVNetを別サブスクへ移動できない場合がある
- Private Endpoint：移動サポートはリソース種別により限定される
| 構成 | 影響 | 推奨対応 |
|---|---|---|
| Standard Public IP付きVM | 跨ぎ移動の制約により、事前に切り離しが必要になる場合 | Public IPをデタッチ→Move→移行先で新Public IPを付与しDNSで吸収 |
| VNetも跨ぎで移す必要がある | VNet移動が詰むとVMの“そのままMove”も詰む | VNetが移せるかを最初にValidate。不可なら新VNetへ再構築（新NIC）案に切替 |
| 暗号化／Backup／Marketplace | 追加手順が必須になりやすい | VM移動ガイダンスを前提に手順化し、必要なら「再作成」ルートも用意 |
Disk（マネージドディスク）：基本はVMと一括、単体移動は設計が必要
- 通常はVMとディスクを同じMove操作に含めます（依存関係があるため）。
- ディスク単体を移したい場合は、事前にVMからデタッチし、移動後に再アタッチする設計が必要です（運用上の停止や整合性確認が増えます）。
API Management（APIM）：Moveか再構築かを早期に見極める
APIMはサブスクリプション間移動に対応しています。一方で、Consumption SKUはMoveできないため、その場合は「移行先に新規APIMを構築し、設定を移植する」方式が前提になります。
依存関係の例（現場で必ず確認）
- バックエンド到達性：APIM→VM/サービスへの疎通（VNet統合・NSG・DNS）
- カスタムドメイン：DNSレコード、証明書（Key Vault参照の有無）
- ログ出力：Log Analytics / Storage / Event Hub 等の出力先
- 運用：リリース（CI/CD）、Named Value、ポリシー、プロダクト、サブスクリプションキー運用
移行前バックアップの実務ポイント
- 「設定を復元できる状態」を最優先に、API定義・ポリシー・プロダクト構成はエクスポートして保全します。
- Moveできる場合でも、移動中のロックや、移動後の周辺参照更新（ログ先、証明書参照など）を見込んでテスト手順を作ります。
API Connection：Moveはできても“認証は別問題”
Microsoft.Web/connections（いわゆるAPI Connection）はサブスクリプション間Moveに対応しています。ただし、Logic Appsなどと組み合わせる場合、移行後にOAuthが必要な接続は再作成または再認証が必要になる点が実務の落とし穴です。
依存関係の典型
- 参照元：Logic Apps（Consumption/Standard）、Playbook、各種自動化
- 依存先：サービスプリンシパル／Managed Identity、接続情報（トークン等）
推奨アプローチ（失敗率を下げる）
- 「Moveする」よりも「移行先で新規作成→再認証→利用側を切替」の方が、結果的に早く安定します（特にOAuth系）。
- 利用側（Logic Apps等）に埋め込まれたconnectionId（旧ID）を、新IDに置換するタスクをRunbookに明記します。
Action Group：移動後に“通知が飛ばない”事故を防ぐ
Action Group自体はMoveできますが、アラートルールはAction GroupをリソースIDで参照していることが多く、移動でIDが変わると参照更新が必要になります。さらに、アラート（ルール）はスコープに特定リソースIDを含む場合、移動後に古いIDを見に行って失敗するため、ルール側の更新／再作成まで含めて計画します。
現場で安全な切替パターン
- パターンA（推奨）：移行先で新Action Groupを作成→アラートルール側を順次切替→通知テスト→旧を廃止
- パターンB：Action GroupをMove→アラートルールの参照を一括更新→通知テスト
パターンAは「新旧を並行できる」ため切り戻しが簡単です。監視系は最後に移す設計にすることで、移行中の検知が薄くなる時間を最小にできます。
推奨される移行順序：土台→実行→入口→接続→監視
複数リソースの跨ぎ移行は、順序を間違えると「動かしたのに到達できない」「認証だけが壊れる」「監視が沈黙する」など複合障害になります。安全側の考え方として、次の順を推奨します。
| 順序 | 対象 | 目的 | 成功条件（最低限） | 切り戻しの考え方 |
|---|---|---|---|---|
| 先行 | Storage account | ログ/データの土台を先に安定 | 重要データの読み書き・ログ出力が成立 | 旧ストレージを残して参照だけ戻せる設計に |
| 次 | VM + Disk（+ネットワーク） | バックエンドを先に稼働可能に | 起動、疎通、アプリ動作 | 旧VMを残す/停止で温存、DNS切替で戻せるように |
| 次 | APIM | 入口（API）を新サブスクへ | 主要APIの疎通、認証、ログ | カスタムドメイン切替前なら戻しやすい |
| 次 | API Connection | 自動化/連携の復旧 | 再認証完了、ワークフロー正常 | 旧接続を残し、段階的に切替 |
| 最後 | Action Group（＋アラート） | 監視・通知を完全復旧 | テスト通知が届き、ルールも有効 | 旧監視を残し、切替後もしばらく併走 |
当日Runbook：そのままMoveするケースの実行手順（雛形）
フェーズ0：作業前（開始前チェック）
- 変更凍結の宣言（アプリ/ネットワーク/監視）
- 移動元/先のReadOnlyロック解除（終了後に戻す手順も用意）
- 移動先サブスクでプロバイダー登録済みを確認
- クォータ・ポリシー事前確認（Validateで通る状態）
- APIM設定・重要データのバックアップ取得
- ロールバック条件（例：主要API疎通NG、VM起動不可、監視復旧不可）をチームで再確認
フェーズ1：Validate（本番前最終検証）
Move対象（親リソース）と依存（NIC、VNetなど）を同一のMoveバッチに含め、validateMoveResourcesでエラーが出ないことを確認します。
フェーズ2：ネットワークの事前調整（該当時のみ）
- Standard Public IPが紐づく場合はデタッチ（必要なら後で新規PIP付与）
- VNetを跨ぎでMoveする必要がある場合、VNetピアリングを無効化→Move後に再有効化
- Private Endpointやサブネットリンク等、移動不可条件がないか最終確認
フェーズ3：Storage accountの移動（または切替）
MoveできるならMove対象に含め、Moveできないなら新規作成→データコピー→参照切替の方式に切替します。
フェーズ4：VM + Diskの移動
VMは構成により追加作業が必要です。暗号化・Marketplaceプラン・Azure Backupが絡む場合は、公式の特殊ケース手順をRunbookに組み込んでから実施します。
- 暗号化：跨ぎ移動の前に暗号化無効化が必要になるケースがある
- Azure Backup：restore point collections（インスタント復旧ポイント）の整理が必要になるケースがある
実際のMoveは、Azure CLIのaz resource move、またはPowerShellのMove-AzResourceで行います（Move-AzResourceはサブスク跨ぎに対応し、-WhatIf等の一般的な保護パラメータも利用可能です）。
# Azure CLI（Move）
az resource move --destination-group <targetRG> \
--destination-subscription-id <targetSubId> \
--ids <resourceId1> <resourceId2> <resourceId3>
# Azure PowerShell（Move）
Move-AzResource `
-DestinationSubscriptionId <targetSubId> `
-DestinationResourceGroupName <targetRG> `
-ResourceId @(<resourceId1>, <resourceId2>)
フェーズ5：APIMの移動（または再構築）
- Move可能なSKUで、依存（ログ先・VNet・証明書参照等）の整合が取れるならMove。
- Consumption SKUなどMove不可の場合は、移行先に新規APIMを作り、バックアップ/エクスポートした構成を移植。
- バックエンド疎通、カスタムドメイン、TLS、認証（サブスクキー/JWT等）を重点的に確認。
フェーズ6：API Connectionの再作成・再認証（推奨）
Logic Apps等でOAuthを使う接続は、移行後に再作成または再認証が必要になります。ここを後回しにすると「Moveは成功したのにワークフローだけ死んでいる」状態になりやすいので、入口（APIM）より後、監視より前に確実に復旧させます。
- 移行先でAPI Connectionを作成し、サインインして認証を確立
- Logic Apps/利用側のconnectionIdを新しいIDへ差し替え
- 手動実行で成功することを確認
フェーズ7：Action Groupとアラートの復旧（最後）
- Action Groupを移行先で新規作成（またはMove）
- アラートルールのAction Group参照（ID）を更新
- 通知テスト（メール/Teams/Webhook等）を実施
- ルールのスコープが旧IDを参照していないか確認し、必要なら更新または再作成
移動不可・再構築が必要な場合の代替ルート
現実には「一部はMoveできるが、一部はMoveできない」混在がよく起きます。その場合は、Moveに固執せず、最小影響で再構築できる設計を選びます。
| 対象 | Moveできない/しない理由 | 代替案 | 影響を抑えるコツ |
|---|---|---|---|
| APIM（Consumption） | SKU制約でMove不可 | 移行先に新規APIM→構成移植 | カスタムドメインをDNS切替にしてBlue/Green化 |
| API Connection（OAuth） | トークン/認証が引き継げない | 移行先で再作成・再認証 | 利用側を段階切替し、旧接続を残しておく |
| VMのネットワーク | VNet移動不可条件、PIP制約など | 移行先VNetを新規作成し、新NICでVM再構築/切替 | DNS/ロードバランサで切替点を一箇所に寄せる |
移行後に必ずやる確認：チェック漏れを防ぐ“最終試験表”
| 領域 | 確認項目 | 合格基準 | 失敗時の初動 |
|---|---|---|---|
| 権限 | RBAC（特にサブスク継承で付いていた権限） | 運用者・アプリが必要操作できる | 不足ロールの付与、孤立ロールの整理 |
| VM | 起動、RDP/SSH、アプリ疎通 | ユーザー操作とAPI応答が正常 | ネットワーク（NSG/ルート/DNS）から切り分け |
| Storage | 読み書き、診断ログの出力 | データ整合、ログが流れる | 接続文字列/キー/RBAC/ネットワーク制限を再確認 |
| APIM | 主要APIの疎通、認証、ポリシー | 想定通りのステータス・遅延 | バックエンド疎通、証明書、Named Valueの確認 |
| API Connection | 再認証、ワークフロー実行 | 手動/自動実行とも成功 | コネクションID差替、権限/同意の見直し |
| 監視 | アラート発火、通知、ルールのスコープ | テスト通知が届く | Action Group参照更新、必要ならルール再作成 |
ロールバックと旧環境クリーンアップ：失敗したときに戻せる設計にする
Moveは途中で失敗すると「一部は移動済み／一部は未移動」の状態が起こり得ます。またMoveできたとしても、参照更新が終わるまでは“機能的に未完”です。現場では、次の2段構えが安全です。
- 切替点（DNS/入口）を最後にする：APIMカスタムドメイン、Public IP参照など、外部影響が出る切替を最後に持っていく
- 旧環境は一定期間残す：移行後の監視・稼働確認期間を設け、問題がないことを確認してから削除
| 状況 | 判断基準 | 推奨アクション |
|---|---|---|
| Move自体が失敗 | Validate段階で依存不足/ポリシーが判明 | 対象を同一RGに集約、依存追加、ポリシー例外のいずれかで再計画 |
| Move成功だが疎通不可 | VM/APIM/Storageの到達性が崩れた | DNS切替前なら旧へ戻せる。切替後ならネットワーク・権限・参照更新を優先 |
| 監視だけ沈黙 | 通知が来ない／ルールが旧ID参照 | Action Group切替、ルール更新（必要なら再作成） |
テンプレート：依存関係マトリクス（記入例）
Runbookに落とすときは、最低限この粒度で「どれがどれに依存しているか」を残すと、当日の作業が格段に速くなります。
| リソース | 依存先（動かす/再作成するもの） | 参照元（更新が必要なもの） | 移行方式 | 移行後テスト |
|---|---|---|---|---|
| StorageA | （必要なら）Private Endpoint / 診断設定 | VM診断、APIMログ、アプリ接続文字列 | Move or 新規+コピー | 読み書き、ログ出力 |
| VM1 | NIC1、VNet1、NSG、Disk(OS/Data)、PIP | APIMバックエンド、監視対象 | Move（一括） | 起動、SSH/RDP、API疎通 |
| APIM1 | VNet/サブネット（構成次第）、証明書、ログ先 | DNS、クライアント設定、監視 | Move or 再構築 | 主要API、認証、ポリシー |
| APIConn1 | 認証（OAuth/MI） | Logic Apps定義（connectionId） | 新規+再認証 | ワークフロー実行 |
| ActionGroup1 | 通知チャネル（Email/Teams/Webhook） | アラートルールのAction参照 | 新規→切替 | テスト通知 |
まとめ：成功の鍵は「Moveの成否」ではなく「参照更新まで含めた完了定義」
サブスクリプション間のAzureリソース移動は、公式にMove対応しているリソースでも、依存関係の同居、ネットワーク制約、認証の再確立、監視の参照更新など、実務タスクが多層になります。
だからこそ、事前のValidateと依存関係マトリクス、そして「土台→実行→入口→接続→監視」の順序で進めるRunbookが効果を発揮します。移行後チェックとロールバック条件を先に合意し、旧環境を一定期間温存する設計にしておけば、複数リソースを跨ぐ移行でも安全に完遂できます。
コメント