AI エージェントに UI を作らせる時代、「AI がデザインシステムのルール通りに作れているか」は誰も確かめていませんでした。relay では固定のお題（現在 10 件）を AI に解かせ、ルール通りに作れたかを採点する試験（evals）を運用しています。お題は 2 種類あり、既存ルールが壊れていないかを守る回帰用の 8 件と、新しく教えた知識が効いているかを測る改善メーター用（capability）の 2 件で構成します。デザインシステムやドキュメントを変えたとき、また AI モデル自体が更新されたときに、生成品質が静かに劣化していないかをスコアで検知します。

hooks と evals — 防ぐ仕組みと測る仕組み

relay には以前から hooks（AI がコードを書いた直後にハードコード違反を検知してその場で直させる、利用者側のガードレール）があります。evals はこれを置き換えるものではなく、ルールに従えているかを測って記録する、デザインシステム側の定期健康診断です。防ぐ × 測るの両輪で品質を守ります。

採点は 2 段構え

「アカウント削除の前に確認を挟んで」のような意図レベルの曖昧なお題を AI に解かせます（コンポーネント名は伝えません — デザインシステムが選定を導けているかを測るためです）。生成された UI を 2 種類のチェックで採点します。

結果は 4 区分 — 品質の低下と測定の故障を混同しない

運用してみると、スコアが落ちる理由は「AI の生成品質」だけではありませんでした。生成そのものの失敗や審査員の不調が混ざると、劣化が本物かどうか判別できません。そこで結果を 4 区分で記録し、品質の失敗（FAIL）だけをデザインシステム改善のシグナルとして扱います。

定点観測 — 静かな劣化をスコアで検知

毎回同じ試験を回し、結果をスコアとして蓄積します。推移表で「いつから・どのお題が落ち始めたか」を追えるため、利用者からの「最近生成が変」という報告より先に劣化へ気づけます。品質スコアは測定できた判定だけで読みます（生成失敗・審査不能は分母に含めません）。

8 月の「スコア急落」は、2 値の読み方では品質劣化に見えましたが、区分してみると大半がテスト基盤の故障でした。測定を疑える仕組みがないと、健全な改善はできない — 4 区分はその実体験から生まれた設計です。

お題はどこから来るか — 実運用の失敗を試験に変える

お題は机上で発明せず、2 つの源から増やします。ひとつは実運用の失敗 — relay を実プロダクトへ導入する作業で AI の実装が期待と違った箇所のうち、「デザインシステムの知識で防げたはずの違反」を一般化してお題化します（チーム固有のデザイン判断はお題にしません）。もうひとつはアクセシビリティの責任境界 — デザインシステムが完全担保する項目はコンポーネントを使わせることで守り、プロダクト側が書くべき項目（aria 属性・ラベル関連付けなど）を試験が測ります。

この仕組みはすでに機能しています。実運用で起きた「絞り込みフォームが選択と同時に自動送信される」という失敗をお題化して初回実行したところ、AI は同じ失敗をそのまま再現しました。つまりあの失敗は偶然ではなく、デザインシステムの知識にある再現性の高い穴だと確定 — 次の改善ターゲットが試験によって特定されました。

これから

• 試験が特定した知識の穴（ナビ・絞り込みフォーム）をデザインシステム側の改善で潰し、前後のスコアで効果を証明する
• 8 月に頻発した生成失敗（測定の故障）の原因を解消し、測定を安定させる
• ルール（MCP・DESIGN.md・コンポーネント仕様）を変更する PR は、直したい振る舞いのお題を先に追加してから変更する（テスト先行）
• スコアが安定したら CI に組み込み、試験に落ちたルール変更はマージできないようにする
• 実運用で見つかった失敗を継続的にお題へ還流し、デザインシステムが使われるほど試験も育てる

デザイナーは「なぜこちらを選ぶのか」という判断軸を明文化し、それがそのまま試験になります。relay Design System は「UI パーツの提供」から「品質を保ち続ける仕組みの提供」へ。

仕組みの詳細・実行方法は GitHub の evals/README.md を参照してください。