【Docker】WordPress環境構築完全ガイド｜compose完全版・wp-cli・Xdebug・mailpit・Redis・HTTPS・本番移行・CI/CD

【Docker】WordPress環境をDockerで構築する手順 Docker
2025.09.20

WordPressのローカル開発環境は長らくXAMPPやLocal by Flywheelが定番でしたが、2026年現在、Docker Composeが最も再現性が高く、チーム共有しやすい手段として主流になっています。1つのcompose.ymlで「PHP・DB・phpMyAdmin・メール・キャッシュ・SSL」まで一式が再現でき、PCを買い替えてもdocker compose up一発で同じ環境が立ち上がります。

しかし多くの入門記事は「公式wordpressイメージを起動するだけ」で止まっており、実案件で必要になるwp-cli統合・Xdebug・mailpit・Redis object cache・本番DB取り込み・SSL対応（mkcert）・複数WP同時起動（nginx-proxy）・セキュリティ（非root）・CI/CDでのイメージビルドまでカバーした情報源はほとんどありません。

この記事では、Dockerの基本構成3パターン比較から始めて、本番運用レベルのcompose.yml完全版（WordPress + MariaDB + phpMyAdmin + mailpit + Redis）、wp-cliをコンテナから叩く方法、Xdebugデバッグ、HTTPS対応（mkcert）、本番データ取り込み、複数WPを同時起動するnginx-proxy構成、セキュリティ、CI/CD統合まで、2026年の現場で通用するWordPress × Docker完全ガイドとしてまとめます。

Docker基礎（volume／bind mount／compose）の前提知識は【Docker】volumeの使い方とデータ永続化の基本、【Docker】bind mountとvolumeの違いと使い分け、【Docker】Composeで複数コンテナを連携させる方法で補完できます。

この記事で学べること

  • WordPress × Dockerの構成3パターン比較（公式image／Nginx+PHP-FPM／Bitnami）
  • 本番相当のcompose.yml完全版（WP／MariaDB／phpMyAdmin／mailpit／Redis）
  • bind mount vs named volume のWordPress特有の使い分け（plugins／themes／uploads／DB）
  • wp-cliをコンテナから叩いてプラグイン／テーマ／オプション操作を自動化
  • Xdebugを有効化したPHPイメージでVS Codeデバッグ
  • メール送信テスト用のmailpit連携（Contact Form 7確認）
  • Redis object cacheでパフォーマンス向上
  • 本番サイトのDB・ファイルを安全にローカルへ取り込むフロー
  • ローカルHTTPS対応（mkcertでTLS証明書を作成）
  • 複数WPを同時起動するnginx-proxy構成
  • セキュリティ強化（非rootユーザー・secrets／env_file分離）
  • GitHub Actionsでのイメージ自動ビルドとテスト
スポンサーリンク

30秒クイックスタート：最小compose.yml

まずは動く最小構成。compose.ymlを置いてdocker compose up -dで起動できます。

compose.yml（最小構成）
services:
  wordpress:
    image: wordpress:6.7-php8.3-apache
    ports: ["8080:80"]
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: wp
      WORDPRESS_DB_NAME: wp
    volumes:
      - ./wp-content:/var/www/html/wp-content
    depends_on:
      db:
        condition: service_healthy

  db:
    image: mariadb:11
    environment:
      MARIADB_DATABASE: wp
      MARIADB_USER: wp
      MARIADB_PASSWORD: wp
      MARIADB_ROOT_PASSWORD: root
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 5s
      timeout: 3s
      retries: 10

volumes:
  db_data:
起動確認
docker compose up -d

# http://localhost:8080 でWordPress初期セットアップ画面

# 停止
docker compose down

# データも削除（volume含む）
docker compose down -v

2026年時点の推奨構成：wordpress:6.7-php8.3-apache＋mariadb:11。旧来のMySQL 5.7はEOL、MariaDBは互換性＋活発な開発で後継に最適。version:キーはComposeV2以降不要（指定すると警告）。

WordPress × Docker 構成3パターン比較

公式イメージだけでなく、用途によって最適な構成が変わります。

構成 特徴 向いているケース
公式wordpress:*-apache Apache同梱、最短5行で起動 入門／小規模開発／プラグイン検証
公式wordpress:*-fpm + nginx 高速／本番相当／SSL構成が楽 本番移行前の検証／高トラフィック想定
Bitnami wordpress 構成済み・K8s／Helm対応 本番K8sで動かす予定／SSL/nginx一体

どれを選ぶか迷ったら

個人ブログ／小規模開発は公式Apacheイメージで十分。本番相当の性能検証が必要なら公式PHP-FPM + nginx。Kubernetesへの本番デプロイを視野に入れるならBitnamiが楽。まずはApache版で始めて、必要になったら移行するのが現実的です。

本番相当の完全版compose.yml

実開発で必要な機能を詰め込んだ完全版。WordPress／MariaDB／phpMyAdmin／mailpit／Redisが連携します。

compose.yml（完全版）
services:
  wordpress:
    image: wordpress:6.7-php8.3-apache
    ports: ["8080:80"]
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: wp
      WORDPRESS_DB_NAME: wp
      WORDPRESS_DEBUG: "true"
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_DEBUG_LOG', true);
        define('WP_DEBUG_DISPLAY', false);
        define('SCRIPT_DEBUG', true);
        define('WP_REDIS_HOST', 'redis');
    volumes:
      - ./wp-content:/var/www/html/wp-content      # テーマ・プラグイン・uploads
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro
    depends_on:
      db: { condition: service_healthy }
      redis: { condition: service_started }
    networks: [wp-net]

  db:
    image: mariadb:11
    environment:
      MARIADB_DATABASE: wp
      MARIADB_USER: wp
      MARIADB_PASSWORD: wp
      MARIADB_ROOT_PASSWORD: root
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 5s
      retries: 10
    networks: [wp-net]

  phpmyadmin:
    image: phpmyadmin:latest
    ports: ["8081:80"]
    environment:
      PMA_HOST: db
      UPLOAD_LIMIT: 128M
    depends_on: [db]
    networks: [wp-net]

  mailpit:
    image: axllent/mailpit:latest
    ports:
      - "8025:8025"   # Web UI
      - "1025:1025"   # SMTP
    networks: [wp-net]

  redis:
    image: redis:7-alpine
    networks: [wp-net]

  wpcli:
    image: wordpress:cli-php8.3
    user: "33:33"              # www-dataユーザー
    volumes:
      - ./wp-content:/var/www/html/wp-content
    working_dir: /var/www/html
    depends_on:
      db: { condition: service_healthy }
    networks: [wp-net]
    profiles: ["cli"]         # 通常起動しない
    command: ["--info"]

volumes:
  db_data:

networks:
  wp-net:
uploads.ini（PHP設定上書き）
file_uploads = On
memory_limit = 512M
upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300

各サービスの役割

  • wordpress：本体（Apache＋PHP8.3）、wp-contentをホスト同期
  • db：MariaDB 11、healthcheckで準備完了を保証
  • phpmyadmin：DB GUI操作（http://localhost:8081）
  • mailpit：送信メール全てキャプチャ（UI: http://localhost:8025）
  • redis：Object Cache。redis-cacheプラグインで有効化
  • wpcli：profiles: [cli]で通常は起動しない、必要時のみ

WordPressでのbind mount／named volume使い分け

WordPressの全ディレクトリをbind mountするとパフォーマンスが落ち、すべてnamed volumeにすると開発できなくなります。編集対象だけbind、DBはvolumeが鉄則です。

対象 推奨 理由
wp-content/themes/ bind mount エディタで直接編集
wp-content/plugins/ bind mount プラグイン開発／Git管理
wp-content/uploads/ bind mount（開発）
named volume（本番）		 開発：画像をgit除外で確認／本番：I/O最適化
wp-admin/／wp-includes/ マウントしない（image内のまま） WordPress本体コア、通常編集不要
DB（/var/lib/mysql） named volume I/O最速／Docker管理／削除時はvolume明示

全体を./wp-data:/var/www/htmlでマウントする構成を入門記事でよく見かけますが、コア（wp-admin等）まで含まれホスト側が肥大化、アップデート時のコンフリクトも起きます。wp-content配下のみマウントするのが現代的。詳しくは【Docker】bind mountとvolumeの違いと使い分け参照。

wp-cli統合：コンテナから叩いて自動化

wp-cliはWordPressをコマンド操作するツール。プラグイン／テーマ／オプション／ユーザー／投稿をスクリプト化でき、Dockerなら1コマンドで叩けます。

wp-cliの実行パターン
# プロファイルで一度だけ起動
docker compose run --rm wpcli wp --info

# プラグインを一括インストール
docker compose run --rm wpcli wp plugin install \
  wordpress-seo redis-cache wp-mail-smtp \
  --activate

# テーマ切替
docker compose run --rm wpcli wp theme activate mytheme

# オプション一括設定
docker compose run --rm wpcli wp option update blogname "開発環境"
docker compose run --rm wpcli wp option update blogdescription "dev"

# 管理者ユーザー作成
docker compose run --rm wpcli wp user create admin admin@example.com \
  --user_pass=admin --role=administrator

# データベース操作
docker compose run --rm wpcli wp db export /var/www/html/wp-content/backup.sql
docker compose run --rm wpcli wp db import /var/www/html/wp-content/backup.sql

# search-replace（本番→ローカルDB移行時のURL置換）
docker compose run --rm wpcli wp search-replace \
  "https://example.com" "http://localhost:8080" --all-tables

# キャッシュクリア
docker compose run --rm wpcli wp cache flush
自動セットアップスクリプト（scripts/setup.sh）
#!/usr/bin/env bash
set -euo pipefail

docker compose up -d
echo "Waiting for DB..."
until docker compose exec db healthcheck.sh --connect &>/dev/null; do sleep 2; done

echo "Installing WordPress..."
docker compose run --rm wpcli wp core install \
  --url=http://localhost:8080 \
  --title="Dev Site" \
  --admin_user=admin \
  --admin_password=admin \
  --admin_email=admin@example.com

echo "Installing plugins..."
docker compose run --rm wpcli wp plugin install \
  redis-cache wp-mail-smtp --activate

echo "Activating object cache..."
docker compose run --rm wpcli wp redis enable

echo "Setup complete: http://localhost:8080"

scripts/setup.shを1回実行するだけで、DB初期化→WP本体インストール→プラグイン導入→Redis有効化まで完結。メンバー全員が同じ環境を5分で構築でき、新人オンボーディングが革命的に楽になります。

Xdebugでステップ実行デバッグ（VS Code連携）

プラグイン／テーマ開発で「なぜこの値が入る？」をステップ実行したい時にXdebugが必須。公式イメージをベースにしたカスタムDockerfileで有効化します。

Dockerfile（Xdebug付き）
FROM wordpress:6.7-php8.3-apache

RUN pecl install xdebug \
 && docker-php-ext-enable xdebug

COPY xdebug.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
xdebug.ini
zend_extension=xdebug
xdebug.mode=debug,develop
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.idekey=VSCODE
xdebug.log=/tmp/xdebug.log
compose.yml（Xdebug対応）
services:
  wordpress:
    build: ./docker/wordpress    # Dockerfileのあるディレクトリ
    ports: ["8080:80", "9003:9003"]
    extra_hosts:
      - "host.docker.internal:host-gateway"   # Linux対応
    # ... 他は省略
.vscode/launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        "/var/www/html/wp-content": "${workspaceFolder}/wp-content"
      }
    }
  ]
}

Xdebugでできること

  • ブレークポイントで処理を停止して変数確認
  • ステップ実行（F10／F11で1行ずつ進める）
  • 式の評価（デバッグコンソールで$post->ID等を確認）
  • コールスタック表示で「誰から呼ばれたか」追跡
  • WordPressのフック動作を実体レベルで理解

mailpitでメール送信テスト（Contact Form 7確認）

WordPressのお問い合わせフォーム送信やユーザー登録メールをローカルで確認するためには、SMTPをキャッチする仕組みが必要。mailpitが最も手軽で、送信メールをすべてWeb UIで見られます。

wp-cliでWP-Mail-SMTPプラグインをインストール
# プラグイン導入＋有効化
docker compose run --rm wpcli wp plugin install wp-mail-smtp --activate

# 送信設定はGUIから
#   WordPress管理画面 → WP Mail SMTP → Settings
#   Mailer: Other SMTP
#   SMTP Host: mailpit
#   SMTP Port: 1025
#   Authentication: OFF
#   From Email: dev@localhost

# 受信UI
# → http://localhost:8025 で全メール確認

コードで直接送信先を指定（シンプル版）

wp-config.php に直接追加
// wp-config.php or mu-plugin
add_action('phpmailer_init', function($phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Host = 'mailpit';
    $phpmailer->Port = 1025;
    $phpmailer->SMTPAuth = false;
    $phpmailer->From = 'dev@localhost';
    $phpmailer->FromName = 'Dev';
});

mailpitの強み：全メールをWeb UIで保存し、HTMLプレビュー＋Raw表示両方可能。Contact Form 7の管理者通知・自動返信の差出人／件名／文面を1画面で検証でき、「実メールアドレスに送信して本番スパムフィルタで消える」事故が発生しません。

Redis Object Cacheでパフォーマンス向上

WordPressのオブジェクトキャッシュは標準でメモリ上（リクエスト毎にリセット）。Redisを繋げばキャッシュがリクエスト間で共有され、DB問い合わせが数十%減少します。

Redis有効化の手順
# すでにcompose.ymlにredisサービスと
# WP_REDIS_HOST=redis が定義されている前提

# プラグイン導入＋有効化
docker compose run --rm wpcli wp plugin install redis-cache --activate

# Object Cache有効化
docker compose run --rm wpcli wp redis enable

# 動作確認
docker compose run --rm wpcli wp redis status
# Status: Connected
# Client: PhpRedis (4.x.x)

WP-Content配下にobject-cache.phpが生成される

wp redis enableを実行するとwp-content/object-cache.php（drop-in）が生成されます。このファイルはWordPressコアより優先されるため、Redisが未起動だとWordPress自体が動作不能になる可能性あり。本番切替時は必ずwp redis disableでdrop-inを削除してから環境を変更してください。

本番サイトのDB・ファイルを安全にローカル取り込み

本番データでバグ再現したい、テーマ開発をリアルデータで確認したい——よくある要件ですがURLの置換を忘れると本番に影響する事故が起きます。

本番データ取り込みフロー
# ① 本番でDBダンプ（SSH経由）
ssh prod-server "mysqldump -u wp_user -p wp_db | gzip" > backup.sql.gz

# ② gunzipして取り込み
gunzip -c backup.sql.gz | docker compose exec -T db \
  mysql -u wp -pwp wp

# ③ uploadsディレクトリを同期
rsync -avz prod-server:/var/www/html/wp-content/uploads/ \
  ./wp-content/uploads/

# ④ URLを本番→ローカルへ置換（最重要）
docker compose run --rm wpcli wp search-replace \
  "https://example.com" "http://localhost:8080" \
  --all-tables --skip-columns=guid

# ⑤ transient／キャッシュクリア
docker compose run --rm wpcli wp transient delete --all
docker compose run --rm wpcli wp cache flush

# ⑥ ユーザーパスワードリセット（開発用）
docker compose run --rm wpcli wp user update admin --user_pass=admin

search-replaceで--skip-columns=guidを必ず指定。guidカラムはWordPress内部でユニーク識別子として使われ、URL形式ではあるものの置換すると既存リンクが壊れる仕様です。さらに--dry-runで先にプレビューすると安心。

本番データで開発する際の注意：ユーザーメール情報を持つ場合は個人情報保護の観点からwp db query "UPDATE wp_users SET user_email=CONCAT(ID, '@localhost')"等でマスキング推奨。本番のAPIキー・決済情報が含まれるDB表も削除／無効化しておくこと。

ローカルHTTPS対応：mkcertでTLS証明書

OAuth／Stripe／Cookie（SameSite=None）などを検証するにはHTTPSが必須。mkcertで信頼済み証明書を数秒で作れます。

mkcertセットアップ
# インストール
brew install mkcert            # macOS
choco install mkcert           # Windows
sudo apt install mkcert        # Ubuntu (snapやaptで)

# ローカルCAをインストール（初回のみ）
mkcert -install

# 証明書作成（wp.localhostなど用途に応じた名前）
mkcert -key-file ./certs/wp.key -cert-file ./certs/wp.crt \
  wp.localhost localhost 127.0.0.1
compose.yml（nginx + SSLで公開）
services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on: [wordpress]
    networks: [wp-net]
nginx.conf（HTTPS + WordPress Apache逆プロキシ）
server {
  listen 80;
  server_name wp.localhost;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  server_name wp.localhost;

  ssl_certificate     /etc/nginx/certs/wp.crt;
  ssl_certificate_key /etc/nginx/certs/wp.key;

  client_max_body_size 128M;

  location / {
    proxy_pass http://wordpress:80;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}
hosts に追加＋確認
# /etc/hosts（macOS/Linux） or C:\Windows\System32\drivers\etc\hosts
127.0.0.1  wp.localhost

# 起動後
open https://wp.localhost   # 鍵マーク付きでアクセス成功

複数WPを同時に起動：nginx-proxyパターン

案件が複数あるとポート衝突や設定が混乱。nginx-proxyが各プロジェクトのVIRTUAL_HOSTを見て自動ルーティングしてくれます。

proxy/compose.yml（共通プロキシ）
services:
  nginx-proxy:
    image: nginxproxy/nginx-proxy:latest
    ports: ["80:80", "443:443"]
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./certs:/etc/nginx/certs
    networks: [proxy-net]

networks:
  proxy-net:
    external: false
各プロジェクト側のcompose.yml
# projects/siteA/compose.yml
services:
  wordpress:
    image: wordpress:6.7-php8.3-apache
    environment:
      VIRTUAL_HOST: siteA.localhost
      VIRTUAL_PORT: 80
      # ... DB設定
    networks:
      - proxy-net
      - internal

  db:
    image: mariadb:11
    networks: [internal]

networks:
  proxy-net:
    external: true
    name: proxy_proxy-net
  internal:
起動と追加
# 1. 共通プロキシ起動（1回だけ）
docker compose -f proxy/compose.yml up -d

# 2. 各プロジェクトを追加
docker compose -f projects/siteA/compose.yml up -d
docker compose -f projects/siteB/compose.yml up -d

# /etc/hosts に追加
# 127.0.0.1 siteA.localhost siteB.localhost

# ブラウザ
# http://siteA.localhost
# http://siteB.localhost

mkcert＋acme-companionと組み合わせれば、VIRTUAL_HOST追加時に自動でSSL証明書も付与されます。案件5〜10個を並行管理するフリーランス／制作会社には鉄板構成。

セキュリティ強化：非root・secrets・env分離

開発環境でもセキュリティ習慣を守ると、そのままステージング／本番にデプロイしやすくなります。

secrets／env_fileで機密情報を分離

compose.ymlとenv分離
# .env（.gitignore対象）
DB_ROOT_PASSWORD=supersecret
WP_DB_PASSWORD=wpsecret

# compose.yml
services:
  wordpress:
    environment:
      WORDPRESS_DB_PASSWORD: ${WP_DB_PASSWORD}
    env_file:
      - .env                # 別env_fileでまとめることも可

  db:
    environment:
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root
      MARIADB_PASSWORD: ${WP_DB_PASSWORD}
    secrets:
      - db_root

secrets:
  db_root:
    file: ./secrets/db_root.txt
.gitignore例
.env
.env.local
secrets/
wp-content/uploads/
wp-content/cache/
wp-content/object-cache.php
wp-content/advanced-cache.php

非rootユーザーで動かす

userとfile_permission
services:
  wordpress:
    build: ./docker/wordpress
    user: "33:33"      # www-data UID/GID
    # マウントしたディレクトリの所有者をホスト側で合わせる
    # sudo chown -R 33:33 ./wp-content

非root化するとホスト側のwp-content所有者と合わせる必要があり、ローカル開発者の編集権限に影響します。macOS／Windows（Docker Desktop）は自動調整されるため気にしなくてよいが、Linux直接ではchownまたはumask調整が必要。開発者単独ならrootのままで運用し、本番Dockerfileで非root化するのが現実的。

CI/CD統合：GitHub Actionsでイメージ自動ビルド

カスタムDockerfileを使っているなら、GitHub Actionsでイメージをビルド→GHCR（GitHub Container Registry）にpushし、本番サーバーでdocker compose pullする運用が堅牢。

.github/workflows/docker-build.yml
name: Build WP Docker Image

on:
  push:
    branches: [main]
    tags: ["v*.*.*"]
    paths:
      - "docker/wordpress/**"
      - ".github/workflows/docker-build.yml"

permissions:
  contents: read
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: docker/setup-buildx-action@v3

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/metadata-action@v5
        id: meta
        with:
          images: ghcr.io/${{ github.repository }}/wordpress
          tags: |
            type=ref,event=branch
            type=semver,pattern={{version}}
            type=sha

      - uses: docker/build-push-action@v6
        with:
          context: ./docker/wordpress
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

タグ付きリリースで自動的にwordpress:v1.2.3のようなイメージがGHCRに並びます。本番サーバーのcompose.ymlでimage: ghcr.io/org/repo/wordpress:v1.2.3と参照すれば、ロールバックや段階デプロイも容易。GitHub Actions 詳細は【GitHub】Actions完全ガイド参照。

よくあるトラブルと対処

①”Error establishing database connection”

対処：healthcheck＋depends_on
# DBが完全起動する前にwordpressが先に接続してエラー

# 解決：healthcheckで起動完了を保証
services:
  wordpress:
    depends_on:
      db:
        condition: service_healthy   # ← DBの準備完了待ち

  db:
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 5s
      retries: 10

②permalinks が動かない（404）

Apache image + パーマリンク変更後404はmod_rewriteの有効化と.htaccess設定が必要。公式イメージはデフォルトでAllowOverride Allとmod_rewrite済みですが、nginxベースの場合は手動で書き換えルールをlocation /にtry_files $uri $uri/ /index.php?$args;追加。

③アップロードできない（413 Request Entity Too Large）

uploads.ini＋nginx両方を調整
# PHP側（uploads.ini）
upload_max_filesize = 128M
post_max_size = 128M

# nginx経由ならさらに
# nginx.conf: client_max_body_size 128M;

④wp-contentへの書き込み権限エラー

所有者とumaskの調整
# ホスト側で
sudo chown -R 33:33 wp-content   # www-data

# または開発中は全員書き込み可に
chmod -R 777 wp-content   # 本番NG・開発OK

⑤Docker Desktopが起動しない

Windowsで頻発する問題は別途詳しく解説しています：【保存版】Docker Desktopが「Docker Desktop stopped」で起動できない時の完全解決ガイド

よくある質問

QXAMPPとDockerどちらを選ぶべき？
A2026年時点ならDocker推奨。XAMPPは1台のPCで1バージョンの環境しか動かせず、複数案件／PHP切替／チーム共有が煩雑。Dockerはcompose.yml1つで環境を配布でき、PCの買い替え・新人オンボーディングが数分で完結します。XAMPPが楽なのは「最初の1回だけ」で、継続的開発では差が広がります。
QMariaDBとMySQLの違いは？
AどちらもMySQL互換DBですが、MariaDBはOSSとして活発に開発され、デフォルト設定もWordPress向きです。公式WordPressイメージとの組み合わせ実績も十分。MySQL 5.7はEOLが近く、8.x以降はWordPressとの相性で細かい注意点がある（認証プラグインなど）ため、新規構築はMariaDB 11推奨です。
QDocker Desktop以外の選択肢は？
A商用利用の有料化でDocker DesktopからRancher Desktop／OrbStack（macOS）／Podman Desktopに乗り換えるケースも増えています。Mac上でのパフォーマンスはOrbStackが際立って高速。Linuxはapt install docker.io docker-compose-v2等でネイティブ動作が最速。
Q./wp-data:/var/www/htmlでマウントするのは何がダメ？
AWordPressコア全体（wp-admin／wp-includes／index.php等）までホスト側に展開されるため、①ディスク使用量が無駄、②コア更新時のコンフリクト、③Git管理で余計なコミットが増える、等の問題があります。wp-content配下のみマウントすれば編集対象だけがホストに見える健全な構成になります。
Q本番データをローカルで使いたい
ADB：mysqldump→wp search-replaceでURL置換。ファイル：rsyncでuploadsを同期。最重要は置換時に--skip-columns=guidを必ず指定すること。本記事「本番サイトのDB・ファイルを安全にローカル取り込み」セクション参照。
Qメモリ使用量が大きい、軽量化できる？
A①mariadb:11ではなくmariadb:11-ltsやAlpine版を検討、②不要なサービス（phpmyadmin／mailpit／redis）をprofilesで条件起動、③Docker DesktopのResource設定でメモリ上限を下げる、④PHP-FPMのpm.max_childrenを減らす。必要なときだけdocker compose --profile full upのように使い分けると快適です。
QWP-CLIをいちいちdocker compose run打つのが面倒
Aシェルエイリアスを設定すると楽になります：alias wp="docker compose run --rm wpcli wp"を~/.bashrcに追加。これで通常通りwp plugin list等が使え、自動化スクリプトも本番とローカルで同じコマンドにできます。
Q本番サーバーでもこのcompose.ymlを使える？
A基本構造は流用できますが、本番は①HTTPS（Let’s Encrypt）、②非rootユーザー、③secretsを.envではなくマネージドsecrets／Swarm secrets、④named volumeで性能最適化、⑤healthcheck＋restart: alwaysなど加えます。開発用compose.ymlと本番用compose.prod.ymlを分けてdocker compose -f compose.yml -f compose.prod.ymlで重ねる運用が一般的。
Q開発中ログを見たい
Adocker compose logs -f wordpressでApacheログ、docker compose logs -f dbでDBログ追跡。WordPressのPHPエラーはWORDPRESS_DEBUG: "true"＋WP_DEBUG_LOGでwp-content/debug.logに蓄積されます。tail -f wp-content/debug.logで開発中見ると効率的。

関連記事

まとめ

  • 2026年の標準構成：wordpress:6.7-php8.3-apache＋mariadb:11（version:キーは不要）
  • マウント戦略：wp-content配下のみbind mount／DBはnamed volume
  • wp-cliをprofiles: [cli]で常駐させずオンデマンド起動
  • scripts/setup.shで初期化→プラグイン導入→Redis有効化まで自動化
  • Xdebug：カスタムDockerfile＋VS Code launch.jsonでステップ実行
  • mailpit：SMTP→Web UIでメール確認、Contact Form 7検証が安全
  • Redis object cache：wp redis enableでDB問い合わせ削減
  • 本番DB取り込みはwp search-replace --skip-columns=guidでURL置換
  • ローカルHTTPS：mkcert＋nginxリバプロ／wp.localhost等
  • 複数WP同時起動：nginx-proxyでVIRTUAL_HOST自動ルーティング
  • セキュリティ：.env＋secrets＋.gitignore徹底
  • CI/CD：GitHub ActionsでイメージをGHCRにpush、本番はpullするだけ
  • トラブル：healthcheck活用、permalinks mod_rewrite、413はPHP＋nginx両方調整

WordPress × Dockerは「公式イメージをupするだけ」の入門から本番運用相当の自動化・セキュリティ・CI/CD統合まで幅広く応用できる組み合わせです。本記事の完全版compose.ymlとscripts/setup.shをベースにすれば、新規案件でも数分でチーム全員が同じ環境で開発を始められます。基礎知識の補完はvolume・bind mount vs volume・Compose複数コンテナ連携を、自動デプロイ連携はGitHub Actionsを併せてご参照ください。