みなさん、こんにちは。Google Cloud Solutions Architectの中井です。

HTML5 Conference 2016では、「Webアプリケーションにおける機械学習活用の基礎」と題して、機械学習の基礎となる仕組み、そして、機械学習を利用したクライアントアプリケーションの例を紹介させていただきました。今回は、この発表の内容を振り返りたいと思います。

機械学習とディープラーニング、そして、AIの関係

機械学習そのものは古くから利用されている技術であり、過去のデータを元にして、「（まだ見たことのない）未来のデータにもあてはまる一般的なルール」を発見することがその役割となります。つまり、はじめて見るデータに対して、何らかの予測を立てることができるようになります。たとえば、映画のレコメンデーションシステムであれば、新しいユーザーのプロファイルデータから、そのユーザーが高い評価を付けるであろう作品を予測します。

ただし、これはあくまでも予測ですので、必ず正解するというわけではありません。予測の精度をいかに上げるかが機械学習の課題となります。そして、近年のディープラーニングの発展により、一部の領域においては、その予測精度が格段に向上しました。プロの棋士と同等、あるいは、それを上回る精度で「勝利につながる一手」を予測する囲碁プログラム、本物の人間であるかのように、あるメッセージに対する「自然な応答メッセージ」を予測するチャットボットなど、中の仕組みを知らない人間からすると、あたかもコンピューターが「知性」を持っているかのように感じられるレベルにまで達しています。

ちなみに、最近、各種メディアでは、「AI（人工知能）で◯◯を実現」というタイトルを目にすることがあります。しかしながら、何を指して「AI（人工知能）」と呼んでいるのかが曖昧なことも少なくありません。AI（人工知能）もまた長い歴史を持つ研究分野であり、AI（人工知能）の定義にもいくつかのパターンがあるようですが、現代的な文脈では、「あたかも知性を持っているかのように感じられる製品やサービス」を指して、AI（人工知能）と呼んでいると考えるのが適切かもしれません。

そのような製品・サービスを実現する上で、高い精度での予測を実現するディープラーニングは、欠くことのできない中核技術になりつつあるということでしょう。（これは余談ですが、個人的には、「AI（人工知能）で◯◯を実現」というタイトルを見るたびに、心の中でそっと、「AI（知性を持ったかのように見える製品やサービス）を実現するために研究・活用が進んでいる機械学習を基礎とした一連のデータ収集・分析技術で〇〇を実現」と読みかえて納得することにしています）

「線形2項分類器」で機械学習の基礎を学ぶ

この発表では、まずはじめに、機械学習の基礎となる「線形2項分類器」、そして、それを実現する「ロジスティック回帰」のアルゴリズムを解説しました。下図のように平面ちらばった◯✕の2種類のデータに対して、これらを分類する直線を自動的に見つけ出すという問題です。

そして、機械学習の世界では、主に「確率」を用いた予測が行われます。下図のように、求めるべき直線を関数 f で表した後に、ロジスティック・シグモイド関数 σ を用いて、「あるデータが『✕』のタイプである確率」を計算します。この計算式には、未知のパラメーター（w0, w1, w2）が含まれており、既存のデータに対する予測精度が最大化されるように、これらのパラメーターを自動調整するということを行います。

自動調整に用いられるアルゴリズムの詳細は、ここでは割愛しますが、たとえば、「Neural Network Playground」を利用すると、実際のチューニングの様子を観察することができます。これは、TensorFlowの動作をJavaScriptでエミュレーションしたもので、機械学習の処理が進む様子をブラウザー上で観察することができます。会場では、参加者の方々にも、実際にリンクを開いて機械学習の動作を体験していただきました。

「線形多項分類器」で文字認識に挑戦

先ほどの例では、◯✕の2種類のデータを分類しましたが、これをより多数の種類に分類できるように拡張したものが「線形多項分類器」です。たとえば、3種類に分類するのであれば、下図のように、3つの１次関数を用意します。そして、どの１次関数の値が最も大きいかによって、領域を分類します。ちなみに、(x1,x2)平面上で１次関数がとる値を3次元のグラフに表すと、1枚の平面になります。したがって、3枚の平面を配置して、どの平面が一番上に来るかで領域を分類していると考えることができます。

ただし、前述のように、機械学習の世界では「確率」で予測を行う必要があります。それぞれの1次関数の値を0〜1の確率に変換するのが、下図の「ソフトマックス関数」です。ここでは、簡単化した1変数の例を図示してありますが、f1, f2, f3の値の大小関係が、きれいに確率の大小関係に変換されていることがわかります。会場では、この仕組みを用いて、画像データの分類を行うデモを紹介しました。

ここで使用したのは、MNISTデータセットと呼ばれる手書き数字の画像を集めたデータセットです。それぞれが28✕28=784ピクセルのグレイスケールの画像になっており、1つの画像データは、784個のピクセル値（各ピクセルの濃度の値）からなります。そして、784個のピクセル値からなるデータは、784次元空間の1つの点に対応すると考えることが可能です。

いきなり784次元空間が登場して驚くかも知れませんが、それほど難しい話ではありません。3次元空間の点は、(x,y,z)の3つの数値で指定することが可能です。これと同じように、784次元空間の点は、784個の座標値で指定することができます。そして、大量の画像データを784次元空間にばらまくと、下図のように、同じ数字の画像は互いに近くに集まって、クラスターを形成すると想像することができます。

仮にこの想像が正しければ、線形多項分類器を用いて、784次元空間を10ヶ所の領域に分割することで、画像の分類が可能になります。新しい画像データが与えられた場合は、それがどの領域に入るかによって、どの数字であるかを予測することができます。

下図は、TensorFlowを用いて実装したコードで実際に分類を行った結果です。ここでは、トレーニング用のデータセットで学習した後に、テスト用のデータに対して予測を行っています。正解例だけを見ていると優秀な結果にも見えますが、不正解例を見ると、わりと単純なミスを犯していることもわかります。

これは、ピクセルの配置情報だけを用いて分類を行っていることが原因です。たとえば、上図における、上から2段目の右端の例が特徴的です。この縦長の「6」は、ピクセルの並びだけを見ていると「1」に近いため、「1」であると誤分類されています。人間が数字の種類を判別する際は、単純なピクセルの並びだけではなく、「穴が空いている」などの空間的な情報も利用します。この分類の精度を向上するには、このような、ピクセルの並び以外の特徴を取り出す必要があるのです。

「畳込みニューラルネットワーク」による性能向上

画像認識において、画像の空間的な特徴を取り出すのに役立つのが「畳込みフィルター」です。下図に示す「畳込みニューラルネットワーク(CNN:Convolutional Neural Network）」では、事前に畳込みフィルターを用いて、画像の特徴を抽出した後に、それを用いて多項分類器（ソフトマックス関数）による分類処理を行います。

ただし、どのようなフィルターを用いれば、分類に役立つ特徴が抽出できるかを考えるのは簡単ではありません。実は、CNNでは、フィルターを構成するパラメータ値も機械学習の対象としてしまいます。はじめは、乱数で用意したフィルターを用いて判別処理を行います。当然ながら、判別精度はそれほど高くありません。この後、判別精度が向上するように、フィルターのパラメータ値を自動的に調整していきます。

会場では、この処理を実行するTensorFlowのコードを紹介した上で、学習結果を用いた簡易的な「手書き文字認識アプリ」をデモで紹介しました。下図は、入力画像に対して、「0」〜「9」のそれぞれの数字である確率を表示している例になります。

参考資料

当日の発表では、このような機械学習を活用したアプリケーションの例、あるいは、今後想定される利用パターンなども紹介させていただきました。興味のある方は、当日の発表資料を参考にしてください。

また、発表の中では、線形多項分類器やCNNのパラメータを自動調整するアルゴリズムの解説までは手が回りませんでした。これらの理論的背景に興味のある方は、下記の書籍も参考にしていただければ幸いです。

• ITエンジニアのための機械学習理論入門 中井悦司（著）（技術評論社）
• TensorFlowで学ぶディープラーニング入門 中井悦司（著）（マイナビ出版）

HTML5 Conference 2016特集・第5弾は、「Unity WebGL入門」です。WebGL正式対応により、ゲームをはじめとしたブラウザコンテンツ制作ツールとして広く使われるようになったUnityの概要及びWebGLへの書き出しについて解説します。

WebGLにも対応したUnityのいま

Unityは統合的なインタラクティブコンテンツ制作ツールです。

無料で使えるPersonalから文字通りプロフェッショナルのためのProまで3つのサブスクリプション・プランを用意していますが、根幹となるUnityエディタの機能はどのプランも同一のものとなっており、対応プラットフォームにも違いがありません。つまり、Personalでも強力な3D表現が実現できてしまうのです。

そして2015年末にリリースされたバージョン5.3より、Unityは正式にWebGLに対応し、ゲームを始めとしたブラウザ上でのリッチコンテンツの作成環境として広く使われるようになりました。その後も着実に進化を続け、次期バージョンである5.5ではWebAssembly対応による飛躍的なパフォーマンスの向上が見込まれています。本稿ではUnityのWebGLの概要に始まり、実際にコンテンツ開発を始めるにあたって注意すべき点などを紹介します。

パフォーマンス

Unityをコンテンツ開発の選択肢に挙げるにあたりユーザー最も気にするのは「どの程度のものが作れるのか」という話ではないでしょうか。結論から言うと、iOSやAndoriodなどのUnity製のモバイルネイティブアプリと概ね近しいクオリティが得られます。

特にグラフィックの表現力はWebGL2.0をブラウザでの正式対応に先んじてサポートしており、Unity内で一般的な3Dオブジェクトに使われるStandard Shaderでの描画能力はモバイルよりもデスクトップに近く、ソフトシャドウを使うことも可能です。

反面、マルチスレッド非対応やヒープ領域の制限、ファイルシステムを持たないなどの理由によりCPUとメモリはボトルネックになりやすく、パフォーマンスを引き出すためにはそれらを考慮した実装を考える必要があります。

また、スマートフォンなどのモバイル版ブラウザは現在のところ未対応となっており対応時期も未定です。シンプルなプロジェクトであれば大きな支障なく動作することもありますが、「まあ動くこともある」程度に捉えていただくのが無難です。

Unity WebGLを支える技術

WebGLで実行するためにはコードがJavascriptで書かれている必要がありますが、UnityはEmscripten コンパイラーツールチェーンを使用し、CおよびC++で記述されているUnityのランタイムコードをビルド時にasm.js JavaScript にクロスコンパイルしています。

ams.jsとは高速化を目的としたJavaScript言語仕様のサブセットであり、事前コンパイル（AOT）された形で実行されます。過去にはFireFoxのみに対応していたこの技術も今や多くの主要ブラウザが対応しており、ブラウザ間でのパフォーマンスの差は徐々に埋まりつつあります。また非対応のIEではパフォーマンスに大きな難を抱えています。

では、開発者が記述することになるユーザーコードはどうでしょうか。Unityは.Net互換のMono環境で実行されるので、ユーザーはC#あるいはUnity独自の言語であるUnity Scriptでの開発がメインとなります。

Unityはビルドする際、通常は書き出されたCIL（中間言語）をmonoのランタイムにより各プラットフォームのネイティブコードに変換するわけですが、WebGLをターゲットとした場合はUnityの独自技術であるIL2CPPにより一旦C++に変換し、その後はUnityのランタイムコードと概ね同じ手順でJavascriptに変換されます。

IL2CPPはUnityが多くのプラットフォームに展開、そして最適化するための重要な技術です。

Unityでの設定のポイント

WEBコンテンツである以上、ビルドサイズを少しでも削減することは大きな課題と言えるでしょう。

エンジンコード、及びユーザーの記述したコードについてはリリースビルドとして書き出すことで縮小化、gzip圧縮され、ダウンロード後にブラウザ上で解凍、及びパージングして実行されます。さらにStrip Engine Codeオプションにより使用しないエンジンの機能をあらかじめ削除しておくことができます。

シーンファイル及びシーン内で使用されるアセットはアーカイブデータとして通常1ファイルにまとめられます。

サーバからは上記同様gzip圧縮したものをブラウザ上で展開し、得られたファイルはさらにLZ4形式で圧縮されています。ブラウザのタブを閉じるまでメモリ内にストックされ、使用すべきアセットがロードするときだけ解凍される仕様です。

しかし2種類の圧縮がかかっているとはいえ大量のテクスチャやサウンドを含むデータをコンテンツ開始時に一度にロードさせ、メモリ内に保持し続けることは得策ではありません。ダウンロード時間とメモリ使用量の削減を両立させるためにはhtmlから直接参照されるアセットを最小限に留め、それ以外をAsset Bundleで提供することが望ましいと言えます。

Asset Bundleは簡単に言うとアセットをシリアライズしたアーカイブファイルです。実行時にサーバからダウンロードして利用するため読み込みのタイミングを管理し、必要なくなったタイミングで破棄し、メモリを解放することができます。使用の際は通常アセット同様にチャンクベースの圧縮形式LZ4が多くのケースで有用です。

Unityの提供するサービスとの連携

前述した通り、WebGLへのビルドは複雑な手順で行われており、他のプラットフォームに比べ時間を要します。CIサーバを用意して自動化するという解決法もありますが、もっと手軽な方法としてUnityはクラウド上でビルドを行うサービスを提供しており、サービス内容に差はあるものの全てのプランで無料提供されています。

GitやSubversionなど広く使われるソースコントロールであればリポジトリを更新するだけで自動的に行われ、書き出されたURLを伝えればどこからでも確認できるようになります。またAssetBandleのビルドもサポートしており、開発効率を上げるためには欠かせないサービスとなっています。

その他にもユーザーの環境や動向を分析するUnityアナリティクスや、Unityエディタに統合された簡易的なソースコンントロールであるUnityコラボレイトなど、Unityの提供するサービスは広がり続けています。

まとめ

冒頭でも述べましたが、Unityは統合的なインタラクティブコンテンツ制作ツールであり、WebGLを構築するためのJSライブラリ等とはアプローチが大きく異なります。

特に3Dビューに慣れていない方は最初は戸惑われるかもしれません。しかしユーザー数やコミュニティに後押しされる形で多くの情報をWebで手軽に入手できるほか、チュートリアルや入門書籍なども充実しています。一度是非お試しください。

Unity – Game Engine

当日の資料と動画は下記で公開されていますので、こちらも参照してください。

• 講演資料

HTML5 Conference 2016の展示ブースでお届けしたカンファレンス ラジオコーナー。Increments及川卓也さんとヤマハ河合良哉さんがゲストに来てくれた「地方で日本で働く・海外で働くの話」を完全版テキストの後編をレポートします！

日本と海外の違いの話

前編に引き続き、ゲストはIncrements及川卓也さんとヤマハ河合良哉さんです。

「実際に今年海外に行かれて困ったことや、こういうところが違うの？とか、びっくりしたエピソードがあればお聞きしたいのですけれど、何かギャップとかありますか？日本のカルチャーと（比べて）」

「ギャップですか？」

「はい。例えば、僕が一番気になるのは食べものとかです。海外の姿は想像ではあるんですが、日本だとそこらへんに自動販売機やらコンビニやらがあって、買いたいジャンルのものがすぐに手が届くところにいっぱいある。たぶん海外というか、今お勤めされているサンフランシスコは土地も広いこともあるし、そういうのはないんじゃないかなって思って。

「そうなんです。そこおっしゃる通りで、日本に帰ってきていつも便利だなって思うのがコンビニエンスストアの存在なんですね。アメリカにもコンビニエンスストアはあるんですけど、そこに陳列されているものが全然違ってるんです」

「日本だとちょっと小腹がすいたなって思うとおにぎりだったり、サンドイッチや菓子パンは大体100円とか200円くらいで手に入るというのが大体じゃないですか。向こうに行くとおにぎりとか、サンドイッチとか…おにぎりはないにしてもサンドイッチとかは結構な値段しちゃったり。買って食べると、えっこれすごいまずいみたいなのがあったりして。気軽に買えないんですよね、怖くて。逆にがっかりしちゃうことがあるので（笑）」

「こっちで買うような気持ちで、サンドイッチ買うっていうことはできないんですね」

「やめたほうがいいかなと（笑）。そこは日本に帰ってきてすごい便利だなと思いつつ、便利すぎて日本に帰ってくるといっぱい食べちゃうんで、夜寝るときなんか胃がもたれてるなとか」

「なんかアメリカのそういったコンビニにとかで売ってるやつって、見た目からしてまずそうですよね」

「そうですね」

「見た目あまりこだわらないじゃないですか」

「こだわらないですね」

「こだわるときはなんかカラフルな感じになっていて、これはこれで食べたらまずそうな感じだなって（笑）」

「本当M&M’sの配色の感じですよね。もうすごい赤とか、すごい黄色とか」

「なんか脳の奥の方でこれ食ったらダメだよって、自分に語りかけてるようなものしかないんですよね（笑）」

「そうですね（笑）」

「色に対する感覚が違うんですかね？」

「原色が好きなんじゃないですか？知らない（笑）」

「原色系本当多いですよね。例えば食べ物の話じゃないですけど、MicrosoftのWordとか開いて、1番最初に図形とかパッと入れるとすごく緑の色が出てきたりするわけですよ。これすごい昔から不自然だなって思ってたんですけど、アメリカのそういう食材とか見ると、なるほどなって逆に納得しちゃって（笑）」

「そういうことですか」

「おそらく。だから色に対する感覚が、日本人と違うところは間違いなくありますよね」

「やっぱり、普段慣れ親しんでいる色がそういう配色のものが多いという環境による要因なのか、人種による気質がそうなっているのかというと、どっちなんでしょうね？それはわからないですね」

「どうなんでしょうね」

「とりとめのない質問をしてしまって、今は反省しています」

年齢が違う人とのコミュニケーション

「この後、僕らはどこにいく感じになるんですか？」

「えっとですね…」

「別に早く終われって言っているわけじゃないですよ。まだ全然話してもいいんだけど、この議論はどこに流れ着くのかなと思って（笑）」

「本来僕がここでやらなきゃいけないのは、ゲストのお二方の面白い話を伝えないといけない」

「今ね、加藤くんが面白い人になっているから（笑）」

「ごめんなさい。では、みんなが聞きたいんじゃないかなって思ったことを及川さんに質問していいですか？」

「いいですよ」

「去年転職されて大きく環境が変わったと思うんですけど、お若い方が多い会社に入られたじゃないですか。年齢が違うと、共通の話題だったり当時流行っていたものも違うと思うんですけど、年齢が違うことでコミュニケーションが難しい部分があったりするんでしょうか？」

「たぶんね、みんなが気使ってくれるんですよ。だからあまりそういうので困ったことはないですね」

「なるほど（笑）」

「長老が入ってきたという感じで、一生懸命おじいちゃんから聞いた話とかを思い出して話してくれるから」

「皆さんとは飲みに行ったり、遊びに行ったりするんですか？」

「そうですね。でもね、真面目な話わからないというか、今同じ世代でも趣味が違ったら全然話通じなかったりしません？昔って、視聴率30%取ったようなドラマがあったらみんなそれ見てるとかってあるけど、今は高校の時見てたドラマで全員に絶対通じるものってなかったりすると思う。趣味が違った人とはあまり通じないっていうことは、普通だったりするんじゃないかなって思うんですよね」

「なるほど」

「あまり困らないし、わからなくても別に気にしないし、そこで教えてもらえればいいかな。それ何？って言って、あーそんなのあったんだ、その頃俺何やってたかなー？みたいな感じで。で、気にせず僕、昔の話ガンガンしますから（笑）」

「素直にやり取りできるのってすごく大事ですよね。そういった謙虚さってすごいです」

新しい技術に対する取り組み方の違い　

「僕は仕事が変わって、学生とやり取りすることが多くなったんですけど、彼らってどんどん新しいことをやろうとするのに物怖じしない子が多いなと思って。新しい言語が出たら、『よしやってみよう！』ってやるんですけど、僕だと『これいつまで使えるのかな？』とか、『実際これ覚えたとして何の役に立つんだろう？』とか考えてからやっちゃうんですよ」

「彼らは、『それ面白い使ってみよう、動いた！』って。で、どんどんやっていくっていうので、なんか自分歳をとったなって感じることがあって。一概にそういうわけじゃないですけど、年齢が離れれば離れるほど物事に対する取り組み方って変わってくるのかなって思って」

「でも、技術がずっと使われるかどうかなんて全然わかんなくって、僕だって大学時代に使ってたのってFortranですけど、今Fortranなんて全く忘れてる。10年くらい前Web系のやつやっていた時はPerlだったけど、Perlもほとんど覚えてないし、その時にFortranが自分の30年後、40年後も使ってるかなんて考えたこともないし」

「Perlの時だって別にそこまで考えたわけじゃなくて。そこはあまり気にしないし、逆に、大きく内容が違うならともかく、技術ってどこかで関連性があるから一つの技術を覚えた時に、ここの応用だとか、これはここでいう何だっただろうってことを考えるだけで飲み込みが早いってことは多いと思うんですよ。プログラム言語じゃない話をすると、僕OSを作ってたわけですよね、Microsoft時代に」

「はい」

「今Webブラウザって結局はOSなんですよ。中でやっているものっていうのは、普通にスケジュール管理みたいなものもあれば、スレッド管理みたいなものもある。メモリ管理みたいなものもあるし、ガベージコレクションどうしようとかっていうところとかって中で普通にガチガチ入ってたりするわけですね」

「そうすると、ブラウザがOS化してくっていう流れになった時に、OSを作っていた時のいろんな知識だとか経験って役に立つんですよね。たぶんそれプログラム言語でも一緒ですし、ネットワークプロトコルでも一緒だし、なんでも同じだと思うんですよ。例えば、ネットワークって昔TCP/IPが流行る前とかっていうのは、普通にシリアルコネクタRS232Cっていうのがあったんですよ」

「はい」

「その上で、パソコン通信のためのやり取りだとか、ファイル転送のプログラムがあるわけですよ。Kermitって言われているのがあって、僕はKermitをあるプラットフォームに移植したんだけれども、そこでやっているプロトコルのいろんな手順で、結局はその後TCP/IPで見た時に同じ様なことをやっているんですよ」

「結局はウインドウ制御みたいな話が出てきたりとかっていうのは、基本は一緒なんですね。ヘッダーがあってトレーラーがあってだとか、あとはチェックサムだかなんかをつけて、ちゃんとそこのところのデータの妥当性をチェックしてますみたいな当たり前のところっていうのは、どんなプロトコルになったってそんな変わらなかったりするんですよね」

「なので、一旦覚えたってやつが完全に無駄になることはないと思うんですよ。そのままその技術が使えるかっていうとそれはこの世の中だし、これだけ技術が早いんで、それは期待しないほうがいいとは思うけど、なんかで流用できるし、生きてくるんじゃないかなと思います」

「なんかこれエラー発生しましたけど大丈夫ですか？」

「これは…よくないエラーですね」

「じゃあ、僕らは会場にいる人に語りかけましょう。会場限定！」

「YouTubeの配信の方が今壊れてまして」

「配信の方は申し訳ないです」

「聞こえてないですけどね、配信の人には（笑）」

「そうですね（笑）」

「河合さんはなんかそういうのないんですか？僕はいいことばっか言っちゃったけど、こういうのを見て、その技術には取り組んだ方がいいかもしれないけど、それはちょっと流石に慎重になった方がいなって思うようなものとか」

「まだ僕はおそらく経験が浅すぎていっぱい取り込んでる方だと思っているので、そこまでのところはないですけど、おっしゃった通りです。1つ学んだことっていうのはそこで学んだものが終わったとしても死ぬわけではなくて、必ずどこかで生きてくるっていうことが所々感じるとこはもちろんある。だからやっぱり物怖じしてやらないというよりは、やってしまった方が面白いんじゃないのかなっていう気はします。私事をお話しするんですけど、このWebBluetoothを始めたのは1カ月か2カ月くらい前なんですよ」

「そうなんですか」

「面白そうだなっては思っていたんですけど、やれる機会があまりなくて、まあちょっとやってみようって始めてみて、もちろんまだGoogleのChromeしかおそらく対応していないので、このあと使える技術かどうかなんてわからないわけなんですよ。なんですけど、やっぱり面白いからやってみよう感じになっているので」　

「そうそう！だからその技術がなくなっちゃうっていうことを恐れている人は、会場にもいたんですけど、あんどうやすしさんっていう人がいるんですね。知っていますか？」

「はい！」

「彼ね、今日ね、引っ張り出したっていうウエーブ(Google Wave※)のTシャツ着てきてましたから。ウエーブ本出したらウエーブがシャットダウンすることになって、シャットダウンのアナウンスがあった数日後に出版になったっていうね（笑）。人生で一番不幸な人みたいな。なんか彼が取り組んだ技術はだいたいdeprecateされるっていうDEATH NOTEの生き証人みたいな人がいるんです。でも全然恐れていないで、いろんなことどんどんやってますよ」

「なるほど。これからはそういう姿勢をとっていった方がいいことが多いかもしれませんね。学生のやり方を見て僕がいいなと思ったのが、Webの質問サイトとかに質問をたくさん書いていたんですよ。それが1個2個じゃなくて10個20個とかすごく書いていて、調べて分からなかったらすぐに聞いてどんどんやっているんだって思って」

「まとめたものがあったらまさしくQiitaとかに書けばいいし、そうすると最新の技術が出てきた時に、早めにキャッチアップできてQiitaみたいな記事が書けると、みんなに注目されて界隈で目立てるというか、そういうプラス面があるじゃないですか。その姿勢ってすごくいいなって思いました。スモールスタートというか、物怖じするんじゃなくて、面白そう、ちょっとやったらできるんじゃないか、頑張ってやってみよう、わからなかったら周りに聞こう、まとめたらアウトプットしようみたいな、そういうエンジニアになっていくのがいいんじゃないかって」

「でも技術者って、基本面白いからその技術に取り組むんじゃないですか？例えばArduinoだとかRaspberry Piとかも、今でこそIoT的に使えるかもしれないけど、最初はただの電子工作じゃないですか」

「いわゆるおもちゃみたいな位置付けだったんですよね」

「すべての技術はおもちゃから始まるんですよ。僕それもうずっと言っていて、要はイノベーションのジレンマっていう話あるじゃないですか？あの破壊的イノベーションっていうのは、基本的にその時にその業界において、ほとんどおもちゃって思われているやつなんですよ。メインフレームがあった時に、僕がいたDECって会社が作っていたミニコンっていうのは、ほとんどおもちゃみたいなものなんですね。ミニコンとかがある程度出てきてダウンサイズが見えた時にもうワークステーション、さらにそれ飛び越えてパソコンなんておもちゃなんですよ」

「当時のNECの98シリーズを作った時に、おそらくNECの98をやれって言われていた技術者の人は、メインフレームをやっていた時に、そこに部隊異動になったら勘弁してくれって思うわけですよ。ほとんどおもちゃって言われていたのが、あっという間にメインストリームの技術を追い越していくっていうのが破壊的イノベーションなんですね。基本おもちゃっていうところで、これ面白いっていうのが実は人が集まってきて育っていくと、それがメインストリームになって、今までの事実を置き換えていくということが起きているんですよ」

「みんなが面白いって思っているやつとか、さっき言った生き残るかもっていうのは何かあると。生き残るかもしれないっていうのは、確率論でいうとあるかもしれないですよ」

「そこにいろいろ面白い展示がありますけど、WebのMIDI関係今一番面白いなって思っていることってどういうことですか？」

「面白いなって思っていることですか？」

「さっき及川さんが、空間の？概念がWebで表現できるって、そしたら音もその空間、例えばちょっと動いたらそっちから聞こえるっていうそういう表現ができたりっていう風になっていくんでしょうか？」

「この間Chromeの方に実装されたJUMP(※)っていう、Googleの出している専用のプラットホームでしか見られない映像でしたっけ？音響をWebブラウザ上で再現できるようになっていて、そのJUMPでフォーマットで録られた音声は3Dの音響でちゃんと聞けるっていう状態になっていたりします」

「もうそういうことができる時代になっていたんですね」

「そうですね。だいたい音って、結構最初は取りかからないんですよ。最初は映像が入って、目で見る方が完成し出すと、音ができるみたいな。WebオーディオとかMIDIもそうだったんですけど。Canvasが動くようになって、WebGLが動くようになって、じゃあは次は音だろってみたいな流れになるわけですよ。音ができると、その次は3Dだという話になるわけですよね。CanvasからWebGLになったみたいに。今その流れがきているかなって感はありますけどね」

「なるほど」

「最近WebVRとか言ってWebブラウザ上でVRができるようなフレームワークができていたりするんですけど、そこは面白いかなっていう気はします」

• Google Wave：過去に米グーグルがサービス提供していたコミュニケーション及びコラボレーションツール。2010年5月にはサービスを一般公開したが利用者が増えず、同年8月4日に開発中止を表明。サービス自体は2012年4月末まで継続された。
• JUMP：グーグルが提供するVRコンテンツ作成システム

まとめ

「この後13時からセッションされるんですよね？」

「そうですね。13:20ですね、そろそろ」

「そちらの方で今のような話とかも？」

「そうですね。まさに今頭の中でそこで話す内容ちょっと話しちゃったな、みたいな。どうしようみたいな感じだったんですけど（笑）」

「今ここで先にお話ししてしまったかもしれませんが、その話も聞けるということなので、ぜひご興味ある方は河合さんのセッションをご覧になってみてはと思います」

「よろしくお願いします」

「準備のお時間もありますよね、すみませんでした」

「いえいえ、13:20からなんで大丈夫です。おそらくまとめをするとなると、とりあえずやってみろっていうことですよね。口で言う前にとりあえず手を動かしてみろと。それが自分を作るっていう感じなんですかね？」

• 河合さんの講演動画はこちらからどうぞ！

「純粋に面白いんじゃないじゃないですか？学生さんもきっと面白いと思ってやっているんで。逆に言うと、なんで加藤さんやんないのかなっていう（笑）」

「なんかちょっとひねくれているんでしょうかね？」

（笑）

「ごめんごめん、いじめたかったわけじゃないから（笑）。元気出そうよ！なんかツラいことあった？」

「いえ、大丈夫です」

「今日夜行のバスで福島から来てるんですよ。おそらく疲れてらっしゃる」

「なるほど」

「すみません、多大なフォローをいただきありがとうございます！」

「いえ、とんでもない」

「すみません、スピーカーを入れていただいた方もどうもありがとうございました。この辺りで、第1回目は終了したいと思います」

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

ラジオブースで放送した全ての内容を動画で公開！

放送1回目だけでなく、ラジオブースで放送した全ての内容を動画でも公開中です。「地方で日本で働く海外で働くの話」は、動画の[3:03:38]-[3:50:50]です。

• 「地方で日本で働く・海外で働くの話」 by DJ KATO [ゲスト：及川卓也さん、河合良哉さん]
• 「ハードウェア楽しいですよね」 by DJ KATO [ゲスト：中川友紀子さん、羽田野太巳さん]
• 「ハートブレイクカフェ」 by DJ KATO & 物江修さん

HTML5 Conference 2016の展示ブースでは、私DJ KATOによる特別ラジオをお届けしておりました。
すごく面白いので、Increments及川卓也さんとヤマハ河合良哉さんがゲストに来てくれた「地方で日本で働く・海外で働くの話」を完全版テキストで書き起こしてみました。ぜひ、カンファレンスレポートの番外編としてお楽しみください！

まずは、自己紹介をお願いします

「海外にも地方にも行っていないのに、なぜか呼ばれています。Increments株式会社の及川卓也です」

「ヤマハ株式会社の河合良哉です。よろしくお願いします」

「地方にも海外にも行っていないというお話がありましたが、環境が大きく変わったという面で共通点があると考え、広い意味での定義としてとらえてほしいです」

「はい」

「まず、及川さんは…」

「ちょっと待って。お前は誰だという感じだから（笑）」

「あ！僕ですね！私、会津若松にあるIT系の会社に勤めております、加藤と申します。DJ KATOと名乗って、こういった司会をやらせていただいてます。どうぞよろしくお願いします」

「イエーイ！」

及川卓也さんの基調講演のお話

「先ほど基調講演を終えられたばかりですよね？（基調講演の後で）時間ありました？」

「1つセッションを聞いてきましたよ、React.jsの難しいやつを。途中で抜けてきちゃったんだけど」

「結構技術的な話を聞いてきたんですね。及川さんはどのようなお話をされたんですか？僕は聞きに行けなかったので…」

「聞いてなかったんだ！（笑）」

「準備をしていたので…」

「そうですか、ご苦労様です。僕は何の話をしたんだっけ？Webの話をしたんですよ。一応Webのカンファレンスなので。なんか飲んでもいないのに酔っ払ってるみたいですみません（笑）」

「Webは3つの側面がありますねという話で、アプリケーションの技術としてのWebとメディアとしてのWeb。あとはインフラ技術としてのWebで、それぞれいろんな局面を迎えている。でも今後も投資して、さらに発展させていかなきゃいけないですね、というすごくいい感じの話をした気がします」

「なるほど。そういった広い視点でのお話をされたという感じですね」

？？？？？？？？？？？？？

「ごめんなさい！緊張してしまって、わけのわからないことを言って申し訳ないです」

「基調講演を聞いていないのに申し訳ないのですが、プラットホームとしてのWebって、例えばどういう変化が起きてて、これからどうなるということなんでしょうか？」

「ずっと起きている話で、要は機能的にもどんどん追加されてきていると。で、ある程度WebのAPIってそこそこ揃ったようには見えるんだけれども、実はWebって古くからコンピューターディスプレイがあって、キーボードがあって、マウスがあるというところから、やっと今スマホみたいなところになってきている。そういった今までのデバイスやメディア系のものを超えたものに、これからはなっていくでしょうという話をしました」

「はい」

「ちょうど私の前にW3Cで慶応大の中村修先生が、HDRの話をされていました。要は輝度の部分をJavaScriptでWebからコントロールできたならば、映像が大きく変わるだろうって話を少しされてたんです」

「それにインスパイアされて、音の部分もaudioタグがあって、Web MIDIがあって、Web Audioもある。そんな状況ですが、実は2009年という早い段階からGoogleは考えていたんです。空間音響みたいなところで、要はVRのサウンド版。どこの位置にいたならばどういうふうに音が聞こえるはずだということを、拡張機能として公開しているのがもうあったりするんですね」

「はい」

「今までの普通にコンピューターディスプレイやスピーカー、ヘッドホンだけでは想像もつかなかったようなところまで、実はそのアプリケーションとしての可能性もまだまだ可能性がありますねって話」

「あとはWebAssemblyの話で、もはやそうなってくるとJavaScriptとHTMLとCSSとは全く違うアプリケーション開発技術も出てくるから、楽しいと同時にいろいろと考えなきゃいけないねっていう話をした感じです」

• 【基調講演】Webはオープンな分散型OS、アプリケーション・メディア・プラットフォームとしてのWeb技術─中村修教授、及川卓也氏が語ったHTML5の未来

「大丈夫ですか？これで今回のテーマにだんだん近づいてきます？」

「まだ1mmも近づいていないんですが、話の流れを大事に進めていこうと思います」

「了解です、任せます。ちょっと不安になりました（笑）」

河合さんに聞いたWeb MIDIのお話

「河合さんはWebとMIDIに関してお仕事上関わりがあると思うのですが、その方面で、今までできなかったことが今後できるようになるものにはどのようなものがありますか？」

「この隣にWeb Music Developers JP(※)というコミュニティーが主催している展示会場があって、そこで缶が鳴っていますけど、実はMIDIで動いていたりするんですよ。今まさに及川さんがおっしゃった、プラットホームとしてのWebのところでMIDIも入ってくるのかなと。外部のExtarnalのデバイスとブラウザが直接つながると、そこで起こったことは僕が言うのもすごく手前味噌なんですけど、楽器業界がWebの業界にどんどん入ってきたと言えるんじゃないかと思います」

「楽器が…Webに？」

「これも手前味噌なんですけど、ヤマハがrefaceというシンセサイザーを去年出したんですね。そのシンセサイザーは、普通のシンセサイザーだと大体ボイス、音色のパラメーターを保存するのに楽器に載っているメモリに保存するんです。だけど、そのrefaceというモデルに関しては保存する部分がなくて、どうするかというとWeb MIDIで接続をして、ブラウザから直接Cloudの方に保存する。そういうことで少し形が変わったかな。Webをストレージとして使うというような考え方に移ったと」

「なるほど」

「もう少し話すと、プラットホームとしてのWebという意味で、僕も昔から思っていて、やっぱりブラウザというとディスプレイがあってキーボードが目の前にあって、そこから外にあまり出ないよみたいなイメージがあると思うんですけど、それがまずMIDIで楽器の業界で外に出ましたと」

「はい」

「今ですね、GoogleのChromeにしか搭載されていないのかもしれないですけど、WebBluetoothっていうのがあって。このWebBluetoothというのを使うと、今度Bluetooth SMARTって呼ばれる世の中でいうBLEというやつですね。BLEの機器に直接接続ができるんですよ」

「はい」

「あそこにM&M’sが入ったおもちゃみたいなのがあるじゃないですか。あれ実はBluetoothで接続をして、ボタンを押すと中に入っているM&M’sがババババーッと出てくるおもちゃなんですけど、ああいうものが作れるようになるわけです」

「なるほど。これたぶんラジオで聞いている人にはちょっと…」

「見えないですね（笑）」

「見えづらいかなと思うんですけど、このすぐ隣にWeb Music Developers JPさんのブースがありまして、そこにWeb MIDIといろいろなものがあって、PCとMIDI楽器なんでしょうか？あれは？」

「そうですね。真ん中に並んでいるのはMIDIを使ったコントローラーで、その次に並んでいるのがライブビーツっていうブラウザを楽器にしてしまうような作品です。で、その隣にあるのがシーケンサー、これFirebaseを使って、いろいろな人と進行しながら音楽を作っていくハッカソンでハックしてもらった作品が展示されています。その隣には、これもWebの技術を使って照明をコントロールしようというもので、照明がコントロールされています」

「照明を、MIDIで？」

「はいそうですね」

「あ、そうなんですね」

「MIDIってミュージカルインストゥルメンタルデジタルインターフェイスという名前なんですけど、そのプロトコルを別の用途で使ってしまっているということですね」

「つまりMIDIって、タイミングだったり音色だったりという概念があって、それを表示のタイミングだったり、どの色にするかに置き換えて命令を出すという感じなんでしょうか」

「そうですね。おっしゃるとおりでございます」

「なるほど」

「その隣に並んでいるのがMIDIに関係ないですけど、WebBluetoothで接続されているお菓子が出てくるおもちゃです」

「さっき河合さんがブースを作っている準備段階をお見かけしたんですけど、M&M’sが勝手に動いてチョコレートをバラバラと吐き出しているのを見ましたけど、あれもMIDIでやっていた？」

「いや、あれはMIDIとは関係なくて、Bluetoothで接続をしてBluetoothで動かしています。もう一回出してみます。……あんな感じで」

※筆者注：↑Bluetoothで動かしているとさっき河合さんが言ってました。話を聞いていない。

「今出てる！」

「ここから接続しているんですけどね、全然見えないですよね（笑）」

「今まではMIDIというと、鍵盤があってそれをUSBでPCに繋ぐと、そのPCのソフトで楽器が鳴る。それは専用のソフトがあってそのソフトが鳴るイメージだったものが、今はWebブラウザがあればそのWebブラウザの表示の機能でMIDIのUSBに繋ぐだけで全部音が鳴ったりだとか、専用ソフトになるようなことが全部出来てしまうという状態になっているということですね」

「そうですね。それを楽器以外のもので使うことのも可能なので、そういったとこに応用していくっていうのもありかな」

「なるほど」

＜参考情報＞

• Web Music Developers JP のgoogleグループ
• reface

河合さんがサンフランシスコに拠点を移されたお話

「ちなみに今年サンフランシスコの方に拠点を移されたということで、それはどういった目的で移動されたのですか？」

「夢にも思ってもなかったのですが、ありがたいことに駐在の司令を出してもらえ、今年1月下旬からアメリカに住んでます」

「日本でのWebのMIDIの普及と、海外でのWebのMIDIの普及には違いがあるんでしょうか？ご自身で決めていったというわけではないという話だったので、そういう依頼があったわけではないと思いますけど、海外に行ったことで日本のWebMIDIの盛り上がりと、海外の盛り上がりの違いがあったらお聞きしたいです」

「基本的に僕がまだ全然知らないだけかもしれないですけど、日本で今展示しているのがWeb Music Developers JPなんですけど、ここが異常に盛り上がっている感があるというのが僕の印象です（笑）」

「海外にWebでミュージックをする方たちがいるかなというと、あまりいないかなという気がしています。とはいえ、音楽で盛り上がっているというコミュニティはあるみたいで、その方々はいろいろなことをやっているみたいです。例えばWebGLを使って音楽と組み合わせて作品を作ったり、そういうのをアメリカでよく見かけることがありますね」

及川さんが海外で仕事をしていた話

「及川さんは海外で勤務された経験もおありなんですよね、いつ頃でしたでしょう？以前働いてらっしゃったのは日本DEC(※)にいらした後、Microsoftで働いていた時に海外にいらしたと…」

「そうです、よく知っていますね！」

「ネットで調べたら出てきました」

「その前に加藤さん声ちっちゃくない？」

「すみません、気持ちの萎縮が声に出ていたのでちょっと張ります」

「あと、マイクは柄の部分を掴んだ方がいい気がするよ（笑）」

「はい、こんな感じでよろしいでしょうか？（笑）」

「はい、ぜひ元気よくいきましょう！」

「私今から20年ちょっと前にまだMicrosoftが小さかった時ですね。Windowsのエンタープライズ版のWindowsNTっていう今のWindowsなんですけど、それの元のバージョンを作った時に1年くらい派遣されました。シアトルというか、郊外のレドモンドにある今Microsoftの本社があるところに行きました」

「その時に、日本から海外に行かれたということで、暮らす環境だったり仕事のやり方だったり、すごく違いを感じたのではないかと想像するのですが、その辺りはどうでしたか？」

「そうですね、だいぶ違いましたね。しかも当時ってインターネットまだないんですよ。あるんですけど、Webはまだ作られていない時だったんですね。ちょうど私がレドモンドにいた時に、Webっていうものがあるらしいぞというので、NASAの宇宙の写真とかを最初に見たのを覚えているくらいなんですよね。なかったんですよ」

「つまりどういうことかというと、行く前に現地の情報とかそんなに分かんなくて、ニフティサーブという今のニフティの原型があり、そこがアメリカのコンピュサーブっていうパソコン通信にゲートウェイで接続きたので、そっちの方のフォーラムに入ったりしていろんな情報を入手したりしていたんですね。また逆に、アメリカ勤務していても、日本の情報がほとんど入ってこないんですよ」

「そうなんですね。

「なので、どっちがいいかというと正直分からなくて、昔は昔でそういった現地に行かないと分からないものを、現地に行って分かる面白さとか醍醐味があったんですけれども、不便といえば不便でした」

＜参考情報＞

• 日本DEC：日本 ディジタル イクイップメント株式会社
• ニフティサーブ：NIFTY-Serve、のちにNIFTY SERVE、1987年から2006年までニフティ株式会社が運営していたパソコン通信サービス。
• コンピュサーブ：CompuServe、アメリカのパソコン通信会社。

インターネットで知ることと、現地に行って知ることの話

「なるほど、それは良し悪しあるんですね。今は狙った検索ワードを入れれば、大抵のものはヒットして分かるという状態になっているじゃないですか。それは日本にいても海外にいても見れるので、ネットで繋がっていれば一緒に仕事もできるし、知らなかった情報もすぐネットでキャッチアップできるような環境に今は変わってきている気がする。なので、海外に行って困るというのは前と比べると少なくて済む状況になってきているのではないかと思うのですが」

「そうですね。今僕も向こうにいるわけなんですけど、インターネットから大体情報が入ってきますし、すごく変わったかなと思うのが、テレビもすごく変わったと思うんですよ。家にソニーさんが作っているnasne（ナスネ）™というサーバーを、日本の自宅に置いているんですね。そうすると、海外からも日本のテレビ番組が普通に見れるんですよ」

「撮りためておいて、普通にそれが見れるという感じなんですか？」

「そうですね。撮りためもできるし、リアルタイムで見ることもできたりするので、アメリカにいるのに日本のテレビ番組を見てたりすることもあったりして、その辺は本当に情報がすごく入って来やすい。自分で取りに行こうと思えばいつでも行けるという状態になっているというのは間違いなくあるという気はするんですけど、1つ僕が結構思うのは、情報ってやっぱり情報なんですよ」

「はい」

「重要なのって情報の周りにある雰囲気だったり、文化的な背景だったり、そういうところが結構重要だということを僕は思っているんです。情報は入ってきやすくなってきたけど、ディテールのところは現地に行かないと分からないかなという気がしているんですけど、及川さんその辺いかがでしょうか？」

「そうなんですよね。英語圏でアメリカにいると、インターネットで得られる情報と、現地で得られる情報っていうのはもちろん差はあるけれど、そんなには多くないんですね」

「はい」

「ただ他の国に行った時に、我々が現地の言葉を知らなかったりすると、どうしても英語の情報に頼るじゃないですか。もしくは日本語の情報に頼ると。例えばヨーロッパに行った時に現地の人から教えてもらったのは、トリップアドバイザーの情報でいい店だって言われて行くわけですよ。それはアメリカ人のテイストにあってる店がレコメンドされるだけだよってはっきり言われたんですね」

「なるほど（笑）」

「だから、本当に現地の人が行くところで推奨している店が、そこに引っかかるとは限らないということを言われたから、やっぱりインターネットで得られる情報と現地の本当の情報は必ずしも一致していないことは覚えておいたほうがよくて。ただ、今ちょっとトリップアドバイザー、最近元Googleの僕の友人が日本法人の社長になったんですけど」

「そうなんですか（笑）」

「まあ、それはいいんですが（笑）」

「だけれども、逆に言うとそれはそれで便利なんですよ。なぜかというと、トリップアドバイザーでいいって言われているのは確実に英語が通じたりだとか、アメリカ人と日本人のテイストはだいたいあっているんで、そんなに間違いはない」

「ただ、やっぱり今言ったみたいに、本当に現地で価値があるって言われているものが英語で情報として流通しているかどうか分からないところはあったりするんで、やっぱりネットの情報で便利になったと思う反面、ネットだけでいろんなところに行こうとしたら、実は現地でしか味わえない醍醐味だとか、本当に大事なものを見失ってしまう可能性はあるかもしれないなって思いますね」

「そういう側面もありますね」

「例えば、逆にふっていいですか？　地方に東京から移住した加藤くんに聞きたいんですけれども」

「はい」

「要は、もう日本語で普通に会津若松の情報って分かるじゃないですか。でも現地に行ってみたら全然違ったっていうようなことって、実際に暮らし始めてみてからあるんですか？」

「いくつかやっぱりありますね。そもそもあんまり店がないのかなって思っていたら、みんながWebにあげていないだけで、実際に足を運んでみるとすごく美味しい店が近くにたくさんあったりとか、そういうギャップがあったり。あとは食べログとかを見てお店を選ぶんですけど、評価が普通なお店でも行ってみると店員さんがすごく優しくてフレンドリーで、何回か行ったら一品増やしてくれたりとか、これはちょっと分からないだろうなとは思いました。それは現地に行ってこそ分かるものだなって分かりました」

「今は逆に検索すればわかるから、ネットがつながってるから、情報共有も簡単にできるだろうと思い込むのは危険なところはありますよね。その辺は会社によってやり方は違うと思うんですけど。Microsoftなんかはレドモンドに社員を皆さん集結させて、なるべく物理的に近くにいてコミュニケーションロスを減らそうとしているとどこかで見たのですが、そういう会社もあれば、Googleは逆にどこにいても仕事はできるからというかたちで、物理的に散らばって要所要所で集まって意思疎通をしていると聞きました」

「そういうスタイルや、会社さんごとにいろいろなやり方でやっていると思うんですが、1つ言えるのは以前よりも単純な情報の共有はすごくやりやすくなったので、海外にいきなり行くとなった時も、以前のような準備がそこまでいらなくなってきているのかなと感じました」

＜参考情報＞

• ナスネ：nasne、地上/BS/110度CSに対応したデジタルチューナーと大容量ハードディスクを搭載したネットワークレコーダー＆メディアストレージ

──後編は「日本と海外の違いの話」「年齢が違う人とのコミュニケーション」などの話を紹介します。

こんにちは、ふろしきです。HTML5 Conference 2016の当日は、38度近くの熱があり、発表時はろれつが回ってませんでした。しかし、伝えたいことは伝えられたと思っています。その内容とは…

「この1年でWebのパフォーマンスの技術にどんな動きがあったのか」

というダイジェスト。ここで話した3つのテーマについて、本記事でもご紹介。

1. レイアウト処理を減らす

HTML5がバスワードするよりもずっと前から、CSSでアニメーションさせることはごくごくあたりまえ。JSが扱えないデザイナーであっても手軽にアニメーションできる良い世界になりました。しかしそこに、モバイルが出現したことで、JSだけで満足という人たちもCSSの機能を活用しなくてはいけなくなりました。

モバイルのUIによくありがちなのが、あるコンポーネントの形状を変化させるようなアニメーションや、スワイプ操作のような指の位置に応じてコンポーネントを動かすもの。それを描画するとなると、CPUはあまりにも非力で、GPUの力を借りることが求められています。CSSはGPUと相性がよいため、JSからCSSの機能を呼び出して効率的にGPUを活用するということが求められています。

そのアプローチについては、HTML5 Experts.jpでも「モバイルWebのUIを速くする基本テクニックがわかる──Google I/O 2016 High Performance Web UI」で紹介していますので、本記事では簡単にだけ説明。

GPUでできることは、極めてシンプル。ある四角形の描画結果を、どの位置に表示させるのか、拡大縮小させるのか、回転させるのか、といった変更加えるだけ。それだけでいいというのであれば、CPUを介さず、GPUのみで描画処理を完結させることができます。

これをブラウザで行う場合は、ある特定のDOMとその配下にあるDOMの描画結果をGPU側に転送し、GPU側にどういう描画を行わせるのか指示を送ることで、高速に処理させます。その間、操作はすべてCSSのプロパティを使って行うことになります。

CSSも、従来の left や top といった、レイアウトを操作するようなものではなく、 transform プロパティ経由で指定。 JS上で、以下のように指定することで、CPUによるレイアウト処理を避けつつ、GPUで描画の位置のみを変えるというもの。

// ある要素の横の位置を移動
elem.style.transform = `translateX(#{position}%)`;

この方法は一昔前には泥臭いとされ、バッドプラクティスと考えられていました。しかしそれも、最近は will-change というCSSプロパティが正式に標準化の流れに入ったことで、考えが改められています。GPU上に描画結果を保存させるのはバッテリー消費が大きいため、開始時に will-change: transform; で有効にし、終了時には will-change: none; で解除する、という流れになります。

簡単な例をあげると、以下の通りです。

// スワイプ時、指の位置にあわせてコンポーネントを左右に動かす。
class MovableComponent {
  constructor(elem) {
    this.elem = elem; // 動かす対象のコンポーネントのDOM
  }
  // ある要素の横の位置移動を開始
  function begin(beginX) {
    this.x = beginX; // 開始位置をセット
    this.elem.style.willChange = 'transform'; // GPU側に描画結果を置く
  }
  // 位置を変更(指の位置がかわるごとに呼び出される)
  move(currentX) {
    this.x = currentX; // 現在の位置をセット
  }
  // 描画(requestAnimationFrameで毎回呼び出される)
  render() {
    this.elem.style.transform = `translateX(#{this.x}px)`;
  }
  // 横移動の完了
  end() {
    this.elem.style.willChange = 'none'; // 解除
  }
}

2. スクロールイベントを減らす

ブラウザのscrollイベントが、スクロールの滑らかさを落としてしまう。とはいえ、「どれだけスクロールされたのか？」というのに応じて何かしらのJSの処理を動かしたくなるという需要はなくならず、できるかぎりパフォーマンスを上げようという努力はされてきました。

2015年の4月にChromium Blogにポストされた「Chromium Blog News and developments from the open source browser project 」は有名な話です。Chromeではブラウザ上で動作するタスクに優先度を与え、JSの処理やブラウザ側の内部で行われる処理のうち、スクリーン上への描画が関わるタスクを優先的に扱うようにすることで、スクロールの滑らかさを損なわないようにしようという取り組み。確かに、ユーザーの体感としてパフォーマンスは上がったようにみえるでしょう。

しかしこの問題、その本質は、イベント自体が無駄に多く呼び出されてしまっているというところが大きかったりします。したがって、ユーザーワールド側でも、scrollイベントを毎回素直に実行するのではなく、頻度を落として実行するThrottlingという方法が一般的になっています。

これらはパフォーマンスを改善する上で、たしかに有効ではあります。ただ、デベロッパーが本当にやりたいことに目をむけ、そこにより特化した機能をブラウザ側が持てば、もっと良い解決につながるのは間違いありません。ハードウェアが貧弱で、スレッドの扱いに制約の多いブラウザでは、そこに踏み込んだアプローチが求められています。

scrollイベントの利用ケースで、かなり多いもののひとつに「画像の遅延読み込み」があげられます。例えば、ATF(Above The Fold : Webページアクセス直後にスクリーン内に映り込む領域)の表示を速くしたい！それこそ、headタグ内の大量のCSSファイルやトップの巨大な画像ファイルに帯域を譲らないことには高速化が困難ということになれば、ATF外にある画像ファイルは後から読み込んだほうがいい、ということになります。もちろん、サーバーの負荷を下げるという用途でも活用されるでしょう。

それを解決する方法として、Web標準「Resource Priorities」にて、lazyloadというプロパティをHTMLのタグに追加しようという流れが生じ、IE11にも実装されたのですが、「そもそもそういう用途で使われるようなプロパティは追加されるべきなのか？」「本来JSであったり、より低レイヤーなアプローチで解決すべきでは？」という意見もあり、削除されてしまいました。

あれから2年が経ち、lazyloadは理想的な形で実現できるようになりました。それが「Intersection Observer」です。

Intersection Observerは、スクロール時に特定のDOMがスクリーン上に現れるタイミングでイベントを発火させてくれます。したがって、scrollイベントよりも軽量な上、scrollイベントの多くのユースケースを巻き取ることができます。そもそもDOMの位置を取得する、scrollTop、offset、getBoundingClientRect、といったプロパティやメソッドは、本記事の1章でもあげたような、レイアウト処理というヘビーな処理を呼び出しのタイミングで必要とする場合がある。それも無くなるとなれば、一石二鳥でlazyloadのような類の処理を最適化できるというわけです。

以下、使い方の例。jQuery.lazyloadのようなものを実装するとしたら、以下のようになります。

// 遅延読み込みをさせる専用のObserverを生成
let imageLazyLoader = new IntersectionObserver((changes) => {
  // イベント発火のタイミングで、遅延読み込みさせる
  changes.forEach((change) => {
    let image = change.target;
    image.src = image.getAttribute('data-original');
  });
}, {
  rootMargin: "120% 0" // 読み込みを開始するタイミング
});
// 遅延読み込みさせたいimg要素を取り出し、Observeさせる
let images = Array.from(document.querySelectorAll('img.lazyload'));
images.forEach((image) => {
  imageLazyLoader.observe(image);
});

3. タスクキューの待ちを減らす

最後に、タスクの最適化の話です。ここの話については、ピクシブのブログのエントリー「JSがブラウザを固めてつらいので、新しいAPI「requestIdleCallback」を使うことにした」でも取り上げてますので、ざっくりと背景と概要を。

元々は、2016年頃にMicrosoft側が「setImmediateをちゃんと実装しよう！」と。Microsoftのプラットフォームにおいて、多くのユーザーがsetImmediateを利用しているということを、W3C Web Performance WGのMLで問題提議し、 setTimeout(fn,0) を使ってタスクを遅延実行させるバッドプラクティスを緩和しようという提案から始まった話です。こうした悩みは「requestAnimationFrameで解決されるものだ！」という意見もあったのですが、現実問題としてはそうはうまくいかないというのは、フロントエンドをやっているエンジニアなら感じられたはずです。

そもそもこの問題はどこから生じたのか？一昔前のビデオカードが、１つのスレッドでしか描画を扱えないという制約があった。そういった背景もあり、現在のブラウザもまた、ブラウザの内部の処理からJSで実装したユーザーワールドの処理に至るまで、その多くのUIスレッドと呼ばれる単一のスレッドだけで処理しざる得ない状況となった。その恩恵というべきか、JSはこれだけ単一スレッドで処理実行させることに進化したのですが！JSでやることが多くなってしまった今、本記事の2章でも語られたような「タスクの優先度」に手を加えないことには、解決出来ない問題も多くなったのです。

こうした中ででてきたのが、requestIdleCallbackという機能です。

2章にもでてきた、Chromeのスクロールパフォーマンスを改善した、パフォーマンス周りを専門としているGoogleのエンジニアRoss McIlroyら。彼らが、Microsoftがだした「setImmediateを全ブラウザでちゃんと実装しようぜ！」という案をはねのけて提案したのがこのrequestIdleCallback。

scrollイベントの改善で、彼らはあくまでブラウザ側のタスクの優先度に対して手を加えたわけですが、ここにきてデベロッパーが作ったJSの処理。ユーザーワールドで実行されるものについても、優先度のようなものを与えて、タスクが実行されるタイミングをうまく制御しようという提案をしたのでした。scrollイベントで培ったノウハウを広げようとしたんだろうなぁと、私は推測してます。

requestIdleCallbackはどういうものか？scrollイベントの一件では、緊急度の高いブラウザ内のタスクを、あらゆるタスクよりも優先して速く実行するというものでした。一方でrequestIdleCallbackは、ユーザー側の体験としてパフォーマンスが低いという状況を生み出しがちな、緊急度が低いユーザーワールドのタスクを、あらゆるタスクよりも低く実行するというもの。ブラウザ側だけじゃ限界があるから、デベロッパー側でもなんとかする術というのを提供したといったところです。

その仕組はとてもシンプルで、処理されることを待っているタスクがあれば絶対に実行しない。無ければそのタイミングで実行しようというもの。

サンプルは以下の通り。

var hd = requestIdleCallback( => {
  // タスクキューが空になってから実行されるタスク
},{
  timeout: 10000 // 何msであきらめるか。
});

最後に

CPUからGPUに処理を移したいというお話から、それでもどうしようもないシングルスレッド問題を、いかにして効率的に運用するのかというお話まで。GPUがデベロッパーを幸せにしたり、不幸にされたからどうにかしようとしたり、という感じで、GPUとブラウザのパフォーマンス問題は切っても切り離せないようですね。

ちなみに、この記事を書いている今、TPACというイベントが開かれ、パフォーマンスに関する議論も行われています。そこでは様々な議論が繰り広げられているのですが「Measuring and improving scroll latency (~30m; rbyers)」というスクロールをもっと良くしようよという話や、「Paint metrics」といったレイアウト処理のさらに先の描画系の発展的な話であったり、「Long Tasks API」みたいな、requestIdleCallbackとか以前にタスクの処理時間長くね？ってところをなんとか変えていこうよという議論もあったりします。

個人的に注目しているのは、以前からデベロッパーの間で薄っすら思われていた、SPAの時にブラウザのナビゲーション計測系のAPIが役に立たないのだけどどうするの？って問題に注目しているところです。SPAと一言でいっても、Ruby on RailsのTurbo Linksのようなものもあり、ブラウザの持つページ遷移機能が活用されないケースがある中で、パフォーマンス計測はどうあるべきなのか。「ナビゲーションの開始」と断定することが困難であり、それゆえに画面の切り替わりにどの程度の時間がかかったのかわからないこの問題を、今後どう扱うのかが議論されるようです。

一通り終わったなぁ、パフォーマンス周りの機能整備、なんて思ったのですが、よくよく考えたら実態にそこまで即した感じでもないんですよね。今後も様子を見ておきたいと思います。それでは！

はじめまして。GoogleでChromeの開発をしている保呂毅です。
Chromeの中では特にService Worker周りを担当してまして、最近はNavigation Preloadという新機能をがんばって実装しています。 先日開催されたHTML5 Conference 2016でService Worker周辺の最近（ここ1年くらい）の動向に関する発表をさせていただいきました。
今回は、この発表の内容を振り返りたいと思います。

Service Workerとは

まず本題に入る前に簡単にService Workerの説明します。 Service Workerとはどういうものかと言いますと、 下のコードのようにnavigator.serviceWorker.registerというAPIで登録する、バックグラウンドで動作するJavaScript実行環境です。

navigator.serviceWorker.register('./sw.js', {scope: './'});

登録されたServiceWorkerでは、ページからのネットワークリクエストを横取りすることができます。 下のコードでは、ページからのネットワークリクエストを横取りしてHello Worldという文字列をページに返しています。

self.addEventListener('fetch', event => {
  event.respondWith(new Response('Hello World!'));
});

また、ページからのネットワークリクエストの横取りをする以外にも、ページを開いていなくても Push通知を受け取って Notification （通知）を表示する、Push Notificationsという機能も備えています。

Service Workerは新しいAPIでして、まだ利用できるブラウザが限られています。 Is ServiceWorker ready?というページに各ブラウザの対応状況が書かれています。ChromeとFirefox、Opera、Samsungのブラウザは対応していて、Edgeは開発中、Safariは検討中となっています。

Push Notifications

Push Notificationsの仕組み

Push Notificationはどういう仕組みかといいますと、WebサービスのサーバーからFCM (Firebase Cloud Messaging)のサーバーにメッセージをポストすると、それがブラウザに届いて通知を表示できるというものです。FCMは、最近GCM (Google Cloud Messaging)から名前が変わりました。

Push Event

self.addEventListener('push', event => {  
  event.waitUntil(  
    self.registration.showNotification(
      'Hello',
      {
        body: 'We have received a push message.',
        icon: 'message.png',
        tag: 'tag'
      }));  
});

このコードはService Worker上のPushイベントハンドラです。WebサービスのサーバーからFCMのサーバーにPOSTリクエストすると、このイベントハンドラが呼びだされます。このコードでは、ServiceWorkerRegistration の showNotification というAPIで下のような通知を表示しています。 タイトルが’Hello’で中身が’We have received a push message.’で、アイコンにmessage.pngを指定しています。

Notificationclick Event

self.addEventListener('notificationclick', event => {
  event.notification.close();
  clients.openWindow('/messages');
});

このコードはNotificationClickイベントハンドラで、先ほどの通知をクリックした際の処理を書いています。このコードでは、通知を閉じて、messagesというページをopenWindowで開いています。

Payload Data

ここまでの機能は2015年4月にリリースされたChrome 42から使えます。 ところが、Chrome 49までは、Pushメッセージにデータを含めることができないという制限がありました。例えばチャットアプリなどでチャットの内容を通知に表示する場合は、Fetch APIを使ってWebサーバーに問い合わせる必要がありました。 それが、今年の4月にリリースされたChrome 50からは、Pushメッセージ自体に暗号化したデータを含めることができるようになりました。

self.addEventListener('push', event => {
  if (event.data) {
    console.log(event.data.json());
  }
});

Service Worker側ではこちらのコードのようにPushEventにdataというプロパティがついて、データを読めるようになります。 サーバーからどう送信するかの詳細はこちらのURLで説明されているので、興味のある方はぜひ読んでみてください。Node.js用のライブラリ Web Push library for Node.js もありますので、Node.jsをサーバーで使っている方はこちらを使うといいかと思います。

Notification Actions

続きまして、Chrome 48から使える機能、Notification Actionsです。この機能を使うと上の絵のように、ボタンを追加できるようになります。

self.registration.showNotification(
  'Hello',
  {
    body: 'We have received a push message.',
    icon: 'message.png',
    tag: 'tag',
    data: 1234,
    actions: [
      {action: 'like', title: 'Like', icon: 'like.png'},
      {action: 'reply', title: 'Reply', icon: 'reply.png'}]
  });

コードを見ると、Actionsという項目で指定しているのが分かるかと思います。各ボタンに対応する、actionの文字列と、titleの文字列と、iconの画像を指定しています。

Notificationclick Event

このボタンをクリックすると、NotificationClickイベントハンドラが実行され、NotificationClickEventのactionを見ることで、どのボタンがクリックされたのかがわかります。

self.addEventListener('notificationclick', event => { 
  var messageId = event.notification.data;
  event.notification.close();
  if (event.action == 'like') {
    silentlyLikeItem();
  } else if (event.action == 'reply') {
    clients.openWindow('/messages?reply=' + messageId);
  } else {
    clients.openWindow('/messages?reply=' + messageId);
  }
});

このコードの場合、likeがクリックされたらsilentlyLikeItem()というメソッドを呼び出しています。Replyがクリックされた場合は、該当するメッセージのページを開いています。ボタン以外の部分がクリックされた場合も同様です。 ちなみに、メッセージを表示するURLのメッセージIDにnotification.dataの値を使っていますが、こちらはさきほどの通知を表示する際に指定したdataが渡ってきています。 この値は、Pushイベントのdataから取得するといいかと思います。

Standard Web Push Protocol

Chrome 51までは、Web Pushを実現するためには、以下のような手順が必要でした。この認証方法はFCM独自のプロトコルです。

1. 事前にFCMに登録をしてgcm_sender_idというIDを取得
2. manifest.jsonにそのIDを記述
3. FCMサーバーへのPOSTリクエストの際にAuthorizationヘッダにAPIキーを指定する

ところが、Chrome 52からVoluntary Application Server Identification (VAPID) という標準化されたプロトコルでサーバー認証することでFCMへの事前登録が必要なくなりました。 詳しくはこちらのURLを御覧ください。

Stream

サーバーにFetchリクエストをして、帰ってきたレスポンスに手を加えてページに返すService Workerを考えます。

Chrome 51までは、このような処理をした場合、上のアニメにあるようにレスポンスを最後まで読んでからでないと、ページに返すことができませんでした。 しかし、今年の７月にリリースされたChrome 52から、Streamの新しい機能を使うことで、サーバーからのレスポンスを逐次処理しながらページに返すことができるようになりました。

具体的な例で解説します。

ページのヘッダとフッタを事前にキャッシュに入れておいて、ページを読み込む際はコンテンツだけをサーバに問い合わせて、Service Worker内で文字列連結してページに返す。ということを考えます。

self.addEventListener('install', event => {
    event.waitUntil(
      caches.open('cache_name')
        .then(cache => cache.addAll(['./header.txt',
                                     './footer.txt'])));
});

まず、ヘッダとフッタをキャッシュに入れるには、Installイベントハンドラで上のコードのようにCacheStorage APIを使います。この例ではheader.txtとfooter.txtをキャッシュに保存しています。 caches.open()でキャッシュを開き、取得したcacheに対して、cache.addAll()を呼んでヘッダとフッタをサーバーから取ってきて保存しています。

self.addEventListener('fetch', event => {
  var url = event.request.url;
  if (!url.endsWith('.html'))
    return;

  event.respondWith(
    Promise.all(
        [caches.match('./header.txt'),
         fetch(url +  '.txt'),
         caches.match('./footer.txt')])
      .then(responseList => Promise.all(responseList.map(res => res.text())))
      .then(textList =>
            new Response(textList.join(''),
                         {headers:[['content-type', 'text/html']]})));
});

次に、Fetchイベントハンドラで、先ほど保存したヘッダとフッタをキャッシュから取り出して、サーバーから取得したコンテンツと文字列連結します。 先ほど保存したheader.txtとfooter.txtをキャッシュから読み込みつつ、Fetch APIで元のURLに”.txt”をつなげたURLにネットワークリクエストを投げています。 そして、それらすべてのレスポンスから、text()でコンテンツ本文を取得し、その後、joinで連結しています。 これで目的通り、ヘッダとフッタを連結してページに返すことができるのですが、問題があります。 先ほど書いたとおり、サーバーからのコンテンツ全体を取得完了するまでページに返せないのです。 そこで、解決方法がStreamです。Streamを使えば、サーバーから取得したコンテンツを徐々にページに返していくことができます。

self.addEventListener('fetch', event => {
    var url = event.request.url;
    if (!url.endsWith('.html'))
      return;

    var stream = new ReadableStream({
        【次コード参照】
    });

    event.respondWith(new Response(
        stream,
        {headers:[['content-type', 'text/html']]}));
  });

具体的にコードを見ていきましょう。 Installイベントハンドラは先ほどと同じです。 Fetch イベントハンドラは上のコードのようになります。 ReadableStreamという新しいクラスが登場します。中身は下で説明しますが、ここでReadableStreamをつくって、それをResponseオブジェクトを作る際に渡し、respondWith()でレスポンスをページに返しています。

var stream = new ReadableStream({
start(controller) {
  var promises = [caches.match('./header.txt'),
                  fetch(url + '.txt'),
                  caches.match('./footer.txt')];
  function pushStream(body) {
    var reader = body.getReader();
    return reader.read().then(function proc(result) {
      if (result.done)
        return;
      controller.enqueue(result.value);
      return reader.read().then(proc);
    });
  }
  promises[0]
    .then(response => pushStream(response.body))
    .then(() => promises[1]).then(response => pushStream(response.body))
    .then(() => promises[2]).then(response => pushStream(response.body))
    .then(() => controller.close());
}});

ReadableStreamの中身は、このようになります。 start()というメソッドの中でまず、header.txtとfooter.txtのキャッシュからの読み込みと、サーバへのFetchリクエストのPromiseを作っています。 下の方で、まず、ひとつ目のPromise、つまりHeader読み込みのPromiseからレスポンスを取得し、そのレスポンスボディをpushStream()という関数に渡しています。 pushStream()ではbodyからreaderを取得して、順番に読んでいって、controller.enqueue()で詰め込んでいきます。 それが終わったら２つ目のPromise、つまりFetchのPromiseからレスポンスを取得して、あとは同様にbodyの中身を徐々にenqueueしていきます。その後、３つ目のPromise、つまりfooter.txtのPromiseも同様です。最後に、controller.close()を呼んでStreamを閉じています。

このようにすると、サーバーからのレスポンスを最後まで待たずに、徐々にページにデータを返していくことができます。

Unified Media Pipeline

実は、Android Chromeは51まで、audioエレメントやvideoエレメントではAndroidのメディアスタックを利用していました。それが、7月にリリースされたChrome 52からデスクトップ版Chromeと共通化されました。 そのおかげで、

• Service Workerを使ったキャッシュ
• Blob URLからの再生
• playbackRateの指定
• MediaRecorderからのMediaStreamsをWeb Audioに送信する

といったことができるようになり、クロスデバイスの開発が容易になりました。 詳細はこちらのURLを参照してください。

Background Sync

Background Syncはどういうものかと言いますと、その名の通り、バックグラウンドでデータを送受信できる機能です。 例えば、「オフライン時にメッセージを書いて、オンラインになったときに自動で送信」といったことができるようになります。AndroidだとChromeアプリを閉じていても動作します。 この機能はChrome 49 から利用可能です。

ちょうどいい動画がYouTubeにあったのでこちらをご覧ください。 この動画は、Service Workerを使ってオフラインでもWikipediaの記事を読むことができるというWebアプリのデモです。このアプリで、キャッシュに入っていない記事を読もうとしたら、エラーになるのですが、Background Syncを使ってオンラインになった時に自動で記事をダウンロードし、ダウンロードが完了したら先ほど紹介したNotificationのAPIで通知を表示しています。

Foreign Fetch

普通の Fetchイベント

Foreign Fetchの説明をする前に通常のFetchイベントを復習します。 a.comのサイトにService Workerが登録されているとします。 この場合、

• a.comのページ自体のHTMLファイル（メインリソースと言います）へのリクエスト
• このページで読み込まれる、a.com上にある画像等のサブリソースへのリクエスト
• このページで読み込まれる、b.com上にあるサブリソースへのリクエスト

これらはすべて、Service WorkerのFetchイベントハンドラで横取りすることができます。

しかし、例えば、b.comのサイトのページからa.com上にある画像などのサブリソースへのリクエストはFetchイベントハンドラで横取りすることができません。

Foreign Fetchを使うと

これを可能にするのがForeign Fetchです。 Foreign Fetchを使うと、他のサイト(この図の場合はb.com)からの自分のサイト(この図の場合はa.com)へのサブリソースのリクエストをa.comのService Workerで横取りすることができるようになります。

普通のFetchイベント vs Foreign Fetchイベント

まとめますとこうなります。 「ネットワークリクエストを横取りする」という点は共通です。 相違点としては、 普通のFetchイベントは自分のサイトのページからのネットワークリクエストを横取りします。自分のサイトのHTMLページと、そこからの画像などのサブリソースリクエストも横取りできます。

それに対してForeignFetchイベントでは、他のサイトから自分のサイトへのサブリソースのリクエストを横取りすることができるようになります。Web FontサーバやCDN等で活用できるのではと考えられます。

Foreign Fetch の登録方法

具体的にコードを見ていきましょう

self.addEventListener('install', event => {
    event.registerForeignFetch({
        scopes: ['/myscope/'],
        origins: ['https://b.com/']
      });
  });

Foreign Fetchの登録方法ですが、先程の例のように、a.com上のService Workerが、 b.com からの a.com/myscope/ 以下へのリクエストを横取りしたい場合は、Installイベントハンドラで上のコードのようにregisterForeignFetch()というAPIを叩きます。 scopesに横取りしたいリクエストの範囲、originsにリクエスト元のオリジンを指定します。すべてのオリジンからのリクエストを横取りしたい場合は、originsにアスタリスクを指定します。

上のコードのようにForeign Fetchを登録すると、 a.com/myscope/ 以下へのネットワークリクエストの度にForeignFetchイベントハンドラが実行されるようになります。

Foreign Fetch Event

ForeignFetchイベントハンドラでは普通のFetchイベントと同じようにrespondWith()でページにレスポンスを返すことができるのですが、普通のFetchイベントと違って、辞書に包む（以下のコードの{response: res}）必要があります。

self.addEventListener('foreignfetch', event => {
    event.respondWith(
        fetch(event.request).then(res => ({response: res}));
  });

注意点として、このようにしてページに返したレスポンスはページではOpaqueになります。つまり、<img>タグで画面に表示はできるのですが、JavaScriptから中身を読むことができません。 これを読めるようにするにはCORSの設定が必要になります。

CORS (Cross-Origin Resource Sharing)

self.addEventListener('foreignfetch', event => {
  event.respondWith(
     fetch(event.request)
       .then(response =>({response: response,
                          origin: event.origin,
                          headers: ['...']})));
});

具体的にはこのように、respondWith()に渡す辞書でページのoriginを指定します。headersを指定すると、指定したHTTPヘッダもページ側で読めるようになります。

このForeign Fetchですが、まだ実験中の機能でして、試す場合は、Chrome 54以降でchrome://flagsのenable-experimental-web-platform-featuresを有効にしてください。

Header-based Installation

今まで、Service Workerを登録する場合、JavaScriptでnavigator.serviceWorker.register()を呼ぶ必要がありました。

navigator.serviceWorker.register('/sw.js', {scope: '/'});

Header-based Installationを使うと，これが、下のようなHTTPのLink Headerで登録したり、

Link: </sw.js>; rel=serviceworker; scope=/

下のような、HTMLのLink Elementで登録できるようになります。

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

ここでポイントとなるのが、サブリソースのリクエストに対するHTTPレスポンスのLink HeaderでもService Workerをインストールできるということです。この機能を使うと、Iframe等でHTMLを読み込ませる必要なく、Foreign FetchのService Workerをインストールできます。CDNなどでサブリソースをサーブしている場合でもCDNのドメインに対してForeign FetchのService Workerを登録できるようになるのです。

この機能もForeign Fetchと同様に実験中の機能でして、試す場合は、Chrome 54以降でchrome://flagsのenable-experimental-web-platform-featuresを有効にしてください。

Origin Trials

Origin TrialとはChromeの実験的な新しいAPIを、申請のあった特定のオリジン(ドメイン)で一定期間だけ使ってもらってフィードバックをもらう仕組みです。 いま(2016年10月現在)はPersistent Storage, Web Bluetooth, Web USB, Foreign Fetch (Header-based Installation含む)が対象になっています。

申請の方法など詳しくはこちらのURLを参照してください

AppCache

Application Cache (通称AppCache)という、Webサイトのオフライン対応のためにかつて提案された機能があります。

しかし、FirefoxはApplication Cacheの非サポート化を明言してまして、Chromeも非セキュアなコンテクストではAppCacheをサポートしなくするとしています。 ですので、Webサイトのオフライン対応はAppCacheではなく、Service Workerを使おうという流れにあります。

Service Workerに移行する際の参考として紹介したいのが、sw-appcache-behaviorというAppCacheの動作を Service Workerを使ってシミュレーションするライブラリです。 もし興味がありましたら、このURLを参照してください。

DevTools

DevToolsは進化が早くてよくUIが変わるのですが、今は、”Application”というタブの中にService Workersというのがありまして、こちらでService Workerの状態を確認したり、デバッグしたりすることができます。

この画面で注目していただきたいのが、このメッセージです。 Service Worker termination by a timeout timer was canceled because DevTools is attached. このメッセージは最近表示するようにしたのですが、「DevToolsがアタッチされてるので、タイムアウトによるService Workerの停止がキャンセルされました」と書かれてます。

Service Workerは一定期間イベントが実行されないと停止し、次回イベントで再起動するようになっています。ただし、DevToolsを開いている間は停止しません。 つまり、通常の状態だと、しばらくほっておくと勝手に停止し、FetchEventなどのイベントハンドラを呼ぶ必要が出ると再起動します。 ですので、Globalスコープに変数を置いて保存していると、再起動時に消えるので、Service Workerのコードを書く際は気をつけてください。

まとめ

駆け足になりましたが、Service Worker周辺の最近（ここ１年くらい）の動向について説明いたしました。下に関連リンクを貼り付けていますので、もっと詳細を確認したい方はご参照ください。

関連リンク集

Introduction to Service Worker

• https://developers.google.com/web/fundamentals/primers/service-worker/

Push

• https://developers.google.com/web/updates/2015/03/push-notifications-on-the-open-web
• https://developers.google.com/web/updates/2016/01/notification-actions
• https://developers.google.com/web/updates/2016/03/web-push-encryption
• https://developers.google.com/web/updates/2016/03/notifications
• https://developers.google.com/web/updates/2016/07/web-push-interop-wins
• https://github.com/web-push-libs/web-push/
• https://developers.google.com/cloud-messaging/

Stream

• https://developers.google.com/web/updates/2016/06/sw-readablestreams
• https://www.youtube.com/watch?v=Pii-LaWOyuo
• https://jakearchibald.com/2016/streams-ftw/#creating-your-own-readable-stream

Unified Media Pipeline

• https://developers.google.com/web/updates/2016/06/ump

Background Sync

• https://developers.google.com/web/updates/2015/12/background-sync
• https://github.com/WICG/BackgroundSync/blob/master/explainer.md
• https://ponyfoo.com/articles/backgroundsync

Foreign Fetch

• https://github.com/slightlyoff/ServiceWorker/blob/master/foreign_fetch_explainer.md
• https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#on-foreign-fetch-request-algorithm
• https://crbug.com/540509
• https://github.com/slightlyoff/ServiceWorker/pull/751

Header-based installation

• https://crbug.com/582310
• https://github.com/slightlyoff/ServiceWorker/issues/685#issuecomment-176473764

Origin Trials

• https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

Web Bluetooth

• https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web?hl=en

WebUSB

• https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web

当日の講演資料と動画は下記で公開されていますので、こちらも参照してください。

• 講演資料

HTML5 Conference 2016特集・第四弾は、「HTMLスナップショット2016」。2016年現在、HTMLはW3CとWHATWGという2つの組織によって別々に標準化が進んでいます。2つのHTMLが存在するに至った歴史と将来の展望、両者の違いを簡単にまとめます。

2つのHTMLに至った歴史

1999年にHTML4.01勧告が発行されてから足掛け15年、2014年にHTML5が勧告として発行されるに至ったわけですが、その間の主な出来事を表1に示します。

XMLこそがウェブの未来であるという見方が支配的だったために、2004年のOperaとMozillaの共同提案は却下され、W3CでHTMLを改良する道が閉ざされました。そこでブラウザーベンダーが集まってW3Cとは別の組織でHTMLやHTMLに関連する仕様の改良を行う、というのがWHATWGのはじまりです。

以来今日に至るまでずっと、WHATWGはHTMLの開発を（ある期間はW3Cと共同で、ある時期からはW3Cとは別に）し続けています。「WHATWG HTMLこそが実装者とウェブ開発者によって参照されるべき最新の仕様であり、欠陥フォーク（W3C HTMLのこと）は答えではない」というのはWHATWG HTMLのエディターであるAnne van Kesterenの言葉の通り、WHATWG HTMLを第一に参照すべきでしょう。

HTML5勧告以降のW3Cの動向

さて、W3Cに話を戻します。HTML5はスケジュールどおりに勧告となりましたが、後続のHTML 5.1はなかなか方針が定まらないまま、結局2015年の秋にHTML Working GroupがWeb Platform Working Group (WPWG)に改組されました。2016年1月にようやく新Working GroupからGitHubで開発を再開するというアナウンスがなされ、周知の通り6月にHTML 5.1は勧告候補となり、9月15日付けで勧告案が発行されました。順調にいけば、10月下旬には勧告が発行されるでしょう。

また、WPWGの新しいCharter（憲章）案には、すでに8月に草案として公開したHTML 5.2を2017年第4四半期に勧告とする、さらにはHTML 5.3の最初の公開草案を2017年第3四半期に発行するといった文言も見られますので、W3Cとしては1年に1回程度のペースで更新していく算段なのでしょう。

ところで、この9月に行われたTPACにおけるWPWGのミーティングでは、2つのHTMLが存在することそのものの問題は認識されており、このミーティングの中では「（2つのHTMLの）唯一の解決策はW3CがHTMLの作業を止めること」というような発言もWPWGの共同議長であるCharles McCathie Nevileから飛び出しましたが、WPWGとして合意に至るような結論は出されませんでした。あるいはHTMLをコア技術として採用しているEPUBの動向によっても、HTMLの開発に何らかの影響を与える可能性があると思われます。

2つのHTMLの違いについて

これまではごく簡単にW3Cから見たHTMLの過去と将来をざっくり俯瞰してみましたが、ここからは技術的に2つのHTMLがどのように異なるのかを見ていきたいと思います。図1は、2つのHTMLの違いを示したものですが、W3C HTMLがWHATWG HTMLの厳密な部分集合ではなく、W3C HTMLにWHATWG HTMLとは異なる独自の規定があるという点が肝となります。

具体的にどのように違うのか、というのは2つのHTMLの違いを明瞭に記述した文書が存在しないため、その全容を正確に把握するのは困難が伴います。理論上は両HTMLのGitHubのコミットログを丹念に追いかければ可能ですが、ここではW3C HTML (HTML 5.1の勧告案) とWHATWG HTML（HTML LS）の要素や属性の違いなどについて、紙面の都合上その全部の詳説は省きますが、主に両者の索引の比較からその一端を明らかにしようと思います。まず、要素の違いについて表2に示します。

今年に入ってWHATWG HTMLに導入されたShadow DOMに関わる<slot>要素を除けば、HTML 5.1とHTML 5.0でそれほど大きな違いはないと言えます。また、要素そのものは存在しますが、少なくとも<main>の定義や<dl>の説明にHTML 5.1とHTML LSとの間で差異があることを筆者が確認しています。これ以外にも2つのHTMLの説明で異なるものがあるかもしれません。続いて、属性の違いを表3に示します。

そもそもW3C HTMLでは別仕様として切り離されているMicrodata関連の5つの属性を除けば、11の属性が片方の仕様にあってもう片方にはない、という状況になっています。longdesc属性に至っては、一旦はHTML 5.1自身に含めておきながら、再び拡張仕様に分離する（すなわち、HTML 5.0とlongdesc拡張仕様の関係に戻す）という迷走を見せています。さらに、説明は省きますが、イベントハンドラー属性の違いを表4に示します。

また、IDL属性として、innerTextがWHATWG HTMLに規定されています。最後に両HTMLの違いとしてコメントの構文の違いを挙げておきます。

<!-- これは正当なコメントです -->
<!-------->
<!-- ↑のようなHTML断片を書いたことはありますか？ -->

コード例の2行目は、WHATWG HTMLでは正当なコメントになります。

おわりに

駆け足でW3C視点での歴史と将来の展望、およびW3C HTMLとWHATWG HTMLとの要素や属性、構文など比較を行いましたがいかがでしたでしょうか。W3C HTMLはあまりうまく策定作業が行われていない一方で、WHATWG HTMLのレポジトリーでは活発に議論が交わされており、毎日のようにHTMLが更新され続けています。当面は勢いのあるHTML Living Standardを参照するようにしてはいかがでしょうか、という提案をもって締めさせていただきたいと思います。

当日の資料と動画は下記で公開されていますので、こちらも参照してください。

• 講演資料

セッション内容を講演者自らが解説するという「HTML5 Conference 2016特集」の第三弾。今回のテーマは「Webのグラフィックス後編: WebGL2、そしてWebVR」。
すでに策定が始まっている次期バージョンWebGL2.0のお話や、WebでVRを実現する「WebVR API」を用いてVRコンテンツの実装の仕方を解説します。

VRとは？

今年、2016年はVR元年と言われ、様々なVRデバイス、VR関連ガジェット、VRコンテンツが世に生み出されています。 しかし、VR発祥は意外と古く、遡ること1960年代にVRの基礎となる理論、デバイスが発表されています。

ただ当時は個人で手が出るものではなく、体験自体はデパートのアトラクションとして登場するなど、体験は限定的でした。

参考

時を戻して2016年。世界が動き出します。
2016年6月時点のGoogle検索トレンドでは、検索回数が飛躍的に伸びているのが見てとれます。

きっとこれを読まれている方も、周りで「VR」というワードを聞くことが増えてきたのではないでしょうか。そしてこの波に乗るように、VRについてもWebでの体験を可能にする技術が公開されています。

WebVRは体験の話ではない

WebでのVR技術、それが「WebVR」です。
取りざたされているVRを手軽にWebで体験できるもの。それが「WebVR」。

…ではなく。
あくまでWebVRはイチ仕様に過ぎません。
つまり、WebVRに対応したからといって、即座にWeb上でVRコンテンツを提供できる、という類のものではないということです。

WebVRはAPIの仕様

誤解を恐れずに言えば、WebVRはセンサーからの情報を扱うためだけのAPIです。
要は、HMD（ヘッドマウントディスプレイ）からの位置、回転、視野情報など様々な、ハードウェアの情報を取り扱うAPIということです。もっと言ってしまえば、モバイルで利用しているジャイロセンサーとなんら変わることはない、ということです。

事実、WebGLの仕様と比べると格段に少ない内容の仕様となっています。（仕様はこちら）

VRコンテンツの構築

Webで手軽に体験できるVRコンテンツ、と書きましたが提供する側が同じく手軽であるとは限りません。
（とはいえ、その他のネイティブなVRコンテンツと比較すると格段に手軽だと思いますが）

WebVRはただのAPIだと書きました。
つまり、VRコンテンツ自体は別のAPI、具体的にはWebGLを利用して3Dコンテンツを制作する必要があります。事実、VRコンテンツの制作について既存の3Dコンテンツの制作と違いはほとんどありません。

WebGLコンテンツでは通常、requestAnimationFrameなどを利用して、一定時間置きに画面を更新しアニメーションやインタラクションを実現します。ジャイロセンサーを使ったコンテンツの制作を行ったことがある方であれば、どういったコンテンツが制作できるのかのイメージがわくでしょう。

そして上でも書いたように、ジャイロセンサーで行っていたような処理をWebVR APIに替えて画面を更新してやればいいのです。

ただし、（当然ではありますが）通常のWebGLコンテンツとWebVRコンテンツでは決定的に違うところがあります。それは「VR体験を作り上げる必要がある」という点です。

具体例を上げましょう。
今までの3Dコンテンツはカメラの位置は製作者側で制御可能でした。
ということはつまり、都合の悪い、カメラの後ろ側を映さないようにカメラを制御することができた、ということです。 しかし、VRコンテンツはそのカメラの操作はユーザーの視点という形で使われるため、当然、その後ろ側を見られる可能性があります。
（というより、ほとんどの場合、ユーザーはあたりを見渡すでしょう）

このように、裏側が見られてしまうということは、悪く言えば手抜き、よく言えば無駄を省いた部分までもしっかりと作り込まないとならないということを意味しています。

基本的なセットアップ方法

さて、それではざっくりとですが、WebVR APIを使ったセットアップのコードを紹介しましょう。
本コードはこちらのサイトのサンプルを引用させていただいています。

▼ HMDハードウェアの参照を取得する

navigator.getVRDisplay().then(function (displays) { if (!displays.length) { return; }

vrDisplay = displays.length[0];

}).catch(function (err) { console.error('Could not get VRDisplay', err.stack); };

▼ 描画対象として必要なサイズを取得する

var eyeParameter = vrDisplay.getEyeParameters('left'); var width = eyeParameter.renderWidth; var height = eyeParameter.renderHeight;

▼ WebGLのCanvasおよびVRモード移行のための処理を記述 var webglCanvas = document.querySelector('#webglcanvas'); var enterVRBtn = document.querySelector('#entervr');

vrDisplay.exitPresent();

▼ 画面のアニメーションループを処理する var id = vrDisplay.requestAnimationFrame(onAnimationFrame);

vrDisplay.cancelRequestAnimationFrame(id);

▼ HMDのセンサーからの値を取り出す var pose = vrDisplay.getPose();

var position = pose.position;

▼ ハードウェアに設定された個々の設定を読み取る（瞳孔間距離など） var eyeParameters = vrDisplay.getEyeParameter('left');

var eyeMatrix = makeProjectionMatrix(vrDisplay, eyeParameters);

▼ 取得した情報から、プロジェクション行列を生成する function fieldOfViewToProjectionMatrix (fov, zNear, zFar) { var upTan = Math.tan(fov.upDegrees * Math.PI / 180.0); var downTan = Math.tan(fov.downDegrees * Math.PI / 180.0); var leftTan = Math.tan(fov.leftDegrees * Math.PI / 180.0); var rightTan = Math.tan(fov.rightDegrees * Math.PI / 180.0); var xScale = 2.0 / (leftTan + rightTan); var yScale = 2.0 / (upTan + downTan);

var out = new Float32Array(16);
out[0] = xScale;
out[1] = 0.0;
out[2] = 0.0;
out[3] = 0.0;
out[4] = 0.0;
out[5] = yScale;
out[6] = 0.0;
out[7] = 0.0;
out[8] = -((leftTan - rightTan) * xScale * 0.5);
out[9] = ((upTan - downTan) * yScale * 0.5);
out[10] = -(zNear + zFar) / (zFar - zNear);
out[11] = -1.0;
out[12] = 0.0;
out[13] = 0.0;
out[14] = -(2.0 * zFar * zNear) / (zFar - zNear);
out[15] = 0.0;

return out;

}

Three.jsを使えばお手軽

WebGLといえばThree.js、というくらいデファクトスタンダードなライブラリとなったThree.js。
実はThree.jsのリポジトリにはWebVRに対応するためのプラグインがすでに存在しています。

それは VRControl.js と VREffect.js の2種類です。
これはどちらもThree.jsでVRを実現するのを手助けしてくれるプラグインです。
VRControl がHMDのセンサーの処理を、 VREffect.js がフルスクリーンモードへの移行や、VRモードの表示を手助けしてくれます。

基本的に、Three.jsを使った3Dコンテンツ制作の方法はVR化すると言っても大きな違いはありません。
その証拠に、VR化するためのコード断片は以下のようにとても短いものとなります。

var controls = new THREE.VRControls(camera); var effect = new THREE.VREffect(renderer);

// clickイベントなどのユーザ操作のタイミングで実行される関数 function toVRMode() { effect.requestPresent(); }

対応ブラウザ

対応ブラウザは、執筆時点（2016/09/28）ではまだ限定的にしか存在していません。
安定版で動作するものは今のところないのが現状です。

対応状況は以下のサイトから確認することができます。
Is WebVR Ready?

VR成功の鍵を握るのはWebVR

個人的な見解ですが、VR成功の鍵をにぎるのはWebVRにあると思っています。
その理由はいくつかあります。

一つ目が、プラットフォーム（Oculus Rift、HTC Viveなど）に依存しないこと。
つまり今までのWebアプリと同様に、モバイル、PCなどのプラットフォームに依存しないコンテンツ展開ができることです。

二つ目に、インストールが不要なこと。ネイティブアプリにしてしまうとどうしてもこの「インストール」という手順が必要になってしまいます。しかし、WebVRであればWebサイトに訪れたユーザが、VRモードの開始ボタンを押すだけでVR体験をすることが可能になります。

そして最後の三つ目として、「ちょっとだけVR」が使えること。
例えばECサイトの商品をVRで見てみる、例えば不動産サイトの部屋の感じをVRで体験してみる、などなど、VRが活用できればユーザの利便性が上がることはたくさんあります。

しかし、例えばこれらを、アプリをインストールしたのちにしか行えないとしたら大部分の人はそれを倦厭するでしょう。

またコンテンツ制作側からしても、そんなちょっとしたVRアプリだけをプラットフォームに載せて配信する、というハードルの高さも出てくるでしょう。

こうしたように、今までの「Webならではの良さ」がそのままVRにも当てはめることができると考えています。そしてこれが結局、VRとユーザの接点となり、より多くの人にVRとはなにか、VRでどんなことができるかを広める機会になると考えています。

まとめ

まとめると、

• WebVRはAPIの名称
• WebVR APIがやってくれるのはセンサーの値を取るなどの最低限の処理のみ
• Three.jsを使えば手軽にVRコンテンツの制作が可能
• とはいえまだサポートブラウザが（ほぼ）ない
• しかし、Webでの活用はまだまだ（いい意味で）未知数

ということです。
詳細についてはカンファレンスで使用したスライドがアップされているので、そちらを参照ください。

当日の動画は下記で公開されていますので、こちらも参照してください。（編集部注：動画は3：26：10あたりから比留間さんの講演となります）

2016年9月3日に東京電機大学で開催された「HTML5 Conference 2016」のセッションを特集する第二弾は筆者である私、小林徹が登壇した「 Reactの最新動向とベストプラクティス 」の内容を解説します。

Reactの現状

Reactは、2013年にFacebookが公開した、Viewを作るためのJavaScriptのライブラリーです。

• https://facebook.github.io/react/

現在のバージョンはv15.3.2です。 v1.0.0からv14.0.0までのバージョンはありません。 「すでに安定していてプロダクションでも利用できる」ことや「セマンティック・バージョニング（パッチ.マイナー.メジャー）に準拠している」ことを示すために、v0.14.8からのバージョンアップ時にv0.15.0ではなく、マイナーのバージョン番号をメジャーにシフトさせてv15.0.0になりました。

Reactの採用事例を見ていきましょう。

Reactを開発しているFacebookは、ウェブページのコメント欄などで部分的にReactを使用しています。 同じくFacebookが運営しているInstagramでは、ウェブページ全体をReactのComponentで構築しています。

Facebook以外の事例を見てみると、NetflixやTwitter、Airbnb、Uberなど多くの企業でReactが使われています。 日本でも、Abema.tvなど大規模にReactが導入されている事例が増えています。

これらは、ReactのDeveloper Toolsを使用することで確認できます。

• https://github.com/facebook/react-devtools

また、Electron製のターミナルソフトであるHypertermは、ReactとReduxを使って作られています。 機能拡張の仕組みを、Reduxのミドルウェアの仕組みで実現するなど興味深い点も多く、ソースコードはGitHubで公開されています。

• https://github.com/zeit/hyperterm

他にもJenkinsが、新しいUI ComponentをReactのComponentとして提供しているなど、Reactはまさに「今使われているライブラリー」であることが言えます。

特徴

それではまず最初に、Reactの特徴について見ていきましょう。 Reactのサイトのトップには、「Declarative」、「Component-Based」、「Learn Once, Write Anywhere」の3つのキーワードが紹介されています。

「Learn Once, Write Anywhere（一度学べば、どこでも書ける）」は、ReactにとってDOMはreact-domによるただの1つの環境であることを表しています。 react-nativeなどを使うことで、「同じReactの考え方」でiOSやAndroidのような、DOM以外の環境をターゲットにしたアプリケーションを開発できます。

「Write Once, Run Anywhere（一度書けば、どこでも実行できる）」ではないのは、Viewは各プラットフォームのルールや特徴に応じて構築するべきであり、安易に共通化すべきでないことを意味しています。 しかしながらViewに関連しないロジックの多くは共通化できるとしており、実際にFacebookのAds Managerのアプリは、react-nativeを使うことでiOSとAndroidで80%以上のコードが共通化できているそうです。

それでは、DeclarativeとComponent-Basedについて見ていきます。

Declarative

Reactでは、Declarative（宣言的）にComponentを組み合わせてViewを構築します。 宣言的という言葉の通り、状態に対しての「あるべき姿」を宣言するように定義します。

例えば、イベントに対する処理を命令的に記述すると、下記のようになります。

// elに対する変化を書いている
button.on(‘click’, () => el.append(child));

これを宣言的に書くと、下記のようになります。

// render関数は、渡されたstateに対するあるべき表示を定義している
render = state => {
  el.innerHTML = state.map(child => `<div>${child}</div>`).join(‘’);
};

// 状態を更新して、render関数に渡す
button.on(‘click’, () => {
  state.push(child);
  render(state);
};

上記の場合、render関数は受け取ったstateをもとにViewを構築するだけです。 これは、初期表示の場合もイベントによる更新時も常に同じです。

この結果、render関数はstateのみに依存し、同じstateからは常に同じViewを構築します。 これは、テストやデバッグを容易にします。

ReactはComponentを使い、宣言的にViewを構築します。

const View = props => (
    <div>{props.items.map(item => <div>{item}</div>)}</div>
);

Component-Based

Reactでは、Componentを作り、組み合わせることでViewを構築します。 Componentは、Appのようなアプリケーションを全体を表すものから、TextBoxのような既存の要素を少し拡張するようなものまで規模は様々です。

class App extends React.Component {
  constructor(...args) {
    super(...args);
    this.state = {
      text: '',
    };
  }
  render() {
    return (
      <TextBox
        text={this.state.text}
        onChange={text => this.setState({text})}
      />
    );
  }
}
const TextBox = (text, onChange) => (
  <div>
    <input type="text" onChange={e => onChange(e.target.value} />
    <p>{text}</p>
  </div>
);

ReactDOM.render(
  <App />,
  document.getElementById('app')
);

Componentは、View = Component(State)のような、Viewを作る関数として考えることができます。 Componentが返すViewは、ReactElementのツリーとなります。 作成したReactElementのツリーは、ReactDOMによってDOMへと反映されます。 更新時は、更新前のReactElementのツリーと比較して、差分だけがDOMに反映されます。 これがVIRTUAL DOMと呼ばれる部分です。

この差分の反映により、Reactは関数のようにViewの構築を宣言的に書いた場合でも、パフォーマンスの劣化を避けることができます。 先ほど紹介したReactを使わないinnerHTMLによる反映では、毎回DOMを再構築するため、規模が大きくなるとパフォーマンス上問題となります。

Componentの作り方

React Componentの作成方法には、下記の4種類あります。

• Stateless Functional Components
• React.Component
• React.PureComponent
• React.createClass

Stateless Functinal Componenens

関数によるComponentの定義方法です。

const Item = ({item}) => (
  <div>
    <div>{item.name}×{item.count}</div>
  </div>
);

ただの関数であり、インスタンスも持たないのでStateやライフサイクルメソッドが定義できないなどの制限があります。 ですが最もシンプルな定義方法であり、Componentを作成する際は、まず最初にStateless Functional Componentsで定義できないかを考えることをオススメします。

SFCと省略して記述されることもあります。

React.Component

ComponentにStateを持たせたい場合や、ライフサイクルメソッドを使いたい場合にはReact.Componentを使った定義方法を使います。

class App extends React.Component {
  constructor(...args) { 
    super(...args);
    this.state = {
      user: null,
    };
  }
  componentDidMount() {
    fetch('/api/user')
    .then(res => res.json())
    .then(user => this.setState({user}))
    ;
  }
  render() {
    if (this.state.user == null) return <Loading />;
    return (
      <div>
        <User user={this.state.user} />
      </div>
    );
  }
}

React.PureComponent

パフォーマンスが問題となるような場面では、React.Componentの代わりにReact.PureComponentの利用を検討します。 React.PureComponentを使うことで、PropsとStateに対してのshallowEqual(浅い比較)がshouldComponentUpdateに適用されるようになります。

shouldComponentUpdateは、無駄なrenderメソッドの呼び出しを避けるためのライフサイクルメソッドです。

class Counter extends React.PureComponent {
  constructor(...args) {
    super(...args);
    this.state = {count: 0};
  }
  render() {
    return (
      <div>
        <p>{this.props.label}:{this.state.count}</p>
        <button
          onClick={() => this.setState({count: this.state.count + 1})
        />
     </div>
    );
  }
}

React.PureComponentは、PropsやStateのデータをイミュータブルに扱っている場合に利用できます。 イミュータブルであることが保証出来ない場合は、React.Componentを使い、shouldComponentUpdateを自ら実装する必要があります。

ただし、最適化はreact-addons-perfを使い、問題となっている部分を計測して確認してから行うことをオススメします。

React.creteClass

React.createClassは、最初から存在するComponentの作成方法です。 ですが、今後は緩やかに非推奨の方向に進んでいます。

Componentの拡張

Reactでは、Componentの拡張を継承ではなく、Higher Order Components(HOC)を使ったCompositionで行うパターンが推奨されています。

Higher Order Componentsとは、高階関数（Higher Order Function）のComponent版と考えることができます。 Higher Order Functionは関数を引数や戻り値とする関数です。

https://ja.wikipedia.org/wiki/高階関数

• Higher Order Functionの例

// 何かする関数を受け取って、結果をログ出して返す
const logger = operation => (...args) => {
    const result = operation(...args);
    console.log(result);
    return result;
};
const add = logger((a, b) => a + b);
add(10, 20);
// 30

Higher Order Componentsでは、Componentを引数として受け取り、それをラップした新しいComponentを返します。

• Higher Order Componentsの例

// Componentを受け取って、PureComponentでラップして返す
const pure = Component => (
  class Pure extends React.PureComponent {
    render() {
      return <Component ...{this.props}/>;
    }
  }
);
const Item = ({name}) => <div>{name}</div>;
const PureItem = pure(Item);
// <PureItem name=“foo” />

Higher Order Componentsのパターンは、react-routerやreact-reduxなどのライブラリーでも使われています。

また、Higher Order Componentsのパターンを集めたrecomposeというライブラリーもあります。

• https://github.com/acdlite/recompose

// isLoadedによってComponentを出し分ける
const enhance = branch(
  props => props.isLoaded,
  Component => Component,
  () => Loading
);
const LoadUser = enhance(User);
// <LoadUser isLoaded={isLoaded} user={user} />

State管理

Reactでは、ComponentはView = Component(State)であると紹介しました。 したがって、Componentにはなるべく状態を持たせないことが推奨されます。

これにより、親Componentだけに状態管理が集約します。 親Componentは、子Componentに「状態」と「状態を変更するための関数」を渡します。 子以下のComponentは、それらを受け取り利用するだけです。

ViewTree = ComponentTree(State)

親Componentに状態管理が集約されることで、アプリケーションの状態を把握することが容易になります。 それと同時に、子Componentはほとんどロジックを持たず、状態を受け取りViewを構築するStateless Functional Componentsで定義可能なただの関数になります。 これによりテストも容易になります。 加えて、親のComponentは状態管理、子のComponentは見た目に関してと、役割を明確に分けることができます。

しかしながら、このパターンの場合、親Componentに処理が集中するため、規模が大きくなると管理が難しくなります。 その解決方法として、Facebookが発表したFluxというアーキテクチャがあります。

Fluxでは、状態管理の流れを役割ごとに細かく分割し、React Componentから切り離します。

Fluxの影響を受けているライブラリーとして、Reduxがあります。 Reduxは、状態管理のためのライブラリーです。

• http://redux.js.org/

Reduxでは、アプリケーションの状態をシリアライズ可能な1つのオブジェクトにまとめます。 状態の更新は、Actionを発行して、Reducerと呼ばれるActionを元に新しい状態を作成する関数によって行われます。

Reduxでは、React ComponentをContainer ComponentとPresentational Componentの2つの役割に分けます。 それぞれの役割は以下の通りです。

Reduxでは、データはシリアライズ可能なオブジェクトとして単一のStoreに保持されるため、各処理は入力を受け取り入力に応じた結果を出力するただの関数として実装できます。

• アクションの発行 – action = ActionCreator([event])
• 状態の更新 – newState = Reducer(state, action)
• 状態の取得 – props = Selector(state)

これにより、各部分もPresentational Componentのように簡単にテストができます。

状態と処理を切り離し、ActionとStateをシリアライズ可能なオブジェクトにすることは、デバッグや状態の再現を容易にします。 それを利用したRedux DevTools Extensionでは、Actionを記録して任意のActionの流れを再現するだけでなく、指定したActionの流れをJSONとしてインポート・エクスポートできます。 これにより、処理の流れを複数人で共有したり、エラーがあった場合にサーバーに送信することで、状況の再現が可能になります。

• https://github.com/zalmoxisus/redux-devtools-extension

Reduxを使う場合、副作用や非同期処理の扱いを、Middlewareのレイヤーで吸収します。 Middlewareは発行されたActionを改変したり別のActionを発行するなど、アプリケーションの処理に大きく影響を与える部分です。 副作用や非同期処理を扱うためのMiddlewareは、すでにたくさん公開されています。 したがって、アプリケーションの要件に適した、副作用や非同期処理の方法を選択できます。

FluxアーキテクチャやReduxは、必要と感じるまで利用する必要はありません。 ですが、Reduxを使わない場合でも、React ComponentをContainer ComponentとPresentational Componentに分けて考えることは重要です。

エコシステム

Reactでは、すでに多くのエコシステムが存在します。 React Componentのテストを簡単に書くための仕組みを提供してくれるEnzymeや、Component単位でデザインを確認しながら開発できるReact StorybookなどOSSからたくさんのライブラリーやツールが公開されています。

• http://airbnb.io/enzyme/
• https://getstorybook.io/

また、React ComponentやJSXのためのESLintのプラグインも存在します。

• https://github.com/yannickcr/eslint-plugin-react

コーディングのスタイルだけでなく、廃止予定のAPIの使用や、ベストプラクティスに沿っているかなど数多くの観点からのチェックが可能です。 ESLintとともに利用をオススメします。

また、a11yに対するチェックを行うeslint-plugin-jsx-a11yというプラグインもあります。

• https://github.com/evcohen/eslint-plugin-jsx-a11y

将来

Reactは、Facebookが開発しているライブラリーです。 Facebookの内部ではすでに25,000以上のReact Componentがあるそうで、ReactはFacebookの中でも重要な位置付けのライブラリーとなっています。 そのためFacebookが必要としている機能に対する優先度は当然高くなりますが、今後も継続してメンテナンスされることが期待できます。

加えて、OSSとしての役割も重要視されています。 例えば、SVGやcustom elementsの対応のようなFacebookでは必要とされていない機能も必要であればReact本体でサポートされます。 また、ReactのコアチームのミーティングノートをGitHubで公開したり、コマンド1つでReactを使ったアプリケーションの雛型を作成するcreate-react-appもその1つです。

• https://github.com/reactjs/core-notes
• https://github.com/facebookincubator/create-react-app

前述した通り、Facebookだけでなく多くの企業がReactをプロダクションで使用しています。 そのため、Reactは非互換な変更に対してはとても慎重です。

何かAPIを廃止する場合は、「次のメジャーバージョンで警告の出力と移行プランの提供」、「その次のメジャーバージョンで廃止」という流れになります。 したがって、メジャーバージョンアップで突然動作しなくなることがないように配慮されています。

現在進行中の大きな開発として、「ReactFiber」があります。 ReactFiberは、ComponentとRendererがやりとりする、Reactのコアとなるアルゴリズムを全面的に書き直すものです。

現在は、更新処理からReactElementの差分計算・DOMへの反映までが同期的に行われています。 これは、規模の大きなComponentツリーや60FPSが求められるような場面で問題となることがあります。

ReactFiberでは、更新処理をFiberというタスクの単位で非同期に処理できるようになります。 例えば、アニメーションの更新処理など遅延が許されないものは、requestAnimationFrameを使い可能な限りすぐに反映し、APIのレスポンスや画面に表示されてない部分は、requestIdleCallbackを使い多少の遅延を許容するといった具合です。

ReactFiberは、現在ベースとなる部分が実装中であり、すぐに現在のアルゴリズムと置き換えられるものではありません。 しかしながら、今後注目すべき動向の1つです。

まとめ

ReactはComponentを使いViewを構築するためのライブラリーです。 そのためReactが担う範囲は広くありません。しかし、Reactを使うことでクライアントでの状態管理の難しさを排除し、シンプルに考えることができます。

また、Facebookのサイト自体もそうであるように、ReactはSingle Page Applicationではないアプリケーションに対しても、部分的に導入していくことが可能です。 その際に必要となる、設計としては綺麗とは言えないようなAPIも提供しています。

Reactを取り巻くエコシステムは大きくなっており、それらの組み合わせを紹介する記事も多く存在します。

しかしながら、Reactをこれから初めてみようと思っている場合は、最低限の構成で小さく始めることをオススメします。その後、必要だと思った段階で、エコシステムが提供するライブラリーの導入を順番に検討してください。

そうすることで、各ライブラリーが、「何を」問題と考えて「どのように」解決しようとしているのかを理解できるようになります。その結果、多くの情報やライブラリーに振り回されることなく、エコシステムと付き合っていけるようになると考えています。

上記の基調講演は動画でも公開中です

当日の資料と動画は下記で公開されていますので、こちらも参照してください。

Web技術者の祭典「HTML5 Conference 2016」が2016年9月3日に東京電機大学で開催されました。今年もWebの最先端で活躍するエキスパートたちがWebAssembly、Angular、React、Progressive Web Apps、AI・機械学習、WebVR、IoTなどHTML5を取り巻く注目の技術について語りました。

HTML5 Experts.jpでは、HTML5 Conferenceのセッションで語られた技術情報を特集としてレポートしていきます。その第一弾として、基調講演として行われた2つのセッションを紹介します。

Webは世界で動く唯一の分散型OSである

トップバッターとして登壇したのは、W3Cのサイトマネージャである慶應義塾大学環境情報学部・中村修教授。セッションタイトル「WEBという名前の大規模分散オペレーションシステム」。

色の輝度幅を拡大し、高画質化する技術HDR（High Dynamic Range）がNetflixなどの映像コンテンツなどに使われているが、Webブラウザから輝度情報のハンドリングするAPIを作るなどで、HDRをWebでも使うことができないかという投げかけから、講演をスタートさせました。

▲慶應義塾大学環境情報学部教授 W3C/KEIO Site Manager 中村 修氏
（1983年　慶應義塾大学工学部卒業　工学博士、1990年から東京大学大型計算機センター助手を経て1993年慶應義塾大学環境情報学部助手となり、現在慶應義塾大学環境情報学部教授。1987からWIDEプロジェクトにてインターネットの研究開発に携わる。広帯域インターネットやIPv6の研究開発、普及に携わる。2014年からW3C/KEIO Site Managerに就任し、Web技術の標準化活動を推進する。WIDEプロジェクトボード、総務省IPv6研究会委員、IPv6普及高度化推進協議会理事も務める）

Webはこれまで既存の文化や紙のような表現・データ構造に引っ張てきた。だが、これからはロボットやVRといった新しいデバイスに対し、新たなデータ表現を取り入れたコンテンツの発信を行っていくことがミッションであるという中村修教授。

IT業界ではビッグデータ、AI、IoTといった技術がバズワードになっているが、その基盤となっているのはWebとインターネット。「皆さんが基盤を支えている、今の世界を作っていることを再確認してほしい」とメッセージを送ります。

「Webは世界で動く唯一の分散型OS（Distributed Operating System）であり、インターネットで繋がった世界や、IoTで繋がるすべてのデバイスなどの計算資源をHTTP/HTTPS、HTML、URL、APIによってユーザーに提供している。W3Cでは日本のHybridcastや欧州のHbbTV 2.0がHTML5に準拠し、自動車の地図の車載情報やセンサー情報が、Webプラットフォームとして扱うためのAPIが研究されている。近い将来、車載のディスプレイやインパネはHTML5になるはず」と中村教授は言います。

W3Cの活動状況については、電子書籍とWebに関してもIDPF(E-Pub)とW3Cの統合に向けた話し合いが行われていることや、日本独自の文化である縦書きやルビの標準化が進んでいることを報告。ブロックチェーンに関するワークショップも7月に開催されたとのこと。

なぜ、W3Cがその話をするのかといえば、世界中のみんなでトラストして作ることがオープンな分散環境となるからだという中村教授。みんながオープンで平等な世界観がブロックチェーンなら発揮できる、WoT（Web of Things）の世界が作れるのではないかと語り、「WoT Servient」というアーキテクチャを紹介。

さらに、「Webとインターネットの共通のPhilosophy（哲学）はOpen」と、Webの生みの親とインターネットの父の言葉を紹介。「様々なデバイスや制御のためのプログラムインターフェイスとなるAPI、セキュリティ、新しいアプリのためのアーキテクチャ、共通な識別子とデータ構造とその表現を考える必要がある。Webコミュニティの協力を得ながら、こうしたWebの機能拡張を進めていきたい」とセッションを締めくくりました。

アプリケーション・メディア・プラットフォーム、3つの側面から見たWeb

及川卓也さんのセッションでは、「アプリケーションとしてのWeb」「メディアとしてのWeb」「基盤技術としてのWeb」という3つの側面から見たWebが語られました。

※こちらのセッションは、要約としてご紹介します。

▲Increments株式会社 プロダクトマネージャ 及川 卓也氏
（大学卒業後、外資系コンピューター企業での研究開発、マイクロソフトでの日本語版・韓国語版Windowsの開発統括を経て、グーグルでプロダクトマネージャとエンジニアリングマネージャを務める。2015年11月より、プログラマのための技術情報共有サービス「Qiita」やドキュメントを軸としたコラボレーションサービス「Qiita:Team」を提供するIncrements株式会社にてプロダクトマネージャとして従事。エンジニアのキャリアプランニングやエンジニアリングマネージメントなどの領域で自社のQiitaやQiita:Teamの活用を軸としてスタートアップにアドバイスも行う）

1.アプリケーションとしてのWeb

これは、まさに今私たちがHTML5と呼んでいるWebそのもの。情報の公開や共有手段としてセマンティック性を持ったWebを、アプリケーションプラットフォームとして定義しなおし、実際に使えるものにしようというものです。

デスクトップアプリケーションから始まり、ネイティブのアプリケーション、最近ではモバイルアプリケーションを中心にAPIの補充やさまざまな機能が追加され、プログラマの生産性を高めるためのコンポーネント技術や、Progressive Web Appsなどに転換していきました。

中村先生がHDRの話をしたので思い出したのですが、以前からaudioタグやvideoタグというようなプラグインを必要としないオーディオやビデオの再生がWeb上でできるようになると、Google Developer Dayなどの基調講演でも話してきました。

GoogleのChrome WebAudioチームは、サラウンドサウンドを配信するOmnitoneを開発し、すでに空間音響システムをWebで実現しています。VRなどのビジュアルの世界で仮想現実を実現することができるようになってきたんですね。

さらに視野を広げてみると、Webというのはデスクトップパソコンの横長のディスプレイやキーボード、マウスに閉じていたのですが、それを超えたものが考えられ、標準化され、実装されていくという世界になっています。

Progressive Web AppsはSingle-page Application（SPA）で考えたときに、よりアプリ化するところの新たな提案になるわけです。 Chromeアプリはdeprecateされたが、失敗というわけではなく、学んだことを活かして別の形にしたものがProgressive Web Appsなんです。

WebAssemblyの登場により、Webって何だろうと考えることがあります。CやC++で書かれたものがネイティブコードで動く。asm.jsやGoogle Native Client（NaCl）が出てきて、言語がJavaScriptであるという必要もなくなってきた。いわゆる1990年後半のWebと言われているものとは違い、汎用のアプリケーション技術として認識したほうがいいのではないかと考えています。

2.メディアとしてのWeb

次はモバイルデバイス、スマホという切り口で考えてみたいと思います。隙間時間にはスマホを見ている人はたくさんいます。その典型例がニュースキュレーションアプリ。マーケットリサーチも示しているように、情報を取得する手段として、ニュースキュレーションアプリが最も使われているのは明らかです。

ここでWebがどういう役割を果たせているか、課題は何かを考えてみます。Webのニュースサイトを「モバイルで見る」ときに、私たちは今まで何をしてきたか、何をさぼってきたかを目の当たりにするわけです。逆に言うと、なぜニュースキュレーションに特化したアプリが出てきたか、なぜ多くの人に使われているのか。これはモバイルのWebページが否定されているということでもあるのです。

ブラウザからニュースサイトを開くと広告がいろいろ出てきて、次のページに行こうとすると微妙にじゃましてきて、押すつもりがないのにタップしてしまう。タップさせることに悪意がなかったとしても、サードパーティのコンポーネントやアドネットワークを入れてしまうと、ロードが遅延して肝心のコンテンツがなかなか表示されないということが発生してしまう。

サイトオーナーが意図的にやっているケースもあれば、サードパーティのコンポーネントのふるまいによって行われていることもあるが、ユーザーから見たらUXは最悪。見たいページが見れず、不要なタグだらけになってしまう。

そのアンチテーゼとして出てきたのが、ニュースキュレーションアプリ。特別のフォーマットでコンテンツを流していたり、スクレイピングして本当のコンテンツだけ見れるようにしているので、ユーザーは見たい情報を見ることができるし、不要な広告は見なくて済むし、操作性もいいというUXになっています。

だから、ニュースキュレーションアプリが流行っているのは、これまでWebがこうしたことをさぼっていたということで、それで一気にひっくり返されたという状況なんです。

このさぼっていた状況に対してエコシステムとして働いたのが、Googleが提唱しているAMP（Accelerated Mobile Pages）。AMPのJSのフレームワークに沿ってタグを入れることによって即座にロードすることができ、ページがキャッシュされるので、こうした課題は解決されます。

ただ課題としては、CMSやツールがこうしたPWAppsやAMPの対応を阻害しているケースがあることです。自分でWebサイトを作っているわけではないので、対応したくても対応できない。さらには見た目はいいんだけど、セマンティック性がバラバラになっていることがあり、モバイル対応の遅れにつながったり、Web上のさまざまな技術を阻害する原因になっていることもあり、今後対応していく必要があります。

3.基盤技術としてのWeb

アプリと使うときもメディアとして情報の流通として使うときも、必要になるのは安定、安心、快適に使うための基礎技術です。HTTP/1.1がHTTP/2にアップグレードし、GoogleがWebアクセスの高速化のために開発した通信技術QUIC、W3Cが推奨し牽引しているSSL/TLS。これらは全てきちんとやることによって、利用者に快適に使ってもらう規定路線です。

Webに対して再投資を考えてみよう

Google I/OではAndroidのVR標準対応やインストール不要のInstant Appsが発表された。2016年はもう一回Webを見直し、Webに再投資する年だということも言っている。モバイルのアプリはストア上で発見してもらうことも大変だし、インストールしてもらうことも、使い続けてもらうことも大変という状況。Webの検索との連動など、Webは使える事実がある。ハイブリッドという形でユーザーとのエンゲージメントを高めていく可能性もあります。

• Reinvest in the Web（今こそWebに再投資しよう）
• Reinvent the Web（今こそWebを再発明しよう）

ティム・バーナーズ＝リーも「Webに対して再投資を考えてみよう」と言っている。今こそもう一度正しい技術を考えていくことが必要なのではないかと思います。

■上記の基調講演は動画でも公開中です