Generative UIとは？デザイナーがAIに画面を任せる前に設計すべき5つのこと
AIの回答をカード・フォーム・比較画面として次の行動につなげるには、何を先に決めるべきか。最初のGenerative UIに必要な5つの設計上の問いを整理します。
AIに「2泊3日の旅行日程を作って」と頼めば、もっともらしい画面を何枚もすぐに作れます。ところがユーザーが日付をひとつ変えた瞬間、問題が始まります。料金カードは消え、フィルターは変わり、予約ボタンの意味も画面ごとに揺れてしまうのです。
この状況に心当たりがあるなら、いま必要なのはもっと長いプロンプトではありません。Generative UIで大切なのは、AIが画面を作る速さではなく、画面が変わってもプロダクトらしく振る舞うための境界を設計することです。
この記事では、生成UIとは何か、チャットボットUIとどこで分かれるのか、そしてAIにまだ慣れていないデザイナーが最初のプロトタイプ前に答えるべき5つの問いを整理します。読み終えるころには、見栄えのよいモックではなく、編集・取り消し・アクセシビリティまで検討できるブリーフを作れるはずです。
Generative UIは、回答を次の行動に変える
Generative UIは、AIに好き勝手なHTMLを生成させることではありません。ユーザーの意図、現在の文脈、ツールが取得したデータに合わせ、カード、フォーム、比較表、チャートなどの検証済みコンポーネントを必要なときに組み合わせて見せる手法に近いものです。
従来のチャットボットは、質問が変わっても、たいてい同じ入力欄と吹き出しで答えます。一方、旅行を比べるなら日付選択と予算スライダーを、複数の選択肢から選ぶなら比較カードとフィルターを先に出せます。文章で三度聞き返すことを、画面上の一度の操作で済ませられるのです。
Vercelはツール呼び出しの結果をReactコンポーネントにつなぐ生成UIの流れを公開しています。Flutterも、アプリが提供するウィジェットカタログとデータモデルの中でUIを組み合わせるGenUIを紹介しています。画面を「描く」というより、AIがいま必要なインタラクションを選び、プロダクト側が安全にレンダリングすると捉えるほうが正確です。Vercel AI SDK · Flutter GenUI
1. ユーザーがいま終えたいことは、一つか
最初のGenUIを「AI旅行アプリ」のように広く設定すると、すぐにデモ止まりになります。代わりに、ユーザーが三回以上聞き返している一場面を選んでください。たとえば「予算内の三つの旅程を比較して、一つを選ぶこと」です。
目標が明確なら、画面も変わります。長い推薦文ではなく、料金・移動時間・雨天時の代案を比べるカードと、一つだけ条件を変えられるコントロールが先に必要です。Generative UIの最初の問いは「何を生成するか」ではなく、「ユーザーがどんな決定をより早くできるようにするか」です。
2. AIが組み立てられるブロックはどこまでか
AIに自由なコード生成権限を与えると、ブランドらしさも品質も一緒にぶれます。現実的なのは、デザイナーが用意したレゴ箱の中でだけ組み立てさせることです。
ボタン、入力、選択カード、表、通知、ローディング状態を承認済みコンポーネントに限定し、色・余白・文言・エラー表現もトークンとルールで固定してください。GoogleのA2UIも、実行可能なHTMLやJavaScriptではなく、宣言的データと信頼できるコンポーネントカタログを中心に据えています。この方式は、デザインの一貫性とUIインジェクションのリスクを同時に減らします。Google A2UI
3. 根拠と不確実性は画面のどこに見えるか
AIの推薦結果は、見栄えがよいからといってすぐ信用できる情報ではありません。価格・在庫・ポリシーのように変化するデータには出所と確認時刻が必要で、確信度の低い提案には「要確認」という状態が必要です。
ここでデザイナーが設計するのはカードの見た目より、判断の根拠です。顧客インタビューを要約するツールなら、結論カードの下から元発言とサンプル数を開けるべきです。ユーザーが結果を読むだけで終わらず、なぜその推薦になったかを確かめ、修正できるようにすることが信頼の出発点になります。
4. 編集・再試行・取り消しはすぐ隣にあるか
生成結果は正解ではなく仮説です。だから「もう一度生成」だけでは足りません。ユーザーがどの条件を変えたかが分かり、結果の一部を直接直せて、前の状態に戻れる必要があります。
とくに決済・共有・削除のように元に戻しにくい操作は、AIが提案しても確認ステップを通すべきです。Appleの生成AIデザインガイドも、AIの利用を明確に伝え、ユーザーが結果を編集・再試行・取り消しできるよう勧めています。よいGenUIは、自動化の速さよりユーザーの操作権を目立つ位置に置きます。Apple HIG
5. AIが失敗しても、プロダクトは動き続けるか
モデルの遅延、データ不足、曖昧な依頼は例外ではなく基本シナリオです。読み込み中は実際の進捗を伝え、情報が足りなければ次に入力すべき項目を示し、生成機能を使わなくても重要な作業を行える固定UIを残す必要があります。
アクセシビリティも同じ原則です。生成後に検査するのではなく、コンポーネントの契約にラベル、キーボード操作、フォーカス順、コントラスト、エラーメッセージの方針を入れるべきです。生成される画面の数は多くても、使うブロックと行動ルールは少なく、検証可能でなければなりません。
最初のプロトタイプは、この5行で十分
最初からすべての画面を生成させる必要はありません。まずは次の一枚のブリーフから始めてみてください。
- ユーザーの目標: ユーザーがいま終えたい一つの判断
- 許可するコンポーネント: AIが組み合わせるカード・入力・表・チャートの一覧
- 必須の根拠: 表示すべきデータの出所・時点・不確実性
- ユーザーの制御: 編集・再試行・取り消しと、重要な操作の確認
- 失敗時の導線: データなし・遅延・エラー時の固定UI
Generative UIは、デザイナーを画面制作から追い出す技術ではありません。むしろ画面が流動的になるほど、「この人にいま必要な次の行動は何か」をより正確に定める必要があります。チャットボットを少し派手にするところから始めないでください。一つの繰り返し質問をカード、フォーム、比較画面に変えてみること。その小さな転換が、いちばん現実的な出発点です。