iCloudからOffice 365移行後のメール日付ずれを修正する

日付を確実に壊す移行シナリオ

iCloudのメールボックスをOffice 365へ移行し終えた直後のことを想像してください。メールは揃っている、フォルダも整っている、一見すべて完璧です。月曜日の朝、最初の問い合わせが来ます。「古いメールが全部今日の日付になっているのですが」。そして2件目。気づけば10件。

これは孤立したバグではありません。iCloud MailからOffice 365への移行は、メール日付の破損として最もよく報告されるシナリオのひとつです。Apple Mailの挙動、IMAPプロトコルの仕様、そしてMicrosoft 365が受信メッセージを処理する方法、これら3つが組み合わさった結果として生じる、技術的に明確な問題です。

iCloud→Office 365で日付が壊れる理由

問題を理解するには、多くの人（経験豊富なIT管理者でさえ）が混同しがちな3つの概念を区別する必要があります。Date:ヘッダー、IMAPのINTERNALDATE、そしてファイルの作成日時です。

Date:ヘッダー（RFC 2822）

すべてのメールにはDate:ヘッダーが含まれており、メッセージが送信された日時を示します。このヘッダーはメッセージの生データの中に埋め込まれており、理論上は変更されません。厳密な意味での「元の日付」です。

IMAPのINTERNALDATE

IMAPプロトコル（RFC 3501で定義）は、各メッセージにINTERNALDATEと呼ばれる独立したメタデータを関連付けます。ほとんどのメールクライアントは、受信トレイでメッセージを並べ替えて表示する際にDate:ヘッダーではなく、このINTERNALDATEを使用します。Outlookは特にINTERNALDATEへの依存度が高く、表示と並べ替えの両方でこの値を使います。

問題は何か。移行ツールがあるIMAPサーバーから別のサーバーへメールをコピーする際、本来はこのINTERNALDATEを保持すべきです。実際には、そうならないことがあります。

Apple Mail特有の挙動

Apple Mailは、iCloudからメッセージを同期する際、サーバー側のファイル作成日時をINTERNALDATEの参照値として使用することがあります。これは厳密な意味でのバグではなく、IMAPの仕様に対する解釈の違いです。他のクライアントとは異なる実装になっています。（実際、生のIMAPのRFCを読んでINTERNALDATEの問題をデバッグしようとしたことがある方ならわかると思いますが、この点についてRFCの解釈にはかなりの余地があります。）

結果として、Apple Mail経由でiCloudからエクスポートまたは移行すると、Office 365に到着する前の時点で、メッセージのINTERNALDATEがすでに不正確になっている可能性があります。

iCloud移行の3つの方法とそれぞれの落とし穴

直接IMAP移行

最も一般的な方法は、iCloudをIMAPソースとして設定し、Office 365を移行先として設定したうえで、移行ツール（imapsync、MigrationWiz、あるいは独自ツール）を使用するものです。ツールが両サーバーに接続してメッセージをコピーします。

ここでの問題は二重になっています。まず、AppleのIMAPサーバーにはレート制限があり、ツールに一時停止を強いるため、接続が切れたり再接続したりする時間帯が生まれ、これが不正なINTERNALDATEを生む可能性があります。次に、Exchange OnlineへIMAP APPENDでコピーされた各メッセージは、ツールが挿入コマンドで元のINTERNALDATEを明示的に渡さない限り、デフォルトで移行時点の日時を受け取ります。

これを正しく処理するツールもあります。そうでないものも。40,000件のメッセージがある場合、エラー率が2%でも800件のメールが誤った日付を持つことになります。

imapsyncを使った移行については、Microsoft 365でのimapsync移行による日付破損の修正も参照してください。

.mboxまたは.emlエクスポートからのインポート

iCloudのメールをApple Mail経由で.mbox形式にエクスポートし、Outlookにインポートしようとするユーザーもいます。これは 手作業の方法であり、結果にはばらつきがあります。

.mbox形式はメールをテキストメッセージの連続として格納します。各メッセージのDate:ヘッダーに日付情報は存在しますが、メッセージ間の区切り行（"From "）には、一部のインポーターが作成日として解釈してしまう可能性のある日付が含まれます。Outlookは、.mboxを.pstに変換してインポートする際、メッセージ自体のDate:ヘッダーではなく、この区切り行の日付を使用することがあります。

Outlookによるドラッグ&ドロップ

最も大きなダメージをもたらす方法がこれです。ユーザーがOutlookで2つのアカウント（iCloudとOffice 365）を設定し、フォルダ間でメッセージをドラッグ&ドロップします。操作は簡単に見えます。日付にとっては壊滅的です。

Outlookが2つのIMAPアカウント間でドラッグ&ドロップによってメッセージを移動すると、実際には新しい.EMLファイルが生成され、移行先アカウントに挿入されて元のファイルが削除されます。この新しいファイルはWindowsのファイル作成日時、つまりドラッグ&ドロップした瞬間の日時を引き継ぎます。元のDate:ヘッダーはメッセージの本文中に残っていますが、Exchange Onlineのサーバーに記録されるINTERNALDATEは操作時点の日時になります。Outlookは移動されたすべてのメッセージにこの移行日を表示します。

正確に言うと、この挙動はOutlookのバージョンによって異なります。2023年秋のOutlookアップデート以降、一部のシナリオでは若干改善されましたが、アカウント間のドラッグ&ドロップは依然として日付破損の原因として記録されています。

Office 365とOutlookが実際に表示するもの

Exchange OnlineはメールをそのINTERNALDATEとともに保存します。Outlook デスクトップはこのINTERNALDATEを読み取り、「受信日時」列への表示と受信トレイの並べ替えに使用します。移行中にINTERNALDATEが上書きされていれば、Outlookは移行日を表示します。以上です。

Outlook Web App（OWA）も同様です。元のDate:ヘッダーの日付を表示する「代替ビュー」は存在しません。日付列に表示されるのはINTERNALDATEです。

元のDate:ヘッダーは常にそこに存在し、メッセージの生ヘッダーを表示すれば読むことができます。ただし、通常の表示では一切現れません。これがこの問題の核心にある苦しさです。正しい情報は存在しているのに、技術的な修正なしにはアクセスできない。

Microsoftサポートが解決してくれないこと

この問題でMicrosoftサポートにチケットを起票した場合、おそらくこんな回答が返ってきます。表示されている日付は保存されているINTERNALDATEに対応しているという確認、Outlookの並べ替え設定を確認する提案、そして場合によっては使用した移行ツールへの案内。

これは悪意があるわけではありません。Microsoftには、Exchange Onlineに取り込まれた何千ものメッセージのINTERNALDATEを事後的に修正するネイティブツールが単純に存在しないのです。修正には個々のメッセージにアクセスし、ヘッダーを解析し、日付のメタデータを再構築する必要があります。これは標準サポートの対象範囲外です。

iCloud側のサポートは、メッセージは正しくエクスポートされており問題は移行先にあると判断します。双方のサポートが責任を押しつけ合い、ユーザーは移行日を日付とした12,000件のメールを抱えることになります。

スケールの問題

日付が壊れた理由を理解することと、本番環境のメールボックスで手動修正することは、まったく別の話です。

スクリプトで修正を自動化しようとするIT管理者もいます。基本的な考え方を概念化すること自体は難しくありませんが、実際の大量データに対する実行には、手製スクリプトではうまく対応できない問題が数多くあります。

• S/MIMEで署名されたメールやPGPで暗号化されたメールは、暗号署名を無効にせずに変更できません
• 複雑なmultipart/alternative構造（HTML+プレーンテキスト+ネストされた添付ファイル）を持つメッセージは操作に脆弱です
• 非ASCIIでエンコードされたヘッダー（RFC 2047、特に日本語、アラビア語、キリル文字のケース）は、これらのエンコーディングを適切に処理しないツールによって破損する可能性があります
• Microsoft Graph APIのクォータとExchange Onlineのレート制限（429 Too Many Requestsエラー）は、指数バックオフを考慮して設計されていないスクリプトを止めてしまいます
• 500件のテストメールで正常に動作したスクリプトが、実際のメールボックスの8,000件目で深夜3時に止まり、再開の仕組みもない

そして最も重要な問い。修正後、個々のメールが無傷かどうかをどうやって確認しますか？添付ファイルはまだそこにありますか？スレッドは壊れていませんか？手製スクリプトは通常、この検証を行いません。

リデイト（Redate.io）がiCloud→Office 365移行をどう処理するか

Redate.ioはMicrosoft 365の権限（Azure AD）経由でOffice 365に直接接続します。iCloudサーバーへのアクセスは不要です。Redateが介入する時点で、メールはすでにExchange Onlineの中にあります。

Redateの修正エンジンは各メッセージのヘッダーチェーンを解析し、移行時に追加されたReceived:ヘッダーと正規の日付メタデータを区別しながら元の日付を特定します。この解析には既知の移行ツールシグネチャへのパターンマッチングが含まれており、不正なヘッダーがすぐには明らかでない場合でも識別できます。

修正された各メールは処理後に個別に検証されます。元のメールは30日間、目視確認できるバックアップフォルダに保存されます。これはどんな手製スクリプトにもデフォルトではない機能です。最初のスキャンは無料で、修正を決定する前に影響を受けているメールの正確な件数を把握できます。

Microsoft 365への移行後の日付修正については、Microsoft 365移行後のメール日付を修正する方法やExchange Online移行後のメール日付破損を修正するも参照してください。

まずスキャン、それから修正

iCloudからOffice 365への移行で日付が狂っている場合に推奨される出発点は、影響を受けたメールボックスでRedate.ioの無料スキャンを実行することです。スキャンにより、INTERNALDATEに問題があるメールが何件あり、どのフォルダに存在するかが正確に特定されます。

ボリュームによって12分から45分ほどかかりますが、何らかの介入を行う前に問題の全体像を明確に把握できます。移行後に複数のメールボックスを一括管理するMSPにとって、このバッチスキャンは修正が不要なメールボックスに手を加えることを防いでくれます。

iCloudからの移行後にメールの日付が狂っている場合は、Redate.ioの無料スキャンから始めてください。Office 365のメールボックスで問題がどこまで広がっているかを把握できます。