AI生成UIをCIで守る ──デザインハーネスの組み立て方
ハーネス基盤を整えた組織でも、画面に関しては「このままリリースしてよいのか」に誰も答えられないという光景をよく見かけます。エンジニアはデザインの責任を持てず、デザイナーは生成の速度に追いつけません。レビュー依頼は溜まり、リリースは止まらないものの、不安だけが残ってしまいます。
AIによって素早く画面を作れるようになった一方で、ユーザーからは「使い方が分からない」「表示が見づらい」といった不満の声が増加しています。機能が実装されることと、ユーザーがそれを使いこなせることの間には以前から大きな溝がありました。AIの登場でその溝が埋まるかと思いきや、生成速度が上がった分だけむしろ広がっています。
これらの根本的な原因は、技術の不足ではなく「デザインの免責構造」が存在しないことです。
コードには「CIが通れば出してよい」という免責の仕組みがありますが、画面にはそれがありません。免責がない状態では、生成された画面がデザイナーのレビュー待ちになったり、そのままリリースして後からの改修が困難になったりします。結果として、ユーザーに届く画面の質は下がっていきます。
そこで、エージェントが生成した画面の責任はハーネスを整備する責任者が持つと定義します。エンジニアは生成物のデザインに対する直接の責任を負わずにリリースできるようにすることで、この問題は解決に向かいます。生成を行うエンジニア全員に、UX・デザイン設計の素養を求めるのは現実的ではないからです。
既存画面のデザインエラーを個別に修復して回るのではなく、まずはこれから新しく作成される画面の使いやすさが、仕組みによって自動的に担保される状態を作りましょう。
本連載では、皆さんがコードで実践してきたハーネスの定石を、そのままUI領域に当てはめていきます。初回の今回は「機械が守る範囲を確定する」ところまでを解説します。第2回では人間がレビューすべき変更の切り分け方を、第3回ではAIが作成した画面の責任構造について取り上げます。
コードの定石をUIに適用する「デザインハーネス」の全体像
AIエージェントに確実に仕事をさせるため、制約・検証・フィードバックの装置で挙動を包み込む仕組みをハーネスと呼びます。このハーネスエンジニアリングの考え方をデザイン領域に当てはめたものが「デザインハーネス」です。作ってよいものの範囲を定め、判断の前提を渡し、生成物が基準を満たすかを検証し、その結果を次の生成に書き戻す。コード側のハーネスで皆さんが行ってきたことと、基本的な骨格は同じです。
コード側の定石が、デザイン領域では何にあたるのかを対応表で見てみましょう。
| コード側の定石 | デザインでの対応物 |
|---|---|
| 失敗のたびに仕組み化する | 生成物を人間がデザインレビューし、その指摘をログとして蓄積。同種の指摘が溜まったらルール化する。 |
| 指示文ではなく仕組みで担保する | ガイドライン文書をlinterなどに昇華させる。トークンのlint、コンポーネントの突合、アクセシビリティチェックなど。 |
| すぐにフィードバックできる仕組みを作る | ファイル検索で分かるデザイントークン値の直書き、禁止クラス、用語の表記ゆれはコーディングエージェントのフックへ。コントラストやタップ領域のような描画が必要な検査は、エージェントにローカルでブラウザを起動させて確認させ、CIでは同じ検査を最終ゲートとして強制する。 |
| 評価セットで回帰テストする | 機械的に判定できないものは実例集で測る。例：判定に迷った画面10件に自分の判定を添えた問題集をLLMに解かせ、人間との一致率を見る。（次回詳述） |
| 既存の違反は直さず、増加だけ止める | デザインのエラーも同じ。現状の件数を記録し、これから増える方向だけを止める。既存分の改善は別プロジェクトに切り分ける。 |
| 定期的に削る | ルールは一覧で持ち、効かなくなったものは整理を頑張らず捨てて作り直す。 |
デザイン固有の課題「描画」「ゆらぎ」「らしさ」とは
骨格は共通していますが、デザインならではの違いが3つ存在します。
- ファイルを検索するだけでは判明しないことが多く、ブラウザでのレンダリングが必要です。テキストの検査で完結するコードのチェックと異なり、エージェントにローカルでブラウザを起動させて検証させる工程が挟まります。CIは同じ検査を最終ゲートとして受け持ちます。
- 正解が1つに決まらないことがあります。例えば一覧データを書き出すボタンの配置場所は、他の画面に合わせて右上に置いても、テーブルのすぐ下に置いても操作として成り立ちます。複数の正解が存在する中で、片方だけをハーネスで弾いてしまうと、ユーザー体験の自由度を奪うことになります。答えが複数存在することや、時間・文脈によって変化することを許容しなければなりません。
- 「らしさ」などのブランディングやパーソナリティといった有機的・非言語的な要素は、ハーネスでは扱えません。これらはデザインシステムとして人間が定義し、機械はそのルールの遵守のみを検証します。
正解が複数存在することや、非言語的な要素が含まれる点により、コード側に比べて決定的なチェックで判定できる範囲は狭くなり、人間の判断に依存する領域が広がります。この残された判断を個人の感覚に委ねたままにせず、チームの誰が担当しても同じ判定ができる形へ移行させる作業こそが、デザインハーネスの構築です。次の手順から順番に説明します。
