会話の設計

ここでは、デジタル・アシスタントで会話を設計するための概要レベルのベスト・プラクティスを示します。

ユーザーは、ソフトウェア・アプリケーションが人間同様の品質を備えることを暗黙のうちに期待します。アプリケーションがユーザーフレンドリとみなされるのは、多くの場合、礼儀正しさや常識といった人間的な特徴を示すためです。

会話型インタフェース(デジタル・アシスタント)の場合、期待はさらに高くなります。デジタル・アシスタントは人間の会話という概念に基づいて設計されるため、ユーザーの意識と無意識両方の期待にデジタル・アシスタントが応えられるように設計することが特に重要です。

会話型デザインは、基礎となるタスクやプロセスのインタラクション・モデルから技術的な側面を取り除き、ユーザーが理解しやすく魅力的に感じる自然な会話に置き換えます。

優れた会話デザインは、効率性を目指し、文脈を理解し、ユーザーへの背中を反映し、感情的に魅力的であり、優れた対話を構築します。エンジニアとして、良い会話デザインは達成しやすいと思うかもしれませんが、すべての偉大な歌手が良い歌詞を書く方法を知っているわけではないことに留意してください。良い歌詞の作者が歌えるわけではない。

デジタル・アシスタントは人間ではありませんが、デジタル・アシスタントが会話的手法ときっかけを使用し、人間的な思いやりを示せば、会話をさらに自然な(好ましい)ものに感じさせることができ、ユーザーをいら立たせる可能性を抑えることができます。デジタル・アシスタントのこのような特性によって、実際の懸念事項に対処できることをユーザーが確信できるようになります。

ユーザーにとってデジタル・アシスタントがさらに魅力的になるために役立つ会話手法をいくつか次に示します:

Orientユーザー

デジタル・アシスタントの設計の基本的な重要な部分は、ユーザーがデジタル・アシスタントを効果的に使用する方法を容易に発見できるようにすることです。

歓迎

ユーザーに対して幸先のよいスタートを切るためには、デジタル・アシスタントとユーザーがどのように出会うかを考慮してください。次を行う必要があります:

肯定的かつ友好的な紹介を用意します。
デジタル・アシスタントが実行できること、またはユーザーが次に実行すべきこと(あるいはその両方)を示します。
挨拶の言葉に変化を持たせます(特に繰り返し使用されるデジタル・アシスタントの場合)。

デジタル・アシスタントには歓迎のためのデフォルトの実装が用意されていますが、独自の実装を提供することもできます。

ヘルプ

デジタル・アシスタントの重要な役割は、デジタル・アシスタントが何を行えるかをユーザーに伝え、会話が予期したとおりに進まない場合に立ち往生しないよう支援することです。次を行う必要があります:

デジタル・アシスタントが、会話のどの時点でもヘルプのリクエスト(ヘルプを求める明示的なリクエストでも「どうすればいいでしょうか」といったさりげない質問でも)を処理できるようにします。
ユーザーが初めて使用する際と同様に、デジタル・アシスタントが実行できること、またはユーザーが次に実行すべきこと(あるいはその両方)を示します。

デジタル・アシスタントにはデフォルトのヘルプ実装が用意されていますが、自らヘルプ・エクスペリエンスを設計することもできます。

ユーザーによる終了

ユーザーが誤って開始した会話スレッドを強制的に終了させるのは、不適切なユーザー・エクスペリエンスです。ユーザーが会話を行っているときは、会話が予想どおりに進まなかった、またはその時点で会話を完了する意思がなくなったなど理由にかかわらず、ユーザーが会話を終了できる方法を確保しておく必要があります。

これにはいくつかの方法があります。たとえば、すべての選択肢リストに現在の会話を終了するオプションが含まれるようにすることができます。または、デジタル・アシスタントの組込みexitインテントを使用し、特定のリクエストを明示的に処理して現在の会話を終了できます。

ヒントと手がかり

スキルおよびデジタル・アシスタントの複雑さによっては、様々な形式のガイダンスおよび視覚的な手がかりをユーザーに提供して、何ができるかを示唆すると役立つ場合があります。これには、次のような形式があります:

メッセージ内のヒント(「...または、続行しない場合には、会話を終了するように指示してください」など)。
操作を完了した後で次に予期すべきことをユーザーに伝える情報。
一般的な操作のためのボタン。
会話の要所要所に含めるリマインダ。メニューの起動、会話の終了、ヘルプの要求、エージェントとの会話などを行う方法を説明します。
一部のチャネルでは、メッセージング・プラットフォーム固有の機能を利用して、終了やメニューの表示など一般的な操作のボタンを表示することもできます。

クイック応答を処理ボタンとして表示

ユーザーに情報の入力を求める場合、ユーザーが通常選択する内容に基づいてユーザーの選択を予測できる場合があります。

たとえば、カレンダーエントリの日付を要求する場合、共通オプションは「今日」または「明日」です。そのため、プロンプトの下には、「今日」と「明日」という2つのボタンを追加できます。ユーザーが2つのボタンのいずれかを選択するか、いずれかのボタンのラベルを入力すると、現在の日付または明日の日付が基礎となる変数に設定されます。

もう1つの例は、ボットに配信アドレスが必要な場合です。ファイルに自宅住所がある場合は、配送先住所を要求したり、宅配ボタンを含めることもできます。

クイック返信を使用する場合は、ボタンが唯一の選択肢ではないこと、およびボタンがメッセージによってトリガーされる可能性があることをユーザーが理解していることを確認してください。会話は音声も意味し、自分の音声を使用してチャットボットを操作するユーザーはボタンを押す機会がないことを常に覚えておいてください。ほとんどの場合、ボタンのラベルが記載されます。

相互理解の確保

会話をうまく進めるには、デジタル・アシスタントがユーザーを理解し、ユーザーがデジタル・アシスタントを理解していることを確認する必要があります。この点において役立つ技術がいくつかあります。

プレーン言語の使用

製品データベースの設計方法を話すユーザーはいません。ボットが、定義したペルソナがガイドするターゲット・オーディエンスの言語を使用していることを確認してください。例:

「ユーザーID」ではなく「ユーザー・アカウント」
「配送先住所」ではなく「配送先住所」
"The query did not return a result"ではなく"I tried my best but could not find what you were looking for"でした。

また、コンテキストとガイダンスを提供することで、メッセージをロボットによる音声化を減らすことができます。

だから、「あなたの注文IDは何ですか?」の代わりに、「私はあなたの注文を見つけるのを助けることができます」のようなより有用なメッセージを提供することができます。ご注文番号をお伝えいただければ、それは素晴らしいことです。そうでない場合は問題ありません。製品や日付で検索することもできます。

ユーザーに魔法の言葉を知ってもらいたくない

営業担当者が生成した収益と、その収益が予測目標にどのように対応したかをグラフィカルに表現してリクエストできるセールス・ボットを想像してみてください。

チャートは、追加するチャートのタイプ、ラベルを追加するかどうか、表示するY軸の数など、多くの関数を使用して作成できます。営業担当が「linear_plotにno_label double_y_axisがある円としてQ2 / 2021の売上を見せてくれ」などと言って統計を要求する必要があるデジタル・アシスタントは、実際には機能しません。

オプションを明確にし、会話を続け、ターゲット・オーディエンスの言語を使用します。ファンネル、ガント・チャート、散布図、バブル・チャートおよびパレート・チャートを提供する場合は、この情報を自分に保持し、ユーザーとは異なる方法で表示します。次に、そのボットのユーザーが尋ねる可能性が高い例をいくつか示します。

「Q2 / 2021の販売の概要を表示する」
「昨年と比較して、Q2 / 2021の売上を見せてください」

どちらの問合せでも、レスポンスを様々なタイプのグラフでレンダリングでき、ユーザーは必要なものを与える魔法の単語を理解する必要がありません。デジタル・アシスタントは直感的に使えるだけでなく、選択肢も少なくなります。次の項で説明するように、会話タスクを短くしておくことを念頭に置いておくことをお薦めします。

会話内でのフィードバックの提供

ボットがエスケープ・ゲームとして設計されていないこと、および十分なポインタ、フィードバック、確認、サインポストを提供し、ユーザーが現在何を期待しているか、次に何であるか、どのように立ち往生するかを常に理解できるように支援することを確認してください。これらの手法の例を次に示します。

確認: 「OK」ご注文頂きました>>
署名: 「OK。ご注文を承りました。次に、これをどこに送るべきかを知る必要がある」
プロンプト: "OK"ご注文を承りました。次に、これをどこに送ればいいのか知りたい。届けるべき住所を教えてください」
ヘルプ: 「OK」ご注文を承りました。次に、これをどこに送ればいいのか知りたい。だから、私がそれを配達するべき住所を知らせてください、またはあなたの自宅の住所に出荷するために下のボタンを使用してください。

ユーザーがどの情報を提供するかを知らない場合や、タスクの完了に関心を失う場合もあります。このような場合に役立つ1つの方法は、ユーザーがタスクを取り消したり、ヘルプ状態に移動するための追加のコントロール(ボタンなど)を表示することです。また、入力コンポーネントでmaxPrompts設定を使用すると、ユーザーが誤った情報を複数回提供したときにヘルプ状態へのナビゲーションを自動化することもできます。

ユーザー入力の明確化

スキルがユーザー入力を理解しているかどうか確認することをためらわないでください。言葉は対面していてもあいまいになる可能性があります。

たとえば、木曜日にユーザーが「次の土曜日に予約を入れます」と言った場合、日付は2日後または9日後として解釈される可能性があります。このケースでは、次のような表現でスキルに日付を確認させる必要があります。「念のため確認いたしますが、10日の土曜日でしょうか、17日の土曜日でしょうか。」

ダイアログ・フローでは、ユーザー入力の収集時にエンティティを変数タイプとして使用することをお薦めします。エンティティを変数タイプとして使用すると、ユーザー入力が検証され、あいまいさが自動的に検出されます。つまり、ユーザーにプロンプトを表示するときに適切な表現を見つけることが必要なだけです。

代替プロンプトの指定

前述したように、会話形式でメッセージを書くことが重要です。ただし、ユーザーが正しく応答しなかったためにこのメッセージを繰り返す必要がある場合はどうなりますか。例:

「Cool。これをどこに出荷するか教えてください」

会話形式で書かれたメッセージでさえ、繰り返されるとロボットに聞こえ、関係のないものになります。したがって、プロンプトが再表示される場合(または会話が繰り返される場合)にユーザーが異なるテキストが表示されるように、各プロンプトの複数のバージョンを記述する必要があります。

エンティティに定義された複数のプロンプトを使用して、代替プロンプトを自動的に表示できます。そのため、ユーザー情報がエンティティ・タイプ変数によって検証される場合は、エンティティのプロンプト・プロパティを使用して、必要な数のプロンプトを定義できます。エンティティの解決コンポーネントを使用して、変数を関連付けておく必要があります。

追加情報の段階的な開示

変化するプロンプトは素晴らしい。しかし、ユーザーが理解できなければ、言い換えは少しだけ改善します。ここでは、詳細情報を段階的に開示するか、必要に応じてエスカレーションします。

ボット:「クール」これをどこに出荷するか教えてください」
ユーザー:「自分」
ボット:「申し訳ありませんが、「私にとって」は機能していないようです。通りの名前、家番号、都市名を教えてもらえるなら、私はこれをあなたに送ることができます。
ユーザー:「自分に送信」
ボット:「試してみましたが、私にとっても機能しませんでした。ぜひここでお手伝いしたいと思います。僕の仲間と話したいのかもしれない。もしそうなら、あなた方を人間のエージェントに結びつけるように頼んでください。「ああ、これなら送れるよ」と。

その一連のプロンプトで、メッセージが徐々にユーザーに役立つ詳細情報を表示する方法に注意してください。エンティティを使用してプロンプトを定義すると、このような会話を簡単に実装できます。プロンプトに連番を追加するだけです。

プロンプトのシーケンス番号は、いつ表示されるかを示します。前述の例には、1から3までのシーケンス番号のメッセージが含まれています。次に、エンティティの解決コンポーネントのmaxPromptsプロパティを3に構成すると、3番目の失敗したユーザー入力試行によって、ヘルプやヒューマン・エージェントの状態などのナビゲーションがトリガーされます。

同じシーケンス番号のプロンプトは、前の項で説明したように、交互動作を示します。この方法では、追加情報を徐々に公開し、代替プロンプトを表示することもできます。

多様なレスポンスおよび漸進的な開示

会話の様々なポイントに対して複数のレスポンスを用意します。多様なレスポンスにより、スキルに対するユーザーの信頼が向上します(堂々巡りしているように感じなくなります)。また、これらを使用して、ユーザーが立ち往生しないように情報を徐々に開示することもできます。

たとえば、「どのサイズにしますか」という質問に対してユーザーが無効な入力を行った場合は、そのプロンプトの後に次のように続けることができます。「では、もう一度、サイズを確認いたします。」大、中、小から選択してください。」

確認および反映的傾聴

スキルのレスポンスでは、反映的傾聴(ユーザーの入力を違う表現で言い直す方法)を使用して、スキルがユーザーのリクエストを理解していることを示してから、次のステップに進む必要があります。たとえば、ユーザーが「ピザをオーダーしたい」と伝えた場合に、スキルが「了解しました。ピザのオーダーを始めましょう」と応答してから、次の質問に進むことができます(「どのサイズにしますか」など)。また、この確認は、逐語的で不自然な音声(「ピザ・オーダーのリクエストが確認されました」など)ではなく、それとなく人間らしい自然な口調(「ピザのオーダーを始めましょう」)で表すことをお薦めします。

また、ユーザーが情報を入力したが、スキルがバックエンドで処理を実行するために多少の時間が必要な状況についても考えてください。応答できるまでプロセスの完了を待機するのではなく、リクエストが処理中であることを確認できるようにすることをお薦めします。たとえば、決済詳細が送信されたが、まだ処理されていない時点で、スキルは次のように応答できます:「了解です。すべての決済情報を受け取りました。銀行でそれらの詳細情報を確認いたします。」

同様に、入力インジケータを使用して、デジタル・アシスタントがレスポンスを準備していることを示します。

AIと人間の理解の間に存在するギャップを埋める

人間の脳は世界でもっとも遅いが最高のコンピューターだ。これは、コンテキストを検出および維持する能力によるものです。会話型AIのすべての改善にもかかわらず、チャットボットがユーザーの希望やユーザーが提供した情報の目的を判断できない状況が発生します。ここでは、チャットボットとユーザーを助けるために会話の設計をステップアップする必要があります。

たとえば、次の3つのメッセージについて考えてみます:

「明日の午前10時から午後12時までの日記をブロックする」
「明日の午前10時に2時間、カレンダーにマーカーを設定する」
「明日の2時間、午前10時にスケジュールにエントリを作成します。」

3つのメッセージはすべて同じことを言っており、人間の脳はユーザーが望むもの、イベントの日付、および開始時間と終了時間がすぐに取得します。

会話型AIは、適切にトレーニングされると、「自分の日記をブロックする」、「自分のカレンダにマーカーを設定する」および「自分のスケジュールにエントリを作成する」が同じ意味を持つことを理解し、ユーザー・カレンダにイベントを作成します。

しかし、情報に関しては、会話型AIは「明日」をイベント日として、午前10時と午後12時を時間として、期間として2時間を抽出します。ミーティングの開始時刻と終了時刻、特に終了時刻をデュレーションから計算する必要がある場合について理解しにくい場合があります。「明日」とは、(例えば)ヨルダンとは対照的にオーストラリアに住んでいる場合、ボットの観点からどういう意味ですか?

実装で処理できないものは何であれ、ボットが理解していないことを認めることを意味し、情報を要求し直しても、設計はそれを処理する必要があります。

良いマナー

デジタル・アシスタントは、ユーザーの時間と懸念を考慮する必要があります。ここでは、デジタル・アシスタントに組み込むための優れたマナーのいくつかの側面を示します。

世間話

世間話は人間の会話に当然含まれるというだけではなく、人はデジタル・アシスタントに対しても世間話から始めます。デジタル・アシスタントの場合、実際に次のような実用的な用途があります:

チャット・インタフェースの背後にいるのがボットであり人間ではないことを確認します。
デジタル・アシスタントに何ができるかを発見します。
フラストレーションを表明します。

たとえば、ユーザーが罵り言葉を入力した場合、デジタル・アシスタントはこれをきっかけとして、謝罪したり、ユーザーを人間のエージェントにつないだり、問題を修正したりすることができます。

少なくとも、基本レベルの世間話を処理できる必要があります。適切に処理すれば、デジタル・アシスタントが賢く見えるようになり、ユーザーがデジタル・アシスタントを信頼できるようになります。

責任を転嫁しない

ユーザーが間違った内容を入力したり、会話の進行を中断することを行ったりしても、ユーザーに責任を転嫁しないように注意します(明示的にも暗黙的にも)。そのようなケースでは、ユーザーが間違って行ったことではなく、デジタル・アシスタントで問題が発生した部分に焦点を当てる表現にする必要があります。

たとえば、「それは違うオーダーIDです」というレスポンスは、問題がユーザーの誤りであることを暗に意味するため、イライラさせたり気を悪くさせたりする可能性があります(また正しくない可能性もあります)。「その番号のオーダーを見つけることができませんでした」とすれば、よいレスポンスになります。

共感の使用

共感とユーモアを使用してデジタル・アシスタントをより人間的なものにすることができますが、やりすぎないように慎重にしてください。誤解によるコストは、どのようなメリットもはるかに上回ります。

たとえば、会議登録デジタル・アシスタントのユーザーが「会議に参加できなくなります」と入力したとき、「それは残念です」とレスポンスを開始するのは適切です。ただし、ユーザーが「娘が出産するので会議に参加できなくなります」と伝えた場合であれば、このレスポンスはまったく共感しているように感じられません。

簡潔さ

メッセージは手短で要領を得たものにします。(ユーザーの時間や画面のスペースを考慮してください。)

チャネルでリンクがサポートされている場合は、外部コンテンツへのリンクを提供することをお薦めします。

顧客対応を短く保持

物事を成し遂げるには、会話の始まりから終わりまでの最短の道を考えてください。会話の停止をスキップする必要があるオプションをすべて使用します。次に、考慮する2つのオプションを示します。

エンティティ・スロッティングを使用し、最初のメッセージにタスクに必要な情報の一部(すべてではない場合)を含める方法をユーザーにガイドします。

ビジュアル・モードで設計されたダイアログ・フローでは、「Common Response」および「Resolve Entity」コンポーネントによって、ユーザーが初期メッセージで提供したエンティティ値が自動的に抽出され、指定された値の入力は求められません。

YAMLモードで設計されたダイアログ・フローでは、入力コンポーネントのnlpResultVariableプロパティを使用して、この自動スロッティングを有効にできます。
プロンプトが表示されたら、ユーザーが追加情報を入力できるようにします。たとえば、ピザ・オーダー・ボットで、ユーザーがピザ・サイズを求められたときに、ピザ・タイプとトッピングも受け入れないのはなぜですか。順不同の情報抽出は、コンポジット・バッグ・エンティティを使用して簡単に実装できます。

Webアプリケーションのように設計しない

チームにはWebアプリケーションの開発経験がある可能性が高く、意識的あるいは無意識のうちに、Webアプリケーションのパラダイムをデジタル・アシスタントに適用する可能性も高くなります。それは避けてください。デジタル・アシスタントの要点は、ユーザーが自然言語でタスクを完了することです。Webアプリケーションを小さいウィンドウに配置することではありません。

考慮事項を次に示します:

データベース・フィールド名のように聞こえる言葉をレスポンスで使用しないでください。
たとえば、「無効なオーダーID」と応答するかわりに、「オーダー番号が見つかりません」などと応答します。
ユーザーがリクエストを行ったときに、何百もの解決策がある場合、スクロール表示しなければならない数百行ものデータで応答しないでください。もっと簡潔なリストを示すことができるように、ユーザーがリクエストを絞り込むために役立つ方法を考えてください。
たとえば、ワイン・ショップに入ってワインを1本買おうとする場合、商店主は売り場のすべてのボトルについて説明するわけにはいきません。好み(赤か白か、産地、品質など)を尋ねた後で、具体的な選択肢を示します。スキルも同じ方法で処理できます。
すべての詳細情報についてユーザーに問い合せずに、会話のための情報を収集する方法を見つけます。たとえば、質問せずにユーザーの居場所を判別する方法があります。もう1つの例は、必要な情報が提供される画像(領収書など)を送信するようにユーザーに依頼することです。

複数言語サポートの検討

海外から輸入される製品のインストール手順が、時々あまり翻訳されない理由を考えたことがありますか?翻訳サービスが使用され、翻訳者が件名や製品に精通していなかったことが考えられます。もう一つの理由は、特定の偶像が存在しないか、翻訳する言語で異なる表現になっているからです。ただ、米国で何が機能するかについて、いくつかの例をあげてみましょうが、おそらく他の場所ではそうではありません。

『UNDER THE WEATHER』
『HANG IN THERE』
「We'll cross that bridge when we get to it」です。
"オランダへ"
『CALL IT A DAY』

翻訳時にデジタル・アシスタントに定義された会話も機能するようにするには、いくつかのオプションがあります。翻訳者がメッセージの意味を把握できるようにリソース・バンドル内のアイドルに注釈を付けるか、アイドルをまったく使用しないかです。当然のことながら、ボット応答を外国語に翻訳するとき、機械翻訳サービスはうまく機能しません。