協栄興業のWeb・メール環境を再編する【第3回】-- メールを守った後、テンポラリーのWordPressを本番へ
そして、NAMIKI PROPERTYへ —
前回までの記事では、協栄興業のメール環境を旧サーバーから新サーバーへ移行した記録を紹介しました。
メールは9アカウント、合計約4万6千通。作業前にVPSへ退避し、新環境へ復元した後、メールボックスの件数・フォルダー構成・実ファイルまで照合しました。
しかし、メール移行の完了はゴールではありませんでした。
新しいサーバーには、協栄興業のWordPressサイトをテンポラリーURLであらかじめ構築していました。次の工程は、このサイトを正式ドメイン kyoeikogyokk.co.jp へ移すことです。
ここで重要だったのは、レンタルサーバーの仕様上、旧環境からドメイン設定を削除すると、Webサイトだけでなくメールデータも削除される可能性があることでした。
だからこそ、順番を逆にしてはいけませんでした。
先にメールを完全に守る。
その後で、Webサイトを本番へ移す。
第3回では、そのWordPress本番移行と、並行して進めていた NAMIKI PROPERTY の立ち上げについて記録します。
Web移行で守った原則は、「移行元を壊さない」
テンポラリー環境は、xxxxx.namiki-associates.co.jp で稼働していました。
通常であれば、テンポラリーサイトのURLを書き換えて本番化する方法もあります。しかし今回は、テンポラリー環境そのものを直接変更しない方針にしました。
まずテンポラリーサイトのデータベースとファイルを取得し、別の正式環境を作成します。そこでのみ本番URLへの書き換えを行い、問題があってもテンポラリー環境へ戻れる状態を保ちました。
この「コピー先だけを加工し、移行元は生きた原本として残す」という考え方は、Web移行ではとても有効です。
今回のバックアップ対象は、次の規模でした。
| 対象 | 内容 |
|---|---|
| WordPressデータベース | 62テーブル |
| WordPressファイル | 21,089件 |
| ファイル容量 | 約11GB |
| テンポラリーURLから正式URLへの置換 | 1,103件 |
WordPressサイトは、記事本文や画像だけで構成されているわけではありません。テーマ、プラグイン、アップロード済み画像、設定情報など、多くのファイルとデータベース情報の組み合わせで動いています。
「画面が表示されたから移行成功」とは判断せず、データを数値で照合することにしました。
バックアップは「取った」だけでは終わらせない
データベースはエクスポート後にハッシュ値を照合し、取得したファイルについても件数を確認しました。
移行先へインポートした後は、テーブル数や主要なレコード数が一致することを確認しました。WordPressファイルも、テンポラリー環境と正式環境で21,089件すべてが揃っていることを確認しています。
バックアップは、作成しただけでは十分ではありません。
- 何を取得したか
- 取得したデータが壊れていないか
- 移行先に同じ内容が復元されているか
まで確認して、初めて「戻れる状態」と言えます。
メール移行でも同じでしたが、今回も件数照合を重視しました。見た目では分からない欠落を、数値で早い段階に見つけるためです。
URL置換は、まず試算してから実行する
テンポラリーURLを正式URLへ切り替える際には、WordPressのコマンドラインツールであるWP-CLIを使用しました。
単純にデータベースの文字列を置換すると、WordPress内部の設定情報を壊すおそれがあります。WordPressには、文字数情報を含むシリアライズデータが保存されている場合があるためです。
そこで、WordPressを理解しているWP-CLIで、まず変更件数を確認する「dry-run」を実施しました。
wp search-replace 'https://xxxxx.namiki-associates.co.jp' \
'https://kyoeikogyokk.co.jp' \
--all-tables --dry-run
想定どおりであることを確認してから、本実行へ進みました。
wp search-replace 'https://xxxxx.namiki-associates.co.jp' \
'https://kyoeikogyokk.co.jp' \
--all-tables
置換対象は1,103件でした。
実行後は、WordPressの home と siteurl が正式URLになっていることを確認し、さらにデータベースとHTMLソースの両方からテンポラリーURLが残っていないかを調べました。
結果は、いずれも残存0件でした。
このように、
変更前に件数を確認する
→ 本実行する
→ 残りがないことを確認する
という三段階に分けることで、URL切替を一度きりの操作にしないようにしています。
確認は「サイトが開く」だけでは足りない
URLの置換が終わった後も、確認項目は残っています。
正式サイトでは、次の技術確認を行いました。
- HTTPからHTTPSへの301リダイレクト
- トップページ、会社案内、サービス案内、投稿ページのHTTP 200応答
- アップロード済み画像の表示とContent-Type
- OGPの
og:urlが正式URLになっていること - HTMLソース内のテンポラリーURL残存が0件
- データベース内のテンポラリーURL残存が0件
また、テンポラリー環境もHTTPSで正常に表示され、移行元を変更せず維持できていることを確認しました。
最後は、自動確認だけに頼りませんでした。
実際のブラウザでトップページだけでなく、下層ページ、投稿、画像、リンク、レイアウトをほぼ全ページ確認しました。明らかな表示崩れ、画像欠落、リンク異常はなく、人間による受入確認も完了しました。
AIやコマンドによる確認は非常に有用ですが、最終的にサイトを見るのは人です。
だからこそ、機械的な照合と人間の目視確認の両方を通すことを、今回の基本方針にしました。
移行と改善を、あえて同時にしない
今回、もう一つ意識したことがあります。
それは、サイト移行とサイト改善を同時に行わないことです。
WordPressを本番環境へ移す作業中に、デザイン変更、ページ削除、文章修正、プラグイン追加などを同時に始めると、不具合が起きた際に原因が分かりにくくなります。
そのため、今回の目的はあくまで「テンポラリーで確認済みのサイトを、正式ドメインへ安全に移すこと」に限定しました。
移行完了後の改善やサイト再編は、別の作業として扱います。
この切り分けは地味ですが、作業を安全に進めるうえで大切な判断でした。
会社サイトの先に、NAMIKI PROPERTYという入口をつくる
協栄興業のサイトを正式化する一方で、同じ時期に NAMIKI PROPERTY の構築も進めました。
NAMIKI PROPERTYは、特定の一社だけの会社ホームページではありません。
共栄産業、協栄興業、湘南興発産業、そして個人・共有名義を含む不動産を、法人名や所有形態の違いを越えて紹介していくためのブランドサイトです。
目指したのは、強い営業色を出した不動産ポータルではなく、衣笠の街、建物の歴史、現在運営されている物件、これから再整備される土地を、写真と必要な情報で静かに伝えていくサイトです。
衣笠とともに、不動産を育てる。
という言葉には、建物を単に貸す・売るだけでなく、地域のなかで長く運営し、次の世代へつないでいくという思いを込めました。
当初は、物件一覧と6物件の紹介、「NAMIKI PROPERTYについて」、そして衣笠栄町1丁目の再整備プロジェクトを中心に整えました。
歴史ページや空室情報、関連法人の説明などは、急いで完成させず、資料や写真が揃った段階で少しずつ育てていく方針です。
Webサイトも、公開した瞬間に完成するものではありません。
長く使い続け、情報を更新し、地域や物件の変化を記録していくための土台として考えています。
今回の移行で残したかったこと
メール、WordPress、ドメイン、DNS、SSL、問い合わせフォーム。
それぞれは別々の技術に見えますが、実際の運用では密接につながっています。
今回の作業では、次の原則を最後まで守りました。
- 移行元を壊さない
- 先にメールを守る
- 正式環境を独立して構築する
- 件数とURL残存を数値で照合する
- 自動確認の後に、人間が最終確認する
- 移行と改善を混ぜない
ChatGPTには全体の整理、設計の相談、Claude Codeへの指示書作成を担ってもらいました。Claude Codeには、SSHによる調査、バックアップ、実装、差分・HTTPレスポンスの確認を担ってもらいました。
そして、作業を進めるかどうかの判断と、実際の画面を見た最終承認は、人間が行いました。
AIを使うからこそ、作業を止める地点と、確認する根拠を先に決めておく。
今回の移行は、その考え方を実際のメール・WordPress・不動産サイトの運用で試せた事例になったと思います。
協栄興業のメールとWebサイトを安全に移行し、その先にNAMIKI PROPERTYという新しい入口を整える。
ここから、衣笠の不動産を少しずつ、長い時間をかけて紹介・記録していきます。
※本記事は実際の作業記録をもとに構成しています。サーバーやメールの移行手順は、契約サービス、ドメイン設定、メール運用、WordPress構成によって異なります。実施の際は、事前のバックアップ、復旧方法、影響範囲を十分に確認してください。


