Claude Code「/design」公開、実装前の画面案を判断する方法

Claude
Claude Code

Claude Codeの「/design」は、コードベースを踏まえた複数の画面案を実装前に比較し、選んだ案を編集して実装へつなぐ早期プレビューです。対象は、要件をすぐコードにせず、デザイナー・開発者・企画担当者の判断を先にそろえたいチーム。本記事では、公開情報から確認できる範囲と、試行時の4段階の判断手順を整理します。

何が起きたか

2026年8月17日、AnthropicのプロダクトデザイナーであるNate Parrott氏は、Claude Codeで使える「/design」コマンドの早期プレビュー公開を案内しました。Claude Code DesktopまたはCLIから、機能について複数の案を作るよう依頼し、好みのアートボードを選び、編集して実装へ進む流れが示されています。

同氏の追加投稿によれば、利用前には最新版へ更新するよう案内されています。また、Claudeがコードベースを読み、既存UIのスタイルに合わせて、共有可能なモックをArtifactとして作ると説明されています。Claude Designで使われてきた編集機能とプロンプトによる操作が、Claude Codeから利用できる形になったという位置づけです。

この発表だけを見ると新機能に見えますが、設計とコードの連携自体は、Anthropicが2026年6月17日に公開した公式記事ですでに説明されていました。同記事では、Claude DesignからClaude Codeへ作業を引き継ぐ流れに加え、Claude Codeから「/design」を使い、デザインプロジェクトの作成・編集・同期を行う方向が示されています。コードベースへのデザイン取り込み、コードからのライブプロトタイプ化、設計から実装までの継続も例として挙げられています。

今回の8月17日の案内で具体化したのは、「実装前に複数案を出し、選択・編集してから実装する」という使い方です。6月の公式記事がデザインとコードの接続範囲を広く説明しているのに対し、8月の投稿は実装前の画面案比較という入口を明確にしています。

一方、提供範囲については慎重に読む必要があります。8月の投稿は「早期プレビュー」と明記しています。AnthropicのヘルプセンターにはClaude Designの開始案内ページが存在しますが、今回提供された本文抜粋からは、「/design」の対象プラン、地域、組織設定、段階的な提供条件までは確認できません。本記事では、全利用者が同じ条件で使える一般仕様とは扱いません。

なぜ重要か

重要なのは、画面を作る速度そのものより、実装へ入る前に比較できる判断材料が増えることです。従来、文章の要件だけで合意した場合、担当者ごとに想像しているレイアウトや操作順が異なり、実装後に認識差が表面化することがあります。「/design」で複数案を先に可視化できれば、どの方向を採用するか、何を直すか、そもそも実装すべきかをコード変更の前に話し合えます。

Anthropicの7月24日の記事では、Claude Designを作ったNate Parrott氏が、設計案を早い段階で探索・反復・共有する用途を説明しています。同氏は、当初、テキスト出力や画像を渡してデザインを依頼したものの、良い結果にならなかったと振り返っています。その後、HTMLを対話的な視覚表現として使い、ブランドのフォント、色、素材、原則をプロンプトへ整理したことで、製品文脈に合う出力へ近づけたと説明しています。

ここから得られる判断基準は明確です。生成された画面が見栄えよく見えるかだけではなく、既存製品の文脈が入力されているか、比較可能な複数案になっているか、人が採用理由を説明できるかを確認する必要があります。コードベースを読めることは有力な材料ですが、それだけで要件、ブランド、使いやすさ、実装妥当性が自動的に保証されるわけではありません。

複数出典の一致点は、既存の設計資産やコードを起点にし、設計と実装の間をつなぐ方向です。Anthropic公式記事とEngadgetの記事は、ローカルのコードベースや既存コンポーネントを反映し、画面画像だけを起点にせず実装へ引き継げる点を共通して説明しています。一方、8月のX投稿は早期プレビューとしての具体的な試し方を示し、6月の公式記事はデザインシステムの取り込みや同期を含む広い製品像を説明しています。この違いを混同せず、試行時には自分の環境で何が利用できるかを確認する必要があります。

実務でどう使うか

1．対象と成功条件を決める

最初に、何をデザインさせるかではなく、今回どの判断を終わらせたいかを決めます。対象は、境界が明確で比較しやすい一つの機能に絞ります。たとえば「設定画面全体」ではなく、「通知設定を追加するときの選択方法」のように限定します。

成功条件には、利用者が完了したい行動、必ず表示する情報、既存画面から変えてよい範囲、今回決めない事項を含めます。「良い感じ」「使いやすく」といった表現だけでは、案を比較できません。「主要操作が一つに見える」「既存の設定項目と区別できる」「追加説明なしで次の操作を選べる」など、関係者が同じ観点で確認できる言葉にします。

さらに、複数案に求める違いを指定します。単なる色違いではなく、情報の順序、操作の入口、確認方法など、判断したい論点が異なる案を求めます。採用基準を先に置くことで、生成物への好みの投票ではなく、業務要件に沿った比較へ変えられます。

2．入力と権限を確認する

次に、Claudeが参照するコードベースと設計資産の範囲を確認します。X投稿では、Claudeがコードベースを読み、UIスタイルに合わせると説明されています。公式記事では、GitHubリポジトリ、デザインファイル、アップロードした素材から、一つまたは複数のデザインシステムを取り込む流れも示されています。

ただし、参照できることと、参照させてよいことは別です。試行前に、対象リポジトリへ機密情報や不要な顧客データが含まれていないか、組織の利用規則に合うか、変更対象を限定できているかを確認します。本記事の出典だけでは、個別環境におけるデータ処理条件や管理設定までは確定できないため、組織の契約条件と管理画面を別途確認する前提です。

入力には、対象機能、利用者、達成したい行動、既存コンポーネント、守るべき表示ルール、複数案で変える論点をまとめます。ブランド名や抽象的な雰囲気だけに頼らず、使用可能な部品や既存パターンを示します。Nate Parrott氏の記事でも、ブランドのフォント、色、素材、原則を整理したことが出力改善につながったと説明されています。

3．小さく実行する

早期プレビューを試す場合は、最新版で利用できることを確認したうえで、小さな機能について複数案を依頼します。X投稿で示された基本形は、「ある機能についていくつかの案を作る」という依頼です。最初からアプリ全体の再設計や、本番実装までを一括で任せるのではなく、一つの判断単位で試します。

出力後は、各案の違いを言葉にします。「案Aは操作数が少ない」「案Bは説明量が多い」「案Cは既存パターンとの共通性が高い」のように、比較軸へ戻して整理します。違いが説明できない場合は、案数があっても実質的な選択肢になっていません。その場合は、変更する論点を指定して再生成します。

選んだアートボードは、そのまま正解として実装へ渡さず、不要な要素を削り、文言や状態変化を編集します。今回の公開案内は、好みのアートボードを選び、編集して実装する流れを示しています。ここでの「好み」は入口にすぎません。最終判断では、対象利用者の行動、既存UIとの整合、実装時に必要な状態や例外を確認します。

なお、本記事のためのComputer Useによる実デモ記録は提供されていません。そのため、コマンドが実際に表示した画面、生成時間、成功率、編集操作の詳細、実装結果について、筆者の体験としては記載しません。

4．結果を評価して見直す

評価では、画面の美しさ、要件適合、既存資産との整合、実装可能性を分けて確認します。第一に、利用者が目的の操作へ進めるか。第二に、必要な情報と状態がそろっているか。第三に、既存コンポーネントやブランド原則から外れていないか。第四に、選んだ案を実装したときの例外処理や保守負担を説明できるかを見ます。

デザイナーは視覚階層と一貫性、開発者はコンポーネントの再利用性と状態設計、企画担当者は業務要件と優先順位を確認します。三者の評価が割れた場合は、生成を繰り返す前に、成功条件の曖昧さを見直します。条件を変えずに案だけ増やすと、比較対象が増える一方で判断が進まないためです。

採用案には、採用理由、残った懸念、実装前に確認する項目を添えます。不採用案にも理由を残すと、後から同じ方向を再生成したときに判断を再現できます。最終的な目的は、AIに決めてもらうことではなく、人が比較可能な材料を使って、実装前の合意を早めることです。

適用イメージ

一つ目は、業務システムへ新しい絞り込み機能を追加する場面です。入力するのは、既存の一覧画面、利用可能な検索部品、必須の絞り込み条件、利用者が結果へ到達するまでの流れです。「常時表示」「折りたたみ」「段階選択」など論点の異なる案を作り、Claudeには既存UIに合わせたモックを生成させます。人は、条件の見つけやすさ、一覧の表示領域、既存操作との一貫性を比較し、採用案を決めます。

二つ目は、SaaSの初期設定フローです。入力は、完了させる設定項目、順序に依存する項目、途中で省略できる項目、既存コンポーネントです。処理では、1画面型、段階型、必要時に説明を開く型などを比較します。企画担当者は要件漏れ、デザイナーは情報量と誘導、開発者は状態管理と再利用可能な部品を確認します。見た目が簡潔でも、必須条件や戻る操作が表現されていなければ不採用にします。

三つ目は、既存製品へ通知設定を追加する場面です。入力は、通知の種類、利用者が選べる単位、現在の設定画面、変更確認の要否です。Claudeには、既存コードベースのUIスタイルを踏まえながら、選択方法の異なる案を作らせます。人は、誤操作の可能性、設定状態の理解しやすさ、既存コンポーネントで実装できるかを確認し、必要なら採用案を編集してから実装へ渡します。

注意点

「/design」は早期プレビューとして案内されています。本記事の出典からは、すべての利用者、プラン、地域、組織で同じように使えるとは確認できません。利用できない場合に、設定不足や操作ミスだと即断しないことが重要です。最新版への更新という案内はありますが、それだけで提供対象になるとは限りません。

対象外にしたいのは、画面案だけでは安全性や正しさを判断できない業務です。法的表示、アクセシビリティ、セキュリティ、個人情報の扱い、重大な誤操作を防ぐ設計は、生成されたモックの印象だけで承認できません。専門要件と組織の審査を別に通す必要があります。

失敗条件は、複数案の違いを説明できない、既存UIの表面的な色だけを似せている、必要な状態や例外が欠けている、採用理由を関係者が言語化できない、実装可能性を確認せずコード化へ進む場合です。コードベースを読んだという説明があっても、出力がすべての設計規則へ適合したと仮定してはいけません。

また、Claude Designの公式記事では、デザインシステムの取り込み、出力の確認と修正、管理者による標準システムの承認と編集制限が説明されています。しかし、これらの説明を、今回の早期プレビュー環境ですべて同条件で利用できるという根拠にはできません。試行時は、実際に表示される機能と組織設定を確認し、出典間の説明範囲を分けて判断してください。

まとめ

Claude Codeの「/design」は、実装前に複数の画面案を作り、選択・編集して実装へつなぐ早期プレビューです。価値は、生成された案をそのまま採用することではなく、コードを書く前に関係者が比較できる状態を作る点にあります。

実務では、対象と成功条件を決め、参照させる入力と権限を確認し、小さな機能で複数案を作り、人が要件適合・既存資産との整合・実装可能性を評価します。コードベースやデザインシステムを起点にできても、要件の不足や判断責任までは自動化されません。「何を作れたか」より、「なぜこの案を選ぶのかを説明できるか」を導入判断の基準にしてください。

更新を見逃したくない方は、このアカウントをフォローしてください。