2019/04/06 Alexa Day 2019

1. 交通情報系スキルを事例に見る
日常生活に溶け込むスキル開発のテクニック
2019/04/06 (Sat) Alexa Day 2019
ジョルダン株式会社
山手 政実

2. Profile
山手 政実
2016年4月
ジョルダン株式会社 入社 (現在4年目)
ジョルダン株式会社 営業技術部所属
2017年11月
Alexaとの運命的に出会い、Raspberry Piを使いつつ
スキル開発を始める
2017年12月
Alexa版ジョルダンライブ!をリリース

3. 本題に入る前に宣伝を…

4. ジョルダンが提供するAlexaスキル
現在は、2つのスキルをリリース

5. ジョルダンライブ!
2017年12月5日 サービス開始
(開発期間は1週間前後)
「ジョルダンライブ!」とは
現場から列車の運行状況を生中継する、ユーザ投稿型運行状況提供サービスです。
alexa-sdk(v1)からask-sdk(v2)への移行、
Echo spotでのテンプレート対応など、最新のAlexaに
合わせたアップデートを重ねているスキルです。
ごめんなさい、まだこちらAPL未対応です…

6. バス案内 – 乗換案内シリーズ -
2018年12月12日 サービス開始
Echo show発売と同時にリリース
「バス案内 – 乗換案内シリーズ - 」とは
全国720社以上のバス会社(コミュニティバス)の指定したバス停に到着するバス時
刻を簡単に知ることができるスキルです。
APLは、リリース当初より対応
Alexaスキルでは珍しく、複数デバイスで活用することも
視野に入れて開発しています。

7. 本日のアジェンダ
• スムーズな対話に近づけるためのスキル開発手法
• 「バス案内」で実現したマルチデバイスへの対応方法
VUI/VUXではなく、技術的なトークが中心です

8. スムーズな対話に近づけるための
スキル開発手法

9. 一般的なAlexaスキルの構成
「Alexa、大阪環状線の運行状況を教えて」
お客様 Alexaデバイス Alexaサービス AWS Lambda

10. 一般的なAlexaスキルの構成
音声データをAlexaサービスに送付
お客様 Alexaデバイス Alexaサービス AWS Lambda

11. 一般的なAlexaスキルの構成
解析結果をLambdaに渡す
お客様 Alexaデバイス Alexaサービス AWS Lambda

12. 一般的なAlexaスキルの構成
Lambdaで、処理を行う
お客様 Alexaデバイス Alexaサービス AWS Lambda

13. 一般的なAlexaスキルの構成
Alexaサービスに結果を戻す
お客様 Alexaデバイス Alexaサービス AWS Lambda

14. 一般的なAlexaスキルの構成
処理結果に応じた音声データを生成
音声データをデバイスに返却
お客様 Alexaデバイス Alexaサービス AWS Lambda

15. 一般的なAlexaスキルの構成
「現在、大阪環状線は遅れていないようです」
お客様 Alexaデバイス Alexaサービス AWS Lambda

16. こんなこと、ありませんか？
「Alexa、大阪環状線の運行状況を教えて」
お客様 Alexaデバイス Alexaサービス AWS Lambda

17. こんなこと、ありませんか？
「……… 現在、大阪環状線は遅れていないようです」
微妙に気になる返答までのラグ
お客様 Alexaデバイス Alexaサービス AWS Lambda

18. Lambdaが遅い理由
コールドスタートが影響
• 利用可能コンテナがない、利用可能コンテナ数以上のリクエスト時に発生
• 利用可能コンテナを殺さないように定期的リクエストを行うなどで、コール
ドスタートは減らすことができる
スキルが利用されるタイミングは、読めない
• 時間帯によってリクエスト数が変わるため、100%コールドスタートを抑止す
ることは難しい
※コールドスタート以外にもパッケージ容量やメモリの割り当て量も、実行速度を遅くしている原因になり得る

19. Lambdaの生成フロー
1. (ENIの作成)
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開
5. ランタイム起動・初期化
6. 関数・メソッドの実行
• VPC利用時のみ実行
• 約10~30秒かかる

20. Lambdaの生成フロー
1. (ENIの作成)
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開
5. ランタイム起動・初期化
6. 関数・メソッドの実行
• 指定されたランタイムの取得
• S3からパッケージのダウンロードとZIP
ファイルの展開

21. Lambdaの生成フロー
1. (ENIの作成)
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開
5. ランタイム起動・初期化
6. 関数・メソッドの実行
• 各ランタイムの初期化処理
• グローバルスコープの処理を実行

22. Lambdaの生成フロー
1. (ENIの作成)
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開
5. ランタイム起動・初期化
6. 関数・メソッドの実行 • ハンドラーで指定した関数・メソッドの実行
• ここの処理が課金対象

23. Lambdaの生成フロー
1. (ENIの作成)
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開
5. ランタイム起動・初期化
6. メソッドの実行
全て実行するのがコールドスタート
Cloud Watchの Duration Timeには含まない
コンテナが生きていれば、再利用してStep6のみ実行
→ウォームスタート

24. Not serverless

25. あえてLambda を捨てる
Alexaとのやりとりは、JSONを含むPOSTリクエスト
• 投げられたJSONを処理して、結果を返却できるWebサービスを用意できれば、
スキルとしては動く
Node.js + Express + ask-sdk + forever
• ジョルダンのカスタムスキルは、すべてhttpsホスティング
• デーモン化をして、常にリクエストを待ち受けている

26. ジョルダンのカスタムスキルの構成
お客様 Alexaデバイス
Route53
Alexaサービス
Cloud front ELB
スキルスクリプト向け
EC2インスタンス
スキルスクリプト向け
EC2インスタンス
お気に入り情報用
DynamoDB
乗換案内API
など

27. DEMO

28. 実行速度の比較 (1)
※1 アカウントリンク後の初回起動時には、時刻表検索以外の処理も実行されるため比較対象から外した
※2 並行系統が存在し、日中多くの便が設定されているため
検証条件
• 環境
• Lambda メモリ割り当て量：512MB
• EC2インスタンスタイプ：t2.nano
• スキル
• 「バス案内 –乗換案内シリーズ-」を利用
• アカウントリンク後、1度スキルを起動している ※1
• 検索区間
• 東急バス 「目黒駅」から「元競馬場前」 黒06系統を指定 ※2

29. 実行速度の比較 (2)
実行回数 Lambda https
1 1417.44 ms 918.23 ms
2 1519.69 ms 1108.29 ms
3 1156.68 ms 1235.44 ms
4 1568.00 ms 1595.03 ms
5 1159.74 ms 1133.11 ms
Average 1364.31 ms 1198.02 ms
• リクエストからレスポンスまでの処理時間
・Lambdaは、DurationTime
・httpsは、リクエストからレスポンスまでの時間をconsole.time()で計測

30. 実行速度の比較 (3)
Lambda https
コールドスタート時 3080 ms 2090 ms
ウォームスタート時 2180 ms 2360 ms
• Alexaデバイス上でレスポンスの発話が行われるまでの時間差
※ スキルを呼び出しからレスポンスの発話が開始されるまでの時間を計測

31. 注意点
• リクエスト要件の検証が求められる
 公式ドキュメントに詳細な要件の記載がある
 httpsでホスティングしているスキルは、審査担当者による確認前に自動で、
リクエスト要件が満たされているか確認しているようです
• 検証を行ってくれるnpmモジュールも存在
 「alexa-verifier」など

32. 「バス案内」で実現した
マルチデバイスへの対応方法

33. マルチデバイス対応にこだわった理由
• 普段使うバス停は、１箇所ではないから
• 自宅以外でもAlexaを使うシーンが今後広がることを期待して…
出勤時、家の近くのバス停を使ったり… 帰宅時、最寄駅からのバス停を使ったり…

34. 家の外でもAlexaを使う世の中が近いかもしれない…

35. ユーザー・デバイスを識別するには
• userIdとdeviceIdを活用する
• userId
スキル + アカウントごとにユニーク
• deviceId
スキル + アカウント + デバイスごとにユニーク
参考元：[日本語Alexa] スキルで利用可能な各種IDの一意性調査 - DevelopersIO
スキル内で完結する場合かつ、”発話で“デバイスごとにデータを紐づける場合は、
「userId」と「deviceId」を活用すればマルチデバイス対応は可能

36. カスタムスロットとバス停数
カスタムスロットの上限数を以上のバス停の情報を提供
• カスタムスロット上限数：5万件
• 提供したいバス停の数 ：約23万件
→ 発話から特定のバス停名を抽出することができなかった
アカウントリンクを活用し、アカウントリンクページから普段使
うバス停を登録するようにした

37. アカウントリンクとは
• 既存サービスのユーザーとスキルのユーザーを紐づける機能
• アクセストークンを元に既存サービスの情報を利用する
Alexaサービス 自社Webサービスなど
1.既存サービスへのログイン
2.アクセストークンの発行

38. アクセストークンを取得する方法
• OAuth 2.0認証に対応
• 2種類の認証方法が提供
• Implicit Grant
• Authorization Code Grant
• アクセストークンは、アカウントIDに対して1つ保持される
• スキル上で、識別に用いる値のuserIdやdeviceIdなどは、認証時に取
得できない
どのデバイスからのお気に入り登録のリクエストなのか識別がで
きない

39. マルチデバイス対応方法
• アカウントリンクから登録される情報は、仮情報としてDBに保持
• スキル起動後に、デバイスと仮情報を紐づける
お客様
Alexaアプリ
1.お気に入り候補の登録
【お気に入りの候補の登録】
2.お気に入り候補を
仮情報としてDBに登録
自社 DBサーバー3.アクセストークンを
返却
4.アクセストークンを
紐づけ

40. マルチデバイス対応方法
1.スキルの呼び出し
【デバイスへのお気に入り情報紐づけ – 初回起動 - 】 2.アクセストークンを元に
お気に入りの候補をリクエスト
自社 DBサーバー
3.お気に入り候補を返却
ユーザーデータ用
DynamoDB
4.デバイスIDとお気に入り情報を
ペアにして登録
乗換案内API
など
5.お気に入りバス停の
時刻表データをリクエスト
6.時刻表データの返却
7.時刻表の読み上げ

41. マルチデバイス対応方法
1.スキルの呼び出し
【デバイスのお気に入りを変更する場合 (1) 】
2.アクセストークンを元に
既存の候補を削除
自社 DBサーバー
ユーザーデータ用
DynamoDB
3.デバイスIDに対して
お気に入り変更のフラグを立てる
4. 再度アカウントリンクを促す
5. Alexaアプリからアカウントリンクを行う

42. マルチデバイス対応方法
1.スキルの呼び出し
【デバイスのお気に入りを変更する場合 (2) 】
6.お気に入り登録の
確認
ユーザーデータ用
DynamoDB
自社 DBサーバー
2.userId , deviceIdを元に
お気に入り情報を取得
3.お気に入り情報を返却
<お気に入り変更フラグが立っている>
4.アクセストークンを元に
お気に入りの候補をリクエスト
5.お気に入り候補を返却
※Step6以後、「はい」と発話した場合は時刻表の読み上げ
「いいえ」と発話した場合は、再度アカウントリンクを促す

43. ちょっとした懸念事項…
• Voice Profile利用時のuserId , deviceIdの変化
• 変化する場合は、話者特定まで現在考慮していないので、対話の流れを考
え直す必要が…
• 上手くいけば話者ごとに、お気に入り登録もできるかも…?

44. こんなことできたらいいな
• 外部サービスから利用状況を引っ張れたらな…
• DynamoDBなどに保存しているスキル内データではなく、アカウントに紐
づくdeviceIdなど
音声でカバーできない部分を外部サービスで賄って、より
リッチなスキルを作れるようになる気がするなぁ…
【もし、実現したら…】
声の大きい独り言ですね()

45. まとめ
【スムーズな対話に近づけるための技】
• Lambdaのコールドスタートが、返答が遅れる原因の1つ
 httpsでホスティングすることで、コールドスタートの抑止は可能
 Lambdaのメモリ割り当て量を増やしましょう
【アカウントリンク利用時のマルチデバイス対応】
• アクセストークン以外のユーザー識別手段がない
• アカウントリンクページで操作を完結させない
• 対話によるスキル操作を少し含めることで、カスタムスロット上限を超え
るワードやデバイスごとに設定することが可能に
→よりリッチなスキル作りが可能になる

46. スキルの詳細はこちらから
https://norikae.jorudan.co.jp/ss/alexa/

47. Thank you
ご静聴ありがとうございました