古いメールが全部同じ日付になっている場合

症状：古いメールが全て同じ日付に集まっている

ある朝、OutlookやGmail、Apple Mailを開くと何かがおかしい。数百件、場合によっては数千件の古いメールが全て同じ日付を表示しています。数日前や数週間前の日付です。2021年や2019年、2016年のメッセージが昨日届いたかのように見えているのです。日付順の並び替えはまったく意味をなしません。去年の重要なメールを探そうとしても、同じ日に届いたように見える何千件ものメッセージに埋もれてしまっています。

新しいメールは正しい日付で表示されています。影響を受けているのは古いメッセージだけです。

一体何が起きたのでしょうか？

最初の反応：ソフトウェアのせいにする

当然、バグを疑います。Outlookがクラッシュした、更新がうまくいかなかった、ファイルが壊れた。そして、よくある悪循環が始まります。「Outlook 日付 バグ」で検索すると、OSTファイルやSCANPST.exe、Outlookプロファイルをゼロから作り直す方法を話しているフォーラムが出てきます。

2時間かけて全て試してみる。問題は解決しない。

ちなみに、SCANPSTはOutlookのローカルデータファイルを修復するツールです。特定のファイル破損は直せますが、メールサーバー上に保存されたデータには触れません。つまり、OSTファイルを完璧に修復しても日付は間違ったままです。問題はあなたのコンピュータ側にないからです。

問題はサーバー上のメール自体の中にあります。

実際に何が起きたか：移行の影響

ほぼ全てのケースで、この症状はメール移行の後に発生します。会社が古いシステムからGoogle Workspace、Microsoft 365、または新しいサーバーに乗り換えた際に、誰かがツールを使って全てのメールをある場所から別の場所に転送したのです。

その移行について知らされていなかったかもしれません。あるいは知っていたが、日付の問題と結びつけていなかっただけかもしれません。それはごく自然なことです。

移行ツールは膨大な仕事をこなしています。何千件ものメッセージ、フォルダ全体、添付ファイルをコピーするのです。しかし、やっかいな副作用があります。メールがあるサーバーから別のサーバーに転送される際、ツールはメールに「Received:」と呼ばれる小さな技術的な行を追加します。これは新しいサーバーにメッセージが届いた日時、つまり移行日を記録します。

これが問題の核心です。

メールクライアントが表示する日付を決める仕組み

実は、メールには技術データの中に複数の日付が含まれています。通常表示される元の送信日付だけでなく、インターネット上でのメッセージの各経由地を記録する「Received:」ヘッダーも存在します。

（メールの「ソースを表示」や「全ヘッダーを表示」をクリックしたことがあれば、あの意味不明なテキストのブロックのような暗号めいた行を見たことがあるかもしれません。まさにそれです。）

通常、メールソフトは最新の「Received:」ヘッダーを見てメールをいつ表示するかを判断します。このロジックは完璧に機能します。最後の「Received:」は常に送信後数秒以内にメールボックスにメッセージが届いた時刻と一致するからです。

しかし移行後は、このロジックが逆効果になります。移行ツールが転送日時を含む新しい「Received:」ヘッダーを一番上に追加したのです。メールソフトはそのヘッダーを最初に読み、移行日を見て、それを表示します。元の送信日付は今もそこに、メールのデータの奥に完全な形で存在します。しかしメールソフトは最初のヘッダーで止まってしまうので、それを見てくれないのです。

結果：8,000件のメールが全て同じ11月の火曜日に届いたように見えてしまいます。

どの移行ツールがこの問題を引き起こすか

主要な移行ツールは全てこの動作をします。BitTitan MigrationWiz、CloudM、imapsync、GSMMO（OutlookからGoogleへの移行用の無料ツール）、その他多数。これはツール側の欠陥というわけではありません。メールプロトコルの技術的な仕組みの結果です。これらのツールがヘッダーを追加するのは、メッセージがあるサーバーから別のサーバーに転送される際にプロトコルがそれを想定しているからです。

問題なのは、ユーザーにそれが起きることを誰も事前に教えてくれないことです。

会社が最近メールシステムを変更した場合、あるいはIT部門が「クラウド移行」を行った場合、これがほぼ確実に問題の原因です。影響を受けている日付を確認することで検証できます。それらは全ておおよそ同じ時期に集中していますか？そうであれば、その時期が移行が行われた時期です。

避けるべき間違ったアプローチ

フォーラムでよく見かける解決策がありますが、どれも効果がありません。

SCANPSTでデータファイルを修復する

先ほど触れましたが、SCANPSTはOutlookのローカルファイル（コンピュータ上の.pstや.ostファイル）を修復します。サーバー上のメールは変更しません。修復後も、メール自体の中にある日付は変わらないので、同じ間違った日付のままです。ローカルファイルの問題ではないからです。

Outlookプロファイルを再作成する

同じ理屈です。Outlookプロファイルを再作成するとは、ローカルをまっさらな状態にして、サーバーから全メールを再ダウンロードすることです。再ダウンロードされたメールは以前と全く同じ間違った日付を持っています。全て再設定するのに時間を無駄にしただけです。

「受信日時」の代わりに「送信日時」で並び替える

Outlookの並び替え基準を受信日時から送信日時に変更することを提案するフォーラムもあります。場合によってはある程度助けになることもありますが、常にそうではありません。また、他のソフトウェア、他のデバイス、あるいはあなたのメールボックスにアクセスする他の人にとっては何も解決しません。根本的な原因は残ったままです。送信日時での並び替えは解決策ではなく、応急処置にすぎません。

メールソフトを再インストールする

いいえ。メールはサーバー上にあり、ソフトウェアの中にあるのではありません。Outlook、Gmail、Apple Mail、Thunderbirdを再インストールしても、オンラインに保存されたデータは何も変わりません。

朗報：本当の日付はまだそこにある

重要なことがあります。修正を可能にするのはまさにこの点です。各メールの元の送信日付は削除されていません。「Date:」と呼ばれるヘッダーの中に、今もメールの中に存在しています。これは送信者が設定した送信日付です。これは全ての移行ツールが遵守しているメール標準（RFC 2822という技術仕様で定義されています）であり、変更することは重大な標準違反になります。

つまり、2022年3月14日にメールを受信していれば、そのメールのデータのどこかにまだその日付が含まれています。ただ、メールソフトが最初に表示する日付でなくなっているだけです。

これがまさに修正を可能にするものです。データが失われているわけではありません。メタデータの読み方の問題なのです。メールソフトが間違った日付を読んでいますが、正しい日付は常にそこに存在しています。

自分で修正しようとするのが危険な理由

IT担当者がスクリプトを書いて問題を修正できるのではないかと思うかもしれません。何が起きているかを理解することと、何千件ものメールを一件も失わずにきれいに修正することは、全く別の話です。

メールは単純なテキストファイルではありません。添付ファイル、電子署名、複雑なフォーマットでエンコードされたコンテンツが含まれている場合があります。そのようなメッセージの構造を崩さずにメタデータを変更するには、数十のエッジケースを処理する必要があります。電子署名されたメッセージ（S/MIME）、暗号化されたメール（PGP）、非標準のエンコーディング、マルチパート構造... 20件のテストメールで動作した自作スクリプトは、15,000件のメッセージがある本番メールボックスでは正しく動作しないでしょう。何か問題が起きた場合、メールが壊れたり失われたりしていないことをどうやって確認しますか？自作スクリプトでは：不可能です。

メール一件ごとの個別バックアップと検証の仕組みがなければ、副次的な被害のリスクは現実のものです。

Redate.ioができること

リデイト（Redate.io）はまさにこの問題のために設計されたサービスです。メールボックス（Google Workspace、Microsoft 365、またはIMAPサーバー）に接続し、移行によって日付が変わってしまったメールを特定して、完全なヘッダーチェーンを解析し各メッセージの日付メタデータを再構築する独自エンジンで修正します。

修正された各メールは個別に検証されます。オリジナルは30日間、見えるバックアップフォルダに保存されます。何か問題があれば、元に戻すことができます。

初回スキャンは無料です。Redate.ioはメールボックスを分析し、何かを決める前に何件のメールが影響を受けているかを正確に表示します。サプライズはありません。

料金は修正するメール数に基づく1回限りの支払いです。サブスクリプションはありません。一度支払えば、問題は解決します。

何も決める前に被害の全容を把握したいですか？Redate.ioで無料のメールボックススキャンを実行して、何件のメールが影響を受けているかを数分で確認してください。