コンテンツに移動
デベロッパー

Dialogflow CX でサブフローを使用する方法

2022年1月17日
Google Cloud Japan Team

※この投稿は米国時間 2022 年 1 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

ソフトウェア開発のベスト プラクティスの一つは、よく使用するコードをリファクタリングしてモジュール化し、それをあらゆるアプリケーションで使用することです。Dialogflow CX の主な機能の一つは、複数のチームで複雑なエージェントの作成を行えるようにすることです。それには、単一のエージェントだけでなくあらゆるエージェントで、よく使用する機能をさまざまなフローで再利用できることが必要です。

このブログ投稿では、Dialogflow CX のエージェントの設計時にサブフローを使用する方法を見ていきます。サブフローとは、1 つまたは複数のフローで利用するよく使われる機能のようなものと考えてください。

サブフローを使用したエージェントの例

ここでは、ダウンロード可能な既成のエージェントを使用して説明します。こちらの手順に沿って、エージェント プロジェクトとしてサンプル エージェントを復元してください。エージェントを復元すると、以下のサンプルフローを確認できるはずです。
https://storage.googleapis.com/gweb-cloudblog-publish/images/Agent-DefaultFlow.max-1100x1100.png

このサンプル エージェントにはデフォルトのフローが設定されており、現時点では次の 2 種類の問い合わせに対応しています。

  • 営業時間に関する情報の取得

  • お得情報のお知らせへの登録

Dialogflow CX コンソールのエージェントのテスト機能を使って、以下のフレーズを試してみることができます。

  • 営業時間を教えてください。(Store Hours(店舗の営業時間)ページ)

  • いま利用できるお得情報はありますか。(Signup for Deals(お得情報のお知らせへの登録)ページ)

サブフローについて理解する

このブログ投稿で着目するのは、ユーザーが自分のメールアドレスにお得情報が届くように登録できる、Signup for Deals ページです。このサンプルには、Signup for Deals ページからのルートの 1 つによって起動される、Collect User Information(ユーザー情報の収集)サブフローがあることがわかります。以下に示す、このサブフローについて見ていきます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Agent-Subflow.max-600x600.png

このサブフローは、ユーザーからの 3 種類の入力(パラメータ)をキャプチャします。

  • First Name(名)

  • Last Name(姓)

  • Email Address(メールアドレス)

このことは、以下に示す Collect User Information ページとパラメータ設定からもわかります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Subflow-Collect-User-Information-Page-Sett.max-1000x1000.png

これに加え、パラメータ(いずれも必須)をキャプチャすると実行される、このページからのルート設定があります。ルートが実行されると、personal-details-collected のパラメータが “DONE” に設定され、このフローが終了します。この設定を以下に示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Subflow-ExitRoute.max-1000x1000.png

このサブフローは、このエージェントの他のシナリオや他のプロジェクトでも必要となるであろう使用頻度の高い機能と考えることができます。こうした使用頻度の高いパラメータを、ユーザーからキャプチャする必要が生じるたびにフローを作り直して記述することは望ましくありません。

そこで、まずパラメータをキャプチャする Collect User Information フローを呼び出して、そのキャプチャしたパラメータを親フローであるデフォルトの Start フローが読み込むようにします。

親フローについて理解する

サブフローについて説明済みなので、親フローについては理解しやすいはずです。先述のセクションでは、パラメータ personal-details-collected を “DONE” に設定しました。つまりこれは、サブフローに移行する前は、Signup for Deals ページでこのパラメータが PENDING(保留)に設定されているということです。この設定を以下に示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/DefaultFlow-SignupForDeals-Page.max-2200x2200.png

サブフローから戻ると、このページには以下に示す 2 つのルートがあります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/DefaultFlow-SignupForDeals-Routes.max-2200x2200.png

そのうち 1 つは、パラメータが収集されていれば Display Information(情報表示)ページに進みます。もう一方は、同じサブフロー Collect User Information フローにもう一度ルートします。この例では、ユーザーのパラメータすべてを入力必須としているため、後者のフローが起動するのはあまり望ましくありません。しかし、入力を必須にしておらず親フローで確認する必要があった場合、パラメータが提供されていればサブフローに戻る方がユーザー エクスペリエンスとして適切だと考えられます。

最後は、セッションで取得したパラメータ値をキャプチャして表示する Display Information ページです。この時点ではこれはむしろ、サブフローが統合され、適切に機能していることを把握するための確認ページといえます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/DefaultFlow-DisplayInformation-Page.max-1700x1700.png

エージェントをテストする

以下に示すエージェントのテスト実行の例では、Capture User Information サブフローを起動するルートを試しています。サブフローでキャプチャされたパラメータは、親フロー内のセッション パラメータとして読み戻されて表示されます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Agent-SampleTestRun.max-800x800.png

テスト実行中は、以下に示す [Parameters] 欄を確認するようにしてください。パラメータが正しく入力されているか確認することで、開発プロセスにおいてすべてが想定どおりに動作しているかを確認できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Agent-SampleTestRun-ParameterValues.max-800x800.png

サブフローを再利用することは、よく使われる機能を把握してあらゆるエージェントで再利用できるようにするための重要なポイントの一つです。これにより、複雑なエージェントの開発や、そのエージェントのさまざまなフローの作成を複数のチームが担当する場合の作業が容易になります。

ご質問やご意見がございましたら、Twitter で @iRomin までお気軽にお寄せください。

関連情報


- デベロッパー アドボケイト Romin Irani
投稿先