Alexaで世界をより良い場所に」が開催されました。Skill開発」をテーマにプレゼンテーションを行いました。Skill開発」ということで、やっていこうと思います。自己紹介ですが、岡本です。Kitでできることや、ワークフローなどを全般的に話していこうと思います。Alexaのイベントに参加して、作り方を覚えると、こういう気持ちになって帰るんですね。「よっしゃ、スキルを作ろう!」。なにか作って、一発当てたい気持ちがあるし、僕もそう思っていたんですけど、その前に考えたほうがいいなと思うことがありました。「そのスキルを作ろうという気持ちは(下記の)どちらか?」ということなんですよね。Qiitaなどで上げたい系のものなのか、それとも会社で提案して、プロダクションでやりたいのか、サービスとしてローンチしたいのか。そのどちらなのかは、いったん整理したほうがいいかなと思っています。いうのも、なんでもいいから作ってみたいんだったら、僕が今しゃべっている間にパソコンを開いて、Storylineで触っていたら、それで公開できちゃうんですよね。フラッシュブリーフィングスキルがRSSを食わせるものがあるので、それであればStorylineで画面操作をする必要もなく、作れるんじゃないかと思いました。作るだけだったらすぐできます。それをプロダクションとかサービスでやるときに、そのノリでやっていいのか、いきなりコードを書いていいのかということです。(会場の参加者を見て)なんか目が合わないですね(笑)。普通、Webサイトを作るときは、ユーザーストーリーやデザインを作ると思うのですが、音声のアプリケーションも音声のデザインが必要です。音声UI設計のチェックリスト音声デザインすることとは何か。ここに関しても、Alexaに関してはAmazonが「音声デザインガイド」というサイトをオープンしているんですね。ここにチェックリストであったり、「こういうことを考えてください」などが全部書かれています。チェックリストでは、「スキルでユーザーがなにができるかを明確に書いていますか?」や「スキルを家で呼び出すときに簡単に呼び出せるか?」や「自然な会話になるようになっているか?」などですね。ユーザーが想定外の発話ですね。ありうることは、家で使っている場合に、自分がしゃべっている間にほかの人が話しかけて混ざってしまう。混声してしまって、Alexaが何を言っているかがわからなくなっちゃうときに、エラーを出さないように持っていけるかなども考えると書かれています。この中のチェックリストで一番大事なのは、先ほどの話にもあったんですが、「ユーザーが実際に使っているところを1回でも観察しましたか?」というところです。ここの中の紹介文だけピックアップすると、公開前にそのスキルに慣れていないユーザー、そのため、開発に関わっていないユーザー、その人に使ってもらって、どう使うか、もしくはどこでつまづいているかなどを絶対確認するとチェックリストに書かれています。することでなにが起きるかというと、会話が思っていたようにスムーズにいく部分と、逆に思っていたようにいかない、「あっ、こういう言い方するんだ」みたいなことなどが発見されるんですね。Alexaのイベントで登壇されている方が言われるんですけど、会議室で作ったあとに絶対に家で使ってから、次の日もう1回ブラッシュアップする。いうところを考えるのがすごく大事になっています。いうことをやっていこうと思うと、なにが大事になってくるか。始めるのは早くやったほうがいいですね。大事なのはその次で、どれだけ早く失敗できるか、どれだけ早く会社にダメージを与えない、自分がしんどい思いをしないで失敗できるかが大事だと思います。Skillで作る部分は基本的な範囲としては2つあります。Kitというところが音声とテキスト、テキストと音声の変換をやってくれます。その裏側で、LambdaやStoryline、フラッシュブリーフィングのRSSなどがテキストを受け取って、テキストを返すデータ処理をやっています。そこに関しては、今のお話を踏まえて、僕が考えているのは、先に音声をどう変換するか、スライドの上の部分をやるべきだと思っています。Kitがやっているところは、今僕がしゃべっているような内容をどうテキストに変換するかを定義する場所なので、ここの上の部分の定義が「やはり違ったわ」といって変えちゃうと、その裏側の実装も全部変わっちゃうんですね。Kitの音声の変換の部分をどれだけ早く作って、どれだけ早くfixさせてから実装に入れるかが大事になってきます。そんななかで、その対話モデルを作っていくところによりフォーカスできるなと思っているサービスとしては、先ほどご紹介のあったStorylineですね。なにがいいかというと、やはり両方ないと動かせないのでこの下側の部分を作らないといけないんですが、下の部分をコードを書いて実装をやりだすと、それはそれで時間かかってしまうし、Alexaのものすごく長いJSONが200行ぐらいあるんですけど、あれをどう処理するかを覚えなきゃいけなくなってくるので大変だと思います。そのため、StorylineというGUIで作れるものがあるので、それを使ってモックの部分を裏側に作ってしまうことが大事かなと思います。先ほどもご紹介ありましたが、ドラッグ&ドロップでこういうかたちで、どの部分でなにを言ったら、Alexaがなにを言ってユーザーがなにを言ったらどこにいくかをフローチャート的に作れるので、社内でフローチャートなどを作ったあとにそれをそのまま書き起こす、モデルに落とすことも簡単にできるかなと思います。Kitで作ったものが、ユーザーが「これ使いにくいわ」と言われたらもうそもそも使われなくて、その裏側の処理も呼ばれなくなってしまいます。いうことを考えると、実際の利用シーンでその対話モデルが合っているか、今後の裏側の処理じゃなくて対話モデルがしっかりできているかというのをどれだけ早くテストして調整していくかというところが大事です。Storylineを使うべきか例えばそもそもその利用シーンで音声アプリを使うかですよね。会議室の中などでみんなで話して「こういうアプリあったらいいよね」という。「ゴミの回収日について聞けるようなものがあったらいいよね」と思いつく。「何日の月曜日のゴミはなんですか?」などの質問をいろいろ考えてやってみても、実際に使おうと思うと、だいたい月曜日ではないんですよね。「明日や今日のゴミは何ですか」ということしか聞きたくないですし、その今日のゴミも回収時間のあとにそれを教えられてもぜんぜん意味がないんですよね。いうところを使ってみないとわからないですよね。そのあたりを考えていくと、音声なので機械に対してモデルを作ると言ってますけども、もしそのAlexaに何かやってもらおうと思ったときに、例えば家族や会社の同僚などにお願いする場合にどんな会話になるかを考えていく必要があります。あとは返事の部分ですよね。ほうから来ているんですけど、方言や略称で意味合いが変わってくるものもあります。ターゲットが実は大阪なのに、東京の話ばかりでやっていて、実は大阪でこういう言い回しがあったから、そこがカバーできてなかった、みたいなことが起きるかもしれない。いうケースもあるんじゃないかと思います。あとは「ユニバーサルスタジオジャパン」や「東京ディズニーランド」をフルでしっかり言うかというところですよね。略称で言うこともありますし、新しいサービスなどだったら、略称もいろいろあると思います。いうところもカバーできるのか。いうところをやる上で観察が本当に大事になってきます。逆にLambdaやAlexaのSDK、JavaScriptやAPIなど、これなしでStorylineで作っちゃうだけでいいのかというと、そんなこともないです。GUIで先ほどの画面を定期的に保守・アップデートしていくところに関してやっていくのがOKと、開発チームが言ったら別なんですが、正直、対話モデルだけ作って、テストケースをそこで作る。Alexaの開発画面のテストコンソールでJSONのInputとOutputが見れるので、それをテストコードにして実装組むほうが、開発チームとしてもコードで、もしくはCI/CDを乗せたりできますし、実際に企画する側のほうでGUIでいろいろ作って、それを渡すワークフローになるので、両方使っていくことが大事かなと思います。新しい機能をStorylineでモックを作って、SDKやLambdaで実装していくイメージですね。このあたりのもう少し具体的な話をしていくと、まず音声デザインガイドに従って台本や対話モデルを作る。Storylineでその台本や対話のモデルを、適当にポチポチ入力していったら、モデルが作れます。何時の新幹線など、その台本のそのまま変数の部分などを変えたい気持ちはあると思うんですが、そこを抑えて、「9時の新幹線」と台本に書いてあったら、9時の新幹線しか受け入れないモックだというので、割り切ってスキルにまず起こしていくのが大事かなと思います。Skill向けのCLIツールがあるので、対話モデルのコード管理などされたい方は、ask-cliでこのStorylineが作ったモデルを全部引っこ抜いて、それをコードに改めて起こしていくやり方があるかなと思います。Storylineでの台本のスキル化ここからはもう開発チームのやりとりですね。Storylineでできたモックを実際にLambdaで実装していって置き換えていく。Herokuなどで自分でAPI作って置き換えていくやり方があると思いますが、そこは作られる方の好きにやっていけばいいと思います。台本のスキル化ですが、StorylineはGoogleアカウントさえあれば作れます。Alexa」というボタンを押したら、Amazonアカウントとさえ連携ができていればそれでデプロイができます。音声再生やラジオストリーム、もしくはストーリーテリング的なものであれば、Blueprintがあるので、そこを使うやり方もあるかなと思います。「ストーリーへようこそ!」とサンプルが全部あってダイアログ形式になっています。Alexa」というボタンを押すとAlexaの画面にデプロイできるので、これをテストするとOKということです。先ほどもありましたけど、台本をそのままスキルに起こすところで、変数の裏側の処理も確認したい気持ちがやはり湧くんですけど、ここでテストしたいのは、そもそもの台本が音声でやりとりしている状況に合っているかというところだけなので、処理についてはいったん諦める、割り切るところが大事かなと思います。ask-cliを使ったモデルのコード化テックな話になりますけど、ask-cliですね。Skillの管理に関してCLIで全部できるようになっています。Skillの対話モデルやLambdaのソースコードなどで作れます。get-skill」で、Storylineが作ったスキルの説明文や公開情報などをエクスポートできます。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との自然な会話を目指すここからStorylineから離れてTips的なところになりますが、「より自然な対話のところを目指して」というところです。AlexaはAmazonが公式でブログをやっています。その中で日本語がだいたい1〜2割、ドイツ語が1割、英語が残り7割みたいな比率ですが、スキルの開発に関するTipsがいろいろ載っているので参考になります。最近、子ども向けスキルが日本でも公開できるようになりました。お子さん向けにスキルを作られたい方は、今まではレビューが弾かれていたんですけど、今は申請したら通ります。あとは、ビジネスの話ですが、まだアメリカだけですが、スキル内課金ですね。月額何円というサブスクリプションモデルと、1回何円という買い切りモデル。両方とも今アメリカではパブリックになっています。いった課金のモデル、Alexaの中でビジネスをやっていくところも、まだ日本に来ていないだけで、そういうビジネスのかたちはこれから間違いなく来るだろうなとは思っています。そこで紹介されているTipsについても、例えば「複数の質問がある場合はDialogという機能を使いましょう」であったり、効果音を、先ほどもエコちっちで出てきましたけど、「効果音をいろいろ使っていきましょう」「返事を人間っぽくしましょう」というものが載っています。紹介していくと、完全に僕の仕様なんですけど、「今晩出発の新幹線の新大阪行きののぞみの窓際の指定席を探して」と。これをAlexaでやりたい場合、変数がこれだけあるんですね。インテントとスロットを扱うにあたって、なんとなくわかるかなと思うんですけど、この全部を入れているインテントがもしなかった場合に、どういう質問をしてどういう判定をする、値を引き継ぐかなどを考え出すとけっこう頭が痛いんですね。ここに関してもスロットの数がたくさんになりますが、「ダイアログを編集」というアクションがあって、ここを使うことによってダイアログごと編集できます。time(出発時間)をユーザーが言ってなかった場合に、ここで入力して「出発時間を教えてください」と言うと、Alexa側で、スキル側が実装しなくても、足りなかったら追加の質問をしてくれて、情報を集めて、全部が揃ったら処理を走らせる仕組みとして、Dialogという機能が用意されています。ここに1個だけ裏側でも実装しなきゃいけないものがあって、ダイアログの状態が始まった状態か、継続中か、全部揃ったかと(質問がある)。そこについては実装をやらないといけないですが、自力でインテントとスロットで全部がんばるよりは、だいぶ簡単にできます。複数の変数を、会話の中でやりたいとなってきた場合は、Dialog機能を使いましょう。Libraryを出しています。こんな感じでSSMLでS3に上げられているファイルを読み込ませると、Alexaチームが用意している効果音を導入することができます。説明文は基本英語なのですが、かなり種類があります。Animal、Cartoon、Office、Transportation、SF的なものもありますし、例えば拍手などもあるので、クイズゲームなどを作られる際にも、効果音をここから拾ってくればいいです。Alexaの返事に「人間らしさ」を加える最後、「人間らしさを加える」というところなのですが、けっこうコードを書いているとやっちゃいがちなんですけど、Alexaが毎回同じ文章で、同じ発話や返事をするんですよね。そのほうが簡単なので。人間は、同じ質問を3回されたら3回とも同じ返事を返すことが不自然なんですね。同じことを聞かれたら、少し言い回しが毎回違ったり、3回目だったら「もうわかっているでしょ?」とイラッとした気持ちが乗っかったり、そういうところでいろいろ変わってくるんですね。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のスキル内課金などのビジネスが日本でも始まったときに、いいスタートダッシュを切れるんじゃないかなと思います。ありがとうございました。07:00スピーカーの話が良かったらいいねしよう!株式会社PE-BANK株式会社PE-BANKに関する記事をまとめています。コミュニティをフォローすることで、株式会社PE-BANKに関する新着記事が公開された際に、通知を受け取ることができます。