AWS認定クラウドプラクティショナーに合格したので学習法を書いておく
※29日の朝起きたらスコアが公開されてましたので追記しました
掲題の通り、先ほどAWS認定クラウドプラクティショナーに合格しましたので
その学習方法を記載しておきます。
それに
の中で以下のこと言ってしまいましたし。
問題の中身に触れるとNDA引っ掛かるんで、そこはお察しです。
かつ、試験のスコア結果がくるまで時間がかかる&年末年始なので合格したことしかわかってないです。
※29日の朝起きたらスコアがきてました
スコア 2019年12月29日追記
700点が合格ラインで855点らしいです。 けど問題によって得点が異なるTOEICみたいな採点っぽいです。
どの分野も十分だったらしい。
これは、各分野が7割超えていたということだろうか?
本気出した時間
12月25日の午後から、26日終わるまで。
27日は模擬試験と復習のみ。
そもそもなぜ受けたか
ある程度、AWSを触ってきていたので、そろそろ何かしら受験するかとは思っていたのと、
11月27日のBlack Beltの内容がクラウドプラクティショナーで、これを視聴していて
「いけんじゃね?しかも1000円アマギフくれるらしいし」
となっていたからです。
なんでクラウドプラクティショナーを選んだのか
ビッグデータから受けようと思ったらアソシエイトの何かしらか、クラウドプラクティショナーが事前に必要だったらしいのと直接的な技術面以外の知識も欲しかったからです。
コスト計算とかサポートとか。
そして年内の試験会場的に選べるのがこれしかなかったからです。
前提、僕のスペック
情報系の工学部大学学部、修士卒。
IT系のエンジニアを9年くらい。
AWS利用歴はDBAだった時のRDSと最近のAlexaがらみが中心でした。
が、以下の本は今年の夏で読破済みです。
・Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-
・Amazon Web Services パターン別構築・運用ガイド 改訂第2版
・Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく
・AWSによるサーバーレスアーキテクチャ
・Amazon Web Services実践入門
・合格対策 AWS認定ソリューションアーキテクト - アソシエイト
かつ、フリーランスとして以下を作りました。
今回の試験対策で具体的にやったこと
モットー:資格試験は舐めプしない
■1.以下の動画をみて、試験の存在と自分に足りない部分に気づく
■2.公式サイトをみる
■3.クラウドプラクティショナーとソリューションアーキテクトアソシエイトの受験記、合格体験記のブログを読む
クラウドプラクティショナーの試験はできたてであり、ノウハウが少ないので、 ソリューションアーキテクトのブログ類もめぐります。
AWS実務経験の無いシニアエンジニアがAWS認定試験に合格するまで - Qiita
3日くらいの対策でAWS認定ソリューションアーキテクト アソシエイトに合格したので、対策内容をまとめてみた - Qiita
AWSソリューションアーキテクト-アソシエイトに合格したので、合格するために必要と思われる感想をスライドモードで公開 - Qiita
AWS認定ソリューションアーキテクト(アソシエイト)の合格に重要かもしれないことをまとめてみた | MMMブログ
新卒入社4ヶ月でAWS 認定ソリューションアーキテクトに合格した話 | MMMブログ
AWS 認定 Associate level を大体一ヶ月で取った話 - Qiita
「AWS 認定クラウドプラクティショナー」資格のサンプル問題を解いてみよう | トレノケート公式ブログ
【合格体験記】AWS 認定クラウドプラクティショナーの効率的な勉強方法
AWS認定クラウドプラクティショナー取得しました - Qiita
AWS認定クラウドプラクティショナー受検してきました! | AWSコスト削減・IaaSインフラ構築のシンプライン株式会社
【合格体験記】AWS 認定クラウドプラクティショナー試験(AWS Certified Cloud Practitioner) | 最強SEの仕事術
■4.AWS Cloud Practitioner Essentialsの動画を一周する
7時間半くらいかかります。
しかも、口調が単調でしんどいです。
知っている箇所も復習をかねて僕はすべて視聴しました。
確認問題が最後に出るのはチェックしておくと良いと思います。
AWS Cloud Practitioner Essentials
ぶっ続けで動画をみていると、以下のようにメールボックスが素敵なことになります。
■5.ドキュメント類を読む
以下のクラウドプラクティショナーのサイトから直接リンクされているホワイトペーパーを読む。
特にサポート系とAWS Trusted Advisorの動画は要チェック。
ここらへんが技術面以外で試験範囲に思いっきりあるからです。
その後に
の、ソリューション別資料のSlideShareやPDFを流していく。
■6.「合格対策 AWS認定ソリューションアーキテクト - アソシエイト」を読む
日本語でAWSの試験対策本は2018年12月28日時点でこれしかないので、再読します。
2016年時点ですが、要点は書いてあります。
しかし、この本にない部分も試験にはわんさかでます。
ちなみに、2019年1月18にはSAAの新試験対応の別の本が出るみたいですね。
■7.Webの問題集を無料の範囲で解く
公式サイトや以下のような箇所です。
AWS WEB問題集で学習しよう | 赤本ではなく黒本の問題集から学習する方向け
■8.模擬試験を受ける
模擬試験を受けます。
2問間違えたらしく92点でした。
気になった単語等はメモしておきます。
■9.模擬試験で気になった箇所を今までの資料や本で見直す
今までの資料のうち、模擬試験で気になった箇所を読み直します。
サポート体系と、「合格対策 AWS認定ソリューションアーキテクト - アソシエイト」
を再チェックします。
■10.ちゃんと寝る
試験前夜はちゃんと睡眠をとります。
たぶん最重要です。
■11.受験30分前には会場について受験
15分前から入室なので、30分程度前について、トイレに行き、注意事項等を確認して受験
■12.ブログを書く
いまここ
所感
・ブログ類
・ソリューションアーキテクト本
・クラウドプラクティショナーの動画
以外の観点も数問出題されました。
過去のソリューションアーキテクトレベルの問題も一部でてきたように感じます。
他の方の受験記にもありますが
模擬試験が本試験より簡単すぎますので、
模擬試験で調子に乗ると危険だと思われます。
模擬試験がギリギリ合格以下だと本番は厳しいと思われるので、その場合は勉強時間を確保した方がいいです。
クラウドプラクティショナーは対象がエンジニア以外も含まれますが、IT用語なのかAWS用語なのか区別がつかない人が受けるなら、それなりにお勉強しないと厳しいだろうと感じました。
さて、次にいこう。
特許出願したVUIのログ収集・分析およびレビュー・フィードバックシステムの話
この記事は
ADVENTARの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」
の25日目の記事です。
さて、アドベントカレンダー最終日。
思いっきり、技術の話をしようと思います。
2018年4月末に会社をスパッと辞めて
「VUI・スマートスピーカーに専念するぜ!」
となってましたが、半年もしないで自分単独が発明者となって特許出願するとは思ってませんでした。
しかも、API Gatewayってなんですか?のレベルからAWSをガッツリ勉強・検証することにもなったわけです。
そんなシステムの話。
対外的に一番語っている資料はAlexaSalon
25分間、このシステムについて語っているのは
クラスメソッド社、清野さん(せーのさん)からご招待があった、AlexaSalonにて語っていて、すでにそこでスライドは共有済みです。
ご関心ある方はそちらをどうぞ。
■Alexa Salon SP @東京 〜秋のNLT(Not LT)大会〜 AlexaエバンジェリストにAlexa Championも!
特許出願したSH Analytics(通称SHA)
上記の通り、SmartHacks社に納品したシステムです。
このシステムには以下のような目的があります。
平たく言えば、VUIのスキル・アクションの品質を高めるための仕組みです。
・VUIの各プラットフォームのログデータを一元管理して分析する
・自分および他社のスキル・アクションを様々な角度で比較してKPI等の具体的数値を出す補助をする
・人気のスキル・アクションが他の人からも見てわかる
・開発者と開発を依頼したい人のマッチングにつなげる
・スキル・アクションの利用頻度が落ちてきた場合等もグラフで一目でわかる
・音声サービスに対するレビューを音声で行う
・音声サービスに対するフィードバックコメントを音声で行う
などなど、様々な使い方を想定しています。
AWS構成図
動き出した時点の構成図は公開されているので、ここで語ることができます。
わかる人には、「ん?ここおかしくね?」というポイントがあると思いますが、そこらへんはこの後にある程度進化させているつもりです。
この構成にはいくつかのポイントがあります。
1.VUIのスキル、アクションとしてスキル・アクションそのもののユーザーに負担をかけない
Lambda等でHTTPSで本システムのAPI GatewayにPOSTで必要事項を送付すると、DynamoDBに、SHA登録済みであるか確認を行い、即時スキル側にHTTPのレスポンスを返しています。
基本的に200か、それ以外を返しますが、先日202を追加しました。
本来、Amazon Cognito等と使ってしっかり認証・認可をすべきですが、VUIの応答速度およびアカウントリンク等の負担を鑑みて、それはやらないことにしました。
2.データ収集はそれ用のLambdaをinvokeさせてバックで行う
1に関することですが、DynamoDBでSHAの正規ユーザーだとわかり、かつ、想定通りのJSON形式だと200を即時スキル側に返答しています。
その際に新しいLambdaをinvokeで起動させて、Amazon Kinesis Data Firehoseに投げています。
FirehoseからS3等にアウトプットする際にデータ形式を変更することが可能ですが、お金が若干かかるのと、データ格納先がRedShiftであるため、CSV形式にあらかじめ変換しています。
めっちゃバズったらAmazon Kinesis Data Streamsを間に挟んだ方が良いと考えています。
もともとは、AuroraかRDS PostgreSQLで行う予定でしたが、やはりLambdaと相性が悪すぎました。
CSV形式なのはそのなごりでもありますが、クライアントさんがエンジニアではないことも考慮するとCSV形式の方が読みやすいと判断しました。
ちなみに、新卒3年目くらいの時に、同じようなロジックをJavaのマルチスレッドで実装して怒られました。
「DBに格納されているか不透明なのにOKを返すことは何事か」
と。
そこは最低限、この図にない部分のS3にも格納しています。
3.Athenaを選ばずに初めからRedShift
VUIが流行るかどうかすら正直不透明であり、そんな中でいきなりRedShiftを選択します。
安価にシステムをまわすことを考慮するとS3に格納してAmazon AthenaでSQLライクに呼んだ方が良いと思われます。
が、今回の場合、僕はあくまでフリーランスでの単発受注だった点と、RedShiftはFirehoseから容易につなぐことができる点、そして後からRedShiftにいれるようにいじるのはかなりしんどいと判断して、コスト計算をした上でクライアントのOKをもらってRedShiftにしました。
Athenaもそこそこいじりましたが、VUIのログデータがガンガン飛んでくるとログファイルもガンガン増えていくことになり、ファイルをまたがりまくるとAthenaの性能がつらぽよでした。
僕のAWS力が高ければうまいことやれたんだろうとは思います。
RedShiftでのテーブル分散もそれなりに考えています。
例えば、スキル・アクションに関するデータ(カテゴリとか)を管理するテーブルはデータ量が少ないがJOINする頻度が高いのでALL分散でJOINの負荷を下げたつもりです。
ログデータに関してはさすがにALL分散は選ばないようにしています。
4.分析画面はQuickSight
BIツールは他にも経験がありましたが、QuickSightに落ち着きました。
以下のような画面になっています。
Alexaのカスタムスキルの、スキル毎のユニークセッション数や、カテゴリごとの利用頻度、音声でのレビューの星の数やユーザーからの音声からのフィードバック等を表示しています。
提供しているダッシュボードは複数ありますが、開発中のスキルの場合は基本的に、SHAから割り振られた匿名の開発者名とスキル名が表示されます。
流行ってきたと思ったら、公開する旨をSHAの中の人に連絡すると、開発者名とスキル名を伏せずに公開しているダッシュボードにデータを公開することができます。
平たく言えばアピールできます。
※
スマートスピーカーを遊びたおす会で表示したスライドです。
一部、テスト用のスキルのデータも含みます
QuickSightに落ち着いた理由は主に以下です。
・サーバレス最高
・MetabaseとかのためにEC2やElastic Beanstalkを使うのは嫌だ
・料金プランが非常に良い
・E-mailで分析画面を送付できる
・登録して、閲覧するためのユーザーはメールアドレスをもらえばよい
QuickSightは操作に慣れれば非常に扱いやすく、また、分析画面のダッシュボードの閲覧権限を与えたユーザーが、どんなに使い倒しても1ユーザー(1アカウント)あたり月5ドルです。
使わなければ0ドルというか0円です。
なのでダッシュボードをばら撒くことがやりやすいので大変良いです。
QuickSightは機械学習対応をするらしく、グラフの傾向から今後のグラフがどうなるかまで分析してくれるみたいです。
となると、SHAに登録したスキル・アクションの今後の利用頻度が予想されることになります。
神か。
E-mailで分析画面のレポートを送付できるのも強いです。
分析画面をBIツールでいかにかっこよくしようとも、見られないのは意味がないです。
そこにE-mailで分析画面のキャプチャを送付できるのはPUSH型であり、かなり強いと考えています。
※
ただし、Oracle DBとはつなぐことができません。
たぶんライセンスがうんぬん・・
5.僕が作った「ノリノリのサンタ」へのフィードバック
「ノリノリのサンタ」というスキルを本システムに対応させています。
すると上記のようなユーザーからのコメントが寄せられていることがわかります。
・何やってるんですかね
・ノリノリの具合がすごい
等のユーザーからのコメントがもらえるのは開発者として非常に嬉しいことです。
6.検討したが辞めた技術類
1.Glue
バグを猛烈に踏みました。
そして、本システムにはお金かかりすぎだと判断しました。
2.AWS Batch
RDS PostgreSQLにデータを格納しようとして、AWS Batchでがんばろうとしましたが、断念しました。
Firehoseから直にRedShiftに入れた方がシステムが安定するのと、Batchに現実的にどれだけの時間がかかるのか未知数だったためです。
3.AWS Step Functions
Lambdaを組み合わせて、RDSとうまいこと連携できないかと模索しましたが辞めました。
CSVをRDSに格納する際に使用するこを検討しましたが、やりたいことに対して複雑すぎると踏んだからです。
そこまでして、RDSではないといけないのかということになりまして、クライアントと話した結果、
「firehoseから直にRedShiftに格納できるならそれでいいじゃん」
となった次第です。
もちろん間にS3を挟みますが、努力が減って、やりたいことが実現できるならその方が良いです。
4.RedShiftのクエリエディタ
■RedShiftのQuery editorの注意
意図していないタイミングでSQLが発行される可能性がありました。
怖すぎる。
結局これをつくるのにどれだけの時間がかかったか
本格的に着手してから2か月ちょいくらいです。
「API Gatewayってなんですか?」
の状態から、市販本を買いあさり、AWS Well-Architected フレームワークを読んで、AWS Loftに通ってエキスパートさんに随時質問して、QuickSight等のハンズオンに参加したらこうなりました。
VUIに関する知識と、今までのエンジニアとしての経験をフルフルに注ぎました。
このシステムを創って得たモノ
1.AWSの知識と経験
AWSの知識類は飛躍的に上昇しました。
re:Invent2018の内容をみて、
「え、まじか。あれこうなったのか」
とかがわかるようになりました。
2.AWSの中の人と仲良くなれた
AWSの中の人達と、結構仲良くなれました。
今ではほとんど顔見知りです。
AWS Loftを使って、VUIで特許出願システムが生まれたという事例はたぶん初だと思います。
AWS LoftやQuickSightの活用事例の話として、登壇お声がけになるかもです。
3.がっつりエンジニアリングした
VUIのスキルを創る際に利用するのはせいぜいLambda、DynamoDB、S3くらいです。
今回、他のサービス類をめっちゃ検討して、めっちゃ使って、エンジニアリングしたなーと思えてるのは、やはり大きな収穫です。
4.技術的に話せる機会が増えた
フリーランスなので、お仕事の依頼を受けることはちょくちょくあります。
僕の場合は基本的には「VUIの人」なのですが、「AIスピーカーを使ったシステムを創りたい」みたいな話が来た時に、同時にオンプレ環境をクラウド化したいという潜在課題がある場合もあります。
その際に、自分でその場でAWSへのマイグレーション案がだせるようになれたのは非常に大きいです。
もちろん、イベント類でも話すことができるようになりました。
あとは認定資格でもとって名刺に記載しようかな。
5.特許出願のやりかたを知った
めっちゃ大変でした。
想像以上でした。
大学の論文を書いてる感覚でした。
大学院時代を思い出しました。。。
弁理士さんと随時相談していくわけですが、そもそもIT業界のエンジニアだってVUIに詳しくない状態で、
弁理士さんにVUIやスマートスピーカーを語り、クラウドの仕組みを語り、法的な文面に落としていくのがめっちゃ大変です。
アドベントカレンダーやりきった
25記事を書き続けてきたわけですが、当初の予定と大幅に変わりました。
「情報は水物」って本当ですね。
僕が1人で25記事(Qiitaを含めると50記事)+他のアドベントカレンダーへの数記事を合わせると結構な量になります。
あとMediumで英語ブログも始めました。
そもそも1人アドベントカレンダーを勧めてくれた人が何名かいましたし、
VUIやってきた2018年で、仕事の時間をコントロールできる今年が25記事やりきるタイミングとしてBESTだと踏みました。
PostgreSQL界隈の積極的な方々が1人アドベントカレンダーをやっているのを目にしていましたし、やりきることで得るものはたしかにたくさんありました。
やってみて本当に良かったと思っている点は
何かをやるときに、どうアウトプットするかを考えながら行動できるようになってきたことです。
アウトプットを前提としてインプットすることができると、吸収量が半端なく上がります。
そして、ブログの閲覧数が大変多くなりました。
みなさん、ありがとうございます。
来年も調子にのってやるかもしれないですが、もうちょい計画的にやりたいですね。。
以上です。
Alexaで位置情報を取得するReal-Time Location Services for Alexa Skillsの設定と流れるJSON
この記事は
ADVENTARの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」
の24日目の記事です。
AlexaDevSummitの1日目で会場をふらふらしてたら、岡本さんから
「showさんやばいっす!これみてくださいよ!!」
と、ノートPCを開きながらめっちゃ興奮されてたので、そのPCをみたらAlexaが位置情報に対応してた画面でした。
岡本さんありがとうございました。
僕もその日の夜に「おおおー」となってました。
で、既に試されてる方々がブログに上がっているわけですが、僕は僕で改めて試して、流れるJSONがたしかに変わったなーと思ったのでここに記載します。
Real-Time Location Services for Alexa Skills
これについては公式のサイトをみてください。
Enhance Your Customer Experience with Real-Time Location Services for Alexa Skills : Alexa Blogs
先に確認できた記事類
これらをみればわかると思います。
■情報提供元、岡本さんの記事
・Alexaから位置情報を取得可能になったので試してみた
■さっそくためした @MYamate_jp さんの記事
・Alexa Real Time Location Serviceを使う
■ @MYamate_jp さんの他の記事
・Alexa Skill開発でよく使いそうな関数をまとめたnpmモジュールを作った
僕も試してみた
まず、APL対応した画面を、スマートスピーカーを遊びたおす会で録画したかったがためのスキル
「ヒロインのテスト」
で、試します。
が、別に何でもいいです。SDK v2であるだけです。
1.Alexa Developer Consoleのアクセス権限を押す
いつもの左下箇所です。
2.位置情報のトグルをONにする
いつの間にか、しれっとでてきていた、位置情報サービスのトグルをONにします。
3.LambdaでJSONを確認してみる
単純にJSONの中身を出力します。
console.log(JSON.stringify(handlerInput));
LaunchRequestのHandlerにでも入れてみてください。
4.スマホからスキルを起動する
スマホからスキルを起動してみたら "alexa::devices:all:geolocation:read" が追記されていました。
が、アクセス権を許可していないのでDENIEDになっています。
"requestEnvelope": { "version": "1.0", "session": { "new": true, "sessionId": "amzn1.echo-api.session.fad41c95-9292-XXXXXXXXXXXXXXX", "application": { "applicationId": "amzn1.ask.skill.fd6f4522-518c-XXXXXXXXXXXXXX" }, "user": { "userId": "amzn1.ask.account.XXXXXXXXXXXXXXXX", "permissions": { "scopes": { "alexa::devices:all:geolocation:read": { "status": "DENIED" } } } } }, "context": { "System": { "application": { "applicationId": "amzn1.ask.skill.fd6f4522-518c-40b3-8508-71e6d205ed1e" }, "user": { "userId": "amzn1.ask.account.XXXXXXXXXXXXXX", "permissions": { "scopes": { "alexa::devices:all:geolocation:read": { "status": "DENIED" } } } }, "device": { "deviceId": "amzn1.ask.device.XXXXXXXXXXXXXXXXXX", "supportedInterfaces": { "Geolocation": {} } }, "apiEndpoint": "https://api.fe.amazonalexa.com", "apiAccessToken": "XXXXXXXXXXXXXXXXXXXXXXXXX" } },
5.スマホのAlexaで位置情報を許可してみる
スマホ(僕はAndroid)のAlexaスキルアプリを呼び出して、スキルへの位置情報提供を許可します。
一応、スクリーンショットをとってみました。
まずは起動してメニューを表示しましょう。
上記で「スキル・ゲーム」を選びます。
はい。いつもの画面です。
ここでいつも通り、有効なスキルを選びましょう。
今回の「ヒロインのテスト」は開発中のスキルなので
開発スキル を選びます。
そして、画面をスクロールして目的のスキルを選びましょう。
目的のスキルを選んだら、グレーになっている「設定」をタップ。
※個人的に選べなさそうな色にみえる。
Alexa Developer Consoleで位置情報サービスのトグルをONにしているので、権限を聞かれます。
ここで位置情報サービスの権限を許可して保存します。
スマホで位置情報が取得できているなら、位置情報サービスのアクセス権に許可がされたことが確認できます。
6.もう1回、スマホからスキルを呼び出してみる
再度スマホから、「ヒロインのテスト」を起動します。
するとJSONが変化しています。
"alexa::devices:all:geolocation:read"がGRANTEDに変化して、位置情報のJSONとしてGeolocationが追記されています。
※位置情報の有効桁数はそのままで、適当な数字をいれてます。
"requestEnvelope": { "version": "1.0", "session": { "new": true, "sessionId": "amzn1.echo-api.session.0c9XXXXXXXXXXXXXXXX", "application": { "applicationId": "amzn1.ask.skill.XXXXXXXXXXX" }, "user": { "userId": "amzn1.ask.accounXXXXXXXXXXXXXXXXXXXXXX", "permissions": { "consentToken": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", "scopes": { "alexa::devices:all:geolocation:read": { "status": "GRANTED" } } } } }, "context": { "System": { "application": { "applicationId": "amzn1.asXXXXXXXXXXXXXXXXXXXXXXXX" }, "user": { "userId": "amzn1.ask.account.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", "permissions": { "consentToken": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", "scopes": { "alexa::devices:all:geolocation:read": { "status": "GRANTED" } } } }, "device": { "deviceId": "amzn1.ask.device.AXXXXXXXXXXXXXXXXXXXXXXXXX", "supportedInterfaces": { "Geolocation": {} } }, "apiEndpoint": "https://api.fe.amazonalexa.com", "apiAccessToken": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }, "Geolocation": { "timestamp": "2018-12-24T10:12:06Z", "coordinate": { "latitudeInDegrees": 79.1235586, "longitudeInDegrees": 283.1111355, "accuracyInMeters": 33.1111104196167 }, "altitude": { "altitudeInMeters": 40.111111525878906, "accuracyInMeters": 29.23455004196167 }, "heading": { "directionInDegrees": 0 }, "speed": { "speedInMetersPerSecond": 0 } } }, "request": { "type": "LaunchRequest", "requestId": "amzn1.echo-api.request.XXXXXXXXXXXXXXXXXXX", "timestamp": "2018-12-24T10:13:44Z", "locale": "ja-JP", "shouldLinkResultBeReturned": false } },
位置情報っぽいような数値がたくさんでてきましたが、個人的にアツいと思っているのが
speedInMetersPerSecond です。
まだドキュメントを読んでいないので正確なことはわからないのですが、そのまま解釈すると1秒当たりの移動速度がメートル単位ででてくる・・・??マジで?
となると、例えば車などの乗り物に搭載されたAlexaデバイスとかも想定してるのだろうかと個人的には考えています。
というわけで
位置情報を使ったスキルを組み込むことが可能になったと思われます。
もちろん日本語版で。
となるとエラーハンドリングとかも大変そうですが、IoTやりたい勢としては実世界との融和性が高まるので・・オラ、わくわくしてきたぞ!
以上です。
技術書典5で買ったスマートスピーカー系の本を読み直した
この記事は ADVENTERの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」 の23日目の記事です。
技術書典6に向けて、次にやるならアレをやろうみたいな話がそろそろ僕の周囲でも具体的な話がでてきています。
技術書典5では、「スマートスピーカーを遊びたおす本」を出させて頂きましたが、他にもスマスピ・VUI系の本は技術書典5にて購入していました。
もちろん、1度読みましたが、今回改めて読み直したので、それぞれの内容等にざっくり触れたいと思います。
書評するような立場ではないですし、100%個人の感想です。
そもそも技術書典って何?
今の時期ならコミケが着目される時期で、要するに同人誌即売会です。 それの技術書のみが集まるイベントです。
僕が参加した技術書典5は1万人の来場者がいらっしゃいました。
以下では、その場で買ったスマートスピーカー・VUI本に触れていきます。
1.GoogleHomeプチハック
入ってすぐのサイボウズさんのブースでまさかの200円。
サイボウズさんなので、kintoneの話なのですが、Google Homeアプリのインストール設定からActions on GoogleやDialogflowの設定までがフルカラーでめっちゃ丁寧に書いてあります。
VUI LT7で会場がサイボウズ社であったこともあり、著者のミケさんの登壇をその場で観させていただきましたし、サイボウズ社の森みたいな会場もすごかったわけです。
が、この本の内容、これ絶対200円じゃない。
プチハックと言いつつも、設定類はできますし、kintoneとの連携はもちろん記載されてます。
Google Homeの設定を知りたい、kintoneと連携したい等のモチベーションがあればイチオシです。
2.Raspberry PiではじめるDIYスマートホーム
表紙これ、怒られないのかと思うんですけども、それはさておいて。
この本はAlexaを使ったスマートホームについて触れています。 そして、タイトル通り、Raspberry Piを使ったスマートホームの話です。
Alexaについても記載がされてますが、スキル作成はNode-REDです。 プログラミングに関する記述はむしろ bash しかないです。
Node-REDの使い方や、Raspberry Piで動かすコード、物理的な環境について語っている本です。
Node-REDでAlexaスキルを扱い方、Raspberry Piなどを使ってセンサー類を扱いたい方にはオススメです。
3.スマートスピーカーアプリのお品書き
サインもらってますが、温泉BBAの方々の本です。
内容は大きく分けてVUIデザインの話と、Clovaのスキルの作り方の二部構成です。
VUIのデザイナーをなさっている元木さん記述部分はさすがデザイナーです。 音声アプリの企画の話から対話設計の話まで、大変濃密です。
特筆すべき点は 音声アシスタント3プラットフォームの機能別比較表 だと思います。 これの何が良いかというと、本当にこれからVUIをやろうとしたときに、どのプラットフォームで何ができるの?という壁に最初に当たるからです。 それが一目でわかります。
執筆時点での日本とアメリカの比較と、Clovaで何ができるかがまとまっています。
スキルの履歴書という発想も僕にはまったくなかったので大変参考になります。
第二部のClovaスキルの作成方法は画面キャプチャが丁寧なのですが、npmのエラー時の対応方法まで記載されているVUI本は他に観たことがないです。
Clovaの画面は変化が激しい状態にありますので、現状とは若干ことなりますが、この本を読んでおけば、スキル作成時に気を付けることが濃縮されている上に、本当に初心者向けに書いてありますので、これからVUIを始めたい方にはオススメです。
巻末の用語集も嬉しい記載です。
4.俺たちが知りたかったAlexaの話
この本は、とんでもないです。 なんで2000円なんだ。安すぎる。
技術書典5で、この本だけは絶対に手に入れるつもりでいました。
Alexaチャンピオンの方々が関わっているというのもありますが、書いた人うんぬんよりも 内容がガチだから です。
例えば、一般的なVUIのデザインや設計だと「ハッピーパスを作りましょう」という感じですが、そんなレベルではないです。
代替パス、シーンの前提、ヘルプなどのパスについても書いてあります。 Experience flowの話は大変勉強になる上に、他にもダメな例、良い例など非常に具体的です。
デザイン面だけでも濃厚ですが、開発面はより一層深いところまで踏み込んでいます。
・ASK CLI
・SSMLの効果的な使い方
・DynamoDBを扱う場合にask-sdkとaws-sdkのメリデメの比較
・開発手法
・粒度ごとのテスト
・ツール類の紹介
などなど極めて実践的です。
そして、最後にコミュニティの話と、アウトプットの話になっています。
Alexaでスキルを複数個リリースしてきて、市販本等に物足りなくなってきたら、この本は必読だと思います。
VUIのデザイン部分は他のプラットフォームでも考え方は同様になると思います。
極めて良書です。
読んでみて思ったことは
技術書典5は、そもそも僕自身の人生経験として「同人誌即売会」が初でした。
そしていきなり執筆&編集をやらせてもらい、リアルお仕事にもつながりました。
技術者にとって、本を書くというのは一つの目標だと僕はずっと思っていたわけですが、上記4冊のように様々な人たちが様々な視点で本を書いています。
アウトプットというと、ブログやイベント登壇などが個人的には思いがちなのですが、技術書典に1回本をだしてみると得られることがありますし、自分が経験したからこそ上記の本の「すごさ」がわかる面もあると思います。
というわけで、Qiitaなどのブログ類以外にも、本という形でアウトプットしてみてはいかがでしょうか。
以上。
もしビブリオバトルするなら選ぶ予定のAlexaスキル
この記事は ADVENTARの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」 の22日目の記事です。
来年の某イベントで、自分のオススメのスキルを選んで、それを集まったみんなで試すというビブリオバトル なイベントをやる流れなのですが、そこで紹介しようと思っているスキルをここに記載しておきます。
今年1年、いろんなイベントで、いろんなVUIのスキル・アプリを観てきました。
イベントで見たのもあれば、人から勧められたのもありますが、僕が知る中で、個人単位で、 色んな意味でもっともがんばってる と勝手に思ってるAlexaスキルのうちの1つは
強欲なうさぎの迷路
だと思ってます。
Amazonのスキルストアの結果
以下は、Amazonのサイトで「強欲なうさぎの迷路」の検索結果です。
これ、審査通るのかよ!w という内容です。
詳細説明を読んでみると凄すぎる
以下の文言で掲載されてるのが凄すぎる。
・Wi***dry彷彿とさせる
・画面がなくても難易度は高いですが遊べます
・方眼紙でマップ作製
・アイテムの名称はランダムで65536通り
知った機会
VUI LT7で作者がこのスキルについて登壇なさってました。
■VUI LT7
何がすごいかは見ればわかる
Echo Showでのプレイ動画をあげました
あのゲームを再現しているのがわかります。
これをEcho Dotなどの音声のみでやらせるという流れがすごい。
僕は画面があってもわかんないですからね。。。
画像作成にこだわりまくっている
上記connpassのスライドにあるのですが、
・通勤電車内でドット絵を描いた
・迷路画像256パターン全部作った
・迷路生成ロジックがガチだし、0.5msで生成される
VUIのイベントで、「ビット演算」とかこのセッション以外聞いたことないです。
APL対応したらどうなるのか
このスキルをAPL対応させるとどうなるのか、ものすごい興味があります。
たぶん、現時点での描画の方があえていいんでしょうけども。
がんばってる感は半端ない
VUIでWi***dryをやるという発想から、ビット演算とかドット絵とか考え抜いて、審査通過して公開されてるわけです。
埋もれてしまうには、あまりにも残念なので、ご関心ある方はプレイしてみてください。
まったく関係ないけど、PS Vita版もあったんですね
懐かしくてググってたら、PS Vita版があったらしいです。
けど、A社なので、きっとものすごい難易度なんだろうなぁと勝手に思います。
以上。
深夜テンションで創ってAmazonさんの審査員さんに協議させてしまった「ノリノリのサンタ」の話
この記事は ADVENTARの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」 の21日目の記事です。
Echo Showのために4つのスキルを作成した方々、お疲れ様です。
さて、今回は僕が完全に深夜テンションで作成したAlexaスキル「ノリノリのサンタ」について記載します。
相変わらず、AmazonJapanの方を大至急協議させてしまいましたので、それについても触れていきます。
Alexaスキル「ノリノリのサンタ」とは
「なんかクリスマスのスキルを創るかー」
と思って、いらすとや ではない素材を探していたら、テンションが高そうなサンタクロースの画像素材を見つけました。
なので、サンタクロースとかクリスマスとかについての雑学をググって、まとめて、僕が深夜テンションで自分で声を収録しました。
もちろん画面対応
Echo Showが来る前にリリースしたので、Echo Spotでの画面表示に対応しています。
テンション高めなサンタクロースの画像と、ノリノリな声がぞれぞれランダムに再生されます。
ソースコードの一部
めっちゃ一部ですが、たいしたことはしてないです。
ユーザーが初回起動か否かの判定と、操作説明をオーディオファイルで流しているだけです。
画像とオーディオファイルは別々にランダムで表示させています。
'use strict'; const Alexa = require('ask-sdk'); const AWS = require("aws-sdk"); const docClient = new AWS.DynamoDB.DocumentClient({region: 'ap-northeast-1'}); //音声を定義 //起動時 const smartmacchiato = '<audio src=\"https://s3XXXXXXX.mp3\" />'; //2回目以降、わしがのりのりサンタじゃあ const washiganorinori = '<audio src=\"https://s3-XXXXXX.mp3\" />'; //初回ユーザー用説明 const first_user = '<audio src=\"https://s3-XXXXXXXXXXX.mp3\" />'; : : : //トリビアの数 const norinori_01 = '<audio src=\"https://s3-XXXXXXXXXXX/norinori1.mp3\" />'; const norinori_02 = '<audio src=\"https://s3-XXXXXXXXXXX/norinori2.mp3\" />'; const norinori_03 = '<audio src=\"https://s3-XXXXXXXXXXX/norinori3.mp3\" />'; : : : //トリビアのの音声配列 var norinori_speak_array = [ norinori_01, norinori_02, norinori_03, : : : ]; //画像 const DisplayImg1 = { title: 'のりのりサンタ1', url: 'https://s3-XXXXXXXXXXXX/img/santa1.png' }; const DisplayImg2 = { title: 'のりのりサンタ2', url: 'https://s3-XXXXXXXXXXXX/img/santa2.png' }; const DisplayImg3 = { title: 'のりのりサンタ3', url: 'https://s3-XXXXXXXXXXXX/img/santa3.png' }; : : : //サンタ画像の配列 var norinori_img_array = [ DisplayImg1, DisplayImg2, DisplayImg3, : : ]; ////////////////////////////////////////////////////////////////////////// const LaunchRequestHandler = { canHandle(handlerInput) { return handlerInput.requestEnvelope.request.type === 'LaunchRequest'; }, async handle(handlerInput) { //サンタ話のうち1つをランダムで選ぶ var factSpeakArr = norinori_speak_array; var factSpearkIndex = Math.floor(Math.random() * factSpeakArr.length); var randomSpearkFact = factSpeakArr[factSpearkIndex]; //サンタ画像のうち1つをランダムで選ぶ var factImgArr = norinori_img_array; var factImgIndex = Math.floor(Math.random() * factImgArr.length); var randomImgFact = factImgArr[factImgIndex]; // Template 6 if (supportsDisplay(handlerInput)){ const myImage1 = new Alexa.ImageHelper() .addImageInstance(randomImgFact.url) .getImage(); const myImage2 = new Alexa.ImageHelper() .addImageInstance(randomImgFact.url) .getImage(); const primaryText = new Alexa.RichTextContentHelper() .withPrimaryText('') .getTextContent(); handlerInput.responseBuilder.addRenderTemplateDirective({ type: 'BodyTemplate6', token: 'string', backButton: 'HIDDEN', backgroundImage: myImage2, image: myImage1, title: "", textContent: primaryText }); } //JSONを扱う関連 let handlerInput_json = await JSON.stringify(handlerInput, null, 2); (略) let norinori_start = washiganorinori + randomSpearkFact; try{ const queryItems = await docClient.query({ TableName: "norinoriSantaTable", KeyConditionExpression: "#userId = :userId", ExpressionAttributeNames: {"#userId": "userId"}, ExpressionAttributeValues: {":userId": JSONのユーザーID} }).promise(); try{ console.log("queryItems.Items[0].userId: " + queryItems.Items[0].userId); } catch (err){ //よろしくない実装 //初回ユーザー用のオーディオファイルにする norinori_start = first_user; console.log("user Nothing"); } } catch(err){ console.error(`[query Error]: ${JSON.stringify(err)}`); } //DynamoDBにputする情報 var item = { userId: JSONからのユーザーID, }; var params = { TableName: 'テーブル名', Item: item }; //DynamoDBにPut await putDynamo(params); //sessionAttributeを、起動後であることを示すように格納 var sessionAttribute = ''; sessionAttribute = { "SHA_state": "after_start" }; handlerInput.attributesManager.setSessionAttributes(sessionAttribute); //しゃべる音声スキルと、間に0.7秒の待機を挟み、ノリノリの話とユーザーへの操作説明をする let speechText = smartmacchiato + '<break time="0.7s"/>' + norinori_start + ask_next; return handlerInput.responseBuilder .speak('<speak>' + speechText + '</speak>') .reprompt('<speak>' + speechText + '</speak>') .withShouldEndSession(false) .getResponse(); } }; //起動直後、本アプリの継続に「はい」「次」「もっと」「のりのり」「きかせて」と答えた場合の処理 const continueHandler = { canHandle(handlerInput) { return handlerInput.requestEnvelope.request.type === 'IntentRequest' && ((handlerInput.requestEnvelope.request.intent.name === 'AMAZON.YesIntent') || (handlerInput.requestEnvelope.request.intent.name === 'AMAZON.NextIntent') || (handlerInput.requestEnvelope.request.intent.name === 'AMAZON.MoreIntent') || (handlerInput.requestEnvelope.request.intent.name === 'norinoriIntent') || (handlerInput.requestEnvelope.request.intent.name === 'kikitaiIntent') ) && handlerInput.attributesManager.getSessionAttributes().SHA_state == 'after_start'; }, async handle(handlerInput,event) { //サンタ話のうち1つをランダムで選ぶ var factSpeakArr = norinori_speak_array; var factSpearkIndex = Math.floor(Math.random() * factSpeakArr.length); var randomSpearkFact = factSpeakArr[factSpearkIndex]; //サンタ画像のうち1つをランダムで選ぶ var factImgArr = norinori_img_array; var factImgIndex = Math.floor(Math.random() * factImgArr.length); var randomImgFact = factImgArr[factImgIndex]; // Template 6 if (supportsDisplay(handlerInput)){ const myImage1 = new Alexa.ImageHelper() .addImageInstance(randomImgFact.url) .getImage(); const myImage2 = new Alexa.ImageHelper() .addImageInstance(randomImgFact.url) .getImage(); const primaryText = new Alexa.RichTextContentHelper() .withPrimaryText('') .getTextContent(); handlerInput.responseBuilder.addRenderTemplateDirective({ type: 'BodyTemplate6', token: 'string', backButton: 'HIDDEN', backgroundImage: myImage2, image: myImage1, title: "", textContent: primaryText }); } //ランダムに話して、ユーザー操作を促す const speechText = randomSpearkFact + ask_next; return handlerInput.responseBuilder .speak('<speak>' + speechText + '</speak>') .reprompt('<speak>' + speechText + '</speak>') .withShouldEndSession(false) .getResponse(); } }; //DynamoDBにputする関数 function putDynamo(params) { console.log("=== putDynamo function ===" + params); docClient.put(params, function (err, data) { console.log("=== put ==="); if (err) { console.log(err); } else { console.log(data); } }); } // returns true if the skill is running on a device with a display (show|spot) function supportsDisplay(handlerInput) { var hasDisplay = handlerInput.requestEnvelope.context && handlerInput.requestEnvelope.context.System && handlerInput.requestEnvelope.context.System.device && handlerInput.requestEnvelope.context.System.device.supportedInterfaces && handlerInput.requestEnvelope.context.System.device.supportedInterfaces.Display; console.log("Supported Interfaces are" + JSON.stringify(handlerInput.requestEnvelope.context.System.device.supportedInterfaces)); return hasDisplay; }
リジェクト内容で協議させてしまうパターン
僕にとっては、もう慣れているので構わないのですが、リジェクト理由に納得がいかずに、進言したら協議の上、承認されました。
リジェクト理由は 「ノリノリ」は名詞ではないから。
日本語でスキルの呼び出し名を決める際には、原則として名詞を2つにする必要があります。
「ヒロインの告白」みたいな。 「の」は無くてもOKの場合も多いです。
で、納得いかないので以下のように伝えたら承認されました。
1.「ノリノリ」は名詞でも使われる
goo辞書で検索すると、以下のように記載されてます。
[名・形動]《動詞「乗る」の連用形を重ねた語。「ノリノリ」と書くことも多い》調子がよくて気分が高揚していること。乗りがよくて、リズミカルであること。また、そのさま。いけいけ。「乗り乗りな曲で踊る」「乗り乗りムードで一気に勝ち進む」
[名・形動]ってあるじゃん。
2.テンションが高い場合はどう表現するのか
テンションが高い状態を示す場合、具体的にAmazonさんはどういう表現なら良いのか求めました。
そしてその際に、
仮に「ハイテンションなサンタ」にした場合、【ハイテンション】こそ日本語ではないと私は解釈します。 日本語のみで状況・状態を説明するための具体的なガイドラインをください。
と、伝えました。
そしたら通った
いつも通り?、「大至急協議します」のメールが飛んでくるので、しばし待ちます。 Amazonさんから「大至急協議します」のメールが来た場合、たいていその日のうちに返答がきます。
今回は 「協議の上、認められることになりましたので、再申請をお願いします。」
とのことで、再申請したら通りました。
その後のAlexaDevSummitでつかまる
AlexaDevSummitで会場をウロウロしてたら、中の人からお声がけがありました。
A「showさんですよね!この間の件ですが・・・」
僕「(やらかしまくっているので)どの件でしょうかごめんなさi・・・」
A「ノリノリの件です。ご指摘ありがとうございました。あれはたしかに認められないと表現できないですよね。フィードバックありがとうございました!」
僕「こちらこそ、ご対応ありがとうございましたぁぁぁ!!!」
全力で土下座する体制にしようとしましたが、むしろ感謝されました。
何が言いたいかというと、最近、スキル審査結果に対してフィードバックが画面ポチポチで選べるようになったんですけども、審査員側だって、ユーザーからのご意見が欲しいわけです。
明らかに開発者側のミスは置いておいて、リジェクトされたから黙って従うだと、AmazonさんのAlexaスキル審査員さんが独りよがりの神になってしまうわけです。
なので、ちゃんと根拠を示して、自分の意見を伝えると、AmazonのAlexa担当の方々はちゃんと対応してくれますよ。
リジェクトを頂いても、認定されても、フィードバックは送りましょう。 その方がお互いにハッピーだと思います。
以上。
Alexaデザインガイドの本は他のプラットフォームでも応用できる
この記事は ADVENTARの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」 の20日目の記事です。
先日のAlexaDevSummitで以下の本が配られました。
中身は基本的に以下のWebページと同様です。
紙の物理本ですので、オンラインの方が最新であることは確かでしょう。
■Alexaデザインガイド
developer.amazon.com
もう1回振り返るのに最適
Alexaでスキルを作成している方々はすでに上記サイトは確認済みとは思いますが、画面が付いたりマルチモーダルになってきたAlexaについてのデザインガイドは再度読んでおくと、新しい発見があると思います。
もちろん、これからスキルを作成する方々にも極めて有用です。
他にも公式のこのドキュメントは目を通すべき
上記のデザインガイドはもちろん有用ですが、以下も併せて確認することをオススメします。
■音声デザインガイド
Amazon Alexa Voice Design Guide
特にチェックリストが載っているのが良いと思われます。
Alexa以外のプラットフォームでも共通部分は多い
もちろんこれらのドキュメントはAmazonのAlexa用のドキュメント類です。
とはいえ、音声デザインに関しては他社プラットフォームに共通している部分も多く、上記のドキュメントをしっかり読んでいれば他社プラットフォームでも応用が十分聞くと思います。
特にLINE系の場合はClovaに限らず、Messaging APIやLIFFなどに置き換えることもある程度できるのではないでしょうか。
以上