こんにちは、サイオステクノロジー技術部 武井です。ここ数日に渡って、de:code 2019の「ほぼ」リアルタイムレポートをお届けしております。
今回はこちらです。
すみません、セッションタイトルのスライドの写真を撮るのを忘れてしまいました。
スピーカーはちょまどこと千代田まどか氏、Google Developers Expertの田中 洋一郎氏でした。
このセッションは以下のような方に向いていると思います。
既存サービスをVUI(Voice User Interface、アレクサのように話しかけることで命令するもの)に置き換えるときの注意点などを知りたい！！
はじめに
本セッションでは、GUIで今まで行われていた会議室予約をVUIを置き換える例をもとに、どのようなところに注意を払うべきかが焦点となっていました。まず一番最初に、最後のスライドをお見せしてしまいます。
勘所は以下の5つになります。
- サーバー分離
- AIアシスタントの仕組み
- VUIの設計方法
- 自然言語処理
- OAuth2によるAccount Linking
ちょっと気になったところをピックアップしてみます。
AIアシスタントの仕組み
今回のデモでは、デバイスはGoogleアシスタントを使っていました。Googleアシスタントであれ、アレクサであれ、AIアシスタントの構成は変わらず、以下のような流れになります
- デバイスからの発話を解釈(Speech to Text)
- Webhookでイベントを発生
- 何らかの処理(ここでAzure Functionsを使います)
- 回答(HTTPレスポンス)を音声に変換(Text to Speech)
2がWebhookであることがポイントです。Webhookなので、HTTPで受けられるものであれば何でも処理が可能です。図にもありますように、Azure FunctionsもしくはAzure WebAppで処理をすることが出来ます。
VUIの設計方法
次にVUIの設計方法です。
上図のように、ユーザーとAIアシスタントの対話をシナリオ化することが重要のようです。GUIでは「ユーザーがボタンを押した」などシステムが解釈するイベントは必ず固定化しています。例えば、HTTPリクエストでメソッドはPostで、Content-Typeはapplication/x-www-form-urlencodedで、ボディはname=hoge&submit=sendで、、、といった感じですよね。GUIではユーザーの意思に対して、HTTPリクエストはいつも固定です。
ただしVUIでは異なります。例えばデバイスに対してユーザーの発話が以下のようになされたとします。
- 「3時からSaturnの会議室の予約を取りたい」
- 「Saturnの会議室を3時から取りたいなー」
- 「3時からSaturnの会議室取ってよ」
これらは、全て「3時からSaturnの会議室の予約をする」というユーザーの意思を表します。でも、HTTPレスポンスは全て異なります。
もちろんこれらのパターンを全て同じ意志であるということをシステムには教え込む必要があり、そのため、先に述べた対話のシナリオが必要となるわけです。これがVUIの難しさなんですね。
OAuth2によるAccount Linking
Azure Functionsを叩くところは、もちろん認証が必要です。Azure Active DicrectoryであればAzure管理ポータルから認証の設定が全て完了するとのことです。このあたり、Azure Bot Serviceと同じですね。
自然言語処理
Azure Bot Serviceと同じように、ここでもLUISが用いられているようです。
まとめ
de:codeのセッションを通して感じたことは、今回のVUIもそうですし、Azure Bot Serviceもそうですし、UIは大きなパラダイムシフトを迎えているということです。そのパラダイムシフトに乗り遅れないためにも、このセッションで紹介された技術は、いち早く正確にキャッチアップすべきと思います。
