2018.2.11@Alexa Day 2018 神戸三ノ宮で開催された「Alexa Day 2018」での講演資料です

1. How do we connect
VUI to the real services
using Serverless
@yoshidashingo
2018.2.11
Alexa Day 2018

2. 吉田真吾
n バックグラウンド
証券システム基盤開発
p 基盤システム開発、Oracleチューニングなど
エバンジェリスト
p 講演113回(2013年実績)
p AWS設計・構築・移行(2014-2015)
n 現在のしごと
(株) セクションナイン 代表取締役社長
p APN コンサルティングパートナー
p DevOps Dockerize Serverless 支援など
(株) 実績等
p AWSウルトラクイズ
初代チャンピオン (2012年)
p AWS Samurai 2014 / 2016

3. Alexa アプリ
• カスタム対話モデル
• スマートホームスキルAPI
• フラッシュブリーフィング
スキルAPI
• ビデオスキルAPI

4. ・Amazon開発者ポータルアカウント
・AWS Lambda（AWSアカウント）
・alexaアプリ（＋Amazon.co.jpアカウント）

5. How to DESIGN?

6. 音声デザインガイド
1. 目的とユーザー
ストーリーの設定
2. 台本の作成
3. 対話フローの作成
4. スキル構築のための
準備
https://developer.amazon.com/ja/designing-for-voice/design-process/
ひとつのスキルで色々なこと
をやろうとするとインテント
の区別や発話→インテントの
マッピング精度がいまいちに
なりがち

7. 音声デザインガイド
1. 目的とユーザー
ストーリーの設定
2. 台本の作成
3. 対話フローの作成
4. スキル構築のための
準備
https://developer.amazon.com/ja/designing-for-voice/design-process/
実際に声に出し話してみる
• 質問は適切か
• 答えは冗長ではないか
• 次の行動をどう促すか
• 機能性として十分か

8. 音声デザインガイド
1. 目的とユーザー
ストーリーの設定
2. 台本の作成
3. 対話フローの作成
4. スキル構築のための
準備

9. 音声デザインガイド：4. スキル構築のための準備
https://developer.amazon.com/ja/designing-for-voice/design-process/
スキルの「呼び出し名」
インテント
(=Lambdaハンドラー)
スロット
(=Lambda: switch case / value)

10. われわれがつくりたいのは
IVR(自動音声応答システム)
ではない
・声による入力
・ユーザーはコマンドラインのようには
話しかけてくれない

11. 言葉ではなく
意味・文脈を理解する
アシスタント
・動詞が揺れる（聞かせて／教えて／調べて…）
・目的語が抜ける
・指示語（それ）のあつかい、などなど

12. インテントの作成 (Skill Builder)
それぞれのインテントが
Lambdaの別々のハンドラーに
マッピングされる
サンプル発話で動詞の
「ゆれ」を吸収する

13. カスタムスロットの作成 (Skill Builder)
変数化

14. カスタムスロットの作成 (Skill Builder)
スロットの値に別名を
たくさんつけることで
目的語の「ゆれ」を吸
収する

15. 視点
• 会話の文脈によりそのときに最適で複雑なス
テートが存在する（≠チャットボット）
• 予測：サンプル発話やスロットのシノニムで
「ゆれ」を吸収する部分はプラットフォーム側
に移っていくと想定される（すべてユーザーが
設定→辞書から提案→自動でマッピング）
• 予測：Webアプリ、業務システム丸ごと再現で
きる規模のスキルが実現されるようになる（→
より本格的な設計プロセスの必要性）

16. ここまで
• バックエンドを実装する以前に、対話モデルや会話
体験を設計して作り込む必要がある
• 自然に話しかけてどの程度理解してもらえるか？
• 期待する動作をしてくれるか？
• 冗長なやりとりにならないか？
• 言葉のゆらぎを吸収してくれるか？
• ここで促すべき次の行動はなにか？
→ Voice User Interface eXperience Designer
(VUXデザイナー)

17. AWS Lambda
Lambdaが
Alexaカスタムスキルの
実質スタンダード

18. AWS Lambda
• 2014年末 re:Invent にて発表
• サポート言語 2016.12.11現在
• Node.js – v0.10.36, v4.3.2
• Java – Java 8
• Python – Python 2.7
• C# - .NET Core 1.0.1
• ホスト
• Amazon Linux (時々バージョンアップ)
• 実行環境は再利用される
• 初回起動が遅いが再利用時は高速
• 一時ストレージとして /tmp 利用可能（スケールしたり破棄されたりするので
頼らないこと）
• 課金は使った分だけ
• 確保(指定)したメモリ(128MB〜1.5GB) x 実行時間(100ms単位) x 実行回数
• メモリに比例してCPUの割当ても多くなる
http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html

19. パラダイムシフト
• Why The Future Of Software And Apps Is Serverless
by Ken Fromm, VP of Business Development at Iron.io
• コンピューティングリソースの調達リードタイムの短縮
• スタンダローンアプリからの変化（現在のMicroservices）
• クラウドで柔軟にコンピューティングリソースをサービスとして
利用することができる
• サーバーが要らないということではなく、開発者はサーバーにつ
いて「考えなくてもよくなる」
1 2 2 0. 5 52 0 0 2 / 11 2 2-

20. Functions as a Service の台頭
• 特徴
• 実行環境は隠蔽＆プラットフォーム
管理で、必要なのはコードのみ
• コンテナベースで調達リードタイム
を短縮
• 分散実行環境による可用性の確保
• 実行時間のみ課金によるコスト低減
• アーキテクチャにおける責務
• Stateful >> Statelessへ
• 永続データ >> 揮発性
• モノリシック >> Microservices
• バッチ処理 >> イベントドリブン
https://aws.amazon.com/jp/about-aws/events/reinvent-report-2014-pt2/

21. なにがサーバーレス？
FaaS と Functional SaaS について

22. http://www.slideshare.net/acloudguru/ant-stanley-being-serverless

23. サーバーレス
エコシステム
プラットフォーム
開発・運用フレームワーク
開発者

24. プラットフォーム事業者 フレームワークやツール
アプリケーション開発者
サーバーレスエコシステム
• サーバー構築不要
• スケーラブル
• 従量課金 etc…
• API定義と関数コード
の一体管理
• チーム開発（テスト、
デプロイ） etc…
• 企画→開発→デリバリーに
集中
• サービスマネジメント
• etc…

25. サーバーレス
だからこそできることをやる
開発の高速化
運用の省力化

26. 10X Product Development
• 製品がマーケットにフィットす
るかどうかが最も重要である
• ビジネスに関連するコードの開
発時間に極力時間を使うべきで
ある
• 顧客とまわすイテレーションを
最大化すべきである
• 依存性を最小化すべきである：
仕様確定待ちで開発者を待たせ
たり、運用やDBAやその他の開
発者の影響で待たせることを極
力避けるべきである
http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development

27. 10X Product Development
Commercial Search
• 開発者2人ｘ4ヶ月
• TypeScript 13,307行
• 開発者の稼働 95%以上(待ち時間なし)
構成
• Auth: Firebase
• Static Site Hosting: Netlify
• 画像管理: Cloudinary
• 検索: Algolia
ペインポイント
• Firebaseのダッシュボードでは大きなデータセッ
トが扱えない
• RDBMSからFirebaseに移行する開発者のラーニン
グカーブ
http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development

28. まかせっきりでよい？
プロダクトの最終責任について

29. Serverlessness, NoOps and the Tooth Fairy
ベストプラクティス
• 自分のプロダクトの問題はちゃん
と直せる人は自分しかいない
• クリティカルパスを理解する
• できるかぎり小さく維持する
• プロバイダの技術情報や、内部技
術が何に依存しているか理解する
• アウトソース先に問題が起きても、
自身のサービスにおけるそれによる
結果については依然としてあなたが
責任を持たなければいけない
http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy

30. 5つの分類パターン
1. Webアプリケーション
2. 運用業務
3. ストリームデータ処理
4. モバイル・IoTのバックエンド
5. アプリケーション連携のバックエンド

31. Webアプリケーション
1) Serverless Single Page Apps

32. Amazon
Route 53
Amazon S3
(Static Website)
Google+ profile
Cognito
Identity Pools
Lambda DynamoDB
SPA

33. Webアプリケーション
2) CSVアップロード／ダウンロード
HR系事業会社

34. Amazon
Route 53
Amazon S3
(Static Website)
Cognito
User Pools
Lambda RDS
Amazon S3

35. Webアプリケーション
3) REST API

36. REST API
<テーブルデータの
取得・追加・削除
をするAPIだよ

37. Webアプリケーション
4) Serverless CMS
Shifter, Serverless Wordpress

38. https://speakerdeck.com/digitalcube/serverlessconf-tokyo-2016-shifter

39. 運用
5) バッチ処理
日経新聞さんの事例

40. https://speakerdeck.com/ikait/serverless-architecture-supports-nikkeis-paper-viewer

41. 運用
6) オンコールシステム
大手人材系メディア

42. Lambda
DB
P
GI
Lambda
A

43. アプリケーション連携
7) Alexa Skills Set

44. エコちっち
• Alexaの中で妖精を育てる育
成ゲーム
• インテント
• リセット(たまごに戻す)
• エコちっちの状態確認
• ごはん
• ダンス
• お勉強
• トイレ
• 寝かせる
• 起こす

45. エコちっち (デモ)
• 「Alexa、エコちっちでリセットして」
• 「Alexa、エコちっちで元気か教えて」
• 「Alexa、エコちっちでごはんを食べさせて」

46. カード

47. Alexa SDK for Node.js

48. こまった！対話のフロー制御
• [発話]状態確認
→おなかがすいてます。ごはんを食べさせてあげますか？
→はい
→(インテント：状態確認※「ごはん」を呼びたいのに)
• [発話]ダンスを踊らせて
→ダンスを踊らせてあげますか？
→はい
→(インテント：ダンス)

49. ステート
1. ステートの定義
2. ステートに応じたハンドラー
群の定義
3. ハンドラー登録
→ステートに応じて追加した
ハンドラーが呼ばれる

50. こまった！エコちっちの生涯
• エコちっちの生涯＝Lambdaランタイムの
ライフサイクル
• Lambdaが初期化されると「たまご」からスタート
してしまう
→もっと長生きさせたい

51. セッション

52. HRアプリ (デモ)
• 「Alexa、オー人事で佐藤さんの給与グレードを
教えて」
• 「Alexa、オー人事で高橋さんの評価を教えて」
• 「Alexa、オー人事で鈴木さんの上司を教えて」
• 「Alexa、オー人事で人事ニュースを教えて」
• 「Alexa、オー人事で自己評価の進捗を教えて」

53. こまった！スロット別のコマンド制御
• 「Alexa、オー人事で佐藤さんの給与グレードを教
えて」
• 「Alexa、オー人事で高橋さんの評価を教えて」
• 「Alexa、オー人事で鈴木さんの上司を教えて」
• 「Alexa、オー人事で人事ニュースを教えて」
• 「Alexa、オー人事で自己評価の進捗を教えて」
→1つのインテントのスロット別にコマンドがある

54. こまった！スロット別のコマンド制御

55. こまった！スロット別のコマンド制御
• Developerポータルで作成したカスタムスロッ
トの値が、シノニムにひっかかった場合はシノ
ニムの値で入ってくる
→シノニムをすべてcaseに設定する
→追記1：スロット値の「ID (オプション)」を
使うことで対応できる
→追記2：返答するメッセージはスロットの値
(ユーザーが発話した単語)をそのままおうむ返
ししてあげるほうが自然です

56. エコちっちの
ソース規模
(設計当初) 「150行くらいかな？」

57. 816行
ステート x インテント x スロットの組合せが爆発した

58. ステートを制するものが
対話モデルを制す
そして結論

59. まとめ
• リッチなスキルを作る場合はしっかりとした対
話フローや返答内容の設計が必要
• サーバーレスコンポーネントを組み合わせるこ
とでスキルに無限の可能性
• 対話モデルを再現する実装は想像しているより
ずっと大変だけど頑張ろう