前回ご紹介したVoiceflowのDialog Management APIをつかって、LINEとつないでみました。
目次
構成
Voiceflow SDKでLINEとつないだときと基本的に同じです。
ローカルに立てたNode.jsアプリにngrok経由でLINE Messaging APIかつなぎこみます。Herokuあたりを使えばインターネット経由で動かすこともできると思います。
コード
コードは以下で公開しています。
詳細は↑のREADMEを参照してください。あと、LINE Messaging API側の設定はVoiceflow SDKの記事も参考になると思います。
メインのコードだけ抜粋。
- あまりエラー処理とかはちゃんとできてないです。
- LINE Messaging APIの場合は、ユーザごとにuserIdが渡ってくるので、それをState APIのキーにしてます。めっちゃ楽ちんです。
- 逆にキーとなる情報がない場合（例えばTwilioとかだと、userIdに該当するものが渡ってこないので、ユーザの識別が難しい。発信元の電話番号が使えるかなと思ったけど、非通知だったりする場合もあるので難しい・・・）は、何らかの方法で自前でキーを管理する必要があると思いますし、その場合はStateless APIを使って、Stateを自前で管理するのが良いでしょう。
- 会話セッションという点では、ほぼ恒久的に残ってる（つまり会話の途中で時間が経ってもそこから再開する）みたいなので、一定時間内に完了させないといけないトランザクションが必要なケース（ショッピングカートとか）では、最後のタイムスタンプ（fetch stateすればわかる）を見て、会話フローの最初からやり直す（type:launchをなげる）ような処理が必要になると思います。
- Dialog Management APIからはtraceオブジェクトが配列で返ってきます。ここのフォーマットはVoiceflow SDKから変わってるみたい（Audioとかが以前とは違う）で、また、Voice Assistant/Chat Assistantのプロジェクトタイプでも違うみたい。この辺は実際にレスポンスを見たほうがいいと思います。
動作
こんな感じで動きます。
テキストのやり取りはもちろんですが、AudioやVisualでレスポンスが返ってきてるのがわかると思います。
State APIで永続的な情報をVoiceflow側に持たせるとこういうこともできます（2回目以降は名前と年齢を聞いてこない）
その他
Dialog Management APIとはちょっとずれますが、Voice Assistant/Chat Assistantなどのカスタムアシスタント、どうもNLUはMicrosoft LUISを使ってる痛いです。
ビルトインのエンティティタイプ（Alexaでいうスロットタイプのこと）を見てると、それっぽいんですよね。
で、Alexaに比べると種類が少なくて、日本語になると特に少ない。人名などよく使うものがまだ日本語対応されていない（英語と中国語しかない）ので、カスタムでやるしかなく、今回「名前」を受け取りたかったので、テストデータ作成ツールなどを使って、カスタムで5, 600件登録してます。が、それでも認識が悪い。この辺は今後に期待かなと思います。
（Alexaのビルトインスロットのありがたみがよくわかります・・・）
回避策としては以下のようなやり方があるかなーと思います（試してない）
- last_utteranceというユーザの発話・入力をそのまま入れたビルトインの変数があります。スロットに値が入ってない場合はこちらを参照するとよいかも。
- ただし、インテントにマッチしてるかどうかはわからないので、intent_confidenceというインテントへのマッチの信頼度を参考に、一定の信頼度の場合はそれを使う、というような工夫は必要かも
発話・入力の処理が複雑にはなってしまうので、多用はしたくないですね・・・。これについてはそのうちまとめます。
まとめ
次はSlackあたりか、TwiliioでStateless APIを試してみようかなと思います。
