Lightsailのメンテ終了を機に、インフラの「自由」を手放してレンタルサーバーに回帰した話

長年運用してきたAWS（Amazon Lightsail ＋ Route 53）上のWordPressブログを、国内定番のレンタルサーバー「エックスサーバー」へ完全移行しました。今回は、移行を決断した心境の変化から、WordPressデータの移行、1回ミスると1週間が吹き飛ぶ「ドメイン移管の罠」、そして現代のメーラー設定における「見えない時間差（DNS浸透とSSL）」の落とし穴まで、全プロセスと実践的なトラブルシューティングをまとめました。

きっかけはLightsailのメンテ終了通知──「自由」が「煩わしさ」に変わった日

移行の直接のきっかけは、AWSから届いた「Lightsailインスタンスのメンテナンス終了（サポート期限）のお知らせ」でした。
若い頃やクラウド全盛期は、IaaS/VPSの「何でも自分で自由に設計・構築できる」環境が刺激的で魅力的でした。OSを選び、Webサーバーをチューニングし、DNSや証明書をコマンドラインで操る──そこにエンジニアリングの楽しさがあったのは事実です。
しかし、シニア世代となりライフスタイルが変わるにつれて、その「自由度」はいつの間にか「運用の煩わしさ」へと姿を変えていました。

• OSやPHP、ミドルウェアの定期アップデート対応
• クラウド事業者からのメンテナンス追従
• メール送信（SMTP）のためにポート25番解除申請やAmazon SESを渋々設定する苦労
• ドル建て請求による為替リスク

「自分はサーバーの保守員をやりたいのではなく、ブログのコンテンツを書きたいだけだ」──そう思い至り、オールインワンで勝手に面倒を見てくれる国産レンタルサーバーへの原点回帰を決断しました。

WordPress移行とプラグインの「断捨離」

エックスサーバーが提供する移行ツールは完走できませんでした。データー量の問題なのか、もっと他の原因なのかはわかりません。いきなりつまづいていてもしょうがないので、さっさと見切りをつけて経験あるツールでの移行に切り替えます。

UpdraftPlusによるバックアップと移行

データの移行には、定番プラグイン「UpdraftPlus」を使用しました。エックスサーバー側に新規インストールしたWordPress上でUpdraftPlusを実行し、バックアップファイルを流し込むだけでテーマや記事データはスムーズに復元できます。

【注意点】復元後のGoogle Drive再認証： UpdraftPlusでクラウド（Google Drive等）へ定期バックアップを取っている場合、環境復元直後は外部ストレージの認証が一旦切れた状態になります。そのまま放置すると、バックアップファイルがサーバーのローカル領域に蓄積されて容量を圧迫するため、復元後は必ずプラグイン設定からGoogleアカウントの再認証を行いましょう。

プラグインの整理整頓

移行を機に、プラグインも見直しました。長年使っていたAkismet（スパム対策）を手放し、より軽量でユーザー体験を損なわない「Cloudflare Turnstile」に一本化。管理対象を減らし、身軽な構成に整えました。

最大の難所：ドメイン移管の鈍重さと「Whoisプライバシー保護」の罠

今回の移行で最も神経を使い、時間がかかったのが「Route 53からXServerドメインへの移管」でした。
ドメイン移管はレジストラ間の認証フローが厳格で、1回の申請に数日〜1週間単位の時間がかかります。しかし、最大の落とし穴は「レジストラは申請時に不備があっても事前チェックしてくれない」という点でした。

なぜか移管が進まない……原因は「Whois情報公開代行」

AuthCode（認証鍵）を取得し、移管ロックを解除して申請したにもかかわらず、処理が一向に進まない状態に陥りました。検索しても「ロック解除してAuthCodeを入れるだけ」という表面的な記事しか見当たりません。そこでAI（Gemini）と壁打ちしながら原因を突き詰めたところ、判明したのは「Route 53のプライバシー保護機能」でした。

• Route 53側でWhoisのプライバシー保護（情報公開代行）が有効になっていると、連絡先アドレスがマスキングされる。
• その結果、移管承認プロセスで必要な確認が通らず、エラー通知もないままサイレントで保留・失敗してしまう。

教訓：Route 53から移管する際の必須チェックリスト

1. 移管ロック（Transfer Lock）を解除する
2. AuthCodeを取得する
3. 【最重要】Route 53のWhoisプライバシー保護を一時的に「無効化」し、自分の連絡先メールアドレスを露出させる
4. 移管完了後、新しいレジストラ側で改めて情報公開代行を有効化する

この「Whoisのマスキング問題」は一般的なマニュアルに記載が少なく、1回失敗すると1週間単位で時間を浪費します。AIをトラブルシューティングのアドバイザーとして活用したことで泥沼化を未然に防ぐことができました。

独自ドメインのメール設定とThunderbirdの落とし穴

Webサイトの表示が無事に切り替わった後、最後に立ちふさがったのがメールクライアント（Thunderbird）の設定でした。

なぜGmailのように一発で登録できないのか？

Gmailなどの大手サービスは、アプリ側に設定データベース（ISPDB）があらかじめ登録されており、アドレスを入れるだけでサーバーやポートが自動入力されます。また、認証も最新の「OAuth2」が使われます。一方、独自ドメインは世界に一つしかないため、アプリ側がサーバーの仕様を自動判別できません。そのため、標準プロトコル（IMAP/SMTP）に基づいた手動設定が必要になります。

過渡期とDNS浸透後で変わる「SSL証明書」

Thunderbirdの設定時、接続先サーバーに smtp.ドメイン名 などを指定すると、「セキュリティ例外の追加」という警告画面が出ることがあります。

• 移管直後の過渡期（一時的な運用）： ネームサーバーの切り替え直後は、エックスサーバー側で独自SSL証明書（Let’s Encrypt）がサーバー全体に行き渡るまでにタイムラグがあります。この段階では、エックスサーバーの親サーバー名（svXXXXX.xserver.jp）を直接指定することで、証明書警告を回避して即座に通電・送受信テストが可能です。
• DNS浸透後（完全反映後の本運用）： 数十分〜数時間が経過してDNSと証明書のバインドが完了すると、エックスサーバー側で smtp.ドメイン名 / imap.ドメイン名 に対するSSL証明書が自動適用されます。この状態になれば、Thunderbirdの自動検出を走らせるだけで、独自ドメイン名を使った標準構成で警告なく一発で開通します。

「エラーが出たからといって設定が間違っているとは限らず、裏側でネットワークが整うのを待つ時間が必要」というインフラならではのリアルな知見です。

アカウント設計と運用の引き算（実体 vs エイリアス）

メールが開通した後は、今後の運用の散らかりを防ぐためにアカウント設計を整理しました。

• dev@ドメイン名（実体アカウント）
  • GitHubやDiscord、各種API連携用。独立したIDとして持たせることで、開発基盤としての信頼性と安定性を確保。
• contact@ドメイン名（エイリアス / 転送）
  • Webサイトの問い合わせ窓口や各種通知用。エックスサーバーの転送機能を使い、メールボックスを増やさずにメインアカウントへ集約。
  • 返信時はThunderbirdの「差出人情報（Identities）」機能を使うことで、Fromアドレスを contact@ のままスマートに返信可能。

AWS側の完全撤退と片付け

移行が完了したら、AWS側のリソースを削除して課金を確実に止めます。ここでもAWS特有の初見殺しがありました。

1. Lightsail インスタンスの削除
2. Static IP（静的IP）の解放：インスタンスを消しても、固定IPが未アタッチで残っていると時間課金され続けるため確実に削除。
3. スナップショットの削除
4. Route 53 ホストゾーンの削除
   • 落とし穴：ホストゾーンを削除しようとすると The specified hosted zone contains non-required resource record sets エラーで弾かれます。システム標準の「NS」「SOA」以外のレコード（AレコードやTXTレコードなど）を先に手動ですべて削除してからでないと、ホストゾーン本体を削除できない仕様になっていました。なにがダメかはやっぱり教えてくれませんでした。

これらをすべて片付け、翌月の請求ダッシュボードで「利用料0円」を確認した上で、AWSアカウント自体を解約（抹消）する予定です。

7. おわりに：手放して得られた「運用の引き算」

今回の移行を通じて、インフラの維持管理にかかっていた見えないコスト（精神的なリソースやアップデート追従の時間）がいかに大きかったかを実感しました。

エックスサーバーへの一本化により、

• 高速なWeb環境と無料SSLの自動更新
• 安定したメール環境と標準装備のセキュリティ（SPF/DKIM/DMARC）
• 定額で安心な月額運用

が手に入り、サーバーの面倒を見る時間から完全に解放されました。

技術を使いこなす楽しさがある一方で、ライフステージや目的に合わせて「あえて手放し、任せる」という選択もまた、大人のエンジニアリングの一つですよね。コストも随分と安くすることができましたし、念願の普通のメールクライアントが利用できるSMTPサーバーを立ち上げることが出来ました。これは嬉しいです！