Dialogflow CX の基本

このドキュメントでは、Dialogflow CX の基本的な使用方法について説明します。最も重要なコンセプトの概要を説明します。

エージェント

Dialogflow CX エージェントは、エンドユーザーとの会話を処理する仮想エージェントです。これは、人間の言語のニュアンスを理解する自然言語理解モジュールです。Dialogflow は、会話中のエンドユーザーのテキストまたは音声をアプリやサービスが理解できる構造化データに変換します。Dialogflow エージェントは、システムに必要な種類の会話が処理されるように設計および構築されます。

Dialogflow エージェントは、人間のコールセンター エージェントに似ています。 予想される会話のシナリオに対処するためにトレーニングを行ってください。ただし、トレーニングを過度に行う必要はありません。

フロー

多くの場合、複雑なダイアログでは複数の会話トピックが関与します。たとえば、ピザの配達エージェントの場合、料理の注文、顧客情報、確認という別個のトピックが考えられます。各トピックでは、エージェントがエンドユーザーから関連する情報を取得するため、複数の会話ターンを実行する必要があります。

フローは、これらのトピックと、関連する会話パスを定義するために使用されます。すべてのエージェントには、デフォルトの開始フローと呼ばれるフローが 1 つあります。単純なエージェントであれば、このフローのみで十分でしょう。より複雑なエージェントでは追加のフローが必要になる場合があります。さまざまな開発チームのメンバーに、これらのフローの構築と保守を担当させることができます。たとえば、ピザの配達エージェントのフローは次のようになります。

マルチフロー図の例

Dialogflow CX のフローは、Dialogflow ES メガ エージェントのサブエージェントと同様の目的で機能します。フローを使用すると会話をより適切に制御できます。追加のコストは発生しません。

ページ

Dialogflow CX の会話(セッション)は、ステートマシンとして記述し、可視化できます。CX セッションの状態はページで表されます。

フローごとに多数のページを定義します。結合されたページでは、フローが設計されたトピックに関する完全な会話を処理できます。どの時点でも、正確に 1 つのページが現在のページであり、また現在のページがアクティブで、そのページに関連付けられたフローもアクティブであるとみなされます。すべてのフローには特別なスタートページがあります。フローが最初にアクティブになると、スタートページが現在のページになります。会話の各ターンでは、現在のページがそのまま表示されるか、別のページに遷移します。

各ページを、そのページが表す会話の状態に関連するエンドユーザーから情報を収集するように構成します。たとえば、次の図にピザ宅配業者の Food Order フローのページ(青で表示)作成します。図の Start ノードは Food Order フローの開始ページを表します。フローが完了すると、Confirmation フローに遷移します。

マルチフロー図の例

エンティティ型

エンティティ タイプを使用して、エンドユーザー入力からデータを抽出する方法を制御します。CX エンティティ タイプは、ES エンティティ タイプとよく似ています。

Dialogflow では、多数の一般的なタイプのデータに対応する事前定義のシステム エンティティが用意されています。たとえば、日付、時刻、色、メールアドレスなどを照合するシステム エンティティがあります。カスタムデータを一致させる独自のカスタム エンティティを作成することもできます。たとえば、食料品店エージェントで購入可能な野菜の種類に一致する野菜エンティティを定義できます。

パラメータ

パラメータは、セッション中にエンドユーザーが指定した値を取得して参照するために使用されます。各パラメータには名前とエンティティ タイプがあります。未加工のエンドユーザー入力とは異なり、パラメータは、ロジックの実行やレスポンスの生成に簡単に使用できる構造化データです。

CX パラメータは、ES パラメータと似ていますが、ユーティリティとスコープが拡張され、パラメータを参照する構文が異なります。

フォーム

ページごとにフォームを定義できます。これは、ページのエンドユーザーから収集する必要があるパラメータのリストです。エージェントは、必要なすべてのフォーム パラメータ(ページ パラメータとも呼ばれます)を収集するまで、複数の会話ターンでエンドユーザーとやり取りします。フォーム パラメータごとに、エージェントがエンドユーザーからの情報をリクエストするために使用するプロンプトも表示します。このプロセスをフォーム入力と呼びます。

たとえば、Collect Customer Info ページのエンドユーザーの名前と電話番号を収集するフォームを作成できます。

CX フォームの入力は、ES スロットの入力に似ています。

インテント

インテントによっては、1 回の会話ターンにおけるエンドユーザーの意図(含意)を分類します。 ES インテントと比較すると、CX インテントは簡素化され、より再利用が可能なリソースになりました。

インテントには以下のデータが含まれます。

用語 定義
トレーニング フレーズ トレーニング フレーズは、エンドユーザーの発話に含まれる可能性があるフレーズのサンプルであり、エンドユーザー入力と呼ばれます。エンドユーザー入力がこれらのフレーズのいずれかと似ている場合、Dialogflow によりインテントと照合されます。考えられるすべてのサンプルを定義する必要はありません。Dialogflow の組み込み機械学習機能によって類似するフレーズが追加され、リストが拡張されます。
パラメータ トレーニング フレーズを定義してパラメータを使用し、エンドユーザー入力の特定部分から値を抽出する。

Webhook

Webhook は、ビジネス ロジックをホストするサービスです。Webhook では、セッション中に Dialogflow の自然言語処理で抽出されたデータを使用することで、動的レスポンスの生成、収集したデータの検証、バックエンドでのアクションのトリガーが可能になります。

CX Webhook は ES Webhook に似ていますが、CX 機能をサポートできるようにリクエストとレスポンスのフィールドが変更されています。

フルフィルメント

エージェントの会話のターンでは、エージェントはエンドユーザーに対し、質問への回答、情報に対するクエリ、セッションの終了のいずれかで応答する必要があります。また、動的レスポンスの生成や、ターンのアクションを実行するには、エージェントによるサービスへの問い合わせが必要な場合があります。フィルメントは、このすべてを行うために使用されます。

フルフィルメントには次のいずれかを含めることができます。

  • 静的レスポンス メッセージ。
  • 動的レスポンスやアクションの実行のための Webhook 呼び出し。
  • パラメータ値を設定またはオーバーライドするパラメータのプリセット。

エージェントのターンの間に、複数のフルフィルメントを呼び出して、それぞれがレスポンス メッセージを生成することが可能です(生成が必要な場合もあります)。Dialogflow は、こうしたレスポンスをレスポンス キューに保持します。エージェントのターンが終了すると、Dialogflow は順序付けされたレスポンスをエンドユーザーに送信します。

ES フルフィルメントは、Webhook サービスの接続に限定されます。フルフィルメントのスコープが CX 向けに拡張され、すべてのタイプのプロンプトとレスポンスが対象になりました。

状態ハンドラ

状態ハンドラは単にハンドラとも呼ばれ、エンドユーザーへのレスポンスを作成する、または現在のページを移行することで、会話を制御するために使用されます。会話ターンごとにハンドラが評価され、セッションに影響を与える可能性があります。 ハンドラには、次の 3 種類の一般的なデータがあります。

用語 定義
ハンドラの要件 ハンドラがセッションに影響を与えるためには、満たす必要がある要件が存在します。ハンドラは、要件を満たし、なんらかの方法でセッションに影響を与えると呼び出されたとみなされます
ハンドラのフルフィルメント ハンドラが呼び出されると、オプションのフルフィルメントを使用してエンドユーザーのレスポンスが作成されます。これらのレスポンスは、静的エージェント データで定義するか、Webhook サービスから動的に取得します。
ハンドラの遷移ターゲット ハンドラが呼び出された場合は、オプションの遷移ターゲットを使用して現在のページが変更されます。 次のページは、フローのスタートページ、または現在アクティブなフロー内のページのみです。

ハンドラの要件が異なる次の 2 種類の状態ハンドラがあります。

用語 定義
ルート ルートは、エンドユーザーの入力がセッション ステータスのインテントまたは一部の条件に一致した場合に呼び出されます。インテント要件のあるルートは、インテント ルートとも呼ばれます。条件のみを要件とするルートは条件ルートとも呼ばれます。
イベント ハンドラ イベント ハンドラは、イベントが呼び出された場合に呼び出されます。 予期しないエンドユーザー入力を受け取ったとき、または Webhook エラーが発生したときに、一部の組み込みイベントがトリガーされます。会話の外で何かが発生したときに呼び出すカスタム イベントを定義することもできます。

状態ハンドラの処理は、次の 3 つのステップで行われます。

用語 定義
1. 範囲 セッションに影響を与えるには、ハンドラがスコープ内に存在する必要があります。スコープは、ハンドラがフロー、ページ、またはフォーム パラメータに適用されるかどうか、さらに関連付けられたフローがアクティブであるかどうか、関連付けられたページがアクティブであるかどうか、またはエージェントが現在関連付けられたフォーム パラメータを入力しようとしているかどうかによって決まります。
2. 評価 スコープ内の各ハンドラは、順に評価されます。ハンドラの要件を満たしている場合は、評価に合格します。
3. 発信 ハンドラはスコープ内にあり評価に合格すると、呼び出されます。関連付けられたフルフィルメントが呼び出され、関連付けられた遷移ターゲットがセッションに適用されます。

リージョン指定と位置情報の設定

エージェントを作成するときは、エージェントのロケーションとしてリージョンを指定する必要があります。エージェントに送信されたリクエストは、このリージョンの Google サービスによって処理されます。最高のパフォーマンスを得るには、サービスとエンドユーザーに近いリージョンを選択する必要があります。

エージェントの作成後に、エージェントのロケーションを変更することはできません。エージェントのロケーションを変更するには、ロケーションが異なる新しいエージェントに対してエクスポートと復元を行う必要があります。

各ロケーションには、プロジェクト全体に適用される設定が関連付けられています。ほとんどの場合、これらの位置情報の設定は編集する必要がないため、デフォルト設定をそのまま使用できます。システムが、データ所在地に関する保証または顧客管理の暗号鍵(多くの場合、政府の機関や規制対象業界で必要)を必要とする場合は、位置情報の設定で詳細をご確認ください。

Console

Dialogflow では、Dialogflow CX Console(ドキュメントに移動コンソールを開く)と呼ばれるウェブユーザー インターフェースがあります。このコンソールを使用して、CX エージェントを作成、ビルド、およびテストします。CX Console は ES Console と同様の目的で使用できますが、CX Console のユーザー インターフェースの方がずっと視覚的です。各フローは会話のステートマシン図としてグラフ化されるため、複雑なエージェントの設計と理解が容易になります。

Dialogflow CX Console は Google Cloud Platform(GCP)Console とは異なります(ドキュメントに移動コンソールを開く)。Dialogflow CX Console は Dialogflow CX エージェントの管理に使用され、GCP Console は GCP 固有の Dialogflow CX 設定(課金など)およびその他の GCP リソースの管理に使用されます。

ほとんどの場合、Dialogflow CX Consoleを使用してエージェントをビルドする必要がありますが、Dialogflow CX API を使用して高度なシナリオ用のエージェントを作成することもできます。

統合

Dialogflow CX は現在、他の会話プラットフォームとの組み込み統合を実現しています。これらの統合は、エンドユーザーに対するユーザー インターフェースを備えており、Dialogflow API を呼び出します。ユーザーが行う必要がある作業は、エージェントを構築し、必要に応じて Webhook サービスを実装することのみです。各統合によってプラットフォーム固有の方法でインタラクションが処理されるため、詳細については特定の統合に関するドキュメントをご覧ください。

Interactions

会話ターンごとに、操作が行われます。操作中に、エンドユーザーが Dialogflow に入力を送信し、Dialogflow がレスポンスを送信します。システムを実装して操作を処理する際には、API を使用する方法と統合を使用する方法の 2 つの選択肢が存在します。

API の使用時には、システム側で以下の処理を行う必要があります。

  • エージェントをビルドする。
  • エンドユーザー向けのユーザー インターフェースを用意する。
  • 会話ターンごとに Dialogflow API を呼び出して、エンドユーザー入力を API に送信します。
  • エージェントのレスポンスが純粋に静的な(一般的でない)場合を除き、webhook サービスをホストして、Webhook 対応フルフィルメントを処理する必要があります。

統合を使用する場合、システムでは次の処理のみを行う必要があります。

  • エージェントをビルドする。
  • 必要に応じて Webhook サービスを実装します。

次の図は、セッションの 1 回の対話ターンで実行される手順を示しています。

API フロー図。

  1. エンドユーザーが、エンドユーザー入力と呼ばれる何かしらの情報を入力または発声します。
  2. ユーザー インターフェースまたは統合システムが入力を受信し、インテント検出リクエストで Dialogflow API に転送します。
  3. Dialogflow API がインテント検出リクエストを受信します。入力とインテントまたはフォーム パラメータを照合し、必要に応じてパラメータを設定し、セッションの状態を更新します。Webhook 対応フルフィルメントを呼び出す必要がある場合、Webhook サービスに Webhook リクエストを送信します。それ以外の場合は、手順 6 に進みます。
  4. Webhook サービスが Webhook リクエストを受け取ります。サービスは、外部 API の呼び出し、データベースのクエリや更新など、必要なアクションを実行します。
  5. Webhook サービスがレスポンスを作成し、Webhook レスポンスを Dialogflow に返します。
  6. Dialogflow がインテント検出レスポンスを作成します。Webhook が呼び出された場合、Webhook レスポンスで提供されたレスポンスが使用されます。Webhook が呼び出されなかった場合は、エージェントで定義された静的レスポンスが使用されます。Dialogflow は、ユーザー インターフェースまたは統合システムにインテント検出レスポンスを送信します。
  7. ユーザー インターフェースまたは統合システムがインテント検出レスポンスを受信し、テキストまたは音声のレスポンスをエンドユーザーに転送します。
  8. エンドユーザーがレスポンスを確認または聞き取ります。