皆さん、来週2015年10月26日〜30日の5日間、W3C Technical Plenary / Advisory Committee Meetings Week(TPAC)というイベントが開催されるのをご存知ですか？

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での熱い議論、参加される方は現地で、参加されない方もインターネット等を通して、ぜひウォッチしてみてください！新しい発見があるかもしれません。