【Lightsail】Bitnamiからネイティブ版WordPressへの移行で「Blogs prepared.」でフリーズした時の解決策
サイト管理者事前準備：PHP容量制限とタイムアウトの拡張
250MBの バックアップファイルをインポートするため、新サーバーの php.ini を書き換えて上限を拡張します。ネイティブ版WordPress（Debian）の該当ファイルは以下にあります。
bash
/etc/php/8.2/apache2/php.ini
コードは注意してご使用ください。
【変更箇所】
ini
upload_max_filesize = 512M
post_max_size = 512M
memory_limit = 512M
max_execution_time = 600
コードは注意してご使用ください。
設定後、Apache2を再起動して設定を反映させます。
bash
sudo systemctl restart apache2
コードは注意してご使用ください。
「Blogs prepared.」でフリーズ発生！原因はタイムアウトではなかった
インポートを開始するとプログレスバーは100%まで進むものの、その後の「Blogs prepared.」の画面から一向に進まなくなりました。
📷【ここに挿入する画像：「Blogs prepared.」のまま止まっているインポート画面のスクリーンショット
タイムアウトを疑いましたが、Apacheの追加エラーログ（/var/log/apache2/error.log）を確認したところ、原因は別のものでした。
text
[Sat Oct 24 08:34:10 2026] [php:error] [pid 17655:tid 17655] [client xxx.xxx.xxx.xxx:5886] PHP Fatal error: Trait "Automattic\\Jetpack\\Connection\\Traits\\WPCOM_REST_API_Proxy_Request" not found in /var/www/html/wp-content/plugins/jetpack/_inc/lib/core-api/wpcom-endpoints/class-wpcom-rest-api-v2-endpoint-email-editor-bootstrap.php on line 30, referer: http://xxx.xxx
インポート処理の最終段階で、バックアップデータに含まれていた Jetpackプラグインのファイル破損による致命的エラー（Fatal error） が発生し、処理が完全にストップしていました。
トラブルを引き起こした真の根本原因（複合要因）
今回のフリーズと移行の難航には、環境のミスマッチと手戻りによる以下の複合要因がありました。
- 環境の誤認と手探りのコマンド操作（最大の原因）：
移行作業の初期、新しい環境が「Nginx」なのか「Apache」なのか仕様が不確定なまま、AIとのチャットに沿ってコマンドラインから先走って色々とインストールや設定変更を進めてしまった。これにより新環境の構成が内部でごちゃごちゃになり、エラーを誘発してチャットのログも肥大化。セッション自体が重くなって作業が完全に崩壊するという大失態を招いた。 - PHPバージョンアップに伴う非互換（PHP 8.1 → 8.2）：
移行元（PHP 8.1）から引っ張ってきた古いJetpackのコードが、新環境（PHP 8.2）の厳密な型チェックやクラス読み込み仕様と衝突し、Fatal errorを吐いた。 - WP-CLIの巻き込み停止：
安全にコマンドライン（WP-CLI）からプラグインを無効化しようとしたが、WordPressのコアが立ち上がる前にJetpackのエラーが発火するため、wp pluginコマンドすら巻き込まれて強制終了する状態に陥っていた。
解決策：SSHからプラグインを物理的に強制無効化して突破
一度インスタンスを削除して環境をまっさらに作り直して仕切り直した後、WP-CLIすら動かない状態だったため、SSHから直接Jetpackのプラグインディレクトリ名を変更し、システムに強制的に読み込ませない（物理的な退避）手法をとりました。
bash
user@stored-instance:~$ sudo mv /var/www/html/wp-content/plugins/jetpack /var/www/html/wp-content/plugins/jetpack_old
コードは注意してご使用ください。
ディレクトリ名を変更した瞬間、システムがエラーから解放され、止まっていたブラウザのインポート画面が即座に動き出しました。
インポート完了
無事にファイルの復元が最後まで走り切り、インポートが正常に完了しました。
新しいサーバー環境の仕様がクリアになっていない状態で、手探りでインストールを進めるのは手戻りの元であり、非常に危険です。
仕切り直して環境をクリーンにし、エラーログの根本（Fatal error）を特定した上で物理的に対処することが、崩壊した状況から生還するための最大の鍵となりました。
