Azureを長く運用していると、組織変更やグループ会社統合をきっかけに「別テナントへサブスクリプションとリソースをまとめて移したい」というニーズが必ず出てきます。本記事では、その可否と具体的な手順、見落としやすい注意点までを、実務でそのまま使えるレベルで整理します。
Azureサブスクリプションを別ディレクトリ（テナント）へ移行できるのか
最初に、よくある誤解を含めて「何ができて、何ができないのか」を整理します。
結論の要点
- サブスクリプションの「ディレクトリ（テナント）変更」は可能です。
- ディレクトリ変更を行うと、そのサブスクリプション配下のすべてのAzureリソースはまとめて新テナントにぶら下がる形になります。
- ただし、RBAC（ロール割り当て）・カスタムロール・マネージドID・Key Vaultアクセス制御など、ID／権限に紐づく情報はテナントをまたいで移りません。移管後に新テナント側で再作成・再設定が必要です。
- 個々のリソースをサブスクリプション間で移動できるのは同一テナント内のみです。テナントをまたぐ「リソース単位の移動」はサポートされていません。
- したがって、別テナントへの移行手段として現実的なのは、①サブスクリプションごとのディレクトリ変更か、②新テナント側への再構築＋データ移行のどちらかです。
- 一部の提供形態（例：CSPパートナーから提供される一部のサブスクリプション）はディレクトリ変更の対象外である点に注意が必要です。
つまり、「今のサブスクリプションとリソース群を丸ごと別テナントへ引っ越したい」という要求に対しては、サブスクリプションのディレクトリ変更が王道です。ただし「権限・ID・Key Vaultまわりは引き継がれない」という前提を理解しておくことが、安全な移行計画のスタートラインになります。
用語と構造の整理：ディレクトリ／テナント／サブスクリプション
移行手順を理解するために、よく使われる用語の関係を簡単に整理しておきます。
| 項目 | 概要 | 移行時のポイント |
|---|---|---|
| ディレクトリ（テナント） | Microsoft Entra ID（旧Azure AD）のインスタンス。ユーザー、グループ、アプリ、サービスプリンシパルなどのIDを管理する単位。 | サブスクリプションのディレクトリ変更とは、このテナントの紐付け先を変える操作。 |
| サブスクリプション | 課金と管理の単位。リソースグループや各種Azureリソースはサブスクリプション配下に存在する。 | 今回の主役。ディレクトリ変更により、紐付くテナントを切り替えられる。 |
| アカウント（ユーザー） | ディレクトリに属するユーザーやサービスプリンシパルなどのID。 | ディレクトリ変更後は、新テナント側のユーザー／グループ／SPNを使って権限を再構成する。 |
この構造を意識しておくと、「なぜRBACやマネージドIDは引き継がれないのか」「なぜKey Vaultの設定をやり直す必要があるのか」が理解しやすくなります。
別テナントへの移行パターンの全体像
別テナントへサブスクリプション／リソースを移行するパターンを、ざっくりマッピングすると次のようになります。
| パターン | 概要 | テナント跨ぎ | 向いているケース |
|---|---|---|---|
| サブスクリプションのディレクトリ変更 | サブスクリプションを丸ごと別テナントに紐付け直す。 | 可能 | 既存のリソース構成をほぼそのまま活かしたい場合。 |
| リソースのサブスクリプション間移動 | リソースグループや個別リソースを別サブスクへMove操作する。 | 同一テナント内のみ | 同じテナント内での再配置・リソース整理。 |
| 新テナントで再構築＋データ移行 | 新テナント側に環境を作り直し、データや設定を移行する。 | 当然可能 | 移管非対応サービス（AKS等）が多い、もしくは大幅な再設計を兼ねる場合。 |
| Azure Lighthouseによる委任管理 | 旧テナントにサブスクリプションを残したまま、新テナント側から管理権限のみ委任する。 | テナント跨ぎで管理可能 | 恒久的なマルチテナント運用、長期にわたる移行期間の暫定措置。 |
本記事では、もっともニーズが高い「サブスクリプションのディレクトリ変更」を中心に解説しつつ、併用候補となる「再構築＋データ移行」「Azure Lighthouse」の位置付けも補足します。
事前準備：影響調査と前提条件チェック
ディレクトリ変更は「クリック数」だけで言えばそれほど多くありませんが、事前準備を怠ると本番でサービスダウンやデータアクセス不能を招きます。ここでは特に重要な観点を整理します。
必ず棚卸ししておきたい対象
まずは、以下の観点で「テナント依存度」を洗い出します。
- RBAC（ロール割り当て）
- ユーザー／グループ／サービスプリンシパルに対するロール割り当て。
- リソースグループ単位、リソース単位で設定している権限も含めて一覧化します。
- カスタムロール
- テナント配下に定義されるため、ディレクトリ変更では引き継がれません。
- JSON定義をエクスポートし、新テナントで再登録する必要があります。
- マネージドID（Managed Identity）
- システム割り当て・ユーザー割り当て問わず、テナントのID基盤に紐付きます。
- ディレクトリ変更後、再有効化や作り直しが必須です。
- Key Vaultとアクセス制御（アクセス ポリシー／RBAC）
- Azure SQL / MySQL / PostgreSQLなどでのEntra認証
- Azure Kubernetes Service (AKS)（移管不可。再構築対象）
- Azure Policy／Azure Databricks／Dev Box／Deployment Environments／Entra Domain Servicesなど
これらのサービスは、テナントやIDとの結び付きが強く、移行計画の「山場」になります。
前提条件チェックリスト
| チェック項目 | 内容 |
|---|---|
| CSPサブスクリプションではない | 一部のCSP提供サブスクリプションはディレクトリ変更がサポートされません。提供形態を事前に確認します。 |
| 課金アカウントの所有者である | サブスクリプションを移管するには、課金契約の所有者権限が求められるケースがあります。 |
| サブスクリプションのOwnerロールが「直接割り当て」されている | グループ経由やPIM経由の権限ではディレクトリ変更操作ができない場合があります。自分自身に直接Ownerロールを付与しておきます。 |
| 移行操作ユーザーが両テナントに存在する | 同じアカウント（UPN）が、元テナント／先テナントの両方に存在している必要があります。 |
| ダウンタイム方針が決まっている | 業務影響の許容範囲に応じて、完全停止・部分停止・ゼロダウンタイムのどこを目指すかを決めておきます。 |
暗号化とKey Vault依存リソースへの注意
以下のような「Key Vaultベースの暗号化／シークレット参照」を行っているリソースは、特に慎重な計画が必要です。
- ディスク暗号化（Azure Disk Encryption）でKey Vaultを利用しているVM
- ストレージアカウントのカスタマー管理キー（CMK）
- DB（Azure SQLなど）のTransparent Data EncryptionでKey Vaultのキーを利用しているケース
- App ServiceやFunctionsなどでKey Vault参照（
@Microsoft.KeyVault()）を利用している構成
Key Vault側のテナントやアクセス ポリシーが変わると、暗号化キーにアクセスできず復旧不能になるリスクがあります。事前に以下のような対応を検討します。
- 一時的にプラットフォーム管理キー（Microsoft管理キー）へ切り替える
- 新テナント側にKey Vaultを複製し、移行後に参照先を切り替える手順を用意する
- テスト環境で「ディレクトリ変更 → Key Vault関連の再設定」を必ずリハーサルしておく
Azureポータルで行うサブスクリプションのディレクトリ変更手順
ここからは、Azureポータルを使った具体的な操作の流れを確認します。
操作の全体像
- 事前準備とバックアップ
RBAC／カスタムロール／Key Vault設定／マネージドIDなどをエクスポートし、影響範囲を整理します。 - Azureポータルでサブスクリプションのディレクトリ変更を実行
対象サブスクリプションの「ディレクトリの変更」を行います。 - 移管後の再構成作業
RBACの再付与、カスタムロールの再登録、マネージドIDの再作成、Key Vault設定の再構成などを行います。 - 動作確認と移行完了宣言
監視・アプリログを確認し、想定した通りに動いていることを確認してから切り替え完了とします。
ディレクトリ変更の実操作
Azureポータルでの代表的な操作手順は次の通りです。
- 元テナント側でAzureポータルにサインインします。
- 「サブスクリプション」ブレードを開き、移行対象のサブスクリプションを選択します。
- 上部メニューまたは設定項目から「ディレクトリの変更」を選択します。
- 移行先として表示されるディレクトリ（新テナント）一覧から、目的のテナントを選びます。
- 警告メッセージや影響範囲の説明を確認し、同意のうえで実行します。
- 処理が完了すると、サブスクリプションは新テナント側にぶら下がった状態になります。
課金所有権もあわせて別アカウントへ移したい場合は、「ディレクトリの変更」とは別に、課金所有権の譲渡手続きが必要になるケースがあります。組織内の経理／情報システム部門と事前に合意しておきましょう。
ディレクトリ変更で裏側では何が起こるか
ディレクトリ変更時には、次のようなことが起こります。
- サブスクリプション配下のリソース自体はそのまま（同じリソースID・同じリージョン）で、新テナントに紐付きます。
- 旧テナントのユーザー／グループ／サービスプリンシパルに対するRBACロール割り当ては削除されます。
- 旧テナントに定義されていたカスタムロールは利用できなくなります。
- マネージドIDは無効化／再生成が必要になり、Key Vaultなどへのアクセス権も再定義が必要になります。
このため、ディレクトリ変更直後のサブスクリプションは「リソースはあるが、ほとんど誰も触れない」「アプリが認証エラーを起こす」といった状態になることが多く、その復旧計画をあらかじめ用意しておくことが重要です。
移管後に必要となる再構成作業
ここでは、ディレクトリ変更後にほぼ必ず必要になる再構成作業を整理します。
RBACとカスタムロールの再構成
事前に以下のようにAzure CLIでRBACとカスタムロールをエクスポートしておくと、移行後の再構成がスムーズです。
# サブスクリプション一覧の確認
az account list --output table
# 対象サブスクリプションの選択
az account set --subscription "<対象サブスクリプション名>"
# RBAC（ロール割り当て）の保存
az role assignment list --all --include-inherited --output json > roleassignments.json
# カスタムロールの保存（全カスタムロール）
az role definition list --custom-role-only true --output json > custom_roles.json
# 特定のカスタムロールのみ保存したい場合
az role definition list --name "<CustomRoleName>" --output json > customrolename.json
移行後は新テナント側で、次のような流れでRBACを再構成します。
- 新テナント側で、必要な管理者／運用者用のグループを作成します。
- 旧テナントで使っていたカスタムロール定義（JSON）を、新テナントのサブスクリプションに対してインポートし、ロールを再作成します。
- roleassignments.jsonを元に、どのリソースにどのロールを割り当てていたかを確認し、新テナントのユーザー／グループ／SPNに対して再割り当てを行います。
この作業は手作業だとミスが起きやすいため、可能であればスクリプト化したり、重要なプロジェクトについては「事前にマッピング表（旧テナントのID → 新テナントのID）を作る」などの工夫をすると安全です。
マネージドID（Managed Identity）の再作成・再設定
マネージドIDはテナントのID基盤に強く依存しているため、ディレクトリ変更後は次の対応が必要です。
| 種類 | 状態 | 必要な対応 |
|---|---|---|
| システム割り当てマネージドID | ディレクトリ変更により無効化される／再有効化が必要 | 各リソース（VM、App Service等）のマネージドIDを再度「オン」にする。 新しく払い出されたIDに対して、Key Vaultや他リソースへのアクセス権を再設定する。 |
| ユーザー割り当てマネージドID | 旧テナントに属するためそのままでは利用不可 | 新テナント側で同名（または別名）のユーザー割り当てマネージドIDを作成し直す。 各リソースに対して、新しいユーザー割り当てマネージドIDを再アタッチする。 |
マネージドIDは多くの環境でKey VaultやStorage、Databasesへの認可に使われているため、ここを再設定しないとアプリケーションが一斉にエラーを吐くこともあります。優先度高めで再構成しましょう。
Key Vaultと暗号化キーの再設定
Key Vaultには次のようなポイントがあります。
- Key Vault自体のテナントIDや、アクセス ポリシー／RBACの設定は、ディレクトリ変更に伴い見直しが必要です。
- Key Vault内のシークレットやキー自体はそのままでも、それにアクセスするID（ユーザー／SPN／マネージドID）が変わるため、アクセス許可の付け直しが必要です。
- Key VaultをCMKとして利用しているリソース（ディスク、DB、ストレージなど）は、新しいテナントのID体系に合わせて、キーの参照設定を更新する必要があります。
Key Vaultに依存するリソースは、「一度に全部切り替える」のではなく、サービスごとに計画的に切り替えるほうが安全です。可能であれば、次の順序で進めるとよいでしょう。
- Key Vaultのアクセス制御を新テナント側IDに合わせて再設定する。
- 影響の小さいリソースから、CMK・シークレット参照の切り替えを試す。
- ログ・監視でエラーが出ていないかを確認しながら、重要システムの設定を切り替えていく。
Entra認証DB・AKS・その他サービスの注意点
- Azure SQL / MySQL / PostgreSQLなどのEntra認証
- DBに紐付く「Azure AD管理者」設定や、DBレベルのユーザー／ロールは旧テナントのIDに依存しています。
- ディレクトリ変更後は、新テナント側のユーザー／グループを使って再構成する必要があります。
- AKS（Azure Kubernetes Service）
- AKSクラスターはディレクトリ変更の対象外です。
- 別テナントへの移行では、新テナント側でクラスターを作り直し、マニフェスト・コンテナイメージ・シークレットを移行するのが基本方針になります。
- Azure Policy、Azure Databricks、Dev Box、Deployment Environments、Entra Domain Servicesなど
- 多くの場合、再デプロイまたは再割り当てが必要です。
- ポリシー定義やノートブックなど、エクスポート可能なものは事前にバックアップしておきましょう。
CI/CDパイプラインとシークレットの差し替え
最後に見落とされがちなのが、CI/CDパイプラインや各種開発ツールとの連携部分です。
- Azure DevOpsのサービス接続（Service Connection）
- GitHub Actionsなどで利用しているAzureへの接続用シークレット
- アプリケーション構成にハードコードされているクライアントID／テナントID／シークレット
これらは、ディレクトリ変更後にはすべて新テナントの値へ差し替える必要があります。「どこにID／シークレットを埋め込んでいるか」を一覧化し、確実に更新しましょう。
サブスクリプション移管が使えない／向かないケースと代替案
移管非対応のサブスクリプション種別
一部のサブスクリプション（特にCSPパートナー経由提供など）は、ポータルの「ディレクトリの変更」が利用できません。対象外のサブスクリプションでは、次のような代替プランを検討します。
- 新テナント側で新たなサブスクリプションを発行し、再構築＋データ移行を行う。
- 旧テナントにサブスクリプションを残したまま、Azure Lighthouseで新テナントから管理委任する。
Azure Resource Moverの限界
名前から誤解されがちですが、Azure Resource Moverはリージョン間移動（例：東日本→西日本）に特化したサービスであり、サブスクリプション／テナントを跨いだ移動には対応していません。テナント移行の解としては使えない点に注意が必要です。
Azure Lighthouseを用いた並行運用
テナント統合の初期フェーズや、グループ会社を跨ぐ運用では、「いきなりサブスクリプションを移管せず、管理だけ新テナントから行いたい」というニーズもあります。この場合はAzure Lighthouseが有力な選択肢になります。
- 旧テナントにサブスクリプションを残したまま、新テナント側の管理者に対して特定のロールを委任できます。
- 運用チームは新テナント側に集約しつつ、実際のリソースは当面そのまま旧テナントに置くといった構成が可能です。
最終的にサブスクリプション移管や再構築をするにしても、「移行前後での並行運用を支える仕組み」としてLighthouseを活用すると、リスク分散に役立ちます。
実務で役立つAzure CLIの活用例
先ほどRBACのエクスポート例を紹介しましたが、実際の現場では「とにかく状況を可視化する」ことが重要です。代表的なコマンドをいくつか挙げます。
サブスクリプション配下のリソース一覧を取得する
# サブスクリプション内の全リソースを一覧表示
az resource list --subscription "<対象サブスクリプションID>" --output table
# リソースグループごとにまとめて確認したい場合
az resource list --subscription "<対象サブスクリプションID>" --output json > resources.json
resources.jsonをスプレッドシートなどで整理し、どのサービスがどの程度Key VaultやマネージドIDに依存しているかを分析しておくと、移行計画が立てやすくなります。
Key Vaultのアクセス制御とシークレットを確認する
# Key Vaultのアクセス ポリシー確認
az keyvault show --name "<KeyVault名>" --query "properties.accessPolicies"
# Key Vault内のシークレット一覧
az keyvault secret list --vault-name "<KeyVault名>" --output table
どのシークレットがどのアプリやサービスに使われているかを紐付けておくことで、移行後のトラブルシュート時間を大幅に減らせます。
最小チェックリストとプロジェクト計画のコツ
最後に、「これだけは外せない」という最低限のチェックポイントをまとめます。
| チェック項目 | 説明 |
|---|---|
| CSPサブスクリプションではない | 提供形態によってはディレクトリ変更自体が不可。事前に必ず確認する。 |
| 課金所有者・サブスクリプションOwnerを保有 | ディレクトリ変更に必要な権限が適切なユーザーに直接割り当てられている。 |
| 両テナントに同一ユーザーアカウントが存在 | 移行操作を担当するユーザーが、元テナント・先テナント両方に存在している。 |
| 影響対象の棚卸し完了 | RBAC／マネージドID／Key Vault／Entra認証DB／AKSなどの依存関係を洗い出している。 |
| RBAC再配布・シークレット差し替え計画あり | 誰にどのロールを再付与するか、各アプリのシークレット・IDをどう差し替えるかが決まっている。 |
| ダウンタイムとロールバック手順が決まっている | どの時間帯に切り替え、問題が起きたらどう戻すかを事前に文書化している。 |
プロジェクトとして進める際は、以下のようなフェーズ分けをすると進めやすくなります。
- 調査フェーズ：棚卸し・依存関係の洗い出し・キー／シークレットの確認
- 設計フェーズ：ディレクトリ変更の対象／タイミング決定、再構成手順書の作成
- 検証フェーズ：開発・検証サブスクリプションで一連の流れをリハーサル
- 本番移行フェーズ：計画した手順に沿って本番切り替え実施
- 安定化フェーズ：監視やログを見ながら微調整し、移行完了報告まで行う
よくある質問とアンチパターン
Q. 一旦ディレクトリ変更したあと、すぐ元に戻せる？
A. 技術的には再度別テナントへディレクトリ変更を行うことは可能ですが、RBACやID、Key Vaultの設定を再度やり直すことになるため、軽い気持ちで往復させるべきではありません。必ず検証環境で手順を固めたうえで、本番移行は一方向に進める前提で計画しましょう。
Q. リソースグループ単位で別テナントに移せない？
A. できません。リソースグループや個別リソースのMove操作は、同一テナント内のサブスクリプション間移動のみサポートされています。テナントを跨ぐ場合は、サブスクリプションごと移すか、新テナントで再構築＋データ移行のパターンになります。
Q. すべてのサービスに対してゼロダウンタイムで移行できる？
A. サービス構成や要件によりますが、完全なゼロダウンタイムを全システムで実現するのは現実的ではないケースが多いです。特にKey VaultやDBの認証方式を切り替える場面では、短時間の接続エラーや再起動が避けられないことがあります。重要度の高いシステムほど、ダウンタイムをいつ・どの程度許容するかを事前にビジネス側と合意しておくことが重要です。
まとめ：別テナントへのAzureサブスクリプション移行のポイント
- 別テナントへの移行は「サブスクリプション単位のディレクトリ変更」が基本パターンです。
- ただし、RBAC／カスタムロール／マネージドID／Key Vaultアクセス制御など、ID・権限まわりは引き継がれないため、移行後の再構成が必須です。
- AKSなど一部サービスは移管不可のため、再構築＋データ移行の計画も並行して検討する必要があります。
- Azure Resource Moverはテナント跨ぎには使えず、管理の集約にはAzure Lighthouseが有効なことを覚えておきましょう。
- 成功のカギは、事前の棚卸し・影響調査と、手順書レベルまで落とし込まれた計画にあります。
「別テナントへはサブスクリプションごと移す。その代わり、権限やIDの再構成が移行作業の肝になる」という前提をチームで共有し、十分な検証と準備を行えば、ディレクトリ変更は十分に安全に実施できます。本記事をベースに、自社環境に合わせた具体的な手順書へ落とし込んでいってください。
コメント