新しいOutlook：移行後の日付エラーの本当の原因

2つのOutlook、同じメールに対する2つの動作

最近Microsoft 365へのメール移行を行い、古いメールがすべて移行日の日付で表示されるという苦情をユーザーから受けた場合、奇妙なことに気づいたかもしれません。従来のOutlookを使っているユーザーは読み取りウィンドウで正しい日付が表示されることがある一方、Windows版の新しいOutlookを使っているユーザーは一貫して移行日が表示される。同じメールボックス、同じメール。なのに結果が違う。

これは厳密な意味でのバグではありません。IMAP移行後の日付表示に直接影響するアーキテクチャ上の設計判断です。何が起きているかを理解するには、メールヘッダーとIMAPプロトコルの詳細に踏み込む必要があります。難解な内容ですが、クライアント側の操作だけでは問題を解決できない理由がはっきりわかります。

IMAP INTERNALDATE：本当の元凶

メールがIMAPサーバーに保存されると、共存しながらも混同してはいけない2種類の日付が存在します。

1つ目はDate:ヘッダーで、RFC 2822で定義されています。メッセージ本体に書き込まれた日付であり、送信者がメールを送った際に設定したものです。メッセージの一部として存在し、その後どんな経路をたどっても変わることはありません。

2つ目はINTERNALDATEです。これはメッセージの外側にあるIMAPサーバーが管理するメタデータで、サーバーがメッセージを記録した日時を指します。通常の移行では、まともなツールはINTERNALDATEを元の値のまま保持します。しかし設定が不適切だったり、このメタデータを正しく扱えないツールを使った場合、INTERNALDATEが移行当日の日付にリセットされてしまいます。結果として、移行された全メールがサーバーの目には同じ受信日として記録されます。

（imapsyncやMigrationWizのログを見たことがあれば、INTERNALDATEを保持しようとする専用オプションが存在することをご存知でしょう。それらが常に機能するとは限らず、移行先サーバーが設定を無視する場合もあります。）

従来のOutlook：日付の読み取り方

従来のOutlook、つまりローカルにインストールされたCOMベースのバージョン（Outlook 2016、2019、2021、Microsoft 365 Appsのデスクトップクライアント）は、メッセージ一覧に表示する日付を決定するために、少し複雑なメカニズムを使っています。

送信済みフォルダーのメールにはDate:ヘッダーを参照します。受信メールには優先的にサーバーのINTERNALDATEを使いますが、状況によっては（OSTキャッシュが関わる場合や、読み取りウィンドウでの初回表示時など）Received:ヘッダーの連鎖を読んで元の日付を近似的に再構築することもあります。

これが一貫性のない動作につながる理由です。従来のOutlookは読み取りウィンドウで正しい日付を表示できることがあります。詳細プレビューのためにメッセージの元のDate:ヘッダーを読むからです。ただし、メール一覧自体はおかしくなったINTERNALDATEを使い続けます。これは信頼できる動作ではなく、何も修正されていません。日付による並び替えはおかしいままで、日付検索も狂ったままです。

新しいOutlook：根本から異なるアーキテクチャ

2023年末から段階的に展開されているWindows版の新しいOutlookは、もはやCOMアプリケーションではありません。実質的に、Outlook on the web（OWA）と同じコードベースをベースにしたプログレッシブウェブアプリ（PWA）です。この刷新は根本的な影響をもたらします。

新しいOutlookは日付表示を完全にMicrosoft 365 APIに委ねています。Received:ヘッダーを読まず、元の日付を見つけるためにヘッダーの連鎖を掘り下げず、クライアント側での再構築も試みません。単純にサーバーから返されるものを表示する、つまりINTERNALDATEです。

結果として、移行中にINTERNALDATEがおかしくなっていた場合、新しいOutlookは迷わず各メールに移行日を表示します。例外なく、ニュアンスなく。従来のOutlookより一貫性があり予測可能な動作ですが、移行の問題が即座に目に見えるようになり、無視できなくなります。

金曜の夜に300のメールボックスを移行した管理者は、月曜の朝、新しいOutlookを使っている全ユーザーがアーカイブ全体に先週末の日付が付いているのを目にすることになります。チケットはすぐに殺到します。

クライアント側の回避策がうまくいかない理由

多くの管理者は、問題がサーバーのデータにあることを理解する前に、クライアント側での解決策を試みます。よくある試みと、それがうまくいかない理由を見ていきましょう。

「受信日時」ではなく「送信日時」で並べ替える

Outlookでの送信日時による並べ替えは、メッセージのDate:ヘッダーを参照します。これはおかしくなっていません。なので、この並べ替えは機能することがあります。でもこれは応急処置であって、解決策ではありません。日付検索はおかしいままです。日付ベースのルールも使い物になりません。そして何より、ユーザーは各フォルダー、各メールボックスを手動で設定し直す必要があります。300のメールボックスではそれは現実的ではありません。送信日ソートは解決策ではないのに、なぜ使い方を変えなければならないのか、エンドユーザーには理解できません。

Outlookのキャッシュを削除するか、プロファイルを再作成する

これはサーバー側のINTERNALDATEに触れません。プロファイルを再作成した後、Outlookはサーバーからメールを再同期し、まったく同じおかしくなったメタデータを取得します。キャッシュは問題ではありません。

OWAを代わりに使う

OWAと新しいOutlookは同じデータベースを共有しています。Exchange OnlineサーバーでINTERNALDATEがおかしくなっていれば、OWAもまったく同じ間違った日付を表示します。クライアントを変えてもデータは変わりません。

問題はサーバー側にあり、各メッセージのメタデータにあります。サーバー側に保存されているデータを、クライアント側の操作で修正することはできません。

Receivedヘッダーの罠：なぜすべてが複雑になるのか

移行ツールがIMAPを通じてあるサーバーから別のサーバーにメールをコピーする際、移行先サーバーは自動的にReceived:ヘッダーをヘッダーチェーンの先頭に追加します。挿入の日時とともに。これはRFCに準拠したSMTP・IMAPサーバーの正常な動作です。

これらのヘッダーはメールがたどった経路の逆順に蓄積されます。最新のものが先頭にきます。一部のメールクライアントは最初のReceived:を受信日の推定に使うため、元の日付ではなく移行日が表示されてしまいます。

補足として、この動作は特定のツールに限りません。BitTitan MigrationWiz、CloudM、imapsync、GSMMO、さらには2つのThunderbirdクライアント間での手動IMAPコピーでも、すべて同じ結果になります。メッセージの元のDate:ヘッダーは無傷のまま残ります。技術的に修正が可能なのはまさにそのためです。しかしINTERNALDATEは、サーバーが管理する別のメタデータであり、クライアント側でメッセージのヘッダーを操作するだけでは修正できません。

このメカニズムの詳細については、IMAP INTERNALDATEと日付が壊れる理由の記事で、このメタデータがサーバーによってどのように扱われるかを詳しく解説しています。

Microsoft 365でこの問題を引き起こす移行ツール

よく聞かれる質問があります。すべての移行ツールがこの問題を引き起こすのでしょうか？

短い答えは、設定と移行先のプラットフォームによる、ということです。Exchange Online / Microsoft 365では、サーバーがINTERNALDATEの管理において特に厳格です。保持しようとするツールでも失敗することがあります。Graph APIとEWS（Exchange Web Services）では、使用する挿入パスによって動作が異なるためです。

BitTitan MigrationWizはMicrosoft 365への移行で最も広く使われているツールの1つであり、日付の問題が最もよく文書化されているツールでもあります。Microsoft 365でのBitTitan移行による日付破損の修正のページでは、注意すべき具体的な設定をカバーしています。CloudMとimapsyncにはそれぞれ固有の特性があり、Microsoft 365でのCloudM移行による日付破損の修正とMicrosoft 365でのimapsync移行による日付破損の修正で解説しています。

これらすべてのツールに共通すること：元のDate:ヘッダーは移行を生き延びます。これが修正の技術的な基盤となります。

自作スクリプトがここでは危険な理由

問題を理解すると、解決策も簡単そうだという錯覚に陥ることがあります。本番環境のスケールでは、そうではありません。

Exchange Onlineに保存されているメールのメタデータを変更するのは簡単ではありません。MicrosoftのGraph APIは厳しいレート制限を課しています（深夜のバッチ処理で429 Too Many Requestsエラーはあっという間に発生します）。S/MIME署名付きまたはPGP暗号化されたメールは、署名を無効にしないよう特別な注意が必要です。大きな添付ファイルを持つマルチパート構造はネットワークタイムアウトの制約を生みます。そして最も重要なこと：コンテンツや添付ファイルを変えることなく修正が正しく機能したことを、メールごとにどう確認するのでしょうか。

50通のテストメールで問題なく動いたスクリプトが、8年分の履歴を持つ40,000通のメールボックスでは同じように動きません。エッジケースが何かを壊す可能性は、1,000通増えるごとに高まります。そしてロールバックの仕組みがなければ、途中でエラーが発生するとメールボックスは整合性のない状態になります。

利用可能なオプションの全体像については、Microsoft 365移行後のメール日付を修正する方法もあわせてご参照ください。

Redate.ioが具体的に行うこと

リデイト（Redate.io）は、それぞれがMicrosoftアカウントでサインインすることで、そのメールボックスだけを開きます。無料で日付が誤っているメールをスキャンし、特定されたメッセージに独自の修正エンジンを適用します。多段階分析パイプラインは、数百の既知の移行ツールのシグネチャとのパターンマッチング、RFCコンプライアンスの検証、そして正確な日付メタデータを再構築するためのヘッダーチェーン分析を実行します。

修正された各メールは個別に検証されます。元のメッセージは、表示可能なバックアップフォルダーに保管され、削除するまで残ります。料金モデルはメールボックスごとの1回払いで、サブスクリプションはありません。

新しいOutlookは正しい日付を表示します。データが隠されるのではなく、サーバーのデータが修正されるからです。

新しいOutlookで影響を受けているメールボックスがありますか？ Redate.ioで無料スキャンを開始すると、対応を決める前に何通のメールが影響を受けているかを正確に確認できます。