WordPress安心診断 by MozCheck

WordPressのwp-config.php設定完全マニュアル｜セキュリティ強化とトラブルシューティング

Written by

Yudai Tsuyuzaki

in

,

WordPressを運用・カスタマイズする上で、最も重要かつ強力な設定ファイルが「wp-config.php」です。

データベース接続情報はもちろんのこと、エラー発生時のデバッグモード有効化、メモリ上限の引き上げ、さらにはサイト改ざんや不正アクセスを防ぐ強固なセキュリティ設定まで、wp-config.phpを正しく設定することでサイトの安定性と安全性を飛躍的に高めることができます。

しかし、wp-config.phpはWordPressの心臓部であるがゆえに、たった1行の記述ミスや文字コードの誤りだけでサイト全体が真っ白（WSOD）になったり、管理画面にアクセスできなくなる重大なリスクも孕んでいます。

本記事では、WordPressの基本設定からトラブルシューティング時に役立つ定数、セキュリティを劇的に強化する実践的なカスタマイズまで、具体的なコード例と安全な編集手順を網羅して分かりやすく解説します。

目次

wp-config.phpとは？役割と編集前の重要注意事項

WordPressの心臓部としての役割

wp-config.php（ダブリューピー・コンフィグ・ピーエイチピー）は、WordPressが動作するために必要な基本環境や各種定数を定義する最重要ファイルです。WordPressがインストールされているサーバーのルートディレクトリ（通常は public_html や htdocs 直下）に配置されます。

WordPressコアファイル（wp-settings.php 等）が読み込まれる前に実行され、以下のような重要な役割を担っています。

  • データベース接続の確立（ホスト名、ユーザー名、パスワード、DB名）
  • 認証用ユニークキーとソルトによるCookie・セッションの暗号化
  • テーブル接頭辞の定義（セキュリティ対策）
  • デバッグモードやログ出力の制御
  • ファイル編集やプラグイン更新の制限などのセキュリティポリシー適用
  • メモリ上限やリビジョン保持数などのシステムパフォーマンス制御

編集前に絶対に守るべき4つの鉄則

wp-config.phpはPHPコードで構成されているため、構文エラー（Syntax Error）や不正な文字コードが含まれると、WordPressは一切起動できなくなります。編集を行う際は、必ず以下の4つの鉄則を厳守してください。

1. 必ず事前にファイルのバックアップを取得する

編集作業を始める直前に、FTPソフト（FileZilla等）やレンタルサーバーのファイルマネージャーを使用して、現在の wp-config.php を手元にダウンロードして別名で保存（例: wp-config.php.backup）してください。万が一エラーが発生しても、バックアップファイルを上書きアップロードするだけで即座に復旧できます。

2. 文字コードは「UTF-8（BOMなし / UTF-8N）」、改行コードは「LF」を使用する

Windowsの「メモ帳（Notepad）」などで編集・保存すると、ファイルの先頭に不可視の「BOM（Byte Order Mark）」が付加されてしまい、「Headers already sent」エラーや画面真っ白（WSOD）を引き起こす原因になります。必ず「VS Code」「Cursor」「秀丸エディタ」「サクラエディタ」などの高機能エディタを使用し、文字コードを UTF-8 (BOMなし) に指定して保存してください。

3. 追記位置を厳守する（「That’s all, stop editing!」より前）

wp-config.phpの末尾付近には、以下のようなコメント行が記載されています。

/* That's all, stop editing! Happy publishing. */
/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}

/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

定数（define(...)）の追加やカスタマイズは、必ず /* That's all, stop editing! Happy publishing. */ よりも上の行に記述してください。このコメント以降に定数を記述しても、すでに wp-settings.php がロードされた後であるため、設定値が正しく反映されません。

4. ファイル末尾にPHP終了タグ「?>」を書かない

PHPのみで書かれたファイルでは、末尾の ?> を省略することが公式のコーディング規約（PSR-12）で推奨されています。?> の後に誤ってスペースや改行が入ってしまうと、HTTPヘッダー送信エラーの原因となるため、末尾の終了タグは記述しないようにしましょう。

基本設定項目（データベース接続情報・ユニークキーとソルト）

データベース接続情報（DB設定）

WordPressがMySQL/MariaDBと通信するための最も基本的な設定です。通常、WordPressインストール時に自動生成されます。

// ** データベース接続情報 ** //
/** WordPress のためのデータベース名 */
define( 'DB_NAME', 'database_name_here' );

/** MySQL データベースのユーザー名 */
define( 'DB_USER', 'username_here' );

/** MySQL データベースのパスワード */
define( 'DB_PASSWORD', 'password_here' );

/** MySQL のホスト名 */
define( 'DB_HOST', 'localhost' );

/** データベースのテーブルを作成する際のデータベースの文字セット */
define( 'DB_CHARSET', 'utf8mb4' );

/** データベースの照合順序 (ほとんどの場合は空欄のまま) */
define( 'DB_COLLATE', '' );

「データベース接続確立エラー」が発生した場合のチェックポイント

サイトに「データベース接続確立エラー（Error establishing a database connection）」と表示された場合、9割以上はこのDB設定に原因があります。

  • DB_NAME, DB_USER, DB_PASSWORD に不要なスペースやタイプミスがないか
  • DB_HOST がサーバー会社指定の値になっているか（レンタルサーバーによっては localhost ではなく mysql123.example.ne.jp やソケット指定が必要な場合があります）
  • データベースユーザーに対象データベースへの「全権限（ALL PRIVILEGES）」が付与されているか

テーブル接頭辞（$table_prefix）の変更

WordPressのデータベーステーブルは、初期状態では wp_ という接頭辞（プレフィックス）が付きます（例: wp_posts, wp_users）。

$table_prefix = 'wp_';

SQLインジェクション攻撃などを仕掛ける攻撃者は、テーブル名が wp_ で始まっていることを前提に攻撃コードを組み立てます。そのため、新規インストール時に wp_ 以外のランダムな文字列（例: mp_9x4b_ など）に変更しておくことで、自動化された攻撃の標的から外れるセキュリティ効果があります。

※運用中のサイトで変更する場合の注意
すでに記事やデータが存在する運用中のサイトで $table_prefix を書き換えるだけではサイトが動作しなくなります。phpMyAdmin等で実際のDBテーブル名をすべてリネームし、wp_options や wp_usermeta 内のキー名も一括置換する必要があるため、必ず専門の手順に沿って慎重に実施してください。

認証用ユニークキーとソルト（AUTH_KEY等）の役割と再生成

ユーザーのパスワードやログインCookieを暗号化・ハッシュ化するための乱数キー群です。

define( 'AUTH_KEY',         'put your unique phrase here' );
define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );
define( 'LOGGED_IN_KEY',    'put your unique phrase here' );
define( 'NONCE_KEY',        'put your unique phrase here' );
define( 'AUTH_SALT',        'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT',   'put your unique phrase here' );
define( 'NONCE_SALT',       'put your unique phrase here' );

以下のようなタイミングでソルトの再生成・更新を強く推奨します。

  • サイトが不正アクセスや乗っ取りの被害に遭った疑いがあるとき
  • 管理者のパスワード漏洩が疑われるとき
  • 定期的なセキュリティメンテナンス時

WordPress.org公式の「オンライン秘密鍵ジェネレーター（https://api.wordpress.org/secret-key/1.1/salt/）」にアクセスすると、強固なランダム文字列が即座に生成されます。生成された8行のコードをコピーして既存のキーと置き換えるだけで、現在ログインしているすべてのユーザーのセッションが即座に強制ログアウト（失効）され、不正なCookieセッションを完全に無効化できます。

トラブルシューティングに役立つ定数設定

サイトに予期せぬエラーが発生した場合や、プラグイン導入後に画面が真っ白になった場合、wp-config.phpを活用して原因を迅速に特定・復旧できます。

WP_DEBUG / WP_DEBUG_LOG / WP_DEBUG_DISPLAY（デバッグログ出力）

WordPressの標準では、致命的なエラーが発生しても画面上に詳細なエラー文を出さないよう設計されています。原因を特定するにはデバッグモードを有効化します。

本番サイトでエラー内容を画面上に直接表示してしまうと、サーバーの内部パスやDB構造が第三者に漏洩し、セキュリティ上の脆弱性となります。そのため、画面にはエラーを表示せず、サーバー内のログファイルにのみ出力する設定が鉄則です。

// デバッグモードを有効化
define( 'WP_DEBUG', true );

// エラー内容を /wp-content/debug.log に記録
define( 'WP_DEBUG_LOG', true );

// 画面上にはエラーメッセージを表示させない（非表示）
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// スクリプトのデバッグ（未圧縮のJS/CSSを使用）
define( 'SCRIPT_DEBUG', false );

上記を設定後、不具合の起きているページにアクセスすると、/wp-content/debug.log ファイルが自動生成され、エラーの原因となっているプラグイン名、テーマ名、ファイルパス、行番号が詳細に記録されます。

※注意
原因調査とトラブルシューティングが完了したら、WP_DEBUG および WP_DEBUG_LOG は必ず false に戻してください。ログファイルの肥大化や不要なリソース消費を防ぐためです。

WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT（PHPメモリ上限引き上げ）

多機能ページビルダーや、ECプラグインなどを使用していると、以下のようなメモリ不足エラーが発生することがあります。

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate ...)

WordPressがPHPスクリプト実行時に使用できるメモリ上限は、wp-config.phpで引き上げることが可能です。

// フロントエンドおよび通常の処理におけるメモリ上限（例: 256MB）
define( 'WP_MEMORY_LIMIT', '256M' );

// 管理画面・バックエンド処理におけるメモリ上限（例: 512MB）
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

※サーバー自体の php.ini で設定されている物理メモリ上限（memory_limit）を超える値は指定できません。サーバーの仕様に合わせて適切な値を設定してください。

WP_ALLOW_REPAIR（データベース自動修復モード）

データベースのテーブルが破損し、「データベーステーブルの修復が必要です」というエラーが出た場合、WordPressの内蔵修復機能を有効化できます。

define( 'WP_ALLOW_REPAIR', true );

データベース修復の手順:

  • 上記コードを wp-config.php に追加して保存
  • ブラウザで https://あなたのサイトURL/wp-admin/maint/repair.php にアクセス
  • 「データベースの修復」または「データベースの修復と最適化」ボタンをクリックして実行
  • 【超重要】修復が完了したら、直ちに wp-config.php からこの行を削除またはコメントアウトする

※警告
WP_ALLOW_REPAIR が有効になっている間は、ログイン権限のない第三者でも repair.php にアクセスしてDB修復・最適化を実行できてしまいます。作業後は必ず削除してください。

サイトのセキュリティを劇的に高めるwp-config.phpのカスタマイズ

WordPressサイトのセキュリティを強化する上で、管理画面の権限制限や直接アクセス防御をwp-config.phpに記述することは非常に効果的です。

DISALLOW_FILE_EDIT（管理画面からのファイル編集禁止）

WordPressの管理画面には、標準で「外観 > テーマファイルエディター」および「プラグイン > プラグインファイルエディター」が用意されています。

万が一、管理者のログインパスワードが突破されたりセッションが乗っ取られた場合、攻撃者はこのファイルエディターからPHPファイルを改ざんし、バックドア（悪意ある不正プログラム）を仕掛けます。

// 管理画面からのテーマ・プラグインのファイル編集を完全禁止
define( 'DISALLOW_FILE_EDIT', true );

この定数を有効にすると、管理画面からファイルエディター機能自体が非表示になり、万が一の不正ログイン時にも直接のコード書き換えを防ぐことができます。すべての本番サイトで設定を強く推奨します。

DISALLOW_FILE_MODS（プラグイン・テーマの追加/更新禁止）

より厳格な運用環境やエンタープライズサイト向けの設定です。ファイルの編集だけでなく、管理画面からのプラグイン・テーマの新規インストールやアップデート、WordPressコアの更新操作をすべて無効化します。

// プラグイン・テーマの追加・更新・編集をすべて禁止
define( 'DISALLOW_FILE_MODS', true );

Gitによるバージョン管理やCI/CDデプロイを採用している開発現場において、管理者が意図せず本番環境で直接プラグインを更新してレイアウト崩れを起こす事故を防止できます。

FORCE_SSL_ADMIN（管理画面の常時SSL強制）

管理画面へのアクセスおよびログイン処理をすべてHTTPS（SSL通信）に強制します。

// 管理画面とログインのSSL通信を強制
define( 'FORCE_SSL_ADMIN', true );

ログイン時のID・パスワード送信やCookieセッションの平文盗聴（中間者攻撃）を防止し、セキュアな通信を担保します。

wp-config.php 自体のアクセス拒否設定と保護対策

wp-config.phpにはDB接続パスワードやソルトなどの極秘情報が記載されています。ファイル自体のアクセス保護も万全にしておきましょう。

1. wp-config.php を1階層上に退避させる（WordPress公式仕様）

WordPressには、ルートディレクトリに wp-config.php が存在しない場合、自動的に1つ上の階層（親ディレクトリ）を探しにいく仕様が組み込まれています。

  • 通常配置: /home/user/public_html/wp-config.php
  • 退避配置: /home/user/wp-config.php（Web公開領域の外側）

Webサーバーの公開領域（ドキュメントルート）の外に配置することで、Webサーバーの設定不備や誤動作があっても、外部からブラウザ経由で直接閲覧されるリスクを物理的にゼロにできます。※親ディレクトリに別のWordPressがインストールされていない単一サイト構成の場合に有効です。

2. .htaccess によるアクセス拒否（Apache環境）

ルートディレクトリの .htaccess に以下の記述を追加し、外部からのWebアクセスを遮断します。

# wp-config.php への直接アクセスを完全拒否
<files wp-config.php>
order allow,deny
deny from all
</files>

3. Nginx 設定によるアクセス遮断（Nginx環境）

Nginxを使用している場合は、サーバー設定ファイル（nginx.conf 等）に以下を記述します。

location = /wp-config.php {
    deny all;
    access_log off;
    log_not_found off;
}

4. 推奨パーミッションの設定

ファイルのパーミッションは、Webサーバーの実行権限に応じて最も厳しい設定を適用します。

  • 通常の推奨値: 400（所有者のみ読み取り可）または 440
  • サーバー仕様により書き込みが必要な場合: 600 または 640

サイトURLの強制指定（WP_HOME / WP_SITEURL）とSSL化移行時の使い方

WP_HOME と WP_SITEURL の違いと定義方法

WordPressのサイトURLはデータベース（wp_options テーブル）に保存されていますが、wp-config.php に定数を定義することで、DBの設定値を上書きして強制指定できます。

// サイトのアドレス（トップページの表示URL）
define( 'WP_HOME', 'https://example.com' );

// WordPress のアドレス（WordPressコアファイルが置かれているURL）
define( 'WP_SITEURL', 'https://example.com' );

※サブディレクトリ /wp にWordPressコアを配置している場合は、WP_SITEURL を https://example.com/wp に設定します。末尾にスラッシュ（/）を付けないように注意してください。

URL誤変更による管理画面アクセス不能からの緊急復旧

WordPress管理画面の「設定 > 一般」でサイトアドレスを誤って書き換えてしまい、管理画面にもサイトにもアクセスできなくなるトラブルは非常に多く発生します。

この場合、wp-config.php をFTPで開き、上記のように正しいURLを WP_HOME / WP_SITEURL として追記して保存するだけで、DBを直接編集することなく即座にアクセスを復旧させることができます。

運用効率・パフォーマンスを向上させるおすすめ定数一覧

WordPressの長期運用において、データベースの肥大化を防ぎ軽快な動作を保つための実用的な定数です。

定数名推奨設定値効果・解説
WP_POST_REVISIONS5 または 10記事の下書き保存ごとに無制限に増え続けるリビジョン保持数を制限し、DBの肥大化を防止
EMPTY_TRASH_DAYS7 または 14ゴミ箱に入った記事やコメントを自動的に完全削除するまでの日数（初期値は30日）
AUTOSAVE_INTERVAL120 または 180記事執筆時の自動保存間隔を秒単位で指定（初期値60秒から広げることでサーバー負荷軽減）
CORE_UPGRADE_SKIP_NEW_BUNDLEDtrueコアアップデート時にデフォルトテーマが自動追加されるのを抑止
// リビジョン数を直近5件に制限（無制限保存によるDB肥大化を防止）
define( 'WP_POST_REVISIONS', 5 );

// ゴミ箱の自動完全消去を7日間に短縮
define( 'EMPTY_TRASH_DAYS', 7 );

// 記事編集画面の自動保存間隔を120秒に延長
define( 'AUTOSAVE_INTERVAL', 120 );

コピペで使える！おすすめのwp-config.php設定スニペットまとめ

セキュリティと保守性を両立した本番環境向けのおすすめ設定ブロックをまとめました。wp-config.php の /* That's all, stop editing! Happy publishing. */ より直前の行に追記してご活用ください。

/* --------------------------------------------------
 * 本番サイト向け セキュリティ・運用最適化設定
 * -------------------------------------------------- */

// 1. 管理画面からのテーマ・プラグインファイル編集を禁止
define( 'DISALLOW_FILE_EDIT', true );

// 2. 管理画面の常時SSL化を強制
define( 'FORCE_SSL_ADMIN', true );

// 3. 安全なデバッグログ設定（画面には出さず /wp-content/debug.log に記録）
define( 'WP_DEBUG', false ); // 調査時のみ true に変更
define( 'WP_DEBUG_LOG', false ); // 調査時のみ true に変更
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// 4. メモリ上限設定
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

// 5. データベース肥大化防止（リビジョン保持数を5件に制限）
define( 'WP_POST_REVISIONS', 5 );

// 6. ゴミ箱の自動削除間隔（7日間）
define( 'EMPTY_TRASH_DAYS', 7 );

まとめ：wp-config.phpを正しく設定して安全で快適なWordPress運用を

wp-config.phpは、WordPressサイトのパフォーマンスやセキュリティを根本からコントロールできる非常にパワフルな設定ファイルです。

本記事の重要ポイント:

  • 編集前のバックアップ取得と、UTF-8（BOMなし）での保存を徹底する
  • 追記は必ず /* That's all, stop editing! Happy publishing. */ より前に行う
  • 本番環境では DISALLOW_FILE_EDIT と FORCE_SSL_ADMIN を設定して不正アクセス時の被害を最小化する
  • エラー調査時は WP_DEBUG_DISPLAY: false かつ WP_DEBUG_LOG: true で安全にログを収集し、解決後は必ずオフにする

設定ファイルを適切に最適化し、安全で高速なWordPressサイト運用を実現しましょう。

サイトの脆弱性診断やセキュリティ設定に不安がある方は、MozCheckのセキュリティ診断ツールや監視サポートの活用もぜひご検討ください。

関連記事

  1. WordPress改ざん復旧完全マニュアル｜原因特定からバックドア根絶・安全なデータ復元手順まで
  2. WordPressで勝手にリダイレクトされる原因と対策｜リダイレクトハッキングの特定・完全駆除マニュアル
  3. WordPress乗っ取り被害からの緊急復旧マニュアル｜管理者権限の奪還・バックドア駆除・再発防止策
  4. WordPressの403 Forbiddenエラー原因と直し方完全ガイド｜管理画面・記事保存時のWAF解除から.htaccess・パーミッション復旧まで

投稿者

Yudai Tsuyuzaki

フリーランスのWeb系プログラマー。 長野県の北アルプス地方在住

🧰 WordPress無料診断

サイト改善の第一歩をお届け

当サイト「MozCheck」は、WordPressサイトの不安をチェックできる無料診断サービスです。
URLを入力するだけ。登録不要、すぐに診断結果が表示されます。

無料で診断する

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

More posts