デザインハーネスは「5行の採点表」から：対抗する3案を作って採点し、別社のモデルに反論させ、人が決める

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

PMやエンジニアでもAIで「それらしい」画面が作れるようになり、問題は作ることより「それが本当に良いか」の判断になった。コントラスト・トークン・コンポーネントの使用などの検証できる部分だけ自動化しても、方向性・流れ・階層の良し悪しは見られない。チームでAIにUIを作らせていて、レビューの基準をそろえたいときに使う。

やり方

1. 検証できる部分を先に固める：名前で呼べるコンポーネント、意味のあるトークン、ベテランがレビューで伝えていた知識（エッジケース、和文組版、多言語、アクセシビリティ）を、コード生成の前に読み込まれるルールにする。
2. 判断を5行の採点表に書く（記事の例。各5点・計25点）：
   text

   ブリーフに問いを立てているか   /5
   そのユーザーの仕事ができるか   /5
   できないことを正直に示しているか /5
   階層が明確か                   /5
   デザインシステムの使い方       /5

   中身はチームごとに違ってよい。書き出すこと自体で、自分が無意識に2つの軸を取引していたことに気づける。

3. 磨き込みではなく探索に使う：1つのブリーフから「今の方向を強める案」「横にずらす案」「真逆の案」の3つを、実際に動く試作として並行に作り、採点表で採点する。
4. 別ベンダーのモデルに反論させる：記事の例では横ずらし案が22点で勝ったが、反論役が「すでに決まった2つの判断を黙って落としたから、すっきり見えて高得点になった」と指摘した。両方の主張を文章で残し、最後は人が決める。
5. 批評会もエージェントで：UX・プロダクト・データ・エンジニアリング・ブランド・市場・「誰も担当していない反論」の7席。実物の画面をヘッドレスブラウザで撮って見せ（説明文ではなく描画結果で判断させる）、席ごとに違うモデルを使う。
6. AIの提案と人の実際の判断を別々に記録し、リリース後に照合する。どの助言が当たっていたかが分かってから、ループ自身のプロンプトを調整する。

注意点

• AI同士の批評は盲点を共有しやすい。モデルを分けても完全には防げないので、人のレビュー席は外さない。
• 自動QAは教えたものしか見ない（記事では、デスクトップ・ライトモード・メニューを閉じた状態しか見ておらず、新しい操作部品を一度も開かなかった失敗例がある）。
• 始めるなら11エージェントではなく、よく後輩に説明している判断1つを採点表にするところから。
• 関連：チームとエージェントが同じ部品とルールで作れるよう、「見た目・部品・エージェント」の3層のルールと /ds ページを作らせる、oil-uiスキルで、本当に違うデザイン案を並べて比べ、選んだ1案を実画面のスクショで仕上げる、Claude Code × Figma MCP で清書した画面は、文脈を持たない読み取り専用の検査役に「実測値」で全数検査させる。

出典

• 紹介投稿: @kgsi · 2026-10-23
• 記事: Money Forward Design「Anyone can design now. Someone still has to judge.」note.com（本文を確認）