期待のネット新技術
呼び掛けにどう応答しているのか？ Amazon EchoやGoogle Homeが動く仕組み
【スマートスピーカーの裏側に迫る】（第1回）
2018年3月6日 06:00
スマートスピーカーは“AIスピーカー”とも呼ばれ、声で呼び掛けて質問すると、応答を返してくれるもの。AmazonやGoogle、LINEなどが発売しているが、その裏側では、どうやって質問に対して音声で回答をおこなっているのだろうか？ 今回は、スマートスピーカーが質問を音声として認識し、これを処理するまでの仕組みと、そのバックエンドに必須となるクラウドサービスの役割について解説する。（編集部）
この連載は基本的に下回り、OSIのネットワーク階層で言うならレイヤー1～レイヤー3あたりがメインではあるが、今回は若干毛色を変えて、昨今流行（？）のスマートスピーカーの話をしてみたい。といっても、相変わらずそのスマートスピーカーのバックエンドの話だったりするのだが。
スマートスピーカーの提供する機能
一般論として、スマートスピーカーがどんな原理で動いているかを簡単にまとめたのが上の図だ。左上が、いわゆるスマートスピーカーそのものである。「Amazon Echo」や「Google Home」などの製品はあるものの、基本的に中身はどれも大して変わらず（とかいうと石が飛んできそうだが）、スマートスピーカーそのものの仕事は、以下の2つしかない。
- ユーザーの音声を取り込んで、これをフロントエンドのクラウドサービスに送り出す
- フロントエンドのクラウドサービスからの返答を音声化して出力する
厳密に言えば、Amazon EchoにしてもGoogle Homeにしても、その他のスマートスピーカーでも、ほとんどがもう1つの機能を持っているが、本質的な機能とは言い難いので、これは後述する。
スマートスピーカーは、この2つの仕事に向けて、それぞれ洗練された以下のような機能を持つ。
- 複数のユーザーからの音声を聞き分ける
- 指向性を持たせる
- ノイズリダクションやエコーキャンセルの機能を搭載する
例えばAmazonの「AVS（Alexa Voice Service）」はこちらに用意されているが、これらの機能をどう実現するかで、各社が差別化を図っているのが分かるかと思う。現在はまだ、音声入力の精度を高めるのがメインだが、これが一段落すると、次は再生する音声の品質を上げる方向に行くだろうことは明白である。この目的で、高度な音声プロセッサが搭載されることも珍しくないだろう。
音声認識と処理実行のプロセス
さて、音声が取り込まれたら、次はこれをネットワーク経由でクラウドサービスに引き渡す必要がある。これはWi-FiやBluetooth経由（今は見当たらないが、そのうち有線LANのポートを持った製品も出てくるかもしれない）だが、そもそも必要とされる帯域が極端に大きくはなく、それこそ32bit MCUにWi-FiやBluetoothのモデムを組み合わせるだけで十分だったりする。
さて、次はフロントエンドのクラウドサービスである。Amazonなら「Alexa」が、Googleならば「Google Assistant Service」がこれに相当する。スマートスピーカーからのリクエストは、まずネットワークのフロントエンド側で接続プロトコルの差などを吸収し、これを経て音声認識ロジックに引き渡される。ここでは、例えば「照明オン」という発音を「照明」「オン」に分解するなど、純粋に音声を認識して、それぞれ言語化する処理を行う。
ここも実は何気なく進化していて、例えばちょっとした方言はここで吸収してくれる。また、「照明」「あかり」「ライト」といった複数の言い回しを「照明」に収束させるなどの機能が搭載され始めたサービスもある。だが、とは言っても発展途中の技術なだけに、必ずしも思ったとおりに収束するとは限らないようだ。
この音声認識ロジックから出てきた言葉をベースに、実際に処理を実行させるのが次のジョブ生成・管理である。ただし、ジョブ生成・管理は別にAIベースでもなんでもなく、単なるリストベースで動作している。例えば「照明」「オン」なら、リストの中から「照明」を探し、その「照明」に対するアクションの一覧の中で「オン」に相当するものと見つけ、その処理を実行するわけだ。
このジョブリストは、「操作する（できる）対象」と「対象に対する可能な操作と実際の動作」の一覧をまとめたもので、Amazonなら「Amazon Skills Kit」、Googleなら「Actions on Google」がこれに相当する。これはある程度のものはAmazonなりGoogleなりが用意するが、もちろん完璧ではないし、新製品が出るたびにメンテナンスはしていられないので、機器メーカーやユーザーの側で追加できるようになっている。逆に言えば、これを追加しないと「照明オン」と呼び掛けても「分かりません」で終わってしまうことになる。
ジョブ生成・管理のロジックでは、処理を終えるとバックエンドあるいは外部のクラウドサービスに対して処理を発行することになる。外部というのは、例えば「東京の温度は？」「日中は13度まで上がります」といった処理に関してであれば、温度情報を持つサービスに問い合わせを行い、これを受け取る形になるためだ。ジョブリストにはこうしたものも含まれている。
それはともかく、「照明オン」をはじめとしたユーザーからの呼び掛けに対しては、「照明をオンにします」、もしくは外部のサービスから得た温度情報などの返答を音声化する必要がある。このために用意されている音声合成ロジックを経由して、音声化されたデータが再びスマートスピーカーに送り返され、最終的にスピーカーで再生されるわけだ。
バックエンドのクラウドサービスで各々のデバイスを管理
こうした音声の入出力プロセスとは別に、バックエンドのクラウドサービスが動いている。例えば「照明」「オン」にしても、「ここで言われている『照明』とは、どの家にあるどの照明のことか？」をまず特定せねばならない。それは当然スマートスピーカーのある場所となるが、実際に分かるのはIPアドレスだけなので、普通に考えれば同一のIPアドレスを持つスマートライト、ということになる。
もっとも、ここで言うIPアドレスは、あくまでルーターのIPアドレスだから、その先のプライベートネットワーク（図で言うホームネットワーク）の構成については分からない。さらに言えば、スマートライトが1つしかなければ問題ないが、複数あれば、どれをオンにするのか？ という問題も出てくる。これはスマートホームを本格的に稼動させようとすると、必ず問題になる点だ。
こうした問題を解消してくれるのが、バックエンドのクラウドサービスになる。Amazonなら「AWS IoT」、Googleなら「Weave」がこれに相当する部分だ。これらは本来、IoTデバイスを管理するためのクラウドサービスではあるが、スマートデバイスの管理も同時にやってくれる。例えば、居間にスマートライトが複数あった場合、「居間の照明をオン」とすると「居間」に属するスマートライトをリストアップし、それぞれのスマートライトに対して照明オンの設定を送る、という作業を行ってくれる。もちろん、事前にそれぞれのスマートライトを、どのグループに属するどんなデバイスなのか登録しておく必要はある。
こうした処理をどう実現しているかは、クラウドサービスごとに実装が異なっているが、これは個々のデバイスごとにサポートする物理層やプロトコルが異なるためだ。その結果は、やはりネットワークフロントエンドを経由して、それぞれのスマートデバイスに送り出される。
スマートデバイス側の通信機能
ということで、やっとスマートデバイスまで話が戻ってきた。スマートデバイスは、バックエンドのクラウドサービスから送られてきた命令を受け取り、これに応じて自身の動作を行うことになる。スマートライトならオンにしたり、輝度を調整したりといった作業だ。ただ、これもその前段階として、まずリクエストを受信するという作業が当然ながら必要で、これがなかなか難題だったりする。
1万円以上の高価格帯デバイスであれば、Wi-Fiのモデムを実装することはそう難しくないが、もっと安価なデバイスだと、Wi-Fiを実装するのは価格面でかなり厳しい。そうした用途では、ZigBee/Thread/Z-Waveのほか、最近やっと多少価格が落ちてきたBLEなどでの接続にならざるを得ない。
問題は、こうした接続では直接クラウドサービス（というかインターネットそのもの）に繋がらないことで、必然的にホームゲートウェイに相当するものが必要となる。また、1つの部屋の中「だけ」ならZigbeeでもBluetoothでもいいのだが、家全体（ここではワンルームマンションではなく、郊外の一軒家を念頭においてほしい）で繋ぐとなると、Wi-FiやBluetoothではリピーターを入れるか、メッシュ接続を考える必要がある（ZigBee/Thread/Z-Waveは最初からメッシュ接続である）。いろいろと、話はややこしいわけだ。
ちなみにスマートデバイスの場合、リクエストを受けても必ずしもレスポンスを返すとは限らない。例えばスマートライトの場合、点く点かないは、端的に言えば見れば分かるからだ。そんなわけで、スマートデバイスからバックエンドのクラウドサービスへのレスポンスは破線になっている。ただその場合、IoTのサービスコアからフロントエンドのジョブ生成・管理へは、照明が「点いた」のではなく照明を「点けた」というレスポンスが返ることになる。
ところで先ほど、スマートスピーカーのもう1つの機能について言及した。例えばGoogle HomeやAmazon Echoは、BGMを鳴らす機能を持っている。これはもちろんフロントエンドの音声合成ロジックで音楽を鳴らすようにしているわけではない。その代わり、スマートスピーカーの中に（スマートスピーカーとは別に）ストリーミング再生プレイヤーの機能がスマートデバイスとして実装されており、これをフロントエンドから起動させるかたちとなっている。
この場合、そのストリーミング再生プレイヤーは自身で直接ネットワーク経由でストリーミングサーバーと接続し、ここから音声データを受け取って再生するという仕組みになっている。これは必ずしもスマートスピーカーに必須の機能とは言えない、というか本来（?）の機能ではないが、現実問題として通常はスマートスピーカーには標準的に搭載されている。
今回は、スマートスピーカーの動作の仕組みと、バックエンドで連携するクラウドサービスの動作について、その概略を解説しました。次回はフロントエンドの実装と、そのキーになるSkillsについて解説する予定です。