テナント統合とは？ ― 必要になる場面と全体の流れ
「テナント統合」──M&Aや組織再編を経験した企業のIT担当者であれば、一度は耳にしたことがある言葉でしょう。しかし、具体的に何をするのか、どこまでが範囲なのか、全体像を把握している人は多くありません。
本記事では、テナント統合の基本概念と、統合が必要になる場面、プロジェクト全体の流れを解説します。
テナントとは何か
Microsoft 365やGoogle Workspaceにおける「テナント」とは、1つの組織が利用するクラウド環境の単位です。
Microsoft 365のテナント
- Entra ID（旧Azure AD）のディレクトリ
- Exchange Online（メール）、SharePoint Online、OneDrive、Teamsなど全サービスの基盤
contoso.onmicrosoft.comのようなデフォルトドメイン + カスタムドメイン- ユーザーアカウント、グループ、セキュリティ設定のすべてがテナントに紐づく
Google Workspaceのテナント
- Google Admin Console で管理される組織単位
- Gmail、Google Drive、Google カレンダーなどの基盤
- プライマリドメインとセカンダリドメイン
- OU（組織単位）構造、ユーザー、グループ
テナントは組織の「デジタルな器」であり、日常業務のほぼすべてがこの器の上で動いています。
テナント統合が必要になる場面
M&A（合併・買収）
最も多いケースです。買収元と買収先がそれぞれ別のテナントを持っており、統合が必要になります。
- 買収元：Microsoft 365テナント、買収先：別のMicrosoft 365テナント
- 買収元：Microsoft 365、買収先：Google Workspace（クロスプラットフォーム）
- グループ会社間の統合
組織再編・分社化
持株会社化やカーブアウト（事業切り出し）に伴い、テナントの分割や統合が発生します。
テナントの乱立解消
過去の経緯で複数のテナントが存在し、管理が煩雑になっているケースです。事業部ごとに別テナントを契約してしまった、海外拠点が独自にテナントを作った、といった状況です。
プラットフォーム移行
Google WorkspaceからMicrosoft 365へ（またはその逆）、組織全体でプラットフォームを切り替える場合もテナント統合と同様の作業が発生します。
テナント統合の対象範囲
テナント統合で移行・統合が必要なデータと設定は多岐にわたります。
ユーザーとアカウント
- ユーザーアカウント（表示名、UPN / メールアドレス、属性情報）
- セキュリティグループ、配布グループ、Microsoft 365グループ
- ライセンスの割り当て
- MFA設定（再登録が必要になるケースが多い）
メール
- メールボックスの全データ（受信トレイ、送信済み、フォルダ構造）
- メールルール、自動応答設定
- 共有メールボックス、リソースメールボックス（会議室など）
- 配布リスト、動的配布グループ
- メールフロールール（トランスポートルール）
ファイル
- OneDrive for Business / Google Drive の個人ファイル
- SharePoint Online サイト / Google 共有ドライブ
- ファイルのアクセス権限、共有リンク
- バージョン履歴
コラボレーション
- Microsoft Teams のチーム、チャネル、チャット履歴
- Google Chat のスペース
- SharePoint サイト / Google Sites
- Planner / Google Tasks のタスク
セキュリティと管理設定
- 条件付きアクセスポリシー
- DLP（データ損失防止）ルール
- MDM / MAM ポリシー（Intune）
- 監査ログの保全
- コンプライアンス設定（保持ポリシー、eDiscovery）
ドメインとDNS
- カスタムドメインの移管
- MXレコード、SPF / DKIM / DMARC 設定
- 自動検出（Autodiscover）レコード
テナント統合プロジェクトの全体フロー
テナント統合は一般的に以下の6フェーズで進みます。
Phase 1：判断（2〜4週間）
テナントを統合すべきか、併存させるべきかを判断します。ユーザビリティ、ガバナンス、コストの3軸で評価し、経営判断を仰ぎます。
Phase 2：アセスメント（2〜4週間）
移行元・移行先の環境を詳細に調査します。ユーザー数、データ量、SaaS連携、セキュリティ設定などを洗い出し、移行計画の基礎データを収集します。
Phase 3：設計（2〜4週間）
移行方式（ツール移行 / 手動 / ハイブリッド）、スケジュール、カットオーバー方法を設計します。リスクとロールバック手順も策定します。
Phase 4：準備・テスト（2〜4週間）
移行ツールの設定、パイロットユーザーでのテスト移行、手順書の作成、ユーザーへの事前通知を行います。
Phase 5：本番移行（1〜4週間）
段階的にユーザーを移行します。メール、ファイル、Teams等のデータ移行と、ドメイン・DNSの切り替えを実施します。
Phase 6：検証・最適化（2〜4週間）
移行後の検証、残データの確認、ユーザーからの問い合わせ対応、旧テナントの停止・クリーンアップを行います。
テナント統合の期間と規模感
| 規模 | ユーザー数 | 想定期間 | 難易度 |
|---|---|---|---|
| 小規模 | 〜50名 | 1〜2ヶ月 | ★★☆ |
| 中規模 | 50〜300名 | 2〜4ヶ月 | ★★★ |
| 大規模 | 300名〜 | 4〜6ヶ月+ | ★★★★ |
クロスプラットフォーム移行（GWS → M365 など）は、同一プラットフォーム内の統合に比べて期間が1.5〜2倍になる傾向があります。
本連載シリーズの全体像
本連載では、テナント統合のプロセスを全11回にわたって解説します。
- テナント統合とは？（本記事）── 全体像の理解
- 統合する？しない？ ── ユーザビリティ・ガバナンス・コストで判断
- 事前アセスメント ── 移行元環境の調査項目
- M365テナント間移行 ── 手順と注意点
- GWSテナント統合 ── 手順と注意点
- クロスプラットフォーム移行 ── GWS ↔ M365はツール移行が正解
- メール・カレンダー移行 ── ダウンタイム最小化の実務
- ファイル移行 ── OneDrive / SharePoint / Google Drive
- 移行ツール比較 ── AvePoint FLY / BitTitan / ネイティブツール
- ドメイン・DNS移行 ── メールフロー切り替え
- 統合後の検証と最適化 ── チェックリスト
次回は、テナント統合を「する / しない」の判断基準を、ユーザビリティ・ガバナンス・コストの3軸で解説します。
まとめ・ご相談
M&A後のIT統合やテナント移行をご検討の方は、Project365（ITプロジェクト支援・IT PMI）をご覧ください。
貴社のIT課題について、まずは60分の無料相談でお気軽にご相談ください。