会話フローの設計と制御

従来のアプリケーションでは、ユーザーインターフェイス（UI）は一連の画面です。
単一のアプリまたはウェブサイトで、必要に応じて1つまたは複数の画面を使用して、ユーザーと情報を交換できます。
ほとんどのアプリケーションは、ユーザーが最初に訪れるメイン画面から始まり、新しい注文の開始、商品の閲覧、ヘルプの検索など、さまざまな機能のための他の画面に繋がるナビゲーションを提供します。

アプリやウェブサイトと同様に、ボットにもUIがありますが、画面ではなくダイアログ（対話）で構成されています。
開発者はダイアログを使用して、ボットの機能のさまざまな領域を論理的に分離し、会話の流れを導くことができます。
例えば、「ユーザーが製品をブラウズするのに役立つロジックを含むダイアログ」と、「ユーザーが新しい注文をするのに役立つロジックを含む別のダイアログ」を設計することができます。

ダイアログには、グラフィカルインターフェイス（GUI）がある場合と無い場合があります。
それらは、ボタンやテキストなどの他の要素を含めることもできれば、完全に音声に基づくこともできます。
ダイアログには、他のダイアログを呼び出す、ユーザー入力を処理するなどのタスクを実行するアクションも含まれています。

ダイアログを使用した会話フローの管理

以下の図は、従来のアプリケーションの画面フロー（左）を、ボットのダイアログフロー（右）と比較しています。

従来のアプリケーションでは、すべてメイン画面から始まります。
メイン画面で新しい注文画面が表示されます。新しい注文画面は、他の画面を閉じるか呼び出すまで制御されます。
新しい注文画面を閉じると、ユーザーはメイン画面に戻ります。

ボットでは、すべてがルートダイアログから始まります。
ルートダイアログが新しい注文ダイアログを呼び出します。その時点で、新しい注文ダイアログは会話を制御し、他のダイアログを閉じるか、呼び出すまで制御状態を維持します。
新しい注文ダイアログが閉じると、会話の制御がルートダイアログに戻ります。

ダイアログのスタック

1つのダイアログが別のダイアログを呼び出すと、ボットビルダーは新しいダイアログをダイアログスタックの最上部に追加します。
スタックの上にあるダイアログは、会話を制御します。
ユーザーがボットに送信したすべての新しいメッセージは、そのダイアログを閉じるか、別のダイアログにリダイレクトされるまで、そのダイアログによる処理の対象となります。
ダイアログが閉じられるとスタックから削除され、前のダイアログは会話の制御を引き継ぎます。

ダイアログ、スタックと人間

ユーザーがダイアログを横断的にナビゲートしてダイアログスタックを作成し、ある時点で元の方向に戻り、ダイアログを1つずつきちんと整然とした方法でアンスタッキングすることを推測することが魅力的かもしれません。

例えば、ユーザーはルートダイアログから開始し、そこから新しい注文ダイアログを呼び出してから、商品検索ダイアログを呼び出します。次に、ユーザーは商品を選択して確認し、商品検索ダイアログを終了し、注文を完了し、新しい注文ダイアログを終了してルートダイアログに戻ります。

ユーザーがいつもそのような線形で論理的なパスを行き来するのは素晴らしいことですが、それはほとんど起こりません。
**人間は「スタック」で通信しません。**頻繁に心を変えがちです。
次の例を考えてみましょう。

あなたのボットは論理的にダイアログのスタックを構築しているかもしれないが、ユーザーは全く別のことをするか、現在のトピックと無関係かもしれない質問をすることもできます。

この例では、ユーザは、ダイアログが期待する「はい」または、「いいえ」で答えるのではなく、質問をしています。
あなたのダイアログはどのように応答する必要がありますか？

まずユーザーに、質問に答えてもらうように主張します。
ユーザーが以前に行ったことのすべてを無視し、ダイアログスタック全体をリセットし、ユーザーからの質問に答えることによって最初から開始します。
ユーザーの質問に回答し、その後、上記の質問に戻り、そこから再開しようとします。

最良の解決策は、シナリオの詳細と、ユーザーがボットの応答を合理的に期待する方法に依存するため、この質問に対する正解はありません。

ユーザが（たとえ非線形であっても）目標を達成できるように会話フローを設計することは、ボット設計の基本的な課題です。

まとめ

「MicrosoftBotFramework」では、ダイアログと呼ばれる、主にユーザからの応答に対する処理のかたまりを適切に管理することでボットを構築していきます。少し触ってみると分かりますが、ロジック内の各々のトピックを関数化していくようなイメージですね。

私は他のボット系フレームワークをあまり触ったことはないですが、「MicrosoftBotFramework」のこの方法は、結構気に入ってます。
会話の流れをスタックで管理するというのは、あるトピックに限った会話の流れって意味では理にかなってると思っていて、横槍的なものを入れなければ、論理的に単一方向に流れる処理で事足りる、と。

ただ、「そういえば、〜」とか「話変わるけど、〜」みたいなことは、人間の会話としては当然あり得るので、それに対応するための方法は用意しておく必要があるってことですね。

次回は、
いくつかの、設計が不十分なナビゲーションの一般的な落とし穴を検討し、これらのトラップを回避するための戦略について！（らしいです）です。