企業分割やカーブアウトで、親会社の EA（エンタープライズ契約）配下にある Azure サブスクリプションを、新会社の従量課金（PAYG）へ移したい――このとき、多くの担当者を悩ませるのが「できるだけ止めずに移せるのか」「再構築は避けられるのか」というポイントです。本記事では、EA→PAYG の制約と、現実的かつダウンタイムを最小化しやすい移行パターンを、実務目線で整理します。
EA から PAYG への Azure サブスクリプション移管で押さえるべき前提
まず最初に、今回の議題である「EA 配下のサブスクリプションを、新会社の従量課金（PAYG）へ移したい」という要件を、もう少し構造的に分解しておきます。
よくあるシナリオ：企業分割・カーブアウト
典型的な背景は次のようなものです。
- 親会社は長年 Azure EA を利用しており、複数の業務システムが EA 配下サブスクリプションで稼働している。
- グループ再編により、特定の事業を切り出して新会社を設立。
- 新会社は独立した Microsoft Entra ID テナントと、独自の請求（PAYG）を持ちたい。
- しかし、システムの再構築や長時間停止は避けたい。
このとき、次のような質問が必ず出てきます。
- EA 配下サブスクリプションを、そのまま新会社の PAYG に「請求所有権だけ」移せないか？
- もしダメなら、どのようなステップを踏めば、停止を極力抑えて移行できるのか？
結論：EA → PAYG の「直接」請求移管はできない
最初に押さえるべきポイントはシンプルです。
- EA → PAYG への “直接” の請求所有権移管はサポートされていない。
そのため、次のような二段階（＋必要に応じて三段階目）で進めるのが現実的かつ安全です。
- 親会社テナント内で EA → PAYG（課金体系の変更）
対象サブスクリプションの請求先を、親会社側の PAYG（Microsoft アカウント / MCA など）に切り替える。 - PAYG サブスクリプションを新会社テナントへ「ディレクトリ変更」
サブスクリプションを丸ごと、新会社の Microsoft Entra ID テナントへ移す。 - 必要に応じて、PAYG → PAYG の請求所有権移管
新会社が最終的に管理したい請求アカウントへ、Billing Transfer を実施する。
ポイントは、「サブスクリプション単位で動かす」ことです。リソース単位のコピーや再構築を避けられるため、全再構築に比べると大幅にリスクと工数を抑えられます。
EA と PAYG の違いをざっくり整理
なぜ EA → PAYG の直接移管が難しいのかを理解するために、両者の特徴を簡単に比較しておきます。
| 項目 | EA（エンタープライズ契約） | 従量課金（PAYG） |
|---|---|---|
| 契約主体 | 企業と Microsoft との包括契約 | 個別のアカウント単位（MCA やクレジットカードなど） |
| 課金の集約 | 部門ごとに集計できるが最終的には EA 契約単位で集計 | 請求アカウントごとに課金。企業・個人いずれもあり得る |
| 契約の柔軟性 | 契約期間・最低利用額などの条件がある | 柔軟だが割引は EA ほどではないケースもある |
| サブスクリプションの位置づけ | EA 契約配下にぶら下がる | PAYG の請求アカウント配下にぶら下がる |
| 企業分割時の取り回し | 親 EA から切り出しにくい | テナントや請求アカウントを分けて独立させやすい |
この構造の違いがあるため、「EA のまま新会社へ引き渡す」のではなく、「PAYG に変換したうえでテナント移管する」というステップが必要になります。
推奨パターン：PAYG 化 → ディレクトリ変更 →（必要に応じて）PAYG 間請求移管
ここからは、実際にどう進めるかをもう少し詳しく解説します。
ステップ 1：親会社テナント内で EA → PAYG 化する
最初のステップは、「対象サブスクリプションの請求先を親会社の PAYG に変更する」ことです。
大まかな流れは次の通りです。
- 親会社の Azure／請求担当と合意し、対象サブスクリプションを特定。
- EA 管理者・Billing 管理者が、サブスクリプションの請求先を PAYG 側に変更（または PAYG 契約へ所有権を移管）。
- この時点ではテナント（ディレクトリ）はまだ親会社のまま。リソースの停止は発生しない。
このステップは主に「請求レイヤー」の話なので、Azure リソースそのものには基本的に影響しません。ただし以下の点には注意してください。
- EA 側の予約（Reserved Instances / Savings Plans）やクレジットがどの程度使われているか。
- EA 経由の割引レベルから PAYG に変わることで、コストが一時的に変動しないか。
- 社内のコスト配賦ルール（部門コード等）に影響がないか。
| 確認項目 | 観点 |
|---|---|
| 予約インスタンスの利用状況 | EA の予約が大きい場合、新会社に移すとコスト増になる可能性 |
| 割引率 | EA 割引から PAYG 料金に変わるタイミングと影響額の試算 |
| 会計処理 | どの請求書まで親会社持ちとし、いつから新会社負担にするか |
ステップ 2：PAYG サブスクリプションを新会社テナントへ「ディレクトリ変更」
PAYG 化が完了したら、次はいよいよ 新会社の Microsoft Entra ID テナントへサブスクリプションを移管します。Azure ポータル上では「ディレクトリの変更」として実行する操作です。
ディレクトリ変更とは何か
Azure サブスクリプションは、「請求」と「ディレクトリ（テナント）」という二つの軸を持っています。ディレクトリ変更で動くのは後者だけです。
- 請求：どのアカウント・契約にお金が請求されるか。
- ディレクトリ：どの Microsoft Entra ID（旧 Azure AD）テナントのユーザー・アプリがそのサブスクリプションを使えるか。
今回のシナリオでは、次のような状態遷移になります。
| タイミング | ディレクトリ（テナント） | 請求（契約・アカウント） |
|---|---|---|
| Before | 親会社テナント（EA 配下） | EA 契約 |
| ステップ 1 後 | 親会社テナント | 親会社の PAYG（MCA 等） |
| ステップ 2 後 | 新会社テナント | 請求はまだ親会社の PAYG（または合意したアカウント） |
| ステップ 3 後（任意） | 新会社テナント | 新会社の PAYG 請求アカウント |
ディレクトリ変更自体は、原則としてリソースをそのまま保ったまま実行できます。ただし後述するように、テナントに紐づく情報（ID、RBAC、バックアップなど）は大きく影響を受けるため、事前の棚卸しと準備が必須です。
ステップ 3：PAYG 同士での請求所有権移管（必要な場合のみ）
最後に、請求そのものを新会社側の PAYG アカウントへ移したい場合、PAYG→PAYG の Billing Transfer を行います。
- Azure リソースやテナントはステップ 2 までで新会社側に移っている。
- 残るのは「請求書を誰が受け取るか」というお金の話のみ。
このステップは運用面・会計面の整理であり、Azure リソースへの影響は限定的です。ただし、社内の稟議・承認プロセスに時間がかかることが多いので、早めに経理部門とすり合わせておきましょう。
テナント間移管での「落とし穴」と対策
ここからは、実際にディレクトリ変更・テナント移管を行う際にハマりがちなポイントを整理します。
サービス・機能ごとの移動可否チェック
まず最優先で行うべきは、「このサービスはテナント間でそのまま移せるのか？」の棚卸しです。代表的な例を表にまとめます。
| サービス / 機能 | テナント間移管 | 注意点 / 推奨アクション |
|---|---|---|
| Azure AD DS（ドメインサービス） | 不可 | 新テナントで再構築が必要。ドメイン名・OU 構造・ユーザー同期の再設計を行う。 |
| Azure Backup / Recovery Services Vault | 不可 | テナントを跨いで移動できない。バックアップ停止 → 登録解除 → 新テナント側でボールト再構築とバックアップ再設定。 |
| Azure Site Recovery（ASR） | 制約あり | レプリケーション関係を張り直す必要があるケースが多い。メンテナンスウィンドウ中に切替手順を設計。 |
| ユーザー割り当てマネージド ID | 不可 | テナントに属するリソースのため、新テナントで再作成。依存するリソースの権限再付与が必要。 |
| システム割り当てマネージド ID | リソース自体は移動可 | 有効化し直すと ID が変わる。Key Vault やストレージなどのアクセス許可を再設定。 |
| Key Vault | 移動可（リソース自体） | アクセス主体（ユーザー・グループ・SPN・MI）が全て変わるため、RBAC / アクセスポリシーの再定義が必須。 |
| AKS の AAD 連携 | 構成変更が必要 | 新テナントのアプリ登録・グループを使って再連携。ClusterRoleBinding 等の見直しも必要。 |
| Enterprise Applications（ギャラリーアプリ） | 再同意が必要 | SaaS 側との接続情報も含めて、再同意・再連携が必要。事前に一覧化して関係者と調整。 |
| Azure DevOps 連携（Service Connection など） | 再作成が必要 | 紐づくサービスプリンシパルが変わるため、Service Connection を新しい SPN で再作成。 |
| Managed HSM | 要注意 | 移行制約が厳しいため、再構築を前提とした設計を検討。 |
| クラシック（ASM）リソース | 要注意 / 非推奨 | 可能であれば ARM へのモダナイズを先に行い、そのうえで移行計画を立てる。 |
上記はあくまで代表例です。実際には、全リソースを棚卸しし、「移せるもの」「再構築が必要なもの」をラベリングする作業が重要になります。
RBAC（ロール割り当て）はほぼ全てやり直しになる
ディレクトリ変更後、新会社テナントから見て、親会社テナントのユーザー・グループ・サービスプリンシパルは存在しないものとして扱われます。そのため、次のようなことが起こります。
- 既存のロール割り当ての principal（主体）が「不明なオブジェクト」 になる。
- リソースへの管理・運用権限が一時的に失われる危険がある。
- 自動化スクリプトや CI/CD からのデプロイが動かなくなる。
これを防ぐためには、次の手順を事前に設計しておきます。
- 新会社テナント側に、必要な管理者・運用者グループ・サービスプリンシパルを作成。
- ディレクトリ変更後、ただちに付与すべきロール（Owner、Contributor、User Access Administrator など）を一覧化。
- 可能であれば Azure Policy や管理グループ構成も、新テナント側に移植する計画を立てる。
| 主体 | 移行前の準備 | 移行後のアクション |
|---|---|---|
| 人間の管理者 | 新テナントでグループ設計（例：Infra-Admins） | サブスクリプション / RG に Owner または必要なロールを再付与 |
| CI/CD 用 SPN / MI | 新テナントでアプリ登録・MI を作成 | Key Vault、ストレージ、RG などへのロールを再付与 |
| 監視・運用ツール | 現行の接続方式を棚卸し | 接続先・認証情報を新テナントの ID に更新 |
マネージド ID とシークレット管理の再設計
マネージド ID は便利な反面、テナントに強く依存しているため、テナント間移行ではハマりどころになりがちです。
- システム割り当て MI：ディレクトリ変更をしてもリソース自体は移るものの、再有効化すると ID が変わるため、依存先のアクセス権を一斉に更新する必要があります。
- ユーザー割り当て MI：テナントに属するリソースなので、新テナントで作り直す前提で計画します。
- Key Vault：シークレットや鍵そのものは残せても、「誰がアクセスできるか」はゼロから再定義が必要です。
移行計画では、次のようなマッピング表を作っておくとスムーズです。
| 現行テナントの ID | 種別 | 新テナントでの対応 | 依存先 |
|---|---|---|---|
| vm-web-01 (System-assigned MI) | システム割り当て MI | 再有効化し、新 ID で権限付与し直し | Key Vault: kv-app-secrets, Storage: stlogs01 |
| mi-app-deploy | ユーザー割り当て MI | 新テナントで同名 MI を作成し、権限設定を移植 | App Service, ACR, Key Vault |
| spn-azdo-ci | サービスプリンシパル | 新テナントにアプリ登録を作成し、Azure DevOps の Service Connection を更新 | Azure DevOps パイプライン |
IP アドレスと DNS への影響
「サブスクリプションのディレクトリ変更」という操作は、基本的にはリソース構成や IP アドレスを変えません。そのため多くのケースで、アプリケーションのエンドポイントや外部公開 IP は維持されます。
ただし、次のようなケースでは IP やエンドポイントが変わり得るため注意が必要です。
- 非対応リソースを再作成する必要がある（例：ネットワーク系の特定 SKU）
- 移行に合わせて SKU を変更する（Standard → Premium 等）
- 旧構成からのリファクタリングを同時に行う
これらのケースでは、DNS レコードの切替手順が重要になります。
- 移行直前に DNS の TTL を短くしておく。
- 一時的に旧環境と新環境を並走させ、トラフィックを段階的に切り替える。
- 内部 DNS / Hosts ファイル / API Gateway の設定なども含めて網羅的に見直す。
課金・予約の扱い
EA の予約や Savings Plans は、基本的に「請求アカウント側の資産」として扱われます。そのため、次の点を整理しておきましょう。
- 予約がどのスコープ（共有 / 特定サブスクリプション）で適用されているか。
- 移管後のサブスクリプションにも、既存の予約を適用し続けるのか。
- 企業分割後に「誰のコストとして扱うか」が会計的に整理されているか。
新会社が完全に独立したコスト構造を持ちたい場合、移行後に新会社側で改めて予約購入を検討するケースも多いです。
必要な権限セットの整理
権限不足で作業が止まると、メンテナンスウィンドウを無駄にしてしまいます。最低限、次のロールが揃っているか事前確認しましょう。
- 元テナントの Microsoft Entra ID グローバル管理者
- 新テナントの Microsoft Entra ID グローバル管理者
- 対象サブスクリプションの Owner（＋ User Access Administrator）
- EA / PAYG 側の Billing Account Owner または同等の請求管理権限
| ロール | 必要な場面 |
|---|---|
| グローバル管理者（元テナント） | ディレクトリ変更前のアプリ登録・グループ確認、必要に応じた設定変更 |
| グローバル管理者（新テナント） | 新テナントでのアプリ登録作成、Enterprise Applications の再同意 |
| サブスクリプション Owner | ディレクトリ変更操作、RBAC の再付与、ポリシーやロールの設定 |
| Billing Account Owner | EA → PAYG への課金変更、PAYG → PAYG の請求所有権移管 |
最小ダウンタイムを狙うランブック例
ここまでの内容を踏まえた、実際の進め方の一例をステップベースでまとめます。実プロジェクトでは、これをベースに自社向けにカスタマイズしていくイメージになります。
ステップ 1：棚卸し（インベントリ）
- 対象サブスクリプション内の全リソースを一覧化。
- ID・ネットワーク・Key Vault・Backup・監視・CI/CD 連携など、「外部とのつながり」を重点的に洗い出す。
- Azure Resource Graph やタグを活用すると抜け漏れを減らせます。
ステップ 2：可搬性評価と再構築対象の特定
- 先ほどの表を参考に、「テナント間移管でそのまま動かせるか」をサービスごとに評価。
- 移管不可のものは「再構築」「移行ツール利用」など代替案を決定。
- 停止時間が大きくなりそうなワークロードは別途メンテナンス計画を立てる。
ステップ 3：権限・体制の整備
- 元／先テナントで必要なロールが揃っているか確認。
- メンテナンスウィンドウの候補日と関係者（インフラ・アプリ・業務部門）の連絡体制を準備。
- ロール付与の変更履歴を残すための手順（チケット管理など）も整える。
ステップ 4：親会社内で EA → PAYG 化
- EA 管理者と連携し、対象サブスクリプションを PAYG へ変更。
- 変更後の請求書の出力先・コストセンターなどを確認。
- このタイミングで、移行対象外のサブスクリプションとの切り分けも整理するとよいです。
ステップ 5：ディレクトリ変更（テナント移管）を実施
- 事前にバックアップやスナップショットを取得（影響度の大きいリソースは特に）。
- Azure ポータルもしくは API から、PAYG サブスクリプションのディレクトリを新会社テナントへ変更。
- 作業ログを残し、完了後にサブスクリプション所有者が新テナントのアカウントになっていることを確認。
ステップ 6：RBAC の再付与とガバナンス設定
- 新テナント側のユーザー／グループ／サービスプリンシパルへ、事前に定義したロールを一括付与。
- 管理グループ階層・Azure Policy・Blueprint 相当の仕組みを再設定。
- 間違って過剰な権限を付与しないよう、最小権限の原則を徹底します。
ステップ 7：ID／連携の復旧
- システム割り当て／ユーザー割り当て MI を再作成・再関連付け。
- アプリ登録・Enterprise Applications の再同意を実施。
- Azure DevOps・GitHub Actions・その他 CI/CD ツールのサービス接続・シークレットを新テナント情報に差し替え。
ステップ 8：データ保護と監視の再構成
- Backup・Site Recovery の再設定、テスト復元の実行。
- ログ収集（Log Analytics）、メトリクス、アラートルールを確認し、新テナントの ID に紐づけ直す。
- 監査ログ・アクティビティログの出力先ストレージや SIEM 連携も忘れずに更新。
ステップ 9：ネットワーク・アプリ検証
- Private Link、NSG、UDR、ロードバランサー、WAF など、ネットワーク構成が意図通り動作しているか確認。
- 必要に応じて DNS 切替や、アプリケーションレベルの疎通テストを実施。
- 業務部門と連携した受け入れテスト（UAT）を行い、影響がないことを確認。
ステップ 10：PAYG → PAYG の請求所有権移管（必要に応じて）
- 新会社側で用意した請求アカウントに対し、サブスクリプションの所有権を移管。
- 移管後の請求書フォーマット・通貨・支払い方法を確認。
- 社内の会計ルールに従い、どの月から新会社負担とするかを明文化。
ステップ 11：総合リグレッションテスト
- 高可用性（HA）構成が正しく機能しているか（フェールオーバーテスト含む）。
- 監査ログ・アクセスログが想定どおり取得できているか。
- セキュリティポリシー（CIS / NIST 等）に準拠しているか、スキャンツールでチェック。
ステップ 12：クリーンアップ
- 親会社側に残っている古い ID・DNS・資格情報を削除。
- 古いドキュメント（旧サブスクリプション ID・旧テナント ID など）をアーカイブ・更新。
- 運用マニュアル・オンボーディング資料も新テナント前提に更新して完了。
代替アプローチ：個別移動や再構築が向いているケース
ここまで紹介したのは「サブスクリプション単位で移す」アプローチですが、場合によっては次のような代替案のほうが適しているケースもあります。
個別リソース移動（同一テナント内の移動を組み合わせる）
まず、同一テナント内では Azure ポータルの「移動」や Move-AzResource コマンドを用いて、リソースグループ間・サブスクリプション間での移動が可能です。
- 同一テナント内であれば、対応しているリソースは比較的安全に移動可能。
- テナント間移行前に、構成を整理する目的でサブスクリプションを分割するのに有効。
- ただし、テナントを跨いでの直接移動は多くのサービスで非対応。
再構築＋データ移行を前提にする
サービスが多岐に渡り、かつ「これを機に構成を刷新したい」場合は、思い切って 再構築＋データ移行 を前提とした設計の方が結果的にスッキリすることもあります。
- IaaS / VM：Azure Migrate や Azure Site Recovery を用いて、段階的に VM を新サブスクリプション・新テナント側へ移行。
- PaaS データベース：Database Migration Service（DMS）、geo レプリケーション、バックアップ＆リストア、BACPAC などを組み合わせて移行。
- ストレージ：AzCopy、ストレージアカウント間レプリケーション、Data Factory などを利用してデータコピー。
デメリットとしては停止時間や切替作業が増えますが、老朽化した構成や技術的負債を一気に解消できるチャンスでもあります。どこまでを「移す」のか、どこからを「作り直す」のか、ビジネスと相談しながら線引きを行いましょう。
よくある疑問と考え方
Q. どうしても完全ノーダウンで移行したい場合は？
多くのシステムで、テナント間移管や ID 再構成に伴い、全くのノーダウンを実現するのはかなり難度が高いです。現実的には、次のような方針でダウンタイムを最小化することを目指します。
- システムごとに「許容ダウンタイム」を整理し、優先度・クリティカル度でグルーピング。
- 読み取り系はレプリカを活用して新環境を先に立ち上げ、切替時の影響を最小化。
- 書き込み系はバッチ停止時間やメンテナンス時間を確保し、リプレイ戦略を検討。
Q. 新会社テナント側の設計はいつやるべき？
「サブスクリプションを移してから考える」ではなく、新会社テナント側の ID・セキュリティ・ネットワーク設計を先に固めるのが理想です。
- テナント・サブスクリプション構成（ランディングゾーン）の設計。
- ロールベースアクセス制御（RBAC）の設計。
- ネットワーク（Hub-Spoke、オンプレ接続、名前解決）の基本方針。
- ログ収集・監査・セキュリティモニタリングのポリシー。
先に「土台」を作っておけば、移管してきたサブスクリプションをスムーズに組み込めます。
Q. EA 契約は完全にやめるべき？
企業グループ全体としては、EA 契約を継続利用するメリットは依然として大きいケースが多いです。重要なのは、独立性が求められる新会社部分だけを PAYG に切り出す設計をとることです。
- グループ全体の共通基盤は EA 配下で維持。
- 独立したガバナンス・会計が必要な新会社は PAYG・独自テナントで運用。
- 将来的な再編や買収を見据えて、サブスクリプション設計に「切り出ししやすさ」を組み込む。
まとめ：EA → PAYG → テナント移管が「本命パターン」
本記事のポイントを改めて整理します。
- EA → PAYG への直接の請求所有権移管は不可であり、現実的には
- 親会社内での PAYG 化
- PAYG サブスクリプションのディレクトリ変更による新会社テナントへの移管
- 必要に応じた PAYG → PAYG の請求所有権移管
- サブスクリプション単位で移せば、リソース個別の再構築を大幅に減らせる一方で、RBAC / ID / Backup / 連携の再設定が最大のハマりどころになります。
- 移行前には、サービスごとの移動可否を棚卸しし、「移せるもの」「再構築するもの」「この機会に刷新するもの」を明確にしておくことが重要です。
- 完全ノーダウンを目指すよりも、ビジネスと合意したうえで「許容できる最小ダウンタイム」を設計し、その範囲で堅実に移行する方が現実的です。
企業分割やカーブアウトにおける Azure の移行は、技術だけでなく契約・会計・組織ガバナンスが密接に絡み合うプロジェクトです。早い段階から情報システム部門・経理・法務・現場システム担当が一体となって計画を立て、「PAYG 化 → テナント移管」を軸にしたシンプルな構成を保つことで、リスクとコストを最小限に抑えた移行が実現しやすくなります。
コメント