このガイドでは、すべてのタイプのエージェントを設計する際の一般的なベスト プラクティスについて説明します。
音声エージェントを設計するための音声エージェント設計ガイドと、Dialogflow を使用するためのベスト プラクティスガイドもご覧ください。
エージェントを構築する前に
このセクションでは、エージェントの構築を開始する前に検討しておく必要がある内容について説明します。
目的
エージェントの全体的な目的を検討します。
- ビジネスで達成しようとしている目標は何か？
- ユーザーはエージェントに何を期待しているか？
- ユーザーがエージェントとやり取りする頻度はどの程度か？
プラットフォーム
ユーザーがエージェントにアクセスする方法を検討します。コンテンツを作成する前に、Dialogflow でサポートされているプラットフォームを確認します。サポートするプラットフォームを選択したら、それに応じてコンテンツを準備します。Dialogflow のプラットフォーム統合の中には、画像、リンク、候補ワードなどの要素を組み込める高度なメッセージがサポートされているものもあります。
エージェントを反復方式で構築する
大規模または複雑なエージェントの場合は、最初に最上位のリクエストのみを扱うダイアログを作成します。基本構造を確立したら、会話パスを反復して、ユーザーが辿る可能性のあるすべてのルートを網羅していることを確認します。
Prebuilt Agent
Dialogflow には、使い始める際に役立つあらかじめ作成されたエージェントが用意されています。これらの既製エージェントは、ホテルの予約、ナビゲーション、オンライン ショッピングなどの一般的なユースケースに対応します。こうしたエージェントには、最も一般的なユーザークエリに対応するインテントとエンティティが組み込まれています。企業独自のレスポンスを追加すれば、機能するエージェントをすぐに構築できます。
システム エンティティ
ユーザーがリクエストを送信したら、その内容から解析すべき重要な情報があります。Dialogflow では、こうした情報はエンティティと呼ばれます。特にシステム エンティティは、Dialogflow が提供する既製エンティティであり、最も使用頻度が高い種類の情報が処理されます。
Small Talk
ダイアログを開発する際に、トピックから外れたリクエストの処理が検討されることもあります。Dialogflow には、Small Talk と呼ばれるオプション機能があります。この機能を有効にすると、エージェントは一般的な会話、感情的な反応、エージェント自体に関する質問に対応できるようになります。ブランドに適したエクスペリエンスが提供できるように、Small Talk のレスポンスはすべてカジュアルにも、ビジネスライクにも、あるいはその中間にもカスタマイズできます。
エージェント設計のベスト プラクティス
このセクションでは、堅牢で正確、高パフォーマンスで実用的なエージェントを設計するためのベスト プラクティスの一覧を示します。
挨拶と結びの言葉
| ベスト プラクティス | 詳細 |
|---|---|
| Welcome Intent に、ブランディングを反映した上でエージェントの機能をユーザーに知らせる。 | エージェントの Welcome Intent で、エージェントがサポートできる 2～3 のタスクをユーザーに知らせ、それらの機能の使い方を（必要に応じて）簡単に説明する必要があります。 |
| やり取りが正常に終わった時点で、エージェントが適切なメッセージで終了するようにする。 | ユーザーがエージェントでのタスクを完了したら、エージェントがトランザクション / タスクの概要をまとめ、「またお会いしましょう」などの言葉をかけるようにします。 |
機械学習とトレーニング
| ベスト プラクティス | 詳細 |
|---|---|
| インテントには（インテントの複雑さに応じて）少なくとも 10～20 のトレーニング フレーズが必要です。 | 各インテントに必要な実際のトレーニング フレーズの数は、エージェントの複雑さに応じて決まりますが、（インテントの複雑さに応じて）10～20 は最小値として適切です。インテントに含まれるパラメータの数が多いほど、機械学習モデルのトレーニングに提供するフレーズの数を増やす必要があります。 |
| 多種多様なトレーニング フレーズを含める。 | 行われる可能性がある多種多様なリクエストに対応できるよう、フレーズには、質問、命令、動詞、よく使われる名詞の類義語のバリエーションを含めてください。 |
| アノテーションに一貫性を持たせる。 |
|
| システム エンティティに意味論的に意味のあるアノテーションを使用します。 | トレーニング フレーズの残りのテキストは、アノテーションに対して選択されたトレーニング フレーズパートの意味論的な意味に影響を及ぼす可能性があります。次に例を示します。
たとえば、上記の最初の「7 年」の例のアノテーションには、 @sys.duration システム エンティティを使用しないでください。「7 年」の意味論的な意味は、単純な期間と一致しません。代わりに、@sys.age システム エンティティを使用する必要があります。 |
| カスタム エンティティには、さまざまな例を含める必要があります。 | エンティティとは、アイテムのリストのことです。文法上の形態は機械学習で対処できますが、エンティティには考えられるすべてのアイテムを含める必要があります。また、[Define synonyms] オプションをオンにして、いくつかのバリエーションを含めてください。 |
| ML を無効にするインテントの数を可能な限り少なくする。 | ML が無効なインテントのトレーニング フレーズは、エージェントのトレーニング時には使用されません。ML が無効なインテントのトレーニング フレーズと非常によく似たユーザークエリは、ML が有効な他のインテントがそのユーザークエリとわずかに似ている場合、誤ったインテントに一致することがあります。誤検知の問題がある場合は、ML を無効にする代わりに ML 分類しきい値を増やしてください。 |
| トレーニング データが非常に少ないエージェントに、高い ML 分類しきい値を設定しないようにする。 | しきい値が高く、トレーニング データがそれほど多くない場合は、トレーニング フレーズとほぼ完全に一致するユーザークエリのみがインテント マッチングになります。高いしきい値が必要な場合は、大量のトレーニング データを提供する必要があります。 |
| エージェントにフォールバック インテントを含める。 | フォールバック インテントがないと、一致しないユーザークエリは空のレスポンスになります。 |
| エージェントがネガティブ サンプルを提供するようにする。 | ネガティブ サンプルは、トレーニング フレーズにわずかに似ているユーザークエリが、誤ってインテントに一致することを防止します。 |
| 実質的に何にでも一致するエンティティを定義しない。 | このようなエンティティでは、ML のパフォーマンスと品質が低下します。トレーニング フレーズのほぼすべてが、一致候補として評価されます。代わりに @sys.any の使用を検討してください。同様に、複合エンティティには類義語として単一の @sys.any を含めないでください。 |
| つなぎ言葉や意味のないテキストで構成されているエンティティを定義しない。 | つなぎ言葉や意味のないテキストの例には、「うーん」、「どうでしょう」、「どうか」、「してくれませんか」などがあります。このようなエンティティを使用して変化形に対応しようとしても、ML のパフォーマンスが低下するだけです。Dialogflow は、このような変化形を処理できるようにデータを拡充しています。このようなフレーズは、エンティティではなくトレーニング フレーズに追加してください。 |
| エンティティは、1 つの種類の情報の個別値を把握するためスコープを限定する必要があります。 | エンティティは短く、簡潔性を保持します。エンティティ値が複雑な場合は、インテントのトレーニング フレーズが状況に適しているからである可能性があります。たとえば、「プラン A で国際電話をかけるにはどうすればよいですか」「プラン B での国際データ ローミングを使用」といったエンドユーザーの表現を考えてみましょう。エンティティは、アクション（「国際電話のかけ方」、「国際データ ローミングを使用」）とプラン（「プラン A」、「プラン B」）の両方に作成しないでください。その代わり、トレーニング フレーズやインテント マッチングを使用して、プランを取得するアクションやエンティティを取得します。 |
| トレーニング フレーズではさまざまなテキストにアノテーションを付ける。 | たとえば、トレーニング フレーズで @sys.time システム エンティティと解析される時間値を指定している場合、すべてのトレーニング フレーズに同じ時間を指定しないでください。トレーニング フレーズには、「午前 7 時」、「午後 8 時」「9 時」など、さまざまな時間が含まれている必要があります。 |
| 多数のパラメータが指定されているインテントには、多数のトレーニング フレーズも含める。 | 原則として、トレーニング フレーズの数は（インテントの複雑さに応じて）10～20 個以上とし、さらにパラメータ数の 3 倍以上にする必要があります。 |
| 各パラメータを多数のトレーニング フレーズで使用する。 | 原則として、各パラメータを 5 つ以上のトレーニング フレーズで使用してください。 |
1 つのトレーニング フレーズ内での複数の @sys.any エンティティの使用を避ける。 |
1 つのトレーニング フレーズに、2 つの連続する @sys.any または合計 3 つの @sys.any エンティティを含めないでください。Dialogflow ではこのようなエンティティを区別できない可能性があります。 |
| 異なるインテントで類似するトレーニング フレーズを使用しない。 | 異なるインテントに類似のトレーニング フレーズを含めないでください。このようにすると、Dialogflow がそのようなフレーズの認識方法を学習できなくなります。 |
| 自動スペル修正を有効にする。 | テキスト入力を使用している場合は、自動スペル修正を有効にしてください。 |
| 複合エンティティをネストしない。 | 複合エンティティでは複数レベルのネストを使用しないでください。各ネストレベルの品質が大幅に低下します。 |
| トレーニング フレーズに特殊文字を使用しない。 | トレーニング フレーズに特殊文字（{、_、#、[ など）が含まれている場合、これらの文字は無視されます。絵文字は例外であり、予期されているとおりに機能します。 |
インテントの命名
インテントが多いエージェントの場合は、整理しやすい命名規則にすることをおすすめします。インテント名は句読点で区切るのが一般的で、左から右に向かって具体性が増加します。また、インテントの名前には、会話ターンにおけるエンドユーザーのインテントを反映する必要があります。
有効な命名規則は多数あります。次の例をご覧ください。
- 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
有用なインテントの特長
| ベスト プラクティス | 詳細 |
|---|---|
| エージェントが、コンテキストを補う必要がある質問にも対応できるようにする。 | たとえば、天気予報のリクエストを処理するエージェントに対して「サンフランシスコの天気」と尋ねた場合、「明日はどうですか」など、それに続くリクエストをサポートするコンテキストを確実に追加してください。 |
| エージェントで、「はい」、「いいえ」、「キャンセル」、「次へ」、「戻る」などのフォローアップを使用する。 | 一般的なレスポンスに対応するには、フォローアップ インテントを使用します。フォローアップ インテントを追加するには、インテントにカーソルを合わせて、[Add follow-up] をクリックします。 |
| すべてのインテントに少なくとも 1 つのテキスト レスポンスを設定する。 | レスポンス セクションはインテントのページの下部にあります。バリエーションを追加すると、選択されるレスポンスがシャッフルされ、同じレスポンスが繰り返される頻度が少なくなります。 |
| ユーザーのリクエストに応えるために必要なすべての情報をエージェントで収集する。 | 必要なパラメータを必須パラメータにすることを検討してください。その場合、エージェントは必要な情報を取得するまで、ユーザーに情報の入力を求め続けます。この動作は、スロット充填と呼ばれます。 |
| 注文を確認する場合など、必要に応じてレスポンスで情報を繰り返す。 | ユーザーが注文や情報変更などのリクエストを行った場合、エージェントは確認のために、リクエストされた内容を繰り返す必要があります。こうした確認のためのレスポンスを作成する際は、繰り返す可能性があるエンティティとパラメータの組み合わせをすべて含めるようにしてください。 |
会話の修正
| ベスト プラクティス | 詳細 |
|---|---|
| エージェント用に、会話の各段階で認識できなかった場合に役立つメッセージを用意する。 | たとえば、最初のプロンプトが「何色にしますか」の場合に、ユーザーが「ジャングルのオウム」と返答すると、フォールバック / フォローアップ インテントによって「申し訳ありませんが、どのような色ですか？」などの質問に言い換える必要があります。 |
| エージェントのデフォルトのフォールバック インテントに、カスタマイズされたブランド固有のレスポンスを含める。 | ユーザーがインテントと一致しないことを言った場合、デフォルトのフォールバック インテントが照合されます。ブランドを反映するようにこのフォールバック インテントをカスタマイズするとともに、有効なリクエストを行うようユーザーを導く情報を提供してください。 |
| カスタマイズされているフルフィルメントの場合、エージェント用に、ユーザーが情報を繰り返せるようにするためのインテントを用意する。 | 1 つのインテントで、「もう一度言って」、「繰り返して」、「もう一度再生して」などのリクエストに対処できます。これは、フォローアップ インテントにできます。 |
| ユーザーの成功を手助けし、返答として聞きたいことを正確に伝えるように誘導する | たとえば、選択肢を提供する場合に、「A にしますか？それとも B にしますか？」と質問しないでください。これは、ユーザーが「はい」と返答しかねないためです。代わりに「A と B があります。どちらにしますか？」と質問してください。 |
ペルソナ
| ベスト プラクティス | 詳細 |
|---|---|
| エージェントの返答を、ブランドに合ったスタイルと語調で、エージェント全体で一貫しているようにする。 | ユーザーがエージェントと会話する際、1 人の人物と話しているように感じなければなりません。すべての返答に、エージェントとしての資質と個性が表れるようにしてください。 |
| エージェントでは、文化、性別、信仰、能力、年齢などを慎重に考慮する。 | 固定概念で作成すると、冗談であってもユーザーの反感を買って、ユーザーが二度とエージェントを利用しなくなる可能性があります。 |
音声を考慮して設計する
| ベスト プラクティス | 詳細 |
|---|---|
| グラフィックや、キーボードやマウスでの操作が必要となるコンテンツを避けます。 | ハイパーリンク、テーブル、画像、略語は使用しないでください。ウェブサイトはサイト名で参照できます。選択肢の一覧を表示する場合は、最も一致するものを返し、別の選択肢を聞きたいかどうかをユーザーに確認してください。 |
| 不自然な沈黙が発生しないようにしてください。常に質問で終わるようにしてください。やり取りが継続するように、会話を主導してください。 | |
| わかりやすくコンパクトなダイアログを作成します。 | スクリーンの場合、長いテキストを表示でき、また複数の段落を含めることもできます。スクリーンであれば興味のない箇所はスキップすることができますが、仮想エージェントが長時間話しているのを聞いても、ユーザーは満足できません。 |
| SSML を使用する | SSML を使用して文のイントネーションを構造化および変更し、音声がより自然に聞こえるようにします。 |
音声を考慮した設計について詳しくは、音声エージェントの設計をご覧ください。
ユーザーのプライバシー保護
| ベスト プラクティス | 詳細 |
|---|---|
| GDPR コンプライアンスのために、エージェント設定でデータロギングを無効にします。 | エージェントの設定で、Dialogflow でのやり取りのロギングを無効にできます。ロギングを無効にすると、PII データが Dialogflow に保存されなくなります。またこれは、分析などの特定の機能が使用できないことを意味します。 |
| チャットの会話データを BigQuery に保存して、Regional Storage を制御します。 | Cloud Logging または Dialogflow API を使用して、受信チャットの発話を BigQuery に送信できます。このアプローチを使用すると、データを保存するリージョンを管理できます。さらに、Data Loss Prevention API を使用して機密情報をマスクすることもできます。GCP で AI を利用したカスタマー サービスを構築するためのブループリントをご覧ください |
ナレッジベース コネクタの使用
| ベスト プラクティス | 詳細 |
|---|---|
| 一般公開された FAQ をインポートするときは、有効な HTML5 マークアップを使用してください。 | たとえば、schema.org/Question や schema.org/Answer などの schema.org 表記のある記事要素を使用します。 |
| Google ロボットにより FAQ ウェブサイトがインデックスに登録されていることを確認する | ウェブサイトは Google ロボットを許可する必要があり、Google ウェブマスター ツールを使用して Google 検索エンジンに追加する必要があります。pages.github のようなサイトはクロールできないため機能しません。 |
| 1～200 のよくある質問を使用する | 複数の Q&A ペアが必要です。また、Q&A ペアはナレッジベースあたり 200 以下である必要があります。必要に応じて、複数のナレッジベースを読み込むこともできます。 |
Dialogflow API の実装
| ベスト プラクティス | 詳細 |
|---|---|
| モバイルまたはウェブ アプリケーション用のクライアント コードベースでサービス アカウントの秘密鍵を公開しないでください。 | これは安全とはみなされません。Chrome デベロッパー ツールを使用できる人であれば誰でも、アカウントから鍵を盗み出して、（有料の）API 呼び出しをお客様のアカウント経由で行えます。常に API プロキシ サーバーで Google Cloud 認証を処理するようにすることをおすすめします。これにより、サービス アカウントが公開されなくなり、鍵が安全に保存されます。} |
1 つのエージェントで音声とテキストを考慮して設計する
| ベスト プラクティス | 詳細 |
|---|---|
| デフォルトのプラットフォーム レスポンスで SSML を使用しないでください。 | エージェントが音声とテキストの両方で応答できる場合、テキスト レスポンスには未加工の SSML コードが含まれます。デフォルトのプラットフォーム レスポンスで書式なしテキストを使用し、プラットフォーム固有のレスポンスでは SSML を使用します。または、Webhook を使用して、音声レスポンスが必要な場合にのみ SSML を生成できます。 |
テスト
| ベスト プラクティス | 詳細 |
|---|---|
| アプリ開発に関わっていない人とアプリを徹底的にテストする。 | エージェントをよく知らない人物にアプリを使ってもらうと、会話の流れがどれだけ自然であるかについての見識を得ることができます。正確さ、長い休止、欠落している会話パス、ペース、ぎこちない遷移などに注意してもらいます。 |
| サポート予定のすべてのプラットフォームでアプリをテストする。 | エージェントが 1 つ以上のプラットフォームで利用可能である場合、そのすべてのプラットフォームで高度なメッセージとレスポンスが正常に表示されることを確認してください。 |
エンタープライズ企業のおすすめの方法
- Google Cloud アーキテクチャ フレームワークをご覧ください。