監修：岩田 侑城（株式会社LeapAI 代表取締役CEO）
Claude Designに「/design」登場｜デザインと実装をつなぐ判断ガイド
Anthropicは、Claude Designとターミナル上の開発作業を行き来できる「/design」を発表しました。既存のデザインシステムを使い、デザインの作成・編集・同期から実装への引き継ぎまで進められます。本記事では、発表内容とDesignプラグインを混同せず、導入前に確認すべき条件と実務手順を整理します。
何が起きたか
結論から言うと、今回の変更は、デザインと実装を別々に生成するのではなく、既存のコンポーネントや作業内容を引き継ぎながら往復できるようにしたことです。
Anthropicは2026年6月17日、Claude Designの更新を発表しました。公式発表では、主に次の変更が示されています。
GitHubリポジトリ、デザインファイル、直接アップロードから、1つまたは複数のデザインシステムを取り込める
Claudeが既存コンポーネントを使って制作し、出力をデザインシステムと照合して、表示前に修正する
大規模なチームでは、管理者が標準のデザインシステムを承認し、編集を制限できる
「/design-sync」でデザインシステムを取り込み、Claude Designでの制作を既存コンポーネントから始められる
デザインから実装へ移る際、画像だけを手掛かりに最初から作り直すのではなく、それまでの作業を引き継げる
「/design」により、ターミナルを離れずにデザインプロジェクトを作成・編集・同期できる
デザインをコードベースへ取り込む、コードを動くプロトタイプにする、プロジェクトを継続して進める、といった使い方が示されている
公式ブログによると、Claude Designにはデスクトップアプリのサイドバー内に新しい入口も設けられました。同記事は、最初の1週間に100万人を超える利用者がClaude Designを使ったとも説明しています。ただし、この数値は利用人数を示すものであり、制作時間の削減率や成果物の品質を保証する指標ではありません。
ここで区別したいのが、「/design」とDesignプラグインです。
「/design」は、公式ブログで説明された、ターミナルからデザインプロジェクトを作成・編集・同期するための操作です。一方、Anthropic VerifiedのDesignプラグインは、デザインレビュー、デザインシステム管理、UXライティング、アクセシビリティ監査、リサーチ統合、開発者への引き継ぎを支援する別の拡張機能です。
公開リポジトリのREADMEでは、Designプラグインは主にCowork向けに設計されつつ、ターミナル側の環境でも動作すると説明されています。明示的なワークフローとして、構造化されたデザインレビューを行う「/critique」、デザインシステムを監査・文書化・拡張する「/design-system」、開発者向け仕様を作る「/handoff」などが掲載されています。
つまり、「/designを使えば、すべてのデザイン業務を自動で完了できる」という発表ではありません。今回の中心は、Claude Designと実装工程の間で、デザインシステムと作業コンテキストを維持しやすくしたことです。Designプラグインは、その周辺にあるレビューや文書化などを支援します。
なぜ重要か
重要なのは、生成できる画面の種類が増えたことより、デザインと実装の受け渡し方が変わる可能性がある点です。
従来、デザイン案を実装へ渡す場面では、画像を見ながらコンポーネント、状態、余白、文言、操作を読み直す必要がありました。今回の公式発表は、デザインが完成した後も既存の作業を引き継ぎ、画像から開始し直さずに実装へ進める方向を示しています。
業務への影響は、次の3点に整理できます。
第一に、既存資産を起点にしやすくなります。GitHubリポジトリ、デザインファイル、直接アップロードからデザインシステムを取り込めるため、毎回ゼロから見た目を指示するのではなく、既存コンポーネントを制作条件として渡せます。
第二に、デザインと実装の間で認識が途切れにくくなります。公式ブログでは、Claude Designから実装へ渡す場合と、ターミナルからデザインを始める場合の両方向が説明されています。企画、デザイン、実装を完全に独立させるのではなく、同じプロジェクトを段階的に育てる考え方です。
第三に、チーム標準を管理する選択肢があります。公式発表には、管理者が標準システムを承認し、編集を制限できる仕組みが記載されています。個人が自由に生成するだけでなく、会社のガイドラインに合わせる運用を想定した変更と読めます。
ただし、導入判断は「新機能があるか」だけで決めるべきではありません。一次情報から導ける判断基準は、次の通りです。
1. 再利用できるコンポーネントやトークンがすでに存在するか
2. デザインと実装の間で、同じ内容を作り直す負担が発生しているか
3. チームで承認すべき標準と、担当者が変更できる範囲を分けられるか
4. 出力後に、デザイナーや実装担当者が確認する工程を置けるか
5. 必要なのが制作と同期なのか、レビューやUXライティングなどの支援なのかを区別できているか
特に、整備されたデザインシステムがない組織では、同期機能を導入しても基準そのものが曖昧なままです。その場合は、まず既存コンポーネント、命名、状態、利用ルールを整理する必要があります。
実務でどう使うか
1. 対象業務と完成条件を決める
最初に、「新しい画面を作る」「既存画面を直す」「コードからプロトタイプを作る」のどれを行うか決めます。対象ユーザー、主要タスク、必要な状態、確認担当者も明文化します。
完成条件を「見た目が整っている」にすると判断がぶれます。「既存コンポーネントだけで構成されている」「主要な操作状態が定義されている」「実装担当者が確認できる」といった条件へ分解してください。
2. デザインシステムの入力元を選ぶ
公式発表で示された入力元は、GitHubリポジトリ、デザインファイル、直接アップロードです。複数のデザインシステムも取り込めるとされています。
ただし、複数のシステムを渡す場合は、どのプロジェクトでどれを優先するかを人が決める必要があります。色や余白、同名コンポーネントの定義が競合している状態では、一貫性の確認が難しくなります。
3. 「/design-sync」で既存部品を同期する
デザイン側から始める場合は、公式ブログに記載された「/design-sync」でデザインシステムを取り込みます。目的は、自由な作図を始めることではなく、既存コンポーネントを出発点にすることです。
同期後は、利用されたコンポーネント、色、文字、状態が組織の基準と一致しているか確認します。Anthropicは、Claudeが出力をデザインシステムと照合して修正すると説明していますが、人による受け入れ確認が不要になるとは述べていません。
4. 「/design」で作成・編集・同期する
ターミナル側から始める場合は、「/design」でデザインプロジェクトを作成・編集・同期する流れが示されています。公式ブログには、デザインをコードベースへ取り込む、コードを動くプロトタイプにする、プロジェクトを継続して進めるという用途が挙げられています。
入力には、対象画面、利用する既存部品、必要な状態、変更してよい範囲、変更してはいけない範囲を含めます。曖昧な依頼だけで進めず、確認可能な制約として渡すことが重要です。
5. レビューと引き継ぎを分けて確認する
制作後は、見た目と実装可能性を別々に確認します。Designプラグインを利用する場合、公開情報上は「/critique」でユーザビリティ、視覚的な階層、アクセシビリティ、一貫性の観点からレビューでき、「/handoff」で寸法、トークン、状態、操作などの引き継ぎ仕様を扱えます。
ただし、これらは「/design」と同じコマンドではありません。必要なワークフローを整理し、制作、レビュー、引き継ぎのどこに拡張機能を使うか決めます。
6. 人が差分を承認してから実装へ進める
最後に、デザイナーはブランドと操作性、実装担当者は既存コードとの整合性、業務責任者は要件との一致を確認します。
確認対象は、使われたコンポーネント、画面状態、UX文言、アクセシビリティ上の懸念、既存箇所への影響です。管理者による標準システムの承認や編集制限を使える場合でも、個々の成果物が業務要件を満たすかは別途確認します。
適用イメージ
新しい業務画面の試作
入力は、対象ユーザー、実行したい業務、必要な画面状態、既存コンポーネントです。Claude Designでは、取り込んだデザインシステムを前提に案を作り、必要に応じて編集します。その後、作業内容を引き継いで実装工程へ移します。
人は、業務手順の抜け、エラー時の状態、既存部品との一致を確認します。正常時の画面だけでなく、未入力、処理中、完了、失敗など、業務に必要な状態がそろっているかを見ることが重要です。
既存画面の改善
入力は、現在の画面やコード、変更目的、維持すべきコンポーネント、変更禁止領域です。処理では、既存資産を基準にデザイン案を作成・編集し、必要ならDesignプラグインのレビュー機能でユーザビリティや一貫性を点検します。
人は、改善前後の差分が目的に沿っているか、ブランドや操作方法を不必要に変えていないかを確認します。生成された案が見栄えのよい全面刷新になっても、依頼が部分改善なら採用しない判断が必要です。
開発者への引き継ぎ整理
入力は、確定したデザイン、利用コンポーネント、状態、操作、実装上の制約です。Designプラグインの公開説明では、開発者への引き継ぎが対象業務に含まれ、READMEでは「/handoff」が寸法、トークン、状態、操作などの仕様を扱うとされています。
人は、生成された仕様が実際のデザインと一致するか、既存コードに存在しない要素が混ざっていないか、未決事項が確定事項として書かれていないかを確認します。引き継ぎ資料の生成と、実装可否の承認は分けて扱います。
注意点
第一に、「/design」、Claude Design、Designプラグインを同じものとして扱わないでください。公式ブログはデザインと実装の同期を説明し、プラグインの公式ページとREADMEはレビュー、UXライティング、アクセシビリティ監査、リサーチ統合、デザインシステム管理、引き継ぎなどを説明しています。導入前に、どの機能がどの提供物に属するかを確認する必要があります。
第二に、提供条件をこの記事だけで決めないでください。Anthropic SupportにはClaude Designの開始方法を扱う文書が存在しますが、提示された本文情報からは、利用可能なプラン、地域、管理設定、段階的提供の詳細までは確認できません。実際の導入時には、対象アカウントで表示される案内と最新の公式文書を確認してください。
第三に、プラグインは信頼性と権限を確認してから導入します。Claude Codeの公式ドキュメントでは、プラグインがスキル、エージェント、フック、MCPサーバーを追加できると説明されています。マーケットプレイスを追加する操作と、個別プラグインをインストールする操作は別です。公式マーケットプレイスは初回の対話利用時に自動追加されるとされていますが、ネットワークやポリシーによって追加できない場合も示されています。
第四に、デザインシステムの品質以上の一貫性は期待できません。古い部品、重複したトークン、曖昧な利用規則を取り込めば、参照元の問題も作業へ持ち込まれます。同期前に、正しい入力元と優先順位を決めてください。
第五に、人の判断を外さないことです。公開情報は、ブランド適合、レビュー、アクセシビリティ監査、引き継ぎを支援する機能を説明していますが、すべての出力が自動的に正しいことや、特定のアクセシビリティ基準への適合を保証するとは記載していません。
対象外になりやすいのは、デザインシステムが存在せず完成条件も決められない案件、入力元の利用権限を確認できない案件、生成結果を確認する担当者がいない案件です。また、複数のデザインシステムが競合している、変更禁止範囲を指定していない、レビュー結果を無条件で採用するといった運用は失敗条件になります。
なお、この記事ではComputer Useによる実デモを行っていません。確認日時、操作環境、入力、画面上の観察結果を伴うデモ記録が提供されていないため、操作体験、生成品質、所要時間、成功率については主張していません。記載内容は、提示された公式発表、公式文書、公式プラグインページ、公開リポジトリの情報に限定しています。
まとめ
「/design」の最大の変化は、デザインと実装を別々の成果物として作り直すのではなく、既存のデザインシステムとプロジェクトの作業を引き継ぎながら往復できるようにした点です。
導入時は、次の順で判断すると整理しやすくなります。
1. 対象業務と完成条件を決める
2. 正しいデザインシステムを選ぶ
3. 既存コンポーネントを同期する
4. 作成・編集する範囲を明示する
5. レビューと引き継ぎを分ける
6. 人が差分を承認する
制作と同期が目的なら「/design」とClaude Designの連携を確認し、デザインレビュー、UXライティング、アクセシビリティ監査、リサーチ統合、引き継ぎが目的ならDesignプラグインの対象範囲を確認します。この区別が、機能への期待と実際の運用を合わせる最初の判断基準です。
更新を見逃したくない方は、このアカウントをフォローしてください。
出典
この記事の監修者
新卒で株式会社リクルートに入社し、HR領域のマーケティング業務に従事。2024年9月に株式会社LeapAIを創業し、生成AIによる業務の自動化とAI動画制作で企業の事業成長を支援している。事業売却の経験を持ち、戦略の設計から実行までを一貫して担う。
※本記事は生成AIを活用して制作しています。内容はLeapAI編集部がファクトチェックおよび編集を行い、 図解・画像は生成AIで作成したもの、または実際のサービス画面を掲載しています。
AI顧問のサービス紹介資料を無料で受け取る
