メールボックスをひとつ別のサービスへ移すだけなら、六つの項目を入力するフォームで済むこともあります。しかし、百人分の一括移行は別の問題です。単に量が増えるだけでなく、気づきにくい失敗が起きる機会も増えます。パスワードの誤り、四十回目の接続を過ぎたあたりで制限をかける移行元サーバー、4,000 件でコピーが止まったのに、全 12,000 件を移し終えたように表示されるフォルダーなどです。
CSV は繰り返し作業を減らします。ひとつのファイルから一括処理を登録し、並列に実行しながらメールボックスごとの進捗を確認できます。ただし、移行の成否を判断するには、進捗バーが完了した後の確認が必要です。すべてのツールが、実際に届いたメールまで調べるわけではありません。
この記事では、ファイル形式、接続前の行データの検証、処理中の動作、コピー後の照合について説明します。
一括移行用の CSV を作る前の準備
前提条件はふたつです。どちらかを忘れると、一晩を無駄にすることもあります。
移行先のメールボックスは、あらかじめ作成してください。移行処理はメールを既存のメールボックスにコピーするもので、メールボックス自体は作成しません。百人分を用意する場合は、先に一括作成を行います。管理者が設定したパスワードを含む CSV を使う方法と、各利用者が自分でパスワードを設定できるよう招待を送る方法があります。
移行先のパスワードは不要です。ご自身のアカウントに属するメールボックスへの認証は、サービス内部で行われます。そのため、CSV に入れるのは移行元の認証情報だけです。他のツールでは両側の情報を求められる場合があります。その場合はファイルの保護が特に重要ですが、それだけで不正利用の証拠になるわけではありません。
一括移行のファイル形式
すべてのメールボックスが同じサービスにある場合は、三列で足ります。サーバー設定には、フォームで選んだサービスの設定が使われます。
source_email,source_password,destination_email
alice@oldhost.com,app-pw-1,alice@yourdomain.com
bob@oldhost.com,app-pw-2,bob@yourdomain.com六列の形式なら、複数の移行元を混在させられます。たとえば、買収した会社の一部が Google Workspace、残りが cPanel サーバーを使っている場合です。以下の例は、各サービスがパスワード認証を許可していることを示すものではありません。
source_email,source_password,destination_email,source_host,source_port,source_security
alice@gmail.com,app-pw-1,alice@yourdomain.com,imap.gmail.com,993,ssl
bob@outlook.com,app-pw-2,bob@yourdomain.com,outlook.office365.com,993,ssl
carol@oldhost.com,pw-3,carol@yourdomain.com,mail.oldhost.com,993,sslファイルは手作業でも、さまざまなソフトのエクスポートでも作られるため、読み込み時には一般的な形式の違いを認識します。
| 項目 | 内容 |
|---|---|
| ファイルサイズ | 最大 2 MB |
| 文字コード | UTF-8 で保存してください。対応していない文字コードは、データを黙って変更せずに拒否します |
| ヘッダー行 | 任意。自動で認識します |
| 区切り文字 | カンマ、タブ、セミコロンを自動で認識します |
| 空行 | 読み飛ばします |
| コメント | # で始まる行は読み飛ばします |
| メールアドレス | 小文字に変換し、前後の空白を取り除きます |
| 一括処理の行数 | 原文では Starter が 100、Pro が 300、Agency が 1,000。現在の上限を確認してください |
Excel を使う場合、セミコロンへの対応は重要です。地域設定によっては、CSV の区切り文字にセミコロンが使われます。カンマしか認識しないツールでは、行全体がひとつの列として読まれる可能性があります。
表計算ソフトには注意してください。=、+、- で始まるパスワードは、数式として解釈され、保存時に変わることがあります。テキストエディターで作成するか、パスワード列を明示的に文字列として取り込み、書き出した内容を確認してください。CSV の値を引用符で囲むだけでは、パスワードの保持を保証できません。
移行元の認証情報を集める作業が難所です
各メールボックスについて、移行元に接続できる IMAP の認証情報が必要です。この CSV はパスワードを使いますが、すべてのサービスがその認証方式を受け付けるわけではありません。情報を集める前に、対応状況を確認しましょう。
| 移行元 | 必要なアクセス方法 |
|---|---|
| Gmail / Google Workspace | アカウントと管理者のポリシーで許可されている場合は、アプリ パスワード。アカウントの 2 段階認証が必要です |
| Microsoft 365 | Exchange Online では IMAP の基本認証を再び有効にすることはできません。対応した OAuth の認証手順か、別のサポート対象の方法が必要です。パスワードを入れるこの CSV では代用できません |
| Yahoo、AOL、iCloud | サービスとアカウントがそのアクセスを許可している場合は、アプリ用パスワード |
| cPanel と従来型のホスティング | サーバーが IMAP のパスワード認証に対応している場合は、メールボックスのパスワード |
百人から百個のアプリ用パスワードを集めることが、移行で最も手間のかかる作業になる場合もあります。完了日を約束する前に考慮してください。移行元の管理権限があれば、使えるアクセス方式と、認証情報をまとめて生成できるかを確認します。権限がなければ、画面付きの説明を送り、操作の支援が必要な人のために時間を確保しましょう。
移行が終わり、確認や追加のコピーにも不要になったら、CSV を削除してください。有効な認証情報が入っています。複製したファイルも管理し、一時的なパスワードは可能な範囲で失効させます。
接続する前に検証する
データを貼り付けるかファイルをアップロードし、プレビューと検証を選びます。移行用の接続を開く前に、行が分類されます。
- 準備完了：事前検証を通過し、キューに登録できます。
- エラー：不正なアドレス、パスワードの欠落、存在しない移行先メールボックスなどです。該当する行は除外されます。
- 警告：この移行先には最近メールを移しています。重複インポートの可能性を確認してください。
- 重複：同じ移行元と移行先の組み合わせが、ファイル内に複数あります。
- 上限超過：プランで許可された一括処理の行数を超えています。
ファイルを修正し、必要なだけプレビューを繰り返せます。この段階ではコピーは始まらず、パスワードが使えることも確認できていません。「移行先メールボックスが見つからない」という検証は特に役立ちます。ドメイン名の入力ミスが百行に及んでいても、接続してから問題が発覚する事態を避けられます。
一括移行の重要な設定
対象フォルダー。すべてのフォルダー、標準フォルダーのみ（受信トレイ、送信済み、下書き、ごみ箱、アーカイブ、迷惑メール）、または受信トレイのみを選べます。標準フォルダーに絞ると、同じメールを複数回表示する一部の仮想ビューやラベルを避けられます。ただし、独自のフォルダーを残したい場合には不十分です。必要な範囲を開始前に決めてください。
インポート開始日。対象とする最も古い日付です。十一年分ではなく二年分をコピーすれば量は減りますが、それ以前のメールは除外されます。残す必要があるメールと、別途移すメールをチームで決めましょう。
重複をスキップ。追加の移行では有効にしておきます。認識済みのメールの再インポートを減らせますが、すべての状況で重複がなくなるわけではありません。使える識別情報がない場合などは、結果の確認が必要です。
一括処理の名前。内容が分かる名前を付けてください。三週間後には、時刻だけの名前より「Acme、フェーズ 2」のほうが役に立ちます。
一括移行の処理中に起きること
アカウントはプランの上限内で並列に処理されます。原文では Starter が 2、Pro が 5、Agency が 10 です。現在の設定を確認してください。移行元は接続やリクエストを制限することがあります。同じアドレスから四十本の IMAP 接続を同時に開くと、制限や一時的なブロックにつながる可能性がありますが、反応はサービスによって異なります。
各アカウントは、キュー待ち、開始、検証、計画、パーセント表示付きのインポートを経て、完了、失敗、キャンセルのいずれかになります。ページを閉じても、サーバー上の処理は続きます。
処理中には三つの操作が使えます。
- すべてキャンセルは、実行中と待機中のアカウントに停止を要求します。インポート済みのメールは削除しません。
- 失敗したものを再試行は、失敗したアカウントだけをキューに戻します。移行元のパスワードが原因なら、先に修正してください。
- 再開は、一時停止した一括処理を続けます。
アカウントのストレージ使用率が 90% に達すると、一時停止してメールで通知する仕組みがあります。コピーの途中で容量を使い切る危険を減らしますが、残りすべてを移せる容量を保証するものではありません。空きを増やすか容量を拡張し、部分的な結果を確認してから再開します。
一括処理の終了時にも通知が届きます。半数を超えるアカウントが失敗した場合には、別の警告が用意されています。五十件の個別の問題ではなく、移行元のアクセス制限など共通の原因がある可能性があります。確認にはエラーの調査が必要です。
進捗バー完了後の照合
移行ツールを選ぶときに、特に確認したい失敗の形です。
IMAP のコピーは、多数の個別操作で成り立っています。接続の切断、フォルダーの途中での制限、移行元からの不完全な一覧によって、メールが残ることがあります。ツールは受け取った情報をすべて処理したため、成功と表示するかもしれません。進捗は 100%、画面には問題が見えなくても、四千件のメールが欠けている可能性があります。
そこで、追加の照合処理が用意されています。自動照合が有効で、移行が設定されたメッセージ数のしきい値を超えた場合は、五分の遅延を付けて照合を予約します。キューの状況によって実際の開始は遅れることがあります。フォルダーごとに、移行元と移行先の一意な Message-ID の集合を比較します。このヘッダーは通常コピー後も残りますが、欠けていたり使い回されていたりする場合があります。そのため、すべてのメールの存在や内容全体の完全性を証明する比較ではありません。確認できる範囲が不十分なら、結論が出ないこともあります。
メールの欠落が確認された場合は、三つの処理が用意されています。
- 該当するメールとフォルダーの報告を、移行記録に保存します。
- 不完全なフォルダーを一部移行済みとして扱い、再開時に完了済みとして飛ばさず、再処理できるようにします。
- フォルダー名、検出した不足件数、次の対応をメールで知らせます。
照合の対象は、移行計画に含まれるフォルダーだけです。意図的に除外したものは、その除外を理由に欠落として報告しません。たとえば Gmail のすべてのメールには、他のラベルでも見えるメールに加えて、アーカイブされたメールが含まれる場合があります。選んだ範囲で必要なメールを網羅できるか確認してください。
不完全な移行を知らせるメールは歓迎できませんが、移行元が残っている間に対応できます。十一月になって三月の請求書がないと気づくよりはよい結果です。不足が検出されなかった報告でも、照合範囲の確認や手作業のチェックは省略できません。
切り替えの手順
コピーは作業の一部にすぎません。切り替え前後の順序によって、管理すべきリスクが変わります。
- 移行先のメールボックスを作成し、ログインできることを確認します。
- 最初の移行を実行します。この時点では MX を旧サービスに向けたままにします。移行元は引き続き使われるため、認証情報を保護し、サービスを止めないようにしてください。
- 結果を確認します。報告と照合範囲を読み、いくつかのメールボックスでフォルダー、件数、最古と最新のメールを確認します。
- MX を切り替えます。その一日か二日前に TTL を下げておきます。元の TTL が切れている必要があり、変更はすべての送信元に即座に反映されるわけではありません。
- 二回目の移行を実行し、重複をスキップして、切り替え中に旧サービスへ届いたメールを取り込みます。キャッシュや実際のメールの流れによっては、さらに確認や追加のコピーが必要です。
- 旧メールボックスを一か月残すことを計画の目安にします。保管義務と確認結果に応じて期間を調整してください。移行を確認する前に移行元を解約しないことが重要です。削除後は再コピーできない場合があります。
旧サービスを使い続けるなら、統合受信トレイが移行の代わりになることもあります。機能と費用を比較してください。移行元別の手順は、Google Workspace、Microsoft 365、cPanel のドキュメントにあります。記載されたアクセス方法が現在も使えるか確認しましょう。
よくある質問
一回の一括処理で何個のメールボックスを移せますか？
原文では一括処理あたり Starter が 100、Pro が 300、Agency が 1,000 です。処理内では、プランに応じて 2 から 10 アカウントを同時に扱います。現在の上限と移行元の制限を確認してください。この上限は負荷を抑えますが、他の制限をなくすものではありません。
移行先のパスワードは必要ですか？
不要です。CSV に入れるのは移行元の認証情報だけで、ご自身のアカウントに属するメールボックスへの認証は内部で行われます。
すべてを重複させずに再実行できますか？
重複をスキップする設定を有効にしてください。追加の処理は、認識済みのメールを再コピーせず、不足分を加えようとします。MX 切り替え後の追加移行に役立ちますが、使える識別情報がないメールが含まれる場合は特に結果を確認してください。
移行元のパスワードが間違っていたらどうなりますか？
そのアカウントは失敗し、他のアカウントは処理を続けられます。パスワードを修正して失敗したものを再試行を使うと、失敗分だけをキューに戻せます。サービスが別の認証方式を求めている場合は、パスワードを変えるだけでは解決しません。
フォルダーと既読状態は残りますか？
移行は、選んだ範囲と移行先の機能に応じて、フォルダーや既読、スターなどのフラグを保持しようとします。Gmail のラベルは IMAP のフォルダーと完全には対応しません。標準フォルダーだけにすると一部の扱いは簡単になりますが、独自のフォルダーやアーカイブ済みメールが除外される場合があります。必要な対象を確認してください。
メールが欠けていないことをどう確認しますか？
照合が有効で実行条件を満たしていれば、両側の一意な Message-ID を比較します。確認された欠落は通知され、該当フォルダーは一部移行済みになります。照合範囲も確認してください。使える識別情報がないメールの存在は、この比較では証明できません。件数を比べ、各フォルダーの最古と最新のメールを開き、重要なメールでは追加の確認を行います。
API から移行を管理できますか？
対応している操作は、必要な権限があれば REST API や MCP で接続する AI エージェントから管理できます。各インターフェースが実際に対応する操作、特に一括処理や再試行については、移行 API のドキュメントで確認してください。
どのくらい時間を見ておけばよいですか？
データ量、メールの件数、両側の性能、移行元の制限が所要時間に影響します。原文では、小規模なチームは数時間、大規模なチームは一晩を計画上の目安にしていますが、保証された時間ではありません。試験的に移行し、MX 切り替え前に最初のコピーを始めてください。切り替えを急がずに計画を調整できます。
