Amazon WorkMail EOL対応 Google Workspace移行の手順とMX切替

はじめに

Amazon WorkMailからGoogle Workspaceへ、業務メールを止めずに移行しました。

対象は3メールボックス、10万通を超える過去メールです。Route 53のMXレコードをGoogleへ切り替えた後も、Google WorkspaceからWorkMailへ二重配信する構成を残し、直接アドレスとグループアドレスの両方で受信を確認しました。

この記事では、実際に進めた順番、標準のIMAP移行でうまくいかなかった場合の対応、MX切替前後の差分移行、重複を防ぐ仕組みをまとめます。

この記事は2026年9月8日時点の公式情報と移行実績を基にしています。組織名、実在ドメイン、メールアドレス、認証情報は公開用に置き換えています。Google AdminやAWSの画面表示は変わることがあるため、実作業では公式ドキュメントも確認してください。

先に結論

• Google Workspaceのドメイン所有権確認とMX切替は、別の作業として扱う
• ユーザー、グループ、過去メールを先に用意してからMXを変更する
• 過去メールはIMAPから取得し、チェックポイントを残して再開可能にする
• MX切替前にGoogle WorkspaceからWorkMailへの二重配信を設定する
• MX切替の直前と直後に差分移行を行い、Message-IDで重複を防ぐ
• 直接アドレスとグループアドレスを外部からテストし、監視期間後にWorkMailを停止する

Amazon WorkMailのサポート終了日

AWSはAmazon WorkMailについて、2026年4月30日から新規顧客を受け付けず、2027年3月31日にサポートを終了すると案内しています。既存利用者もサポート終了までに別サービスへ移行する必要があります。

AWS公式: Amazon WorkMail end of support

サポート終了直前に作業を始めると、メールの棚卸し、移行テスト、DNS反映、利用者への案内を同時に進めることになります。MXを変更しなくてもGoogle Workspaceの初期構築と過去メールの事前移行はできるため、早めに準備を始める方が安全です。

前提と移行範囲

項目	内容
ドメイン	example.com
DNS	Amazon Route 53
移行元	Amazon WorkMail
移行先	Google Workspace Gmail
対象	3ユーザーと3グループアドレス
過去メール	WorkMailのIMAPからGmailへコピー
新着メール	MX切替後はGmailを主系、WorkMailを副配送先にする
対象外	カレンダー、連絡先、Google Drive、Vaultの詳細移行

移行元のメールは削除しません。Google Workspaceで受信と過去メールを確認し、監視期間を終えるまでWorkMailを残します。

移行中のメール経路

MXレコードは、外部から届いたメールを最初に受け取るメールサーバーを指定します。Google Workspaceへ申し込んだだけでは、受信先は変わりません。

今回はMX切替後にGoogle Workspaceを主系とし、Google AdminのルーティングでWorkMailにも同じ新着メールを配送しました。

MXにGoogleとWorkMailを併記して同報を期待する構成にはしていません。MXの優先度は配送先の冗長化やフォールバックに使われるもので、同じメールを必ず両方へ配送する仕組みではないためです。

Google公式: 二重配信を使用して複数の受信トレイにメールを配信する

実施した順番

順番	作業	MXへの影響
1	WorkMailのユーザー、グループ、メール量を棚卸しする	なし
2	Google Workspaceを契約し、ドメイン所有権を確認する	なし
3	Google Workspaceにユーザーとグループを作る	なし
4	WorkMailのIMAP接続を確認する	なし
5	過去メールを事前移行する	なし
6	GoogleからWorkMailへの二重配信を設定する	なし
7	SPF、DKIM、DMARCを準備する	TXTのみ変更
8	Route 53のMXをGoogleへ切り替える	受信先が変わる
9	差分移行と外部送受信テストを行う	なし
10	14〜30日ほど監視してからWorkMailを停止する	契約停止時に確認

ポイントは、MX切替を最後の方まで待つことです。手順1〜7の間、新着メールは従来どおりWorkMailで受信できます。

1. WorkMailを棚卸しする

最初に、メールアドレスだけでなく次の項目を確認します。

• 有効なユーザーと代表アドレス
• 代表アドレスがユーザー、エイリアス、グループのどれか
• 各メールボックスのフォルダとメッセージ数
• 転送、受信ルール、送信元アドレス
• 退職者や停止ユーザーの保管要否
• WorkMail以外から送信しているシステムの有無

代表アドレスをGoogleグループへ置き換える場合は、メンバーと外部送信者からの受信可否を先に決めます。グループを作っただけでは、外部からのメールを受信できない設定になっている場合があります。

2. ドメイン所有権確認とMX切替を分ける

Google Workspaceのドメイン所有権確認では、Googleから指定されたTXTレコードをRoute 53へ追加します。この段階でMXは変更しません。

所有権確認用TXTの例

google-site-verification=Googleから指定された値

TXTを追加したら、Google Adminで確認を完了します。

ターミナル

dig +short TXT example.com

今回の準備では、最初に作ったGoogle Workspace環境で所有権確認の期限を過ぎ、環境を作り直すことになりました。登録直後にTXTを設定し、管理画面で「確認済み」になるところまで同じ日に終えるのが重要です。

Google公式: Google Workspaceのドメインを所有していることを証明する

3. ユーザーとグループを先に作る

WorkMailと同じメールアドレスでGoogle Workspaceのユーザーを作成します。代表アドレスはGoogleグループとして作り、移行前の配布先を再現しました。

管理者専用ユーザーを追加すると、そのユーザーにもライセンス料金が発生することがあります。小規模環境では、通常利用するユーザーへ特権管理者権限を付け、管理用の代表アドレスはライセンス不要のグループにする方法もあります。

ただし、特権管理者を1人だけにすると、そのユーザーがログインできないときに復旧が難しくなります。料金だけでなく、予備の特権管理者、再設定用メール、電話番号、2段階認証も合わせて設計します。

4. WorkMailのIMAP接続を確認する

Amazon WorkMailはIMAPでメールを取得できます。リージョンごとのエンドポイントを使い、SSL/TLSで接続します。

接続設定の例

サーバー: imap.mail.us-east-1.awsapps.com
ポート: 993
暗号化: SSL/TLS
ユーザー名: [e-mail]

AWS公式: Connect your client to your Amazon WorkMail account

全件移行を始める前に、各ユーザーで次を確認します。

• 認証に成功する
• INBOX以外のフォルダも一覧取得できる
• 日本語件名、添付ファイル、送信済みメールを取得できる
• メッセージの受信日時が維持される
• 1ユーザーの少量テストをGmailで確認できる

5. 標準移行で0件だったためGmail APIへ切り替えた

最初はGoogle Adminのデータ移行機能からIMAP移行を試しました。接続確認は成功しましたが、この環境では移行件数が0件のまま進みませんでした。

原因調査に時間を使い続けるより、WorkMailからIMAPでRFC 2822形式のメールを取得し、Gmail APIのusers.messages.insertで対象ユーザーへ投入する方式へ切り替えました。

Google公式: IMAPアカウントからメールを移行する

Gmail API: users.messages.insert

複数ユーザーへ管理者側から投入するため、サービスアカウントとドメイン全体の委任を一時的に使いました。ドメイン全体の委任は強い権限なので、必要なスコープだけを許可し、移行終了後に無効化または削除します。

Google公式: ドメイン全体の権限の委任を管理する

6. チェックポイントで再開と重複防止を行う

10万通を超える移行は、通信エラーやAPI制限で中断する前提にしました。移行元のユーザー、フォルダ、UIDVALIDITY、UIDを複合キーにし、SQLiteへ結果を保存します。

state.sql

CREATE TABLE message_state (
  source_user TEXT NOT NULL,
  folder TEXT NOT NULL,
  uidvalidity TEXT NOT NULL,
  uid TEXT NOT NULL,
  status TEXT NOT NULL,
  gmail_id TEXT,
  updated_at TEXT NOT NULL,
  PRIMARY KEY (source_user, folder, uidvalidity, uid)
);

再実行時はstatus = 'success'のメールを飛ばし、未処理と失敗だけを対象にします。これにより、プロセスを安全に止めてワーカー数を変えたり、ユーザー単位で再開したりできます。

ターミナル

sqlite3 state.sqlite3 \
  "SELECT source_user, status, COUNT(*) FROM message_state GROUP BY source_user, status;"

チェックポイントだけでは、MX切替前後に別経路でGmailへ届いた同じメールを見分けられません。そのため、Gmail側に同じMessage-IDが存在する場合は新規投入せず、移行済みとして記録しました。

Message-IDがないメールや、同じMessage-IDを不正に再利用するメールもあります。ハッシュ値、日時、送信者などを組み合わせた補助判定を用意すると、さらに安全です。

7. GoogleからWorkMailへの二重配信を設定する

MX切替後もWorkMailへ新着メールを残すため、Google Adminで追加の配信先を設定しました。大まかな流れは次のとおりです。

1. Google AdminのGmail設定でWorkMailの受信エンドポイントをホストとして登録する
2. 接続を確認し、組織の要件に合わせてTLS、証明書、ホスト名検証を設定する
3. 受信メールと内部送信メールを対象に、追加の配信先としてWorkMailを指定する
4. 対象ユーザーとグループにルールが適用されることを確認する
5. 外部アドレスからテストメールを送り、両方の受信箱で確認する

ルーティング条件を誤ると、同じメールが循環する可能性があります。WorkMailからGoogleへ同じルールで戻す設定は入れず、GoogleからWorkMailへの一方向にしました。

Google公式では、ルーティング設定の反映に最長24時間ほどかかる場合があると案内されています。保存直後の画面だけで完了とせず、外部からテストメールを送り、GmailとWorkMailの両方へ届くことを確認します。

8. SPF、DKIM、DMARCを準備する

受信先をGmailへ変える作業と、送信メールの認証は別です。切替前にGoogle Workspaceからテスト送信し、SPF、DKIM、DMARCを確認します。

Google Workspaceから送信するドメインには、Googleが案内するSPFレコードを設定します。同じホスト名にSPFレコードを複数作るとPermErrorの原因になるため、既存レコードがある場合は1つに統合します。

Google Workspace用SPFの例

v=spf1 include:_spf.google.com ~all

Amazon WorkMailは標準ではamazonses.comのサブドメインをMAIL FROMドメインに使います。Amazon SESでカスタムMAIL FROMドメインを使っている場合は、そのサブドメインへAWSが案内するMXとSPFを設定します。

Amazon SESのカスタムMAIL FROM用SPFの例

v=spf1 include:amazonses.com ~all

Google用とAmazon SES用のSPFを同じホストへ無条件に併記するのではなく、実際のMAIL FROMドメインと送信経路を確認して設定します。二重配信でWorkMailを受信先として残すだけなら、WorkMailからの送信を継続するとは限りません。

DKIMはGoogle Adminで鍵を生成し、指定されたTXTレコードをRoute 53へ追加してから認証を開始します。既存のWorkMail用DKIMは、WorkMailからの送信を止めるまで残します。

DMARCは最初から厳しい拒否設定にせず、まずp=noneでレポートを確認する方法があります。

DMARCの例

v=DMARC1; p=none; rua=mailto:[e-mail]

• Google公式: SPFを設定する
• Google公式: DKIMを設定する
• Google公式: DMARCを設定する
• AWS公式: Amazon SESでカスタムMAIL FROMドメインを使用する

9. Route 53のMXをGoogleへ切り替える

Google Workspaceのユーザー、グループ、過去メール、二重配信を確認してからMXを変更します。現在のGoogle公式手順では、新しいGoogle Workspace環境のMX値としてsmtp.google.comが案内されています。

Route 53のMXレコード

名前: example.com
タイプ: MX
値: 1 smtp.google.com.
TTL: 300

Google公式: Google WorkspaceのMXレコードを設定する

AWS公式: MX record type

切替前にTTLを短くしておくと確認しやすくなります。変更後は複数のDNSリゾルバーで結果を確認しました。

ターミナル

dig +short MX example.com
dig +short MX example.com @8.8.8.8
dig +short MX example.com @1.1.1.1

期待する結果は次のとおりです。

1 smtp.google.com.

10. 切替境界の差分を取り込む

初回移行を終えてからMXを切り替えるまでの間にも、WorkMailへ新着メールが届きます。そこで、次の3回に分けて移行しました。

1. MX切替前に過去メールを全件移行する
2. MX切替の直前に差分移行する
3. MX切替後にもう一度WorkMailを走査する

3回目では、二重配信によりGmailとWorkMailの両方に存在するメールが見つかります。Gmailに同じMessage-IDがあれば投入を省略し、チェックポイントだけを完了にしました。これにより、切替境界の取りこぼしとGmail内の重複を同時に避けられます。

実際の移行結果

公開用に端数を丸めた結果です。

項目	結果
対象メールボックス	3
移行対象メール	10万通超
データ量	20GiB超
最終失敗	0
最終未処理	0
外部受信テスト	直接アドレス3件、グループアドレス3件
二重配信	GmailとWorkMailの両方で確認

Gmail側の総メッセージ数は、移行チェックポイントより数件多くなりました。これはGoogle Workspaceを作成した後にGmailで受信した案内メールやテストメールが含まれるためです。移行件数とGmail総数が完全一致することを求めず、差分の理由を説明できるかを確認しました。

切替後の確認項目

MXがGoogleを向いただけでは、移行完了とは判断しません。次を利用者別、アドレス種別に確認します。

• 外部メールから各ユーザーへ届く
• 外部メールから各グループへ届き、想定メンバーへ展開される
• 同じ新着メールがWorkMailにも届く
• Gmailから外部へ送信できる
• 返信が同じアドレスで届く
• 添付ファイル、日本語件名、HTMLメールが崩れていない
• 送信メールのヘッダーでSPF、DKIM、DMARCを確認できる
• 過去メールを日付、差出人、キーワードで検索できる
• チェックポイントの失敗件数と未処理件数が0になっている

WorkMailをすぐ停止しない

MX切替後も、DNSキャッシュ、ルーティング条件、グループ設定、端末側の見落としが残る可能性があります。今回はWorkMailの元メールを削除せず、Googleからの二重配信も残して監視期間へ移りました。

WorkMailを停止する前に、少なくとも次を満たしていることを確認します。

• 14〜30日程度、新着メールの取りこぼしがない
• 全ユーザーがGoogle Workspaceへログインできる
• 代表アドレスのメンバーが正しい
• SPF、DKIM、DMARCの結果に問題がない
• 業務システムの送信元と返信先を確認した
• 過去メールの検索と添付ファイルを確認した
• 監査や保管の要件を満たした
• WorkMail停止後の問い合わせ先と復旧手順を決めた

監視終了後は、二重配信ルール、WorkMail用のSPF・DKIM、移行専用のサービスアカウントとドメイン全体の委任を整理します。

つまずいた点と対策

つまずいた点	対策
ドメイン所有権確認の期限を過ぎた	新規登録とTXT確認を同じ日に完了する
標準IMAP移行が0件のまま進まなかった	少量テスト後、IMAP取得とGmail API投入へ切り替える
長時間処理が途中で止まる	SQLiteへメール単位のチェックポイントを保存する
MX切替境界で同じメールが両方に届く	Message-IDを確認して重複投入を防ぐ
MXを変えるまでGmailに新着が届かない	Google Workspaceの契約とMXの役割を分けて考える
MX切替後の保険がない	GoogleからWorkMailへの一方向の二重配信を先に設定する

移行チェックリスト

• WorkMailのユーザー、グループ、転送設定を棚卸しした
• Google Workspaceのドメイン所有権を確認した
• 全ユーザーがGoogle Workspaceへログインした
• ユーザーとグループのアドレスを再現した
• WorkMailのIMAP接続を全ユーザーで確認した
• 少量のテスト移行を確認した
• チェックポイント付きで過去メールを事前移行した
• GoogleからWorkMailへの二重配信を確認した
• SPF、DKIM、DMARCを準備した
• Route 53のMXをGoogleへ切り替えた
• MX切替前後の差分を取り込んだ
• 直接アドレスとグループを外部からテストした
• 送信認証の結果をメールヘッダーで確認した
• 監視期間を終えてからWorkMailを停止した
• 移行用の強い権限と不要なDNS設定を削除した

まとめ

Amazon WorkMailからGoogle Workspaceへの移行では、MX変更そのものより、変更前後の状態を両方追えるようにすることが重要でした。

• 所有権確認、ユーザー作成、過去メール移行をMX切替前に終える
• 標準移行が進まない場合は、小さく検証して別方式へ切り替える
• チェックポイントとMessage-IDで、再開と重複防止を両立する
• Googleを主系、WorkMailを副配送先にして切替後も比較できるようにする
• 件数だけでなく、直接アドレス、グループ、送信認証を確認する

この順番なら、利用者への影響を抑えながら、段階的にGoogle Workspaceへ移行できます。

おわりに

Wealthy Design株式会社では、AWS・Google Workspaceを含むクラウド活用や業務システムの設計・開発を行っています。