会話フローの設計と制御
この記事の対象: SDK v4
従来のアプリケーションでは、ユーザー インターフェイス (UI) は一連の画面で構成されます。つまり、1 つのアプリや Web サイト上で、必要に応じて 1 つ以上の画面を使用し、ユーザーと情報を交換できます。 多くのアプリケーションでは、起動するとまずメイン画面が表示され、ユーザーはそこに表示されたナビゲーションから別の画面に移動して、新しい注文を開始したり、製品を参照したり、ヘルプを検索したりします。
アプリや Web サイトと同様、ボットにも UI がありますが、ボットの UI は画面ではなくメッセージで構成されます。 メッセージでは、ボタン、テキスト、およびその他の要素を使用することもできますし、完全に音声ベースのメッセージにすることもできます。
従来のアプリケーションや Web サイトでは、複数の情報を 1 つの画面でまとめて要求することができますが、ボットでは、同じ量の情報を複数のメッセージによって収集します。 これにより、ユーザーからの情報収集プロセスをアクティブなエクスペリエンスにし、ユーザーがボットとアクティブに会話する流れを構築します。
適切に設計されたボットならば、自然な会話フローを提供することができます。 ボットでは、中心となる会話をシームレスに処理しながらも、会話の中断やトピックの切り替わりにも柔軟に対応できるようにする必要があります。
手続き型の会話フロー
ボットによる会話は、そのボットが達成しようとしているタスクに焦点が置いて設計されます。これを手続き型フローと呼びます。 ボットがユーザーに一連の質問をして、タスクを処理する前に必要なすべての情報を収集します。
手続き型の会話フローでは、質問の順序を定義することにより、ボットがそのとおりの順序で質問を発するようにします。 開発者は、質問を複数の論理群にまとめてコード cMicrosoft Entralized を一元化しながら、会話の流れを制御できるようにします。 たとえば、あるモジュールには、ユーザーが製品を参照できるようにするためのロジックを実装し、別のモジュールには、ユーザーが新しい注文を作成できるようにするためのロジックを実装するといったことが可能です。
これらのモジュールは、自由形式のフローからシーケンシャルなフローに至るまで、任意の方法で構築できます。 Bot Framework SDK では、ボットに必要な会話フローを自由に構築するできるよう、ダイアログ ライブラリが提供されています。 ライブラリには、一連のステップを作成するためのウォーターフォール ダイアログと、ユーザーに質問するためのプロンプトが含まれています。 詳細については、「ダイアログ ライブラリ」を参照してください。
従来のアプリケーションでは、すべての操作がメイン画面から開始されます。 メイン画面が新規注文画面を呼び出します。 新規注文画面は、画面が閉じられるか、製品検索画面などの他の画面が呼び出されるまで、制御権を保持します。 新規注文画面が閉じられると、ユーザーはメイン画面に戻されます。
ダイアログを使用するボットでは、すべての操作がルート ダイアログから開始されます。 ルート ダイアログが [新規注文ダイアログ] を呼び出します。 この時点で、新規注文ダイアログに会話の制御権が渡され、ダイアログが閉じられるか、別のダイアログ (製品検索ダイアログなど) が呼び出されるまで、制御権を保持します。 新規注文ダイアログが閉じられると、会話の制御権がルート ダイアログに戻ります。
ダイアログ ライブラリを使用して会話フローを実装する方法の例については、「順次会話フローを実装する」を参照してください。
割り込みの処理
ダイアログを開発する際には、ユーザーが手続き型タスクを 1 つずつ順序よく実行していくことを想定しがちです。 たとえば、ダイアログを使った手続き型会話フローでは、ユーザーがルート ダイアログから操作を開始し、新規注文ダイアログを呼び出します。 ユーザーは、新規注文ダイアログから製品検索ダイアログを呼び出します。 次に、製品検索ダイアログに一覧表示されている結果のいずれかを選択すると、新しい注文ダイアログが呼び出されます。 注文が完了すると、ルート ダイアログに戻ります。
ユーザーが常にこのようなストレートな論理パスをたどってくれれば、それに越したことはないのですが、実際にはこのようなことはあまりありません。 ユーザーが常に順番に通信するとは限りません。 ユーザーが心変わりすることは頻繁に起こりえます。 次の例を考えてみましょう。
ボットが手続き型で設計されていても、ユーザーは現在の操作とまったく違うことをしようとしたり、現在のトピックとは関係のない質問をしてくる場合があります。 上記の例で言うと、はい/いいえの応答を返すはずの流れにおいて、ユーザーが逆に質問をしてきています。 このような場合、ボットはどのように応答すべきでしょうか?
- まず質問に答えるよう、ユーザーに求める。
- ユーザーがこれまでに行ったことをすべて無視し、ダイアログ スタック全体をリセットした後、ユーザーの質問に答えることで最初からやり直す。
- ユーザーの質問に答えた後、はい/いいえの質問に戻り、そこから再開する。
この質問に対する正解はありません。なぜなら、どのようなシナリオが想定されるかや、ユーザーがボットにどのような応答を期待するかによって、最良の対応方法は変わってくるからです。 一部の種類の中断を処理するように設計されたボットの「ユーザー割り込みを処理する」方法について説明します。
会話を期限切れにする
会話を最初から始め直すと便利な場合があります。 たとえば、ユーザーが一定期間置いて応答しない場合などです。 会話を終了するためのさまざまな方法を次に示します。
- ユーザーからメッセージが最後に受信された時刻を追跡し、ユーザーから次のメッセージを受信したときに、時刻が構成済みの長さを超える場合は状態をクリアします。
- Cosmos DB の Time to Live 機能などのストレージ レイヤー機能を使用して、構成済みの時間の長さ後の状態をクリアします。
詳細については、「会話を終了する」の方法をご覧ください
次のステップ
ダイアログ間でのユーザーの移動を管理し、ユーザーが (シナリオとは違った方法であっても) 目標を達成できるように会話フローを設計することは、ボット設計の基本的な課題です。 「ボット ナビゲーションを設計する」記事では、ナビゲーション設計に関する一般的な落とし穴と、そのような失敗を回避するための戦略についておさらいします。