歴史ある大きなプロダクトでは、まずDESIGN.mdに仮置きし、次にStorybookを「唯一の正」にしてAIに部品を選ばせる

どんな問題を解決するか / いつ使うか

長く運用されている大規模プロダクト（Gaji-Labo の事例は、5つのプロダクト・約50人のチーム）で、開発がAI前提になり、Figmaでのデザイン工程が遅れの原因になってきたとき。デザインハーネス（AIと一緒に一貫したUIを作るための仕組み）を、最初から全部そろえずに小さく始めたいときに使う。

やり方

1. ルールを1か所に仮置きする：散らばったデザインルールを、Figmaと実装を突き合わせて DESIGN.md に集める（Googleの仕様に沿った形式）。これだけで色・余白・文字の基本ルールは生成結果に反映された。
2. 限界を見極める：DESIGN.md をいくら厚くしても、「どの部品を使うか」「必要な部品が存在するか」は伝わらず、ファイルが厚くなるとAIが必要な記述にたどり着きにくくなった。
3. Storybookを唯一の正（SSOT）にする：アプリのコードを読ませるより、UIカタログとして整理された Storybook から部品を選ばせてモックを作らせる方が精度が高かった。整える順番は次の4段階。
   1. Storybook を、AIが部品を選べる状態に整える
   2. 色・文字・余白などのトークンを整理する
   3. デザイナーのルールや意図を言葉にする
   4. 実際のページを Storybook 上に組み合わせの例として置く
   5. ゼロから作るならルールとトークンが先でもよいが、既に Storybook がある場合は、生成結果への効果が一番大きかった Storybook から始めた。
4. 部品は「選ばせる」制約にする：自由に作らせず、Storybook にある部品から選ばせる。モックはコードとして生成され、Storybook 上でそのまま確認でき、磨けば本番コードに使える。
5. 毎回「引用リスト」と「推測リスト」を出させる：何を根拠にしたか、どこを推測したかを書かせると、指示が足りないのか Storybook の記述が足りないのかがすぐ分かる。見つけたズレは DESIGN.md や Story の記述に戻す。

注意点

• 結果として、標準的な画面設計なら非デザイナーにも任せられる見通しが立ち、社内アプリ程度の規模なら実用水準。大規模サービスのチーム全体への定着はまだ途中とのこと。
• デザイナーが書いたルールは、エンジニアが既存の実装と合っているかの観点でレビューして磨く。
• 組み合わせの例示（4段階目）は、トークン名ではなく「正しい使い方のコード例（ゴールデンセット）」をエージェントに渡す。レジストリ／MCPで配る と同じ考え方。

出典

• @kgsi · 2026-11-04
• 記事：Gaji-Labo ブログ「デザインハーネスの試行錯誤。鍵は小さく始めることだった」 gaji.jp