WordPress移設備忘録― AIを活用してトラブルを解決した実務ログ ―

先日、取引先の担当者から「WordPressの引越がうまくいかない」という相談を受けました。
引越先の新サーバーの仕様が原因でうまくいかないとのことです。
一般的な移設に使う「All-in-One WP Migration」のプラグインでの引越は試したが、容量制限に引っかかってしまい、うまくいかなかったということのようです。

今回は特殊なケースでのWordPressの移設作業を、AIのサポートを受けながらなんとかできたお話になります。

WordPress移設作業の条件

渡された情報は
・新旧サーバーのFTPアカウント
・新旧サーバーのWordPress管理者アカウント
のみとなります。

サーバーのコントロールパネル情報とphpMyAdminの情報は無いため、WordPressの管理画面のみで移設を行う必要があります。
サーバーによってはコントロールパネル内に「WordPress簡単インストール」や「WordPress簡単移設ツール」などがある場合がありますが、今回は使えない状況となります。

新サーバーにWordPressはインストール済ということですので、課題は「All-in-One WP Migration」で移設できなかったという部分です。

その他、新サーバーではWordPressのインストール階層が一段下がる、DNSの切り替え前、といった細かい条件はありますが、このあたりはよくあることなので細かい説明は省略させていただきます。

また、WordPressはセキュリティ対策、バックアップなど重要な事項がありますが、今回はそこには触れておりません。ご了承ください。

まずはGeminiに相談

移設作業の条件をGeminiに提示し、「All-in-One WP Migration」で失敗したことを説明したところ、「WPvivid – Backup, Migration & Staging」（以下WPvivid）で移設をするのがオススメとのことでした。

※「WPvivid – Backup, Migration & Staging」は2026年にぜい弱性が見つかったとのことです、最新バージョン（0.9.124 以降）を使うようにしましょう。

公式サイトはこちら

WPvivid – Backup, Migration & Staging

WPvividを使って移設作業開始

ここからは、作業をしながらリアルタイムでGeminiのサポートを受けつつ進めます。
作業フローとしては
1. 旧サーバーにWPvividをインストールしてバックアップを取得・ダウンロード
↓
2. DNS切り替え前なのでhostsファイルを変更し、新サーバーにWPvividをインストール
↓
3. 新サーバーでバックアップファイルをアップロードし復元
となります。

別のプラグインを使っても同様のことだと思いますし、サーバーの知識がなくてもそこまで難しくはない手順となります。
が、今回は「新サーバーのアップロードの容量制限に引っかかった」とのことでしたので、復元時に何かしらの不具合がでるのではないかと予想できる状況です。

WPvividの復元前の警告

以前は容量制限に引っかかったとのことでしたが、今回はバックアップデータのアップロードは正常に完了したようです。
ですが、復元前のWPvivid操作画面には

max_allowed_packet = 1 MB is too small. The recommended value is 16M or higher. Too small value could lead to a failure when importing a larger database.

という警告がでています。

Geminiに相談しましたところ、FTPアクセスでの.htaccessやuser.iniなどでは解決不可能な状況となります。
また、phpMyAdminもアクセス不可なためお手上げ状態となりました。

解決策がないので強行復元 → 不具合発生で失敗

警告がでているだけですので、「まだ失敗したわけではない」ということで、一度復元を試してみました。
復元ログをみていると順調に展開できている様子ですが、途中で何度もリトライしているようで、66%で停滞してしまいました。
WordPressは他の操作を受け付けず、固まってしまっているように見えます。
Webサイト側の表示もメンテナンス中の表示となってしまいました。

結果は失敗です。

※ここの時点で復元ログをGeminiに提示していたことが後の解決につながります。

ChatGPTに切り替えてまずはエラーからの復旧

ここからはChatGPTのサポートを受けてWordPressの復旧から、原因の調査、移設作業の続きを行いました。
AIを切り替えた理由は、「なんとなく経緯を知らないAIの方が問題解決に向いていそう」と思ったからです。

復元の強制終了

ChatGPTの指示で、WPvividが復元を行っているディレクトリの削除を行い復元を強制終了させます。

メンテナンス表示のままになってしまった場合の解除方法

復元やアップデートなどが途中で停止すると、WordPressがメンテナンスモードのままになってしまうことがあります。
この状態は、サーバー上の特定のファイルを削除することで解除できます。

WordPressのルートディレクトリに作成される
.maintenance ファイルを削除すると、メンテナンスモードを解除できます。

失敗の原因調査と復元の再挑戦

ここから復元の原因調査を行います。

復元ログから原因の特定

Geminiに提示していた復元ログをChatGPTにも提示したところ、
原因はおそらく、
WordPressのファイル数が多い要因でPHP実行時間のタイムアウトかメモリ不足とのことです。
先方の担当者が「All-in-One WP Migration」で移設が失敗したのもこれが原因のようです。

復元ログから解決法を検討

ログを詳しくみると、
アップロードが必要なテーマやプラグイン、画像などのデータはすべて展開完了していて、WordPressのコアファイルの展開で失敗している様子でした。
その状況であれば、WordPressのコアファイルは新サーバーのものをそのまま使えばOKという状況のようでした。

解決策まとめと復元成功

ChatGPTからの提案で、フルバックアップのファイルをローカルで展開して、WordPressのコアファイル以外のファイルを取り出しFTPで上書き、、、
といった指示だったのですが、FTPでサーバーアクセスをしたところ、データはすでにアップロードされ展開されているようでした。

ですので（面倒なので）
「あとはDBの移設だけで良いでしょうか？」
と聞いてみたところ、
またカスタムバックアップでのDBの再取得とカスタム復元がどうのこうのって面倒な指示を出してくるので、

提案を無視して、旧サーバーのWPvividでDBのみをバックアップし、新サーバーでDBのみを復元しました。

結果は復元（移設）成功です。

移設完了後の調整や動作検証など

完了したように見えますが、まだいくつか動作検証や調整、対応するポイントがあります。

移設後のパーマリンク設定

一番見落としがちなのが、動作検証で投稿した記事や画像がリンク切れを起こしてしまうことです。
これを防ぐには、以下の操作を行ってください。

WordPress管理画面で「パーマリンク設定」を開き、何も変更せずに［変更を保存］をクリックします。これにより .htaccess が自動生成（更新）され、パーマリンク設定が正しく反映されます。

ディレクトリ階層の調整

WordPressを一階層下のディレクトリに設置したまま、サイトURLのみルートで公開する場合は以下の手順で設定します。
記述内容など詳細は省きます。ご了承ください。

• WordPressディレクトリ内の index.phpと.htaccess をルートディレクトリへコピー
• コピーした index.php の読み込みパスをWordPressディレクトリに合わせて修正
• 管理画面「設定 → 一般」で サイトアドレス(URL) をルートURLに変更
• 表示確認後、不要となった一階層下の index.php を削除
• .htaccess はリライトルールが含まれている場合があるため削除前に内容を確認

その他警告の修正と動作検証

投稿画面でPHPのバージョンによる警告がでていたので、これもChatGPTのサポートでfunctions.phpの記述を調整して解決。
その他、投稿・削除のテスト、問い合わせフォームなどのテストを行って移設完了です。

SSLの設定

あとはSSLの設定を行い完了となるのですが、DNS切り替え前ですのでここからは先方に対応してもらえばOKです。

まとめ

今回は、レンタルサーバーのコントロールパネルやphpMyAdminにアクセスできず、
FTPとWordPress管理画面のみで移設作業を行う必要があるという少し特殊な条件での対応でした。

結果として、
・WordPressのバージョンが新旧サーバーで揃っていた
・復元が止まったのがWordPressのコアファイルだった

といった条件が重なり、コアファイルは新サーバーのものを利用し、データベースのみ復元することで移設を完了することができました。

WordPress移設はプラグインで簡単にできることも多いですが、サーバー環境や権限の制約によって思わぬトラブルが発生することもあります。
今回の事例が、同様の状況で作業を行う方の参考になれば幸いです。

また今回は、作業の途中で発生したエラーについてリアルタイムでAIに相談しながら対応することができたため、原因の切り分けや対応方針の検討をスムーズに進めることができました。
トラブル発生時にもすぐに複数の解決策を確認できるため、結果として作業スピードの向上にもつながったと感じます。

おまけ

ChatGPTとのやり取りです。

この記事を読んだ方はこちらも読まれています

ワイドネットクラウドバックアップの導入検討にあたりよくあるご質問 WordPress管理画面にログインできなくなったのはデータベースの容量制限が原因だった！ Webサイトの簡易的な多言語対応【Google翻訳での多言語対応の導入】 SynologyNASのActive Backup for Businessを試した雑感