デザインシステムを渡してもスロップが出るときに効く8つの現場施策
エージェントがDSを読んでも、トークン外の色や未登録ボタンが出ることがある。lintで止める、ルールの有無で10回ずつ試す、本番部品だけの遊び場リポジトリを渡す、などの実務が共有された。
どんな問題を解決するか / いつ使うか
DESIGN.mdやコンポーネントライブラリを渡しているのに、生成UIが「それっぽい別物」になるとき。チームで何から手を付けるか選びたいとき。
やり方（投稿で挙がった施策の要約）
- 出力をシステムと照合する：例として UI Guardrails（Ruby gem）のように、トークン外の色・存在しないボタンを機械的に検知する。
- コンポーネントの上書きを止める：フックやルールで「カードの中のチャート」など、はみ出しやすい組み合わせを固定する。
- 夜次などでエージェント出力を評価する：AI向けに整えたオープンなDSの研究を参考に、定期evalを回す。
- ルールが効くかを試す：同じUIを「ルールあり10回・なし10回」生成し、差分でルールの価値を見る。
- トークンと部品のあとにルールを書く：先に層を固め、その上でテーマ生成などをエージェントに任せる。
- 本番部品だけの playground リポジトリを渡す：本番と同じコンポーネントでエージェントに作らせる（GoFundMe Heart の例）。
- 使い捨て画面もDSの部品と使用ルールから組ませる。
- ステッカーシート用スキルで部品をFigmaに並べる：カタログ化をエージェントに手伝わせる。
自チームでは、まず 1（lint）と 4（ルールの効果測定）と 6（playground）から入れると再現しやすい。
注意点
- 投稿はラジオ回の寄せ集め。ツール名は変わりうるので、方針（検知・測定・本番部品に閉じる）を先に採用する。
- 関連：デザインシステムで9割まで作らせ、最後の1割は画面に書き込んで見せて直させる。システムへの書き戻しは人が決める、DESIGN.mdだけでは部品の選び方がぶれる。種類一覧と使い分けの索引を1階層上に置く