WordPressエラーログの出力設定と場所【出力されない対処法も】

この記事ではWordPressのエラーログの出力設定やどこに出力されるのかなど場所について解説します。

また、出力されない時の対象方もあわせてご紹介しております。

この記事を読むと、次のことが分かります。

WordPressのエラーログの仕組みと出力設定の全体像
エラーログファイルの場所（debug.logとサーバー側ログ）の探し方
エラーログが出力されないときに確認すべきチェックポイント

WordPressエラーログの基礎｜出力設定を理解する前に知っておきたいこと
wordpressエラーログの出力設定をざっくり全体把握しよう
wordpressエラーログの場所まとめ｜debug.logとサーバーログ
wordpressエラーログが出力されないときのチェックリスト
wordpressエラーログの読み方と原因特定のコツ
wordpressエラーログ運用の注意点｜本番環境の安全な出力設定
よくある質問（wordpressエラーログ・出力設定・場所編）
まとめ｜wordpressエラーログの出力設定と場所をおさらい

WordPressエラーログの基礎｜出力設定を理解する前に知っておきたいこと

ごとう

最初に、「そもそもエラーログとは何か」「どんな場面で使うのか」を整理しておきます。ここがぼんやりしていると、出力設定や場所の話がどうしても分かりにくく感じてしまいます。

エラーログを見ると何が分かる？（まずはイメージから）

エラーログと聞くと難しそうに聞こえますが、やっていることはとても単純です。エラーが起きたときに「いつ」「どのファイルの」「何行目」で「どんなエラーが起きたか」をメモしてくれているだけです。

よくあるトラブルと、エラーログで分かることをざっくり表にまとめてみます。

状況・トラブル例	エラーログで分かること
画面が真っ白になる	どのプラグインやテーマファイルで致命的エラーが出たか
管理画面だけエラーになる	管理画面用プラグインやfunctions.php周りのエラー
特定の投稿ページだけレイアウトが崩れる	そのテンプレートファイルやショートコードのエラー
サイト全体がやたら重い	警告やデータベース関連エラーの多発状況
お問い合わせフォームが送信できない	メール送信処理や外部API周りのエラー

こうして見ると、エラーログは「原因のヒントがまとまっているメモ帳」とイメージしてもらうと分かりやすいと思います。WordPressのエラーログの出力設定と場所を知っておくと、修正のスタート地点を素早く見つけられるようになります。

WordPressで扱う主なログの種類

WordPressの周辺では、似たような名前のログがいくつか登場します。ここで整理しておきましょう。

WordPress独自のデバッグログ（wp-content/debug.log）
PHP自体のエラーログ（サーバー側の設定で場所が決まる）
Webサーバー（Apache / Nginxなど）のエラーログ・アクセスログ

ざっくり役割を分けると、次のようなイメージです。

WordPressのデバッグログ：WordPress本体やテーマ、プラグインの動きで発生したエラーのメモ
PHPのエラーログ：サーバー上で動いているPHP全体のエラー
Webサーバーのログ：アクセス状況や通信エラーの記録

この記事では、特に「WordPressのエラーログの出力設定と場所」としてよく使う、wp-content/debug.logとPHPのエラーログを中心に話を進めていきます。

wordpressエラーログの出力設定をざっくり全体把握しよう

ごとう

次に、「どこを触ればエラーログが出るようになるのか」の全体像を見ていきます。ざっくり言うと、WordPressではwp-config.phpで出力設定をし、必要に応じてプラグインで読みやすくする、という流れになります。

wp-config.phpでの基本的な出力設定

WordPressのエラーログの出力設定は、基本的にwp-config.phpに書き込みます。よく出てくる定数と役割を表に整理してみました。

定数名	設定例	役割
WP_DEBUG	`define('WP_DEBUG', true);`	デバッグモードのメインスイッチ
WP_DEBUG_LOG	`define('WP_DEBUG_LOG', true);`	エラーをファイル（debug.log）に書き出すかどうか
WP_DEBUG_DISPLAY	`define('WP_DEBUG_DISPLAY', false);`	画面にエラーを直接表示するかどうか
SCRIPT_DEBUG	`define('SCRIPT_DEBUG', true);`	圧縮前のJS・CSSを読み込むかどうか

実務では、このあたりをセットで使うことが多いです。特に本番サイトでは「画面には出さず、ログだけ残す」という設定が大事になります。

本番・テスト環境のおすすめ出力設定例

「本番環境でWP_DEBUGをtrueにしても大丈夫？」と聞かれることが多いのですが、ポイントを押さえておけば問題なく運用できます。ここでは、環境ごとのおすすめイメージを言葉で整理しておきます。

本番サイト：WP_DEBUGとWP_DEBUG_LOGをtrue、WP_DEBUG_DISPLAYはfalseにする。エラーはdebug.logにだけ残し、画面には出さない。
ステージング環境：基本的にWP_DEBUGとWP_DEBUG_LOGをtrue、WP_DEBUG_DISPLAYもtrueにしておき、画面とログの両方で動きを確認する。
ローカル開発環境：細かいNoticeやDeprecatedも含めて見たいので、WP_DEBUG関連はすべてtrueにしてしまってOK。

特に本番環境で避けたいのは、エラー内容が画面にベタッと表示されてしまう状態です。データベースの接続情報やファイルパスなど、外部に見せたくない情報がそのまま出てしまうことがあるので、WP_DEBUG_DISPLAYの設定は慎重に扱ってください。

プラグインで楽にログを見たいとき

FTPやファイルマネージャーが苦手な場合は、プラグインを使って管理画面からエラーログを確認する方法もあります。代表的なものを挙げると、次のようなプラグインです。

Error Log Monitor
WP Debugging
Query Monitor（SQLのエラーや遅いクエリの確認にも便利）

こういったプラグインを入れておくと、「ファイルを一度もダウンロードしないでログを眺める」といったことができて、とても楽です。ただ、プラグインの入れすぎがトラブルの原因になることもあるので、「調査が終わったら停止・削除する」といった使い方がおすすめです。

wordpressエラーログの場所まとめ｜debug.logとサーバーログ

ごとう

ここからは、実際に「ログをどこで探すか」の話に入ります。WordPressのエラーログと言えばwp-content/debug.logが代表ですが、レンタルサーバーのPHPエラーログも一緒に覚えておくとトラブル対応がかなり楽になります。

WordPress標準debug.logの場所とパスのイメージ

wp-config.phpでWP_DEBUG_LOGをtrueにすると、特にパスの指定がなければ、wp-content直下にdebug.logというファイルが作られます。代表的なパスのイメージを表にまとめます。

サイトのトップパス例	debug.log の標準の場所
/home/ユーザー名/public_html/	/home/ユーザー名/public_html/wp-content/debug.log
/var/www/html/	/var/www/html/wp-content/debug.log
/home/ユーザー名/example.com/	/home/ユーザー名/example.com/wp-content/debug.log

FTPソフトやサーバーのファイルマネージャーでWordPressのフォルダを開き、wp-contentフォルダの中を見てみましょう。そこにdebug.logがあれば、それがWordPressのエラーログの1つです。

また、WP_DEBUG_LOGにパスを指定している場合は、その指定した場所にファイルが作られます。例えば、define('WP_DEBUG_LOG', '/home/ユーザー名/logs/wp-debug.log');のように書いていると、wp-contentではなくlogsフォルダ配下に出力されます。

レンタルサーバーごとのerror_logの場所（代表例）

WordPressのdebug.logだけでは分からないエラーもあります。そんなときは、レンタルサーバー側のPHPエラーログも合わせて確認すると、原因にたどり着きやすくなります。よく使われるサーバーのイメージを表にまとめました。

サーバー名（例）	主なエラーログの場所・見方のイメージ
エックスサーバー	サーバーパネルの「ログ」→各ドメインのerror_log
ConoHa WING	コントロールパネルの「サイト管理」→「ログ」→error.log
さくらのレンタルサーバ	/logs/error.log や、ドメイン配下のerror_log
ロリポップ！	管理画面の「ログ」メニュー、または/logs/error_log
Kinsta などのマネージドホスティング	ホスティング管理画面の「ログ」メニュー、SFTPで/logs/配下

名称はサーバーごとに少しずつ違いますが、「コントロールパネル内のログメニューにPHPエラーやアクセスログがまとまっている」と考えておくと探しやすいです。WordPressのエラーログの場所としては、テーマやプラグインのエラーはdebug.log、サーバー全体に関係するエラーはerror_log、と役割を分けて覚えておくと頭の中が整理しやすくなります。

wordpressエラーログが出力されないときのチェックリスト

ごとう

【稼げるキーワード教えます】
▼　　▼　　▼

ここからは、よくつまずくポイントである「設定したはずなのにエラーログが出てこない…」というケースを見ていきます。私も一度ハマると何時間も使ってしまったので、順番に確認できるチェックリストとしてまとめました。

まずはWordPress側の設定を疑う

かなり多いのが、単純な設定ミスや書く場所の勘違いです。次の項目を落ち着いて確認してみてください。

wp-config.phpにWP_DEBUGとWP_DEBUG_LOGが正しく書かれているか
セミコロン（;）やシングルクォート（’）の打ち間違いがないか
/* That's all, stop editing! Happy publishing. */より前の位置に定数を記述しているか
別のプラグインが独自にエラーログ設定を上書きしていないか

まずは「wp-config.phpの書き方が正しいか」「そもそもPHPエラーが起きているか」「それでもログファイルが増えないのか」という順番で切り分けると、落ち着いて状況を整理できます。

ファイル権限・パス・ディスク容量を確認する

WordPressのエラーログが出力されないとき、ファイルの権限やディスク容量が原因になっていることもよくあります。特に複数人で運用しているサーバーでは、知らないうちに権限設定が変わっていることもあります。

チェック項目	確認する内容
wp-content の権限	サーバーからの書き込みが許可されているか（例：755程度）
debug.log の権限	書き込み可になっているか（例：644〜664程度）
所有者・グループ	Webサーバーと同じユーザー／グループになっているか
ディスク使用量	サーバーの容量がいっぱいになっていないか
パス指定	WP_DEBUG_LOGに書いたパスに打ち間違いがないか

私がよく踏んだのは「絶対パスの1文字ミス」と「ディスク容量の不足」です。特に、WP_DEBUG_LOGの値に独自パスを指定している場合は、そのパスが本当に存在しているか、フォルダごと書き込み可能かをセットで確認してみてください。

サーバー設定やphp.iniが原因のケース

ここまで見てもWordPressのエラーログが出ない場合は、サーバー側の設定でエラーログの出力先が上書きされている可能性があります。

php.iniのerror_log設定で、特定のファイルパスにエラーが集約されている
マルチPHP環境で、対象サイトだけ別のphp.iniを参照している
.htaccessにphp_value error_logが書かれていて、そこに出ている

どうしても見つからない場合は、PHPファイルのどこかに一時的にerror_log('WordPressのエラーログテストです');のような一行を追加してアクセスし、その文字列をサーバー全体で検索する方法もあります。見つかったファイルが「実際にエラーが吐かれているログファイル」なので、そこから「なぜdebug.logに出てこないのか」を逆算していくと突破口になることが多いです。

wordpressエラーログの読み方と原因特定のコツ

ごとう

ここでは、実際にエラーログを開いたときに「どこを見ればいいか」をお話しします。出力設定や場所が分かっても、読み方が分からないと活かしきれないので、最低限のポイントだけ押さえておきましょう。

ログ1行の構造をざっくり理解する

エラーログの1行には、だいたい次のような情報が含まれています。

日時
エラーレベル（Warning / Fatal error / Notice / Deprecated など）
エラーメッセージの本文
ファイルのパス
行番号

代表的な見どころを表に整理すると、こんな感じです。

見どころ	例	注目ポイント
エラーレベル	Fatal error / Warning / Notice / Deprecated	どの程度深刻なエラーかの目安になる
メッセージ本文	Call to undefined function 〜など	何が原因でエラーになっているかのヒント
ファイルパス	`/wp-content/plugins/〇〇/…` など	どのテーマ・プラグイン周りかを判断する材料
行番号	on line 123 など	コードのどのあたりで問題が起きているか

最初から全文字を理解しようとすると挫折しがちなので、「どのプラグイン（またはテーマ）の、どのファイル名あたりまで分かればOK」と割り切るのがおすすめです。例えば、/wp-content/plugins/contact-form-7/…というパスが出ていれば、「まずはそのプラグインを疑ってみよう」というようにあたりをつけられます。

よくあるエラーと対処パターン

最後に、WordPressのエラーログによく出てくるエラーの例と、ざっくりした対処方針を表にまとめます。

エラーの例（ざっくり）	状況のイメージ	主な対処の方向性
Fatal error: Call to undefined function …	存在しない関数を呼び出している	プラグインのバージョンや読み込み順、書き間違いを確認
Fatal error: Allowed memory size exhausted …	PHPのメモリ上限を超えている	メモリ上限の引き上げや、重いプラグインの停止・見直し
Warning: require_once() failed to open stream …	必要なファイルが読み込めない	ファイルの存在、パスの指定、権限を確認
Notice: Undefined index / Undefined variable	配列キーや変数が定義されていない	開発環境ではコードを修正、本番では優先度低めで対応
Deprecated: Function xxx is deprecated	古い書き方が非推奨になっている	テーマやプラグインのアップデート、コード修正を検討

WordPressのエラーログの出力設定と場所さえ押さえておけば、あとはこうしたパターンを少しずつ覚えていくだけで、トラブル対応のスピードがかなり変わってきます。「全部理解しないといけない」と力を入れすぎず、「ファイルパスとエラーレベルだけでも見る」といったライトな使い方から慣れていくのがおすすめです。

wordpressエラーログ運用の注意点｜本番環境の安全な出力設定

ごとう

最後に、本番サイトでWordPressのエラーログを運用するときの注意点をまとめます。設定を間違えると、エラー内容が外から丸見えになったり、ログファイルが際限なく増えてサーバーを圧迫したりするので、このあたりはあらかじめ意識しておきましょう。

debug.logを公開しないためのポイント

まず確認してほしいのは、「debug.logにブラウザから直接アクセスできないか」です。

https://あなたのドメイン/wp-content/debug.log
https://あなたのドメイン/logs/error.log

こういったURLにアクセスして、中身がそのまま表示されてしまうと危険です。対策としては、次のようなものがあります。

wp-content配下に.htaccessを置き、.logファイルへの直接アクセスを拒否する
debug.logをWeb公開ディレクトリの外（例：/home/ユーザー名/logs）に出力する
そもそも本番環境では、必要な期間だけログを有効化する運用にする

特にクライアントサイトを預かっている場合、WordPressのエラーログから意図せず情報が漏れるのは絶対に避けたいところです。「ログは内部の人だけが見られる場所に出す」という意識を持って設定しましょう。

ログをためすぎない工夫

WordPressのエラーログは、放っておくとあっという間にサイズが大きくなります。私もdebug.logが何十MBにも膨らんでいて、開くだけで大変だったことがあります。

調査が終わったらWP_DEBUGをfalseに戻し、一度debug.logを削除してリセットする
サーバーのログローテーション機能を使い、古いログは自動削除にする
ステージングやローカル環境では常にログを有効、本番では期間を区切って有効化する

「常にログを取り続ける」のではなく、「必要なときだけONにして終わったらOFFにする」という運用にしておくと、トラブルも少なくなります。WordPressのエラーログの出力設定も、日々の運用ルールの一部として考えておくと良いですね。

よくある質問（wordpressエラーログ・出力設定・場所編）

ごとう

ここからは、私が相談を受けることが多い、WordPressのエラーログの出力設定や場所に関する質問にQ&A形式で答えていきます。

Q1. wordpressエラーログの場所はdebug.logだけ見ればいいですか？

A. 多くのケースでは、wp-content/debug.logだけで十分なヒントが得られます。ただ、PHP全体のエラーやサーバー設定由来の問題を追いかける場合は、レンタルサーバーの管理画面から見られるerror_logも合わせて確認した方がスムーズなことが多いです。

まずはWordPressのエラーログの場所としてdebug.logを開いてみて、それでも原因がぼんやりしているときに、サーバー側のエラーログも一緒に見る、という二段構えがおすすめです。

Q2. wordpressエラーログがどうしても出力されないときの最終手段はありますか？

A. あります。WP_DEBUGやWP_DEBUG_LOGの設定、wp-contentの権限やディスク容量、php.iniの設定などを確認してもログが出ない場合は、PHPファイルのどこかに一時的にerror_log('テスト');と書いてみてください。

そのうえでサーバー全体を「テスト」という文字で検索すると、該当の文字列が書き込まれたログファイルが見つかります。それが実際にPHPエラーが吐き出されているログファイルなので、そこを起点にWordPressのエラーログの出力設定や場所との関係を整理していくと、道が開けることが多いです。

Q3. 本番環境でwordpressエラーログ出力設定をONにしたままでも大丈夫ですか？

A. 条件付きで大丈夫です。WP_DEBUG_DISPLAYをfalseにして画面にエラーを出さないこと、debug.logをインターネットから直接見えない場所に置くこと、この2つが守られていれば、本番環境でWordPressのエラーログを出力し続けても大きな問題は起きにくいです。

ただし、ログを取りっぱなしにするとファイルが肥大化するので、「調査が終わったらWP_DEBUGをfalseに戻す」「定期的にdebug.logをチェックして不要になったら削除する」といった運用ルールを決めておくと安心です。

まとめ｜wordpressエラーログの出力設定と場所をおさらい

ここまでの内容を振り返ります

WordPressのエラーログは、いつ・どこで・何が起きたかを教えてくれる「トラブル原因の地図」のような存在
出力設定の中心はwp-config.phpのWP_DEBUG / WP_DEBUG_LOG / WP_DEBUG_DISPLAYで、本番と開発で設定を分けて使うのがポイント
エラーログの場所は、WordPressのdebug.log（wp-content/debug.log）と、サーバー側のerror_logをセットで覚えておくと便利
ログが出力されないときは「設定→権限・パス→サーバー設定」の順にチェックし、最終手段としてerror_log('テスト');で実際のログ場所を探す
本番環境では、debug.logが外から丸見えにならないようにしつつ、ログをためすぎない運用ルールを決めておくことが大切

今日できる最初の一歩として、まずはあなたのサイトのwp-config.phpを開き、WP_DEBUG・WP_DEBUG_LOG・WP_DEBUG_DISPLAYがどう設定されているかを確認してみてください。そのうえで、wp-contentフォルダにdebug.logがあるか、レンタルサーバーのログ画面からerror_logが見られるかを一度チェックしてみるのがおすすめです。

「どこに何が出ているか」を一度把握しておくだけでも、いざトラブルが起きたときの心の余裕がかなり違ってきます。少しずつWordPressのエラーログの出力設定や場所、読み方に慣れていって、トラブル対応のストレスを減らしていきましょう。

記事を読んだらコチラ
▼　　▼　　▼