一般的なエージェント設計のベストプラクティス

このガイドでは、あらゆるタイプのエージェントを設計するための一般的なベストプラクティスについて説明します。

音声エージェントを設計するための音声エージェント設計ガイドと、Dialogflow を使用するためのベストプラクティスガイドもご覧ください。

一般的なアドバイス

エージェントを反復方式で構築する

大規模または複雑なエージェントの場合は、最初に最上位のリクエストのみを扱うダイアログを作成します。基本構造を確立したら、会話パスを反復して、エンドユーザーが辿る可能性のあるすべてのルートを網羅していることを確認します。

エージェントの機能強化を行う際には、テスト駆動型開発にテストケース機能の使用を検討してください。

ビルド済みエージェント

Dialogflow には、利用を開始する際に活用できるエージェントのテンプレートが用意されています。ビルド済みエージェントは、金融サービス、通信、旅行などの一般的なユースケースに対応します。こうしたエージェントには、最も一般的なユーザークエリに対応するインテントとエンティティが組み込まれています。ビジネスに固有のルートとフルフィルメントを追加すると、機能するエージェントを迅速に構築できます。

サービスの統合と接続

Dialogflow エージェントと統合するには、いくつかの方法があります。このセクションでは、統合方法を選択するためのベストプラクティスについて説明します。

統合

Dialogflow 統合は、エージェントにすぐに使用できるユーザーインターフェースを提供します。統合を使用する場合、Dialogflow API を直接呼び出す必要はありません。これは統合によって処理されるためです。これらの統合により、ウェブサイトに埋め込んだり、他のメッセージングプラットフォームと接続したり、テレフォニーインターフェースを提供したりできるテキストエージェントを提供できます。

Dialogflow API

直ちに使用できる統合のいずれも適していない場合や、システムのインターフェースをカスタマイズする必要がある場合は、Dialogflow API を直接使用できます。このアプローチでは、エージェント用のユーザーインターフェースを実装するか、既存のユーザーインターフェースを使用する必要があります。

Webhook

エージェントを静的データで完全に定義できる場合を除き、Webhook を使用してサービスを接続し、動的シナリオを処理できるエージェントを提供する必要があります。これは、統合と Dialogflow API のどちらを使用する場合についても該当します。

エージェント向けリソース

Dialogflow エージェントリソースを使用すると、さまざまな方法で目的とする結果を達成できます。このセクションでは、適切なシナリオに適したリソースを選択するためのアドバイスを提供します。

フローとページ

フローとページは、エージェントの構造を指定します。ページはステートマシン内のノードとして、フローは関連するページのグループと考えることができます。状態ハンドラを使用してノード間の遷移を制御します。ハンドラは、インテントが一致したとき、条件が満たされたとき、またはイベントが呼び出されたときに呼び出されます。

単純なエージェントは単一のフローで問題なく動作する場合がありますが、複雑なエージェントはほとんどの場合、複数のフローでより適切に設計されています。各フローはエージェントの大まかなトピックを表す必要があり、フローに関連付けられた各ページがそのトピックの処理に役立ちます。さらに、各フローには独自の設定がいくつかあり、チームメンバーのサブセットによって所有できるため、大規模なエージェントを設計するときに作業を分割するのに役立ちます。

大規模で複雑なエージェントを設計する場合は、「エージェントあたりのフロー数」と「フローあたりのページ数」の上限を考慮する必要があります。これらの上限は、エージェントのパフォーマンスを維持するために役立ちます。

エージェントの設計でエージェントごとのフローが多すぎる場合は、関連するトピックを 1 つのフローに結合します。たとえば、次のトピックを 1 つの「残高を取得する」フローに組み合わせることができます。

当座預金残高を取得する
普通預金残高を取得する
住宅ローンの残高を取得する
クレジットの残高を取得する

エージェントの設計でフローごとのページが多すぎる場合は、関連するページを組み合わせ、ページごとに多数のルートを使用します。

フローとページの制限に関する問題が解決しない場合は、エージェント自体にビジネスロジックが過剰に組み込まれている可能性があります。このロジックを Webhook に移行することを検討してください。

エージェントリソースの会話制御の粒度を、粒度の高い順に一覧表示します。

エージェント（1 つのエージェントがすべての会話を処理）
フロー（1 つのフローが 1 つ以上の関連する会話トピックを処理する）
ページ（1 つのページで、関連する 1 つ以上の会話ターンを処理する）
ルート（1 つのルートがユーザーのインテントまたは条件チェックを処理する）

インテントパラメータとフォームパラメータ

システムがエンドユーザーから構造化データを取得する主な方法は、パラメータを使用することによるものです。パラメータは、インテント（インテントパラメータ）またはページ（フォームのパラメータ）で使用できます。

一部のページは、エンドユーザーから特定の情報を収集することを主な目的としています。たとえば、エンドユーザーの連絡先情報を収集するようにページを設計できます。この場合、常にフォームパラメータを使用してこの情報を収集します。

場合によっては、あるページから別のページへの遷移中にエンドユーザー情報を取得する必要が生じる可能性があります。たとえば、エンドユーザーが会話の開始時に特定のプロダクトをリクエストする場合、適切な注文ページへの遷移中に目的のプロダクトをキャプチャします。この場合は、インテントルートの一部としてインテントパラメータを使用します。

また、インテントパラメータとフォームパラメータの両方を使用するのが理想的な状況もあります。たとえば、エンドユーザーが会話の開始時に小さなシャツをリクエストする場合、シャツの注文ページへの移行中に目的のサイズパラメータ（小）をキャプチャします。シャツの注文ページでは、希望する色などの追加情報が求められることがあります。シャツの注文ページには、サイズと色のフォームパラメータが必要です。この例では、サイズパラメータがすでに指定され、伝播されているため、エージェントは色のみをリクエストします。ただし、シャツの注文ページがアクティブになったときにエンドユーザーが目的のサイズを指定しない場合、他の会話が別のパスをたどる可能性があります。このパラメータを両方の方法で定義すると、エージェントが情報を抽出する方法の柔軟性が向上します。

ルートとルートグループ

別のページに移動したり、応答メッセージをキューに入れたり、インテントが一致したり条件が満たされたときにWebhookを呼び出したりする場合は、ルートを使用します。

複数のページで同じルートセットを使用していることが判明した場合は、ルートグループを使用します。これにより、エージェント設計の不要な重複を回避できます。

インテントの再利用

類似したトレーニングフレーズで複数のインテントを定義していることが判明した場合は、複数のページでインテントを再利用することを検討してください。理想的には、多くのページで使用される汎用インテントと、単一ページでのみ使用されるいくつかの特定のインテントを定義する必要があります。これにより、エージェント設計の不要な重複を回避できます。

たとえば、確認インテントは通常、再利用可能なインテントとして最もよく定義されます。 confirmation.yes インテントには、次のようなトレーニングフレーズを含めることができます。

○
ええ
はい
OK
はい、使用します
そのとおりです
もちろんです
はい、お願いします

confirmation.no インテントには、次のようなトレーニングフレーズを含めることができます。

いいえ
nah
いいえ
あり得ません
好みに合わない
絶対ないです
同意しない

これらの再利用可能な確認インテントは、エージェントのさまざまなシナリオで使用できます。

場合によっては、特別な確認インテントの作成も検討する必要があります。たとえば、注文を確認するときに、次のようなトレーニングフレーズを含む特殊な order.confirmation.yes インテントを作成できます。

注文内容に問題ありません
この注文に同意します

また、次のようなトレーニングフレーズを使用した特殊な order.confirmation.no インテントも指定できます。

この注文は要りません
この注文に同意しません

注文確認ページがアクティブな場合、これら 4 つすべてのインテントのインテントルートが対象範囲内にあることが必要です。これにより、エンドユーザーによる一般的な確認または特定の確認が適切に処理されます。

デフォルトのネガティブインテント

エンドユーザーが話しかける可能性のあるフレーズをデフォルトのネガティブインテントに入力する必要がありますが、エージェント内のインテントには一致しないようにしてください。

フルフィルメント

フルフィルメントを使用してエンドユーザーに対応するためには、さまざまなオプションがあります。会話ターン中にエージェントは複数のメッセージをレスポンスキューに追加できます。連結されたキューは会話ターンの終了時にエンドユーザーに送信されます。このセクションでは、個別のメッセージを作成するための各オプションについて説明します。

ページエントリのフルフィルメント: このフルフィルメントは、ページが最初にアクティブになったときに呼び出されます。ページの目的を説明するメッセージが必要な場合に便利で、ページがアクティブである場合にのみ 1 回だけ伝えるようにします。例:
- 当座預金口座について何を知りたいですか？
- 購入を希望される商品の種類を選択してください。
- 注文を希望されるシャツに関する情報をいくつか収集する必要があります。
ルート: このフルフィルメントは、インテントルートまたはフルフィルメントを含む条件ルートが呼び出されたときに呼び出されます。これは、インテントの一致、条件（フォーム入力の完了条件である場合が考えられます）が満たされていること、または遷移についてエンドユーザーに応答するメッセージが必要な場合に有効です。例:
- はい、国際プランに日本が含まれています。(インテントマッチング)
- シャツを 300 枚購入してもよろしいですか？（比較条件が満たされている）
- 予約は明日の午前 7 時です。（フォーム入力の完了）
- それでは、ツチブタについてご説明します。（遷移）
イベントハンドラ: このフルフィルメントは、イベントが呼び出されたときに呼び出されます。これは、イベントに応答するメッセージが必要な場合に有効です。たとえば、次のような情報が得られます。
- 購入を検討なさっている株式の価値が 10% 上昇しました。（カスタムイベント）
- 言い換えていただけますか？（不一致イベント）
フォームの初期プロンプト: このフルフィルメントは、エージェントがフォームの入力を実行したときに呼び出されます。これらのメッセージは、エンドユーザーに具体的な質問をする必要があります。各フォームパラメータには独自の初期プロンプトフルフィルメントがあります。たとえば、次のような情報が得られます。
- どのサイズのシャツをご希望ですか？
- どの色のシャツをご希望ですか？
フォームのリプロンプトハンドラ: このフルフィルメントは、エージェントがフォームに入力している際に呼び出され、エージェントは現在のパラメータに関するエンドユーザーの選択を理解しません。このフルフィルメントは、リプロンプトメッセージを最初のプロンプトメッセージとは異なるものにする場合にのみ必要です。リプロンプトハンドラが存在しない場合、エージェントはリプロンプトメッセージとして最初のプロンプトを使用します。たとえば、次のような情報が得られます。
- わかりません。シャツの有効な色をご指定いただけますか？

命名

このセクションでは、エージェントリソースの命名に関するアドバイスを示します。

インテントの命名

インテントが多いエージェントの場合は、整理しやすい命名規則にすることをおすすめします。インテント名は句読点で区切るのが一般的で、左から右に向かって具体性が増加します。また、インテントの名前には、会話ターンにおけるエンドユーザーのインテントを反映する必要があります。

有効な命名規則は多数あります。次の例をご覧ください。

phone-service.order.cancel
phone-service.order.create
phone-service.order.change
tv-service.order.cancel
tv-service.order.create
tv-service.order.change
account.balance.get
account.balance.pay
account.address.get
account.address.update

移行

状態ハンドラで定義された遷移では、アクティブなページを変更して会話を制御します。このセクションでは、エージェントの遷移を整理するためのアドバイスを提供します。

補完の遷移

遷移をトリガーするルートを定義する際は、補完的なルートや逆方向のルートが存在する可能性がある点に留意してください。

例:

confirmation.yes のインテントルートがある場合は、confirmation.yes 用の別のルートを定義することを検討してください。
ブール値 = 演算子で条件ルートを定義する場合は、!= を使用する別のルートを定義することを検討してください。

エンドユーザー入力の処理

このセクションでは、エージェントがエンドユーザーの入力を最適に扱い処理できるように、インテントとトレーニングフレーズのガイドラインを提供します。

少なくとも 20 個のトレーニングフレーズを定義する

インテントごとに少なくとも 20 個のトレーニングフレーズが必要です。この状態にしないと、NLU モデルには、インテントに適切にマッチングするのに十分な情報を確保できない可能性があります。これは必要最小限のガイドラインです。理想的には、より多くのエージェントを定義する必要があります。特に、大規模なエージェントの主なインテントについては、約 50 個が望ましい数です。

インテントバイアスに注意する

1 つ以上のインテントに、他のインテントよりもトレーニングフレーズが大幅に多い場合は、不均一なデータのために NLU モデルが大きいインテントにバイアスします。このインテントバイアスは、トレーニングフレーズの量が桁違いに異なる場合に発生します。

このような動作が望ましい場合があります。これは、ライブトラフィックでより頻繁に観察されるエンドユーザー入力に対応するため、他のインテントよりも頻繁に一致する必要があるインテントを定義する場合があるためです。

一方、この動作は、こうしたより大きなインテントを優先するバイアスが生じることを回避する必要があるため、望ましくない場合があります。この場合は、これらの大規模なインテントのトレーニングフレーズ数を、他のインテントと同じ大きさに減らします。例:

インテント A のトレーニングフレーズ	インテント B のトレーニングフレーズ	インテント B のバイアス
20	50	いいえ
20	200	ボーダーライン
20	2000	○

エンティティの使用とトレーニングフレーズの量

インテントで使用されるすべてのエンティティタイプの場合:

エンティティタイプのすべての例にアノテーションを付けます。
エンティティタイプごとに、アノテーション付きの例を含むトレーニングフレーズを少なくとも 5 つ指定します。
エンティティタイプの少なくとも 3 倍の数のトレーニングフレーズを指定します。たとえば、1 つのインテントのアノテーションに 10 種類のエンティティタイプを使用する場合、少なくとも 30 個のトレーニングフレーズが必要です。

トレーニングフレーズは自然であることが必要である

トレーニングフレーズは、会話的かつ自然で、ユーザーが実際に言う言葉と一致する必要があります。可能であれば、本番環境で発生したエンドユーザーの入力をトレーニングデータとして使用します（特に最も一般的なものに着目してください）。

必要なトレーニングフレーズの種類

考えられる多種多様なリクエストに対応できるよう、フレーズには、質問、命令、動詞、よく使われる名詞の類義語のバリエーションを含めてください。

「請求額を支払います」などの短いフレーズと、「請求残高を支払う必要がありますと書かれたメールを受け取りました」などの長いフレーズと文を含めることをおすすめします。短いフレーズと長いフレーズの推奨する割合はありませんが、本番環境でエージェントに送信された実際のエンドユーザー入力に基づいた割合にする必要があります。

エージェントに適したトレーニングを提供するために、長さ、フレーズ、文の構造が異なるトレーニングフレーズを定義することが重要です。バリエーションを確保するためにバリエーションを追加する必要はありませんが、NLU モデルが幅広いエンドユーザー入力からエンドユーザーのインテントを正常に検出できるだけの十分なバリエーションを提供する必要があります。バリエーションが十分でない場合は、過学習の状態になるリスクがあります。つまり、指定した特定のサンプルとモデルの関連性が極端に高くなり、他のサンプルにまで一般化が十分に適用されない危険性があります。

大文字小文字表記の多様性

大文字小文字表記の感度は、エージェントが使用している NLU モデルによって異なります。

標準の NLU

標準の NLU モデルでは、大文字と小文字は区別されません。まれに、大文字小文字表記のみが異なるトレーニングフレーズを追加しなければならない場合があります。通常は、エンドユーザーがすべて大文字のテキストを入力すると想定される場合が該当します。

代わりに使用できる方法は、次のとおりです。

ML 分類しきい値を下げる
Dialogflow に送信する前にエンドユーザー入力を小文字に変換します。

高度な NLU

標準の NLU モデルとは異なり、高度な NLU モデルでは大文字と小文字が区別されます。インテントのマッチ率を向上させるには、関連する大文字に変換されたトレーニングデータをテストして追加することをおすすめします。

不要なトレーニングフレーズの多様性

トレーニングフレーズについては、NLU モデルに重複する情報を提供することになるため、相違点が軽微なバリエーションの使用は回避してください。たとえば、次の点のみが異なるバリエーションは含めないでください。

大文字小文字表記: 標準の NLU モデルを使用している場合は、まれなケースを除き、「Order a ticket」と「order a ticket」のような重複フレーズを使用しないでください。ただし、高度な NLU モデルでは大文字と小文字が区別され、インテント一致を増やすには、より多くのトレーニングフレーズが必要です。詳しくは、大文字小文字表記の種類のセクションをご覧ください。
つなぎ言葉: たとえば、「OK、チケットを注文して」や「チケットを注文して」などです。
句読点: 「お手伝いをお願いできますか？」、「お手伝いをお願いできますか！？」

アノテーションの整合性

アノテーションに選択されたトレーニングフレーズ部分には、エンティティと一致するために必要なテキストすべてが含まれており、その他の要素は含まれていない必要があります。また、インテント全体でトレーニングフレーズの類似部分にもアノテーションが付けられるようにします。

たとえば、次の表は、@sys.date システムエンティティにアノテーションを付ける良い方法と悪い方法を示しています。

良い	悪い
9 月 7 日出発	9 月 7 日出発
7 月 4 日に出発	7 月 4 日に出発

システムエンティティに意味論的に意味のあるアノテーションを使用する

アノテーションに選択されたトレーニングフレーズ部分の意味論的な意味は、トレーニングフレーズの残りのテキストによって変わる可能性があります。例:

アノテーション付きトレーニングフレーズ	アノテーション付きテキストの意味論的意味
私は 7 歳です。	人物の年齢
契約は 7 年間有効です	期間

Dialogflow の機械学習モデルは、システムエンティティとの照合時に意味論的な意味を考慮します。トレーニングフレーズ部分の意味論的意味は、システムエンティティの意図された意味論的意味と一致する必要があります。

@sys.durationたとえば、上記の最初の「7 年」の例のアノテーションには、システムエンティティを使用しないでください。「7 年」の意味論的な意味は、単純な期間と一致しません。代わりに、アノテーションに「7」を選択し、@sys.number システムエンティティを使用する必要があります。

非準拠のフォーム入力回答を処理するインテントを定義する

非準拠のフォーム入力回答を処理するインテントを定義することを検討してください。たとえば、エージェントが「旅行の日程は？」と尋ね、それに続いてエンドユーザーが「まだわからない」と回答したとします。この回答はフォームパラメータのプロンプトを満たしていませんが、エージェントに、この回答に一致するインテントルートがある場合、エージェントは状況に対して適切に対処できます。

@sys.any を避ける

@sys.any システムエンティティタイプは使用しないでください。カスタムエンティティを構築するためなど、すべての方法を使用しており、他に使用できる方法がない場合にのみ使用してください。このエンティティタイプは非常に広範囲にわたるため、望ましくない動作を引き起こす可能性があります。

このエンティティタイプを使用する場合は、あいまいさが生じ、エージェントの動作が未定義になるため、1 つのトレーニングフレーズの複数の部分にこのエンティティタイプでアノテーションを付けないでください。

フォームパラメータのプロンプトではエージェントが特定の情報を想定しているため、フォームパラメータで @sys.any を使用する危険は低くなります。

アノテーションにはさまざまなエンティティ値を含める必要がある

アノテーション付きのトレーニングフレーズを定義する場合は、さまざまなエンティティ値の例をフレーズで使用する必要があります。アノテーションに同じエンティティサンプルを一貫して使用しないでください。次の例は、商品エンティティタイプの良好なアノテーションと良好ではないアノテーションを示しています。

良い	悪い
シャツを購入したい	シャツを購入したい
新しい帽子を注文する	新しいシャツを注文する
カートにスマートウォッチを追加する	カートにシャツを追加する

カスタムエンティティにはさまざまなものを含める必要があります

カスタムエンティティには、さまざまな例を含める必要があります。 NLU モデルでは文法構造に対してバリエーションが提示されますが、考えられるすべてのアイテムを含める必要があります。

積極的に一致するエンティティの使用を回避する

実質的に何にでも一致するエンティティを定義しない。このようなエンティティでは、ML のパフォーマンスと品質が低下します。トレーニングフレーズのほぼすべてが、一致候補として評価されます。

マップエンティティとリストエンティティは個別の値に焦点を当てる必要がある

マップとリストエンティティタイプは、1 つの種類の情報の個別値を把握するためスコープを限定する必要があります。エンティティは短く、簡潔性を保持します。

エンティティ値が複雑な場合は、インテントのトレーニングフレーズが状況に適しているからである可能性があります。たとえば、次のようなエンドユーザー入力について考えてみます。

「プラン A で国際電話をかけるにはどうすればよいですか？」
「プラン B で国際データローミングを使用します」

次のように、アクションとプランの両方にエンティティタイプを作成しないでください。

アクションのエンティティタイプ	プランのエンティティタイプ
「国際電話をかけるにはどうすればよいですか」	「プラン A」
「国際データローミングを使用します」	「プラン B」

その代わり、トレーニングフレーズやインテントマッチングを使用して、プランを取得するアクションやエンティティを取得します。

正規表現エンティティを使用して非単語識別子を取得する

非単語識別子を含むエンドユーザー入力を取得する場合は、正規表現エンティティを使用する必要があります。たとえば、「AA-256」や「AC-436」などの商品 ID を取得するには、「[A-Z]{2}-\d{3}」などの正規表現エンティティを使用します。

複合エンティティをネストしない

複合エンティティでは複数レベルのネストを使用しないでください。各ネストレベルの品質が大幅に低下します。

類似したインテントを避ける

各インテントはエンドユーザーのインテントを取得する必要があります。類似したトレーニングフレーズを使用して異なるインテントを定義すると、NLU モデルが十分な信頼性を持ってどのインテントが一致するかを判断できないため、一致の信頼性が低下する可能性があります。

2 つのトレーニングフレーズが同じ意図を表す場合、それらのフレーズは同じインテントに属している必要があります。たとえば、「現在の請求期限を変更する」と「支払い期限の延長」は、どちらも同じインテントに属する必要があります。これは、どちらも期限の変更をリクエストしているためです。ただし、「プラン A で国際電話をかけることはできますか？」と「プラン A で国際データローミングを使用できますか？」は、エンドユーザーごとに必要とする対象が異なるため、異なるインテントに属する可能性があります。

類似したエンティティタイプの使用を回避する

NLU モデルが曖昧になる可能性があるため、類似したエンティティエントリを持つ複数のエンティティタイプを定義することは回避する必要があります。

本番環境で不一致イベントを使用してインテントを改善する

エージェントを本番環境で実行する場合、一部のエンドユーザー入力が不一致イベントになることは不可避です。これらの機会を活用して、次の 3 つの方法のいずれかでエージェントを改善できます。

エンドユーザー入力をトレーニングフレーズとして目的のインテントに追加します。ただし、これが最適な選択肢であるとは限りません。インテントに対してこれを多数回行うと、インテントバイアスにつながる可能性があります。
目的のインテントのトレーニングフレーズをクリーンアップして、すべてのインテントが意図を正確に反映するようにします。場合によっては、多岐にわたるトレーニングフレーズを使用したインテントがインテントのマッチングを妨げる可能性があります。
エンドユーザー入力に一致しないようにする必要があるインテントに、エンドユーザー入力と一致する可能性があるトレーニングフレーズが含まれている場合は、これらのトレーニングフレーズを削除します。

特殊文字を使用しない

トレーニングフレーズ内の特殊文字（{、_、#、[ など）は無視されます。例外として、顔文字は想定どおりに動作します。

「ええと」、「あの」、「まあ」など、発話の合間にはさみこむ言葉は使用しないでください

つなぎ言葉は、無視できるものの、テキストを理解できる単語です。例:

お願い
お願いですから
んー
はいかがですか？

NLU モデルでは無視されるため、トレーニングフレーズでつなぎ言葉を使う必要はありません。ただし、つなぎ言葉だけが異なるトレーニングフレーズは定義しないでください。

つなぎ言葉で構成されているエンティティを定義しない。

ML 設定を試す

ML 設定は、エンドユーザー入力の処理方法を調整するのに使用できます。ほとんどの場合、デフォルト設定で問題ありません。ただし、エージェントのパフォーマンスを向上させるために設定を微調整することが必要になる場合もあります。

エンドユーザーへの応答

このセクションでは、フルフィルメントを使用してエンドユーザーに対応するためのガイドラインを説明します。

エンドユーザーを歓迎する

新しく作成されたエージェントには、歓迎のインテント用の自動的に作成されたインテントルートがあります。このルートを編集して、エンドユーザーを歓迎するフルフィルメントメッセージを含める必要があります。このメッセージはエージェントについて説明し、エージェントができることをエンドユーザーが理解できるようにするものであることが必要です。

エンドユーザー情報を確認する

多くの場合について、レスポンスでエンドユーザーから提供された情報を繰り返すことをおすすめします。これにより、エージェントがリクエストを理解していることをエンドユーザーが理解できます。

インテントが一致し、遷移が発生した場合は、リクエストに基づいて会話を進めていることをエンドユーザーに伝えます。例:

対話	説明
エンドユーザー: 当座預金口座について質問があります。エージェント: わかりました。当座預金口座について何を知りたいですか？	エンドユーザーの入力がインテント一致となり、フルフィルメントメッセージとアカウント確認チェックを処理するページへの遷移を含むルートがたどられました。エージェントは、エンドユーザーが当座預金口座について知りたいことを確認したことがわかります。

フォームの入力が完了したら、エンドユーザーから提供されたデータを繰り返します。例:

対話	説明
エンドユーザー: 明日エージェント: 承知しました。ヘアカットは明日午後 7 時にスケジュールされています。他にも何かサポートが必要なことはございますか？	エンドユーザーが、アクティブなページの最後のフォームパラメータである日付フォームパラメータを指定しました。エージェントは、スケジュールしたヘアカットの日時を確認しました。

会話をガイドする

エージェントは常にエンドユーザーとの会話をリードする必要があります。これは、各レスポンスの末尾に次のような質問を行うことで簡単に実現できます。

他にも何かサポートが必要なことはございますか？
ビーグルについてお知りになりたいことは何ですか？
注文をキャンセルもしくは送信しますか？
どんなことでお困りですか？
旅行は 1 人ですか、それとも誰かと一緒ですか？

質問を定義するときは、次のような複数の質問は避ける必要があります。

まだここにいますか？お問い合わせのサービスは何ですか？
引き続きこの注文を希望しますか？何かを追加しますか？

エンドユーザーがいずれかの質問にのみ回答すると、エージェントがその状況に正しく対処できない場合があります。

エラーと予期しないエンドユーザー入力の処理

このセクションでは、エラーと予期しないエンドユーザー入力の処理に関するアドバイスを提供します。

組み込みイベント用のイベントハンドラを作成する

必要に応じて、組み込みイベントのイベントハンドラを作成する必要があります。これらのイベントの処理は、ソフトウェアプログラミングでの例外の捕捉と類似しています。状況に応じて、パラメータ固有のイベントハンドラ、ページ固有のイベントハンドラ、またはフロー固有のイベントハンドラでイベントを処理できます。

Webhook エラーを処理する

Webhook サービスが失敗した場合、エージェントが障害を適切に処理できることが重要です。これを実現するには、Webhook 固有の組み込みイベントのイベントハンドラを定義します。Webhook エラーの処理には、次の方法をおすすめします。

Webhook 呼び出しをトリガーする state ハンドラからの遷移ターゲットを指定しないでください。指定すると、Webhook エラーのイベントハンドラは呼び出されません。代わりに、Webhook サービスからの Webhook レスポンスで遷移ターゲットを設定します。
エラーカウンタをゼロに初期化できるページを選択します。このページは、Webhook 呼び出しをトリガーするページの前にアクティブであることが必要です。このページのエントリフルフィルメントでは、フルフィルメントパラメータプリセットを使用して、エラーカウンタを 0 に初期化する必要があります。例:

パラメータ値

webhook-error-count 0
Webhook エラーイベントを処理する Webhook エラーページを作成します。
- エントリフルフィルメントは、エンドユーザーの障害を認識し、フルフィルメントパラメータプリセットを使用してエラーカウンタセッションパラメータをインクリメントする必要があります。例:
  
  パラメータ値
  
  webhook-error-count $sys.func.ADD($session.params.webhook-error-count, 1)
- エラー数が最大許容数未満であることを要件とする条件を持つ条件ルートを定義します（例: $session.params.webhook-error-count <= 3）。このルートには、エージェントが再試行することをエンドユーザーに通知するフルフィルメントが必要です。このルートには、PREVIOUS_PAGE、または Webhook の呼び出しを再試行できるページに設定された遷移ターゲットを配置する必要があります。
- エラー数が許容最大値（$session.params.webhook-error-count > 3 など）よりも大きい条件を持つ条件ルートを定義します。このルートには、エンドユーザーにエージェントが再試行しなくなったことを通知するフルフィルメントを設定する必要があります。このルートには、Webhook 再試行をトリガーしないページに設定された遷移ターゲットを配置する必要があります。
Webhook イベントハンドラには、Webhook エラーページに遷移する遷移ターゲットが必要です。

パラメータ	値
`webhook-error-count`	`0`

パラメータ	値
`webhook-error-count`	`$sys.func.ADD($session.params.webhook-error-count, 1)`

ツール

このセクションでは、ツールを使用してエージェントの設計を改善するためのアドバイスを提供します。

検証ツールを使用する

エージェントの確認には、常に検証ツールを使用する必要があります。このツールによって、このガイドで説明する問題をいくつか検出できます。

テストケース機能を使用する

エージェントのテストケースは常に定義する必要があります。これらのテストケースは、エージェントが進化してより多くのシナリオを処理する過程で、回帰を防止するのに活用できます。

サービス使用のベストプラクティス

音声エージェント設計のベストプラクティス