GWS間移行でメール日付が壊れる

誰も疑わないシナリオ

Google Workspaceのテナント間移行が完了しました。企業買収、ドメイン変更、長年別々のG Suiteアカウントで運用していた2つの組織の統合。作業はうまくいき、メールボックスは準備完了、ユーザーもログインできています。月曜の朝、最初のチケットが届きます。「すべてのメールが同じ日付になっています。」次に2件目。それから10件。

直感的に、IMAPの設定ミスか、珍しいツールの問題だろうと考えます。まさかGoogle同士の移行が原因だとは思いません。ところが、実際にそこで起きているのです。

このシナリオは、おそらく業界で最も文書化が不十分な問題です。実際に経験したITエンジニアの多くは、メールクライアント側、Outlook側、アカウント設定側と何時間も調査してから、ようやく問題がメール自体のヘッダーにあると気づきます。

なぜGoogle間移行で日付が壊れるのか

何が起きているかを理解するには、メールヘッダーの仕組みに立ち返る必要があります。RFC 2822準拠のメッセージにはすべて、送信側のクライアントまたはサーバーが送信時に付与したDate:フィールドが含まれています。これがメールの「本当の」日付、つまりメッセージが作成・送信された日時です。

しかし、もう一つの仕組みがあります。IMAP INTERNALDATEです。これはメッセージがメールボックスに格納された日時を示す、サーバー側に保存されるメタデータです。そしてここが重要なポイントになります。

移行ツールがGoogle Workspaceのあるテナントからべつのテナントへメールを転送する際、両サーバーがGoogleのものであっても、IMAPプロトコルを経由します。メッセージはソースから読み取られ、宛先に再挿入されます。この再挿入の際、宛先サーバーは操作のタイムスタンプ、つまり移行の日付を含むReceived:ヘッダーを自動的に追加します。

そして、Outlookのようなメールクライアントは、メッセージの表示日付として、元のDate:フィールドではなく、ヘッダーチェーンの先頭にあるReceived:を参照することがあります。結果として、すべてのメールが移行日の日付で表示されます。

問題を引き起こすツール

Google Workspaceのテナント間移行に使われるほぼすべてのツールが影響を受けます。例外はほとんどありません。

GSMMO（Google Workspace Migration for Microsoft Outlook）: 本来はExchangeからの移行向けに設計されていますが、GWS間のフローでも使われます。
CloudM Migrate: MSPのGoogleテナント間移行で広く使われており、移行用のReceived:ヘッダーを常に追加します。詳細はCloudMの詳細分析をご参照ください。
BitTitan MigrationWiz: 同様の動作で、BitTitanに関するこちらの記事で詳しく解説しています。
imapsync: 2つのGoogleテナント間を含むIMAP移行をスクリプト化できるオープンソースツールです。
Takeout + IMAPインポートによる手動エクスポート/インポート: 頻度は低いですが、まったく同じ問題が発生します。

理由はシンプルです。これらのツールはすべて、標準的なIMAPクライアントとして動作します。メタデータを保持するGoogleネイティブの経路にはアクセスできません。両テナントがGoogle上にあっても、転送はIMAP層を経由し、その層は自分自身と通信していることを認識しません。

Receivedヘッダーの仕組みを詳しく見る

（GmailやOutlookでメールのヘッダーを生で読もうとしたことがある方なら、それがいかに読みにくいか分かるはずです。でも、真実はすべてそこに隠されています。）

通常の経路を経たメールには、経路の逆順でReceived:ヘッダーが連なっています。最後にメッセージを処理したサーバーが先頭にきます。移行後は、移行ヘッダーがスタックの一番上に来ます。

CloudMで別のGWSテナントへ移行されたメッセージでは、次のようになります。

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <user@new-domain.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Date:フィールドは2019年を示しています。先頭のReceived:は2024年10月を示しています。Outlookは先頭のReceived:を読みます。ユーザーには、2019年のメールが2024年10月のものとして表示されます。

元のDate:フィールドは無傷です。変更されていません。これが朗報です。データは存在していて、正しく使われるのを待っているだけです。

OutlookとGmailでは表示が異なる

これは重要な違いです。GmailのWebインターフェースでメールにアクセスするユーザーは、正しい日付が表示されることが多いです。GmailはメッセージのRFC 2822 Date:フィールドを優先して表示するためです。Web側では問題が見えにくくなります。

一方、OutlookにIMAP経由（またはExchange ActiveSync同期経由）でGoogle Workspaceのメールボックスを設定しているユーザーは、誤った日付の直撃を受けます。OutlookはIMAP INTERNALDATEを参照しており、そのINTERNALDATEが移行時に追加された先頭のReceived:の日付を反映しているからです。

正確に言うと、Outlookの動作はバージョンと接続モードによって異なります。Outlook 2019およびMicrosoft 365の最新バージョンは、IMAP接続時にINTERNALDATEを使用します。古いバージョンでは若干異なる動作をする場合があります。ただし、実際の本番環境で観察されたすべてのケースにおいて、IMAP経由のGWSからGWSへの移行はOutlookで誤った日付を生み出しています。

つまり、新しいテナントに移行し、ハイブリッド環境（GmailウェブユーザーとOutlookユーザーが混在）を維持している組織では、サポートチケットの状況が矛盾して見えます。「なぜ一部のユーザーだけ影響を受けているのか」と調査に時間を費やしますが、答えは単純です。使っているメールクライアントが違うだけです。

企業買収、合併、ドメイン変更: よくある事例

このタイプの移行は珍しくありません。最もチケットが多く発生するシナリオを紹介します。

企業買収

買収された企業は独自のGoogle Workspaceテナント（@old-company.comドメイン）を持っていました。買収後、250のメールボックス、アーカイブ、8年分のメール履歴すべてを親会社のテナント（@group.com）に移行する必要があります。BitTitanまたはCloudMが作業を担当します。結果: 移行作業の週末の日付がついた240万通のメール。

ドメイン変更

ブランド刷新した企業が@old-name.comから@new-name.comに移行します。同じGoogleテナントではありますが、設定の残骸を避けるためクリーンに再出発するべく新しいテナントを作成（よくある選択です）。imapsyncまたはGSMMOでメールボックスを移行します。日付はまったく同じように壊れます。

子会社の統合

それぞれが独自のG Suiteテナントを持つ4つの子会社を抱えるグループが、すべてを単一テナントに集約することを決定。4つの並行移行、それぞれのメール群に日付破損が発生し、対処が必要になります。

3つのシナリオいずれも、問題は同じで解決策も同じです。メール移行チェックリストを使えば、移行開始前にこの種の問題を予防できます。

手製スクリプトが答えではない理由

問題を理解することは一つのことです。「Pythonスクリプトを書いてヘッダーを修正しよう」と考え、それを本番環境の3万通のメールに適用することは、まったく別の話です。

エッジケースは山ほどあります。クリーンな環境でテスト用の50通のメールで動いたスクリプトは、実際の本番メールボックスでは以下に必ず遭遇します。

S/MIME署名またはPGP暗号化されたメッセージ。メッセージ構造を少しでも変更すると、暗号署名が無効になります。
複雑なネストされたMIME構造のメール（数十メガバイトの添付ファイルを含むmultipart/mixed内のmultipart/alternativeなど）。
RFC 2047エンコード（非ASCII文字）のヘッダー。設定が不適切なパーサーはこれをサイレントに破壊します。
深夜2時に修正バッチの最中に発生する、Google APIからの429 Too Many Requestsエラー。プロセスが不確定な状態のまま残ります。
Received:チェーンが曖昧なメール: 複数の移行ツールがそれぞれヘッダーを追加しており、どれを除去すべきか判断するのは簡単ではありません。

そして最も重要な問題: 修正された各メールが損傷なく、何も失われたり破損したりしていないことを、メールごとにどう確認しますか？手製スクリプトは通常この検証を行いません。Redate.ioは自動的に行い、30日間の閲覧可能なバックアップフォルダで元のメールを保持します。

このタイプの移行でRedate.ioができること

リデイト（Redate.io）は、ドメイン委任経由でGoogle Workspaceの宛先テナントに接続し（メールボックスごとの手動作業なし）、日付メタデータがメッセージの内容と矛盾しているメールをスキャンして特定します。このスキャンフェーズは無料で、修正前に問題の規模を正確に把握できます。

独自の修正エンジンが各メッセージのヘッダーチェーンを分析し、既知の移行ツール（BitTitan、CloudM、imapsync、GSMMO、その他のマイナーなツール）のシグネチャに対してパターンマッチングを適用し、メッセージの内容を変更することなくメタデータの的確な修正を実行します。修正された各メールは個別に検証されます。元のメールは保持されます。

Google Workspaceテナント間移行に特化して言えば、複数回の移行パスが行われた場合（例えば2021年に一度移行され、2024年に再び移行されたメールボックス）も対応し、複数層の不要なヘッダーを解きほぐします。

具体的な接続手順については、CloudMからGoogle Workspaceへの修正ガイドおよびBitTitanからGoogle Workspaceへの修正ガイドをご覧ください。

ユーザーが気づく前に問題を検出する

日付の破損を検出するのに最適なタイミングは、移行直後、ゴーライブ前です。ThunderbirdのようなIMAPクライアントを使っていくつかのパイロットメールボックスを素早く確認することで、表示される日付と期待される日付を比較できます。インポートされたすべてのメールが同じ最近の日付を持っているように見えたら、それが問題の特徴的なサインです。

しかし実際には、問題が発覚するのは移行から数週間後であることが多いです。ユーザーが古い契約書を探して、Gmailのメールボックスが移行日の日付で完全に整理されていることに気づくとき。同じタイムスタンプに数千通のメールが積み上がっています。日付での検索が機能しません。スレッドはバラバラです。履歴が消えてしまったように見えます。

定期的にGoogle Workspaceのテナント間移行を担当するMSPにとって、Redate.ioのスキャンを移行後チェックリスト（クライアント承認前）に組み込むことで、このような事態を避けられます。

Google Workspaceの2つのテナント間で移行を行い、メールの日付が正しくない状態ですか？ Redate.ioで無料スキャンを実行して、修正前に影響範囲を確認してください。

Google Workspace間移行でメール日付が壊れる原因と修正