デザインツールにブランドカラーやコンポーネントの形を説明し直す作業を、私はこれまで何度繰り返してきたか分かりません。新しい画面案がほしいたびに「角丸は8px、ボタンの高さは44px、プライマリはこの紫」と毎回伝える。出てきた案はきれいでも、実装してある既存のコンポーネントとは微妙にずれていて、結局コード側で揃え直す——この手戻りが地味に時間を食っていました。
6月17日に入った Claude Design の更新は、その手戻りの根を一つ抜いてくれるものでした。ローカルのコードベースを起点に動けるようになり、生成されるアセットに既存プロダクトの要素が反映されるようになったのです。デザインシステムのインポート、キャンバスの直接編集、エクスポート形式の追加も同時に入りました。Pro・Max・Team・Enterprise で使えるベータ機能です。
ここで扱うのは、すでにある Claude Design → Claude Code ハンドオフ の「デザインから実装へ」という向きの逆です。コードを起点にしてデザインを生成する という新しい向きを、Dolice Labs の4サイトを一人で手入れしている運用に当てはめて整理します。
「コードを起点にする」とは具体的に何が変わったのか
これまでの Claude Design は、原稿や参考画像、あるいは口頭のブランド説明を入力にして画面案を出していました。良くも悪くも「ゼロから描き起こす」道具で、既存プロダクトとの整合は人間が後から取る前提でした。
6/17 の更新で加わったのは、次の4点です。
追加点 何ができるようになったか 個人開発での効き目
コードベース起点の生成 ローカルリポジトリを読み、既存コンポーネントの形・余白・色を反映した案を出す ブランドの再説明が要らなくなる デザインシステムのインポート 既存のトークン定義を正本として取り込む 案ごとの「微妙なずれ」が消える キャンバスの直接編集 生成結果を再プロンプトせず手で直せる 細部の調整がプロンプト往復より速い エクスポート形式の追加 用途に応じた書き出しを選べる 後工程ごとに最適な形で渡せる
私が一番効くと感じたのは最初の点です。実装ずみのコンポーネントが「事実上のブランドガイド」として機能するので、デザイン側がそれに寄せてくれる。デザインと実装のどちらが正本かという長年の曖昧さに、「コードが正本」という一つの答えを与えてくれた格好です。
まず何を読ませ、何を読ませないかを決める
コードベースを起点にすると言っても、リポジトリ全体を漫然と読ませるのは得策ではありません。4サイトのうち Claude Lab のフロントは Next.js + TypeScript ですが、関係するのはごく一部です。読ませる範囲を絞るほど、生成される案のブレが減ります。
私が起点として渡すのは、おおむね次の3層だけです。
層 具体的なパス例 役割
トークン src/styles/tokens.css, tailwind.config.ts 色・余白・角丸・フォントの正本 基礎コンポーネント src/components/ui/ 配下 ボタン・カード・入力欄の形 代表的な1画面 記事詳細ページの page.tsx 1枚 余白の取り方・密度の参照
逆に読ませないのは、API ルート、課金まわりのロジック、ビルド設定、テストです。これらは見た目に寄与しないどころか、Claude Design の注意を散らします。スコープを宣言する小さなファイルをリポジトリ直下に置いておくと、起点指定が安定します。
# DESIGN_CONTEXT.md — Claude Design に読ませる範囲の宣言
## 正本（必ず参照） - src/styles/tokens.css … 色・余白・角丸・タイポの単一の正本 - tailwind.config.ts … トークンのエイリアス - src/components/ui/ … Button / Card / Input / Badge の実装
## 参照（密度の参考程度に） - src/app/[ locale ]/articles/[ category ]/[ slug ]/page.tsx … 代表1画面
## 読ませない - src/app/api/ … 見た目に無関係 - src/config/pricing.ts … 機密・見た目に無関係 - * */* .test.ts … 同上 このファイルは Claude Code 側の CLAUDE.md とは別物です。CLAUDE.md がエージェントの行動規範なら、DESIGN_CONTEXT.md は「デザイン生成が見るべき景色」の地図にあたります。両者を分けておくと、片方を直したときにもう片方が巻き込まれません。
デザインシステムのインポートで「微妙なずれ」を消す
コードベース起点と並んで効くのが、デザインシステムのインポートです。これまでは生成のたびにブランドを説明していたため、案ごとに角丸が 6px だったり 8px だったりと、わずかなゆらぎが出ていました。インポート機能は、その「正本」をツール側に固定してくれます。
ポイントは、インポートさせる入力の優先順位です。私は次の順で渡すと精度が安定すると感じています。
実装ずみのトークン定義 （tokens.css の CSS 変数）— 最も信頼できる正本コンポーネントの実装 （実際に動いている Button.tsx など）— 振る舞いと状態が含まれる仕様書やスタイルガイド （あれば）— 言語化された意図口頭・文章の説明 — 最後の補完
実装が一番上に来るのは、「動いているコードは嘘をつかない」からです。スタイルガイドに「角丸8px」と書いてあっても、実コードが 10px ならユーザーが見ているのは 10px です。トークンを機械的に吸い上げる小さなスクリプトを一度書いておくと、インポート前の整形が楽になります。
// scripts/extract-tokens.ts // tokens.css の :root から CSS 変数を抜き出し、インポート用 JSON に整形する。 // 期待する出力: { "color-primary": "#6d5ae6", "radius-md": "8px", ... } import { readFileSync, writeFileSync } from "node:fs" ;
const css = readFileSync ( "src/styles/tokens.css" , "utf8" );
// :root { --name: value; } の宣言だけを対象にする const root = css. match ( /:root \s * {( [ ^ }] * )}/ s )?.[ 1 ] ?? "" ; const tokens : Record < string , string > = {};
for ( const line of root. split ( ";" )) { const m = line. match ( /--( [\w-] + ) \s * : \s * ( . + )/ ); if (m) tokens[m[ 1 ]. trim ()] = m[ 2 ]. trim (); }
writeFileSync ( "design-tokens.json" , JSON . stringify (tokens, null , 2 )); console. log ( `抽出したトークン数: ${ Object . keys ( tokens ). length }` ); // 実行例: npx tsx scripts/extract-tokens.ts → 抽出したトークン数: 37 このスクリプト自体は素朴ですが、要点は「人間がスクショやスポイトで色を拾い直さない」ことです。私は4サイトでトークン名を揃えているので、1本書けば使い回せます。色を手で拾う作業を一度やめると、案ごとのゆらぎが目に見えて減りました。
生成してからキャンバスで直接直す、という順番
コード起点で画面案が出たあと、細部が完全に思いどおりということはまずありません。見出しの行間がわずかに詰まっている、カードの影が強すぎる——こうした調整を、以前はプロンプトに書いて作り直していました。けれど「影を20%弱く」と言葉にして再生成すると、ほかの部分まで微妙に変わってしまうことがあります。
キャンバスの直接編集が入ったことで、ここを手で直せるようになりました。私の運用は単純で、構造はプロンプト、見た目の微調整はキャンバス と役割を分けています。
プロンプトで決めること: セクションの構成、要素の有無、レイアウトの大枠
キャンバスで直すこと: 余白、行間、影、フォントサイズの ±1〜2 段階
この線引きをすると、再生成で「直したはずの別の場所が戻る」事故が起きません。言葉で伝えるのが速いものと、手で動かすのが速いものは違う、というだけの話なのですが、道具がようやくその当たり前に追いついた感覚があります。
コード起点だからこそ、Claude Code への受け渡しが破綻しない
ここが今回の更新で一番うれしい点です。従来のハンドオフでは、ゼロから描いたデザインを Claude Code が実装するため、「このスペーシングは既存のどのトークンに当たるのか」をエージェントが推測する場面が残っていました。推測が外れると、新しい一回限りの値がコードに紛れ込みます。
コードを起点に生成した案は、そもそも既存トークンの上に乗っています。だから受け渡し時に「対応するトークンを探す」工程がほぼ消えます。私は受け入れ側に、対応関係を明示させる小さなスラッシュコマンドを置いています。
<!-- .claude/commands/accept-design.md --> 渡されたデザイン仕様を実装に落とす。次の制約を厳守すること。
1. 新しい色・余白・角丸の値を **生成しない** 。すべて src/styles/tokens.css の 既存変数（var(--...)）にマッピングする。 2. 既存トークンに該当がない値が出てきたら、実装せず一覧で報告する。 勝手に近い値へ丸めない。 3. 使ったコンポーネントは src/components/ui/ の既存実装を再利用する。 新規作成する場合は理由を1行添える。
出力: 変更ファイル一覧 + 「トークン未対応で要判断」の項目リスト 制約1と2が肝です。エージェントに「足りなければ勝手に作る」のではなく「足りなければ止めて報告する」と約束させる。コード起点で作った案ならそもそも未対応はほとんど出ませんが、出たときに静かに紛れ込まないことが、長く運用するうえで効いてきます。受け渡しの内部仕様の詳細はハンドオフの本番ガイド に譲りますが、起点がコードに変わっただけで、この受け入れ作業の体感はかなり軽くなりました。
エクスポート形式の使い分け
エクスポート形式が増えたぶん、後工程ごとに最適な渡し方を選べます。私が実際に使い分けているのは次の3つです。
渡す先 選ぶ形式 理由
Claude Code（実装） 構造化された仕様（コンポーネント＋トークン対応） 受け入れ時にトークン照合が要らない SNS 告知・ブログ挿絵 画像書き出し そのまま貼れる。デザイナー業務側で完結 記録・レビュー 共有リンク 後日見返す・他環境で確認する
個人開発だと、同じ1枚の画面案を「実装に回す」「告知画像にする」と二度使うことがよくあります。実装には構造化仕様、告知には画像、と一度の生成から二方向へ書き出せるのは、一人で運用と発信の両方を回す身には素直に助かる変化でした。
うまくいかなかったパターンと、その直し方
最後に、移行初期に私がつまずいた3点を共有します。同じ轍を踏まないための実例です。
1. リポジトリ全体を読ませて案がぶれた。 最初はスコープを切らずに起点指定したところ、テスト用のダミーデータの色まで拾ってしまい、案にノイズが乗りました。DESIGN_CONTEXT.md で読ませる範囲を3層に絞った時点で安定しました。
2. スタイルガイドを最優先で渡してずれた。 言語化された仕様を一番上に置いたら、実コードと食い違う値が出ました。優先順位を「実装トークン > コンポーネント > 仕様書」に入れ替えて解消。動いているコードを正本に据えるのが結局いちばん確実です。
3. キャンバスで直した後にプロンプトで再生成して、手直しが消えた。 構造変更をプロンプトでやり直したら、キャンバスで詰めた余白が初期値に戻りました。以降は「構造が固まってからキャンバスで仕上げる」と順番を固定して回避しています。
いずれも、道具のせいというより私の段取りの問題でした。コード起点という新しい向きは強力ですが、起点を絞り、正本の優先順位を決め、構造と微調整の役割を分ける——この三つを最初に決めておくと、最短で安定します。
次のアクション
まずは一番手を入れている小さなリポジトリで DESIGN_CONTEXT.md を1枚書き、トークンとUIコンポーネントだけを起点に1画面を生成してみてください。既存の見た目がどれだけ反映されるかを一度確かめれば、どこまでツールに任せ、どこを自分の手で握るかの線引きが、自分の現場の感覚としてつかめるはずです。
お読みいただきありがとうございました。私自身もこの新しい向きを4サイトの運用に馴染ませている途中ですが、デザインと実装の境目が薄くなっていく流れを、共に手を動かしながら確かめていけたら嬉しいです。