hokupoid は、技術発信の実験場として作った、自分にとって初めてのスクラッチのブログ環境だ。
AI との共同作業により、まず公開できるところまで来た。
GPT-5.5 Pro、Claude Design、Codex で役割を分けて進めることで、自分の中では満足できる仕上がりに見えている。今のところは。
GPT-5.5 Pro は設計を広げ、Claude Design は見た目の制約を作り、Codex はそれを実装単位へ分解する。GenUI は、記事の中で新しい表現を試すための領域として置いた。
GPT-5.5 Pro は設計を広げる場所
最初に必要だったのは、コードではなく大きな設計だった。
ブログの方向性、書く内容、AI支援の制作フローをどこまで含めるのか。Cloudflare Workers Static Assets、Astro、Bun、Svelte、GenUI、LLM-readable exports をどういう順番で扱うのか。
この段階では、細かいファイル構成よりも、実験したいことに主眼を置いた。
GPT-5.5 Pro は、そのための相手として使った。ブログを単なる記事置き場ではなく、AI支援開発と技術発信の実験場にする。その方向性を先に作る。
ただし、大きな設計はそのままでは実装しづらい。
設計書として出力した design.md には、architecture、article workflow、Cloudflare delivery、GenUI、LLM-readable exports などが入った。全体像は見えるが、次の作業単位までは見えにくい。
大きな設計は必要だが、大きな設計だけでは次の作業単位にならない。
Claude Design は手触りを決める場所
次に必要だったのは、一番わくわくする要素でもある見た目の部分だった。
hokupoid は、開発者の作業場らしさを出したかった。
そこで Claude Design で、紙面らしさとターミナルらしさを混ぜた方向性を詰めた。
淡い桃色の紙面、細い罫線、本文はセリフ体、UI はモノスペース寄り。ターミナルの雰囲気は借りるが、偽物のターミナル画面にはしない。
正直、デザインの知識にはだいぶ疎いので、GPT-5.5 Pro と相談して Claude Design に渡すテキストを作成した。
GPT-5.5 Pro が作ったテキストが大量だったとはいえ、Claude Pro プランではたった 3 回の会話で週のリミットに達してしまった。サイトまるごとのデザインを出してもらっているので、制限に当たるのも自然ではある。
ただ、その分、先に Claude Design でデザインシステムとしての制約を出しておけたのはよかった。後から迷う量が減るので、これはかなりありがたかった。
デザインシステムを design_system/ に配置し、design.md と関心事を分けることを AGENTS.md に記述した。
Codex は設計を実装単位へ分解する場所
GPT-5.5 Pro で設計を広げ、Claude Design で見た目を固めても、それだけでは開発に取り掛かれなかった。
両方の設計書が、重たすぎてそれだけで満足しそうになってしまうのが怖いところだった。
そこで Codex に、設計とデザインを実装できる単位へ分解してもらってから、実装を行うこととした。
大きな design.md を Phase plan と ADR に分ける。Phase plan は「いつ何を実装するか」を扱う。ADR は「なぜその判断を採ったか」と「今後何を避けるか」を扱う。
この分解は、人間のためだけではない。実装する AI も迷わないためのインターフェイスでもある。
たとえば docs/plans/README.md を見れば、Phase 0 から Phase 5 までの流れと完了状態がわかる。docs/adr/ を見れば、Phase 分割の理由、見た目で優先する判断、初期リリースでは延期した機能とその理由が残っている。
重要だったのは、AI を使う場所と、判断を残す場所を分けることだった。
GenUI は記事そのものを実験場にするための要素
hokupoid で試したいことのひとつが、記事内の Generative UI だ。
今回は GenUI の実装詳細には踏み込まないでおく。
ここで書いておきたいのは、GenUI を「AI が自由に UI コードを書く場所」として扱わなかったことだけだ。
記事の中にリッチな UI を入れたい。でも、HTML、CSS、JavaScript、Svelte コンポーネントをその場で自由生成させると、安全性を保ちにくくなる。
そのため hokupoid では、検証済み JSON spec と固定された Svelte catalog に閉じる方針にした。AI が触る面を広げるのではなく、触ってよい面を狭くして、記事の表現だけを少し広げる。
AI agent が読む入口も作る
人間向けの HTML だけでは、記事の構造や GenUI の意味を AI agent が辿りにくい。
そこで /llms.txt、記事ごとの Markdown export、GenUI manifest も用意した。これは、本文を複製して別管理するためではない。AI agent が公開記事と関連リソースを低コストで見つけられる入口を作るためのものだ。
この判断も、hokupoid の性格に合っている。
ブログは人間が読む場所であると同時に、将来の自分や AI agent が読み返す作業ログでもある。ならば、人間向けのページだけでなく、AI agent が読みやすい静的な入口も置いておく。
作らない判断も残す
前述の通り、一部の機能はすぐには入れなかった。
ページ検索は便利だが、実公開記事が少ない段階では、依存関係、index 生成、UI、運用の認知負荷のほうが先に増える。そこで、実公開記事が 10 本以上になるまでページ検索機能を延期する判断を ADR に残した。
これは小さい判断に見えるが、私には重要だった。
AI agent に実装を渡すと、「計画に書いてあるから今やる」と判断されることがある。だから、やらない条件も残す必要がある。
機能を足すことだけが設計ではない。いつまで足さないかを決めることも、継続するための設計になる。
何を観察したいのか
hokupoid は、まだ完成品ではない。
むしろ、完成品として閉じるより、AI支援開発と技術発信を継続的に観察する場所として開いておきたい。
GPT-5.5 Pro で設計を広げる。Claude Design で手触りを決める。Codex で Phase plan、ADR、実装、検証へ落とす。
一つの手段にこだわることも大切だが、組み合わせることで生まれるスピード感がある。ただ、AI分業は役割を分けるだけでは機能しない。そのスピードを確実な実装につなげるには、設計と実装を接続する橋渡しが必要になる。
それを実感できたのは、今回かなり大きかった。