結論|コードを書く前に、触れる画面を出すコマンド
Claude Code の /design は、1 行の指示から複数のアートボードが並ぶデザインキャンバスを組み立て、Artifact として公開します。
出てくるのは画像ではありません。リンクを開くと、その場で要素を選び、文字を打ち替え、色を変えられる編集画面が立ち上がります。デザイナーでない人に URL を 1 つ渡せば、インストールも接続設定もなしで、その人の手で直せます。
いちばん効くのは、リポジトリの中で走らせたときです。/design は描き始める前に既存のデザインシステムを探しにいき、実際のコンポーネントから値を拾って画面を起こします。「まずうちの UI を再現して」と頼む手間がありません。逆に既存を外したいときは、そう書けば外してくれます。
| やりたいこと | 渡し方 |
|---|---|
| 実装前に画面の方向性を決めたい | /design 設定画面のレイアウトを 3 案 |
| 既存プロダクトに新しい画面を足す | /design 通知設定のモーダル |
| 触って確かめられる試作が欲しい | /design 料金ページのプロトタイプ |
| A4 1 枚の配布物を作りたい | /design 社内勉強会の告知チラシ |
| 既存を離れた刷新案がほしい | /design 料金ページの刷新案。既存のトーンは外して |
以下では、何が起きているのかを押さえたうえで、使い方・すごいところ・サブコマンド・制約の順に解説します。本稿は Claude Code v2.1.246 で確認した内容です。
補足
/design は Claude Design (claude.ai/design) のキャンバスエディタを Claude
Code
に持ち込んだ早期プレビューです。有効になっていない環境ではコマンド一覧に出てきません。
何が起きているのか
/design に指示を渡すと、Claude は 1 枚ずつ HTML ファイルを書き、それをキャンバスに並べて公開します。
flowchart LR
A["/design 作りたいもの"] --> B["既存のデザイン<br/>システムを読む"]
B --> C[".dc.html を書く<br/>1 ファイル = 1 アートボード"]
C --> D["canvas.json で<br/>座標とページを決める"]
D --> E["Artifact として公開"]
E --> F["ブラウザで編集 → Save"]
覚えておくと話が早いのは、次の 3 点です。
1 つ目は、.dc.html ファイル 1 つが 1 枚のアートボードになることです。ヒーロー案を 3 つ並べたいなら、ファイルが 3 つできます。それぞれが独立したプレビュー枠の中で描画されるため、案同士が干渉しません。
2 つ目は、canvas.json がレイアウトを決めることです。どのアートボードをどこに置くか、ページを分けるか、開いたときにどの画面を出すか。これらをこの 1 ファイルが持っています。
3 つ目は、成果物が Artifact として公開されることです。作業ツリーには元ファイルが残り、あとから直すときはそれを編集して作り直します。
使い方|1 行渡して、聞かれたことに答える
いちばん短い使い方は、作りたいものをそのまま書くことです。
/design 料金ページのヒーローを 3 案引数を付けずに /design 単体で打つと、何を何のために作りたいのかを 1 行で聞かれて止まります。急いでいるときほど、目的まで書いて渡したほうが往復が減ります。
聞かれるのは、多くて 2 つ
アプリや Web の UI を頼んだ場合、静止したモックアップか、押すと反応するプロトタイプか。どちらが欲しいのか指示から読み取れないと、1 度だけ確認が入ります。「クリックできる」「動く」「フロー」といった言葉が入っていれば、確認は省かれます。
もう 1 つは方向性です。参照するブランドもデザインシステムもない状態だと、勝手に 1 つ選ばずに、方向性の違う粗いスケッチを 2〜4 枚出して選ばせます。選択のための案なので、この段階では作り込みません。方向が決まったら、それを本命のアートボードに作り直します。
コツ
案を選ぶときは「Option B」のような名前が付きます。この名前は以降のやり取りでも変わりません。「B のヘッダーを A の余白で」のように、案をまたいで指示できます。
出てきたら、リンクを開く
公開が終わると、カードとリンクが返ってきます。開くとキャンバスが表示され、ピンチで拡大縮小、ドラッグで移動ができます。タッチ操作にも対応しています。
保存が有効なアカウントであれば、そこから先はブラウザの中の作業です。要素をクリックして選び、右のパネルで値を変え、テキストはダブルクリックで打ち替えます。編集は自分の画面に留まり、ヘッダーの Save を押した時点で全員向けの新しいバージョンとして公開されます。保存できない設定の場合は閲覧と書き出しだけになり、その旨が最初に伝えられます。
何がすごいのか
既存の UI に、頼まなくても寄せにいく
リポジトリの中で走らせたときの挙動が、このコマンドのいちばんの特徴です。
描き始める前に、tokens.css や theme 系のファイル、tailwind.config.* の theme 設定、design-system や ui や components といったディレクトリ、Storybook、アイコンセット、assets や public の下のフォントを探します。そのうえで、実際のコンポーネントのソースとスタイルシートから、色・文字サイズ・字の太さ・行間・余白・角丸・枠線・影・コントロールの高さ・アイコンサイズを拾います。
大事なのは、トークンを解決したあとの実値をそのまま使い、4px や 8px のグリッドに丸めないことです。ここが崩れると全体に響きます。丸めた瞬間に「似ているけれど違うもの」へ変わり、実装のときに全部やり直しです。
新しい UI も、その語彙を引き継いで作られます。同じトークン、同じコンポーネント、同じ密度です。
要点
参照できるコードがある場合、スクリーンショットは補助情報として扱われます。Claude はスクリーンショットより、コードとデザインコンテキストからのほうが正確に再現できます。両方渡せるなら両方渡してください。
振り切らせることもできる。ただし言わないと寄せる
寄せるのは既定の動きであって、/design の全部ではありません。
参照できるブランドもデザインシステムも見つからない場合、/design は逆に極端へ倒します。ブルータルなミニマル、マキシマリズムの混沌、レトロフューチャー、オーガニック、ラグジュアリー、プレイフル、エディトリアル、アールデコ、パステル、インダストリアルのうち 1 つを選び、最後まで貫く進め方です。書体は Arial や Inter のような無難な選択を避け、構図には非対称・重なり・斜めの流れ・グリッド崩しを使い、背景はベタ塗りで終わらせません。生成のたびに同じ選択へ収束しないことも、はっきり求められています。
既存の UI がある場合でも、頼み方で切り替わります。文言・色・要素 1 つといった小さな修正では、頼まれた箇所だけを変え、周りの余白やレイアウトには手を付けません。一方で刷新・新しい方向・ゼロベースを頼めば、大きく変えます。「刷新案がほしい」「既存のトーンは一度外して」と書けば、寄せにはいきません。黙っていると寄せる側に倒れる、というだけの話です。
方向が決まったあとに案を増やすときも、同じ美学の濃さ違いは出てきません。定石どおりの案の隣に、目新しいインタラクション・レイアウト・メタファー・スタイルを並べ、基本から冒険的な順に置きます。狙いは最良の 1 案ではなく、混ぜて選べる差分です。
コツ
軸を指定すると案が散ります。「エディトリアル寄り・ブルータリズム・パステルで 3 案」のように書けば、5 段階の濃さ違いではなく、性格の違う 3 案が並びます。
ただし、黙って「既存より良いもの」に差し替える動きはしません。改善が要ると判断した場合も、頼まれた分を仕上げたうえで提案する順序です。判断は人に残ります。なお、AI らしく見える手癖 (グラデーション背景の乱用、絵文字、角丸に左端のアクセント枠、Inter や Roboto といった書体) は、名指しで避けるよう指示されています。
1 枚ではなく、並べて選べる
キャンバスは案を並べるために作られています。方向性の違う案を横に並べ、それぞれに「何を狙った案で、代わりに何を捨てたか」が添えられます。自分の推し案にだけ理由が付いた比較は、比較になりません。
案が増えてきたら、pages でキャンバスを名前付きのページに分けられます。フロー一式とコンポーネント一覧、あるいは v1 と v2 のように、性質の違う集合を分ける使い方です。付箋も置けるので、決まっていない論点をその場に残しておけます。
印刷物がまともに出る
Web の画面だけでなく、チラシ・ポスター・折りパンフレット・A4 1 枚の資料も対象です。しかも扱いが雑ではありません。
寸法は 1 インチあたり 96px で、A4 が 794×1123px、Letter が 816×1056、Tabloid が 1056×1632、A5 が 559×794 になります。本文は 12 ポイント (16px) を下限とし、それより小さくしていいのは短いラベルと注記だけです。紙で消える細すぎる罫線や、インクを飲む大面積のベタも避けます。
ページ送りの扱いも分かれています。ポスターやパンフレットのようにページ構成が固定されたものは、1 ページ 1 アートボードの連番にします。社内メモや報告書のように流れる文書は、1 枚の長いアートボードにしてページ送りを任せます。PDF 書き出しの結果が変わるので、ここは先に決めておくと後が楽です。
押すと反応する試作まで作れる
静止画で終わりません。アートボードの中に状態を持たせて、クリックで色が変わるスウォッチや、選択されたサイズが切り替わるボタン列を作れます。料金ページの月額と年額を切り替えるトグルのように、切り替えて初めて評価できるものを、実装前に確かめられます。
あわせて、アートボードの上に「つまみ」(そのアートボード共通の設定値) を並べられます。ダークモードの切り替え、密度の切り替え、アクセントカラー、表示件数といった、デザイン全体を横断して効く値です。方針ははっきりしていて、文言用のつまみは作りません。文言は画面上で直接打ち替えるものだからです。
サブコマンド|後ろに単語 1 つを付けたとき
/design の後ろに特定の単語を 1 つだけ付けると、キャンバスを作らずに Claude Design 側の操作へ回ります。
| 書き方 | 何が起きるか |
|---|---|
/design sync | /design-sync へ。React のデザインシステムを claude.ai/design へ送る |
/design login | /design-login へ。claude.ai アカウントでデザインアクセスを認可する |
/design consent | Claude が Design プロジェクトを読み書きする許可を与える |
/design revoke | 上の許可を取り消す |
/design import | プレビュー中は使えない。claude.ai/design 側で操作する |
/design export | 同上 |
/design status | 同上 |
sync は、Storybook や素のパッケージから実際のコンポーネントのコードをまとめて claude.ai/design へ送るものです。同期させるプロジェクトを指定したいときは /design-sync <プロジェクト名> と直接書けます。いずれも claude.ai のログインと、組織のポリシーで Claude Design が許可されていることが前提です。
注意
単語 1
つだけを渡すと、サブコマンドとして解釈されます。ステータス画面をデザインしてほしいときに
/design status
と書くと、意図した動きになりません。「稼働状況のダッシュボードを 3
案」のように、文として渡してください。
早期プレビューとして、先に知っておくこと
正直に書きます。ここを知らずに使うと、あとで困ります。
エディタは公開した時点のものがページに焼き込まれます。あとから修正が入っても、すでに公開したキャンバスには反映されません。claude.ai/design と同じ機能がそろうことも、プレビューの目標にはなっていません。デザインシステムのカラートークンの管理と、修正を依頼するエージェントとの往復は、claude.ai/design 側に残ります。
同時編集は後勝ちです。あとから保存した側が衝突として弾かれ、画面は相手の保存内容に読み込み直されます。自分の未保存分は復元バナーから戻せますが、マージはされません。
アートボード同士は、実行時に何も共有しません。状態もロジックもつまみも別です。デスクトップ版のアートボードでトグルを押しても、モバイル版のアートボードは動きません。両方に同じものが要るなら、両方に持たせます。
アートボードをまたいだ要素の複数選択と、要素を別のアートボードへ直接ドラッグする操作は、まだありません。コピーと貼り付けは通ります。
外部ネットワークにも出られません。CDN のスクリプトも外部 API も届かず、通るのは Google Fonts のスタイルシートとフォントファイルだけです。画像はファイルとして同梱するので、1 枚あたり 70 KB 程度に縮めてから渡します。
書き出しにも癖があります。PNG はアートボード単位、PDF は表示中のアートボードをまとめて 1 つのファイルにします。展開表示で背後に隠れたアートボードは含まれません。どちらも Google Fonts は埋め込まれないため、文字はフォールバックの書体で出ます。
共有範囲にも注意が要ります。書き出しを有効にしたキャンバスは組織内限定になり、社外の人はリンクを開けません。社外に見せるなら、書き出した PNG や PDF を渡してください。
どこで効くか
実装に入る前の合意形成が、いちばん効きます。文章とワイヤーで進めていた議論を、実際のトークンで組まれた画面の上に移せるからです。前提がそろっていない状態での議論が減ります。
既存プロダクトへの画面追加も向いています。既存の値を拾って作られるので、「デザインは決まったが実装したら別物になった」という段差が起きにくくなります。
社内向けの配布物も、意外なほど実用になります。A4 1 枚の告知や手順書のように、デザイナーを 1 人押さえるほどではないけれど雑には出せないもの。ここは AI に任せて、人は文言だけ直すのが速いです。
Claude Code をチームの実務に組み込む方法は Claude Code に MCP をつないで実務を加速する 5 つの実例と Claude Code のカスタムコマンドで定型作業を自動化する実用パターンでも扱っています。
FIXITこれって、AI が画像をポンと出してくれるやつ?
Irodori画像ではなく編集できる画面が出ます。リンクを開いた人がその場で直せます。
FIXITえっ、じゃあ「うちのデザインに合わせて」って毎回頼まなくていいの?
Irodoriリポジトリの中で走らせれば、トークンや既存の部品を先に読みにいきます。
FIXITふーん。全部これでよくない?
Irodori2 人で同時に保存すると片方が弾かれます。編集する人を 1 人に決めておくと崩れません。
まとめ
/design の要点は 2 つです。成果物が画像ではなく編集できるキャンバスであること。そして、リポジトリの中で走らせると既存の値をそのまま写しにいくことです。
先に確かめてほしいのは、キャンバスを直す人が 1 人に決まっているかどうかです。同時編集は後勝ちで、マージはされません。ここだけ決めておけば、あとは 1 行投げて出てきたリンクを配れば回ります。
早期プレビューなので、機能の増減はこれからも起きます。エディタが公開時点で固定される点だけ承知しておけば、実装前の合意形成には今の状態でも十分に使えます。
デザインと実装の間で毎回作り直しが発生している、あるいは AI ツールを入れたものの定着していないという状態であれば、AI 開発ツール導入支援で伴走しています。どこから手を付けるか迷っているなら、お問い合わせからご相談ください。

