Claude DesignとClaude CodeのHandoff実行手順｜つまずきやすい3場面と対処法

Claude DesignのExportメニューから数クリックで、作成したデザインをClaude Codeへ引き継いで実装に進められます。ただし実際に動かすと、表示されたコマンドを貼り付けても実装が始まらない、/design-syncが想定どおり同期しない、といったつまずきに当たりがちです。本記事は、Claude DesignとClaude CodeのHandoffを実行する具体的な手順と、つまずきやすい3つの場面（セッション不一致・部品化の前提・スキル未表示）の切り分けを、公式ドキュメントと公開された検証事例をもとに整理します。2026年6月17日アップデートで何が変わったかの全体像は別記事にまとめているため、ここでは「実際に動かすとき」に範囲を絞ります。

まとめ｜Handoff実行手順の要点とつまずいたときの確認順

Handoffの操作そのものは単純です。Claude Designの「Export」メニューから「Handoff to Claude Code…」を選び、表示されたコマンドをClaude Codeに渡すだけで実装に移れます。渡し先はローカルのCLIと「Send to Claude Code Web」の2系統から選べ、手元のターミナルで作業しているならローカル、そうでなければWeb版が基本になります。

つまずきは大きく3つに集約されます。1つ目はブラウザのClaude Designとローカルのセッションが別物でコマンドが通らないケース、2つ目は/design-syncが部品化済みのデザインシステムを前提とするためそのまま同期できないケース、3つ目は/designや/design-syncがClaude Code側に表示されず/updateが必要なケースです。コマンドが動かないときは、まずZIPダウンロードに切り替えると確実に渡せます。使いどころの判断軸は明確で、既存アプリのUI差し替えには向く一方、ゼロからのアプリ全体構築には使わないのが現実的です。

Claude DesignからClaude Codeへ引き継ぐHandoffで実際に動く要素

操作手順の前に、Handoffで「何が」「どこへ」渡るのかを押さえておくと、つまずいたときの原因切り分けが速くなります。

handoff bundleとして渡る中身とコマンド実行の関係

Handoffでは、画面のスクリーンショットではなく、コンポーネント構造・デザイントークン・レイアウト階層・参照アセットをまとめた「handoff bundle」がClaude Codeに引き継がれます。Claude Codeはこの構造化データを読み込み、ピクセルから意図を推測するのではなく、コンポーネントツリーとトークンを起点に実装します。Claude Designは2026年4月の公開時点でClaude Opus 4.7を基盤としており、ファイルやワイヤーフレームの読み取り精度が連携の前提になっています。つまり、渡るのは「絵」ではなく「仕様」だと理解しておくと、後述のつまずきの意味が分かりやすくなります。

2026年6月更新で増えた経路と全体像の参照先

公開当初のHandoffはClaude Design側からClaude Codeへ渡す一方向でした。2026年6月17日のアップデートで、Claude Code側からも/designでデザイン作業を起動できる双方向の往復が加わっています。新機能の全体像・対応プラン・デザインシステム刷新の詳細は、Claude DesignとClaude Codeが双方向連携｜2026年6月アップデートで変わるデザイン実装フロー全解説に整理しています。本記事はその先の「実際に手を動かす段」に集中します。

Claude DesignからHandoffを実行する具体的な操作手順

ここからが本題です。Claude Designで作ったデザインを、Claude Codeへ渡して実装に入るまでの実際のクリック動線を追います。

Exportメニューからの起動とローカル実行・Web実行の分岐

起動から渡し先選択までの流れは次のとおりです。

1. Claude Design画面右上の「Export」メニューを開く
2. 「Handoff to Claude Code…」を選択する
3. 表示されたモーダルで「Send to local coding agent」か「Send to Claude Code Web」を選ぶ
4. ローカルなら「Copy command」でコマンドをコピーし、Web版なら案内に従って受け渡す

手元のターミナルでClaude Codeを動かしているならローカル実行、ブラウザ完結で進めたいならWeb版を選ぶのが基本です。どちらを選んでも、渡される実体はhandoff bundleとそれを読み込ませるコマンドである点は変わりません。

ローカル実行でコマンドをClaude CodeのCLIに渡す流れ

ローカル実行では、「Copy command」で取得したプロンプトをそのままClaude CodeのCLIに貼り付けます。実装対象のプロジェクト直下でclaudeを起動し、コピーしたコマンドを入力すると、bundleの読み込みと実装が始まります。既存プロジェクトに当てる場合は、貼り付け前にそのリポジトリのルートでClaude Codeを起動しておくことが前提になります。起動ディレクトリを取り違えると、意図したコードベースにデザインが反映されないため、最初に作業ディレクトリを確認しておくと事故を防げます。

コマンドが使えないときのZIPダウンロードによる受け渡し

コマンドがうまく通らない場合の確実な代替がZIPダウンロードです。Claude Designはコマンド表示画面でZIP書き出しも用意しており、FOLDERS／PAGES単位で整理されたファイルとして取得できます。これを実装対象プロジェクトの直下に展開し、Claude Codeに「展開したデザインを既存コードに反映して」と指示すれば、コマンドが通らない環境でも作業を継続できます。次章のセッション不一致に当たったときの第一の回避策が、このZIP経由です。

Claude Code側で/designと/design-syncを使うための前提

双方向の往復は便利ですが、Claude Code側のコマンドには見落としやすい前提があります。表示されない、同期が始まらない、というつまずきの多くはここに起因します。

/design・/design-syncがスキルである点と/updateでの取得

/designと/design-syncは、Claude Codeに組み込まれた「スキル」として提供されます。公式ドキュメントでは、これらがコマンド一覧に表示されない場合は/updateを実行して最新のスキルを取得するよう案内されています。さらに、更新後のスキルが効くのは新しいセッションのみで、起動済みのセッションには反映されない点も明記されています。コマンドが見当たらないときは、まず/updateを実行し、Claude Codeを開き直してから再度試すのが正しい手順です。

/design-syncが既存デザインシステムを前提とする制約

/design-syncは、ローカルのデザインシステムをClaude Designに取り込むコマンドです。ここで誤解しやすいのが、どんなプロジェクトでもそのまま同期できるわけではない点です。公開された検証では、UIがコンポーネントとして切り出されていないWebアプリで実行したところ、同期がすぐには始まらず、先にReact化を提案されたと報告されています。/design-syncはボタンやカードといった部品が定義済みのプロジェクト向けの機能であり、画面が部品化されていないアプリにそのまま使える機能ではありません。同期が始まらないときは、コマンドの不具合ではなく「取り込めるデザインシステムが存在するか」を先に疑うべきです。

Handoffでつまずきやすい場面と回避の切り分け

ここまでの前提を踏まえると、現場で起きるつまずきは原因ごとに切り分けられます。代表的な場面と対処を、起こりやすい順に整理します。

ブラウザとローカルのセッション不一致でコマンドが通らない問題

最も多いのが、ブラウザで開いたClaude Designのセッションと、VS Codeやターミナルで起動したClaude Codeのセッションが別物になっているケースです。この状態では「Copy command」で取得したコマンドを貼り付けても、参照先のデザインが見つからず実装が始まりません。回避策はシンプルで、前章のZIPダウンロードに切り替え、展開したファイルをプロジェクト直下に置いてからClaude Codeに反映を指示します。同一アカウントでも、ブラウザとローカルでセッションが共有されない前提で動くと、原因探しに時間を取られずに済みます。

部品化されていないUIにそのまま同期できない場面の切り分け

同期や反映が思うように進まないとき、原因がツール側か自分のプロジェクト側かを切り分けます。判断基準は「対象のUIがコンポーネント単位で切り出されているか」です。切り出されていれば/design-syncで取り込め、各コンポーネントはプレビューや使い方の情報とともに同期されます。切り出されていなければ、まずReact化などで部品化を済ませてから同期するか、ZIP経由で個別に反映する方針に切り替えます。「コマンドが壊れている」と判断する前に、プロジェクトの構造を疑うのが近道です。

既存コードを壊さず差分だけ反映させる渡し方

既存アプリに当てる場合、見た目だけを差し替え、業務ロジックやAPIを壊さないことが最優先になります。Claude Codeへ渡す前に、流用する既存コンポーネントの範囲と「触ってよい層・触ってはいけない層」を明示しておくと、想定外の書き換えを防げます。実装後の差分・依存関係・パフォーマンスは人が確認する領域で、ここを自動化に委ねてはいけません。差分レビューを補助する仕組みとして、Claude Codeのマルチエージェント型コードレビュー機能を併用すると、反映後の確認を効率化できます。

FigmaのハンドオフやFigma MCPと操作面で何が違うか

従来のFigmaを起点にした連携と、Claude DesignのHandoffは、渡すものの性質が根本的に異なります。乗り換えや併用を検討するときの判断材料として、操作面の違いを押さえます。

スクリーンショット受け渡しとhandoff bundleの操作上の違い

FigmaのDev ModeやプラグインでもデザインからコードへのヒントやCSSは取り出せますが、最終的にエンジニアが別のコード表現として作り直す「オープンループ」が基本でした。Claude DesignのHandoffは、デザインを生成したClaude DesignとそれをコードにするClaude Codeが同じモデル系列で、handoff bundleという機械可読の仕様を直接受け渡します。再構築の翻訳工程が1段減るのが操作上の最大の差です。デザインと実装が別々の成果物として二重管理にならない点が、往復作業の負担を下げます。

Figma MCPでの連携と比べたときの相性の前提

handoff bundleは独自フォーマットで、DTCG形式のデザイントークンJSONでもFigmaのトークン書き出しでもありません。CursorやWindsurfなどが使うFigma MCPのDev Modeサーバーとも互換ではない点に注意が必要です。Figma側を起点にしたい、あるいはFigmaを信頼できる唯一の情報源として運用しているチームには、bundleはそのまま噛み合いません。どちらを起点にするか迷う場合は、次の比較表で操作面の要点を整理します。

起点をどちらに置くかで適否が分かれます。Claude Codeで実装まで進める前提なら前者、Figmaを設計の正本として残すなら後者が無理のない選択です。

Claude Designを使えるプランとHandoff利用時の使用制限

手順を試す前に、利用条件と消費の前提も確認しておきます。Handoffは追加料金の機能ではなく、Claude Designの利用枠の中で動きます。

利用できるプランとEnterpriseの既定オフ

Claude Designは無料プランでは使えません。Claude Pro・Max・Team・Enterpriseのいずれかの有料プランに含まれ、Handoffもその範囲で利用できます。Enterpriseでは既定でオフになっており、管理者が組織設定で有効化するまで表示されません。組織で導入する場合は、まず管理者側で有効化されているかを確認するのが先決です。

使用制限の共有プール化とトークン消費の前提

2026年6月の更新で、Claude Designの利用上限はチャット・Claude Cowork・Claude Codeと共通の枠に統合されました。以前はClaude Design専用の週次枠でしたが、現在は共有プールから消費されます。デザインの生成はレイアウトやスタイルを毎回推論するため、チャットの応答よりトークン消費が大きい点は変わりません。大規模なコードベースを取り込む反復作業では消費が増えるため、上限に敏感な運用では、まとめて生成せず段階的に進めるのが安全です。

Handoffを使うべき場面と使うべきでないと判断すべき場面

最後に、Handoffを実務で機能させる線引きを示します。万能のツールとして使うと手戻りが増えるため、向き不向きを先に決めておくべきです。

既存アプリのUI差し替えで効果が高い場面

最も相性が良いのは、すでに動いている既存アプリのUIを後から作り込む場面です。フロントエンド・API・DB・インフラが一式そろい、画面だけ機能確認優先の素朴な状態にとどまっているプロジェクトに、Claude Designで仕上げたUIをHandoffで当て込むパターンは、Claude Codeまでつなげやすい代表例です。LP・管理画面・社内ツールのように、見た目と実装が近い制作物ほど初稿から実装までの距離が短くなります。

ゼロからのアプリ全体構築に推奨しない理由

逆に、ゼロからWebアプリ全体をClaude Design起点で立ち上げる進め方は現時点で現実的ではありません。アプリ全体にはフロントだけでなくバックエンド・API・DB・認証・インフラ・IaCが必要ですが、これらをデザイン駆動で決めるのは無理があります。Claude DesignはビジュアルとUI設計が中心領域で、アーキテクチャ・レイヤ構成・依存関係といった実装側の関心事は専門外だからです。動けば良いデモ用途なら一気に生成する選択肢もありますが、運用・保守を見据えた開発では、意図した構造からずれた実装が出やすく、結局あとから作り直すことになります。

UI設計書として既存開発フローに組み込む使い分け

新規開発で取り入れるなら、生成されたデザインやHTMLを「UI設計書」として既存の開発ドキュメントに組み込み、その後の実装は通常どおり進める使い分けが堅実です。Handoffで一気に成果物を作る前提に寄せず、設計の起点として使うわけです。今回扱った既存アプリへのUI差し替えは、この使い分けの中でClaude Codeまでつなげやすい例の一つにあたります。速さはAIに、最終品質の保証は人に、という役割分担を崩さないことが、Handoffを実務で活かす条件になります。

よくある質問｜Handoff実行時のつまずきに関する疑問

Handoffを実際に動かす段でつまずきやすい点を、質問形式でまとめます。

Handoffのコマンドを貼り付けても実装が始まりません。原因は？

多くはセッション不一致が原因です。ブラウザで開いたClaude Designのセッションと、ターミナルやVS Codeで起動したClaude Codeのセッションが別物になっていると、コマンドを貼り付けても参照先のデザインが見つからず実装が始まりません。対処としては、コマンド表示画面からZIPをダウンロードし、実装対象プロジェクトの直下に展開したうえで、Claude Codeに反映を指示する方法が確実です。同一アカウントでもセッションは共有されない前提で進めると、原因探しを短縮できます。

Claude Codeに/designや/design-syncが表示されません。どうすれば？

/designと/design-syncはClaude Codeのスキルとして提供され、古い状態では表示されないことがあります。公式の案内どおり、まず/updateを実行して最新のスキルを取得してください。更新後のスキルが有効になるのは新しいセッションのみで、起動済みのセッションには反映されません。/updateのあとにClaude Codeを開き直し、新規セッションで再度コマンドを確認するのが正しい順序です。

/design-syncを実行したらReact化を提案されました。なぜ？

/design-syncは、ボタンやカードなどがコンポーネントとして切り出された既存のデザインシステムを取り込む機能だからです。UIが部品化されていないWebアプリで実行すると、同期がすぐに始まらず、先にReact化などの部品化を提案されることがあります。これは不具合ではなく仕様です。対処は、対象のUIを部品化してから同期するか、部品化が難しければZIP経由で個別に反映する方針に切り替えることです。

ハンドオフはローカルのClaude CodeとWeb版のどちらを使うべき？

手元のターミナルでClaude Codeを動かしているならローカル実行（Send to local coding agent）、ターミナルを使わずブラウザで完結させたいなら「Send to Claude Code Web」が基本です。ローカル実行では「Copy command」でコピーしたコマンドをCLIに貼り付けます。既存リポジトリに当てる場合は、そのプロジェクト直下でClaude Codeを起動してから貼り付けるのが前提になります。起動ディレクトリを取り違えると意図したコードベースに反映されないため、最初に確認してください。

既存のReactアプリにUIだけ後から当てられますか？

当てられます。フロントエンドやAPIが実装済みで、画面だけ素朴な状態のReactアプリに、Claude Designで仕上げたUIをHandoffで反映するのは相性の良い使い方です。ポイントは、流用する既存コンポーネントの範囲と、触ってはいけない層をClaude Codeへ事前に伝えることです。見た目の差し替えにとどめ、業務ロジックやAPIには手を入れない制約を明示すれば、既存の安定したコードを壊さずにUIだけを更新できます。

関連記事

• 2026年4月のClaude Codeデスクトップ刷新で変わった開発体験の全体像：Handoffの受け手となるClaude Code側の操作環境を理解できます。
• Base UIとは何か？アクセシブルでカスタマイズ可能なヘッドレスUIライブラリの概要：/design-syncの前提となる、コンポーネント設計とデザインシステムの考え方を補えます。