2026年9月7日

WordPressのwp-config.phpのデバッグ設定を本番環境でオフにする重要性と正しい書き方

セキュリティ

本番サイトで WP_DEBUG を有効にしたままにすると、エラーメッセージを通じてサーバーのファイルパスや使っているプラグインが訪問者に見えたり、誰でもダウンロードできる場所にログが溜まったりします。この記事では、デバッグ関連の定数がそれぞれ何をしているかを整理したうえで、本番向けの安全な書き方、WP_DEBUG を false にしてもエラーが表示されてしまう理由、本番で一時的に調査するときの手順までを説明します。

本番でデバッグ表示を残すと何が起きるか

WP_DEBUG を true にすると、PHPの警告や非推奨の通知（Notice、Deprecated）まで画面に出るようになります。開発中は便利ですが、本番では次のような問題につながります。

内部情報の露出: エラー文には /home/ユーザー名/public_html/wp-content/plugins/○○/... のようなサーバー上のフルパスや、プラグイン名、関数名が含まれます。攻撃者にとっては、どのプラグインのどのバージョンが動いているかを推測する材料になります
データベースエラーの表示: デバッグ表示が有効な状態では、クエリの失敗時にSQL文の一部が画面に出ることがあります
画面や機能の崩れ: HTMLの出力前に警告文が出ると「Cannot modify header information - headers already sent」が発生し、ログインやリダイレクトが失敗します。REST API や Ajax の応答に警告文が混ざると、ブロックエディターの保存が失敗する原因にもなります
ログファイルの公開: WP_DEBUG_LOG を true にすると、既定では wp-content/debug.log に書き出されます。この場所はWebから直接アクセスできるため、URLを知られれば誰でも内容を読めてしまいます

いずれも「すぐにサイトが乗っ取られる」ものではありませんが、攻撃の下調べを楽にし、利用者には壊れた画面を見せることになります。

デバッグ関連の定数を整理する

wp-config.php で使う主な定数と役割は次のとおりです。

WP_DEBUG: デバッグモード全体のスイッチ。true にするとすべての種類のPHPエラーを報告対象にする
WP_DEBUG_DISPLAY: WP_DEBUG が true のとき、エラーを画面に表示するかどうか。未定義の場合は表示される
WP_DEBUG_LOG: true で wp-content/debug.log に記録。WordPress 5.1以降はファイルのパスを文字列で指定することもできる
SCRIPT_DEBUG: 圧縮前のCSSやJavaScriptを読み込む。表示速度が落ちるため本番では不要
SAVEQUERIES: 実行したSQLをすべてメモリに保存する。負荷が増えるため本番では不要

注意したいのは、WP_DEBUG_DISPLAY と WP_DEBUG_LOG は WP_DEBUG が true のときだけ 意味を持つことです。WP_DEBUG が false なら、この2つを true にしても効きません。

また、WordPress 5.5 で追加された WP_ENVIRONMENT_TYPE にも気を配ってください。wp_get_environment_type() が返すこの値が development で、かつ WP_DEBUG が未定義の場合、WordPressは WP_DEBUG を有効として扱います。ステージングからコピーした wp-config.php に development の指定が残っていないか、本番では production になっているかを確認しておくと安全です。

本番環境での推奨設定

本番の wp-config.php では、デバッグ系をまとめて明示的にオフにします。「未定義なら false になるから書かなくてよい」と考えず、意図をはっきり書いておく方が後から見た人にも分かりやすくなります。

編集前に wp-config.php のバックアップを取ってください。バックアップは公開ディレクトリの外に置きます。wp-config.php.bak のような名前で公開ディレクトリに残すと、PHPとして実行されずテキストとしてダウンロードされ、データベースのパスワードが漏れる危険があります。

// 「編集が必要なのはここまでです」の行より上に書く
define( 'WP_ENVIRONMENT_TYPE', 'production' );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );
define( 'SCRIPT_DEBUG', false );

// サーバーの php.ini で display_errors が有効でも画面に出さない
@ini_set( 'display_errors', '0' );

同じ定数を二重に define すると警告が出るため、ファイル内にすでに WP_DEBUG の行があれば、追加ではなく書き換えてください。

WP_DEBUGをfalseにしてもエラーが表示される理由

「WP_DEBUG を false にしたのに、画面に Warning が出る」という相談はよくあります。原因はPHP本体の設定です。

WordPressは WP_DEBUG が false のとき、報告するエラーの種類（error_reporting）を重大なものに絞りますが、PHPの display_errors 設定には手を付けません。レンタルサーバーやVPSの php.ini で display_errors = On になっていると、Warning などはそのまま画面に出てしまいます。

対処は次のいずれかです。

上の例のように wp-config.php で ini_set( 'display_errors', '0' ) を指定する
サーバーの管理画面や php.ini で display_errors を Off にする（本番ではこちらが本来の姿）

設定を変えたら、phpinfo() を一時的に表示するのではなく、サーバー管理画面の表示や WP-CLI で確認する方が安全です。

現在の設定を確認する方法

WP-CLI が使える環境では、wp-config.php の値をコマンドで確かめられます。

wp config get WP_DEBUG
wp config get WP_DEBUG_DISPLAY
wp config get WP_ENVIRONMENT_TYPE

# 書き換える場合（--raw で文字列ではなく真偽値として書き込む）
wp config set WP_DEBUG false --raw

定義されていない定数を get するとエラーになりますが、それ自体は「未定義」という確認結果です。

管理画面からは「ツール」→「サイトヘルス」でも確認できます。デバッグモードが有効だったり、ログが公開されうる場所にあったりすると、改善項目として表示されます。表示の文言はバージョンで変わることがあります（2026年10月現在）。

あわせて、debug.log が外から読めないかも確かめます。

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-content/debug.log

200 が返る場合はファイルが存在し、公開されています。不要なら中身を確認したうえで削除し、残す必要があるならアクセスを拒否します。

# wp-content/.htaccess（Apache 2.4）
<Files "debug.log">
    Require all denied
</Files>

Nginx では location = /wp-content/debug.log { deny all; } のように設定します。

本番で一時的に調査するときの手順

本番でしか再現しない不具合を調べたいこともあります。その場合は「画面には出さず、公開されない場所にだけ記録する」設定にして、作業が終わったら戻します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
// ドキュメントルートの外にあるフルパスを指定する（例）
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

ログの出力先ディレクトリには、PHPを実行するユーザーが書き込める権限が必要です。不具合を再現してログを確認したら、すぐに推奨設定へ戻し、調査用のログも不要になった時点で削除します。ログにはURLのパラメーターや一部の入力値が含まれることがあるため、長期間残さないようにしてください。

なお、WordPress 5.2 以降には致命的エラーの保護機能があり、本番でPHPの致命的エラーが起きると訪問者には「このサイトで重大なエラーが発生しました」という汎用メッセージが表示され、管理者のメールアドレスにリカバリーモードの案内が届きます。詳細なエラー文を画面に出さなくても、原因の手がかりはこのメールやサーバーのエラーログから得られます。

まとめ

本番で WP_DEBUG を有効にしたままだと、ファイルパスなどの内部情報が見え、画面や REST API の応答が崩れる原因にもなる
本番では WP_DEBUG、WP_DEBUG_DISPLAY、WP_DEBUG_LOG、SCRIPT_DEBUG を明示的に false にし、WP_ENVIRONMENT_TYPE は production にする
WP_DEBUG が false でも php.ini の display_errors が On だとエラーは表示されるため、あわせて無効にする
wp-content/debug.log が外部から読めないかを確認し、ログは公開ディレクトリの外に置く
本番での調査は「表示しない・公開場所に置かない・終わったら戻す」を守る