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は抽象的な「高速に」より、具体的な数値を好んで反映します。
ダッシュボード生成で私が4回失敗したパターン
LPは初見でうまくいきましたが、ダッシュボードUI（データ可視化込み）は4回やり直しました。チャート実装そのものの詳細は、Claude インタラクティブビジュアライゼーション で扱っています。失敗の系譜を整理します。
失敗1: チャートライブラリの指定忘れ
失敗2: サンプルデータが不自然
失敗3: レスポンシブが破綻
失敗4: ダークモード切替の実装が不完全 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回です。
数字を並べて分かったのは、短縮幅の大半が「生成の速さ」ではなく「やり直しの削減」から来ているという点でした。往復が3.5回から1.5回へ減っただけで、体感の負荷は大きく変わります。逆に言えば、事前宣言を怠ると往復回数がそのまま時間として跳ね返ります。私が最も投資対効果を感じたのは、派手なプロンプトよりも、たった数行のCLAUDE.md宣言でした。
次のアクション
Claude Design → Claude Codeの連結は、個人開発者にとって最も恩恵が大きいAIツールチェーンの一つになりつつあります。本稿で紹介したプロンプトテンプレートとカスタムコマンドは、そのまま自分のプロジェクトに持ち込んで試せる形にしてあります。
まず最初にやってほしいのは、プロジェクトのルート CLAUDE.md にデザインシステム宣言を書くことです。これだけでハンドオフ後の衝突がほぼ消えます。そのうえで、今抱えている「作りかけのLP」か「新規の1ページ資料」で1往復だけ試してみてください。設計思想の違いが肌感覚で掴めるはずです。