Eddystone ロゴ

iBeaconに強力な対抗馬~Google、BLEを基礎とするEddystoneをオープンソースで発表~

  • このエントリーをはてなブックマークに追加

by [2015年8月03日]

Eddystone ロゴ

Eddystone ロゴ

2.4GHz帯を利用する無線通信規格の1つであるBluetoothは、その取り扱いの簡便さからノートパソコン、タブレット、携帯電話、そしてスマートフォンといったモバイル機器だけでなく、ソニー・コンピュータエンタテインメントのPlayStation 3の標準添付ジョイパッドである「DualShock 3」、あるいはかつての標準添付ジョイパッドであった「SIXAXIS」をはじめとする家庭用ゲーム機の入出力デバイスにおいても、幅広く利用されています。

そんなBluetoothですが、実は2009年4月発表のバージョン3.0と、同年12月発表のバージョン4.0以降の間には、相互互換性がありません。

具体的に言うと、バージョン3.0以前にしか対応しないホストデバイスでは、バージョン4.0以降に対応する各種機器との間で通信ができないのです。

逆に、バージョン4.0以降対応のホストデバイスでは、従来のバージョン2.1あるいは3.0とバージョン4.0以降の両対応を実現していますが、これはBluetooth 2.1あるいは3.0の通信モジュールとBluetooth 4.0以降の通信モジュールを両方搭載し、(利用する周波数帯が同じであるため共用できる)電波の送受信モジュールだけ共用しているという、それぞれのホストデバイスを別個に搭載しているのとほとんど変わりの無い状態での「対応」であって、決してクレバーな解決策とは言えないような力尽くのコンセプトで実現した、かなり煩雑な仕組みになっています。

何故こんな煩雑なことになったかと言えば、一つにはバージョン4.0で大幅に低消費電力動作を可能とするための新仕様「Bluetooth Low Energy(BLE)」が採用されたためです。

このBLE、いわゆるボタン電池1つで数年間も通信機能を維持できるほどの超低消費電力動作を実現しているのですが、その反面データ通信速度そのものはバージョン3.0の高速モードである3.0+HSと比較して1/24の1Mbpsが上限と著しく低くなっていて、低消費電力動作を実現する必要からこの規格に対応する機器同士の通信にはこれまでのBluetoothのそれと比べると互換性がありません。

つまり、同じBluetoothという名前でひとくくりにされているので誤解があるのですが、Bluetooth バージョン2.1あるいは3.0と4.0は、同じ周波数帯を利用してはいるものの用途も挙動も異なる別種規格であると考えればよく(※注1)、本来ならば4.0はBluetoothではない別の規格名を与えられて然るべき新規格であったと言えるのです。

 ※注1:先に触れたBluetooth 4.0対応ホストデバイスで2.1あるいは3.0と4.0の通信モジュールが完全に二重化されてしまっている、というのも、そもそも同じ周波数帯を利用する以外は根本的に全く別の規格であったためだ、と考えれば理解しやすいでしょう。なお、当初このBluetooth 4.0相当の新規格については「Wibree」という別の新名称が与えられていました。

そして、それだけ性質が異なるということは、搭載されるべき機器の種類も当然に異なってくるということで、Bluetooth 4.0以降のBLEに対応するデバイスでは、これまでのBluetooth対応機器では考えられなかったような新しい提案が幾つも現れています。

その中でも特に注目されているのが、Beacon(ビーコン)と呼ばれる技術です。

このBeaconについては端末側での対応もOSでのソフトウェア的なサポートも、いずれもAppleが先行して実現しており、以前ご紹介した「江ノ電なび」のように既にほとんど実用と大差の無いシステムを構築し、実証実験段階にあるケースも少なくありません。

一方、Androidの開発元であるGoogleは、これまでこのBeacon技術について明らかに関心は示していたものの、端末メーカー各社などに出荷される端末へのBluetooth 4.0以降のサポートを強く要請することもなければ、OS側でこの技術に積極的に対応することもありませんでした。

Appleが2011年発売のiPhone 4sの段階で既にBluetooth 4.0を搭載し、以降のiOS対応端末全機種に標準搭載したことと、以後もiOSでかなり積極的に「iBeacon」への対応を進めてきたことと比較すると、Googleのこの沈黙は不気味ですらありました。

しかし、このほどGoogleから発表されたBLE Beaconフォーマットである「Eddystone」では、同社がIoTで重要な位置づけにあると考えられているこのBeacon技術について、Androidでの普及を本格的に推進する意思があるばかりか、先行する「iBeacon」を代替し駆逐することまで視野に入れた、戦略的展開を企図していることが明らかになりました。

そこで今回は、この「Eddystone」と「iBeacon」を中心に、Beacon技術について考えてみたいと思います。

じゃんけんの後出しは有利?

先行して普及が進みつつある「iBeacon」に対し、「Eddystone」には2つばかり有利な点があります。

1つ目は、「iBeacon」のホストデバイスとなれるのが、iOSを搭載するデバイスに限定されていたのに対し、この「Eddystone」ではAndroidをOSとして搭載しているデバイスだけでなく、iOS搭載デバイスも対象とするマルチプラットホーム対応となっていることです。

「iBeacon」の発表時点で「Eddystone」は影も形もなかったのですから、「iBeacon」がマルチプラットホーム対応を謳っていなかったのは無理ない話というか、当然の話です。

またそもそも「iBeacon」が発表された当時、市販されていたAndroid端末ではサムスンのGALAXYシリーズなどのごく限られた機種を除くと、全くと言って良いほどBluetooth 4.0が普及も搭載もされておらず、Beacon技術を普及させるどころか、その際にホストとなるべき機種本体の側にそもそもBluetooth 4.0対応のホストコントローラが搭載されていないという、かなり立ち後れた状態でした。

このあたりの事情を考えれば、今回のこれはもう完全にじゃんけんで後出しを行った側の無理な主張みたいな話です。

そして、その「後出しじゃんけん」でなお残る不利な点を補うのが、この「Eddystone」の「オープンソース」(Apache v2.0準拠)化です。

「iBeacon」は基本的に全てがプロプライエタリでAppleが全てをコントロールする仕組みになっていた訳ですが、こちらの「Eddystone」はそのプロジェクトに含まれるプログラム類のソースコードまで全て公開され、かつ許諾条件の範囲内での自由な改変を許すようになっているのです。

こうなっていれば、例えば「Eddystone」対応のアプリを書く場合に、何かバグが発見されてもOS側の「Eddystone」の挙動はソースコードを追跡することでその原因の切り分けや特定を楽に行えるようになります。

「iBeacon」は善し悪しはともかくとして、OSそのものを含めサービスを実行するコードがブラックボックス化されているため、その挙動についてはそうしたブラックボックスに対するコードの実行と、それによる挙動の切り分け作業が必要となります。

要するに、Androidの場合はGoogle Playをはじめとするプロプライエタリなコードに依存する一部のアプリやサービスを別にすれば、基本的にそのサービスの側の挙動は既に明らかになっているため対策しやすいのに対し、iOSではOS本体とそのサービスがブラックボックスであるため扱いづらい部分があったということなのです。

このあたりは、Androidでの成功事例に倣ったということなのでしょうが、Beacon技術の仕組みとその性質を考えると、後述するように少し危うい印象を受ける部分もあります。

しかし、特別なライセンス料を必要としない。そしてコードについて改変自由のオープンソースプロジェクトは、それ故に多くの開発者を引きつけるのも確かで、その観点ではこの「Eddystone」が一定程度以上の成功を収めるであろうことは、ほぼ確実と考えてよろしいのではないでしょうか。

目玉機能がはらむ問題

さて、この「Eddystone」では、後発なるが故に先行する「iBeacon」をお手本としつつも、それにない新機能を搭載することが行われています。

「Eddystone」で新たに搭載された目玉機能、それはBeaconからウェブページのURLを送信し,それを利用して情報のやりとりを行う機能です。

これは元々Googleが昨年10月に「Physical Web」というプロジェクトの一部として発表していたIoT向けの技術です。

仕組みはかなりシンプルで、この機能に対応するBeaconはあるURLを短縮したコードを定期的に発信し続けていて、そのBeaconに接近したデバイスがURLを受け取ってそこから情報を取得するようになっています。

情報取得に当たってはBeaconで発信できるデータ量が極端に制限されることから、Resolver(リゾルバ)というURL短縮サービスの仕組みが用いられていて、間接的に情報をやりとりする仕組みになっていたりします。

もっとも、これはつまりWebブラウザが搭載されハードウェア的にBluetooth 4.0に対応している端末であれば、特別な専用アプリのインストールなしでBeaconが提供する情報を享受することができるようになっているということなのです。

一見、これは大変に便利かつ有用な新機能に見えるのですが、少なくとも筆者の判断する限り、これはBeaconの設置者あるいは情報の発信者が全て善意をもって周囲に接していることが大前提となっていて、例えばBeaconに悪意あるサイトのURL、例えばスパムサイトやウィルス配信サイトなどのURLを発信させる、といったことを行うのは、全く考慮も想定もしていないように見えます(※注2)。

 ※注2:「Eddystone-URL」と名付けられたEddystone固有のURL用送出フレームタイプでは、URLのスキーマと最大17バイト長のURL(この長さ故に短縮URL以外扱えません)以外ほぼ何も送信しておらず、少なくともBeaconから送出された情報だけでは、そのアドレスについての詳細な情報、例えばスパムサイトなのかどうかを判別する情報を得ることはできません。

つまり、そうしたURLやデータを受け取る側のWebブラウザ、あるいはそれらの挙動を監視するアンチウィルスソフトなどでそうしたURLについて一定の安全性を確認し保証する仕組みを確立しないことには、この機能があればスパム業者やウィルス制作者たちは(例えば他の真っ当な商用Beaconの群れの中に悪意あるBeaconを隠し仕込んでおくなどするだけで)いくらでも利用者にスパムメールを押しつけたりウィルスに感染させたりさせることができるようになってしまうことが危惧されます。

一旦Beaconの情報を対応専用アプリで受け取って、そのアプリ上でそれらを表示させる「iBeacon」のような仕組みであれば、こうしたことはそもそも仕組み的にできない(※注3)わけでありまして、その観点ではURL発信に対応しない「iBeacon」の方が専用アプリをインストールする手間はかかりますが、よりセキュアかつ安全に情報をBeaconと端末の間でやりとりできると言えるでしょう。

 ※注3:「iBeacon」の下では、専用アプリに登録されたBeaconの情報しか扱わないようになっていて、未登録の野良Beaconは原則的に無視するのですからある意味当然の話です。

素人同然の筆者でさえすぐ思いつくようなこんな簡単なことをプロであるGoogleの開発者たちが見過ごしているとはおよそ考えにくいのですが、「Ephemeral Identifiers(EIDs)」という、Beaconが発する信号を頻繁に変更し続けることで、認証されたクライアントとの間でしか通信内容をデコードできないようにする、セキュアな通信環境確立のための仕組みについては言及がある一方で、この辺の単純な話については一切言及されていないのを見ると、正直少々不安になってしまいます。

Beaconが基本的には公的な空間で特定されない善意の第三者に向かって発信される性質のものである以上、また昨今の一般的なWebサイトにおけるスパムやウィルスの状況を考えると、そうした悪意ある第三者による攻撃を防ぐ手立ては何としてもあらかじめ用意しておく必要があるでしょう。

残念ながら、記事執筆時点では浅学な筆者にはそのあたりのことを確認できなかったのですが、ある場所に近づいたら突然端末のWebブラウザが起動して際限なくスパム系広告サイトのWebページを吐き出し続けた、といったことにならないよう対策がとられていることを切に祈らずにはいられません。

iBeaconとの整合をとる必要はある

Googleの立場では、せっかくマルチプラットホームかつオープンソースでBeaconの仕様を決めたのだから、特定のOSにしか対応しない「iBeacon」を押しのけてでも「Eddystone」が普及し業界標準となるべきだ、と主張したいところなのでしょうが、可能であるのならば双方の規格に両対応するような、あるいは双方の規格を1つに統一した形でBeaconが情報を発信する仕組みを作るべきではないか、と筆者は考えます。

正直なところ、これまで何年もの間スマートフォンやタブレットについてBluetooth 4.0以降の普及促進を放置してきたも同然のGoogleが、後からやってきて俺様の「Eddystone」が標準だ、標準になるべきだ、と大声で主張することにはかなりの違和感を覚えます。なぜなら「iBeacon」がiPhone 4sの時点で以後の新機種全てでのBluetooth 4.0対応に踏み切り、OSでもiOS 7の段階で対応していたことを背景として既に一定程度普及していて、それなりの効果を上げつつあるからです。

これが「Eddystone」の通信プロトコルが「iBeacon」のそれの完全上位互換である、というのであれば話は簡単なのですが、それも「iBeacon」で基本的には一種類であった送出フレームが、「Eddystone」では複数種に分かれているという、通信の割と根本的な部分での仕様の相違あるいは不一致を見る限りはおよそ期待できる話ではありません。

とはいえ、この種のBeacon技術が社会に及ぼす影響の大きさや、今後設置されるであろうBeaconの数の多さなどを勘案すれば、この種の規格・仕様は可能であればそれぞれの間で相互互換性を損ねない程度には統一が図られているのが望ましいのは確かです。

対応アプリについてはOSの種類ごとに専用アプリを別途用意せねばならないにしても、例えばバス会社がバス停での時刻表・バス運行情報サービスを提供したい場合に、その会社の設置するバス停全てについてそれぞれ異なった規格に対応したBeaconを別々に設置せねばならないという様な状況になるのはあまりに合理性を欠きますし、それではどれほど便利であっても社会的な支持や容認をとても得られそうにありません。

今回はこうして「Eddystone」という形でBeacon技術の標準化・普及に対するGoogleの主張あるいは方針が示された訳ですが、極論すればAppleが「iBeacon」のAndroid版(あるいはその他の各種OS対応版)実現に必要なソフトウェア一式を提供して既に対応Beaconが一定程度普及していることの強みを生かした標準化推進戦略を採る可能性も皆無ではありません(※注4)。

 ※注:Appleは自社規格の普及が目的の場合、例えばQuickTimeのランタイムをWindows環境向けに提供していることなどが示すように、自社のプロプライエタリな規格に対応したソフトウェアを動作させるための環境を他社のOSに提供することがあります。なお、AndroidでのiBeacon対応は試験的かつ限定的なものながら、一部の企業によって既に行われた実績があります。

今後、Beacon技術の標準化が果たしてどの方向に進むのかは判りませんが、この技術は「江ノ電なび」の記事でもご紹介したとおり、実用上非常に大きな効果が期待できるたぐいのものです。

それゆえ、筆者としては、どの方向でも構わないのでうまく軟着陸し、Beaconについての規格が1つにまとまることをかなり切実な思いと共に祈らずにはいられません。

▼参考リンク
Beacons | Google Developers
Platform Overview | Beacons | Google Developers
google/eddystone · GitHub
Overview | Proximity Beacon API | Google Developers

PageTopへ