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

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

　第1回では、デザイン判定のうち機械に任せられる領域をプロセスも含めて整理しました。第2回となる今回は、生成された画面の仕分け方を解説します。ハーネスにおける検知には事前検知と事後検知が存在します。デザイナーによる事前レビューに回すべき画面と、リリース後に回すべき画面をどのように判別すればよいのか、具体的に見ていきましょう。

生成された画面を、すべてデザイナーに見せることはできない

　AIが生成したコードを人間がどこまでレビューするかは、チームによって判断が分かれます。一方UIに関しては、これまでリリース前に画面を確認する役割をデザイナーが担ってきました。

　ところが国内のBtoB開発現場では、専任のUI/UXデザイナーが不在のチームが7割を超えています。デザイナーが在籍する組織であっても、1人で複数のプロダクトを兼務することは珍しくありません。このような体制において、生成されるすべての画面をデザイナーが確認することは現実的ではありません。

デザインレビューは、実装の確認からリスクの確認に変わった

　従来のデザインレビューは、リリース直前に実施されるケースが主流でした。主なレビュー観点は「デザインデータどおりに実装されているか」であり、画面を設計したデザイナー本人がレビュアーとなり、意図したレイアウトや操作性になっているかを確かめていました。なお、動作不具合の確認はQA担当の領域として明確に区別されていました。

　しかし昨今では、デザイナーが事前にデザインデータを作成する機会自体が減少しています。それに伴い、レビューの目的も「生成された画面を確認する作業」へとシフトしてきました。確認すべき観点は次の3点です。

1. デザイン上のリスクが存在しないか
2. 国内の一般的なユーザーにとって定石とされる体験や表現になっているか
3. 表現を対象ドメインの文脈に当てはめた際、妥当であるか

人間同士で判断が分かれるところは、ハーネスでは担保しない

　機械的な判定が難しい項目として、例えば以下のような指摘が挙げられます。

• ボタンの文言（ラベル）が適切か
• 選択肢をラジオボタンで並べるか、セレクトボックスにまとめるか

　これらはいずれも、ユーザー体験や業界の慣習によって最適解が変化します。実際に見てみなければ判断がつかない類いのものであり、現時点では人間にしか評価できません。

• ハーネスで担保しないもの：人によって判断が分かれる上記のような指摘です。デザイン部門で組織としての見解をすり合わせ、ルールとして保守する程度にとどめるべきであり、この領域までハーネスで精緻に判定しようと期待するのは避けた方が賢明です。
• 担保しない理由：機械的な判定の実装が難しく、生成過程においてどのルールがどのように作用したかを検証するコストに対して、得られる恩恵が少ないためです。
• 具体例による切り分け：ボタンのラベルが多少分かりにくかったり、ラジオボタンとセレクトボックスの使い分けが不揃いであったりしても、リリース後に修正できます。一方で、申込みの最終確認画面で支払時期の表示が欠落していた場合、後から修正してもすでに締結された契約を取り消すことは困難です。リリース前に人間が介入して止めるべきなのは、このように「後戻りできない要素」に限られます。