生成AI関連
Claude Designとは？対話しながらデザイン・プロトタイプを仕上げるAIツール
前回の記事では、AnthropicのAIデザインツール「Claude Design」を取り上げ、要件定義書をもとにお小遣い帳アプリのプロトタイプを作る流れを紹介しました。
本記事ではその続編として、前回Claude Designで作成したUIプロトタイプを、Claude CodeへのHandoffで既存のReactアプリへ反映するまでを実際に試した内容を整理します。
本記事では、次の内容を取り上げます。
なお、Claude Designそのものの基本機能（Questions / TWEAKS / Comment / Drawなど）は前回記事で詳しく扱っているため、本記事ではHandoff機能による連携にフォーカスして紹介します。
Handoffは、Claude Designで作成したデザインをClaude Codeに引き継ぎ、コードベースに反映させるための機能です。Claude Design画面の Share メニューに Handoff to Claude Code… というボタンがあり、これを選択するとClaude Code側に貼り付けて使うコマンドが提示されます。
Claude Designを始める | Anthropic Help Center
機能の流れは次の通りです。
なお、本記事ではこの機能のことを「Handoff」と表記します。
前回のClaude Design記事では、お小遣い帳アプリの要件定義書を渡し、Hi-fiデザインとインタラクティブプロトタイプを生成しました。今回はそのHandoff先として、同じ要件定義書をもとに実装まで進めた既存のWebアプリを用意します。Reactのフロントエンドだけでなく、API、DB、GCP上のインフラ、Terraformによる構成管理まで一式が揃った、最低限動作する状態のアプリケーションです。
この既存アプリは、機能としては残額の計算、支出の登録、カテゴリ別の集計などがひととおり動作するものの、画面は機能確認を優先したシンプルな状態のままになっています。PoCやプロトタイプとして動くものを先に作るとよくある状況で、業務ロジックやAPIの実装が先行し、見た目の作り込みが後回しになりがちです。社内デモではこのままでも問題ありませんが、お客様に見せる、あるいはプロダクトとして成立させる場面では、もう一段の作り込みが欲しくなります。
そこで本記事で試すのは、前回Claude Designで仕上げたプロトタイプの見た目を、Handoff to Claude Code経由で既存Reactアプリに後から当て込めるかという検証です。Claude Designの成果物をHandoff機能で受け取り、Claude Codeに既存コードへ反映させます。
なお、「ゼロからWebアプリ全体をClaude Design起点で作る」という進め方は、現時点ではあまり現実的ではないと感じています。Webアプリをゼロから立ち上げるには、フロントエンドだけでなくバックエンド、API、DB、認証、インフラ、IaCといった要素が必要ですが、これらをデザイン駆動で決めていくのは難しい場面が多いです。Claude DesignはあくまでビジュアルとUI設計が中心領域で、アプリのアーキテクチャ、レイヤ構成、フォルダ構成、依存関係といった実装側の関心事は専門外です。
とにかく動けば良いデモ用途であれば、Handoff機能で一気に成果物を生成する進め方も選択肢になります。一方で、運用・保守まで見据えたプロダクト開発の観点では、意図した構造からずれた実装が出てきやすく、結局あとから手を入れることになりがちです。
そのため、新規開発でClaude Designを取り入れる場合は、生成されたデザインやHTMLを「UI設計書」として既存の開発ドキュメントに組み込み、その後の実装は通常どおり進めるという使い分けが現実的だと考えています。今回扱うように、既存アプリに対してUIだけを差し替えるユースケースは、この使い分けの中ではClaude Codeまでつなげやすい例の1つです。
Handoff機能で渡すデザインは、前回の記事で生成したお小遣い帳アプリのプロトタイプです。要件定義書から生成し、Questions・TWEAKS・Comment/Drawで微調整したうえで、最終的に複数の画面に仕上げました。本記事では、その中からログイン・月一覧・ホームの3画面をピックアップして紹介します。
このプロトタイプは、Claude Design上、または書き出したStandalone HTMLとして動作します。ただしHTMLをローカルのブラウザで開くだけの構成で、内部にはAPI呼び出しもDBも認証もありません。入力した支出を保存して後から見返す、といった使い方はできず、ローカルで触ってその場限りの動作を確認するところまでが限界です。あくまでUIと画面遷移のデザイン成果物であり、これをそのまま見せて終わるか、実装まで連結させるかが、今回の分かれ道になります。
一方、Handoff先となる既存アプリはこちらです。前述の通り、同じ要件定義書から実装側で立ち上がった、動くWebアプリです。プロトタイプと比較しやすいよう、同じ3画面（ログイン／月一覧／ホーム）を並べます。
機能的には、残額の計算、支出の登録、カテゴリ別の集計などがひととおり動作します。しかし画面は機能確認を優先したシンプルな状態のままで、Claude Designで仕上げたプロトタイプとは見た目に大きな差があります。「中身は揃っているが、見せ方が追いついていない」状態です。
ここに、Claude Designのプロトタイプの見た目を、Handoff機能で連携します。
Claude DesignのShare > Handoff to Claude Code… を選択すると、Claude Codeに貼り付けるためのコマンドが提示されます。
提示されるコマンドは次のような形式です。 Implement: 以降には実装対象として渡したいファイル名（Claude Designで生成した代表ファイル）が入ります。デフォルトのまま使うことも、Give the agent more detail on what to implement (optional) の項目から別のプロンプトに書き換えて使うこともできます。
Fetch this design file, read its readme, and implement the relevant aspects of the design. https://api.anthropic.com/v1/design/h/XXXXXXXX?open_file=...
Implement: お小遣い帳.html
このコマンド冒頭の Fetch this design file のURLは、デザイン一式（HTML/CSS/JS、README、関連アセット）をtar.gzで返すエンドポイントになっています。Claude Codeはここから取得した内容を展開して、次のような構成のbundleを参照します。
untitled/
├── README.md ← コーディングエージェント向けの指示書
├── chats/
│ └── chat1.md ← Claude Designでのチャット履歴
└── project/
├── app.jsx / ui.jsx / styles.css / ... ← UI部品
├── お小遣い帳.html
├── お小遣い帳-standalone.html
└── uploads/
├── 要件定義.md ← 添付した元の要件定義書
└── draw-*.png ← Drawで赤入れした画像
特徴的なのは、デザインの最終形だけでなく、そこに至るチャット履歴、Drawで赤入れした画像、元の要件定義書まで同梱されている点です。 README.md には「chatsを最初に読むこと／代表HTMLは全文確認すること／曖昧なら必ずユーザに確認すること」など、エージェント向けの読み順まで明示されており、Claude Codeはこれらを突き合わせて実装方針を決める前提になっています。第1段でこのフェッチと読み込みを済ませることで、既存コードベースとデザインの両方を理解した状態が作られます。
なお、ネットワーク事情やファイルサイズなどの事情でfetchがうまく動かない場合は、エクスポートメニューの「Download zip instead」から同じ内容をzipでダウンロードできます。zipを展開したフォルダをそのままClaude Codeに渡しても、同じ流れで実装に進められます。
ここで重要なのは、このコマンドを既存ReactアプリのコードベースをClaude Codeで開いた状態で実行することです。Handoff機能はあくまでデザイン情報を渡すまでが役割で、それを実プロダクトに落とすかどうかはClaude Code側に見えているコードベース次第です。新規プロジェクトに対して実行すればゼロから一式を生成しようとしますが、既存コードに対して実行すれば、既存コードに合わせて差分の改修を試みる動きになります。今回のデモは、後者です。
まずはHandoff機能を実行するコマンドをClaude Codeに貼り付け、デザインのフェッチとREADME・チャット履歴・対象HTMLの読み込みまでを進めてもらいます。
ただし、Handoff機能で提示されるコマンドは1行目に … and implement the relevant aspects of the design. 、末尾に Implement: お小遣い帳.html という2か所の実装指示が含まれており、コマンドをそのまま貼り付けるとClaude Codeが実装まで走り出してしまいます。今回のように既存アプリへリデザインを反映するケースでは、この時点ではまだ範囲制約や齟齬時の方針を伝えていないため、ここで実装に入ってしまうと意図と外れる可能性があります。
そこで、貼り付ける前に両方の実装指示を外し、「fetchして読み込み、方針だけ提示する」内容に書き換えるのがおすすめです。たとえば次のように変更します。
Fetch this design file and read its readme. https://api.anthropic.com/v1/design/h/XXXXXXXX?open_file=...
実装はまだ着手せず、READMEとチャット履歴、対象HTMLを読み込んだ上で次の指示を待って下さい。
URL部分（フェッチ先）はそのまま残し、1行目の and implement … と末尾の Implement: 行を、読み込みと方針提示の指示に置き換えるのがポイントです。
なお、新規プロジェクトに対してデザインを丸ごと実装させたい場合は、この書き換えはあまり気にする必要はありません。既存資産との整合や触ってほしくない範囲という前提が薄いため、コマンドをそのまま貼り付け、Claude Codeに一気に実装させてしまっても問題になりにくいです。今回のように一度読み込みで止めるのは、既存コードベースとの整合を取りたいケース固有の進め方だと捉えていただくのがよいと思います。
Claude Codeが読み込みを終え、次の指示待ちの状態になったところで、続けて制約を伝えます。
その制約プロンプトを設計するうえで、特に意識したポイントが2つあります。
ひとつは、触ってよい範囲と、絶対に触ってほしくない範囲を分けて伝えることです。Claude Codeはコードベース全体を編集できる権限を持っているため、曖昧に「このデザインを反映して」と頼むと、APIクライアントやバックエンド、Terraformにまで手が入る可能性があります。最初の指示で範囲を明示しておくと、後の事故が減ります。
もうひとつは、デザインと既存APIに齟齬があったときの振る舞いも先に決めておくことです。Claude DesignはUIを生成する都合上、既存APIには存在しない項目（たとえば「先月比の増減率」のような値）を画面に含めてくることがあります。何も指定しないと、Claude Codeが整合性を取ろうとしてAPIや状態管理を勝手に拡張してしまうことがあるため、「足りないデータは勝手に作らず、プレースホルダで仮置きして人間に判断を委ねる」という方針も最初に伝えておきます。
これらを踏まえ、デザインを読み込ませた直後に、次のような指示を続けて出しました。
渡したデザインを確認し、既存ReactアプリのUIを修正してください。
触ってよいもの:
- app/frontend/src/ 配下のcomponentsファイル
- アイコンや画像の追加
触らないでほしいもの:
- app/frontend/src/api 配下のAPIクライアント
- app/backend 配下のAPI
- app/infra 配下の、Terraformや環境変数の設定
デザインと既存APIに齟齬があった場合（UIにある項目が既存APIから取得できない、
もしくは既存APIで取得できる項目がデザインに含まれていない、など）は、
APIや状態管理を勝手に拡張・削減しないでください。
- 既存APIで取得できないデータは、表示しないか、プレースホルダで仮置きする
- 該当箇所はコメントで明示し、最終的な扱いは人間が判断する
完了後はブラウザで起動し、登録・更新・削除・画面遷移といった
既存機能が壊れていないかを確認してください。
この粒度で制約を渡すと、Claude Codeが実装着手前に「変更対象は app/frontend/src/ 配下のコンポーネントとページで、APIクライアントやバックエンドには手を入れません」といった作業方針を返してくれます。ここで方針をすり合わせてから実装させられるため、勝手に範囲外まで編集される事故が起きにくくなります。
Claude Codeはコードベースを読み、Tailwindのクラスとコンポーネントの構造を中心に修正してくれました。
主な修正対象を整理すると、次の通りです。
| 対象 | 変更内容 |
|---|---|
| 画面コンポーネント | ホーム、月一覧、各種フォーム画面のレイアウト調整 |
| 共通コンポーネント | カード、ボタン、入力欄、ナビゲーションの見た目を更新 |
| スタイル / Tailwind | 配色、余白、角丸、影、レスポンシブ対応の調整 |
| アイコン | 支出カテゴリや操作ボタンへの追加 |
一方、APIクライアント、バックエンド、Terraformには手が入っていないことを差分で確認しています。
反映後の画面はこちらです。先ほどと同じ3画面（ログイン／月一覧／ホーム）を並べます。
概ね渡したデザインを再現してくれています。
ここで重要なのは、これはモックではなく、APIから本物のデータを取ってきて表示している画面だという点です。Claude Designで作ったプロトタイプをそのまま見せるのではなく、既存アプリのUIとして関係者に確認してもらえる状態まで持っていけるのが、この進め方の大きな価値です。
もう1点、フッターのタブ構成にも違いが出ています。プロトタイプのフッターには「ホーム／月一覧／分析／設定」の4タブが並んでいますが、反映後の既存アプリでは「ホーム／月一覧／設定」の3タブになっています。既存APIに「分析」タブで使えるエンドポイントが用意されていなかったためです。実装時に「APIを勝手に拡張せず、足りないデータは人間に判断を委ねる」と伝えていたとおり、Claude Codeは分析タブを無理に実装することも、空のままUIだけ残すこともせず、デザインから外したうえで「APIがないため未実装」と報告してきました。後工程で「APIを追加して実装するか／プロトタイプから外すか」を人間が判断すれば良い状態に仕上がっています。
ここまでの流れを通して見えてきた、進め方のポイントを整理します。
まず、本質的なメリットとして、デザインそのものを実装側に渡せるため、人間とAIの認識齟齬が起きにくいという点があります。従来のワークフローでは、デザインの意図を「UI設計書」や「画面要件の箇条書き」といった言語化された中間成果物に落とし込み、それを実装側が解釈する流れになりがちでした。間に人間の言語化が挟まる分、ニュアンスのズレや情報の取りこぼしが発生しやすくなります。今回の進め方では、人間が実際に触って動作と見た目を確認したデザインを、そのままClaude Codeへ渡せるため、「人間が見たもの＝Claude Codeが受け取るもの」という関係になり、言語化段階で生じるロスを最小化できます。Claude DesignとClaude Codeを組み合わせる効用は、突き詰めるとここに集約されると感じます。
そのうえで、進め方として意識したいのが、Claude DesignとClaude Codeの役割を分けることです。Claude Designは「どんな見た目にしたいか」を、コードを書き始める前に固める場として使い、Claude Codeは固まったデザインを既存コードに反映する場として使う。配色やレイアウトの試行錯誤をコード上でやると重くなりますが、Claude Designの中で済ませてしまえば、Claude Codeに渡す段階では実装に集中できます。
次に、Handoff機能はアプリ全体を自動生成する魔法ではないという点です。デザインに含まれているのは画面の見た目とインタラクションが中心で、API仕様、認証、DB制約、Terraformの構成といった裏側の情報は含まれません。今回のように既存アプリのUIを差し替える用途であれば噛み合いますが、ゼロからプロダクトを丸ごと作らせようとすると、運用保守の観点で、結局は人が大量の補完を入れることになりがちです。
そして、変更範囲の制約は最初の依頼で明文化すること。Claude Codeは権限の範囲で何でも触れてしまうので、「Reactコンポーネントとスタイルだけ」「APIクライアントは触らない」と書いておくだけで、PRレビューが格段に楽になります。
最後に、動作確認とコードレビューは人間が行う必要があります。見た目がプロトタイプに近づいていても、実機で触ったときに既存機能の挙動や表示状態まで含めて崩れていないかは、最終的に人間がチェックする前提で進めるのが安心です。いわゆるバイブコーディング全般に共通する話ですが、生成AIが書くコードは動作はするものの、保守性や可読性の観点で粗が残る場合があります。今回はとくにデザイン反映を主目的としてClaude Codeを動かしているため、見た目の整合に意識が寄ったぶん、コンポーネント分割の妥当性、状態管理の一貫性、既存ロジックとの整合といった、アプリケーションとしての作りの部分が手薄になっている可能性もあります。マージ前のコードレビューで、命名・責務分担・既存パターンとの整合といった観点を改めて確認する工程は、後々の保守コストを下げるうえで省略しないほうが無難です。
Claude DesignとClaude Codeの組み合わせは、「動くけれど見た目で損をしているアプリ」を、本格的にデザインから作り直す前のたたき台として一段引き上げる手段になります。
本記事のポイントを振り返ります。
「中身は揃っているが、見せ方が追いついていない」アプリを抱えている方は、ぜひ一度試してみてください。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
