WordPressで「Fatal error: Maximum function nesting level of 100 reached」を修正する方法

TL;DR

このエラーの原因は、十中八九あなたのコードではなく Xdebug です。Xdebug は暴走した再帰を検知するため、デフォルトでネストの上限を100に設定しています。php.ini でこの値を引き上げてください：

; php.ini に追加または更新
xdebug.max_nesting_level = 512

PHP-FPM または Apache を再起動し、ページをリロードしてください。Xdebug を使っていない場合は、本物の再帰バグです — Fix 4 へ進んでください。

実際に何が起きているのか

PHP 自体にはネストの制限はありません。Fatal error: Maximum function nesting level of '100' reached, aborting! というエラーメッセージは、Xdebug 拡張モジュールが完全に独自に挿入しているものです。Xdebug は PHP プロセスのスタックオーバーフローを防ぐため、コールの深さを100でハードキャップしています。

WordPress は1ページを読み込むだけで50〜80ものネストされた呼び出しを消費します。フック、フィルター、テンプレートのインクルード — これらはあっという間に積み重なります。Xdebug が有効な開発環境では、わずかに余分なコール層を追加するプラグインが1つあるだけで、ページのレンダリングが終わる前に上限を超えてしまいます。

本番サーバーで Xdebug が動いていることはほとんどありません。本番環境でこのエラーが出た場合は、設定の問題ではなく本物の再帰バグです。

Fix 1: Xdebug のネスト上限を引き上げる（最も一般的な解決法）

まず、実際に読み込まれている php.ini を確認します：

php --ini
# または:
php -r "echo php_ini_loaded_file();"

そのファイルを開き、以下の行を追加または更新します：

xdebug.max_nesting_level = 512

その後、Web サーバーを再起動します：

# Apache
sudo systemctl restart apache2

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

# MAMP / WAMP / Laragon: GUI の再起動ボタンを使用

512 は WordPress に対して安全な値です。512 に設定してもまだエラーが出る場合は、ほぼ確実に本物の再帰ループが存在します — 設定を変えても解決しません。

Fix 2: Xdebug を無効化する（今すぐ必要でない場合）

Xdebug をたまにステップデバッグするためだけにインストールしている場合は、使わないときは無効にしておきましょう：

# Ubuntu/Debian の場合
sudo phpdismod xdebug
sudo systemctl restart apache2   # または php-fpm

# または php.ini の拡張モジュール行をコメントアウト:
; zend_extension=xdebug.so

Xdebug が読み込まれていなければ、ネストのチェックも完全になくなります。WordPress は通常通り読み込まれます。

Fix 3: .htaccess で上書きする（共有ホスティングの代替手段）

php.ini を直接編集できない場合、共有ホストによっては .htaccess 経由で PHP 設定を上書きできることがあります：

# .htaccess（Apache のみ）
php_value xdebug.max_nesting_level 512

注意点が1つあります：Xdebug は拡張モジュールの読み込み時、つまり PHP コードが実行される前にネスト上限を読み取ります。そのため、wp-config.php 内の ini_set() は効きません — その時点ですでに上限が確定しているためです。.htaccess のアプローチはホストによっては機能しますが、すべてで機能するわけではありません。うまくいかない場合は、ホストに上限を引き上げるか Xdebug を無効にするよう問い合わせてください。

Fix 4: 実際の無限再帰を突き止める

Xdebug なしの本番環境でもこのエラーが出る場合、何かが本当に制御不能な再帰を起こしています。よくある原因はこちらです：

• プラグインがフィルターにフックし、そのフィルターをトリガーする関数を呼び出している
• 別のショートコードをレンダリングするショートコードが、最初のショートコードを再び呼び出している
• カスタム Walker クラスがその内部で wp_nav_menu() を呼び出している
• ベースケースがない、またはベースケースに到達できない再帰関数

まずすべてのプラグインを一度に無効化して、原因を特定しましょう：

# SSH 経由 — plugins フォルダを一時的にリネーム
mv wp-content/plugins wp-content/plugins_backup
mkdir wp-content/plugins

エラーが消えた場合は、プラグインを1つずつ有効化して再発するものを探します。それが犯人です。

ループが始まる場所を特定するには、疑わしいフックにバックトレースを仕込んでください：

add_filter('the_content', function($content) {
    debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS);
    return $content;
}, 5);

スタックトレースの出力を確認してください。コールスタックの末尾付近に繰り返し現れる関数名が、再帰が循環している場所です。

修正の確認

ページをリロードして、正常に表示されることを確認します。次に、コマンドラインから Xdebug が新しい値を読み取っているか確認します：

php -r "echo ini_get('xdebug.max_nesting_level');"
# 512（または設定した値）が表示されるはず

WordPress 内から確認したい場合は、一時的なテーマファイルに以下を追加してください：

<?php
echo ini_get('xdebug.max_nesting_level');

まだ 100 と表示される場合は、Web サーバーが編集した php.ini を読み込んでいません。CLI、PHP-FPM、Apache モジュールはそれぞれ異なる ini ファイルを読み込む可能性があります。Web サーバーのコンテキストで php --ini を実行するか（または phpinfo() を確認して）、実際に使用されているファイルを特定してください。

ローカル開発環境チートシート

• Lando: .lando.yml の config: php: 以下に xdebug.max_nesting_level: 512 を追加し、lando rebuild を実行
• Valet: /usr/local/etc/php/8.x/conf.d/ext-xdebug.ini を編集
• Docker: 環境変数 XDEBUG_CONFIG=max_nesting_level=512 を設定するか、カスタム ini ファイルをコンテナにマウント
• MAMP: /Applications/MAMP/bin/php/phpX.X/conf/php.ini を直接編集し、GUI から MAMP を再起動