せっかく同じClaudeなら、Claude Code側からClaude Designのデータを直接読めるのではないか。
そう思って試したのですが、ここが思ったほど簡単ではありませんでした。
接続方法を調べ、DesignSyncやMCP、Exportまわりを確認する。
かなり時間を使いました。
その途中で分かったのが、こちらが最初に考えていた方向とは逆に、Claude Design側からClaude CodeへHandoffする導線が用意されていたことです。
実際につないでみて分かったのは、
Handoffできることと、Productionが完成することは別。
そしてもう一つ。
AI同士を直接つなぐこと以上に、同じファイル、同じGit、同じSource of Truthを見ることの方が、実務では重要だったということでした。
最初は、Claude Code側からつなごうとした。
前の記事で書いたように、OWL CORPORATEではClaude Designを使ってA、B、CのVisual案を比較し、最終的にDirection Dをつくりました。
見た目の方向性は、ここでかなり固まっています。
次に必要なのは、これを本番サイトへ持っていくことです。
そこで最初に考えたのが、
Claude CodeからClaude Designのデータを直接読ませる
という方法でした。
Claude Designで完成したものをClaude Codeがそのまま参照できれば、スクリーンショットを撮ったり、見た目を文章で説明し直したりする必要が減る。
AI同士が直接つながれば、人間が間に入る作業もかなり減るはずです。
そう考えました。
ところが、実際にはここでかなり苦戦しました。
同じClaudeでも、勝手につながるわけではない。
Claude Code側からClaude Designのデータへアクセスしようとして、接続方法を調べました。
DesignSync。
MCP。
Export。
どうすればDesign側の成果物をCode側へ正しく渡せるのか。
いくつかの方法を確認しましたが、OWLの制作では、Claude CodeからClaude Designへ直接つないで、そのまま安定して制作を続けられる状態までは確認できませんでした。
ここは最初の想像と違いました。
「同じClaudeなんだから、そのまま読めるだろう」
くらいに考えていたのですが、実際の制作ではそんなに単純ではありませんでした。
逆方向には、Handoffの導線があった。
調べていく途中で見つけたのが、Claude Design側のHandoffです。
Claude Designの画面には、
Claude Code — Implement this design in code
という導線があります。
そこから進むと、
Hand off to Claude Code
という画面が開き、Design側からClaude Codeへデザインを渡せる。
最初にこちらが試していたのは、
Claude Code → Claude Design
でした。
でも、用意されていた分かりやすい流れは、
Claude Design → Claude Code
だったわけです。
これは実際の画面を見ると、かなり期待します。
デザインをつくる。
そのままCodeへ渡す。
そして実装する。
Web制作の流れとして、かなりきれいに見えます。
ただ、Handoffはゴールではなかった。
DesignからCodeへ渡せる。
ここまでは大きいです。
以前なら、
「この余白で」
「このカードはここ」
「この動きにして」
と、別のAIへ説明し直していたものを、Design側の成果物ごと渡せる。
ただ、WebサイトをProductionまで持っていくと、その先にまだかなりあります。
レスポンシブ。
Semantic HTML。
Component設計。
Accessibility。
Performance。
SEO / AIO。
Routing。
Asset管理。
Git。
Cloudflare。
問い合わせ機能。
API。
そしてDesktopとMobileでのQA。
Claude Designで見た目が完成しても、Webサイトとして完成したわけではありません。
ここは実際にProductionまでやってみないと、かなり見えにくいところでした。
最終的には、Exportを正本として回収した。
OWLでは、Claude DesignとClaude Codeの直結だけに頼るのをやめました。
Claude DesignからExportされた、
HTML。
JavaScript。
Assets。
仕様情報。
これらをAI_WORKSPACEへ回収しました。
回収したデータについては、元Exportと一致しているかSHA-256まで確認しています。
つまり、
「AIが見た感じ同じと言っている」ではなく、同じデータを次の工程へ渡していることを確認した。
そのうえで、CodexやClaude Code側が同じ成果物を読めるようにしました。
ここからProduction実装を進めています。
気づけば、人間がAI同士の通信ケーブルになっていた。
今回かなり実感したことがあります。
AIを何種類も使えば、人間の作業は減る。
そう考えていました。
実際、かなり減ります。
一方で、環境が整っていないと、別の作業が増えます。
Claude Designの結果をスクリーンショットにする。
ChatGPTへ見せる。
指示をつくる。
別のAIへコピーする。
ファイルを回収する。
また別のAIへ渡す。
結果を持ち帰る。
気づけば、人間がAI同士の通信ケーブルになっていました。
AIが増えているのに、人間がコピペ係になる。
これはかなりおかしい。
そこで、制作途中から考え方を変えました。
AI同士を直接つなぐより、同じ正本を見せる。
最初は、AI同士を直接接続することを考えていました。
実際に制作を進めてみると、もっと重要だったのは別のことでした。
同じファイルを見ていること。
同じGitを見ていること。
同じSource of Truthを読んでいること。
この方が安定しました。
Claude DesignがVisualをつくる。
ExportをAI_WORKSPACEへ置く。
Productionを担当するAIが同じものを見る。
修正内容はGitに残る。
現在の判断はSource of Truthへ残す。
そうすると、「別のAIへ説明し直す」回数を減らせます。
AI同士が直接会話していなくても、同じ正本を共有していれば仕事はつながる。
これは今回かなり大きな発見でした。
逆方向の同期は、少なくとも今回は確認できなかった。
もう一つ、今回の記事で明確にしておきたいことがあります。
Claude DesignからClaude Codeへ渡す方向は確認できました。
一方で、
Claude Code側で修正したProductionコードを、そのままClaude Designへ戻し、再びVisual編集を続ける。
この逆方向の流れは、少なくともOWLの制作時点では実用確認できていません。
つまり、
Design ↔ Code
を自由に往復できる、完全な双方向同期として使えたわけではありません。
OWLでは基本的に、
Claude DesignでVisualを固める ↓ Exportする ↓ AI_WORKSPACE / Gitへ入れる ↓ Production側で実装する
という、一方向寄りの運用に落ち着きました。
最終的に、AIごとの役割が決まった。
今回の制作では、最終的にこうなりました。
Claude Design
Visual Prototype / Visual Source。
Codex
Production実装の主担当。
Claude Code
Design Bridgeの候補、そして後には独立コード監査。
ChatGPT
構成、Copy、制作ディレクション、比較、採否判断。
AI_WORKSPACE / Git / Source of Truth
AI同士が同じものを見るための共通基盤。
最初からこの形を設計していたわけではありません。
つなごうとして、
うまくいかなくて、
別の方法を試して、
人間が橋渡ししすぎていることに気づいて、
少しずつこの形になりました。
AI間連携の本質は、直結ではないのかもしれない。
Claude DesignとClaude Codeを直接つなごうとしたところから始まった今回の検証。
Design側からCode側へ渡すHandoffはあります。
それ自体も便利です。
でも、今回一番大きかったのはそこではありませんでした。
AIを実務で複数使うなら、
「AI同士をどう直接つなぐか」より、
「AI同士に何を共通で見せるか」
の方が重要なのかもしれません。
同じファイル。
同じGit。
同じSource of Truth。
それがあれば、AIが変わっても制作を続けられる。
OWL CORPORATEでは、Webサイトをつくる途中で、Webサイトそのものだけではなく、AIが一緒に働ける環境までつくることになりました。
そして今は、その制作方法自体を別のWebサイトへ横展開し始めています。