※この記事では、WordPressの中にオリジナルで作成したページをローカルで確認する方法について書いてある記事です。
WordPressの中にオリジナルページを作成する方法に関しては、別の記事にしているのでご参照ください！
（👇の記事はFTPを使ってリモートで確認する方法が書いてあります。ここではDockerを使います。）
オリジナルページ関連の記事は、この記事下部に掲載しています。
WordPressの子テーマをいじっていて、いちばん困るのが「確認するには本番サーバーに上げるしかない」という状況です。
私はCocoonの子テーマでトップページのテンプレートを自作していて、今回それを大きく作り替える作業をしていました。
ですが、途中の状態を本番サーバーに上げたくありません。
かといって、ローカルでHTMLファイルを開いて見るだけでは、PHPの部分（get_header()のような呼び出し）が動かないので、本当の見た目がわかりません。
そこでDockerを使って、パソコンの中に「空のWordPress」を立てて、そこに開発中の子テーマだけを読み込ませる環境を作りました。
この記事では、そのときの手順をそのまま残しておきます。
この記事はCocoonの子テーマを例にしていますが、仕組み自体はどのテーマでも同じです。
サイト名やフォルダ名は sample に置き換えて書いています。ご自身の環境に合わせて読み替えてください。
Dockerは「WordPressのフォルダに入れる」ものではありません
最初、私はここを勘違いしていました。
「今あるWordPressのディレクトリは複雑なのに、そこにDockerを入れてもいいのかな？」と思っていたんです。
結論から言うと、逆でした。
やることは、ローカルにまっさらな新品のWordPressをDockerで立てて、そこに自分の子テーマフォルダを「マウント」するだけです。
本番のサーバーには一切触れません。
イメージとしてはこういう形になります。
Docker（自分のパソコンの中だけ）
├─ WordPress本体のコンテナ（空の新規WP）
│ └─ wp-content/themes/
│ ├─ cocoon-master/ ← Cocoon親テーマ（無料でDLして置く）
│ └─ sample-child-master/ ← ★開発中の子テーマをマウント
└─ データベースのコンテナ（MariaDB）子テーマのフォルダはコピーされるのではなく、手元のフォルダがそのままコンテナの中から見えている状態になります。
なので、パソコンでファイルを編集してブラウザをリロードすれば、それだけで反映されます。
【手順①】Docker Desktopを入れる
まずDocker本体が必要です。
私はMacなので、Docker Desktopの公式サイトからダウンロードしてインストールしました。
インストール後、Docker Desktopを起動しておきます。
ターミナルで次のコマンドを打って、バージョンが返ってくればOKです。
docker --versionDocker Desktopのインストール方法については、別の記事の最初の方に掲載しているのでご参照ください。
【手順②】子テーマのフォルダに docker-compose.yml を置く
ここが今回のキモです。
子テーマのフォルダ（GitHubで管理しているならそのリポジトリのルート）に、docker-compose.yml というファイルを1つ作ります。
私が実際に使っているものが、こちらです。
services:
db:
image: mariadb:10.11
environment:
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
MYSQL_ROOT_PASSWORD: root
volumes:
- db_data:/var/lib/mysql
wordpress:
image: wordpress:latest
depends_on:
- db
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
- wp_data:/var/www/html
# Cocoon親テーマ（local-dev/にダウンロードしたもの）
- ./local-dev/cocoon-master:/var/www/html/wp-content/themes/cocoon-master
# このフォルダ＝子テーマ（本番と同じフォルダ名でマウント）
- .:/var/www/html/wp-content/themes/sample-child-master
# wp-cliは `docker compose run --rm wpcli <コマンド>` で使う
wpcli:
image: wordpress:cli
profiles: ["cli"]
depends_on:
- wordpress
- db
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
- wp_data:/var/www/html
- ./local-dev/cocoon-master:/var/www/html/wp-content/themes/cocoon-master
- .:/var/www/html/wp-content/themes/sample-child-master
volumes:
db_data:
wp_data:長く見えますが、やっていることは3つだけです。
db（データベース）
WordPressにはデータベースが必要なので、MariaDBを一緒に立てています。
ユーザー名もパスワードも wordpress のままですが、ローカルの自分のパソコンの中でしか動かないので、これで問題ありません。
wordpress（本体）
ports の "8080:80" は、ブラウザで http://localhost:8080 と打つとこのWordPressが開く、という意味です。
そして volumes のところが、いちばん大事な部分になります。
- .:/var/www/html/wp-content/themes/sample-child-masterこの .（ドット）は「今いるフォルダ」、つまり自分の子テーマフォルダそのものです。
それを、コンテナの中の themes フォルダに 本番と同じフォルダ名で置いています。
本番と同じフォルダ名にするのは大切で、名前が違うと親テーマの参照がずれることがあります。
wpcli
wp-cliはWordPressをコマンドで操作するためのツールです。
profiles: ["cli"] と書いてあるので、普段は起動しません。
使いたいときだけ呼び出す形になっています。
【手順③】Cocoon親テーマをダウンロードして置く
子テーマだけでは動かないので、親テーマも必要です。
私は local-dev というフォルダを作って、そこに親テーマを展開しました。
mkdir -p local-dev && cd local-dev
curl -sL -o cocoon.tar.gz https://github.com/yhira/cocoon/archive/refs/heads/master.tar.gz
tar -xzf cocoon.tar.gz && rm cocoon.tar.gz
cd ..これでCocoonの公式GitHubから親テーマ一式（14MBくらいありました）が落ちてきて、local-dev/cocoon-master/ に展開されます。
Cocoon公式サイトからzipをダウンロードして、手で置いても構いません。
local-dev フォルダは .gitignore に入れておくといいと思います。
親テーマはサーバーにアップロードする必要がありませんし、Gitで管理するにはサイズが大きいためです。
【手順④】起動する
あとはコマンド1つです。
docker compose up -d初回はイメージのダウンロードがあるので少し時間がかかります。
終わったら、ブラウザで http://localhost:8080 を開きます。
WordPressの初期設定画面（言語選択からのインストール画面）が出れば成功です。
【手順⑤】初回だけ、WordPress側の設定をする
ここは初回だけの作業です。
ブラウザの管理画面から、次の順で設定していきます。
① WordPressをインストール（管理者ユーザー名とパスワードを決める）
② 「外観」→「テーマ」→ 自分の子テーマを有効化
③ 固定ページを新規作成 → ページ属性のテンプレートで自作テンプレートを選ぶ
④ 「設定」→「表示設定」→ ホームページの表示を「固定ページ」にして、③で作ったページを指定
⑤ 新着記事欄などの確認用に、ダミー記事を2〜3本投稿しておく
これでトップページのテンプレートが、本物のWordPressとして表示されるようになります。
ここまでやれば、データベースはDockerのボリュームに残るので、次回からは設定をやり直す必要はありません。
ちなみに私の場合は、この初期設定を自動でやってくれるシェルスクリプトをClaude Codeに作ってもらったので、コマンド1つで済んでいます。
ですが、手でやっても5分ほどの作業だと思います。
【手順⑥】日常の使い方はこれだけ
2回目以降は、この3つのコマンドしか使いません。
docker compose up -d # 起動する
docker compose down # 停止する（DBの中身は残る）
docker compose down -v # 完全リセット（DBも消える。次回は初期設定からやり直し）起動したら、あとは手元のファイルを編集してブラウザをリロードするだけです。
アップロードもキャッシュ削除も必要ありません。
down と down -v の違いは大事なので、覚えておくといいと思います。
-v を付けるとデータベースごと消えるので、記事も設定も全部やり直しになります。
この環境のおかげで見つかった不具合
ここが、この記事でいちばん書いておきたかったところです。
今回のリニューアルでは、途中まで静的なHTMLプレビュー（PHPを動かさず、ブラウザで見た目だけ確認する方法）で作業していました。
その時点では、ボタンはちゃんとネオンシアンに光って見えていました。
ところが、Dockerで本物のWordPress＋Cocoonの上に載せてみたら、そのボタンが地味なグレーになっていたんです。
原因は、CSSのクラス名の衝突でした。
私が使っていた .btn というクラス名が、Cocoon本体が持っているボタンのスタイルと同じ名前だったのです。
親テーマのCSSに上書きされて、自分で書いた発光の指定が効かなくなっていました。
クラス名を .fl-btn のような独自の接頭辞付きに変えて、解決しました。
静的プレビューでは、絶対にこれは見つかりませんでした。
親テーマのCSSが読み込まれていない状態で見ているので、衝突のしようがないからです。
本番に上げてから「あれ、色が違う」と気づくパターンを、ローカルで回避できたことになります。
子テーマでよく使いそうな汎用的なクラス名（.btn .card .container あたり）は、親テーマ側とぶつかりやすいのだと思います。
自分専用の接頭辞を付けておくのが安全だと感じました。
本番サーバーには何をアップロードするのか
ここも整理しておきます。
docker-compose.yml と local-dev/ フォルダは、ローカル確認専用です。
サーバーにアップロードする必要はありません。
確認が終わったら、今まで通りテーマファイル（.php / .css / .js / 画像フォルダなど）だけをサーバーの子テーマフォルダに上げます。
本番のディレクトリ構造は何も変わらないので、既存の運用をそのまま続けられます。
他の選択肢もあります
Dockerが必須というわけではありません。
ローカルでWordPress環境を作る方法は、調べた範囲では他にもいくつかあります。
| 方法 | 特徴 |
| Docker Compose | 一度組めばシンプル。設定ファイルをGitで共有できる。今回私が使った方法 |
| Local（localwp.com） | GUIで完結するアプリ。Dockerの知識がなくても使える |
| Studio | WordPress.com製のローカル環境アプリ |
| wp-env | WordPress公式のCLIツール。内部でDockerを使う。Node.jsが必要 |
GUIアプリを使う場合も、themesフォルダに自分の子テーマフォルダをシンボリックリンクで置けば、同じことができるようです。
私はもともとDockerを触ったことがあったので、設定ファイル1枚で完結するDocker Composeを選びました。
まとめ
WordPressの子テーマをローカルで確認する方法は、「今あるWordPressにDockerを入れる」のではなく、「空のWordPressをDockerで新しく立てて、そこに子テーマを差し込む」という発想でした。
ここさえ理解できれば、docker-compose.yml を1枚置いて docker compose up -d と打つだけです。
本番サーバーに一切触らずに、PHPもCSSも本物の環境で確認できるようになりました。
そして今回、静的プレビューでは気づけなかったCSSクラス名の衝突を、本番に上げる前に見つけられました。
「上げてから気づく」を1回避けられただけでも、環境を作った価値はあったと思います。
今回の子テーマ改修とDocker環境の構築は、ほとんどClaude Codeにやってもらいました。
ですが、こうして手順を書き出してみると、やっていること自体はそれほど複雑ではありませんでした。
次からは自分でも組めそうです。
オリジナルページ関連の記事はこちら↓
