デザインハーネスをデザイナーらしく改善する
株式会社ライトライトのagu（@GoatVivi）です。
先日、デザインハーネスをテーマにしたイベント デザインハーネス 2nd 〜デザインにおけるハーネスエンジニアリング〜 に登壇してきました！
登壇資料はこちら。
この記事では登壇でお話しした内容を記録として公開します。
私たちは今年の5月からデザインシステムの構築や、AIエージェントに知識を渡すためのMCPサーバー構築を進めてきました。
7月にはメインプロダクトである relay に接続し、今では社内のデザイナーがフロント実装まで行なっています。
社内にエンジニアは1人もおらず、プロダクトチームはデザイナー3人で構成されています。全員がAIを使い、githubでPRを出す。5月に私が入社した際のプロダクト開発から大きく変わっていきました。
私たちがデザインハーネスを作る目的は「人が考える範囲を減らすこと」です。
AIに任せられる責任範囲をしっかり定め、その範囲内で人は何も気にすることなくAIに任せられる状態を作る。
これまでの取り組みはnoteにもまとめてますのでぜひ！
AIに任せ人が考える範囲を減らすために、ハーネスをひとつのプロダクトとして、定量的かつ事実ベースでデザイナーらしく改善する取り組みを行っています。
AIが生成するUIは、モデルの性能も進化し確かに向上していきました。
しかし、生成物とデザインハーネスの品質は切り分けて考えなければいけないと感じています。
デザイナーが主導して進めているものなので、生成物の評価に意識が向かいがちです。そうすると、コンテキストを過剰に与えてしまっていたり、既存パターンの再現に必要以上にトークンを使用していたりします。
実際に運用していく中で出てきた課題です。
デザインハーネスはチームを超えて使われる
社内のデザインハーネスは当初の想定よりも広く使われはじめました。
そうすると、想定していなかった課題も見えてきました。
ハーネスののトークン効率が悪いと、チーム全員のトークン消費が増加し、ダイレクトにコストへ跳ね返ってしまう。
日々「トークンと相談」している弊社メンバーの限られたトークンを喰らうモンスターハーネスを生み出すわけにはいきません…
必要十分な制約とコンテキストでAIエージェントを動かし、既知の再現はなるべくローコストで運用する必要があると感じています。
コンテキストの影響範囲や効果が曖昧
トークン効率を考える上で、ドキュメントを書き換えて「なんとなく良くなった気がする」だけでは改善とは言えません。
出力された成果物の良し悪しだけでなく「ハーネスそのものを定量的に評価する仕組み」が必要だと考えました。
デザイナーらしく、つまり、事実を観察し、課題を見つけ、問いを立てながらデザインハーネスを改善する取り組みを行ってきました。
relayでは7月から、ハーネスに変更を加える際、マージ前に定量的な評価テストを実施するパイプラインを構築しました。
評価テストが完了したら評価レポートを出力し、AIへの過学習を防ぐために人が妥当性を判断します。
そして、人の目でレポートを見て違和感を感じたらAIに壁打ちしながら改善策を考えていきます。
AIには言語化できなかった課題を見つけるために、事実から違和感を見つけ問いに変換するデザイナーの筋力、略してﾃﾞｻﾞｲﾅｰ ﾉ ｷﾝﾘｮｸが試されます。
評価テスト、2つの役割
①能力テスト（できなかったことを、できるようにする）
本番で起きた失敗パターンを「入力・文脈」「実行条件」「期待する結果」「過程の条件」「失敗の記録」に整理し、ゴールデンデータセットとして蓄積します。
このデータセットが能力テストのひとつひとつの項目になります。
デザインハーネスが担保する責任範囲を広げるためのテストで、0点から100点に改善していくテストです。
②回帰テスト（できていたことが、引き続きできているか）
能力テストに繰り返し合格して安定したデータセットは、回帰テストへ移行します。
ハーネスをいじったことで以前できていたことが壊れていないかを確認するためのテストで、100点を維持できているかのテストです。
能力テストはハーネスに求める一元的品質、回帰テストは当たり前品質として整理します。
実行AI × 機械判定 × AI審査員
テスト判定は以下のように役割分担しています。
実行AI：プロンプトを受け取り、画面をひたすら生成するだけの悲しきモンスター
機械判定：クラス名のルールや特定タグの有無など、厳密な制約を低コスト・高速にチェック
AI審査員：生成されたUIやコード全体を俯瞰して評価レポートを作成する偉そうなやつ
評価テストが完了すると詳細な評価レポートがHTMLファイルで出力されます。
レポート内容
お題・達成基準（ゴールデンデータセット）
計測サマリー
達成基準を満たしたかの判定
生成にかかった時間
入力/出力/推論トークンの内訳
ツールの呼び出し回数
ステップ数
など
行動ログ
生成された画面
AI審査員からみた改善案
行動ログは「AIがどの順番でツールを呼び、どのコンテキストを参照して、どうコードを書いたのか」を追跡できるようになっています。
この行動ログの生データはAIが可読できるようjsonファイルで保管されており、レポートでは人が見やすいようにインターフェースを作り表示しています。
そうこうして出てきた評価レポートの妥当性や、変更が他のお題に与えた影響を人が最終チェックしてマージ判断します。
成果物だけを見ていると分からないAIの迷いや無駄な動きを、行動ログから発見しハーネスを改善した実例を2件ご紹介します。
CASE 1：検索が空振りすると、故障を疑ってローカルを漁り始めるAI
行動ログを見ると、MCPサーバーで提供している、デザインシステムを横断検索できるsearchツールを使用後、Bashコマンドでひたすらローカルファイルを探しにいく事実を発見しました。
起きていた問題
実行AIがデザインシステムに存在しないコンポーネントを検索したところヒットせず。するとAIは「検索ツールの故障かもしれない」と疑い、Bashを使ってローカルのリポジトリファイルを片っ端から探し回るという迷走が発生していました。所要時間として約5分、この間にも入力トークンを大量消費しています。
どう改善したか？
Bashの実行権限を奪って無理やり止めるのは、症状を抑えているだけで根本治療ではありません。そこで「存在しません」だけで終わらせず、「存在しません。代わりに〇〇を使ってください」と次の具体的な行動のサジェストを返すように検索ツール側を変更しました。
結果、無駄な探し直しがなくなり、適切なツールへ回り道することなく到達できるようになりました。
入力トークン：2,053,711 → 462,690（約77%削減）
出力トークン：20,239 → 6,349（約68%削減）
生成時間：4分58秒 → 1分36秒（約3分の1に短縮）
CASE 2：必要な節だけではなく全文読んでいた…
こちらもsearchツール使用後に、他のステップと比較して大量にテキストを読んでいる事実をログから発見しました。
起きていた問題
特定のUIパーツにおけるアクセシビリティ対応を知りたいだけなのに、get_accessibilityツールを呼ぶと約3.5万文字の巨大なドキュメントが丸ごと渡されていました。
どう改善したか？
ドキュメント（Markdownファイル）の粒度をAIが取り出しやすい構造に見直し、必要な節だけをピンポイントで取得できるようにツールを修正。
知識を削るのではなく、必要なときに必要な情報へ辿り着ける道を整備しました。
結果、生成に不要なドキュメントを読まなくなり、全体の入力トークン数が改善しました。
get_accessibility`の応答文字数：34,902文字 → 484文字
全体の入力トークン：638,107 → 440,688
生成された画面は改善前も問題ありません。生成物だけを見ていると気付けなかった事実に行動ログから気付き改善した例でした。
また、ハーネス変更後の再計測は最低でも3回は行うようにしています。出力は確率的なので、運よく良い計測ができた可能性があるためです。
試行回数が多いほどデータを集められますが、ここはトークンと相談しながら進めています。
この取り組みの学びとして、目的地に辿り着けたかだけでなく、そこに至るまでの道が整備されているかにも目を向けるべきということでした。
不要な回り道をしていないか？違法な抜け道を使っていないか？
必要なコンテキストに正しく誘導していくことで、全体のトークン消費や生成時間が改善できました。
現在、基盤モデル自体の性能向上に伴い、単純なタスクの品質スコアそのものの差は小さくなってきています。だからこそ今後は、生成までの道筋を整え、トークン効率や生成スピードを最大化する「モデルの最適化・ハーネスの最適化」に取り組んでいます。
始めにもお伝えしたとおり、既知の再現はローコストで運用する方が良いと考えています。
オーバースペックのモデルを使っていないか？最新モデルの消費トークン数は実際どうなのか？
定量で測り、自社デザインハーネスのベンチマークを社内向けに公開することで、さらにチーム全体のトークン効率は良くなると考えています。
ハーネスを整えて「人が考える範囲」を減らすのは、決してサボるためではありません。
返ってきた時間やトークンは、次の魅力を考えるために使う。
そのためにはユーザーと向き合い、未知の課題に取り組まなければなりません。
当たり前品質はハーネスが守り、魅力品質は人が作る。
そんな人とAIの心地よい協働関係を、これからもデザイナーの視点から追求していきたいと思います。
というわけで、
