このドキュメントでは、Dialogflow CX の基本的な使用方法について説明します。最も重要なコンセプトの概要を説明します。
エージェント
Dialogflow CX エージェントは、エンドユーザーとの同時会話を処理する仮想エージェントです。これは、人間の言語のニュアンスを理解する自然言語理解モジュールです。Dialogflow CX は会話中のエンドユーザーのテキストまたは音声を、アプリやサービスが理解できる構造化データに変換します。Dialogflow CX エージェントは、システムに必要な種類の会話が処理されるように設計および構築されます。
Dialogflow CX エージェントは、コールセンターの担当者と似ています。予想される会話のシナリオに対処するためにトレーニングを行ってください。ただし、トレーニングを過度に行う必要はありません。
フロー
多くの場合、複雑なダイアログでは複数の会話トピックが関与します。たとえば、ピザの配達エージェントの場合、料理の注文、顧客情報、確認という別個のトピックが考えられます。各トピックでは、エージェントがエンドユーザーから関連する情報を取得するため、複数の会話ターンを実行する必要があります。
フローは、これらのトピックと、関連する会話パスを定義するために使用されます。すべてのエージェントには、デフォルトの開始フローと呼ばれるフローが 1 つあります。単純なエージェントであれば、このフローのみで十分でしょう。より複雑なエージェントでは追加のフローが必要になる場合があります。さまざまな開発チームのメンバーに、これらのフローの構築と保守を担当させることができます。たとえば、ピザの配達エージェントのフローは次のようになります。
ページ
Dialogflow CX の会話（セッション）は、ステートマシンとして記述し、可視化できます。セッションの状態はページで表されます。
フローごとに多数のページを定義します。結合されたページでは、フローが設計されたトピックに関する完全な会話を処理できます。どの時点でも、正確に 1 つのページが現在のページであり、また現在のページがアクティブで、そのページに関連付けられたフローもアクティブであるとみなされます。すべてのフローには特別なスタートページがあります。フローが最初にアクティブになると、スタートページが現在のページになります。会話の各ターンでは、現在のページがそのまま表示されるか、別のページに遷移します。
各ページを、そのページが表す会話の状態に関連するエンドユーザーから情報を収集するように構成します。たとえば、次の図にピザ宅配業者の Food Order フローのページ（青で表示）作成します。図の Start ノードは Food Order フローの開始ページを表します。フローが完了すると、Confirmation フローに遷移します。
エンティティ タイプ
エンティティ タイプを使用して、エンドユーザー入力からデータを抽出する方法を制御します。Dialogflow CX には、多数の一般的なデータタイプに対応する事前定義のシステム エンティティが用意されています。たとえば、日付、時刻、色、メールアドレスなどを照合するシステム エンティティがあります。カスタムデータを一致させる独自のカスタム エンティティを作成することもできます。たとえば、食料品店エージェントで購入可能な野菜の種類に一致する野菜エンティティを定義できます。
パラメータ
パラメータは、セッション中にエンドユーザーが指定した値を取得して参照するために使用されます。各パラメータには名前とエンティティ タイプがあります。未加工のエンドユーザー入力とは異なり、パラメータは、ロジックの実行やレスポンスの生成に簡単に使用できる構造化データです。フォーム
ページごとにフォームを定義できます。これは、ページのエンドユーザーから収集する必要があるパラメータのリストです。エージェントは、必要なすべてのフォーム パラメータ（ページ パラメータとも呼ばれます）を収集するまで、複数の会話ターンでエンドユーザーとやり取りします。エージェントは、これらのパラメータを、ページで定義された順序で収集します。必要なフォーム パラメータごとに、エージェントがエンドユーザーからの情報をリクエストするために使用するプロンプトも表示します。このプロセスをフォーム入力と呼びます。
たとえば、Collect Customer Info ページのエンドユーザーの名前と電話番号を収集するフォームを作成できます。
インテント
インテントによっては、1 回の会話ターンにおけるエンドユーザーの意図（含意）を分類します。
インテントには以下のデータが含まれます。
| 用語 | 定義 |
|---|---|
| 表示名 | コンソールに表示されるインテントの名前。 |
| ラベル | インテントを分類するためのラベル。例: 主なインテント。 |
| トレーニング フレーズ | トレーニング フレーズは、エンドユーザーの発話に含まれる可能性があるフレーズのサンプルであり、エンドユーザー入力と呼ばれます。エンドユーザー入力がこれらのフレーズのいずれかと似ている場合、Dialogflow CX はこれをインテントにマッチングします。Dialogflow CX に組み込まれている機械学習は他の類似のフレーズまで拡大して解釈するため、すべての例を定義する必要はありません。 |
| パラメータ | トレーニング フレーズを定義してパラメータを使用し、エンドユーザー入力の特定部分から値を抽出する。 |
| DTMF パターン | テレフォニー統合用の DTMF をご覧ください。 |
Webhook
Webhook は、ビジネス ロジックのホストや、他のサービスの呼び出しを行うサービスです。Webhook では、セッション中に Dialogflow の自然言語処理で抽出されたデータを使用することで、動的レスポンスの生成、収集したデータの検証、バックエンドでのアクションのトリガーが可能になります。Webhook は、標準 Webhook またはフレキシブル Webhook のいずれかになります。標準 Webhook では、リクエスト フィールドとレスポンス フィールドは Dialogflow によって定義されます。フレキシブル Webhook では、リクエスト フィールドとレスポンス フィールドを自分で定義します。
フルフィルメント
エージェントの会話のターンでは、エージェントはエンドユーザーに対し、質問への回答、情報に対するクエリ、セッションの終了のいずれかで応答する必要があります。また、動的レスポンスの生成や、ターンのアクションを実行するには、エージェントによるサービスへの問い合わせが必要な場合があります。フルフィルメントは、このすべてを行うために使用されます。
フルフィルメントには次のいずれかを含めることができます。
- 静的レスポンス メッセージ。
- 動的レスポンスやアクションの実行のための Webhook 呼び出し。
- パラメータ値を設定またはオーバーライドするパラメータのプリセット。
エージェントのターンの間に、複数のフルフィルメントを呼び出して、それぞれがレスポンス メッセージを生成することが可能です（生成が必要な場合もあります）。Dialogflow CX は、こうしたレスポンスをレスポンス キューに保持します。エージェントのターンが終了すると、Dialogflow CX は順序付けされたレスポンスをエンドユーザーに送信します。
状態ハンドラ
状態ハンドラは単にハンドラとも呼ばれ、エンドユーザーへのレスポンスを作成する、または現在のページを移行することで、会話を制御するために使用されます。会話ターンごとにハンドラが評価され、セッションに影響を与える可能性があります。 ハンドラには、次の 3 種類の一般的なデータがあります。| 用語 | 定義 |
|---|---|
| ハンドラの要件 | ハンドラがセッションに影響を与えるためには、満たす必要がある要件が存在します。ハンドラは、要件を満たし、なんらかの方法でセッションに影響を与えると呼び出されたとみなされます。 |
| ハンドラのフルフィルメント | ハンドラが呼び出されると、オプションのフルフィルメントを使用してエンドユーザーのレスポンスが作成されます。これらのレスポンスは、静的エージェント データで定義するか、Webhook サービスから動的に取得します。 |
| ハンドラの遷移ターゲット | ハンドラが呼び出された場合は、オプションの遷移ターゲットを使用して現在のページが変更されます。 次のページは、フローのスタートページ、または現在アクティブなフロー内のページのみです。 |
ハンドラの要件が異なる次の 2 種類の状態ハンドラがあります。
| 用語 | 定義 |
|---|---|
| ルート | ルートは、エンドユーザーの入力がセッション ステータスのインテントまたは一部の条件に一致した場合に呼び出されます。インテント要件のあるルートは、インテント ルートとも呼ばれます。条件のみを要件とするルートは条件ルートとも呼ばれます。 |
| イベント ハンドラ | イベント ハンドラは、イベントが呼び出された場合に呼び出されます。 予期しないエンドユーザー入力を受け取ったとき、または Webhook エラーが発生したときに、一部の組み込みイベントがトリガーされます。会話の外で何かが発生したときに呼び出すカスタム イベントを定義することもできます。 |
状態ハンドラの処理は、次の 3 つのステップで行われます。
| 用語 | 定義 |
|---|---|
| 1. 範囲 | セッションに影響を与えるには、ハンドラがスコープ内に存在する必要があります。スコープは、ハンドラがフロー、ページ、またはフォーム パラメータに適用されるかどうか、さらに関連付けられたフローがアクティブであるかどうか、関連付けられたページがアクティブであるかどうか、またはエージェントが現在関連付けられたフォーム パラメータを入力しようとしているかどうかによって決まります。 |
| 2. 評価 | スコープ内の各ハンドラは、順に評価されます。ハンドラの要件を満たしている場合は、評価に合格します。 |
| 3. 呼び出し | ハンドラはスコープ内にあり評価に合格すると、呼び出されます。関連付けられたフルフィルメントが呼び出され、関連付けられた遷移ターゲットがセッションに適用されます。 |
リージョン指定と位置情報の設定
エージェントを作成するときは、エージェントのロケーションとしてリージョンを指定する必要があります。エージェントに送信されたリクエストは、このリージョンの Google サービスによって処理され、Dialogflow CX によって保存データは地理的地域または場所に物理的に格納されます。最高のパフォーマンスを得るには、サービスとエンドユーザーに近いリージョンを選択する必要があります。
エージェントの作成後に、エージェントのロケーションを変更することはできません。エージェントのロケーションを変更するには、ロケーションが異なる新しいエージェントに対してエクスポートと復元を行う必要があります。
各ロケーションには、プロジェクト全体に適用される設定が関連付けられています。ほとんどの場合、これらの位置情報の設定は編集する必要がないため、デフォルト設定をそのまま使用できます。システムに顧客管理の暗号鍵が必要な場合（多くの場合、政府機関や規制対象の業界で必要です）、位置情報の設定で詳細をご覧ください。
Console
Dialogflow CX では、Dialogflow CX Console（ドキュメントに移動、コンソールを開く）と呼ばれるウェブユーザー インターフェースがあります。このコンソールを使用して、エージェントを作成、ビルド、およびテストします。各フローは会話のステートマシン図としてグラフ化されるため、複雑なエージェントの設計と理解が容易になります。
Dialogflow CX Console は Google Cloud Console とは異なります（ドキュメントに移動、コンソールを開く）。Dialogflow CX Console は Dialogflow CX エージェントの管理に使用され、Google Cloud Console は Google Cloud 固有の Dialogflow CX 設定（課金など）およびその他の Google Cloud リソースの管理に使用されます。
ほとんどの場合、Dialogflow CX Consoleを使用してエージェントをビルドする必要がありますが、Dialogflow API を使用して高度なシナリオ用のエージェントをビルドすることもできます。
統合
Dialogflow CX は、他の会話プラットフォームとの組み込み統合を実現しています。これらの統合は、エンドユーザーに対するユーザー インターフェースを備えており、API を呼び出します。ユーザーが行う必要がある作業は、エージェントを構築し、必要に応じて Webhook サービスを実装することのみです。各統合によってプラットフォーム固有の方法でインタラクションが処理されるため、詳細については特定の統合に関するドキュメントをご覧ください。
インタラクション
会話ターンごとに、操作が行われます。インタラクション中に、エンドユーザーが Dialogflow CX に入力を送信し、Dialogflow CX がレスポンスを送信します。システムを実装して操作を処理する際には、API を使用する方法と統合を使用する方法の 2 つの選択肢が存在します。
API の使用時には、システム側で以下の処理を行う必要があります。
- エージェントをビルドする。
- エンドユーザー向けのユーザー インターフェースを用意する。
- 会話ターンごとに Dialogflow API を呼び出して、エンドユーザー入力を API に送信します。
- エージェントのレスポンスが純粋に静的な（一般的でない）場合を除き、webhook サービスをホストして、Webhook 対応フルフィルメントを処理する必要があります。
統合を使用する場合、システムでは次の処理のみを行う必要があります。
- エージェントをビルドする。
- 必要に応じて Webhook サービスを実装します。
次の図は、セッションの 1 回の対話ターンで実行される手順を示しています。
- エンドユーザーが、エンドユーザー入力と呼ばれる何かしらの情報を入力または発声します。
- ユーザー インターフェースまたは統合システムが入力を受信し、インテント検出リクエストで Dialogflow API に転送します。
- Dialogflow API がインテント検出リクエストを受信します。入力とインテントまたはフォーム パラメータを照合し、必要に応じてパラメータを設定し、セッションの状態を更新します。Webhook 対応フルフィルメントを呼び出す必要がある場合、Webhook サービスに Webhook リクエストを送信します。それ以外の場合は、手順 6 に進みます。
- Webhook サービスが Webhook リクエストを受け取ります。サービスは、外部 API の呼び出し、データベースのクエリや更新など、必要なアクションを実行します。
- Webhook サービスがレスポンスをビルドし、Webhook レスポンスを Dialogflow CX に返します。
- Dialogflow CX がインテント検出レスポンスを作成します。Webhook が呼び出された場合、Webhook レスポンスで提供されたレスポンスが使用されます。Webhook が呼び出されなかった場合は、エージェントで定義された静的レスポンスが使用されます。Dialogflow CX は、ユーザー インターフェースまたは統合システムにインテント検出レスポンスを送信します。
- ユーザー インターフェースまたは統合システムがインテント検出レスポンスを受信し、テキストまたは音声のレスポンスをエンドユーザーに転送します。
- エンドユーザーがレスポンスを確認または聞き取ります。