アフィリエイト広告を利用しています

【メールサーバー移行】独自ドメインのメールを一通も落とさず、無停止で別サーバーに引っ越す(Claude Codeを相棒に)

こんにちは、今日はメールサーバーの引っ越しの話。

結論から言うと、独自ドメインで運用している30を超えるメールアドレスを、一通も落とさず、受信も止めず、別のレンタルサーバーへまるごと移行できた。本当に、ホッとした仕事でした。

そして今回いちばん伝えたいのは、この一連の作業を、ぜんぶ Claude Code を相棒にして進めた、ということ。計画づくりから、自動化スクリプト、進捗ダッシュボードの自作、トラブルの原因調査、そして”欠損ゼロ”の証明まで。AIと会話しながら、その場で道具を作っては試す、を高速で回していける。この進め方が、仕事の質そのものを変えていく感覚があった。

「サーバーの乗り換えなんて、設定を移すだけでしょ」と思うかもしれない。僕も昔はそう思っていた。が、独自ドメインのメールを”止めずに”引っ越すのは、かなり神経を使う。今回ハマったところと、どう乗り切ったか、そしてClaude Codeがどう効いたかを残しておきます。

いちばんの壁は「同じドメインを二重登録できない」

今回の移行元も移行先も、同じ系列のレンタルサーバーだった。

ここで問題。多くのレンタルサーバーは、同じドメインを別々の契約に「同時に」登録できない。つまり、古い契約から削除してからでないと、新しい契約に登録できない。

順番が、避けられない。「削除 → 登録」。

で、この”削除してから登録するまでの空白時間”が怖い。この隙間に、外からメールが一通でも届くと、受け取るサーバーが存在しないので、送り主に「宛先不明(550エラー)」が即座に返る。そのメールは、二度と戻ってこない。

メールは、失われると取り返しがつかない。ここがいちばん神経を使うところ。

ConoHa WINGを中継にして、MXを2段階で切り替える

そこで考えた作戦が、あいだにもう一台、中継サーバーを挟むこと。

今回はConoHa WINGを中継役にした。メールの宛先(MXレコード)の向き先を、こう動かす。

旧サーバー → 中継(ConoHa) → 新サーバー。

いきなり旧から新へ飛ばすと空白ができるが、あいだにConoHaを置くことで、どの瞬間も「必ずどこかで受信できる」状態をキープできる。空白がゼロなら、バウンスもゼロ。

先に中継へ向けておいて、そのあいだに旧サーバーの中身を全部コピー。移行先の準備が整ったら、中継から新サーバーへ切り替える。受信の受け皿を、一度も絶やさない。

この「絶やさない」が今回の設計の肝でした。

過去メール11万通・10GBを imapsync で運ぶ

過去のメールの移行は、imapsync というツールを使った。IMAPのメールボックスを、サーバーからサーバーへ、一通ずつ丸ごとコピーしてくれる定番ツール。

全部で、11万通ほど。容量にして10GBぐらい。夜に流して数時間、という規模。

imapsyncの良いところは、何度実行しても安全なこと。すでにコピー済みのメールはスキップして、差分だけを運んでくれる。だから切り替えの直前にもう一度流せば、その時点の最新状態でスタートできる。

ひとつ気をつけたのは、パスワードの扱い。台帳にはメールアドレスとパスワードが並ぶ。これを画面にもログにも、プロセス一覧にも一切出さない設計にした。パスワードは一時ファイル経由で渡して、使い終わったらすぐ消す。

このあたりは、自己責任の作業になります。人様のメールを預かるので、パスワードの管理はいくら慎重でも慎重すぎることはない、と思っている。

つまずき — メモリ不足でVMが落ちた

順調かと思いきや、途中でつまずいた。

移行の後半、いくつかのメールボックスで処理が突然「強制終了」になる。ログを見ると、原因は、メモリ不足。

Docker(Colima)で動かしていたのだけど、割り当てていたVMのメモリが2GBしかなく、巨大なメールボックスを処理するときにパンクしていた。

colima stop してから、メモリを8GBに増やして再起動。

そして、落ちたぶんだけ個別に流し直す。imapsyncは差分同期だから、すでに運んだぶんはスキップして、続きから積み上がる。再実行に強いって、こういうときに本当にありがたい。

もうひとつ、地味にハマったのが、中継サーバー側のパスワードの仕様。記号必須とか文字数制限とかがあって、旧サーバーと全く同じパスワードが使えないアドレスがいくつかあった。ここは例外として個別に対応する仕組みをツール側に足して乗り切った。

進捗が見えなくて不安だったので、ダッシュボードを自作した

11万通の同期は、数時間かかる。

これがまた、待っているあいだ、いま何割終わったのか、どのアドレスを処理中なのか、失敗していないか、が見えなくて不安になる。ターミナルのログを目で追うのもしんどい。

なので、進捗をリアルタイムで表示するダッシュボードを自作した。ブラウザで開くと、完了したメールボックス数、転送したデータ量、いま処理中のアドレス、失敗の有無が、3秒ごとに自動で更新される。

これが、まさにClaude Codeの真骨頂だった。「同期の進捗を、ブラウザでリアルタイムに見たい」と伝えるだけで、ログを解析して状況を返す小さなサーバーと、それを表示する画面が、その場でできあがる。ダークモード対応まで、ついでに。

正直に言うと、一人でやっていたら、このダッシュボードは作らなかったと思う。「そこまでするのは大げさかな」と、ログを目で追って済ませていたはず。でも相棒がいると、「じゃあ作っちゃおう」の一言で数分でできてしまう。この身軽さが、仕事の丁寧さそのものを底上げしてくれる。

作ってみたら、精神衛生が段違いに良くなった。「あと何割」が見えるだけで、こんなに安心するとは。

ちなみにこのダッシュボードも、台帳のパスワード列は一切読まない作りにしてある。表示するのはアドレスとメモと容量だけ。ここも「パスワードは絶対に画面に出さないで」と最初に伝えて、その方針で作ってもらった。

「本当に全部移ったか」を件数照合で証明する

移行でいちばん大事なのは、たぶんここ。

「たぶん全部移った」ではなく、「全部移った」を証明すること。

移行元と移行先で、アドレスごとにメールの通数を突き合わせる。移行先の通数が移行元以上なら、欠損なし。この照合を、全アドレスで実施して、記録に残した。

結果は、全アドレスで欠損ゼロ。数字で確認できると、はじめて安心して次に進める。

(ちなみに、2アドレスだけ通数が1通ずつ少なく出たが、これは旧サーバー側に完全に同一の重複メールがあって、ツールが1通にまとめたもの。中身は失われていない、とログで確認済み。こういうときに「なぜ1通ずれたか」を説明できる状態にしておくのが大事。)

SPF/DKIM/DMARC、そして送受信・転送を実地で確認する

DNSの切り替えでは、MXレコードだけでなく、なりすまし対策の設定も引っ越す。SPF、DKIM、DMARC。ここを疎かにすると、送ったメールが相手先で迷惑メール扱いされる。

切り替え後、実際に外からテストメールを送って、ヘッダーを1行ずつ確認した。SPF pass、DKIM pass、DMARC pass。通信もTLS1.3で暗号化されている。バッチリ。

送信も、新サーバー経由で送ってみて、こちらも認証はすべてpass。

最後に転送設定。ここで一つ、わかりやすい落とし穴があった。転送先を入力しても、管理画面で「設定する」ボタンを押して保存するまでは有効にならない。開いただけの状態だと、転送が発火しない。あるアドレスで「転送されない」と焦ったのだけど、原因は単純に未保存だった。保存したら、ちゃんと転送された。

こういうのは、実際に一通流してみないと気づけない。テストは、めんどうでもやる。

そして、この「転送されない」の原因調査も、Claude Codeと一緒だった。焦って「imapsyncのせいかも」と疑ったのだけど、相棒が新サーバーのメールボックスを実際にのぞいて「テストメールはちゃんと届いていますよ。これは転送設定の話で、データ移行とは別問題です」と切り分けてくれた。頭に血がのぼっているときに、事実ベースで冷静に切り分けてくれる存在は、本当にありがたい。

Claude Codeを相棒にすると、仕事の”密度”が変わる

今回いちばん実感したのは、これ。

やったことを並べると、けっこうな量になる。移行計画の設計、DNSの調査、11万通を運ぶ自動化スクリプト、パスワードを画面にもログにも出さない仕組み、記号必須バリデーションへの例外対応、優先アドレスを先に処理する並べ替え、進捗ダッシュボード、件数照合による証明、メモリ不足の原因調査、SPF/DKIM/DMARCの確認、転送トラブルの切り分け。

これを全部、一人で、しかも一つずつ道具を作りながらやろうとしたら、たぶん心が折れる。「そこまでやらなくても」と、どこかで手を抜きたくなる。

でも、相棒がいると違う。「こういう道具が欲しい」と言えば、その場で形になる。作った道具を「ここ直して」と言えば、すぐ直る。だから、面倒で省略しがちな”丁寧さ”を、省略しなくて済む。件数で証明する。進捗を可視化する。パスワードを徹底的に隠す。この一つひとつを、億劫がらずにやり切れる。

技術力というのは、たぶん「難しいことができる」だけじゃなくて、「当たり前の丁寧さを、最後まで手を抜かずにやり切れる」ことでもある。AIを相棒にすると、その”やり切る”のハードルが、ぐっと下がる。

もちろん、丸投げではない。どういう作戦で移行するか、どこがリスクか、どの順番でやるか、という判断は人間の仕事。相棒はものすごく優秀な実装者だけど、”何を作るべきか”を決めるのはこちら。ここの手綱は、握っておく。

今回の移行は、その「AIを相棒にした仕事の進め方」の実践そのものでした。

そして最近は、こういうAIと一緒に進める仕事のやり方を、御社の中に導入する支援のお仕事もやっています。「うちの業務にも、こういう形でAIを組み込めないか」というご相談があれば、遠慮なく声をかけてください。今回のような、地味だけど止められない業務ほど、相性が良かったりします。

終わりに

そんなわけで、無事に引っ越し完了。

利用者のみなさんがやることは、メールソフトの「サーバー名」を1か所書き換えるだけ。メールアドレスもパスワードも、過去のメールも、そのまま。

裏方の仕事は、うまくいくと「何も起きなかった」ように見える。でも、その”何も起きない”を作るのがいちばん難しい。バウンスゼロ、欠損ゼロ、無停止。この三つを同時に守るために、中継を挟み、差分同期を回し、件数で証明し、実地で確認する。

そして今回、その一つひとつを、Claude Codeという相棒と一緒にやり切れた。技術力に、AIという相棒が加わると、”丁寧にやり切る”の底上げができる。それを一番実感した仕事でした。

地味だけれど、こういう止められないシステムの引っ越しは、嫌いじゃない。というか、けっこう好きな仕事です。

無事に終わって、ホッとしています。

この記事を書いた人

大東 信仁

カンパチが好きです。

プロフィールはこちら

10月14日開催 参加者募集中
(画像をタップ→詳細へ)

ミッションナビゲート モニター
(画像をタップ→詳細へ)

広告