2026年8月11日

WordPressのwp-config.phpに定数を追加する方法と主な定数一覧

カスタマイズ

wp-config.php に定数を追加するときは、define( '定数名', 値 ); の形で、ファイル後半にある「編集が必要なのはここまでです」（英語版では「That's all, stop editing!」）というコメント行より上に書きます。この記事では、追加する位置と書き方の決まり、よく使う定数の意味と設定例、白い画面になったときの戻し方までをまとめ、作業後に設定が効いているか確認できるところまで解説します。

作業前に：バックアップと編集方法の確認

wp-config.php はデータベースの接続情報を含む、サイトの起動に欠かせないファイルです。1文字の書き間違いでサイト全体が表示されなくなるため、編集前に次の準備をしてください。

現在の wp-config.php をパソコンにダウンロードし、別名で保存しておく
FTP/SFTPクライアントかレンタルサーバーのファイルマネージャーで、ファイルを直接上書きできる状態にしておく
可能ならステージング環境で先に試す

ファイルはWordPressをインストールしたディレクトリ（wp-admin や wp-content と同じ階層）にあります。セキュリティ対策で一つ上の階層に移しているサーバーもあります。

編集には、文字コードをUTF-8（BOMなし）で保存できるテキストエディターを使います。Windowsのメモ帳や表計算ソフト由来のツールでBOM付きになると、「headers already sent」の警告やログイン不能の原因になります。

定数を書く位置と書き方の決まり

wp-config.php の後半は、おおむね次の構成になっています（コメントの文言はバージョンや言語で多少異なります）。

<?php
// ……データベース設定、認証用キー、テーブル接頭辞、WP_DEBUG など……

/* ここに独自の定数を追加する */
define( 'WP_POST_REVISIONS', 10 );
define( 'DISALLOW_FILE_EDIT', true );

/* 編集が必要なのはここまでです ! WordPress でのパブリッシングをお楽しみください。 */

if ( ! defined( 'ABSPATH' ) ) {
	define( 'ABSPATH', __DIR__ . '/' );
}

require_once ABSPATH . 'wp-settings.php';

定数は require_once ABSPATH . 'wp-settings.php'; より前に定義されている必要があります。wp-settings.php の中でWordPress本体が読み込まれ、その時点の定数を見て動作が決まるためです。コメント行より下、特に wp-settings.php の読み込み後に書くと、設定が効かないか、すでに定義済みという警告が出ます。

書き方で間違えやすいのは次の点です。

真偽値は引用符で囲まない：true / false と書きます。'false' と引用符で囲むと「false という文字列」になり、PHPでは真として扱われます。WP_DEBUG を止めたつもりで有効のまま、という事故の典型です。
数値も引用符なし、サイズ指定は引用符あり：WP_POST_REVISIONS は 10、メモリ指定は '256M' のように書きます。
行末のセミコロンを忘れない：抜けると構文エラーで画面が真っ白になります。
全角の引用符や空白を混ぜない：Webページからコピーしたコードに全角の ’ やスペースが紛れていると、見た目は正しくてもエラーになります。
同じ定数を二重に定義しない：WP_DEBUG のように最初から書かれている定数は、新しい行を足さず既存の行の値を書き換えます。

よく使う定数と設定例

ここからは、実際によく追加される定数を目的別に紹介します。既定値はWordPress本体の挙動で、レンタルサーバーやプラグインが別の値を設定している場合もあります（2026年10月現在）。

デバッグ関連

不具合の原因を調べるときに使います。本番サイトでは画面にエラーを出さず、ログだけ残す組み合わせが安全です。

define( 'WP_DEBUG', true );          // デバッグモードを有効にする
define( 'WP_DEBUG_LOG', true );      // wp-content/debug.log に記録する
define( 'WP_DEBUG_DISPLAY', false ); // 画面には表示しない
@ini_set( 'display_errors', '0' );

WP_DEBUG_LOG に true を指定すると wp-content/debug.log に書き出されますが、このファイルはURLを知っていればブラウザから開けてしまう場合があります。調査が終わったら WP_DEBUG を false に戻し、ログファイルを削除してください。WP_DEBUG_LOG には、公開ディレクトリの外にあるファイルのパスを文字列で指定することもできます。

メモリ関連

define( 'WP_MEMORY_LIMIT', '256M' );     // サイト表示時のメモリ上限
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // 管理画面の重い処理用の上限

WP_MEMORY_LIMIT の既定値は単一サイトで40M、マルチサイトで64Mです。PHP側の設定がこれより大きければ、通常はそちらが優先されます。ここで大きな値を書いても、サーバー側で上限が決められている場合はそれ以上には増えません。メモリ不足のエラーが続くなら、サーバーのPHP設定も確認します。

投稿の保存・ゴミ箱関連

define( 'WP_POST_REVISIONS', 10 );   // リビジョンを投稿ごとに最大10件まで残す
define( 'AUTOSAVE_INTERVAL', 120 );  // 自動保存の間隔（秒）。既定は60
define( 'EMPTY_TRASH_DAYS', 30 );    // ゴミ箱を自動で空にするまでの日数

WP_POST_REVISIONS は false にするとリビジョンを保存しなくなります。データベースの肥大化を防げますが、誤って上書きしたときに戻せなくなるので、件数で制限する方が無難です。すでに溜まっているリビジョンは、この設定を追加しても消えません。

EMPTY_TRASH_DAYS を 0 にするとゴミ箱が無効になり、削除操作がゴミ箱を経由せずにそのまま実行されます。誤削除から戻せなくなるため、意図がなければ0にしないでください。

セキュリティと更新関連

define( 'DISALLOW_FILE_EDIT', true );    // 管理画面のテーマ・プラグインファイルエディターを無効化
define( 'FORCE_SSL_ADMIN', true );       // ログインと管理画面をHTTPSに限定
define( 'WP_AUTO_UPDATE_CORE', 'minor' ); // コアの自動更新はマイナー（保守・セキュリティ）のみ

DISALLOW_FILE_EDIT は、管理者アカウントが乗っ取られた場合にPHPファイルを書き換えられるリスクを減らす設定で、多くのサイトで有効にして損のないものです。より強い DISALLOW_FILE_MODS を true にすると、プラグインやテーマの追加・更新、コアの更新も管理画面からできなくなります。更新をデプロイ作業で管理している環境向けで、通常の運用では更新が止まってしまう点に注意が必要です。

FORCE_SSL_ADMIN は、SSL証明書を設定してHTTPSで表示できる状態にしてから追加します。ロードバランサーやCDNの背後にあるサーバーでは、HTTPSの判定がうまくいかずリダイレクトが繰り返されることがあり、その場合はサーバー会社の案内に沿った追加設定が必要です。

WP_AUTO_UPDATE_CORE は true（メジャー更新も含めて自動更新）、false（無効）、'minor'（マイナー更新のみ）を指定できます。

環境・cron・URL関連

define( 'WP_ENVIRONMENT_TYPE', 'staging' ); // local / development / staging / production
define( 'DISABLE_WP_CRON', true );          // アクセス時の疑似cronを止める
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

WP_ENVIRONMENT_TYPE を設定すると、wp_get_environment_type() でテーマやプラグインが環境を判別できるようになります。ステージングでメール送信を止める、といった切り替えに使えます。

DISABLE_WP_CRON を true にした場合、予約投稿や定期処理はサーバー側のcronから動かす必要があります。WP-CLIが使えるなら wp cron event run --due-now を数分おきに実行するのが一般的です。代わりのcronを設定しないまま止めると、予約投稿が公開されなくなります。

WP_HOME と WP_SITEURL はデータベースに保存されたサイトURLより優先され、「設定」→「一般」の該当欄が変更できなくなります。ドメイン移転の作業中や、管理画面からURLを書き換えてログインできなくなったときの復旧に使えます。末尾にスラッシュは付けません。

設定が効いているか確認する

追加後は、まずサイトのトップページと管理画面が表示されるかを確かめます。そのうえで、管理画面の「ツール」→「サイトヘルス」→「情報」タブを開くと、WordPress関連の定数の現在値を一覧で確認できます。WP_DEBUG や WP_MEMORY_LIMIT が意図した値になっているかをここで見てください。

SSHでサーバーに入れる場合は、WP-CLIで値の確認や追加ができます。

wp config get WP_POST_REVISIONS
wp config set WP_POST_REVISIONS 10 --raw
wp config list

--raw は値を引用符で囲まずに書き込む指定で、数値や true / false を設定するときに使います。WP-CLIは既定で英語版の「That's all, stop editing!」の行を目印に、その上へ書き込みます。日本語版のコメントに書き換わっているファイルでは目印が見つからず意図しない位置に入ることがあるため、実行後にファイルを開いて位置を確認してください。

白い画面になったときと、ファイルの権限

保存後に画面が真っ白になったり「重大なエラー」と表示されたりした場合は、ほぼ構文エラーか値の誤りです。慌てずに、事前に保存しておいた wp-config.php をFTPやファイルマネージャーで上書きすれば元に戻ります。原因を調べたい場合は、サーバーのPHPエラーログに、エラーの行番号が記録されていることが多いです。

wp-config.php のパーミッションは、ほかのユーザーから読めない設定（400、440、600、640など）が推奨されることが多いですが、適切な値はサーバーの構成によって変わります。厳しくしすぎてWordPress自体が読めなくなることもあるため、レンタルサーバーの推奨値に合わせてください。

なお、wp-config.php の中にある認証用キーとソルト（AUTH_KEY など）は、人に見せたりブログやチャットに貼り付けたりしてはいけない値です。質問のためにファイルの中身を共有するときは、データベースのパスワードと一緒に伏せ字にしてください。漏れた可能性がある場合は新しい値に置き換えると、ログイン中のユーザーはいったんすべてログアウトされます。

まとめ

定数は define( '定数名', 値 ); の形で、「編集が必要なのはここまでです」の行より上、wp-settings.php の読み込みより前に書きます。
真偽値と数値は引用符なし、サイズ指定は引用符ありで書き、既存の定数は二重定義せず値を書き換えます。
よく使うのはデバッグ（WP_DEBUG 系）、メモリ（WP_MEMORY_LIMIT）、リビジョン（WP_POST_REVISIONS）、セキュリティ（DISALLOW_FILE_EDIT、FORCE_SSL_ADMIN）、cron（DISABLE_WP_CRON）などです。
EMPTY_TRASH_DAYS の0、DISALLOW_FILE_MODS、代替cronなしの DISABLE_WP_CRON は副作用が大きいので、意味を理解してから使います。
編集前のバックアップと、サイトヘルスやWP-CLIでの確認をセットで行うと、白い画面になっても落ち着いて戻せます。