期待のネット新技術

クラウドのバックエンドは発展途上、無数のデバイスと多様なプラットフォームが乱立

【スマートスピーカーの裏側に迫る】(第3回)

 スマートスピーカーは“AIスピーカー”とも呼ばれ、声で呼び掛けて質問すると、応答を返してくれるもの。AmazonやGoogle、LINE、Appleなどが発売しているが、その裏側では、どうやって質問に対して音声で応答しているのだろうか? 今回は、スマートスピーカーに呼び掛けによって通じてコントロールされる対象であるバックエンド側のデバイスを、クラウドサービスへ接続するための方式とその標準化などを解説する。(編集部)

無数のデバイスが接続されるクラウドサービスのバックエンド

 比較的見えやすいスマートスピーカーからクラウドサービスまでのフロントエンドに対して、バックエンド側は非常に見えにくくなっている。その理由の1つは、スマートスピーカーなどから操作する対象となるデバイスの数や種類が無数にある、ということだろうか。1回目にはバックエンド側の接続を簡略化した図を掲載したが、実際には、以下の図のようなシナリオが考えられる。

フロントエンドに直接接続されるサービス

 前回の例で言えば、これを利用して、それこそ時刻や温度といった情報は取得する。

フロントエンドに直接接続するデバイス

 上の図では冷蔵庫にしているが、これは冗談ではなく、実際にSamsungはクラウドに直結できる「Family Hub」というスマート冷蔵庫をラインナップしている。価格は一番安いもので約3500ドルだ。

 こうしたデバイスは、フロントエンドのクラウドサービスと直接コミュニケーションするために、インターネットアクセス機能や多少の演算能力が必要になる。このため、実質的にはPCやスマートフォンと同等レベルの機能を内蔵することになり、価格もそれなりにならざるを得ない。現在はGoogleの傘下にあるNestのサーモスタットなども、ここに分類されるだろう。

インテリジェンスゲートウェイ経由で接続するデバイス

 このインテリジェンスゲートウェイとは、ローカルネットワーク内でバックエンドのクラウドサービスの代わりとなるようなのルーターである。実際Amazonはこの目的のために、「AWS Greengrass」を2016年12月に発表している。これをローカル側に置き、その先にさまざまなデバイスを接続するかたちだ。このケースでは、デバイス(ここではスマートエアコンとしている)は、必ずしもインターネット接続機能は必要ない。

バックエンドクラウドサービスと、さらに必要ならホームゲートウェイ

 現実問題として、特に日本ではほとんど見かけないものの、従来“スマートホーム”として語られてきた本命がこの構成。対象物となるのは、それこそ照明、ドアロック、カーテン制御のほか、温度/湿度/環境/照度/防犯/火災などのセンサー類などだ。こうしたものは、いずれも低価格化へのニーズが強い。

デバイスの低価格化に必須な軽量プラットフォーム

 例として、米国では「Smart Bulb」と呼ばれる、いわゆる“スマートライト”を挙げてみよう。Philipsの「Hue」は最近低価格化が進んできたが、原稿執筆時点のAmazon.comでの価格は4個パックで49.96ドル。一方、スマートではない、ただのLED BulbはAmazon Basicだと6個パックで19.99ドルだ(いずれも60W相当)。

 1個あたりの単価ではHueの12.49ドルに対して3.33ドルなので、スマートライトになることで9ドルほど上乗せされる格好だ。1個か2個だけならこの価格差は許容されるだろうが、特に廿楽が広い上に間接照明を多用する米国では、必然的に個数が増える。同等とは言わないまでも、せいぜい2倍程度まで価格が下がらないと、本格的な普及は難しいだろう。

 これは量産効果だけでは解決は難しい。要するに、搭載する通信回路とLED制御回路の原価をあわせて3ドル未満程度まで下げないといけないからだ。この原価でフロントエンド側のクラウドサービスと通信しろというのが、土台無理な話である。

 そこで、こうしたところに向け、クラウドベンダー各社では、軽量なプラットフォームを提供している。以下はいずれも、MCU(Micro Controller Unit)の上で動く軽量の「RTOS(Realtime OS)」と、クラウドコネクティビティ(厳密にはクラウドもしくはホームゲートウェイまで)および、これに対応したクラウドサービスをパッケージにしたものだ。Windows 10 IoT CoreだけはMPU(Micro Processing Unit)がターゲットとなる。MCUとMPUの違いについてはこちらを参考にしてほしい。

クラウドベンダープラットフォーム
AmazonAmazon FreeRTOS + AWS IoT
Googlembed OS + Cloud IoT Core
MicrosoftWindows 10 IoT Core + Azure IoT

 ただ業界には、これ以外にも多数のソリューションがある。主要なMCUのベンダーはいずれも自社でRTOSもしくはこれに順ずるものを提供しており、ほかにもExpressLogicの「ThreadX」や、Micriumの「Micrium OS」、国内でも「μITRON」、「TOPPERS」など、製品やソリューションで言えば2けた以上の数が存在する。

多様なコネクティビティ、標準化も規格が乱立

 一方、コネクティビティに関しては、まず物理的なレイヤーで言えばWi-Fi以外にBluetooth/Bluetooth Mesh、ZigBee、Thread、Z-Wave、etc...とこちらも各種あり、国内ではWi-Sunもこの中に入る。主要なプラットフォームはこの大半をサポートするが、例えばWi-SunだとμITRON以外は独自RTOSしかない、といったケースもある。プロトコルとしてもTCP/IPを必ずしも実装しているとは限らず、6LoWPAN(IPv6 over Low-Power Wireless Personal Area Networks)をベースにしたThreadはともかく、Z-WaveもそのものではTCP/IPをサポートしていない。このため、これらはクラウドへの直接のコネクティビティを持たないため、いずれもホームゲートウェイを間に挟んで接続するのが基本のかたちになる。

 そしてまた、クラウドサービスの側も、実は数多く存在している。検索エンジンで“IoT クラウド”を探せば、上に挙げた3つ以外のクラウドサービスが山ほど見つかるはずだ。これらは、バックエンド側のクラウドサービスとして利用できるものとなっている。

 ただし、コネクティビティが確保されればスマートスピーカーからすぐに使えるようになるかというと、技術的には不可能ではないが、現実的にはまだ難しい。スマートライトを例に取れば、PhilipsのHue、Creeの「Connected LED Bulb」、Eufyの「Lumos」、GEの「Link Connected LED」、MiPowの「Playbulb」など多数の製品が世の中に存在するが、これらは接続方法や調整方法がすべて異なる。

 もちろん、どれか1社の製品だけを使うのであれば、対応するホームゲートウェイを使えば済むわけだが、複数の製品が混在した環境では、相互運用性が維持できない。そこで業界はいくつもの標準化団体や組織を作り、「コネクティビティが確保された上で、その上位で相互運用性を確保する」ための規格策定を進めた。

 これによって、スマートライトであれば、オン・オフ/照度/色温度といった項目をまとめた“照明”というプロファイルを作り、これに対する統一的な操作法を定めることで、HueだろうがLumosだろうが、どの製品でも同じように操作できるようにしよう、という話だ。

 ただ、これにも問題がある。それはメジャーな規格だけでもすでに乱立していることで、その一部が以下である。

標準化団体・企業技術・規格
AllSeen(Qualcomm)Alljoyn
OIC/OCF(Intelその他)IoTivity
GoogleWeave
AppleHomeKit

 Microsoftは元々「Alljoyn」に賛同しており、例えばWindows 10は標準で対応している。また「OIC(Open Interconnect Consortium)」はUPnP(Universal PnP)を吸収した後で「OCF(Open Connectivity Foundation)」という組織に鞍替えしたが、ここにQualcommが加わることになり、OCFとAlljoynが合併した(存続組織はOCF)。現在は、OCFの傘下にAllJoynとIoTivityという2つの規格があるが、これは最終的にIoTivityにまとまる形になると思われる。

 そんなわけで現在は、このAllJoyn/IoTivityが一番勢力が大きい。もっともここで言う「勢力」をどう判断するのかは難しい。Z-WaveやZigBeeは昔から通信プロトコルだけでなく相互運用性に向けたプロファイル策定までをカバーしていた。特にZ-Waveは実際に多くの製品が出荷されて利用されている。Appleはお得意の囲い込み戦略で自身の顧客をがっちりつかんでいる。GoogleのWeaveは、Androidが標準でサポートすることになるので、利用できる機器の数では猛烈に多くなる。といった具合だからだ。

 余談ながら、Weaveには現在、GoogleのWeaveと、Google傘下であるNestの開発したNest Weaveの2種類があるが、最終的に後者に統合されていくことが発表されている。

スマートスピーカーのエコシステム構築に向け、バックエンド側は発展途上

 面白いのは、フロントエンドでは王者とも言える地位にあるAmazonが、コネクティビティに関しては何の標準化作業も行っていないことだ。この結果、「Alexaから使えるけれど、機器そのものはOCF対応」「Alexaから使えるけれど、機器そのものはZ-Waveで接続」といったかたちになっている。

 この部分については、今後も当面は混沌とした状態が続くのは間違いない。現状、“Alexa対応”や“Google Assitant対応”などと称しているスマートスピーカー以外の機器は、ほとんどがフロントエンドに直接接続可能な高価格帯デバイスに限られている。

 先のPhilips Hueにしても、“Alexa対応”と称されてはいるが、実態はHueそのものではなく、Hue用のホームゲートウェイがAlexaに対応しているだけの話で、HomeKitやWeave(Nestへの対応を表明している)、さらにそのほかの規格にも対応しているが、これはホームゲートウェイがそれぞれに対応するかたちでしかない。

 そして機器が増えてくると、ベンダーごと、下手をすると製品ごとに、こうしたホームゲートウェイが山のように増えてゆき、互いに干渉し始めるだろう。そのうち、複数ベンダーの製品に対応した“スマートホームゲートウェイ”なるものが出てきて……、というあたりまでは、なんとなく予測可能な範囲である。

 そうした意味では、スマートスピーカーのエコシステム構築に向け、まだバックエンド側は発展途上というか初期段階にしかないことを理解する必要がある。このあたりが今後どう発展していくか次第で、使い勝手はどんどん変わっていくが、これを現時点で見通すのは不可能だ。

 今回は、接続方式や標準規格が乱立するスマートスピーカーのバックエンドについて解説しました。次回は、「IFTTT」をはじめとした、サードパーティーが提供するサービスについて解説する予定です。

大原 雄介

フリーのテクニカルライター。CPUやメモリ、チップセットから通信関係、OS、データベース、医療関係まで得意分野は多岐に渡る。ホームページはhttp://www.yusuke-ohara.com/