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

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

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

一般的なアドバイス

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

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

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

ビルド済みエージェント

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

サービスの統合と接続

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

統合

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

Dialogflow API

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

Webhook

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

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

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

フローとページ

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

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

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

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

当座預金残高の取得
コスト削減のバランスをとる
住宅ローンの残高を取得する
クレジット残高を取得する

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

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

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

エージェント（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.no 用の別のルートを定義することを検討してください。
ブール演算子 = を使用して条件ルートを定義する場合は、!= を使用する別のルートを定義することを検討してください。

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

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

20 個以上のトレーニングフレーズを定義する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大文字小文字表記（まれなケースは除く）: 「Order a ticket」と「order a ticket」など。
つなぎ言葉: たとえば、「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 設定を使用すると、エンドユーザー入力の処理方法を調整できます。ほとんどの場合、デフォルトの設定で問題ありません。ただし、エージェントのパフォーマンスを向上させるために設定を微調整することもできます。

エンドユーザーへの対応

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

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

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

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

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

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

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

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

対話	説明
エンドユーザー: 明日エージェント: 承知しました。ヘアカットは明日の午後 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)`

ツール

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

検証ツールを使用する

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

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

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

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

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