2026年5月22日

WordPressのローカル開発環境を構築する方法｜Local・wp-env・Docker Composeの選び方と手順

サーバー・ホスティング

WordPressのローカル開発環境は、GUIで手軽に始めるならLocal、テーマやプラグインの開発ならwp-env、本番に近い構成を再現したいならDocker Composeを選ぶのが基本です。この記事では、それぞれの構築手順と、本番データを取り込むときの置換、本番との差で起きるトラブルの避け方までを解説します。読み終えるころには、自分の目的に合った環境を立ち上げ、本番サイトのコピーを安全に手元で動かせるようになります。

ローカル環境を用意する理由

本番サイトで直接プラグインを更新したり、テーマを編集したりすると、エラーが出た瞬間に訪問者にも影響します。ローカル環境は自分のPCの中だけで動くWordPressなので、壊しても作り直せます。PHPのバージョンを上げたときの互換性確認、大型アップデート前の動作確認、テーマ開発、トラブルの再現といった作業を、本番に触れずに試せるのが最大の利点です。

主な選択肢と選び方

代表的な方法は次の4つです（2026年10月現在）。

Local（WP Engine提供のデスクトップアプリ）: インストーラーを入れて画面の指示に従うだけでサイトが作れます。PHPやWebサーバーの種類をサイトごとに選べ、メール確認ツールやデータベース管理画面も付属します。サーバーの知識がなくても始めやすい方法です。
wp-env（@wordpress/env）: WordPressプロジェクトが提供する開発用ツールです。Node.jsとDockerが必要ですが、設定ファイル1つでプラグイン・テーマを読み込んだ環境を再現でき、チームで同じ環境を共有しやすいのが特徴です。
Docker Compose: 公式のWordPressイメージとデータベースイメージを組み合わせて自分で構成します。Webサーバー、PHP拡張、Redisなど本番の構成に寄せられる自由度があります。
XAMPPなどのパッケージ: Apache・MySQL（MariaDB）・PHPを一括で入れる方式です。昔からある方法ですが、複数サイトでPHPのバージョンを切り替えるのは手間がかかります。

このほか、WordPress.comが提供するデスクトップアプリ「Studio」のように、Dockerなしで軽量にサイトを立ち上げられるツールもあります。

迷ったら、「サイトの中身を確認したい・運用担当者」はLocal、「プラグインやブロックを開発する」はwp-env、「本番サーバーの構成ごと検証したい」はDocker Compose、と考えると選びやすくなります。

方法1: Localで始める

Localは公式サイトからインストーラーを入手して導入します。起動後、新規サイトの作成を選び、サイト名を入力します。環境の選択では、おすすめ設定（Preferred）か、PHP・Webサーバー・データベースのバージョンを個別に選ぶ設定（Custom）を選べます。最後に管理者のユーザー名・パスワード・メールアドレスを決めれば、数分でサイトが起動します。

ここで意識したいのは、PHPのバージョンを本番サーバーに合わせることです。おすすめ設定のまま作ると本番より新しいPHPになることがあり、ローカルでは動いたのに本番でエラー、という食い違いの原因になります。本番のPHPバージョンは、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。

サイトのファイルは、Localが作るフォルダの中の app/public に置かれます。テーマやプラグインを編集する場合は、ここをエディターで開きます。

方法2: wp-envで開発用環境を作る

wp-envは、プラグインやテーマのリポジトリに設定ファイルを置き、コマンド1つで環境を起動する使い方が基本です。事前にDocker（Docker Desktopなど）とNode.jsを入れておきます。

プロジェクトのフォルダに .wp-env.json を作り、使うPHPのバージョンや読み込むプラグインを書きます。

{
  "core": null,
  "phpVersion": "8.2",
  "plugins": [ "." ],
  "themes": [],
  "config": {
    "WP_DEBUG": true,
    "WP_DEBUG_LOG": true
  }
}

"core": null は最新の安定版WordPressを使う指定、"plugins": [ "." ] はこのフォルダ自体をプラグインとして読み込む指定です。起動と停止は次のコマンドで行います。

npx @wordpress/env start    # 起動（初回はイメージの取得に時間がかかる）
npx @wordpress/env stop     # 停止
npx @wordpress/env run cli wp plugin list   # コンテナ内でWP-CLIを実行

既定では http://localhost:8888 で開発用サイトが開きます。ポートが他のアプリと重なっていると起動に失敗するため、その場合は設定ファイルの port で変更します。初期の管理者アカウントなど細かな既定値は、公式のドキュメントで確認してください。

方法3: Docker Composeで本番に近い構成を作る

Docker Composeでは、WordPressとデータベースを別々のコンテナとして定義します。次は最小構成の compose.yaml です。パスワードはローカル専用のダミー値にし、本番と同じものは使わないでください。

services:
  db:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp
      MYSQL_PASSWORD: local-dev-password
      MYSQL_ROOT_PASSWORD: local-root-password
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:php8.2-apache
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: local-dev-password
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DEBUG: 1
    volumes:
      - ./wp-content:/var/www/html/wp-content

volumes:
  db_data:

docker compose up -d で起動し、http://localhost:8080 を開くとインストール画面が表示されます。wp-content だけを手元のフォルダと共有しているので、テーマやプラグインはPC側のエディターで編集でき、WordPress本体はイメージ側で管理されます。データベースは名前付きボリュームに保存されるため、コンテナを作り直してもデータは残ります。

つまずきやすい点が2つあります。1つは起動直後の接続エラーです。データベースの初期化が終わる前にWordPressが接続しようとして「データベース接続確立エラー」になることがありますが、少し待って再読み込みすれば解消します。もう1つはWindowsやmacOSでのファイル共有の遅さです。Windowsでは、プロジェクトをWSL2側のファイルシステム（Linux側のホームディレクトリなど）に置くと、管理画面の表示が大きく速くなります。

本番サイトのデータをローカルに取り込む

新規サイトではなく本番のコピーで検証したい場合は、データベースと wp-content を持ってきます。作業は本番側の読み取りだけで済みますが、念のため本番のバックアップを取ってから始めてください。

# 本番側: データベースを書き出す
wp db export production.sql

# ローカル側: 取り込み、URLを置き換える（まず --dry-run で件数を確認）
wp db import production.sql
wp search-replace 'https://example.com' 'http://localhost:8080' --all-tables --dry-run
wp search-replace 'https://example.com' 'http://localhost:8080' --all-tables

URLの置き換えに、テキストエディターやSQLの REPLACE を使うのは避けてください。WordPressのオプションやウィジェット設定にはPHPのシリアライズ形式で保存された値があり、文字数が変わると壊れてしまいます。wp search-replace はシリアライズされた値も正しく書き換えます。Localには、書き出したファイルを読み込んでサイトを作る機能もあります。

本番との違いで起きるトラブルを防ぐ

ローカル環境で見落としやすいのは、「本番と同じ動きをしてほしくない部分」です。

メール送信: 本番の会員データを取り込んだ環境でメールが実際に送られると、利用者に誤送信してしまいます。Localの付属ツールや、Mailpitのようなメールを外に出さずに受け止めるツールを使います。
環境の種類: wp-config.php に define( 'WP_ENVIRONMENT_TYPE', 'local' ); を書いておくと、wp_get_environment_type() で環境を判別できます。プラグインの中にはこの値を見て、本番以外では外部連携を止めるなど挙動を変えるものがあり、自作のコードでも「ローカルでは送信処理をしない」といった分岐に使えます。
外部連携: 決済、メール配信、バックアップ先のクラウドストレージなどのAPIキーが本番のままだと、ローカルから本番の外部サービスを操作してしまいます。取り込み後にテスト用の値へ差し替えるか、該当プラグインを無効化します。
デバッグ表示: WP_DEBUG を有効にしてエラーを出すのはローカルだけにし、同じ設定を本番に持ち込まないよう注意します。

まとめ

手軽さならLocal、プラグイン・テーマ開発ならwp-env、本番構成の再現ならDocker Composeが選びやすい
PHPのバージョンは本番に合わせ、サイトヘルスの「情報」で確認する
Docker ComposeではWindowsならWSL2側にファイルを置くと速い
本番データの取り込み後のURL置換は wp search-replace を使い、先に --dry-run で確認する
メール送信・外部APIキー・デバッグ表示など、本番と同じ動きをしてほしくない部分を取り込み直後に止める