ClaudeでMicrosoft 365テナント間移行を計画

要点：テナント間移行を実際に動かすのは移行ツールであり、チャットモデルではありません。ただし、ツールの周りにある計画は大量のスプレッドシートであり、Claude が役立つのはそこです。両方の Microsoft 365 テナントからインベントリをエクスポートし、機微な情報を取り除き、Claude に移行元から移行先へのマッピング表を作らせ、競合を洗い出し、移行ウェーブを提案し、各拠点の言語で従業員向けの切り替え通知を下書きさせます。各行は必ず実際のテナントで人が確認し、エクスポートにパスワード、キー、メールボックスの内容を決して含めてはいけません。

香港の商社グループの IT マネージャーを想像してください。これを A グループと呼びます。A グループはシンガポールとクアラルンプールに拠点を持つ会社を買収したばかりで、こちらを B 社と呼びます。A グループは自社の Microsoft 365 テナントに約 240 人のユーザーがいます。B 社は別のテナントに約 180 人、内訳はシンガポール 110 人、クアラルンプール 70 人で、香港グループのテナントに統合すると約 420 人になります。

その計画の最初の草案は、たいてい一人の担当者が Entra のユーザー一覧から手作業で作った表で、想定外が見つかるたびに継ぎ足されます。同じ営業用エイリアスが両方のテナントに存在すること、シンガポールの経理用共有メールボックスの所有者がすでに退職していること、クアラルンプールのノート PC が相手会社の Intune に登録されていることを、まだ誰も知りません。

移行プラットフォームは、指示されたものを何でも移動します。何を指示するか、どのユーザーがどのアカウントに対応するか、どのアカウントは移行する価値がないか、誰が最初に移るかを決めるのは、複数のエクスポートをまたいで読み、突き合わせる作業です。モデルが計画を下書きして突き合わせ、移行ツールが移動を担い、人が検証します。

メールボックスを動かす前に、何をマッピングする必要があるか

メールボックスの移動のほかに六種類のオブジェクトがあり、最初のウェーブを組む前に、それぞれが計画の中に一行を持つ必要があります。

ID、ライセンス、共有メールボックス、グループ、サイト、デバイス

ID。移行元テナントのすべての Entra ID ユーザーについて、移行する、移行先の既存アカウントに統合する、残す、廃止する、のいずれかを決める必要があります。移行元 UPN、移行先 UPN、プライマリ SMTP アドレス、すべてのエイリアスを記録します。

ライセンス。移行元テナントのライセンスは引き継がれません。移行するユーザーには移行先でのライセンスが必要で、ライセンスレポートを見れば、移行先に適切なプランで十分な数があるかがわかります。Exchange Online のネイティブなテナント間メールボックス移行には、ユーザーごとのアドオンライセンスと、テナント間の信頼構成も必要です。ライセンスと前提条件は、最新の Microsoft Learn で確認してください。

共有メールボックスとグループ。共有メールボックス、Microsoft 365 グループ、配布リスト、Teams にはすべて所有者とメンバーがいますが、その全員が移行するとは限りません。孤立したオブジェクトになりやすいのがこれらです。

SharePoint サイトと OneDrive。SharePoint 管理センターのサイト一覧からは、所有者、サイズ、最終アクティビティがわかります。これらのコンテンツへの共有リンクは、コンテンツが移動すると通常は壊れます。

Teams。チーム構造とチャネルのファイルは移行ツールで移動できます。ネイティブなメールボックス移動は、これまで Teams のチャット履歴を引き継いできませんでした。Microsoft は、2025 年 12 月初旬からパブリックプレビューとなる移行オーケストレーターを発表しており（メッセージセンター MC1198079）、新しい Graph PowerShell コマンドでメールボックス、OneDrive、Teams のチャットを対象とします。ただし状況は変わっている可能性があるため、これを前提に計画を立てる前に現在の状況を確認してください。

デバイス。Intune に登録されたデバイスと Autopilot のレコードは、移行元テナントに属しています。移行先への再登録を計画してください。多くの場合、リセットや再プロビジョニングが必要で、Autopilot のデバイスレコードは移行元から登録解除し、移行先にインポートします。お使いのデバイスの種類に合った手順は、Microsoft の最新のガイダンスで確認してください。

インベントリのエクスポートをマッピング表と競合リストに変える

このワークフローでは、Claude はどちらのテナントにも接続しません。インベントリをエクスポートし、整形して貼り付けると、モデルはそれらを並べて読みます。

取得するエクスポートと、貼り付ける前の整形方法

1. 両方のテナントの Entra ユーザー。Entra 管理センターからユーザー一覧をダウンロードするか、Microsoft Graph PowerShell でエクスポートします。オブジェクト ID、表示名、UPN、メール、有効状態、ユーザーの種類、最終サインイン、拠点を残します。

2. メールボックス統計。Exchange Online PowerShell で、Get-EXOMailbox はメールボックスの種類（ユーザー、共有、会議室、機器）とエイリアスを、Get-EXOMailboxStatistics はサイズ、アイテム数、最終ログオンを返します。サイズと件数は残しますが、内容は決して残しません。

3. グループと Teams。Microsoft 365 グループ、配布リスト、Teams を、所有者数とメンバー数とともにエクスポートします。

4. SharePoint サイト。SharePoint 管理センターからアクティブなサイトの一覧をエクスポートします。URL、テンプレート、所有者、使用ストレージ、最終アクティビティです。

5. Intune デバイス。Intune 管理センターから管理対象デバイスをエクスポートします。名前、OS、所有形態、主なユーザー、登録の種類、コンプライアンス状態です。

6. ライセンスレポート。ユーザーごとに割り当てられたライセンスとサブスクリプションの概要で、モデルがシート数を移行先テナントの保有数と比較できるようにします。

貼り付ける前に取り除く。不要な列はすべて削除します。パスワード、MFA のシークレット、認証方法の詳細、BitLocker などの回復キー、管理者トークン、メールボックスの内容は決して含めないでください。ポリシーで求められる場合は仮名化も行います。小さなスクリプトで氏名と各アドレスのローカル部分を ID に置き換え、鍵ファイルは自社の側にだけ置きます。こうすれば同じ人やエイリアスが両方のテナントで同じ ID になり、衝突を検出できます。ドメイン部分は見える状態で残してください。ドメインの競合はそれに依存するからです。

マッピング表と競合リストを作るプロンプト

整形したファイルを、次の一つの指示とともに貼り付けます。「添付は、テナント A（移行先）とテナント B（移行元）の整形済みインベントリのエクスポートで、個人の識別子は ID に置き換えてあります。テナント B のユーザー一人につき一行のマッピング表を作ってください。移行元 ID、提案する移行先 UPN、必要なライセンス、メールボックスの種類とサイズ、そして移行、統合、残す、廃止のいずれかの判断と理由です。続いて、競合をグループ別に挙げてください。テナント A との UPN またはエイリアスの衝突、ドメインに関する阻害要因、テナント間で重複する表示名、アクティブな所有者がいない共有メールボックス、無効、ライセンス未割り当て、または 90 日間サインインしていないアカウント、所有者が全員退職予定または非アクティブのグループや Teams です。すべての項目に根拠とした行 ID を示し、推測せずに『データにありません』と答えてください。」

モデルが根拠を示せない競合は、まだ信用できない競合であり、実際のテナントで十行を抜き取って確認すれば、残りをどこまで信頼できるかがわかります。

洗い出す価値のある競合

想定外の多くは、短いリストから生まれます。UPN とエイリアスの衝突（同じアドレスが両方のテナントにある）、重複した表示名（別人が二人、または一人が二つのアカウントを持つ）、誰も所有していない共有メールボックス、費用をかけて移行するより残す候補となるライセンス未割り当てや非アクティブなアカウント、そして所有者が退職した孤立したグループと Teams です。モデルはこれらを見つけるのが得意で、それぞれをどうするかを決めるのはビジネス上の判断です。

ウェーブの順序を決める——誰が先に、なぜ

ウェーブ計画とは、誰がいつ移行し、各移行が何に依存するかの一覧です。使うツールにかかわらず、順序を決める要因は三つあります。

一つ目は依存関係です。マネージャーと代理権限を持つアシスタント、あるいはメールボックスと Team を共有するチームは、一緒に移行すべきです。そうしないと、テナントをまたいだ代理権限が壊れます。二つ目はサイズとスロットリングです。非常に大きなメールボックスや多数の並行移行は互いに遅くし合うので、重いものは複数のウェーブに分散します。三つ目はドメインです。

カスタムドメインは、一度に一つのテナントでしか検証できません。B 社のドメインを移行先で使うには、まず移行元テナントから削除する必要があり、移行元のユーザー、グループ、エイリアスのどれも、もうそれを使っていない状態にしなければなりません。この一つのルールが切り替え週末の段取りを決めます。ユーザーを一時的なアドレスに移し、ドメインを移行元から削除してから移行先に追加して検証し、メールのルーティングを切り替え、その後で初めて全員がプライマリアドレスを取り戻します。

実例——二つのテナント、三つの地域、一回の切り替え週末

1. エクスポートして整形する。IT 管理者が両方のテナントから六つのインベントリをエクスポートし、不要な列を削除し、小さなスクリプトとローカルの鍵ファイルで氏名とアドレスのローカル部分を ID に置き換え、パスワード、キー、メールボックスの内容が含まれていないことを確認します。

2. マッピングのプロンプトを実行する。Claude がマッピング表と競合リストを返します。このシナリオでは、両方のテナントに営業用エイリアスがあるという数件のエイリアス衝突、別人が使う二つの表示名、唯一の所有者が無効化されているシンガポールの経理用共有メールボックス、最近のサインインがなくライセンスもない数件のクアラルンプールのアカウントが指摘されます。

3. 競合を関係者と解消する。IT マネージャー、シンガポールとクアラルンプールの拠点長、人事が一覧を確認します。不在の所有者は差し替えられ、古いアカウントは廃止され、エイリアスの衝突は計画上で名前を変更します。

4. ウェーブ計画を依頼する。プロンプト：「マッピング表をもとに、テナント B のユーザーの移行ウェーブを提案してください。ウェーブ 0 は IT チームと数名のボランティアです。メールボックス、Teams、定期会議を共有する人は同じウェーブに入れ、最も重いメールボックスは単独のウェーブにし、経理は月末を避け、各ウェーブの依存関係を挙げてください。」続いて二つ目の質問をします。「依存するものより前のウェーブにいる人はいませんか。また、すべての共有メールボックスは主な利用者と同じウェーブにありますか。」

5. 実際のテナントと突き合わせる。承認の前に、人が管理センターで一部の行を検証し、移行先テナントのライセンス数が移行するユーザーをカバーしていることを確認します。移行ツール自身の検出または事前チェックの実行が二つ目の情報源です。

6. 切り替え週末のチェックリストを下書きする。順序立てたチェックリストを依頼します。変更凍結、最終同期、移行元からのドメイン削除、移行先でのドメイン検証、メールのルーティング切り替え、デバイスの再登録、初回ログイン対応です。

拠点ごとの言語で従業員向けの切り替え通知を下書きする

人は、自分にとって何が壊れるかを通して移行を体験するので、通知にはそれを列挙する必要があります。作り直しが必要な定期的な Teams 会議、使えなくなる外部共有リンク、再設定が必要な Outlook と OneDrive、再登録が必要なデバイスです。

事実と日付はこちらからモデルに渡し、次のように依頼します。「[拠点] の従業員向けに切り替え通知を下書きしてください。いつ何が変わるか、前後に何をする必要があるか（サインアウト、再サインイン、Outlook と OneDrive の再設定）、何が引き継がれないか、誰に連絡すればよいかを書いてください。」同じ通知を、全員向けに英語で、香港の従業員向けに繁体字中国語で、希望するシンガポールの従業員向けに簡体字中国語で、クアラルンプール向けにマレー語で作ります。送る前に、各拠点でその言語を母語とする人に訳文を確認してもらってください。モデルの版は下書きです。

Claude が下書きした計画 vs. 移行ベンダーの検出ツール vs. マネージド移行

Claude が下書きした計画。複数のエクスポートをまとめて読み、マッピング表、競合リスト、ウェーブ、多言語の通知を下書きするのが速い。御社のテナントを確認できず、自信満々に間違えることもあるので、すべての主張に確認が必要です。正しい使い方は、計画の層と最初の草案として、そのテナントを知る人がレビューすることです。
移行ベンダーの検出ツール。ShareGate、AvePoint、BitTitan、Quest などのサードパーティ製プラットフォームは Teams や SharePoint の移行によく使われ、テナントに直接接続するため、そのインベントリは実際のオブジェクトを反映します。再現度の限界は製品ごとに異なるので、最新のドキュメントで確認してください。正しい使い方は、何をどう移行するかの正式な記録とし、Claude の計画は突き合わせ用にすることです。
マネージド移行。こうした切り替えを実施してきたチームが、テナント構成、ライセンス、デバイスの再登録、そして週末当日を担い、責任も負います。正しい使い方は、プロジェクトが日常業務と並行して IT チームが運営できる規模を超えるときです。

正しく運用するために——モデルに貼り付けてはいけないものと、データ所在地の制約

機密は一切入れない。パスワード、MFA のシークレットや回復情報、BitLocker などの回復キー、管理者トークン、メールボックスの内容は、プロンプトに決して入れません。

エクスポートを個人データとして扱う。氏名、メールアドレス、部署、サインイン日は個人データです。香港の PDPO と、シンガポールおよびマレーシアの PDPA のもとでは、目的、最小化、データの行き先を考え、ポリシーで求められるなら貼り付ける前に仮名化してください。従業員データを貼り付ける前に、ご利用のプランのデータ条件と自社のポリシーを確認してください。これは法的助言ではありません。

各テナントがどのクラウドにあるかを把握する。香港のテナントはグローバル版の Microsoft 365 にあります。中国本土の 21Vianet が運営する Microsoft 365 は独立したソブリンクラウドで、それとグローバル版 Microsoft 365 の間の移行は、標準的な同一クラウド内のテナント間移行ではありません。Microsoft の最新のドキュメントを確認し、サードパーティ製ツールとより多くの計画が必要になることを見込み、中国リージョンのテナントから何かをエクスポートする前に、データ所在地について助言を得てください。

どのエクスポートなら安全にモデルへ入れられるかを決め、その周りのプロンプトと突き合わせを組み立てるのは、AI+ Support の仕事です。テナント構成、ライセンス、デバイスの再登録、切り替え週末を含む移行そのものはマネージド IT サービスの領域で、切り替え当日の従業員対応は当社の IT サポートチームが担当します。その後の継続的なサービスをご希望なら、各市場のリアルタイム料金をマネージド IT サポートでご覧ください。同じプロジェクトの AI 以外の側面については、香港向け Microsoft 365 移行チェックリストと、シンガポールでの買収後テナント移行のガイドをお読みください。

よくある質問

テナント間移行にはどのくらい時間がかかりますか。

正直に言える単一の数字はありません。決まる要因は、ユーザー数、総データ量と最大のメールボックス、両方のテナントでのスロットリング、ウェーブの数、環境の中で Teams と SharePoint のコンテンツが占める割合、デバイスの再登録、そしてテストとパイロットに充てる時間です。

Teams のチャット履歴は移行できますか。

ツールによって異なり、変化も頻繁です。ネイティブなメールボックス移動は、これまで Teams のチャット履歴を引き継いできませんでした。Microsoft が発表した移行オーケストレーターのプレビューは対象に含める予定で、サードパーティ製プラットフォームにはそれぞれ再現度の限界があるため、従業員に何かを約束する前に、それぞれの現在の状況を確認してください。

切り替え当日に何が壊れますか。

定期的な Teams 会議は通常作り直しが必要で、外部共有リンクは使えなくなり、Outlook のプロファイルと OneDrive の同期クライアントは再構成が必要で、Intune に登録されたデバイスは再登録が必要です。

Intune に登録されたデバイスは再登録が必要ですか。

一般にはそうです。多くの場合リセットや再プロビジョニングを伴い、Autopilot のデバイスレコードは移行元から登録解除して移行先にインポートします。

中国リージョンのテナントを移行する場合、何か変わりますか。

変わります。21Vianet が運営する Microsoft 365 は独立したソブリンクラウドなので、それとグローバル版 Microsoft 365 の間の移行は、標準的な同一クラウド内のテナント間移行ではありません。Microsoft の最新のドキュメントを確認し、サードパーティ製ツールとより多くの計画が必要になることを見込んでください。