Microsoft 365 / Google Workspace テナント分離ガイド｜事業譲渡・スピンオフ時のIT環境分割の進め方
テナント分離とは
テナント統合（複数のテナントを1つにまとめる）が「M&Aの買い手」のテーマであるのに対し、テナント分離は「売り手」や「スピンオフを行う企業」のテーマです。
テナント分離が必要になる典型的な場面として、事業譲渡（自社の一部門を他社に売却する場合）、会社分割・スピンオフ（子会社や事業部門を独立させる場合）、グループ会社の独立（持株会社傘下の事業会社を分離する場合）があります。
いずれのケースでも、「1つのテナントで管理していたユーザー・データ・ドメインの一部を切り出して、別のテナントに移す」作業が必要になります。テナント統合と比べて情報が少なく、手順も複雑なため、計画的に進める必要があります。
テナント統合との違い
テナント統合は「2つを1つにする」作業ですが、テナント分離は「1つを2つに分ける」作業です。一見似ていますが、分離特有の難しさがあります。
データの仕分けが必要な点が最大の違いです。統合は「全部持っていく」のに対し、分離は「どのデータを誰に渡すか」を仕分ける必要があります。共有されているファイル、全社配布リストのメンバー、共有メールボックスなど、「境界があいまいなデータ」の扱いが複雑です。
共存期間中のアクセス制御も難題です。分離完了まで両者が同じテナントで作業するため、「見せてはいけないデータ」の制御が必要になります。
タイムラインが契約で決まることも多いです。事業譲渡契約で「クロージング後3ヶ月以内にIT環境を分離する」と定められているケースが多く、統合以上にスケジュールのプレッシャーがかかります。
Microsoft 365 テナント分離の手順
Phase 1：分離計画（2〜4週間）
まず、分離の対象範囲を確定します。
対象ユーザーの確定として、分離対象の部門・社員のリストを作成します。部門横断で仕事をしていたメンバーや、兼務者の扱いを明確にしてください。
データの仕分け基準の策定として、個人のメールボックス・OneDriveは原則ユーザーに紐づけて移動、SharePointサイトは部門単位で判断、共有メールボックス・配布リストは利用実態を確認して分配先を決定します。
ドメインの扱いを決定します。分離先が独自ドメインを新規取得するか、既存ドメインの一部を移管するかを確定します。
新テナントの準備として、分離先企業用のM365テナントを新規作成し、ライセンスを購入します。
Phase 2：環境準備（2〜4週間）
新テナント側のM365環境を構築します。
新テナントのセットアップとして、組織情報の設定、セキュリティポリシー（MFA、条件付きアクセス等）の設定、グループ・配布リストの作成を行います。
ドメインの追加として、分離先が使用するドメインを新テナントに追加します。ドメインの移管は、DNSの切り替えタイミングに注意が必要です。現テナントからドメインを削除してから新テナントに追加する順序になるため、一時的にメール受信ができなくなる期間が発生します。この作業は夜間や週末に実施してください。
並行運用期間中のメール転送として、ドメイン切り替え前の移行期間中、旧テナントから新テナントへのメール転送ルールを設定し、メールの不達を防ぎます。
Phase 3：データ移行（2〜8週間）
対象ユーザーのデータを新テナントに移行します。
メールボックスの移行として、移行ツール（BitTitan MigrationWiz、AvePoint FLY等）を使って、対象ユーザーのメールボックスを新テナントにコピーします。過去メール・カレンダー・連絡先が対象です。
OneDriveデータの移行として、個人のOneDriveデータを新テナントのOneDriveに移行します。共有リンクは移行後に無効になるため、事前に棚卸しが必要です。
SharePointサイトの移行として、分離対象部門が使用していたSharePointサイトを新テナントに移行します。サイト内のファイル、リスト、権限設定をまとめて移行しますが、ワークフロー（Power Automate）やカスタマイズ部分は個別対応が必要です。
Teamsの移行として、Teamsのチームとチャネルの移行は最も複雑な領域の一つです。チャット履歴の完全移行はMicrosoft標準ツールでは困難なため、移行ツールの利用または「アーカイブして新テナントで再作成」のアプローチを選択します。
Phase 4：切り替え・旧テナントのクリーンアップ（1〜2週間）
DNSの切り替えとして、MXレコード、SPF/DKIM/DMARC、その他DNSレコードを新テナント向けに変更します。
旧テナントのクリーンアップとして、分離対象ユーザーのアカウントを旧テナントから削除（または無効化）します。共有リソース（共有メールボックス、配布リスト等）から分離対象メンバーを削除します。旧テナントのライセンス数を調整し、不要なライセンスを解約してコストを最適化します。
Google Workspace テナント分離の手順
GWSのテナント分離もM365と基本的な流れは同じですが、いくつかのGWS固有の注意点があります。
Google Driveの共有構造として、GWSのDriveは「マイドライブ」と「共有ドライブ」で構成されます。共有ドライブのオーナーシップの移管が必要になります。
Googleドキュメントの共有として、Googleドキュメント・スプレッドシート・スライドは共有リンクベースで広く共有されていることが多く、分離後にアクセスできなくなるファイルの棚卸しが重要です。
Google Groupsの分割として、全社グループやクロスファンクショナルなグループからメンバーを適切に分離する必要があります。
GWS管理コンソールの権限として、分離作業中は両社の管理者が協力して作業する必要がありますが、権限の範囲を適切に制限してください。
データ移行にはGoogle Workspace Migrate（Google公式の移行ツール）またはサードパーティツールを使用します。
テナント分離で特に注意すべきポイント
共有データの「境界線問題」
最も難しいのは、「どちらに属するかあいまいなデータ」の扱いです。両部門が共同で使っていたSharePointサイトやGoogleの共有ドライブ、全社配布リストに含まれる分離対象メンバー、両社にまたがるPower Automateフローなどが該当します。
これらは技術的に解決する前に、ビジネス側の判断（「このデータはどちらのものか」）が必要です。IT部門だけでは決められないため、事業部門の責任者を巻き込んだ判断プロセスを設けてください。
ライセンスコストの増加
1つのテナントを2つに分けると、ライセンスコストは基本的に増加します。ボリュームディスカウントの適用が外れる場合がある、両テナントにそれぞれ管理者ライセンスが必要、セキュリティツール（Defender等）のライセンスも別途必要になるためです。分離後のライセンスコストを事前に試算し、事業譲渡の価格交渉に反映させることを推奨します。
SaaS連携の再設定
現テナントとSSO連携しているSaaSアプリがある場合、分離対象ユーザーのSSO設定を新テナント側で再構築する必要があります。SaaS側の設定変更も必要なため、各SaaSベンダーとの調整を早めに開始してください。
法的・契約上の期限
事業譲渡契約でIT分離の完了期限が定められている場合、その期限に間に合わせるスケジュールを逆算で設計してください。技術的に理想的なスケジュールと契約上の期限が合わない場合は、優先度の高い領域（メール・認証）を先行で分離し、残りは期限後に段階的に進めるアプローチも検討します。
まとめ
テナント分離は、テナント統合と比べて「データの仕分け」「共有リソースの分割」「タイムラインのプレッシャー」という追加の複雑さがあります。事業譲渡やスピンオフが決まった段階で、早めにIT分離の計画に着手することが重要です。
特に共有データの境界線問題は、技術的な解決の前にビジネス判断が必要な領域です。IT部門だけで抱え込まず、事業部門の責任者と連携しながら進めてください。
情シス365では、テナント分離を含むM&A関連のIT統合・分離プロジェクトを専門的にサポートしています。事業譲渡やスピンオフに伴うIT分離のご相談は、お早めにご連絡ください。