Eddystoneで始まる
Physical Webの世界 
株式会社リクルートテクノロジーズ
アドバンスドテクノロジーラボ
加藤 亮
Leading the way to W3C TPAC 2015
Agenda
• ビーコン関連技術の現状を整理、理解する
• Eddystoneって?iBeaconは?Physical Webは?
• そのなかでWebエンジニアに今関係するところ、将来関係し
てくるところをピックアップ
7月のGoogleの発表
• Beacon Platform
• Eddystone
• Nearby
• Beacon Proximity API
7月のGoogleの発表
• Beacon Platform
• Eddystone
• Nearby
• Beacon Proximity API
標準規格の話
あとはGoogleが提供するサービスの話
Eddystone
• ビーコンの規格(ビーコンデバイスの振る舞いや発信
するパケットのフォーマット)
• オープンスタンダードを提唱
• Bluetooth LEのアドバタイジングパケットを利用
AppleのiBeaconとの違いは?
Eddystone = Physical Web?
Physical Webって何?
Eddystone
ビーコンからFrameを定期的にブロードキャスト
これをスマホなどで受け取ってどう料理するかは
Eddystoneの仕様外
Eddystone
Frameは3種類
Eddystone-TLM
Eddystone-UID Eddystone-URL
Eddystone-TLM
TLM(telemetry frame)は管理に使うものなので
一度除外して話を進めます
電圧、温度、起動後からの秒数やパケット送信数など
管理に利用するためのビーコンのデータを送信
補助的に利用するもの
Eddystone-
TLM
Eddystone
重要なのは
この二つのうちどちらを飛ばすモードであるか
二種類の振る舞い
Eddystone-UID Eddystone-URL
Eddystone-UID
Eddystone-UID
Namespace
Instance ID
FQDNのsha1ハッシュの最初10byte
Eddystone-UID
Namespace
Instance ID
あるいはUUIDの真ん中を抜いたもの
8b0ca750-e7a7-4e14-bd99-095477cb3e77
8b0ca750095477cb3e77
Eddystone-UID
Namespace
Instance ID
Instance IDは好きなように
6byte
Eddystone-UID
ビーコンからFrameを定期的にブロードキャスト
スマホ側のアプリはFrameをスキャンすると
Namespaceを見て自サービスのものかどうか判断する
近接を発見すると何らかのサービスを実行
Namespace
InstanceID
InstanceID
1
InstanceID
2
InstanceIDを使って
店舗内移動などに対応した
サービスや分析など
iBeacon
Proximity UUID
major
minor
NamespaceではなくProximityUUIDでフィルタリング
自サービスのためのビーコンの発見
major/minorという二つの16bit整数値を自由に使う
Eddystone-UID
まとめ
iBeacon的な用途をカバー
洗練されたオープンスタンダードな仕様
Eddystone-TLMを使って管理もできる
Eddystone-URL
Eddystone-URL
URL
Namespace&IDの代わりにURLを飛ばす
小さいパケットの中にURLを乗せるために
様々な工夫がされています
長いURLは載せられないので短縮URLを使います
Physical WebにおいてUriBeaconと呼ばれていた仕様とほぼ同じ
Physical Web
http://www.slideshare.net/recruitcojp/w3-c-signage
より詳しくは前回資料(W3C/Keio デジタルサイネージとHMTL5セミナー)を
あるいはgihyo.jp連載などを
http://gihyo.jp/admin/serial/01/physicalweb
これらと重複しますが
簡単にフローだけ紹介します
http://example.com
http://example.com
http://example.com
http://example.com
ビーコンからURLを
Bluetooth LEで周囲にブロードキャストします
http://example.com
 スマホを持ったユーザーが
ビーコンの横を通り過ぎるときに
ビーコンから飛ばされたURLを
見つけます
http://example.com
http://example.com
http://example.com
http://example.com
http://example2.com
http://example2.com
http://example2.com
こういうビーコンの横を
通り過ぎていくと
各ビーコンからURLを拾い
結果をリストアップできます
実際は拾ったURLから
メタデータ(title,icon,descriptionなど)を
取得する処理を挟んでいます
欲しい情報が見つかったらWebブラウザで表示
WebView
UID VS URL
URLは必要なのか
Namespace/ID12345: http://example.com/
12346: http://google.com/
12347: http://yahoo.com/
…
http://example.com
変換テーブルがあれば同じような
事はUIDでも可能
UID VS URL
packet
Namespace/ID12345: http://example.com/
12346: http://google.com/
12347: http://yahoo.com/
…
http://example.com
このテーブルを誰が運営するのか
URLはいつ登録されるのか
という問題が発生する
Beacon Ecosystem
現在のiBeaconやEddyston-UIDでは、それぞれ独自アプリ作って配布
ビーコンが飛ばすIDなどを自由に使う
業者Aの
スマホアプリ
業者Bの
スマホアプリ
業者Cの
スマホアプリ
業者Aの
ビーコン
業者Bの
ビーコン
業者Cの
ビーコン
開発費用の問題、ユーザーのスマホに入れてもらうのも大変
標準準拠
アプリ
業者Aの
ビーコン
業者Bの
ビーコン
業者Cの
ビーコン
ユーザーのスマホに一つ標準ブラウザが入っていればよい
Beacon Ecosystem
Physical Webのような標準化が浸透した世界では…
コンテンツ提供側はビーコンとWebサイトを設置するだけでよい
個人
ホームページ
Web Echosystemを
振り返る
個人
ホームページ
飲食店の
店舗サイト
標準規格の上での様々なコンテンツの充実
飲食店
店舗サイト
レンタルサーバーや解析ツール等
ぐるなび等
Facebookやブログサービス
Wordpressなど
個人
ホームページ
個人
ホームページ
飲食店の
店舗サイト
周囲に派生ビジネス - 競争のレイヤーの変化
飲食店
店舗サイト
標準準拠
アプリ
業者Aの
ビーコン
業者Bの
ビーコン
業者Cの
ビーコン
この分野でも新たな競争レイヤーが生まれていくのでは
Beacon Ecosystem
GoogleのNearbyやBeacon Proximity APIなどもその一つかも
つまりEddystone-URL(Physical Web)のほうは
ただの機能的なイノベーションの話ではなく
プラットフォームの話
今回のGoogleの発表で
実験的プロジェクトから
実践フェーズへ
Eddystone対応ビーコンデバイスは
市販も始まっている
例: Estimote(技適マークも対応済み)
気軽にアプリ側を実装して実験もできる
最新のChrome (iOS)で対応済み
Today Widget
実験的?とは言え、たくさんのユーザーの手元に
Physical Webを体験できる環境が
実験フェーズから実践フェーズへ
Eddystone-URL
http://googledevelopers.blogspot.jp/2015/07/lighting-way-with-ble-beacons.html
普及するかどうかの勝負
キラーアプリケーションの登場が待たれる
Google Nowが最初の本命?
Physical Webの
現状まとめ
UriBeaconの仕様がEddystoneに取り込まれ
正式にGoogleのサービスと共に発表された
Chrome(iOS)というユーザーシェアの大きい
アプリに機能が取り込まれた
規格としてはほぼ固まって実践投入できる
多くのエンドユーザーの手元で試せる環境がある
ただしキラーアプリケーションとは言えない
おそらく最初の本命であるGoogle Now対応待ち
もちろん他社の参入があっても面白そう
Eddystoneの
イノベーション
UID
URL
TLM 実運用で想定される問題の解決を
補助するためのサポート機能
iBeaconに対するカウンター
洗練された仕様、オープンスタンダード
Physical Webの世界の実現
実験フェーズから実践フェーズへ
今後おそらく
考えなければ
ならなくなってくること 
Real Worldも含めた
サービスのアイデア
UI/UXデザイン
O2O的サービスデザイン
リアル店舗設計
自然にユーザーが立ち止まる場所にフック
あるいはサイネージによるアテンション
近接+URLで
嬉しい組み合わせは何か
(例) CDショップの視聴コーナーで
視聴用のハードウェアの代わりに
YouTubeのURLを飛ばすビーコンを置く
現状その要件のために特製ハードウェアで
実現されているサービスを
ビーコン&スマートフォンで置き換える実例が
どんどん出てくるのでは
ブラウザから
IoT的なサービスへの
ダイレクトアクセス
Web Bluetooth, Web NFC
現状では、iOS/Androidなどにネイティブで搭載されているものを
FirefoxOSなどのWebOSでも使えるように、というくらいの用途?
純粋なブラウザ上のWebアプリケーションでも必要な機能へ
Physical Webによって
近接を前提とするWebサービス登場の可能性
他のIoT関連の
技術との連動
Wifi Aware
Apple HomeKit
Google Weave, Brillo, Nest
その他IoT機器やプロトコル
Web Browser
BLE NFC その他
他のIoT関連の
技術との連動
Physical Webは近接&URLから始まる
Webブラウザからその他のIoT関連サービスとの連動
というのは非常に相性が良いはず
このブリッジがどうなるかが
Native -> モバイルWebへの揺り返しにとって
重要なポイントの一つになりうるのでは
ご静聴
ありがとうございました

Eddystoneで始まるPhysical Webの世界