Hara Daizo WordPressを手元のパソコンだけで動かせるローカル環境があれば、公開サイトへ影響を与えずにテーマ変更や更新テストを行えます。初めて作るなら画面操作で完結しやすいLocal、公式の開発ツールを使いたいならWordPress Studio、サーバー構成を細かく学ぶならXAMPPやDockerが候補です。
この記事ではLocalの手順を中心に、4つの方法の違い、本番サイトの複製、共有、エラーの切り分けまで説明します。テーマ開発を始める準備として使う場合は「テーマ自作の入門」もあわせて確認してください。
WordPressのローカル環境とは
ローカル環境は、自分のパソコン上にWebサーバー、PHP、データベース、WordPressを用意し、ブラウザから閲覧できるようにしたものです。通常はインターネットへ一般公開されず、パソコンを止めればサイトも停止します。
本番環境は訪問者が利用する公開サーバー、ステージング環境は本番に近い非公開の検証サーバーです。ローカルは速度と作業の自由度に優れますが、本番とOSやサーバー設定が違うため、ローカルで動けば必ず本番でも動くとは限りません。
ローカル環境を作るメリット・デメリット
ローカル環境の主な利点は、失敗を公開サイトへ見せずに試せることです。PHP更新、プラグイン競合、テーマ編集、データ移行などを繰り返せます。インターネット接続が不安定でも作業でき、同じ構成を複数用意して比較することも可能です。
一方で、次の違いには注意が必要です。
- メールは実送信されない、または別の受信確認機能を使うことがある
- SSL、キャッシュ、CDN、WAFなど本番固有の機能を再現できない場合がある
- PHP、データベース、拡張モジュールの差で結果が変わる
- 外部APIや決済はテスト用資格情報が必要になる
- 本番データを複製すると、個人情報がパソコン内に残る
本番データを使う場合は、保存範囲を最小限にし、不要な個人情報を匿名化します。バックアップファイル、データベース、設定ファイルを共有ストレージへ無造作に置かないでください。
WordPressローカル環境ツールを比較
| ツール | 操作 | 構成の自由度 | 主な強み | 注意点 |
|---|---|---|---|---|
| Local | デスクトップ画面 | 中 | WordPressサイトを短時間で作成、SSL、Blueprint、Live Links | Local独自の環境差を理解する必要がある |
| WordPress Studio | デスクトップ・CLI | 中 | 無料、SSL、独自ドメイン、デバッグ、Blueprint、プレビュー | 標準DBはSQLite。必要に応じて任意のMySQLサーバーも使用できる |
| XAMPP | 管理画面と手動設定 | 高 | Apache、MariaDB、PHPをまとめて学べる | WordPressとDBを自分で配置・設定する |
| Docker | 設定ファイルとコマンド | 高 | 構成をファイル化してチームで再現しやすい | Docker、ネットワーク、ボリュームの知識が必要 |
LocalのLive LinksやStudioのプレビューは共有に便利ですが、公開前の一時確認用です。認証、保存期間、外部から見えるデータを確認し、本番サイトの代わりに常用しないでください。
比較時には、作成の簡単さだけでなく、本番へどこまで寄せられるかも見ます。WebサーバーがApacheかNginxか、PHPの小数バージョンと拡張、MySQLかMariaDBか、メールとcronをどう再現するかを確認します。公開前の最終試験は、本番に近いステージングで行うと環境差を減らせます。
チーム利用では、サイト本体の共有方法も重要です。LocalやStudioのアプリ設定だけを伝えても、テーマ、プラグイン、DB、アップロードが同じになるとは限りません。構成をBlueprint、バックアップ、Git、Docker設定のどれで共有するかを決め、秘密情報は別管理にします。
目的・レベル別のおすすめ
ブログや企業サイトを初めてローカルへ作るなら、Localが取り組みやすいでしょう。WordPressごとのサイト作成、起動、管理画面表示をひとつのアプリで行えます。
WordPress.comやPressableとの同期、内蔵デバッグ、Studio CLIを使いたい人にはWordPress Studioが合います。公式ドキュメントでは、macOS、Windows、Linux向けの配布と、ローカルサイトの作成、バックアップの入出力、プレビューが案内されています。
PHPとデータベースを自分で触りながら仕組みを学びたいならXAMPP、開発チームで同じ構成を再現し、設定をバージョン管理したいならDockerが候補です。Dockerは便利ですが、ひとりで記事編集を試すだけなら準備が過剰になることもあります。
LocalでWordPressを構築する手順
作業前に、パソコンの空き容量とOS対応状況を確認します。Localの公式案内では、最低4GBのメモリと1.5GBの空き容量が目安とされていますが、複数サイトや大容量データを扱うならさらに余裕が必要です。
Localをインストールする
Localの公式サイトから使用OSに合うインストーラーを取得し、通常のデスクトップアプリと同じようにインストールします。Windowsでは初回起動時にファイアウォールの許可を求められる場合があります。表示されたアプリ名と配布元を確認してから許可してください。
公開サーバーへ直接WordPressを用意する手順とは異なります。本番を新規構築する場合は「本番サーバーへのインストール」で、ドメイン、データベース、SSLまで含む流れを確認できます。
新しいWordPressサイトを作成する
Localを起動し、新規サイト追加のボタンからサイト名を入力します。環境を選べる画面では、最初は推奨構成を選ぶと迷いません。特定のPHPやWebサーバーを検証したい場合だけ、カスタム構成を選びます。
続けてWordPressの管理者ユーザー名、パスワード、メールアドレスを設定します。本番と同じパスワードを使い回さないでください。マルチサイトを試す場合は、作成時の詳細設定を確認します。
作成が完了すると、LocalがWordPress、PHP、データベースなどをまとめて準備します。サイトの保存場所も確認し、容量の大きいバックアップを同じフォルダへ何重にも置かないようにします。
同じ初期構成を繰り返し使う場合は、必要なテーマ、プラグイン、設定を入れたサイトをBlueprintとして保存できます。Blueprint自体を直接編集するのではなく、元にしたサイトを更新し、新しいBlueprintとして保存する運用にすると変更履歴を追いやすくなります。
サイトを起動して管理画面へ入る
対象サイトを選び、「Start site」で起動します。「Open site」で公開側、「WP Admin」で管理画面を開けます。初回は、設定した管理者情報でログインします。
SSL警告が出る場合は、Localの証明書を信頼する操作を確認します。URLを別のホスト名へ変えた場合は、画像や内部リンクの置換が必要になることがあります。作業後はサイトを停止し、アプリも終了するとパソコンの資源を解放できます。
LocalのMailpitなどメール確認機能が使える構成では、フォームやパスワード再設定メールを外部へ送らず確認できます。実メールサービスとは到達条件が違うため、From、Reply-To、本文の確認に使い、本番ではDNS認証と実送信も別途テストします。
WordPress Studioで構築する場合
WordPress Studioは、WordPressのローカル開発用デスクトップアプリです。公式ドキュメントでは、SSL、独自ローカルドメイン、Blueprint、デバッグログ、phpMyAdmin、Xdebug、バックアップの入出力などが案内されています。
Studioで新規作成したサイトは、標準ではMySQLサーバーではなくSQLiteを使用します。本番がMySQLまたはMariaDBなら、データベースエンジンの違いも互換性確認の対象です。公式FAQの手順に従えば、Studioでも任意のMySQLサーバーを接続して検証できます。
インストール後、「Add site」から「Build a new site」「Empty site」を選び、サイト名を付けます。詳細設定では、保存先、WordPress、PHP、管理者情報、独自ドメインを選べます。最初は既定値で作り、互換性試験時だけバージョンを合わせる方法が安全です。
WordPress.comへ接続すると、対応する同期、プレビュー、Studio Codeなどを利用できます。同期操作は公開側のデータを書き換える可能性があるため、接続先と方向がpushかpullかを実行前に確認します。
XAMPPで構築する場合
XAMPPはApache、MariaDB、PHP、Perlをまとめた配布パッケージです。WordPress専用ではないため、次の作業を自分で行います。
- 公式サイトからOSに合うXAMPPを入れる
- コントロールパネルでApacheとMySQLを起動する
- phpMyAdminなどでWordPress用データベースとユーザーを作る
- WordPress公式パッケージをWeb公開フォルダへ展開する
- ブラウザでインストール画面を開き、DB接続情報を入力する
Apacheのポート、PHP設定、ファイル権限を自分で調整できるため学習には向きます。一方、別のWebサーバーやデータベースが同じポートを使っていると起動しません。XAMPPは開発用途として扱い、設定を確認せず外部公開しないでください。
Dockerで構築する場合
Dockerでは、WordPressとデータベースを別コンテナとして定義し、ポート、環境変数、永続ボリュームを設定します。公式WordPressイメージには、DBホスト、DB名、ユーザー、パスワードなどの環境変数とDocker Composeの例があります。
チームで使う場合は、compose.yamlなどの構成ファイルを共有し、秘密情報はファイルへ直接書かず、環境変数管理やDocker Secretsなどを使います。データベースとwp-contentを永続化しないと、コンテナを作り直したときにデータを失います。
イメージのlatestだけに依存すると、時期によってWordPressやPHPが変わります。検証目的に合うタグを固定し、更新時は意図的に変更します。メール送信や追加PHP拡張は標準イメージだけで用意されないことがあるため、要件に応じて独自イメージを作ります。
本番サイトをローカルへ複製する
複製には、移行プラグインを使う方法、ツールのインポート機能を使う方法、ファイルとデータベースを手動で移す方法があります。どの方法でも、作業前に本番の完全なバックアップを作成します。
基本の流れは次のとおりです。
- 本番のWordPressファイルとデータベースを取得する
- ローカルへファイルとDBを取り込む
- wp-config.phpのDB接続先をローカル用にする
- 本番URLをローカルURLへ安全に置換する
- パーマリンクを再保存し、表示と管理画面を確認する
- メール、決済、外部連携、解析タグを停止またはテスト用へ切り替える
シリアライズされたデータを単純な文字列置換で壊さないよう、WordPress対応の移行機能やWP-CLIのsearch-replaceを使います。本番利用者へのメール誤送信を防ぐため、取り込み直後に送信経路を止めることが重要です。
会員、EC、予約サイトでは、利用者名、住所、注文、アクセストークンが複製される可能性があります。必要な投稿や設定だけを抽出できないか検討し、不要な個人情報は匿名化します。ローカル端末のディスク暗号化、画面ロック、バックアップの保管場所も確認してください。
複製後は管理者パスワードをテスト用へ変更し、決済をサンドボックスへ、外部Webhookを無効へ切り替えます。検索エンジンから見えないローカルでも、Live Linksを有効にすると外部アクセス経路が生まれるため、共有前にデータを再点検します。
ローカル環境を共有・本番へ移行する
短時間の確認なら、LocalのLive LinksやStudioのプレビューを使えます。共有前に、管理画面が外部へ露出していないか、認証が有効か、個人情報が含まれないかを確認します。パソコンから直接トンネル接続する方式では、端末を止めると閲覧できません。
完成したローカルサイトを公開へ移す場合は「ローカルから本番への移行」で、ファイル、DB、URL置換、DNS、SSL、動作確認の順を確認してください。移行直前には本番をバックアップし、更新停止時間と戻し方を決めます。
テーマやプラグインだけをGitやSFTPで移す場合と、データベースを含むサイト全体を移す場合ではリスクが違います。DBを上書きすると、本番で増えた注文、問い合わせ、コメントを失うことがあるため、差分の扱いを先に決めてください。
移行テストでは、ファイルとDBを転送できたかだけでなく、管理画面ログイン、パーマリンク、画像URL、フォーム、メール、定期処理を確認します。本番ドメインへ切り替えた後にローカルURLが残っていないかを検索し、混在コンテンツや外部から開けない画像を探します。
公開直後に問題が出た場合の戻し方も用意します。DNSを変える移行では旧サーバーの保持期間、DBを上書きする移行では直前バックアップと書き込み停止時間を決めます。戻した後に新旧環境へ注文などが分散しないよう、受付の扱いを明確にします。
起動しない・ポート競合・DB接続エラーの対処
サイトが起動しない場合は、アプリを再インストールする前に、エラーメッセージとログを保存します。次の順で切り分けます。
- アプリとサイトが起動状態か
- ディスク容量とメモリに余裕があるか
- WebサーバーやDBのポートを別アプリが使っていないか
- ファイアウォールやセキュリティソフトが通信を遮断していないか
- サイトの保存先に読み書きできるか
- DBホスト、DB名、ユーザー、パスワードが一致しているか
Localでサイトドメイン方式が動かないときは、ポート80や443を使う別アプリを調べます。XAMPPではApacheとMySQLの起動ログ、Dockerではコンテナの状態とログを確認します。
ポートを変更して起動できても、保存済みURL、Cookie、リダイレクトが古いポートを参照している場合があります。ブラウザのキャッシュとCookieを消し、WordPressのサイトURLも確認します。複数のローカルツールを同時起動すると競合しやすいため、使わない側のサイトとサービスを停止します。
DockerでDBだけ再起動を繰り返す場合は、コンテナ名ではなくサービス名、ネットワーク、ボリュームを確認します。データを消す可能性のあるdownのオプションを意味を確認せず実行しないでください。XAMPPではDBファイルを直接移動する前に、プロセスが停止しているかとバックアップを確認します。
DBへ接続できないときの詳しい確認順は「データベース接続確立エラー」で説明しています。DBを初期化する前に、接続情報の誤り、DBコンテナの未起動、壊れたテーブルを区別してください。
よくある質問
Local本体は無料でダウンロードしてローカルサイトを作成できます。アカウント接続が必要な機能や、外部サービスと連携する機能は条件が変わる可能性があるため、利用前に公式案内を確認してください。
本物のメールサーバーへ送らず、メール内容をローカルの受信箱で確認する構成が一般的です。Localなどのツールには確認機能があります。外部SMTPを使う場合は、誤送信と資格情報の保存に注意し、テスト専用の宛先を使います。
完全に同一でなくても編集はできますが、公開前の互換性確認では主なPHPバージョンと必要な拡張をそろえるのが安全です。データベース、Webサーバー、キャッシュなどの差も動作へ影響します。
まとめ
WordPressのローカル環境は、公開サイトへ影響を与えずに制作、更新、障害調査を行う場所です。初めてならLocal、WordPress公式の開発体験や対応サービスとの同期を重視するならStudio、手動構築の学習ならXAMPP、再現可能なチーム開発ならDockerが候補になります。
ローカルと本番の違いを記録し、個人情報、メール、決済、外部APIを安全なテスト設定へ切り替えてください。本番へ反映するときは、バックアップ、差分、URL置換、戻し方を決め、移行後の確認までを一つの作業として進めます。