こんにちは、パレイド思想部の橘です。
前回は、Docker staging と Cloudflare Tunnel で、本番に触らずに Claude Design と往復できる場所を作りました。手元の写しで好きなだけ試して、まとまったら本番へ——ここまでは順当な流れに見えます。
次の問題は、その「本番へ」のところで、何をどう持っていけば本番稼働させたまま新テーマへ移れるのか、という話になります。
本記事は LLM による自動執筆パイプラインで生成されました。現在は人間が補助していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
staging 環境で十分に詰めても、本番に乗せた瞬間にしか出ない「ずれ」は必ずあります。読者が読んでいる場所を、一日かけて止めながら直していく、というのはやりたくない。新テーマを試しながら、いつでも切り戻しができる手段を、別に用意しておきたい、というのが第 4 回の出発点です。
本番を動かしたまま、テーマで切り替える
WordPress には、もともとそれに近い仕組みが入っています。管理画面の「外観 → テーマ」で別のテーマを選ぶと、媒体の見た目と挙動が一段乗り換わる。テーマを「切り替える」操作は、ファイルを上書きするのとは違って、いつでも元のテーマに戻せるという性質を持っています。
新テーマ (pareido) を、Cocoon を動かしたまま別パッケージとして本番にアップロードしておくことができます。アップロードしただけでは有効化されないので、読者から見える媒体は Cocoon のままです。準備が整った段階で「テーマを切り替える」を押せば、その瞬間だけ媒体が乗り換わる。何かおかしければ、もう一度管理画面で Cocoon を選び直せば、すぐに元へ戻る。テーマ切替そのものが、ロールバック手段になる、という構造です。
連載 #1 で「不可逆操作を不可逆にしない」と書いた手すりの、テーマ側への適用にあたります。テーマファイルを直接上書きすれば不可逆ですが、テーマパッケージを別物として置いておけば、有効化と無効化を行き来できる。読者が読んでいる時間を止めずに、新テーマの最後の調整を本番上で続けられる、という余白がここで生まれます。連載 #3 で staging を写しとして手元に置いた発想を、本番側にも持ち込んだ形と言えるかもしれません。
自前テーマ作成も、後方互換も、AI に任せられる
ただ、テーマを別パッケージとして用意する、と書くのは簡単ですが、自前テーマを一から書くのは、かつてはかなり重い仕事でした。テンプレート階層、ループ、ウィジェット、フック——WordPress のテーマ開発には、独自の作法がそこそこあります。Cocoon を親テーマにしておけば多くは継承できますが、その継承自体を捨てて pareido テーマで置き換えたいなら、必要なテンプレートを自分で書き直すことになります。
ただ現在は、WordPressのテーマ作成は AI に任せられる範囲に入ってきました。Claude Design が出した handoff bundle (HTML/CSS と意図メモ) を Claude Code に渡して、「これを WordPress テーマとして実装してほしい」と指示すると、index.php single.php archive.php functions.php といった一式が、テンプレート階層の作法に沿った形で起きてきます。連載 #3 で Docker や Cloudflare の細部を Claude Code に引き受けてもらったのと、同じ筋の任せ方です。SSH 設定や wp-cliなどの使用を許可すれば、セットアップやバックアップまでエージェントで実行可能です。
もう一つ重い仕事が、Cocoon 由来の独自ショートコードや独自設定値の互換機能を作ることでした。pareido.jp の記事本文には、Cocoon が提供する のようなショートコードが埋め込まれていますし、wp_options には Cocoon が前提とする設定値が積まれています。新テーマに切り替えた瞬間に、これらが解釈されないと記事の見た目が壊れる。新テーマ側に、Cocoon のショートコードを最低限受け止める互換機能 (shim) を組み込んでおく必要があります。
互換機能を手で書こうとすると、まず「どのショートコードが、どの引数パターンで、何本の記事に使われているか」を全文走査するところから始まります。これも Claude Code に任せられる仕事の側に入ってきました。wp_posts を一通り読んで、使われているショートコード名と引数の組み合わせを一覧化し、それぞれを pareido テーマ内の関数として受け止める形まで、AI が組んでくれます。昔は調べることそのものが重かった作業が、DB を読みに行ける AI のおかげで、調査と実装が地続きになりました。
自前テーマを書く決断のコストが下がった分、託す前に整えるべきものの構成が変わってきています。テーマファイル一式を書くこと自体ではなく、何を互換させて、何は捨てるかのほうが、こちら側に残る判断になりました。
（参考）公開していいかは、ちゃんと調べる
ここまでで、技術的にはほぼ AI に任せられる、という景色が見えてきます。今回は自サイトの内部利用のためのテーマ開発ですが、作り込んだテーマを公開したいという場合もあるでしょう。ただ、AI が組めることと、それをそのまま公開していいことは別の話です。
例えば、今回ベースとなっている Cocoon は GPL 系のライセンスで公開されていて、派生物を作ることは許容されています。もし完全な互換テーマを外部に配布する、となると、線がだいぶ繊細になります。内部だけで使う互換機能なのか、互換テーマとして第三者に配るのか、で話の重さが変わる。互換機能を組み込んだテーマ全体を GitHub などで公開するなら、Cocoon に限らず、本体のライセンス本文を精読して、派生としてどう振る舞うべきかを確かめておくのが重要です。心配があれば、原作者にひと言相談しておくのも、たぶん遠回りではありません。
完全コピーではなく、互換性を確保して中身は独自実装、という形でも、安心しきれない領域は残ります。AI への指示の出し方は注意が必要で、曖昧な指示だとライセンス条件を確認せず丸ごとコピペをする場合もありますし、指示をしてもコピペが含まれる場合もあるため、ダブルチェックが欠かせません。AI が技術的に組めることと、それをそのまま使って良いか別——開発は AI に任せられますが、人間が確かめるべきものの比重が、法的・社会的な側へ移ってきています。
連載 #3 で「触らないと分からないことを、触らないまま媒体を前に進められる」と書いた感触の、別側面にあたります。前進そのものは AI が引き取ってくれる。託す範囲が広がった分、確かめる側の手間は別の場所に移っただけで、総量が消えるわけではありません。互換機能の実装はおそらく一晩でできてしまうので、その前後にライセンスを読み直す半日のほうが、いまの自分にとっては本筋の作業になりそうです。
次回に向けて
テーマパッケージを別物として並走させる構えが見えてくると、次に来るのは「何をどの粒度で本番に上げるか」という話です。テーマ全体を上げる、テンプレートだけを上げる、functions.php の一部だけを上げる、ACF のフィールド定義だけを上げる——切り替えの単位を絞るほど、戻すべき範囲も狭くなります。
今回の「テーマだけを切り替える」が、次回の「テーマだけを上げる」の運用側の延長になりそうです。AI に託せる範囲は、上げる粒度を絞った分だけ広がる——そういう構造を、次回は deploy_theme.sh の dry-run デフォルトという設計判断のあたりから書いていきます。