【レポート】ユーザーを夢中にさせるAlexaスキルの作り方 #reinvent #ALX303

AWS re:Invent 2017

#セッションレポート

#レポート

#AWS

#Amazon Alexa

Yosuke Miyajima

2018.03.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本記事はAWS re:Invent 2017のセッション"ALX303 - The Art and Science of Conversation Applied to Alexa Skills"のレポートです。

このセッションでは、「ボッシュ」というAmazonプライムビデオで人気のドラマを題材にしたスキル（英語版）を例にして、スキルの開発を担当したPullString社の方から、ユーザーを夢中にさせるAlexaスキルを開発する際のノウハウが共有されました。

ここから下には、『ボッシュ』Alexaスキルの結末に触れている記述があります。『ボッシュ』スキルの結末を知りたくない方は、スキルをクリアしてからご覧ください。

導入

ユーザーを夢中にさせる(engagingな)スキルとは
- ユーザーとの会話の往復（マルチターンの対話）により、ストーリーが進行していくようなエンタメ系スキル
- デフォルトの天気スキルのようなスキルは、非常に便利だが、engagingなスキルではない
engagingなスキルの好例が、Amazonプライムビデオのドラマ「Bosch(ボッシュ)」を題材にしたスキル
- Choose-your-own-adventure形式のゲームスキル
  - インタラクティブなラジオドラマ
- ユーザーは、ロサンゼルス市警の刑事になりきって、事件を解決する
- 開発は、Pixar社のスタッフが中心となって設立された、Conputer Conversationのスペシャリスト集団であるPullstring社が担当した

会話設計について

スキル開発からデプロイするところまで会話デザイナー(Conversation Designer)という役割が担当した
- エンジニアチームが開発したオーサリングツールを使用して、コーディングする必要を無くした
- エンジニアチームの役割は、会話デザイナーがスキルの中身に注力できるような環境の構築、ツールの開発を行うこと
- インテント、サンプル発話、スロットの設計も会話デザイナーが担当

『ボッシュ』スキルの会話設計

「プロンプト」と呼ばれる、これから作ろうとするスキルのコンテンツのタネ・制約条件となる一文をまず作成した
- 『ボッシュ』スキルのプロンプト：

『ボッシュ』の最新シーズンに関係した探偵ミステリーもののインタラクティブドラマ

プロンプトを起点にして、以下を行った
- ユーザーの属性の明確化
- コンテンツのソースの収集
- コンテンツの世界観を豊かにするための調査
『ボッシュ』の場合
- ユーザーの属性の明確化
  - ドラマのファン
- コンテンツのソースの収集
  - ドラマのエピソード
  - 原作の小説
  - 原作者へのインタビュー
  - ドラマのサウンドトラックなど
- コンテンツの世界観を豊かにするための調査
  - 舞台となるロサンゼルスの市警、ホテルについての調査
  - コールガール、ハッカーなどの登場人物にリアリティを持たせるための調査など
プロンプトを作り、上記作業を行ったら、「ピッチ」を作成する

「ピッチ」の作成

ピッチには、コンテンツの作成を始めるための起点となる主要な情報を網羅したあらすじのようなもの
- 『ボッシュ』スキルのピッチ（抜粋）：

アナベル・クローは『ボッシュ』シーズン３に登場するコールガールで、ある殺人事件の容疑者である。彼女はボッシュにボイスメールを残す。その内容は次のようなものである：「友人であるノラがトラブルに巻き込まれている。ノラはあるクライアントとのトラブルを抱えている。そのクライアントは既婚者で、ノラと駆け落ちしたいと言っていた。誰もここ数日ノラの行方を知らない。ノラが何かとても悪い事件に巻き込まれたのではないかと心配している。調査をしてほしい」ユーザーはロス市警に着任して数週間の新人刑事で、ボッシュはユーザーにこの件を秘密裏に調査することを依頼する。

物語の展開について

ユーザーを夢中にさせるために、「ストーリー・アーク」構造にする
- ストーリー・アークは、何回かに分けて語られる一連のストーリーが、クライマックスに向けて徐々に盛り上がっていく展開となるような構造のこと
- インタラクティブドラマは舞台、映画、テレビなどの一方通行のメディアと違って、ユーザーとの対話のある双方向のメディアなので、ストーリー展開を考えるうえでユーザーとの対話を考慮する必要がある

ゲームの進行について

『ボッシュ』スキルでは、時間と予算の制約から、以下のような構成となった
- ３つの大きなストーリーライン
  - ハッピーエンドに至るストーリーラインは１つだけ
  - 各ストーリーライン毎に一連の正解・不正解の2択の選択肢を繰り返し提示して、不正解の選択肢が選ばれたらその時点でゲームは終了（バッドエンド）
他の同系統(Choose Your Own Adventureゲーム形式）のスキルには、もっと複雑なストーリー構造のものもある

ストーリー・アーク構造の『ボッシュ』スキルへの適用

３つのストーリーラインいずれにおいても、ストーリーの盛り上がりを演出するために、各ストーリーラインごとにストーリー・アーク構造を適用した
- そのために行った具体的な施策：
  - ストーリーの展開に”原因と結果”の構造を導入すること
    - ユーザーが選んだ行動の結果、物語の核心に近づく
  - ストーリーの進行に時間の概念を導入すること
  - ユーザーが誤った選択を行うと、事件の解決するのに使える時間が減る
  - ストーリーが進むにつれて、
    - より多くの登場人物を出す
    - より多くの効果音を使う
    - ナレーターの話すスピードを速くする

会話設計における考慮事項

ユーザーに提示する選択肢を可能な限りシンプルにする
- 2~3までに留めることで、聞き手にとって記憶に留めやすく、かつ聞き返しても負担にならない
コンテンツが散漫になることを避ける
- 「illusion of choice」という手法で対処する
  - ストーリーの進行に影響の無い内容の選択肢をユーザーに提示して選択をさせて、結果を描写した後ストーリーの本筋に戻す手法
    - ストーリーが散漫になることを避けつつ、ユーザーをストーリーに惹き付ける効果を得られる
  - 声優の声の録音（ボイスオーバー）や効果音を使っている場合は、やった分だけ制作コストが増えるので要注意
書いたストーリーは声に出して読み上げる
- 自分で読み上げてみて不自然と感じるのなら、他人が聞いた時も不自然に感じる
AlexaのTTS（Text to Speech,音声合成)を使う場合は、Alexaもストーリー上のキャラクターとして扱うこと
- 『ボッシュ』の場合はAlexaのTTSは使わなかった
- 『ボッシュ』と同じくAmazonプライムビデオで人気の番組『グランド・ツアー』のスキルではAlexaと声優（番組の登場人物）の掛け合いが行われた
ボイスオーバーで「アレクサ」という発話をさせてはいけない
- ウェイクワードエンジンが反応してしまい、スキルが意図しない動作をしてしまうと思われる
ユーザーを物語の登場人物になった気分にさせること
- サンプル発話をできるだけたくさん定義することが必要
"the zen of fallbacks"
- ユーザーが想定外の発話をした時や音声認識に誤りがあった時にも、「すいません、わかりません」のような機械的な応答を返すのではなく、ユーザーが物語の世界の中にいる気分を損なわないような応答を返すようにする
ユーザーが発する可能性のある、スキルに関連はするが、話の筋には無関係な内容の発話についてもサンプル発話として定義しておき、それらしい応答を返す

テストにおける考慮事項

テストしながら、コンテンツのリバイズを行う
恒常的に音声認識が失敗するケースは、失敗する単語を事前に定義してエラーを回避する
- 英語の場合は、地域（北米、英国、インドなど）の違いによっても認識結果が異なる場合があるので、地域を切り替えてのテストも行うこと
『ボッシュ』スキルのように大規模なスキルではあらゆる対話の経路をテストすることは難しいので、主要な経路を通るように調整したランダムテストを活用した
ユーザーテストを行う
- スキルのバグを見つけるだけでなく、開発者では持て無いエンドユーザー観点からのスキルの改善点が見つかることも期待

プロジェクトマネジメントにおける考慮事項

『ボッシュ』スキルのプロジェクトマネジメント

「Bosch」スキルの公開は、ドラマのシーズン３公開中に行う必要があった
- TTSオンリーなら、余裕で間に合うが、『ボッシュ』スキルではボイスオーバーを全面的に採用することになった
- ボイスオーバーでクオリティをあげようとすると、間に合わない
- TTSベースでスキル開発を進めつつ、並行してボイスオーバーの収録を進めることで、間に合わせた
ボイスオーバーする場合は、しない場合の予算に対して少なくとも30~50％上乗せするようにしている

コスト要因について

TTSのみ、TTS+ボイスオーバーいずれでも共通のコスト要因
- 脚本・台本・シナリオなどのライティング
- エンジニアリングサポート・ソリューションアーキテクトの人件費
- QA(品質保証)のコスト
- 申請サポート
- スキルの開発・構築
ボイスオーバーを行う場合の追加コスト
- オーディオエンジニアリングと編集
- オーディオデザイン（音楽、音声、効果音）
- 声優
- 追加のマネジメントコスト
- 追加のQAコスト

スケジュール管理について

TTSのみ、TTS+ボイスオーバーいずれでも共通のプロセス
1. スキルの設計
2. スキルの実装
3. QA
4. 審査提出
ボイスオーバーを行う場合のプロセス
1. オーディオデザイン + 音楽/効果音
2. レコーディング
3. 編集
共通プロセスと並行して、ボイスオーバーのプロセスを進めることでスケジュールに間に合わせた
- プロセスを並行させることで、共通プロセス完了までに要する期間は増大した
TTS＋最小限のオーディーデータの状態でスキルのQAを終わらせ申請に出すということを行った
- 事前にAmazonのSA(Solution Architect)と調整した
- それと並行してボイスオーバーの編集を行い、スキルのローンチまでに差し替えを完了させた

技術面における考慮事項

コンテンツ作成は得意な人にまかせて、エンジニアはコンテンツを作る人が楽になるようなツールを作ることに専念すること
- コンテンツ作成担当
  - 作ろうとするスキルが扱う題材の専門家
  - 脚本・台本・シナリオを書くスキルを持った人
  - ユーザーエクスペリエンスデザイナー
  - VUIに精通した人

オーディオ面の考慮事項

SSMLで音声(MP3)を使う場合の制限事項
- サンプリングレートは16kHzの制限がある
- １回のレスポンス中に、オーディオファイル５つまで、の制限がある
- シングルトラック
  - １つのファイルに音声・BGM・効果音などをまとめる必要がある
- 再生できる音声データは最長９０秒まで(複数ファイルを使う場合は合計で９０秒まで)、と制限されている(2017/9現在)
英語のように、複数の国をサポートしている言語については国によるアクセントの違いがあるため、それぞれの国ごとにTTSの調整が必要