専任デザイナー不在でも破綻しない、AI生成画面を安全にデプロイするためのハーネス設計

UI/UXにおけるハーネスエンジニアリング実践論　第2回

高リスク体験や画面以外は、リリース後にデザイナーが直す

　ここまでの判断基準を整理すると、以下の図のようになります。

生成された画面の行き先を決める分岐図。問い1「戻せない画面か」がはいならマージ前にデザイナーが承認（CODEOWNERS）。いいえなら問い2「正本に書いてあるか」へ進み、はいならlinterとCIで判定して自動マージ、いいえならマージしてリリース後にデザイナーが直す

　「一方通行のドア」に該当しない一般的な画面は、マージをブロックせずに素早くリリースします。そしてリリース完了後に、デザイナーがコードベース上でUIをリファクタリングしていく運用を私は推奨しています。

　この運用体制は、海外の先進的なデザイン組織でも導入が進んでいます。例えばIntercomでは2025年以降、デザイナーがCursorなどのAIコードエディタを活用し、UI品質の課題をコードベースから自ら発見して直接修正しています。エンジニアによる簡易的なコードレビューを経て本番環境へ反映させることで、従来後回しにされがちだった軽微な品質負債を、デザイナー自身が迅速に解消しています。

　ただし、事後対応は仕組み化しておかなければ形骸化してしまいます。これは技術的負債への対処と同様です。あらかじめ負債を許容してリリースした機能については、返済計画を開発サイクル内に確実に組み込み、自動的または定期的に改修が進む枠組みを整えておく必要があります。

　デザイン負債とは文脈が異なりますが、OpenAIにおいても「エージェントが既存の不揃いな実装パターンを複製し、コードベースの乖離が徐々に広がる」という問題に対して同様のアプローチを取っています。当初は毎週決まった曜日に手作業で負債解消を行っていたものの継続が難しくなったため、リポジトリに準拠すべき原則を明文化し、不整合を検知して軽微な修正プルリクエストを定期実行で自動作成する仕組みへと移行しました。

　私の支援先においても、リリース後の人手によるレビューや修正作業はスケールしにくいのが実情です。説明責任を果たすために人間が過度に細かく確認してしまいがちですが、まずは「人間が見なくても重大なリスクにならない画面」を確実に自動マージへ切り替えるべきです。

　そして創出されたリソースを定期的なUI改善へと充てていくのが現実的な解といえます。人手で行っていた定常作業も、トリガー、ログ、実行結果のフィードバックを仕組み化できれば、ハーネスの一部として組み込めます。最初から完璧なハーネスを構築しようと気負うのではなく、まずは定期実行の運用から着手することをお勧めします。

　では、どのタイミングで定期実行を行うべきでしょうか。UIの刷新に当てはめて考えると、以下の2つのサイクルで運用するのが効果的です。

• 日常の周期（頻度はスプリントや開発計画に応じて設定）：リリースされた画面の微細なズレをデザインチームが検知し、類似するデザイン負債をまとめて修正PRとして提出します。ストリームアラインドチームが追う事業開発を阻害しないよう、頻度は余力リソースと開発ロードマップに合わせて柔軟に調整します。
• 2〜3年ごとの中長期的な周期：日常的なパッチ修正によって生じた体験やUIの全体的な歪みを、包括的にリニューアルします。同一のドメインオブジェクト（例えば「顧客」「案件」「請求」など）を扱う主要画面を並べ、操作性や表示ルールが統一されているかを確認します。差異が認められた場合はデザインチーム内で統一方針を策定し、改修規模、リリース時期、事業インパクトをプロダクト責任者と協議した上で、専任プロジェクトとしてリソースを確保して推進します。

　この2〜3年という周期は、プロジェクト管理ツールを展開するLinearのデザイン責任者、Karri Saarinen氏が提唱する「プロダクト全体の体験バランスは2〜3年ごとにまとめて再構築するのが望ましい」という知見に基づいています。近年のデザインシステムやフロントエンド技術の進化スピードを考慮しても、非常に妥当なインターバルといえます。

「後戻りできない画面」の検出をLLMに委ねる

　レビュー対象を絞り込んだとしても、対象となるPRを人間が手作業ですべて洗い出していては運用の負荷は軽減されません。AIによって生成されるPRが急増する中、対象PRを特定して差分を読み解く時間は、PRの増加に比例して肥大化していくためです。

　そこで私の支援先では、リスク判定そのものをLLMに担わせる検証を進めています。あらかじめ判断基準をプロンプトとして定義し、対象のPRやIssueチケットが「一方通行のドア」に抵触するかどうかを一次判定（スクリーニング）させるアプローチです。

　現時点では試行段階ですが、極めて良好な結果が得られています。判断基準のドキュメントのみを与えた独立セッション環境で「取り消し可能性」および「正本（デザインシステム）の準拠性」を判定させたところ、用意したシナリオはすべて正しく分類され、判定に要した時間はわずか30秒ほどでした。さらに100件以上のチケットをLLMに自動分類させた際も、人間の事前レビューが必要と判定されたのはわずか1件のみでした。

　運用開始時はマージを停止させない「監視モード」からスタートし、LLMの判定精度が確認できた領域から段階的に自動振り分けへと移行させています。デザインシステムをはじめ、デザイン資産をあらかじめ構造化・コンポーネント化（工業化）できている組織ほど、ハーネスへの移行がスムーズであり、その恩恵を最大限に享受できます。

直近1週間のUI変更を「後戻りできるか」で仕分ける

　ここまで、デザイナーが事前にレビューすべき画面の基準と、それ以外の画面をいかにハーネスへ組み込むかについて解説してきました。最後に、明日から実践できる具体的なアクションを紹介します。直近1週間にマージされたUI関連のPRを、下表のフローに当てはめてみてください。

問い	はいの場合	いいえの場合
金銭・誤認・取り消せない操作・顧客の対外操作のいずれかに抵触するか？	マージ前にデザイナーが承認する。CODEOWNERSで必須レビュアーにする	次の問いへ
正本（デザインシステム）に定義済みのコンポーネント・仕様であるか？	linterとCIで判定し、通れば自動でマージする	マージしてリリースし、事後にデザイナーが修正

　前の節で触れた支援先のように、事前のレビューが必要なものはごく一部に収まるはずです。このくらいの数であれば、多くのチームで、デザイナーに見てもらいやすいのではないでしょうか。

　重大なリスクに関わる画面のみを事前レビューで厳密に担保し、それ以外の画面はリリース後に有用性を検証した上でデザイナーが「リファクタリング」を行う――こうした開発スタイルは今後確実に一般化していくと考えられます。

　その際、新たな議論として浮上するのが「事後改修における責任の所在」です。万が一、操作性や誤認に起因するトラブルが発生した場合、その責任は誰が負うべきなのでしょうか。コードを生成したエンジニアなのか、リリースを承認した関係者なのか、それとも改修を行わなかったデザイナーなのでしょうか。

　AIによって作業の実行責任を委譲できるようになった現在でも、意思決定の説明責任やシステムの挙動を正しく理解する責任は、依然として人間に委ねられています。第3回は、ハーネス運用と切り離せない「AI生成画面における責任の所在」について掘り下げていきます。