品質評価（evals）
AI 生成の定期健康診断AI エージェントに UI を作らせる時代、「AI がデザインシステムのルール通りに作れているか」は誰も確かめていませんでした。relay では固定のお題を AI に解かせ、ルール通りに作れたかを採点する回帰テスト（evals）を運用しています。デザインシステムやドキュメントを変えたとき、また AI モデル自体が更新されたときに、生成品質が静かに劣化していないかをスコアで検知します。
hooks と evals — 防ぐ仕組みと測る仕組み
relay には以前から hooks（AI がコードを書いた直後にハードコード違反を検知してその場で直させる、利用者側のガードレール）があります。evals はこれを置き換えるものではなく、ルールに従えているかを測って記録する、デザインシステム側の定期健康診断です。防ぐ × 測るの両輪で品質を守ります。
| 例えると | hooks = 車線逸脱防止アシスト | evals = 定期健康診断 |
|---|---|---|
| いつ動く | AI がコードを書いた直後 | 週 1 回 + ルール変更時 |
| 何をする | 違反をその場で直させる | 従えるかを測って記録する |
| 動く場所 | 利用者のプロジェクト | デザインシステムのリポジトリ |
採点は 2 段構え
「アカウント削除の前に確認を挟んで」のような意図レベルの曖昧なお題を AI に解かせます（コンポーネント名は伝えません — デザインシステムが選定を導けているかを測るためです）。生成された UI を 2 種類のチェックで採点します。
機械チェック
コードで判定 — 決定的・無料
- 色・余白などのハードコード（配布中の hooks と同一判定）
- 実在しないクラスの捏造（例:
btn-outlineのような架空 variant） - 必須マークアップ（
aria-currentなど）
AI 審査員
機械で測れない判断を判定
- 明文化された選定ルールの遵守判定（例: 削除確認は modal + negative ボタン）
- 採点基準は各コンポーネント仕様の「機能 / 使用法」など、デザインシステムが文書化したルールから作成
- 判定に迷う場合は不合格に倒す設定（甘い採点をしない）
定点観測 — 静かな劣化をスコアで検知
毎回同じ試験を回し、結果をスコアとして蓄積します。推移表で「いつから・どのお題が落ち始めたか」を追えるため、利用者からの「最近生成が変」という報告より先に劣化へ気づけます。
| 実行日 | 削除確認 | 招待フォーム | 契約一覧 | 空状態 | 設定ナビ | 計 |
|---|---|---|---|---|---|---|
| 2026-07-21 | PASS | PASS | PASS | PASS | PASS | 5/5 |
2026-07-21 時点のベースライン。以降、週次の実行で行が増えていきます。
これから
- 週 1 回の定点観測でスコアの安定性を検証する
- ルール（MCP・DESIGN.md・コンポーネント仕様）を変更する PR は、前後で evals を回して効果を測定する
- スコアが安定したら CI に組み込み、試験に落ちたルール変更はマージできないようにする
- 新しいコンポーネントを追加したら試験のお題も 1 本追加し、デザインシステムが育つほど試験も育てる
デザイナーは「なぜこちらを選ぶのか」という判断軸を明文化し、それがそのまま試験になります。relay Design System は「UI パーツの提供」から「品質を保ち続ける仕組みの提供」へ。
仕組みの詳細・実行方法は GitHub の evals/README.md を参照してください。