メール移行手順：T-7からT+1までの日別実行計画

メール移行の手順：停止時間を抑える日別スケジュール

メール移行は単なるファイルコピーではありません。利用者が両方の環境でデータを変更し続ける中、稼働中の二つのデータベース間で状態を切り替える作業です。データ層 (IMAP) とルーティング層 (DNS) の同期が崩れると、一部のメールは旧サーバーへ、残りは新サーバーへ届く分割ルーティングが発生します。

この手順書では、T-7からT+1まで日ごとの実行順序を示します。理論ではなく、実際の作業順序に絞っています。構成全体については、メール設定の完全ガイドをご覧ください。

管理する三つの層

メール移行には三つの層が関係し、どれか一つに問題が起きても停止につながる可能性があります。

1. データ層：既存のメール (IMAP)
2. ルーティング層：新着メールの配送先を決めるDNSレコード (MX)
3. アクセス層：Outlookやモバイルアプリなどのメールクライアント設定

T-7日：調査と整理

存在を把握していないデータは移行できません。利用者一覧だけでは完全な棚卸しにならないため、最初に全体像を明らかにします。

すべての対象を棚卸しする

• オブジェクト種別を洗い出す：メールボックス、エイリアス、配布リスト、パブリックフォルダー
• 巨大なメールボックスを特定する：20 GBを超えるメールボックスを探します。GoogleではIMAPのダウンロードが約2,500 MB/dayに制限されます。50 GBのメールボックスには数時間ではなく数週間かかる可能性があります。詳しい制限はGoogle Workspaceのデータ移行ガイドで確認できます。
• 不要なデータを整理する：退職者のメールボックスを有効なまま残す必要はありません。ローカルアーカイブへ書き出します。

Exchangeから移行する場合は、PowerShellで実際のアイテム数を取得します。圧縮の影響があるため、GB単位の容量だけでは正確に比較できません。

T-2日：事前同期

金曜の夜まで待たず、利用者が作業している間に履歴データの90%を移します。これにより、本番切り替え時のリスクを大幅に下げられます。

同期を開始する

移行ツールまたはimapsyncで、30日より古いメールを移行するよう設定します。HTTP 429 (Too Many Requests) やGoogle 11001エラーを監視してください。

把握しておくべき転送制限

Gmailの注意点：All Mailと各ラベルを別々のフォルダーとして同時に移行しないでください。Gmailのラベルは同じメッセージを参照しており、実体の複製ではありません。ただし、ラベルからフォルダーへの対応付けを誤ると、移行先に重複が生じる可能性があります。ラベルを慎重に対応付け、この方式ではGmail/All Mailを除外します。

T-1日：TTLを下げる300秒ルール

DNSレコードは24時間キャッシュされることがあります (TTL 86,400)。TTLの事前変更は、移行時に見落とされやすい作業です。先にTTLを下げずにMXレコードを変更すると、一部のリゾルバーは既存キャッシュが切れるまで旧サーバーへメールを送り続ける可能性があります。

1. DNSプロバイダー (Cloudflare、Route53など) にログインします
2. MXレコードを見つけます
3. TTLを300秒 (5分) に変更します
4. 古いレコードはまだ削除せず、TTLだけを変更します

digで確認します。

T-0 (金曜夜)：切り替え

利用者の作業が終わったら切り替えを実行します。ここが移行で最も重要な段階です。

ステップ1：変更を止める

利用者にメール送信を停止してもらいます。可能であれば移行元のアカウントをロックし、取り残されるメールを防ぎます。

ステップ2：差分同期

移行ツールをもう一度実行し、直近30日分と新しいアイテムを取得します。大部分のデータは移行済みですが、実際の所要時間はデータ量、変更量、プロバイダーの制限に左右されます。

UIDVALIDITYの問題に注意：移行元サーバーがフォルダーを再インデックスした場合、ツールが重複データを再ダウンロードする可能性があります。必ず最初にドライランを実行してください。UIDVALIDITYの詳しい意味はIMAP RFC 3501で説明されています。

ステップ3：MXレコードを切り替える

MXレコードを新しいプロバイダーへ向けます。TrekMailでは次の値を使います。

TTLが300秒なら、その値に従うキャッシュは約5分で更新される場合があります。ただし、別のリゾルバーや既存キャッシュではさらに時間がかかることがあります。

ステップ4：SPFとDKIMを更新する

新しいプロバイダーが送信を始める前に、新しい送信元IPアドレスをSPFへ公開して検証します。旧プロバイダーから送信する可能性がある間は、その許可も残してください。詳しくはドメインのメール認証設定ガイドをご覧ください。

T+1 (月曜朝)：検証

最後の段階では結果を検証します。成功したと決めつけず、実際に確認してください。

アイテム数を照合する

移行元と移行先のアイテム数を比較します。1%未満と5%超という値は、記録や調査を始めるための運用上のしきい値にすぎず、成功や失敗を断定する基準ではありません。差異ごとに原因を確認してください。大きな差は、フォルダー階層の制限やフィルター設定の誤りを示す場合があります。

メールクライアントを再設定する

メールクライアントを新しいアカウントへ切り替えます。クライアントとサービス変更の内容によっては既存プロファイルを安全に修正できますが、旧アカウントを削除して新しく追加する方が確実な場合もあります。

カレンダーと連絡先

TrekMailは企業向けのプロフェッショナルなメールホスティングを提供し、サーバー側カレンダーにはCalDAV、連絡先にはCardDAVを使用します。ただし、IMAP移行が転送するのは対応するメールとフォルダーだけで、これらのデータは対象外です。旧プロバイダーからカレンダーを.ics、連絡先を.vcfで書き出してから、TrekMailへインポートし、対応する各端末で同期を確認してください。

続行可否を判断する確認ゲート

ロールバック計画

新しいシステムがメールを拒否する場合や、重要なデータが不足している場合は次のように対応します。

1. MXを戻す：MXレコードを旧プロバイダーへ戻します。一部のキャッシュは5分で更新される場合があります。TTLが300sでも、その時間内に全体が復旧する保証はありません
2. 移行期間中の差分を書き出す：この期間に新しいプロバイダーへ届いたメールはすべてEML/MBOXで書き出し、旧サーバーへ取り込みます
3. 原因を調べる：再試行する前に550 5.7.1 (Relay Access Denied) やファイアウォールの遮断を確認します

TrekMailによるメール移行手順の自動化

手動の移行は作業量が多く、リスクも伴います。TrekMailはインフラ作業の一部を自動化し、顧客対応に集中できるようにします。

小規模企業向け

TrekMailの組み込み移行ツールは、対応するメールとフォルダーについて、IMAP接続、再試行、転送制限への対応を行います。認証情報を入力して処理を監視し、完了後には必ず移行元と最終照合してください。

代理店とMSP向け

100+ドメインを一括で設定できます。利用者ごとの上限ではなく、全顧客で使える共有ストレージを提供します。マネージドSMTPにより、独自IPのウォームアップ作業を減らせます。

すべての有料プランには14日間の無料トライアルが付きます (カードが必要)。Nanoプランにはカードが不要です。

まとめ

各段階が前の段階に依存するため、メール移行では決めた順序を守ることが重要です。TTLを事前に下げなければ、既存キャッシュの影響で分割ルーティングが最大24時間残る可能性があります。事前同期を省けば、切り替え時間が予定より大幅に長引くことがあります。

日程に沿って進め、アイテム数を照合し、ロールバック計画を準備してください。これが移行の基本です。

準備ができたら、無料のTrekMailアカウントを作成し、組み込みの移行エンジンで手作業を減らしましょう。