デザインハーネスの構築3ステップ
使いづらいと声のあがった画面から始める
ハーネスエンジニアリングの出発点は、「エージェントがミスをするたびに、そのミスが二度と起きないよう仕組みを作り込む」という原則です。これをデザインに置き換えると、ユーザーや社内から「使いづらい」と指摘のあった画面が「エージェントのミス」に相当します。
例えば、送信ボタンを押した後のフィードバック位置が悪くユーザーが送信完了に気づけないケースや、ボタンが3つ並んでいて選択すべきラベルが分からないケース、情報の入力を求めているのに必要な事前準備が伝わっていないケースなどがあります。
まずは、改善要望が出ている画面をAIに修正させ、その提案に対する自身の判定結果を記録することから始めます。AIの改善案が妥当か、却下した理由は何かといった判定の記録が、最初のルールとなります。記録には改善前後のスクリーンショットを添えてください。コードの差分だけでは、後から人間が判定基準として再利用しづらいためです。
記録先は専用ツールでなくても構いません。プルリクエストのコメントや1枚のドキュメントなど、後から検索して件数をカウントできる場所に集めておくことが重要です。数件運用して抽象化できた指摘から、CIのチェック項目として追加していきます。
ここで重要なのは、必ずadvisory（検出は行うがマージはブロックしない設定）から始めることです。観測すべき対象は、検出数、誤検出の割合、そして他の開発者がノイズと感じていないかどうかです。マージを止める設定への昇格は、観測によって十分な信頼性を確認した後のフェーズになります。小さく始めて影響を慎重に観察することが、構築のスタートラインです。
デザインの正本をlinterに変換する
デザインシステムは「人が読むもの」から「AIが参照するもの」へと役割が変化しました。定義が明確なものは機械的に判定できるため、linterへと変換していきます。
色やコンポーネントの定義が分散していると、AIも人間もどれに従うべきか迷いが生じます。そのため、迷った際に必ず参照する基準データを1つ定めます。これを「正本」と呼びます。多くのチームでは、デザインシステムが正本にあたります。
ただし正本であっても、1つの巨大なファイルにまとめると機能しにくくなります。全体像を示すindex.mdを起点として、役割ごとにファイルを分割して運用します。
- index.md：全体像の地図。何がどこにあり、どの順序で参照すべきかを示す。
- tokens.md：色・余白・文字サイズの定義と、対応するコード側の変数
- ng-cases.md：スクリーンショットの実例を添えた、禁止事項（やってはいけない例）集
何から変換すべきかは、チェックの性質によって2つに分類するとスムーズです。答えが外部に存在するチェックと、答えを自分たちで定義するチェックです。
答えが外部にあるチェックの代表例がアクセシビリティです。WCAGやJIS X 8341といった規格により、コントラスト比やフォーカス操作の基準が既に公表されています。自社のデザインルールがまだ存在しなくても外部に基準があるため、今日から機械判定を開始できます。ユーザーが「読めない」「操作できない」といった基礎的な問題から優先して防ぐことが可能です。これにはeslint-plugin-jsx-a11yやaxe-coreなどの既存linterがそのまま活用できます。
一方、答えを自分たちで定義するチェックとは、自社のデザインシステムに準拠しているかどうかの判定です。デザイントークンに従っているか、定義済みコンポーネントがあるのに自前で再実装していないか、用語や表記が統一されているかなどを検証します。デザイナーが用意したデザインシステムを読み込ませることで、このレベルのlinterへ変換できます。例えばトークンの直書き検出であれば、stylelintのプラグインを用いて「指定のトークン変数以外の値を記述した場合はエラー」とする設定を数行加えるだけで運用を開始できます。
機械判定できない領域は「決定権を持つ人」を定めておく
linterによる自動チェックの範囲を確定したら、残りの判定を担当する役割を定めます。「この画面はこの目的に適しているか」「より適切な表現はないか」といった問いは、前述のボタン配置と同様に答えが1つに定まりません。機械に強硬に判定させると、柔軟性が必要な部分まで固定化されてしまいます。かといって担当者を曖昧にしたままでは、生成された画面がレビュー待ちのまま滞留してしまいます。
振り分けの基準となる問いは図のとおり2点のみです。「正本が存在するか」「その変更は破壊的か」です。
正本が存在し、変更がその範囲内に収まる非破壊的なものであれば、機械がレビューを担当します。CIが通過すればそのままリリースして問題ありません。文言の統一やトークンの置き換えといった変更は極力ここに集約し、人を介さずに進めます。
正本が存在しても変更が破壊的（正本側の更新を伴うもの）である場合は、人間の判断が必要となります。ただし、ここで判断すべきは画面単体の出来栄えではなく「正本を更新すべきかどうか」です。ルールを変更する決断は、ルールを管轄する人にしかできません。
最も注意が必要なのは、正本が存在しない領域です。AIも人間も推測で補うようになり、少しずつ仕様の異なる「それっぽい」画面が乱立してしまいます。この領域については、職種を問わず画面に責任を持つ担当者を1人指定し、その人の判断に一任する運用にします。各自が個別に行った意思決定を後から追跡するのは困難ですが、担当者が集約されていれば判断の経緯や責任の所在を明確に保てるためです。
多くの組織ではエンジニアに対してデザイナーの人数が少ないため、デザイナーのレビューを必須にすると開発速度が低下するリスクがあります。その場合は、デザインの厳密さよりもリリースの速度を優先する判断も合理的です。画面の見た目や使い勝手に多少の問題があっても、即座に事業上の重大なリスクへ直結するケースは限られているからです。
リリース後にユーザーからの要望やアクセスログをもとに目星をつけ、後から改善に着手しても遅くはありません。先進的なWeb企業においても、良かれと思って作った改善案の大半が、実際の計測では効果が出なかった事例が公表されています。リリース前の議論を重ねるよりも、公開後に計測して修正するサイクルに重きが置かれています。
エージェントによる生成量が人間のレビュー能力を超える環境では、「修正のやり直し」のコストは低く、「リリースを停滞させる」ことのコストの方が高くつきます。先行するチームでも、マージをブロックするポイントは最小限にとどめ、問題は後から修正する方針が採用されています。最も重要なのは開発サイクルを維持し続けることです。
この振り分けが機能し始めると、機械が受け持つ領域はトークン準拠、用語統一、アクセシビリティ、コンポーネントの突合となります。エンジニアが担当できる領域は、正本の範囲内での画面生成と既存パターンの組み合わせです。
デザイナーが注力すべき領域として残るのは、ブランディングの定義、新たなユーザー体験の探求、正本の更新判断、そして前例のないドメイン固有の体験の設計です。具体的には、同じ操作に対して画面ごとに異なる名称が使われている際の統一判断や、業務現場の特殊な制約を画面仕様へ翻訳する作業などが挙げられます。
なお、個人情報の取り扱いや事業の中核を担う業務画面などの高リスク領域については、正本が存在する場合であっても人間のレビューを経由させます。CODEOWNERSなどの機能を活用し、対象のディレクトリやファイルに対して必須レビュアーを指定すれば、運用上の注意書きではなくシステム上の制約として運用できます。
