2015/8/25に開催されたLeading the way to W3C TPAC 2015での発表資料です。 7月にGoogleから発表されたbeacon-platform、特にEddystoneについての話、また、それらがこれまで実験的なものとして進められてきたPhysical Webのプロジェクトとどう関係するのかなど、複雑になってきているビーコン関連の業界動向を一度整理してみました。

1. Eddystoneで始まる
Physical Webの世界
株式会社リクルートテクノロジーズ
アドバンスドテクノロジーラボ
加藤 亮
Leading the way to W3C TPAC 2015

2. Agenda
• ビーコン関連技術の現状を整理、理解する
• Eddystoneって？iBeaconは？Physical Webは?
• そのなかでWebエンジニアに今関係するところ、将来関係し
てくるところをピックアップ

3. 7月のGoogleの発表
• Beacon Platform
• Eddystone
• Nearby
• Beacon Proximity API

4. 7月のGoogleの発表
• Beacon Platform
• Eddystone
• Nearby
• Beacon Proximity API
標準規格の話
あとはGoogleが提供するサービスの話

5. Eddystone
• ビーコンの規格(ビーコンデバイスの振る舞いや発信
するパケットのフォーマット)
• オープンスタンダードを提唱
• Bluetooth LEのアドバタイジングパケットを利用
AppleのiBeaconとの違いは?
Eddystone = Physical Web?
Physical Webって何?

6. Eddystone
ビーコンからFrameを定期的にブロードキャスト
これをスマホなどで受け取ってどう料理するかは
Eddystoneの仕様外

7. Eddystone
Frameは3種類
Eddystone-TLM
Eddystone-UID Eddystone-URL

8. Eddystone-TLM
TLM(telemetry frame)は管理に使うものなので
一度除外して話を進めます
電圧、温度、起動後からの秒数やパケット送信数など
管理に利用するためのビーコンのデータを送信
補助的に利用するもの
Eddystone-
TLM

9. Eddystone
重要なのは
この二つのうちどちらを飛ばすモードであるか
二種類の振る舞い
Eddystone-UID Eddystone-URL

10. Eddystone-UID

11. Eddystone-UID
Namespace
Instance ID
FQDNのsha1ハッシュの最初10byte

12. Eddystone-UID
Namespace
Instance ID
あるいはUUIDの真ん中を抜いたもの
8b0ca750-e7a7-4e14-bd99-095477cb3e77
8b0ca750095477cb3e77

13. Eddystone-UID
Namespace
Instance ID
Instance IDは好きなように
6byte

14. Eddystone-UID
ビーコンからFrameを定期的にブロードキャスト
スマホ側のアプリはFrameをスキャンすると
Namespaceを見て自サービスのものかどうか判断する
近接を発見すると何らかのサービスを実行
Namespace
InstanceID

15. InstanceID
1
InstanceID
2
InstanceIDを使って
店舗内移動などに対応した
サービスや分析など

16. iBeacon
Proximity UUID
major
minor
NamespaceではなくProximityUUIDでフィルタリング
自サービスのためのビーコンの発見
major/minorという二つの16bit整数値を自由に使う

17. Eddystone-UID
まとめ
iBeacon的な用途をカバー
洗練されたオープンスタンダードな仕様
Eddystone-TLMを使って管理もできる

18. Eddystone-URL

19. Eddystone-URL
URL
Namespace&IDの代わりにURLを飛ばす
小さいパケットの中にURLを乗せるために
様々な工夫がされています
長いURLは載せられないので短縮URLを使います
Physical WebにおいてUriBeaconと呼ばれていた仕様とほぼ同じ

20. Physical Web
http://www.slideshare.net/recruitcojp/w3-c-signage
より詳しくは前回資料(W3C/Keio デジタルサイネージとHMTL5セミナー)を
あるいはgihyo.jp連載などを
http://gihyo.jp/admin/serial/01/physicalweb
これらと重複しますが
簡単にフローだけ紹介します

21. http://example.com
http://example.com
http://example.com
http://example.com
ビーコンからURLを
Bluetooth LEで周囲にブロードキャストします

22. http://example.com
スマホを持ったユーザーが
ビーコンの横を通り過ぎるときに
ビーコンから飛ばされたURLを
見つけます

23. http://example.com
http://example.com
http://example.com
http://example.com
http://example2.com
http://example2.com
http://example2.com
こういうビーコンの横を
通り過ぎていくと

24. 各ビーコンからURLを拾い
結果をリストアップできます
実際は拾ったURLから
メタデータ(title,icon,descriptionなど)を
取得する処理を挟んでいます

25. 欲しい情報が見つかったらWebブラウザで表示
WebView

26. UID VS URL
URLは必要なのか
Namespace/ID12345: http://example.com/
12346: http://google.com/
12347: http://yahoo.com/
…
http://example.com
変換テーブルがあれば同じような
事はUIDでも可能

27. UID VS URL
packet
Namespace/ID12345: http://example.com/
12346: http://google.com/
12347: http://yahoo.com/
…
http://example.com
このテーブルを誰が運営するのか
URLはいつ登録されるのか
という問題が発生する

28. Beacon Ecosystem
現在のiBeaconやEddyston-UIDでは、それぞれ独自アプリ作って配布
ビーコンが飛ばすIDなどを自由に使う
業者Aの
スマホアプリ
業者Bの
スマホアプリ
業者Cの
スマホアプリ
業者Aの
ビーコン
業者Bの
ビーコン
業者Cの
ビーコン
開発費用の問題、ユーザーのスマホに入れてもらうのも大変

29. 標準準拠
アプリ
業者Aの
ビーコン
業者Bの
ビーコン
業者Cの
ビーコン
ユーザーのスマホに一つ標準ブラウザが入っていればよい
Beacon Ecosystem
Physical Webのような標準化が浸透した世界では…
コンテンツ提供側はビーコンとWebサイトを設置するだけでよい

30. 個人
ホームページ
Web Echosystemを
振り返る
個人
ホームページ
飲食店の
店舗サイト
標準規格の上での様々なコンテンツの充実
飲食店
店舗サイト

31. レンタルサーバーや解析ツール等
ぐるなび等
Facebookやブログサービス
Wordpressなど
個人
ホームページ
個人
ホームページ
飲食店の
店舗サイト
周囲に派生ビジネス - 競争のレイヤーの変化
飲食店
店舗サイト

32. 標準準拠
アプリ
業者Aの
ビーコン
業者Bの
ビーコン
業者Cの
ビーコン
この分野でも新たな競争レイヤーが生まれていくのでは
Beacon Ecosystem
GoogleのNearbyやBeacon Proximity APIなどもその一つかも

33. つまりEddystone-URL(Physical Web)のほうは
ただの機能的なイノベーションの話ではなく
プラットフォームの話

34. 今回のGoogleの発表で
実験的プロジェクトから
実践フェーズへ

35. Eddystone対応ビーコンデバイスは
市販も始まっている
例: Estimote(技適マークも対応済み)
気軽にアプリ側を実装して実験もできる

36. 最新のChrome (iOS)で対応済み
Today Widget
実験的?とは言え、たくさんのユーザーの手元に
Physical Webを体験できる環境が
実験フェーズから実践フェーズへ

37. Eddystone-URL
http://googledevelopers.blogspot.jp/2015/07/lighting-way-with-ble-beacons.html
普及するかどうかの勝負
キラーアプリケーションの登場が待たれる
Google Nowが最初の本命?

38. Physical Webの
現状まとめ
UriBeaconの仕様がEddystoneに取り込まれ
正式にGoogleのサービスと共に発表された
Chrome(iOS)というユーザーシェアの大きい
アプリに機能が取り込まれた
規格としてはほぼ固まって実践投入できる
多くのエンドユーザーの手元で試せる環境がある
ただしキラーアプリケーションとは言えない
おそらく最初の本命であるGoogle Now対応待ち
もちろん他社の参入があっても面白そう

39. Eddystoneの
イノベーション
UID
URL
TLM 実運用で想定される問題の解決を
補助するためのサポート機能
iBeaconに対するカウンター
洗練された仕様、オープンスタンダード
Physical Webの世界の実現
実験フェーズから実践フェーズへ

40. 今後おそらく
考えなければ
ならなくなってくること

41. Real Worldも含めた
サービスのアイデア
UI/UXデザイン
O2O的サービスデザイン
リアル店舗設計
自然にユーザーが立ち止まる場所にフック
あるいはサイネージによるアテンション

42. 近接+URLで
嬉しい組み合わせは何か
(例) CDショップの視聴コーナーで
視聴用のハードウェアの代わりに
YouTubeのURLを飛ばすビーコンを置く
現状その要件のために特製ハードウェアで
実現されているサービスを
ビーコン&スマートフォンで置き換える実例が
どんどん出てくるのでは

43. ブラウザから
IoT的なサービスへの
ダイレクトアクセス
Web Bluetooth, Web NFC
現状では、iOS/Androidなどにネイティブで搭載されているものを
FirefoxOSなどのWebOSでも使えるように、というくらいの用途?
純粋なブラウザ上のWebアプリケーションでも必要な機能へ
Physical Webによって
近接を前提とするWebサービス登場の可能性

44. 他のIoT関連の
技術との連動
Wifi Aware
Apple HomeKit
Google Weave, Brillo, Nest
その他IoT機器やプロトコル
Web Browser
BLE NFC その他

45. 他のIoT関連の
技術との連動
Physical Webは近接&URLから始まる
Webブラウザからその他のIoT関連サービスとの連動
というのは非常に相性が良いはず
このブリッジがどうなるかが
Native -> モバイルWebへの揺り返しにとって
重要なポイントの一つになりうるのでは

46. ご静聴
ありがとうございました