[Claude Design] 6分でデザインがコードになった——Claude Design × Claude Code で起きていること
「6分」という数字が示すもの
Datadogのチームは「1週間かかっていたデザインレビューサイクルが1会話に圧縮された」と言う。Brilliantの担当者は「競合のツールで20プロンプト必要だったものが、2プロンプトで完成した」と言う。unnamed ITアセット管理ツールのチームは「『アセット管理が欲しい』のひと言から、フルダッシュボード・トラッキング・レポートが1セッションで完成した」という事例を残している。
これらの数字を並べて改めて考えると、何かが起きていると確信せざるをえない。「AIでデザインが速くなった」という話ではない——設計と実装の間にあった「翻訳」が、構造的に消えたという話だ。
ハンドオフバンドルの正体——これはファイルの受け渡しではない
Claude Designで作ったものをClaude Codeに渡す機能を「ハンドオフ」と呼ぶ。
だが「ハンドオフ」という言葉から「ファイルを渡す」というイメージを持ったなら、それは違う。この誤解を解くことが、Claude Design × Claude Codeの本質を理解するための第一歩だ。
従来のデザイン→実装ハンドオフの問題
従来のデザイン→実装ハンドオフを思い出してほしい。デザイナーがFigmaでUIを作り、エンジニアに渡す。このとき何が起きているか。
Figmaファイルが送られてくる。エンジニアはそれを開き、スペックを確認する。「このパディングは24pxか」「このカラーコードは何？」「このホバー状態は？」——膨大な情報が、視覚情報として圧縮されている。エンジニアはそれを「読み解く」作業をする。
デザイナーが意図したこと、考えた文脈、なぜこのレイアウトにしたかという理由——これらは多くの場合、ファイルの中に入っていない。デザイナーの頭の中にある。
そして実装が始まると、確認の往復が発生する。「このボタンのホバー状態はどうするんでしたっけ」「このエラー時の表示って考えてます？」「このモバイル表示はどうなりますか？」——仕様書を用意していても、想定外のケースは必ず出てくる。
これが翻訳コストの正体だ。
視覚情報を言語情報に変換する際に起きる情報の欠落。デザイナーの意図を実装者の理解に変換する際に起きる解釈のズレ。そして、その解消のために必要な「確認の往復」にかかる時間。
スタートアップで働いたことがある人なら、このコストの重さを知っているはずだ。デザイナーとエンジニアが5人ずついるチームで、一つの機能のデザインレビューに1週間かかる——それが当たり前だった。
ハンドオフバンドルの技術的な正体
Claude Designのハンドオフバンドルは、この構造を根本から変える。
バンドルの中に入っているのは、JPEGやPDFではない。コンポーネント定義・デザイントークン（色・余白・タイポグラフィの値）・コピー（テキスト内容）・インタラクション注釈・デザインシステム仕様——これらが、設計時の会話コンテキストと一緒にパッケージされる。
具体的に言えばこういうことだ。Claude Designと会話しながら「このボタンのホバー状態はシアンで0.2秒のフェードトランジション」と決めた場合、その判断がバンドルの中に入っている。「なぜシアンか」「なぜ0.2秒か」という設計の文脈も、会話ログとして含まれている。
Claude Codeがそのバンドルを受け取ったとき、「ホバー状態は？」という疑問を持つ必要がない。すでに答えが含まれているからだ。
そして最も重要な点がある。ProducerであるClaude DesignとConsumerであるClaude Codeは、同一モデルファミリーだ。
これが何を意味するか。
デザインを作ったモデルが、コードを書くモデルと「同じ言語を話している」ということだ。人間の言語で言えば、日本語ネイティブの設計者が英語ネイティブの実装者に渡すのではなく、同じ言語を持つ二人の間で受け渡しが行われる。翻訳は必要ない。「設計者の意図」がそのまま「実装者の入力」になる。
情報は欠落しない。意図は消えない。翻訳コストは発生しない。
「翻訳コストの撤廃」——前回の記事でこの言葉を使った。今回、実際に使ってみてその意味が具体的になった。コストが「削減」されたのではなく、構造的に「不要になった」のだ。
実際に触ってみた——プロンプト1本から動くUIができるまで
理論は理解した。では実際にどうなるのか。自分で試した体験を順番に書く。
Step 1: Claude Designで設計する
「このシリーズのLPを作りたい」——そこから始めた。
最初にやることは、コードベースとデザインファイルの読み込みだ。Claude Designはそこからチームのデザインシステムを自動構築する。使っている色、フォントサイズ、コンポーネントの丸みの設定、余白のリズム——コードの中に蓄積されてきた無数の判断を、形式知として抽出する。
実際にやってみると、「うちのデザインって、こうなってたのか」という発見がある。自分たちが気づかないうちに積み上げてきた暗黙のデザイン判断が、可視化される瞬間だ。
「このチームはプライマリーカラーに #3B82F6 を一貫して使い、ボタンのroundnessは8pxに統一していますね」——Claudeがコードから読み取ったデザインシステムを説明してくれる。「あのサービスのデザインシステムって実は自分たちのコードベースの中にあった」という体験だ。
次に、「3つの方向性を出して」と頼む。同じ要件に対して、3つの違うビジュアルアプローチが並ぶ。選んで、インラインコメントで「こっちのタイポグラフィで、あっちのレイアウトを試して」と伝える。会話で洗練させていく。
ここでの体験は、「デザインツールを操作する」感覚よりも、「デザイナーと会話する」感覚に近い。Figmaでオブジェクトをドラッグして配置するのではなく、「このメインコピーをもっと大きく、左寄せで」という言語で指示が通る。
一つの方向性が選ばれ、さらに会話で磨かれていく。「このCTAボタンはもっと視線を引きたい」「このヘッダーエリアの情報密度が高すぎる」——自然言語で修正を入れる。Claudeがその意図を解釈して、デザインを更新する。
設計が固まるまでにかかった時間は、今回のケースで20〜30分。「決断の質」は確実に上がった——ゼロから考えるより、3案が目の前にある状態で選ぶほうが、判断が速く正確になる。
Step 2: ハンドオフ
「完成」と判断したら、ハンドオフを実行する。
このとき渡されるバンドルを意識すると、「ファイルを渡した」ではなく「設計会話ごと渡した」という感覚になる。Claude Codeが受け取るのは、完成した画像ではなく「なぜこうなっているか」が含まれた構造だ。
前述の「ホバー状態はシアンで0.2秒」という例で言えば、その判断に至った会話のコンテキストがバンドルの中に入っている。Claude Codeは「受け取ったデザインをコードにする」だけでなく、「設計者がどういう意図でこれを作ったかを理解した上でコードにする」という状態から始まれる。
Step 3: Claude Codeで実装する
受け取ったバンドルを元に、Claude Codeがコードを生成する。
驚くのは、コードが「デザインから逆算されている」という点だ。変数名がデザイントークンの名前と一致している。コンポーネントの構造が、設計時に定義した粒度に対応している。たとえばClaude Designで「HeroSectionとFeatureGridとCallToActionのthree-sectionレイアウト」として設計したなら、コードも `HeroSection.tsx`・`FeatureGrid.tsx`・`CallToAction.tsx` という構造で出てくる。
「ジュニア開発者のアウトプットを安定して超える」——この評価は、量だけでなく整合性という点で正確だと思った。設計と実装の間に乖離がない。何十行も書いた後に「あ、ここのコンポーネント名、デザインのやつと違う」という状況が発生しない。
Brilliant社の「20プロンプト → 2プロンプト」という圧縮は、この整合性の高さによるものだと思う。指示の往復が減れば、トータルのインタラクション数も減る。
Step 4: Ultraplanとの組み合わせ
シンプルなLPであれば、Step 3までで完成することが多い。しかし、複雑なダッシュボードや多機能なプロダクトページになると、Ultraplanが本領を発揮する。
Ultraplanは2026年4月に追加されたClaude Codeの新機能だ。クラウドで実装計画を下書きし、Webエディターで確認・注釈を加え、確認が取れたらローカルまたはリモートで実行する、という三段階のフローを提供する。
Ultraplanを使うと、実装が始まる前に「これから何を作るか」のリストが手に入る。それをWebエディターで確認し、「このコンポーネントは既存の `Button.tsx` を使ってほしい」「このAPIはモックでいい」という注釈を加える。曖昧さを潰してから実行に移す。
この「計画→確認→実行」のループは、Datadogのチームが実現した「デザインレビュー1週間 → 1会話」の圧縮の核心にある構造だと思う。決定を並べて一気に確認できるから、往復のコストが激減する。
ハーネス設計が完成した——Planner × Generator が同一エコシステムで動く
ハーネス設計という概念。AIを自律稼働させるための三層構造だ。
Planner: 何を作るか・どう作るかを決める
Generator: 実際に作る
Evaluator: 成果を検証し、フィードバックループを回す
PlannnerとGeneratorの間に「翻訳コスト」があることが課題だ。設計の意図をGeneratorに正確に渡すのは難しい、という問題。Plannerが生成した仕様をGeneratorが正しく受け取るためのインターフェース設計が、ハーネス設計の難所の一つだった。
Claude Design × Claude Codeのハンドオフバンドルは、その課題への直接的な回答だ。
Claude Design = Planner（課題を視覚化し、設計意図を形式化する）
Claude Code = Generator（実装し、コードを生成する）
自分（人間） = Evaluator（方向性を判断し、品質を評価し、最終的に承認する）PlannerとGeneratorが、初めて同一エコシステムで繋がった。
Playwright事例が教えてくれること
Anthropicのエンジニアリングブログで紹介されているPlaywrightの自動テスト事例が、この構造を理解する助けになる。
この事例では、テスト自動化のハーネスが次のように組まれている。
Plannerエージェント: テスト対象の機能を分析し、テスト計画を作成する
Generatorエージェント: 計画に基づいて実行可能なテストコードを生成する
Healerエージェント（Evaluatorの変種）: テストが失敗した際に壊れたセレクターを自動修復する
このハーネスの設計で特に重要な点が一つある。「作業するエージェント」と「評価するエージェント」を分離することで、自己評価バイアスを排除する——これがハーネス設計の核心だ。
GeneratorにEvaluatorを兼ねさせると、自分が作ったものを自分で評価することになる。当然、バイアスがかかる。「これで問題ない」という結論に引っ張られやすくなる。だから分ける。
Claude DesignとClaude Codeが「別のツール」であることは、この原則と一致している。設計を担当するPlannerと実装を担当するGeneratorを分けることで、それぞれの役割が明確になる。Claude Codeは「受け取ったバンドルを忠実に実装する」ことに集中できる。自分が作った設計を自分で評価するバイアスがない。
Claude Agent SDK——ハーネスを自分で組む時代
Claude Code SDKが「Claude Agent SDK」としてリブランドされた（Python & TypeScript対応）。
名前の変更は、単なるリブランドではない。「Claude Codeという特定のツールを操作するSDK」から、「エージェントを組み立てるためのフレームワーク」への進化を示している。
Claude Agent SDKが提供するのは、Claude Code本体を動かしているのと同じツールセットだ——自律的なファイル読み込み・コマンド実行・Web検索・コード編集。これを使えば、Planner-Generator-Evaluatorハーネスを自分のプロダクトに組み込める。
「使う」から「組む」への移行
Datadogのチームが実現した「1週間のデザインレビューが1会話に」という圧縮を、自社のデザインレビュープロセスに組み込む。Claude Designをデザイン生成のPlanner、Claude Code SDKをコードレビューのEvaluator、Claude Codeを実装のGeneratorとして設計する。それをClaude Agent SDKで繋げる。
あるいは、スタートアップのプロトタイプ開発フローに組み込む。ユーザーインタビューで得た課題をClaude Designに渡して複数のUX方向性を生成し、チームで選択・修正したものをハンドオフバンドルでClaude Codeに渡して実装する。その出力をClaudeを使った自動テストで評価するEvaluatorを挟む。
「AIの動作そのものを設計する」仕事へ
PdMとエンジニアにとっての示唆は大きい。
「AIを使う」のではなく「AIの動作そのものを設計する」という仕事が、専門的なMLエンジニアでなくてもできる範囲に入ってきた。
Claude Agent SDKのドキュメントを読むと、「エージェントの自律性の度合いをどう設定するか」「どのタイミングで人間の確認を入れるか」「エラーハンドリングをどう設計するか」というオプションが明示されている。これらは、ソフトウェアエンジニアリングの設計判断と変わらない。コードで書く部分がAPIの呼び出しになるだけで、思考のフレームは同じだ。
第1回で書いた「ハーネスの設計が人間の仕事になる」というテーゼが、もう一段具体化した。
誰の仕事がどう変わるか
実際に触れた経験から、「変わること・変わらないこと」を整理する。単なる機能紹介ではなく、「日々の仕事の文脈で何が変わるか」という視点で。
PdMにとっての変化
一番変わるのは、「デザイナーへの依頼の前」だ。
従来、PdMがデザイナーに「こういう機能を追加したい」と依頼するとき、言語で説明していた。「ボタンを追加して、クリックしたらモーダルが出て、その中に〜」という形で。デザイナーはそれを受け取って、Figmaでビジュアル化する。
Claude Designを使えば、PdMが自分でそのビジュアルを作れる。しかも、「こういうイメージで」という質の低いたたき台ではなく、チームのデザインシステムに準拠した、見せられるレベルのもの。
デザイナーへの依頼の精度が上がる。「このビジュアルを元に、ここを磨いてほしい」という形になる。探索フェーズをPdMが担い、精緻化フェーズをデザイナーが担う、という分業が自然に生まれる。
また、前回の記事で書いた「評価基準の設計」——Evaluatorがどう判断するかをビジュアルで定義する、というフローが現実的になる。「完成したら、このビジュアルと比べる」という基準を設計フェーズで作っておける。
エンジニアにとっての変化
「ゼロから書く」という起点がなくなる。
受け取るのはコードのスキャフォールドだ。コンポーネント構造が決まっており、変数名がデザイントークンに対応しており、インタラクション定義が含まれている。エンジニアはそこに「ビジネスロジック」を追加する仕事に集中できる。
これは、エンジニアの価値が下がるという話ではない。「何を書くか」を考える時間が減り、「なぜそう書くか」を考える時間が増えるという話だ。アーキテクチャ判断・パフォーマンス最適化・エッジケースの処理——これらは依然として人間の判断が必要な領域だ。
Ultraplanとの組み合わせで、実装の前に「何を作るか」の計画を確認できるようになったことも大きい。「作ってみたら方向性が違った」という手戻りが減る。
デザイナーにとっての変化
「探索」に使える時間が増える。
Figmaで一つのデザインを丁寧に作るより、Claude Designで10の方向性を素早く試して、最も有望なものを選んでFigmaで磨く——この分業が自然になる。
「Claude Designが自分の仕事を奪う」という不安は、今すぐには杞憂だと思う。Claude Designが今できないこと——Figmaのような精緻なコンポーネント管理・バージョン管理の詳細な履歴・チームでの同時編集——は依然としてデザイナーの専門領域だ。
むしろ「もっと前の段階で、もっと多くの選択肢を試せるようになった」という拡張として捉えるほうが生産的だ。
スタートアップ創業者にとっての変化
「デザイナーを雇う前のフェーズ」でも、ビジュアルのクオリティが確保できる。
ピッチデック、LP、プロダクトプロトタイプ——シードフェーズで必要なこれらを、Claude Designで作り、Claude Codeで動かし、投資家や顧客に見せながら検証を回せる。
「デザイナーは早めに雇うべき」という従来の経験則が、見直されるかもしれない。「設計の試行錯誤はClaude Design + Claude Codeでやり、デザイナーはプロダクトが検証フェーズを超えてから雇う」という戦略が現実的になった。
変わらないこと——課題特定の価値はむしろ上がった
ここまで「変わること」を書いてきた。しかし同じくらい重要なのが「変わらないこと」だ。
「何を作るか」は人間の仕事のままだ。
Claude Designに何を頼むか。どの方向性を選ぶか。ユーザーにとって本当に必要なものは何か。Datadogのデザインレビューを圧縮した話も、Brilliantの2プロンプトで完成した話も、「正しい問いを立てた」という前提がある。
第1回で書いたことを再確認する。AIが「書く仕事」を担えるようになるほど、「問う仕事」の価値は上がる。不の解像度を高め、課題を特定し、「これを解くべき」と判断する——この能力は、AIが設計・実装の両方を担えるようになっても、人間の核心的な仕事として残る。
最終的な美的判断・ブランドの哲学も変わらない。
Claude Designが出してくるものが技術的に優れていても、「これがうちのプロダクトらしいか」「このトーンはユーザーへのメッセージと一致しているか」を判断するのは人間だ。デザインシステムを自動生成できても、「そのシステムが目指すべき価値観」は人間が定義する。
ユーザーへの共感も変わらない。
「なぜこのユーザーはここで詰まっているのか」「このUIを初めて見た人はどこに視線が行くのか」——これらはClaude Designが答えられる問いではない。ユーザーインタビューで聞いた言葉、観察した行動、感じたフラストレーションを元に「この設計で伝わるか」を判断するのは、依然として人間の仕事だ。
まとめ——ハーネスの「内側」が完成した
AIが担える領域が、確実に上流へ移動している——この命題は変わらない。しかし今回で変わったのは、「上流への移動」だけではなく、「上流（設計）と下流（実装）が同一コンテキストで繋がった」という構造的な変化だ。
ハンドオフバンドルは「翻訳の高速化」ではなく「翻訳の不要化」だった。
AIが上手くなるほど、「問う力」が価値を持つ。
ハーネスを設計することが、AI活用の本質的なスキルになる。
Claude Designが「Planner」フェーズを視覚の領域まで拡張した。デザインという行為が、AIエコシステムの中に入ってきた。
そして今、PlannerとGeneratorが同一エコシステムで動いた。ハーネスの「内側」が一繋がりになった。
次は——ハーネスを「使う」から「組む」への移行だ。
参考資料
#ClaudeCode #ClaudeDesign #Anthropic #AIエンジニアリング #AI開発 #ハーネス設計 #プロダクトマネジメント #デザインエンジニア #生成AI #AIワークフロー #スタートアップ #AIプロダクト #フロントエンド開発 #デザイン自動化 #AIled開発
いいなと思ったら応援しよう！
サポートありがとうございます！頂いたチップは、より質の高い実務知見を還元するための「AIツール活用費」や「学習用書籍」として大切に活用させていただきます。現場で戦うPdMの視座を共に高めていくための、心強いガソリンになります。