【ITニュース解説】Activer WP_DEBUG et lire debug.log sans casser le site en production

WordPressサイトを運用していると、突然サイトが表示されなくなったり、一部の機能が動かなくなったりする事態に遭遇することがある。サイトは通常、何が起こったか具体的なエラーメッセージを直接表示しない。これは、もしエラーの詳細を一般の訪問者に見せてしまうと、サーバー上のファイルパスや使用しているソフトウェアのバージョンといった情報が漏洩し、セキュリティ上のリスクにつながるためだ。しかし、サイトの管理者としては、エラーの原因を特定し、問題を解決する必要がある。

そこで活用するのが、WordPressのデバッグモード「WP_DEBUG」という機能だ。この機能を使えば、エラー情報をユーザーの目に触れさせることなく、裏でその内容をログファイルに記録させることができる。これにより、サイトの利用者体験を損なわず、セキュリティリスクも最小限に抑えながら、開発者がエラー情報を入手し、問題解決に役立てることが可能になる。

WP_DEBUGを有効にするには、WordPressの根幹をなす設定ファイルである「wp-config.php」を編集する。このファイルはWordPressが動作するために必要な重要な設定が記述されている。編集する場所は、「/* C'est tout, ne touchez pas à ce qui suit ! */」というコメント行よりも前だ。ここに以下の3つの定数を追記することで、デバッグモードを適切に設定できる。

まず「define('WP_DEBUG', true);」を設定する。これはWordPressのデバッグモード自体を有効にするための設定だ。これをtrueにすることで、WordPressはエラーを検知し、その情報を処理する準備を始める。

次に「define('WP_DEBUG_LOG', true);」を設定する。この定数をtrueにすることで、WordPressは発生したエラーを「wp-content/debug.log」というパスに生成されるファイルに記録するようになる。サイト上にエラーを表示させる代わりに、このログファイルに記録することで、後から内容を確認できる。

そして最も重要で、忘れられがちなのが「define('WP_DEBUG_DISPLAY', false);」という定数だ。この設定は、WordPressがエラーメッセージをウェブページ上に表示するかどうかを制御する。もしこれをtrueにしたままにすると、サイトを訪れた訪問者や検索エンジンのクローラーに、エラーメッセージがそのまま表示されてしまう。これはセキュリティリスクにつながるだけでなく、サイトの信頼性を損なうため、特に公開中のサイト（プロダクション環境）でデバッグを行う際には、必ずこの定数をfalseに設定し、エラーメッセージが画面に表示されないようにすることが極めて重要だ。

WP_DEBUGの設定は一時的なものであり、常に有効にしておくべきではない。「debug.log」ファイルはエラーが発生するたびに内容が追記されていくため、長期間放置するとファイルサイズが際限なく増大し、ホスティングサービスのディスク容量を圧迫する可能性がある。さらに、多くのWordPressインストール環境では、この「wp-content/debug.log」ファイルがHTTP経由で誰でもアクセスできる状態になっている場合があり、サイトの内部情報が外部に漏洩する重大なセキュリティホールとなる。そのため、問題を診断したらすぐに無効化し、ログファイルを削除する習慣を徹底する必要がある。

「debug.log」ファイルは、エラーが実際に発生するまで作成されない。設定を有効にした後、問題のページを再読み込みし、エラーを発生させる必要がある。その後、「wp-content/debug.log」のパスを確認すると、ファイルが作成されているはずだ。もしファイルが作成されない場合、一つは「wp-content」フォルダにWordPressがファイルを書き込む権限がない場合が考えられる。もう一つは、WordPress自体が正常に起動していない場合で、この状況ではWordPressの設定は機能しないため、ログファイルも生成されない。このような場合は、サイトが真っ白な画面になったり、致命的なエラーが表示されたりすることが多いため、それらの情報をもとに調査を進めることになる。

ログファイルが作成されたら、その内容を読み解く。ここでは、典型的なエラーログの例を基に、どこを見て何を判断すべきか説明する。

エラーログの一例を以下に示す。 [22-Aug-2026 07:19 UTC] PHP Fatal error: Uncaught Error: Call to undefined function creebs_lab_fonction_supprimee_par_une_maj() in /var/www/html/wp-content/mu-plugins/lab-fatal.php:3 Stack trace: #0 /var/www/html/wp-settings.php(451): include_once() #1 /var/www/html/wp-config.php(139): require_once('/var/www/html/w...') #2 /var/www/html/wp-load.php(50): require_once('/var/www/html/w...') #3 /var/www/html/wp-blog-header.php(13): require_once('/var/www/html/w...') #4 /var/www/html/index.php(17): require('/var/www/html/w...') thrown in /var/www/html/wp-content/mu-plugins/lab-fatal.php on line 3

このログから読み取るべきポイントは主に三つある。 まず、エラーの種類に注目する。ログの先頭付近に「PHP Fatal error」と表示されている場合、これはサイトが完全に機能停止する「致命的なエラー」だ。「Warning（警告）」や「Notice（通知）」はサイト動作を停止させないことが多く、まずは「Fatal error」に焦点を当てるべきだ。

次に、エラーが発生したファイルパスを確認する。ログの中の「in /var/www/html/wp-content/mu-plugins/lab-fatal.php」という部分に注目する。この「in」の後に続くパスが、エラーの直接的な原因となっているファイルを示している。ファイルパスに含まれるフォルダ名（例：plugins, mu-plugins, themes, wp-includes, wp-admin）を見ることで、問題がプラグイン、テーマ、あるいはWordPress本体のどこに起因するのか見当がつく。

最も信頼性の高い情報がログの末尾にある「thrown in /var/www/html/wp-content/mu-plugins/lab-fatal.php on line 3」という行だ。これは、エラーが実際に発生した正確なファイルと行番号を示している。エラーによっては、最初に表示されるファイルパスと実際の発生場所が異なる場合があるため、この「thrown in」の行が最も正確な情報となることが多い。

また、ログの中央部分にある「Stack trace（スタックトレース）」は、WordPressがどのように動作してエラーに至ったか、関数の呼び出し履歴を示している。スタックトレースは下から上に読む。例では、「index.php」が「wp-blog-header.php」を呼び出し、それが「wp-load.php」を呼び出した、といった流れで、最終的にエラーを引き起こしたファイルへとつながる経路がわかる。直接の原因ファイルが特定しにくい場合や、エラー発生の経緯を理解したい場合に、このスタックトレースが役立つ。

エラーメッセージの中でも特に「Call to undefined function」は、サイトのアップデート後に頻発する。これは「未定義の関数が呼び出された」という意味で、あるプラグインやテーマが、WordPressやPHPの新しいバージョンではもはや存在しない、古い関数を呼び出そうとしていることを示している。この場合、問題はプラグインやテーマが「壊れている」のではなく、サイトの環境（WordPressやPHPのバージョン）が進化し、それらが対応できていないことにある。このような場合、正しい解決策は、問題のプラグインやテーマを最新バージョンに更新すること、あるいは、もし更新が提供されていない場合は代替機能を探して導入することだ。ファイルを直接修正しようとするのは誤った対処となる。

問題の原因を特定し、解決策が見つかったら、速やかにデバッグモードを終了させる必要がある。wp-config.phpファイルに戻り、「define('WP_DEBUG', true);」の行を「define('WP_DEBUG', false);」に変更する。これにより、デバッグモードが完全に無効になる。その後、必ず「wp-content/debug.log」ファイルを削除する。このファイルは自動では消去されず、サイトのファイルパスなど重要な情報が平文で記録されたまま残るため、セキュリティ上の観点からも速やかな削除が必須だ。

もしエラーログがWordPressのコアファイル（「wp-includes」や「wp-admin」といったフォルダ内のファイル）を示している場合、安易にそのファイルを直接編集してはならない。WordPressのコアファイルが直接エラーの原因となることは稀であり、ほとんどの場合、それは別のプラグインやテーマの問題の「症状」として現れているに過ぎない。コアファイルを編集すると、今後のWordPressのアップデート時に変更が失われたり、さらなる問題を引き起こしたりする可能性がある。コアファイルに問題が示された場合は、そのログの内容をよく分析し、専門家のアドバイスを求めることが賢明だ。