環境構築って、だるくないですか？
WordPressをローカルで動かしたいだけなのに、MySQLとかdockerとか、ついでにGutenbergブロックのビルド環境とか、やたら手が多い。
そこで今回は、OpenAI Codexを使って、環境構築を丸投げしてみた話をします。
自分ではほぼ何もせず、「こうして」と言うだけで、WordPressのブロック開発までできる環境を作る――そんな無責任な試みです。
Codexってなに？誰が使えるの？
ここはぶ厚めに記事を前書いたので、良かったら下記で確認できます。
Codexで使う環境変数とシークレット
CodexのDockerコンテナ内で利用する環境変数と、セットアップ中にだけ使えるシークレット値は以下の通りです。
環境変数（コンテナ起動中に有効）
| 変数名 | 値 |
|---|---|
| WORDPRESS_DB_USER | user |
| WORDPRESS_DB_HOST | localhost |
| WORDPRESS_DB_NAME | wordpress |
| LOG_LEVEL | debug |
シークレット（セットアップスクリプト中のみ有効）
| 変数名 | 値 |
|---|---|
| WORDPRESS_DB_PASSWORD | admin |
セットアップスクリプト（Codex用）
Codexではセットアップ時にしかインターネットが使えません。なので、初期セットアップのタイミングで以下を済ませておきます：
.envの自動生成npm installplugins/*以下の各パッケージの依存解決- テスト系ツールの導入（eslint, prettier, jest）
- WP-CLIのダウンロード・インストール（PHPがあれば）
#!/usr/bin/env bash
set -euo pipefail
# .envがなければ自動生成（Codexの環境変数・Secretsを活用）
[ -f .env ] || cat <<EOF > .env
WORDPRESS_DB_PASSWORD=${WORDPRESS_DB_PASSWORD:-changeme}
WORDPRESS_DB_USER=${WORDPRESS_DB_USER:-wp}
WORDPRESS_DB_NAME=${WORDPRESS_DB_NAME:-wordpress}
WORDPRESS_DB_HOST=${WORDPRESS_DB_HOST:-db}
API_KEY=${API_KEY:-}
EOF
# package.jsonがあればnpm install
[ -f package.json ] && npm install
# サブディレクトリ（plugins/以下など）でpackage.jsonがあればnpm install
for dir in plugins/*/ ; do
if [ -f "$dir/package.json" ]; then
(cd "$dir" && npm install)
fi
done
# Linterやテストツール
npm install --save-dev eslint prettier jest || true
# WP-CLI（phpが入ってる場合のみ）をインストール
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp || true
いざ開発！（全部AI）
手は一切動かしません（大事なポリシー）。
以下のプロンプトをCodexに与えました：
このリポジトリに、WordPressのGutenbergブロック開発・検証ができるローカル環境一式を構築してください。
要件：
- docker-compose.yml で WordPress本体・MySQL・WP-CLIコンテナを用意
- ブロック開発用サンプルプラグイン（例：plugins/my-custom-block/）を @wordpress/create-block 相当で生成
- package.json、ビルド・テスト用npmスクリプト、README.md にセットアップ手順を明記
- WP-CLIからWordPressの操作（プラグイン有効化・DB初期化等）がすぐ使えるようにして
- 必要に応じてテーマや開発用設定も含めてOK
- すべてのセットアップが「docker-compose up」「npm install」「npm run build」で完結し、手元で即ブロックの動作検証・WP操作・開発ができるようにしてください。
結果として、Codexが以下のPRを一撃で生成してくれました：
👉 https://github.com/wasipo/wp-lab/pull/1
何度かプロンプト修正してできたもの
初期出力を元に、数回以下のサイクルを繰り返しました：
- コード生成（Codex）
- 動作確認（自分）
- 問題点をGPTにプロンプトで伝えてCodexに渡すプロンプトを受け取る
- ３でもらったプロンプトを再投入
結果として、最終的に以下のような状態まで持っていけました：
👉 https://github.com/wasipo/wp-lab
感想
ChatGPTオンリーでやったことないスマホの環境構築作って（ReactNative/NestJs）カオスになった覚えがあります。
現在のインストールの状況を毎度毎度伝えるのがかなりだるかった覚えがありますが、Codexだともうディレクトリ構造知ってるのでその辺の共有は不要なのでやりやすかったです。
ただ、Codexが実行できない範囲のエラーはCodexが検知出来ない部分なので、実行できない範囲でエラーが起きた場合は、命令もかなり詳しめに入力する必要があります。
今回の場合だと、Dockerイメージの中でDockerイメージをPullすることができないので、Codexが作成したコマンドを自分で実行できず、エラーがわからないため、
単にエラーメッセージを共有するだけだと、上手いこと修正ができませんでした。
そのため、指示も下記のようにすることで、意図通りの改修をしてもらえました。
Codexくん、READMEでは `docker-compose up -d` の時点で WordPress が自動的にインストールされる前提ですが、実際に試すと `wp-config.php` に `DB_HOST='mysql'` が設定されてしまい、`wp-cli` 経由のコマンド（例: `core install`）が `Error establishing a database connection.` で失敗します。
Docker Compose の `wordpress` サービスには `WORDPRESS_DB_HOST=db:3306` を設定しているので、本来は `db` が正しい接続先のはずです。
しかし `wp-config.php` に `mysql` が自動設定されることで、CLI系コンテナが `db` を解決できずに死んでいます。
これは WordPress イメージの entrypoint が環境変数を正しく受け取れていない場合に、`DB_HOST=mysql` をデフォルトで書いてしまう仕様に起因しています。
この構成が安定して動作するようにするために、以下の対応が必要ではないでしょうか？
1. `setup` および `wpcli` サービスに、明示的に DB 接続用の環境変数を追加する
2. README に `wp-config.php` が生成されるタイミングと、環境変数が渡らなかった場合の挙動を補足する
このままだと、ユーザーが `setup` を実行しても CLI からの操作が失敗する可能性が高いです。まだまだ自分も初心者ですが、他にもなんか作りながら慣れていきたいと思います。
FAQ
-
Codex って結局なに？ ChatGPT とどう違うの？
-
Codex は O3モデルを基盤とした新モデル「codex-1」が搭載されてます。自然言語で「docker-compose.yml を作って WordPress + MySQL を動かして」と頼むと、GitHub PR まで丸ごと出してくれます。
-
日本語のプロンプトで大丈夫？
-
問題なし。日本語だけでも今回やれました。
-
Codexは無料で使えるの？
-
使えません。現状プロプランのみです。
-
テスト・Linter は最初から入る？
-
セットアップスクリプトで入力する必要があります。
-
手動でやることは本当にない？
-
今回は自分で一切プログラミングをしませんでした。Codexに渡すプロンプトをChatGPTと考える必要がたまにあると感じてます。
コメントを残す