AI に UI を任せる前に決めておく「操作の重み」

AIDD デザイン室の武井です。AI 駆動開発の案件に UI デザイナーとして参加していて、要件定義チームが AI で作ったモックを UI の観点でレビューしています。その中で、AI に UI を任せるには、機能の説明とは別に「その操作がどれだけ重いか」を渡す必要があるとわかってきました。削除・通知・待ち時間・一覧表示の 4 つの UI を例に、何を決めておけばよいかを整理しました。

新しい AI 活用の Tips は出てきません。デザイナーだけでなく、PRD（プロダクト要求仕様書）を書く方にも読んでいただきたい内容です。

削除を頼むと、どの削除も同じ確認モーダルになる

AI 駆動開発を始めてまず感じたのは、決めることが想像以上に多いということでした。AI は画面を作るのが速い一方で、作っている途中で「ここはどうしましょう」という整理ポイントが次々に出てきます。そして、事前に決めていないところは AI が一律の既定値で埋めます。

たとえば「削除機能を実装して」と頼むと、次のような性質の違う操作に対しても、出てくるのは同じ「本当に削除しますか？」の確認モーダルでした。

顧客マスタの全削除は消すと影響が大きく、めったに行いません。チャットのメッセージ削除は影響が小さく、頻繁に行います。受注データの締め処理は影響が大きいうえに毎日行います。

確認モーダル自体は間違いではありません。ただ、顧客マスタを丸ごと消す操作とチャットの一言を消す操作が同じ扱いになっていて、ここに違和感があります。

AI に渡していない情報は「操作の重み」

違和感の原因は情報不足でした。AI に渡している情報と、渡していない情報を並べると次のようになります。

右の列をまとめて、ここでは 操作の重み と呼びます。重みを知らないので、AI は無難な既定値として削除確認モーダルを選んでいます。そしてこの重みは、業務を知っている人にしかわかりません。AI が推測で埋められない以上、人が判断基準を渡す必要があります。

AI に渡すものを 3 つの層で考える

AI に渡すものの全体像を、次の 3 つの層で整理しています。

1 段目の横断ルールは、DESIGN.md のようなデザインシステムの規範ドキュメント に書いてあるものです。3 段目は PRD に書きます。ここで扱うのは、その間にある 2 段目です。2 段目は書く場所というより 判断する工程 を指していて、判断が決まったら結果を横断ルールに書き足していきます。

正直なところ、AI 駆動開発を始める前は、この層があること自体を想定できていませんでした。

削除 UI を重要度と操作頻度の 4 象限に分ける

重みをそのままでは判断しにくいので、2 つの軸に分解します。

• 重要度: ミスしたときに誰がどれだけ困るか、元に戻せるか
• 操作頻度: 1 日に何回押すか

操作頻度を軸に入れているのは、毎回止めると 警告疲労 で確認が読まれなくなるからです。この 2 軸で削除 UI を 4 象限に分けると、次のようになります。

重要度が高く年に数回しか行わない操作では、対象名を入力させて あえて摩擦を設けます。一方、重要度が高くても毎日行う操作で毎回確認を出すと、誰も読まなくなります。そこでゴミ箱への移動で取り返しがつく状態を作り、完全削除だけを別の操作に切り出します。

同じ「削除」でも 4 種類あり、AI が既定値で出してくるのは左下（重要度・頻度ともに低）の確認ダイアログだけでした。残りの 3 つは人が指定しないと出てきません。

通知・待ち時間・一覧表示も同じ方法で整理できる

削除と同じ考え方で、ほかの UI も 2 軸の 4 象限に整理できました。

「通知」は緊急度と発生頻度で分ける

• 割り込むのは「行動を求める」ときだけ
• 毎日起きるものは、常に視界に置く
• 急がないものはベルに集約

「待ち時間」は処理時間と結果への依存度で分ける

• 結果がないと進めない → その場で待たせる
• 待たずに他の作業ができる → 裏で処理
• 長く待たせるなら、進捗の提示と中断

「一覧表示」は見せ方と主タスクで分ける

• 比べる → テーブル／比較カード
• 眺める → リスト／グリッド

デザイナーと要件を書く人で分担する

冒頭の「どの削除も同じ確認モーダルになった」という結果は、AI の問題ではありませんでした。機能は書けていても、その操作がどれだけ重いかを書いていなかったのが原因です。対策として、役割ごとに 2 つのことを分担します。

1 つ目は、判断軸をもとに UI パターンを用意することで、これはデザイナーの仕事です。前述の 4 象限の整理を、横断ルールに書き込んでおきます。

2 つ目は、PRD に判断材料を書くことで、これは要件を書く人にお願いしたい部分です。削除であれば、機能の説明に操作の重みを示す事実を書き加えます。

「削除」ボタン押下で当該顧客を削除する。
年に数回しか行わない。消すと関連する取引履歴も消え、復元できない。

2 行目のような事実があれば、AI は横断ルールの「重要度：高 × 頻度：低」に当てはめて、二段階確認を選べます。

操作の重みはお客様にしか分からない

「PRD に書く判断材料は、デザイナーが気づいて要件定義チームに伝えるのか、要件定義チームが自分で考えるのか」という質問をいただきました。年に何回行うか、消えたら誰が困るかは、業務を持っているお客様にしか分かりません。要件定義チームにお客様へ確認してもらい、PRD に書いてもらう必要があります。

実際の流れとしては、デザイナーが UI を作りながら「この操作はどれくらいの頻度だろう」と疑問を持ち、要件定義チームに確認をお願いすることが多いです。最初から PRD に書いてあれば、その往復が要らなくなります。

判断軸で見直したことで、必要な画面そのものが抜けていたという経験はまだありません。ただ、時間のかかる取り込み処理に完了通知がないことに気づかないまま進めていた、というコンポーネント単位の考慮漏れはありました。

まとめ

• AI は操作の重み（被害の大きさ・頻度・元に戻せるか）を知らないので、指定がなければ無難な既定値で UI を作る
• 重みは 2 軸に分解すると判断しやすい。削除は重要度 × 操作頻度、通知は緊急度 × 発生頻度、待ち時間は処理時間 × 結果への依存度で分けた
• デザイナーは判断軸にもとづく UI パターンを横断ルールに用意し、要件を書く人は PRD に判断材料となる事実を書く

一度決めた判断は横断ルールに積み上がっていくので、案件の実装が進むほど新しく決めることは減っていくはずです。一方で、今回の 4 つ以外にも判断軸が必要な UI はまだあると考えていて、案件を進めながら整理を続けています。

gaipack では、AI が参照できるデザインシステムの構築を AIDD デザイン として、PRD の作成を AIDD 要件定義 として支援しています。AI 駆動開発で UI の品質にお悩みでしたら、お気軽にご相談ください。