WordPress をローカル・ステージング・本番の複数環境で動かすなら、wp-config.php は「全環境で共通の部分」と「環境ごとに違う部分」に分け、違う部分は環境別ファイルか環境変数から読み込む形にするのが扱いやすい方法です。あわせて WP_ENVIRONMENT_TYPE で「今どの環境か」を WordPress に教えておくと、テーマやプラグインのコードからも環境を判定できます。この記事では、その設定の組み方と、環境間でデータを移すときの注意点までを順に説明します。
なぜ環境ごとに設定を分けるのか
環境ごとに変わる値は意外と多くあります。
- データベース名・ユーザー・パスワード・ホスト
- サイトのURL（
WP_HOME/WP_SITEURL） - デバッグ表示の有無（
WP_DEBUGなど） - メール送信や外部APIの接続先、APIキー
- キャッシュやCDNの有効・無効
これらを1つの wp-config.php に直書きしたまま環境をまたぐと、「ステージングのDB設定のまま本番に上げてしまった」「本番でデバッグ表示が出たままになった」といった事故が起きます。共通部分と環境固有部分を分けておけば、コードはGitで共有しつつ、環境固有の値だけをサーバーごとに持たせられます。
WP_ENVIRONMENT_TYPE で環境の種類を宣言する
WordPress 5.5 以降には、環境の種類を表す定数 WP_ENVIRONMENT_TYPE と、その値を返す関数 wp_get_environment_type() があります。指定できる値は次の4つです。
local：自分のPC上の開発環境development：共有の開発サーバーstaging：本番前の確認環境production：本番
wp-config.php で次のように定義します。
define( 'WP_ENVIRONMENT_TYPE', 'staging' );定数のほか、サーバーの環境変数 WP_ENVIRONMENT_TYPE でも指定できます。何も指定しない場合や、上の4つ以外の値を入れた場合は production として扱われます。つまり「設定し忘れた環境は本番扱い」になるので、ステージングやローカルでは明示的に指定しておくのが安全です。
テーマやプラグイン側では、関数で判定して処理を切り替えます。
if ( 'production' !== wp_get_environment_type() ) {
// 本番以外では検索エンジンにインデックスさせない
add_filter( 'wp_robots', 'wp_robots_no_robots' );
}wp_robots_no_robots は WordPress 5.7 で入った robots メタタグ用の関数です。ステージングが検索結果に出てしまう事故を防ぐ用途によく使われます。
現在の値はWP-CLIで確認できます。
wp eval 'echo wp_get_environment_type();'環境別ファイルを読み込む構成
もっとも手軽なのは、wp-config.php を共通部分だけにして、環境ごとの値を別ファイルに書く方法です。ファイルがあるときだけ読み込むようにしておけば、本番とローカルで同じ wp-config.php を使い回せます。
<?php
// wp-config.php（共通部分）
// 環境固有の設定ファイルがあれば読み込む
if ( file_exists( __DIR__ . '/wp-config-local.php' ) ) {
require __DIR__ . '/wp-config-local.php';
}
// 環境別ファイルで定義されなかった値の既定値（本番向けの安全側）
defined( 'WP_ENVIRONMENT_TYPE' ) || define( 'WP_ENVIRONMENT_TYPE', 'production' );
defined( 'WP_DEBUG' ) || define( 'WP_DEBUG', false );
$table_prefix = 'wp_';
/* That's all, stop editing! Happy publishing. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}
require_once ABSPATH . 'wp-settings.php';<?php
// wp-config-local.php（この環境だけに置く。Gitには入れない）
define( 'DB_NAME', 'wp_local' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'your-db-password' );
define( 'DB_HOST', 'localhost' );
define( 'WP_ENVIRONMENT_TYPE', 'local' );
define( 'WP_HOME', 'http://example.local' );
define( 'WP_SITEURL', 'http://example.local' );
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );つまずきやすいのは読み込む位置です。環境別ファイルの require は、require_once ABSPATH . 'wp-settings.php'; より前に置きます。wp-settings.php が読み込まれた時点で WordPress の初期化が始まるため、それより後で定数を定義しても反映されません。また、同じ定数を2回 define すると警告が出るので、既定値は defined() || の形で「未定義のときだけ」定義しています。
認証用キーとソルト（AUTH_KEY など）も、環境ごとに別の値を持たせ、環境別ファイル側に書くのがおすすめです。
環境変数（getenv）から読み込む構成
サーバーやコンテナの環境変数を使える環境なら、値を getenv() で読み込む方法もあります。秘密情報がファイルとしてドキュメントルートに残らない点が利点です。
<?php
// wp-config.php
define( 'DB_NAME', getenv( 'WP_DB_NAME' ) ?: 'wordpress' );
define( 'DB_USER', getenv( 'WP_DB_USER' ) ?: 'wordpress' );
define( 'DB_PASSWORD', getenv( 'WP_DB_PASSWORD' ) ?: '' );
define( 'DB_HOST', getenv( 'WP_DB_HOST' ) ?: 'localhost' );
define( 'WP_HOME', getenv( 'WP_HOME' ) ?: 'https://example.com' );
define( 'WP_SITEURL', getenv( 'WP_SITEURL' ) ?: 'https://example.com' );
$wp_debug = getenv( 'WP_DEBUG' );
define( 'WP_DEBUG', 'true' === $wp_debug );getenv() は値が無いと false を返し、値があっても文字列です。WP_DEBUG のような真偽値は 'true' === ... のように文字列で比較してから定数にしないと、'false' という文字列が真として扱われてしまいます。環境変数の渡し方は、Apache の SetEnv、PHP-FPM のプール設定の env[...]、Docker の environment などサーバー構成によって異なります。PHP-FPM では既定で環境変数が引き継がれない設定（clear_env）になっていることがあるので、値が空になるときはそこを確認してください。
なお、Bedrock のようなWordPress用のプロジェクト構成では、.env ファイルと環境別の設定ファイルを組み合わせる仕組みがあらかじめ用意されています。新規にプロジェクトを組むなら、こうした構成を採用するのも選択肢です。
秘密情報をGitに入れない
設定を分ける大きな目的は、DBパスワードやAPIキーをリポジトリに含めないことです。.gitignore に環境別ファイルを加えます。
wp-config-local.php
.env代わりに、値をダミーにした見本ファイル（例：wp-config-local-sample.php）をコミットしておくと、新しいメンバーや新しいサーバーでも何を設定すればよいかが分かります。すでに秘密情報をコミットしてしまった場合は、ファイルを消すだけでは履歴に残るため、パスワードやキーそのものを変更してください。
環境ごとに変えるべき主な設定
WP_HOME/WP_SITEURL：定数で指定すると、DB内の「WordPress アドレス」「サイトアドレス」より優先され、管理画面から変更できなくなります。環境ごとにURLが違う場合に便利です。WP_DEBUG/WP_DEBUG_LOG/WP_DEBUG_DISPLAY：ローカルではログ出力を有効にし、本番ではWP_DEBUGをfalseにします。本番で原因調査のために一時的に有効にする場合も、WP_DEBUG_DISPLAYはfalseにして画面に出さないようにします。DISALLOW_FILE_EDIT：本番では管理画面からのテーマ・プラグイン編集を止めておくと安全です。WP_DEVELOPMENT_MODE：WordPress 6.3 以降で使える定数で、themeなどを指定するとテーマ開発時にキャッシュの影響を受けにくくなります。開発環境だけで設定します。
環境間でデータを移すときの注意
本番のデータをステージングに複製したり、ステージングで作ったデータを本番へ移したりするときは、DB内のURLを置き換える必要があります。WordPress はシリアライズされたデータの中にURLを保存しているため、SQLの単純な置換では文字数情報が壊れることがあります。WP-CLI の wp search-replace はシリアライズを考慮して置換してくれます。
# 作業前にDBをバックアップ
wp db export before-replace.sql
# まず変更件数だけ確認
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid --dry-run
# 問題なければ実行
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid--dry-run で置換対象の件数を確認してから本実行すると、想定外のテーブルまで書き換える失敗を防げます。guid 列は投稿の識別子として使われるため、置換対象から外すのが一般的です。ステージングに本番の会員情報や注文データを複製する場合は、個人情報の扱いや、ステージングから実際のメールが送信されないかにも注意してください。
設定が反映されたかの確認方法
環境を切り替えたら、次の点を確認します。
wp eval 'echo wp_get_environment_type();'で期待した環境名が返るかwp config get WP_HOMEなどで定数の値が読めるか（WP-CLI はWebサーバーとは別のPHPプロセスで動くため、Apache や PHP-FPM にだけ設定した環境変数はWP-CLIからは見えません。CLIでも同じ値を使うなら、シェル側にも環境変数を設定します）- 管理画面の「設定」→「一般」でURL欄がグレーアウトしているか（定数で指定した場合）
- 本番で画面にPHPの警告が表示されていないか
（2026年10月現在）WordPress の最新版でもこの設定方法は変わっていませんが、利用しているホスティングによっては独自の環境変数や設定画面が用意されていることがあります。その場合はホスティングの説明に従って値を渡してください。
まとめ
wp-config.phpは共通部分だけにし、環境固有の値は環境別ファイルか環境変数から読み込むWP_ENVIRONMENT_TYPEをlocal/development/staging/productionで明示し、コード側はwp_get_environment_type()で判定する- 環境別ファイルの読み込みは
wp-settings.phpより前に置く - DBパスワードやAPIキーはGitに入れず、見本ファイルだけを共有する
- 環境間でデータを移すときは
wp db exportでバックアップしてからwp search-replaceを--dry-run付きで試す