何をするか
最近、古くなったWebサーバーから最新の環境へお引っ越しをする機会がありました。今回は、普段使っているAIコーディングアシスタント「Antigravity」を相棒にして、PHP 7の旧サーバーから、AWS EC2上の最新のBitnami WordPress(PHP 8)環境への完全移行を行いました。単にデータを移すだけでなく、「AIと一緒にトラブルシューティングをしながらインフラを再構築する」という新しい移行体験を記事にまとめました。
サーバー移行って何?(1分で分かる概要)
今回直面した最大の動機は「PHP 7のサポート終了(EOL)」です。古いバージョンのまま放置するとセキュリティリスクが高まるため、サーバーまるごと最新環境へ移す必要がありました。手順の概要は以下の通りです:
AWS上に新サーバー構築 → データのエクスポート/インポート → SSL・セキュリティの再設定 → 旧サーバー削除
今回はデータ移行の定番プラグイン「All-in-One WP Migration」を利用しましたが、環境が新しくなることで発生した様々な「摩擦」をAIと一緒に乗り越えることになりました。
最新環境(PHP 8 + Bitnami)にするメリット
最新のサーバー環境にするだけで、以下のような恩恵があります。一言で言うと「速くてめちゃくちゃ堅牢」になります。
- セキュリティの大幅向上
最新のPHPパッチが適用されるのはもちろん、Bitnami標準のガチガチなセキュリティ設定(.htaccessのシステムレベルでの無効化など)により、外部からの攻撃耐性が飛躍的に高まります。 - 処理速度(パフォーマンス)の向上
PHP 7から8になることでWordPressの動作自体が最適化・高速化され、表示速度の改善が見込めます。 - 分かりやすいコスト削減
移行完了後に古いEC2インスタンスを完全削除することで、無駄なクラウド維持費をスパッとカットできます。
手順(Antigravityと進める完全移行劇)
1. 新サーバーへのデータインポートと「タイムアウト」の壁
AWSで新しいBitnami WordPressを立ち上げ、データをインポートしようとしたところ、最初の壁が出現。データ量が大きかったため、なんとインポートが77%でストップしてしまいました。
原因は「PHPの処理時間上限(タイムアウト)」。ここでAntigravityが本領を発揮します。チャットで「止まりました」と伝えただけで、AIが裏側でSSH経由で新サーバーに接続し、php.iniのmax_execution_time設定を1時間(3600秒)に拡張。その後、無事に100%までインポートが完走しました。
2. 実はここでハマった…「Critical Error」と古いプラグインの悲鳴
これで移行完了!と思いきや、サイトを開くと画面が真っ白になり「There has been a critical error on this website.」の絶望的な文字が。
原因は、旧環境から引き継いでしまった「古いプラグイン」でした。これらが最新のPHP 8の仕様に対応しきれず、裏でエラーを吐き続けていたのです。これもAntigravityがすぐにエラーログを解析し、SSHから直接問題のプラグインフォルダをリネームして強制無効化。一瞬でサイトが復旧しました。
3. Let’s EncryptによるSSL証明書の再設定
続いてHTTPS化です。サーバー(IPアドレス)が変わったことでブラウザから警告が出る状態になっていました。Bitnami専用のbncert-toolコマンドを実行して証明書の再発行を試みましたが、ここでも「wwwあり」ドメインのDNS設定が存在しないというエラーが。
すかさず設定を「wwwなし」単体に切り替えてAIが対話を自動で進行させ、無事に新しいSSL証明書の発行と、定期更新の自動設定(cronジョブ)まで完了させることができました。
4. 最大の罠:超セキュア環境による「ログイン画面」の仕様衝突
最大の難関はセキュリティプラグインでした。以前は専用のログインURLを作るために「Login Rebuilder」プラグインを使っていましたが、新環境では全く機能しません。理由は、Bitnamiの強固なセキュリティ設定でした。「.htaccess」ファイルがシステム根幹で無効化されていたため、プラグインが物理ファイルを作ったりURLを偽装する手法が全ブロックされていたのです。
そこでモダンな「WPS Hide Login」へ切り替えを試みますが、これも404エラーに。最終的に、Antigravityが不要な古いプラグインの残骸を完全にパージし、パーマリンクの空更新を行うことで、Bitnami独自のルーティング設定をうまく機能させ、「新しい安全な専用ログインURL」を完璧にセットアップできました。
おまけ:旧サーバーを落としてスッキリ
新環境が完璧に動くこと、ログイン画面の保護が強力に効いていることを確認したのち、AWS CLIコマンドを使って古いEC2インスタンスをterminate-instancesで完全削除しました。
aws ec2 terminate-instances --instance-ids [古いインスタンスID]
これで、毎月発生していた旧サーバーの無駄な維持費もストップ。移行プロジェクトは無事に完了となりました。
まとめ
今回の移行で痛感したのは、「環境を新しくするということは、過去の古い仕組みとの摩擦が必ず起きる」ということです。特にBitnamiのような高セキュリティ環境では、直感的な操作(プラグインを入れるだけ)が通用しない場面が多々あります。
しかし、AntigravityのようなAIアシスタントがいることで、「エラーが起きた」と伝えるだけで、AIが原因を見抜き、SSHで直接サーバーに潜り込んでコマンドを叩き、設定を書き換えて直してくれる。そんな専属のインフラエンジニアとペアプログラミングをしているかのような、次世代の保守運用を体験できました。システム移行を重荷に感じている方は、ぜひAIを相棒に迎えてみてはいかがでしょうか。


