DESIGN.mdだけでは部品の選び方がぶれる。種類一覧と使い分けの索引を1階層上に置く
カナリーのUI生成では、DESIGN.mdやコンポーネント単体の定義だけだと画面ごとにドロップダウンとラジオが入れ替わる。コンポーネント種類一覧・使い分けの index、レイアウトパターンの index、余白の px 指定を足すと、AIは「選ぶだけ」になる。
どんな問題を解決するか / いつ使うか
Claude Code などでデザインシステムに沿ったUIを量産するとき。見た目のトークンは揃うのに、似た部品の選択やレイアウト型が画面ごとに違うとき。
やり方
- DESIGN.md(トークン・禁止・雰囲気)だけでは足りないと割り切る。生成のたびに「この画面ではどの部品か」を都度判断させると、操作目的が同じでも部品が入れ替わる。
- コンポーネントの1階層上に「種類一覧+扱い方の index」を置く。いつどの部品を使うか/使わないかを明示する。Adobe のデザインシステムにある
component-decision-tree.mdと同じ発想。 - レイアウトパターンも同様に index 化する。各レイアウトを「どんな場合に使うか」まで定義し、生成時はまずレイアウト index を読み、次にコンポーネント index を読んでから配置する。
- 余白・配置はざっくり書かず px 単位で固定する。数字が粗いと生成のブレが残る。
- 生成用エージェントとレビュー用エージェントは分け、共通のデザインシステム(カナリーでは NestUI)を両方のリファレンスにする。レビューはアクセシビリティ・部品・レイアウト・情報設計・文言などで採点ループを回す。
複数画面を一度に作るときは、先に画面遷移・共通シェル・バッチ判断など横断の設計を出し、目視でズレを直してから一括生成する。単一画面ならこの前段は省略してよい、というのがカナリーの運用。
注意点
- NestUI の一部は GitHub 公開(
SSK-TBD/NestUI)。構造の参考用で、自社の部品名・ルールはそのままコピーしない。 - 似た考え方は AIの画面に「らしさ」を出すには、デザインシステムに使用ルール・使い分け・「やらないこと」まで書き込み、Figmaとコードを一致させる(使用ルールと横断の使い分け)や 歴史ある大きなプロダクトでは、まずDESIGN.mdに仮置きし、次にStorybookを「唯一の正」にしてAIに部品を選ばせる も参照。
出典
- @kgsi · 2026-11-05
- カナリー 寺本 裕成「思考プロセスの再現性を求めて。カナリーの「UI生成ワークフロー」の現在地」 cocoda.design