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の仕様外

EddystoneFrameは3種類

Eddystone-TLM

Eddystone-UID Eddystone-URL

Eddystone-TLMTLM(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 UUIDmajor 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 URLURLは必要なのか

Namespace/ID12345: http://example.com/ 12346: http://google.com/ 12347: http://yahoo.com/ … http://example.com

変換テーブルがあれば同じような 事はUIDでも可能

UID VS URL

packetNamespace/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 EcosystemPhysical 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-URLhttp://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への揺り返しにとって

重要なポイントの一つになりうるのでは

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