この記事の要点

Maximum execution time of N seconds exceeded は PHP の実行時間制限超過エラー 既定 30 秒（Web）。CLI は無制限が既定（max_execution_time = 0） 永続変更: php.ini の max_execution_time = 300 一時変更: ini_set("max_execution_time", 300); または set_time_limit(300); Nginx + PHP-FPM の場合は request_terminate_timeout も同時に設定が必要 set_time_limit(N) は呼び出すたびに残り時間をリセット → ループ内で定期呼び出しも有効

このエラーの概要

PHP スクリプトが規定時間（既定 30 秒）を超えると即座に終了し、次のメッセージが出ます:

Fatal error: Maximum execution time of 30 seconds exceeded in
/var/www/html/import.php on line 42

これは PHP の安全機構で、無限ループや極端に遅い処理が Web サーバーを占有し続けるのを防ぐためです。バッチ処理 / CSV インポート / 外部 API ループ / 大量画像処理で頻発します。

対処1: php.ini で永続的に変更

# php.ini の場所を確認
php --ini
# Loaded Configuration File: /etc/php/8.2/fpm/php.ini

# 編集
sudo vi /etc/php/8.2/fpm/php.ini

; /etc/php/8.2/fpm/php.ini

; 既定 30 秒 → 300 秒（5 分）
max_execution_time = 300

; 0 で無制限（CLI のみ推奨、Web では絶対避ける）
; max_execution_time = 0

; 入力受付の最大時間（POST/GET の読み取り）
max_input_time = 300

; メモリ上限も同時に上げることが多い
memory_limit = 512M

; アップロード関連
upload_max_filesize = 100M
post_max_size = 100M

反映するには PHP-FPM / Apache の再起動が必要:

# Nginx + PHP-FPM
sudo systemctl restart php8.2-fpm

# Apache mod_php
sudo systemctl restart apache2

# 変更確認
php -i | grep max_execution_time
# max_execution_time => 300 => 300

対処2: スクリプト内で一時変更

<?php
// 方法 A: ini_set
ini_set('max_execution_time', 300);

// 方法 B: set_time_limit
set_time_limit(300);

// 0 で無制限（CLI 推奨、Web 慎重に）
set_time_limit(0);

// 重要: set_time_limit は呼び出すたびに「N 秒の新しいタイマー」を開始
// → ループ内で定期的に呼ぶと事実上無制限化
foreach ($largeDataset as $row) {
    set_time_limit(30);  // この行から 30 秒以内に次が来れば OK
    processHeavy($row);
}

// 同じ意味
foreach ($largeDataset as $row) {
    set_time_limit(0);   // 無制限
    processHeavy($row);
}

ini_set('max_execution_time', ...) と set_time_limit(...) の違い:

関数	動作
ini_set('max_execution_time', 300)	残り時間を 300 にセット、それまでの経過は無視
set_time_limit(300)	同様、明示的・分かりやすい
ini_set('max_execution_time', 0)	無制限
set_time_limit(0)	無制限

safe_mode 有効時 / 一部の共有レンタルサーバーでは set_time_limit() が無効化されているケースがあります。

対処3: Nginx + PHP-FPM の壁

Nginx + PHP-FPM では php.ini の max_execution_time より先に他のタイムアウトに引っ掛かることがあります:

; /etc/php/8.2/fpm/pool.d/www.conf
; PHP-FPM プロセスを終了するまでの時間
request_terminate_timeout = 300s

# /etc/nginx/sites-available/example.conf

location ~ \.php$ {
    fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;

    # FastCGI 応答待ち時間（既定 60s）
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_connect_timeout 75;
}

# サーバー全体
http {
    proxy_read_timeout 300;
    send_timeout       300;
}

3 箇所すべてを揃える必要があります:

設定	場所	例
PHP 実行時間	php.ini	max_execution_time = 300
PHP-FPM プロセス終了	www.conf	request_terminate_timeout = 300s
Nginx FastCGI 読取	nginx.conf / vhost	fastcgi_read_timeout 300;

対処4: Apache mod_php / .htaccess

# .htaccess または httpd.conf
php_value max_execution_time 300
php_value memory_limit 512M
php_value max_input_time 300

# Apache 自体のタイムアウト
Timeout 300

対処5: バッチは CLI で実行

そもそも長時間処理は Web からではなく CLI から動かすのが原則:

# CLI は max_execution_time = 0（無制限）が既定
php /var/www/html/artisan import:csv

# Cron で定期実行
# /etc/cron.d/myapp
0 3 * * * www-data php /var/www/html/artisan schedule:run

# キューワーカー
php artisan queue:work --tries=3 --timeout=600

本質的な対処: 処理を分割

そもそも 30 秒で終わらない Web リクエストは UX 的にも問題。非同期化が王道:

// Laravel ジョブキューに投げる
ImportCsvJob::dispatch($file)->onQueue('imports');

// ユーザーには「処理中」を返してすぐ応答
return response()->json(['status' => 'queued', 'job_id' => $jobId]);

// クライアントはポーリング or WebSocket で完了通知
// /api/jobs/{id}/status

FAQ

Q: set_time_limit(0) を入れたのに 30 秒で死ぬ
A: PHP-FPM の request_terminate_timeout または Nginx の fastcgi_read_timeout に引っ掛かっています。3 つすべてを揃えてください。

Q: max_execution_time は何を測っている？
A: PHP の実行時間のみ。sleep() や system() / exec() で外部コマンド実行中の時間は含みません（OS 依存）。Windows では実時間で測ります。

Q: ループの途中で setting したい
A: set_time_limit(30) をループ内で呼ぶと「ここから 30 秒」のタイマーがリセットされ続け、事実上無制限と同じになります。

関連エラー

• Allowed memory size of N bytes exhausted — memory_limit 不足、別途対処
• 504 Gateway Time-out — Nginx のタイムアウト、上記設定で対処
• Maximum execution time exceeded（CLI 上）— CLI でも明示的に max_execution_time が設定されている、または set_time_limit が呼ばれた