この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
本記事はAWS re:Invent 2017のセッション"ALX202 - "Integrate Alexa voice technology into your product with the Alexa Voice Service"のレポートです。
このセッションでは、Alexa対応デバイスを開発するためにAmazonが用意したAlexa Voice Service(AVS)という仕組みについての說明と、AVSを使ったデバイス開発を行うためのSDKと開発キットについての說明が、AmazonのPrincipal Solutions ArchitectであるTravis Grizzelさんによって行われました。
導入
音声対話の進化
- 第1世代
- 単一のマイク
- 常時ON
- スピーカーはどこか別の場所に設置される
- ラジオのように、スピーカーからリスナーへの一方向の話しかけ
- 第2世代
- プッシュ・トゥ・トーク（Push to talk, PTT）
- ビルトインのスピーカー
- 双方向の通話
- 第3世代
- 音声アクティベーション
- ノイズキャンセレーション
- プッシュの必要が無い双方向の通話
- 第4世代
- 360度のマイクカバレッジ
- 複数人の音声検出
- 遠距離の音声検出
Amazon Echo: 最初のAlexa対応機器
Amazon Echoは、
- スピーカー
- マイク
- ネットワークコネクション
を組み合わせただけのシンプルなデバイス
ビジョン：Alexaをあらゆる場所に
現在Alexaは大半がスマートスピーカーの形態で提供されていて、一部スマートフォンでも利用できるような状況だが、サードパーティも巻き込んで、Alexaをあらゆる場所で使えるようにしたい。
Alexa Voice Service (AVS)
AVSとは、
- クラウドベースのAlexaの頭脳である。
- 音声設計をシンプルにし、簡単にデバイスに組み込むことができる
- 無料で使える（AWS利用費は別）
- 成長するAlexaのエコシステムを活用することができる
- より多くの顧客との接点を持てる
シンプルな音声対話モデル
- イベント：デバイスからAVSに送られる情報
- ディレクティブ：AVSからデバイスに送られる情報
- イベントもディレクティブも、JSONのペイロードとしてやりとりがなされる
基本的な動作
- ウェイクワードエンジンがウェイクワード（デフォルトは”Alexa”）を検出すると、ウェイクワードの後に続く音声データストリームがAVSに送信される
- デバイスとAVSとのやりとりは、オーケストレーション層となる”スピーチプラットフォーム”を介して行われる スピーチプラットフォームが各種サブシステムの調停を行う
- デバイスから”Recognizer”イベントがAVSに送信され、 それを受けて音声認識サブシステム(ASR)が生のオーディオファイルをテキストに変換する
- ASRが生成したテキストは自然言語理解(NLU)サブシステムに送られて、 話者の意図（”インテント”）に変換される
- インテントがスキルに渡される
- スキルに渡されたインテントへの応答内容のテキストは、TTS(Text to Speech、音声合成)サブシステムへと渡されて、オーディオファイルへと変換されて、デバイスに送信される。デバイスは単にそのオーディオファイルを再生するだけでよい
タイマーをセットする際のイベントとディレクティブのやりとりの例
- ユーザーが「アレクサ、10分のタイマーをセットして」と発話すると、 発話内容の音声データと共に、”recognizer”イベントがAVSに送信される
- Recognizerイベントと音声データを受け取ったAVS側では、 オーケストレーション層がASR、NLU、Skill、TTSなどのサブシステムを制御して、 最終的に「10分のタイマーをスタートします」という音声データと共に”speak”ディレクティブがユーザー（デバイス）に送信される。発話内容はMP3フォーマットの音声データとしてデバイスに送信される
- Speechディレクティブの発話内容の発話が始まるとただちに”speech started”イベントがデバイスからAlexaに対して送信される
- デバイスの発話が完了するとspeech finished eventがAVSに送信される。それと同時にAVSコントローラーがオーディオプレイヤーでspeakディレクティブで受け取ったMP3を再生する
- Set alertディレクティブがAVSからデバイスに送信されて、Alert Manager storeに保存される
- 10分後、Alert StartedイベントがデバイスからAVSに送信されて、実際にアラートが鳴り出す
デバイスとAVSとの情報交換
- イベントとディレクティブのやりとりはHTTP/2の持続的接続を用いてAVSとデバイス間で行われる
- AVS側からの通知やメッセージを受け取れるように、最初にダウンストリームチャネルを確立する必要がある
AVSデバイスSDK
- 製品レベルのデバイス開発に対応
- C++で開発されたライブラリ
- オーディオ入力の処理
- AVSとの恒常的な接続の確立
- デバイスとAlexaで行われる全てのインタラクションの処理
AVSデバイスSDKの主要な構成要素
- Audio Input Processor (AIP)
- Wake Word Engine
- Alexa Communications Library (ACL)
- Alexa Directive Sequencer Library (ADSL)
- Capability Agents
- Activity Focus Manager Library (AFML)
オーディオのキャプチャから処理まで
- Shared Data Stream
- 単純なリングバッファ
- オーディオデータを継続的に取り込む、使われないデータは廃棄される
- デバイスのメモリにオーディオデータが格納される
- Wake Word Engine
- Shared Data Streamに取り込まれるオーディオデータに対して、デバイス上にある”Alexa”という単語モデルと一致するかどうかの検査を常時行う
- 一致を検出したら、AIPにトリガーを送る
- Audio Input Processor
- トリガーを受けた時のみオーディオデータをAVSに送る
- AVSから“stop directive”を受け取るまでオーディオデータをAVSに送る
AVSとの情報交換
- ACLは恒常的なダウンチャネルのストリームを確立する
- 双方向のイベントストリームをオープンしてクローズする
- ACL(Alexa Communication Library)はディレクティブをADSL(Alexa Directive Sequencer Library)に転送する
命令の伝達
- ACLからディレクティブを受け取る
- ディレクティブを適切な順序で処理する
- ディレクティブを適切なCapability Agentに転送する
ユーザーとの対話の優先順位付け
AFML(Alexa Focus Manager Library)が、ある時点においてどのcapability agentが優先されるのかを制御する
特定の機能の実行
機能毎に用意されたCapability Agentが担当する
| Capability Agent | 機能 |
|---|---|
| Speech Recognizer | スピーチのキャプチャ |
| Speech Synthesizer | スピーチの合成 |
| Alerts | 時刻とアラートの管理 |
| Audio Player | 音楽再生の制御 |
| Speaker | ボリューム制御、ミュートなど |
| Notifications | 通知機能 |
| System | AVSとのステータス通信 |
| PlaybackController | ボタンによる楽曲の開始・停止・スキップ |
| TemplateRuntime | 視覚メタデータをレンダリング |
AVSデバイスSDKとAVSの相互作用
AVSデバイスSDKの特徴
- 移植性が高い
- Linux、Mac OS、ラズベリーパイ向けのSDKを用意
- さまざまなハードウェアプラットフォームへ対応可能
- ガーミンの例
- Alexa対応製品を素早く事情に投入するために、AndroidOS向けにAVSデバイスSDKをクロスコンパイルした
- 拡張性が高い
- 新機能を最小限のグルーコードで追加可能
- Hisense社は、自社製品のAlexa対応TV向けに独自のカードを表示させたかったので、独自のcapability agentを書いた
- モジュラー構造
- 必要なライブラリだけを使い、必要ないものは除外できる
- 好きなWWE(ウェイクワードエンジン)を選ぶことができる
- Sonosは自社開発のAlexa対応製品に独自のメディアプレーヤを搭載した
- アクセシブル
- SDKのC++コードはGithub上で公開
- 製品独自のUXのためにSDKの振る舞いを変更可能
AVSデバイスSDKサンプルアプリを用いたプロトタイピング
- サンプルアプリはgithub上で公開されている
- 商用グレードのSoC(NXPなど)またはラズベリーパイでの開発に対応
- 「アレクサ」という単語でウェイクするウェイクワードエンジンが同梱
ハードウェア開発について
Alexa対応機器を開発する場合、ハードウェアの開発からまずとりかかること。 ハードウェアの開発には１２ヶ月以上かかる。 一方、SDKの実装については通常２〜３ヶ月、早い場合は２〜３週間で完了する
Alexaの製品への組み込み
- 最も簡単な方法は、既存のAlexa対応製品をはめ込むこと
- iHomeクロックライトや、オリジンアコースティックのシーリングマウントなどがこの方法で製品を開発
- 一般的には、リファレンス・デザインを用いたデバイス開発を行う
リファレンス・デザイン
- ホワイトボックスデザイン
- 機能・外装が決まっている
- 外装の色を変えたり、ロゴをつけたり程度はできる（それ以上のことはできない）
- Gemtek社のPuckなど
- フォームファクターリファレンス・デザイン
- ホワイトボックスデザインよりもカスタマイズ性がある
- SDカードポート、HDMIポートの追加など可能
- 内部のハードウェアもある程度カスタマイズできる場合もある
- Gemtek社のVita FFRDなど
- AVSイネーブルドモジュール
- フォームファクター自体からカスタマイズしたい場合はAVSシステムインテグレータが提供するAVSイネーブルモジュールを使う
- 開発キット
- カスタム性の高い製品を開発したい場合は、開発キットを使う
音声モデル
- Touch Activated
- プッシュ＆ホールド型
- Fire TV用のAlexa対応リモコンのような、ボタンをプッシュ＆ホールドしている間に 話した内容がAVSに送信されるもの
- タップトゥトーク型
- Amazon TapやAmazon Echoについているアクションボタンのような、ボタンをタップするとAVSに音声の送信が開始されるもの。発話の終了検出はクラウド側で行われる
- いずれのタイプもwake wordを発する必要無し
- プッシュ＆ホールド型
- Hands-Free Voice Activated
- wake word検出によるハンズフリーアクティベーション
- 5~7フィートくらいまでの距離での利用を想定
- デバイスに向かって話しかけるイメージ
- Far-Field Voice Activated
- Amazon Echoのように、デバイスから離れた場所からでも音声で操作可能
AVSクライアントのハードウェア構成
- マイクアレイボード
- マイク
- ADC(ADコンバータ)
- DSPボード
- DSP(Digital Signal Processor)
- ノイズキャンセレーション、AECなどのオーディオアルゴリズムの実行
- DAC(DAコンバータ)
- DSPからのオーディオ出力をアンプにつなぐ
- DSP(Digital Signal Processor)
- SoCボード
- SoC(System-on-a-Chip)
- WWE(Wake word engine)
- AVSクライアント
- オーディオドライバ
- WiFiインタフェース
- SoC(System-on-a-Chip)
オーディオフロントエンドの構成要素
- オーディオアルゴリズム
- マイクの数
- マイクの配置
作ろうとするデバイス毎に検討する必要がある
オーディオアルゴリズム
ウェイクワードエンジン
ウェイクワードエンジン(Wake word engine,WWE)は、”Alexa”という単語を識別して、音声のクラウドへの送信を開始する
- 一般的にSoC上で実行される
- モデルサイズは一般的に大きいほど精度が良い
- クラウドベースの検証が併用される
- AVSクラウド側でデバイス（クライアント）側のWWEの識別結果をダブルチェックする
ノイズリダクション
- Alexaに話しかけようとする話者の声以外の全ての音は雑音になる
- 雑音が多ければ多いほどAlexaの応答の精度は低下する
- Far-Field型はHands-Free型が全く応答できないようなSNR(SN比,信号と雑音の比率)が低い環境下でも ある程度の精度で応答できる
- 高いSNR環境下ではHands-Free型でもFar-Field型でも大差なく高い精度で応答できる
アコースティックエコーキャンセレーション
- 反響を相殺してSNRを向上させるためにオーディオフィードバックを行う
- オーディオフィードバック
- 音楽のオーディオデータはスピーカーに送られると同時にDSPにも送られてマイクからの入力データから減算される
ビームフォーミング
- 最初に音声が到達したマイクと最後に音声が到達したマイクの組み合わせから、話者の方向を推定する 話者に近い方のマイクのゲインを上げる
ビームフォーミングにおけるデバイスの設置方向について
- ビームフォーミングを行う際、デバイスの設置位置も考慮に入れる必要がある
- EchoやEcho Dotの場合は、テーブルの上のような平面にデバイスの上面を天井に向けて置いて使われることを想定してチューニングされており、天井や壁に設置とりつけた場合はビームフォーミングが適切に機能しない。静かな環境下では動くかもしれないが、騒音があると全然使えなくなる
マイクの配置について
- テーブルトップ型（Echo、Echo Dotなど）
- 円状に配置
- 壁掛け型
- 水平に一直線に配置
マイクの数
- Touch Activated型: １つで十分
- Hands-Free型： ノイズリダクションとユーザーの位置を特定するために最低２つ必要
- Far−Field型： 一般的に4,6,7,8個かそれ以上必要
- マイクの数が多いほど応答精度は良くなるが、数を2倍にしたからといって2倍の効果があるわけではない
- SNRの高い環境では少ないマイクでも高い応答精度が得られる
- SNRが低下するとマイクが7つあっても応答精度は低下する
AVS開発キット
- 高性能なボイスキャプチャー機能の統合
- マイクアレイ、DSP、SoCを含む開発キット
- 先進的なチップセットプロバイダによるサポート
公式Webにさまざまなタイプのキットの情報がある
Alexa対応デバイス開発に取り組む際の留意事項
- ユニークなものを作る
- 単にAmazon Echoや他社製のスマートスピーカーの類似品を作ろうとしない
- UXファーストで考える
- ユーザーに製品をどのように使って欲しいのか、実際のユースケースを考える
- デバイスの用途によっては、マイクはたくさん無くても大丈夫な場合もある
- 元々Alexaを組み込む予定の無かったデバイスにAlexaを搭載しようとすると、搭載のためだけに12ヶ月間の追加工期が必要になる場合がある
- こういう場合は、次のモデルから、最初からAlexaを搭載することを考慮した設計を行うほうがよい
- AVS開発キットを使って開発をはじめる
- 開発キットは認証を通すノウハウを持っているメーカーが開発しているので、適切に使えば認証を通すまでの労力を削減することができる
- AVSデバイスSDKを活用する
- Alexaにはこれからも新しい機能が追加されていくので、SDKもそれに追随して更新される
- デバイス開発に十分な時間を確保して取り組む
- Alexaを製品に搭載するために、だいたい２〜１２ヶ月、長いときには１８ヶ月くらいを要することがある
- Alexaに追加される新しい機能のためにCPUパワー・RAMなどのリソースに余裕をもたせる
- AVS認証に備える
- 何かあったらAmazonのAVSチームに相談する
- AVSのSolution Integratorもいるので、必要に応じて活用する
おわりに
セッションは以下のようなまとめで終わりました。
- 音声は人間のテクノロジーとの関わり方を根本的に変える
- 展望・構想ーAlexaをあらゆる場所に
- Alexaはユーザーがデバイスを操作する新しい手段を提供する
- 高品質なAlexaの実装のためにはハードウェアとソフトウェア両面からの熟慮が必要
- AmazonはAVS SDKを提供することでAlexa対応機器の開発を簡単にできるようにしている
Alexa対応デバイス開発の全体像が掴めるとても勉強になるセッションでした。動画も公開されていますので、興味を持たれた方はご覧になられてはいかがでしょうか？
1
