WordPressのデバッグモードとは、PHPエラーや警告、WordPress内部の非推奨処理などを確認し、トラブルの原因を調べやすくするための機能です。
WordPressでは主に WP_DEBUG という設定を使い、必要に応じてエラーをログへ保存したり、画面には表示しないようにしたりします。
「画面が真っ白になった」「プラグイン更新後に500エラーが出た」「特定操作だけ失敗する」といった場合に役立ちますが、本番サイトでエラー内容を画面へ表示すると、サーバー内部の情報が訪問者に見える可能性があります。 そのため、初心者が使う場合は画面表示をOFFにしてログへ記録する設定が基本です。
30秒でわかる結論
- WordPressのデバッグモードは、PHPエラーや警告を確認して原因を調べるための機能
- 基本設定は
wp-config.phpのWP_DEBUG - ログ保存には
WP_DEBUG_LOGを使う - 画面表示は
WP_DEBUG_DISPLAYで制御する - 本番サイトではエラーを画面に表示しない
- 通常は調査が終わったらデバッグモードをOFFへ戻す
- 変更前にバックアップを取り、wp-config.phpの編集ミスに注意する
WordPressのデバッグモードとは？
WordPressには、開発者やサイト管理者がエラーを調査しやすくするためのデバッグ機能があります。
中心になるのが WP_DEBUG という定数です。
初心者向けに言い換えると
通常のWordPressでは見えにくい「内部で何が失敗しているか」を確認しやすくするための診断モードです。 エラー原因を直す機能そのものではなく、原因を見つけるための情報を増やす機能と考えてください。
WordPress公式では、WP_DEBUG を有効にするとPHPのエラー報告レベルが上がり、WordPress内部でも非推奨関数などに関する通知が有効になります。
WP_DEBUG・WP_DEBUG_LOG・WP_DEBUG_DISPLAYの違い
WordPressのデバッグでは、似た名前の設定が複数あります。 初心者は次の3つを区別できれば十分です。
| 設定 | 役割 |
|---|---|
| WP_DEBUG | デバッグモード全体を有効にする |
| WP_DEBUG_LOG | エラーをログファイルへ保存する |
| WP_DEBUG_DISPLAY | エラーをWebページ上へ表示するか決める |
安全に調査する基本形 ＝ WP_DEBUGをON ＋ LOGをON ＋ DISPLAYをOFF
WP_DEBUG_LOG と WP_DEBUG_DISPLAY は、WP_DEBUG が有効なときに利用する設定です。
ログへ保存しながら、訪問者にはエラーを見せない構成にできます。
デバッグモードを有効にする方法
WordPressのデバッグ設定は、通常 wp-config.php を編集して行います。
FTP、ファイルマネージャー、SSHなど、利用中サーバーで提供されている方法でファイルを編集します。
編集前に必ずバックアップ
wp-config.phpはWordPressの重要な設定ファイルです。記述ミスがあるとサイトが表示されなくなる可能性があります。編集前に元ファイルを保存し、すぐ戻せる状態にしてください。
基本的な設定例
本番サイトで一時的に調査する例
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );この設定では、デバッグを有効にしつつ、エラーを画面には表示せずログへ保存します。 WordPress公式も、ログ保存と画面非表示を組み合わせた例を案内しています。
記述する場所
設定は wp-config.php 内の、WordPressが案内している編集終了コメントより前へ記述します。
すでに WP_DEBUG が定義されている場合は、同じ定数を重複して書かず、既存設定を変更してください。
debug.logはどこに保存される？
WP_DEBUG_LOG を true にすると、通常はWordPressのコンテンツディレクトリ内に debug.log が作成されます。
一般的な構成では次の場所です。
一般的な保存場所
/wp-content/debug.log
ログには、PHPのFatal error、Warning、Notice、Deprecatedなど、問題を調べる手掛かりになる情報が記録される場合があります。
ログで確認するポイント
- エラーが発生した日時
- Fatal errorやWarningなどの種類
- 問題が発生したファイル名
- プラグイン名・テーマ名がパスに含まれていないか
- 何行目でエラーが起きたか
ただし、ログに出た最後の行だけを見て原因と断定しないでください。 同じエラーが繰り返されている場合や、別のエラーが先に発生している場合もあります。
デバッグログの見方
デバッグログには英語のエラーメッセージが並びますが、初心者はまずエラーの種類とファイルパスを見ると原因を絞りやすくなります。
| 表示例 | 意味の目安 |
|---|---|
| Fatal error | 処理を継続できない重大なPHPエラー |
| Warning | 警告。処理が継続する場合もある |
| Notice | 注意情報。コード改善の手掛かりになる |
| Deprecated | 非推奨になった機能を使っている可能性 |
見るべき部分の例
ログのファイルパスに /wp-content/plugins/example-plugin/ が含まれていれば、そのプラグインがエラー発生箇所に関係している可能性があります。
ただし、呼び出された側でエラーが表面化しているだけの場合もあるため、すぐ削除せず切り分けます。
デバッグモードが役立つ場面
画面が真っ白
有効度：高
PHPのFatal errorなどがログに出れば、原因となるプラグイン・テーマ・PHP処理を絞り込めます。
500エラー
有効度：高
WordPress側のPHPエラーならdebug.logに手掛かりが残る場合があります。ただしWebサーバー側ログも必要なことがあります。
プラグイン更新後の不具合
有効度：高
対象プラグインのファイル名や関数名がログに現れるか確認します。
表示崩れだけ
有効度：中
PHPエラーではなくCSSやJavaScriptが原因なら、ブラウザ開発者ツールなど別の確認方法も必要です。
本番サイトでWP_DEBUG_DISPLAYをONにしない
本番サイトで最も注意したいのが、デバッグ情報を画面へ表示することです。 エラーメッセージには、サーバー内のファイルパス、プラグイン名、テーマ名、コード構成などが含まれる場合があります。
訪問者に内部情報を見せない
原因調査中でも、本番サイトでは WP_DEBUG_DISPLAY を false にし、エラーはログで確認する方が安全です。WordPress公式もデバッグツールを本番サイトで常用することを推奨していません。
特に会社サイト、ECサイト、会員サイトなどでは、不特定多数の訪問者へ技術情報を表示しないことが重要です。
デバッグが終わったら元に戻す
原因調査が終わったら、通常はデバッグモードを無効へ戻します。
デバッグを無効にする基本例
define( 'WP_DEBUG', false );
また、調査中に作成された debug.log が不要になった場合は、必要な情報を保存したうえで削除または整理します。
ログを長期間放置するとファイル容量が増える場合があります。
調査終了後の確認
- WP_DEBUGをfalseへ戻したか
- エラー表示が画面に出ていないか
- debug.logを必要以上に残していないか
- 原因となったプラグイン・テーマを修正または更新したか
- サイト表示・管理画面・フォームなどを再確認したか
WP_DEBUGだけでは分からないエラーもある
WordPressのデバッグログですべての障害原因を確認できるわけではありません。 WordPressより手前のWebサーバーやPHP-FPM、データベース、OS、レンタルサーバー側で問題が起きている場合は、別のログを見る必要があります。
| 問題 | 確認先の例 |
|---|---|
| WordPress・PHP処理 | debug.log |
| Webサーバーエラー | サーバーのエラーログ |
| データベース障害 | DB・サーバー側ログや接続設定 |
| JavaScriptエラー | ブラウザの開発者ツール |
| サーバー障害 | レンタルサーバーの障害情報 |
「debug.logに何も出ない＝WordPressに問題がない」とは限りません。 どの層で失敗しているかを切り分けることが重要です。
SCRIPT_DEBUGとは？
WordPressには SCRIPT_DEBUG という別のデバッグ設定もあります。
これはWordPressコアのJavaScriptやCSSについて、圧縮された通常版ではなく開発用ファイルを読み込むための設定です。
通常のサイト運営では不要
SCRIPT_DEBUGは、WordPressコアのJavaScriptやCSSを調査・開発するときに使う設定です。一般のサイト運営者がPHPエラーを確認する目的なら、まずWP_DEBUG・WP_DEBUG_LOG・WP_DEBUG_DISPLAYを理解すれば十分です。
SAVEQUERIESは初心者が使う必要がある？
WordPressにはデータベースクエリを保存する SAVEQUERIES というデバッグ向け設定もあります。
どのSQLが実行されたか、実行時間、呼び出し元などを調べる用途があります。
ただし、クエリ情報を保存するためサイトへ追加負荷がかかります。 一般的なトラブル確認で初心者が常時有効にするものではありません。
必要な機能だけ有効にする
デバッグ機能は「全部ONにすれば詳しく分かる」と考えないでください。調べたい問題に必要な設定だけを一時的に使い、調査後は戻すのが基本です。
よくある設定ミス
trueとfalseを文字列にする
WordPress公式では、true と false はクォーテーションで囲まないよう案内されています。
正しい例
define( 'WP_DEBUG', false );
'false' のように文字列として書くと、意図した無効設定にならない可能性があります。
同じ定数を重複して定義する
すでにWP_DEBUGの行があるのに、新しく同じ行を追加するのではなく、既存設定を確認して変更します。
本番サイトで表示をONにしたままにする
一時確認が終わったのに WP_DEBUG_DISPLAY をONのまま放置すると、エラー発生時に内部情報が表示される可能性があります。
ログだけ見てファイルを削除する
ログにプラグイン名が出ていても、そのプラグインが必ず根本原因とは限りません。 停止・更新・互換性確認など、影響の小さい方法から切り分けます。
教科書判定
初心者は「画面に出さず、ログへ残す」使い方を覚えれば十分
WordPressで原因不明のPHPエラーを調べるときは、WP_DEBUGを有効、WP_DEBUG_LOGを有効、WP_DEBUG_DISPLAYを無効にしてログを確認する方法が基本です。
ただし、本番サイトで常時デバッグを有効にする必要はありません。 変更前にバックアップを取り、調査が終わったらWP_DEBUGを無効へ戻してください。
FAQ
Q．WP_DEBUGをONにするとサイトが壊れますか？
通常はエラー報告を有効にする設定なので、それだけでサイトを壊すものではありません。ただしwp-config.phpの編集ミスでPHPエラーが起きる可能性があるため、編集前にバックアップを取ってください。
Q．debug.logが作成されません
WP_DEBUGとWP_DEBUG_LOGが有効か確認してください。また、まだ記録対象のエラーが発生していない、書き込み権限に問題がある、ホスティング側でログ設定が制御されているなどの可能性もあります。
Q．デバッグログにプラグイン名が出たら削除してよいですか？
すぐ削除するのは避けてください。停止して症状が変わるか、更新版があるか、PHP・WordPressとの互換性に問題がないかを確認します。削除で設定データを失うプラグインもあります。
Q．WP_DEBUGをONにしたまま運用してもよいですか？
本番サイトでの常時利用はおすすめしません。WordPress公式でもデバッグ機能は主に開発・ステージング環境向けとされています。必要な調査が終わったら無効へ戻します。
Q．500エラーなら必ずdebug.logに原因が出ますか？
必ずではありません。WordPressが処理を始める前のWebサーバー設定、PHP-FPM、サーバー障害などが原因なら、WordPressのdebug.logではなくサーバー側のエラーログを確認する必要があります。
まとめ
この記事の結論
- WordPressのデバッグモードはエラー原因を調べるための機能
- 中心となる設定はWP_DEBUG
- WP_DEBUG_LOGでエラーをログへ保存できる
- 本番サイトではWP_DEBUG_DISPLAYをfalseにする
- 通常のログ保存先はwp-content/debug.log
- デバッグログだけで分からない障害もある
- 調査後はWP_DEBUGをfalseへ戻す
WordPressのデバッグモードは、トラブルを自動修復する機能ではありません。 「どこで何が失敗しているか」を確認するための診断手段です。 初心者は、エラーを訪問者へ表示せずログへ記録し、原因を1つずつ切り分ける使い方を覚えておけば十分です。
「エラーログとは？確認する場面と見方を初心者向けに解説」「WordPressで画面が真っ白になる原因と対処法」もあわせて確認してください。