「サイトでエラーが出ています」という連絡が来たとき、手元にあるのは真っ白な画面か、英語が1行だけ表示された画面です。ここから原因まで辿り着く道は2本しかありません。サーバーが記録したエラーログを読むか、WordPress側にデバッグ出力をさせるか。どちらも数分あれば見られるのに、使い分けが分からないまま「プラグインを片っ端から無効化する」に進んでしまう例をよく見ます。ログの出し方、1行の読み方、そして大量に出てくる無関係な警告をどう捨てるかを、実際の切り分け手順と一緒に書きます。
見るログは2種類あって、役割が違います
ひとつはサーバーが記録しているエラーログです。レンタルサーバーなら管理画面からダウンロードできるか、logs のようなディレクトリに置かれています。PHPが処理を中断したときの記録がここに残ります。WordPressが動く前に落ちている場合でも記録されるのが利点で、真っ白な画面の調査ではまずここを見ます。
もうひとつがWordPress側のデバッグログです。wp-config.php の設定で有効にすると、標準では wp-content/debug.log に出力されます。こちらはWordPressの内部から見た記録なので、どのプラグインが警告を出しているか、非推奨の関数がどこで使われているかまで分かります。プラグインやテーマの相性を切り分けるときに効きます。
そして、この2つのどちらにも出ない不具合があります。ボタンを押しても反応しない、モーダルが開かない、送信できない。この種の症状はブラウザ側のJavaScriptで起きているので、サーバーのログをいくら眺めても何も見つかりません。実際に「特定のページのボタンが反応しない」という相談を受けたことがありますが、こういうときはブラウザの開発者ツールのコンソールから入ります。表示の崩れも同じで、たとえば記事本文の画像サイズが揃わない・大きすぎるときの調整のような症状は、ログではなくCSSとメディア設定を見ることになります。
出力の設定は3行。ただし本番では出し方に条件があります
デバッグログを取るには、wp-config.php の /* 編集が必要なのはここまでです */ の行より上に次を書きます。
<code>define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);</code>大事なのは3行目と4行目です。WP_DEBUG_DISPLAY を true のままにすると、エラーが画面に直接表示されます。訪問者に見えるだけでなく、サーバー内のディレクトリ構成まで露出します。本番で調査するときは、必ず画面には出さず、ファイルにだけ書く設定にしてください。
もうひとつ、wp-content/debug.log はWebから見える場所にあります。URLを直接入力すれば読めてしまう構成なので、調査の間だけ有効にして、終わったら false に戻すのが基本です。長期間出しっぱなしにすると、警告が積み上がってファイルが数百MBに育ちます。.htaccess で .log への直接アクセスを拒否しておくか、出力先を公開領域の外へ変える方法もあります。
1行の読み方
致命的なエラーは、だいたいこういう形で記録されます。
<code>PHP Fatal error: Uncaught Error: Call to undefined function my_helper() in /home/username/yoursite/public_html/wp-content/themes/your-theme/functions.php:42</code>
読む順番は決まっています。先頭の種別で深刻度が分かり、次のメッセージで何が起きたかが分かり、最後のパスと行番号で場所が分かります。実務でいちばん価値があるのは3つめです。functions.php の42行目、と分かった時点で、原因の候補は一気に絞れます。スタックトレースが続く場合は、いちばん下の行が最初の呼び出し元なので、そこから読むと早いです。テーマの編集で落ちたときの戻し方はfunctions.phpを編集して落ちたサイトを元に戻す方法にまとめています。
| 種別 | 意味 | 扱い |
|---|---|---|
| Fatal error | 処理が停止した | 最優先。白い画面や500の直接原因 |
| Warning | 処理は続いたが問題がある | 症状と時刻が一致するなら追う |
| Notice | 未定義の変数など、行儀の問題 | 症状と無関係なことが多い |
| Deprecated | 将来のPHPで動かなくなる書き方 | 今の不具合の原因ではない。ただし更新前に確認 |
| Parse error | 文法エラー。実行以前の問題 | 直前に編集したファイルが確実に原因 |
無関係な警告を捨てる基準
実際にログを開くと、まず量に圧倒されます。数千行のうち9割が同じ Deprecated の繰り返し、ということも珍しくありません。ここで全部を理解しようとすると先に進めなくなります。
捨てる基準は4つです。第一に時刻。エラーログには日時が付いているので、症状が出た時間帯の前後だけを切り出します。これだけで大半が消えます。第二に種別。Fatal error と Parse error だけを先に拾います。第三にファイルパス。自分たちが触ったテーマやカスタマイズ部分か、それとも第三者のプラグインの内部かで、対処の方向が変わります。第四に直近の更新。数日以内に更新されたプラグインやテーマがあれば、そこが最有力です。
逆に言うと、症状の時刻と一致しない Notice や Deprecated は、そのときは放置して構いません。無害ではありませんが、今起きている不具合の原因ではありません。ただし、PHPのバージョンを上げる予定があるなら、Deprecated は事前に潰しておく対象になります。
実際の切り分けは、この順番で回しています
複数の店舗向けサイトを運用している事業者から、不具合が起きるたびに連絡をもらう関係が続いています。1件あたりは数千円規模の小さな対応ですが、進め方はいつも同じです。
まず、実際のURLを開いてエラー画面とステータスコードを確認します。500なのか、404なのか、真っ白なのかで、その先の道が分かれます。サーバー側の切り分けはサイトが表示されないときにまず確認するサーバー側の4か所に書いたとおりです。次に WP_DEBUG かサーバーのエラーログでPHPのエラーを特定します。3番目に、直近で更新されたプラグインやテーマがないかを見ます。4番目に、疑わしいプラグインを一時的に無効化して切り分けます。5番目にキャッシュをクリアし、最後に復旧を確認します。この順番なら、数十分で終わります。
このサイト群にはセキュリティ系のプラグイン（SiteGuard）が入っていて、致命的エラーが起きると管理者宛に自動で通知メールが飛ぶようになっていました。この通知の本文には該当ファイル名と行番号が書かれています。つまり、連絡をもらう時点でそのメールを転送してもらえれば、最初の2工程を飛ばせます。同じような通知が届く設定になっているサイトは多いので、不具合の相談をするときは、まずそのメールを探してみてください。
正直に書くと、この案件には反省があります。当時、納品時のやり取りに「何のエラーが、なぜ起きて、どう直したか」を残していませんでした。そのため、後日に似た症状が出たとき、過去の対応を参照できませんでした。今は、どんなに小さな対応でも「原因:」「対処:」の2行だけは必ず記録に残すようにしています。ログを読む技術より、この2行のほうが次回の復旧時間を短くします。
もうひとつの反省は、本番を直接触ってしまいがちなことです。すぐ直せる規模の不具合ほど、バックアップを取らずに編集を始めます。最低限、編集前のファイルの控えは取ってから手を入れてください。
調査が終わったあとにやること
デバッグ出力は必ず戻します。WP_DEBUG を false にし、debug.log が残っていれば中身を確認したうえで削除します。放置すると、次に調べるときにどこからが今回の記録なのか分からなくなります。
サーバーのエラーログには保存期間があり、数日から数週間で消えるところもあります。不具合が起きたら、原因が分からない段階でもログをダウンロードして手元に置いてください。後から「あのときのログを見たい」と思っても、すでに無いことがあります。
そして、復旧よりも先にいつから起きているかを確定させます。更新の直後なのか、特定の日時から急に始まったのか。ログの時刻とプラグインの更新履歴を突き合わせれば、たいていの原因はここで見当がつきます。復旧を急いで先に上書きしてしまうと、この情報が消えます。緊急で止まっているサイトの復旧については障害復旧の対応内容のページにまとめています。
よくある質問
画面が真っ白で、ログにも何も出ていません
ログの出力自体が止まっている可能性があります。まずサーバー側のエラーログを見て、そこにも記録がなければ wp-config.php でデバッグ出力を有効にします。それでも何も出ない場合、PHPのメモリ上限に達して途中で落ちているか、wp-config.php 自体に文法エラーがあってWordPressが起動していないかのどちらかが多いです。直前に編集したファイルがあれば、まずそれを元に戻して切り分けてください。
Deprecated の警告が大量に出ています。危険ですか
今すぐ壊れるものではありません。将来のPHPバージョンで動かなくなる書き方が使われている、という予告です。放置しても表示には影響しませんが、2つだけ注意点があります。ひとつは、ログファイルが肥大化してディスク容量を圧迫すること。もうひとつは、サーバー側でPHPのバージョンを上げる予定があるなら、その前に対象のプラグインやテーマを更新しておく必要があることです。
サーバーの管理画面に入れず、ログを見られません
WordPressの管理画面にだけ入れる状況なら、wp-config.php をファイル編集機能かFTPで書き換えてデバッグログを出す方法があります。それも難しい場合は、サイト表示のURL、エラー画面のスクリーンショット、直近に何をしたか（更新した、プラグインを入れた、記事を編集した）の3点を揃えてください。この3点だけでも、原因の候補はかなり絞れます。契約しているサーバー会社が分かれば、ログの取得方法を案内することもできます。
