「この画面、こういう感じで実装します」と説明して合意したのに、出来上がったものを見たら「思ってたのと違う」。
こんな経験、Web開発をしていたら誰でも一度はありますよね🙂↕️
Figmaを開いてがっつり設計するほどの規模ではない。でも言葉だけだと細部が詰まらない。結果として、実装が終わってから初めて「微妙なUI/UX」を見ることになります。
Claude Codeに /design コマンドが入ったので、この問題が解決できるかを試してみました。
結論として、たった1行の指示で 動くモック ができあがり、 状態ごとのパターンを網羅 してくれました。
図1: 出てきたモックは実際に操作できる。スキップはいつでも押せる
図2: 指示していない例外・縮退の状態も、4パターン揃って出てくる
/design で何ができるのか
使い方は /design 〈作りたいもの〉 と打つだけです。出てくるのは、拡大縮小できる1枚のキャンバスに複数の画面（アートボード）が並んだArtifactで、共有用のURLがその場で発行されます。
図3: 1枚のキャンバスに画面が並ぶ（写っているのは1ページ目。全体は2ページ・5枚）
| できること | 中身 |
|---|---|
| 複数画面のキャンバス | 画面・状態・案をひとつのキャンバスに並べる。ページ分割と付箋メモも置ける |
| 触れるプロトタイプ | 状態を持てるので、遷移や入力を実際に操作して確認できる |
| 切り替えツマミ | ライト/ダーク、バリアント、件数などを画面上のチップで切り替えて見比べる |
| 公開後の直接編集 | ブラウザ上でクリック選択・プロパティ編集・文字の直接編集ができ、保存すると全員に反映される |
| 書き出し | 画面単位でPNG、まとめてPDF |
汎用のAIにUIを作らせるのと決定的に違うのは、リポジトリ準拠であることだと思います。既存のデザイントークンやコンポーネントの実装を読んで、実値のまま描いてくれます。「それっぽいUI」ではなく「うちのUI」が出てくる、という感覚です。
Claude Designとの関係
/design は、Claude Designのキャンバスエディタが Claude Code の中で動く早期プレビューという位置づけです。Claude Design と同等の機能が揃っているわけではないようです。
Claude Design 単体の使い方については、以前スライド作成の観点で書いた記事があります。
試したこと: 「ご意見BOXにAIヒアリングを足したい」
私は自社の無料Webツール集「ラッコツールズ」の開発・運用を担当しています。
このサイトには「ご意見BOX」という意見投稿の窓口があります。
図4: ご意見BOX（モバイル表示）
ここに届く声はとてもありがたいのですが、「見づらい」「カウントがうまく作れない」のように主語がなかったり、
短文のため解釈に迷う投稿も多く、再現手順や期待していた動作が分からないまま対応を検討することになりがちでした。
そこで、送信したあとにAIが2〜3問だけ追いヒアリングする案を検討しています（あくまでアイデア・構想段階のものであり、実装・開発予定を示すものではありません）。
この案を /design に投げました。
指示はこれだけです。
/design ご意見BOXにAIチャット導入した場合のデザイン作って欲しい
すると、次の4つのアーティファクトを作ってくれました。
- 触れるフロー（デスクトップの右パネル / モバイルのボトムシート）
- 追加する前の現状の画面
- 例外・縮退の状態
- ヒアリング結果の受け渡し先
ここからは、実際に感じた /design コマンドの「良いところ」について画像付きで紹介しようと思います！
良いところ1: 実装から実値を拾ってくる
出てきた画面は、パネル幅448px、内側の余白24px、角丸はカードが10px・入力欄が8px。すべて既存のコンポーネントとCSSから拾った値でした。
丸めたりキリのいい数字に寄せたりせず、実装にある値のまま描いています。
図5: 追加前（左）と追加後。既存の余白・角丸・色をそのまま踏襲している
「だいたいこんな感じ」と指示して作らせたデザインだと、「余白が広すぎる」「このボタンはうちのスタイルじゃない」といったズレが生じます。
本当に議論したいのは体験の設計なのに、見た目の差分に時間を取られてしまう。
実値をベースに作られたデザインでは、この議論がそもそも発生しませんでした。
良いところ2: さわって動かせるので、体験そのものを判断できる
選択肢のチップを押すと次の質問に進み、3問答えると完了する。
この「体験」を実装前に確認できます。
図1（再掲）: チップを押すと次の質問へ進む。スキップはいつでも押せる
こういった体験は、静的なモックでは判断しづらいですよね。
今回だと
- 「1問ずつ出す体験は本当に軽いのか」
- 「スキップがいつでも押せると、負担感は消えるのか」
これらは実際に触ってみないと分かりませんでした。
仕様書の文字で「最大3問・参加は任意」と書いてあるのと、実際に3回タップして終わる体験をするのでは、受ける印象が違います。
良いところ3: 例外の状態を先に洗える
とくに指示していなかったのに、UIの状態別にデザインを作ってくれました
- AIが応答しないとき
- 会話の途中で落ちたとき
- 一度断ったあと
図2（再掲）: 例外・縮退の4状態
「AIが落ちたときにエラーを出すのか、黙って従来の完了画面に倒すのか」は、実装に入ってから決めると帳尻合わせになりがちな部分です。それが最初から画面として並んでいたので、方針をその場で決められました。
良いところ4: コードに基づいて仕様の穴を見つけてくれる
現状のご意見BOXは送信するとパネルが閉じる実装になっています。つまり、送信後にヒアリングを出すには、まずこの「閉じる」挙動を止める必要があります。
要件定義の段階では、そこの考慮がすっかり漏れていました。
しかし、 /design コマンドを実行すると、デザイン生成の過程でこの仕様の穴に気がつき、修正要件まで盛り込んでくれたのです。
リポジトリベースで動いているからこそ成せることだなと感心しました✨
実装に入ってから「あれ、パネル閉じるじゃん」と気づくのと、絵を描く段階で気づくのでは、手戻りの量が違いますからね。
ChatGPTのImage2などに同じデザイン生成依頼をしても、コードベースにのデータを持っていないのでこの仕様の穴には気づけないんじゃないかと思います。
効く場面と、効かない場面
一通り触ってみて、向き不向きがかなりはっきりしていると感じました。
| やりたいこと | 判断 | 補足 |
|---|---|---|
| 新機能のUIを実装前に合意したい | ◎ | 一番の使いどころ。受け入れ条件を書く材料もそのまま揃う |
| 方向性を2〜4案比べたい | ◎ | 1枚のキャンバスに並べて選べる |
| 例外・空・エラー状態を洗い出したい | ◎ | 抜けやすいところを先に潰せる |
| 既存UIの表示を1箇所だけ直したい | △ | コードを直接直したほうが速い |
| データ可視化の資料を作りたい | ✕ | 通常のArtifactのほうが向いている |
| 実装コードが欲しい | ✕ | 素直にClaude Codeへ実装を依頼する |
私の場合は「要件定義の一番曖昧なところを埋める」用途に絞ると、費用対効果が高いと感じました。逆に、すでに仕様が固まっている改修に使うと、単に工程が1つ増えるだけになります。
つまづいたところ・注意点
実装コードは出てこない
最初に誤解しかけたのですが、/design が出すのはあくまで絵です。生成されるファイルはキャンバス専用の形式で、そのままReactコンポーネントとして取り込めるものではありません。
絵を見て実装するのであって、コードが出てくるわけではない、という理解が正確だと思います。
共有範囲の設定に注意が必要
書き出し機能（PNG/PDF）を有効にしたキャンバスは、共有範囲が組織内に限られる仕様になっています。社外の人に見てもらいたい場合は、この設定を含めるかどうかで共有できる範囲が変わります。
社内レビュー用なら気にしなくてよいのですが、記事や外部向け資料に貼るつもりなら、公開したあとに共有ダイアログで実際にどこまで共有できるかを確認しておくのが安全です。
早期プレビューであること
現時点では早期プレビューです。公開したキャンバスにはエディタが埋め込まれる形になっているため、あとから機能が改善されても、すでに公開したキャンバスには反映されません。また、複数人が同時に編集して保存すると後から保存したほうが勝つ挙動なので、リアルタイムの共同編集を前提にした運用には向きません。
実装フェーズにどう渡すか
個人的に一番ありがたいのは、ローカルのコードを一切触らないことです。ブランチも切られませんし、PRも出ません。既存コードを読むだけなので、要件定義フェーズとして安心して回せます。
そして、できあがったArtifactがそのまま仕様の合意物になります。「この画面で合意した」が1枚のURLで残るので、受け入れ条件を書くときに「どの画面のどの状態の話か」を言葉で再構成する手間がなくなりました。
実装する人が見るデザインと、合意したデザインが同じものになるので、認識のズレが生まれにくい。
要件定義から実装までをAIに任せるフローは以前から組んでいますが、その入口に「触れる絵」が1枚あるだけで、後工程の解像度がかなり変わると感じています。
まとめ
/design を試して感じたのは、これは「デザインツールの代替」ではなく、これまで絵が無いまま進んでいた小さな改修に、絵を持ち込む道具だということです。
Figmaを開くほどでもない、でも言葉だけでは詰まらない。その隙間はずっと放置されていて、実装後の「思ってたのと違う」として回収されていました。1行の指示で触れるモックが出てくるなら、その隙間は埋められそうです。
デザインの方向性を探りたいとき、いろんなパターンを試したいときに、また使ってみようと思います。
最後まで読んでいただき、ありがとうございました！
Discussion