大規模WordPressサイトでプラグインが途中で止まるエラーの解決法
大規模なWordPressサイトでプラグインの一括処理が「0/」と表示されたまま進まず「error-generation stopped」で停止する現象は、PHPの実行時間やメモリ制限が主な原因だ。設定を調整しバッチサイズを小さくすれば、処理を最後まで走らせられる。
大規模サイトでプラグインが途中で止まる原因
WordPressの管理画面から実行するプラグインの一括処理は、Webサーバーを介したHTTPリクエストのなかで動く。このリクエストにはサーバー側で複数の時間制限がかかっており、処理がそれを超えると強制終了する仕組みだ。
とくに影響が大きいのは以下の3つだ。
- PHPの最大実行時間（max_execution_time）
- PHPのメモリ制限（memory_limit）
- WebサーバーやFastCGIのリクエストタイムアウト
5000件を超える投稿があるような大規模サイトでは、1回のリクエストですべてのデータを処理しようとすると、これらの制限に引っかかる。結果として「0/」のまま進捗が表示されず、しばらくしてエラー停止する。
プラグインのバッチ処理設定を見直す
最初に確認すべきは、そのプラグインがもつ「一度に処理する件数」の設定だ。多くの一括処理系プラグインは、内部的にデータを小分けにして処理するバッチサイズを指定できる。
プラグインの設定画面を開き、「1回あたりの処理件数」や「Records per iteration」といった項目を探す。デフォルトでは無制限に近い値になっていることも多く、これを10件〜50件程度まで下げるだけでエラーが解消するケースは多い。
バッチサイズを小さくすると処理全体の回数は増えるが、1回あたりの負荷が下がるためPHPやサーバーの制限にかかりにくくなる。この調整だけで問題が解決するなら、最も手軽でリスクの低い対処法だ。
一括処理を開始する
バッチサイズを小さくして再試行する
上の図は、バッチサイズを調整するだけで一括処理が正常に完了する流れを表している。
PHPの最大実行時間とメモリ制限を引き上げる
バッチサイズの調整だけでは改善しない場合、PHP側の制限値が厳しすぎる可能性が高い。とくにレンタルサーバーの共用プランでは、max_execution_time が30秒、memory_limit が128MB程度に設定されていることが多い。
まず wp-config.php に以下の行を追加して制限を緩和する。
set_time_limit(300);
define('WP_MEMORY_LIMIT', '256M');set_time_limit(300) はPHPの最大実行時間を300秒に延長し、WP_MEMORY_LIMIT はWordPressが利用できるメモリ上限を256MBに引き上げる。必要に応じて値をさらに増やしても構わない。
サーバー環境によっては、php.ini や .user.ini で直接 max_execution_time と memory_limit を指定できる場合もある。どちらの方法が有効かはサーバー仕様に依存するため、変更後は必ず phpinfo() やサイトヘルス画面で反映を確認する。
また、管理画面からの実行に限らず、サーバー負荷の高い処理ではメモリが不足しがちだ。256MBでも足りないようであれば512MBまで引き上げることを検討する。
サーバー側のリクエストタイムアウトを確認する
PHPの実行時間を延ばしてもエラーが続くなら、WebサーバーやFastCGIのリクエストタイムアウトが原因だ。Apacheのmod_fcgidを使っている環境では、FcgidIOTimeout や FcgidBusyTimeout が短く設定されていると、PHPが処理中でも接続を切られてしまう。
この設定はサーバー全体に影響するため、共用サーバーではユーザー側で変更できないケースがほとんどだ。該当しそうな場合はサーバー管理会社のサポートに「管理画面の長時間処理が途中で切れる」と伝え、設定の緩和が可能か問い合わせる。
VPSや専用サーバーを利用しているなら、ApacheやNginxの設定ファイルでタイムアウト値を直接編集できる。変更後はWebサーバーの再起動を忘れずに行う。
WP-CLIでバックグラウンド処理を実行する
サーバーがWP-CLIに対応しているなら、ブラウザからのHTTPリクエストではなくコマンドラインからプラグインの処理を走らせるのが最も確実な回避策だ。CLI実行にはWebサーバーのタイムアウト制限が適用されないため、大規模データでも安全に処理できる。
ただし、すべてのプラグインがWP-CLIコマンドを提供しているわけではない。まずプラグインの公式ドキュメントで「WP-CLI commands」の有無を確認し、該当するコマンドがあればターミナルから実行する。
実行例は以下のような形だ。
wp plugin-command run --batch-size=20WP-CLIが使えない場合は、処理を手動で分割してブラウザから複数回に分けて実行する方法も有効だ。たとえばカテゴリ別や投稿タイプ別に絞り込み、1回の処理対象を数百件以下に抑える。
これらの手順を順に試すことで、多くの大規模サイトで発生するタイムアウトエラーは解決できる。
よくある質問
共有サーバーでもPHPの最大実行時間は変更できるか
wp-config.php での set_time_limit() や .user.ini による上書きが許可されていれば可能だ。ただしサーバー側で一律に上限が決められており、設定値を超えて延長できない場合もある。
バッチサイズを小さくしても途中で止まる場合はどうすればよいか
メモリ制限と最大実行時間の両方を引き上げた上で、さらにバッチサイズを絞る。それでも改善しない場合は、サーバー側のリクエストタイムアウトが原因の可能性が高いため、サポートへの問い合わせやWP-CLIの利用を検討する。
「error-generation stopped」以外のエラーが表示されることはあるか
「このサイトで重大なエラーが発生しました」というWordPressの標準エラー画面や、「504 Gateway Timeout」といったサーバーエラーが表示されることもある。いずれも根本的な原因は処理時間の超過であることが多い。
特定のプラグインでしか発生しない場合はどう対処するか
まずそのプラグインの設定画面でバッチサイズを調整する。設定項目がなければ、開発元に問い合わせてフックやフィルターでバッチサイズを変更できないか確認する。別のプラグインで代替できる機能であれば、乗り換えも選択肢になる。
設定を変えてもまったく改善しない場合はサーバー移転が必要か
すべての設定を試しても解決しないなら、現在のサーバープランが大規模サイトの運用に適していない可能性が高い。VPSや専用サーバーなど、より自由度の高い環境への移行を検討するタイミングだ。
この記事のポイント
- 大規模サイトの一括処理停止はPHPとサーバーの制限が原因
- プラグインのバッチサイズを10〜50件に下げると効果的
- max_execution_timeとmemory_limitの引き上げも併用する
- 共用サーバーではサポートへの問い合わせが必要な場合もある
- WP-CLIが使えれば最も確実に回避できる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている