TPACはWebの標準化団体であるW3Cが年一回開催する全体会合です。今年はその会合がなんと、札幌で開催されます。最先端のWeb標準に関する様々な議論が日本で交わされること記念して、TPACの魅力を伝えるとともに、Web標準の今をわかりやすく紹介するイベント「Leading the way to W3C TPAC 2015」が、8月終わりに開催されました。テーマは「Webの未来の肌触りを感じよう」。

来週TPACに参加される方もそうでない方も、全ての方に改めてWeb標準に興味関心を持っていただきたいと考え、そのイベントの模様をレポートします！

はじめに

イベントはW3C Keioサイトマネージャーの中村修氏の挨拶から始まりました。

W3CとIETFの関わり

今年は、Web標準を作るW3CのTPACと、インターネットプロトコルの標準を作るIETFが、それぞれ10月と11月に日本で開催される。この2つの会議が同じ時期に同じ国で行われることは歴史的にみても初めての試みだ。例えば、Webブラウザ上でP2Pによる通信を実現するWebRTCを例にとると、関連するプロトコルの議論はIETF、APIやアーキテクチャの議論はW3Cで議論が進められており、今や両者は密接に関わっている。そのため、今回のような取り組みは非常に重要な意味を持つ。また、IETFとW3Cが作る標準は「オープン標準」であることが最も重要なこと。みんなが自由にソフトウェアを書いて、その上で同じく自由に新しいサービスを作っていけるように、そのための基盤作っていく作業をIETFとW3Cは日々やっている。そこを理解してほしい。

TPAC2015の歩き方

最初のセッションはHTML5 Experts.jpのエキスパートでもある矢倉眞隆氏による「W3Cの歩き方」です。矢倉氏は以前、W3Cメンバーであるミツエーリンクスに所属しており、そこで標準活動を積極的に行っていた経歴を持ち、2007年からほぼ毎年TPACに参加しているそうです。

W3Cの情報ってどうやって収集するの

W3Cの標準化に関する活動の様子を知る手段としては、「メーリングリスト」、「GitHub」、「F2Fミーティング」の3種類がある。中でも今はGitHubでの議論が活発。Issuesを活用し様々なトピックについて議論がなされているため、議論に加わりたい方にはオススメ。気軽にコメントやPRができる。F2Fミーティングは、各ワーキング・グループ毎にTPAC以外で、年2回以上は開催されており（グループごとに差がある）、コミュニケーションが密に取れるという意味では大変重要な役割を担っている。例えば、CSSのワーキング・グループでは、図形に関する議論が多いため、F2Fでプロジェクターを見ながら議論することで、より捗る傾向にある。

TPAC2015ではどのようなことが行われるのか

TPACはW3Cの全体会合（TECHNICAL PLENARY）、運営会議（ACミーティング）、F2Fミーティング（グループミーティング）で構成されており、年に1回実開催される。スケジュールやどのようなグループが議論を行うかは、公式サイトに掲載されている。

中でも注目は、水曜日に開催される「TECHNICAL PLENARY DAY」だ。これは、アンカンファレンス形式で進められる。TPACの参加者自身が喋りたい内容をその日の朝に出し合い、早い者勝ちで予め用意されているミニセッション枠を確保する。他の参加者たちは好きなセッションに参加可能である。これは、各グループの垣根を超えたコミュニケーションを促進することで、イノベーションを促進する狙いがある。

なぜTPACに参加するのか

標準化に関する内容は、Webで簡単に手に入る時代になった。この時代に、あえてTPACに行く理由はなにか？開発者目線のTPACは、ブラウザベンダにこのようなAPIを実装してほしい、ここの部分が使いにくいので変えてほしい等、開発者の声を積極にアピールする場になっている。また、直接あって話がしたい、発表したい、他の開発者と差を付けたいなど、野心的な想いを持った開発者も多い。

これからの標準化と開発者の関わり方

最近では、ブラウザベンダも標準をかなり意識し始めている。標準じゃないと実装しないという風潮になりつつある。そして、標準化の現場も変わりつつある。これまで標準化の場で作り出されるAPIは、開発者からの要望に基づいたハイレベル（高機能）なものが多かった。そのため、新しく出てくる様々なユースケースに対応できなかった。（対応に時間がかかっていた）今後は、様々なユースケースに短期間で対応できるように、ブラウザで扱える範囲にはなるが、比較的ローレベル（低機能）なAPIの標準化が主流になる。それを組み合わせることで、開発者は様々なユースケースに迅速に対応できる。（いわゆるExtensible Webの流れ）また、JQueryのように、ローレベルなAPIを開発者自らがラッパーしてわかりやすいAPIを定義するということが、増えてくるだろうと期待もされている。

Developer Meetup in Sapporoが開催されます！

次のセッションは、TPAC2015の開催に合わせて札幌で開催される「Developer Meetup in Sapporo」の紹介です。登壇は、このイベントをホストするNTTコミュニケーションズの本間咲来（さっくる）氏。

TPAC2015は参加条件があるため、一般の開発者が参加するにはちょっとハードルが高いイベント。そこで、TPAC2015の為に来日する海外のエキスパートと日本のエンジニアの交流の場として、TPAC2015初日（10/26）に「Developer Meetup in Sapporo」が開催されます。会場はW3Cと同じ会場。展示やトークセッション、懇親会が企画されていて通訳も用意されるそうです。まだ参加登録を受け付けているようなので、興味がある方は是非参加してみては？（参加は無料です）

また、イベント開催に合わせて、クリプトン・フューチャー・メディア株式会社主催の北海道オープンデータハッカソンが10/17に開催されました。ハッカソンの優秀者の作品はDevelopers Meetupで展示されるそうです。

※写真はイベント開催時（8月末）のものです

Eddystoneで始まるPhysical Webの世界

ここからは、ゲストスピーカーによる最新のWeb技術に関する、テクニカルセッションが続きます。

最初のセッションはリクルートテクノロジーズの加藤亮氏。加藤氏は以前当メディアで取材したPhysical Webのエキスパートです。このセッションでは、Physical Webをテーマに、Googleが7月に発表したばかりの標準規格である、Eddystoneについて解説していただきました。

Eddystoneとはなにか？

EddystoneはGoogleが7月に発表したBeacon Platformを構成するもので、ビーコンの規格。ビーコンは、フレームと呼ばれるデータを定期的にブロードキャストするもので、この規格では、ビーコンデバイスの振る舞いや、発信するパケットのフォーマットを規定している。Googleはオープン・スタンダードを提唱している。

Eddystoneには3つのフレーム（Eddystone-TLM、Eddystone-UID、Eddystone-URL）がある。Eddystone-TLMは、ビーコンの管理情報を送信するもので、バッテリ電圧や温度、起動後の経過時間、パケット送信料などを送る。重要なのは、Eddystone-UIDとEddystone-URLの方。

Eddystone-UID

Eddystone-UIDは、NamespaceとInstanceIDと呼ばれる固有IDを送信します。ビーコン受信側では、Namespaceを見て自分のサービスのビーコンかどうかを判断し、InstanceIDを利用して複数のビーコンをまたがった移動などを検知することができる。iBeacon的な用途をカバーするする、洗練されたオープン・スタンダードな仕様だといえる。

Eddystone-URL

Eddystone-URLは、Physical WebのおけるURIBeaconのことであり、NamespaceとInstanceIDの代わりにURLを送信する。小さいパケットの中にURLを載せるための工夫がなされているほか、長いURLは短縮URLを使うといった配慮が必要。これは、いわゆるPhysical Webの世界を現実のモノにするためのモノで、実験フェーズから実践フェーズへの移行を象徴付ける存在である。

Eddystone-URLはビーコンの新たなエコシステムを作る

一番の醍醐味は近接通信をサービスに活用できること。Eddystone-URLを使えば、ビーコンからBluetooth Low Energy（以下、BLE）でURLをブロードキャストできる。近くにいるスマホは、複数のビーコンから受信したURLを元にOGPなどを収集、リスト表示してユーザに提示することができる。

URLが必ずしも必要かといえばそうではなく、UIDとURLの変換テーブルをもったスマホアプリを独自に作れば同じようなことができる。これは今までのBeacon（iBeaconやEddystone-UID）のエコシステムで、独自に設置したビーコンとそれ専用のスマホアプリを配布し使ってもらうというもので、開発費もかかり、ユーザにビーコン毎に別のスマホアプリを導入してもらう必要があり、ハードルが高かった。

Eddystone-URLを利用すれば、URLという共通のフォーマットでデータのやり取りができるため、スマホには標準準拠アプリ（例えばWebブラウザ）を1つ入れておけばよく、コンテンツ提供側はビーコンとWebコンテンツを用意すればよい。これは、標準規格の上で様々なコンテンツが充実したWebのエコシステムによく似ており、ビーコンにおける新たなエコシステムと言ってもいい。今後周辺ビジネス含めて新たな競争が生まれる可能性を秘めている。つまり、Eddystone-URLはただの機能的なイノベーションの話ではなく、プラットフォームとしての意味合いが強いと言える。

すぐに使えるのか

もともとPhysical Webと言われていたこの技術であるが、7月にGoogleがBeacon Platformを正式発表したことで、実験フェーズから実践フェーズに移行したといってもいい。Eddystone-URL対応ビーコンデバイスも出始めており、既存のiBeaconでもファームウェアのアップデートで対応できるものもある。（例：Estimote）

また、Beacon Platform発表のすぐ後にChrome（最新iOS）がPhysical Webに対応した。Physical Webの機能をONにすれば受信したURLをウィジェットにリストアップすることが可能で、もちろんEddystone-URLからの情報を受けることもできる。まだ実験的な対応であることは否めないが、普及に向けた第一歩であることは間違いない。尚、本命はGoogle Nowで活用したいのではないかと考える。キラーアプリの登場が普及の鍵を握っている。

Web開発者が考えなければならないこと

サービス提供側としては、ビーコンを活用する関係でリアル・ワールドを考慮したサービス設計（UI/UXデザイン）が必要になる。例えば、スマホは基本的にはインポケットデバイスである。ビーコンの情報を受信してもユーザがスマホを見てくれなければ意味がない。ユーザが自然にスマホを見るような環境に上手くビーコンを配置したり（バス停やレストラン等）、サイネージなどと組み合わせて、歩いているユーザを立ち止まらせるような仕掛けを合わせて考えなければならない。

今後の展望

近接通信を活用したPhysical Webの普及で、WebブラウザからIoTデバイスへのダイレクトアクセスという需要が出てくる可能性がある。今でもWebBluetoothやWebNFCの議論があるが、FirefoxOSなどのWebOSで使えるようにすることが主目的となっている。今後、近接通信を前提とするWebサービスを作りたいという要望が出てくれば、純粋なWebブラウザ上のWebアプリケーションからもこれらの機能が必要となってくる。そして、これらの機能が整備されると、ビーコンにかぎらず、他の様々なIoTデバイスや近接通信機器とのIFとなり得るため、デバイスが普及した暁には、Webの大きなアドバンテージになっているはずである。

発表資料

加藤氏の発表資料はこちらで公開されているので、ぜひご覧ください。

終わりに＆次回予告

次回は加藤氏に続く3人のゲストスピーカーによるセッションの模様をお伝えします。そして、来週からはじまるTPACでの熱い議論、参加される方は現地で、参加されない方もインターネット等を通して、ぜひウォッチしてみてください！新しい発見があるかもしれません。

IoTに関心のあるWeb技術者であればスルーは許されない「Physical Web」について、詳しい人（株式会社リクルートテクノロジーズ ITソリューション統括部 アドバンスドテクノロジーラボ 加藤亮さん）に詳しく聞いてきました！

　　　▲株式会社リクルートテクノロジーズ ITソリューション統括部 アドバンスドテクノロジーラボ 加藤亮さん

編集部より注意

このインタビューの直後に、Googleよりbeacon-platformの発表がありました。

読者の皆さんが誤解なく、最新の情報に更新された知識を得られるよう、インタビュー記事の合間に注釈として、今回Googleに発表された情報を踏まえた上での補足を加藤さんご自身に差し込んでいただきました。加藤さん、本当にありがとうございます！

自己紹介

白石: 加藤さん、今日はよろしくお願いします。まずは簡単な自己紹介からお願いできますか？

加藤: 私はリクルートテクノロジーズのアドバンスドテクノロジーラボという部署に所属していて、様々な先端技術についての研究開発に携わっています。そうした研究開発の中、iBeaconやBluetooth Low Energy (BLE)について調べていくうちに、BLEはiBeacon以外にもいろいろと応用できるのではないかと思っていたのです。

そうしたある日、TechCrunchにPhysical Webの記事が出まして。それがちょうど、BLEの新しい可能性を示しているように思ったので、追求していくことにしたのです。

Physical Webは、GitHubにそのビジョンや中核のコード、機能デモ的なサンプルアプリが置いてあります。それをベースに、エンドユーザーの体験を表現できるよう、実際にアプリを作って様々な機能を足しながら実験をしています。

白石: Physical Webを仕事にしているわけですね。このタイミングで、Physical Webで仕事をしているというのは、世界的にも珍しいんじゃないでしょうか(笑)。

では、まずはPhysical Webの概要について、簡単にお話しいただけますでしょうか？

Physical Webの概要

加藤: Physical Webを使用したアプリの動作自体はけっこう単純です。基本はビーコンが決まったURIを周りに発信し、近くにいるスマホがそれを受け取る、というだけです。受け取った側は、そのURIにアクセスして情報を得るわけです。

Physical Web処理概要

ビーコンは、BLEを利用してURI（URL）を一定間隔で周囲に発信しますが、この部分は「UriBeacon」と呼ばれます。アプリはUriBeaconからURLを受け取ったら、直接そのURLにアクセスするわけではなく、Resolverという仕組みを介して情報をWebから取得します。

例えば私たちは、UriBeaconを実装した実際のビーコンと、それらからURLを受け取って表示できるデバイスを作っています。 こちらのビーコンは、1秒に1回様々なURIを発信しており、スマホ側のアプリは、そのURIから得た情報をリスト表示しています。

白石: すごい！もう動いてる。しかも確かに単純そうです。URLを受け取って、そこから情報を取得するだけなんですね。ちなみに、そういう製品まで作れているということは、Physical Webはもう「使える」状態なのでしょうか？

加藤: うーん、何を持ってPhysical Webか、というところが難しいんですよね。WebイコールHTTPとは言いきれないように。先ほど申し上げたUriBeaconの部分は仕様もだいぶ固まりつつありますが、それ以外の部分はまだ議論の余地がある部分がたくさんあります。

白石: なるほど、そういう状況なんですね。では、技術的な詳細はちょっと後回しにして、この仕組みは何が新しくて、どう世界を変えるんでしょう？

インタビュー後 注釈(1) – UriBeaconからEddystoneへ

Physical Webは実験的なプロジェクトとされ、その中でUriBeaconの仕様が固められてきましたが、 その成果を踏まえ、今回GoogleからEddystoneという規格が発表されました。　

また、Eddystoneに準拠したビーコンデバイスもすでに市販が始まっており、例えばiBeacon対応デバイスとして販売されていたEstimoteでも、ファームウェアアップデートによりEddystoneのビーコンとして動作させることができるタイプのものもあります。(ちなみにEstimoteであれば技適マークも既に適応済みです)

Physical Webのイノベーション

加藤: まずPhysical Webは、標準的な「URI / URL」という仕組みを活用していることが非常に大きな強みですね。Physical Webが普及したあかつきには、現実世界のあらゆるものがURLを持つようになるでしょう。例えば人もURLを持つ。Facebookのプロフィールページがいい例です。例えばみんながビーコンを身につけて、イベント会場や会議室で自分のURLを発信していれば、名刺交換など必要なくなるわけです。

UriBeaconのドキュメントでは、「リアル・ワールド・ワイド・ウェブ 」というフレーズを標榜しています。

白石: Physical Webは、今までのO2Oアプリなどが抱えていた、「ビーコンから得る情報を活用するには、そもそも特定のアプリをインストールしておかなくてはいけない」といった問題を解決するのでしょうか？

加藤: そうですね。標準仕様に準拠したアプリが一つインストールされてさえいれば、あとはビーコンを置くだけで情報を送ることができる、という世界が実現できます。

白石: 今まではO2Oの文脈などでも、「特定のアプリをインストールしてその場に行けばいい」という話はよくありましたが、そもそもその「特定のアプリをインストールしておく」というところのハードルが高かった。それがPhysical Webが普及したら、UriBeaconに対応した標準的なアプリが端末にインストールされてさえいれば、他のアプリをインストールする必要はなくなるわけですね。

加藤: そこは昔の、WindowsアプリとWebアプリに例えることもできるかもしれませんね。Windowsでクライアント・サーバモデルのアプリケーションが主流だった時代に、Internet ExplorerというWebブラウザがWindowsに同梱されて普及すると、Webアプリケーションが登場して、クライアントは専用アプリである必要がなくなった。

それと同様に、Physical Webに対応したクライアントアプリが一つ普及すれば、お店の人たちはWebページを用意して、ビーコンを置くだけで情報を伝えることができる。アプリを作ったり、配布してインストールしてもらうといったマーケティングが必要なくなります。

今だと、専用のアプリをインストールしてもらっておくことが必要なので、先にそのサービスに対してロイヤリティを持っていることが前提になります。「ある場所に来るだけで（偶発的に）情報にアクセスできる」という役には立ちません。

白石: ある場所に来るだけで情報を得られるというのは、面白いですね。

加藤: Physical Webのドキュメントの中でよく触れられているのは、有料パーキングエリアのチケット券売機です。 今は専用のハードウェアがあって、チケットの発券や精算を実現しているわけですが、Physical Webの世界では、そこにはビーコンさえあればいい。ビーコンが発信するURLをスマホで拾い、そこにアクセスするとWebアプリケーションが立ち上がる。そのアプリケーションで、課金なりなんなりすればいいというわけです。

白石: それは未来感ありますねえ。

加藤: 他にぼくがよく挙げる例としてはバス停の時刻表だとか、レストランでメニューを見たい場合だとか、「その時、その場所で必要な情報」を取り扱うシーンです。

現在のところ、こういう情報はだいたいアナログです。「その時、その場所にいる人にしか必要のないデータ」って、インターネットに置く必要性が今までは薄かったんですよね。その場に来ないとわからない、その場に来ればわかるといった情報は、コストをかけてWebページを作りサーバーを用意するよりも、店の前に看板を置いておくほうが安いし、集客効果もある。デジタルサイネージも面白いのですが、費用対効果が厳しいケースもあるかと思います。

Physical Webは、そうしたデータのデジタル化を促進するかもしれません。例えばバス停の時刻表のデータ等は、今はアナログで静的な情報ですが、それがデジタルで動的な情報になることにより、「あと何分でバスが来る」などの情報を提供できるようになるかもしれない。

つまり、情報やサービスのフックが世の中に増えていくということです。

白石: すごく夢が広がりますね。先ほどデジタルサイネージといった話もありましたが、デジタルサイネージは設置にお金もかかるし、平面も必要になる。デジタルサイネージを補完するような形も、置き換えるような形もあり得るかもしれませんね。

加藤: はい、いろいろあるでしょうね。スマホでPhysical Webを利用する場合のウィークポイントといいますか、歩いているときに偶発的に情報に出会ったとしても、スマホはポケットの中にあるわけですね。なので、そうした情報と出会ったことにすぐには気づかない。プッシュしてブルブル震わせれば気づかせることもできるんですが、みんながそれをやってしまうとスパム行為になってしまうので、それはやらないようにしましょう、ということになってます。そうなると最初のアテンションとして、デジタルサイネージなどが有効なのではと。

白石: なるほど。

加藤: 例えば案内図のようなものがあったとして、デジタルサイネージがビーコンで情報を飛ばしていれば、案内図を暗記しなくても、続きは自分のスマホの中で見ることができる。今まで、ファーストスクリーンからセカンドスクリーンへのナビゲーションって、URLを使うとか、「○○で検索」とか、QRコードとか、エンドユーザにコストがかかるものが多かった。そこが自然な、手元を見れば情報がリストアップされているという世界になるでしょう。

白石: 面白いなあ。

Physical Webのコードを書く

白石: では、Physical Webの具体的な処理の流れを教えて下さい。BLEのこともよくわかっていないので、そこから教えていただけると嬉しいのですが。まずビーコンは、どんな感じで情報を発信しているのですか？

加藤: ビーコンは、0.5秒や1秒など、一定の間隔でパケットをブロードキャストしています。そして、そうしたパケットをアプリ側から定期的にスキャンして、パケットを拾うわけです。

アプリがフォアグラウンドにいる間しかスキャンしないか、バックグラウンドにいる状態でもスキャンを行うかはアプリの設計次第ですね。先程言ったような、「スマホがポケットにいる間も情報を受け付ける」という場合は、バックグラウンドでの動作が必要です。

白石: なるほど。

加藤: 送られてくるURLは、Google url shorterのようなURL短縮サービスで生成した短縮URIを、さらに圧縮したものになるのが一般的です。BLEはパケットサイズの制限が厳しいので、例えば「http://」や「https://」といった文字列を1バイトで表すなどの圧縮処理を施します。

/shumpei-shiraishi/

↓ Google url shorterで短縮

https://goo.gl/rYtZme

↓ 「https://」を「0x03」1バイトに変換/

あらゆるURLを合計14バイトの文字列にすることができる

アプリケーションはそれを受け取って、Resolverに送ります。この部分は、単なるWeb APIになります。

URLを受け取ったアプリケーションは、そのURLをResolverと呼ばれる外部のWebアプリケーションに渡します。この部分は、単純なWeb APIの呼び出しです。するとResolverはURLを展開して、そのURLが示す先からデータを取得したり、URLごとにデータをキャッシュしてレスポンスを高速化するなどの処理を行ってくれるわけです。Resolverの処理の戻り値は、アクセスした先のWebページに含まれる（OGPなどの）メタデータを、JSON形式にしたものです。

Physical Web処理概要（再掲）

ビーコンからURLを受け取ってResolverに渡し、結果を得る部分のコード例は以下の様なものです。 (UI関連のコードは省略しています) 編集部注: （Webエンジニアにはあまり馴染みがないかもしれない）Objective-Cのコードではありますが、コメントと併せて読めば難しくないと思います。

URIのスキャンには、uribeaconのリポジトリで提供されているライブラリを、 リゾルバへのアクセスはAFNetworkingを利用しています。

#import "UBUriBeaconScanner.h"
#import "UBUriBeacon.h"

- (void)viewDidLoad {
    [super viewDidLoad];
    // スキャナの準備
    self.scanner = [[UBUriBeaconScanner alloc] init];
}

- (void)startScan {
    __weak typeof(self) wself = self;

    // コールバックを定義してスキャンの開始
    [self.scanner startScanningWithUpdateBlock:^{
        // スキャンして拾ったビーコン（複数）をループ処理しながら、リゾルバを呼び出す
        NSArray *beacons = [wself.scanner beacons];
        for(UBUriBeacon *beacon in beacons) {
            NSURL *u = beacon.URI;
            [wself resolveURI:u];
        }
    }];
}

// リゾルバにURLを渡して、メタデータを取得する
- (void)resolveURI:(NSURL *)url
{
    AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
    
    manager.requestSerializer = [AFJSONRequestSerializer serializer];
    manager.responseSerializer = [AFJSONResponseSerializer serializer];
    
    NSDictionary *params = @{
                             @"objects": @[
                                     @{ @"url": url.absoluteString }
                                     ]};
    
    // HTTP POSTリクエストでリゾルバのWeb APIを呼び出す
    [manager POST:@"http://atl-phyweb.net/resolve-scan"
       parameters:params
          success:^(NSURLSessionDataTask *task, id responseObject) {
              NSDictionary *results = (NSDictionary *)responseObject;
              // 結果を取得し、ループ処理
              NSArray *metadatas = results[@"metadata"];
              for (NSDictionary *metadata in metadatas) {
                  
                  Metadata *m = [[Metadata alloc] init];
                  m.title = (NSString *)metadata[@"title"];
                  m.url = (NSString *)metadata[@"url"];
                  m.iconUrl = (NSString *)metadata[@"icon"];
                  m.desc = (NSString *)metadata[@"description"];
                  
                  [self.metadatas insertObject:m atIndex:0];
                  if (self.metadatas.count > MAX_NUMBER_OF_METADATA) {
                      [self.metadatas removeLastObject];
                  }
                  [self.listView reloadData];
                  
                  
              }
          } failure:^(NSURLSessionDataTask *task, NSError *error) {
              
          }];
}

白石: コードもシンプルでわかりやすいですね。

加藤: ちなみにResolverの行う処理は、今のところ標準化されたりはしていません。受け取ったURLをどう料理するかは、今のところアプリケーション側に委ねられています。

将来的には、Resolverのような仕組みははGoogleなどの少数のプロバイダが提供するものを利用していく形と、DNSのように世界中で分散管理する方式が考えられると思います。一見、分散管理する方式のほうがインターネットの思想からすると理想的な気もするのですが、セキュリティの担保などを考えると、Googleなどの力のある企業が運営する形のほうが、うまく機能するかもしれませんね。Physical Webの課題として、悪意のあるURLに誘導しようとするビーコンの登場なども考えられますので。

インタビュー後 注釈(2) – サンプルコードとライブラリ

上記のサンプルコードはUriBeaconの規格用のライブラリを利用したものですが、 Eddystoneが正式に発表されたことにより、UriBeaconのプロジェクトは閉じられてしまいました。

とは言っても近いうちに、しっかりとしたEddystoneのライブラリコードも世に出てくると思われます。

インタビュー後 注釈(3) – Resolverはどうなる?

今回のEddystone発表の発表に合わせて、今までMetadata Resolverと暗黙に呼ばれていたこの サーバーサイドのサービスをPhysical Web Serviceとして、ドキュメントも更新されました。

Eddystone-URLを利用するにあたり、「仕様として必須ではないが、一緒に使うと便利なサービス」 という位置付けで進めていくようで、Google App Engineですぐに立ち上げられるpythonコードが引き続き提供されています。

Physical Web普及への課題

白石: Physical Webの課題という話が出ましたので、最後に、普及に向けた課題についていろいろお聞きできればと思います。思いつきですが、例えばBLEの範囲は10mと言われています。それが制限になったりといったことはないのでしょうか？また、BLE以外でもPhysical Webを使えるようにするという話は出ていますか？

加藤: 10mといった距離の議論に関しては自分は関知できていません。BLE以外でも、という話は挙がっていて、例えばuPnPやAppleのBonjourなどの上でも使えるようにするというアイデアは出ています。

白石: その他には？

加藤: 広く普及することを考えると、まだまだ課題が山積していると言えるでしょう。

例えば認証の問題があります。同じURIを通知することしかできないので、あらゆる人に同じ情報を見てもらいたい場合は問題ないのですが、ユーザーごとに違うコンテンツを見せたい場合とか、パーソナライズするのが難しい。

なので、例えば通りすがりに自動でチェックインするとか、ユーザごとにカスタマイズされたクーポンを送るとかが現時点では難しいです。同じ振る舞いをするビーコンを別の場所に置いておけば、同じようにチェックインできてしまうわけですし…。そういうわけで、パーソナライズされたアクションを、自動的に行わせるというのは厳しそうです。「CSRFと同じような問題」と言えば、Webエンジニアにはわかりやすいかもしれないですね。「チェックインしますか？」みたいなUIを通じて、ユーザーが1アクション挟まないといけなくはなるだろうな、と思っています。

それに漏洩の話もあります。会議室や建物の中でだけ共有したい情報があったとしても、BLEの届く範囲であれば誰でもその情報を受け取れてしまうわけです。このソリューションのために、前述したようなBLE以外のIPベースのネットワークを利用しようという案が挙がっているわけです。

最後にスパムの問題がありますね。悪意のあるURLを送りつけたり、多量の通知を送るといったことが想定されます。これはもしかすると、技術的な問題だけではなく、社会的な規制も必要になる分野かもしれません。ポスターとかも、どこにでも貼れるわけではありませんよね。

白石: なるほどー、実際に普及させるとなると、いろんな課題が出てきますね。

加藤: また、プラットフォームを普及させるのに付きものの、「ニワトリが先か、卵が先か」という問題もありますね（プラットフォームのユーザが少ないからサービスが作られない、サービスが作られないからユーザが増えない）。

GoogleがAndroidに抱き合わせるとか、例えばうち（リクルート）みたいな会社が店舗にビーコンを配るとか、ニワトリか卵のどちらかをまずは力技で解決しないと、プラットフォーム系は普及が難しいのかな、なんて思っています。

インタビュー後 注釈(4) – Google Now で Physical Web？

今回のGoogleの発表で、次のようにGoogle MapsやGoogle NowをEddystone対応させていくというアナウンスがありました。

これがEddystone-URLの話なのか、それともEddystone-UIDの話なのかといったように、どのような形で対応がされるのかはまだ分かりませんが、ひょっとするとGoogle Nowが最初のデファクトスタンダードの対応ブラウザとして、Physical Web普及のきっかけになるのかもしれません。

おわりに

白石: 本日は貴重なお話をありがとうございました。Physical Webの実現する世界について、最後に一言お願いします。

加藤: Physical Webのビジョンに、「リアル・ワールド・ワイド・ウェブ」というのがあると先ほどお話しましたが、更に「セマンティック・ウェブ」を掛け合わせて、「セマンティック・リアル・ワールド」と言えるようになるんじゃないでしょうか。現実世界のあらゆるものが、自身の持つ意味やメタデータを常に発信し、私たちはドラゴンボールのスカウターのようなデバイスや、MicrosoftのHoloLensのようなデバイスを通じて、それらのデータに視覚的にアクセスできるようになるかもしれませんね。

今回のデモ、Google Glassでも遊べました。未来。