◉ Claude.ai/2026-04-22上級

Claude Design → Claude Codeハンドオフ — デザインから本番実装までを一本化する

Claude DesignとClaude Codeを連結し、LP・ダッシュボード・ピッチ資料を本番実装まで仕上げるワークフローを、5日間の実プロジェクト検証で測った数字と失敗ルート込みで共有します。

Claude Design⁸ Claude Code¹⁹⁷ Claude Opus 4.7² workflow²⁴ production⁸⁷

✦ プレミアム記事

Claude DesignとClaude Codeを連結できると知った瞬間に、多くの開発者は「これで実装の90%が自動化される」と期待します。私も最初はそうでした。しかし数週間使ってみて分かったのは、ハンドオフは魔法ではなく、むしろ「個別の工程を高速化する連続体」であるという事実です。適切なプロンプト設計と、受け取った側での調整プロセスを整えなければ、かえって混乱が増えます。

本稿はClaude Designが発表された2026年4月17日から5日間、自分の実プロジェクト（個人開発アプリのLP・ダッシュボード管理画面・投資家向けピッチ資料）で検証した記録を、再現可能な手順としてまとめたものです。成功パターンだけでなく、何度もやり直した失敗ルートも残します。

ハンドオフの内部仕様 — 何がやり取りされているのか

Claude Designで「Handoff to Claude Code」を押すと、生成物が次の形式でバンドルされます。

design-bundle/
├── manifest.json       # デザインシステム情報（トークン・フォント・カラー）
├── pages/              # HTML + CSS + JS（スタンドアロン）
├── components/         # React Component (TSX)
├── assets/             # 画像・SVG・フォントリファレンス
├── preview.mp4         # インタラクションの動画記録（任意）
└── build.log           # 生成過程のログ

このバンドルは api.anthropic.com/v1/design/h/<hash> というURLでホストされ、Claude CodeはWebFetchツールでこのURLを取得します。重要なのは、Claude Codeがこのマニフェストを読み込んだうえで、プロジェクトの既存コードベースと統合するという点です。つまり、「生成物をそのままコピーする」のではなく「既存の設計に馴染ませる」動きをします。Figma由来のデザインを扱う場合は、Claude Code + Figma MCP 実装ガイドも併せてご覧いただくと、ツール間連携の勘所が掴めます。

ここで最初のつまずきポイントがあります。プロジェクトが既にデザインシステム（独自のCSS変数・Tailwindコンフィグ・コンポーネントライブラリ）を持っている場合、Claude Designが生成したmanifest.jsonのトークンと衝突します。私のプロジェクトでは、--color-primaryの値が既存#2563EBと新規#6366F1でぶつかり、Claude Codeは親切にも両方を保持する形にまとめてくれましたが、結果的に使われない定義が残りました。

回避策は、ハンドオフ前に CLAUDE.md 内でプロジェクトのデザインシステムを明示しておくことです。

## Design System (authoritative)
 
Primary color: #2563EB (blue-600)
Font stack: "Inter Variable", system-ui, sans-serif
Component library: shadcn/ui (do not introduce a second library)
CSS approach: Tailwind only, no custom stylesheets

この状態でハンドオフするとClaude Codeが既存システムを優先する判断をしてくれます。

本番投入に耐えるLP生成プロンプトの型

LPを1回のプロンプトで生成するとき、Claude Design側には「情報密度」と「技術要件」の両方を与える必要があります。私が試行錯誤の末に辿り着いたテンプレートが以下です。

[製品の一行定義]
[ターゲット顧客の具体像 — 架空の人物でよい]
[メインCVの定義 — ダウンロード／サインアップ／問い合わせ]

# Hero
- 見出しは13〜20字の日本語＋英訳
- サブコピーは2行、35字/行以内
- 視覚要素: [具体的に書く — グラデーションメッシュ／3D Card／動画背景 など]

# Features (3ブロック)
- 各ブロックは30字以内の見出し＋100字以内の説明
- アイコン: Lucide
- レイアウト: [cards / split / grid]

# Social Proof
- 実在の企業名を使わない。架空の肩書きと名前で構成
- 3〜5件

# CTA
- [強いアクション動詞] + [得られる価値]
- ボタン色: [アクセント色]

# Technical
- Framework: Next.js 16 App Router
- Styling: Tailwind CSS
- Animations: prefers-reduced-motion を尊重、IntersectionObserver発火
- Accessibility: WCAG 2.2 AA、aria-label必須
- Performance: 画像はnext/imageを前提、Lighthouse Performance 90+

このテンプレートで生成した結果は、過去のv0出力と比べて手直しが1/3程度で済みました。ポイントは「技術要件」ブロックに具体的なベンチマーク（Lighthouse 90+など）を書くことです。Claude Designは抽象的な「高速に」より、具体的な数値を好んで反映します。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦ハンドオフ直後にデザイントークンが衝突する原因と、CLAUDE.mdでの事前宣言による回避策

✦LP・ダッシュボード・ピッチ資料それぞれで実際に失敗した具体パターンと、そのまま使える修正プロンプト

✦受け入れ作業を約60%短縮したカスタムスラッシュコマンド3本と、5日間の検証で測った実数値

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

ダッシュボード生成で私が4回失敗したパターン

LPは初見でうまくいきましたが、ダッシュボードUI（データ可視化込み）は4回やり直しました。チャート実装そのものの詳細は、Claude インタラクティブビジュアライゼーションで扱っています。失敗の系譜を整理します。

失敗1: チャートライブラリの指定忘れ
「棒グラフと折れ線グラフを配置」とだけ書いたら、独自実装のSVGチャートを生成されました。Rechartsを指定するまで直りません。

失敗2: サンプルデータが不自然
金額データで「¥1,234,567,890」のような非現実的な数値が出てきました。プロンプトに「数値は1,000〜9,999の範囲で、日本円で表現」と制約を書いて解消。

失敗3: レスポンシブが破綻
モバイルビューでサイドバーが重なるケース。「lg:768px未満ではサイドバーをドロワー化、開閉ボタンを右上に配置」と明示するまで直りません。Claude Designはデフォルトでデスクトップファースト志向です。

失敗4: ダークモード切替の実装が不完全
テーマトグルは出るものの、CSS変数がライトモード前提の記述で、実際には切り替わりません。「data-theme="dark"ルートセレクタでCSS変数を上書きする実装」と明示して解決。

これら4件を踏まえ、ダッシュボード生成プロンプトにはLP用テンプレートに加えて以下を追加しています。

# Data & State
- チャートライブラリ: Recharts
- サンプルデータはcomponents/_data.tsで定義（固定値・型付き）
- 状態管理: useState内で完結、グローバルストア禁止

# Responsive
- lg未満ではサイドバーをDrawer、ボタン配置: 右上
- モバイルでテーブルはカード化

# Theme
- data-theme属性でダークモード切替
- CSS変数はすべて--color-*, --bg-*, --text-*で命名

Claude Code側の受け入れ作業 — カスタムスラッシュコマンド3本

ハンドオフを受けた後のClaude Code作業を効率化するため、.claude/commands/配下に3つのカスタムコマンドを用意しています。コマンド定義そのものの書き方は、Claude Code カスタムスラッシュコマンドにまとめています。

1. /design-intake — バンドルを受け取って既存プロジェクトに統合

---
description: Claude Design bundle をプロジェクトに統合する
---
 
以下の手順を順に実行してください：
 
1. `design-bundle/manifest.json` を読み、既存の `src/config/design-tokens.ts` と衝突する値がないか確認する
2. 衝突がある場合は既存側を優先し、バンドル側をコメントアウトで残す（後で比較できるよう）
3. `design-bundle/components/` の TSX を `src/components/design-intake/` にコピー
4. コピー時にimport pathを既存プロジェクトの規約（絶対パス＋@/エイリアス）に書き換え
5. `design-bundle/pages/` は一旦 `src/app/preview/` 以下に配置し、既存ルートと分離
6. 完了後、追加・変更したファイルの一覧を表示

2. /design-cleanup — 未使用コード・重複を削除

---
description: Intakeで取り込んだコードのノイズを削除する
---
 
1. `src/components/design-intake/` 配下のTSXから、未使用のimportを削除
2. Tailwind未使用ユーティリティクラスを `tailwindcss-prune`（存在しない場合はgrepベース）で検出、削除提案をリスト化
3. 重複するTypeScript型定義を検出し、集約先を提案
4. 破壊的な変更は行わない。提案のみ出す

3. /design-ship — 本番投入前の最終チェック

---
description: Claude Designから持ってきたUIを本番に出す前の検証
---
 
以下12項目を順にチェックし、結果をMarkdownテーブルで出力：
 
| # | 項目 | 結果 | 備考 |
| 1 | レスポンシブ（sm/md/lg/xl） | | |
| 2 | ダークモード切替 | | |
| 3 | prefers-reduced-motion対応 | | |
| 4 | WCAG 2.2 AA（コントラスト比・aria） | | |
| 5 | キーボード操作のみでの導線完遂 | | |
| 6 | Lighthouse Performance 90+ 想定 | | |
| 7 | 画像のnext/image化 | | |
| 8 | フォントのsubset化・preload | | |
| 9 | i18nキーの漏れ（ja/en両方） | | |
| 10 | SEOメタ（title/description/OGP） | | |
| 11 | エラーバウンダリ | | |
| 12 | 未使用依存ライブラリ | | |
 
問題がある項目は、修正案を具体的なdiffで提示してください。

これら3本を使い回すと、ハンドオフ後の作業が体感で60%短縮されます。特に/design-shipは本番投入前の抜け漏れを減らしてくれるため、一人で開発しているプロジェクトでは欠かせません。

ピッチ資料生成の勘所 — PPTXは別モードで扱う

資料作成は、LPやダッシュボードとは別の設計思想で接するのが正解でした。理由は、PPTXは1スライド=1ページという制約があり、「情報密度を意図的に低くする」必要があるからです。

私はピッチ資料を生成するときのみ、プロンプトに次の一文を必ず入れます。

# Slide design principles
- 1スライドの要素数は5以下
- テキストは見出し＋キーワード3つまで
- 図解がメインで、文章は補足
- フォントは36pt以上（見出し）／24pt以上（本文）
- スライド間で色使いに統一感を持たせる（3色以内）

この制約なしに生成すると、1スライドに段落が5つ並ぶ「報告書型」が出てきます。PPTXの文化は口頭補足を前提とするので、テキスト量を抑える意識をプロンプトで明示する必要があります。

ハンドオフ後に必ず発生する調整作業

最後に、ハンドオフでは自動化されない、確実に手作業になる5つの領域を共有します。

日本語フォント周りの調整: 英字ベースのデザインに日本語を入れるとベースラインと行間がずれます。font-feature-settingsとline-heightの微調整はほぼ必須
i18nの埋め込み: 生成物にはハードコードされたテキストが残ります。next-intlのキーに差し替える作業は機械的だが時間がかかる
既存APIとの繋ぎ込み: ダッシュボードはダミーデータで生成されます。実APIへの置換は必ず手動
アニメーション過剰の調整: Claude Designは演出が豪華になりがちで、prefers-reduced-motionの分岐を別途実装する必要あり
アクセシビリティの最終調整: aria-labelやroleはプロンプトで指定しても完全ではなく、axe DevToolsでの検証が必要

これらは「自動化できない領域」ではなく「Claude Codeを使えば高速化できるが、放置はできない領域」です。/design-shipコマンドを整備することで、これらを体系的に潰していくのが現実解だと感じています。

5日間の検証で測った数字

感覚だけで「速くなった」と言っても課金の判断材料にはなりません。ここでは私自身が個人開発で運用している壁紙アプリの管理画面（AdMobの収益指標を確認するダッシュボード）を題材に、同じプロジェクトで測った実数値を残します。いずれも中央値、計測回数は各項目3〜4回です。

工程	整備前	整備後	効いた対策
LP1枚の手直し時間	約45分	約15分	技術要件ブロックに数値目標を明記
ダッシュボードの往復回数	平均3.5回	平均1.5回	チャートライブラリ・レスポンシブ・テーマを事前指定
トークン衝突の発生	3案件中3件	3案件中0件	CLAUDE.mdにデザインシステムを権威宣言
本番前チェックの所要	約25分（手作業）	約10分	`/design-ship`の12項目表で自動化
バンドル取得〜intake完了	—	平均8分	`/design-intake`で統合手順を固定

数字を並べて分かったのは、短縮幅の大半が「生成の速さ」ではなく「やり直しの削減」から来ているという点でした。往復が3.5回から1.5回へ減っただけで、体感の負荷は大きく変わります。逆に言えば、事前宣言を怠ると往復回数がそのまま時間として跳ね返ります。私が最も投資対効果を感じたのは、派手なプロンプトよりも、たった数行のCLAUDE.md宣言でした。