kun432's blog

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

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

Voiceflow TIPS #2 変数と永続セッション

Voiceflow Alexa

※2019/8/3追記
この記事には少し誤りがあります。以下の記事で訂正含めて記載していますのでそちらをご覧ください。

本記事については一部訂正してますが、誤った過程も含めて必要かなと思いますので、このままにしておきます。
※追記終わり

TIPS第二弾、今回は少し基本的なところで、Voiceflowの変数と永続セッションについてまとめます。ここ少しクセがあって、特に永続セッションでユーザごとに値持たせておいて次のセッションにも引き継ぎたい、みたいな時にやや混乱するかなと思いますので整理します。

サンプルとしてこういうスキルを作ってみます。

1回目

アレクサ、カウントアップサンプルを開いて

カウントアップサンプルメモです。はじめてのご利用ありがとうございます。あなたのお名前を教えてください。

太郎

わかりました、太郎さんですね、覚えておきますね。

2回目

アレクサ、カウントアップサンプルを開いて

カウントアップサンプルです。太郎さん、こんにちは。2回めのご利用ありがとうございます。

フローはこんな感じになります。

f:id:kun432:20190707090907p:plain

では順番に見ていきます、

変数の設定

まず、最初に変数を設定します。上のスキルの中では、1回目でユーザの名前を聞いて、2回目はそれを覚えています。これのための変数 userNameを用意しておきます。

f:id:kun432:20190707092736p:plain

① はじめてのセッションかどうかを判断するIFブロック

Voiceflowではビルトインされている変数sessionsがあり、これがユーザの利用回数を保持しています。したがって、最初の1回目は必ず「1」になりますので、これをIFブロックで判断すれば、はじめての利用か？2回目以降の利用か？が判断できます。

f:id:kun432:20190707093013p:plain

これで、1回目のセッションは1のパスへ、それ以外、つまり2回目以降はElseのパスに流れます。

② はじめての利用の場合にユーザに名前の発話を促すSpeakブロック

スキル起動後にAlexaが話す部分、こっちははじめての場合になりますので、名前を言ってもらうように促します。

f:id:kun432:20190707093224p:plain

③ ユーザの名前を取得するCaptureブロック

f:id:kun432:20190707150101p:plain

ユーザの発話を受けて変数に入れます。ユーザの発話をまるっと取得して変数に入れる場合はCaptureブロックを使います。ここでは、ユーザの名前をスロットタイプAMAZON.FirstNameで取得して、userNameに入れてます。

ホントはInteractionブロックを使って、きちんとサンプル発話を受け取ってその中のスロットを変数に入れるほうがいいと思いますが、今回はCaptureブロックを使いました。Captureブロックはスロットに入る部分の発話を取るだけのブロックで、凝ったことができない代わりにシンプルに書けるブロックです。メリット・デメリットあるので、それはまた別の機会に・・・）

④ ユーザの名前を保持したことを伝えて終了するブロック

f:id:kun432:20190707152834p:plain

ここがはじめてのアクセスの場合の最後にブロックになります。③で聞いた名前を話しているだけですね。

⑤ 2回め以降の処理

f:id:kun432:20190707153511p:plain

①でsessionsを確認して、初回起動でない場合のフローがこちらになります。起動回数と、初回で取得したユーザの名前を発話します。

お気づきになりましたか？sessionsはもともとビルトインで組み込まれているのでそういうものだ、と思ってもらって良いですが、userName、特に何もしていないのに永続セッションになっているのがわかりますでしょうか？

感のいい人ならわかると思いますが、そう、

Voiceflowではすべての変数が永続扱いになります。

※2019/8/3追記
上記の記載は誤りです。プロジェクト変数として作成した場合には永続扱いになります。永続扱いにしたくない場合にはフロー変数を作成する必要があります。
※追記終わり

ここ、一般的な変数の考え方だと非常にハマるポイントですね。メリット・デメリットを整理してみると、こんな感じかと思います。

  • メリット
    • ユーザごとの情報をもたせたいならば単に変数作ればいいだけ。
    • DynamoDBとかGoogleスプレッドシートとかみたいな、永続ストレージみたいなものは意識しなくてもよい。
  • デメリット
    • 逆に言うと、きちんと初期化等を意識しておかないと、前のセッションの情報が残ってしまって、意図しない動きになる可能性がある。
    • 意識しなくても使える＝逆に意識したくても中身を見れないので、例えば、集計かけたい、とか統計情報取りたい、とかはできない。
    • 変数が多くなりがちになり、数が増えると見通しが悪くなる。

※2019/8/3追記
上記のうち、「初期化等を意識」というのは、プロジェクト変数として作成した場合です。フロー変数の場合はセッションごとに初期化されます。
※追記終わり

このあたりは、作るスキルの規模だったり複雑性だったりデータどれだけ使うか？とかにもよると思うので、ユースケースに合わせて考えていただければと思います。

ちなみに、ガリガリに外出しして管理してみたというのを以下のエントリでまとめてますので、やろうと思えばここまでできるよ、ということで、ご参考になればと思います。