このガイドでは、すべてのタイプのエージェントを設計する際の一般的なベスト プラクティスについて説明します。
音声エージェントを設計するための音声エージェント設計ガイドと、会話エージェント（Dialogflow CX） を使用するためのベスト プラクティスガイドもご覧ください。
一般的なアドバイス
エージェントを反復方式で構築する
大規模または複雑なエージェントの場合は、最初に最上位のリクエストのみを扱うダイアログを作成します。基本構造を確立したら、会話パスを反復して、エンドユーザーが辿る可能性のあるすべてのルートを網羅していることを確認します。
エージェントの機能強化を行う際には、テスト駆動型開発にテストケース機能の使用を検討してください。
ビルド済みエージェント
会話エージェント（Dialogflow CX）には、利用を開始する際に活用できるエージェントのテンプレートが用意されています。ビルド済みエージェントは、金融サービス、通信、旅行などの一般的なユースケースに対応します。 こうしたエージェントには、最も一般的なユーザークエリに対応するインテントとエンティティが組み込まれています。ビジネスに固有のルートとフルフィルメントを追加すると、機能するエージェントを迅速に構築できます。
サービスの統合と接続
会話エージェント（Dialogflow CX）エージェントと統合するには、いくつかの方法があります。このセクションでは、統合方法を選択する際のベスト プラクティスについて説明します。
統合
会話エージェント（Dialogflow CX）の統合は、エージェントにすぐに使用できるユーザー インターフェースを提供します。統合を使用する場合、会話エージェント（Dialogflow CX API） を直接呼び出す必要はありません。これは統合によって処理されるためです。これらの統合により、ウェブサイトに埋め込んだり、他のメッセージング プラットフォームと接続したり、テレフォニー インターフェースを提供したりできるテキスト エージェントを提供できます。
会話エージェント（Dialogflow CX）API
直ちに使用できる統合のいずれも適していない場合や、システムのインターフェースをカスタマイズする必要がある場合は、会話エージェント（Dialogflow CX API）を直接使用できます。このアプローチでは、エージェント用のユーザー インターフェースを実装するか、既存のユーザー インターフェースを使用する必要があります。
Webhook
エージェントを静的データで完全に定義できる場合を除き、Webhook を使用してサービスを接続し、動的シナリオを処理できるエージェントを提供する必要があります。 これは、統合と会話エージェント（Dialogflow CX）API のどちらを使用する場合についても該当します。
エージェント向けリソース
会話エージェント（Dialogflow CX）エージェント リソースを使用すると、さまざまな方法で目的とする結果を達成できます。このセクションでは、適切なシナリオに適したリソースを選択するためのアドバイスを紹介します。
フローとページ
フローとページは、エージェントの構造を指定します。ページはステートマシン内のノードとして、フローは関連するページのグループと考えることができます。 状態ハンドラを使用してノード間の遷移を制御します。ハンドラは、インテントが一致したとき、条件が満たされたとき、またはイベントが呼び出されたときに呼び出されます。
単純なエージェントは単一のフローで問題なく動作する場合がありますが、複雑なエージェントはほとんどの場合、複数のフローでより適切に設計されています。各フローはエージェントの大まかなトピックを表す必要があり、フローに関連付けられた各ページがそのトピックの処理に役立ちます。さらに、各フローには独自の設定がいくつかあり、チーム メンバーのサブセットによって所有できるため、大規模なエージェントを設計するときに作業を分割するのに役立ちます。
大規模で複雑なエージェントを設計する場合は、「エージェントあたりのフロー数」と「フローあたりのページ数」の上限を考慮する必要があります。これらの上限は、エージェントのパフォーマンスを維持するために役立ちます。
エージェントの設計でエージェントごとのフローが多すぎる場合は、関連するトピックを 1 つのフローに結合します。 たとえば、次のトピックを 1 つの「残高を取得する」フローに組み合わせることができます。
- 当座預金残高を取得する
- 普通預金残高を取得する
- 住宅ローンの残高を取得する
- クレジットの残高を取得する
エージェントの設計でフローごとのページが多すぎる場合は、関連するページを組み合わせ、ページごとに多数のルートを使用します。
フローとページの制限に関する問題が解決しない場合は、エージェント自体にビジネス ロジックが過剰に組み込まれている可能性があります。 このロジックを Webhook に移行することを検討してください。
エージェント リソースの会話制御の粒度を、粒度の高い順に一覧表示します。
- エージェント（1 つのエージェントがすべての会話を処理）
- フロー（1 つのフローが 1 つ以上の関連する会話トピックを処理する）
- ページ（1 つのページで、関連する 1 つ以上の会話ターンを処理する）
- ルート（1 つのルートがユーザーのインテントまたは条件チェックを処理する）
インテント パラメータとフォーム パラメータ
システムがエンドユーザーから構造化データを取得する主な方法は、パラメータを使用することによるものです。パラメータは、インテント（インテント パラメータ）またはページ（フォームのパラメータ）で使用できます。
一部のページは、エンドユーザーから特定の情報を収集することを主な目的としています。 たとえば、エンドユーザーの連絡先情報を収集するようにページを設計できます。 この場合、常にフォーム パラメータを使用してこの情報を収集します。
場合によっては、あるページから別のページへの遷移中にエンドユーザー情報を取得する必要が生じる可能性があります。たとえば、エンドユーザーが会話の開始時に特定のプロダクトをリクエストする場合、適切な注文ページへの遷移中に目的のプロダクトをキャプチャします。この場合は、インテント ルートの一部としてインテント パラメータを使用します。
また、インテント パラメータとフォーム パラメータの両方を使用するのが理想的な状況もあります。 たとえば、エンドユーザーが会話の開始時に小さなシャツをリクエストする場合、シャツの注文ページへの移行中に目的のサイズ パラメータ（小）をキャプチャします。 シャツの注文ページでは、希望する色などの追加情報が求められることがあります。 シャツの注文ページには、サイズと色のフォーム パラメータが必要です。 この例では、サイズ パラメータがすでに指定され、伝播されているため、エージェントは色のみをリクエストします。 ただし、シャツの注文ページがアクティブになったときにエンドユーザーが目的のサイズを指定しない場合、他の会話が別のパスをたどる可能性があります。このパラメータを両方の方法で定義すると、エージェントが情報を抽出する方法の柔軟性が向上します。
ルートとルートグループ
別のページに移動したり、応答メッセージをキューに入れたり、インテントが一致したり条件が満たされたときにWebhookを呼び出したりする場合は、ルートを使用します。
複数のページで同じルートセットを使用していることが判明した場合は、ルートグループを使用します。これにより、エージェント設計の不要な重複を回避できます。
インテントの再利用
類似したトレーニング フレーズで複数のインテントを定義していることが判明した場合は、複数のページでインテントを再利用することを検討してください。理想的には、多くのページで使用される汎用インテントと、単一ページでのみ使用されるいくつかの特定のインテントを定義する必要があります。これにより、エージェント設計の不要な重複を回避できます。
たとえば、確認インテントは通常、再利用可能なインテントとして最もよく定義されます。
confirmation.yes インテントには、次のようなトレーニング フレーズを含めることができます。
- はい
- ええ
- そう
- OK
- はい、使用します
- そのとおりです
- もちろんです
- はい、お願いします
confirmation.no インテントには、次のようなトレーニング フレーズを含めることができます。
- いいえ
- いや
- いいえ
- あり得ません
- 好みに合わない
- 絶対ないです
- 同意しない
これらの再利用可能な確認インテントは、エージェントのさまざまなシナリオで使用できます。
場合によっては、特別な確認インテントの作成も検討する必要があります。
たとえば、注文を確認するときに、次のようなトレーニング フレーズを含む特殊な 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 モデルが幅広いエンドユーザー入力からエンドユーザーのインテントを正常に検出できるだけの十分なバリエーションを提供する必要があります。バリエーションが十分でない場合は、過学習の状態になるリスクがあります。つまり、指定した特定のサンプルとモデルの関連性が極端に高くなり、他のサンプルにまで一般化が十分に適用されない危険性があります。
大文字小文字表記の多様性
大文字小文字表記の感度は、エージェントが使用している NLU モデルによって異なります。
標準の NLU
標準の NLU モデルでは、大文字と小文字は区別されません。まれに、大文字小文字表記のみが異なるトレーニング フレーズを追加しなければならない場合があります。通常は、エンドユーザーがすべて大文字のテキストを入力すると想定される場合が該当します。
代わりに使用できる方法は、次のとおりです。
- ML 分類しきい値を下げる
- 会話エージェント（Dialogflow CX）に送信する前にエンドユーザー入力を小文字に変換します。
高度な 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 CX）の機械学習モデルは、システム エンティティとの照合時に意味論的な意味を考慮します。トレーニング フレーズ部分の意味論的意味は、システム エンティティの意図された意味論的意味と一致する必要があります。
@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-count0Webhook エラーイベントを処理する 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 エラーページに遷移する遷移ターゲットが必要です。
ツール
このセクションでは、ツールを使用してエージェントの設計を改善するためのアドバイスを提供します。
検証ツールを使用する
エージェントの確認には、常に検証ツールを使用する必要があります。このツールによって、このガイドで説明する問題をいくつか検出できます。
テストケース機能を使用する
エージェントのテストケースは常に定義する必要があります。 これらのテストケースは、エージェントが進化してより多くのシナリオを処理する過程で、回帰を防止するのに活用できます。