こんにちは、パレイド思想部の橘です。
前回は、Claude Design に pareido.jp を「見せる」工程を書きました。四案を比較して採用するところまで進み、サイトの印象は AI と共有できた状態です。
問題はここから先で、選んだデザインを WordPress に乗せながら、Claude Design と何度も往復して細部を詰めたい。けれど本番サイトは運用中のままで、ここを叩き台にするというのは現実的ではありません。
本記事は LLM による自動執筆パイプラインで生成されました。現在は人間が補助していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
本番を本番のまま稼働させながら、AI と往復する
採用した Claude Design の案は、JSX(JavaScript XML) で作られたデザインサンプルで、それ自体が完成品ではありません。現状、Cocoon を親テーマにした pareido.jp の実装に移すには、ショートコードの置き換え、ACF フィールドの追加、配色とタイポの再調整など、細かな作業がいくつも残ります。しかも、ひとつ手を入れるたびに、もう一度 Claude Design に見せて意見をもらい、また直す——という往復が必要になる。やってみないと、自分の選んだ像が WordPress 上で本当に機能するかどうかは、たぶん分かりません。
本番運用と並行での記事データ喪失のリスクも気になります。オプションを触れば不可逆、テーマを差し替えれば Customizer の設定値も巻き込まれ、戻すのに手間がかかる。読者が読んでいるあいだに、目の前で実験を繰り返したくない、という感覚もあります。
連載 #1 で「不可逆操作を不可逆にしない」と書きました。あれは攻める側の論理にも反転します。戻せる状態が手元にあって、はじめて勢いよく相談できる。本番をそのままにして、本番の写しを別に立てておく。手を入れるのは写しの側にして、本番は読者のために静かに動かしておく。いわゆる staging 環境が必要だ、と素直に思いました。
Docker + WordPress で staging を、AI に組んでもらう
写しの作り方そのものは、技術的にはそれほど凝っていません。本番のサーバーから public_html/ を rsync で引いて、MySQL は mysqldump でまるごと取り、ローカルの Docker で立てた WordPress に流し込む。REST API 越しに整った形で写す道もありましたが、Cocoon の独自設定や .htaccess まで含めて運びたかったので、素朴な「まるごと写す」側に倒しました。
ただ、その素朴な手順の中身を、わたしは全部わかっているわけではありません。匿名 volume と bind mount のどちらにすれば手元から触りやすいのか、wp search-replace でどの範囲を置換すれば本番への踏み外しが防げるのか、wp-cli を Docker コンテナ越しに動かすときの作法はどうか——一つ一つは資料を読めば分かりますが、整った形で手元に揃えるまでには、それなりの時間が要ります。それでも、staging は今ほしい。
結局、staging環境の構築と同期は、Claude Code に丸投げしました。docker-compose の細部や bind mount のパス設計は、AI 側が引き受けてくれた領域です。触らないと分からないことを、触らないまま媒体を前に進められる。これは連載 #1 で書いた「託す側の足場を整える」の、別の側面のように感じます。
Cloudflare で staging を Claude Design に見せる
ここまでで、手元に触れる写しは整いました。ただ、もう一つ問題があります。Claude Design は URL でしか媒体を見られないのです。http://localhost:8080 はわたしの机の上にしか存在しない URL で、Claude Design からは届きません。staging が「自分で試行錯誤する場所」のままだと、結局 Claude Design との往復は本番ベースに戻ってしまう。
ここで使ったのが Cloudflare Tunnel (cloudflared) です。staging に一時的な公開 URL を付けて、Claude Design からアクセスできるようにする。終わったら畳めば URL ごと消える、という性質も、写しを外に出す心理的なハードルを下げてくれました。
結論として、ここも Claude Code に丸投げしました。Cloudflare の細部も、わたしは把握しきれていません。tunnel の認証情報をどう持つか、DNS をどう向けるか、staging 側の WordPress の siteurl をどう扱えば公開 URL でちゃんと描画されるか——調べれば分かることでも、自分で組み上げるには時間がかかります。これも Claude Code に任せて、コマンドと設定ファイルを整えてもらいました。Docker のときと同じ構図で、staging の周りの足場が、わたしの手の届かない部分ごと一段増えた、ということです。
公開 URL が手元にあると、staging の役割が静かに変わります。これまでは「自分でいじり倒す場所」だったものが、「Claude Design に見せて意見をもらう場所」を兼ねはじめる。手を入れて、見せて、コメントをもらって、また直す——その往復が、本番に触らずに成立する。staging を Claude Design 側にも開いたことで、相談相手が触れる場所と、わたしが触れる場所が、はじめて同じ画面の上で重なりました。
次回に向けて
staging が立ち、Cloudflare で外にも見せられるようになったところで、リニューアルの作業領域は一応そろいました。staging があれば壊しても直せる、という前提に、わたしはここまでずっと寄りかかってきました。
ただこの前提は、「本番からもう一度 clone すれば戻せる」という暗黙の条件の上に乗っています。本番側そのものが壊れたら、その瞬間に砂場の意味も変わる。次回は、その手前に置いておくべき多層の保険——hosting 側の日次バックアップ、staging の snapshot、git の履歴——と、ロールバックを独立した儀式として演習する話を書きます。戻せることを、机上ではなく身体に刻む工程を、思想部の側から観察するつもりです。