Zennへの投稿記事
経緯
長らくDockerでWordPress単体運用していた自社サイトですが、正直「オリジナルデザインにしたい」「表示速度がイマイチ」という悩みをずっと抱えていました。
一番悩んだのはWPを完全に捨てるかどうかでした。ブログ入稿の使い勝手は手放したくないので、Headless化を含めたフル移行はオーバーエンジニアリングだと判断し、「メインは Astro、ブログだけ既存WPを /blog に残す」というハイブリッド構成に落ち着きました。
実装方針が決まったあとは、いきなりコードを書かせず、まず Claude チャットで壁打ちしてページ構成・デザインの方向性を固め、それを指示書（REQUIREMENTS.md）に落とし込んでから Claude Code に渡す、という2段構えにしました。行き当たりばったりで進めるより手戻りが圧倒的に少なく、Teamプラン1アカウント・当日上限の約70%で1日でリニューアルが完了したので、そのプロセスを記録として残したいと思い記事にしました。
記事には書いていないこと
フロントエンドの微調整はどうしてもトークン消費が激しくなるので、会話が長くなってきたタイミングで /compact を打つか、素直にセッションを切り替えるかの判断に何度か迷いました。目安としては「同じCSSの微調整で3往復以上している」と感じたら切り替えどきです。
Astro側とWP側のスタイル（フォント・余白・カラー）を完全に統一しようとすると、Astroのビルド設定とWPテーマの両方を毎回横断してコンテキストに読ませる必要が出てくるため、ここは最初から「完全一致」ではなく「トンマナが揃っていればOK」くらいの緩さで指示書に書いておくと、トークン消費を抑えられます。
もう一つ記事には書きませんでしたが、今回初めてWPの中身をきちんと触ってみて、フックやテーマ階層の作り込みは「よくこれを考えたな」と素直に感心しました。長年愛用されているだけの理由があります。ただその反面、同じ見た目の変更をするにも「テーマ側で対応するべきか、プラグインで対応するべきか、functions.phpに書くべきか」の選択肢が多く、正解が一つに定まらない面倒さも同時に感じました。スクラッチ開発は自由度が高い分すべて自分で決められますが、WPは自由度が高いがゆえに「決め方」自体にも一手間かかる、という違いを肌で感じられたのは今回の収穫でした。