この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。
Google Workspace Migrateは、Exchange、SharePoint/OneDrive、ファイル共有、Box、既存WorkspaceなどからGoogle Workspaceへ組織データを移すための管理者向け移行基盤です。2026年は一部のMicrosoft 365移行元でadvanced data import toolへの切替が進んでいるため、旧手順をそのまま採用せず現行のGoogle公式情報を確認します。
情報確認基準日：2026-09-19
まず一言でいうと
「古い環境からGoogle Workspaceへ引っ越す」ための道具です。ただしコピーだけではなく、ユーザーID、共有権限、フォルダとラベルの違い、差分移行、切替日の設計までが移行プロジェクトになります。
| 観点 | 要点 | 確認すること |
|---|---|---|
| 移行元 | Exchange、SharePoint/OneDrive、ファイル共有、Box等 | 現在もMigrate対象か |
| Identity mapping | 元ユーザー/グループを移行先IDへ対応 | 権限を誰へ引き継ぐか |
| Mapping / template | 何をどこへ移すか定義 | 対象外機能・変換差 |
| Main migration | 本体データを移す | 件数・エラー・欠落 |
| Delta migration | 本番切替直前の新規・変更分を追随 | 最終同期後の差分 |
| 2026年の注意 | Microsoft 365系の一部で新方式へ移行 | advanced data import toolの適否 |
2026年に特に注意する点
Google公式ヘルプは、SharePoint Online / OneDrive向けGoogle Workspace Migrateは2026年9月15日から更新・バグ修正を受けなくなり、Exchange Online向けは2026年10月から利用できなくなると案内しています。Microsoft 365から新規移行を計画する場合は、Googleが案内するadvanced data import toolへの切替を先に確認します。
このため「Migrateという製品名を知っている」だけでは不十分です。移行元ごとに、現行サポート、移行先、移せるデータ種別、移せない設定を公式表で確認します。
Google全体での位置づけ
Google Workspace Migrateは、日常利用アプリではなく導入・移行フェーズの管理ツールです。移行完了後の日常業務はGmail、Drive、Calendar等へ移り、Migrateを常時使うわけではありません。
flowchart LR S[移行元 Exchange / Files / Box等] --> SCAN[調査・スキャン] ID[Identity mapping] --> MAP[Mapping / Template] SCAN --> MAP MAP --> MAIN[Main migration] MAIN --> CHECK[件数・エラー・権限確認] CHECK --> DELTA[Delta migration] DELTA --> CUT[Workspaceへ切替]
Identity mappingが重要な理由
移行ではファイルだけでなく「誰が所有者か」「誰に共有されているか」というID情報があります。Identity mappingは、移行元のユーザー・グループ等をGoogle Workspace側のIDへ対応付ける仕組みです。Google公式資料では、共有権限、作成・変更メタデータ、ユーザー名を含む参照などを移行先へつなぐために使うと説明されています。
たとえば退職者や旧グループを誤って対応付けると、データ件数が合っていてもアクセス権が期待どおりになりません。移行品質は「ファイル数」だけでなく「所有者・共有・日時・フォルダ/ラベル変換」まで確認します。
Exchangeからの移行で起こる考え方の違い
Exchangeのフォルダ階層はGmailではラベルへ対応するなど、移行元と移行先でデータモデルが完全には同じではありません。共有メールボックス、カレンダー、フィルタなども、Google公式のsupported / unsupported一覧とmonitoring pointsで変換先を確認します。
誰に関係する？
一般利用者・事務職
利用者自身がMigrateを操作する場面は多くありません。重要なのは移行後に「メールはどこにあるか」「フォルダがラベルへどう変わったか」「共有ファイルへアクセスできるか」を受入確認することです。
IT管理者
移行元の棚卸し、ID対応表、対象外機能、帯域、実行ノード、エラー再実行、差分移行、切替、ロールバック条件を設計します。特に2026年は移行元ごとの製品移行予定を確認し、廃止予定経路で新規設計しないことが重要です。
開発者・自動化担当
Migrate本体を無理に自動操作するより、移行前後の件数・CSV・権限一覧を読み取りで比較する補助ツールが安全です。APIが必要な場合は、移行先サービス側のWorkspace APIと認証を別途設計します。
Microsoft側の移行ツールと比べる
| 観点 | Google Workspace Migrate | Microsoft 365側の移行ツール群 |
|---|---|---|
| 方向 | 他環境 → Google Workspace | 他環境 → Microsoft 365が中心 |
| ID | Google Workspace側IDへmapping | Entra ID / M365側IDとの対応 |
| 変換 | Gmailラベル等Google側モデルへ変換 | Exchange/SharePoint等Microsoft側モデルへ変換 |
| 切替 | Main + Deltaで追随 | 段階移行・差分同期等を方式別に設計 |
| 注意 | 2026年に一部M365移行元で方式変更 | 対象ワークロードごとにツールが異なる |
Microsoft経験者は「Migration ManagerのGoogle版」と一括りにするより、移行元ごとにGoogleの現行推奨経路を選ぶと理解すると安全です。
安全に試す：移行前後の件数比較
Migrate本体へ破壊的な変更を加えず、ダミーCSVで件数比較できます。
$before = Import-Csv ./before.csv
$after = Import-Csv ./after.csv
[pscustomobject]@{
Before = $before.Count
After = $after.Count
Delta = $after.Count - $before.Count
}
見る点： Before / After / Delta。成功条件： 3値が表示され、想定件数と一致すること。1か所変える意味： after.csv にダミー1行を追加するとDeltaが1増え、差分検知の考え方を確認できます。実メールアドレスや社内IDはサンプルに入れません。
セキュリティと移行品質
Identity mappingには実IDが含まれるため、公開GitHubへ置かない。
移行用管理権限は必要最小限にする。
一時ファイル、ログ、CSVにも個人情報が残り得る前提で保護する。
TLSや接続要件を公式資料で確認する。
「成功件数」だけでなく、所有者、共有、日時、ラベル/フォルダ変換をサンプリング確認する。
切替直前はDelta migration後に最終差分を確認する。
Google公式情報
次に何をすればよい？
まず移行元を「Exchange Online」「SharePoint Online/OneDrive」「オンプレミスExchange」「ファイル共有」「Box」などに分けます。次に、その移行元でGoogleが2026年9月時点に推奨する経路を確認し、10〜50件程度のダミー/検証データでmapping・変換・差分移行・受入確認を一巡させてから本番計画へ進みます。
結局どういうサービス？
Google Workspace Migrateは、組織データをGoogle Workspaceへ移すための移行基盤ですが、2026年は移行元によって後継方式への切替が進んでいます。
単なるデータコピーではなく、ID・権限・データモデル変換・差分・受入確認までを一つの移行プロジェクトとして扱い、最初にGoogle公式の現行推奨経路を確認するのが重要です。
