2026年7月19日

WordPressの「Maximum execution time」エラーの対処｜max_execution_timeの確認と変更

エラー・白い画面

WordPressの更新、プラグインのインポート、画像の一括処理などの途中で、次のようなエラーが出て処理が止まることがあります。

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /var/www/html/wp-content/plugins/example-plugin/includes/import.php on line 214

これは、PHPの1回のリクエストで使える時間（max_execution_time、単位は秒）を処理が超えたため、PHPが処理を打ち切ったという意味です。WordPress 5.2以降では、エラーを画面に出さない設定のサーバーだと「このサイトで重大なエラーが発生しました」という表示だけになり、詳しい内容はエラーログや管理者へのメールで確認することになります。

この記事では、原因の絞り方、現在の制限値の確認、制限値の変え方を説明します（2026年10月時点）。

先に知っておくこと

PHPの max_execution_time の初期値は30秒です。コマンドライン（CLI）で実行するPHPでは0（制限なし）になります。WP-CLI のコマンドに時間制限がかからないのはこのためです
PHPの公式マニュアルによると、Windows以外では、この制限で数えるのはスクリプト自体の実行時間だけです。データベースへの問い合わせ、外部への通信、sleep() などで待っている時間は含まれません。そのため、エラーが出た行は「重い処理をしている場所」を示していることが多い一方で、外部APIの応答待ちが長いだけの場合はこのエラーではなく、後述のWebサーバー側のタイムアウトになります
WordPress本体は、本体・プラグイン・テーマの更新処理の中で set_time_limit( 300 ) を呼び、時間制限を延ばしています

手順1：エラーが出たファイルから原因を絞る

エラー文の in のあとのパスに、処理が止まった場所が書かれています。

wp-content/plugins/プラグインのフォルダー名/ を含む：そのプラグインの処理が長い
wp-content/themes/テーマのフォルダー名/ を含む：テーマの処理が長い
wp-includes/ や wp-admin/ だけ：本体の処理で止まっているが、本体を呼んでいるプラグインの処理が原因のこともある

画面にエラーが出ない場合は、wp-config.php でデバッグログを有効にして同じ操作をもう一度行い、wp-content/debug.log を確認します。

<?php
// wp-config.php の「編集が必要なのはここまでです」より上に追加
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

調べ終わったら WP_DEBUG を false に戻し、debug.log を削除します。デバッグの設定についてはWordPressのデバッグモードを有効にする方法も参照してください。

原因のプラグインが分かったら、まずそのプラグインの設定（一度に処理する件数など）や更新の有無を確認します。管理画面に入れない場合は、WP-CLI で無効にできます（example-plugin はプラグインのフォルダー名に置き換えます）。

wp plugin list --status=active
wp plugin deactivate example-plugin

手順2：現在の制限値を確かめる

管理画面の「ツール」→「サイトヘルス」→「情報」タブを開き、「サーバー」の項目にある PHP の時間制限（英語表示では「PHP time limit」）を見ます。ここに表示されるのは、Webサーバー経由で動いているPHPの値です。

WP-CLI の wp eval 'echo ini_get( "max_execution_time" );' で表示される値は、CLIのPHPの値（通常は0）なので、Webサーバー側の確認には使えません。

手順3：制限値を変える

どの方法が使えるかは、PHPの動かし方（Apacheのモジュール、PHP-FPM など）とサーバーの種類で変わります。60〜120秒程度から試し、必要以上に大きくしないようにします。

方法	使える環境	書き方
サーバー会社の管理画面	レンタルサーバー	「php.ini 設定」などの画面で `max_execution_time` を変える
php.ini	VPS・専用サーバー	`max_execution_time = 120`
.user.ini	PHP-FPM・CGI で動いているサーバー	WordPressのフォルダーに置き、`max_execution_time = 120`
.htaccess	Apache の PHP モジュール（mod_php）だけ	`php_value max_execution_time 120`

php.ini を変える（VPS・専用サーバー）

Webサーバー経由のPHPが読んでいる php.ini の場所は、phpinfo() の「Loaded Configuration File」で確認します。php --ini で表示されるのはCLI用の php.ini なので、別のファイルのことがあります。たとえば Debian・Ubuntu で PHP 8.3 の PHP-FPM を使っている場合は、次のファイルです。

sudo grep -n '^max_execution_time' /etc/php/8.3/fpm/php.ini
sudo sed -i 's/^max_execution_time = .*/max_execution_time = 120/' /etc/php/8.3/fpm/php.ini
sudo systemctl reload php8.3-fpm

Apache の PHP モジュールで動かしている場合は、/etc/php/8.3/apache2/php.ini を編集して Apache を再読み込みします。

.user.ini を置く（PHP-FPM・CGI）

php.ini を直接変えられないサーバーでも、PHPが PHP-FPM か CGI で動いていれば、WordPressのフォルダー（wp-config.php と同じ場所）に .user.ini を置いて変えられます。

max_execution_time = 120

.user.ini は、PHPの初期設定では最大300秒（user_ini.cache_ttl）ごとに読み直されるため、反映まで数分かかることがあります。

.htaccess に書く（mod_php だけ）

php_value は、Apache の PHP モジュール（mod_php）で動いている場合だけ使えます。PHP-FPM や CGI の環境で書くと、「500 Internal Server Error」になります。書いたあとにサイトが表示されなくなったら、すぐにこの行を消してください。

php_value max_execution_time 120

コードの中で延ばす

時間のかかる処理を自分で書いている場合は、その処理の中で set_time_limit() を呼ぶと、そのリクエストだけ制限を延ばせます。呼んだ時点から数え直されます。

<?php
if ( function_exists( 'set_time_limit' ) ) {
    set_time_limit( 120 );
}

wp-config.php に書いてすべてのリクエストの制限を延ばすのは避けます。重い処理だけでなく、すべてのページの暴走も止まらなくなるためです。サーバーによっては set_time_limit() が無効にされていて、効かないことがあります。

PHP-FPM・nginx・Apacheのタイムアウトとの違い

PHPの制限を延ばしても、その手前のサーバーのタイムアウトが短いと、処理は途中で打ち切られます。この場合は「Maximum execution time」ではなく、「502 Bad Gateway」や「504 Gateway Timeout」などの別の表示になります。

打ち切る場所	設定	打ち切られたときの表示
PHP-FPM	プールの設定の `request_terminate_timeout`	502 などのエラー
nginx	`fastcgi_read_timeout`（初期値60秒）	504 Gateway Timeout
Apache（PHP-FPM と組み合わせ）	`Timeout`、`ProxyTimeout`	504 などのエラー

max_execution_time を延ばしたのに504になる場合は、これらの値も確かめます。nginxの設定はnginxのタイムアウト設定で説明しています。

時間のかかる処理は WP-CLI で実行する

ブラウザーから行うと時間がかかる処理は、WP-CLI で実行すると時間制限を受けません。たとえば次のような処理です。

# サムネイルの再生成
wp media regenerate --yes

# データベース内のURLの置き換え（まず --dry-run で件数を確認）
wp search-replace 'http://example.com' 'https://example.com' --dry-run

WordPressのエクスポートファイル（WXR）の取り込みも、WordPress Importer プラグインを入れていれば wp import で行えます。

注意点

制限値を変えたら、サイトヘルスの表示で反映されたことを確かめます
一時的に延ばした場合は、作業が終わったら元の値に戻します
制限を延ばしても毎回エラーになる場合は、無限ループなど処理自体の問題のことがあります。そのプラグインやテーマの作者に、エラー文を添えて問い合わせます
メモリ不足のエラー（Allowed memory size of ... bytes exhausted）は別の問題です。WordPressのメモリ上限をphp.iniで変更する方法を参照してください

まとめ

エラー文のファイルパスから、時間がかかっているプラグインやテーマを特定する
現在の値は、サイトヘルスの「情報」→「サーバー」で確かめる（WP-CLI の値はCLIのもの）
変える場所は、サーバー会社の管理画面、php.ini、.user.ini、.htaccess（mod_php だけ）から環境に合うものを選ぶ
502・504になる場合は、PHP-FPM・nginx・Apacheのタイムアウトも確かめる
重い一括処理は WP-CLI で実行する