イベントに参加できなかった方に向けてセッションの内容を記事にまとめましたので、ぜひご覧ください。

この記事では、昨今話題に上ることが多いPWAことProgressive Webアプリケーションについて、実際の作り方を解説しながら、それがいったいどういったものであるかを詳(つまび)らかに紹介することを目的としています。

Webでは、「ネイティブアプリと同じことができる」「ネイティブアプリを置き換える」など、期待に胸を膨らませずにいられない浪漫に満ちた噂がありますが、それが本当かどうか記事をご覧いただくとご理解いただけると思います。

Progressive Web Appsの作り方を紹介する前に、簡単に概要を紹介しましょう。

Progressive Web Appsとは?

Progressive Web Apps(以下PWAと記述) は、一言でいうならば「ネイティブアプリのようなUXを提供するWebアプリの概念」といったところでしょう。2015年の11月に開催されたChrome Dev Summit 2015のキーノートで発表されて話題となりました。

もともとは、その年の10月にAlex Russell氏(Google)がブログ記事に投稿した、クライアントの性能に合わせて段階的に進歩するWebアプリケーションのコンセプトでした。

PWAというと、”ネイティブアプリのような体験”といった特徴ばかりが注目されますが、大きな特徴がもう一つあります。それは、PWAという名前にも含まれているProgressiveというところです。

これはHTML5が普及しはじめた頃にあった、「HTML5が解釈できるモダンブラウザーにはリッチな体験を、そうでないブラウザーには従来とおなじ体験を」というデザインの考え方 Progressive Enhancementに由来します。

PWAはこの思想を踏襲し、性能の低いWebブラウザーを切り捨てることなく、クライアントの性能に合わせた機能提供を行います。

PWAは、性能の低いWebブラウザーからアクセスがあった場合は従来と同じWebページとして動作し、PWAが動作する機能を備えたWebブラウザーからアクセスがあった場合は、その機能を活かし、これまでのWebアプリにはなかったネイティブアプリのような体験を提供します。

Progressive Web Appsを実現する機能

それでは、”これまでのWebアプリにはなかったネイティブアプリのような体験”というのはどのようなものがあるでしょう?

代表的なものとしては以下の4つが挙げられます。

1. オフラインサポート
2. プッシュ通知
3. バックグラウンド処理
4. デバイスへのインストール(デバイスのホーム画面から起動できる)

これらはの機能はそれぞれ以下のような新しいAPIによって実現されます。

1. オフラインサポート – Cache API
2. プッシュ通知 – Push API
3. バックグラウンド処理 – Background Sync
4. デバイスへのインストール(OSのメニューから起動できる) – Web App Manifest

そして、これらの機能を提供しているのが1～3がService Workerで、4がWeb App Manifestです。

PWAの定義に明確なものはありませんが、上記の機能の中からオフラインサポートと、インストール（アイコンをデバイスのホーム画面に追加）機能をサポートしていれば、PWAを名乗ってもそう否定されることはないでしょう。

これらの機能により、デバイスのホーム画面から、ナビゲーションバーなどのブラウザーUIがない状態でアプリケーションを起動し、オフラインの状態でも使用できる、という体験をユーザーに提供できます。これらの体験は、これまでのWebアプリケーションにはなかったネイティブアプリのならではのメリットと言えるでしょう。

それでは、逆に Web ならではのメリットとはなんでしょう?

Webのメリット

ネイティブアプリにはないWebならではのメリットを、Googleさんのイベントではよく以下のSLICEという言葉で表しています。

• Secure (安全)
• Linkable (リンク可能)
• Indexable (インデックス可能)
• Composable (再構成可能)
• Ephemeral (一時的な利用)

これら従来のWebとネイティブアプリの体験上のメリットを合わせたものが、PWAのメリットとなります。

Progressive Web Appsが提供する価値

PWAの提供する価値について、GoogleさんのイベントではよくFIREという言葉で紹介されていますが、

• Fast: パフォーマンスの良い、軽快な動作
• Integrated: OSと統合されたユーザー体験
• Reliable: オフラインでも動作する利便性と信頼性
• Engaging: Webサイトの価値向上

この記事ではもう少しかみ砕いて紹介しましょう。

発見性

PWAであれば、アプリを公開するのにアプリストアにわざわざお金を払ってアプリを提出したり、審査を通すための不自由なルールに縛られる必要はありません。これまでのWebアプリと同じようにインターネットに公開しておけば、検索エンジンがクロールして見つけてくれます。

いままでのSEOのスキルがそのまま使える上、Webはアプリストアとは比べものにならない数のユーザーが、比べものにならないくらいの回数、常に検索を行っています。この圧倒的なオポチュニティ（機会）の違いは、自分自身が今日何回Webを検索したか、アプリストアを何回検索したか、比べてみればよくわかるでしょう。

インストール可能

PWAはさまざまなデバイスにインストール可能ですが、そのためにプラットフォームごとに違う開発言語で書き直したりパッケージンクしなおしたりする必要はありません。PWAをサポートしているWebブラウザーであれば、同じアプリケーションをその全部にインストールして使うことができます。

また、”インストールしなくても使える”点もメリットです。もともとがWebページなので、ちょっとだけ使ってみるということが可能です。

サービスを試用してみようと思ったときに、”アプリのインストールが障壁になって利用を中断してしまった”、という経験は誰にでもあることでしょう。また、スマートフォンでコンテンツを閲覧中に、突然、アプリのストア画面が表示され、アプリのインストールを促されて不快な思いをしたこともあるかと思いますが、そういったことを避けられます。

PWAであれば提供者もユーザーもアプリのインストールについてのネガティブな点を回避することができます。

再エンゲージ可能

従来のWebページであれば、ユーザーがコンテンツから離脱したあとは、再び訪問してくれることを祈るくらいしかできませんでしたが PWAはサーバー側から通知をPushすることができます。

これによりユーザーに即時的な価値を提供できます。例えば、ECショップであればタイムセールの開始であるとか、オークションサイトであればオークションの開始や、最高落札額の更新などです。

通知機能を適切に利用することで、ユーザー側の機会獲得を増やし、再エンゲージを促すことができます。

逆にどうでもいいことを通知しすぎるとユーザーの心象を害するので注意が必要です。特に、初めてページを訪問したユーザーに「プッシュ通知を許可しますか?」というメッセージを表示するのは避けたいところです。

ネットワーク非依存

PWAはオフラインでの使用が可能ですので、ネットワークの状態に左右されないように作ることが可能です。また、常に使用されるアセットをローカルにキャッシュすることで表示のスピードアップや、回線の使用料を減らすことにも貢献します。

プログレッシブとレスポンシブ

PWAはきちんとその思想を理解して開発すれば、低機能なブラウザーやPWAをサポートしないデバイスにもサービスを提供できます。また、さまざまな画面サイズに対応するためのレスポンシブな機能については、WebにはMedia Queries等、そのためのナレッジもリソースも豊富に存在するため、既存のスキルを活かして機能を実装できます。

安全

PWAはWebコンテンツと同じWebブラウザーの強力なサンドボックス内で動作するため、ネイティブアプリのようにユーザーの強い権限で動作しないため、誤動作や悪意のあるコードによってシステムに深刻なダメージを与えることはありません。またhttpsによる接続でのみ動作するのでサーバーとのやりとりを安全に行うことができます。

リンク可能

PWAはインターネット上でユニークな URL をもっており、ハイパーリンクのあるさまざまなところからサービスに接続することができます。PWAを使用するのにアプリ ストアは必要なく、面倒なインストールプロセスも必要ありません。

PWAのメリットは、Webとネイティブ アプリのメリットを合わせたということだけでなく、それらを状況に合わせて取捨選択できることです。

Progressive Web Appsを実現するAPI

ここからはPWAを実現するためのAPIと、それらをどのように使ってアプリケーションを構築していくかについて紹介します。

Service Worker

PWAを実現する上で中心となる機能を提供するのが、Service Workerです。

Service Workerとは何か？ 端的に言うと、「バックグラウンドで動作する“プログラミング可能な”ネットワークプロキシ」です。

Service WorkerはWeb Workerの一つで、Webページのスクリプトとは独立して動作しており、DOMにアクセスしたりすることはできませんが、Webページのネットワークリクエストすべてをインターセプトできます。

つまり、Webページからのリクエストを横取りしてキャッシュしたものを返したり、改ざんしたりといったことができます。そのため localhost、127.0.0.1接続以外はhttpsの使用が必須となります。

Service Workerが提供する機能

Service Workerが提供する機能は主に以下の4つです。

• キャッシュ
• リクエストのハンドリング
• Push通知
• バックグラウンド同期

これらの機能を図で紹介します。

キャッシュとリクエストのハンドリング

Service WorkerはWebページからのリクエストの中に、自分のキャッシュリストに含まれるアセットを見つけると、レスポンスからこれを取得してキャッシュします。

それ以降、Webページからリクエストされたアセットがキャッシュ内に存在する場合は、そのキャッシュされたアセットを返します。ネットワークから取得しないので、アセットの取得は高速に完了し、通信コストは発生しません。

Push通知

関連付けられたWebページがアクティブでなくても、サーバーからのPushを受け取り、Notification API等を使用してユーザーに通知を行えます。

バックグラウンド同期

オフライン中にユーザーが行った操作をキャッシュし、

オンライン時にその内容を同期することができます。

このように Service Worker はプログラミング可能なネットワークプロキシとして、これまでにないさまざまな機能を提供します。

これらの機能の2018年6月時点のサポート状況は以下のとおりです。

ここからは、Service Workerの具体的使い方について解説していきます。

Service Workerを使う準備

Service Workerを使った開発を行う際に用意しなければならないものがあります。

まず、Service Workerを利用するためのWebアプリケーション、もしくはWebコンテンツが必要です。これはけしてSPA(Single Page Application)のようなアプリケーション然としたものである必要はなく、既存の一般的な Web ページであってもかまいません。

このWebページ、もしくはWebアプリケーションは、htmlやcss、jsや画像に代表されるメディアといった複数のファイルで構成されていると思いますが、それとはべつにService Worker用のJavaScriptファイルをひとつ用意します。ここでは便宜上sw.jsと名付けます。

このService Worker用のJavaScriptファイルはWebコンテンツ側のJavaScriptコードから登録され稼働を開始します。

Service Workerは、自身のファイルが配置された以下のディレクトリに対しスコープを持つので、コンテンツ/アプリケーション全体をキャッシュするなど管理下におきたい場合はWebサイトのルートに配置します。

Service Workerの登録

Service Workerの登録はWebコンテンツのJavaScript から行います。

登録に必要なコードは非常にシンプルで、最低限、以下のコードで問題を発生させることなく、Service Workerの登録が行えます。

Webコンテンツ側のコードから、navigator.serviceWorker.registerメソッドにより、Service Workerの登録が行われると、Service Worker用のJavaScriptコード（ここではsw.js）ではinstallイベントが発生します。

install イベントハンドラ内では、キャッシュを開き

キャッシュにアセットのリストを登録します。

Service Workerが登録され、installイベント内の処理が無事に完了すると、次にactivateイベントが発生します。（もしinstallイベント内の処理が失敗した際にはerrorイベントが発生します）

installイベント内で”しなければいけない処理”というものは特にないのですが、一般的に古いキャッシュを削除するのに使用されます。このサンプルコードではキャッシュからキーの一覧を取り出し、

キャッシュの名前（新しく指定された）と比較し、異なるものをすべて削除しています。

上記サンプルコードの、”キーの一覧と新しく登録されたキャッシュの名前を比較して異なるものをすべて削除してしまう”、というやり方は少々乱暴かもしれませんので、実際に実装を行う際にはどのようにキャッシュの削除を行うかは十分に考慮してください。

なぜ、activateイベントでキャッシュを削除するのか？

Service Worker自体は、Service Worker用のJSファイルを更新することで再登録されますが、キャッシュが削除されるわけではありません。よって、いずれどこかのタイミングで用済みとなった古いキャッシュを削除する必要が出てきます。

例えば、キャッシュの対象となっているindex.htmlに更新があった場合は、更新前のindex.htmlを保持しているキャッシュを削除しないかぎりユーザーにはいつまでも更新前のindex.htmlが表示されることになります。

Service Worker用のJSファイルが更新されたあと、新しいService Workerはバックグラウンドでインストールされますが、まだ動作はしません。新しいService Workerに制御が移るタイミングは、古いService Workerが制御しているすべてのページが閉じた後からになります。そのためinstallイベントで古いキャッシュを削除してしまうと、まだ動作している古いService Workerはキャッシュを使用できなくなってしまいます。

一方、activateイベントではページの制御が新しいService Workerに移っているので、古いService Workerが使用していたキャッシュを削除することができます。

何をキャッシュさせるか？

Service Workerにキャッシュさせるべきは、App Shellです。App ShellはアプリケーションのUIが機能するために必要な最小限のリソースです。App Shellをローカルにキャッシュすることで、アプリケーションのUI表示と使用可能となるまでの時間を短縮することができ、オフラインでの使用も可能になります。また要件に応じて、キャッシュが有効となるアセット類を指定してもよいでしょう。

しかし、何でもキャッシュさせればよいというものでもありません。例えば、WebGLベースのゲームは、一般的に使用するアセット類のサイズが大きく、これを毎度起動する際にサーバーからダウンロードするのは時間もかかり、通信コストもかさみます。たしかに、これらをキャッシュさせておけば、通信コストを下げ、ゲーム開始までの時間も短縮できます。

しかし、キャッシュストレージの容量には制限があり、また、cacheオブジェクトの代わりに容量の大きいIndexedDBを使用したとしてもクライアントのストレージを占有することになります。

PCなどのストレージ容量の大きいデバイスではあまり問題にならないかもしれませんが、スマートフォンのようなモバイルデバイスではストレージ容量を圧迫することにつながります。よって、なにをキャッシュさせるかは十分に考慮する必要があります。

リクエストのハンドリング

Service Workerは有効化(activate)された後、アイドル状態となり、WebページからのリクエストやサーバーからのPushを待ちます。

アイドル状態のとき、制御下にあるWebページでリンクをクリックするなどしてネットワークリクエストが発生するとService Worker ではfetchイベントが発生します。

fetchイベントハンドラの引数として渡されるオブジェクトに、発生したリクエストが含まれるので、同リクエストがキャッシュ内に存在するのか調べ、

キャッシュ内にリクエストが存在すればそれを返し、存在しなければfetchメソッドを使用してネットワークにリクエストを投げます。

それぞれの処理結果をリクエスト元のWebコンテンツ側に返します。

この動作により、Webコンテンツ側ではService Workerやキャッシュを意識することなく、これまで通りの方法でページの制作を行うことができます。

また既存のWebコンテンツにService Workerの機能を追加する場合も、Service Workerを登録するためコードを追加する以外の作業は基本的に必要ありません。

de:code 2018のセッション動画でService Workerを追加するデモを行っていますので、ぜひ実際の動作をご覧ください。

Web App Manifest

Web App Manifestは、デバイスのブラウザーによって[ホーム画面に追加]される際のアイコンや、ホーム画面から起動した際のスプラッシュアイコンや背景色、アプリケーションが動作するウィンドウのスタイルを定義します。

manifestは、json形式で記述し、以下のようなlinkタグをWebコンテンツ/アプリケーション側に追加して参照させます。

Web App Manifestについては、詳しい解説がMDNにあるので、そちらを参照することをお勧めしますが、以下に簡単な説明を兼ねたサンプルを掲示します。

de:code 2018のセッション動画でWeb App Manifest を追加するデモを行っているので、ぜひ実際の動作をご覧ください。

現在のWindows 10バージョン 1803のProgressive Web Appsの動作

なお、2018年6月現在のWindows 10バージョン1803(OS ビルド 17134.112)では、残念ながらWeb App Manifestによるウィンドウの制御は有効になりません。

例えば、Windows 10のMicrosoft EdgeでProgressive Web Appsのページをタスクバーにピン留めして起動したとしてもWebブラウザーのUIを表示したまま起動してきます。

Windows 10でProgressive Web Appsにそれらしい動作をさせるにはUWP(Universal Windows Platform)アプリでラップする必要があります。

しかし、Windows 10の次のアップデートでは、Web App Manifestのdisplayの設定に対し、PWAのウィンドウは以下のような表示になるそうです。

マイクロソフトのProgressive Web Appsへの
取り組み

Windows 10の[Microsoft Store]から Progressive Web Appsとして作られたアプリを入手することができます。

Web App Manifestのところで書いたとおり、現在のWindows 10にプレーンな Progressive Web Appsをインストールしても、ネイティブアプリのような外観にはなりません。そのためMicrosoft Storeから入手できるProgressive Web AppsはUWPアプリにラップされています。

MicrosoftストアでのProgressive Web Appsの公開

MicrosoftストアでProgressive Web Appsを公開するには 2つの方法があります。

1つめがBingによる自動インデックスによる登録と、2つめがProgressive Web Appsの提供者がMicrosoftストアにProgressive Web Appsを提出するセルフパブリッシングです。

以下でこの 2つの方法について紹介します。

Bingによる自動インデックス(BETA)

現在はまだBETAの状態ですが、BingがWeb上のProgressive Web Appsを検出し、レビューを行い、自動的にMicrosoftストアに公開します。

Bingに自動インデックスされるための条件は、現在のところ以下のようなものがあります。

• HTTPS、セキュアなエンドポイント
• 高品質の manifest
• オフラインサポート
• ストアの審査をパス
  • デジタルグッズを販売しないこと
  • アダルトコンテンツを含まないこと
  • 不快なコンテンツは不可
• Windowsならではの差別化がされている

上記リストで、最後の”Windowsならではの差別化がされている”というのは、少しわかりづらいかもしれません。

Microsoft Storeで公開されるProgressive Web Appsは、UWPアプリにラップされるのでWinRT (Windows Runtime) APIを使用することができます。

つまりWinRT APIを使用することで、Windows 10で使用した際には、純粋なProgressive Web Appsからはアクセスできないプラットプラットフォームやハードウェアリソースの機能を使用することができるため、これらを利用した機能を実装することで差別化を図ることができます。

Microsoftストア向けProgressive Web Appsの検証

決して、Progressive Web Appsの検証に限ったものでなく、ましてやMicrosoftストア向けのWebコンテンツ用に限定するものではありませんが、WebサイトやProgressive Web Appsの品質をチェックするためのsonarwhalというサービスが公開されています。

sonarwhalはProgressive Web AppsがMicrosoftストア向けの準備がてきているか、だけでなく、一般的なWebサイトやアプリケーションのパフォーマンスやユーザーエクスペリエンス、セキュリティの向上の役に立つ情報を提供してくれます。

Bingに検出されないようにするには

インターネットで公開しているProgressive Web AppsをMicrosoftストアから配布されたくない場合、Progressive Web Appsが以下のいずれかの条件に合致していた場合、Bingは自動インデックスを行いません。

• manifest なし
• https なし、もしくは オフラインで動作しない
• Robot.txtファイルが設定されている
• manifestのdisplay設定がbrowser

既に Microsoftストアで公開されているものを取り消したい場合は、アプリを削除するよう reportapp@microsoft.com宛にサービスリクエストを出します。

セルフパブリッシングによるMicrosoftストアでの公開

Bingの自動インデックスに期待するのではなく、明示的にMicrosoftストアでProgressive Web Appsを公開するにはdev.microsoft.comで開発者アカウントを取得し、パッケージ(appx)化してMicrosoftストアに提出します。アプリの内容がMicrosoftストアの審査をパスすればMicrosoftストアで公開されます。

Progressive Web Appsをパッケージ化するには以下の方法があります。

• Visual Studio 2018 を使用する
• PWABuilder を使用する
• pwa-builder CLI を使用する

PWABuilder

PWABuilderはインターネットにホストされているサービスで、同じくインターネットにホストされているWebアプリケーションのためのmanifestファイルやService Workerのコード、Service Workerを登録するためのコードを生成します。

また、UWPのHostedアプリのパッケージも生成できるので、Progressive Web AppsをMicrosoftストアで公開する際にはこれをストアに提出します。

PWABuilderを使用した既存のWebアプリケーション用のmanifestファイルやService Workerのコードを生成する手順については de:code 2018 の セッション動画のデモをご覧ください。

Windows ストア(UWP) アプリの価値

前述しましたが、Progressive Web AppsをUWPアプリ(Hosted Web アプリ)としてラップすることで WinRT が提供するすべての機能を利用することができます。

これは予定表やアドレス帳といったプラットフォームが提供するソフトウェア的なリソースはもちろん、USBやセンサー類といったハードウェアリソースも含まれます。

アプリケーションが通常のWebブラウザー上で動作しているのか、UWPで動作しているかは JavaScriptのif文で簡単に判断できるので、WinRT APIにアクセスするためのコードをインターネットでホストされているコンテンツに含めておくことができます。

JavaScriptで記述したUWPから,WinRT APIを使用するサンプルコードは以下に豊富に用意されているので、Windows 10限定となってしまいますが、純粋なProgressive Web Appsの機能だけでは実現できない要件がある場合は、こういった方法もあるということを覚えておくとよいかもしれません。

・コードサンプル – Windows アプリの開発

Visual Studio 2018を使用してProgressive Web AppsをUWPでラップし、WindowsRT APIを使用する方法については、de:code 2018 のセッション動画のデモをご覧ください。

その他、Progressive Web AppsをUWPとしてMicrosoftストアに公開することで、Microsoftストアの提供するマーケティングデータ (ダウンロード数、ユーザーの性別、年齢層、国、etc.)や、決済のためのストアのAPIが利用できたり、人気があればMicrosoftストアのトップページに掲示されたり、とさまざまなメリットもあります。

しかも、Hostedアプリであれば、共通のコンテンツでありながら純粋なままのProgressive Web Appsがインターネットでホストされているので、アプリストアを通さない場合のメリットも享受できます。

【参考】
・Windows デベロッパーセンター – PWAとWindows10

この記事では、UWPのHostedアプリについて紹介しましたが、Apache Cordovaでもさまざまなモバイル プラットプラットフォーム向けに Hostedアプリを開発することができます。興味のある方は以下の記事をご覧ください。

・Create a hosted web app using Apache Cordova

Progressive Web Appsの価値を高める API

ここまでWindows 10で動作するUWPアプリでラップされたProgressive Web Appsの紹介をしていましたが、ここからは再びプレーンな Progressive Web Appsについてです。

Progressive Web Appsは、ネイティブアプリのような体験を提供しますが、WebアプリケーションなのでWebブラウザーの機能を超えて動作することはできません。

例えば、表示速度や動作速度はネイティブアプリと比較するとどうしても劣ります。

しかし、Webブラウザーで新しくサポートされた以下のような機能を使用すれば、その能力的な差を縮めることができます。これまでの Webコンテンツにはなかった新しい体験をユーザーに提供したり、決済の仕組みもWeb標準のAPIを使用してこれまでよりも少ない工数で組み込むことができるので、これらを使用してアプリケーションの価値を高めることができます。

• CSS3 3D Transform関連等GPUを使用する設定があり、これを意識的に利用することで描画速度を向上させることができます。
• WebAssembly C言語などで記述し、あらかじめコンパイルしたものをWebブラウザーで動作させるため高速な計算が可能となります。
• WebVR VRデバイスの提供するAPIをサポートし、ユーザーによりImmersiveな体験を提供できます。
• Web Payments 決済画面その他、支払いに関する機能を提供します。これとPaypalやStripeなどが提供する決済用のAPIを繋げれば少ない工数で独自に決済期の機能を実装できます。自前の決済の仕組みがあれば、もう何かを販売するたびにアプリ ストアに使用料を支払う必要はありません

この他にも、最新のWebブラウザーにはこれまでできなかった機能が日々搭載されてきます。そういった新機能をいち早く利用できるのも、逆にレガシーなWebブラウザーには引き算した機能を提供できるのもProgressive Web Appsの良いところです。(もちろん、そう作れば、ですが)

Progressive Web Appsの位置づけ

PWAことProgressive Web Appsは「ネイティブアプリのような体験を提供する」という言葉が独り歩きしてしまい、まるで「ネイティブアプリを置き換える」といった印象を持っている人も多いようです。とはいえ、「ネイティブアプリを置き換えることはできない」というのも真ではないでしょう。

例えば、スマートフォンアプリには、アプリとしてインストールさせるためだけに外側をWeb Viewでラップしたいわゆる「ガワアプリ」と呼ばれるものがあります。こういったものは今後はProgressive Web Appsに置き換えられていくでしょう。

実際にイベントサイトや、カンファレンスのセッションスケジュールの部分をPWA化してユーザーが持ち歩けるようにしているサイトはすでにいくつか存在します。

• ABC 2018 Spring | 日本最大級のAndroidデベロッパーの祭典
• ng-japan – The Angular conference in Tokyo, Japan (2018/6/16)

こういったものもProgressive Web Appsが出てくる以前はWebページとは別にスマートフォン用のアプリを、場合によってはプラットフォームごとに別々の言語で開発し、それぞれのアプリストアに提出して審査を受けるといったことをしていました。

Webページとアプリの開発が共通化でき、配布の手間もかからないということは予算や時間的にも非常に大きなメリットがあります。

しかし、Webブラウザー内のJavaScriptからアクセスできないプラットフォームの機能を利用するアプリケーションや、高速な動作や描画を必要とする用途には今後もネイティブ アプリが選択されることでしょう。

Progressive Web AppsはWebアプリケーションとネイティブアプリの体験的なメリットを受け継ぎ、ちょうどその中間に位置し、その隙間を埋めるものです。

Webのページではpoorだったもの、逆にネイティブアプリではtoo muchだったものが、Progressive Web Appsには最適なのかもしれません。

少し作って試すだけの実装ならそれほど難しくありませんので、気になる人はぜひProgressive Web Appsを作ってみることをお勧めします。

Webに足りなかったもの

私はWebが大好きです。リンクを1つクリックしたら（インストールなど煩わしい手続きなしで）すぐに新しいコンテンツを読めるのは最高の体験だなと常日頃感じています。ただし、今までのWebアプリのユーザー体験は決して最適なものではないとも思っています。たとえば以下のような体験をした覚えはありませんか？

• 朝の満員電車でも情報収集に勤しむ現代のビジネスパーソンのあなた。つり革に捕まりながらなんらかの記事コンテンツを見ようとリンクをタップする
• 途端にHTMLのレスポンス待ちで真っ白な画面。レスポンスが返ってきたと思ったら今度はWebアプリ側のローディングGIFが動き出す。
• しばらく待つとテキストが表示され読み始めるものの、時間差で画像が差し込まれレイアウトがずれる（どこを読んでいたんだっけ？）。極めつけは全画面広告が画面を占拠し、嫌になってそっとブラウザを閉じる（代わりにソーシャルアプリやゲームアプリを起動する）。

このように世に出回っている多くのWebアプリはパフォーマンスに課題があります。特に、さまざまなスペックなデバイスがあらゆる環境で利用されるモバイルにおいては、Webアプリは単純に耐えられないくらい遅く、実測で3G回線と同等な環境における平均ページロード時間は19秒もかかっているという統計もあります[1]。 Webアプリはとにかくこのパフォーマンスをどうにかしなければなりません。

一方ですでにネイティブ アプリに慣れ親しんでいるユーザーの期待値を満たすためには、パフォーマンスを改善するだけでは十分ではありません。

• ホーム画面にアイコンを追加したり
• プッシュ通知がタイミングよく送られてきたり
• オフラインでも動作する信頼性だったり

「ユーザー体験の基準」がどんどん上がっていくなか、Webアプリだけがこのような体験を提供できずに取り残されている状況がずっと続いていました。時代に合わせて、ユーザーが求める機能性もWebアプリで実現できなければならないのです。

PWAはベストプラクティス集である

そこで満を持して登場したのがPWAです。PWAと聞くと何かを特定の技術を指すものと思われるかもしれませんが、実はそのコンセプトは幅広く、どちらかというと前述した Webアプリ本来の課題を解決し、よりよいユーザー体験を実現するためのベストプラクティス集のようなものです。Googleが提供しているProgressive Web App Checklist なるものがあり詳細な内容はそちらを確認いただければと思いますが、PWAのコンセプトをざっくり申し上げると以下となります。

• とにかくパフォーマンスいいWebアプリを作りましょう。SPAでもSPAじゃなくても、どんなフレームワーク使っても使わなくても、なんでもいいので、表示が速くて画面遷移がスムーズなものにしてユーザーに好かれましょう。
• また、最新のWeb APIを積極的に使って、機能性も身につけましょう。たとえば、Webアプリをホーム画面に追加できるようにしたり、オフラインでも動作するようにしたり。そんな今までWebアプリでは実現できなかった機能が実装できるようになったんだから、やらない手はないでしょう？

少し上記でも触れていますが、PWAはあくまでベストプラクティス集なので特定のサードパーティーフレームワークやライブラリには依存しません。世の中には ReactやAngularを使ったPWAもありますし、Vanilla JavaScriptなPWAもあります。また、サーバーサイドの構成には一切言及しません。したがって技術スタックを変えずとも適用可能なベストプラクティスでありますし、一度に全部を適用するのではなく段階的に（= Progressively）最適化することもできます。

以下の項目でPWAの特徴をより具体的に見ていきます。

ハイパフォーマンス

何より重要であり最も難しいテーマとなります。パフォーマンスの基準としては、2015年にChromeチームが発表したユーザー中心に考えるパフォーマンスモデルであるRAIL[2]を前提に考えていただければ間違いありませんが、各Webアプリの特性や環境に応じてそれぞれのサービスごとに Performance Budget（ロード時間やファイルサイズ等の上限を決め、それを「予算」として管理する）を設けることをオススメします。たとえば、2017年のChrome Dev SummitでChromeチームが推奨したPerfromance Budgetは、TTI（Time to interactive)を5秒以内、それを実現するためにクリティカルパスのファイルサイズを170KB以内に収めるというものです。[3][4]

何事もまずは現状分析から。Webアプリのパフォーマンス測定やプロファイリングをするLighthouseやChrome DevTools等のツールを使って現状の評価とボトルネックを確認し、対応すべきポイントを決めて最適化を進めます。その後はCalibreやSpeedCurveといったパフォーマンスモニタリングツールを利用して定点観測するといいでしょう。

ハイパフォーマンスなPWAを作るためのデザインパターンであるPRPLパターンもまた参考にすべき方式です。PRPLパターンはPush 、Render、Pre-cache、Lazy-loadの頭文字を取ったもので、主にApp Shell モデルやSPAを採用したWebアプリのために用意されたパターンですが、それ以外の構成に関してもパフォーマンス向上のヒントとなる点が多くあります。

• Push/Render: 初期描画に必須なリソースをHTTP/2 Server Pushするか link rel=preload を利用することで先行取得します。そしてそのリソースを利用し、特にAbove the fold [5] (スクロールしないで見える範囲)を優先してレンダリングします。
• Pre-cache: 次ページ（またはルート）で使用するであろうリソースを先読みします。これにはService Workerを利用するといいでしょう。
• Lazy-load: 初期描画に必要なもの以外はすべてLazy-loadします。SPAであれば別ルートの取得がこちら該当しますし、スクロールに合わせたフラグメントの取得であればIntersection Observer APIを利用するといいでしょう。

上記のとおり、Webアプリでもパフォーマンスをあげるためのツールやデザインパターンなど、使えるナレッジが多くたまってきました。ぜひともこれらを利用してハイパフォーマンスなWebアプリの開発を実現してください。

ホーム画面に追加

Web App Manifestを実装するとWebアプリをホーム画面に追加できるようになります。以下のようなJSON形式のマニフェストファイルを用意し、

{
   "name": “PWA Demo Application”,    
   "short_name": “PWA demo”,
    "icons": [{
        "src": “/assets/icon.png”, "sizes": “192x192”
     }],
    "start_url": “/index.html”,
    "display": “standalone”,
    "scope": “/”
}

link タグでページにひも付けた上で、Service Workerをインストールすると、

<link rel="manifest" href="/manifest.json">

<script>
if ('serviceWorker' in navigator)    
   navigator.serviceWorker.register('/sw.js')
</script>

このようにホーム画面へ追加を促すプロンプトが上がってきます。ホームに追加した後はフルスクリーンで起動しますし、Androidの場合は1つの アプリとしてみなされディープリンクまで可能です。

1点補足すると、この「ホーム画面に追加」は強力ですが、よりユーザーに気持ちよく追加してもらえるように、意味のあるタイミングでプロンプトを表示するとさらにいいでしょう。これを実現するためにぜひともonbeforeinstallpromptイベントハンドラーを利用してください。

onbeforeinstallpromptイベントハンドラーはプロンプトが表示される直前に呼び出されます。そのタイミングでプロンプト表示が適切でなければ表示をキャンセルし、別の任意のタイミングで表示することができます。たとえば、画面上に独自の「ホームに追加アイコン」を作成し、それの onclickのイベントハンドラ内でプロンプトを表示させることも可能です。

var deferredPrompt;
window.addEventListener('beforeinstallprompt', (e) => {
  console.log('beforeinstallprompt Event fired');
  // デフォルトのタイミングでは表示させない
  e.preventDefault();
  // Eventオブジェクトを保存しておく
  deferredPrompt = e;
  return false;
});
// どっか別のタイミングで...
deferredPrompt.prompt();

また執筆時点での最新のChrome Canary (67.0.3394.0)ではプロンプト表示形式を以下のように変更して、ホームに追加の体験をより良くすべく機能検証をしています。ポイントはページ下部に表示されるバナーがコンテンツの邪魔にならないサイズに調整され、PWAが追加済であればそのディープリンク用のバナーに差し替えます。また、前述のprompt関数を利用してユーザーのインタラクションに応じてプロンプトを表示する際は、モーダル表示に切り替わります。

オフライン対応

ハイパフォーマンスの解説でも少し登場したService Worker と Cache APIを利用することでWebアプリをオフラインで実行することが可能になります。Service Workerとはオリジン単位（またはパスの粒度）でインストール可能なJavaScriptで書かれたクライントサイドプロキシのことで、ページ内で発生するHTTPリクエスト / レスポンスを監視したり、それを書き換えたり、必要に応じてリソースを先読みすることもできます。これとCache APIというHTTPリクエスト/ レスポンスオブジェクトをKey-Value形式で保存できるAPIを組み合わせることで、オフライン時でもあらかじめキャッシュしておいたレスポンスを利用すことができるようになるわけです。

このService WorkerとCache APIの組み合わせは「Service Worker の紹介」に記載の方法で使用することができますが、より汎用的な使い方をまとめたWorkboxというライブラリを利用するのも1つの手です。Workbox を利用すると実装が煩雑になる、特定のファイルのラインタイムキャッシュも以下のようにシンプルに記述することができます。

workbox.routing.registerRoute(
  new RegExp('.*\.js'),
  workbox.strategies.networkFirst()
);

Workboxはその他にも、ファイル単位でリビジョンを付与したPrecaching、Expirationの定義やBackground Syncを利用したオフライン時の Google Analytics の計測などの機能も提供します。

オフラインの戦略はWebアプリの特性に応じて変わってくるものです。例えばニュースサイトであれば、トップページに出ている注目記事をすべて先読みし、オフラインでも読めるようにすることも考えられますし、ECサイトであればまた別の戦略が適している場合もあるでしょう。電波状況が比較的良好な日本においても、速度制限や電車内などオフライン（または不安定なネットワーク）になりえるユースケースは存在しますし、最低限でも Offline Dinasourはユーザーに見せないようにフォールバックページを用意すべきです。

その他のWeb API

以下にPWAを実装する上で注目すべきその他のWeb APIを列挙します。

• プッシュ通知: Push API / Notification API
• 自動ログイン: Credential Management API
• 支払いフォームの強化: Payment Request API

上記のAPIも組み合わせることによって、リエンゲージメント性の向上や商品の購買フローを最適化することができます。

クロスプラットフォームなイニシアチブ

上記にあげたPWAで利用するWeb APIは、すべてのブラウザで利用できることを目標に標準化を進めています。個別の対応状況を確認するにはCan I Useをご参照いただければと思いますが、冒頭に述べましたとおりiOSでもiOS 11.3からSafariでService Workerが動作するようになりましたし、Microsoft はWindowsストアにPWAを載せはじめました[6]。このように、さまざまな形でPWAのクロスプラットフォーム利用の機運が高まっていると言えます。

また、PWAはProgressive Enhancementな実装を推奨している点も改めて触れておきます。たとえばService Workerを利用したオフラインキャッシュの実装は、Service Workerが未実装なブラウザでもWebアプリ本来の動作には影響がないように以下のように条件分岐をいれることを推奨しています。

// ServiceWorkerが利用できる場合にのみ
if ('serviceWorker' in navigator) {
  // ServiceWorkerを登録する
  navigator.serviceWorker.register('/sw.js')
}

特定の環境のみでしか動かないWebアプリを作るのではなく、どの環境でもハイパフォーマンスに動作するようにし、最新のWeb APIが利用できる環境では進んでそれをレバレッジするとよいでしょう。

Webアプリ vs ネイティブ アプリ

PWAはその機能性や実現したいコンセプトから「PWAはネイティブ アプリを潰そうとしているのか？」「Webアプリがネイティブアプリにかなうはずない！」など当該テーマにおいては辛辣なコメントを見かける場面もあります。ここで1つお伝えしたいことは、多くのユーザーはネイティブアプリなのかWebアプリなのかというプラットフォームの選択には関心がないということです。大事なのは「うまい、やすい、はやい」ユーザー体験の良いサービスを提供することです。PWAの出現によりWebアプリでもそれを実現する準備が整いつつあり、事業者やソフトウェア エンジニアとしては理想のサービスを提供できるプラットフォームのオプションが増えるという意味で、このWebの進化を前向きに捉えていただければ幸いです。

実際Webアプリにはまだできないこともあります[7]。ただし、Webアプリには他のプラットフォームよりも優れたリーチがあり、その意味でWeb アプリとネイティブ アプリがむしろ手を取ることは、戦略としても決して矛盾しません。

使用したい機能がWebプラットフォームが提供するもので十分であり、技術スタックをWebのみに集約するメリットも感じるのであれば「PWA のみ」という選択肢も今後は出てくるかと思います。しかし、前述した「まだできないこともある」という前提を加味するとネイティブアプリが活躍する場面は引き続きありますし、PWAは「Webアプリ vs ネイティブアプリ」という二者択一を迫る提案ではない点をご理解ください。

ユーザー体験の新たな基準

このようにPWAはWebアプリの「ユーザー体験の新たな基準」を満たすために作られたベストプラクティスでしかありません。重要なのはそれぞれの機能を単純に実装するのではなく、Webアプリの特性に応じて使い分け、ときにはカスタマイズし、ユーザーによりよいサービスを提供することです。今回ご紹介しました各種ツールやデザインパターン、iOSでもService Workerが利用できるようになった点など、舞台は整いつつあります。ぜひとも最高のWeb体験を実現すべくPWAの考え方を取り入れてみてください。

• [1] The need for mobile speed: How mobile latency impacts publisher revenue
• [2] RAILモデルでパフォーマンスを計測する
• [3] Fast By Default: Modern Loading Best Practices (Chrome Dev Summit 2017)
• [4] Can You Afford It?: Real-world Web Performance Budgets
• [5] Above the fold
• [6] First Windows 10 Progressive Web Apps (PWA) published by Microsoft hit the Store
• [7] What Web Can Do Today

HTML5 Experts.jp編集部の馬場です。毎回豪華ゲストをお呼びして、Webの現在と未来について語っていただく公開座談会企画「Webの未来を語ろう」シリーズ第3弾！

今回は検索エンジン最適化（SEO）の第一人者である辻正浩さんをお招きし、2018年のSEOを語る上で欠かせないことやWeb制作で気をつけたいポイント、「AI First」時代のSEOはどうなっていくのかなどを語っていただきました。

今回のゲスト

辻正浩さん（株式会社 so.la 代表取締役SEO）

Search Engine Optimizer。
1974年北海道生まれ。営業、広告制作、Web制作の経験の後、株式会社アイレップでSEOの専門家としての活動を開始。様々な業界・規模のWebサイトのSEOを担当する。 2011年10月に独立の後、株式会社so.laを設立。SEO専門家としてWebサービスやECサイト、企業サイトのSEOに取り組む。特に大規模サイトを得意とし日本有数の大規模サイトのSEOを多数担当している他、各地での講演にてSEOの啓蒙活動を行なっている。

SEOのエキスパート、辻さんの空前絶後な仕事術

白石：日本で検索される約5％は辻さんの顧客のサイトなのだそうですね。現在はお一人で13社のSEO支援をされているとのことですが、どうやってそれだけの仕事をこなされてるのか気になります。1日のスケジュールはどんなかんじで仕事されているんですか？

辻：だいたい規則的ですね。平日は朝8時か9時に起きて、昼くらいまではメールなどをチェックします。午後はお客様とのミーティングに出かけ、夕方帰ってきたらその日のうちの作業やメール対応などをしています。深夜0時くらいから翌日の作業の準備をして、4時か5時くらいに寝ます。

白石：えっ、朝起きる時間はそんなに早くないなと思ったら、夜中の4時とか5時まで起きて仕事してるんですか。遅くまで仕事をしすぎなんじゃ…。

辻：13社のお客様とは、月に1回か2回必ず1～2時間のミーティングを入れているので、平日の午後はほぼ埋まるんですね。そのミーティングのために、各社のSEOの分析や提案の準備で短くても5～6時間はかかります。翌日の準備をしているとどうしても朝5時くらいになっちゃうんですよ。

ツールも使っていますが、マンパワーでなんとかやってしまうので、同業のSEO業界の人に話をしてもまったく参考にならないって言われてます(笑)。

白石：クライアントワークやってる辻さんもすごいんですけど、仕事以外でも辻さんは検索結果を常に広い領域でウォッチしているイメージがあります。

辻：30万キーワードくらいは定期的にウォッチしてます。私が他社に勝っている点があるとすると、全部一人で見ていることですね。日頃の順位や流入の変化からサイト変更による変化を一人で全部見ていれば、傾向が把握できますから。

白石：辻さんを医療系サイト「WELQ」問題（※）で記憶している人も多いと思うのですが、このときの医療業界の動向はたまたま気づいたんですか？

（※「WELQ（ウェルク）」問題：DeNAが運営する医療情報のキュレーションメディア「WELQ」が、クラウドソーシングなどを使って記事を安く大量に作り、その記事が検索結果で上位表示されていた件。医療系の情報にも関わらず信頼度が低い、記事の制作過程で多数の著作権侵害が認められるなど、多くの批判を受けて現在サイトは停止中）

辻：医療・金融・法律関連といった深刻な情報の検索では、特殊なアルゴリズムが動いています。その中でも医療関連は動きが顕著ですので定期的に確認していました。医療を追っていればけば、その後の他業界がどういう動きになるか予想できますので。

例えば医療系なら一般的な薬や病名とか症状などのキーワードを、それぞれ数百づつ定期的に検索しておいて、上位表示されるサイトの傾向を見ていると面白いですね。動きが変わってきたときに、じゃあペットの病気だと同じような動きか？などとずらして比較するといろいろ見えてきて、興味深いです。

白石：すごいな…。そういった動きを調べているときは何かツールも使ってるんですか？

辻：データはツールを使って分析しています。ただちゃんと分析するときは、ツールだけではできないので、力業ですね(笑)。

白石：辻さんの大事にしているポリシーや哲学的な話も聞いてみたいです。WELQのときって「これは許せない！」という社会正義みたいな想いもあったんですか？

辻：あまり社会正義的なことはやりたいくないです(笑)。基本的に楽しい仕事しかしたくないですし、好きなサイトとか面白いサイトの仕事だけを受けています。そういうサイトだけに関わっていれば仕事も大変ではないですから。

ただ、自分の義務として検索に関わる問題提起をしていくべきとも思っています。SEOを行っている会社にとって、検索エンジンが取引先となることが多いので、おおっぴらに文句は言いづらい人が多いんですね。私は利害関係はありませんし、身軽な立場なのでいくつか話していると、いろんな人からの相談やタレコミがどんどん来るようになって、半分義務のようになってしまっているところはあります。

モバイルファーストの流れでSEOはどうなる？

白石：続いては、SEOの過去から現在までの大まかな流れと制作者向けのポイント、SEOの未来を聞いていきたいと思います。まず、モバイルファーストはGoogleのSEOにどういう影響を及ぼしているんでしょうか。

辻：2016年、2017年、2018年の今くらいまででいうと　モバイルファーストの影響は大きいと思います。Googleの仕様として大きな変化は、モバイルファーストインデックス（MFI：Mobile First Indexing）ですね。

（モバイルファーストインデックス：Googleがこれまで検索エンジンがPCサイトの内容をもとにコンテンツの質を評価していたのを、スマートフォンサイトを評価の主軸に評価し、インデックスするという方針転換のこと）

Googleはレスポンシブウェブデザインでやっているサイトについては、PCサイトのページとモバイルページのソースに違いはないので一切影響はないと言っています。レスポンシブ以外のところはどうかというと、同じURLで別のHTMLを出しているダイナミックサービングも、別のURLでPCとモバイルを対応しているサイトも、内容が同じなら影響はないと言っています。

（ダイナミックサービング：URLはPCサイトとスマホサイトで一緒だが、アクセスするデバイスによって見せるページやテンプレートを切り替える方式）

ただ、レスポンシブウェブデザイン以外では、Googleが見るページのデザインや動線が大幅に変わることになるわけですよね。おそらく経験がある方も多いと思いますが、コンテンツを変えずにデザインと導線を全部変える大幅なリニューアルをすると検索順位に大きな影響があるものです。

しかしGoogleはその影響がほぼないようにすると言っているんですよ。今までの経験上そうなるはずはないのですが、そう言い切るからには、Googleはいろいろな今までにない処理をしてくるんだろうなあと思っています。

本当にそうなればいいのですが、やはり大きな変化になるかもしれないとして、ウォッチしていく必要があると考えています。

白石：PCサイトしかないサイトはどうですか？

辻：モバイルファーストインデックスでも大きな変化はないはずです。ただ、昔からモバイル版を用意していないサイト、モバイルフレンドリーではないサイトは、モバイルからの検索では順位が大幅に落ちていますので、どうにかするべきでしょうが。

白石：スマホ用URLがあるサイトやスマホ用コンテンツが違うというサイトはいかがでしょう？

辻：そういうサイトはアノテーションなどを複雑に対応する必要があって難易度が高いですね。Googleはカンファレンスの質問などで「完璧に実装できた場合は問題ない」と回答してします。ただし「そういうサイトはめったにないし、だいたいみんなミスをする」とも言われていたそうですが。私なら早めにコンテンツの整理をお願いしますね。

このPC版とスマホ版という話は、サイトの規模によってはクロールの観点で複雑になることもあります。PC版とスマホ版でソースが違う巨大なサイトでは、PC版しかまともにクロールできていないところが多いです。

毎日数万とかページが増える巨大サイトは毎日数百万何千万とGooglebotがデータを取りに来て、Googleのためにサーバ負荷対応が必要なところも多いのですが、PC版とモバイル版の両方を取得するためには、さらに倍の負荷になってサーバ費用もかなり増えます。

そういう事情への配慮なのか、巨大なサイトではPC版を中心にクロールをかけて、スマホ版ページはパターン認識による推測ですましていることがあります。

巨大なサイトのクロールでは、かなり複雑な処理が行われているんです。モバイルファーストインデックスになるとそのあたりも変わるでしょうから、巨大なサイトではなにか特殊な変化が発生する可能性は十分にあるでしょうね。

白石：今後はモバイルクロールがメインになると？

辻：私がログを見られる巨大サイトの多くでは、PCクローラとモバイルクローラの割合が8：2くらいなんですが、今後は逆転させるそうなんです。巨大サイトではPCページは認識できていてモバイルページは認識できていないようなケースも多いので、データベースの処理も複雑になるんだろうなと。そのタイミングでは何かイレギュラーなことが起こるかもしれません。

Googleは問題ないといいますが、過去にない大規模な仕様変更ですので、どういう影響があるかはやはり分からないですね。

普通の規模のサイトや、レスポンシブウェブデザインのサイトは確かに問題は起きないと思いますが、そうではないところにとってはいろいろイレギュラーがあるかもという想定で注意して監視しておいたほうがいいと思います。

Webコンテンツの「正しさ」への流れ

白石：では、話題を変えて。最近はWebコンテンツの「正しさ」への流れがありますが、どうお考えですか？

辻：WELQ問題が端を発し、Googleは2017年12月6日にウェブマスター向け公式ブログで、日本語検索の結果について「医療や健康に関する検索結果の改善」を発表しました。医療や健康に関する部分はここで非常に大きな変化があったわけですが、この前後にGoogleはいろんなことをやっているんですよね。

明確に違法と言えないけど怪しいサイトや悪質なサイトの順位を露骨に落とした、と思える動きもありました。昨年末に逮捕者も出たようなフィッシングサイトへの対応も進んでいます。大きな社会問題になったことに対して積極的に対応するようになった、と思いますね。フェイクニュースなどインターネットへの信頼性が疑われるようになって、明らかに態度を変えたように思います。

白石：それまでのGoogleは「インターネットの自由」を優先していて、それは面白さでもありましたが…。「正しさ」が大事という方向に舵を切ったと？

辻：はい。情報の正確性を意識するようになったことはいわれています。「Googleは検閲はすべきでない」というポリシーとインターネットの自由を大切していることは確かです。Googleを含めたインターネット全体が自由だけでは問題があるという方向に流れています。いいことかはわかりませんが、どんどん加速化していますね。

白石：でも、人によって「正しさ」が違う情報っていっぱいあるじゃないですか。Googleがその「正しさ」を決めるのは、限られたことにしかできないんじゃないかなって思うんですけど。

辻：難しいですね。最近は癌について検索したら、国の医療機関などしかまともに出なくなりました。ただお医者さんの眉をひそめるような高額だったり、実績に乏しい微妙な治療方法の多くは違法ではないですよね。それらがGoogleの判断によって多くの人に知られづらくなったわけですよね。これはGoogleの検閲ともとれる行為かもしれませんが、それが受け入れられています。難しいことですよね。

個人的には、深刻な病気に悩む人が検索の情報で迷惑をかけられたという話をたくさん聞いてきたので、今の状態が悪いとはまったく思わないんです。インターネットの自由も大事だけど、その自由の中でも規制したほうがいいこともあります。ただ、これがどんどん拡大するようではまずいですよね。

白石：価値中立、道徳的に中立という言葉がありますが、Googleは今まではそこを頑張ってたんでしょうけど、あまりに誤った情報などを出してしまうのはまずいと考えたんでしょうね。ただ、Googleの一存で何が正しくて、何が間違っているのかという思想の部分を決めてしまうのはどうかという問題もありますね。

辻：本当にそう思います。ただこの問題、Googleは本当に慎重に考えていると思います。Googleの考え方は発表される声明だけではなくて、実際の順位の動きなどで大分理解できているつもりですが、今のGoogleでも表現の自由とかインターネットの自由の尊重とかは、過剰なほど慎重だと思います。

ただ、それでも対応を変えていかないと行けないほどインターネットは複雑になったということかなと思います。現状のGoogleには不安はないし、変なことはやらないと信じています。でも今後どう変わるかはわからないので、今後も動向は見ないといけないですね。

全てのサービスとGoogleが競合化する！？

白石：次のテーマ「Googleの競合化」ですが、これはどういう意味でしょうか？

辻：最近、Googleでグルメ関連の検索をすると一番上に地図が出ますよね。ユーザー評価もあるし、ローカルガイドにもなって、とても便利ですよね。あと飛行機の予約ができるGoogleフライトも、ホテルの予約もできるし、ユーザーには便利でいいサービスなんですが、これらによって奪われてしまったサービスも出てきます。

Googleマップではスマホを持ったユーザーの行動がオプトインで記録されていますが、そのあたりの独自データを激しく使い出すと、他のサービスはなかなか太刀打ちできないですよね。

白石：あらゆるサービスにGoogleが競合として参入していくわけですね。

辻：増えていることはたしかです。Googleが持てない価値を考えて作るしかないんですが、情報を集めて出すサービスは勝ち目がなかなかない厳しい状況になると思います。

Web制作におけるSEOのポイントは？

白石：ここからはWeb制作におけるSEOのポイントについて聞いていきたいと思います。マークアップなどで気をつけることとかありますか？

辻：昔は「<strong>をつけろ」とかありましたけど、最近は効かなくなりましたね。私もマークアップを変えろという指摘はほぼしなくなりました。普通にミスのないマークアップでWebサイトを作れば評価されるので、SEOのためにマークアップで何かするということが減ってしまったんですよね。

ただ、サイト設計については口を出さなくてはいけないことが、多くなってきました。Googleは公式に認めていませんが、どんなユーザーがどういうページを見ていていて、どこで離脱しているかなど、ユーザー行動を見ているんですね。

白石：まあ、肯定しにくいですよね。

辻：Googleは否定するけど、一般ユーザーがWebページ内でどういう行動をするかが検索結果に影響するようになってきました。その影響力はどんどん大きくなっています。

白石：昔は内部リンクを充実させるために、人間が踏まなさそうなリンクをフッターに大量に仕込んでたじゃないですか。あれはまだ有効ですか？

辻：2012年くらいから一切やらなくなりました。そういう人が使わないリンクをはずして順位がかわるか実験を何度もしてみたのですが、一切変わらなかったんです。それからはSEOだけの目的でリンクを張ることはあまりしなくなりましたね。

白石：クローラーのためにAタグを書いておくのはもう必要ないんですね。

辻：これからはユーザーが使いやすいページを作ることを優先した上で、どうやって検索に強くするかを考えることが有効になってきます。例えば、グローバルメニューとかカテゴリとか本来はユーザ動線として強いはずなのに、ニーズがない情報が並んでるサイトってあるじゃないですか。ユーザが好む動線に検索ニーズもある情報をまとめるとか、マークアップとかよりもユーザーの検索ニーズを意識したサイト作り、などが重要ですね。

白石：ユーザーにとって自然な導線をちゃんと作り込むようにしなさいということですね。

辻：はい、それがSEOの観点として大事になったということです。

白石：一般ユーザーはあまり気にしてないと思いますが、URLは未だに重要ですか？

辻：少なくとも日本国内ではURLの深さとかは、最近は関係なくなくなってきました。パラメータをつけるとどうこうとかありましたが、今のGoogleだけでいうなら認識するようになってきた。ただし、Google以外の検索エンジンは上手く認識できない場合が多いので、やるしかないんですが。

白石：コンテンツづくりについても聞いてみたいと思います。昔、辻さんがGoogleに好かれるための記事を書いてたじゃないですか。検索エンジンには好かれるキーワードを散りばめて、見出しをちゃんと書いて、先に結論があって、見出しの近くに重要キーワード置いてとか。

辻：それは今でもまだガリガリ効きます。SEOを考えたキーワードは大事ですね。ただし、キーワードを書かなくても、テーマによって検索ニーズがあるものはランキングが上がるという流れもあります。

白石：以前流行ったキーワードたくさん入れたSEO用の記事も効くのでしょうか。

辻：そういう何も考えてないSEO記事は大分効かなくなりましたね。Googleはユーザーを見出したということもあり、読み込んでくれる文章じゃないとユーザーは離脱するので効果はなくなっていくと思います。

白石：AMPのSEO観点は何かありますか？

辻：AMPということだけではなく、考えなくてはいけないことがあります。例えば、最近はパーマリンクの重要性がすごく高まっていると思います。3年前くらいはパーマリンクのURLを評価をするサービスは少なかったと思いますが、最近はスマートニュースやグノシーなど、評価付けする存在が増えてきました。

URL単位で評価をするサービスにとって、AMPのURLでシェアなどをされると本来の記事と価値を統合するのに時間がかかったり、されなかったりすることもあります。他にも様々なデメリットはありますが、表示スピードが上がるといったメリットもあるわけで、メリットデメリットを考えて判断するべきですね。

個人的には、ニュースなどAMPに対応すると表示枠が増えるジャンル以外は、まだ様子見をするべきだと思います。先に言いましたパーマネントリンクの問題も今後の仕様改定で解決されるようですし、AMP関連の仕様はまだまだ進化を続けています。対応の工数も大きいですし、大きな利益が見込めないならもう少し仕様が固まってからでいいのではないでしょうか。

パフォーマンス・スピードはSEOに影響しない！？

白石：パフォーマンススピードが高いサイトは評価するとGoogleが言ってますが、実際はどうでしょう？

辻：実はそれ勘違いなんですね。Googleのウェブマスターブログでは、極めて遅い体験を提供しているサイトだけを落とすと言っています。昔行った以前の実験によると、読み込み速度が25秒以上かかるサイトはだいたい順位が落ちました。

白石：辻さん、そんな実験もやってるんですね(笑)。

辻：はい！どれだけ速くしてもランキングが上がることはなく、遅いサイトが落ちます。ただ、スピードを上げることはユーザーの行動が良くなります。結果的に順位が高くなることはあります。

個人的な経験では、サーバーの速度がある程度早ければ、さらにサーバ環境を向上してもユーザー体験は目に見えて変わらないですよね。それだと順位も変わりません。ただ、速度の実測値は変わらなくてもCSSの配慮などでサクサク動いているような感覚にしたほうがランキングが上がるんですよね。

白石：ということは、本当の速度を見ているのではなく、Googleはユーザー体験の方を見ているということですね。

辻：はい、良いユーザー体験を提供すれば順位が上がります。勘違いしてはいけないのは、速度改善でユーザー行動を良くするのは素晴らしいことなんです。

白石：なるほど。ユーザーのためにやるのはいいことなのに、SEOのためにやるのは違うということですね。

白石：最後はネイティブアプリのようなUXをWebページでも提供することができるProgressive Web Apps（PWA）について。プッシュ通知がWebサイトでできたり、ホームスクリーンにアイコンが出てアプリをダウンロードしてもらえたら、以降はアプリで作ってもらえるとか、クロスプラットフォームで対応できるなど便利な機能がいろいろある上に、SEOにもいいということで盛り上がっています。

辻：Googleはアプリ内のユーザの行動はあまり把握できていませんよね。ユーザーが自社アプリに流れた結果、メインサイトのユーザ行動が減って検索順位が落ちる影響は明らかにあります。そういう観点ではPWAはアプリより良いと考えています。

白石：PWAが有望なのであれば、クロスプラットフォームでWebページからアプリ版も作れる。SEO効果もあるし、ゲーム仕様でなければ普通に作れるし、今後は全部PWAでいいんじゃないでしょうか。

辻：PWAのニーズは高まっていくでしょうね。逆に、アプリ開発しかできない開発者はPWAによって活躍の場が減っていくかもしれません。

「AI First」で変わるSEOの未来

白石：「AI First」という言葉をいままで使っていませんでしたが、未来の話もしたいですね。

辻：Googleが公式でも「AI First」と言うようになってきましたね。プロダクトの全てにAIを入れ出しているので、今後AIでいろんな判断がされるようになっていくのが一番影響されるところです。

白石：これまで、Googleがユーザー行動を見ているという話がたくさんありました。結局のところ、今までのクローラーが単純すぎたということで、普通の人間がページを見たときにいい印象を受けるかを判断をするようになる。人間の判断にどんどん近づいているということでしょうか。

辻：その通りだと思います。その状況でSEOを考えると、GoogleのAIに上質な餌をどう与えていくかを意識することが大事になっていきます。

白石：「餌付け」というのはユーザーに有益な情報を提供しようということですね。Googleに情報をあげるとAIが賢くなる。Googleはその先に何を作っていくのか考えちゃいますね。

辻：そうですね。その先に過剰な怖さを感じている話もよく聞きますが、「Google怖い」は「電気怖い」と同じような話かなとも思っています。Googleを恐れるときは正しく恐れるべきだと言っておきたいです。

白石：ただしく恐れろということですね。辻さんに大きな拍手をもって終わりにしたいと思います。ありがとうございました！

この記事は2017年5月17、18、19日に米国カリフォルニア州マウンテンビューにあるAmphitheatreで行われたGoogleの開発者向けカンファレンスGoogle I/Oの3日目に「The Future of Audio and Video on the Web」というタイトルのセッションの内容です。

はじめに

タイトルをパッと見て、例えばWeb Audioの話も絡むのか！？と思いきや、内容はビデオでしたが、2000年からwebのみならずリビングにあるテレビ（動画）から、YouTube、SNSでの動画も含めて歴史を追った説明、デモをまじえ動画を中心としたwebサイトの現在できる最高のExperience、そして見えかけている未来のwebでの動画の拡がり、とwebで動画という切り口から幅広く説明をした中身の濃いセッションでした。

登壇したのはこのお二方。Product ManagerのJohn Pallettと、Developer Programs EngineerのFrancois Beaufortです。

それでは内容を見ていきましょう。

動画が机、リビングから手の上に乗り外に向けて歩き出す

2000年から10年はほとんど変わらなかった。 2000年は私(John Pallett)がHDのテレビを買った最初の年。この当時はHD動画を録画する機器すらなかったが、直後にHD録画機器も出始めSkypeも同じ頃に登場。2005年にYouTube、2007年にはAmazonのPrimeビデオ、Netflixがストリーミングサービスを開始。しかし、この頃は机、リビングで見るのが主でした。

2010年からは私の娘を軸に見ていきます。 2010年はタブレットが出始めた年。娘はこの頃から場所を選ばず受動的に動画、音楽を聞いたり、一方で能動的に録画、録音するようになっていました。

ちょうどその頃にはFaceTimeが登場し、ビデオチャットが気軽にできるようになり、2011年にはTwitchでゲーム動画の配信、2013年にはSnapchat、2014年にmusical.lyで若者が音楽ビデオを録り、さらにそれを友達同士で配信するようになった。さらに過去数年では、VR、AR、360度動画が出てきたりと、イノベーションがここ数年の動画の進化を加速。

この進化を裏付けるように、現在のインターネットのトラフィックの70%が映像（ビデオ）で、Cisco社は2020年までにこれが80%まで伸びるだろうと予測しています。

モバイルwebでの動画の過去と未来

先程挙げた、Twitch、Snapchat、musical.ly、これらのサイトに行くと実はアプリ（Android, iOS）のインストールを求められます。

しかし、モバイルwebでこれらのアプリを作ればアプリのインストールは不要、そしてすぐにやりたいことができるはずなのに、なぜそうなっていないのでしょう？少し奇妙です。

理由を考えると実はそれにはいくつかの問題、課題がありました。一言でいうと、モバイルwebは動画が得意ではなかったのです。その問題点を見ていきます。

Buffering

動画の提供側はFlashを第一に、第二にHTML5に向けて公開するという時代が続いていて、モバイルwebは眼中の外でした。なぜならモバイルwebで動画にアクセスすると動画のダウンロードに時間がかかり、再生までにかなりの時間がかかっていたからです。

映像のクオリティの低さ

「ダウンロードに時間がかかるのなら、映像のクオリティを落とし、ファイルサイズを小さくしよう！」となりますが、小さくすればするほど映像のクオリティは低下します。

いけてないレイアウト

動画の提供側はモバイルwebは眼中の外だったので、サイト全体のデザイン、レイアウトはデスクトップに最適化されていて、モバイルwebでは動画の一部しか表示されていなかったりした。しかし、この現象は防ぐためのAPIがなかったことが大きい要因で、対策はできなかったかもしれないというのも事実。

オフラインでは利用不可

オフラインでの利用はできなかった。もちろんChromeではOffline時には恐竜ゲームはできて楽しいけど、動画を観たいのに恐竜ゲームを例えば飛行機に乗って数時間するのは現実的ではありません。

では現在のモバイルwebでどうなっているかを紹介します。

デモアプリとしてDeveloper Relations TeamのPaul Lewisが書いたアプリを例に紹介します。アプリの名前は「Biograf」で、アプリとソースコードは以下のURLにあります。

• アプリ bit.ly/pwa-media
• ソースコード bit.ly/pwa-media-code-media

（セッションではここで実際にデモを行います。併せてご覧になると分かりやすいと思います。デモの動画）

（クリックでデモ部分の動画が再生可能です）

特徴は以下です。これはwebアプリですよ！

• Progressive Web App
• Nativeアプリのようにホーム画面からアイコンをタップして起動可能
• 起動アニメーション（Splash）が表示できる
• Chrome（ブラウザ）の枠はなく、全画面でアプリ全体を表示
• スクロールも非常にスムース
• 動画は再生をタップしてから一瞬で開始
• デバイスを横にするとフルスクリーンでも動画の表示が可能
• タイムラインをスクロールすると、サムネイルも表示可能
• フルスクリーン中にタップすると、「再生、停止、コマ送り・戻し」のコントロール画面が表示可能
• 通知エリアにもコントロールを表示することが可能
• 動画のダウンロード機能もあり、ダウンロードした動画はプラウザを閉じても、機内モードでも再生可能（Background Fetch）
• ロック画面からのコントロールも可能
• ロック画面で動画のサムネイルを背景としても表示可能
• 制限付き動画でもライセンスをハンドルして再生可能

これらのExperienceは動画の再生時「ページのロードが遅いとユーザはサイトから離脱してしまう」事実を元に考えると非常に重要な機能でもあります。Akamai社の調査では2秒で表示されないとサイトからの離脱が始まり、また動画の再生に関しては6秒以内に再生されないとユーザは再生開始を待たず離脱してしまうという調査結果を出しています。

では、このアプリを例にExperienceを1つ1つ見ていきましょう。

反応の速い再生(Fast Playback)

これはAdaptive Bitrate Streamingで実現しています。動画を再生するには動画のダウンロードは必須だが、モバイル環境下ではダウンロードするデバイスがトンネルを通ったり、帯域を失ったりする。Adaptive Bitrate Streamingがこれらのネットワークがコンスタントでない部分を解決します。

再生するビデオは複数のBitrateでエンコードして、それらがさらにある時間間隔で断片化して保存する。断片化されたファイルをダウンロードするアプリ側で低域等の状況に合わせてBitrateと断片の組み合わせの最適化を施すことで、反応の速い再生を可能にします。

これを実装したのがOpen SourceのShaka Playerです。

また、再生ボタンをクリック/タップしてからの再生の反応に関しては、Service Workersで動画をPre-Cacheすることで速くしている。これが実装されているのがTHEOPlayerです。Biografにも実装されているが、動画の説明等も一緒に、事前にキャッシュ（Pre-Cache）することで再生までの時間を短縮している。またService Workersを使うとサイト自体のスピードもアップすることが可能です。

VIACOM18のVootという動画サイト（5月25日現在、インドでの提供のみ）ではページロード時間が5倍速くなり、これによってユーザがが77%増加、日々に動画を再生するユーザは15％増加したという結果もあります。

Offline

Offlilneは例えば飛行機に乗っている時など、インターネットアクセスがない場所では非常に重要な機能。BiografではService Workersを使って、ページに表示する動画の説明、また動画に関してはリーズナブルなBitrateで事前にダウンロードしキャッシュとしてブラウザ側に保存することでどこでも再生できるようにしています。このBitrateは開発者側からService Workersのロジックの中で、またはユーザ側が例えばダウンロード開始時に選択することが可能。

Offlineはオーディオにも適応可能です。例えばオーディオブックを考えると、Service Workersを使って事前にブック内のプレイリストのオーディオを事前にキャッシュしておくことで、Offlineでも再生が可能になる。

Biografでは動画をキャッシュするためにBackground FetchというAPIを使っていますが、この機能は現在開発中でExperimental Web Platform features（Chromeのアドレスバーにchrome://flags/#enable-experimental-web-platform-featuresを入力すると変更可能です）をEnableにすることで利用が可能になります。このAPIに関するフィードバックをお待ちしています。

VP9

コーデックに関してです。クオリティを落とさずに2倍のコンテンツを保存できたらよいですよね。VP9は一般的なコーデックに比べると50％程圧縮率が高いので、質を落とさずにファイルサイズを50％減らすことができます。既に20億のデバイスがサポートされている状態なのでとてもよい選択肢。例えばYouTubeではVP9を使うことで他のコーデックで配信したときよりも再生までの時間を15〜80％縮めることができています。

User Experience

Media Session API

ロック画面、通知エリアでサムネイルをバックグラウンドに表示していたのと、コントロールボタンを表示していたのがこのAPI。ウェアラブル側にも表示されます。

実装は簡単でMetadataとしてタイトル、アーティスト、アルバム名、表示する画像を指定をし、コントロール（再生、ストップ等）のボタンが押された時のHandlerをそれぞれ書くことで実装が可能です。

Session Orientation API

デバイスを回転させたときの動作を指定できるAPI。Biografでは横にした場合に全画面表示にしている。縦、横になった場合のHandlerを書くことで実装が可能。

webでの動画の未来

タイトル通りの未来のお話をします。映像周辺の仕様の進化はディスプレイをよりリアルな表現の表示に近づけてくれます。

Wide Color Gamut

まずは色からお話します。現在のテレビ（4Kや8K）で実現されている色がモバイル、デスクトップのwebで表現できるようになります。

現在のディスプレイで表現できている色は目で見えているよりも色の表現は乏しい。その色は存在する色が外側の枠だとすると、最も内側にある三角枠が現在のディスプレイ（SRGB）の守備範囲。これがBT2020になると真ん中の三角枠まで表現できるようになります。

僕の履いている靴、実はこのディスプレイ（登壇者の背面にある）では正しい色で表示されていない。けども4K、8Kではより近い色が出てるはず。
（独り言：もしや登壇者のJohn Pallettさん、このために靴を新調したのかな？）

High Dynamic Range (Brightness)

いままでよりも明るいものは明るく、暗いものは暗く表示できるようになる仕様です。現在の一般的なディスプレイではSDR（Standard Dynamic Range）しか表現できません。これは現実の世界の明るさからするとかなりの差があります。

HDR(High Dynamic Range)をサポートしたディスプレイがこれから市場に出てきます。これはOTF（electric Optical Function、またはガンマFunctionともいう）を変えます。デジタルの数字からディスプレイでどれだけの明るさで表示するかのFunctionのことで、それが変更されるので映像・画像を扱う方はどのディスプレイが何をサポートしているか、またそのディスプレイの特性を知った上で選択する必要が出てくるということです。

Wide Color GamutとHigh Dynamic Rangeのコードは以下です。上部についてです。CSS Media Query Level4で可能になります。現在のChromeではcolor-gamutがサポートされていますが、デバイスでどの色が使えるかをクエリすることが可能で、それによって決定することが可能です。

また下部のコードではVP9がHDRとOTFでどの色で表示できるかをクエリによって決定することができます。

Alliance for Open Media(AOM)

アライアンスです。このアライアンスはYouTube、Google、Amazon、Twitch、Netflix、Microsoft、Mozilla、Hulu、BBCが参加していて、Open SourceでRoyalty-Freeの新しいCodecを作ろうとしています。

HDRだけでなく、Wide Color Gamut、また8K、4K、360どビデオも低いBitrateでも届けることができるようなCodecを考えています。なぜなら世界で皆が同じレベルのネットワークを使えるわけではないから。

このアライアンスではAV1という名前のCodecを開発している。数週間前はまだ開発も終えていないし、使えるフォーマットではなかったが、NetflixがVP9よりも20％高い圧縮率のフォーマットを実現することができたとの報告を受けている。

恐らく疑問に思うのは「AV1がどれだけのデバイスでサポートされているのか？」というところだと思います。ここがwebのユニークで面白いところ。1GHzと3GHzのデバイスでは再生のされ方が違う。ではそこをどうするか、VP9を例にコードを見てみます。Media Capabilities APIを使うことで以下のようにいろいろな値を指定することが可能です。

APIにResolution、Bitrate、再生したいCodecを渡すと、指定した形式をサポートしているか、指定した形式でスムースにつまらずに再生できるか、バッテリパワー的に効率的かを返してくれるので、この情報をどのタイプで再生するかのみならず、どのResolutionで再生するか等、ユーザに最適なExperienceを提供することができるようになる。

録音・録画とシェアとSNS

ここ数年、映像とオーディオに関してここ数年で飛躍的に前進している。私の娘がモバイルで音楽の制作、映像の撮影をしている。顔に飾り物をディスプレイ上でつけたりカスタマイズして、そのまま友達とSNSでシェアしてる。これは5、6年前では考えられなかったことです。SNSでは即座に撮影してシェアすることがキーになります。これはwebにはとても得意ところ。なので、ここでSNSやコミィニケーションについて話をします。

WebRTCはあたらしい技術ではないが、ここ数年で急速にブラウザベンダとアプリケーションプラットフォームとしての両方に適応されてきました。そしてWebRTCを使えばLiveStreamingもすることが可能です。

そしてユーザがシェアする動画・音楽の制作に関して、簡単に探せて、簡単に見ることができ、さらにそれを見た友達が動画・音楽の制作ができ…となれば、とてもよいサイクルが生まれます。

このサイクルの実現はwebでなら難しくはありません。それではこのサイクルがwebで実現できるかどうかを、デモを交えてフランソワから紹介してもらいます。

Mustache（髭）

映像とシェアに関わる部分で現在のwebでできることを盛り込んだデモをご紹介します。アプリは「Mustache」という名前です。

Progressive Web Appになっています。ホーム画面のアイコンから起動すると、起動アニメーション（Splash）が表示されます。このExperienceですと、既にwebアプリだと認識するのが難しいと思います。顔には髭、頭には帽子をかぶっています。動かしても映像はとてもスムーズです。動画の撮影も可能で、それをシェアすることももちろん可能です（上の画像の右側）。

Mustacheが利用しているAPI

映像を扱う(getUserMedia())

カメラを扱い、画面に表示するコードが以下になります。

getUserMeida()でカメラの映像と音声を取得します。Mustacheの場合は映像のみを利用します。その他の条件として利用するカメラ（前面、背面）、Framerate、サイズをしています。そして下部のコードで取得した映像を画面に表示しています。

形状の検知（Shape Detection API）

現在、実験中のAPIであるShape Detection APIを使っています。動いている顔へ髭、そして頭に帽子をと、このAPIが重ねる正しい場所を検知することを可能にしています。つい先週完成したばかりのAPIです。

コードは以下のようになります。とてもシンプルです。FaceDetector()に顔を取得するか、また、顔を最大いくつ検知するかの数を指定するだけです。ブラウザ側のAPIなのでインターネットへの接続は不要です。

このShape Detection APIはBarcode、QR Codeを検知するAPIと同時に9月にはChrome安定版でテスト利用という目的で利用可能になります。また、現在でも「Experimental Web Platform features」をEnableにすることで利用可能です。もし要望、バグがあったら知らせてください。

映像の録画（Media Recording API）

Mustacheでは、以下のようにMedia Recording APIを使っています。MediaRecorder()へCodecをVP9と指定して、映像を受け取ったら処理をするHandler、また録画を停止した時のHandlerを書いている。Chromeに公開されて1年になるのでAPIは安定しています。

シェア機能（Web Share API）

シェアボタンを押したときにAndroidのNativeのシェア選択画面が出てきていましたよね。自然過ぎてわからなかったかもしれませんが…。これはWeb Share APIを使っています。
コードは以下です。share()にタイトル、テキストと映像のURLを指定します。このAPIは今年末には利用できるようになるでしょう。

Mustacheは以下のURLで公開しています。
Chrome for AndroidのCanaryを使い、Experimental Web Platform featuresのEnableにして利用してください。

• Mustache

全てのAPIを1つのノードとしてみるとwebではPlug-inなしでこれらノード同士を無限につなげることができます。例えば、Media Streamを使えばカメラからCanvasに描画、アップロード、またマイクからWeb Audioそして、WebRTCのRTCPeerConnectionへと、たくさんのAPIと接続して利用することが可能です。

まとめ

デモに交えてたくさんのAPIを話しました。多くが現在でも利用可能なAPIです。

Biografでは、Service Workers、Media Session API、Full Screen API、Screen Orientation APIなどを使っています。フランソワがこちらに記事としてまとめてくれていますので詳しくはそちらを参照してください。

映像の再生等に関わるProgressive Web Appを書く場合はBiografのコードを参考にするとよりよいExperienceを提供できるでしょう。
そしてMustacheで使っているMediaStream Recording API、Media Capture API、Media Streams APIは現在でも利用可能です。

最後に、以下の3つは特にFeedbackをお待ちしています。

• Background Fetch
• Shape Detection API
• Web Share API

ありがとうございました！

おわりに

個人的に数年前から年に数回はFacebookをモバイルwebから使う儀式をしています。写真や動画を撮ってシェアしたりするのが特にですが不自由な点がありました。

また、QRコードの読み取りも必ずモバイルのNativeアプリ、またはインターネットへの接続が必須とされていました。それを元に考えると近年のWebブラウザの進化には目を見張るところがあり、また同時にその進化を肌で実感できるエキサイティングなプラットフォームの1つだと思います。

今後も映像のみならず、他の分野でのWebブラウザの発展、拡張も期待できそうですし、その進化から目が離せないですね。

特別企画「Webの未来を語る」のエキスパート、ブラウザベンダー対談の後編です。前編はこちらから。今年1年のWeb業界を占うということで、エキスパート、ブラウザベンダーの方々に「Webの未来」について、がっつりお話を聞いてきました。

どこから、どこまでが Progressive Web Apps？

白石 PWAは、すごい重要なキーワードだと思いますが、どこまでがPWAなんですかね？ 厳密に定義付けする必要があるとも思わないんですが、モバイルのホーム画面にアイコンを追加するとか、プッシュができますというところまではPWAなんだろうと思うんですが、BluetoothだとかUSBだとかはPWAと言えるのかどうか。

えーじ 一応基準として挙げられるものは2つあって、1つはWeb Fundamentalsというサイトにチェックリストをのせています。あまり明確に定義するのはやめようという話は当初ありましたが、ただそれだとちょっと曖昧すぎるということで、いくつかポイントを挙げてチェックリストになっています。チェックリストの中身は、今後増える可能性はあります。

もう1つは、「Lighthouse」というものをChromeの拡張機能とnode moduleで出しています。拡張機能のほうを使うと、見ているページのスコアを出しくれるというものです。今後これがDevToolsにも入る予定で、AuditでWebサイトの分析をユーザーエクスペリエンス視点でやるという感じになります。その評価基準のひとつとして、PWAの対応状況をスコアリングしてくれるようになります。

矢倉 そういえば、Chrome Dev Summitのセッションの中のひとつで、Chromeチームの定義として「Webのエクスペリエンスを根本的に向上させるもの」という風に紹介されていました。ここで言うエクスペリエンスは何かというと、速くて、信頼できて、ユーザーとのエンゲージメントもある。それでいて、モバイル向けサイトとPWAと別に作るんじゃなくて、ひとつのドメインでWebのエクスペリエンスを向上させるのがPWAだよ、と説明していました。使う技術スタックだけではPWAじゃないというとこに踏み込んだなっていう印象がありますね。

えーじ スピード周りもすごく重要で、そういう意味ではHTTP/2だとかHTTPSへの対応もPWAの要素のうちのひとつと数えるといえば数えられます。モジュールローディングなどで、どうやってモジュールをいかに早くロードするか、などもそうですね。そこはノウハウとかもこれからどんどん溜まっていって、そのあたりが今一番面白いところだと思うんですけど、これから1年ぐらいでおそらくいろいろ整備されてくるかなと思います。

白石 WHATWGのローダーみたいな？

矢倉 それよりかはどちらかというと、フレームワークとかのほうになるのかなって思います。Webpack 2のtree-shakingとか。仕様は実装を待たないといけないので、いま手をつけ始めやすいところという意図なのかなと。

白石 少し前に公開したAngularのインタビューで、結論のところでAngularも半年ごとにメジャーバージョンアップしていって、もしかしたら後方互換性のことは気にせずにやっていくかもしれないと。なので、Webの進化にどんどん追随していくという感じで、Webの進化とAngularの進化が両輪で進んで行くみたいな感じになるのかな、っていう形で終わったんですけど、そんな感じで捉えていけばいいんでしょうか？

えーじ それとはあんまり関係ないかな（笑）。一般的なエコシステムというかプラットフォーム（基盤）が動いていく仕組みとして、Webの場合どんどん変えていく、進んでいるっていうことなのかなと思います。Angularもそれに追随するためにそういう動きをとっていると捉えれば、当然開発者側もそういう体制をとっていく必要があるなと僕はすごく感じます。

なので、受託開発で年に1回大きく予算を取って開発するというよりは、ちゃんと継続的に開発していくような体制をとっていったほうがいいんじゃないかなと思いますね。

Progressive Web Appsは、完全にモバイルアプリとしても動くようになる

えーじ ひとつ面白いのは、こないだのChrome Dev Summitで発表したんですが、PWAをホーム画面に追加するだけじゃなくてバイナリにもなります。apkファイル（Androidのアプリケーションパッケージ）ですね。

白石 それって何か利点があるんですか？

矢倉 ランチャーの中に入ります。

えーじ リソースの管理とかもアプリと同様にできるので、ユーザーからしてみると完全にアプリだと思って使うことができます。

矢倉 設定の中のアプリ一覧の中にリストされたりとかしますね。

白石 なるほど。Androidだと、このアプリはSDカードにデータを保存するとかそういう設定ができますよね。そういうこともできるようになるのかな？

えーじ ちょっとそこまでは把握していないですけど、できるんじゃないですかね。

白石 完璧なアプリ扱いですね。それは面白いな。

Firefox、EdgeのProgressive Web Apps対応状況は？

あとMozillaさんにも聞きたいんですけど、Android版のFirefoxとかでPWAはやっているんですか？

浅井 やっていますよ。PWAをサポートしますっていうのは用語の出来た 2015 年から表明していて、アプリをホーム画面に追加するなど一通りできるようになってきていますが、フルスクリーンで起動するオプションへの対応などが抜け落ちていたり、細部でまだChromeさんに追いついていないところがあるのが正直な状況ですね。

何で遅れてるいるかについては、Firefox OSをやめてMozilla内で開発体制を切り替えていた影響もあります。Firefox OSをやめた理由は、純粋にWeb技術で全てを実現可能にしましょうって自分たちでリードして標準も作っていったんですが、誰も同じ標準を実装してくれない（笑）。それが単独実装の独自仕様状態になってしまなら、それはよくないエコシステム、もうひとつのWebベースのネイティブみたいになってしまうと良くないのでやめました。

スマートフォンだけじゃなくてもっと多くのものがインターネットに繋がる時代なので、その時代に対応していくため力点を変えましょうと、スマートフォン向けのFirefox OSに注力していたモバイル周りの開発体制を切り替えている中で、PWA対応も一部遅れてしまいました。

よく見てる人はわかるかも知れませんが、Android版Firefoxは機能面の追加が少し緩やかな時期があります。ちょっと遅れているところはありますが、PWA対応も普通に入ってくると思ってください。Service Worker対応やホーム画面にアイコンを追加するメニューなどが(一部は開発版だけに)入っている通りです。

白石 Firefoxでホーム画面にアイコンを追加して、それを押すとFirefoxで起動するんですか？

浅井 今は、Firefoxの新しいタブとして起動するっていう形です。Chromeだとオプション次第でフルスクリーンで起動できます。もう一つChromeとの違うのはFirefoxの場合は、今はアプリマニフェストがあるとメニューに「ホーム画面に追加」が出てきます。Chromeの場合には、何度も使っていたり、一週間の別の日に2回以上同じサイトを訪問すると勝手にバナーが出てきて、インストールしませんかと聞いてきますが、それをFirefoxでやるかどうかは未定です。

白石 プッシュ通知はどうですか？

浅井 プッシュ通知は随分昔に実装してますね。

矢倉 Edgeは、どうなんでしょう？

物江 現在、実装中です。もしかしたら次のバージョンで入るかも？

浅井 僕らとしては、みんなで同じようにPWAに対応していくというのはある意味コンセンサスを取りながら実装する取り組みのひとつだと思っています。APIレベルのものってプログレッシブに、使う使わないって判断を段階的にできるから、それぞれのペースで実装したらいいと。

それに対してWeb Assemblyは、JavaScript言語仕様が違うと構文エラーで全く動かなくなるのと同様、バイナリ形式は最初から全員で確実に統一することが必須になるため、自分たちがリードしている取り組みでも先行アナウンスなどはせず、何から何まで各社と同時に行う体制にしているんですね。この辺りは特に頑張って一緒にやることを重視している取り組みです。

次世代ブラウザエンジンを作るMozillaのQuantumプロジェクト

浅井 Firefox OSのときにAPIを作りまくっても、リードしても誰もついてこなくて悲しい思いをするってのはある意味反省点としています。特にハードウェア系のAPI、例えば加速度センサーとか近接センサーなどはAndroid版の初期から実装してましたが、そういう単独でのAPI先行実装は一段落しています。

どちらかというと今はパフォーマンスをすごく重要視していて、Web Assemblyもその一つですが、同時にそもそもAPIレベルじゃなくってブラウザエンジン自体のアーキテクチャ自体を大きく変える余地があるだろうと、GPUを使ったり、CPUのマルチコアを活かすといったところに注力して、ブラウザエンジンを次世代のアーキテクチャに置き換えていく動きをしているところです。

矢倉 Quantumですよね。

浅井 そうですね。Quantumプロジェクトと呼んでいますが、Mozillaでは珍しく一時的に社内Confidentialとされていて、話をまとめて決めてから大々的に発表したプロジェクトです。といっても数ヶ月後にはすぐ発表されたので、長い間秘密にしていたわけではないですが。

えーじ これは、Servoと関係あるんですか？

浅井 関係あります。Servoは何年も前からの取り組みなのですが、高速な並列処理を書きやすいのは勿論セグメンテーション違反などはコンパイル時にエラーとして検出でき、確実で高速な並列処理をガンガン実装できる新言語Rustを作るレベルからブラウザエンジン自体のアーキテクチャまで、全てをイマドキに刷新した、新しいブラウザエンジンを実験的に開発してきたプロジェクトです。並列化大好きなインテルとかサムスンなども参加してくれました。

ただ、Servoというのはあくまで実験的なブラウザエンジンであり、本当にすべてのAPIとかすべてのブラウザ機能を実装することを目標にしているわけじゃないんですね。Servoで新しいアーキテクチャを確認して、検証されたアーキテクチャでうまくいくものを実際のユーザ向け製品であるFirefoxのコンポーネント単位で置き換えていくっていうのがQuantumプロジェクトです。Servoの成果をFirefoxに取り入れるっていうのがQuantumという関係です。

このQuantumプロジェクトでは例えば、レイアウトやCSSのスタイリング処理を高速化します。CSSのスタイリングってまずDOMツリーを使ってそれにCSSのルールを適用していくのですが、DOMツリーって要するにツリーだから、このサブツリーとこのサブツリーを並列処理できるっていうのは当たり前のデータ構造じゃないですか。

構造的に並列化が容易だっていうのは分かっているので、並列化しやすい言語とアーキテクチャを採用して作り直しました。よくブラウザが遅い原因にリフローとか挙げられますけど、そのリフロー時に発生するレイアウト処理時間の半分がスタイリングで、そのスタイリング処理が2倍、4倍とかいうオーダーで高速化します。

例えばこちらのビデオなどを見れば違いが分かります。

エフェクトが非常に滑らかになるデモ

たくさんのオブジェクトを高fpsで描画するデモ

こういうのって、やっぱりこれまで十何年もつかっていたブラウザエンジンそのままじゃ難しくって、次の世代のブラウザエンジンを作ろうって取り組みがこのプロジェクトです。Mozillaは、今ここに一番注力しています。

2017年の前半のうちに、今お見せしたスタイルのスタイリングが数倍早くなる実装がFirefoxに入るのを目標にしていたり、WebRenderと呼んでるものなどもなんとか形にしたいなと思っています。他にもネットワークの並列化とか、キャッシュをうまくするとか、そのあたりもQuantamプロジェクトで取り組んでいるところは、まだまだお楽しみにというところです。Mozillaはいま、APIとかよりエンジンの世代交代にエンジニアのリソースをがっつり割いてる感じです。

Mozillaのビジョンは、ブラウザに限らずインターネットのオープン性や、それに触れるための機会をどこまでも広げること

白石 Mozillaさんは、IoTとか、そちらのほうに注力しているというのは存じてますが、そういったあたり、Webブラウザがどこまで広がるのか、広げられるのかとか、そういったビジョンみたいなものをお聞きしたいですね。

浅井 単純にモバイルのスマートフォンだけに注力するってのをやめて、IoT時代のブラウザとかブラウザエンジンみたいなことを考えて開発をしています。だから、個別のデバイスの話よりも、そういうインターネットがどこにでも広がって、Web技術がどこでも使われる時代に適したものを作る。

だから、Quantumのようにマルチコア時代のモダンなCPUをフル活用するプロジェクトに注力するし、日本ではGeckoを組み込み用のハードウェアに移植してブラウザエンジンをより広く使えるようにするプロジェクトGecko Embeddedに取り組んでいます。組み込み機器では普通、スマートフォンとは違うCPU (SoC)を使うんですけど、そちらではChromeもFirefoxもWebKitも、みんなまともにビルドすら通らないし、パフォーマンスも全然でない。

そういう課題をちゃんと解消し、組み込み機器でも使えるブラウザ1個ぐらい作りましょうって取り組みです。全体的に、具体的なプラットフォームや製品よりも、本当にベースラインとしての誰もが使い易いコアの部分を改良をしているという感じです。

白石 じゃあそういったどこまでも広げていこうっていうのがMozillaのビジョンになるわけですね。

浅井 そうですね。もともとインターネットのオープン性とか、それに触れるための機会とかを広げるのが目的で、そのための手段がブラウザなので。じゃあ、そのブラウザっていうのはインターネットが広がるに従って、全部、ブラウザという形をとるのか、ただのJavaScriptエンジンととるのかわからないですが、それを広げるというのが僕らのミッションです。

白石 最後に、Mozillaさんが考えているPWAも、Googleが考えているPWAも変わらなと思っていいんですかね？

浅井 僕らの独自のPWAの定義は作っていません。そういう意味では変わらないと思います。

EdgeはWindowsの一部、当然これからもどんどん改良していく

白石 物江さんにもいろいろお聞きしたいんですが、Microsoftが考えるPWAとかもGoogleやMozillaと変わらないんですかね？

物江 PWA自体の考えは変わらないですね。ただ、こちらにはまだ動いているものが何もなく、それがどういったものになるかということについては、社外で話して良いかどうか許可も取れていないので私の口からはなんとも言えません。だだ、さきほど矢倉さんがおっしゃってた Edge チームの Jacob Rossi の記事によれば、アプリのようにすべてのアクセス権をもっていて、ブラウザなしで実行されるようなものを目指しているようですね。あくまでもこの記事によれば、ですが。

白石 なるほど。PWAをのっけていくプラットフォームというのは、きっとWindowsになると思いますが、そのWindows × PWAっていうのがちょっと面白いところですね。

物江 今、収益の柱はクラウドになっているので、クライアントがなんであるとか、実はあまりに気にしていないんですよね。Azure使ってくれれば。本当にみんなPWAでアプリ作ってAzureを使ってください（笑）。

白石 でもビジネス上の話って結構重要かなと思っていて、Edgeのシェアをどこまで本気で伸ばすつもりがあるのか。ブラウザって直接収益には結びつかないじゃないですか。その上で、Microsoftがどこまで本気で今後もブラウザを改良していくのかっていうところは興味があります。

物江 もちろんどんどんやります。何故かというと、うちのブラウザはWindowsの一部なので、Windowsに付随するところがいろいろあるんですね。例えば、例えば、Windows Defender Application Guardという機能では、Edgeの設定で信頼済みのサイトじゃないところでリンクをクリックするとHyper-Vシステムで完全にOSから仮想化されたプロセスが立ち上がって、そこでブラウザが動くのでマルウェアが動いたとしても外に出れないっていうものがあります。

そういった、Windowsとユーザーの安全、アクセシビリティを守るっていうところに注力していく形で進んでいます。ブラウザはWindowsの一部であり、Windowsユーザーの利便性をあげるために今後も取り組んでいきます。

現場でもすごく頑張っていて、DOMのパフォーマンスを上げることに非常に躍起になっています。こないだのアニバーサリーアップデートでも相当早くなりましたが、次回のアップデートでもさらに早くなります。EdgeからIEも起動できますが、IEはブラウザではなくて、従来のIEでしか動かないものを動かすためのランタイムとして見ていただければ。

日本だと大人しく見えるかもしれないですけど、アメリカのほうではEdgeでWebのセッションとかすごくやってますね。Edgeサミットとかもやっていて、オンラインイベントとかも頑張っています。他にもEdgeのデベロッパー向けのサイトには、そこで求人することはまずないんですが、ブラウザ作りませんかっていう求人募集もやっていて、それぐらい力を入れて人を集めています。MozillaさんからもX-tag（Web Componentsのポリフィル）を作ってた方に来ていただいて、今はそれもMicrosoftがやってます。

白石 じゃあ全然やる気ありますよって感じなんですね。ちなみにCordovaにも注力してるって聞いたんですけどほんとですか？

物江 はい、注力してますね。Visual Studioが絡んでいるのもあるし、やはり周り回ってAzureのお客さんになるじゃないですか。ぶっちゃけた話、Windows Phoneがバカ売れしてたらCordovaはやらなくてもいいんですが、お察しのとおり Windows Phone は数が出ていないんですよね（笑）。Webの技術者の方々がアプリを作ってくれて、Azureを使ってくれれば最高です。

白石 なるほど、じゃあMicrosoftは、XamarinやCordovaっていうクロスプラットフォームのテクノロジーに注力していく形ですね。

そして、Appleは…？

白石 話は変わりますが、ここにいないAppleは、どうなんでしょうか。ここにいるひとは、Webに対してものすごくアグレッシブに、こう変えていこう、良くしていこうとしていると思うんですけど、Appleがどう思っているのかは気になります。何かAppleについて知っていること、感じていることがあれば教えてください。

えーじ 面白いと思ったのは、WebKitからBlinkがフォークしたときにShadow DOMが入っていたんですけど、それをWebKitから消したんですよね。にもかかわらず、去年いきなりWeb Componentsの議論にAppleさんが入ってきて、過去に我々が作っていたWeb Components周りの仕様をv0として、Appleが加わって新しく刷新した仕様をv1という形でSafariにもめでたく、Shadow DOMが入りました。今後もCustom Elementなんかも入ってくることを考えるとすごくポジティブに捉えてもいいんじゃないかなと。

白石 いきなり今年頑張り始めて、ECMAScriptとかも一気に対応したんですよね。

浅井 そうそう、なんかテクノロジープレビューだして、すごいアップデートニュース飛ばしまくってるなと思ったら、突然ECMAScriptの対応100%ですってすべてのブラウザをぶち抜いていったっていう。

ちなみに、現在ECMAScript 2015の対応はSafariが100%で、ECMAScript 2017くらいまでの仕様が安定している部分もSafari Technology Previewがリードしてるんですが、仕様議論中の先行実装ではFirefoxがトップでChromeが次、あとはその他大勢という感じで一気に下がるという感じで進められてきました。JavaScriptに限らず先進部分はだいたいその２者で実装していて、ある程度仕様が固まってくるとMSさんが追いついてくる、そんな流れですよね。Appleさんは、標準化されたものをどこかの段階でやるって決めたらいきなり投入してくる、サプライズが好きな会社。そんなイメージを持っています。

矢倉 かなり少数精鋭っていう印象を受けるし、やっぱり1年に1回しかアップデートされないブラウザエンジンというのももう少ないですし、やっぱり過去数年でWeb開発者のフラストレーションが溜まっていて、Safariが新しいIEだと揶揄されていた。そういう風にWeb開発者からの印象が悪かったんですね、それを改善しようって本気になって、例えばテクノロジープレビューを出したりとかWebKitのブログをリニューアルして積極的に情報公開したりとかというのをやっています。

カンファレンスなんかのパネルディスカッションとかにも、あんまり出ないと思うんですけど、彼らは愚直に彼らの思うWebブラウザっていうものに対してしっかり取り組んでいるなっていう印象があります。とくにJavaScript APIも実装するだけじゃなくて、早くなくちゃ意味がないと言ってますし、かなり尖ったことをやっていると。

ただ、新しい機能、例えばService Workerとかに対しては、あまり反応がないってところで、やっぱりSafariがネックになるっていう感じのところはありますけど、別に彼らはAppleストアがあるからってあぐらをかいて、Webに関して注力していないとかそういうわけではないかなと思います。

白石 ここ数年そう見えなくもなかったけど、実はそうでもないと。

矢倉 MacでSafari使うんですが、やっぱり普通に他のより速いんですよね。だからしばらくデフォルトブラウザにしてみたりとかしているんです。開発者ツールの違いや、新しい機能が載るまでに時間がかかる点で、開発者にとってはあんまり嬉しくない部分があるかもしれないですが、でもユーザーにとって使いやすいもの、早いものって考えると、それが彼らにとって一番の価値だろうと思います。もうちょっと開発者のほうにもアピールができるともっと健康的なのかなと思いますけどね。

おわりに

白石 最後に、皆さんからいろいろお話を聞いて、「Webの今後のビジョンとは何か」という問いに対しては、概ねPWAであるという印象を受けましたが、それで良いでしょうか？

物江 いろいろな動向を見ていると、そうとしか思えないですよね。

えーじ 少なくてもGoogleはそう考えています。というよりPWAっていう言葉が全部飲み込んでいるんですよ。なので、細かいところ見るとたぶん各社注力するところは違うと思うんですが、大きな視点で見ると全部PWAと言えるんじゃないかなと思います。そういう意味では、バズワード的な感じでよろしくないのかもしれないですけど、モバイルのWebを良くしていきましょう、クロスプラットフォームの部分を良くしていきましょうという想いなのかなと。

矢倉 えーじさんが最初にバズワードっていうふうに揶揄されてるって言ってましたけど、けどわかりやすいってところでPWAがある。でもPWAの細かいところをつついていくと、ただWebの良さっていうのをもっと全面に押し出していこうというのを具現化したにすぎないのかなと思っていて、まあ新たなマーケティング要素という側面もありますが、ちゃんとWebをWebとしてプロモートするっていうところに再び舵をきったのかなと思います。

白石 なるほど。皆さん、貴重にご意見をどうもありがとうございました！ これにて対談を終わりにしたいと思います。

HTML5 Experts.jp 副編集長兼エキスパートの吉川です。今年1年のWeb業界を占うということで、エキスパート、ブラウザベンダーの方々に「Webの未来」について、がっつりお話しを聞いてきました。

HTML5 Experts.jp 編集長の白石が、Googleのデベロッパーアドボケイトのえーじさん、 Web標準ウォッチャーとして有名な矢倉さん、MicrosoftのWebエバンジェリスト物江さん、Mozillaの技術戦略マネージャ浅井さんをお迎えして、興味深いお話が盛りだくさんです。今後のWeb業界の動向を追いかける上で、重要な内容となっているので、ぜひ読んでみてください！

今、Web標準ってどうなってるの？ WHATWGとW3Cとか

白石 皆さん、よろしくお願いします。最初に、僕が個人的に思っていることとして、最近Webのビジョンが見えないな、と。これまでのWebの歴史を見ると、例えば1990年代だったらWebが急拡大して、いろいろなサイトが出てきてきてわくわくしました。2000年代前半になると、Servletとか書きまくったり、XHTMLとかXMLも出てきて面白かった。2000年代後半だとWeb2.0のブームがあって、そして2010年代前半には、HTML5のムーブメントがあった。

それに対して、今どこに向かっているかということを考えると、そんなに楽しいビジョンが見えるかというと、あまりそうは感じていなくて。例えば、モバイルアプリが使う時間がのびて、Webブラウザ使う時間が短くなったかなとか。各社のWebに関する戦略の変更もあるかなと思うんですが、Chrome Appsがサポート終了だとか、IEの開発が終了してEdgeに移行したりとか、Firefox OSも今年終了ということもあって、これまでイケイケでWebを拡大していこうっていうところから曲がり角に来てるのかなと僕は感じています。

今後のWebがどういう流れになっていくのか、というところも見え難くなっていると。今日はWebの未来について何かビジョンを描くとか、少しでもそういうことができると嬉しいなと思います。

さっそくですが最初にWeb標準について、ちょっとお聞きしたいと思います。現在、WHATWGとW3CといったWeb標準はどうなっているのか、そこらへんの現状とかを教えてほしいと思います。では、矢倉さんお願いできますか？

矢倉 正直、最近あんまり追いかけていないところもありますが、聞きたいのはWHATWG、W3Cだとか、HTMLの仕様がどうなっているのかというところだと思います。どこから話しましょうか。

白石 そうですね、仕様が分かれているというのはみんな知っていて、ただ詳しく仕様を追いかけていない僕ぐらいのレベルからすると、W3Cというのはスナップショットを取る団体に見えていると。W3CとWHATWGの仕様がちょっとぐらいズレがある、ぐらいは把握しているんですけど、まずそういう世の中の認識は正しいのか、みたいなところとか。現実の標準化の現場ではどうなのかというところが聞きたいですね。

矢倉 わかりました。まずW3CのHTML仕様というのは、10年前にスタートしましたが、その時点で既にあった2007年当時のWHATWGのWeb Applications 1.0という仕様をベースに進めたというのがW3Cの仕様です。WHATWGの仕様は、基本的にエディター（当時はIan Hickson）がフィードバックをMLから集めて、それを頭の中で考えてこねこねして書いたものが仕様に反映される。それをみんながレビューするという形です。それに対して、W3Cの策定プロセスは、とりあえず何か議題があったら、それについてみんなで話し合ってコンセンサスをまとめて、それから仕様に反映させるということをやってたので、やり方に相違があったと思います。

WHATWGのほうは、ソフトウェア開発的なモデルとして仕様も同じように作っていくべきという意識でずっとやっていて、だからバージョンというのもとくに切っていません。マーケティング的な要素で「HTML5」と一瞬名前を変えたときもありますが、べつにバージョンを切ったというわけではありません。コミットされるたびに更新されるので、W3Cの仕様にある日付がついた仕様のドラフトも（一瞬つけたものが出たりしたんですが）、特にやらずに進めています。最新版が常にベストみたいな感じですかね。

一方で、W3Cにはまず勧告プロセスがあり、勧告しなきゃいけない以上、どこかでフィーチャーフリーズしないといけない。なので結局スナップショットになってしまう。勧告が必要なのかというと、勧告されないと特許ポリシーが発効されないので、IPR（知的財産権）的に危うい状況になるんですね。そういうのがあって、仕様を固めないといけない。

W3Cのほうがだんだんと乖離してきた原因のひとつが、Web Applications 1.0でHTML 4.01から変わった箇所、特にマークアップやアクセシビリティの変更に対して、HTML WG内外からいろんな議論があって、それに対処しないといけなかった。W3C側は、HTML WGだけじゃなくて関連する他のグループとも仕様について調整しないといけないんですが、特にアクセシビリティ関連の機能で話がまとまらなかった。まあ生産的でない議論がずっと続いているというのがあって、それに対処していった結果少しずつ離れてしまっている部分がでた。で、Hixieなどはそれをよしとしないので、Web Applications 1.0に反映されない。そういうのが続いて、完全にコミュニケーションがこじれたので、今のよくわからない2つの仕様があるんですね。

風向きが少し変わったGitHubへの移行

矢倉 少しだけ風向きが変わったのが1〜2年前で、WHATWG HTMLがそれまでHixie(ヒクシー: Ian Hicksonの通称)がwhatwg.org上のリポジトリで個人でやってたものがGitHubに移行したんですね。そしたら、みんなPull Requestを投げたりとか、issueを作って議論するようになってきたりして、少しずつコミュニティみたいに、みんなで作る仕様みたいになってきた。そうしたら、W3C側からも仕様を一致させようという動きが少しあって、多少一致したところもあります。ただ、マークアップ絡みのところだとやっぱり、Hixieや彼の周りの人が入れた仕様が受け入れられずまたこじれたまま、どうにもいかないところもあります。いまHixieは完全に離れちゃったんですけどねえ。

例えば、アウトラインアルゴリズムでWHATWGのほうでは、セクションの見出しとしてh1をレベルに応じて使うんじゃなくて、全部h1でいいよっていうのがあったんですけど、W3Cの中ではそれが省かれちゃったんですね。というのもスクリーンリーダーがちゃんと対応していないからという理由です。実装状況とかも反映するのがWHATWGのやり方なんで、W3C側で省かれた変更を取り込もうというのもGitHubのほうでissueができたんですが、それが受け入れられずに放置されているとかいうのもあります。ひいてはコミュニケーション不足、解消するにしてもちょっとこじれすぎててどうしたらいいのかわからないっていう気がします。

白石 なるほど。Hixieはもう離れちゃったんですね。

矢倉 離れてますね。今はFlutterっていう、ちゃんと見てないんですが、アプリ版のUnity…つまりXamarinみたいなものですかね、それに関わってるようです。あと個人では、IoTみたいな感じのことやってるみたいです。

白石 あ、Googleもやめたんですか？

矢倉 Googleはやめてないですね。FlutterはGoogleでつくられてるので。あと、Flutterに関わってる人を見ると、以前Chromeをやってた人とDartをやってたひとが集結していたりもしてて、なんか不思議です。

W3Cがフォークになってしまってる状況はぼくもなんとかしてくれとは思うんですけど、結局、特許ポリシーまわりなのかなあと。特許ポリシーがないと、実装に特許的な問題がでたときに、どこからも守ってもらえなくなるじゃないですか。そうするとWebプラットフォーム自体の進化が止まってしまうので、大人の付き合いは必ずしないといけないんじゃないかなあと。まあ、それをどこまで一般のWeb開発者が認識しなければいけないというのはありますし、別の話ではあるんですが。

ブラウザベンダーの人は、WHATWGの仕様を見ているんすよね。逐次アップデートされていくので、APIなんかの仕様はWHATWGのほうが安定度合いが高いと見ている。特許の部分てそこら辺に関わることが多いでしょうから、そこがちゃんと特許ポリシーで守られるべきだし、そうなるとW3C側の仕様でAPIの乖離が起こるのはよくない。そこはなんとかする仕組みがあればなあと思います。

で、API部分の乖離というのは、ただWHATWG HTMLのほうが更新されてるだけで、話がこじれたからというものってかなり少ないんじゃないかなと思うんですよね。ちゃんと調べたわけではないですが、大体マークアップのところに多いような気がします。マークアップのところでは、仕様を読む限りはW3Cのほうが筋がいいと感じるところも少なからずあって、例えばルビのマークアップとかでしょうか。WHATWGのやつだとあんまり嬉しくないようなものが確か残ったままだったような気がしています。

ただ、マークアップは、あっちの仕様でこう書いてあるけどこっちの仕様ではこう書いてあるからどっちを選ぶというのよりも、それも踏まえてどう使うかを自分で判断するってところが大事じゃないのかいと思うんですよね。結局、CSSとかJavaScript APIとかだって開発するときに「これはこのブラウザで対応してないからどうする」とか、ブラウザの対応状況を見て決めているわけじゃないですか。それと同じことをマークアップでやればいいんじゃないかなと思います。都合が悪い仕様ならそれは突っ込むべきなんですが、グループの政治的なところを、仕様を選ぶ理由にすべきじゃない。そんなのただただナンセンスなだけですよね。

普段Webを開発している人のフィードバックを得る仕組みが必要

白石 マークアップで問題になっているところって、rubyとかh1とか、hgroupとか。timeとかもいろいろ問題ありましたね。

矢倉 そうですね。あ、で、マークアップの仕様について言うと、まだ仕様がこなれてないんじゃないかと思うことがしばしばなんですよね。Hixieは基本的にかなり合理主義なところがあって、例えばブラウザのリバースエンジニアリングをして、その当時ブラウザが実装していたものを仕様に落とし込むってことをやっています。HTMLパーサなどが最たる例でしょうか。

でも、マークアップに関していうとかなり理想主義で、だいぶ厳格な考えを持つ人という印象があります。それがアウトラインアルゴリズムだったりとかに現れてるんですよね。HTML 4.01にはStrictという、タグセットを絞った厳格な定義がありますが、HTML5のはそれよりもさらに厳格なマークアップを要求しているように思います。もちろん、HTML5の策定当時にもそこらにあるHTMLのマークアップをまとめて、それをもとに要素を追加してたんですが、ちょっと理想が強すぎて、世の中のマークアップに対応できずに進んできたのかなあと。

で、HixieのHTMLがどれぐらい「Strict以上」かというと、ひとつの例としては、もう仕様からは10年前ぐらいに消えたんですけどpredefined classsesっていって、class名の値を特定の値だけに限定してそれ以外のclassを使ったらnon-conformingにするっていう仕様があったぐらいなんですよね。さすがに消えましたけど、それくらいドラスティックな変更を仕様に盛り込んだりしてたんです。rel属性の値とか、メタタグの名前も似たように限定してて、それは今でも残ってたりはしますね。

もちろんこれも、あとから解釈を広げた結果ふんわりしすぎちゃったってことにならないようにという意図があったとは思うんですが、フィードバックがなかったから使いづらい仕様のままになってしまってるケースってあるような気がするんですよね。

ブラウザの実装に係わるアルゴリズムやAPIの部分に関しては、数多くフィードバックが寄せられたので今のいい仕様があるわけですけど、マークアップのところはそういう仕様のフィードバックサイクルがまわらなかったのかなと。これは、普段WebサイトやWebアプリを開発している人のフィードバックが少なかったていうのもひとつあると思うんですよね。フィードバックを送って、それを適切に処理して反映させるっていうことができないと、作られるWebサイトやアプリのマークアップまわりがちょっと窮屈になって、結果としてユーザーの不利益になるかもしれない。もう起こってるかもしれないので、それを避けるように動かないといけないのかなあと。

Microsoftはどちらの仕様を参照するか、というよりもデファクトを重視

白石 それでは、さきほどの話を踏まえて、じゃあそれに対してブラウザベンダーの方々がどう標準を考えているのかみたいなところも聞きないとなと思います。そもそもブラウザベンダーの方々がみんなWHATWGのほうを参照しているっていうのは本当なんですか？

物江 うち（Microsoft）の最近の流れだと、相互運用性を非常に重視しているので、WHATWGにあるかどうかわからないことでも他のブラウザがやるのであれば対応しようっていうのがあります。結局のところWHATWGかW3Cかっていうよりは、デファクトがどうかっていうところですね。

白石 なるほど。デファクトという話だと、パターンとしては2つあって、みんなで一緒に始めるか、それとも誰かに始めてもらってそのあとを続くかになりますね。

矢倉 デファクトが重要というのは確かにそうですね。能動的であるか、受動的であるか、残念ながらやるみたいな。MozillaとかOperaとかはそういうポジションになってるんじゃないですか（一同笑）。

物江 例えば、WebRTCだと、最初WebRTCを包括するORTCという仕様を提案して進めていたんですが、結局相互運用性の問題で従来のWebRTC 1.0を後から実装する形になりました。突っ張っちゃったけど、しょうがないねっていう（笑）。

白石 例えばWebAssemblyなんかはみんなで一緒にやりましょうって始まって、すごくいい感じになってますね。

矢倉 デファクトっていうと、XMLHttpRequestとかも元々IEが持っていたものをMozillaが組み込んで、Geckoがたしか最初だと思うんですけど、確かその後WebKitが追従したんじゃないかなと思います、そういうプロプラエタリなものでも、取り込んでいく。

浅井 サービス側での利用が広がっちゃうとそれはもうしょうがないですね。そういう意味ではMozillaも例えば、WebKitのプリフィックスがついた機能をFirefoxでもサポートするということもやっています。

矢倉 そうですね、仕方なしにやるのか、便利だからやろうっていうのはわからないですが、そういうことをやってるというのはあんまり昔と変わっていないのかなと。WebKitプリフィックスの話だと、その上にっていう名前がついちゃってプロプラエタリ感が満載だから心理的な抵抗があるってだけで、やってることに関してはたしかに同じですね。

浅井 プロプラエタリ感が満載っていうよりも、せっかく標準化されたのに古い構文が残っていて、それを捨てられずにいるってのは、やっぱりもう一つの抵抗の理由だと思う。でも残念ながらサイトが対応してくれない状況が続くんだったら、まぁしょうがないよねっていう。

物江 ベンダープリフィックスって、Mozillaが一回はずしたんですけど、またサポートしたんですよね。

浅井 そうですね。-moz-プレフィックスは外している一方で-webkit-プレフィックスのサポートを追加した状況です。

Mozillaが日本のトップモバイルサイト100を調査して、修正依頼？

浅井 実は、MozillaがWebKitプリフィックスをサポートする判断をした背景には日本市場の影響も結構あります。MozillaにはWeb Compatibilityチームという、Firefoxに限らずWebサイトが誰にでも使えるようにするために取り組む部隊がいて、どのプレフィックスがどの程度ユーザの多いサイトで使われているかをこのチームで広く調査した上で、FirefoxでのWebKitプレフィックスの一部サポートを決断しました。

最初、中国とかアジアのサイトを見 ると酷かった。標準準拠コードを書いていないから、全然動かない。北米とかは最新標準仕様のコードを書くサイトが多いんですけど、中国のサイトはあまりにもひどいかった。

日本についても、日本のトップモバイルサイト100以上を片っ端から調査しました。動かないサイトがあったら原因が何かって徹底追求して、動かない原因と直すべきコードも全て調べた上で、各社にメールや電話をしまくり、Webのフォームやコンタクト先がなければ知り合いを通じて教えてもらうなどしてWeb担当者にFirefoxはもちろんIEなどでも意図通り動くコードへの修正をお願いしました。

その結果例えば、日経新聞とか、サントリーさんとか、ガールズチャンネルさんとかは直してくれたんですね。反応が面白かったのは、ガールズチャンネルさんなど、直し方わからなかったんです、ありがとうございますって即座に直してました（笑）。

矢倉 こうやったら直るっていうのまで伝えたんですね。

浅井 そうです。コードも全部、こうするだけで終わりですってところまで教えるんですね。例えば、ミクシィさんともこんな感じで直していただけますかって打ち合わせをしたのですが、彼らの場合 5万行以上のCSSファイルがあったりするので、なかなかすぐには難しいとお断りされました。いや、こういうツールを使うとプレフィックスがあるコードを自動変換できるやつもあるんですよってご紹介などもしたのですが、マネージャーレベルでは対応いただけなかったのです。

でもしばらくして、その打ち合わせに参加してくれていた現場のエンジニアの方が、次に携わるサービスでは提案してくれたツールを導入して対応しますとこっそり教えてくれました。その後それがmixi全体に広がりましたが、現場から変えてくれた彼には感謝しています。 最初から全体は直せなくても少しずつ直したりツールを用意したり教育をしたり、息の長い取り組みをしています。ただ、あまりにも日本やアジアのサイトはダメなところが多く、修正も時間がかかることが多くてユーザが不利益を被ってしまうため、非標準の標準化をしようっていったのがあの仕様 (Compatibility Standard)になります。

意外に思うかも知れませんが、日本のトップのIT企業が対応してくれないことが結構ありました。 社名は伏せさせてください(笑) 。当初は中国の特定サイトだけとか、日本の特定サイトだけブラックリストに入れて対応する案もあったのですが(実装もしていました)、トップ企業でも対応してくれない事例が多くあり、全サイトを対象とすることになりました。

ちなみに、他にも日本での調査を機に互換性対応で実装を変えた問題として、UA (UserAgent 名)があります。Mozillaとしては、ユーザのプライバシー確保とトラッキング対策のため、ユーザの絞り込みに繋がる情報は最小限とする方針であるため、主要ブラウザでも最もシンプルなUAとしており、AndroidのOSバージョンも含めていませんでした。

でも、日本のモバイルトップサイトを確認するとAndroidバージョンを入れると壊れるサイトと、入れないと壊れるサイトの両方があり、Androidバージョンを入れたときのほうが直るサイトの割合が遙かに高かったです。それである意味仕方なく、OSバージョンを入れることになりました。この話なんかもWeb標準仕様と同じように、実態に合わせつつ、あるいは他のブラウザの挙動に合わせつつ実装をしていっている事例の一つでしょう。

白石 ちなみに、その非標準の標準化っていうのは本当に標準化するんですか、つまりW3Cのプロセスにのせたりとかするつもりがあるということですか？

浅井 WHATWGでは[Compatibility Standard]（https://compat.spec.whatwg.org/）という仕様として書いていますが、W3Cでやるかっていうとそれはわからないですね。あんまそういう動きはないと思います。

矢倉 あ、でも一部の機能はCompat Standardみたいなパッチではなくて、標準仕様にとりこまれてます。たとえば、Element.matches()という、ある要素が特定のCSSセレクタにマッチしてるか判別する仕様があるんですけど、それが昔の仕様だとmatchesSelector()という名前で、それがWebKitではwebkitMatchesSelector()として実装されていたんですね。で、互換性のために仕様で定義しようって話になったときに、それはもうCompatibility Standardじゃなくて、DOMの仕様の中で定義したんですよね。そういうのもあります。

浅井 innerTextとかもそうですね。標準のtextContentしかサポートしないって僕らは言い張ってたんですけど、僕らだけサポートしないっていってても日本などのサイトは直らないから仕方がないということでinnerTextでも動くようになりました。標準にも反映されています。

新しい取り組みである「Origin Trial」とは？

えーじ ベンダープリフィックスの問題って結構長くあって、それを解決する方法として、Chromeでは基本的にExperimentalな機能をStableに入れないっていうのを始めたんですよね。もうその機能は、Betaまでのバージョンまでしか動きませんっていう状態で、まずは実装をはじめて、最終的にそれをStableにのせるために必ずコンセンサスをとらないといけない。

なのでMLにIntent to Shipっていうメールを出すんですが、それで合意が得られて、実装が2つ以上存在している場合にのみStableにのせるという段階を踏むようになりました。なので、新しい機能については基本的にはある程度、成熟した仕様であり、かつ実装も問題ないという合意が得られたうえでshipしますというような状態になっています。

最近始めたOrigin Trialというのがあって、それは新しい機能をStableにのせるけど、あらかじめ使いたいと手を挙げたサイトでのみが使えるというもの。それをやるためには、フォームで申請をして、そのトークンをサイトに載せることによってブラウザがホワイトリストでその機能を動かす、そうすると我々としてもどのサイトがそれを実装してるかわかるし、もし仮にそれにひどい変更が入りますってときにもコンタクトをとることができると。

矢倉 あと、Origin Trialは、一定期間過ぎたら終了するっていうのもありますね。

浅井 Origin Trialは、面白いなと思って見ています。その機能が大規模に使われると、サイトのドメインの数が少なくても例えばfacebook.comで使われてしまうと後戻りできなくなるので、ユーザーの数が一定以上を超えたら無効になるっていう仕組みがある。そういうのをちゃんと考えているのが面白いなと思う。

今後、全面的にOrigin Trialになっていくのかどうかとか、例えばBLE（Bluetooth Low Energy）は、Origin Trialに入れながらやって、この時期には標準にするよって宣言しながら実装されてます。それが宣言された時期までに他のブラウザが実装しているかどうかというのは、本当にshipする基準にするのか、それとももう宣言してしまったから実装がなくてもshipするのか、どっちなのかなという点を気にしながら見ています。

矢倉 Origin Trialは、もともとマイクロソフトの人が提案してたんですよね。EdgeチームのJacob RossiがW3CのTPACで提案してて、そこにChromeチームのAlex Russellものっかっていて、もしかしたら二人のアイディアなのかもしれないですけど、最終的にChromeだけでやってはいますけどね。

Origin Trialは、APIのローンチカスタマーを作る意味でも結構良いのかもしれないですね。手厚くフィードバックも得られるし、カジュアルに試して見たよっていうよりもこういう業界的なニーズがあるから使いたいということでOrigin Trialに申請するといったら、ChromeのDevRelのひとも反応しやくすくなるのかなっていう気がします。

白石 たしかに。ニーズがあるかわからない機能が入ってくるとかもありますしね。

矢倉 そして不幸になるっていうのはHTML5でいくつか経験してますからね。

浅井 Extensible Webのときからそうだというイメージありますが、やっぱりブラウザベンダーと標準化団体だけで作っていたらもうダメだっていうのがよくわかっていて、いかにデベロッパーの声を集めて標準化に反映するかが大事です。Origin Trialはそれを実現する手段を具体化した手段の一つだと思うので、非常に面白いと思って見ています。

GoogleはWebが目指すべきところに必要な機能があればどんどん進めていく

白石 ちょっとえーじさんに聞いてみたいなと思ったのは、さっきEdgeはデファクトを追いかけますって話だったので、だとすると、まず最初に実装するベンダーとかが必要になってくるじゃないですか、デファクトを作る人たちが必要なので。それって、ここでいうとGoogleとか、Mozillaとか動きが早そうだなと。そうすると、どの仕様を実装するかを決めるのってどういう基準でやってるのかなというところを聞きたいなと。

えーじ 社内的にはやっぱり、Webが目指すべきものっていうのをざっくり持っていて、その中でじゃあそのピースを埋めるために必要なのはどの機能なのかっていう判断をして、なければ作るしっていう感じで進めちゃいますね。他がやるのを待ってるっていうスタンスではないです。

白石 なるほど。具体的いうと、例えばService Workerとかなんですかね？

えーじ そうですね。ひとことで言っちゃえばProgressive Web Appsっていう話になるかと思います。以前より一言ですむんでだいぶ言いやすくなりましたね（笑）。今までは、一生懸命Service WorkerとAdd to Homescreenと〜、とか説明しなきゃいけなかったのが一言で済むので個人的にはありがたいですけど。所詮マーケティング用語みたい感じの部分もあって、結構揶揄されたりしますが、一言で表せるという意味ではモバイルに対するWebの回答と考えるとわかりやすくて良いのかなと思います。

ここ最近は、Webが割と盛り返してきた感じを受けてるんですけど、去年までの2〜3年ぐらいの間ってやっぱり日本の各社もWebチーム解散してAndroidにリソース注ぎ込むとか、ざらにあったりとかしてWebがだいぶ負けてきているっていうのはすごく思っていたんですけど、Service WorkerとかPWAの流れがでてきて、だいぶ盛り返してきた感じがあります。

Progressive Web AppsはモバイルWebをいかによくするかのムーブメント

えーじ PWAに対する反応もすごくいいんですよね。なので、そういう意味ではモバイルでのWebをいかによくしていくかっていうムーブメントとして僕はPWAを捉えている。技術的には細かい話はいっぱいありますけど、そのピースをどう組み合わせていくかっていうのは各ブラウザベンダーの判断もあるでしょうし、思惑もあるでしょうが、最近は足並みが揃ってるという感じがしています。

物江 EdgeでもPWA周りの仕様は、開発中のステータスになっているので、近いうちにEdgeでも使えるようになる可能性がありますね。

矢倉 EdgeチームのJacob RossiがMediumに投稿していて、WindowsでPWAを考えるとブラウザの中だけにとどめておくってことはしないで、WindowsストアだとかBingの検索結果に乗せるだとか、PWAをインストールしたら、それがスタートメニューやランチャーに乗るとかも検討しているらしいですね。

物江 Chrome Appsみたいになるらしいです（笑）。

えーじ 話をややこしくした（笑）。

白石 Chrome Appsは、サポート終了するのに（笑）。

えーじ ある意味それは正しくて、Chrome Appsを終了する理由って、Webの標準を盛り上げていかないといけないのにChrome Appsというプロプラエタリなものに注力し続けるよりは、Webの標準からネイティブ的なアプリが作れるようになるべきであるという感じです。

白石 じゃあ、Chrome Appsに実装されていたBluetooth APIやUSB API、Socket APIとかは。

矢倉 USB APIはOrigin Trialになってますね。

えーじ Socket APIは、入っていないですね。それをやるかどうかも決まっていないと思います。要望があれば受け付けますというフォームもあるので、その辺はデベロッパーのユースケース次第という感じですかね。

白石 なるほど。少なくてもそれらを標準化にのせていこうという意図は、持っているということですかね？

えーじ モチベーションがある人がいればやるって感じですね。社内でそれを是非やりたいという人がいれば仕様も書くだろうし、実装もすると思います。いい例でいえば、PaymentRequest APIとかCredential Management APIとか、最近はここら辺を担当しているんですが、やっぱり担当のチームがきちんとあります。Paymentsに関してはMozillaさんやMicrosoftさんと並行して実装も進めていると思います。

物江 Paymentsは、Edgeでも開発中なので、近いうちに。

（後編へ続く）

Web技術でアプリ開発2016特集・第5弾は、プログレッシブウェブアプリ (Progressive Web Apps)をご紹介させていただきます。

はじめに

プログレッシブウェブアプリ(Progressive Web Apps)という言葉が初めて登場したのは2015年8月のAlex Russellによる記事Progressive Web Apps: Escaping Tabs Without Losing Our Soulです。当時オフラインやプッシュ通知など、モバイルウェブを飛躍的に進化させる画期的な機能が次々と追加されていた状況において、このムーブメントを呼称するための言葉が求められていました。Google社内でいくつもの候補が挙げられましたが、Service Workerの発案者としてAlex Russellが推したのが、この「プログレッシブウェブアプリ」でした。

また、当初Googleで始まったプログレッシブウェブアプリの動きではありましたが、先日のProgressive Web App Dev SummitではMicrosoft、Mozilla、Opera、Samsungの代表者も登壇するなど、各ブラウザベンダーとも足並みが揃いつつあります。これはもはやウェブ全体の動きと言うことができます。

若干古い情報になりますが、以降この (長い) 記事を読む以外に手早く情報を得るための方法として、下記を挙げておきます。

スマートフォン体験を一歩先へ – プログレッシブウェブアプリの作り方

講演動画

プレゼン資料

プログレッシブウェブアプリとは

プログレッシブウェブアプリとは、最新の標準ウェブ技術を用いることで、オフラインやプッシュ通知といったこれまでよりも一次元上のユーザー体験をもたらすウェブアプリのことです。必ずしもデスクトップのウェブアプリや、ページ遷移を使ったサーバーサイドでレンダリングされるアプリを除外するものではありません。

理屈で説明するよりも、実際に体験した方が早いかと思います。いくつか具体例を挙げましょう。

• Flipkart
• Washington Post
• AliExpress
• suumo

※ 他にも様々なプログレッシブウェブアプリが既に存在していますが、pwa.rocksというサイトにいくつかまとまっていますので、ぜひご覧頂下さい。

実際に使ってみるとわかりますが、これらのアプリケーションにおいてこれまでにない特徴的な点がいくつかあります。

• ホーム画面に追加してワンタップで起動
• キャッシュを使ってオフライン、もしくは高速に動作
• プッシュ通知を送信
• 自動でログイン

プログレッシブとは何か

「プログレッシブ」という言葉自体は直訳すると「進歩的な」といった意味がありますが、ピンとこない方は多いと思います。

プログレッシブウェブアプリの「プログレッシブ」のひとつの意味は、ウェブページとして使い始めたサービスが、ホーム画面に追加し、オフラインで動作し、プッシュ通知を送り始めるといった流れの中で、「徐々にアプリへと変化していく」様を指しています。

もう一つ意味があります。

フロントエンドエンジニアであれば、プログレッシブ・エンハンスメントという言葉を聞いたことがあると思います。プログレッシブ・エンハンスメントとは、HTML5 時代に続々と新しい機能が登場する中で、最新の標準技術をまだ盛り込んでいないブラウザでも、情報を届けるといった目的をゴールに、必要最低限の機能をベースとして、可能であれば最新技術を使うことでよりリッチな体験を提供する、という設計コンセプトのことを言いました。(逆に、リッチな体験を提供できるブラウザをベースに、最新の技術が使えないブラウザでも最低限の目的は達成できるように設計する手法をグレースフル・デグラデーションと呼びました)

プログレッシブウェブアプリも同様に捉えることができます。つまり、必要最低限の機能を提供できる状態をベースとし、オフラインやプッシュ通知などをプログレッシブな (進歩的な) 機能として提供する、というものです。

これは言い方を変えれば、対応していないブラウザがあるからといって対応を待つべきではなく、それを前提としてウェブを前に進めていこう、というメッセージでもあるのです。実際、プログレッシブウェブアプリ対応への副作用として、複数の機能に未対応のブラウザでもコンバージョンレートが改善したという事例も出ています。

アプリとウェブのギャップ

Web2.0の時代を経てコンピューターの世界はネイティブアプリケーションからウェブアプリケーションの時代へと変化を遂げました。地図アプリケーションを思い出して下さい。その昔CD-ROMからせっせとインストールする必要のあった地図が、URLひとつでブラウザから見られるようになったのです。他にも例を挙げればキリがありません。

ウェブはその後もHTML5やその周辺技術の発展により大きく進化していきました。しかしその恩恵を満足の行く形で受けられたのはデスクトップでの話。モバイル・スマートフォンの時代となり、ユースケースが変化していく中で、スマートフォン上で快適に目的を達成するためには、ウェブブラウザは力不足と言われるようになってしまいました。その象徴的な出来事の一つがFacebookのCEOマーク・ザッカーバーグによるこの発言でした。

Disrupt：ザッカーバーグ、「HTML5を過大評価したのは、われわれ最大の失敗」と認める | TechCrunch Japan

これはひとえに標準化を必要とするウェブという環境の特性ゆえと言わざるを得ません。標準化を進めつつ実装し、浸透を待たなければならなかったウェブと異なり、ネイティブアプリはモバイルに最適化した仕様や機能を次々と取り込み、技術革新を起こしていきました。

しかしウェブには、ネイティブアプリでは実現できない特性も持ち合わせています。それがSLICEと呼ばれるものです。

• Secure (安全)
• Linkable (リンク可能)
• Indexable (インデックス可能)
• Composable (再構成可能)
• Ephemeral (一時的な利用)

ウェブもネイティブも、お互いの短所を埋める進化を遂げていく中で、ウェブが着実に前進していることの現れが、プログレッシブウェブアプリと言えるでしょう。一度はHTML5化を断念したFacebookがプッシュ通知を採用したのはその最たる例です。

Facebook、Googleと協力してモバイルウェブユーザーにプッシュ通知を送信

プログレッシブウェブアプリはWeb 2.0、HTML5と続いてきた大きな流れの、次の一歩と捉えて間違いありません。

プログレッシブウェブアプリを構成する機能

プログレッシブウェブアプリはそれ自体が機能を表しているわけではなく、様々な先進的機能をまとめたひとつのムーブメントです。具体的にどんな機能があるのか、ひとつひとつ見ていきましょう。

• HTTPS
• Web App Manifest
• Service Worker
• Cache API
• Web Push / Push Notifications
• Background Sync
• Web Budget API
• Credential Management API
• Payment Request API

HTTPS

プログレッシブウェブアプリに対応する上で大前提になるのがサイトの完全なHTTPS対応です。ログイン画面や商品購入画面だけではなく、すべてのページをHTTPS化する必要があります。

一般的に、HTTPSに対応することでウェブサイトは

• ウェブサイトの一意性を守るアイデンティティ(Identity)
• サーバー・ブラウザ間の通信を秘匿するコンフィデンシャリティ(Confidentiality)
• 送受信されるデータを改ざんさせないインテグリティ(Integrity)

の3つを手に入れることができます。

プログレッシブウェブアプリ対応において重要なのが、以下でご紹介する機能のほとんどがHTTPS上でのみ動作 (セキュアコンテキスト)するという点です。こういった機能はPowerful Features と呼ばれ、以前はHTTP上でも動作したgetUserMediaやgeolocationといったAPIもそこに加えられ、最近HTTPSのみで動作する変更が加えられました。

HTTPSに対応することなしにプログレッシブウェブアプリを実現することは不可能ですので、対応を検討する方はここからスタートして下さい。(ちなみにChromeでは、localhostとfile://もセキュアコンテキストに含まれますので、開発時は少し役に立つかもしれません)

Web App Manifest

ネイティブアプリとウェブサイトを比較した時に、最も大きく異なるのがアクセスのしやすさです。もちろん、アプリのようにインストールしなくても、リンクを踏むだけでアクセスできるという意味で、ウェブは手に届きやすい存在です。しかしスマートフォンの場合、デスクトップのようにキーボードで手軽に検索ができるわけではありません。ホーム画面からタップひとつで起動できるだけで、ユーザーにとっての身近さは大きく改善します。

そこで登場するのがWeb App Manifestです。Web App Manifestを使うことで、該当ページに関する様々な情報を定義することができます。

Web App Manifest | MDN

最近はlangやscope、screenshotsといった項目も新しく追加されていますので、その辺りも注目して下さい。

これらの情報を踏まえ、「ホーム画面に追加」をすると、ウェブアプリはホーム画面に鎮座することができるようになります。しかし、この機能がiOSでも古くからあるmetaタグを使ったものに近いと思われた方もいるかもしれません。

Chromeの場合、このWeb App Manifestといくつかの条件が加わることで、ブラウザが自動的にホーム画面に追加を促してくれる、という点が大きく異なります。詳しくは下記の記事を参照して下さい。

Web App ManifestでWebアプリをインストール可能に – Qiita

Service Worker

Service Workerはプログレッシブウェブアプリを構成する機能の中でも、コンセプトを成立させた一番の立役者で、中核を成すものです。

従来のウェブにおいて、ページはサーバーから送られたHTMLとそれに付随するリソースで構成される機能がすべてであり、ページが閉じられると同時に忘れ去られる存在でした。Service Workerは、ページとは独立して動作するスクリプトを、ページを閉じた後でもブラウザ上で動かし続けることができる機能です。このService Workerを活用することで、様々な可能性が開かれます。

オフライン：Service Workerはページが送信するあらゆるリクエストを横取りすることができます。実質的なローカルプロキシーとなるため、強力なキャッシュを活用すれば、ネットワークに接続していない状態でもレスポンスを返すことができるようになります。詳しくはCache APIの項で説明します。

プッシュ通知：Service Workerはページが閉じた状態でも、また、ブラウザによっては起動してない状態であっても、イベントを検知することができます。そのため、外部サーバーが送信したプッシュリクエストをイベントとして受け取り、何かしらのアクションを起こすことができるのです。詳しくはWeb Push / Web Notificationsの項で説明します。

それでは、Service Workerの使い方を雰囲気だけ見てみましょう。

Service Workerは独立したJavaScriptとして動作するため、ファイルも分けて記述する必要があります。例えばページ上で動作するスクリプトapp.jsが、service-worker.jsというService Workerを使いたいとします。

navigator.serviceWorker.register('service-worker.js', {scope: './'});

これだけでService Workerが登録されます。簡単ですね。

service-worker.jsの中身はイベント・ドリブンのスクリプトになります。例えば下記のように記述しておけば、あらゆるリクエストをService Workerが拾い上げて、サーバーにリクエストを転送することなく”Hello World!”とレスポンスを返します。

self.addEventListener('fetch', function(event) {  
  event.respondWith('Hello World!');  
});

Service Workerは実際いつ動作を開始するのでしょう？影響範囲はどこまででしょう？こういった細かい話になるとセキュリティへの懸念も出てくるため、若干複雑な内容を理解する必要が出てきます。scopeとライフサイクルについては抑えておきましょう。

scope

Service Workerが登録されると、以後半永久的にスクリプトを動かし続けることになります。仮にService Workerがドメインの範囲内すべてに影響をおよぼすことができるとすると、ブログなどのユーザーの権限がパスで区切られたサービスでは、自分の預かり知らないスクリプトが埋め込まれてしまう可能性がでてきます。そこでService Workerでは、scopeという概念を使って影響範囲を制限します。詳しくはこちらの記事が参考になります。

ServiceWorkerのスコープとページコントロールについて – Qiita

ライフサイクル

Service Workerが登録されたあと、スクリプトを手動で更新したい場合もあります。新しいスクリプトはすぐに有効になるのでしょうか？その場合古いスクリプトはどうなってしまうのでしょうか？Service Workerは放っておいたら永久に更新されないのでしょうか？

Service Workerのライフサイクルを正しく理解することはとても重要です。下記の記事をぜひご覧ください。

• Service Workerの紹介: Service Workerの使い方 – HTML5 Rocks (一部古い内容が含まれます)
• 中級者向け Service Worker Tutorial | blog.jxck.io
• Service WorkerのRegistration

デバッグ

Chromeではプログレッシブウェブアプリのデバッグをしやすくするために、最近DevToolsにResourcesパネルの代わりに Applicationパネルが追加されました。Manifestや各種ストレージなどを、ひとつのパネルからまとめて確認することができます。中でもService Worker専用の項目では、現在起動中のスクリプトだけでなく

• Offline – オフラインのエミュレーションボタン
• Update on reload – リロードするだけでService Workerを更新
• Bypass for network – ネットワークリクエストの横取りを一時的に停止

といったオプションが利用できます。ここからService Workerの単独のDevToolsを開いてデバッグを行ってください。

少し未来の話

今後利用可能になるService Worker周辺の重要な機能についても少し触れておきましょう。

Link rel=serviceworker Chrome 54からOrigin Trial (特定のドメインに実験的にホワイトリストで機能を提供) ベースでService Workerの登録が linkタグやHTTPヘッダーで行えるようになりました。将来的にこれが利用できるようになれば、JavaScriptを記述することなく、linkタグやHTTPヘッダーのみでService Workerを登録できるようになります。

<link rel="serviceworker" href="/js/sw.js" scope="/">

https://www.chromestatus.com/feature/5682681044008960

Foreign fetch また、Web Fontsのような複数ドメインから共有されるリソースをCDN経由で提供するサーバーのリソースも、現在は利用する側のService Workerがハンドリングすることが可能ですが、これをCDN側のService Workerがハンドリングできれば効率が向上します。これを可能にする機能はForeign Fetchと呼ばれ、Chrome 54からOrigin Trialベースで提供が開始されています。

https://www.chromestatus.com/feature/5684130679357440

その他、Service Workerのさらに詳しい情報はHTML5 Conference 2016で行われたChromeエンジニアの保呂さんのスライドが参考になります。
Service Worker Deep Dive

Cache API

先程説明したように、Service Workerを使ってあらゆるリクエストを横取りすることで、オフラインの機能が実現可能になります。そこで強力なキャッシュ機能を提供するのがCache APIです。

Cache APIは取得されたリソースだけでなく、リクエストやレスポンスの内容も含めて保存されます。下記の例では、キャッシュが残っていればキャッシュされていたレスポンスを、なければサーバーにリクエストを送って、返ってきたレスポンスを返します (キャッシュに保存はしません)。

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).then(function(response) {
      return response || fetch(event.request);
    })
  );
});

Cache APIを使った実例について、詳しくはこちらの記事が参考になります。

ServiceWorkerとCache APIを使ってオフラインでも動くWebアプリを作る – Qiita

なお、Cache APIを扱う上で fetch()も避けては通れませんが、ググらビリティの低さから、まとまった資料が見つかりにくいという問題があります。こちらのページがよくまっていたのでリンクしておきます。

お疲れさまXMLHttpRequest、こんにちはfetch – Qiita

ここまで述べてきたように便利なService Worker + Cache APIですが、多くの人が似たようなコードを書くであろうことは容易に想像ができます。そこで便利なライブラリがいくつかあります。

sw-toolbox

リソースをキャッシュする際に必要になるのが、リソースの優先順位の判定です。例えば共通で利用されるJavaScriptファイルは、更新がない限りネットワークにリクエストを送るまでもなく常にキャッシュから読み込むことでスピードを優先したいと思うはずです。逆に例えば、天気アプリであれば、開く度に最新の天気予報を見たいですが、オフラインだった場合はオフラインだと言われるよりは、キャッシュからでもその後の天気予報を見たいと思うはずです。

このように、同じキャッシュを活用するでも、場面によってキャッシュを優先したいのか、ネットワークを優先したいのかが異なってきます。そこで便利なのがsw-toolboxです。

toolbox.router.get('/myapp/index.html', toolbox.networkFirst);

sw-toolboxではネットワークを優先するnetworkFirst、キャッシュを優先するcacheFirstの他にもfastest、networkOnly、cacheOnlyといった様々なオプションが利用可能です。

https://googlechrome.github.io/sw-toolbox/docs/master/index.html

sw-precache

Service Workerを使ったキャッシュ機能以前にオフラインを実現する機能として登場したApplication Cacheは、ページを初めて開いた時点で、予め定義されたリソースをすべてキャッシュするものでした。Service Worker + Cache APIにおいても同様のニーズはあるでしょう。例えばアプリの外枠や必要最低限のCSSやJavaScriptファイルを予めロードしておくことで、コンテンツ部分のみをダイナミックにロードすればよいというApplication Shellというアーキテクチャを利用する場合です。

これを実現するのに便利なライブラリがsw-precacheです。Gulp やGruntといったタスクランナーを使うことで、リストされたリソースを最初のロード時点でキャッシュしてしまうJavaScript のコードを出力してくれます。あとはこれをService Workerとしてロードすればよいだけです。また、リソースの更新もハッシュを使って自動的に管理してくれるので、どのファイルを書き換えたからリストを変更しなければならない、といったようなマニュアル作業が不要になります。

gulp.task('generate-service-worker', function(callback) {
  var path = require('path');
  var swPrecache = require('sw-precache');
  var rootDir = 'app';

  swPrecache.write(path.join(rootDir, 'service-worker.js'), {
    staticFileGlobs: [rootDir + '/**/*.{js,html,css,png,jpg,gif,svg,eot,ttf,woff}'],
    stripPrefix: rootDir
  }, callback);
});

なお、最近追加されたruntimeCachingという機能を使うことで、sw-toolbox の便利な機能を宣言的に記述することもできます。

sw-appcache-behavior

もし既にApplication Cacheを使っていて、Service Workerに移行を検討している場合は、sw-helpersライブラリの一部であるsw-appcache-behaviorが便利です。既存の Manifestファイルをそのまま利用してService Workerによるオフラインを実現することができます。

sw-offline-google-analytics

オフラインのウェブサイトがうまく作れたとしても、ユーザーがどのアクセスページにアクセスし、どのように利用しているかが分からなければ、本当に役に立っているのかどうかを知ることはできません。これもsw-helpersの一部であるsw-offline-google-analyticsを使えば、オフライン中のアクセス解析をデータベース上に保存しておいて、オンラインになったタイミングでサーバーに送信してGoogle Analyticsでアクセス解析結果を閲覧することができるようになります。

Web Push / Web Notifications

プッシュ通知は、プログレッシブウェブアプリを語る際、これまでできなかったことの中で、技術者ではなくても効果が理解できるという意味では、最も分かりやすい機能です。実際に既に多くのサービスがこれを利用しています。例えば Facebook です。モバイルウェブ版のFacebookにアクセスしてみると、すぐにそのことに気付くでしょう。

navigator.serviceWorker.ready().then(function(sw) {
  sw.pushManager.subscribe({userVisibleOnly: true})
    .then(function(sub) {
      // パーミッション取得後
      sendSubToServer(sub);  // Send subscription to the server
  });
});

self.addEventListener('push', function(event) {
  event.waitUntil(
    self.registration.showNotification(title, {
      body: body, icon: icon, tag: tag,
      actions: [{action: 'remindMe', title: 'REMIND ME'}]
    }
  });
});

具体的な実装方法は若干複雑ですので、サードパーティーのサービスを使うのも手かもしれません。自分で実装する場合は、こちらのドキュメントがよくまとまっています。

Web Pushでブラウザにプッシュ通知を送ってみる – Qiita
Firefox (Developer Edition)でW3C Push APIを使ってみる – Qiita

Chromeの場合、以前はGCM (Google Cloud Messaging、もしくはFirebase Cloud Messaging)が必須でしたが、現在は標準の Web Pushが利用できます。詳しくは下記をご覧下さい。

ChromeでW3C Push APIを使ってみた – Qiita

Web Pushについては、node.js 向けのライブラリも提供されています。

Background Sync

妙なタイミングでネットワークがオフラインになってしまったために、リクエストが送れなかったという経験は誰しもあると思います。そんな時にリクエストをキューしておいて、オンラインになったタイミングで送ってくれるとありがたいですよね。それを実現してくれるのが、Background Syncです。

ServiceWorkerのBackground Syncでオンライン復帰時にデータ送信 – Qiita

Web Budget API

現状Service Workerはプッシュを受信すると、通知を出さなければなりません。これはブラウザリソースの無駄遣いを防ぐためです。しかし、例えばバックグラウンドで購読しているフィードを更新するといったユースケースは容易に思いつきます。

そこで検討されているのがWeb Budget APIという機能です。これを使うことで、ページは与えられたバジェットを適切に配分してバックグラウンドでの処理を行うことが可能になりますので、リソースの無駄遣いを防ぎつつ必要な機能を実現できるようになるはずです。

https://www.chromestatus.com/features/5691190548627456

Credential Management API

Credential Management APIはユーザーのクレデンシャル (認証情報) を制御するためのAPIです。

これを使うことにより

• id / passwordをブラウザに覚えさせる
• ソーシャルログインの選択肢をブラウザに覚えさせる
• ログイン時にアカウント選択ダイアログを提供する
• ユーザーを自動的にログインさせる

といったことが可能になります。

典型的なユースケースとしては、ニュースサイトやコマースサイトといった、必ずしもログインしなくてもよい、しかし提供者側としてはログインしてもらいたいサービスにおいて役立ちます。実際に利用されている例としてはAliExpressの実装が非常によくできていますので、是非一度お試し下さい。

実装は基本的にフロントエンド側だけですので、比較的気軽に導入することができます。

• デモアプリ (ソースコード)
• 翻訳済みのドキュメント
• 実際に実装を体験できるコードラボ
• 仕様
• MDN リファレンス

Payment Request API

Payment Request APIは支払い時のチェックアウトに必要なフォームを置き換えるUIを提供します。Chromeではバージョン 53から利用できるようになる予定です。

Payment Request APIが提供するのは、ユーザーインターフェースです。ブラウザのAutofill機能を活用することで、クレジットカードの情報や住所などを、すばやく簡単に入力できるようになります。

支払い方法は現状クレジットカードのみですが、まもなくAndroid Payも利用可能 (残念ながら当初日本は対象外) になる予定です。将来的には、さらに様々な支払い方法をオープンかつ柔軟に組み込めるようになっていく予定です。

• アナウンス・概要
• 実装ガイド
• Android Pay 実装ガイド
• 仕様
• MDN リファレンス

その他の機能

プログレッシブウェブアプリを語る上で数えるべき機能や考え方は他にもいくつかありますが、キリがありませんのでこの辺にしておきましょう。

• Web Bluetooth
• Web MIDI
• Web Animation

興味のある方は、この辺りもぜひ抑えておいていただければと思います。

Lighthouse

あるウェブアプリを指してそれがプログレッシブウェブアプリかどうかを議論するのはあまり意味のないことですが、それを示す指標を得ることはできます。それがLighthouseというChrome拡張機能です。ウェブサイトを開いた状態でこの拡張を起動すると、プログレッシブウェブアプリの対応度合いをスコアで示してくれます。

Chrome拡張機能としてだけではなく、node moduleとしても利用が可能です。

https://github.com/GoogleChrome/lighthouse

Lighthouseはまだアルファ版の段階のため、評価できない機能が多数ありますが、今後対応していく予定です。

リソース

プログレッシブウェブアプリに興味を持たれた方で、最新情報を追いかけたいという方は下記のページをご覧下さい。RSSフィードも配信しています。

https://developers.google.com/web/updates/

資料が英語で読めない？英語が分かる人はぜひ、翻訳にご協力下さい。

最後に

プログレッシブウェブアプリについて長々と書いてきましたが、重要なのは決してこれらの機能すべてに対応することではありません。自分が提供するサービスがユーザーに最大の価値を提供するために必要であれば、ネイティブアプリを提供するべき場合もあるでしょう。オフライン機能だけが必要な場合もあるかもしれません。これらの機能をうまく組み合わせて、ユーザーが本当に求めている価値を提供できるアプリを開発していただければと思います。

この記事は、「de:code2016」のセッションレポート、日本マイクロソフトエバンジェリスト物江修氏による「モダンWeb:たった今と、ほんの少し未来のはなし」です。講演内容を再現していますが、ニュアンス等伝えきれない場合があるかもしれません。ご了承ください。

モダンWebとは

昨今、様々なところで「モダンWeb」という言葉を聞くが、その定義は曖昧で意味するところの範囲が広範囲に及んでいるためではないかと考える。多くの場合、「モダンWeb」という文脈で語られている内容は次の４つの事柄で語られている。

• モダンなWebシステム
• モダンな開発手法
• モダンな標準機能
• モダンなアプリケーション

単にモダンWebアプリケーションと言った場合にはこれらいろいろな意味に捉えることが多いが、このように四つに分けることができる。このセッションでは、アプリケーションを開発するのに必要な「モダンなWeb標準の機能」、「モダンなWebアプリケーション」に関して触れる。

なぜ「モダンWeb」が話題になっているのか

第一に挙げられることは「時代の要求」。具体的には以下の3つが挙げられる。

• Web技術の進化
• コンテンツのリッチ化
• クライアントの多様化

Web技術で作るリッチなUIは昔から存在していたが、以前はFlashなどのプラグインを利用したいわゆるRIA(Rich Internet Applications)のほうが優勢だった。その後、Ajaxでデータを取得し、そのデータを使って部分的なUIの更新が可能になり、jQuery UIなどのUIライブラリによる開発生産性の向上、そしてHTML5の登場によって、プラグインで行っていたことがWebの標準技術だけで作ることが可能になった。これがWeb技術の進化である。

そしてスマートフォンから始まったFlashの衰退が進み、今までFlashで行っていたような要求をWebコンテンツ側にやってくるようになり、コンテンツのリッチ化が始まった。

スマートフォンを始め、PCブラウザー以外の様々なものがインターネットに繋がり、クライアントが多様化した。

この「クライアントの多様化」はサーバーサイドの形態にも影響を与え、その影響が、Webブラウザー上で動くアプリケーションにも影響を与えたという状況になっている。具体的にどういうことなのか。

黎明期のWebアプリケーションは、リクエストされたページを単純にレスポンスするというもの。ちなみに一番最初のWebサーバーはティム・バーナーズ・リーが作った「CERN Httpd」で、1991年にニュースグループで公開されたが、翌年に作られた「NCSA Httpd」ではCGIがサポートされ、動的ページが作れるようになった。ご存知の通り、このサーバーサイドで処理をして、処理結果をページで返すWebアプリケーションは広く使われている。

さらに、新しいクライアントとして携帯電話が現れる。NTT Docomoから始まった携帯電話は、それまでWebのクライアントというと、PCブラウザかゲーム機くらいで、いずれも机に座って使うようなものだった。

しかし、携帯電話は持ち歩き、行動に必要な情報を得るためのツールとして機能するモビリティという考え方が生まれた。

今までとは利用用途が異なる、サーバーではデバイスに応じた専用のコンテンツを作る必要があるなどコンテンツを作っていくには困難な状況だった。

やがて、スマートフォンに代表されるスマートデバイスが現れます。これらは、PCブラウザー用のコンテンツを同じ様に処理することができたので、わざわざ専用のコンテンツを用意しなくても済む。問題は、画面サイズに応じて表示を切り替える必要があり、同時期に出てきたHTML5関連技術であるCSS3を使ったレスポンシブWebデザインで、こうした技術を吸収することができた。

さらにスマートフォンは、サーバーサイドの処理にさらに大きな変化をもたらした。

Webアプリケーションの登場です。サーバにリクエストを投げるが、必要とするのはページではなくデータでした。この影響を受け、Webサーバーに必要な技術は、データを返す「API」が重要になった。

現在では、クライアントデバイスの性能とWebブラウザーの機能も数段上がり、処理性能ではネイティブで作られたアプリケーションと同等なことができるようになった。

SPA(Single-page Application)

単一ページによるWebアプリケーションであるSPAの特徴は、以下が挙げられる。

• 画面遷移はDOM操作
• ページのリフレッシュは不要
• リッチなエクスペリエンス

SPAにするメリットもいくつかある。例えば、サーバーサイドを「サービス化」することによって、多様化していくクライアントにも対応できるようになる。つまり、サービスをどこにでも提供できポータビリティを上げることができる。

現在のようにクライアント技術の進化が劇的に早い（言い換えると、陳腐化する速度も早い）状況下でもSPAは有効だ。クライアントとサーバーのロジックを物理的に別けることで保守性を上げることができるから。さらに分業においては、サーバーサイドを開発する人間、クライアントサイドを開発する人間で、やるべきことに集中できるということが挙げられる。

プログラミングスタイルの変化

SPAの登場によつてプログラミングのスタイルも少なからず変化している。Ajaxなどの非同期処理を行う場合、処理の単位はサーバーサイドの動作と必ずしも一致せず、処理の順番やタイミングもまちまちになる。それらを適切にハンドリングして画面に描画する必要がある。

さらに、ユーザーアクションの開始が、いわゆるPull型（サーバにリクエストするという意味で）だったが、WebRTCやWebSocketsの登場にによって、突発的に開始されるPush型（サーバからクライアントに通知する）可能性もある。

非同期処理の完了であるが JavaScriptではイベント通知で行われる。また、今まではサーバーロジックで行われていた処理をクライアントで行うケースも出てくるので、1つの完結する処理を行う場合、複数回サーバーとやり取りする必要がある。よく「コールバック地獄」ということに陥る。

不規則に発生するイベントを適切にルーティングしつつ、状態を把握し、かつ処理全体を制御する仕組みが必要で、こういった制御を行うために、JavaScriptのライブラリやフレームワークが様々な機能を実装し提供している。

そして、最新のモダンブラウザーがサポートしつつあるECMA Script2015や2016にも、こうした機能が標準で用意されようとしている。つまりイベントのフロー制御方法は

• Promise(ES2015)
• async/await(ES2016)
• Generator/yield(ES2015)

Promiseは非同期処理を抽象化したオブジェクトでPromiseパターンで非同期処理を行う。async/awaitは、Promise とGeneratorの糖衣構文で、そのGenerator/yieldは、反復子 (イテレータ )の生成元で、実行環境を維持したま中断・再開が可能となる。

SPAでは画面のレンダリングも従来のサーバーサイドの処理をメインしたものとは異なる。

SPA以前のサーバーサイドでページが生成されるタイプのWebアプリケーションでは、画面データの成形もサーバーサイドで行われていましたが、SPAではその部分をクライアントサイドで行うことになる。

素直に書くなら、エレメント一つひとつのインスタンスを取得して、各々データをセットする所謂「Glue code」を書く（”グルー”とは糊のこと）ことになる。だが、これだとエレメント変更に関わるUI仕様があるたびにコードまで修正する必要がありメンテナンスが大変だし、いちいちデータを入れるためだけのコードを書くということ自体が非効率。

データバインディング

そこで出てきたのがUIへのデータバインドです。 マークアップにUIとデータの関係を記述しておくと、JavaScriptフレームワークがよしなにデータをセットしてくれるという仕組みです。 こうすることで、データと画面、いわゆる ModelとViewの関係を1:1に紐づけ、構造的には明確に分け部品化することが可能になった。

“バインド”とあるように、ModelとViewの関係を保持します。つまり、モデルもしくはビューに変更が発生した場合、その変更が一方向、あるいは双方向に反映されます。Modelの変更のみかViewに反映されるのが1Wayバインドで、双方向に変更が伝わるのが2Wayバインドです。

まとめるとモダンなWebアプリケーションとは

• SPA
• リアクティブな動作
• M-V-Whatever

少し先のWebアプリケーションの技術的コンセプト

ここからは、ここ数年提唱されているWebアプリケーションの技術的コンセプトについて紹介します。

• Web Components
• Progressive Web Apps
• WebAssembly

Web Components

まずは「Web Components」です。これはWebをコンポーネント化する仕組みで、2013年のGoogle I/Oで紹介された。実は、Webをコンポーネント化するという仕組みは、これが最初ではなく、マイクロソフトも1998年にHTMLコンポーネントというものを提案したし、Mozillaも2001年にXBLと2007年にXBL2というのを提案した。

このコンポーネント化のメリット、目的について

Webのアプリケーションは、他のソフトウェア・アプリケーションと同様に複雑になり、今ではリリース製品の開発に大勢が協力して取り組むことは珍しくなくなった。少しでも効率化を図るには、関係者やシステム間の重複が最小限になるように開発作業を分割する正しい方法を見つけることが重要になる。そのための方法としてコンポーネント化がある。複雑なシステムでも、機能を分割していけば、単純化することができる。全体をある程度の機能単位に分割する、つまりはコンポーネント化だ。

Web Componentsの目標は、HTML、CSS、JavaScriptの関連グループを分離し、単一ページのコンテキスト “内” で共通関数を実行することで、複雑さを軽減することだ。

この Web Components は、複数の API を組み合わせるか、それ単独を使用して実現する。 しかし、すべての Web ブラウザーがその API をサポートしているわけではないので、Polyfill 用のライブラリーが用意されています。

そしてこちらがWeb Componentsを構成する要素です。

• HTML Templates
• Shadow DOM
• Custom Elements
• HTML Imports

現在のサポートの状況はこのようになっています。

※ 既定では動作しない

Progressive Web Apps

これはモバイル Web アプリ向けのコンセプトで、具体的には、高性能のモバイルWebブラウザー向けにネイティブアプリケーションのようなUXを提供しようというも。去年の「Chrome Dev Summit」のキーノートで発表され話題になったものだ。今年の４月に行われた「Google Developers Summit Tokyo 2016」でも2日のテーマになっていたくらい力を入れている。

Progressive Web Appsに求められる体験をまとめると次の様なもの

• ネイティブアプリケーションのようなUX
  • オフラインサポート: Service Worker
  • プッシュ通知: Web Notifications/Push API
  • ホームスクリーンにアイコンの追加: Web App Manifest
  • バックグラウンド: Service Worker
  • 高速でなめらかなインターフェース: CSS3 Animation

Service Workerは、JavaScriptで実装されているローカルのプロキシ、あるいはApplication Cacheの改良版として利用できる。 いままで Web ブラウザーからサーバーにコンテンツをリクエストする場合、サーバーになげてそれを返していたのが、その間にカスタマイズ可能な Service Worker というのが入って バックグラウンドで動いているので、タブを閉じてもブラウザを終了しても動作しているので、プッシュ通知もうけとれるとこと。httpsでしか動作しない。

Progressive Web Appsを実現する技術のサポート状況は

WebAssenbly

WebAssenblyは、コンパイル済みのバイナリをWebブラウザ上で直接動作させる仕組で、Microsoft、Google、Mozilla、Webkitプロジェクトのメンバーで共同開発されていて足並みが揃っている。

JavaScriptよりもポータブルでロード時間や実行に対するパフォーマンスに優れたアプリケーションを作ることが可能だ。asm.jsの次のステップとしている。

2016/3/14〜16の間にMicrosoft、Google、Mozillaの3社が3DゲームAngry botでの検証結果を各ブログで公開している。

WebAssemblyの実装状況は

ハイブリッドアプリケーションとしての利用

Webアプリケーションが苦手とするところは

• ストアのエコシステムを利用しない
• Webブラウザからはどうしてもアクセスできないハードウェアリソース

そしてこれらの Web アプリケーションのは、ハイブリットアプリとしてパッケージすることにより、ターゲットとなるプラットフォームのリソースや、ブラウザーからはアクセスできないハードウェアの機能を使用できるようになる。 また、アプリストアのエコシステムを利用することができる。

Webフロントエンドの開発リソース

インタラクティブなコンテンツを作ることができるようになったので、開発は非常に大変なものになった。

• JavaScript
  • ライブラリ
  • フレームワーク
  • エンジンテンプレート
  • altJS
• CSS
  • フレームワーク
  • プリプロセッサー
• HTML
  • 軽量マークアップ
• パッケージマネージャ
• タスクランナー
• モジュール管理

Richになったことで多くのライブラリが提供された結果「Chaos」になったのか？と思いがち。そして、ライブラリ/フレームワークの選定として考える必要がある。

• ブラウザサポート
• ベンダーサポート
• 情報
  • ドキュメント
  • 書籍類
• 学習コスト
• 開発生産性
• 機能範囲
• ロックイン
• 運用コスト

特にこの中のロックインですが、ロックインは決して悪いものではなく、優秀なベンダーと一緒になってやっていくこと、コミュニティの力を借りることでむしろ良い状況も作れる。運用コストに関しては、便利なんだけどお金がかかるというものについては考えもの。

標準技術は不変

結局、Webブラウザで動作するのは、HTML、CSS、JavaScriptであり、ブラウザがサポートしていない機能は動かない。技術はあくまでも「手段」でり、そうした技術に対する勉強は大事だが、手段であって目的ではない。目的は、ユーザに対して良いプロダクトを提供すること。たとえば、YouTubeはFlashで作られていたが、HTML5に変わったことに気づいた人はいない、そういうものが良い。

そして、WebはApplicationのプラットフォームになる。どんどん低レベルなAPIを実装することになる。結果、デスクトップと同じ様なアプリケーションを作っていける。こうした変貌は「変化」ではなく「拡張」である。