専任デザイナー不在でも破綻しない、AI生成画面を安全にデプロイするためのハーネス設計
UI/UXにおけるハーネスエンジニアリング実践論 第2回
ハーネスで担保すべきは「取り返しのつかない体験」の是正
エンジニアの皆さんには馴染み深い、「取り返しのつくものは素早くリリースし、つかないものは慎重に決定する」というアプローチがあります。この考え方を画面のレビューにもそのまま適用します。
Amazon創業者のジェフ・ベゾス氏は、引き返せない重大な決定を「一方通行のドア」と呼び、それ以外の決定は軽量なプロセスで迅速に進めてよいと説きました。OpenAIもAIエージェントのガバナンスに関する文書において同様の指摘をしています。すなわち、事後レビューのみで進行するアクションは、事前承認を要するアクションよりも容易に取り消せなければなりません。
UIにおける「一方通行のドア」とは、後から修正してもユーザーが失った金銭や信頼を取り戻せない体験を指します。具体的にどのような要素が該当するかは、法規制やアクセシビリティ規格によってすでに示されています。
金銭:申込みの最終確認画面
通販サイトなどの最終確認画面については、特定商取引法第12条の6(2022年施行)により、6項目の表示が義務づけられています。対象となるのは、分量、販売価格、支払の時期と方法、引渡しの時期、申込みの期間、申込みの撤回と解除に関する事項です。生成された画面でこれらの項目が1つでも欠落していれば、リリース後に修正しても発生した契約上の不利益は解消されません。
誤認:価格や期間を取り違えさせる表示
消費者庁が2025年に実施した国内サイトの実態調査でも、デフォルトでチェックが入った選択肢や、視覚的な強弱によって誘導を図る表示が多数確認されています。開発側に悪意がない場合でも、AIによって「初回限定価格のみが極端に強調された画面」が意図せず生成されるリスクがあります。
取り消せない・完了できない:解約や送信の導線
WCAG 2.2の達成基準3.3.4(エラー防止)では、法的な合意や金銭取引を伴うデータ送信に対し、「取り消し可能であること」「送信前に確認・修正できること」「確定前に再確認できること」のいずれかを求めています。申込み完了画面や確認メールにキャンセルの手順が明記されていない画面や、一斉送信機能において確認ダイアログや取り消しの猶予期間が設けられていない設計などが該当します。AI生成画面において発生しやすいのは、意図的な囲い込みよりも、こうした仕様の「実装漏れ」です。
業務の中枢:顧客が自分の取引先に対して行う操作
BtoBプロダクトにおいては、顧客が自社の取引先に送付する見積書やメッセージのように、画面上の操作が直接取引先に到達する機能が該当します。他の項目とは異なり公的な外部規格は存在しませんが、「顧客が行う対外的な重要操作」と捉えると分かりやすいでしょう。
業務システムのUI不備が重大な事故につながった実例は枚挙にいとまがありません。過去には米国の金融機関において、本来は利息のみを支払う意図であったにもかかわらず、送金画面の極めて分かりづらいUI設計が原因となり、意図の100倍以上におよぶ元本全額を誤送金してしまった事例が知られています。
もちろんこの事例でも社内マニュアルやダブルチェック体制は存在していたため、画面設計のみに責任を帰することはできません。しかし、やり直しの利かない操作ほど慎重な設計が求められます。画面が何を実行するものなのか、各ボタンや入力フォームがどのような影響を及ぼすのかを、ユーザーが直感的に正しく認識できる構造にしておかなければなりません。プロダクトを提供する側の責任として、リリース前にその可読性と安全性を担保する必要があります。
「金銭」「誤認」「取り消せない操作」「業務の中枢」という4つの観点に関わる画面こそが、マージ前にデザイナーが事前レビューを行うべき対象です。第1回で紹介した「CODEOWNERS」機能を活用すれば、該当するコードディレクトリに対して必須レビュアーを自動指定できます。これにより、リスクレビューを組織の属人的な運用から「システムの制約」へと昇華させることが可能です。
人間が目視で確認しても、すべての問題は拾えない
前述の事例が示すように、人間が承認フローに入ったとしても見落としは発生します。ユーザビリティ工学の分野では、評価者1名が見つけられる問題は既知の課題全体の半分以下にとどまることが古くから知られています。4名の評価者に同一のユーザーテスト録画を個別に分析させた研究においても、全員が共通して発見できた問題は約2割に過ぎないという検証結果が報告されています。同一の事象を観察していても、着目するポイントは人によって異なるためです。このため、複数名が事前に相談することなく独立して評価を実施し、後から結果を持ち寄る手法が推奨されています。
しかし、専任デザイナーが不在のチームが大半を占める現状において、すべての画面にそうした手厚い体制を敷くことは困難です。だからこそ、ハーネスを構築する際にも人間が確認すべき対象を絞り込み、明確な優先順位をつける必要があります。
この記事は参考になりましたか?
- UI/UXにおけるハーネスエンジニアリング実践論連載記事一覧
-
- 専任デザイナー不在でも破綻しない、AI生成画面を安全にデプロイするためのハーネス設計
- ハーネスエンジニアリングの仕組みで実現するUIの品質担保【デザインハーネスの組み立て方】
- この記事の著者
-
イシジマ ミキ(イシジマ ミキ)
株式会社シン・ミキイシジマ 代表取締役。デザイン組織コンサルタント。マネーフォワード・SmartHRなど国内でも数少ない10名超のデザイン組織でプログラムマネージャーを務めた経験を基盤に、事業に資するデザイン人材の採用・育成・定着を一気通貫で支援することを専門とする。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
DeveloperZine編集部(デベロッパージン編集部)
DeveloperZineは、株式会社翔泳社が運営する、技術と組織の意思決定を支える情報メディアです。技術選定やチームづくりに向き合い、自分の判断を確かなものとしたいエンジニアやエンジニアリングリーダーに向けて、翔泳社主催エンジニアイベント「Developers Summit」とも連動しながら実践知...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
