明確化の例

例えば、ダイアログの 2 つのノードに、取り消し要求に対応するインテント条件が含まれているとします。 条件は以下のとおりです。

• eCommerce_Cancel_Product_Order
• Customer_Care_Cancel_Account

もしユーザーが i must cancel it today と言った場合、入力から以下のインテントが検出されるかもしれない：

[
  {"intent":"Customer_Care_Cancel_Account","confidence":0.5602024316787719},
  {"intent":"eCommerce_Cancel_Product_Order","confidence":0.46903514862060547},
  {"intent":"Customer_Care_Appointments","confidence":0.29033891558647157},
  {"intent":"General_Greetings","confidence":0.2894785046577454},

試してみる」ペインからテストすると、目のアイコンにカーソルを合わせて、テスト入力で認識された上位3つのインテントを見ることができる。

![試してみる] ペインからのユーザー入力で認識された上位 3 つのインテントを表示します。](images/tryit-disambig-intent-details.png)

アシスタントは、0.5618281841278076 (56%) の信頼度で、ユーザーの目的が #Customer_Care_Cancel_Account インテントに一致すると予想しています。 この最上位のインテントの信頼度スコアに近いスコアのインテントが他にもある場合に、明確化がトリガーされます。 この例では、#eCommerce_Cancel_Product_Order インテントの信頼性スコアは 46% 近くです。

その結果、ユーザーが i must cancel it today と言った場合、両方のダイアログノードが応答候補となる可能性が高い。 処理するダイアログ・ノードを決定するために、ユーザーはアシスタントによって選択を求められます。 また、ユーザーの選択に役立つように、アシスタントによって、各ノードの実行内容についての簡単なサマリーが示されます。 サマリーのテキストは、ノードの*「名前 (name)」* フィールドから直接抽出されます。 「外部ノード名 (external node name)」 フィールドが存在し、そのフィールドに説明が追加されている場合は、代わりにそのフィールドからテキストが取得されます。

明確化リストに表示される説明は、インテントの一致が発生するブランチ内で処理される最後のノードの名前 (または外部ノード名) から取得されます。 詳しくは、ジャンプ先ユーティリティー・ノードの無効化を参照してください。

アシスタントが、ユーザー入力に含まれていた用語 today を、@sys-date エンティティーの言及である日付として認識していることに注意してください。 @sys-date エンティティーを条件とするノードがダイアログ・ツリーに含まれていれば、そのノードも明確化の選択肢のリストに含まれる可能性があります。 次の画像では、そのノードが*「日付情報のキャプチャー (Capture date information)」* オプションとしてリストに含まれています。

明確化の構成の編集

すべての新しいダイアログ・スキルでは、明確化が自動的に有効になります。 明確化に自動的に適用された設定は、「オプション (Options)」 ページで変更できます。

明確化の設定を編集するには、以下の手順を実行します。

1. 「オプション」 で、 「明確化」 をクリックします。

2. 「明確化メッセージ (Disambiguation message)」 フィールドで、ダイアログ・ノード・オプションのリストの前に表示されるテキストを追加します。 例えば、What do you want to do? などとします。

3. Anything else フィールドに、他のダイアログ・ノードのオプションの中にユーザーの希望が反映されていない場合に、ユーザーが選択できる追加オプションとして表示するテキストを追加します。 例えば、「上記のどれでもない (none of the above)」などにします。

   他のオプションと揃って表示されるように、メッセージは短くします。 メッセージは512文字以下でなければならない。 ユーザーがこのオプションを選択した場合にアシスタントが何を実行するかについては、「上記のどれでもない (none of the above)」の処理を参照してください。

4. ユーザーに表示できる明確化オプションの数を制限する場合は、**「提案の最大数 (Maximum number of suggestions)」**フィールドに 2 から 5 までの数値を指定します。

変更内容は自動的に保存されます。

APIを使用して、さらに曖昧さ除去の設定を変更することができます。 これらの設定には、明確化の感度が含まれます。これは、明確化がトリガーされる頻度と、含まれる選択項目の数に影響します。 詳しくは、 API リファレンスを参照してください。

明確化のオプションとして表示しないノードを選択する

すべてのノードが、明確化リストに含められる対象になります。

• ツリー階層の任意のレベルのノードが含められます。
• インテント、エンティティー、特殊条件、コンテキスト変数、またはこれらの値の組み合わせを条件とするノードが含められます。

一部のノードについては、明確化リストに表示しないようにすることを検討してください。

• welcome 条件および anything_else 条件を持つルート・ノードを非表示にする

  これらのノードに余分な機能を追加しない限り、曖昧性解消リストに含めるには通常有用なオプションではない。

• ジャンプ先ユーティリティー・ノードを非表示にする

  曖昧性解消リストのテキストは、ノード条件がマッチしたブランチで最後に処理されたノードのノード名（または外部ノード名）から入力されます。

  一致したルート・ノードの目的を説明する句の代わりに、ユーザーに感謝したり、別れを言ったり、回答の品質フィードバックを求めたりするなどのユーティリティー・ノードを明確化リストに含めないでください。

  例えば、一致したインテント条件 #store-location を持つルート・ノードが、応答に満足しているかどうかをユーザーに尋ねるノードにジャンプするようになっているとします。 #check_satisfaction ノードにノード名と曖昧性解消がある場合、ジャンプ先のノードの名前が曖昧性解消リストに表示される。 その結果、明確化リストには、Check satisfaction ブランチを表すものとして、ルート・ノードの名前 #store-location ではなく、Get store location が表示されます。

• エンティティーまたはコンテキスト変数のみを条件とするルート・ノードを非表示にする

  明確化をトリガーできるのは一致したインテントを持つノードのみです。 しかし、トリガーされると、条件にマッチするノードはすべて曖昧性解消リストに含まれる。 エンティティーを条件とするノードがダイアログに含まれていると、例えば、ツリー階層内のノードの順序などが、予期しない形で意味を持つことがあります。

  • ノードの順序は、曖昧性解消がまったくトリガーされないかどうかに影響する。 例として、前に明確化について紹介するために使用したシナリオを参照してください。 @sys-date を条件とするノードが、 #Customer_Care_Cancel_Account および #eCommerce_Cancel_Product_Order の意図を条件とするノードよりもダイアログツリーの上位に配置されていれば、ユーザーが i must cancel it today を入力したときに曖昧性解消がトリガーされることはない。 あなたのアシスタントは、ツリー内の対応するノードの配置により、言及された日付（ today ）は、意図の参照よりも重要であると考えるでしょう。

  • ノードの順序は、曖昧性解消オプションリストにどのノードを含めるかに影響する。 ノードが期待どおりに明確化のオプションとしてリストされない場合があります。 これは、条件値が、明確化リストに含めることができない ノードでも何らかの理由で参照されている場合に発生します。 たとえば、あるエンティティが、ダイアログツリーの前のほうに位置するが、曖昧性解消が有効になっていないノードをトリガーすることがある。 同じエンティティが、曖昧性解消が有効なノードに対する唯一の条件であるにもかかわらず、ツリーの下位にある場合、アシスタントがそのノードに到達することがないため、曖昧性解消の選択肢にならない可能性があります。 前のノードと一致して省略された場合、アシスタントは後のノードを処理しない可能性があります。

すべてのノードを明確化に表示しないようにする

ダイアログまたは個々のダイアログ・ノードに含まれているすべてのノードを、明確化リストに含めないようにすることができます。

全体で明確化を無効にするには、次のようにします。

1. 「オプション」 で、 「明確化」 をクリックします。

2. スイッチをオフにする。

1 つのダイアログ・ノードを明確化リストに含めないようにするには、次のようにします。

1. ダイアログノードをクリックして編集ビューで開く。

2. 「設定」 をクリックします。

3. **「ノード名の表示 (Show node name)」スイッチを「オフ (Off)」**に設定します。

   プラス 名前フィールドの代わりに外部ノード名フィールドにノード概要説明を追加した場合は、それを削除する。

   「外部ノード名 (external node name)」 フィールドには、2 つの目的があります。 ノードが明確化リストに含められた場合に、ノードに関する情報を顧客に提供します。 また、会話が人に転送された場合にサービス・デスクの担当者と共有されるチャット要約の中でもノードの説明を提供します。 外部ノード名 フィールドは、有料プラン・インスタンスの一部であるスキルでのみ表示されます。 「名前 (name)」 フィールドにテキストがあるかどうかにかかわらず、「外部ノード名 (external node name)」 フィールドにテキストが含まれていれば、そのテキストが使用されます。

ノードごとに、ノードを明確化のオプションのリストに含める必要があるシナリオをテストします。 テストは、実行時に曖昧性解消がうまく機能するかどうかに影響する可能性のあるノード順序やその他の要因を調整する機会を与える。 明確化のテストを参照してください。

「上記のどれでもない (none of the above)」の処理

ユーザーが*「上記のどれでもない (None of the above)」* オプションをクリックすると、アシスタントは、ユーザー入力で認識されたインテントをメッセージから除去し、メッセージを再送信します。 通常、このアクションでは、ダイアログ・ツリーのその他のノードがトリガーされます。

この状況で返される応答をカスタマイズするために、認識されたインテントが含まれておらず、かつ suggestion_id プロパティーが含まれているユーザー入力 (インテントは除去されることを思い出してください) がないか検査する条件を持つルート・ノードを追加できます。 suggestion_id プロパティーは、明確化がトリガーされたときにアシスタントによって追加されます。

次の条件を持つルート・ノードを追加します。

intents.size()==0 && input.suggestion_id

この条件は、曖昧性解消の選択肢のうち、ユーザーが「どれもゴールに一致しない」と答えた選択肢をトリガーする入力によってのみ満たされる。

提案された選択肢のどれもが彼らのニーズを満たしていないことを理解し、適切な措置を講じることを、そのことを知っているユーザーに伝える応答を追加します。

ツリーでのノードの配置が再度重要になります。 ユーザー入力で言及されたエンティティー・タイプを条件とするノードが、ツリーでこのノードよりも上位にある場合、代わりにその応答が表示されます。

明確化のテスト

テスト時には、オプションがリストされる順序が変更される可能性があります。 実際、曖昧性解消リストに含まれるオプションそのものは、テストごとに変わるかもしれない。

この動作は意図的なものです。 アシスタントがユーザーの選択肢から自動的に学習するのを助けるために進行中の開発の一環として、曖昧性解消リスト内の選択肢とその順序は意図的にランダム化されている。 順番を変えることで、事前にすべての選択肢を注意深く検討することなく、常に最初の選択肢を選ぶ人が何割かいることによってもたらされるバイアスを避けることができる。

明確化をテストするには、以下の手順に従ってください。

1. 試してみる」ペインから、曖昧性解消の良い候補となるテスト発話を入力します。つまり、2つ以上のダイアログノードが、そのような発話を扱うように設定されていることを意味します。

2. 応答に、選択できるダイアログ・ノード・オプションのリストが含まれていない場合は、要約情報がノード名 (または外部ノード名) フィールドに追加されていることを確認してください。

3. 明確化がまだトリガーされない場合は、ノードの信頼度スコアが、思っているほど近い値ではない可能性があります。

   • 入力で検出された上位 3 つのインテントの信頼度スコアを確認するには、「試行する (Try it out)」ペインの目のアイコンにカーソルを合わせます。

   • ユーザー入力で検出されたすべてのインテントの信頼度スコアを表示するには、トリガーされることが分かっているノードのノード応答の末尾に <? intents ?> を一時的に追加します。

     この SpEL 式は、ユーザー入力で配列として検出されたインテントを示しています。 配列には、インテントの名前と、アシスタントにおける、ユーザーの想定される目的をインテントが反映していることについての信頼度のレベルが含まれます。

   • ユーザー入力から検出されたエンティティがある場合、それを確認するには、現在の応答を、 SpEL 表現 <? entities ?> を含む単一のテキスト応答に一時的に置き換えることができます。

     この SpEL 式は、ユーザー入力で配列として検出されたエンティティーを示しています。 配列には、エンティティ名、エンティティの言及の場所、エンティティの言及文字列、およびその用語が指 定されたエンティティ・タイプの言及であることの信頼度が含まれる。

   • すべての成果物の詳細 (呼び出し時のコンテキスト変数値などの他のプロパティーを含む) を表示するには、API 応答全体を検査します。 API 呼び出しの詳細の表示を参照してください。

4. 曖昧さ回避のオプションとして予想されるノードの少なくとも1つについて、 名前フィールド（または外部ノード名フィールド）の説明を一時的に削除する。

5. 再度「試行する (Try it out)」ペインにテスト発話を入力します。

   応答に <? intents ?> 式を追加した場合、テキストには、アシスタントがテスト発話で認識したインテントのリストが含まれ、各インテントの信頼スコアが含まれます。

   

テストが完了したら、ノード応答に追加した SpEL 式を削除するか、または式に置き換えた元の応答を再度追加して、テキストを削除した*「名前 (name)」* フィールドまたは*「外部ノード名 (external node name)」* フィールドを再度設定します。

開始前に

ダイアログ全体をテストすると、脱線して戻ることを、いつどこで許可するのが自然かがわかります。 ノードには以下の脱線制御が自動的に適用されます。

• ダイアログのすべてのルート・ノードは、デフォルトで脱線のターゲットにできるように構成されています。 子ノードは、脱線のターゲットにできません。

• スロット付きのノードは、脱線できないように構成されています。 他のすべてのノードは、脱線できるように構成されています。 ただし、以下の状況では、会話をノードから脱線させることはできません。

  • 現在のノードの子ノードのいずれかが、 anything_else または true の条件を含む場合。 これらの条件は、常に真であると評価されるという点で特殊である。 動作が既知であるため、これらの条件は、続けて特定の子ノードを評価することを親ノードに強制するためにダイアログでよく使用されます。 既存のダイアログフローのロジックを壊さないようにするため、この場合、脱線は許されない。 このようなノードからの脱線を有効にするには、子ノードの条件を別のものに変更する必要があります。

  • ノードが処理された後、他のノードにジャンプするか、ユーザー入力をスキップするように設定されている場合。 ノードの最終ステップ・セクションは、ノードが処理された後の処理を指定する。 ダイアログが他のノードに直接ジャンプするように設定されている場合、特定のシーケンスに従うようにすることが多い。 また、ノードがユーザー入力をスキップするように構成されている場合は、現行ノードの後に続けて最初の子ノードを処理するようにダイアログに強制することと同じです。 どちらの場合も、既存のダイアログ・フロー・ロジックの中断を防ぐために、脱線は許可されません。 このようなノードからの脱線を有効にするには、最終ステップのセクションに指定した内容を変更する必要があります。

脱線のカスタマイズ

脱線の開始と終了は定義しません。 実行時には、ユーザーが脱線フローを完全に制御します。 各ノードをユーザー主導の脱線に含める方法を指定できます。 各ノードについて、脱線するかどうかを構成できます。

• ノードから開始して、ノードを終了します。
• 他の場所で開始された場合、そのノードをターゲットにして進入することができる
• 他の場所で開始し、ノードに入ったものは、現在のダイアログフローが完了した後、中断されたダイアログフローに戻らなければならない

個々のノードの脱線動作を変更するには、次の手順を実行します。

1. ノードをクリックして、その編集ビューを開きます。

2. **「カスタマイズ (Customize)」をクリックし、「脱線 (Digressions)」**タブをクリックします。

   構成オプションは、編集するノードがルート・ノード、子ノード、子を持つノード、またはスロット付きノードのいずれであるかによって異なります。

   このノードからの脱線

   前述の状況が当てはまらない場合は、以下の選択を行えます。

   • すべてのノード・タイプ: 現在のダイアログ・ブランチの最後に到達する前に、現在のノードから脱線することをユーザーに許可するかどうかを選択できます。

   • 子ノードを持つすべてのノード ：ノードの応答が表示され、その子ノードがゴールに付随している場合、会話を現在のノードに戻すかどうかを選択します。 **「このノードの応答の後にトリガーされた脱線からの戻りを許可 (Allow return from digressions triggered after this node's response)」スイッチを「いいえ (No)」**に設定すると、ダイアログが現在のノードに戻ってブランチの処理を再開することを防止できます。

     例えば、ユーザーが「 Do you sell cupcakes? 」と質問し、ユーザーが話題を変える前に「 We offer cupcakes in a variety of flavors and sizes 」という応答が表示された場合、ダイアログを中断した場所に戻したくないかもしれません。 特に、子ノードがユーザーからのフォローアップの可能性のある質問に対応していて、安全に無視できる場合はなおさらです。

     ただし、質問に対処するために子ノードに依存するノードの場合には、強制的に会話を戻して、現行ブランチ内のノードの処理を再開させる必要があるでしょう。 例えば、最初の反応は、 We offer cupcakes in all shapes and sizes. Which menu do you want to see: gluten-free, dairy-free, or regular?。 ユーザーが主題を変更した場合、ダイアログを戻してユーザーがメニューの種類を選び、望んだ情報を得られるようにしたいかもしれない。

   • スロット付きのノード: すべてのスロットに情報が取り込まれる前に、ノードから脱線することをユーザーに許可するかどうかを選択します。 脱線を可能にするには、「スロットに情報を取り込み中に脱線を許可する (Allow digressions away while slot filling)」 スイッチを**「はい (Yes)」**に設定します。

     可能にした場合は、会話が脱線から戻ったときに、情報が取り込まれていない次のスロットを求めるプロンプトを表示して、ユーザーに情報提供を再開するように促します。 不可にした場合、スロットに情報を取り込める値が含まれていないユーザー入力はすべて無視されます。 ただし、スロット・ハンドラーを定義して、ノードとの対話中にユーザーが尋ねるかもしれない割り込みの質問に対処できます。 詳しくは、 スロットの追加 を参照してください。

   • スロットを持つノード: スロットから、リターンを許可するノードにのみディグレスする チェックボックスを選択することで、ユーザーが現在のノードに戻った場合、離脱を許可するかどうかを選択します。

     これを選択すると、ダイアログは、ユーザーの無関係な質問に回答するためのノードを探す際に、脱線の後に戻るように構成されていないルート・ノードを無視します。 ユーザーが必要なスロットを埋め終わる前にノードから永久に退出できないようにする場合は、このチェックボックスを選択します。

   このノードへの脱線

   ノードへの脱線の動作については、以下の選択を行えます。

   • 脱線してこのノードに入ることをユーザーに禁止します。 詳しくは、ルート・ノードへの脱線の無効化を参照してください。

   • このノードへの脱線を可能にした場合は、ダイアログがその脱線元のダイアログ・フローに戻る必要があるかどうかを選択します。 現在のノードのブランチの処理が終わると、ダイアログフローは中断されたノードに戻る。 その後にダイアログを戻すには、 Return after digression を選択する。

3. **「適用」**をクリックします。

4. 「Try it out」ペインを使用して、脱線の動作をテストします。

   ここでも、脱線の開始と終了は定義できません。 いつどこで脱線するかは、ユーザーが制御します。 1つのノードが1つのノードにどのように参加するかを決定する設定を適用することができます。 脱線は予測不可能であるため、コンフィギュレーションの決定が会話全体にどのような影響を与えるかを知るのは難しい。 判断した選択の影響を実際に確認するために、ダイアログをテストする必要があります。

#reservation ノードおよび #cuisine ノードは、ユーザー主導の単一の脱線に参加できる 2 つのダイアログ・ブランチを表しています。 個々のノードに対して構成する脱線設定は、実行時にこのタイプの脱線を可能にするものです。

脱線の使用上のヒント

カスタム戻りメッセージ ：脱線からの復帰を有効にするノードでは、前のダイアログフローで脱線したときにどこに戻るかをユーザーに伝える文言を追加することを検討してください。 テキスト回答では、特別な構文を使って2つのバージョンの回答を追加してください。

メッセージを追加しない場合、同じテキスト・レスポンスが2回目に表示され、脱線したノードに戻ったことをユーザーに伝える。 ユーザーが戻ったときに表示される固有のメッセージを指定することで、元の会話スレッドに戻ったことを明確にすることができます。

例えば、ノードの元のテキスト応答が What's the order number? の場合、ユーザーがノードに戻ったときに Now let's get back to where we left off. What is the order number? のようなメッセージを表示することができます。

これを行うには、次の構文を使用して、ノードのテキスト応答を指定します。

<? (returning_from_digression)? "post-digression message" : "first-time message" ?>

以下に例を示します。

<? (returning_from_digression)? "Now, let's get back to where we left off.
What is the order number?" : "What's the order number?" ?>

追加するテキスト応答には、SpEL 式や省略表現の構文を含めることはできません。 実際には、省略表現の構文は一切使用できません。 代わりに、テキスト・ストリングと完全な SpEL 式構文を組み合わせて完全な応答を形成することで、メッセージを作成する必要があります。

例えば、通常 What can I do for you, $username? として指定するコンテキスト変数をテキスト・レスポンスに含めるには、以下の構文を使用する：

<? (returning_from_digression)? "Where were we, " +
context["username"] + "? Oh right, I was asking what can I do
for you today." : "What can I do for you today, " +
context["username"] + "?" ?>

完全な SpEL 式構文の詳細については、オブジェクトにアクセスするための式を参照してください。

戻ることの防止: 場合によっては、現在のダイアログ・フローでのユーザーの選択に基づいて、中断された会話フローに戻らないようにすることができます。 特殊な構文を使用して、特定のノードから戻ることを防止できます。

例えば、#General_Connect_To_Agent のようなインテントを条件とするノードがあるとします。 トリガーがかかったとき、外部サービスに転送する前にユーザーの確認を取りたい場合は、 Do you want me to transfer you to an agent now? のようなレスポンスを追加することができる。 #yes と #no を条件とする2つの子ノードを追加することもできる。

このタイプのブランチの脱線を管理する最善の方法は、脱線して戻ることを許可するようにルート・ノードを設定することです。 ただし、#yes ノードでは、応答に SpEL 式 <? clearDialogStack() ?> を含めます。 以下に例を示します。

OK. I will transfer you now. <? clearDialogStack() ?>

この SpEL 式は、このノードからの脱線の戻りを防止します。 確認が要求されたときに、ユーザーが yes と回答すると、適切な応答が表示され、中断されたダイアログ・フローは再開されません。 ユーザーが no と回答すると、中断されたフローにユーザーが戻ります。

ルート・ノードへの脱線の無効化

ルート・ノードに脱線したフローは、そのノード用に構成されたダイアログのコースに従います。 フローは、ノード・ブランチの終了前に一連の子ノードを処理してから、中断されたダイアログ・フローに戻る場合があります。 テストにより、予期しないタイミングでルート・ノードが頻繁にトリガーされたり、ダイアログが複雑すぎてユーザーがコースから離れすぎて送信されたりすることに気付く場合があります。 ユーザーに脱線を許可しないほうがよいと判断した場合は、ルート・ノードへの脱線を許可しないように構成できます。

ルート・ノードへの脱線を完全に無効にするには、次の手順を実行します。

1. 編集するルート・ノードをクリックして開きます。
2. **「カスタマイズ (Customize)」をクリックし、「脱線 (Digressions)」**タブをクリックします。
3. Allow digressions into this node を Off に設定する。
4. **「適用」**をクリックします。

複数のルート・ノードへの脱線を禁止する場合に、ノードを 1 つずつ編集したくなければ、それらのノードを 1 つのフォルダーに追加します。 フォルダの Customize ページから、 Allow digressions into this node スイッチを Off に設定すると、すべてのノードに設定が適用されます。 詳しくは、 フォルダーを使用したダイアログの編成 を参照してください。

設計上の考慮事項

フォールバック・ノードの急増を避ける: 多くのダイアログ・デザイナーは、ユーザーがブランチ内にスタックすることを防止する手段として、各ダイアログ・ブランチの最後に true または anything_else 条件を指定したノードを含めます。 この設計では、処理するための特定のダイアログ・ノードを用意していた予期される入力にユーザー入力が一致しない場合は、汎用メッセージが返されます。 しかし、ユーザーは、この方法を使用するダイアログ・フローからは脱線できません。

この方法を使用するブランチを評価して、そのブランチからの脱線を許可したほうが良いかどうかを確認してください。 ユーザーの入力があなたの予想したものと一致しない場合、ツリー内のまったく別のダイアログフローと一致するものが見つかるかもしれません。 汎用メッセージで応答するのではなく、ダイアログの残りの部分を効果的に活用して、ユーザーの入力に対処することができます。 ルート・レベルの Anything else ノードは、他のルート・ノードが対処できない入力に常に応答できます。

クローズ・ノードへのジャンプの再検討: 多くのダイアログは、Did I answer your question today? ユーザーが別のノードにジャンプするように構成されているノードから脱線することはできないなど、標準的な終了の質問をするように設計されています。 そのため、すべての最終ブランチ・ノードを 1 つの共通のクローズ・ノードにジャンプするように構成した場合、脱線は実行できません。 メトリックなどの手段によって、ユーザーの満足度を追跡することを検討してください。

脱線チェーンの可能性をテストする ：ユーザーが現在のノードから脱線を許可している別のノードに脱線した場合、ユーザーはその別のノードから脱線し、このパターンを繰り返すかもしれない。 脱線チェーン内の開始ノードが脱線後に戻るように構成されている場合、ユーザーは最終的に現在のダイアログ・ノードに戻されます。 実際には、戻らないように構成されているチェーン内の後続のすべてのノードは、脱線ターゲットと見なす対象から除外されます。 何度も脱線するシナリオは、テストして、個々のノードが期待どおりに機能することを確認してください。

ステップ条件はディグレッションの復帰時に再評価されない: ステップ条件はディグレッションの前にすでに評価されているため、ディグレッションの復帰時に再度評価されることはない。 会話の流れで、ステップの条件をもう一度評価する必要がある場合は、脱線が始まったのと同じステップでリプロンプトを追加してください。 同じステップでリプロンプトを出したくない場合、またディグレッションリターンを防ぎたい場合は、以下のステップを実行する：

1. ホーム > アクション > 作成者にアクセスしてください。
2. ディグレッションリターンを防ぎたいアクションを選択する。
3. アクション設定をクリックします。
4. 会話のトピックを変更するで、トグルをオンに切り替えます。
5. このアクションを完了した後、元のアクションに戻らないを選択します。
6. 保存 をクリックします。

現在のノードが優先される ：現在のフローの外側にあるノードは、現在のフローがユーザー入力に対処できない場合にのみ、ディグレッション・ターゲットとして考慮される。 脱線を許すスロットを持つノードでは、どのような情報が必要かをユーザーに明確にし、ユーザーが値を提供した後に表示される確認文を追加する。

スロットへの情報の取り込み処理中は、すべてのスロットが取り込み可能です。 そのため、スロットが予期せずユーザー入力をキャプチャーすることがあります。 例えば、ディナーの予約に必要な情報を収集するスロットを持つノードがあるとします。 スロットの 1 つが日付情報を収集します。 ユーザーは、 What's the weather meant to be tomorrow? に問い合わせることができます。 forecastを条件とするルートノードがあれば、ユーザーに答えられるかもしれない。 しかし、ユーザーの入力には tomorrow という単語が含まれており、スロットを持つ予約ノードが処理されているため、アシスタントはユーザーが予約日を入力または更新していると見なします。 現行ノードは常に優先されます。 Ok, setting the reservation date to tomorrow,などの明確な確認ステートメントを定義すると、ユーザーがコミュニケーションの誤りに気付いて修正する可能性が高くなります。

どのスロットにも予期されていない値をユーザーが指定した場合、その値は、ユーザーが脱線することを意図していなかった関連のないルート・ノードと一致する可能性があります。

脱線の動作を構成する際には、必ず何度もテストを行ってください。

スロットハンドラの代わりにディグレッションを使う場合 ：ユーザーが質問するような一般的な質問には、ディグレッションを許可するルートノードを使い、入力を処理し、進行中のフローに戻る。 スロットを持つノードでは、ユーザーがスロットを埋めるときに尋ねたいであろう関連する質問のタイプを予測し、ノードにハンドラを追加することによって、それらに対処するようにしてください。

例えば、スロットを持つノードが保険金請求を完了するために必要な情報を収集する場合、保険に関する一般的な質問に対応するハンドラを追加したくなるかもしれない。 しかし、ヘルプの入手方法、店舗の場所、会社の歴史に関する質問には、ルートレベルのノードを使用します。