2018年5月に開催された日本マイクロソフト主催のイベントde:code 2018で「進化するWeb ～Progressive Web Appsの実装と応用～」というセッションを担当しました。
イベントに参加できなかった方に向けてセッションの内容を記事にまとめましたので、ぜひご覧ください。
この記事では、昨今話題に上ることが多い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つが挙げられます。
- オフラインサポート
- プッシュ通知
- バックグラウンド処理
- デバイスへのインストール(デバイスのホーム画面から起動できる)
これらはの機能はそれぞれ以下のような新しいAPIによって実現されます。
- オフラインサポート – Cache API
- プッシュ通知 – Push API
- バックグラウンド処理 – Background Sync
- デバイスへのインストール(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イベントが発生します。
var urlsToCache = [
‘/’,
‘/index.html’,
‘/css/index.css’,
‘/script/index.js’
];
//install イベントのハンドラ
Self.addEventListener(‘install‘, function(event) {
event.waitUntil(
//キャッシュを開く
caches.open(‘キャッシュの名前’)
.then(function(cache) {
//アセットのリストをキャッシュに登録
return cache.addAll(urlsToCache);
}));
});
install イベントハンドラ内では、キャッシュを開き
var urlsToCache = [
‘/’,
‘/index.html’,
‘/css/index.css’,
‘/script/index.js’
];
//install イベントのハンドラ
Self.addEventListener(‘install’, function(event) {
event.waitUntil(
//キャッシュを開く
caches.open(‘キャッシュの名前’)
.then(function(cache) {
//アセットのリストをキャッシュに登録
return cache.addAll(urlsToCache);
}));
});
キャッシュにアセットのリストを登録します。
var urlsToCache = [
‘/’,
‘/index.html’,
‘/css/index.css’,
‘/script/index.js’
];
//install イベントのハンドラ
Self.addEventListener(‘install’, function(event) {
event.waitUntil(
//キャッシュを開く
caches.open(‘キャッシュの名前’)
.then(function(cache) {
//アセットのリストをキャッシュに登録
return cache.addAll(urlsToCache);
}));
});
Service Workerが登録され、installイベント内の処理が無事に完了すると、次にactivateイベントが発生します。（もしinstallイベント内の処理が失敗した際にはerrorイベントが発生します）
e.waitUntil(
caches.keys().then(function(keyList) {
return Promise.all(keyList.map(function(key) {
if (key !== ‘キャッシュの名前’) {
return caches.delete(key);
}
}));
})
);
});
installイベント内で”しなければいけない処理”というものは特にないのですが、一般的に古いキャッシュを削除するのに使用されます。このサンプルコードではキャッシュからキーの一覧を取り出し、
e.waitUntil(
caches.keys().then(function(keyList) {
return Promise.all(keyList.map(function(key) {
if (key !== ‘キャッシュの名前’) {
return caches.delete(key);
}
}));
})
);
});
キャッシュの名前（新しく指定された）と比較し、異なるものをすべて削除しています。
e.waitUntil(
caches.keys().then(function(keyList) {
return Promise.all(keyList.map(function(key) {
if (key !== ‘キャッシュの名前’) {
return caches.delete(key)
}
}));;
})
);
});
上記サンプルコードの、”キーの一覧と新しく登録されたキャッシュの名前を比較して異なるものをすべて削除してしまう”、というやり方は少々乱暴かもしれませんので、実際に実装を行う際にはどのようにキャッシュの削除を行うかは十分に考慮してください。
なぜ、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イベントが発生します。
e.respondWith(
caches.match(e.request)
.then(function(response) {
return response || fetch(e.request);
}));
})
fetchイベントハンドラの引数として渡されるオブジェクトに、発生したリクエストが含まれるので、同リクエストがキャッシュ内に存在するのか調べ、
e.respondWith(
caches.match(e.request)
.then(function(response) {
return response || fetch(e.request);
}));
})
キャッシュ内にリクエストが存在すればそれを返し、存在しなければfetchメソッドを使用してネットワークにリクエストを投げます。
e.respondWith(
caches.match(e.request)
.then(function(response) {
return response || fetch(e.request);
}));
})
それぞれの処理結果をリクエスト元のWebコンテンツ側に返します。
e.respondWith(
caches.match(e.request)
.then(function(response {
return response || fetch(e.request);
}));
})
この動作により、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にあるので、そちらを参照することをお勧めしますが、以下に簡単な説明を兼ねたサンプルを掲示します。
“lang”: “ja”, ← 言語
“name”: “The enemy of galaxy”, ← アプリケーションの名前
“short_name”: “T.E.O.G”, ← アプリケーションのショートネーム
“start_url”: “/?utm_source=pwd”, ← 開始するときの URL (※1)
“display”: “standalone”, ← ウィンドウのスタイル
“background_color”: “black”, ← 背景色
“description”: “銀河に平和を取り戻すためのゲームです。”, ← 説明文
“orientation”: “portrait” ← 画面の向き
“icons”: [{ (※2)
“src”: “images/homescreen48.png”, ← 画像ファイルのパス
“sizes”: “48×48”, ← サイズ
“type”: “image/png” ← 画像の種類
}, {
“src”: “images/homescreen72.png”,
“sizes”: “72×72”,
“type”: “image/png”
}]
}
(※1)Google Analytics等を使用しているときはクエリーストリングを使用することでPWAとして起動されたのか、ブラウザからページにアクセスしたのか判断が可能
(※2)iPhoneやiPadでアイコンが反映されない場合は、apple-touch-iconを使用
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ストアで公開されているものを取り消したい場合は、アプリを削除するよう [email protected]宛にサービスリクエストを出します。
セルフパブリッシングによる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にアクセスするためのコードをインターネットでホストされているコンテンツに含めておくことができます。
if(window.Windows){
//セカンダリータイルをピン留めする
tile = new Windows.UI.StartScreen.SecondaryTile(
tileId, text, text, activationArguments,
newTileDesiredSize, logoUri);
}
JavaScriptで記述したUWPから,WinRT APIを使用するサンプルコードは以下に豊富に用意されているので、Windows 10限定となってしまいますが、純粋なProgressive Web Appsの機能だけでは実現できない要件がある場合は、こういった方法もあるということを覚えておくとよいかもしれません。
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を作ってみることをお勧めします。
]]>
日米通算1億ダウンロードで日本最大フリマアプリ「メルカリ」。今回はメルカリの小嶋仁司さん、坂本結衣さんにメルカリのフロントエンドエンジニアたちがどんな技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！
メルカリで重要な役割を果たしているWebView
白石：お二人は、メルカリでどんなお仕事をされているんですか？
小嶋：私は2015年10月に入社して、アプリケーション内のWebViewページの開発を担当してきました。具体的には大規模なトラフィックがある取引画面や、配送サービス「メルカリ便」に新たな運送会社を追加したり、「大型らくらくメルカリ便」の配送機能を拡大したり、集荷サービスなどの開発も行いました。
白石：ビジネス的に重要な部分を作っていらしたんですね。
小嶋：技術としてはいわゆるHTML5、CSS3、JavaScriptを使ったフロントエンドで、WebView内からお客様の取引状況に合わせて、Web画面を出す部分を担当してきました。最近はメルカリのJP Web版（日本向けWebサイト）の開発を進めています。機能開発というよりは流入施策ですね。
▲株式会社メルカリ エンジニアリングマネージャー 小嶋 仁司氏
メルカリ エンジニアリングマネージャー / Frontend。大手Webメディアで働いた後、Flash の表現力に感嘆しフリーランスで Flash Developerとして働く。その後、Flashの衰退とともにHTML/JS/CSSにスイッチし、ゲームの受託開発などを行う。2015年にメルカリに入社。Web/WebView開発に従事。今はPWAに興味津々。
坂本：エンジニアの坂本です。Engineering Operations Teamというチームで、エンジニア全体の組織作りや制度、採用にコミットしています。現在3名（取材当時）いますが、全員エンジニアです。私は特に中途エンジニアの採用や技術広報、そして技術ブランディングを担当しています。もともとサーバーサイドエンジニアで、2014年に入社して去年の12月まではプロダクトに関わっていました。
▲株式会社メルカリ Engineering Operations Team ソフトウェアエンジニア 坂本結衣さん
大学卒業後、流通業で営業職や店舗運営を経験し、Web制作会社に転職。PHPを用いたシステムの実装から、要件定義や設計、またDevOpsによる環境構築、Jenkinsサーバー構築等の開発基盤の構築・管理等を担当。2014年にメルカリに入社。Engineer Operation Teamという、エンジニア組織作り・採用・制度・技術ブランディングを行う部署のメンバーとして活躍中。
白石：メルカリはWebViewをかなり使っているんですか？
小嶋：最近はReactNativeを使ったりしているので、WebView自体は減っている傾向にあります。ただし、ReactNativeもJavaScriptで書くのでフロントエンドの領域だと思っています。WebViewとして特にコアな機能は取引画面ですね。
白石：なるほど。ということは、重要な画面はこれまでWebViewで作ってきたんですね。
小嶋：そうですね。当時からするとホットデプロイできる強みや、Webの技術でデプロイして、クイックに画面が切り替えられるという理由でWebViewが選定されたんだと思います。
白石：それはサーバーサイドに画面を更新すれば反映されるということですか？
小嶋：はい。更新性という意味合いでは大分速くなってきたんですけど、ネイティブはどうしてもiOSで申請があったり、ネイティブのアップデートがあるので…。例えば取引画面で使用している外部の配送サービスが急に一時期使えなくなったときに、ネイティブで何ができるかというとメンテナンスと出すしかなく、お客様はアップデートを待つしかありません。それであれば、Web上だけでクイックに開発できる方が良いという選択だったと思います。例えば、招待ページはWebViewで作られていましたね。
WebViewの全体量としては減っていますが、Web文脈でいうと注目度はかなり高まっています。例えばPWAとか。技術選定の根底にあるのは、お客様の体験だと思っているので、その時その時の状況に適した技術選定ができていればいいと思っています。WebViewをなくしていこうとか、PWA（Progressive Web Apps）だけにしていこうとかではなく、その都度リーチできるものを選べばいいかなと。
白石：パフォーマンスの速さとユーザー体験を重視しているわけですね。
小嶋：会社全体としてもテックカンパニーという点を重視しているので、いち早く最新技術を取り入れるという目的もあると思います。
開発速度を優先すべく、コードベースをリージョンで分割
白石：小嶋さんご自身は、ReactNativeの開発をしているんですか？
小嶋：僕自身は以前はUSプロダクトもやっていましたが、現在はJPプロダクトの担当なので、ReactNativeのプロダクト導入経験はないです。
白石：ちなみに、USプロダクトということは、JPプロダクトとは別にアプリを作っているんですか？
小嶋：はい。コードベースの話をすると、去年の秋くらいに現地での開発速度を優先するという目的で、JPとUSとUKのAPI含め、リージョンを分割したんですね。というのも、日本で開発した機能で、一部USで表示がどうしてもおかしくなってしまうこともありました。そういうことを懸念して、現地のことは現地でオーナーシップを持って開発・運営することにして、分割した経緯があります。
白石：Googleは全世界で一つのコードベースだと言ってますが、御社は分割したほうがいいと判断されているというのは、興味深いですね。
小嶋：ステークホルダーが同じリージョンにないということは、タイムゾーン分だけコストがかかります。例えばUSである機能をさくっと1日で開発してリリースしたいときも、JPに影響がないかを見るためにはQAなど複雑なリレーションが発生します。なので、現地でやっていることは現地のルールを優先しています。
坂本：メルカリは会社のミッションとしても、「世界的なマーケットプレイスを創る」ことを目標としています。最終的に世界中でメルカリを使ってもらいたい。ですが、まずは世界を獲りにいくことが最優先。そのために一番いい選択肢は何かと考えたときにリージョンごとに分けるほうが最適だと判断をしました。
小嶋：全リージョンで、完全に共通のコードベースを持つことは大切なんですけど、必ずしも日本のUIが全世界で最適だとは限らない面もあります。民族性や国土の広さなど、様々な違いがあるし、前提として物を売ったり買ったりするマインドの違いもある。そのときに共通のUIベースで勝負するのは難しいという課題もありますね。
白石：とはいえ、決断にはかなりの覚悟が必要だったんじゃないかと思います。そんなことないですか？
坂本：メルカリのバリューの一つに「Go Bold（大胆にやろう）」があります。経営陣も迷ったと思いますが、かなりスピーディに進めていたと思います。
白石：ちなみに、最近GoogleがWeb PaymentsやShippingの機能をブラウザで共有のUIを提供するらしいという話を聞いたのですが、メルカリさんはどう考えますか？
小嶋：Google Paymentsはかなり親和性はあるんじゃないかと思ってます。Webの可能性という話になるんですけど、決済に関して標準化されたものがあるなら、使っていきたい気持ちはあります。もちろんお客様にとって便利になるかどうかを検討してからになりますが、特にPWAやWebベースでのプラットフォーム化が加速していったときに十分可能性がありますね。
白石：個人的にもPWAにはご興味があるとのことでしたけど、社内ではどうPWAを活用していきたいですか？
小嶋：去年もサンフランシスコで開催された「Chrome Dev Summit」というカンファレンスに参加させてもらったのですが、現地ではトラフィックに弱いインドなどではかなり可能性があると発表されていました。話を戻すとお客様にとっての体験向上という意味で、正しいプラットフォームは何なのかを考えながら、特に細かくどんどん変わっていくべきだと考えています。
僕の個人的な意見ですが、例えば会社がビジネスを選定するときは、端末の保有台数や通信インフラの整備の高さなどを含めて海外進出を考えていくと思うんです。いわゆるネイティブライクな体験がWebベースでもできるように担保されるのであれば、Push Notificationなどもありなんじゃないかと。PWAを一番最初に導入してユーザー数を3倍に増やしたインドのFlipkartのように、インドという巨大な人口を有する国でも戦えるんじゃないかと期待しています。
白石：PWAをやるときはWebViewでやってたコードがまた使えるようになるんですか？
小嶋：それでいうと、PWAのアーキテクチャにも最適解がかなりあって。例えばService Workerのオフラインキャッシュ、ヘッダー部分とかグローバルナビ部分などはきっちりコンテンツ部分とは分けるべきだと思います。
App Shellモデルの概念もあるし、既存のWebで培われているコードべースができるとは思っていないのと、メルカリの課題としてリプレイスとかもあると思っているので、新しいものは新しく作りたいですね。
メルカリの開発体制や、サービスのリプレイスは？
白石：続いては、メルカリの開発体制や、サービスのリプレイスをどう進めていくのかなどについて聞かせてください。
小嶋：フロントエンドの文脈で言うと、一部リプレイスの必要があって、常に現場から上げるようにしています。今進んでいるプロジェクトとバランスを持って進められるように意識しています。
白石：それはメルカリJP Webの話ですか？
小嶋：そこもやりたいのですが、もっと優先度が高いところもあります。なぜ今そこをやるのかというのを説明した上でやるようにしています。Webだけではないかなと思っています。
白石：御社でいうフロントエンドというのは、もうWebに限らない？
小嶋：そうですね。フロントエンドはアプリのWebViewの開発をしている人もいるし、Webの開発をしている人もいるし、USはJavaScriptエンジニアが開発しています。Node.jsなども使われています。領域は広がっています。
白石：小嶋さんがフロントエンドだからあまり話に出てこないのかもしれないのですが、思いっきりネイティブで書かれているところも結構あるんですか？
小嶋：かなりあります。うちは優秀なiOSエンジニア、Androidエンジニアが相当数いるので、ロイヤルティ高くお客様の体験向上のために寄与しています。フロントエンドは現状では更新性の高いところを担当していますね。
白石：さらにメルカリの開発の裏側を知りたいと思うんですが、クラウドやデータベースの話から聞かせてもらってもいいでしょうか。
坂本：サーバーサイドはいろいろな会社のサービスを使っていますね。日本のサーバーサイドがメインで動いているのは、さくらの専用サーバーですし、USではAWSを使っていたり、現在では裏側のドメインごとによるマイクロサービス化の流れがあります。
白石：サーバ―サイドは何を使っているんですか？
坂本：サーバ―サイドで最初からコードべースで一番使っているのは、PHPです。
白石：それ以外の言語も増えているということでしょうか。
坂本：マイクロサービスの文脈の中で基本的にインターフェイスが定義されていれば、中身はなんでもOKです。その中でもいろいろな利点からGoを使っているケースが多いです。
チーム体制は3カ月ごとに適したチームを模索
白石：続いては、チーム作りや開発体制について聞いていこうと思います。先ほどフロントエンドの定義についてお聞きしましたけど、大まかにいうとフロントエンド、iOS、Android、サーバーサイドエンジニアというかんじなんですか？
小嶋：開発体制でいうと、さらにプロダクトマネージャーとデザイナーが入ってきます。いわゆるチームプロダクトという大きなくくりで、プロダクトを推進するためのチームになっています。チーム体制についてはクォーター（四半期）制という3カ月ごとに適したチームを模索しています。
僕の経験でいうと、かなりフレキシブルに動いていて、プロジェクトにプロダクトマネージャー、エンジニア、デザイナーと就くこともあれば、僕はJPフロントエンドという横ぐしのチームで動いています。その時にどういうチームが最適なんだろうと結構模索された上でチームを構成します。3カ月後に同じチームがあるとも限らないし、まったく違うチームでやる人もいるし、ずっと同じチームでやる人もいます。
白石：3カ月ごとに編成されるというのは、大分スピーディですね。ちなみにどう開発しているか、どう開発を進めているかもお聞きしたです。相当UXにはこだわっていると思いますが、事前の調査やテスト、それをどうフィードバックして、どう開発やデザインに反映しているんでしょうか。
小嶋：UXに関しては1年前くらいからユーザービリティテストをかなり活発にやっています。お客様に使ってもらって、ご意見を聞きながら、UI/UXの改善しています。あとはABテスト基盤があるので、プロダクトマネージャーが数値をもとに10%改善に基づいて、数値を見ながら取り組んでいます。常にPDCAが回っているかんじです。
ターゲットや契約している会社があるわけではなく、社員は参加も自由で公募もされています。行きたい人が行ける。全社的にプロダクト志向が高いですね。エンジニアだからプロダクトに意見を言わないという風土はないですね。
白石：クォーターごとにチームが変わっていくというお話ですけど、タスク管理などはどうされているんですか？
小嶋：タスク管理に関してはアトラシアンのJIRAを使っていて、全社的にチケット駆動開発で進んでます。情報管理はOSSのコミッターがいるんですが、CrowiというWikiを使っています。チーム移動したからツールが違うというのはないですね。プロジェクトごとに切っているチームもあります。
開発速度が早いがゆえの課題
白石：現在の課題と自慢できること、今後やりたいことについて聞かせてください。
小嶋：メルカリではクォーターごとにプロジェクトのゴールを設定しているので、開発速度が相当早いんです。さらに新規事業も多い。開発速度が早いとなると、エンジニアとしては、技術的負債を早く返したいと考えます。その辺のバランスを見直そうという動きも出ていますが、開発スピードの早い組織ならではの課題だと考えています。
白石：技術的負債をどうするかという問題ですね。
小嶋：スピードも大事ではあるのですが。
白石：自動テストもきっちり書いているとそれだけで時間がかかったりするから、省略するところもあったりしますよね。
CTOとVo/Eの二頭体制
白石：メルカリ開発チームならではの自慢できることは何ですか?
小嶋：現場が技術選定をある程度任されているところですね。あとは月並みですけど、全社員に開発者端末が支給されるんですね。iOSを使っている人だったらAndroid端末、Androidを使っている人ならiOS端末が入社時に無償で貸与されます。パフォーマンス出せるための備品や、エンジニアが最適だと考えるソフトウェアに対してはかなり優遇されていると思います。
坂本：メルカリは退職者が圧倒的に少ないですね。エンジニアに限らず、会社が成長を続けているので離れていく人が少ないし、 ネガティブなことを考える必要がない。プロダクトに集中できるし、今の環境をよくすることに注力できます。
またCTOとVP of Engineerがそれぞれ1名いて、技術的なトップと開発チームのマネジメントのトップが分かれているので、バランスがとれていると思います。CTOが開発体制に入り込んでしまうと、技術的な進歩に貢献することに時間がさけなくなってしまう恐れがありますが、そういうことがありません。
圧倒的に会社の技術を引っ張るという意味で、会社全体を先導しているという姿勢を見せてくれている。リアルな開発現場はVP of Engineerがコミットしてくれている体制があるので、エンジニアたちはよけいなことに時間を使わずに本質的なことにフォーカスできる環境だと思います
白石：CTOがこうだと言っても、現場が異議を唱えることはないんですか？
小嶋：トップダウンというより、どちらかといえば方向性を提示した上でテック寄りな人たちでデスカッションしている。距離が近いので、導入するにしてもしないにしても議論が頻繁に行われています。
白石：現場とトップの距離が近いとのことですが、CTOとのコミュニケーションもフラットにできるということですか？
小嶋：そうですね。かなりオープンな文化なので、CTOと1on1したいときも自由に設定できます。「必ずマネージャーを通すように」などの文化はないです。それから、メルカリでは3カ月に一回、Be Professional Dayという、普段はできないことをやろうという取り組みがあり、誰が何を開発してもいいことになっています。
前回はオートメーションというテーマを設けて箱根で開発合宿をしたのですが、CTOも来てくれて、いろいろアドバイスしてくれました。関係性としてはフラットなのかなって思います。
白石：エンジニアにとってはいい開発環境とチーム体制ですね。これからのメルカリにも期待しています！今日はいろいろ面白い話をありがとうございました。
▲メルカリのバリュー「Go Bold」グッズがたくさん！
HTML5 Experts.jp編集部の馬場です。
いよいよ2020年度から小学校でプログラミング教育が必修化されますね。
今回の「Webの未来を語ろう2018」は「プログラミング教育」がテーマです。
HTML5 Experts.jpの白石編集長をモデレーターに、プログラミング教育の最前線で活躍中の、みんなのコード利根川裕太さん、ライフイズテック水野雄介さん、日本マイクロソフト春日井良隆さんをお招きし、プログラミング教育の現状からプログラミング教育必修化の課題、その先に目指す未来について語っていただきました。
今回のゲストプロフィール
ライフイズテック株式会社 代表取締役CEO 水野 雄介さん
1982年生まれ。慶応義塾大学理工学部物理情報工学科、同大学院在学中に、開成高等学校物理非常勤講師を2年間勤める。卒業後、人材系コンサルティング会社に入社。教育変革を掲げ、退社後、2010年7月、ピスチャー株式会社（現ライフイズテック株式会社）設立。シリコンバレーIT教育法をモチーフとした中高生向けIT教育プログラム「Life is Tech!」を立ち上げる。現在延べ15000名の中高生がLife is Tech !に参加。
NPO法人みんなのコード 代表 利根川 裕太さん
一般社団法人みんなのコード代表。慶應義塾大学経済学部卒業後不動産デベロッパーへの勤務を経て2011年よりラクスル株式会社に立ち上げより参画。2014年Hour of Codeのボランティア実施後プログラミング教育の必要性を感じ、2015年7月一般社団法人みんなのコードを設立し代表理事に就任。2016年、文部科学省「小学校段階における論理的思考力や創造性、問題解決能力等の育成とプログラミング教育に関する有識者会議」委員。
日本マイクロソフト株式会社 プロダクトマネージャ 春日井 良隆さん
岐阜大学 教育学部を卒業後、大沢商会、アドビ システムズを経て、マイクロソフトに入社し、ExpressionとSilverlightのマーケティング戦略を担当する。その後、エバンジェリストとして、ユーザーエクスペリエンスやHTML5、プログラミング教育の普及に奔走し、Imagine CupやHour of Codeの日本での活動を主導する。2015年よりWindowsのプロダクトマネージャーとしてコンシューマ市場を、2017年より教育市場を担当。
プログラミング教育のこれまでの取り組み
白石：まずは皆さんの自己紹介と、プログラミング教育との関わりについてお聞かせください。
水野：ライフイズテック水野です。これまでプログラミング教育は重要だと言われながら、社会がなかなかついていけてなかった。プログラミングスキルは「やりたい」「好き」という気持ちがないと伸びないと考え、7年半前に中高生向けIT教育プログラム「Life is Tech!」を立ち上げました。
「Life is Tech!」は春夏冬休み中に、3～8日間のキャンプ形式でiPhoneアプリやゲームを作りながらプログラミングを学びます。1回150～200人の中高生が参加し、5～6人が1チームになり、大学生がメンターとなって中高生に教えています。これまで延べ27,000人が参加しており、世界2位の規模となりました。
Life is Tech!では、ただプログラミングのスキルをつけるだけでなく、好きな仲間と出会ったり、尊敬する大学生のメンターに学ぶことでこんな先輩になりたいと思ったり、夢中になれることを見つける体験をしてほしいので、大学や企業など、中高生にとって非日常な空間でキャンプするということを大事にしています。
▲「Life is Tech!」キャンプの様子
有料コースと無料コースがありますが、全体の1/3が無料体験会や企業とのタイアップキャンプの参加者です。最近はIoTをテーマに開催したり、NHKさんとAIを学んだりしています。ポケモンGOやUnityのコースも人気があります。参加者には勉強時間はLINEが使えなくなったり、ライバルが勉強し出すと通知が来る機能など、独創的な発想で作った勉強管理のアプリを作り、ダウンロード数が10万超えした子もいます。
子どもたちにはいつもプログラミングの力で「半径2mの世界を自分たちで変えていこう」、さらに「その半径を広げていこう」と伝えています。
▲ライフイズテック株式会社 代表取締役CEO 水野 雄介さん
利根川：僕は大学卒業後、大手の不動産会社に就職し、2011年にラクスルというベンチャーに社長の次にエンジニアとして入って、立ち上げから携わりました。それから4年経った2014年くらいに、エンジニアと非エンジニアの壁をなんとなく感じていたこともあり、アメリカの非営利活動法人Code.orgが展開している「Hour of Code」をみんなでやってみたんですね。
それをきっかけに、こうしたプログラミング教育が日本にも必要だと思うようになり、2015年1月に小学生のプログラミング教育を支援する活動準備を始めました。7月にはCode.orgの日本パートナーとなる一般社団法人みんなのコードを設立しました。
当時はプログラミング教育がこんなに盛り上がるとは思っていませんでしたが、2020年から必修化も決まり、行政・企業との連携を深めながらプログラミング教育の支援活動を広げています。
私たちみんなのコードは、「全ての子どもがプログラミングを楽しむ国にする」というミッションを掲げています。なぜ、全ての子どもなのかというと、プログラミングコンテストはある程度できる子を伸ばすのにはいいけど、全ての子どもの育成に対する取り組みってあまりないと思ったから。なので、裾野を広げるほうを頑張ろうというコンセプトでやってます。
IT人材不足や論理的思考を鍛えるという考え方も大事ではあるんですが、実際に授業でやるときは「プログラミングを楽しむ」というのを第一にして、結果的に子どもの能力が高まるとか、社会で活躍できる人材を育てたいと考えたからです。
「国にする」とした背景は、こういう活動って東京だけ先に進んでしまって、地方との格差が生まれることが多いんですよね。その差を埋めるために地方でも活動しています。とはいえ、全ての子どもに直接教えるのは無理なので学校の先生、特に小学校の先生に対しての指導を行っています。プログラミング教育についてのシンポジウムを開催したり、地方に出向いて体系的に学んでもらったり、実際の授業で使える教材を提供したりなどですね。2017年度のシンポジウムは10都市1000名超の先生に参加してもらいました。これからはさらに拡大していく予定です。
▲一般社団法人みんなのコード 代表 利根川 裕太さん
春日井：日本マイクロソフトの春日井です。Windowsのマーケティング担当として、教育市場を見ています。HTML5 Experts.jpのエキスパートに名前を連ねているように、以前はWeb系の技術のエバンジェリストをしていたのですが、後半は学生向けのエバンジェリズム活動も兼任していて、その頃に知り合ったのが水野さん。
「Life is Tech!」は大学生が中高生を教えるというスタイルで、お互いの年齢が近いから親近感があるんですよね。子どもたちを盛り上げる趣向が凝らされていて「すごい！」って毎回感動しています。しかも、経験と知見が積み重なり、どんどんバージョンアップしてる。
利根川さんとは、彼がCode.orgの日本パートナーとして、みんなのコードを立ち上げた頃に知り合いました。Code.orgはアメリカのSTEM教育（※）の普及を支援するNPO団体で、Microsoft、Apple、Google、Facebook、AWSなど大手のIT系企業が数多くサポートしています。
STEM（ステム）教育：科学（Science）、技術（Technology）、工学（Engineering）、数学（Mathematics）の教育分野を総称する、2000年代に米国で始まった教育モデル。
Microsoftは「Microsoft MakeCode」というMicrosoftが開発した学習者向けのプログラミング環境とコンピューティング教育用教材を展開しています。最近はIoTを活かしたフィジカルコンピューティングが人気で、micro:bitというマイコンと連携できる「MakeCode micro:bit」が注目されています。USBでつないだmicro:bitをビジュアルコーディングでLEDを光らせたり、温度センサーや加速度センサーを使ったモノ作りにも使えます。理科や技術なんかの教科との組み合わせの相性もいいですよね。
ほかにも、MakeCodeはMinecraft（マインクラフト）をプログラミング教材として使うこともできて、一緒に組み合わせる「Minecraft Education Edition」というマイクラの教育版があります。Minecraftは全世界の子どもがほぼ100％やっている人気のサンドボックスゲームですね。
水野：シンガポールでも大人気で、どこのコンビニでも一番目立つ場所に置いてあります。
白石：うちの小4の息子もすごくはまっていますね。いつもYouTubeの実況を見てます(笑)。
春日井：YouTubeを見て勉強する子も多いみたいですね。古い世代は先生からの一方的な詰込み型の教育が当たり前だったんですが、お互い子ども同士が学び合おうという協働学習の学習効果に注目が集まっていて、Minecraft: Education Editionにはそんなこともできるように工夫されています。
先生が黒板に「ここに集合！」と書いたり、仮想世界にいる子どもをガイダンスしたりする機能もあって、お値段もお手頃。先生が一人、1年あたり544円払えば使うことができます。
実績としておもしろいのは、立命館小学校の事例ですね。京都には、たくさんの観光施設があることはご存じの通りですが、海外の人にもっと知ってもらおうという課題を解決する学習にMinecraft: Education Editionが使われました。
ちゃんと設計図を手に入れて、誰が屋根と庭とかを作るかなどの業務分担をし、訪れた人のアングルまで徹底的に考え、議論しながら作っています。先生はあくまで手助けするだけで、子どもたちが主体的に取り組んでいるところが素晴らしいんです。
Minecraft Education Editionはプログラミング教育だけでなく、STEM教育全般をやろうとしています。例えば、私たちの世代だと元素記号を覚えるだけだったものが、仮想空間の中で水素と酸素を合成すると水を生成するようなことを体験したりします。現CEOのサティア・ナデラの理解もあり、マイクロソフトでは全世界的にかなり教育に力を入れていますね。
▲日本マイクロソフト株式会社 Windows プロダクトマネージャ 春日井 良隆さん
白石：子どものプログラミング教育を支援するのは、Microsoftにとってどういうメリットがあるんですか？
春日井：1つは社会的な責任ですね。。第4次産業革命に向けた人材育成を引き合いに出すまでもなく、ICTのスキルを持った人材の育成は急務です。日本のマイクロソフトの人間として、日本の将来に貢献をしたい。それは、偽らざる気持ちです。
商売的な話をすれば、子どもの頃からWindowsに慣れ親しめば、大人になったらSurfaceを買ってくれるだろうという期待もあります(笑)。あとはスマートフォンに対する、パソコンの意義というのも伝えていきたいと考えています。
世界のプログラミング教育はどうなっている？
白石：続いては、世界のプログラミング教育どうなっているかについて伺いたいと思います。1月にロンドンで開催された「BETT」という教育イベント、皆さん行かれてるんですよね？
利根川：私も行ってきました。
春日井：BETTは世界で一番大きい教育系のイベントで、国を挙げてブース出しているところが多く、今年の韓国は大きかったですね。でも、日本はブース出してないんですよ。遅れをとるのではないかとかなり心配しています。
利根川：僕は課題はあるけど、単純に「遅れててやばい」という論調は一面的過ぎると思っています。例えば、グローバルでもプライベートの塾はまだあまりないし、日本の小学校でも先進的な取り組みをやっている先生もいます。
春日井：正確に言うと、プログラミングができる最先端の人材を生み出す高等教育に対する取り組みが遅れているんじゃないかと思っています。
水野：そもそもプログラミング教育の前に、まずパソコンが扱えて、パソコンでものが作れることが必要なんですが、Wifiやパソコンの設備が整っていないですね。以前シンガポールに住んでいたんですが、向こうもそれほど進んでいるわけでもなくて、やはり（プログラミングができる）先生が少ない。
英語は「できない」というマイナスの状態から、「できる」というゼロにすることだけど、プログラミングはゼロをプラスにする学びなので、ほぼ横一線。日本はものを丁寧に作るとか、ソフト面では勝っているので、まだ可能性はあると思います。
利根川：僕も横と比較して嘆くより、これからどれだけ良くしていくかの方が重要で、先に進んでるところからどうやれば前に進めるのかを学べばいいんじゃないかと。アメリカが進んでたらそこからカリキュラムを学べばいいし、悲観する必要はないと思います。
▲HTML5 Experts.jp編集長 白石俊平
白石：ちなみにどこの国が進んでるところかありますか？
利根川：アメリカは進んでますね。あとはイスラエル、イギリス。特にイングランドはコンピューティングという教科があり、小中高と授業があります。時間枠、教科書、センター式みたいな試験もあって枠組みや体制が整っています。
春日井：ちょっと前に話題になった内閣府では、諸外国の若者と比較すると、日本の中学生のスマホの所有率はあまり変わらないのですが、パソコン所有率はかなり少ないという結果になっていました。
水野：普通に向こうは小学3年生からiMovieから動画作ったりしますからね。Googleドライブで宿題出したり、リテラシーの差はかなり大きい。
白石：今の子どもたちはPCがなくてもタブレットやスマホでやっちゃうことが多いですよね。
利根川：コンテンツの消費側はそれでもいいけど、制作する側になるとまだ本格的なところはPCでないとつらいと思います。
春日井：消費は間違いなくスマホ。でも何かクリエイトする時は、PC、キーボード、大きな画面がないと難しい。
白石：ではそういう話やデータから考えると、作る力は育っていかない可能性がありますか？
春日井：なんとかしないといけないですね。
利根川：個人の家庭、学校によっても差が出てくる面もあります。
白石：そういう課題が浮き彫りになり、未来に進んでいかなくてはいけないという話になってきたので、プログラミング教育のこれからの話に進みましょう。
プログラミング教育のこれから
白石：プログラミングの義務教育化の話が出ましたが、ざっくばらんにお聞きしたい。調べたところ「コーディングを覚えることが目的ではない」とか「プログラミング的思考」が大事とか、賛否両論あるらしいですね。アンプラグドコンピュータサイエンスというパワーワードもあったりして。
利根川：よくプログラミングが2020年から必修化になるってメディアに出てるので勘違いする方もいるのですが、正確にいうと小学校、中学校、高校がプログラミングを教えないといけないんですよと指導要領は出ますが、プログラミングという教科ができたり、コードの書き方そのものの授業をやるわけではないのです。その指導要領は10年に一回しか変わらなくて、そのタイミングが小学校が2020年、中学校が2021年、高校が2022年になります。
現状どのくらいプログラミングを授業に取り入れているかというと、小学校についてはほぼなくて、たまに面白いことをやりたい学校や、2020年を見据えて先行的にやる学校がまれにあるくらい。中学校は今の指導要領でも技術課程の中で、4～8時間くらいロボット制御の計測という授業があります。ただこれも問題が山積みで、教科書には入ってはいるけど、ちゃんとやらない先生もいます。
高校は情報という教科の中に、理系よりの「情報の科学」と文系よりの「社会と情報」という科目があり、プログラミングは情報の科学の中にのみ入っています。ただし、学校ごとに開設科目は決まっていて、配分は15％：85％と情報の科学が少ないという状況です。
水野：そうですね。その15％もかなり初歩的な内容が多く、僕が衝撃を受けたのは、テストの問題で「キーボードのここはAですか？Pですか？」って問題が出てたこと。キーボードの位置を覚えることに価値はないし、問題山積みな状況です。
利根川：そして、小学校は算数とか理科の中で、多角形をプログラミングで書いてみる。書くというより、プログラミング体験してコンピュータに指示する感覚をつかみましょうというかんじですね。中学校は今の指導要領にあるロボット等の制御の内容に加えて、ネットワークを使った活動が増えて、今やっていることを倍増にするイメージです。
高校は「社会と情報」と「情報の科学」を統合して情報の科学よりの「情報Ⅰ」という必履修にして、これまで15％しかやってなかったことを100％にして、教科の中に入っていくといったかんじです。プログラミングという単独の教科はありません。
白石：小中高とプログラミングという教科は出てこないと。小学校においては、現在技術課程でやっているのを2020年以降は理科とか算数で、もうちょっと厚めにやるということでしょうか？
利根川：小学校は現時点ではゼロです。ゼロの状態から算数・理科の科目で体験というかたちでやります。ただ、一斉に始められるものでもないので、去年くらいからトライアルが始まっているというかんじです。
白石：まず授業ができるのかが気になりますね。教える科目・内容は学校や先生任せだということですがそこは変わるんですか？
利根川：最低限の基準はありますが、そこは変わらないですね。
春日井：一応教育委員会の皆さんも、変えようとはしていますけどね。
白石：学習指導要領とかって全然わからないんですけど、一応ほかの理科、算数、社会などはここまでやろうよというのは決まっている？
春日井：ざっくりしたガイダンスとかは決まってますね。
白石：たとえば高校3年生の数Ⅲとかだったら微分積分といったところまではやろうとか。
利根川：そういうのは決まってますね。小学校も算数・理科は教科書には書かれるので、多角形を書くのをプログラミングでやってみましょうとか。
白石：でも今の話だと、教科書の内容もバラバラかもしれないと。
利根川：中学校の技術課程くらいになると、あまり教科書は使われなくなるんですよね。副教材中心で、教科書は参考書くらいの扱いになっていくと思います。
白石：「プログラミング教育はコーディングを覚えることが目的ではない」といった内容がブログで書かれて話題になってましたが、どう感じてますか？
利根川：文科省としては、小学校段階からちゃんとプログラミングそのものを学習のターゲットにしようとしています。しかし小学校は全国で2万校あって、40万人の先生がいますが、そのほとんどの先生がITリテラシーが高いわけではありません。その状況から数年でプログラミングを教える環境にするのは無理なんですよね。
春日井：僕が小学生の時は書道やそろばんの塾や、授業で音楽・体育・技術とかやりましたけど、みんな音楽家や書道家になるわけじゃなくて、教養として必要だからやるというかんじでしたよね。
中には体育の授業でスケートを知って、冬季オリンピックを目指すことを決意した子もいるかも知れない。プログラミングもこれから必要になる教養、あるいは未来の可能性をひらくきっかけだと思っています。
利根川：例えば環境問題って家庭科でも理科でも社会科でも、ごみ処理や温暖化などについてはいろんな教科をかいつまんで学ぼうというのは、少しでも興味を持ってもらうために文科省がよくやるやり方です。個人的にはもっとちゃんとやってほしいという思いはありますが、現実的な第一歩としてはしかたがないかもしれません。
白石：でも、そのまま10年間変わらないというのは問題なのでは？
利根川：そうなんです。そこが問題なんですよね。
白石：IT人材を増やすという直接的な影響にはならなさそうですか？
春日井：いわゆる第四次産業革命の人材を育てると国が打ち上げたので、そこに合わせて一つの指導要項が組まれたという背景はありますね。
利根川：文部科学省・経済産業省・総務省、それぞれ動きはかなり違いますね。学校の授業の中で何を教えるのかは文部科学省、総務省は学外や部活や地域であったり、基礎スキルがある人をどうやって伸ばしていくか。経産省はグローバルに発展させるための人材の輩出だったり、このEduTechというものを産業にしていこうとか。文科省だけにとどまらない動きがあります。
学校教育、特に小学校中学校は職業教育じゃなくていろんなチャンスに気づくための機会。30～40代はプログラミングに触れたことがあるのは10％いるかいないかなんですが、この世代になると100％になるんですよね。やってみたら面白いとか伸びそうという子どもの母数が増えて、未来の仕事につながればいい。学校教育としては、そうした体験をしてもらう機会を作るというのが責務になります。
Life is Tech !のような塾・クラブ活動、CoderDojo（コーダー道場）みたいなコミュニティは、よりプログラミングをやりたいという子を伸ばすところ。学校教育にプロフェッショナルな体験を期待しすぎるのはちょっと筋が違います。
ただ政府としては第四次産業革命というムーブメントを起こし、この国をAIやIoTといったテクノロジーの力で、もう一度元気にしようという動きがあります。プログラミング必修化になったのも、ある種内閣内のバズワード、必修化するときの体制を第四次産業革命に生かすため。これらの取り組みで興味が出てきた子のスキルを伸ばし、価値を提供する側に育成するという動きが経産省でも出ています。
社会はどう変わる？子どもたちにはどう教えればいい？
白石：最後は社会がどう変わるか、子どもたちにどう教えればいいんだろうというテーマについてお聞きしたいと思います。どうやったら楽しく効率よく教えることができるのでしょうか。
春日井：白石さんは、今お子さんに何かやらせてるんですか？
白石：うちの小4の息子はHour of Codeから始めました。でもHour of Codeはわりとさくさくできちゃって、次にスクラッチやらせてみたんですが、UIがイマイチいけてないかんじがして…（苦笑）。あとは「プログラミン」をずっとやってました。
最近はビジュアルプログラミング言語で、Minecraftを題材にPythonを教えてました。でも、その辺りから興味が失ってきちゃって。原因はいろいろあると思うのですが、まずプログラミングは多少英語を知ってないとできないんですよね。
例えば、英語でimportと言われてもまったく意味がわからない。すべてがおまじない。コマンドラインをたたかなくてはいけないんですが、そういう単調作業が面倒くさくなってしまってる。親が「やりなよ～」と言うと、逆に嫌になっちゃってる状況なんです。
利根川：そもそも白石さんの「教えよう」というのは、あまり筋がよくない気がします(笑)。基本的に「やりたい」と思ったときに、すっと出す方がいい。いわゆる従来の勉強が嫌いになるのと同じことをプログラミングでもやろうとしている。それであれば教えないほうがよくて、興味を持ったときに教えてあげたほうがいい。特に家庭では子どもに押し付けるとよいことがない気がします。
水野：10歳以上になってくるとだんだん自我が芽生えてくるので、まずお父さんやお母さんがめちゃくちゃ楽しそうにやってることに食いつくんですね。それができないとしたら、僕はコミュニティだと思います。楽しく効率的に学べるかはコミュニティ。
子どもはその場の雰囲気やそこにいる人たちと学ぶことが楽しいとか、ライバルに負けたくないとか、コミュニティに所属することによって子どもたちは成長する。10歳以上になって自分たちが教えられないのなら、自我に任せつつ、そういうところに行かせたほうが伸びると思います。
春日井：でも、白石さんみたいにPython書けるお父さんがいる家庭はなかなかないですよね。
白石：子どもたちも楽しくやってたし、最初はやりたがってたんですけど、そこをどううまく育てていけばいいのかなって考えちゃうんですよね。
水野：英語もそうですよね。5歳くらいのときは楽しかったけど、親が話せなくなると、だんだん楽しくなくなってくる。例えばインターナショナルスクールに行って友だちと毎日楽しく話していると、話せるようになるのと同じことだと思います。
白石：ライフイズテックさんは子どもが「プログラミングをやりたい」って、参加するんですか？それとも親が「やってみたら？」と勧めて参加させてるかんじなんですか？
水野：基本的には子どもたちが「やりたい」と言って参加してきてくれます。僕ら教育者の仕事は、子どもがやりたいって思ってくれるようなものを作る、HPの作りもそうだし、チラシもそうです。オリンピックで飛んでたドローンやPerfumeのプロジェクトマッピングみたいに、子どもたちに作ってみたいと思わせる欲求や、キャンプに参加してみたいというワクワク感を出させることが教育者側のやるべきことだと考えています。
白石：それは子どもたちに直接アプローチしないと、Life is Tech!のキャンプの情報は伝わらないと思うんですが、どうやってるんですか？親とかならいろんなメディアを見ていると思うんですけど。
水野：学校でのクチコミや、友だちの紹介が多いです。先生も自分たちでは教えられないからと、学校単位でキャンプをやったりとか。マイクロソフトさんで、品川女子学院と聖光学院でコラボキャンプをやったこともあります。
親としてはマイクロソフトを見に行けるし、品女の子は共学の雰囲気を楽しめる。きっかけは何でも、結果的に興味を持ってくれればいいんですよね。
春日井：マイクロソフトがMinecraftを教育用にカスタマイズしようとしたのはまさにそれで、子どもたちは興味を持たないとやらない。子どもはMinecraftが大好きなので、だったら教材にしましょうと。Excelでマクロ組んでみましょうっていう授業だったら、楽しくない。
白石：でも、Education Editionは先生しか使えないとのことですが、一般家庭でやるにはどうしたらいいですか。
春日井：最近は教育機関じゃないところでもできるようになってきました。ただMinecraftをパソコンで使う場合、Java版とWindows 10 Editionの2パターンあるんですね。
白石：うちの息子はJava版ですね。
春日井：Pokect Editionは、どんどん、Java版に近づいているのですが、その、Pocket EditionのWindows10版を「Minecraft Windows10 Edition」と言います。Windows10のストアから3,150円でダウンロードできるんですが、これは最初にお話したMakeCodeとつなげられるようになっています。Code Connectionという無償のツールをインストールするだけなので、ぜひやってみて下さい。大人がやっても楽しいですよ。
白石：みんなのコードでは、プログラミング教材「プログル」というツールを作られているんですよね。
利根川：プログルは小学校の算数の授業、主に小学校5年生を対象に、学校の先生が使うために作ったプログラミング教材です。多いときだと1日1000人くらいの児童が使ってくれていて、従来の多角形の学習よりは楽しいと思います。
白石：2020年以降はが爆発的に全国の小学校で使われると。
利根川：そうなるといいですね。うちでプログラミングをやるとしたら、スクラッチとかマイクラのほうが楽しいと思いますけど(笑)。
先生がちゃんと自分が楽しいと思って授業やクラブ、学校外でもやってくれればいいなと。プログルのホームページも学校の先生向けに作っています。
白石：最後に本日のディスカッションを振り返って、ひと言お願いします。
春日井：子どもの頃にピアノを習って、その後ピアノを弾くことが喜びになる人、音楽を聴くことが喜びになる人、音楽に全く興味が持てなかった人など、人それぞれだと思います。いずれにしろピアノを習うという体験をしなかったらわからなかったことですよね。
これからの社会を考えると、プログラミングもそういった機会が与えられるチャンスが増えていくと考えています。そのための支援や活動を続けていきたいと考えています。
利根川：プログラミングを勉強することで、将来ITで価値を提供する仕事に就いたり、営業やマーケッターの仕事でも少し役立てることがあると思います。でも大事なのは、やってみて合うか、合わないと知ること。やったけど自分には合わないというのを早めに知ることはメリットになります。
一方で懸念しているのは、テクノロジーで豊かになっていく東京と、そうでない地方に国が分断されていくんじゃないかという危機感があります。そうならないように、テクノロジーの教育の場を全国に広めていきたいですね。
水野：ライフイズテックは「テクノロジーを知っている」ということを普及させるために活動していますが、プログラミング教育の本質というのはクリエイティビティを伸ばすことだと考えています。業務を効率化させたり、論理的思考を身に付けたり、テクノロジーを進化させるためのツールを作るにもクリエイティビティが必要です。
クリエイティブ力を伸ばすための教育や施策は今後ますます重要になっていきます。本質となるクリエイティビティやコミュニケーションを大事にしながらやっていきたいと思います。
]]>Progressive Web Appsというワードが世に出て約2年半が経ちました。2015年10月に開催されたChrome Dev SummitにてFlipkartの事例をもってお披露目となったそのコンセプトは、2018年現在までに徐々に成功事例を増やしながらWeb界隈の注目を集め、ついに先日（忘れもしない2018年3月30日！）iOS 11.3からiOSデバイスでも一部の機能が利用できるようになるまで成長しました。これは、まるで進学する我が子を見ているかのような、新年度にふさわしい晴れやかなニュースですし、いい機会なので PWAとは何かを改めて振り返ってみようと思います。
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を恐れるときは正しく恐れるべきだと言っておきたいです。
白石：ただしく恐れろということですね。辻さんに大きな拍手をもって終わりにしたいと思います。ありがとうございました！
]]>こんにちは、dotstudioのちゃんとくです。HTML5Experts.jpでは、昨年に引き続き新春企画として「Webの未来を語ろう 2018」を開催することになりました！
ブラウザ編に続く第2弾の今回は、2017年初頭のHoloLens発売に始まり、ARKit/ARCoreとスマートフォン対応の拡充、各地にVR Zone誕生と話題を集め、一挙にホットトピック入りしたxR技術の現在と未来について。各領域のプロフェッショナルを招き、編集長の白石氏をMCに、さまざまな立場から意見交換を行っていただきました。
広がるxR領域の現状と課題、そして未来への期待について、なかなか聞けない学会話や開発事情など、たっぷりとお楽しみください！
ゲスト紹介
諸星 一行氏（いっこう氏）
Mercari, Inc. R4D
株式会社メルカリの研究開発組織”R4D”でVR/AR/MR領域を担当するリサーチエンジニア。
業務の傍らで”xR Tech Tokyo”や”例のハッカソン”といった勉強会やハッカソンなどのコミュニティ運営を行なっている。日本バーチャルリアリティ学会認定VR技術者。
前本 知志氏
株式会社ホロラボ / システムフレンド Co-founder（取締られ役 兼 取締役）
数年前よりモーションセンサーの面白さに取りつかれKINECTを趣味で触り始め、会社にXRや医療機器開発のチームができる。
センサー系飲み会コミュニティTMCNや、HoloLensに特化した株式会社ホロラボの立ち上げメンバー。
米国MicrosoftよりMixedReality分野のMVPとして認められている。
千葉 慎二氏
日本マイクロソフト株式会社
ハドソン中央研究所でゲームのベースシステム等を開発後、Microsoftに転職。ゲーム機向けWindows OSやXbox SDKの開発などを行う。
近年はKinect、HoloLensといった新技術を啓蒙し、研究者や学生向けの支援活動を担当。
2017年に印象に残ったxR領域のトピックは？
白石: 皆さま、本日はお集まりいただきありがとうございます！まずは簡単に自己紹介と、2017年のxR界隈で1番印象に残ったことを教えてください。
いっこう: こんにちは、メルカリのいっこうです。2017年のホットトピックは、MicrosoftがxR領域に本腰を入れてきたことですね。HoloLens、immersiveと、デバイスをいろいろと出してきたのが衝撃的でした。
前本: 株式会社システムフレンドや株式会社ホロラボで取り締まられ役をしている前本です。僕にとっても、HoloLensが発売されたことは大きな出来事でした。HoloLensが出たから、ホロラボという会社もHoloMagiciansというコミュニティもできましたし。HoloMagiciansでのHoloLens日本発売直後のイベントで、80人もの購入者が一同に集まってみんなで繋げたワクワク感はすごかったです。
白石: 80人×約30万……2400万円……。お金の話になるとすぐ計算しちゃう（笑）。
▲ 発売からわずか2週間後に80人が集ったHoloMagiciansミートアップ
千葉: Microsoftの千葉です。もともとはハドソンというゲーム会社でゲームの根底となる部分のシステム開発をしていて、Microsoftに転職してからは16年くらいずっとXboxチームにいました。HoloLensはKinectから派生してできたところがあって、Xboxチームでは一部Kinectの開発にも携わっていたので私がHoloLensのプロトタイプを見たのは実はかなり前のことなんですよね。その頃から開発を続けて、ようやく世に出てきたな、という感覚です。
▲ Xboxをローンチした人にだけ配られるというジャンパーを着た千葉氏
前本: 千葉さんのことはKinect時代から尊敬しているんですよ！僕は当時からKinectで遊んでいて、それがどんどん進化してHoloLensの形になるのを目の当たりにして、感動です。
千葉: お二人がHoloLensをトピックに挙げてくださったように、私にとっては多くの人にHoloLensを使っていただいているということが2017年最も印象深いことです。それとMicrosoftに勤めながら、東京女子医科大学で学生としてHoloLensを使った医療の研究をしています。業務でも研究でもHoloLensを使っています。
白石: えーっ、じゃあ千葉さんは女子大生？周りは女子ばっかりですか？
千葉: 私がいるのは大学院なので、おじさんばかりですよ（笑）。
白石: ちなみに私はHTML5Experts.jpの編集長と、TechFeedというエンジニア向けのキュレーションサイトを作っています。私自身はWeb領域の人間でxRについては素人なので、今日はバンバン質問させていただきます！
VR/AR/MRとは何か？デモで見る各領域の現在
現実と仮想が複合するMRの世界観
白石: 2017年のホットトピックはお三方とも「HoloLens」に関することで一致しましたね。まずはMRについて、現在の様子を伺っていきたいと思います。
千葉: まず伺ってみたいんですが、「Mixed Reality（MR）」という言葉について正しく理解している自信があるという方？
（会場、手が挙がらない）
千葉: なかなかいないですよね。それが一つ、現状の課題なんです。簡単に言うと、MRは現実の世界と仮想の世界が融合しているという形です。どう融合するかにも、現実世界の中に仮想世界を入れ込むとか、逆に仮想世界に現実世界を入れ込むとか、いろいろな考え方があります。MRは、テレビの中に入り込んで、仮想のつくられた世界を見渡すことができ、そこから現実の世界も覗くことができる、というような考え方です。
白石: 仮想と現実がMixする、という意味合いなんですね。HoloLensのデモでは、現実世界をキャラクターが動いたり、現実の壁を割っていたり、というのを見ますが、それはどちらなんですか？
前本: その捉え方は宗教論争に近いものがあるんですよ。
いっこう: Microsoftさんの提唱するMRと、もともと日本バーチャルリアリティ学会が学問として20年以上研究している考え方とで違う部分があるんです「VimかEmacsか」という話に近いです（笑）。
白石: あー、よくわかりました。それは大変だ（笑）。どういう部分でお互いに違うなと思っているんですか？
千葉: デバイスを主体で見るか、現実世界を主体で見るかなど……考え方の違いですね。揉めているわけではなく、「そういう考え方もあるよね」という感じなんですが。
白石: なるほど。話の抽象度が高まってきたので、HoloLensの現在がわかるデモがあるといいんですが。
▲ DNP「AR/VR/MRを活用した体感型デジタルショールーム」（動画リンク）
前本: これはHoroLensだけでなく他のデバイスや技術を組み合わせたデジタルコンテンツエキスポでの展示なんですが、シェアリングという技術を使って同じ空間を共有する仕組みです。
白石: これはHoloLensと、スマートフォン？
前本: そうです。HoloLensとGoogle Tangoの技術を使って、デバイス同士がお互いの位置を認識し、他の人が操作したことを他のデバイスでも検知できるようになっています。「いま隣の人がこの商品をいいねした」とか、「この商品を買った」とか、デバイスを介して共有できる仕組みです。
千葉: 複数の人が同じ世界をそれぞれ見ることができる、というのがシェアリングですね。
前本: 実はtoBの事例も増えてきて、製造業とかデザインの現場とかで活用が進んでいるんですよ。
▲ ホロラボ「AR CAD Cloud」（動画リンク）
前本: AR CAD Cloudは、CADデータをHoloLensにダウンロードしてその場ですぐに見られるサービスです。モノを作る前に、作ったらどうなるかが確認できる時代になっています。
千葉: 日本で一番最初に業務にHoloLensを取り入れた事例は、日本航空さんですね。1つはパイロットの訓練向け、もう1つは整備士の訓練向けシミュレーションです。飛行機は飛ばしていないと利益効率があがらないので実機での練習は難しく、シミュレータも好きな時に使えるわけではなかった。新人の方なんかは、机の上に印刷した紙を広げて手を置いて、ということをしていたらしいです。
VRでもいいんじゃないかと思うかもしれないですが、訓練では自分の手が認識できることが重要だそうで、外の世界をシースルーで見ることができるHoloLensが向いていたようです。
白石: MRとVRは似たようなことができそうだけど、確実な違いがあるんですね。MRのいいところは「現実世界も見えている」というところですかね。
千葉: そうですね。VRにも現実世界を取り込むことはできるんですが、結局カメラであって目で見る現実とは違うものなんですよね。
白石: Windows MRというのがありますけど、どういうものなんですか？
千葉: 最初のデバイスとしてHoloLensが発売されたんですが、やはりコンシューマー向けとしては高額じゃないですか。裾野を広げたいという意図で、Windows MRと名前を変えて、HoloLensはその一つということになりました。
白石: HoloLensはハイエンドなWindows MR対応デバイスの一つ、というところでしょうか。
千葉: 開発者視点でいうと、HoloLensの開発ノウハウでWindows MRが開発でき、逆も然りと。デバイスも複数社から出ていて、4〜5万円程度とそれほど高額ではないので手軽さは広がったかと思います。
被るだけではないVRの領域
白石: 続いてVRについても伺っていきたいです。
いっこう: 実はVRの歴史は長く、日本バーチャルリアリティ学会は25年ほど、研究分野としてのVRは50年ほど前からあります。ちなみに学会的にはVRを「仮想現実」と訳すのは少しNGで、アカデミア的には「人工現実感」を推していきたいです。……細かいんですが、一応（笑）
白石: 訳にも違いが出るんですか。いまVRではどんなことが実現できるんですか？
いっこう: バーチャルというのは「仮想」ではなく、「姿形はそのままだけど実際にはないもの」なんです。VRというとヘッドマウントディスプレイのイメージですが、実際には被らなくてもそこにあるという捉え方です。例えばドームスクリーンとか、匂い系のデバイスとかもVRですし、舌に電気を流して味を感じるのもVRです。頭に電気を流して、幼女にビンタされる感覚を味わうというのもVRです（笑）。
白石: 世界はそんなところまで行っているんですか（笑）！？
いっこう: 開発者レベルなんですけどね。学術としてのVRとコミュニティのVRはやや溝があり、もう少しうまく繋がったらいいなと思っています。VRはMRに比べてデバイスが多いので、一般のガジェット好きが手軽に楽しめるのがいいところかなと思います。
白石: 先ほどMRはシースルーなところが利点という話がありましたけど、VRの利点はやはり没入するというところですかね？
いっこう: 被るタイプのものだと完全没入型というメリットは1つ大きいですね。あとは学会的な見方ですが、VRは「3C/3E」のための道具なんです。3CはCreation（創造）、Control（制御）、Communication（通信）。3Eは、Elucidation（解明）、Education（教育）、Entertainment（娯楽）です。
Control（制御）はいわゆるロボット制御だけでなく、例えば人が入れない原発などを遠隔で見る、というもVRの領域です。
Communication（通信）というと、最近だとVirtual YouTuber（VTuber）やVRChatが流行っていますよね。VTuberではキヅナアイちゃんがいて、去年くらいから他のVTuberがどんどん出てきてかなり盛り上がっています。アイちゃんを知っている人？
（会場、ほとんどが挙手）
白石: VTuber、VR Chat、初耳です……！流行っているんですね。
いっこう: アイちゃんに関しては既にかなり稼いでいて、スタイルとして確立しているかなと。加えて、最近は割と簡単にVTuberになれる仕組みが整ってきたと思います。ちょうど先日UnityとWindows MR（Lenovo Explorer）を使って、ほぼコードを書かずにVTuberになるという記事が上がっていました。
⇒ 参考: windowsMRでバーチャル生放送をするためのセットアップ
白石: これは、配信をする側がデバイスを被っているということなんですか？
いっこう: そうです。鏡を置いて、ボイスチェンジャーを使って。最近はあえて声はおっさんのままというVTuberが流行っていますが（笑）。
白石: うーん、すごいですね。VR Chatというのは？
いっこう: VR Chatはここ最近でグッとユーザが伸びているんですが、セカンドライフのようなイメージで、自分のアバターを使ってワールドワイドにコミュニケーションできるものです。まだ高いんですが、一般人でも自分の身体を3Dスキャンしてアバターに使う人も出てきました。
⇒ 参考: 3Dスキャンした実写アバターで「VRオフ会」する猛者が登場 これもうオフかオンかわかんねぇな……
白石: これはどうやって移動するんですか？実際に歩いて動く？
いっこう: 手に持ったコントローラが紐付いて手の動きを自然に見せてくれ、足の動きは補完されます。
白石: なるほど。3Eの方だとどのような具体例があるんでしょうか？
いっこう: Entertainment（娯楽）ではVR ZoneやVR PARK TOKYOなどが流行っていますし、開発者もエンタメ系の用途で使っている人が多いですよね。HoloLensでもエンタメはできるんですけど、広く受けているのは没入感の違いかなと思います。
千葉: 現実世界から離れたいこと、ありますもんね（笑）。
各OS対応で盛り上がるAR領域
白石: AR領域でいうと、ARKit、ARCoreがすごく盛り上がりましたよね。
千葉: GoogleのハイエンドなARプラットホームTangoは終了が決まってしまいましたね……。後続でマス向けのARCoreが発表されました。
いっこう: ARKitの方はアップデートで、これまで水平だけだったのが垂直も検出できるようになり、できることが増えましたね。
白石: スマートフォンの普及率からいうと、xRの中では一般普及するのはARが早いんでしょうか？
千葉: 手軽に使えるという意味ではそうでしょうね。
前本: VR、MRの課題は、手軽じゃないという部分がありますからね。買わないと、被らないといけない。最近のARはARKit/ARCoreの登場で、すごく現実感が出てきました。10cm動かすと10cm動くように精度が上がって、一つ上のステージに上がったなと思います。
▲ AR World Sharing Demo（動画リンク）
いっこう: Web技術の文脈では、WebVR、WebARが有用ですね。これまでアプリでしかARが実現できなかったのが、ブラウザがgetUserMediaに対応して、Webベースでカメラ情報を取得して実現できるようになったのが大きいです。MozillaさんがWebVRとWebARを統合したWebXRを推していて、W3CではWebVRは既にAPIが用意されていますが、次のバージョンアップではWebXRにしようということになっています。
⇒ 参考: WebXR Device API Specification
いっこう: 簡単にVRアプリケーションを開発できる、WebVRフレームワークのA-Frameもかなり盛り上がっていて、コミュニティが成熟してきていますね。
⇒ 参考: A-Frame
さらなる発展へ向けて技術的課題の解決が必要
白石: ここまではそれぞれの技術の現状を伺ってきましたが、さらなる進歩へのボトルネックや技術的な課題といった部分も聞いてみたいですね。
千葉: デバイスの制約は一つ大きな課題ですね。例えばデバイスを被らないといけないし、デバイスの処理能力がそれほど高くないし、バッテリーの持ちの問題もある。VRでもバッテリーとは逆にケーブル接続の制約があるかと思います。
白石: HoloLensって、実際には電池はどれくらい持つものですか？
千葉: 通常の使い方だと3〜4時間、積極的に使っていると2時間ほどです。技術の進歩で、将来的には解決されていく課題だとは思いますが。
白石: 逆に2012年頃に作っていたプロトタイプから考えるとどうですか？
千葉: 当時はいろいろ剥き出しで、サイズも大きくケーブルも多く、本当に最終製品になるんだろうか？と不安でした。でもやっぱり技術の進歩があって、5年経ってわずか579グラムです。今の課題も5年後、10年後と解決されていくはずですね。
前本: 2017年後半は開発環境の課題が多かったですね。HoloLensのアプリケーションはまずUnityで開発して、Visual Studioに書き出して、HoloLensにデプロイするという流れなんですが、それぞれのバージョンの違いで整合性が取れないようなことがあってかなりバッドノウハウが蓄積していました。
白石: 開発環境の問題があったんですね。
前本: いまはだいぶ落ち着いて、初めての人でも開発しやすくなりました。発売当初に初めてHoloLensを触ったときは、こんなことが生きている間にあるんだ！と思ったのに、すぐに視野が狭いとか腕が疲れるとか、思うところがでてきて、終わりがないです（笑）。
千葉: 本当ですよね。今から10年前を考えてみると、2017年にこんなデバイスがでていると想像できなかった。10年先は想像できないけど、たぶん10年後も満足していないと思います。人間の探究心って便利じゃないところを見つけてしまうので終わりはないけど、気がついたらみんな普通に使ってましたという感じになるんじゃないかと思っています。
xRで盛り上がるビジネス領域
白石: xRの技術的な側面をたくさん聞かせてもらいましたが、実際にはxR界隈ではどういうビジネスが生まれているんでしょうか？
いっこう: VRでいうと、アメリカのVR/AR専門ファンドのThe Venture Reality Fundが年に2回作成しているVRカオスマップが参考になります。
▲ The Venture Reality FundによるVRカオスマップ
いっこう: 機械、ソフト、ハードとだいぶプレイヤーが多くなっていると思います。その中で一部日本の企業も入っていて、健闘しているなあと思いますね。
白石: 大カテゴリが「Applications/Content」「Tools/Platform」「Infrastructure」。ホロラボさんはアプリケーション領域ですよね。どういうお仕事がメインですか？儲かっていますか（笑）？
前本: まあ、お陰様でぼちぼち……（笑）。受託で作る場合と、AR CAD Cloudのように自社パッケージとして作る場合とがあり、始めたばかりなのでなんでもアリ、という感じです。
いっこう: ゲームカテゴリだとバンダイナムコさんが入っていますね。もともとが大きい会社ですけど、VR Zoneもかなり盛り上がっていますし、VR領域では日本で一番じゃないかなと思います。
白石: Tools/Platformというと、去年Oculas Riftが値下げをしたじゃないですか。正直、売れてないのかな？と思ったのですが……。
いっこう: 逆に、値下げをしたことでめちゃめちゃ売れたと思います。Windows MRも手頃な値段なので、結構売れているのではと思っています。
千葉: そうですね、各社お互いの価格を意識しつつ値段をつけていると思います。
xRでどうやって「URL」にアクセスするか
白石: 会場からも質問を受け付けてみたいと思うんですが、どうでしょうか？
参加者: 現在のマウスとキーボードで扱うコンピュータのUIは、平面を前提にしているじゃないですか。xRのような3Dで見られるHPやメディアって、どういう形になっていくんでしょうか？例えばWebページにアクセスしたい時、URLの入力はどうするんだろうって想像がつかないんです。
前本: 一つあるのは、リアリティがあるからといって、リアルと同じようにしないといけないと疲れるんですよね。マウスやキーボードのように、操作性を上げる入力装置があったほうがいいだろうと思います。
いっこう: HoloLensってエアタップなど手を前に出して操作しますけど、結構腕が疲れるんですよね。VR空間の移動も、ワープ方式やコントローラを使う方式があるけど、あまりしっくり来ていなくてまだ確立していない。
千葉: これまでのUIが生きる部分と、人間の通常の行動がそのままUIになる部分とあると思います。URLでいうと声を発したら文字になって適用されるというのも いいかもしれない。
いっこう: いろいろな方法を試していかないとなあというところですよね。
2020年に向けた期待
白石: たっぷりと伺ったところで締めたいと思いますが、最後に2020年の少しだけ未来に、xRはどうなっているか想像や期待を伺わせてください。
いっこう: 2年後かあ……。VRはハード面では一体型が出てきて、画質も上がって、さらに進歩すると思うんですけど、一般普及するのは正直まだまだかなあと思っています。
白石: どうしたら一般普及するんでしょうね？キラーコンテンツの登場？
いっこう: Yahoo!BBがモデムを無料で配ってADSLが普及したように、国や機関が無料で配るくらいしないと普及しないんじゃないかと思います。
白石: 無料で！確かにそうですね。前本さんはどうでしょう？
前本: 現実的には通信が5Gになったり、視野が広がったりと、技術的な課題がクリアされていくと思います。期待でいうと、xRネイティブな世代が遊びとしてVRやARとAIを連携したりしていて、そういう遊びの中からすごいものが出てくるんじゃないかと密かに思っています。もしかしたら攻殻機動隊も実現するんじゃないかな。
千葉: 技術的な進歩はもちろんですけど、私が期待したいのは「xR盛り上がっているぞ」という一体感ですね。熱量のある人が増えて、ビジネスも増えて、私自身この領域の仕事にもっともっと関われたらいいなと期待しています。
白石: それぞれの熱いお気持ち、ありがとうございます。本日は大変勉強になりました！
HTML5 Experts.jp 副編集長兼エキスパートの吉川です。昨年好評だった「Webの未来を語ろう」企画を2018年もやります！
今回はパネルディスカッション形式で、HTML5 Experts.jp 編集長の白石が、ブラウザベンダーのGoogleのデベロッパーアドボケイトのえーじさん、 Microsoftのエバンジェリスト物江さんをお迎えして、興味深いお話を多数お聞きしました。
会場も交えたトークは、今後のWeb業界の動向を追いかける上で、重要な内容となっているので、ぜひ読んでみてください！
2017年のWebで印象に残ったことは？
白石: まずは簡単な自己紹介と、2017年のWebで印象に残ったことを教えてください。
えーじ: えーじです。Googleでデベロッパーアドボケイトをしています。もともとは、Google Chromeのアドボケイトという位置付けでしたが、最近はもっと広くなって、Web全体のアドボケイトを担当しています。 特にChromeだけの話に限らず、Web全般について話をしていますね。これには、我々のチームの理想として、Webすべてに貢献していこうという想いがあります。
2017年で印象に残ったことは、SafariがService WorkerとPayment Requestに対応すると表明したことがすごく意義深いと思っています。
物江: 物江と申します。Microsoftでエバンジェリストをしています。以前はWebに軸足を置いていたんですが、現在はWebだけに限らずISV(Individual Software Vendor)、独立してサービスや製品を提供しているパートナーさん向けに様々な技術の啓発を行なっています。Webについては、個人的なものも含めていろいろ活動しています。
2017年に印象に残ったことは、WebAssemblyやPWA（Progressive Web Apps）などについて、ブラウザベンダーがきちんと足並みを揃えて、仕様を策定するようになったということですね。非常にいい流れになってきていると思います。
▲左から、日本マイクロソフト株式会社 物江修さん、Google デベロッパーアドボケイト えーじさん
白石: 皆さん、ありがとうございます。ついでに私の2017年で印象に残ったこともお話ししておくと、個人的にはdev.toや日本経済新聞社の日経電子版が爆速だったという、そういう事例が出てきたのは印象的だったなと思います。裏側でHTML5やWebの最先端技術とか、そういったものを使って1段階上のレベルの速さを実現している。
Webプラットフォームベンダーやコミュニティの皆さんの啓蒙活動などもあって、PWAをはじめとしたWeb技術だとかパフォーマンスだとかが、ビジネス上も重要であるというところも浸透してきている。その結果として、Webプラットフォームの機能がフル活用されつつ、パフォーマンスというところに影響がでた良い例かなと。
今回は、Webの過去・現在・そして未来を語るという構成で進めてみたいと思います。
イントロダクション:HTML5は世界を変えたのか？
白石: 2017年以前のWebを振り返ると、ブラウザ戦争などの分断化があって、そこからHTML5のムーブメントが起こり、Webの様々な仕様が生まれてブラウザに実装されました。
ただ、それら「HTML5」のムーブメントは世界を変えたんでしょうか？ これまであまり、そういう振り返りをしたことがなかったので、一度やってみたいなと思っていたんです。お二人はどうお考えですか？
物江: そうですね、一般ユーザーの目からすると、確かにあまり変わっていないかもしれません。例えば、YouTubeのプレイヤーは、FlashからHTML5になりましたけど、変わったって気がつく人はあまりいませんよね。普通の人は、きっとまったく意識せずに使っている。HTML5でできたことは、とっくにFlashでもできていたわけで。
でも、開発者にとっては大きな変化がありましたよね。結局、開発者はみなHTML5を使っています。これはなぜかというと、HTML5がシンプルだからこそだと思うんですよ。
エキスパートの竹洞さんがいいことを言っていたんですけど、Webが素晴らしく進化したのはKISSの原則(*1)のおかげといっていました。つまり、誰でも簡単に使えるからこそ普及した。わざわざFlashを使わなくても、Web標準技術だけを使えばいろんなことができるようになった。それによって作り手側の裾野が広がって、以前よりもリッチなコンテンツがたくさん出るようになってきたのかなと思います。
*1 … “Keep it simple, stupid” （シンプルにしておけ！この間抜け）、もしくは、”Keep it short and simple” （簡潔に単純にしておけ）という経験的な原則の略語。Wikipedia
えーじ: ぼくも、世界は変わったと思います。やっぱりHTML5でWebを変えようっていうムーブメントがあったこと、それ自体が良かったと思うんですよね。良い意味でのブラウザ間の競争が起きて、どんどん新しい提案がなされて、共通して使えるものがどんどん生まれていった。
ちゃんと数えたことないですが、HTML5の機能でみんな当たり前に使うようになったものっていっぱいあると思うんですよ。例えば、CSS3で角丸を使うっていうのももう当たり前にみんなやっているし、それが動かないブラウザはほぼ、ない。そういうものが当たり前に使えるようになったっていうのは、一昔前からすると全然状況は異なっている。そういう意味では、相当変わったと思います。
白石: そういえば、元Mozilla Japanの浅井智也さんに以前教えてもらったんですが、Web関連技術を全部まとめた図があるんです。これ、曼荼羅図みたいな感じなので、「Web曼荼羅」なんて呼ばれているそうです(笑)。
HTML5とその関連技術（webapi.link）
こうして考えると、HTML5のムーブメントはたくさんのものを生み出しましたねえ。一般のユーザーからはあまり変わってないように見えても、「それは時間をかけて変わっているから」という面もありそうですね。
えーじ: はい、そして、これだけのものがたくさん生み出された結果、Webはアプリケーションプラットフォームになった。それが、HTML5以前との大きな違いだと思いますね。
Webは難しすぎる─Webプラットフォームの現状と課題
白石: では、iOSやAndroidといった他のプラットフォームとWebプラットフォームとを比較すると、Webはどういう立ち位置にあるとお考えですか？
物江: Webプラットフォームは時間をかけてここまで成熟してきました。機能的な面では、他のプラットフォームにもひけをとらないというところまで来たんじゃないかと思います。
そして今、Progressive Web Apps (PWA)が浸透しつつあることが、今後のWebにとってはすごく意義のあることだと思っています。 PWAって、ある意味ひとつの理想の到達点だと思うんですよね。Javaなどが理想に掲げていた「Write Once, Run Anywhere」を、PWAは真の意味で実現するわけです。 これ、次のWindowsの大型アップデートでPWAがデスクトップアプリっぽく動いだり、Windowsストアからインストールできるようになるから言っているわけじゃないですよ(笑)。
白石: そこでいつも言われているのが、Webアプリって動作が遅いんじゃないかってことですよね。
物江: ただ、そうした問題についても、Webプラットフォームは長いこと取り組んでいて、もはやあまり問題にならないレベルじゃないかと思います。 ブラウザの実装という面でも、仕様の面でも、絶え間ない改善が続けられてきました。
仕様の面でそうした部分について期待できるのは、やはりWebAssemblyですね（筆者注: ブラウザが高速に実行可能な、ポータブルなバイナリ形式）。 昨年、モダンブラウザが同時にWebAssemblyのサポートを表明するということがありましたが、これでWebの速度はまた一段階アップすることが期待できます。
あとはやはりハードウェアの進歩が解決するものも多いでしょう。ちなみに、今のWeb技術の素晴らしいところは、ハードの性能に縛られた設計をしていないこと、どこでも同じWeb技術が動作することだとも思います。
例えば昔、貧弱だった携帯電話の機能に合わせた仕様で、HDMLやCHTMLというモバイル専門のタグがありましたが、今はもうほとんど残っていません。結局、性能に関わる問題は時間が解決してしまう部分も大きいんです。いま大切なことは、「いかに人間が作りやすいか、使いやすいか」が重要になってくるかなと思います。
えーじ: ぼくも、パフォーマンス面は既にあまり課題とは考えていません。それよりぼくが課題だと感じているのは、開発者にとってのWeb技術はかなり複雑になってしまっていることです。
例えば「Extensible Web」というのを聞いたことがある方がいらっしゃると思います。これはWebの技術設計に対する、ここ数年における指針のようなもので、具体的には「標準としては、ユースケースを規定しない低レベル（低レイヤー）なAPIを提供する」というものです。
そうすることで、そうしたAPIを使用したハイレベルなライブラリだとかベストプラクティスが、開発者の手によって作られることを期待する。こうすることで、「ハイレベルだけど使われないAPI」が標準で規定されてしまうという問題を解決しようとしています。
ただ今は過渡期なので、低レベルなAPIがどんどん増え、ライブラリも量産されていて、はっきり言って混沌としています。例えばService Workerもすごく低レベルなAPIで、実際に使うとなるとなかなか難しい。
そこにGoogleがWorkboxというライブラリを出していたりするんですが、それを使うと簡単にServiceWorkerを使える一方で、ServiceWorkerもライブラリもどちらも学ばなくてはならない。
これがWeb Componentsなんかだと、仕様そのものがどんどん変わっていて、なかなか安定しない。Polymerというライブラリを使おうにも、Polymerも仕様に合わせてどんどん変わっている。どの時点の仕様が正しいのか、検索したときにどれが最新なのかわかりづらい。そういうところが複雑で、開発者はみな苦労してるんじゃないかなと思います。
個人的には、以前Webpackにやられたことがありまして(笑) 。将来的にはES Modulesが広まれば、そういうビルドプロセスを経なくてもうまく動くようになるんだと思うんですが、今は過渡期として、やっぱりGulpなりWebpackなりRollupなりを使う必要がある。
ビルドツールも次々に生まれるし、フレームワークもそう。フレームワークとビルドツール、様々なライブラリも組み合わせなくちゃならないし、ベストプラクティスが簡単にはわからない。その辺がかなり複雑になっているなと感じています。
各ブラウザベンダーのこれからの動向は？
白石: 皆さんご自身の会社の立場からお聞きしたいなと思うんですけど、ブラウザベンダー各社がどういう想いで、どういう方向を向いて実装しているのかをお聞かせください。
えーじ: 会社（Google）としての方向性はもちろんですが、チーム内でWebに関する課題を共有して、その解決策を探ることは普段から行っています。
例えば、先ほど挙がっていたパフォーマンスを例に挙げましょう。
実はJavaScriptのパフォーマンスって、もうあまり問題にならなくなっているんです。むしろ悪いのはレンダリングの部分で、そこを速くするための努力はずっと続けています。
あと、ネットワークの遅延もすごく大きい要因なので、ServiceWorkerみたいな仕様を提供することで、スピードの課題に開発者自身が取り組みやすくする。
さらに、パフォーマンスに関するベストプラクティスを開発者の皆さんと共有するのも重要です。
このように、課題一つとってもたくさんのアプローチがある。こういう活動を、チーム一丸となって同時に取り組んでいるという状態ですね。
白石: なるほど。ちなみにGoogleの中で、「今のWebはこういう課題があるね」みたいな、そういう話し合いっていうのはよくされるんですか？どんな議論がされてるのか興味があります。
えーじ: はい、常にやってますね。世界中から集ってきた情報を、雑談ベースでやり取りするような感じです。
例えばこれからGoogleがインドでももっと使われるようにするためには、インドの市場を考えなきゃいけない。しかしインドは全然違う世界だと。
例えばネットワークにしても、今われわれが4Gは当たり前に使ってますけど、向こうの世界は2Gなんです。3Gですらない。なのに、何MBっていうファイルをダウンロードしないと見れないサイトっていうのはざらにあるわけですよ。そういったネットワーク環境の悪いところに対して、開発者の皆さんがサービスを提供しようと思った時にどうするのか。そういう課題がインドに進出しようと思っているチームから上がってきたりします。
他には例えば最近は、アクセシビリティにもかなり力を入れていたりもしますね。アクセシビリティに強く関心のある人たちがチームに入ったことで、Webのアクセシビリティをもっと良くするための話し合いや仕様の提案なども活発に行なっています。
物江: Microsoft Edgeは、相互運用性とセキュリティ、アクセシビリティとパフォーマンスの4つが何においても優先されています。
例えば相互運用性でいうと、 -webkit-text-stroke というベンダープリフィックスがあります。これ、以前はWebKit系のブラウザでしか動かなかったんですが、現在はEdgeでも開発中なんです。多くのサイトで使われているような機能については、全部同じように動くようにするというのを優先的にやっています。
アクセシビリティに関しては、画面に表示されるすべてのテキストについて、スクリーンリーダーのような外部のプログラムを呼び出せるような仕組みが、WindowsにはOSレベルで入っています。それを使って、アクセシビリティを強化するような仕組みがEdgeに入っていたりしますね。
パフォーマンスについては、Chakra（EdgeのJavaScriptエンジン）のパフォーマンスアップを継続的に行っています。特に、こないだのアップデートでようやくブラウザ内部のリファクタリングが終わったようで、Edgeが出た頃からのパフォーマンスでいうと、3～4倍速くなってます。
白石: リファクタリングっていうのは、Internet Explorerから引きずっているコードがかなりあるのを書き直すって話ですよね。それが行われているって話はだいぶ前に聞いていましたが、ついに終わったんですね。
物江: はい、ほぼ全部終わったんじゃないかと。もともとEdgeのレンダリングエンジンってTrident（IEのレンダリングエンジン）から派生したものなので、20年以上前のものということで、根っこの部分で仕様が古い部分があったんですよ。その修正がようやく終わったという感じです。これから先は、Edgeの開発はどんどん加速していくんじゃないかと期待しています。
あとは、やはり2000年代と比較すると、ユーザーの意見をより開発に取り入れようという姿勢が顕著になったかと思います。Windowsをお使いの方はわかると思うんですが、フィードバックHubというのがありまして、そこでバグの報告だとか、追加してほしい機能をリクエストできるんですよ。そのリクエストのベット数が多いと優先度があがっていって、対応されるというようになっています。
各種ブラウザのステータスが確認できるサイト
注目のWeb最新技術を一挙に解説！Web Payments、WebVR、AMP、PWA、WebAssembly…
白石: ではここからは、注目のWeb最新技術についていろいろお聞きしたいと思います。Web Payments、WebVR、AMP、PWA、WebAssemblyなどなど、仕様ごとに概要と現状をお話しください。
Web Payments
えーじ: 今までWebでお金を払うといったら、フォームを使ってクレジットカード番号を入れたりとか、どこかのサイトに飛んで、そこのサイトにあらかじめ保存してある支払い情報を使うといったことがほとんどだったと思います。Web Paymentsを使うと、ブラウザがネイティブで表示してくれるUIを使って支払いができるようになるというのが大きな特徴ですね。ちょっと見てもらうと、PolyCartというWeb Paymentsのデモサイトで確認することができます。
Web Paymentsのデモサイト（PolyCart）
ブラウザネイティブのUIを通じてクレジットカードの情報や、配送先、連絡先などの入力を促すことができます。そうして入力された情報はブラウザが記憶してくれるので、次からはクリックするだけで支払い情報を入力することができます。
もっとすごいのは、将来的には支払い方法を追加できるようになるんです。例えば、Apple PayやGoogle Payで支払うのも可能ですし、仮想通貨なども使えるようになるでしょう。
WebVR
物江: 以前から、「Web上でVRコンテンツを表示する」っていうのは、Three.jsなどを使って実現が可能でした。ではWebVRは何が違うかというとVRデバイスからのフィードバックを受けることができるんです。これによって、VRデバイスと深く連動したWebサイトを作ることができます。
それにWindows10だと、ネイティブでVRの環境をサポートしていて、WebVRに対応したWebサイトにいくと、自動的にVRゴーグル上で全画面表示してくれるようになっています。VRのビデオもそのまま見ることができるので、真の意味でシームレスにVRのコンテンツが提供できるようになっています。
個人的に楽しみなのは、VRをきっかけとして新しいUIが生まれてくることですね。既存のVRゴーグルを使ったことがある人はわかると思うんですけど、キーボードもマウスも何も使えないんです。そうすると新しいUIを考える必要があって、そこに新しい可能性を感じています。
えーじ: ちなみに最近はWebXRっていうらしいですね。VR、AR、MRをコンセプトに入れた仕様を作ろうとしているという動きもありますね。
AMP
白石: 次はAMPですが、これについては既にたくさんの方がご存知でしょうから、簡潔に。主にモバイル環境で、Webページを素早く表示できるようにするための、HTMLのサブセットですね。
えーじ: AMPの仕様自体もさることながら、AMPが基本的にWeb Componentsでできているのは興味深いです。Web Componentsの仕組みを使って独自のエレメントを定義していて、なおかつパフォーマンスも追求しているので、結果としてパフォーマンスのベストプラクティスの塊をWeb Components化したものになっている。大変面白いと思います。
Progressive Web Apps
白石: 次は、恐らく今年最大の注目キーワードProgressive Web Appsですね。これは（ずっと啓蒙してきた）えーじさんに語っていただくしかないでしょう。
えーじ: はい。とはいえPWAという言葉自体は、皆さんに意識してもらいやすくするためのマーケティング用語のようなもので、技術的な観点からはそれ自体意味がないと思っています。実際の中身はService WorkerだったりとかPush Notificationだったりとかそういう具体的な機能やAPIから構成されています。
日本でも、昨年後半くらいからPWAが注目されはじめました。さっきのdev.toとか日経電子版とかも、PWAの構成要素を利用することで高速化が実現できたと。PWAの中のひとつひとつの技術要素をうまく使うとここまで速くできるんだよ、といういい例ができたなと思っています。
白石: ちなみに、個人的にはPWAっていまいち意味がわからないな、と思ってて。なにが「プログレッシブ」なんでしょうか？プログレッシブって、「だんだん（進化する）」って意味ですよね。
えーじ: PWAにおける「プログレッシブ」には2つ意味があります。
1つは昔から言われているプログレッシブ・エンハンスメントです。古いブラウザでも見ることができる基本的なWebサイトをまずは作って、そこに、新しいブラウザで使える機能を足していくという考え方。そうすれば、クライアントの環境を最大限活かすことができます。
白石: では、Service Workerが使えるブラウザだったらオフラインという機能が使えるけど、そういう機能が使えないブラウザにも同等のものを提供する。既存のサイトにあとからその機能を提供することも割と簡単にできますよっていうそういう思いを込めたものということですね。
えーじ: そうです。もう1つが、今あるサイトに機能を付け加えていくことで、徐々にPWAに近づけていけるという意味です。PWAのためにサイトを一から作り直すとか、大幅な改修を行う必要はない。既存のサイトを徐々に拡張していけばいいんです。
白石: なるほど、そういう意味合いだったんですね。ちなみにPWAの中では、Service Workerが代表的なAPIですよね。他にはWeb App Manifestとか、Push Notificationとかでしょうか。
えーじ: そうですね。ちなみに、PWAのウリの一つに、OSのホーム画面にアイコンを追加できるというのがあるんですが、以前はただのWebアプリへのショートカットでした。でも今は違います。PWAをホーム画面に置く際、アプリのパッケージを動的に生成してインストールするので、OS上の扱いはネイティブアプリとほとんど変わりないんです。なので、プッシュ通知のオン／オフをアプリごとに設定できたり、ネイティブアプリでしかできなかったことがPWAでも同様に行えます。
WebAssembly
白石: 次はWebAssembly、物江さんご説明お願いします。
物江: WebAssemblyは、Webブラウザ上で非常に高速に動作させることができる、デバイスに依存しないバイナリ形式です。現在は用途がある程度限られていて、DOMを操作することなどはできませんが、CPU依存の計算処理などは極めて高速に動作させることができます。 Emscriptenなどのツールを使うと、C/C++で作られたものをWebAssemblyに変換できるので、C/C++で書かれたゲームなどをWebAssemblyに移植することも比較的容易です。また現在はまだ開発中ではありますが、MonoがC#からWebAssemblyをコンパイルするmono-wasmであったり、マイクロソフトも実験プロジェクトとしてWebAssemblyを介してWebブラウザー上でC#とRazorを走らせるWeb UI framework Blazorを開発していたりします。
（ここで会場からエキスパートであるあんどうやすしさんから質問）
あんどうやすし: 現在のWebAssemblyって結局計算することしかできないじゃないですか、DOMもいじれないし、JavaScriptのAPI呼び出しも直接は行えない。今後もそれは変わらないんでしょうか。特にデータの渡し方に結構制限があって、使い勝手がいいものにするには難しいなと感じています。SharedArrayBufferという仕組みで一次元配列の共有はありますが、それも使いづらいし…。
物江: それは、今の段階ではまだなんとも言えないですね。
えーじ: ちなみにSharedArrayBufferはこないだのメルトダウンとスペクター(*2)の影響で機能が停止になります。
白石: ありゃ、まさかそんなところにまで影響及ぶとは…(笑)。
*2 … CPUでの投機的実行という高速化プロセスを悪用した脆弱性
Web Share API
白石: 他には、注目のAPIとかはありますか？
えーじ: 最近追加されようとしている新しい機能にWeb Share APIというのがあります。
Androidのインテントをご存知の方だったらすぐ分かる機能ですが、例えばあるサイトを「FacebookやTwitterでシェアしたい」という場合に、Web Share APIを使うと簡単に外部アプリを呼び出すことができます。
逆に、自身のWebアプリを「シェアする先のアプリ」として使ってもらうようにすることもできます。それがWeb Share Target APIというものです。
Web Share APIは既に使えるんですが、Web Share Target APIは、現在限られたサービスにしか開放されていません。このように、Chrome では一部のドメインに先行してWebプラットフォームの機能を試してもらうオリジントライアルというものをやっているのですが、現在TwitterのモバイルサイトがWeb Share Target APIを使えるようになっています。mobile.twitter.comで実際に試すことができますので、TwitterのPWAをまだ試したことがない方は、AndroidのChrome betaチャネルか、devチャネルを使ってインストールしてみてください。何かシェアしようとしたときに、TwitterのPWAが候補として出てきます。
Web Authentication
白石: Web Authenticationというのもあると聞きました。
えーじ: Web Authenticationは、実はEdgeでもう使えるんです。仕様がちょっと古いので、APIが全く異なりますが、Polyfillもあります。Web Authenticationをひとことでいうと、セキュリティキーなどを用いた多要素認証を標準技術で扱えるようにするものです。顔認証や指紋認証と組み合わせれば、安全性の高いログインの敷居はぐっと下がると思います。
物江: FIDO Allianceという標準化団体があるんですけど、そこで生体認証などのもっと広い話をしています。既にWindowsだとWindows Helloという生体認証の仕組みがFIDOの標準で作られていますね。
えーじ: FIDOのWeb版がWeb Authenticationになるわけです。Web Authenticationの実装はこれからどんどん出てくるでしょう。Mozillaさんもこないだ実装を開始しましたし、Chromeもそろそろ入ってくるのかなと思います。
白石: そうすると、もしかしたら今年はWebサイトで指紋認証とか顔認証とかが一般的になってくるという可能性があるってことですかね。
えーじ: そうですね。どの認証方式を使えるようにするかっていうのは、順番に1つずつ入れていくという話らしいので、まずはセキュリティーキーから利用できるようになって、そのうちNFC、指紋認証ができるようになっていくようです。徐々にそういったものが実装されていけば、本当にパスワードを覚えなくてもいい世界っていうのが実現できるかもしれないので、すごく楽しみにしています。
ちなみに、Credential Management APIというIDとパスワード、いわゆる共通鍵認証をする仕様があるんですが、それとAPIのネームスペースが同じになるので、共通のAPIを使うことになります。まったく別々だった仕様が一緒になるというのも個人的には面白いと感じています。
エキスパートたちが見据えるWebの未来について
白石: 最後にWebの今後について感じていることをお聞かせください。
えーじ: ぼくらブラウザベンダーは、「こうなるといいな」というものをいろいろ作ってるんですけど、それはブラウザベンダーが勝手にやってるわけじゃなくて、開発者の皆さんの声とか、こういうWebがいいという声をもとにやっているので、フィードバックをできるだけいただいたほうが、より皆さんの理想としているWebができると思っています。
フィードバック方法にも今はいろいろあって、GitHub上で管理されている仕様にIssueを立てるっていうのも一つの方法ですし、一番簡単な方法です。それすらめんどくさいということであれば、ぼくに直接言っていただくとかでも構いません(笑)。そんな感じで、開発者の皆さんと一緒にWebを盛り上げていけたらいいなと思います。
物江: 個人的な思いとしては、今非常にWebって良い方向に進んでいると思っています。（お互いを傷つけ合うような）ブラウザ戦争は終わりました。今は良い意味でお互いに競争し合ったり、歩調を合わせてWebを良いものにしていこうという動きが主流になりつつ会って、とても好ましく感じています。今後もそれが続いていって、Webのテクノロジーの活用範囲が広がればいいなと思っています。
白石: 皆さん、本日は様々なお話をお聞かせいただき、ありがとうございました！
]]>今年もHTML5 Conference 2017の展示ブースでは、私ことDJ KATOの特別ラジオをお届けしていました。今回はビジネス・アーキテクツ太田良典さんとサイバーエージェント原一成さんをゲストに迎え、「UIデザインとアクセシビリティ」テーマに語っていただきました。その再現レポートをお届けします。ぜひ、カンファレンスレポートの番外編としてお楽しみください！
まずは、どんな講演内容だったのか教えてください
「ビジネス・アーキテクツの太田です。普段はWebアクセシビリティ関連の活動を主に行っています。『多様なユーザーニーズに応えるフロントエンドデザインパターン』というタイトルで講演させていただきました。よろしくお願いいたします」
「サイバーエージェントの原です。アメブロのフロントエンド開発を中心に行っています。『“モダン” ウェブアプリケーション ～アメブロ5ヶ年計画～』という講演タイトルで、アメブロの “モダン化” 実例に沿った考え方や技術採用事例、今後の展望などをお話しました」
「お二人とも先ほど同じ時間に講演されてきたんですよね。どちらかのお話を聞いた人は、どちらかが聞けなかったと思うので、どのような話をされたか教えていただけますか」
「私は、11月4日発売の『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』という書籍で紹介されている、アクセシビリティに配慮した実装手法について、例を挙げて紹介しました」
「どのような実例でご説明されたのでしょうか？」
「先ほどのセッションではサイトでの操作など、使いやすくするためにはどうするかという話をしました。例えば、商品のリストを値段の高い順や安い順に並べたり、最新順に並び替えるなどの機能も、基本的な要素を使ってマークアップしましょうという話ですね。絞り込みの機能を選択するのは高い順・低い順・古い順・新しい順が多いのですが、それは4個の中から1つを選ぶ機能なので、ラジオボタンで実装すればいいとか。
よくある問題は見た目がきれいになるからと、ラジオボタンじゃなくて<span>とか<div>で実装して、JavaScriptでクリックイベントをつけて操作できるようにするとか。それは、ラジオボタンで実装することによってキーボード操作であっても使いやすくすることができます。でもソフトキーボードでちゃんと使えるのか、スクリーンリーダーでアクセスしたときにちゃんと読まれるのかなど、いろんな問題があるわけです。なので、基本的にはちゃんと機能に合った要素を使って、見た目は後からがんばりましょうという話ですね」
「先に知っておけば、そういう落とし穴には落ちないということですね」
「HTMLをやってる人なら誰でも知ってるはずなんですけど、なぜか<div>とか<span>を使ってしまうんですよね。知っていることと実践できているかというのは別なんです」
「そうなってしまうのは、楽だからなんでしょうか」
「というか、『見た目から入ってしまう』からそうなるんですよね。見た目から入ると『枠で囲まれているから<div>かな』という考え方になりがち。後から結構スクリプトでできちゃうので、それなりに動くものができるんですよね。ただ、それがどんな環境でも使えるかというと、結構使えないことがあるのが問題です」
「そういったことをいろいろご紹介されていたんですね。チェックボックス以外のトピックも聞いてみたいです」
「リストや見出しをちゃんと使うことですね。あとJavaScriptやXHRを使ったパフォーマンス改善やアクセシビリティの話を中心にしていました。
アクセシビリティは『JavaScriptをできるだけ使うな』という議論になることが結構多いんです。でも、今普及してるUIはJavaScriptで動かしていることが多いのに、そんなこと言われても困るんですよね。今回ご紹介してる本ではこうすればできるという技法を紹介しています」
「ありがたいですよね。僕もJavaScriptを使いまくりなんですけど、実際のサービスを作る上ではやっぱり使わざるを得ない。さらに、ネイティブアプリとの差をなくしていったり、使いやすさを向上させるには必要な技法です。ピンク本と呼ばれる「デザイニング Web アクセシビリティ」という本があるんですが、毎週チームで読み会をしています」
「そのピンク本、ありがたいことに私の著書なんです(笑)」
「うちの会社にもあります。みんなは読んでいる本なんですけど、僕はどっちかっていうとエンジニアというよりディレクター寄りということもあって、まだ読んでいませんでした。すみません…」
「ディレクターさんにもすごくいい本ですよ」
「というか、ディレクターさんにもぜひ読んでいただきたいと思って書いた本です(笑)」
「なるほど！読みます！」
「実装だけじゃなくて、その上流から踏まえていきましょう、ということも結構書いているので、ぜひ読んでください」
「さっきのサイト制作の話に戻るんですけど、見た目から入っちゃうことが結構多くて。特にビジネスで評価する人って、この見た目がかっこいいとかから入っていきがちなんですよね」
「見た目と動きだけでしか評価できない人が多いという問題もありますね。見た目と動きがちゃんとしてればOKになってしまうことも多いんですよ」
「例えばディレクターがアクセシビリティを知らなくて、スクリーンリーダーなどの存在を知らなかったら、それだけで話が通じなくなりますよね」
「そうですね。それを解消するためにも、ぜひ！」
「まずこれを読むことで、関係者全員のしなくてもいい紛争が減ると」
モダンなウェブとアクセシビリティは両立できますか？
「原さんはモダンなウェブというテーマで講演されていましたが、アクセシビリティと両立するのは難しくないんですか？」
「難しくはないんですけど、ワークフローの中に組み込むのが結構大変ですね。プロジェクトは企画から始まって、デザインを作って…というように、見た目が前提なフローが多いので、どうしてもコードがわかる人はフロントエンドエンジニアくらいになるんですよ。評価できる人も」
「自然と優先度が下がっちゃう、というかんじですね」
「そうなんです。先程も言ったように『コードを知らない』って方もいるので、ピンク本は『JavaScript使うな』とは書いていないので、その辺もありがたいです」
「そういうことですか！」
「昔ながらのアクセシビリティをやってる人だと、『JavaScriptは使うな！』と言っちゃう人もいるんですよね。現場ではそう言われても困るので、なんとかしたいって思ってたんです。今回の本はそういう内容がたくさん書かれているので、いいなと思っているんですよね」
「極端ですけど例えば『危険だから家から出るな』みたいな話になっているんですかね」
「そうそう。何かあった時に『これとこれとこれを準備して』とか『こういうことに気をつけて』というのを示してくれるかんじなんです」
ところで、普段はどんなお仕事しているんですか？
「話は変わるんですけど、太田さんは普段どんなお仕事されてるんでしょうか？」
「ビジネス・アーキテクツという会社で、Webの仕事をしています。主に大きな会社のWebサイトを受託で作ることが多いです」
「企業の公式Webサイトですね」
「そうなんです。グローバル展開している日本の大手企業が多いのですが、そうした企業はアクセシビリティのガイドラインを持っていて、各国に配布したりしてるんですよね。各国にもそれぞれサテライトサイトがあって、全部統一させようと取り組んでいます。そういうアクセシビリティのデザインガイドラインの配布や取り組みに対して、お手伝いをしています。ひと言で言うと、Web制作ですけど」
「ひと言だとそうなんですけど、大変そうというか、慎重にやってかないと…。なんか、あまり軽いノリで作れないサイトってかんじですね」
「重すぎるノリっていうのも問題で、これやるなって言いすぎてもガイドライン無視されるだけなので、やっぱり現場で使えるようにしていかないと。実際に使えるものを作って、かつ運用できるようにしていくということがすごく大事なんですね」
「そうすると、基本のWebだけではなく、モダンな開発手法も知らないといけないですね」
「最近だとモバイル用のページをレスポンシブで作るのが当たり前になっていると思うのですが、そういうところも考えないといけないことがありますね」
「スマートフォンのモバイル用のページのことや、PC用ページではどうかとか、デスクトップのリーダーではどうかというのも書いてあって便利です」
「原さんは、どんなお仕事をされているのですか？」
「私は完全に開発者で、2004年からずっとアメーバブログを作っています」
「長いですね！」
「2015年にリニューアルをしていますが、サービスの歴史も長いですね。主にフロントエンドを担当しています」
「歴史が長いと今までに積み上げてきたものも多いと思います。社内で設計が大きく変わったりすると、かなり大変だと思いますが」
「その辺はエンジニアと協力しながらやっていますね。iOSならiOSの、AndroidならAndroidのエコシステムっていうか開発環境と作り方の基本があるんですけど、その上で他の人と会話しながら、モダン、モダンって言いながら開発してます。閉じこもった自分たちだけのライブラリばかりでは、存続が危うくなると思うので」
「お二人ともなんというか共通するところがあるっていうか、戦っているポイントが結構似ているかんじがします」
「かなり」
「そうですね」
お二人の情報収集や勉強方法を聞かせてください
「お二人はどのように情報収集や勉強されているんですか？」
「今まさに勉強しているつもりです」
「そうそう。かなり勉強してます(笑)」
「気がついたら置いていかれてた…っていうのは一番避けたいのですが、そのためにどんなことをしたらいいのでしょうか。ニュースサイトを見るとか？」
「それもありますが、周りの人と会話をすることも大事なんじゃないかと。最先端の技術者たちとコミュニケーションをとったり、彼らがTwitterなどで何をシェアしているのかを見ることで、どういうものが流行っているかを知ったりすることが多いですね」
「僕も一番簡単な情報収集はTwitterですね。フォローしておいて、その人がリツイートしているものを見るだけでも参考になります。あと、海外の情報も重要なので、英語が読めるだけでも大分可能性は広がります。ちょっと時間差はあるかもしれませんが、日本語に訳してくれる人をフォローするという手もありますね」
「Twitterはすごい情報数があふれているので、普段あまり使ってないんですけど…。どうやって情報の絞り込みをするんですか？」
「もちろん、全部を読むわけではないですよ」
「技術系のカンファレンスで気になったものをフォローしているので、そこからとか」
「良質なツイートをしている人が発信している情報を集めて、どんどんその濃度を上げていくみたいなかんじなんですね」
「あとは情報を発信している人のところに実際に行ってみるとか。そういう会社に入っちゃうというのもありますね」
「なるほど！」
「簡単に希望したところに行けるかはわからないですけど」
「そういう意味では、サイバーエージェントさんは大変いい環境ですよね」
「うちは情報が自然に入ってくる環境なので、勉強する必要がないっていうか。極論ですけどね(笑)」
「自然にっていうのがすごいですよね。周りの人との雑談がなんかマークアップの話になるとか？」
「ちょっと気持ち悪いかもしれないですね、普通の人からすると(笑)。技術に興味がある人が集まっている場所というか」
「でも、マークアップの話で盛り上がれるってすごく楽しいですよね。いや、『それ変態だ』って言われそうですけど(笑)」
アクセシブルなサイト設計・制作について教えてください
「簡単なアプリケーションだったら自分で作ったりもするんですけど、実際に開発始めてみると<div>とか<section>とか、途中で<h3>や<h4>がだんだん適当になってくんです。100行超えてくると『あれ？もともとどんなかんじに作りたかったんだっけ』というかんじになって、全体のことがあやふやになってくるんですけど、どうすればいいんでしょうか」
「それはいい質問だと思いますね！早い段階から見た目を気にして、その段階で増やそうと考えちゃってるんですよね」
「はい。で、書きながら実行してるんですよ」
「それは自然ではあるんですよね。悪いことではないんですが、基本的にオススメなのは、まずCSSを一切適用しない状態でHTMLだけで作ってしまうこと。結構しっかりした構造が作れると思います」
「完全に素のやつですよね」
「さらに言うと、見出しから作っていくとか。それがマークダウンなんですが、逆に難しいかな」
「以前僕が経験したものだと、先にデザインが決まり、デザインカンプが上がってきて、スライスしてCSSをあてる。で、インタラクションとかをJavaScriptでやるという順番でした。ちゃんと考えたつもりなのに、だんだん破綻していくんですよね。いきなりフロートからやるとか、順番がおかしいとは思ってたんですけど(笑)」
「もしかすると、デザイナーさんもあまり整理できてないのかもしれないですね。うちではコンポーネント思考で、デザインから作っています。Webコンテンツをコンポーネントっていう単位で分割するんですよ。例えば見出しなら見出し、本文なら本文、リストならリストみたいなパーツに分割してデザインしてくんです。
それを組み合わせてWebページを作るというシステマティックなやり方をしています。ページごとにデザインするのではなく、パーツごとにデザインしたものを組み合わせてページを作るという考え方をデザインの段階からやっているんです」
「最初はみんな紙ベースというか、ペライチみたいなデザインで始めることが多いんですよね。紙って自由度が高いけど、文字や画像などのコンテンツをバラバラにすることはできなかったり、うまく区切れなかったりとか、Webとは考え方ややり方が違いますよね」
「逆にWebのやり方がわかっているデザイナーさんだと、『これは<h1>で』とか言ってくれたりするんですよ」
「あとは自分たちで共通部分を見つけてコンポーネント化していくとか」
サイトの構造やレイアウトデザイン、昔と今ではどう変わってますか？
「以前、コーディングは全然やらない人で完全にデザインだけやっている外部の人が、『こんな感じでよろしく』って送ってきたデザインが最悪だったことがあります。一方で、フロントエンジニア兼デザイナーをやっている人とやった時はすごくて、まずデザインの前にきちんと要件をはっきりさせてくれました。自分がちゃんと考えきれてなかったサイトの構造やボタンの位置にツッコミを入れてくれたりとか。みんながそれできるかっていうと厳しいですけど」
「今日登壇してる方たちもみんな通っている道ですね(笑)。めちゃくちゃのところからスタートして、だんだん良くなっていくという」
「それはあると思いますね。我々なんかの世代だとHTML3.2の時代からやっている人もいるので。以前はテーブルレイアウトというのがあって…」
「あー知ってます！昔やってましたよ、それ。一番最初にWebサイト作ったときに全部テーブルやりましたね」
「構造も何もあったもんじゃない(笑)」
「完全に見た目だけですよね。最近入社してきた若手なんかはテーブルレイアウト知らない世代でしたけど」
「ある意味うらやましいですね(笑)」
「昔はありだったんでしょうか」
「あるかなしかっていうと、なしだったんですけど。仕方がなかったっていうか」
「あれはフロートがなかったからとかそういうことだったんでしょうか」
「フロートがいつからあったかというのは難しい議論なんですけど、昔はブラウザのCSS周りの実装がボロボロだった時があって、IEでフロートすると横マージンが2倍になるとかありましたね」
「まぁ環境が整ってなかったというかんじですよね。だから一概にさっきの話も悪いとは言えないというか」
「Web標準が流行り出して、ブラウザの実装が統一されてきたのも、もう10年前くらいですね」
「モバイルが出てきてWebkitベースで確認できるようになって…」
「それ以前はもうぐっちゃぐちゃですよね」
「昔はできたデザインとマークアップした結果を重ねて、透過して1ピクセルもずれちゃいけないみたいな」
「ピクセルパーフェクトってやつですね！」
「聞いたことあります」
「昔は『全部のブラウザで同じ見た目にならないといけない』って時代があったんですよ。でも今はそういう時代じゃないですね、『デバイスによってちょっと違いますよね』ってのが当たり前になっているので」
「今はデバイスの種類がたくさんあるので、ピクセルよりも文字サイズはremとか、高さも%じゃなくてvwとか使うんでしょうか」
「状況によりますよね、使うべきときは使います。ちなみにそういう単位をどういうときにどれを使うのかという議論も、『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』に書いてありますので、もしご興味があればぜひ！」
「ぜひ、勉強します！」
「CSSが一番難しいですよね」
「同じことを実現する方法が結構いくつもあって、でもやり方によって結果がかなり違ってくるとか」
「僕CSS書いたら1万行くらいいってしまったことがあって…。さすがにディレクターの人に『俺でも3分の1にはできるぞ、書き方おかしい！っていうか、全部に対してCSS書いてるじゃん』って言われたことがあるんです。その辺のベストプラクティスもあるんでしょうか」
「今はセレクターの値の設定やファイルの指定とか、いろいろな方法が考えられてます」
「CSSについても書いてありますか？」
「そこまで深くはないかもしれないですけど、それなりにCSSについての議論は書いてあります。楽しい本ですよ」
「ありがとうございます！個人的にはすっきりしてきました。なんかもやもやしてたことに明確に答えが返ってきて、なんだか気持ちいいです」
「そうですよね。他の人ととりとめない話をすることがすごく勉強になるみたいなこと、結構あると思うんですよ」
「いろんなカンファレンスありますが、純粋に技術の話できるというのは面白かったなあと思います」
UIを考える時に一番気をつけるべきことは何ですか？
「そろそろまとめというか『オチ』に入っていきたいので、最後に質問をさせていただきます。UIを考える時に一番気をつけないといけないことって何でしょうか」
「ユーザーのことを考えるというのが一番重要だと思います。これでユーザーが実際に使えるのか、どんなユーザーがいてどんな環境でどう使うのかを意識することが大事なことなんじゃないでしょうか」
「僕もユーザーですね。いろんなユーザーがいるということを、いかに自分の中で学ぶかということだと思います。一番いいのは、いろんなサービス使ってみたりして、自分がいろんなユーザーになれることですね。例えば、日本だと回線は速いけど海外だと遅いとか、性能の低いデバイスしか売ってないとか。こんな良い端末でこんないい回線使っている人は世界中にはそんなにいないですよと。そういったことを想像して、自分がユーザーとして変化できることも必要だと思っています」
「そのとおりですね！今日はとても勉強になりました。本当にありがとうございました！」
「ありがとうございました！」
こんにちは、編集長の白石です。
この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に、様々なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。
今回お話を伺ったのは、Googleのえーじさんです。
えーじさんのセッションは「ウェブのための次世代決済法」でした。
スライド資料はこちらで公開されています。
Web Paymentsは（モバイル）Webの決済体験を変える
白石: 本日は、Web Paymentsについてお聞かせください。 Web Paymentsというのは、その名の通りWeb上での支払い体験を改善するものだと思いますが、そもそもなぜWeb Paymentsが重要なのでしょうか？
えーじ: それについては面白いデータがあります。
モバイルデバイス上で買い物が行われるのはもう一般的ですが、その3分の2はアプリじゃなくて（モバイル）Webサイトで行われているんですよ。
白石: へえ！スマートフォンだと、Webよりもアプリのほうが長い時間使われていそうですが、意外です。
えーじ: それだけじゃありません。今度はデスクトップWebとモバイルWebで支払いのコンバージョン率を比較すると、デスクトップのほうが2倍も高いんです。
これはつまり、モバイルWebサイトにユーザーはたくさんアクセスしているけど、買い物はデスクトップのほうがしやすいということです。
白石: 逆に言えば、モバイルWebサイトだと決済がしにくいってことですね。
えーじ: そうです。Amazonとか日頃から自分が使っているサイトであれば、クレジットカードの決済情報をあらかじめサービスが記憶しているので、決済はしやすい。
しかし、初めて訪れるサイトで買い物するとなると大変です。 クレジットカード番号や期限、3桁のセキュリティコードまで入力しなくてはならない。さらに、配送が必要な商品となると住所まで入力する必要が出てくる。
これだとめんどくさくて、途中で諦めてしまいますよね。個人的にも、モバイルで見つけた商品はとりあえずブックマークしておいて、デスクトップで決済するようなこともよくあります。
白石: 確かに。ではWeb Paymentsは、そういう決済に関する体験を改善するものだということですね。
えーじ: とりあえずはそうです。ただ、Web Paymentsが目指す世界はさらに先なんですよ。
クレジットカードは近い将来使われなくなるかもしれない
白石: というのは？
えーじ: そもそも、クレジットカードっていうシステムそのものが非常に脆弱なんですよね。プラスチックのカードそのものに、すべての情報が記載されているわけですよ。情報を盗むのも簡単だし、紛失したらおおごとです。
白石: 確かに…。
えーじ: そこで最近は、Apple PayやAndroid Payなど、スマートフォンにクレジットカード情報を搭載しようという動きが出てきました。
スマートフォンの端末には、指紋認証や顔認証を含めた認証機能があり、情報は端末内で安全に格納されるので、コピーができません。決済を行うには、端末が物理的に手元にある必要がある。しかも保存される番号も、クレジットカード番号そのものではなく、トークンと呼ばれる仮の番号です。仮に盗まれたとしてもリモートで無効化できるし、再発行の必要もないわけです。
このように、クレジットカードに比べてメリットが非常に大きいんです。近い将来物理的なクレジットカードは使われなくなると予想している人もいます。
白石: なるほど、ぼくはまだApple Payなどを使ったことがないんですが、そんなにメリットのある仕組みだったんですね。知りませんでした。
えーじ: 決済方法の進化は、これだけにとどまりません。仮想通貨や銀行間送金など、新しい支払い方法も次々に登場していて、「お金を右から左に移動する」ような取引のすべてで革新が起きようとしています。
Web Paymentsはこうした状況において、様々なプレイヤーをつなぐ「接着剤」のような働きになりつつある仕様なんです。
言ってみれば、新しいペイメントエコシステムを構築する上で欠かせないピースになると考えています。
白石: 現在の決済システムが抱える問題点を解決しようとする、壮大な話なわけですね。聞いていてワクワクします。
えーじ: なので、Web Paymentsはすごくたくさんの仕様から成り立っています。そのうち、現在でも実装が広く進んでいて、Web技術者が簡単に試せるのはPayment Request APIです。
Payment Request APIとは
白石: Payment Request APIとはなんですか？
えーじ: これが、最初に申し上げたWeb上の決済を手軽に行えるようにする仕組みです。
単純に言えば、クレジットカードや住所など、決済に必要な情報の入力をユーザーが簡単に行えるようになります。決済情報はブラウザが記憶してくれていて、ユーザーは事前に入力してある値から選ぶだけで、Webサイトに情報を渡すことができます。
基本的なコードは簡単で、以下のようにPaymentRequestのインスタンスを作ってshow()メソッドを呼び出すだけで、支払い情報を選択できるUIをブラウザが表示します。
var request = new PaymentRequest(methods, details, options);
request.show().then(response => {
// 支払い処理を行う
// PSP（決済代行業者）に送るなどして決済を完了
response.complete('success');
});
ここで、ダイアログの中ほどに「Android Pay」や「Visa」など、支払い方法を選択できる項目があります。これは、PaymentRequestのコンストラクタの第一引数として、支払方法の情報を渡すことで指定できます。
また、ダイアログに表示される情報は、PaymentRequestのコンストラクタの第二引数で指定することができます。購入商品の情報を渡すだけでなく、配送オプションを指定することも可能です。
コンストラクタの最後の引数は支払いに関するオプションです。配送先住所を必要とするかや名前、メールアドレス、電話番号の情報を要求するかどうかなどを指定できます。
これらを指定して表示されたダイアログ上でユーザーが入力を終えると、プログラムにユーザーが入力した情報が渡ってきます。 プログラムはこれらの情報をサーバーに送信するなどして、決済を完了するわけですね。
白石: なるほど、Payment Request APIそのものは、使うのは全然難しくなさそうですね。先ほど、実装が進んでいると仰ってましたが、現在どのブラウザで利用できるんでしょうか？
えーじ: Chromeは、iOSを含む全プラットフォームで利用できます。他にもChromiumをベースに開発されているSamsung Internet BrowserやMicrosoft Edgeでも利用できます。Firefoxでは開発中ですね。あと、Safari上ではApple Pay JSという、Apple Payを利用するためのAPIが存在するのですが、それをPayment Request APIでラップしたライブラリも存在します。嬉しいニュースとしては、Safariも現在Payment Request APIを実装中ということです。
白石: おお、もうかなりのブラウザ上で動作するんですね。
えーじ: あと、Payment Request APIがどういう動作をするかを試してみたかったら、polykart.storeというデモサイトがあるのでアクセスしてみてください。商品を選んで「BUY NOW」を選択すれば、Payment Request APIを使用した支払い用ダイアログが表示されます。もちろん、実際に決済が行われるわけではありませんのでご安心ください。
Web Paymentsが目指す世界——新しいペイメントエコシステム
白石: しかし先ほどのコードでちょっと気になったのは、結局クレジットカード番号とかをプログラムが直接受け取るという点です。 セキュリティコードも含め、決済に必要な情報を全部Webサイトに渡してしまうのは何か怖いというか。まあ、現在でも一般的に行われていることではあるんですが。
えーじ: PaymentRequestに渡すペイメントメソッドに’basic-card’を指定した場合、クレジットカードの情報を生で受け取るように動作するんですよね。
‘basic-card’の仕組みはわかりやすく、どんな決済代行業者でも扱えるという点ではいいのですが、おっしゃるとおりセキュリティ面での懸念があります。ペイメントの未来はそこにはありません。
そこで登場するのが、生のクレジットカード情報ではなく、使い捨てのトークンを利用するという方法、つまり先程お話したApple PayやAndroid Payで利用できるトークンのことです。こちらの方法なら安全性も高まりますし、ECサイト側も、クレジットカード情報に触れる必要がないので助かるんです（※）。
※ ECサイト側も助かる…経済産業省が取りまとめたクレジットカード取引におけるセキュリティ対策の強化に向けた実行計画2017により、ECサイトはクレジットカード情報の非保持化、もしくはカード情報を扱う場合はPCI DSS（※）に対応しなくてはならない。
※ PCI DSS（Payment Card Industry Data Security Standard）…カード会員情報の保護を目的として、国際ペイメントブランド5社（アメリカンエキスプレス、Discover、JCB、マスターカード、VISA）が共同で策定したカード情報セキュリティの国際統一基準
白石: これは素晴らしい。ぼくらWeb技術者がこの仕組みを利用するとしたら、どうしたらいいんですか？
えーじ: PaymentRequestに渡すペイメントメソッドには、URLを渡すというもう一つの方法があるんです。こちらの方法を用いると、支払いを行うにあたって、外部のペイメントアプリケーションを呼び出すことができます。
白石: 先ほどのコード例でも、https://android.com/payというURLを渡して、Android Payが表示されていましたね。
えーじ: こちらの方法を用いると、トークン化の処理を含め、複雑な処理は全て裏で行われ、Webアプリは戻ってきたトークンを使って決済処理を完了させるだけで済みます。
白石: セッションスライドの、ペイメントアプリを通じてトークンをやり取りする図を見て、複雑なので怖気づいてたところでした(笑)。
えーじ: この図の、企業間の提携などについては企業間で行われることですし、Web技術者の手をわずらわせることはありませんのでご安心ください。
ちなみに、ペイメントアプリケーションは技術的には誰でも作ることができます。なので、クレジットカードに限らない支払い方法、例えば仮想通貨やキャリア決済なども将来的にはPayment Request APIから扱えるようになるというわけです。
ペイメントアプリケーションを指定するのには、先ほども申し上げたようにURLを使用するので、基本的にはWebアプリです。ですが、Web Manifestの仕組みに対応していれば、ネイティブのAndroidアプリを呼び出すことも可能です。
BobPayという、ネイティブ、Webどちらにも対応したペイメントアプリのサンプルがありますので、よければ試してみてください。Web版はAndroid版Chrome Dev、ネイティブ版はChrome 60以降がインストールされたAndroidであれば試すことができます。
白石: 支払い方法はよりセキュアに、多様化するということですね。そのために、業界全体が変化しようとしている。まさに新しいペイメントエコシステムですね。
本日は、大変勉強になるお話をありがとうございました！
]]>こんにちは、編集長の白石です。
この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に、様々なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。
今回お話を伺ったのは、Googleの山口能迪（やまぐち・よしふみ）さんです。
山口さんのセッションは「AMPで加速するモバイルウェブアプリケーション」でした。
スライド資料はこちらで公開されています。
https://docs.google.com/presentation/d/1ZYyHFRMZnD6bfi6fl9yh9G_TIs3roSxvp-Goa1JZv_c/htmlpresent
AMPとは何か？なぜ必要とされたか？
白石: 今日はよろしくお願いします。まずは簡単に自己紹介をお願いできますか？
山口: Googleでパートナー・デベロッパー・リレーションを担当している山口です。私の役目は特定の技術にとらわれず、最新の技術を広めていき、採用事例を増やすことです。
白石: 最新技術って、Googleさんすごい数出すから大変ですね(笑)。
山口: そうなんですよ(笑)。
白石: では、早速本題に入っていきたいと思います。AMPについてご存じない方のために、軽く説明をお願いできますでしょうか？
山口: AMPとはAccelerated Mobile Pagesの略で、高速にWebページを表示するための技術です（参考: AMPの公式サイト）。
現在のWebは、低速なインターネット上で、モバイルデバイスを用いた利用が非常に多くなっています。特に東南アジア、インドやアフリカ、中国、南米などでその傾向は顕著です。
そういう環境でもWebページをストレスなく閲覧できるよう、Web標準に則った形で、出来る限り高速にWebページを表示できるようにするための技術がAMPです。
白石: なぜAMPは速いのですか？
山口: AMPは速いというよりも、「遅くなる要素を排除している」と言ったほうが正しいと思います。AMPは主に静的で文字中心のコンテンツを配信することを主眼に、HTML5でできることを相当絞り込んだ仕様です。その仕様に則ったHTMLページだけが、妥当なAMP対応ページとして扱われます。
そうした制限のおかげでページサイズも小さくなり、ブラウザによるレンダリングも高速に行われるというわけです。
白石: 具体的には、どのような制限がかけられているのでしょうか？
山口: 例えば、標準のimg要素やvideo要素は使用できず、すべて<amp-img>や<amp-video>と言ったカスタムタグに置き換える必要があります。こうした要素を使うことで、全ての画像や動画が遅延表示され、また、画面に表示されない間はダウンロードされなくなります。
CSSは外部CSSもstyle属性も使用することができません。全てHTML内に<style>を用いてインラインで記述しなくてはなりませんし、そのサイズも50kbに制限されています。
JavaScriptに至っては、独自のコードを記述することはできません。AMPページでは、動的な振る舞いはすべてカスタムタグを使用して実現することになります。
<!-- AMPページの例 -->
<!doctype html>
<!-- html要素に⚡を付けるとAMP HTMLとして扱われる -->
<html ⚡>
<head>
<meta charset="utf-8">
<!-- AMP用JSの読み込み -->
<script async src="https://cdn.ampproject.org/v0.js"></script>
<title>Hello AMP world</title>
<!--
このAMPページの元となる、通常のHTMLページがある場合はcanonicalで指定
そういうページがない場合はこのページ自体のURLをcanonicalで指定
-->
<link rel="canonical" href="hello-world.html">
<!-- viewport指定は必須 -->
<meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
<!-- 以下のCSSは必須 -->
<style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
</head>
<body>
<h1>Hello AMP World!</h1>
<!-- imgの代わりにamp-imgを使用 -->
<amp-img src=sample.jpg width=300 height=300></amp-img>
</body>
</html>
白石: カスタムタグにはどのようなものがあるんでしょう？
山口: 利用できるタグはすべてドキュメントに記載されていますので、そちらをご覧いただくのが一番です（参考: AMPで利用できるコンポーネント/タグ）。
AMPのタグにはビルトイン（組み込み）とエクステンション（拡張）がありまして、エクステンションのタグを利用するには別途JavaScriptの読み込みが必要です。
ビルトインのタグの代表的なものは、先ほど取り上げた、<img>の代わりとなる<amp-img>です。エクステンションは現時点でもかなりの数が用意されていて、Google Analyticsを使用したり、YouTubeやTwitterの埋め込みを行えるタグもあります。
白石: そうしたエクステンションは、サードパーティの開発者やベンダーでも開発できるんですか？
山口: はい、可能です。ただ、AMPで利用できるタグは、AMP本体のリポジトリに取り込まれているものだけなんです。なので、開発したとしてもそれをリポジトリに取り込んでもらう努力が必要になります（参考: コンポーネントの開発・拡張についてのドキュメント）。
白石: なるほど、そういうプロセスを経なければならないようにすることで、カスタムタグのクオリティを担保しているということですね。そういうレビューはGoogleが行っているんでしょうか？
山口: AMP自体はオープンソースですし、Google一社のものではありません。リリース前からTwitterやPinterestもコミットしていましたし、オープンソースにしたおかげで、プロセスも透過的です。Google以外のコントリビューターも数多くいますし、そこは一般的な企業発のオープンソースプロダクトとあまり変わりはないと思いますね。
AMPページのアクセス解析は？広告は？
白石: AMPはWeb全体に大きな影響を与えている技術だと思いますので、ビジネス面も含めた、もう少し俯瞰的な部分からもお話をお聞きしたいと思います。
まず、AMPに対応すると、Google Analyticsなどの計測を正しく行えなくなるというのを聞いたことがあるのですが、これはどういうことですか？
山口: まず、<amp-analytics>タグを入れているAMPページは、Google Analyticsをはじめとしたツールで、統一的に計測を行うことができます。
ただそれでも、AMPキャッシュの仕組みの都合上、様々な不都合が生じていたのは事実です。
白石: AMPキャッシュというのはなんですか？
山口: GoogleのbotはAMPページを見つけると、専用のキャッシュサーバー（Google AMP Cache）にページをキャッシュします。 Googleは世界中にデータセンターやISP各社に協力していただいているエッジサーバーを持っており、ユーザーにとって物理的に最も近い位置のサーバーからページを読み込みますので、AMPページがより高速に表示されるというわけです。
（筆者注: Google AMP CacheはAPIを用いて明示的なキャッシュを行わせることもできる）
白石: Googleの検索結果から辿れるページとかは、AMPキャッシュからの応答ですね。
山口: ただ、AMPキャッシュの問題は、元サイトとは異なるドメインからページが読み込まれるということです。そうなるとCookieが異なるので、Google Analyticsなどで正しく計測が行えないのです。
（筆者注: 例えば 当サイト（https://html5experts.jp）のAMPページは「https://html5experts-jp.cdn.ampproject.org」から読み込まれました）
ただこの問題は、今ではほぼ解決されています。具体的には、Cookieの欠点を補うためのクライアントIDという値を用いることで、AMPキャッシュから配信されたページへのアクセスと、オリジナルサイトへのアクセスを統一して扱えるようになっています。
筆者注: こうした問題とそのソリューションについては、以下のページに詳しい。
- AMPページの直帰率の高さやユニークユーザー数は全部ウソ!? AMPアクセス解析には潜在的な問題あり – 海外SEO情報ブログ
- ⚡AMPの不正確なアクセス解析をGoogleアナリティクスが解消 – 海外SEO情報ブログ
- Google アナリティクス、AMPキャッシュ計測の問題を解決。AMP Client ID APIのオプトインで正確なアクセス解析が可能に – 海外SEO情報ブログ
- Client IDs in AMP pages – Googleアナリティクスヘルプ（日本語ページもあるのですが内容が古く、「Using a single Client ID across AMP and non-AMP pages」（AMPと非AMPページで同一のクライアントIDを使用する）という重要な節が抜けているようです）
白石: なるほど、アクセス解析の問題については、ほぼ解決済みなのですね。知りませんでした。
ほかには、AMPに対応することでパブリッシャーの広告収益に影響が出るのではないかという話を聞きましたが、これについてはいかがでしょうか？特に、AMPページに比べて広告の表示速度が遅いことで、広告が表示される前にユーザーが離脱してしまうのではないかと聞いています。
山口: 実はAMPは、広告の高速化についても「AMP Ads」（筆者注: 「AMP for Ads (A4A)」とも呼ばれる）という取り組みを既に進めているんです。
これは、広告コンテンツについてもAMPフォーマットで記述するというもので、従来よりも素早く表示されるだけでなく、AMPページ以外でも利用できますし、様々な広告ネットワーク上でも利用できる柔軟性があります。
参考: AMP Ads の読み込みがさらに高速化 – Google Developers Japan Blog AMP Ads – GitHub (英語)
白石: そんな取り組みがされてたんですねー、全然知りませんでした。
AMPとPWAを組み合わせる
白石: 最後に、技術者向けに深いトピックをいろいろお聞かせください。
AMPとPWA (Progressive Web Apps)を共存させる、という話を聞きます（※）が、具体的にはどのように組み合わせることができるのでしょうか？
※ Combine AMP with Progressive Web Apps
山口: AMPは、言ってみればWebプラットフォーム上のフレームワークの1つに過ぎません。なので、例えばWebアプリマニフェストを書いておいて、AMPページからリンクすれば、モバイルアプリにWebアプリをインストールさせることも可能です。AMPだからと言って、特別なことは何もありません。
白石: なるほど。
山口: PWAと言うのはマーケティングワードという側面も強いので、「何を持ってPWAと呼ぶか」も難しいところではありますけどね。
AMPには<amp-serviceworker>というタグもあって、AMPページを起点にしてServiceWorkerをインストールさせることもできます。
これを応用すれば、まずはAMPページを高速に表示させておいて、裏でPWAに必要なアセットをServiceWorkerを利用してキャッシュしておき、リンクをクリックしたらPWAが高速に起動する…というアプローチも取ることができます。
白石: AMPとPWAのいいところ取りができるというわけですね。面白い。
あと、「PWAの中でAMPを使う」というアプローチも聞きました。外部のページをAMPで読み込むと言ったような。
山口: それも可能ですね。AMPをiframeで開くというのが一つのパターンですが、更にもう一歩進んだアプローチとしては、外部のAMPページを読み込んで、Shadow DOMに突っ込んじゃうっていうパターンもあります。
白石: それってどういうメリットがあるんですか？
山口: これも高速化のテクニックの一つですね。iframeだと、AMP JSの読み込みがiframeごとに走るので無駄が多いんです。Shadow DOMに埋め込むのであれば、既に元ページでAMP JSが読み込まれていればいいので、それぞれのページで読み込む必要がありません。
白石: なるほど、面白い！
山口: これはAMPに限った話ではないのですが、従来iframeを使って読み込んでいたコンテンツを、Shadow DOMに埋め込むというテクニックは、広告とかにも応用可能です。広告が元ページに悪影響を及ぼさないようにカプセル化する役割を、Shadow DOMに任せるわけですね。
白石: いやあ、最新のWeb技術てんこ盛りで、Webエンジニアとして大変興味深いお話です。AMPそのものも、そしてAMPを支える技術も、最新技術の塊ですね。本日は大変勉強になりました、ありがとうございました！