Dockerを使う

Docker初心者が「WordPressの検証環境」を作って分かったこと

これまで、案件ごとにPHPが違うたび、ローカル環境の切り替えに手間がかかって困ることが何度かありました。Dockerなら、WordPress検証環境を“複製・切替”しやすくなり、PHPバージョン検証がしやすくなる、と知りました。この記事では、Docker初心者の私がつまずいた点も含めて、導入からPHP切替テストまでの流れをそのまま共有します。

こんな人におすすめ

• XAMPPで運用しているが、案件が増えて切り替えがつらくなってきた
• クライアントのPHP更新に備えて、ローカルで安全に検証したい
• WordPressを複数案件で並行して扱っており、環境を分離したい
• Dockerは聞いたことがあるが、何から始めればいいか分からない

「クライアント案件ごとにPHPのバージョンが違う」
「ローカルに複数のWordPressを持つと、管理がどんどん面倒になる」
「本番に近い検証がしたいのに、毎回ローカル環境を作り直すのが面倒」

ウェブ制作に関わっていると、こうした“地味に効いてくるストレス”に何度も直面します。私自身、これまではXAMPPでローカル環境を作ってきました。XAMPPは手軽で初期構築も早く、これは本当に助かります。ただし、案件が増えたり、サーバー環境の差が大きくなったりすると、少しずつ「限界」が見えてくるのも事実です。

とくに厄介なのが、PHPバージョンの切り替えです。
「PHP 7.4では動いていたのに、8.0に上げたら真っ白」
「エラーメッセージが複数出て、どれが致命的でどれが無視できるのか分からない」
「本番環境で試すのは怖い。でも検証環境を作るのも手間」

この“怖さ”と“面倒さ”が同時に来るのが、PHPバージョン検証のつらいところです。そこで私は、「もっと柔軟に検証環境を作れないか」と考え始め、Dockerを試すことにしました。

この記事で分かること

• DockerでWordPress環境を立ち上げる、最低限の流れ
• docker-compose.yml の役割と、触るべきポイント
• PHPバージョンを切り替えて検証する基本的な手順
• “真っ白画面”など、よくあるつまずきの対処の考え方（ログの見方）

1分で分かる用語

• コンテナ：アプリを動かすための「小さな実行環境」。案件ごとに分けて持てる。
• イメージ：コンテナの“元”になる設計図。PHP8.2版などの違いはタグで指定する。
• ボリューム：データを保存する仕組み。コンテナを作り直してもDBやファイルを保持しやすい。

---

1：なぜDockerでWordPress環境を作ることにしたのか

Dockerはコンテナ技術を使い、アプリケーションと実行環境をひとまとめにして扱えるツールです。WordPress、PHP、データベースなどをそれぞれ独立したコンテナとして動かせるため、環境の切り替えや複製が比較的容易になります。

雑に言えば、こういう世界観です。

• 「案件A用（PHP7.4）」のWordPress環境
• 「案件B用（PHP8.2）」のWordPress環境

これを同じPC上で用意して、必要に応じて切り替えたり、同時に動かしたりできます。この“検証のしやすさ”が大きな魅力だと感じました。

XAMPPは「1台のローカル環境を、運用しながら育てる」感覚に近い一方で、Dockerは「環境そのものを、案件ごとに分けて持つ」イメージに近いです。この違いが、複数案件やPHPのバージョン違いがあるときに効いてきます。

Dockerを使う理由

• できれば本番とほぼ同じ近いサイト構成で確認したい
• でも本番を直接触るのは怖い（事故のコストが高すぎる）
• 検証のたびにローカル環境が変わると、手間が何度もかかり管理しにくい
• “案件ごとの環境”を分離して、気楽にテストし、エラーが出ても気楽に作り直したい

注意点

• 初めて触る場合、Dockerの概念（コンテナ／イメージ／ボリューム等）の理解に時間がかかることがある。
• Windows環境ではDocker Desktopを使うのが一般的で、場合によりWSL2設定が必要になる場合がある。
• PCのスペックやWindowsのバージョンによって挙動に差が出ることがある（起動が重い、同期が遅い等）。

ここまでの要点

• Dockerは「環境を案件ごとに分離して持ちやすい」ため、検証が楽になる。
• PHPバージョン違いの確認を“本番に影響を与えず”試しやすいのが魅力。
• ただし、最初は概念の理解とWindows設定（WSL2）でつまずく可能性がある。

---

2：Dockerで実際にWordPress環境を構築してみた

前提条件

• Windows 10
• Docker Desktopインストール済み
• 基本的なコマンドライン操作（コピペができる程度でOK）

私が実際にやった手順は次の通りです。“完璧”よりも、“まず動かして感覚を掴む”を優先しています。

1. Docker Desktopのインストール

公式サイトからインストーラーをダウンロードしてインストールします。初回起動時、WSL2のインストールを求められることがあるので、その場合は指示に従って設定します。

ここでのポイントは、「Docker Desktopが起動している状態で作業する」こと。後述しますが、起動していないだけでエラーになり、最初は原因に気づきにくいです。

2. docker-compose.ymlファイルの作成

プロジェクト用フォルダ（例：C:\docker-wordpress）を作り、その中に docker-compose.yml を作成します。ここにWordPressとMySQLの設定を書きます。

version: '3.8'

services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - ./wordpress:/var/www/html

  db:
    image: mysql:5.7
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_USER: exampleuser
      MYSQL_PASSWORD: examplepass
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - ./db_data:/var/lib/mysql

補足：docker-compose.yml は「この環境はこういう構成で動かす」という設計図です。WordPress側とDB側を分けて書けるので、構成が見やすいのもメリットです。

注意

• 実際の案件ではパスワードを必ず複雑にする
• ポート（8080）が競合しないか確認が必要
• volumes により、Windows側フォルダとコンテナ内が同期される（便利な反面、環境によっては同期が遅い等の要因になることもある）

3. コンテナの起動

コマンドプロンプトまたはPowerShellでプロジェクトフォルダへ移動し、以下を実行します。

docker-compose up -d

初回はイメージのダウンロードが走るため数分かかることがあります。-d はバックグラウンド実行（ターミナルを占有しない実行）です。

4. WordPressへのアクセス

ブラウザで http://localhost:8080 を開き、WordPressの初期設定画面が出れば成功です。

私が実際につまずいた点

• Docker Desktopが起動しておらずエラーになった
• ポート8080が別アプリで使用中で、ポート番号を変更した
• ファイアウォールが接続をブロックした

このあたりは“環境依存”が強いので、正解が一つではないと思います。私が実感した最短ルートは、「エラーメッセージをそのまま検索する」ことでした。Dockerは「検索して→試して→また検索して→前に進む」が現実的で、むしろそれが普通だと思います。

ここまでの要点

• まずは docker-compose.yml を作って「WordPress＋DB」を起動するのが第一歩。
• 表示できない時は「Docker Desktop起動」「ポート競合」「ファイアウォール」を順に疑うと整理しやすい。
• 最短は、エラーメッセージをそのまま検索して“正解”を拾う。

---

3：Docker内でPHPバージョンを変更する

ここが今回のメインテーマです。制作現場では、サーバーのPHPバージョンアップに伴う動作確認が必須になりがちです。Dockerを使えば、本番環境に影響を与えることなく、比較的安全に検証できます。

現場でよくあるのは、こんな状況です。

• サーバー会社から「PHPを上げます」と通知が来る
• 期日までに検証してくださいと言われる
• でも本番で試して落ちたら終わる
• ローカルで試そうとしても、環境の再現が面倒

Dockerは、この“再現の面倒さ”をかなり減らしてくれます。特に「いつものWordPress環境」を複製しやすいのが大変便利です。

PHPバージョンを変更する方法

docker-compose.yml の WordPress 部分で image タグを差し替えます。

services:
  wordpress:
    image: wordpress:php8.2-apache  # ←ここを変更
    ports:
      - "8080:80"
    # (以下略)

WordPress公式のDockerイメージは、タグでPHPバージョンを指定できます。

• wordpress:php7.4-apache → PHP 7.4
• wordpress:php8.0-apache → PHP 8.0
• wordpress:php8.2-apache → PHP 8.2

変更したら、以下でコンテナを再構築します。

docker-compose down
docker-compose up -d --build

ポイント：「変更したのに反映されない」場合、一度落として作り直すのが確実です。キャッシュが効く場面もあるので、“切り替えたつもり”が起きやすい印象でした。

実際に確認したこと

検証で見るべき項目は、いきなり深掘りしなくてもOKで、私はまず次の順で見ました。

• サイトが表示されるか：http://localhost:8080 で真っ白やエラーが出ないか
• 管理画面に入れるか：/wp-admin にアクセスできるか
• プラグイン／テーマが動くか：互換性があるか、表示崩れがないか
• 重要動線だけ確認：フォーム送信、主要ページ遷移など「壊れると痛い箇所」を優先

全部を完璧に確認するのは現実的に難しいので、「重要度が高い部分から潰す」という考え方が良いと思います。

私が経験したエラー例

• PHP 8.0で、古いプラグインから警告が大量に出た
• テーマによってレイアウト崩れが出た（CSS読み込み順が変わったように見えた）
• 真っ白になった時は、ログに致命的エラーが記録されていた

ログの確認方法

コマンドで

docker-compose logs wordpress

ログを見ると、原因の手掛かりが一気に増えます。真っ白画面のときほど、まずログを確認するという癖がつきました。「ブラウザの問題」と決めつけず、サーバー側のエラーとして扱えるのがDocker検証の強みでもあります。

注意点・推測

• すべての不具合がPHPバージョン起因とは限らない（プラグイン競合やテーマ側要因もあり得ます）。
• 私の環境では7.4→8.0は比較的スムーズだったが、これは使用プラグイン構成に依存していた可能性がある（推測）。
• 本番反映前には必ずバックアップを取る（基本中の基本、しかし忘れることが多い）。

ここまでの要点

• PHP切替は image のタグ変更＋down→up --build が基本。
• 確認は「表示→管理画面→プラグイン/テーマ→重要動線」の順が現実的。
• ”画面真っ白”はログ確認が近道。docker-compose logs wordpress をまず見る。

---

4：Dockerで学んだことと、今後の学習など

Docker初心者として、約1週間ほどかけて一通り試しました。実務と学習を同時進行するのは、時間管理も困難になります。

最後に、XAMPPと比較して感じたポイントをまとめます。

Dockerのメリット

• 環境切り替えが比較的簡単（docker-compose.yml を変更するだけで済む場面が多い）
• 複数案件を同時に管理しやすい（案件Aを壊しても案件Bに波及しにくい）
• 本番に近い条件でテストできる可能性が高い
• チーム開発でも環境共有がしやすい（composeファイルを共有できる）

私が一番ありがたかったのは、「検証のための検証」をしなくてよくなる点でした。つまり、検証したいのはPHPの互換性なのに、その前段でローカル環境が崩れて時間がなくなっていく、この状況が減るのはかなり大きいです。

Dockerのデメリット・課題（個人的に感じた点など）

• 初期学習コストがそれなりに高い（概念が壁）
• トラブル対応には検索スキルが必要
• Windows環境はWSL2周りでつまずきやすい
• ディスク容量をそれなりに消費する（気づくと膨らみがち）

Dockerは「一度慣れれば速い」反面、「慣れるまでが遅い」。ここは人によって感じ方が分かれそうです。ただ、制作業務の中で“検証”が頻出なら、投資として回収できる可能性は十分あると感じました。

今後挑戦したいこと

• 本番に近い構成（Nginx採用など）
• CI/CDと連携した自動テスト環境（更新のたびに自動で動作確認）
• 複数サイトを整理して運用できる仕組みづくり（案件が増えても迷子にならない）

注意事項

• 本稿は私個人の経験に基づくため、すべての環境で同じ結果になるとは限りません。
• Windowsのエディション／バージョンで手順が変わる可能性があります。
• Docker Desktopの更新で設定方法が変わる可能性があります。
• セキュリティの詳細設定は扱っていません（学習用の簡易構成です）。
• 大規模サイトや複雑な要件では専門家相談を推奨します。

ここまでの要点

• Dockerは“検証の武器”になりやすく、案件が増えるほど恩恵を感じやすいです。
• 一方で学習コストとWindows特有のつまずき（WSL2）は現実にあります。
• 万能ではないので、XAMPP等と用途で使い分けるのが現実的です。

---

まとめ：Dockerは「検証の武器」になる。ただし万能ではない

クライアントのサーバー環境が多様化するいま、Dockerで検証環境を組めるようになると、制作の安心感が増します。少なくとも私にとっては、「本番を壊さずに、PHPバージョン違いを試せる」ことが大きな価値でした。

一方で、Dockerは万能ツールではありません。案件や状況によっては、XAMPPのような手軽な方法が適していることもあります。大切なのは「どれか一つに決める」ではなく、用途に応じて使い分けることだと感じています。

参考情報

• Docker公式ドキュメント（英語）： https://docs.docker.com/get-started/overview/
• Docker公式ドキュメント（日本語翻訳版）：https://docs.docker.jp/
• Docker Hub：（英語）https://hub.docker.com/