← ブログ一覧に戻る

WordPress Playgroundを実際に触ってみた話（wp-env比較つき）

2026.07.28

フリーランスでWeb制作をしている矢野です。

前回の記事で、wp-env（Docker）を使ったWordPressのローカル開発環境構 築について書きました。

今回はその続編として、ブラウザだけでWordPressを動かせるという「WordP ress Playground」を実際に触ってみた話です。

Playgroundとは何か

WordPress Playgroundは、PHPをWebAssembly（WASM）にコンパイルし、ブラ ウザの中だけでWordPressを丸ごと動かせるツールです。

サーバーはもちろん、Dockerも必要ありません。

wp-envのようにDocker Desktopの起動を待つ必要がなく、コマンド一発でWordPressの管理画面が触れ る、という触れ込みに惹かれて検証してみました。

npx一発で動いた話

まずはCLIツールの@wp-playground/cliを試しました。

前提条件はNode.js 20.18以上だけで、個別インストールも不要です。

npx
  @wp-playground/cli@latest server --port=9401

このコマンド1つで、WordPressのコアをダウンロードしてきて、PHP 8.3・最新版のWordPressがその場で立ち上がります。

wp-envのように.wp-env.jsonを書いたり、Docker Desktopを起動して待ったりする手間は一切ありませんでした。

実測：初回130秒→2回目29秒

体感の軽さを数字で確認したかったので、起動時間を実際に計測しました。

初回起動(WordPress本体のダウンロードを含む)は約130秒でした。

一方、2回目以降の起動はダウンロード済みのファイルが使い回されるため 、約29秒まで短縮されます。

Docker Desktopの起動待ちそのものが発生しない分、体感としてもこの数字 以上に軽く感じました。

普段使っているwp-envは今回の検証時も別案件(おうちで、わんこと。)用に 稼働中だったので、作業中の環境を壊したくなく、公平な比較のための再計測 はあえて見送っています。

自作テーマをマウントして動かしてみた

ただ起動できるだけでは検証として不十分なので、実際に自作テーマをマウ ントして動かせるか試しました。

--mountオプションで、ホスト側のディレクトリをWordPress 内の任意のパスに割り当てられます。

npx
  @wp-playground/cli@latest server --port=9403 \
    --mount=/Users/yanoyuuki/Documents/jj-company/wanko-to-theme:/wordpre
  ss/wp-content/themes/wanko-to-theme \
    --login

このコマンドで、ポートフォリオ作品「おうちで、わんこと。」のテーマデ ィレクトリをそのままマウントしてみたところ、テーマファイルは200で配信さ れ、管理画面のテーマ一覧にも「wanko-to-theme」として正しく認識されまし た。

wp-envと同じ感覚で、手元のテーマディレクトリをそのまま検証環境に持ち 込めると分かりました。

ハマったポイント①:–loginオプションの302リ ダイレクト

--loginオプションを付けると自動ログインしてくれるのです が、初回アクセス時にステータスコード302が返ってきて、少し戸惑いました。 

curl -I
  http://127.0.0.1:9403/
  # HTTP/1.1 302 Found
  # location: /

調べてみると、自動ログインの処理自体がCookieをセットしたうえで同じUR Lへリダイレクトする仕組みになっているだけで、エラーではありませんでした 。

ブラウザで開く分には自動的にリダイレクトされるので気にする必要はない のですが、curlなどでヘルスチェック的に叩く場合は302も正常系として扱う必 要がある、という点は覚えておきたいポイントです。

ハマったポイント②:–skip-browserはstartコ マンド専用

もう1つ、serverコマンドにブラウザを自動起動させない–skip-browserオプションを渡したところ、エラーになりました。 　

BEFORE(うまくいかなかったコマンド)

npx
  @wp-playground/cli@latest server --skip-browser --port=9401
  # Unknown arguments: skip-browser, skipBrowser

AFTER

--skip-browserは、プロジェクトの種類を自動判定してくれ る簡易版のstartコマンド専用のオプションで、低レベルなserverコマンドには存在しないオプションでした。

serverコマンドはもともとブラウザを自動起動しない仕様な ので、このオプション自体が不要だったというオチです。

startとserverでオプション体系が違う点は、 公式ドキュメントを読むだけでは気づきにくく、実際に手を動かしてよかった ポイントでした。

wp-envとの使い分け

ここまで検証してみて、Playgroundとwp-envは競合するというより役割が違 うツールだと感じました。

Playgroundは、Docker Desktopの起動待ちがなく、npx一発でPHP・WordPressのバージョ ンを切り替えながらサクッと検証できる手軽さが強みです。

ブラウザで開く分には自動的にリダイレクトされるので気にする必要はない のですが、curlなどでヘルスチェック的に叩く場合は302も正常系として扱う必 要がある、という点は覚えておきたいポイントです。

ハマったポイント②:–skip-browserはstartコ マンド専用

もう1つ、serverコマンドにブラウザを自動起動させない–skip-browserオプションを渡したところ、エラーになりました。

BEFORE(うまくいかなかったコマンド)

npx
  @wp-playground/cli@latest server --skip-browser --port=9401
  # Unknown arguments: skip-browser, skipBrowser

AFTER

--skip-browserは、プロジェクトの種類を自動判定してくれ る簡易版のstartコマンド専用のオプションで、低レベルなserverコマンドには存在しないオプションでした。

serverコマンドはもともとブラウザを自動起動しない仕様な ので、このオプション自体が不要だったというオチです。

startとserverでオプション体系が違う点は、 公式ドキュメントを読むだけでは気づきにくく、実際に手を動かしてよかった ポイントでした。

wp-envとの使い分け

ここまで検証してみて、Playgroundとwp-envは競合するというより役割が違 うツールだと感じました。

Playgroundは、Docker Desktopの起動待ちがなく、npx一発でPHP・WordPressのバージョ ンを切り替えながらサクッと検証できる手軽さが強みです。

一方でwp-envは、MySQLを使った本番相当の構成で、腰を据えてテーマ・プ ラグインを開発するのに向いています。

「ちょっとこの挙動だけ確認したい」ときはPlaygroundを、「本格的にテー マを作り込む」ときはwp-envを、というのが今のところの使い分けの結論です 。

まとめ

今回は、WordPress Playgroundを実際にCLIで動かし、起動時間の実測や自作テーマのマウント、ハ マったポイントまで含めて検証した話を書きました。

Docker不要で手軽に試せる分、日々のちょっとした検証や動作確認にはかな り相性が良いツールだと感じています。

wp-envと使い分けながら、これからも開発環境の選択肢として活用していく つもりです。