Claude Code /design実践ガイド|UIを先に決めて実装する
「デザイナーが必要としていたのは、これだ」。UIデザイナーのOliur氏はそう書いた。ほぼ同じタイミングで、Jordan氏(@jstamby)はこう投げつけている。「デザイン機能は、いまだにトークンを食いすぎる」(いずれも原投稿は未確認で、explainx.ai が紹介した内容にもとづく筆者訳。訳語は原文と一部異なる可能性がある)。
同じ機能に対する評価が、絶賛と拒絶にきれいに割れた。2026年8月17日(米国時間)にAnthropicがClaude Codeへ追加した /design スキルの話だ(出典: PC Watch、2026年8月19日)。ターミナルから抜けずにUI案を複数枚出し、気に入った1枚を選んで、そのまま実装させる。文章にすると地味だが、この順序が変わることの意味は小さくない。
- UIの方向性が決まらないまま実装に着手して、作り直した経験のあるエンジニア
- デザイナーが不在の個人開発・小規模チームでプロダクトを作っている方
- Claude Designを触ったが、コードへの受け渡しが面倒で離脱した方
- 研究プレビュー機能を業務に入れるかどうか、線引きの基準がほしいPM
- 実行: ターミナルまたはデスクトップ版で
/designに続けて作りたい画面を説明するだけ - 必要条件: Claude Code v2.1.233以降。Pro / Max / Team / Enterpriseプランが対象(出典: Claude Code Docs, Week 34、2026年8月時点)
- 出力: 編集可能なアートボードが並ぶ公開キャンバスのURLがターミナルに出る。選んで、直して、実装させる
- 土台: Artifacts(生成物を共有URL付きのページとして公開するClaudeの機能)の上に構築。URLを渡せばチームでも見られる
- 注意点: 複数案の同時生成は通常の会話より重い。ただし2026年6月の改善後は「1タスク2〜6%」という検証報告もある。まず自分の環境で1度測るのが現実的
- 位置づけ: 研究プレビュー(正式提供前の試験公開。予告なく仕様変更や提供停止がありうる段階)。業務のクリティカルパスには置かない
Claude Codeの/designスキルで実際に何が起きるのか
アートボードは、Figmaなどのデザインツールが使ってきた考え方で、1画面ぶんを載せて操作できる作業用のキャンバスを指す。/design は、Anthropicが2026年4月17日に公開したClaude Design(出典: TechCrunch、2026年4月17日)のアートボード運用を、そのままCLIとデスクトップ版に持ち込んだものだ(出典: Claude Code Docs - What’s new, Week 34)。
公式ドキュメントの説明はこうだ。
/designスキルは、Claude Designのアートボードワークフローを、Artifactsの上に構築する形でCLIとClaude Code Desktopに持ち込む。ブリーフを添えて実行すると、ClaudeがUI用の編集可能なアートボードを並べたキャンバスを公開する。1つ選び、手を入れ、そのうえでClaudeに実装させる(出典: Claude Code Docs, Week 34ダイジェスト)
公式が挙げている実行例は、抽象度がかなり高い。
> /design redesign the composer based on what people actually use it for
「実際にどう使われているかを踏まえて入力欄を作り直して」。ワイヤーフレームも仕様書も渡していない。ここで効いてくるのが、Claude Codeがすでにコードベースを読んでいるという前提だ。Claude Designを手掛けたAnthropicのプロダクトデザイナー、Nate Parrott氏は、この機能について「既存のコードベースを読み、現在のUIスタイルに合わせ、共有可能なモックアップをArtifactsとして作る」と説明したと報じられている(the-decoderの報道を筆者が翻訳したもので、Anthropicの公式声明ではない。出典: the-decoder、2026年8月18日)。
つまり /design の本体は描画エンジンではなく、コードベースという文脈を持ったままデザイン案を出せるという一点にある。claude.ai/design を別タブで開いて、出力をコピーして貼り戻す手間がなくなった、と説明されているのはそのためだ。
Claude Code /designの使い方:選ぶ、直す、実装させる
手順は3つの動詞に収まる。
1. バージョンを確認する。 claude --version を実行し、v2.1.233未満なら claude update で更新する。公式ドキュメントは「v2.1.233以降が必要」と明記している(出典: Claude Code Docs, Week 34)。直近のバージョンで何が入ってきたかはClaude Code アップデートまとめに整理してある。
2. ブリーフ(作りたい画面の要件メモ)を添えて実行する。 /design a few options for [機能名] のように、案を複数出させる書き方が開発者から共有されている(出典: Nate Parrott氏のX投稿)。ターミナルに公開キャンバスへのリンクが出るので、ブラウザで開く。
3. 選んで、直して、実装させる。 色を変える、ブロックを動かす、余白を広げる。納得できる状態になってから、Claudeにどの案を実装するか伝える。Anthropicの開発者向けアカウントもこの流れを「1つ選び、手を入れ、そしてClaudeに実装させる」と3段階で説明している(出典: @ClaudeDevs)。
ここで手動保存を挟むのを勧めたい。海外メディアの報道では、生成したデザインを実装工程に渡す前に自分で保存しておく必要があるとされている(出典: the-decoder)。研究プレビュー段階の機能に、生成物の永続化まで任せない方が安全だ。
/designで先行ユーザーが踏んだ地雷:トークン消費とデザインシステム継承
新機能の紹介記事だけを読むと、うまくいった話しか出てこない。実際に触った人の記録を並べると、輪郭がはっきりする。
トークン消費の重さ。 冒頭のJordan氏の指摘は /design 単体の話ではなく、Claude Designの描画ワークフロー全般に向けられてきた不満だ。ただしClaude Codeの中では効き方が違う。コーディングセッションはすでにコードベース、会話履歴、接続ツールで文脈を消費している。その上に複数のアートボードを重ねる。AI UIデザインツールを提供するuxpilot.ai(Claude Designと競合しうる立場である点に留意)は、/design 公開前のclaude.ai側のClaude Designについて、2026年5月時点の検証で「Proプランの週次クレジットを5プロンプト・36分で使い切った」と報告している(出典: uxpilot.ai、2026年5月4日)。
ただしこの数字は6月の大型アップデート以前のものだ。2026年6月17日、Anthropicは1ターンあたりの平均トークン消費を下げ、小さな調整のたびにモデルのターンを消費しないドラッグ&リサイズ編集を追加している(出典: VentureBeat、2026年6月17日)。実際、91works CTOのYoshikiAgatsuma氏はアップデート後の検証で、1タスクあたりの消費は2〜6%程度で、思ったより軽かったと書いている(割合の分母は原文で明示されていない。出典: Zenn、2026年6月19日)。数字は作業内容で大きく振れる。重いという前提を持ちつつ、自分の環境で1度測るのが現実的だ。Claude Codeの新機能でトークンが想定外に溶けた実例はUltracodeで170万トークンが消えた検証にまとめてある。
デザインシステムの継承が確実ではない。 ここは情報が割れている。Anthropic側は既存のUIスタイルに合わせると説明する一方、explainx.aiは研究プレビュー段階で自動継承が確認できておらず、コンポーネントのパスを手動で添える必要がある場合があると指摘している(出典: explainx.ai)。Hacker Newsでは、Claude Codeが生成したCSSで色やクラスが何重にも重複し、インラインでハードコードされたスタイル指定が混ざっていたという報告が出ている(出典: Hacker News、2026年4月。Claude Design公開直後の議論であり、6月のデザインシステム取り込み対応より前の話である点に注意)。既存プロダクトに使うなら、生成物のCSS変数の使われ方を必ず確認したい。
抽象的な指示は凡庸な結果になる。 Agatsuma氏は、雑なプロンプトで試した回について「まあよくみるやつでした」とも書いている。一方、具体的なブリーフを与えたサイトのリニューアル検証では「デザインの『深さ』みたいなものが出てきた」と評価が反転している。同じ機能で結果が割れる要因の大部分は、入力側にある。実際に効くブリーフは、たとえばこう書く。
> /design 記事一覧ページのカード案を3つ。src/components/ArticleCard.astro と tailwind の設定を踏襲。1カードにサムネ・カテゴリ・タイトル・投稿日を載せる。PC3カラム、スマホ1カラム
参照させたいファイルのパスと、載せる要素、レイアウトの条件。この3点を書くだけで出力の質はかなり変わる。
細部の実装は別問題。 株式会社ライトコードの検証記事(2026年7月21日)は、より踏み込んだ制約を挙げている。画像はプレースホルダーのみで生成されない。レスポンシブ対応は明示的に指示しないと入らない。スワイプなどの複雑なジェスチャーは不安定で、クリックやホバーのような単純な操作なら安定する。alt属性やARIAといったアクセシビリティ対応もデフォルトでは付かない(出典: ライトコード)。アクセシビリティが自動で付かない点は、公開プロダクトを作るなら実装側で必ず埋める必要がある。
Claude Designそのものを先に把握しておく
/designはClaude Designの機能をCLIに持ち込んだものなので、元の設計思想を知っておくと理解が早い。トークン消費の改善とデザインシステム取り込みについては、6月の大型アップデート記事にまとめてある。
/designはFigmaを置き換えるのか
この機能が出るたびに同じ問いが立つ(AI設計ツールの発表でFigma株が下げた一件もあった)。答えは、少なくとも2026年8月時点では「置き換えない」だ。
uxpilot.aiのレビューは(2026年5月時点、6月に直接編集が入る以前のものだが)、ピクセル単位の手動編集エディタがないこと、Figmaへのネイティブ書き出しがないことを制約として挙げている。前者は6月のドラッグ&リサイズ編集である程度埋まった。一方、書き出しがない状態は8月時点でも変わっていない(6月に入ったのはFigmaからのインポート側だ)。デザイン成果物の管理にFigmaを使っているチームなら、この非対称性は運用上かなり重い。
Hacker Newsでは、Claude Designが扱えるのは末端のノード(leaf-node、画面ツリーの一番先にある個別の見た目部品)であって、デザインにはもっと長いライフサイクルがある、という批判が出ている(出典: Hacker News のユーザーjmull氏の投稿、2026年4月)。
実務的に落ち着いている使い分けは、Agatsuma氏が書いている運用だ。「Claude上でデザインとコードを行き来して試行錯誤し、確定したものをFigma側で管理する」。探索フェーズはClaude、資産管理はFigma。この線引きは、/design にもそのまま当てはまる。
Claude Design本体との棲み分けは、こう整理できる。
| 用途 | /design(Claude Code) | claude.ai/design |
|---|---|---|
| 想定する場面 | 今から自分で実装する画面の方向性決め | 関係者との合意形成、資料化 |
| 起点 | 開いているコードベース | ブラウザ上のプロジェクト |
| レビュー相手 | 自分、またはURLを渡せる開発者 | ターミナルを触らないPM・デザイナー |
| 書き出し | 実装コードとしてリポジトリへ | PDF / PPTX などの形式 |
なお、デザインシステム自体はClaude Code側にも取り込める。2026年6月の大型アップデートで入った /design-sync がそれで、チーム標準を守らせたい場合はこちらと組み合わせることになる。
PMの自分(電脳狐影)が/designを使う場面・使わない場面
自分はPMで、コードを書くのは自分のブログや個人ツールの範囲だ。その立場から書くと、/design は新しい画面をゼロから起こすときだけ使い、既存画面の微調整には使わない。
理由は3つある。
1つ目。個人開発で一番時間を溶かすのは、実装が半分終わったあとで「やっぱりこのレイアウトは違う」と気づく瞬間だ。手戻りのコストは、案を3枚見比べるコストよりはるかに高い。実装前に分岐を潰せるなら、多少トークンを払う価値がある。
2つ目。逆に、ボタンの余白を2px広げるといった調整に複数アートボードを生成させるのは、明確に無駄だ。この用途には6月に入ったドラッグ&リサイズ編集か、単純にコードを直接いじる方が速い。同じ機能でも、使う場面を間違えると評価が反転する。冒頭で紹介した2つの反応が真逆だったのは、たぶん見ていた場面が違うからだ。
3つ目。研究プレビューという但し書きを、自分は額面どおり受け取っている。Claude Codeの機能は前提が短期間で変わる。プラグインやArtifactsも、数か月単位で挙動が変わってきた。だから生成物は必ずリポジトリに保存し、機能が消えても手元に残る形にしておく。
期待していないこともはっきり書いておく。この機能でデザイナーが不要になるとは考えていない。/design が出すのは1画面の見た目であって、情報設計でも、状態遷移でも、運用しながら育てるデザインシステムでもない。先ほど引いたHacker Newsの、扱えるのは末端のノードにとどまるという指摘は、たぶん正しい。埋まるのは、デザイナーがいない開発者が抱えていた「何もない状態から1枚目を出す」コストだけだ。それでも、その1枚目が出ないせいで止まっていた個人開発は、世の中にかなりある。
claude --versionでv2.1.233以降か確認する(公式が明記する最低要件)- 無料プランは対象外。Pro / Max / Team / Enterpriseのいずれかが必要
- 利用上限が近いセッションでは実行しない。複数案の同時生成は通常の会話より重い
- 既存プロダクトに使う場合、生成物がデザインシステムの変数を使っているか確認する。色のハードコードが混ざる報告あり
- 画像・レスポンシブ対応・alt属性やARIAは自動では入らない。実装側で埋める
- 実装工程に渡す前に生成物を手動で保存する。研究プレビュー段階の機能に永続化は任せない
- チーム標準を守らせたいなら、
/design-syncでデザインシステムを取り込む運用も検討する
トークン上限で詰まる前に読んでおく
複数案の同時生成は、セッションを確実に重くする。Claude Codeの新機能でトークンが一気に溶けた実例と、上限に当たる前の止め方をまとめてある。
関連記事
- Claude Designが正式公開|Figmaの対抗馬になるのか
- Claude Design 6月大型アップデート|デザインシステム取り込みとトークン問題の是正
- Claude Code Artifacts完全ガイド|セッションの成果を共有ページにする
- Claude Code Concise設定の落とし穴|文字数35%減の検証データ
- Claude Code プラグイン完全ガイド|導入から厳選おすすめ・落とし穴まで
- Ultracodeで170万トークンが消えた: Claude Code最新機能の実際のリスク
- Claude Opus 4.7とAI設計ツール同時発表|Figma株が下げた全内幕
免責事項
- 本記事の情報は2026年8月23日時点のものである。
/designは研究プレビュー段階の機能であり、仕様・提供範囲・対象プランは予告なく変更される場合がある。最新の情報は公式ドキュメントを参照のこと。 - 引用した英語の投稿および記事は、原文からの筆者による翻訳であり意訳を含む。冒頭のOliur氏・Jordan氏の発言は原投稿を直接確認しておらず、explainx.aiが紹介した内容にもとづく。
- 本記事で紹介したトークン消費の数値は、uxpilot.ai、Zenn(YoshikiAgatsuma氏)、株式会社ライトコードなど各第三者が公表した検証結果であり、筆者が独立に再現検証したものではない。検証時期がそれぞれ異なる点に留意されたい。特にuxpilot.aiおよびHacker Newsの引用は、2026年6月のアップデート以前の状態に対する評価である。
- 第三者の検証記事には、対象製品と競合関係にある事業者によるものが含まれる。評価の位置づけを踏まえて読まれたい。
- 対象プランや提供条件は執筆時点の公表情報に基づく。プラン内容・価格・利用上限は提供元の判断で変更される場合があり、日本国内での課金には別途消費税が加算される場合がある。契約前に必ず公式の料金ページを確認すること。
- 機能の利用にあたっては、必ず公式ドキュメントと自身の契約プランを確認すること。本記事の情報に基づく操作により生じたいかなる損害についても、筆者は責任を負わない。
- 本記事はAnthropic社およびその関連会社と提携・提供関係にあるものではなく、内容は筆者独自の見解である。
※ 記載の会社名・製品名は各社の商標または登録商標です。