テナント分離 （更新: 2026年5月7日）

M365テナント分離プロジェクトでハマる「あるあるトラブル」7選 ― 実務で遭遇する罠と回避策

#テナント分離#Microsoft 365#トラブルシューティング#事業譲渡#PMI

事業譲渡やスピンオフでM365テナント分離を担当することになった情シス向けに、実プロジェクトで本当に遭遇するトラブルとその回避策を、現場目線でまとめました。

テナント分離 完全ガイドでは体系的な手順を解説していますが、この記事は「現場で詰まりやすいポイント」だけに絞った実用記事です。

トラブル1：ドメイン削除でエラーが出続ける

症状

カットオーバー当日、旧テナントから対象ドメインを削除しようとすると以下のエラーが出る。

Microsoft 365 admin center: 
"Cannot delete this domain because some objects in your organization 
still reference this domain."

原因

ドメインに紐づくオブジェクトが残っているため。以下のいずれかが残存している：

  • ユーザーのプライマリ SMTP アドレス
  • ユーザーのProxyAddresses（エイリアス）
  • 配布リスト・セキュリティグループ・M365 グループのアドレス
  • 共有メールボックスのアドレス
  • SharePointサイトのURLに使われているドメイン
  • メールフロールールでの参照
  • Acceptedドメインとしての登録

回避策

事前に以下のPowerShellで依存を洗い出します：

# プライマリSMTPアドレスでの参照
Get-Mailbox -ResultSize Unlimited | 
  Where-Object {$_.PrimarySmtpAddress -like "*@oldco.com"} | 
  Select-Object DisplayName, PrimarySmtpAddress

# ProxyAddresses（エイリアス）での参照
Get-Mailbox -ResultSize Unlimited | 
  Where-Object {$_.EmailAddresses -like "*@oldco.com"} | 
  Select-Object DisplayName, EmailAddresses

# 配布リスト・グループ
Get-DistributionGroup | 
  Where-Object {$_.PrimarySmtpAddress -like "*@oldco.com"}

# M365 グループ
Get-UnifiedGroup | 
  Where-Object {$_.PrimarySmtpAddress -like "*@oldco.com"}

これらを すべて別ドメインに切り替えてから ドメイン削除を実行します。

ハイブリッド構成（オンプレ Exchange あり）の場合、 Set-AcceptedDomain -Identity oldco.com -DomainType InternalRelay 等の設定変更も必要です。

トラブル2：移行ツールの差分同期がカットオーバー直前に失敗

症状

カットオーバー当日、移行ツール（BitTitan、AvePoint等）の差分同期がエラーで止まる。「過去24時間で生成された数千件のメール」が新テナントに同期されない状態。

原因

  • 差分同期のクォータ超過（API制限）
  • アイテム数が多すぎてタイムアウト
  • 移行先メールボックスの容量上限超過
  • 移行ツールのライセンス上限超過

回避策

事前準備：

  • カットオーバー1週間前に「フルリハーサル」を実施し、差分同期の所要時間と失敗率を計測
  • 移行ツールのライセンス上限を事前確認、必要なら追加購入
  • 新テナント側のメールボックス容量上限を事前に拡張

当日対応：

  • 差分同期失敗時は、影響を受けるユーザーに「過去24時間のメールが見えない可能性」を周知
  • 移行ツール側のリトライキューを監視し、失敗ジョブを手動再実行
  • どうしても解消しない場合は、Outlookのpst エクスポート・インポートで個別救済

カットオーバー直前48時間は、移行ツールベンダーのサポートと直接コンタクトできる体制を準備すべきです。AvePoint、BitTitan共に「クリティカルプロジェクトサポート」のプレミアムオプションがあります。

トラブル3：Teamsチャット履歴のID参照が壊れる

症状

Teamsのチャット履歴を移行したものの、過去メッセージの「@メンション」部分が「不明なユーザー」と表示される。リアクション、投稿者情報も部分的に欠落。

原因

Teamsのメッセージは内部的にユーザーの ObjectID（Entra IDの GUID） を参照しています。テナントが変わると同じ人でも別のObjectIDになるため、過去メッセージのID参照が解決できなくなる仕様です。

これはMicrosoft純正ツールでも商用ツールでも完全には解決できない領域です。

回避策

選択肢1：割り切ってクリーンスタート

  • チャット履歴は移行せず、新テナントでチームを新規作成
  • 過去履歴は「TSA期間中、旧テナントで閲覧可能」とする
  • 法的に保管が必要な履歴は、TSA期間中にPDFエクスポートで取得

選択肢2：商用ツールで部分移行

  • BitTitan・AvePointの一部機能で「チャット履歴のリードオンリーアーカイブ」が可能
  • メンション情報は名前テキストに変換される（クリッカブルでなくなる）
  • 100%の再現は無理という前提で利用

選択肢3：法的要請への対応

  • 訴訟ホールド、E-Discovery対象のメッセージは、Microsoft Purview の eDiscovery でエクスポートして別途アーカイブ
  • 移行とは別に、データ保持の確実性を確保

トラブル4：Cross-Tenant Sync で同期失敗が連発

症状

Cross-Tenant Sync を有効化したものの、ターゲットテナントへのユーザー同期が失敗。「Source object not found」「Skipped due to mapping rule」等のエラーログが大量発生。

原因

  • ソーステナントの同期スコープが間違っている
  • ターゲットテナントの招待許可設定がブロックしている
  • ユーザー属性（DisplayName、UPN等）のマッピング設定が不十分
  • 重複検知（既存ユーザーとの衝突）

回避策

事前確認：

□ ソーステナント側
  - Cross-Tenant Access Settings で対象テナントを構成
  - 同期スコープのスコープ条件・除外条件
  - サービスプリンシパル権限

□ ターゲットテナント側
  - 招待ユーザー受け入れ設定
  - 「自動承諾招待」設定
  - ロケール・タイムゾーン設定

監視：

  • Entra ID 管理センター > プロビジョニング > プロビジョニングログ
  • 失敗ユーザーをCSVでエクスポートし、傾向分析

マッピング調整：

  • Microsoftが既定で同期する属性は限定的
  • 必要なら「マッピング設定」で各属性を個別追加
  • カスタム属性のマッピングはJSONベースの定義が必要

トラブル5：旧テナントのEA契約が想定以上に厄介

症状

「旧テナントのライセンス数を減らせばコスト削減できる」と思っていたら、Enterprise Agreement（EA）の契約条件で 3年契約期間中の減数は不可 と判明。分離後も実質ライセンス費が減らない。

原因

EAは契約期間中、最低契約数を維持する義務があります。分離で人数が減っても、契約満期まで支払い続けることになります。

回避策

プロジェクト早期で：

  • EA契約の終了日とTSAスケジュールの関係を確認
  • 契約満期と分離タイミングが近ければ、そこに合わせて分離スケジュールを調整
  • Microsoft アカウントマネージャーと早期に協議：「事業譲渡に伴う減数」は通常のキャンセルとは別扱いになる場合がある

契約変更：

  • EA → CSP（Cloud Solution Provider）への切替提案
  • 直接Microsoftと交渉できない規模なら、CSPパートナー経由で再構築

事業譲渡契約での補填：

  • 「分離による旧EA契約の超過支払い分」を譲渡対価に反映
  • 売り手・買い手で折半する条項

トラブル6：SaaS連携の再構築で見落としがちなもの

症状

カットオーバー後、特定のSaaSアプリで「ログインはできるがデータが表示されない」「メールが送信できなくなった」等の問題が散発。

原因

SaaSアプリ側で旧テナントのID参照（ObjectID、Tenant ID）がハードコーディングされていることが多い。

回避策

事前棚卸し：

連携種別確認ポイント
SAML SSOIdP メタデータURL、エンティティID、Claim ルール
SCIM プロビジョニングプロビジョニングエンドポイント、トークン
API連携（Graph）アプリ登録、APIアクセス許可、シークレット
Webhook通知先URL、認証方法
OAuthクライアントID、リダイレクトURI

カットオーバー時の対応：

  • カットオーバー直後にSaaSベンダー側にも切替依頼
  • 重要SaaSは事前にベンダー対応スケジュールを確認
  • ベンダー側の対応リードタイムが長い場合（1〜2週間）、暫定的に旧テナントのIDで運用継続

特に 業務システム（基幹系、CRM、人事システム） は、最重要候補として早期に動作確認します。

トラブル7：MFA再登録で大量問い合わせが発生

症状

カットオーバー直後、ユーザーが新テナントにサインインしようとすると「MFA登録が必要」表示。Authenticator アプリの再登録、SMS認証の再設定で数百件のヘルプデスク問い合わせが殺到。

原因

MFAデバイス情報はテナントごとに別管理。旧テナントのAuthenticator設定は新テナントでは使えません。各ユーザーが新テナントで再登録する必要があります。

回避策

カットオーバー前周知：

  • 1週間前から段階的に告知
  • 「カットオーバー後、新テナントでMFA再登録が必要」を明確に伝える
  • 動画・図解付きの再登録手順マニュアルを配布

自助対応の強化：

  • セルフサービスパスワードリセット（SSPR）の有効化
  • パスワードレス認証（Windows Hello、FIDO2）への誘導
  • カットオーバー直後の48時間、ヘルプデスク要員を増強

バックアップ手段：

  • 一時的なTAP（Temporary Access Pass）の準備
  • 管理者直通の問い合わせ窓口の用意

まとめ：ハマらないための7つの教訓

  1. ドメイン削除前に依存を全数洗い出す（PowerShellで自動化）
  2. カットオーバー前にフルリハーサル（差分同期の所要時間を計測）
  3. Teamsチャット履歴は割り切る（クリーンスタートを基本に）
  4. Cross-Tenant Sync は事前検証必須（属性マッピングを丁寧に）
  5. EA契約条件を早期に確認（事業譲渡契約に反映）
  6. SaaS連携の棚卸しを徹底（特に業務システム）
  7. MFA再登録の周知と自助対応強化（ヘルプデスク負荷の事前対策）

関連記事・サービス

体系的な手順を学びたい方は、テナント分離 完全ガイド（全11回）をどうぞ。

事業譲渡・スピンオフのIT分離プロジェクトのご相談は、60分無料相談 または テナント分離パッケージのLP からお問い合わせください。

情シスのお悩み、ご相談ください

専門スタッフが貴社の課題に合わせたご提案をいたします。

60分無料相談はこちら 資料ダウンロード
メールでのお問い合わせはこちら →
60分無料相談