Alexaの返事に“人間らしさ”を加えるには？
台本スキル開発のポイントを解説

Alexaのスキルを作る「その前」に

岡本秀高氏：「Storylineではじめる モック駆動Alexa Skill開発」ということで、やっていこうと思います。自己紹介ですが、岡本です。

今日の話ですが、音声のアプリケーションを作る際に意識することであったり、Skills Kitでできることや、ワークフローなどを全般的に話していこうと思います。

Alexaのイベントに参加して、作り方を覚えると、こういう気持ちになって帰るんですね。「よっしゃ、スキルを作ろう！」。なにか作って、一発当てたい気持ちがあるし、僕もそう思っていたんですけど、その前に考えたほうがいいなと思うことがありました。

「そのスキルを作ろうという気持ちは（下記の）どちらか？」ということなんですよね。Qiitaなどで上げたい系のものなのか、それとも会社で提案して、プロダクションでやりたいのか、サービスとしてローンチしたいのか。そのどちらなのかは、いったん整理したほうがいいかなと思っています。

というのも、なんでもいいから作ってみたいんだったら、僕が今しゃべっている間にパソコンを開いて、Storylineで触っていたら、それで公開できちゃうんですよね。もしくはフラッシュブリーフィングスキルがRSSを食わせるものがあるので、それであればStorylineで画面操作をする必要もなく、作れるんじゃないかと思いました。

なので、作るだけだったらすぐできます。ただ、それをプロダクションとかサービスでやるときに、そのノリでやっていいのか、いきなりコードを書いていいのかということです。

Webサイトやサービスを作るときは、いきなりコードを書く前に何をしていますか？　（会場の参加者を見て）なんか目が合わないですね（笑）。

普通、Webサイトを作るときは、ユーザーストーリーやデザインを作ると思うのですが、音声のアプリケーションも音声のデザインが必要です。

音声UI設計のチェックリスト

音声デザインすることとは何か。ここに関しても、Alexaに関してはAmazonが「音声デザインガイド」というサイトをオープンしているんですね。ここにチェックリストであったり、「こういうことを考えてください」などが全部書かれています。

チェックリストでは、「スキルでユーザーがなにができるかを明確に書いていますか？」や「スキルを家で呼び出すときに簡単に呼び出せるか？」や「自然な会話になるようになっているか？」などですね。

もしくは、ユーザーが想定外の発話ですね。ありうることは、家で使っている場合に、自分がしゃべっている間にほかの人が話しかけて混ざってしまう。混声してしまって、Alexaが何を言っているかがわからなくなっちゃうときに、エラーを出さないように持っていけるかなども考えると書かれています。

この中のチェックリストで一番大事なのは、先ほどの話にもあったんですが、「ユーザーが実際に使っているところを1回でも観察しましたか？」というところです。

ここの中の紹介文だけピックアップすると、公開前にそのスキルに慣れていないユーザー、そのため、開発に関わっていないユーザー、その人に使ってもらって、どう使うか、もしくはどこでつまづいているかなどを絶対確認するとチェックリストに書かれています。

そうすることでなにが起きるかというと、会話が思っていたようにスムーズにいく部分と、逆に思っていたようにいかない、「あっ、こういう言い方するんだ」みたいなことなどが発見されるんですね。

Alexaのイベントで登壇されている方が言われるんですけど、会議室で作ったあとに絶対に家で使ってから、次の日もう1回ブラッシュアップする。そういうところを考えるのがすごく大事になっています。

こういうことをやっていこうと思うと、なにが大事になってくるか。やはり始めるのは早くやったほうがいいですね。大事なのはその次で、どれだけ早く失敗できるか、どれだけ早く会社にダメージを与えない、自分がしんどい思いをしないで失敗できるかが大事だと思います。

「音声をどう変換するか」が最優先

Alexa Skillで作る部分は基本的な範囲としては2つあります。Alexa Skills Kitというところが音声とテキスト、テキストと音声の変換をやってくれます。その裏側で、LambdaやStoryline、フラッシュブリーフィングのRSSなどがテキストを受け取って、テキストを返すデータ処理をやっています。

僕らがやるときにどちらを先に作るか？　そこに関しては、今のお話を踏まえて、僕が考えているのは、先に音声をどう変換するか、スライドの上の部分をやるべきだと思っています。

上の部分、Alexa Skills Kitがやっているところは、今僕がしゃべっているような内容をどうテキストに変換するかを定義する場所なので、ここの上の部分の定義が「やはり違ったわ」といって変えちゃうと、その裏側の実装も全部変わっちゃうんですね。ですのので、このSkills Kitの音声の変換の部分をどれだけ早く作って、どれだけ早くfixさせてから実装に入れるかが大事になってきます。

そんななかで、その対話モデルを作っていくところによりフォーカスできるなと思っているサービスとしては、先ほどご紹介のあったStorylineですね。

なにがいいかというと、やはり両方ないと動かせないのでこの下側の部分を作らないといけないんですが、下の部分をコードを書いて実装をやりだすと、それはそれで時間かかってしまうし、Alexaのものすごく長いJSONが200行ぐらいあるんですけど、あれをどう処理するかを覚えなきゃいけなくなってくるので大変だと思います。

そのため、StorylineというGUIで作れるものがあるので、それを使ってモックの部分を裏側に作ってしまうことが大事かなと思います。

先ほどもご紹介ありましたが、ドラッグ＆ドロップでこういうかたちで、どの部分でなにを言ったら、Alexaがなにを言ってユーザーがなにを言ったらどこにいくかをフローチャート的に作れるので、社内でフローチャートなどを作ったあとにそれをそのまま書き起こす、モデルに落とすことも簡単にできるかなと思います。

Storylineを使うべき理由をもう1回整理すると、上の部分の対話のモデル、Skills Kitで作ったものが、ユーザーが「これ使いにくいわ」と言われたらもうそもそも使われなくて、その裏側の処理も呼ばれなくなってしまいます。

そういうことを考えると、実際の利用シーンでその対話モデルが合っているか、今後の裏側の処理じゃなくて対話モデルがしっかりできているかというのをどれだけ早くテストして調整していくかというところが大事です。

なぜStorylineを使うべきか

例えばそもそもその利用シーンで音声アプリを使うかですよね。会議室の中などでみんなで話して「こういうアプリあったらいいよね」という。

「ゴミの回収日について聞けるようなものがあったらいいよね」と思いつく。「何日の月曜日のゴミはなんですか？」などの質問をいろいろ考えてやってみても、実際に使おうと思うと、だいたい月曜日ではないんですよね。「明日や今日のゴミは何ですか」ということしか聞きたくないですし、その今日のゴミも回収時間のあとにそれを教えられてもぜんぜん意味がないんですよね。そういうところを使ってみないとわからないですよね。

そのあたりを考えていくと、音声なので機械に対してモデルを作ると言ってますけども、もしそのAlexaに何かやってもらおうと思ったときに、例えば家族や会社の同僚などにお願いする場合にどんな会話になるかを考えていく必要があります。

あとは返事の部分ですよね。そこも朝急いでいるときなどにすごく長ったらしい説明で、「わかりました」と言って、それで返事をくれればいいものを「今なにをしてますか？」「どういう経緯ですか？」など長々説明されてもイライラするというところもあります。

僕、今日大阪・神戸のほうから来ているんですけど、方言や略称で意味合いが変わってくるものもあります。例えばターゲットが実は大阪なのに、東京の話ばかりでやっていて、実は大阪でこういう言い回しがあったから、そこがカバーできてなかった、みたいなことが起きるかもしれない。そういうケースもあるんじゃないかと思います。

あとは「ユニバーサルスタジオジャパン」や「東京ディズニーランド」をフルでしっかり言うかというところですよね。もっと略称で言うこともありますし、新しいサービスなどだったら、略称もいろいろあると思います。そういうところもカバーできるのか。そういうところをやる上で観察が本当に大事になってきます。

LambdaやAlexaのSDKの活用方法

逆にLambdaやAlexaのSDK、JavaScriptやAPIなど、これなしでStorylineで作っちゃうだけでいいのかというと、そんなこともないです。

GUIで先ほどの画面を定期的に保守・アップデートしていくところに関してやっていくのがOKと、開発チームが言ったら別なんですが、正直、対話モデルだけ作って、テストケースをそこで作る。

Alexaの開発画面のテストコンソールでJSONのInputとOutputが見れるので、それをテストコードにして実装組むほうが、開発チームとしてもコードで、もしくはCI/CDを乗せたりできますし、実際に企画する側のほうでGUIでいろいろ作って、それを渡すワークフローになるので、両方使っていくことが大事かなと思います。新しい機能をStorylineでモックを作って、SDKやLambdaで実装していくイメージですね。

このあたりのもう少し具体的な話をしていくと、まず音声デザインガイドに従って台本や対話モデルを作る。Storylineでその台本や対話のモデルを、適当にポチポチ入力していったら、モデルが作れます。

例えば何時の新幹線など、その台本のそのまま変数の部分などを変えたい気持ちはあると思うんですが、そこを抑えて、「9時の新幹線」と台本に書いてあったら、9時の新幹線しか受け入れないモックだというので、割り切ってスキルにまず起こしていくのが大事かなと思います。

それをやったあとに、このあとコマンドを紹介しますが、「ask-cli」というAlexa Skill向けのCLIツールがあるので、対話モデルのコード管理などされたい方は、ask-cliでこのStorylineが作ったモデルを全部引っこ抜いて、それをコードに改めて起こしていくやり方があるかなと思います。

Storylineでの台本のスキル化

ここからはもう開発チームのやりとりですね。Storylineでできたモックを実際にLambdaで実装していって置き換えていく。もしくはHerokuなどで自分でAPI作って置き換えていくやり方があると思いますが、そこは作られる方の好きにやっていけばいいと思います。

台本のスキル化ですが、StorylineはGoogleアカウントさえあれば作れます。ここで「Upload to Alexa」というボタンを押したら、Amazonアカウントとさえ連携ができていればそれでデプロイができます。

音声再生やラジオストリーム、もしくはストーリーテリング的なものであれば、Blueprintがあるので、そこを使うやり方もあるかなと思います。

「ストーリーへようこそ！」とサンプルが全部あってダイアログ形式になっています。それを「Upload to Alexa」というボタンを押すとAlexaの画面にデプロイできるので、これをテストするとOKということです。

先ほどもありましたけど、台本をそのままスキルに起こすところで、変数の裏側の処理も確認したい気持ちがやはり湧くんですけど、ここでテストしたいのは、そもそもの台本が音声でやりとりしている状況に合っているかというところだけなので、処理についてはいったん諦める、割り切るところが大事かなと思います。

ask-cliを使ったモデルのコード化

テックな話になりますけど、ask-cliですね。npm製なんですが、Alexa Skillの管理に関してCLIで全部できるようになっています。

ひな型の作成は、「ask new」というコマンドで、Alexa Skillの対話モデルやLambdaのソースコードなどで作れます。「ask api get-skill」で、Storylineが作ったスキルの説明文や公開情報などをエクスポートできます。

「api get-model」というコマンドを使えば、言語別にStorylineで作られた対話モデルを長いJSON形式に吐き出してくれるので、それを使ってあとはモックをコードにしたので、あとはコードで管理していくこともできます。

この中で実際に開発ダッシュボードで作ったものをCLIからコード管理するやり方についてもブログで書いているものあるので、そのあたりも、ハッシュタグで流しますので、そこを見ていただければと思います。

Lambda／外部APIのつけかえに関しても、Alexaのコンソールでエンドポイントを変えるだけですね。HTTPSのエンドポイント「getstoryline.com」というAPIがデフォルトで設定されているので、そこをLambdaのリソースネームに変えたり、自分の外部APIに変えていただければ、もうStorylineのAPIから自分のAPIにすぐ変更できます。

1個だけ注意なのは、外部APIの場合、HTTPSが必須なので自分でAPIを作られる場合は、証明書の設定は忘れないようにしてください。

テストについても、Alexaの開発コンソールのテストのタグで実際に文字を打って、会話のモデルをテストすると、左側にAlexaがLambdaであったり、Storylineを投げている値のJSON、右側はそのStorylineがどういうJSONを返してくるかを出してくれるので、ここでテストして開発チームに「こういうJSON投げたら、こういうJSONを返すような実装を作ってください」と伝えれば、それで一通りいけるかなと思います。

というところで、Storylineでモックデプロイして、Skillコンソールでテストして、テストしたInput/Outputを控えておけば、開発チームはAlexaのインテントなどのモデルかわからなくても、「とりあえず、このJSONを受けて、このJSONを返す実装を作ればいいんだ」と伝えられるかなと思います。テストコードにもしておけば、よりCIなどでチェックもできると思いますと。

Alexaとの自然な会話を目指す

AlexaはAmazonが公式でブログをやっています。その中で日本語がだいたい1〜2割、ドイツ語が1割、英語が残り7割みたいな比率ですが、スキルの開発に関するTipsがいろいろ載っているので参考になります。

つい最近、子ども向けスキルが日本でも公開できるようになりました。なので、お子さん向けにスキルを作られたい方は、今まではレビューが弾かれていたんですけど、今は申請したら通ります。

あとは、ビジネスの話ですが、まだアメリカだけですが、スキル内課金ですね。月額何円というサブスクリプションモデルと、1回何円という買い切りモデル。両方とも今アメリカではパブリックになっています。

そういった課金のモデル、Alexaの中でビジネスをやっていくところも、まだ日本に来ていないだけで、そういうビジネスのかたちはこれから間違いなく来るだろうなとは思っています。

そこで紹介されているTipsについても、例えば「複数の質問がある場合はDialogという機能を使いましょう」であったり、効果音を、先ほどもエコちっちで出てきましたけど、「効果音をいろいろ使っていきましょう」「返事を人間っぽくしましょう」というものが載っています。

新幹線予約をする場合の変数

少しずつ紹介していくと、完全に僕の仕様なんですけど、「今晩出発の新幹線の新大阪行きののぞみの窓際の指定席を探して」と。これをAlexaでやりたい場合、変数がこれだけあるんですね。

インテントとスロットを扱うにあたって、なんとなくわかるかなと思うんですけど、この全部を入れているインテントがもしなかった場合に、どういう質問をしてどういう判定をする、値を引き継ぐかなどを考え出すとけっこう頭が痛いんですね。

ただ、ここに関してもスロットの数がたくさんになりますが、「ダイアログを編集」というアクションがあって、ここを使うことによってダイアログごと編集できます。time（出発時間）をユーザーが言ってなかった場合に、ここで入力して「出発時間を教えてください」と言うと、Alexa側で、スキル側が実装しなくても、足りなかったら追加の質問をしてくれて、情報を集めて、全部が揃ったら処理を走らせる仕組みとして、Dialogという機能が用意されています。

ここに1個だけ裏側でも実装しなきゃいけないものがあって、ダイアログの状態が始まった状態か、継続中か、全部揃ったかと（質問がある）。そこについては実装をやらないといけないですが、自力でインテントとスロットで全部がんばるよりは、だいぶ簡単にできます。

なので、複数の変数を、会話の中でやりたいとなってきた場合は、Dialog機能を使いましょう。

あとは効果音です。これもmp3のファイルをアップロードしてそれを読ませればいいんですが、自分で用意するのは大変なのですが、Alexaチームが公式にSound Libraryを出しています。こんな感じでSSMLでS3に上げられているファイルを読み込ませると、Alexaチームが用意している効果音を導入することができます。

説明文は基本英語なのですが、かなり種類があります。Animal、Cartoon、Office、Transportation、SF的なものもありますし、例えば拍手などもあるので、クイズゲームなどを作られる際にも、効果音をここから拾ってくればいいです。

Alexaの返事に「人間らしさ」を加える

ただ人間は、同じ質問を3回されたら3回とも同じ返事を返すことが不自然なんですね。同じことを聞かれたら、少し言い回しが毎回違ったり、3回目だったら「もうわかっているでしょ？」とイラッとした気持ちが乗っかったり、そういうところでいろいろ変わってくるんですね。

Alexaのブログのほうにも、Alexaのチームの人たちが返答に関して、例えばAlexa Skill起動したとき、「Alexa, stop」と言ったときの返事などはもう少しランダムさを持たせたほうが自然な会話っぽくなることが書かれています。

例えば、こういう実装サンプルですけども、ユーザーの発話が混声して聞き取れなかった場合なども、「すいません、よく聞き取れませんでした」と言うときと、「もう一度お願いします」ともう少し丁寧に言ったり。

もしかすると、ユーザー、ユースケースによってはもっとフランクに「えっ、なん？」というぐらい、今関西ノリでしたけど、そういう感じにカジュアルにやったほうが、実はスキルのユーザー層からすると自然な会話がやりやすいかもしれないです。

ここは完全に手前味噌なんですが、このあたりの実装を自分でやりだすとけっこう面倒くさかったので、ask-utilsというnpmのライブラリをこの間作って公開しました。

これを使うと、ask-sdkという新しいNode.jsのAlexa向けのライブラリがあるんですけど、そこでランダムな返事を作ったり、インテントのハンドルしたり、そういうことをよしなにできます。

試行錯誤がカギとなる

最後ですね。Alexaですが、音声も結局、音声アプリも大事なのは最終的にデザインなんですね。なので、Webサイトのデザインをされている方のTwitterのつぶやきなんですけど、Webサイトなどのさまざまなサイトを見たり、お店に行ったりして、「これってこういう配置になっているんだ」「こういう意図でデザインされているんだ」とデザイナーの方が考えられているんですね。

それは音声のアプリを作るときも、僕らがなにげなく家でしている会話などは「ここはAlexaにしたらこうなるんじゃないか」という観察などがこれから大事になってくるかなと思います。

（https://bokete.jp/boke/3702297）

これから初めてやる人が、いきなり丸を描いて、残りのフクロウを描けてすごい絵ができるみたいなことはなくて、何回も描いては消して描いて消してということをやっていって、最終的に何回も失敗して、何回も試した人が、すごい絵を描けるような、すごいアプリを作れるようになってくるかなと思います。

ただ、最後、これからいろいろ作っていって知見がたまってくるところもあると思うんですが、今スキル触る前に「これを音声でできたらいいよね」「ここは声で楽したいな」「ここで言わずに声で次のスライドに行けたらいいな」という気持ちがいろいろあると思います。

（https://twitter.com/i/moments/917589924345389056）

そういうことを控えておいて、ある程度慣れてきたときに「昔、俺こういうことを考えていたんだ」みたいに思えるように、控えておくことや観察していくことなどを今わからないからこそやっておくと、1、2年後、例えばAlexaのスキル内課金などのビジネスが日本でも始まったときに、いいスタートダッシュを切れるんじゃないかなと思います。

ということで以上です。ありがとうございました。

（会場拍手）