ユーザーの視点から見ると、AI システムは本質的に不確実です。一貫性のない結果を生成したり、定期的に間違いを犯したりする可能性があります。ユーザー インターフェースには、AI の制限による不満を吸収、フィルタリング、軽減する多くの機会があります。デベロッパーは、AI システムがどのように、どこで失敗する可能性が高いかについてより深い洞察を持っているため、AI ユーザー エクスペリエンスの形成において中心的な役割を果たします。
設計上の重要な考慮事項の 1 つは、ユーザーが AI をどの程度制御できるかということです。機会には、ユーザーに表示されないものと、明示的なインタラクションがあるものがあります。公開範囲が広くなると、柔軟性は高まりますが、管理する必要があるリスクと複雑さも増します。
このモジュールでは、バックグラウンド、制約付き、オープンエンドの 3 種類の公開について、ユーザー エクスペリエンス（UX）パターンを設計するためのベスト プラクティスを学びます。各タイプについて、技術的およびアーキテクチャ上の選択が AI システムのユーザー エクスペリエンスにどのように影響するかを説明します。
Background AI
AI を使用すると、新しい機能を導入することなく、既存のエクスペリエンスを微妙に拡張できます。これにより、中断と障害の可能性を最小限に抑えることができます。この場合、有用性、信頼性、グレースフル デグラデーションの責任はすべてプロダクトにあります。ユーザーは、AI の仕組みを理解したり、AI が関与していることを知らなくても、AI のメリットを享受できます。
背景 AI は、次のような場合に最適です。
- タスクのリスクは低い。
- ユーザーによる制御によって結果が大幅に改善されることはない。
- AI 機能が失敗したり、利用できなくなったりしても、プロダクトは引き続きコアバリューを提供できます。
スパムフィルタからエンターテイメントのおすすめ、さらには BILIBILI の弾幕コメントのような複雑な例まで、ウェブ上にはバックグラウンド AI の例が数多く存在します。これらの機能の中には、AI とは認識されていないものもあるかもしれません。
例: AI を活用したレビューの要約とハイライト
Example Shoppe を覚えていますか？これまでに、カスタマー サポート機能や強化された商品検索など、さまざまな AI 機能に対応する 2 つのシステム ブループリントを公開しました。今回、3 つ目の機能としてレビューの要約を導入します。AI システムのブループリントをご覧ください。
商品ページには、数百件のレビューが掲載されていることがよくあります。ユーザーにとって、実際に重要な特性を評価することは難しい場合があります。
AI を使用して、検索で繰り返し表示されるテーマを特定し、パーソナライズされたレビューのハイライトと要約を提供できます。この例のインターフェースでは、ユーザーがヘッドフォンを探しているため、音質とバッテリー駆動時間に関するテーマがハイライト表示されています。これにより、認知負荷が軽減され、購入の意思決定が迅速に行われるようになります。
要約はユーザーごとに異なるため、プラットフォームを選択する際は、プライバシーとスピードを優先する必要があります。組み込みの AI と Summarizer API を選択して、ユーザーのデバイスで直接計算を行うこともできます。
ベスト プラクティス
AI 機能が既存のユーザー エクスペリエンスにシームレスに統合されるように、次のガイドラインに沿って実装してください。
- 軽量な透明性を提供する: AI がユーザー作成コンテンツを変換または集約する場合、微妙な合図によってユーザーの期待値を設定します。「概要」や「主な分析情報」などのニュートラルなラベルを使用し、ツールチップなどの UI 要素を通じて段階的な開示を追加できます。
- オプトアウトを許可する: AI に対するユーザーの考え方はさまざまです。AI を邪魔、圧倒的、迷惑と感じる人もいます。これらの機能を無効にする明確な方法を提供します。
- 言葉遣いに注意する: 言葉遣いは、AI 生成テキストを含め、あらゆるユーザー エクスペリエンスにおいて重要な要素です。この例では、要約は主張ではなく傾向を反映する必要があります。システム プロンプトにルールを追加して、要約で過度に自信のある表現を減らすか削除します。
- グレースフル フォールバックを設計する: 可能な場合は、AI を使用せずに値を提供します。モデルが利用できないなどの技術的な理由で要約を利用できない場合でも、システムは要約されていないレビューを提供する必要があります。モデルがダウンロードされると、アプリケーションは新しい要約を自動的に公開できます。
- セットアップ中の中断を最小限に抑える: クライアントサイド モデルの初回ダウンロードで摩擦が生じる可能性があります。まず、機能の価値を実証します。制限付きのサーバーサイド フォールバックを追加するか、ダウンロードをユーザー ジャーニーの最後に移動して、中断を最小限に抑えることができます。適切なタイミングとコンテキストの構築により、プロダクトをユーザーの優先順位に合わせることができます。
制約付き AI
バックグラウンド AI は自動的に実行されますが、制約付き AI 機能はユーザーによって明示的にトリガーされます（多くの場合、リンクまたはボタンを使用）。タスク、インテント、制約、出力形式はシステム プロンプト内で決定します。オープンエンドのプロンプト カーソルとは異なり、ユーザーはタスクを開始して出力を受け取る以外のオプションをほとんど利用できません。AI ができることを厳密にスコープすることで、システムの予測可能性を維持します。
バックグラウンド AI と同様に、制約付き AI 機能は、特定のタスク用にカスタマイズされたクライアントサイド モデルと相性が良いです。
例: タイトルの生成
見出しの生成は特に難しいタスクです。BlogBuddy は AI を使用して、ライターが最小限の労力で思慮深くコンテキストに沿った見出しを作成できるようにします。この機能の AI システム ブループリントを確認します。
ユーザーは [タイトルを表示] をクリックして、評価と改善のために複数の下書きを作成できます。
プロンプト エンジニアリングでは、Prompt API を使用してこれを実装する方法について説明しました。タスク、スタイルの制約、出力構造をエンコードするシステム プロンプトを作成します。ブログ投稿のコンテンツのみが UI から動的に渡されます。クライアントサイドの実装では、この機能は設定費用なしで反復処理を行うように最適化されています。
ベスト プラクティス
ユーザーに新機能を使ってもらうことが目標です。そのためには、価値を示し、結果をコントロールできるようにします。
- 明確さと自信を伝える: 「AI に質問」のような一般的な表現よりも、明確なアクション ラベルが常に望ましいです。ユーザーは、何が起こっているかを直感的に理解できる必要があります。どのように起こっているかだけでなく、何が起こっているかを理解できるようにします。特徴のレイテンシが低い場合は、結果がすでに利用可能であることを伝えるラベルを追加します。たとえば、[タイトルを表示] ではなく [タイトルを生成] とします。
- ユーザーに情報を知らせる: ユーザーの注意を引くために、軽度の認知摩擦を加えます。複数の選択肢を提供することで、ユーザーが気に入らない結果に不満を感じるのを防ぐことができます。ユーザーは、結果が保存される前に明示的に承認または編集できる必要があります。
- 可能であれば、結果を事前に準備する: 特にクライアントサイドのタスクでは、結果を事前に計算して、すぐに利用できるようにすることを検討してください。
- 高速イテレーションをサポートする: 再生成は簡単で、元に戻すことができ、安価である必要があります。ユーザーは操作を元に戻すことができる必要があります。これらのフィードバック シグナルを収集して、今後の実行に向けて機能を微調整できるようにします。
- 必要に応じて、よりきめ細かい制御を行う: トーンタグ、長さセレクタ、プリセット スタイルなどの追加の構造化要素を使用して、結果を絞り込むことができます。多くの場合、ユーザーの信頼と要件が進化するにつれて、追加の制御の必要性が生じます。こうした開発を追跡できるフィードバック ループを設定します。
バックグラウンド AI と制約付き AI のどちらを選択するか
一部の機能は、表示方法や表示タイミングに応じて、バックグラウンド AI または制約付き AI として実装できます。この区別は、利用可能な機能ではなく、視認性、認知負荷、タイミングによって影響を受けます。たとえば、明示的なボタンクリックを必要とするのではなく、ユーザーが入力している間にタイトルをバックグラウンドで事前に作成できます。ユーザーがタイトルのフィールドにフォーカスしたときに、候補を表示できます。
このアプローチは、次のような場合に最適です。
- 機能に必要な入力はデフォルトで利用可能
- AI を活用した機能の数が少ない
- 事前計算のコストが低い
- ユーザーがタスクに集中できるように、提案を統合できる
一方、複数の AI 機能やアクションを備えたプロダクトでは、制約付き AI が適しています。明示的なトリガーを使用すると、不要な計算を回避でき、ユーザーは意図と主体性をより強く感じることができます。
オープンエンド AI
オープンエンド AI を使用すると、ユーザーは自由形式の入力で AI システムの動作を直接制御できます。ユーザーは、事前に決定されたアクションをトリガーする代わりに、自然言語でコンテキストを指定できます。送信されると、AI システムは意図を解釈し、不足しているコンテキストを追加して、次に何をすべきかを推測します。
入力は非常に個別的で予測不可能なことが多く、AI システムはこの変動に対応できる必要があります。このタイプは柔軟性が最も高いですが、ユーザー エクスペリエンスに対するリスクも最も高くなります。
- 曖昧または不完全なユーザー入力
- 予測不能な出力
- 不正確な回答や誤解を招く回答が生成される可能性が高くなる
- 過信のリスクの増大
- システムを侵害しようとする（不適切なコンテンツを生成させるなど）
例: AI を活用したカスタマー サポート エージェント
Example Shoppe の場合、カスタマー サポートは、注文の追跡、返品、製品に関する質問、配送に関する問題、明確なワークフローに当てはまらないエッジケースなど、幅広い問題に対応します。プラットフォーム モジュールの AI システムのブループリントを思い出してください。
最も一般的なアクションに制約付き AI 機能を追加すると、インターフェースが混雑する可能性があります。代わりに、オープンエンドの AI サポート エージェントは柔軟性を提供できます。
- 一般的な問題をすばやく解決します。
- 待ち時間とサポート費用を削減します。
- 複雑なサポートフローなしで、さまざまなトピックについて即座にサポートを提供します。
サポート エージェントの価値は、変動性を大規模に処理することにあります。最終的には、これらの入力を責任を持って処理できるシステムを構築する必要があります。ユーザーが最善の判断を下し、信頼性を調整することを期待している場合でも、モデルが提供した誤った回答に対して責任を負う可能性があります。
お客様がエージェントとのチャットを開始し、「注文した商品はどこにありますか？」や「二重請求されています。どうすればよいですか？」などと質問します。エージェントは意図を解釈し、確認のための質問をし、関連情報を取得して、次のステップやアクションを提案します。
ほとんどのオープンエンド AI システムはサーバーサイド モデルに依存しています。これらは、データベース、外部ツール、ビジネス ロジックなどの他のコンポーネントと組み合わせて、複合 AI システムを形成できます。人間のサポート エージェントへのエスカレーション パスを提供する必要があります。
ベスト プラクティス
透明性、信頼性の調整、制御メカニズムに重点を置きます。
- ユーザーが意図を明確に表現できるようにガイドする: プロンプトの候補（「注文を返品したい」など）とフォローアップの候補を提示して、曖昧さを軽減します。
- システムの状態と前提を可視化する: エージェントは、理解した内容（「注文番号 12345 についてお問い合わせのようですね。」など）と使用している情報を明確に伝えます。
- 行動の前に確認する: 返品、払い戻し、住所変更などの機密性の高い操作を実行する前に、エージェントは操作の概要を説明し、ユーザーに確認を求める必要があります。
- 確認と修正のための設計: ユーザーは、最初からやり直すことなく、誤解を修正したり、リクエストを言い換えたり、会話を巻き戻したりできる必要があります。
- 制約付き AI 機能と組み合わせる: 会話のやり取りが多すぎると、ユーザーが離れてしまう可能性があります。構造化要素をショートカットとして追加します。たとえば、推測された注文番号は、ユーザーがリクエストをテキストで言い換える必要がないように、クリック可能な要素として表示し、検索、選択、置換できるようにすることができます。
- 不確実性と制限を明確にする: エージェントは、不確実性を認め、不足している情報を伝え、信頼度が低い場合は適切に人間のエージェントにエスカレーションする必要があります。
このタイプの AI エクスペリエンスでは、ユーザーが回答を批判的に評価し、エスカレーションのタイミングを理解する必要があります。
重要なポイント
このモジュールでは、さまざまな種類の AI ユーザー エクスペリエンスについて説明しました。
- バックグラウンド AI を使用すると、既存のユーザー ジャーニーに付加価値や喜びを追加できます。
- 制約付き AI 機能は、AI で実行するのが最適な、明確に定義された特定のユースケースで使用できます。
- 変動性の高いドメインには、オープンエンド AI が必要です。システム技術のパフォーマンスに自信がある場合にのみ、オープンエンドを使用してください。
次の表に、各タイプの AI に推奨される UX パターンの概要を示します。
| UX テーマ | UX パターン | 背景 | 制約あり | 自由記述 |
| 外部音取り込み | AI が明確に示されている | |||
| AI の動作に関する簡単な説明 | ||||
| システムの状態と前提条件が可視化されている | ||||
| ガイダンス | プロンプトの候補 | |||
| 構造化入力（タグ、プリセット） | ||||
| 管理 | 明示的な AI トリガー | |||
| 出力を適用する前にプレビューする | ||||
| 複数の候補 | ||||
| 再生成 | ||||
| 元に戻す | ||||
| 信頼の調整 | 控えめな表現 | |||
| 信頼度インジケーター | ||||
| リスクと障害の管理 | 意図的な摩擦とレビュー ゲート | |||
| 人間への引き継ぎ / エスカレーション | ||||
| AI を使用しない正常なフォールバック |
参考資料
UX パターンについてさらに学習するには、以下のリソースをおすすめします。
- Google の People + AI ガイドブックをご覧ください。
- Microsoft の HAX Toolkit、特に人間と AI のインタラクションに関するガイドライン。
- The Shape of AI（Emily Campbell）
- AI プロダクト開発の技術の第 10 章。
理解度を確認する
ビデオ通話の背景のぼかしはどのような UX パターンですか？
オープンエンドの AI を UX パターンとして使用するのはどのような場合ですか？