GSMMO移行でメール日付が変わった場合の修正方法

誰も警告しないGSMMOの日付問題

Google Workspace Migration for Microsoft Outlook(GSMMO)は、PSTファイル、Outlookプロファイル、ローカルメールアーカイブをGmailに移行するために、無料で公式に サポートされている、Googleが提供するデスクトップツールです。OutlookからGoogle Workspaceへ小規模チームや個別のメールボックスをいくつか移行する際に、Googleが推奨する移行方法です。

このツールは実際に動作します。メールはGmailに届き、フォルダー構造はラベルにマッピングされ、連絡先も引き継がれます。しかし移行後にGmailを開いて日付でソートしてみてください。すべてのメールに今日の日付が表示されます。2021年1月に送った提案書は2026年4月になっていませんか。2023年3月に会計士から受け取った請求書も、同じく2026年4月です。

GSMMOはこれが起こることを警告しません。移行ログはすべてのメッセージについて成功と表示します。Googleの公式ドキュメントも、既知の制限としてこれについて触れていません。古いメールを日付範囲で検索した誰かが結果ゼロに気づいたときに、初めて発覚するのです。

GSMMOが実際にメールをアップロードする仕組み

GSMMOはPSTファイルから(またはOutlookプロファイルから直接)メッセージを読み取り、Gmail APIを通じてGmailにアップロードします(このツールに関するGoogleの公式リリースノートにもそう記載されています)。ここに日付問題の原因があります。そしてその仕組みを理解しておく価値があります。なぜ「再インポートすればいい」という単純な話にならないのかが分かるからです。

GSMMOがGmail APIを通じてメッセージをアップロードすると、Gmailはアップロードの瞬間の日付が入った新しいReceived:ヘッダーを追加します。そして元の日付がメッセージとともに送られてこない場合、Gmailが内部的にソートや表示に使用するタイムスタンプであるINTERNALDATEは、元の送信日ではなくアップロードの瞬間に設定されてしまいます。

GSMMO移行後のヘッダーチェーンは次のようになります。

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

2019年9月の元のDate:ヘッダーが見えますか。まだそこにあり、変更されていません。GSMMOはメッセージ本文や元のヘッダーを変更しません。しかしGmailは表示のためにそれを無視し、代わりにINTERNALDATEを使用します。それが今、2026年4月を示しているのです。

GSMMOと管理者側移行ツールの比較

混乱が生じやすいのはここです。Googleには複数の移行ツールがあり、それぞれ動作が異なります。

GSMMO(デスクトップアプリ)はユーザーのマシン上で動作します。OutlookまたはPSTファイルからメッセージを読み取り、Gmail APIを通じてメールをアップロードします。ユーザーはGoogle Workspaceアカウントと、OutlookにインストールされたGSMMOプラグインが必要です。これはクライアント側のツールです。

Google Workspace Migration Service(管理コンソールツール)はサーバー側で動作します。管理者がGoogle管理コンソールで設定し、Exchangeサーバーや別のGoogle Workspaceテナントを指定すると、移行はGoogleのインフラ上で実行されます。このツールは一部の構成で日付処理がやや優れています。元のメタデータに基づいてINTERNALDATEを設定できる場合があるためです。しかし「やや優れている」は「信頼できる」ことを意味しません。多くの管理者が、このツールでも同じ日付の問題を報告しています。

重要な違いは何でしょうか。GSMMOには、日付の保持について判断を行うサーバー側のロジックが一切ありません。アップロードされるすべてのメッセージが同じ扱いを受けます。新しいメールでも10年前のアーカイブメッセージでも、アップロード当日の日付が入ったReceived:ヘッダーが付くのです。それだけです。

GSMMOの日付保持が機能しない理由

GSMMOの設定を見たことがあれば、実際には「日付を保持する」というオプションが存在しないことに気づいたかもしれません。これは見落としではありません。GSMMOはAPIを通じてアップロードされたメッセージをGmailがどう扱うかに依存しており、それを上書きすることはできないのです。

技術的な流れは次のとおりです。

1. GSMMOはPSTファイルからメッセージを読み取ります。元のタイムスタンプも含めてです。
2. GSMMOはGmail APIを通じてメッセージデータをアップロードします。
3. Gmailはアップロードを受け取り、メッセージをメールボックスに保存します。
4. Gmailはアップロードの瞬間の日付が入った新しいReceived:ヘッダーを追加します(上の例のgmailapi.google.comの行がそれです)。
5. 元の日付が一緒に送られてこない場合、Gmailは INTERNALDATE をアップロード時のタイムスタンプに設定します。
6. メールは今日の日付でGmailに届きます。

ステップ4と5が肝心です。Gmailはそのヘッダーを、APIを通じてアップロードされるすべてのメッセージに追加します。ツールが何を送ってきたかにかかわらずです。そしてGSMMOには、元の日付を渡したり保持したりする設定がありません。結果として、あなたの過去のメールすべてが、今日届いたように見えてしまいます。

管理者の中には、特定のGoogle Workspace設定を有効にしてGSMMOを実行したり、GSMMOのプロファイル設定を調整したりを試した人もいます。しかしどれも日付の挙動には影響しません。Received:ヘッダーはGoogle側で追加されるものであり、クライアント側の設定変更では何も変わらないのです。

日付をおかしくする具体的なGSMMOシナリオ

すべてのGSMMO移行が日付の混乱に終わるわけではありませんが、ほとんどはそうなります。特に問題になるのは次の場合です。

• PSTファイルからGmailへ: 日付がおかしくなります。これは最も一般的なGSMMOの使い方であり、最も影響を受けるケースです。
• OutlookプロファイルからGmailへ: 日付がおかしくなります。PSTのインポートと同じGmail APIのアップロードが使われます。
• Exchange Online(Microsoft 365)からGSMMO経由でGmailへ: 日付がおかしくなります。GSMMOはExchangeサーバーから読み取り、Gmail APIを通じてアップロードします。
• オンプレミスExchangeからGSMMO経由でGmailへ: 日付がおかしくなります。同じ仕組みです。
• GmailからGmail(PSTエクスポートの再インポート): 日付がおかしくなります。PST内の元のメールの日付が正しかったとしても、再インポートすると新しい日付が付けられてしまいます。

パターンは明らかです。Gmail APIを通じてアップロードされたすべてのメッセージには、アップロード当日の日付が入ったReceived:ヘッダーが付きます。GSMMOは常にこの経路を使います。

特に厄介なのは、GSMMOの移行レポートがすべて成功と表示することです。日付に関する警告もエラーもフラグも一切ありません。これを見つけるには、移行前後のタイムスタンプを手作業で比較するしかなく、ほとんどの管理者はユーザーから苦情が来るまでそれをしません。

ソートを超えた影響

GSMMO移行後の間違った日付は、乱雑な受信トレイという以上の実際の問題を引き起こします。

Google Workspaceに移行したばかりの会計士だとします。税務申告のために、2024年第3四半期のクライアントとのやり取りをすべて見つける必要があります。Gmailで7月から9月までの日付範囲を指定して検索します。結果はゼロです。その期間のすべてのメールが今では移行日を表示しているため、Gmailの日付フィルターは何も見つけられません。数千件のメッセージをスクロールするか、キーワードで検索して正しい語句を覚えていることを願うしかなくなります。

規制業界にとっては、これは不便どころの話ではありません。メールのタイムスタンプは法的証拠として使われます。取引日より前に開示を送ったことを証明する必要があるファイナンシャルアドバイザーは、メールが2023年2月ではなく2026年4月を示していては、それを証明できません。SOXやHIPAAに基づくコンプライアンス監査は正確な通信タイムスタンプに依存しており、間違った日付は監査の失敗を意味します。

そしてスレッドの問題もあります。Gmailは日付と件名で会話をグループ化します。スレッド内のすべてのメッセージが同じ日付を示すと、会話表示は混乱します。返信が元のメッセージより前に表示されてしまいます。スレッド全体の構造が、同じ日付を持つメールの山に崩れてしまうのです。

Redate.ioでGSMMOの日付を修正する

良い知らせがあります。元のDate:ヘッダーは、移行されたすべてのメールの中に今も無傷のまま残っています。GSMMOはメッセージの内容を変更しません。正しい日付はそこにあるのですが、INTERNALDATEと先頭のReceivedヘッダーが移行日を指しているため、Gmailの表示ロジックによって無視されているだけなのです。

Redate.ioはGoogle Workspaceのメールボックスに接続し、GSMMO移行の影響を受けたメールをスキャンして、独自のヘッダーチェーン分析と日付再構築エンジンを使って日付のメタデータを修正します。Redateは、どのツールが移行を行ったかを知る必要はありません。表示されている日付が元の日付と一致しないメールを見つけ、メッセージの内容、添付ファイル、スレッドを変更することなく修正します。

修正された各メールは、メッセージの完全性、添付ファイルの保持、ラベルのマッピング、スレッドの整合性について個別に検証されます。元のメールは、あなた自身が削除するまで、あなたのメールボックス内のRedate.io - Originalsという目に見えるバックアップフォルダーに残ります。

自分でスクリプトを書いて直せるでしょうか。問題を理解することと、実運用中のメールボックスで12,000件のメールを、S/MIME署名を損なわず、入れ子になったMIMEパートを損なわず、RFC 2047でエンコードされたヘッダーを崩さずに修正することは、まったく別の話です。GSMMOがかろうじて保持したまま取り込んだ、38MBの添付ファイルと破損したMIME境界を持つメールをどう処理しますか。すべてのメッセージが無事に届いたことをどうやって一つ一つ検証しますか。ラボで20件のテストメッセージで動くスクリプトが、8年分のやり取りが入った実際のメールボックスに耐えられるとは限りません。

GSMMOのプラットフォーム別修正ガイド

GSMMOはGoogle Workspaceへの移行に特化しているため、修正はGmailのレベルで行われます。しかし影響を受けたメールは、そのGmailアカウントに接続されたすべてのクライアントで見えるようになります。

• GmailでのGSMMO移行日付の修正
• OutlookでのGSMMO移行日付の修正(Google Workspaceに接続)
• Apple MailでのGSMMO移行日付の修正

数か月前にすでに移行済みですか。元のDateヘッダーは時間が経っても劣化しません。Redate.ioは、移行が先週であっても3年前であっても、GSMMOの影響を受けたメールを修正できます。

GSMMO移行でメールの日付が間違っていますか? 無料スキャンを実行して、何にもコミットする前に、影響を受けたメールの正確な数と修正費用を確認してください。