国内利用の Twilio x Alexa まとめ

ども、@kimihom です。

f:id:cevid_cpp:20190516165345j:plain

今日、以下のイベントで本記事のタイトルで発表予定なので、それを記事としてまとめる。

twiliojp-ug.doorkeeper.jp

音声API としての Twilio と Alexa の相性

初めて Alexa と対話した時、「これを Twilio を使ってプログラムできたら面白いだろうな」と感じた。Twilio が電話で革新を開発者に提供したように、Alexa でも同じような展開に心震えたものだった。

しかし、実際に Twilio と Alexa を組み合わせた実装をしてみると、現実はそうはいっていない様子だ。電話そのものの挙動をいじることができた Twilio Programmable Voice に比べ、Alexa そのものをいじることは不可能だった。現時点で私たちが Twilio で Alexa にできるのは、以下のケースに限られる。

Alexa の任意の会話を受けた際に、Twilio REST API を呼び出す (Twilio REST API)
任意のタイミングで Slack や Facebook と同じように Alexa に「通知」を送る (Twilio Notify)
Alexa で受け取った言葉に対して、その言葉は何で、どんな言葉を返すかを決める (Twilio Autopilot)

一番手軽なのは、任意のタイミングで Twilio REST API を送ることだろう。これで、例えば「Alexa、〜に電話をかけて」といえば確かに Twilio を使って電話をかけることができる。しかし、そのあと相手が電話に出た後、Alexa でそのまま通話できるかといえば No だ。相手が出た際に、機械音声を流すなり、もしくは自身の携帯電話に電話をかけるといった操作が必要になる。Alexa 内だけでコミュニケーションが完結しないことになる。

次の Notify は、Facebook や Slack, LINE などメッセンジャーアプリにある「通知」のついでくらいの立ち位置だろう。確かに「Alexa、通知を教えて」と語りかけて、Alexa 上に溜まっている通知を読み上げることが可能だ。しかし、これは Alexa の利用用途のメインではないので、どうしても「ついで」感が拭えない。

そんな中、Twilio が去年ローンチした Twilio Autopilot こそ、Alexa 等のスマートスピーカーに最適化したソリューションであることが伺える。Alexa で受け取ったメッセージに対して最適な返す言葉を生成するための API である。ただしこれだけを読むと、「それって Alexa アプリ開発でやることと同じやん」って思われる方もいるかもしれない。Twilio Autopilot の強みは、一度 Twilio Autopilot で会話ケースを作っておけば、それ以外の会話つまり「電話のIVR, Slack, Google Assistant, FB Messenger etc」にも対応できる対話モデルを構築することができるという点である。私たちが Slack や Google Assistant のそれぞれの API を追わずとも、Twilio がそれに最適化するように追い続けてくれる。私たちは単に Twilio Autopilot の最新を追い続けるだけで良くなるのである。

Twilio Autopilot の考察

はてさて、私は Twilio ユーザーであるに過ぎないので、感じたことを素直に記してみよう。

確かに Twilio Autopilot を使えば、マルチチャネルな対話モデルを簡単に構築することが可能だ。しかし、それは逆をいえば「Alexa にしかできないことに対応できない」ということになる。例えば、Alexa 単体では以下のようなことが実現可能だ。

音楽を再生する
スキル内課金(日本は Coming Soon)
アカウントリンク (OAuth による外部サービスへのログイン)
Alexa に登録されたユーザー情報の取得
Alexa にあるリマインダー、タイマーへのアクセス

これらを Twilio Autopilot から扱う方法は現時点では存在しない。もしかすると今後 Twilio Autopilot が個別の機能への呼び出しを提供する可能性はあるかもしれないが、結局のところこれらを扱うには Alexa や Google Home の仕組みを理解しなければならなくなる。

Autopilot を使う判断に至るには、どれだけ「対話機能をあらゆるチャネルで提供する必要があるか」という点が重要になってくるだろう。例えば、Android と iPhone はほぼ同じくらいに重要で、スマホアプリを作るならどちらも提供しなければならない(だからこそ React Native etc)といった具合だ。その意味でいうと、現時点では Google Home と Amazon Echo は同じくらい重要で、同じように対応する価値が出てくるだろう。今後、これらスマートスピーカーや、電話、チャットなど、自動応答が同じように必要になるケースが増えていけばいくほど、Twilio Autopilot の価値は上がってくる。だが例えば Slack Bot と LINE Bot でそれぞれ共通の仕組みを Autopilot で作れるわけだけども、Slack は仕事用で LINE はプライベートという点を考慮すると一緒に使う機会というのはほとんどない。組み合わせに関してもたくさんあればいいってわけではなくて、両者の相性を考える必要がある。

現時点で、私は Amazon Alexa Skill ネイティブが提供するアカウントリンクによる認証機能と Alexa スキル内課金の観点から、ネイティブの Amazon Alexa Skill をそのまま使う方が良いという判断をした。ネイティブの Alexa スキルを把握しておけば、今後 Twilio Autopilot に移すっていう時でも出力先を知っているので問題が起きづらいという利点もある。

登壇資料

さて、そんな話をさらっとまとめた資料を共有する。

speakerdeck.com

終わりに

GW からひたすら研究を続けた Twilio Autopilot であるが、現時点では Amazon Alexa Skill をネイティブで実装するという結論に至っている。この判断がいつ「古い判断」になるかはわからないので、引き続き Twilio Autopilot に関しては更新情報を追い続けていく予定だ。

AI と対話をする時代。それはもう既に来ているし、今からでも関わることは遅くない。私は電話やビデオ・チャットといったコミュニケーションの根本部分がメインテーマではなるが、その次の視点として対話モデルの研究を続けていく。