PWAppsとは、最新のWeb技術を有効に活用し、漸進的（Progressive）に高度なユーザー体験を提供しようとする概念です。このPWAppsの概念を具体化する一つの手法として、「PRPL」（パープル）と名付けられた開発・提供パターンが提案されました。本稿ではこのPRPLを解説するとともに、その有効性や課題点を考察します。

本稿は、Google I/O 2016の二つのセッションに関する、解説記事です。

• Polymer and Progressive Web Apps: Building on the modern web
• Progressive, Performant, Polymer: Pick Three

PRPLの概要、PWAppsとの関係

PRPLは、次の4つの頭文字をとった、開発パターンです。

• Push
• Render
• Pre-cache
• Lazy-load

モバイルWebアプリケーションにおいて、現行のWeb開発・提供パターンが抱える課題点を解決するものとしてGoogleが今回の I/Oで提案した新たなフレームワークパターンです。

Web Componentsや、Service Worker、HTTP/2 Serveer Pushといった Webの最新技術をフルに活用し、レスポンス性の高いユーザー体験を提供しようというものです。PWAppsの具体的なパターンの一つとして位置付けられます。

PRPLについては、以降のパラグラフで詳しく解説するとして、まず最初にPWAppsについて概説します。

PWAppsが最初に発表されたのは、昨年11月。シリコンバレーGoogleオフィスで開催された Chrome Dev Summitのことです。モバイルWebアプリにメインターゲットをおき、ネイティブアプリに近いユーザー体験（オフライン動作や高速なレスポンス性）を漸進的に提供していこうという考え方です。

ここで、漸進的といっても、イマイチピンと来ない方も多いことでしょう。具体例としてService Workerのパターンについて紹介します。Service Workerの詳細ついては、HTML5 RocksやGoogleの安田絹子さんの記事（Service WorkerのChrome実装者です！）を参照ください。

Service Workerは、オフラインWebを実現する最新Web標準技術の一つ。オフライン環境でも動作するWebアプリケーションの提供を可能とします。オールドファッションなオフライン Web（Application Cache）とは異なり、柔軟なキャッシュ制御が可能となるため、多様なWebアプリケーションにオフライン Webの世界を適用することができます。ネイティブアプリのようにオフラインでも動作するWebアプリ体験を提供することが可能となるわけです。

また、Service Workerは単なるオフラインアプリの実現にとどまりません。多様なキャッシュ制御ができるということは、リソース（HTMLやJavascriptファイルなど）のロード時間短縮が可能となることを意味しており、アプリキャッシュによる高速なレスポンス性を実現します。

さらに、Service Workerは、プッシュ通知もサポートします。これにより、該当のWebサイトにアクセスしていなくても、通常のモバイルアプリのようにプッシュ通知を提供することができます。Service WorkerはモバイルアプリとWebアプリとの間の様々なギャップを埋め、より高度なユーザー体験を提供するためのAPIなのです。

では、このService Workerと漸進性との関係はなんでしょう？答えは単純で、Service Workerは、それが対応していないブラウザ環境であっても、Webサイトのサービス提供自体を止めることはありません。

したがって、非対応ブラウザ利用ユーザーには、ベースとなるWebサービスのみを提供し、対応ブラウザ利用ユーザーには、オフライン対応・高速なレスポンス性・プッシュ通知といったより高度なユーザー体験を提供します。これが漸進的なWebアプリケーションと言われる所以です。

現状のWeb開発課題を解決するPRPL

さて、本題のPRPLです。これは前述のService Workerなど、様々な最新Web技術を活用したWeb開発・提供パターンです。もちろん、PWAppsの理念に基づいています。

現状のWebアプリ開発の課題。バンドルの肥大化

最近のWebアプリ開発手法は、コンポーネント化による独立性・安定性の向上と、バンドル（単一ファイルの生成）による高速性の両者に基づいています。BabelやReact、npmといったツール類を用い、ES2015やTypeScript記法による洗練されたコンポーネント志向のコーディングを行いつつ、mochaやwebpackなどを用い、オートメーション化されたテスト駆動開発と全てのコンポーネントを集約したコンパイルの実行、バンドルを行うのがベストプラクティスとなっています。

ここで、コンポーネント化のメリットは解説不要でしょう。Webアプリの各機能要素をライブラリとしてコンポーネント開発することで、独立性・安定性・再利用性といった様々な恩恵を得ることができます。

一方で、バンドル化のメリットはなんでしょうか？答えは、ロード時間の短縮です。この点は、PRPLを理解する上で重要な知識となりますので、より詳しく紹介します。

そもそも、Webはコンポーネント志向を支えるプラットフォームであると捉えることができます。それぞれのコンポーネント要素（Javascriptライブラリ、HTMLテンプレート、CSS）は、それぞれ個別のリソースファイルとして提供され、 <script> タグや、 <link> タグなどにより個別にダウンロード、ブラウザ内で一連のプログラムとして結合・コンパイルされ、Webサービスとして提供されます。

しかし、このような開発・提供手法は甚大なユーザー体験の低下を招きます。HTTP/1.1の制約により、ファイルロード時間の増大を促してしまうのです。HTTP/1.1はリクエスト＆レスポンス型のデータ転送プロトコルとなっているため、リソースファイルのダウンロードが完了しないと、次のファイルのダウンロードを開始することができません。

この影響は無視することができないものであり、仮にブラウザとWebサーバー間の往復転送遅延時間を0.1秒とし、300個のコンポーネントリソースをダウンロードしなければならないとなると、0.1 x 300で合計30秒の待ち時間がサービス起動にかかってしまいます（実際には、平行ダウンロードにより数分の一に短縮されますが、極端な例として理解ください）。

これを解決するのがバンドルです。Webアプリ開発時に、サーバーサイドで一連のコンポーネントリソースを結合した一つのファイル（バンドル）を生成し、サービス提供時には、バンドルファイルのみをダウンロードすることで、転送待ち時間によるサービス起動時間を短縮する手法が用いられています（バンドル時には単に結合するだけでなく、ブラウザ依存の解決や、構文チェック・コードの最適化・重畳リソースの削減など、各種コンパイルプロセスが実行されます）。

しかし、これは新たな問題を引き起こしました。それはバンドルファイルの肥大化です。全てのコンポーネントが一つのリソースファイルに集約されるため、設計を怠るととんでもないサイズのバンドルファイルが生成されます。

最近では、SPA（Single-Page Application）の進展により、全てのルート（SPAに不慣れな方は、個別のWebページと考えていただいて結構です）を制御する一つのバンドルファイルが提供されることも珍しくありません。

このようなケースでは数百キロバイトのバンドルファイルとなることもチラホラ。ダウンロード時間の増大をもたらします。これは、モバイル環境のユーザーにとっては、とくに深刻な状況になりえます。

コンポーネント志向への回帰。PRPLによる解決

このバンドルファイルの肥大化問題を解決するのがPRPLです。最新のWeb技術を活用することで、バンドルを行わずとも、転送待ち時間によるユーザー体験の低下を解決することができます。

コンポーネントの定義

PRPLでは、各コンポーネントがWeb ComponentsのCustom Elementsで提供されることを前提とします。具体的には、各コンポーネントが カスタム要素としてHTMLファイルとして提供され、親となるHTMLからはHTML Importsにより各コンポーネントの利用が宣言されます。

この手法の重要な点は、標準化された手法によりコンポーネントの利用が宣言されること、これによりサーバーサイドでHTML Importsのリンクを解析し、Webサービスに必要となるコンポーネントツリーを得ることができます。これが、その後の HTTP/2 Server pushの適用につながります。

HTTP/2 Server pushの適用

先に解説した通り、HTML Importsで記述した場合、個別のリソースファイルの転送待ち時間によるサービス起動時間の増大が発生します。これを解決するため、PRPLではHTTP/2 Server pushが利用されます。

HTTP/2は、HTTP/1.1に続く最新バージョンのファイル転送プロトコル。HTTP/1.1のリクエスト＆レスポンスによる待ち時間の制約を受けずに、複数リソースファイルを効率的・スピーディーにダウンロードすることが可能になります。

HTTP/2では、ダウンロード完了を待つことなく、以降のリソースダウンロードを行うことができます。したがって、サーバーサイドでバンドルすることなく、個別のコンポーネントファイルを高速に転送することができるのです。

PRPLでは、さらなる転送時間の短縮を図るため、HTTP/2 Server pushが用いられます。先にも書いた通り、PRPLでは各コンポーネントファイルがHTML Importsの記法により親となるHTMLファイルに記載されています。したがって、最初のHTMLファイルがダウンロード完了しないと、各コンポーネントファイルのダウンロードを開始することができません。

しかし、HTTP/2 Server pushを用いると、この待ち時間すら短縮することができます。前述の通り、PRPLでは、サーバーサイドで HTML Importsを解析し、コンポーネントツリーを得ます。そして、そのコンポーネントを最初のHTMLファイルに対するレスポンスヘッダーに記述することで、HTTP/2サーバーはクライアントからのリクエストを待つことなく、以降のコンポーネントリソースをPushすることができます。

これにより、いわゆる0 RTT（Round-Trip Time）で、全てのコンポーネントリソースをブラウザに転送することが可能になります。

Service workerによるpre cache

ここまでであげた手法により、初期起動に必要となる リソースを高速に転送し、ユーザーの起動待ち時間を短縮することが可能となりました。しかし、Webサービスは、初期画面だけではありません。その後の、ユーザー操作に基づいた各画面の提供が必要となります。

例えば、ショッピングサイトでは、各商品画面や商品購入画面が必要となります。これらを形成するコンポーネントは、初期画面に含まれるものもあるでしょうし、それ以外のものも含まれるでしょう。これらのコンポーネントリソースのダウンロード待ち時間を短縮するために、PRPLではService Workerが用いられます。

PRPLでは、初期画面用のコンポーネントリソースをService Workerを用いて、キャッシュに保存します。以降の画面で該当のコンポーネントが必要になった場合は、このキャッシュが用いられるためダウンロードは発生しません。

また、初期画面を表示したあと、以降の画面で必要となるコンポーネントリソースをバックグラウンドで事前にダウンロードし、Service Workerを用いキャッシュとして保存します（pre cache）。したがって、これらのコンポーネントリソースについても待ち時間は発生しません。非常にレスポンス性の高いWebアプリをon-the-flyで提供することが可能となります。

さらにユーザー体験を向上する lazy load

最後にlazy loadです。Webアプリのリソースには優先度があります。例えば、ファーストビューには表示されない画像ファイル、初期画面のメニューコンポーネントなどは、優先度が低いリソースの典型的なものです（メニューは、ファーストビューに含まれますが、最初からは表示されてなくてもいいですよね！）。

これらのリソースについては、lazy-loadとして、優先度の低いものとして宣言してしまいます。こうすることで、ブラウザはこれらのリソースのダウンロード順番の優先度を下げ、ファーストビューに本当に必要なものを優先して表示することができるようになります。

サンプルサイト、開発ツール

PRPLを活用したサンプルサイトとして、ショッピングサイトのサンプルが公開されています。

https://shop.polymer-project.org/

Chromeのdev tool、networkタブのwarter fallパターンから、PRPLの転送フローを確認することができます。

また、開発ツールPolymer App ToolboxではPRPLの一端が提供されています。

$ npm install -g polymer-cli
$ mkdir my-app; cd my-app
$ polymer init app-drawer-template
#... write code ...
$ polymer build

HTTP/2対応ブラウザ、非対応ブラウザ用に、それぞれPRPLの概念に基づいた非bundle版、bundle版のjsが生成されます（こういったところに、PWAppsの概念が適用されています）。ただし、こちらの開発ツールでは、HTTP/2サーバーは提供されておらず、PRPL概念の一部を具体化したものとなっています。その点は、注意してください。

PRPLは即座に利用可能か？

さて、今回のGoogle I/Oで発表・提案された新たな開発・提供手法のPRPL。最新のWeb技術を活用することで、従来のWebアプリが内包する課題を解決し、モバイル環境での最高のユーザー体験提供を目指したものです。ただ、ここで気になるのが、以下の2点です。

• 「PRPLは今すぐ、production環境に適用できるものなのか？」
• 「本当にこれまでの開発プラクティスよりも優れているのか？」

この点について、（あくまで）個人的な見解を述べ、本稿を締めたいと思います。

まず結論から言うと、「Productionでの利用は、まだ早い」 というのが僕の率直な感想です。

その理由として、以下の点があげられます。

まだHTTP/2の環境が整備されていない

HTTP/2は、最近標準化が完了したばかり、実装はまだ完全には追いついていません。実際、apahceやnginxではHTTP/2の基本機能は搭載されているものの、Server pushまだ未サポートです。

また、これらの実装が完了したからといって、それがすぐ Productionに適用できるというものではありませんし、AmazonのELBやHerokuなどIaaS/PaaS事業者側のサポートも必要となるでしょう。WebSocketがそうであったように、サーバーサイドのエコシステムが整備されるのにはしばらく時間が必要です。

まだ開発者フレンドリーではない

開発ツールPolymer App Toolboxを見てみてもわかりますが、PRPLの概念はnpm + webpackのような開発者フレンドリーな開発手法とは相性が悪いです（実際、bowerが用いられています）。

Webアプリのコンポーネント開発において、Javascript部分が占める割合は非常に大きく、これをbowerベースで行い、いちいちHTML Importsで記述することは大変なストレスとなります。やはり、npm + webpackでストレスレスにコーディングしたい…、というのがJSエンジニアの率直な意見でしょう。

cacheとの相性が悪い

PRPLで用いられているHTTP/2 Server pushですが、Webのキャシュと非常に相性が悪いことが知られています。基本的に、ブラウザの状態と無関係にリソースをPushする仕組みのため、ブラウザにキャッシュがあろうがなかろうが、リソースをPushしてしまいます。

したがって、「初回の起動である」、「常にダイナミックに変動するリソースである」の場合を除いてHTTP/2 Server pushの効果は限定的ですし、逆に負の効果をもたらします(キャッシュがあるのであれば、リソースをPushする必要はない)。バンドルのサイズ肥大化の問題も、persistant cache制御さえちゃんとしてやれば、初回起動時およびバンドル変更時の問題だけになります。

最後に

最後にネガティブな意見を述べましたが、僕はPRPLの考えには基本的に賛同しています。Googleは常にWebをより良いものにするため、努力を続けている企業。その姿勢の表れであると感じています。

本稿で述べたPRPLの限界点は、現状のツール環境に依存するところが大きく、新たなツールが登場することでこの状況は一変することでしょう（本来、ツールは概念の一部を具現化するものであって、それをもって概念全体を評価されるべきものではありません）。

さまざまな概念やツールが融合し、開発者がフィードバックしていくことで、よりよい形が作り上げられていく。これまでのWeb開発の進化がそうであったように、そのような文脈の中でPRPLや、それのベースとなっているPWAppsが進化していくことでしょう。

Google loves the web

ChromeチームWeb Platformをより先に進めるために、ここ1～2年取り組んでいるアプローチの紹介です。

まず、前提としてGoogleはWebが大好きです。Googleの同僚は皆、Webが大好きです。そしてChrome Teamには「Webをより先に進める」という重要なMissonがあります。ここで私がWebと言っているのはChrome Webということではなく、全てのWebのことを指していて、それら全てのWebが素晴らしくなってほしいと思っています。

よって、Interoperability（相互運用性）を保ちモダンブラウザの全てにShipされるまでが我々の使命です。なぜならInteroperabilityが保たれずShipしてしまったら、誰でも・いつでも・どこでも利用できるというWebの最も大きく重要な利点の1つが失われてしまうからです。Vender Prefixを廃止したのもそういった理由です。

Chromeにおいては、Web Platformをより先に進めるために4つのアプローチをを持ち取り組んでいます。

Chromeチームが取り組んできたこと

• 複数のチャネルを持つ（Stable, Dev, Canary、Beta）
• 実験的な機能にはExperimental flagを設けONにしないと動かなくしている(chrome://flags のことでWeb Bluetoothもこの1つ)
• Original Trials：実装したAPIをそのままExperimental flagとして提供してしまうと、いつの間にかデファクトになってしまう可能性があります。APIの仕様・実装を吟味してからShipすることがよりよいWebを作るのには必要不可欠です。よって、Feedbackをすることに同意したDeveloperのみ利用を可能にすることで、利用するユーザー数を絞り、さらに期間を区切ることでデファクトすることを防ぎ、実験のIterationのスピードを上げることを目的としています。さらに多くのDeveloperが使い始めた場合は自動的に利用を停止する機能も入っています。
• Incubation of substantial new feature(wicg.io)：Web Incubator Community GroupをW3Cでにて行っています。標準化のProposalの議論をライトウェイトに行うグループです。チャーター（W3Cで議論を進める場合には必ず作成します）を作ったりすることに全ての時間は費やさないものの、正しく管理されるし、Contributionも受け付けることが可能です。もし新しい機能を提案したい場合は是非このグループに提案してください。

しかし、機能を追加するだけではWeb Platformを健康に保つことはできません。よって、機能の削除も行います。削除の理由には、他のAPIとの入替えや、実験的に作ったが上手くいかなかった、というものがあったりします。3つ前までで削除された機能のリストがこちら(goo.gl/5gq1Im)です。今後、requestAutoCompleteだったり、HTML5 App Cacheのような影響の大きな機能も削除しようとしています。まだ使われている機能、APIをいきなり削除しないというようなポリシーもありますので安心してください。

これまでの成功の紹介

それでは、ここ数年での成功を紹介します。私がここに立っている、ということは何のことだか分かる方も多いかも知れませんが、そうですWeb MIDIです。

MIDIは知ってる方もそうでない方もいると思います。仕様ができてから30年以上にもなる楽器のキーボード、シンセサイザー等、電子楽器同士、またはコンピュータとを接続する標準化されたプロトコルです。数年前Web Audioで遊んでいたときに「これを楽器のキーボードから操作したい」と思い立ったW3Cにて標準化を始め、Chromeでは去年Shipされました。

ChromeでのShip以降、多くの楽器メーカがユーザー体験を提供するプラットフォームとしてWebを使い始めました。Yamahaはrefaceという新しいシンセサイザーのラインナップに対してSoundmondoという音色のエディタ、ライブラリアンを提供するWeb MIDIを使ったサービスを展開しています。NovationのCircuit Groove BoxはWebに接続して新しいサンプルをダウンロードします。これらの作業においてソフトウェアを新たにインストール必要はないのです。

そして、間違いなくスゴイことはフランスのEDMアーティストであるMadeonがWeb Audioで作られたRemixBoardをWebサイトで公開したことです。ファンに向けられて作られたサイトで、彼のアルバムの中の音をRemixして遊ぶことができるのです。もちろんMIDIデバイスも接続してプレイすることができるようになっているのです。
（デモ（パフォーマンス？）が始まります。実際の動画を御覧ください）

デモアプリのURLはこちらwww.madeon.fr/adventuremachineです。

「これスゴイでしょ？！」と言いたいのですが、本質はそこではなくて「ハードウェアがブラウザにアクセスできる」ということが大きな可能性を生んだ、ということを伝えたいのです。ちょうど加速度センサから素晴らしいユーザー体験（UX）が生まれ、モバイル・デバイスが大きな可能性を持ったのと同じようにです。他にも接続できることで大きな可能性が生まれるデバイスはたくさんあると思います。我々は、そこにある可能性を積極的に解き放っていきたいと考えています。

（ここでChris氏からFrançois氏に交代）

これから何が起こるのか

Web Bluetooth

Bluetoothの名称の由来の説明から始まります。（詳しくはWikipediaのBluetooth 「名称の由来」をどうぞ）

Bluetoothはいろいろなバージョンで20年成長してきた技術で、最新はBluetooth Low Energy（BLE）が導入されたVersion 4でリリースされてから6年経過しています。Wi-Fi、Ethernetのスピードは継続的に上がっていますが、Bluetoothはちょっと様子が違っています。

なぜなら、今まで接続されていなかった多くのデバイスに搭載できるようにバッテリの消費量を最小限にできるようにデザインされているからです。例えば小型のデバイスが使うバッテリは、通常CR2032です。（2032の20は直径、32は厚さを表すそうです！）なので、転送速度はとっても遅いのです。ですが、BLEはそもそも転送速度が遅くても大丈夫なデバイスをターゲットにしているので問題はありません。

それでは、デモをしてみます。デモはPlaybulb Candleという電球のOn/Off、色をBluetooth通信にて変更できるデバイスをWebアプリから操作します。（映像には全体が映っていませんでしたが、会場ではこんな感じでデモが行われていました）

Bluetooth SIG(Bluetoothの規格の策定、技術利用に対する認証を行う団体)は、これから先2年で96%の電話、タブレットにBLEが搭載されると予想している。そこからも、いろいろな場所でBLEが存在するであろうことがお分かりになると思います。

Web BluetoothのAPIを説明する前に、一度BLEの動作を復習してみます。Bletoothには、以下の2つの機能があります。

• Central：近隣のデバイスを探索する（電話、ラップトップPCの等）
• Peripheral：周囲に向けて継続的に自らの情報を格納したアドバタイジング・パケットをBroadcastする。（心拍センサ、ビーコン、冷蔵庫等）

PeripheralがCentralに接続（ペアリング）されると、Peripheralはアドバタイジング・パケットのBroadcastを停止し、CentralがPeriferalで動作するGATTサーバと通信を開始する。通信に関しては、デフォルトで用意されているバッテリ、心拍のようなサービスも存在していますが、もちろん独自にサービスを作ることも可能になっています。それぞれのサービスにはそれぞれのCharastristicに属性を持っていて、読込み（バッテリーレベルの取得等）、書込み（設定の変更等）、また更新時に通知（心拍数のリアルタイム監視）してもらうことも可能です。Web Bluetooth APIを使って書いたサンプルを説明していきます。

値の読込み

コードはラップトップがCentral、何かしらのデバイスがPeripheralとなっていることを想定しています。まず、Centralのラップトップがnavigator.bluetooth.requestDevice(option)をCallして近隣のデバイスを探索します。optionにデバイスが山ほど列挙されないためにどの種類でフィルタするかを記述します。コードではバッテリのサービスは標準化されているので「batttery_service」と文字列で指定していますが、アドバタイジングパケットにはカスタマイズした値も書込むことが可能です。

navigator.bluetooth.requestDevice(option)をCallすることで探索が開始され、それと同時にアドレスバーの直下に該当するデバイスを列挙するポップアップが出てきます。ユーザがリストからデバイスを選択すると、JavaScript側ではそのデバイスのデバイス名、利用可能なサービスが格納されているオブジェクトにアクセスが可能になります。

ここでセキュリティに関する注意点。
navigator.bluetooth.requestDevice(option)はユーザのインタラクションにて初めて動作します。デモではボタンクリックで開始していました。Localhost以外のホストでWeb Bluetoothを使う場合は、HTTPSでコンテンツがServeされたことを要求している。

device.get.connect()をCallしてGATTサーバと接続をします。その後に、server.getPrimaryService(‘battery_service’)でバッテリサービスを取得、service.getCharacteristic(‘battery_level’)で読込みたいCharacteristicを指定して取得、最後にcharacteristic.getValue()をCallすることで、バッテリのレベルの読込み（取得）をすることができます。

値の書込み

先ほどとは違い、心拍センサをPeripheralとしています。その他、ハイライトされた部分が違います。charctristic.writeValue()にUint8Arrayにて、1バイトを引数に渡すことで書込みを行っています。

更新の受取り

この例でも、心拍センサをPeripheralとしています。この例でも、ハイライトされた部分が違います。characteristicにcharacteristicvaluechangedのイベント名でEventハンドラを設定し、beepという関数をCallbackとして指定しています。characteristic.startNotifications()で、更新の受け取りを開始します。これで、更新がある度にbeepが実行されます。

続いて、心拍センサを動作させるデモです。私（François氏）は心拍センサをつけています。リアルタイムに値を受け取ることができますので、ちょっと見てみましょう。通常私の心拍数は60-80ですが、今はどうでしょう？

（普段の倍近くの心拍数が表示されChris氏も会場も爆笑）
次に実際にリアルタイムに心拍数を受け取っていることを証明するために腕立て伏せをしてみます。（前編の最後に掲載さいた画像はここでの1シーンです）
（が、ペアリングが切断されたのか動作せず……そして、今度はChris氏も会場も大爆笑！失敗するということは、デモがリアルタイムに行われている証拠です！）

私以外にも、Web Bluetoothで遊んでいる同僚たちもいます。

Bluetoothのパケット通信の中身を見るときはAndroidを使うのが最も簡単な方法です。AndroidのDeveloper Optionにある「Bluetooth HCI snoop log」を有効にしてください。（詳しくはこの辺りを参照してみてください）

現在Web BluetoothをサポートしているブラウザはOperaとChromeOS、マシュマロ上で動作しているChrome for Android、Chrome for LinuxでChromeでは chrome://flags/#enable-web-bluetooth （アドレスバーにコピー＆ペーストしてください）を有効にすることで利用することが可能です。Mac、WindowsのChromeへは現在実装中です。

開発の助けになるであろう以下の2つを紹介します。

• Get Start with Web Bluetooth (goo.gl/MLKzj2)：コードジェネレータ
• Web Bluetooth Developer Studio Plugin (goo.gl/c2ype5)：Bluetooth SIGが提供しているBluetooth Developer Studio向けのPlug-in

WebアプリからでもNativeアプリと同じように、Bluetoothでデバイスを操作できるようになりました。また、Webアプリですので、URLをシェアすることで、誰でもスグにアプリを利用できるようになります。当たり前のことかもしれませんが、これがWeb Platformの大きな強みです。

Physical Webとの連携

URLを載せたBluetoothのパケットをビーコンからブロードキャストするPhysical Webですが、これがもしBluetoothのアプリからブロードキャストできたらどうでしょう？

URLをPhysical Web経由で受け取り、そのURLにアクセスするとBluetoothデバイスをコントロールするアプリが表示され、Bluetoothデバイスとのペアリングが完了したら、その直後からBluetoothの利用が可能になりますよね。今までのアプリを検索してインストールする等の作業が一切必要がなくなり、通知エリア(Notification Area)に通知されたURLにアクセスするだけでペアリングも含め、Bluetoothデバイスを利用する準備が整うことになります。

今後、Web BluetoothはPhysical Webの機能を組み込み、前述の動作を一気通貫でJavaScriptで実装できるような機能を追加する予定です。

CodelabもControl a PLAYBULB candle with Web BluetoothとInteractive with Bluetooth devices on the web with Polymerもありますので、是非挑戦してみてください。

（再びChris氏）

Web USB

Web USBは現存する全てのUSBデバイスに接続しようと考えているわけではなくて、Firmwareへのアクセスを許可されているような新しい種類のデバイスに適用されます。

まとめ

ここではカバーしきれなかった、まだまだ多くの以下の様な機能が進行中です。

さらに、まだデザインも始めていないPersistent Storageとか、Web Intents v2もあります。

そろそろ時間です。我々がWeb Platformの未来にワクワクしているのと同じくらいに、皆さんもワクワクしていることを期待しています。

developers.google.com/web/updates/ にさらなる情報がありますので、お時間がありましたらご覧ください。

（というところで、セッションは終了しました）

ありがとうございました＆お疲れ様でしたっ！！！