約4ヶ月半のあいだ、私のサイトはTRANSMISSIONという装いをまとっていました。ダーク、シアン、アンバー、そして意図的にテクニカルな雰囲気のデザインです。
ネイビーがかった暗い背景。シアンのアクセント。ガラス調のパネル。これは意図してそう作ったものでした。私は広告業界に18年いました。そして40歳でコーディングを独学しました。サイトを訪れた人がブログ記事までスクロールし、ワードマークを通り過ぎ、開発者ツールのような美意識に気づいた瞬間に、「この人は越境してきたんだ」というシグナルが伝わってほしかったのです。
その役目は果たしてくれました。そして、終わりが来ました。
メモリアルデーの連休のあいだに、以前とはまるで違うリデザインをリリースしました。ライトモード。温かみのある紙のような背景。シアンではなくカーマインレッド。角丸のカードではなく細い罫線。右上には「Vol. 04 · Issue NN」の表示が見えます。Volumeは私がbuild in publicを始めてからの年数、Issueは現在のISOウィークで、どちらも自動で更新されるようにしました。あなたがこの記事を読む日には、Issueは22かもしれないし23かもしれない、あるいは41かもしれません。星のアイコンはもうどこにもありません。サイトはすでにchandlernguyen.comで公開されています。
その意思決定について丸ごと一本記事を書くこともできます。でも、もっと役に立つのはワークフローの話だと思います。今回のリデザインを、私は2つの異なるAIモデルに分担させました。extended thinkingを有効にしたClaude Opus 4.7がデザインを担当。最高reasoning設定にしたGPT-5.5上のCodexが実装を担当。そしてCodexの/goal機能のおかげで、私が散歩に出かけたり夕食を取っているあいだに、Codexは一度に4時間近くも自律的に動き続けてくれました。
4日間。2つのモデル。約30コミット。1つのサイト。
ここからは、どのモデルをどの仕事に使えばよいのか、そしてその境界線が今どこにあるのかについて、私が学んだことを書いていきます。
なぜTRANSMISSIONを手放さなければならなかったのか
ここ2年で、私は広告からコードの世界へと越境してきました。今年のはじめ頃には、サイトもそれに追いついていました。その越境を見える形にするために、わざわざTRANSMISSIONとしてリデザインしたのです。4ヶ月半が経ち、そのシグナルはもう役目を終えました。
次の仕事は別物です。ブログ記事から、LinkedInのスレッドから、Google検索から訪れてくる人たちは、「私がコードを書ける」と確認しに来るわけではありません。彼らはメディア運用におけるAIについて何かを学びに来たり、コースの購入を検討したり、コース、Prova、DIALØGUE、STRAŦUMをプロダクトラダーとして比較しに来たりしています。サイトはシグナルを発信するよりも、案内をする役割を果たす必要がありました。
この変化を一番シンプルに言うなら、こうです。古いサイトは「パーソナリティ」でした。新しいサイトは「オペレーティングモデル」です。背後にいる人間は同じですが、果たすべき仕事が違います。それはつまり、別の美意識が必要だということです。より軽やかで、落ち着いていて、エディトリアルな、長文のブログ記事が呼吸できて、コースのCTAが押し付けがましくなく誠実に感じられるような表面。ガラスではなく、温かい紙です。
ただ、もっと難しい問題は美意識ではありませんでした。スループットです。このサイトには13言語、8つほどの公開ページ(ホーム、ブログ、記事、プロダクト、ラーニング、アバウト、Ask、コースのセールス)、認証が必要なコースアクセスのフロー、Stripeのチェックアウト、そしてSydney RAGエンドポイントがあります。これを手作業で全部作り直すとなると、何週間もかかったでしょう。私には何週間も時間はありませんでした。
そこで、作業を2つのAIモデルに分けました。
そもそもなぜデザインと実装を分けたのか
デザインと実装は、認知的に異なるタスクです。
デザインは遅いものです。それは構成について、抑制について、温かい紙の色合いがiPhoneで黄色すぎないか、別の色合いが冷たすぎないかについての判断です。「このセクションをどうレンダリングするか」の前に「この表面はどういうものになろうとしているのか」を問う作業です。よいデザインの仕事は時間を圧縮します。2時間考えて1つ意思決定をすれば、10時間の実装作業が省けるのです。
実装は速いものです。パターンの適用です。デザインシステムが与えられれば、コンポーネントを生成する。コンポーネントが与えられれば、それを13言語に展開する。ページレイアウトが与えられれば、バリエーションを出していく。仕事のスキルが低いわけではありませんが、曖昧さは少ない。正解はたいてい仕様に照らして説明可能です。
異なるAIモデルは、異なる認知タスクに対して得意不得意があります。ここ数ヶ月の私自身の経験から言うと(最初はClaude Opus 4.6、そして今は4.7、いずれもextended thinking設定で使ってきました)、Opusのほうがバランスのとれたパートナーです。 ブレインストーミングが得意。デザイン判断が得意。純粋なコーディングではやや遅くて外科的な精密さに欠けるところはありますが、答える前に全体の構成を考え、なぜあるフォントが親しみすぎるのか、なぜ別のフォントがしっくりくるのかを掴むような推論をしてくれます。
高reasoning設定のGPT-5.5上のCodexは、デザインチームの近くに行ったことのない優秀なシニアエンジニアという感じです。 速い。複数ステップのツール利用が抜群に上手い。ファイルを開いて、読んで、編集して、テストを走らせて、次のファイルを開く。ボタンが高すぎるかどうかについて強い意見は持っていませんが、ボタンはちゃんと出してきますし、13言語ぶんのバリエーション全部を文句も言わず出してきます。/goal機能を使えば、目標を渡せます。たとえば "convert the v3 design tokens into the Next.js app, wire the new shell, ship working BottomNav, MobileAppBar, ReadingProgress, verify the build passes with the flag off" といった具合に。そして席を立ってよいのです。サブステップを計画し、実行し、ビルドを走らせ、壊れたものを直し、また進めていってくれます。今回のプロジェクトで席を外したまま動き続けた最長記録は、4時間弱でした。
正直に言うと、最初からこの分担を意図していたわけではありません。連休前の数日のうちに、Opusとデザインの会話を重ねていました。連休が始まる頃には、デザインの方向性ドキュメントとデスクトップのプロトタイプが手元にありました。そして連休中に実装をCodexに引き渡したのですが、そうしてから1時間も経たないうちに、それぞれのモデルが自分の半分の仕事にどれだけ向いているかに気づいたのです。
Opusが担当したこと：デザインフェーズ
デザイン作業は、リビルドの前の数日間にOpusとの長い会話のなかで進められました。その会話から2つのアーティファクトが生まれ、いずれも今はリポジトリに入っています。
1. デザイン方向性ドキュメント。 doc/v3-design/に6本のMarkdownファイル。なぜそうするか、トークン、モバイルパターン、ページ仕様、アクセシビリティ制約、実装計画。13,000語を超える意思決定の集合で、その多くは私が渡したブリーフをもとにOpusが書いたものです。指示はこうでした。「次のサイトは、SaaSダッシュボードではなく、小さな印刷雑誌のような感触にしてほしい。抑制によって注意を勝ち取る。Operating Modelの2×2フレームワークを視覚的な署名として使う。」
2. デスクトップのHTMLプロトタイプ。 public/design-prototype-v2/にフラットなディレクトリを置き、6ページと共有のstyle.cssを入れました。ReactなしTailwindなしフレームワークなし、手書きのHTMLだけ。ローカルサーバーで全ページをクリックして回り、デザインシステムが本当にシステムとして成立しているかを肌で感じるためです。週末のリビルドのあいだ、視覚的な処理についてはこのプロトタイプが真実の源でした。迷ったときの答えは「プロトタイプに合わせる」だったのです。
Opusが下した、最も意味のあった決定のいくつかを挙げます。
-
フォントの判断を覆したこと。 それ以前のデザイン検討で、入手性と実装のしやすさを理由にManropeをディスプレイフォントに決めていました。Claude Sonnet 4.6のセッションでコミットされたものです。18時間後、私はデザインの会話をextended thinkingのOpus 4.7に移しており、Opusの最初の動きはそのロックを再検討することでした。私が一晩かけてPP Neue Montrealの公式サンプルページで文字の形を見比べたあと、切り替えが入りました。コミットメッセージはまるでタイポグラフィの事件現場のようです。"Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." 面白いのは、2つの異なるClaudeモデルが同じ意思決定について別の判断に至ったことです。Sonnetは安全な選択肢を選びました。Opusは正しい選択肢を選びました。 -
カーマインの選択。 シアンはAIのデフォルトのアクセントカラーです。私とOpusはカーマインレッド
#c33824に落ち着きました。プリンターインクの赤、ゲラ刷りに編集者がつける朱書きの色、あるいはLoeb Classical Libraryの棚に並ぶラテン語の巻の色です。理由は具体的でした。"the site is trying to feel editorial, not developer-tool. Cyan signals tech. Carmine signals craft. Use the carmine sparingly, always at high contrast, ideally on warm paper." これは実装最適化されたモデルが自分から手を伸ばすような判断ではありません。 -
Operating Modelを視覚的な署名にしたこと。 コースで教えている2×2フレームワーク(Automate / Protect / Deepen / Change)が、新しいサイトの控えめなブランドマークになります。現在の実装では、抑制された2か所にだけ姿を見せています。ホームページのテーゼブロックと、長文記事に添えられた小さなテーゼマークです。フレームワーク自体は私のものですが、これをサイトのビジュアルアイデンティティにしようという動きは、Opusとのデザインの会話から出てきました。
-
ダークよりライト。 Opusは、ライトモードをパーソナリティとし、ダークモードはサポートされるバリアントとして扱うべきだと主張しました。論拠はこうです。長文の読書はガラスよりも温かい紙のほうが楽だ、価格表示はライトの背景のほうが誠実に感じられる、ほとんどすべてのAIツールがデフォルトでダークを出すから、ライトこそ差別化要因になる、と。私は数時間反論したあと、同意しました。
Opusはほぼデザインとレビューのループを担当し、Codexが実装パスを行いました。Opusの仕事は、遅さが報われる部類のものだったのです。
Codexが担当したこと：実装フェーズ
デザインドキュメントとプロトタイプができあがると、作業はCodexに移りました。
新しいCodexセッションを開き、デザイン方向性のファイルをコンテキストとして渡して、/goalセッションを動かし始めました。各goalは、明確な終着点を持つマルチステップの目標でした。
Goal: Convert the v3 design tokens from
doc/v3-design/components/tokens.cssintosrc/app/globals.css. Remove the conflicting TRANSMISSION tokens. Wire up the three new fonts viasrc/lib/fonts.tsandsrc/app/layout.tsx. Generate the v3 shell behind the feature flagNEXT_PUBLIC_ENABLE_V3_DESIGN. Ship a workingBottomNav,MobileAppBar, andReadingProgress. Verify the build passes and that no existing pages are visually affected when the flag is off.
こういうマルチステージの目標こそ、まさに/goalが想定している使い方です。Codexはサブステップを計画し、実行し、pnpm buildを走らせて型エラーをチェックし、壊れた箇所を直し、もう一度ビルドを走らせ、進み続けます。散歩から帰ってくると、v3のシェルはコードベースの中でフラグの裏に動いていて、新しいフォントが読み込まれ、モバイルでボトムナビが描画されていました。
その後の/goalセッションでは、こんな仕事をしました。
- プロトタイプからv3のホームとアーカイブページを生成する。
- v3の記事レイアウトを生成する。リーディングプログレスバーとv3のシェアボタンも含む。
- v3のプロダクトとラーニングのページを生成する。仕様にあるラダー構造に合わせて。
- 既存のコースのセールス、ログイン、サインアップ、MFA、アクセスの各ページを、StripeやSupabase Authの裏側のロジックには手を加えずに、v3に視覚的に揃える。
- v3のコースとAsk Sydneyの表面を、既存の
messages/{locale}.jsonファイルを翻訳ソースとして、13言語ぶんローカライズする。
介入なしに完了した最長の実行は4時間弱。最短は45分ほど。4日間で約30コミットを出しました。その多くはCodexの1回目か2回目のパスで、モデルのアウトプットは正しいけれど形が少し違うところを、私が手で軽くクリーンアップした程度のものです。正直に勘定すると、今プロダクションで動いているコードの大部分はCodexが書いたものだと思います。残りを私が書いたか編集したかしました。
/goalについて一番役に立つのは、速度ではありません。自律性です。これまでAIツールで動かしてきたほとんどのコーディングセッションは、私がキーボードの前に張り付いている必要がありました。変更を承認する、次のファイルを受け入れる、diffをレビューする。/goalは、欲しい 最終状態 を指定して席を立つことを許してくれます。戻ってくる頃には、変更が完了しているか、あるいはモデルが私の判断を必要としている地点で停止しているか、どちらかです。仕事の形が変わるのです。1つ1つの編集の子守をする立場から、数時間にわたるセッションのプランナーになるわけです。
それでも境界線が残るところ
デザインと実装を2つのモデルに分けるのは、魔法ではありません。一方がもう一方を必要とする瞬間や、どちらだけでは足りない瞬間が、まだいくつもあります。
星のアイコン。 Codexは綺麗なv3のモバイルシェルを生成してくれたのですが、Askタブには星 ✨ のアイコンが付いていました。AIツールの普遍的な目印です。アイコンは仕様に対しては正しい。仕様には "do not use the cliché." とは書かれていなかったからです。私は数日後にそれに気づき、Opusのところに戻って差し替えを話し合いました。何度か反復しました。Operating Modelのマーク、それからカーマインレッドのNewsreaderの斜体のクエスチョンマーク。古いエッセイの欄外注に出てきそうなグリフです。最終的な答えはOpusのアイデアでした。Codexは15分でリリースしました。
日の丸の瞬間。 Operating Modelのマークがモバイルアプリバーの左上、私の名前の隣に置かれているあいだ、私は2、3日それを見つめていました。温かい紙のような正方形に、小さなカーマインの点。ある晩、他人の目でそれを見直して、ふっと気づきがありました。それは日本の国旗にそっくりでした。日の丸。淡い地に赤い小さな太陽。これにはOpusもCodexも気づきませんでした。Opusがそのマークを設計し、Codexがそれを実装し、どちらもレビューしていたのに、です。この視覚的な連想は、どちらのモデルにも見えない文化的なパターンでした。私はワードマークからそのマークを削除し、別の解決策に手を伸ばしました。(同じ斜体の?が、Askタブのその場所を埋めることになりました。)
13言語の展開。 Opusは各言語のUIのニュアンスを丁寧にデザインすることもできたでしょうが、何日もかかったはずです。Codexは単独ではデザイン判断はできませんが、パターンが決まってしまえば、1晩で13言語全部をリリースできます。これがデザインと実装の分担の、最も文字どおりの例です。デザインは遅く、実装は速く。
3つのフォントを組み合わせて選ぶこと。 OpusはSatoshi(ディスプレイ)、Newsreader(斜体のアクセント)、JetBrains Mono(ラベル)を選びました。Codexがこの組み合わせを自分で選ぶことはなかったでしょうし、Opusの会話のなかの「遅さ」がなければ、私自身もここに辿り着いたかどうか自信がありません。3つのフォントの構成は、デザインの判断であって、実装の判断ではありません。
2つのシステムのあいだの会話は、モデル同士のあいだではなく、私の頭の中で起きています。それが、2026年時点でまだ自動化されていない部分です。そして今、それこそが「テイスト」という言葉が意味するものを定義している部分だと、私は思います。
正直な勘定
4日間。約30コミット。プロダクションのv3はchandlernguyen.comでライブです。新しいサイトは新しい仕事をこなしています。訪れた人に「私が越境してきた」と告げるのではなく、「次に何を読むか」を見つける手助けをするという仕事を。
サイトにはまだ追いかけている問題が残っています。下書きの時点では、プロダクションのLighthouseモバイルでブログアーカイブが4.6秒で表示される一方、ローカルのChrome DevToolsのトレースでは同じ画像が264ミリ秒で描画されていました。同じコード、まったく違うネットワークモデルです。今のところ私の有力な仮説は、フォントのプリロード圧です。プリロードされた3つのwebfontと、レンダリングをブロックする3つのCSSチャンクが、絞られたモバイル回線で画像とゴールを競っているのではないか、と。最終日に最小レバレッジ版の修正をデプロイしましたが、それが効いたかどうか確認するための新しいLighthouseランがまだ必要です。あなたが読んでいるこの記事は、修正後の数値が出る前に書かれたものです。
サブスクリプションのコストは、Codexの最上位ティアに、すでに加入していたClaude Max。合わせて月数百ドル。このスループットを思えば、安いものです。
v3が3週間ではなく4日で実現したのは、おもにデザインと実装のフェーズを切り分けて、それぞれが得意なモデルに割り当てたからです。これが普遍的だとは思いません。1つのモデルが両方をこなせるプロジェクトもあるでしょうし、どちらのモデルも適切なパートナーではないプロジェクトもあるでしょう。それでも、強いデザインの視点を持つマルチページ・マルチロケール・マルチサーフェスのリデザインについては、この分担こそ私がまた手に取るワークフローだと思います。
もし最近、あなた自身がAI支援のリビルドをやっていたなら、どうやって作業を分けたか、ぜひ聞いてみたいです。1つのモデルでエンドツーエンドに走らせましたか？それとも私と同じようにフェーズで分けましたか、あるいは別の軸で(コンポーネントごと、ファイルごと、タスクの種類ごと)分けましたか？build in publicの次の波は、AIを使うかどうかという話ではなく、 どのAI を どの部分の仕事 に使うか、という話になっていくのだと、私は思っています。
結果を見たければ、今あなたが読んでいるそれです。ホームはchandlernguyen.com。プロダクトラダーは/products/。「オペレーティングモデル」というアイデアの出発点になったコースは/learn/にあります。
それでは、 Chandler