協栄興業のWeb・メール環境を再編する【第2回】-- 46,149通のメールを、新しいサーバーへ移す
NAMIKI ASSOCIATES前回の記事では、協栄興業のWebサイトとメール環境を、別契約のConoHa WINGへ統合することになった経緯と、移行に向けた準備について紹介しました。
今回は、その中でも最も慎重に進める必要があったメールの移行について書きます。
対象となったメールアカウントは9個。
長年使用しているアカウントには数万通のメールが蓄積されており、最終的に移行対象となったメールは46,149通になりました。
Webサイトであれば、バックアップから戻したり、一時的に旧サイトへ戻したりする方法があります。
しかし業務メールは少し事情が違います。
移行作業中にも新しいメールが届く可能性があり、過去のメールだけでなく、切り替えの瞬間まで届き続けるメールをどう守るかを考える必要がありました。
今回は、
ChatGPTで移行方法とリスクを整理し、Claude Codeが実際のサーバー調査と作業を行い、重要な切り替えは人間が確認・承認してから実行する
という方法で進めました。
ConoHa WING間でも、そのまま移せるわけではなかった
今回移行したのは、同じConoHa WING内にある2つの契約です。
一見すると、
同じサービスなのだから、ドメインを旧サーバーから新サーバーへ移せばよいのでは？
と思います。
ところが、実際にはそれほど単純ではありませんでした。
ConoHaのサポートへ確認したところ、旧サーバーから対象ドメインを削除すると、そのドメインで利用しているWebサイトとメールデータも削除されることが分かりました。
しかも、同じドメインを旧サーバーと新サーバーへ同時に登録しておくことはできません。
つまり、
旧サーバーからドメインを削除する前に、メールをConoHaの外へ安全に逃がしておく必要がある
ということです。
ここが今回の移行で最も重要なポイントになりました。
一時退避先としてVPSを使う
そこで用意したのが、別途構築していたConoHa VPSです。
VPSにはUbuntuを導入し、Tailscale経由でのみSSH接続できるようにしていました。
今回、このVPSをメールの一時退避場所（staging）として使うことにしました。
構成を単純化すると、次のようになります。
旧ConoHa WING
mail42
│
│ imapsync
▼
ConoHa VPS
staging
│
│ imapsync
▼
新ConoHa WING
mail64旧メールサーバーから直接新メールサーバーへ移せれば簡単なのですが、新側ではまだ同じドメインを使えません。
そこでいったんVPSへ全メールを退避し、
旧サーバー → VPS → 新サーバー
という二段階の移行にしました。
imapsyncで9アカウントを退避
メールのコピーにはimapsyncを使用しました。
imapsyncは、IMAPサーバー間でメールボックスを同期するためのツールです。
今回は、まず少量のメールしかないアカウントを使ってテストしました。
imapsync \
--host1 <旧メールサーバー> \
--user1 <旧メールアドレス> \
--host2 <退避先> \
--user2 <退避先ユーザー>※実際のホスト名、ユーザー名、パスワード、ディレクトリ構成などはセキュリティ上、一部省略・一般化しています。
いきなり9アカウントすべてをコピーするのではなく、
接続確認
→ TLS確認
→ 認証確認
→ 少量アカウントで試験
→ 結果確認
→ 残りのアカウント
という順番で進めました。
この方法なら、設定を間違えていても被害を小さくできます。
約4万通あるメールボックスもあった
9アカウントの中には、長年使ってきたため、INBOXだけでも約4万通あるメールボックスがありました。
そのため、メール移行は数分で終わるような作業ではありません。
重要なのは、コピー処理が「正常終了した」と表示されたことだけで判断しないことでした。
退避後には、
- メール件数
- フォルダー構成
- 重複
- エラー
- 実際のメールファイル
などを確認しました。
最初の退避では、全9アカウントで46,103通を確認しました。
ここまで確認したところで、まだ旧サーバーのドメインは削除していません。
「バックアップできたから削除」では危なかった
ここで今回、非常に重要なことが起きました。
全メールの退避が終わり、いよいよ旧サーバーからドメインを削除する直前。
念のため、旧メールサーバーとVPSの退避データをもう一度比較しました。
すると、退避後に届いた新しいメールが3通見つかりました。
もし、
さっきバックアップしたから大丈夫
と、そのままドメインを削除していたら、この3通は旧メールサーバーと一緒に消えていた可能性があります。
そこで新着メールをVPS側へ追加同期し、再度照合しました。
この経験から、メール移行では、
バックアップを取った時点ではなく、削除する直前の状態をもう一度確認する
ことが非常に重要だと分かりました。
旧ドメインを削除し、新サーバーへ登録
メールがVPSへ完全に退避されていることを確認してから、いよいよ本番切り替えです。
ここは自動化せず、人間が確認したうえで実施しました。
旧ConoHa WINGから対象ドメインを削除。
その後、新しいConoHa WINGへ同じドメインを登録しました。
続いて、
- DNS
- MX
- SSL
- メールサーバー
- IMAPS認証
などを確認し、新しい環境へ9個のメールアカウントを作成しました。
この時点で初めて、
旧 mail42
↓
VPS staging
↓
新 mail64の最後の矢印を進められる状態になりました。
VPSから新メールサーバーへ復元
新しいメールボックスが利用できることを確認してから、VPSへ退避していたメールを新サーバーへ戻します。
ここでもimapsyncなどを使い、アカウントごとに復元しました。
復元後は、単純に
新サーバーの総メール数が旧サーバーと同じ
という確認だけにはしませんでした。
移行作業中にも、新しいサーバーへ直接届くメールがあるためです。
実際、新サーバー側には切り替え後に届いた新着メールも存在しました。
そのため最終確認では、
VPSのstagingに存在したメールが、新サーバー側にすべて存在するか
を重視しました。
結果は、
stagingからの欠落 0
でした。
最終的に46,149通を確認
切り替え前後に届いたメールも含め、最終的に確認したメールは46,149通になりました。
9アカウントについて、
- 過去メール
- フォルダー構成
- 新着メール
- IMAPS認証
- 実際の送受信
を確認。
メール移行は完了しました。
今回改めて感じたのは、メール移行では「総数が合った」という確認だけでは不十分だということです。
コピー元、退避先、移行先には、それぞれ時間差があります。
そのため、
何を基準データとするのか
を先に決めておくことが重要でした。
今回はVPSのstagingを基準として、
stagingに退避したメールが新サーバーへすべて移ったか
を見ることで、欠落0を確認しました。
AIに全部任せたわけではない
今回の作業では、ChatGPTとClaude Codeをかなり使いました。
ただし、
AIにメール移行を丸投げした
わけではありません。
役割を分けました。
ChatGPT
- 移行全体の設計
- リスク整理
- 作業順序の検討
- Claude Codeへの指示書作成
- 作業結果のレビュー
Claude Code
- サーバーの現状調査
imapsyncなどの実行- 件数・ログ・ファイルの確認
- 結果のレポート作成
人間
- パスワードなど秘密情報の管理
- ConoHa管理画面の操作
- ドメイン削除など不可逆操作の承認
- 最終的な判断
- 実際のメール送受信確認
という分担です。
特に、
調査 → 報告 → 承認 → 実行 → 照合
という順番を崩さないようにしました。
AIが作業できるようになったからこそ、むしろ「どこで人間が止めるか」を決めておくことが重要なのだと思います。
一番印象に残ったのは「最後の3通」
46,000通以上のメールを移した今回の作業ですが、個人的に一番印象に残ったのは、最後に見つかった3通でした。
46,000通を安全にコピーしても、最後の3通を失えば「完全な移行」とは言えません。
バックアップ完了後にもメールは届きます。
だから、
退避
→ 確認
→ 削除直前の再同期
→ 再確認
→ 切り替え
という手順が必要でした。
これは今回実際に作業したからこそ分かったことでした。
次回は、最後に残ったWebサイトを本番へ
メールの送受信まで確認し、旧環境に残っていた最も重要なデータを安全に新環境へ移すことができました。
ただし、この時点ではまだ作業は終わっていません。
Webサイトは、新しいConoHa WING上に用意したテンポラリー環境で既に動作確認を済ませていました。
そのため、メールより先に正式ドメインへ切り替える必要はありませんでした。
まず失いたくないメールを確実に移す。
Webサイトはその後。
次回の第3回では、テンポラリー環境のWordPressを正式なkyoeikogyokk.co.jpへ移した作業と、そこからさらに発展したNAMIKI PROPERTYについて書きたいと思います。
既存サイトを「移す」だけだった作業が、結果としてサイトや不動産情報の見せ方そのものを「考え直す」作業へ発展していきました。
免責事項
この記事は、筆者自身の環境で実際に行った作業を記録したものです。
サーバー構成、契約内容、メールサービス、DNSの設定などによって適切な移行方法は異なります。
特にメールやドメインの削除・変更は、設定を誤るとメールやWebサイトの消失、メール不達などにつながる可能性があります。
実際に作業する場合は、利用しているサービスの公式情報を確認し、十分なバックアップを取得したうえで、ご自身の責任で実施してください。
＼ 最新情報をチェック ／
