TL;DR — 効率は最強のモデルから生まれるのではなく、明確な分業から生まれる。3つのClaudeインターフェースをそれぞれ補完的な役割に当てた。Claude Designがビジュアル発想を担い、Web版Claudeが論理批評を担い、デスクトップ版Claudeがコード実装を担う。それらの間を3種のファイル（スケッチ・仕様書・実際のスクリーンショット）が通信契約として繋ぐ。これは一方向のパイプラインではなくループだ。リリース後の実際の画面が最初のデザインへと折り返し、修正を促す。

新しいレイアウトを設計するとき、私のワークフローは一見ひどく非効率に見える。同じ件について、3つの異なるClaudeインターフェースの間を何周も往復するのだ。まずClaude Designにビジュアルを生成させる。次にWeb版Claudeに投げて「これは合理的か」と問い詰めさせる。そしてデスクトップ版Claudeにコードへ落とし込ませてリリースする。最後に、オンライン上の実際の画面をスクリーンショットに撮り、Claude Designに戻してどこを微調整すべきかを確認する。

遠回りに聞こえるが、使えば使うほど確信が深まる。この「遠回り」こそが威力の源だ、と。

AIを使う人の多くが抱く直感は、十分に強力な万能ツールを1つ見つけて、すべてをそこに押し込むというものだ。AIベンダーもこの幻想を喜んで売る。入力フォームひとつで、アイデアを完成品に変えられると。しかし私の経験はその逆だ。どのインターフェースも単独でこの道を歩き切ることはできない。無理に全部を任せれば、どの工程もかろうじてこなすだけになる。鍵は完璧なAIを探すことではなく、各インターフェースの能力境界を見極め、それぞれが得意な領域で力を発揮させることだ。

3つのClaude：探索者・批評者・建設者

この3つのインターフェースはまったく異なる能力特性を持っている。スペックをいくら強化しても、インターフェース設計がもたらす振る舞いの違いは変わらない。

Claude Designは探索者だ。ビジュアルを「育てる」ことに最も長けている。画面のスケッチ（HTMLモック）を素早く生成し、コンポーネントを描き、デザインのコンテキストをフレームワークとして書き起こす。6月のアップデートでデスクトップAppに移行してからは、既存のコードベースを直接読み込めるようになった。これにより生成されるデザインが、既存のサイトスタイルに自然に馴染むものになった。ゼロから見た目は良くても使えない図を描くのではなく。ただし複雑なデータ連携やインタラクション状態の処理を求めると、途端に手こずる。Claude Designが引き渡すのはビジュアルスケッチ（mock）だ。

Web版Claude（つまりclaude.ai）は批評者だ。ビジュアルを生成する役割は持たないが、デザイン批評に極めて長けている。「なぜそう設計するのか？より良いトレードオフはないか？」と問い続け、曖昧なデザイン言語をエンジニアが理解できる仕様書（spec）に翻訳する。コードを書かせたり図を描かせたりするのは、人選を誤っている。Web版Claudeが引き渡すのは仕様書（spec）だ。

デスクトップ版のClaude Codeは建設者だ。実際に手を動かす側、つまり以前の記事〈ウェブサイトのデザインシステムをAIに学ばせる〉で述べたCodeワークフローを担う。プロジェクトファイル（リポジトリ）を読み書きし、Webコンポーネントを修正し、テストしてデプロイし、アイデアをコードとして実際に書き込む。しかし美的センスとビジュアル発想は決して得意ではない。Claude Codeが引き渡すのは実際のコードと、リリース後の実際の画面だ。

この3つの能力境界と、それらの間でどのように流れが生まれるかを、1枚の図にまとめた。

Three Claudes, One Loop：Claude Design（探索）、Web版Claude（批評）、デスクトップ版Claude Code（実装）の3つの能力境界と、explore → critique → implement → reflectのループ

並べてみれば分業は一目瞭然だ。1つが想像し、1つが欠点を突き、1つが着地させる。互いの代替品ではなく、互いの補完だ。

3種のファイルがAI間の「通信プロトコル」になる

3つのインターフェースがそれぞれ独自に動くとして、どうシームレスに繋ぐのか。具体的な3種のファイルがその答えだ。Claude Designがビジュアルを建設者に渡すのはモックHTML、Web版Claudeが判断を建設者に渡すのは仕様書Markdown、建設者が成果物を探索者に戻すのはデプロイ後のスクリーンショット。整理するとこうなる：

引き継ぎ方向引き継ぐファイル核心的役割
Claude Design → デスクトップ版モックHTMLビジュアル外観の定義
Web版Claude → デスクトップ版仕様書Markdownロジックと実装ルールの定義
デスクトップ版 → Claude Designスクリーンショットオンライン上の実際の表示結果をフィードバック

この3種のファイルが、3つのインターフェース間の「契約」だ。入出力の仕様が厳密に絞られているとき、次のAIは自分が何をすべきかを明確に把握できる。

このワークフローが崩壊しない理由はAIが賢いからではなく、境界と契約が十分に明確だからだ。人間のチームも同じで、協働の混乱はたいてい能力の問題ではなく、引き継ぎの曖昧さの問題だ。AIには人間の「以心伝心」がない。渡すインターフェースが精密であるほど、協働はスムーズになる。

注目すべきは、かつてこれらのファイルは人間が手動でコピー＆ペーストする必要があったことだ。2026年6月のアップデートの核心は、この継ぎ目を消すことにある。内蔵の自動同期（design-sync）により、「探索」と「実装」の間の変換がますます手間なく行えるようになった。システムのループ構造は変わっていない。変わったのは、歯車が回るときの摩擦が小さくなったことだ。

なぜパイプラインではなくループが必要なのか

人々が最も犯しやすい誤りは、このプロセスを一方向の「パイプライン」として捉えることだ。デザイン、評価、コーディング、完了、という具合に。しかし現実はデザインに対して意地悪を仕掛けてくる。

スケッチの中では完璧に見えたレイアウトも、実際のユーザーデータが入り、ブラウザのフォントレンダリングに晒され、異なる画面サイズ（RWD）に切り替えたとき、あっさり崩れることがある。

だからコードのリリースは終点ではない。私は必ず実際のWebページのスクリーンショットをClaude Designに再び与える。これがリフレクション（reflect）だ。次の最適化サイクルを「実際にどう見えるか」の上に築くのであり、「自分の想像」の上に築くのではない。

これがパイプラインとループの本質的な違いだ。パイプラインは最初から正しくできると仮定し、ループは必ず間違えると仮定する。 間違いが避けられないなら、システムの中に「修正」への合法的な経路を設けて、実際の結果が自動的に起点へ還流する仕組みにした方がよい。

起点が正確であれば、後が無駄にならない

先日触れたデザイン同期（design-sync）は、本質的にこのループの「起点校正」だ。

サイトのデザイン仕様（ブランドカラー・フォント間隔などのトークン）をClaude Designに与えるとき、何をしているのか。この「探索者」に自分の家の門を覚えさせているのだ。そこから引かれる最初の線は、サイトのDNAを最初から帯びている。安価で汎用的なAI臭を漂わせるのではなく。

起点が精確であれば、その後に続くすべてのサイクルに品質が宿る。最初から歪んでいれば、ループの中で加速しながら迷うだけだ。これは複数モデルの認知協働の核心でもある。単一のAIがどれほど賢いかではなく、秩序ある構造を構築して互いに補完させることが重要なのだ。

人間を常にループの中心に置く

この自動化された閉ループを見渡すと、興味深いことに気づく。3つのClaudeはいずれも強力だが、「この船は今どこへ向かうべきか」を知っているものは1つもない。

どの方向に修正するか。どの機能のトレードオフが事業利益に合致するか。いつ立ち止まるべきか。これらの価値に関わる意思決定は、AIには届かないし、うまくできない。

ツールは各ステップを猛スピードで走り抜ける。そして人間が方向を決める。3つのAIが1つのループを走り終えたとき、そのループに意味を与えるのは、常に中央に座り、秩序を定める人間だ。