Google Workspace 移行の手順｜メールを止めずに乗り換える

会社のメールやファイル共有をGoogle Workspaceに移行したい。このとき最大の関心事は「移行中にメールが止まらないか」です。結論から言えば、正しい順序で進めればメールを止めずに切り替えられます。止めないための鍵は、切り替えの順序をひとつも飛ばさないことに尽きます。

移行の全体像

移行は大きく次の流れで進みます。中小規模（〜100名程度）なら、準備を含めて2週間〜1ヶ月が目安です。

現状調査とアカウント設計 — 利用中のメール環境（Microsoft 365、旧来のメールサーバーなど）、ユーザー数、共有アドレス、独自ドメインのDNS管理画面に入れるかを確認し、アカウントとグループの一覧を設計します
Google Workspace契約とドメイン所有権確認 — 管理コンソールからTXTレコードをDNSに追加し、ドメインの所有権を確認します。この時点ではメールの経路は一切変わりません
アカウント作成と初期設定 — ユーザー・グループ（info@などの共有アドレスはグループで実現）・組織部門を作成し、２段階認証などのセキュリティポリシーを設定します
データの事前移行 — 過去メール・連絡先・カレンダー・ファイルを移行ツールで新環境へコピーします。旧環境は動いたままです
MXレコード切り替え — メールの配送先をGoogleに向けます。ここが唯一の「切り替えの瞬間」です
差分移行と検証 — 切り替え直前に旧環境へ届いたメールの差分を移行し、送受信・認証設定を検証します

メールを止めない切り替え順序

メールが「消える」事故のほとんどは、受け皿ができる前に配送先を変えてしまうことが原因です。次の3点を守れば、切り替えの瞬間もメールは失われません。

MX切り替えは最後 — 全ユーザーのアカウント作成・ログイン確認・過去データ移行が終わってからMXレコードを変更します。順序を逆にすると、受け皿のないアドレス宛のメールがエラーで返ります
TTLを事前に短縮する — MX変更の数日前に、DNSレコードのTTL（キャッシュの有効期間）を3600秒以下に下げておくと、切り替えが世界中に反映されるまでの時間を短縮でき、問題時の切り戻しも速くなります
切り替え中の二重期間を理解する — DNSの反映には時間差があるため、切り替え後しばらくは旧サーバーにもメールが届きます。旧環境を最低1〜2週間は解約せずに残し、届いた差分を確認・移行してから閉じます。切り替えは受信量の少ない金曜夜〜週末に行うのが定石です

SPF/DKIM/DMARCの整備

MXと同時に必ず整備すべきなのが送信ドメイン認証です。これを怠ると、移行後に「こちらから送ったメールが相手の迷惑メールに入る」問題が起きます。Gmail・Yahooが一括送信者（1日約5,000通以上）向けにSPF/DKIM/DMARCを要件化して以降、一定量を送る企業では設定しないという選択肢は実質なくなりました。少量の送信でも、なりすまし対策としてDMARCの整備が推奨されます。

SPF — 自社ドメインの送信サーバーとしてGoogleを許可するTXTレコード（include:_spf.google.com）を設定します。旧サーバーや配信サービスからも送るなら、それらも1つのレコードにまとめます（SPFレコードはドメインに1つが原則です）
DKIM — 管理コンソールで電子署名の鍵を生成し、DNSに公開鍵を登録して有効化します。設定漏れが非常に多い項目です
DMARC — SPF/DKIMの検証結果をどう扱うかを宣言します。まずは監視モード（p=none）でレポートを受け取り、正当なメールがすべて認証を通ることを確認してから段階的に強めるのが安全です

既存環境からのデータ移行

移行元ごとに使うツールが異なります。Microsoft 365からの移行は、Google提供のデータ移行サービスや移行ツールでメール・連絡先・カレンダーを移せます。OneDrive/SharePointのファイルはGoogleドライブ（共有ドライブ）へ移行し、権限の対応関係を事前に決めておきます。旧来のメールサーバー（IMAP対応）からの移行は、データ移行サービスでIMAP経由の取り込みができます。POP運用で手元のメールソフトにしかデータがない場合は、端末ごとの移行作業が必要になるため、対象者の洗い出しを早めに行います。いずれの場合も、全員分を一気にやる前に数名のパイロット移行で所要時間と落とし穴を確かめるのが安全です。

アカウント設計と権限の考え方

共有アドレスはグループで — info@やsales@は有償ライセンスを消費しないGoogleグループにし、担当者のアカウントで送受信します
組織部門でポリシーを分ける — 部署や職種ごとに組織部門を分けると、アプリの有効/無効や共有設定を部門単位で制御できます
ファイルは共有ドライブへ — 個人のマイドライブに会社のファイルを置くと退職時に迷子になります。部署・案件単位の共有ドライブを最初に用意します
最初からセキュリティ既定値を — 2段階認証の必須化、外部共有の既定設定、退職時のアカウント停止手順は、移行と同時に決めておくと後が楽です

つまずきやすいポイント

DNSの管理画面に入れない — ドメインをホームページ制作会社が管理していて即日変更できないケースは非常に多く、最初に確認すべき項目です
エイリアスと転送設定の移し忘れ — 旧環境にだけ存在する別名アドレスや自動転送は一覧化しないと漏れます
複合機・業務システムからの送信 — スキャナーのメール送信や販売管理システムの自動メールが旧サーバー経由のままだと、移行後に届かなくなります。SMTPリレー設定への切り替えが必要です
メールソフト併用時のPOP設定 — 移行後もOutlookなどを使う場合、POPで受信するとスマートフォンと二重管理になりがちです。IMAPまたはブラウザ利用への統一を推奨します

まとめ｜切り替えの瞬間はMXだけ、準備が9割

Google Workspace移行の成否は、MXを切り替えるその日ではなく、アカウント設計・データの事前移行・送信ドメイン認証という準備で決まります。「受け皿を完成させてから配送先を変える」という原則を守れば、メールを止めずに乗り換えられます。シャノンでは、自社もGoogle Workspaceで業務を運用している開発会社として、アカウント設計からDNS切り替え、移行後のセキュリティ設定までの導入・移行支援を行っています。ドメインやDNSの現状確認といった初期段階からでも、お気軽にご相談ください。