M365⇄GWS 移行の考慮事項｜M365→GWS・GWS→M365 双方向の落とし穴を解説
M365 と GWS の相互移行では、メール・ファイル・権限・コラボツール・認証基盤のそれぞれで「完全には再現できない」仕様差が必ず発生します。 何を移行し、何を割り切るかを事前に決めることが、移行プロジェクト成功の分かれ目です。
結論：M365 と GWS は設計思想が異なるため、データの 1:1 移行はできません。特に「メールのフォルダ／ラベル」「Officeファイルの形式変換」「権限・共有モデル」「チャット履歴」の4点で必ず差分が出ます。移行ツールの利用を前提に、欠落・変換リスクを事前に棚卸ししてください。
本記事では、M365→GWS・GWS→M365 の双方向で共通する考慮事項と、方向ごとに固有の落とし穴を整理します。片方向の手順は GWS→M365 移行ガイド、ツール選定は 移行ツール比較 を参照してください。
双方向で共通する考慮事項
1. メール（フォルダとラベルの構造差）
最大の難所が、Gmail の「ラベル」と Outlook の「フォルダ」の思想の違いです。
- Gmail：1通のメールに複数のラベルを付与できる
- Outlook：1通のメールは原則1つのフォルダに属する
このため、どちらの方向でも構造の変換が発生し、ラベル情報の喪失やメールの複製が起こり得ます。移行ツールのマッピング設定で挙動を必ず検証してください。あわせて、カレンダー（繰り返し予定・会議室リソース）、連絡先、委任・代理アクセスの移行可否も確認します。
2. ファイルと形式変換
ドキュメントの形式変換は、再現性の限界を理解しておく必要があります。
- Office ↔ Google 形式の変換では、複雑な書式・数式・マクロ・コメント・バージョン履歴が崩れる／失われることがある
- 共有リンクや埋め込みリンクは移行先でリンク切れになりやすい
- バージョン履歴は移行先に引き継がれないことが多い
重要文書は移行後の目視確認を前提に計画します。
3. 権限・共有モデルの違い
ファイルの共有・アクセス権の考え方がプラットフォームで異なります。SharePoint／OneDrive のサイト・ライブラリ単位の権限と、Google ドライブ／共有ドライブのメンバーシップ・共有設定は 1:1 で対応しません。移行を機に権限設計を見直すのが現実的です。
4. コラボツールとチャット履歴
- Teams ⇄ Google Chat／Spaces：チャット履歴はほぼ移行できないと考える
- 会議（Teams 会議 ⇄ Google Meet）、電話（Teams Phone）の運用も再設計が必要
5. 認証基盤・ID
- ユーザーのプロビジョニング、パスワード、MFA の再登録
- SSO／IdP（Entra ID ⇄ Google）の構成変更
- アカウントの棚卸しと、移行対象ユーザーの確定
6. DNS とメール認証の切替
メールプラットフォームの切替に伴い、MXレコードの変更と SPF・DKIM・DMARC の再設定が必須です。これを誤ると移行後にメールが届かない／なりすまし扱いで弾かれます。DNS 切替は最も慎重に扱う工程です（参考：メール認証 用語集）。
7. 共存期間と移行後検証
切替当日のダウンタイム、共存期間中のメール二重配信や空き時間（Free/Busy）連携、そして移行後の検証を計画します。検証の自動化は 移行後検証の自動化、事前のエラー検出は 事前スキャンによる移行エラー予防 を参照してください。
M365 → GWS 固有の考慮事項
| 項目 | 考慮事項 |
|---|---|
| メール | Outlook のフォルダ階層が Gmail のラベルに変換され、深い階層がフラット化することがある |
| ファイル | Office ファイルは Drive にそのまま保存・編集可能。ただし VBA マクロは動作しない |
| SharePoint | サイト・リスト・ページ・Power Automate に直接の GWS 同等機能がない。共有ドライブへの再設計が必要 |
| アプリ | Power Platform、SharePoint リストなどで作った業務アプリは作り直しになる |
| ID | Entra ID を IdP として残し Google へ連携するか、Google を IdP にするかを決める |
GWS → M365 固有の考慮事項
| 項目 | 考慮事項 |
|---|---|
| メール | Gmail の複数ラベルが Outlook フォルダにうまく収まらない。複製か集約かを選ぶ |
| ファイル | Google ドキュメント類は Office 形式へ変換が必要。Apps Script・複雑な数式・コメント・履歴が崩れやすい |
| 共有ドライブ | 共有ドライブのメンバーシップを SharePoint／OneDrive の権限へ再マッピング |
| アプリ | Apps Script の自動化、Google サイト、Google フォームは M365 に直接移行できない（フォームは Microsoft Forms で部分代替） |
| グループ | Google グループを Microsoft 365 グループ／配布リストへ移行 |
移行ツールは前提
どちらの方向でも、手動移行は欠落・事故のリスクが高く、規模が大きいほど現実的ではありません。AvePoint FLY、BitTitan MigrationWiz、Quest、CodeTwo などの専用ツールの利用が前提です。手動移行のリスクとツール移行の考え方は クロスプラットフォーム移行はツール移行が正解 に、ツールの比較は 移行ツール比較（FLY/Quest/CodeTwo） にまとめています。
移行プロジェクトのチェックポイント
- 棚卸し：ユーザー・メール・ファイル・グループ・共有・アプリ・自動化を洗い出す
- 割り切りの決定：チャット履歴・マクロ・履歴など「移行しないもの」を明確化する
- ツール選定：データ量・予算・期間に合わせて移行ツールを選ぶ
- DNS／メール認証計画：MX・SPF・DKIM・DMARC の切替手順とタイミングを設計
- 共存・切替：ダウンタイムと共存期間を計画
- 検証：移行後にメール・ファイル・権限を検証する
- 定着支援：ユーザー教育とヘルプデスク体制を整える
まとめ
- M365 と GWS の移行は 1:1 再現できない。メール構造・ファイル形式・権限・チャット履歴で必ず差分が出る
- メール認証（SPF・DKIM・DMARC）と MX の再設定は移行で最も慎重に扱う工程
- 方向ごとに固有の落とし穴（M365→GWS は SharePoint／Power Platform、GWS→M365 は Apps Script／形式変換）がある
- 移行ツールの利用を前提に、棚卸し → 割り切りの決定 → 検証まで設計する
M365 ⇄ GWS の移行計画・実行・移行後の運用代行は、情シス365（IT運用代行）にご相談ください。退職者データの保全方針もあわせて検討する場合は 退職者データ保全：M365 vs GWS を、テナント統合の全体像は テナント統合 完全ガイド をご覧ください。