第1回で技術の概要と展望を、第2回と第3回で要素技術について、第4回で競合技術との差別化ポイントなどを解説させていただきました。それらの内容を踏まえたうえで最後となる今回は、さらなる応用の可能性と、それに伴う課題を挙げていきたいと思います。
応用を考えるにあたり、この技術の重要なポイントとなるのは次の2点です。
- リアルワールドに情報やサービスのフックを増やしていく
- そしてその情報やサービスは、URIから始まる
1. 情報発信のフックをどこにしかけられるか
これまでも少し触れてはいますが、UriBeaconとして振る舞うのは、典型的な独立可動タイプの小型ビーコンでなくても良いわけです。BLEチップさえ組み込んであれば機能は満たせるので、商業施設におけるマシン、デジタルサイネージ、家電などにも組み込んでいくことが可能です。
ビーコンというと、商業施設などの「場所」に特化した情報に意識が行ってしまいがちですが、第1回でも書いたとおり、ネームプレートやスマートフォンがその持ち主の情報を発信していても良いわけですし、家電製品が自身の「取扱説明書」のURLを発信しても良いでしょう。
どんなところに情報のフックを差し込むと便利か、自分の生活の中で改めて探してみると面白いかもしれません。
2. URLから始まるサービス
そして、受け取ったURIからサービスを開始するのですが、このURIは、まずはメタデータ、そしてコンテンツそれ自体の取得のために、2つのステップで利用されるのでした。
この2つのフェーズでもどのような応用が可能かを考えてみましょう。
2.1 メタデータ
メタデータとして有名な一例はOGPであり、実際に現在のリゾルバのサンプルでもそれは利用されているのでした。詳しくは第3回をご参照ください。
今回はOGP以外の別のメタデータ仕様を利用して、さらに利便性を向上できないか考えてみましょう。
Deep Linkを使った応用例
例えばDeep Linkはどうでしょうか。
Deep Linkは、モバイルアプリのための連動技術です。
GoogleはApp Indexing、FacebookはAppLinks、と言ったように様々な事業者が提唱しているDeep Linkのための仕様が存在します。より詳しくはそれぞれの詳細ページを参照されると良いでしょう。
今回はAppLinksを使ってみることにします。 まずHTML内に決められたmetaタグで必要な情報を埋めます。
プロパティ名を見るだけでもそれぞれが何を表しているのかわかるのではないのでしょうか。
このように、AppLinksではそれぞれのモバイルプラットフォームにおけるアプリ起動のための独自スキームURLや、ストア上で表示するためのアプリIDなどをHTML内にあらかじめ埋め込んでおくことで、このサイトに関連するアプリがそのプラットフォーム上に存在した場合に、それと連動させるための情報として利用することが出来ます。
MetaData ResolverがこのHTMLを回収した際に、これらのデータをパースし、第3回で紹介したJSON-LDによる拡張パートとして埋め込みます[1]。
あるいは最初からHTMLの中に次のように独自定義したJSON-LDとして埋め込んでおいても良いかもしれません[2]。
そうすると、リゾルバは次のようにMetadataを返します。
具体的なパケットの中身は次のようなJSONになるでしょう。
スマートフォン側では、このレスポンスをチェックし、該当するネイティブアプリがあれば処理を移行したり、あるいはそのアプリがインストールされていなければ、そのプラットフォームにおけるストアの該当ページへ飛ばしたりするということが出来るようになるでしょう。
ビーコン→URI→Webサービスで完結するフローも魅力的ではありますが、コンテンツの種類によってはNativeアプリのほうが相性が良い場合もあるでしょう。Deep Linkによってその溝を埋めることも可能になります。
このように、メタデータを使ってサービスを向上させることが可能です。今回はDeep Linkによる例を見てみましたが、他にどんなメタデータがあると便利なのか、是非考えてみてください。
2.2 コンテンツ
メタデータの次は、そのURLから始まるコンテンツやサービス自体について考えてみましょう。
最もシンプルなのがHTTP GETによる情報の取得です。メソッド自体は今までのWebの世界と同じではありますが、この用途に最適なコンテンツの種別が今までとは違ったものになってくるでしょう。このあたりは第1回で説明したとおりです。
また、HTTP GETによる単純な情報取得で終わらず、ブラウザ内でWebアプリケーションを利用することも当然ながら可能になります。サービス提供者側は、リアルワールドにフックを仕込み、うまくWebサービスにつなげて行くようなサービス設計の発想が要求されます。
本領発揮するHTML5
上のメタデータの応用例で挙げたDeep Linkのように、アプリとの連動機能を利用する手もあるとは言え、基本的にはWebでのサービス提供をまず考えることになります。
WebブラウザまわりでもService WorkerやWeb Pushのようなイノベーションが進んでいて、従来ネイティブアプリに対して遜色のあった部分が徐々になくなってきつつあります。
Physical Webのようなプラットフォームも、そのような分野の進展と合わせ、Webへの回帰を推進するシナジーとなるかもしれません。
また、それだけでなく、今までになかったタイプのサービスが提供できるのではないかと考えられないでしょうか。
今までにないWebアプリケーション
あまり知られていませんが、例えばWebNFCと言ったような規格もあります。
イベント会場に近づくと、入り口に設置されたビーコンからイベントサービスのURIを受信し、そのWebページを開いて入り口にあるカードリーダーでNFCでチェックイン、と言うようなWebアプリケーションの提供も可能になるかもしれません。
またWeb Bluetoothと言うものも一応存在します。基本的にはiOSやAndroidのネイティブSDKにおけるBluetooth関係のAPIに相当するものをFirefox OSなどのOSで使うためのものであって、いわゆるWebブラウザのための機能ではないのですが、こういった機能がPhysical Webと連動するWebブラウザでも使えるようになると面白いのではないでしょうか。
家電に近づけばそこに仕込まれたビーコンが飛ばしたURLを拾います。Webブラウザで開くと、その家電をBluetoothで操作するコントローラがWebアプリケーションとしてそこに表示されている、と言うのはどうでしょう。Physical Webのブラウザを開けば、まわりにある機器のコントローラがすでに手元に集まっている、ということも可能になるかもしれません。
NFCやBluetoothなど、周囲のデバイスとのインタラクションを行う機能がWebブラウザに搭載されていても、今までは嬉しさがあまり無かったかもしれませんが、Physical Webと組み合わせることで価値が変わってくるものもあるでしょう。
課題
spamや不健全コンテンツ
情報のフックが増えてくるとspamの問題が出てきます。URIを受信したブラウザアプリケーション、第3回で紹介したMetadataのリゾルバの2箇所において、何らかのフィルタリング技術が求められるのではないかと考えられます。
また、アダルトコンテンツなどの不健全コンテンツがむやみに発信されるという可能性もあります。看板や張り紙などは、法律や条例で規制がされています。ビーコンを利用した場合も、公衆における情報配信になってしまうところもあるので、フィルタリングなどの技術だけでは解決できず、何らかの法律的な規制が必要になるのかもしれません。
パーソナライズされたサービスにおけるセキュリティ
フィッシング
ビーコンから始まるWebサービスなどでは、ログインが要求される事もあるでしょう。ダミーのログイン画面のURLを発信し、パスワードを抜き取ろうとするようなフィッシングビーコンの登場の可能性もあります。
自動化は出来ない?
あるビーコンの横を通ったら自動でチェックインさせられないか、というような種類の要求もあるでしょう。しかし特定URLへの1回のアクセスで何らかのデータ変更ができてしまう場合、CSRFと同じ問題が発生します。
ビーコンが発信してるURIさえわかれば、同じURIを発信するビーコンを用意して全然関係ない場所に置き、その横を通り過ぎたユーザにチェックインさせてしまうことが出来てしまいます。
ユーザがトリガーを引く画面は用意して、その裏ではCSRF対策と同じようにワンタイムトークンなどを利用した対策が必要になるでしょう。
また、Metadata Resolverを通すアーキテクチャは、そもそもが自動アクションには向いていません。
ビーコンの詐称
トークンを使った対策をすれば良いだけかというと別の問題もあります。本当にそのビーコンの横を通ったかと言うチェックのことを考えなければなりません。クーポンのように積極的にばらまいても良いものなら問題ないですが、「必ずそこを通った人にだけ特典を与えたい」という場合、その保証は簡単ではありません。
ビーコンが発信しているURLを確認し、同じURLを発信するビーコンを別の場所に用意する、と言うことが簡単に出来てしまうからです。
あくまで応急処置的な一例ではありますが、次のようなものも考えられるでしょう。
ビーコンは定期的に有効期限に制限のついたトークンをバックエンドのサーバに発行してもらい、そのトークンを含めたURLを発信するようにします。
ユーザからアクセスを受けたWebサービスは、そのtokenが有効なものかどうか検証を行います。
ビーコン自体の盗難や、ビーコンが行うバックエンドのやり取りが漏れる可能性にも注意を払わなければなりません。
これらのように、今までのWebのサービスとはちょっと違うタイプの課題があり、それらを解決していかなければなりません。
Physical Webの今後について
実用化のメドは?
さて、エンジニアの皆さんにとって一番気になるのは、「それで結局いつになったらこの技術を実用できるのか」というところだと思います。
Physical Web関連の標準化が進み、その恩恵を受けられるようになるには、少し時間がかかりそうではあります。しかし、iBeaconが要求されるような案件において、やりたいことがシンプルな情報配信であるならば、実はもうUriBeaconだけ部分的に採用してしまって良いのではないかと個人的には考えています。
URLではなくUUIDをビーコンにセットし、iBeaconのProximityUUIDの代わりとするか、あるいはURLを使い、そのドメインをチェックすることで自社のURLだけ通すようにしてしまえば独自アプリを作ることも可能です。
UriBeaconの仕様は単一機能のためシンプルで安定していて、今後変更されにくいと思われます。すでに海外ではビーコンの販売サイトも出てきて、UriBeaconコミュニティの公式Twitterアカウント自体が宣伝していたりします。
iBeaconでもUriBeaconでもどちらでも成り立つ案件であれば、UriBeaconを利用しておけば、キラーアプリケーションとなるPhysical Webの標準ブラウザのようなものが登場したとしても、そのままビーコンを利用した情報配信を継続できる可能性もあります。
今のうちから使えるところは使いつつ、次の展開があったときに即座に動けるようにしておく、あるいはさらにコミュニティへのフィードバックを行ったり、自らがキラーアプリケーションとなるサービスを取りに行く言うようなチャレンジをしたりするのも面白いのではないでしょうか。
最後に
5回に渡ってPhysical Webの紹介をさせていただきました。2015年3月の連載開始タイミングでは業界内であまり取り上げられていませんでしたが、2015年4月に入ってから状況が変わりつつあります。
4月9日に六本木ヒルズで行われた、Google Developer Summit 2015のセッションの中でもPhysical Webについて軽く紹介がされました。そのあたりのタイミングから徐々に海外などの記事も増えてきて、少しずつ注目を集め始めています。
5月末に行われるGoogle I/Oや、それ以降の続報に注目したいところです。今後の動向も是非チェックしてみてください。