kun432's blog

Alexaなどスマートスピーカーの話題中心に、Voiceflowの日本語情報を発信してます。たまにAWSやkubernetesなど。

〜スマートスピーカーやVoiceflowの記事は右メニューのカテゴリからどうぞ。〜

Voiceflowにおける会話のコンテキストを考える ②コンテキストのスイッチ

f:id:kun432:20200724191613p:plain

Voiceflowにおける会話のコンテキストを考える」シリーズの第2回です。今回は「コンテキストの切り替え」です。

この記事は「Voiceflowにおける会話のコンテキストを考える 」シリーズの第2回の記事です。他の記事は以下にあります。よろしければあわせて読んでみてください。

第1回 第2回(この記事) 第3回 第4回 第5回 第6回

目次

②コンテキストのスイッチ

前回の最後に少し紹介した例を振り返ってみましょう。

いらっしゃいませ。ご注文は何になさいますか?

コーヒーを一つ。

砂糖とミルクはおつけしますか?

あ、そうだ、営業時間は何時まで?

営業時間は9:00〜22:00です。ところで砂糖とミルクはおつけしますか?

お願いします

途中で会話の趣旨が「注文を受け付ける」から「営業時間を聞く」に変わっていますよね。しかもそれが終わったら元の「注文」に戻ってます。このように会話のトピックが切り替わることを「コンテキストのスイッチ」といいます。

そして人間の会話ではこれが自然に行われます。

  • 注文をしているコンテキスト中に、営業時間を聞くという異なるコンテキストの会話が始まったら、自然にその内容にスイッチする。
  • 営業時間のコンテキストで必要な情報を得られたら、注文を受けているというコンテキストが継続していたことを記憶していて、元の会話のコンテキストに戻る。

そして、このとき同時に、人間はコンテキスト間の重み付けを認識しています。切り替わったコンテキストをあくまでも「一時的」なコンテキストとして元のコンテキストに戻るべきなのか、それとも元のコンテキスト自体を捨てて新しい「恒久的」なコンテキストに切り替えてしまうべきなのか、です。

上記のうち、今回のテーマは「一時的」なコンテキストスイッチです。そしてVoiceflowでこれを実現するのが「コマンド」です。

コマンド

「コマンド」って何?という方は多いかと思いますが、実はVoiceflowでスキルを作る場合(特に審査に出す場合)は必ず一度は触れています。これです。

f:id:kun432:20200908225508p:plain

Home Blockの下にある「Help」と「Stop」、これが「コマンド」です。Alexaスキルを審査に出す場合に必ず実装する必要がある「ヘルプ」と「ストップ」のインテントはここにあります。そしてこれらは「コマンド」を使って最初から組み込まれているのですね。

ためしにHelpの方をクリックしてみましょう。

f:id:kun432:20200914200215p:plain

右にメニューが表示されます。これはFlow Blockのメニューと同じですね。"Enter Flow"をクリックしてみてください。

f:id:kun432:20200914200105p:plain

「ヘルプ」のFlowが開きました。メッセージは日本語に直してますが、ほぼデフォルトのものです。「ヘルプ」と言ったら、スキルの説明をして、もとに戻るか?で「はい」「いいえ」を答えるというものです。「いいえ」の場合はExit Block、すなわちスキルが終了します。「はい」の場合にはどうなるでしょうか???

f:id:kun432:20200914211441p:plain

試してみましょう。

f:id:kun432:20200914211411p:plain

コーヒーを注文するコンテキストの会話フローの中でヘルプを2回言っています。そして、「ヘルプ」のやりとりが終わったあと、それぞれ呼び出したところに戻っているのがわかるでしょうか?図にするとこういう感じです。

f:id:kun432:20200914214607p:plain

つまり、現在の会話のメインのコンテキストから、一時的に別のコンテキストに飛んで、そのコンテキストが終わればもとのコンテキストに戻る、ということができます。スキルのメインのトピックとまではいかないけど、聞かれたらいつでも答える必要があって、かつ、メインのコンテキストの進行を邪魔しない、重要で短いコンテキストに飛ぶ場合によいでしょう。「ヘルプ」はこの用途にピッタリ合致しますね。

コマンドを追加する

では、コマンドを追加してみましょう。「営業時間」について答えるコマンドを追加したいと思います。Home Blockのグレーの部分をクリックすると右にメニューが表示されるので、"Add Command"をクリックします。

f:id:kun432:20200914220206p:plain

コマンドを実行するサブFlowと、コマンドのトリガーとなるインテントを設定するメニューが表示されます。順に設定していきましょう。

f:id:kun432:20200914220536p:plain

Flowの名前は "open hours flow" とします。Flow名を入力して"Create"をクリックします。

f:id:kun432:20200914220728p:plain

インテント名は "open_hours_intent" にします。こちらも同じように "Create" します。

f:id:kun432:20200914221046p:plain

インテントのサンプル発話を入力します。こんな感じでよいでしょう。

f:id:kun432:20200914221201p:plain

ではフローを作りましょう。"Enter Flow"をクリックします。

f:id:kun432:20200914221306p:plain

open hours flowの画面が開きました。Speak Blockをつなげて、営業時間を伝えるメッセージを入力します。コマンドで作ったFlowはフローの最後がどこにもつながっていなければ元の場所に戻るようになっていますので、これだけでOKです。(「あえて」終了したい場合に限り、Exit Blockを使うと、もとに戻ることなくスキル自体を終了できます。)

f:id:kun432:20200914221506p:plain

Homeアイコンをクリックして、もとのフローに戻りましょう。

f:id:kun432:20200914221754p:plain

ではアップロードしてテストしてみましょう。

f:id:kun432:20200914222327p:plain

うまくいきました!

でも「いらっしゃいませ」ともう一度言うのが少しおかしいですね。コマンドで元のフローに戻った場合、「直前」のSpeak Block「1つ分」が発話されるようになっています。したがって、以下のように「いらっしゃいませ」と「ご注文は何にしますか?」を別々のSpeak Blockを分けてあげるとうまくいきます。

f:id:kun432:20200914222724p:plain

f:id:kun432:20200914222742p:plain

まとめ

「Voiceflowにおける会話のコンテキスト」シリーズの第2回、コンテキストのスイッチ、特に「一時的」なスイッチについてご紹介しました。次回は「恒久的」なコンテキストのスイッチのやり方をご紹介します。

続きはこちら

Alexa Web API for Gamesの公式サンプルを日本語化して試してみた

f:id:kun432:20200913002638p:plain

Alexa Live 2020でGAが発表された「Alexa Web API for Games」。Webアプリはちょっと私の手に余るかなと思いつつも、少し動きとかを見てみたいなということで、以下にある公式のサンプルを日本語で動くようにしてみました。

日本語化したものはこれです。

動かすまでの手順はREADME.mdに書いてあるのですが、いくつか補足も含めて以下に記載します。

目次

必要なもの

  • AWS IAMアカウント
  • Alexa開発者アカウント
  • aws-cli
  • ask-cli V2

事前準備

AWS IAMアカウントおよびAlexa開発者アカウントはすでにお持ちで、aws-cli・ask-cliのインストール及び初期設定(aws configure/ask configure)もできているという前提です。手元の環境ではこうなってました。

$ aws --version
aws-cli/2.0.34 Python/3.8.5 Darwin/19.6.0 botocore/2.0.0dev38

$ ask --version
2.15.0

次にIAMアカウントに権限を付与します。今回のサンプルの実行に以下のようなAWSリソースが必要となります。

  • Cloudformation
  • IAM
  • AWS Lambda
  • Cloudfront
  • S3

これらのデプロイを行うために、aws-cliで使うIAMアカウントにいくつかの権限が必要となります。一例として、以下のような権限を付与しておけば、とりあえず動きます。 (サンプルスキルの動作が確認できたあとは、必要なければ消しといたほうが良いです)

  • AWSLambdaFullAccess
  • IAMFullAccess
  • AmazonS3FullAccess
  • CloudFrontFullAccess
  • AWSCloudFormationFullAccess

これで準備は完了です。

スキル・AWS環境のセットアップ

ask cliでテンプレートから初期化します。

$ ask new --template-url https://github.com/kun432/skill-sample-nodejs-web-api-my-cactus --template-branch master

--template-branchオプションは、テンプレートレポジトリのブランチを指定できるというものです。ask-cli v2のコマンドリファレンスに載ってないし、本来は不要なはずなのですが、指定しないと以下のようなエラーが出ます。

[Error]: CliError: Error: Command failed: git clone --branch ask-cli-x https://github.com/...

元々のレポジトリ側の構成がask-cli-xを使っていた場合に出る、みたいなのをどっかで見かけましたが、どこかは忘れました。

対話形式で設定していきます。最初にスキルの実行環境のホスト先を聞いてくるので、"AWS with CloudFormation"を選択します。

Please follow the wizard to start your Alexa skill project ->
? Choose a method to host your skill's backend resources:
  Alexa-hosted skills
    Host your skill code by Alexa (free).
❯ AWS with CloudFormation
    Host your skill code with AWS services and provision with AWS CloudFormation (requires AWS account)
  AWS Lambda
    Host your skill code on AWS Lambda (requires AWS account).
  ──────────────
  self-hosted and manage your own hosting

公式のレポジトリでない場合は警告がでて確認を聞いてきますので"y"

[Warn]: CLI is about to download the skill template from unofficial template https://github.com/kun432/skill-sample-nodejs-web-api-my-cactus. Please make sure you understand the source code to best protect yourself from malicious usage.
? Would you like to continue download the skill template?  (y/N) y

スキル名を聞いてきます。このままENTERで良いと思います。

? Please type in your skill name:  (skill-sample-nodejs-web-api-my-cactus)

ローカルに作成されるディレクトリ名を聞いてきます。これもこのままENTER。

? Please type in your folder name for the skill project (alphanumeric):  (skill-sample-nodejs-web-api-my-cactus)

以下のように表示されれば、スキルの初期化が完了してディレクトリが作成されます。

Project for skill "skill-sample-nodejs-web-api-my-cactus" is successfully created at ...

Project initialized with deploy delegate "@ask-cli/cfn-deployer" successfully.

まず、スキルの実行に必要なライブラリをインストールします。作成されたディレクトリに移動します。

$ cd skill-sample-nodejs-web-api-my-cactus

lambdaディレクトリに移動して、npm installします。以下のような感じでエラーが出ていなければオッケーです。

$ cd lambda
$ npm install
npm WARN my-cactus@1.1.0 No repository field.

added 73 packages from 100 contributors and audited 74 packages in 8.427s

3 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

では、デプロイしましょう。ひとつ上のディレクトリに戻ってask deployします。

$ cd ..
$ ask deploy
==================== Deploy Skill Metadata ====================
Skill package deployed successfully.
Skill ID: amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

==================== Build Skill Code ====================
npm WARN my-cactus@1.1.0 No repository field.

audited 74 packages in 0.971s

3 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Skill code built successfully.
Code for region default built to /...(snip).../skill-sample-nodejs-web-api-my-cactus/.ask/lambda/build.zip successfully with build flow nodejs-npm.

==================== Deploy Skill Infrastructure ====================
  ✔ Deploy Alexa skill infrastructure for region "default"
  The api endpoints of skill.json have been updated from the skill infrastructure deploy results.
Skill infrastructures deployed successfully through @ask-cli/cfn-deployer.

==================== Enable Skill ====================
Skill is enabled successfully.

最初にAlexa側にスキルが作成されて、スキルのコードがLambdaにアップロードできるようにパッケージ化されます。ここでもnpm installしているみたないので最初似実施したnpm installは不要かもですね。その後、AWS側に各種リソースが作成されて、エラーが出なければOKです。

Webアプリケーションのデプロイ

次にWebアプリケーションのデプロイを行います。まず、AWSマネジメントコンソールにログインして、S3の管理画面を開きます。

f:id:kun432:20200912223945p:plain

以下のようにバケットが3つ作成されているかと思いますので、"webappbucket"と書かれているパブリックなバケットをクリックします。

f:id:kun432:20200912224304p:plain

このバケット名をコピーしておきます。

f:id:kun432:20200912224941p:plain

ターミナルに戻って、先程のバケット名をMY_CACTUS_S3という環境変数にセットします。

$ export MY_CACTUS_S3="ask-skill-sample-nodejs-web-api-my-s3webappbucket-XXXXXXXXXXXX"

webappディレクトリに移動します。

$ cd webapp

Webアプリケーションのビルドに必要なパッケージをインストールします。

$ npm install

> fsevents@1.2.13 install /...(snip).../skill-sample-nodejs-web-api-my-cactus/webapp/node_modules/fsevents
> node install.js

  SOLINK_MODULE(target) Release/.node
  CXX(target) Release/obj.target/fse/fsevents.o
  SOLINK_MODULE(target) Release/fse.node
added 397 packages from 231 contributors and audited 397 packages in 21.474s

3 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Webアプリケーションをビルドします。

$ npm run build

> cactuswebsite@1.0.0 build /...(snip).../skill-sample-nodejs-web-api-my-cactus/webapp
> webpack --config webpack.config.js

Hash: a34925b9d7e130ffda77
Version: webpack 4.43.0
Time: 1003ms
Built at: 2020-09-12 11:04:54 PM
  Asset      Size  Chunks             Chunk Names
main.js  2.37 MiB    main  [emitted]  main
Entrypoint main = main.js
[./node_modules/moment/locale sync recursive ^\.\/.*$] ./node_modules/moment/locale sync ^\.\/.*$ 3.16 KiB {main} [optional] [built]
[./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 497 bytes {main} [built]
[./src/blinds.js] 3.38 KiB {main} [built]
[./src/cactus.js] 4.61 KiB {main} [built]
[./src/guiManager.js] 5.27 KiB {main} [built]
[./src/index.js] 18.9 KiB {main} [built]
[./src/messageSender.js] 2.46 KiB {main} [built]
[./src/mockStartupData.json] 824 bytes {main} [built]
[./src/pail.js] 2.26 KiB {main} [built]
[./src/screenShake.js] 1.64 KiB {main} [built]
[./src/selector.js] 1.67 KiB {main} [built]
[./src/spider.js] 2.49 KiB {main} [built]
    + 140 hidden modules

そしてWebアプリをS3にデプロイします。

$ npm run uploadS3

これで完了です!

スキルの使い方

どんなスキルかは動かしてみてのお楽しみです。3Dとかになっていてなかなか面白いですよ。

なお、動作にはEcho Showが必要です。開発者コンソールはもちろん、FireタブレットやFire TV Stickでも動かないようなのでご注意ください。

以下のような発話があります。どんな発話があるかはskill-package/interactionModels/custom/ja-JP.jsonをご覧ください。

起動

サボテンシミュレーションを開いて

水やり

水やりをして

ブラインドの上げ下げ

ブラインドを上げて

ブラインドを下げて

実績(バッジ)

実績を見せて

スキル及びAWSリソースの削除

Alexa開発者コンソールからスキルを削除します。

f:id:kun432:20200912235913p:plain

AWSマネジメントコンソールからリソースを削除していきます。まず、3つあるS3バケットのうち、S3UserDataBucketとS3WebAppBucketの「中身」を削除します。

f:id:kun432:20200912235427p:plain

f:id:kun432:20200912235716p:plain

※S3UserDataBucketも同様に中身を削除してください。

最後にCloudformationからスタックを削除します。

f:id:kun432:20200913002158p:plain

IAMアカウントの権限なども必要なければもとに戻しておいたほうがいいでしょう。

まとめ

ということで、Alexa Web API for Gamesのサンプルを日本語化しつつ試してみました。Webアプリの中身とかは全然追えてないのでまた覗いてみたいと思いますが、ちょっと今回のは3Dとかになっていて難しそうですねー。Webとの連携を理解したいなと思うのでもう少しシンプルなサンプルがほしいなと思いました。

ご興味ある方はお試しいただければと思います。

Voiceflowにおける会話のコンテキストを考える ①ダイアログコンテキスト

f:id:kun432:20200724191613p:plain

以前、シチュエーショナルデザインについて、Voiceflowで実装する場合について過去5回にわたって説明しました。

シチュエーショナルデザインとは少し絡むところで、会話の「コンテキスト」ということについて、Voiceflow公式ブログに面白いエントリがあったので複数回に分けてご紹介します。

この記事は「Voiceflowにおける会話のコンテキストを考える 」シリーズの第1回の記事です。他の記事は以下にあります。よろしければあわせて読んでみてください。

第1回(この記事) 第2回 第3回 第4回 第5回 第6回

目次

コンテキストとは?

「コンテキスト」を辞書で引くと「文脈」とあります。それでは「文脈」とはどういう意味でしょうか?

  1. 文章の流れの中にある意味内容のつながりぐあい。多くは、文と文の論理的関係、語と語の意味的関連の中にある。文章の筋道。文の脈絡。コンテクスト。「文脈で語の意味も変わる」「文脈をたどる」
  2. 一般に、物事の筋道。また、物事の背景。「政治改革の文脈でながめると」

「意味のつながり」とか「物事の筋道」とありますね。これを会話において考えると、以下のような感じかと思います。

何か飲む?

うん、コーヒーがいいな

オッケー、砂糖とミルクはどうする?

両方ほしいな

了解、じゃあ砂糖とミルクをいれたコーヒーを用意するね

大きく意味だと「どういう飲み物が欲しいか?」を確認するという文脈であり、細かく分けると前半部分は「飲み物が欲しいか?欲しくないか?」、後半部分は「(コーヒーの場合)ミルク・砂糖はどうするか?」という2つの文脈があることになります。これを2つに分けてそれぞれ単独で見た場合、

  • 飲み物は必要かどうか?
    • 飲み物の名前だけで完結する?
    • コーヒーの場合は砂糖とかミルクの確認も必要じゃない?
  • 砂糖とミルクは必要かどうか?
    • これってコーヒーの前提だよね?
    • オレンジジュースの場合には聞く必要ないよね?

となり、片方だけだとそれぞれ情報が足りないのですね。つまり、個々のコンテキストがあって、さらにそれを包括するもっと大きなコンテキストがあるという形です。このような複数のコンテキストからなる大きなコンテキストの会話を別の言い方でいうと「マルチターン会話」といいます。

VUI設計においては、このコンテキストも含めて会話のフローを考えるわけですが、必ずしも常にきれいなフローになるわけではないのが人間の会話です。それをどこまでうまく作り込んで人間の会話に近づけるか?がより自然な会話を成立させるためのキモになるわけですが、これがとても大変なわけですね。Alexa Live 2020の「Build Conversational Interfaces Faster with Alexa Conversations」で出てきたスライドを一部紹介しましょう。

サンプルになっているのは、犬がほしいのでどういう犬種がいいかをおすすめするスキルですね。最終的なオススメ犬種を判断するために、特徴となるキーワードを2つあげてもらって、あと元気かおとなしいか、というのを確認しています。

f:id:kun432:20200724222024p:plain

これを個々のコンテキスト、というかそれぞれの会話ターンに分けています。最初が会話のトリガーとなる「おすすめ犬種を教えて」を受け取って、次に「特徴を2つ」、最後に「元気かおとなしいか」という感じですね。

f:id:kun432:20200724222037p:plain

これを図で表すと、このようにリニア(直線的)な会話フローになっていることがわかりますね。

f:id:kun432:20200724222054p:plain

で、聞いてる方からするとリニアなのですが、実際に裏側のスキルでは、ユーザの発話に応じていろいろ分岐したりするわけですね。そしてこのときに、「会話の状態」を管理しています。例えば、

  • 最初に特徴を2つ述べるところで、「元気」「おとなしい」のどちらかを言う。2つ目の質問の回答はもうわかっている。
  • 最初の会話の回答内容=状態を管理して、次の質問をどうするか?を決める。
  • もしかすると、別の質問が来るかもしれないし、もう追加質問自体が不要になるかもしれない。

みたいな感じです。で、こういうパターンをいろいろ作っていくと、こうなるわけです。

f:id:kun432:20200724222107p:plain

複雑で大変ですね。さらに、ユーザの回答はいろいろです。以下にあるように、想定以上/以下の回答が返ってきたり、途中で気持ちが変わったりするわけで、更に大変です。

f:id:kun432:20200725011849p:plain

そこで出てくるのが「Alexa Conversations」になるわけですが・・・

f:id:kun432:20200725012322p:plain

これはもう少し先の話になると思います(少なくとも日本ではまだ利用できない)ので、現時点でどういうふうにコンテキストに沿った会話を実現できるかを考えていきたいと思います。そこで、冒頭で紹介した公式ブログの話に戻ります。

この記事の中では、6つのパターンを例に、Voiceflowでコンテキストに沿った会話を実現するやり方を書いてあって、とても参考になるとともにちょっと思いつかなかったやり方もありました。ということで、複数回に分けてそれぞれ順に見ていきましょう。

1. ダイアログコンテキスト

ダイアログコンテキストは、単純に言ってしまうと、会話のフローに沿ったコンテキストです。会話のフローに沿って、前後のやり取りが関係する行われることが前提になっています。例で見てみましょう。

f:id:kun432:20200728005537p:plain

ちなみに実行例を先にお見せします。

コーヒーを頼んだ場合。

f:id:kun432:20200728010355p:plain

紅茶の場合。

f:id:kun432:20200728010406p:plain

オレンジジュースの場合。

f:id:kun432:20200728010420p:plain

では、フローを順に見ていきます。

起動して注文を聞くところはよいですね。そのあとorder_intentで飲み物名をdrink_nameというスロットで取ります。

f:id:kun432:20200728010724p:plain

order_intentとdrink_nameはChoice Blockでこんなになってます。普通ですね。

f:id:kun432:20200728011125p:plain

f:id:kun432:20200728011134p:plain

受け取ったdrink_nameの値を使ってCondition Blockで分岐させます。コーヒー、紅茶、それ以外、ですね。

f:id:kun432:20200728011311p:plain

それぞれの分岐を見てみましょう。まずコーヒーの分岐。コーヒーの場合は砂糖とミルクを入れるか?をビルトインインテントであるYes/Noで受け取ってそれぞれで回答します。

f:id:kun432:20200728011356p:plain

次に紅茶の分岐。こちらは、コーヒーのように、砂糖とミルクではなくて、レモンと砂糖を確認するようにしています。同じくビルトインインテントであるYes/Noで分岐させます。

f:id:kun432:20200728011555p:plain

最後にその他の場合。これはもう追加で入れるものは確認しない、という感じです。

f:id:kun432:20200728011616p:plain

大体流れがわかったところで、これをコンテキストの観点で細かく分類していきます。

f:id:kun432:20200728012829p:plain

全体としては、どんな飲み物が欲しいか?を聞く大きなコンテキストとなっていて、飲み物の追加情報が必要な場合に細かいコンテキストが存在するという感じです。

    1. 飲み物の「名前」を聞くコンテキスト
  • 2-1. 飲み物が「コーヒー」の場合に、追加で必要なものを確認するコンテキスト
  • 2-2.飲み物が「紅茶」の場合に、 追加で必要なものを確認するコンテキスト
  • 2-3. 飲み物が「それ以外」の場合のコンテキスト

コンテキストには連続性があります。例えば、1の飲み物の「名前」と2-1の「コーヒー」の場合に追加物を確認するコンテキストは連続することで意味をなします。コーヒーにレモンを入れることは一般的にないでしょうし、コーヒーで追加するものを確認しなければ常にブラックコーヒーしか出せないことになります。Voiceflowではコンテキストの流れを引き継ぐ場合には線でつなぐことで実現しています。当たり前と思うかもしれませんが、実はこれが重要です。

それを理解するには以下のところを見るとよいでしょう。

f:id:kun432:20200728013542p:plain

コーヒー・紅茶にそれぞれ追加するものを確認するとき、ユーザの回答は両方とも「はい」「いいえ」になります。つまり、この「はい」と「いいえ」だけを切り出すと、最初にどの飲み物を言うか?というコンテキストがなければどちらに対する回答なのかを区別できません。

このように、前後の会話のやりとりの流れにより成り立つコンテキストを「ダイアログコンテキスト」と言っています。Voiceflowを使っていると当たり前のことなので、特に疑問を感じないですよね。

実はこれがVoiceflowの最も優れたところで、Alexaスキルをコードで書く(ask-sdkを使う)場合、このコンテキストの維持は開発者が実装しなければなりません。

ただし人間の会話においてコンテキストは突然変わることがあります。例えばこんな感じです。

一時的にコンテキストが変わって戻る

いらっしゃいませ。ご注文は何になさいますか?

コーヒーを一つ。

砂糖とミルクはおつけしますか?

あ、ところで営業時間は何時まで?

営業時間は9:00〜22:00です。ところで砂糖とミルクはおつけしますか?

お願いします

複数のコンテキストが1回で終わる

いらっしゃいませ。ご注文は何になさいますか?

コーヒーを一つ。砂糖とミルクもつけて。

コーヒーに砂糖とミルクをおつけいたしますね。おまたせしました。

ダイアログコンテキストはリニアな流れに依存するという欠点があります。つまり決まりきった会話の流れ以外には対応できないということですが、Voiceflowには、これを回避してより柔軟な会話のコンテキストを実現できるような機能があります。次回以降でそれをご紹介していきたいと思います。

まとめ

「Voiceflowにおける会話のコンテキスト」シリーズの第1回はダイアログコンテキストをご紹介しました。次回以降でコンテキストのスイッチを行う機能をご紹介していきます。

続きはこちら