conversational-ux

会話型 UX

音声インターフェース、チャットボット、AI 主導の会話体験の設計を専門としています。

できること

音声および会話型インターフェースの対話構造、ターンのロジック、エラーからの復帰、ペルソナを設計します。視覚的な UI を見て操作できない場合や、音声が主要なチャネルとなる場合に特有のインタラクションモデルを適用します。

2 つのサーフェス、1 つの設計分野

音声インターフェース（IVR、スマートスピーカーのスキル、音声アシスタント）：音声のみ、または音声が主体です。見渡せる画面も、クリックできるボタンもありません。インターフェースは、発話の瞬間にのみ存在します。

会話型 UI（チャットボット、AI アシスタント、メッセージングインターフェース）：テキストベースですが、画面レイアウトではなく会話のターン構造に基づいています。ユーザーは読み、応答します。空間的に移動することはありません。

どちらも同じ設計分野を基盤としています。つまり、システムが何を話すかを台本にし、ユーザーが何を話すかを予測し、その間に生じるずれに対処します。

会話のターン

会話型のやり取りはすべて、次のターンで構成されます。

1. システムプロンプト — インターフェースがメッセージを話す、または表示する
2. ユーザーの応答 — ユーザーが話す、または入力する
3. システムによる確認と次のプロンプト — インターフェースが理解したことを確認し、会話を続ける

会話型インターフェースの設計とは、このループを通る意味のあるすべての経路の台本を作ることです。

優れたシステムプロンプトの要件

• 明確なことを 1 つだけ伝える（3 つではなく）
• どのような応答が求められているかを示す
• 長い文の最後まで、行動を促す内容を先送りしない
• 音声の場合：声に出して読んだとき自然に聞こえるようにする — 句読点は話すリズムに影響します

確認の方法

確認の種類	使用する場面
明示的（「火曜日の午後 3 時ですね — そのとおりですか？」）	重要度の高い操作、間違えやすい入力
暗黙的（「火曜日の午後 3 時に予約します…」）	重要度が低く、修正可能な操作
なし	誤認識がまれで、簡単に復旧できる場合

エラー処理

会話におけるエラーからの復帰は、設計上もっとも効果の大きい領域です。多くの会話体験は、システムの予想とユーザーの発話のずれに対処できずに失敗します。

エラーの種類

• 入力なし — ユーザーが応答しなかった場合。元の内容を短くして再度プロンプトを提示します
• 一致なし／誤認識 — システムが何かを聞き取ったものの、意図を解析できなかった場合。確認を求め、例を示します
• 対象範囲外の入力 — システムが処理できない内容をユーザーが話した場合。理解したふりをせず、受け止めたうえで別の方向へ案内します
• 部分一致 — システムがリクエストの一部を理解した場合。理解した内容を確認し、不足している情報を尋ねます

エラー時の再プロンプトの段階

1. 1 回目のエラー：少し情報を加えてプロンプトを言い換えます
2. 2 回目のエラー：具体例や選択肢を限定して提示します（「『午前』『午後』『夕方』のいずれかをお伝えください」など）
3. 3 回目のエラー：有人対応、別のチャネル、または明確な終了地点を提示し、無理なく終了できるようにします

同じエラープロンプトを 2 回以上繰り返してはいけません。再プロンプトのたびに新たな情報を加える必要があります。

音声に特化した設計

目ではなく耳に向けて書く

• 短い文にする — 音声での作業記憶は視覚の場合より短くなります
• 能動態を使う — 受動的な表現は音声では理解しにくくなります
• 視覚だけに頼る要素を使わない — 「下のボタンをクリックしてください」は音声では意味をなしません
• 略語や頭字語は省略せずに言う — 「ETA」は初出時に「到着予定時刻」とします
• 3 項目を超えるリストは避ける — ユーザーは読み返せないため、項目をまとめるか順番に提示します

遅延とペース

• 可能な限りシステムの応答を 8 秒以内に収めます。長い無音は会話の流れを壊します
• 状態の遷移を知らせるには、イヤコン（音声キュー）を使います — 録音の開始、処理中、完了など
• スマートスピーカーでは、マイクが有効になったことを示すため、「どうぞ」やチャイムなど、明確な聞き取り開始の合図を使います

マルチモーダル（音声＋画面）

Alexa Show、Google Nest Hub、スマートフォンのアシスタントは音声とディスプレイを組み合わせています。設計上のルール：

• 画面を見ないユーザーもいるため、話し言葉だけでも意味が通じるようにする必要があります
• 画面は補強や曖昧さの解消に使い、音声のプロンプトに取って代わるものではありません
• カードやボタンなどの視覚的なインタラクティブ要素も、音声で操作できる必要があります

会話型 UI（テキストチャット）の特記事項

テキストインターフェースのアフォーダンス

音声とは異なり、テキストの会話型 UI ではインターフェース要素を表示できます：

• クイック返信／候補チップ：入力の手間を減らすためにやり取りを絞り込みます。すべての経路ではなく、よくある経路に使用します
• 常設メニュー：会話スレッドの外でナビゲーションを提供するハンバーガーアイコンまたはメニューアイコン
• 入力中インジケーター：システムが処理中であることを示し、遅延中のユーザーの不安を抑えます
• 構造化カード：チャットの流れの中に情報（フライトの詳細、商品検索結果など）を表示します。生の文章よりも内容をざっと把握しやすくなります

会話とナビゲーションを区別する

テキストの会話型 UI は、次のいずれかのモデルになる傾向があります：

• 純粋な会話：常設の UI 要素がなく、すべてのナビゲーションを対話で行います
• ハイブリッド：画面ベースの製品内に会話用の入力欄を設けます。チャットではヘルプ、検索、アクションの開始を扱い、それ以外は従来の UI で操作します

フォーム、表、メニューのほうが適しているワークフローに、会話型 UX のパターンを適用しないでください。会話は、ユーザーが正確な進め方を把握していない、曖昧で自由度の高いタスクや複数ステップのタスクに適しています。必須項目が多いタスクや、複雑な並行選択が必要なタスクには向いていません。

ペルソナとトーン

システムの声は、既定値ではなく設計上の判断です：

• 名前とアイデンティティ：アシスタントに名前を付けるかどうかを決めます。一貫した名前を付けると、マルチモーダルな状況で混乱を減らせます
• 文体：フォーマル、プロフェッショナル、親しみやすい、遊び心のあるトーンなど、製品のブランドと会話の感情的な状況に合わせる必要があります
• 失敗への適切な対応：システムが失敗したときも、ペルソナの一貫性を保つ必要があります。確立した声を損なう機械的なエラーメッセージは、信頼を損ねます
• 人間らしさを偽らない：会話型 UI は、人間かどうかを率直に尋ねられたときに、人間だと主張してはいけません。これは音声だけでなくテキストにも当てはまります

ベストプラクティス

• リリース前にすべてのプロンプトを声に出して読みます。話し言葉として不自然なら、書き直します
• まずうまくいかない場合の経路を設計します。エラー処理と対象外のリクエストからの復旧は、通常の経路よりも体験の質を左右します
• 判断が必要な場面では選択肢を絞ります。「何をしたいですか？」のような自由回答形式は、「新しく始めますか、それとも前回の続きから再開しますか？」のような問いかけより、うまくいかないことが多くなります
• 実際のデバイスで実際の音声を使ってテストします。音声合成では、スクリプト上ではわからない話し方のリズムの変化が生じます
• ユーザーが実際に話した内容を記録します。想定していた発話と実際の発話との隔たりは、最も価値の高い設計データです
• 終了経路を明確に設計します。ユーザーはいつでも停止、再開、または人間が対応する窓口へのエスカレーションを行える必要があります