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のテクノロジーの活用範囲が広がればいいなと思っています。

白石: 皆さん、本日は様々なお話をお聞かせいただき、ありがとうございました！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

矢倉 Quantumですよね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そして、Appleは…？

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（後編へ続く）

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、エンタープライズ・アーキテクチャについて取り上げます。

HTML5・モバイル・IoT・ウェアラブルなどビジネス環境が激変する中、エンタープライズ・アーキテクチャはどういう課題を抱えていて、どうあるべきなのか。今回は、JJUG (日本Javaユーザーグループ）でご活躍中のお二人に話を伺うことにしました。

アーキテクチャを主軸に第一線で活躍しているグロースエクスパートナーズ株式会社 執行役員の鈴木雄介さんと、「流しのアーキテクト」を自称する株式会社アーキテクタス 代表取締役の細川努さんを交えて、エンタープライズ開発出身の白石俊平編集長がさまざまなトピックスをぶつけていきます。

XML Webサービスは今どうなったのか

白石：とりあえず、昔話から軽く聞いてみたいですね。まずは、エンタープライズ内のシステム間連携でよく話題に上がる、SOAPとRESTについての現状について、どうお考えでしょうか？

鈴木：SOAPは下火だと思われがちですが、私の知る限り、今でもよく利用されています。RESTとJSONの組み合わせも当然よく使われているんですが、（SOAPは）WSDLで型定義ができるので、それなりにかたいシステム間連携だったりすると、WSDLがあるほうがコードの自動生成もできるし、非常に楽なのでよく使われています。

　　 ▲グロースエクスパートナーズ株式会社 執行役員 鈴木雄介さん

細川：とはいえ、SOAPの上位レイヤで規定されているWS-ReliabilityだとかWS-Securityなどの様々なプロトコルは、あまり使われていない印象です。

白石：では、システム間連携などではプレーンなSOAPがよく使われているということですね。

鈴木：まあSOAPもRESTも用意する、というパターンが多いんじゃないでしょうか。オブジェクトモデルは同じで、それをSOAPでもJSONでも表現できるように設計しておくというパターンは、比較的多いような気がします。

細川：あと僕が気になるのは、スケーラビリティなんですよね。SOAPだとちょっと気になるのはやっぱりシリアライズ・デシリアライズの処理が重いし、トラフィックも増大するじゃないですか。そういった意味だとやっぱりREST + JSONのほうにもメリットがありますね。本来だったら使い分けみたいなところが重要なんですけど、いまだにSOAP一択という開発現場も多い。

　　　▲株式会社アーキテクタス 代表取締役 細川努さん

白石：どっちかに寄せちゃったほうが考えることが少なくて、楽ってこともあるかもしれないですね。

鈴木：一長一短…というとつまらない話になってしまいますが（笑）、実際のところそういう結論になっちゃいますね。HTML5が盛り上がっている現在、JavaScriptと相性が良いJSONにはすごく価値がある。一方で例えば、日付型をどう扱うんだとか、型定義やコードの自動生成がしづらいというJSONには苦手な分野もあるのですが、SOAPはそういう部分に強い。「SOAPはXMLだからダメ・ダサい」ということは、実際のシステム開発には全く当てはまらないと思いますよ。

エンタープライズアーキテクチャパターンは今も有効か

白石：アーキテクチャという点では、マーティン・ファウラーのエンタープライズ アプリケーションアーキテクチャパターンが昔は王道だったかとと思うんですが、それは今も有効なんでしょうか？

鈴木：あれは普遍的なものなので、時代が変わったからといって使えなくなってしまうようなものではありません。ただ、昔と比べると今はWeb API主導型のアプリケーションが主流になりつつありますね。クライアントのマルチデバイス化は当然エンタープライズでも相当重要なので、「サーバー側はAPIを提供するだけ」というスタイルに移行しつつあるのは、Webでもエンタープライズでもまったく変わらないと思います。

白石：具体的には、JAX-RSを利用するとか？

鈴木：JAX-RSもありますし、JSON用のバインディングAPIもJava EE 7で標準化されたので、何の違和感もなく使えますね。

細川：エンタープライズ アプリケーションアーキテクチャパターンは非常に洗練されていたのですが、実際のエンタープライズ・アプリケーションはもっと泥臭いです（笑）。 例えばマーティン・ファウラーの提唱するモデルだと、プレゼンテーションレイヤからデータレイヤまでが3、4層ぐらいなんですが、実際はビジネスロジックだけで3層以上に分けたりとか、ビジネスロジックとプレゼンテーションの間にいろいろ挟んだりとか、端から端まで数えると下手したら10層ぐらいあるものも実際のプロジェクトでは山ほどありました。

白石：僕もそういうプロジェクトをやったことがあります。なんか別のメソッドを呼び出してるだけのメソッドが大量にあったり（笑）。

細川：そうそう。なので、どちらかというとほんとに綺麗なレイヤリングはできてなかったというのが現実ですね。最近、６〜７年以前につくられた数十万ステップくらいのシステムをいくつか実際に解析してみたんですけど、結構面白い結果が出たんですよ。サーバーサイドJava（JavaEE）としては最新ではなく、まだJ2EEと呼ばれていた頃のシステムです。どのシステムも、一番複雑度が高いのはビューとデータアクセス（永続化）、アーキテクチャ共通系のモジュールです。ビジネスロジックの部分は量は膨大なんですけど、複雑度自体は比較的シンプルなんです。

何が言いたいかというと、古い世代のサーバーサイドJavaは、ビューとアーキテクチャ制御に作り込みが必要で、そこのところが本当に大変だった。例えば、ビューのところのバリデーションなんかは、かなり作り込みが必要で、簡単な画面作るのも相当手間がかかってたんですよね。結局は、かつてのJava EE（J2EE）って、エンタープライズ系プログラマーが本来集中すべき業務上のロジックにあんまり集中できていなくて、もっと簡単にできるはずのところに手間がかかっていたのが現実だったんじゃなかったかなと。

白石：ほんとにそうですよね。オブジェクトの変換とか、別のメソッド呼び出すだけとか、ファサード作ってそこに一生懸命集めるだけとかやっていて、なにやってるんだろうこれは…とか思っていました。

細川：以前はそうでしたね。そのレガシーなところが今はみんなの足を引っ張ってる（笑）。現在は、それがどれだけ良くなってるか、というところですよね。

白石：今の流れをまとめると、ビューの複雑なところっていうのが、だんだんクライアント側に寄ってきていて、ようはHTML5でリッチクライアント化されてきて、サーバー側はAPIを提供しているだけになっていると。

鈴木：大きくはそうです。ただ、エンタープライズシステムの場合、とにかくシステム間連携が多くて、1つの企業の中でいろんなシステムがあって、ほとんどのシステムが関連付いているのが当然になっています。そうするとクライアント側からするといろんなシステムにいちいちログインして使うのは面倒くさいので、どうやってシンプルに使うのかというのが今の大きなテーマになっていると思います。サーバー間で連携したり、クライアント側でアグリゲーションしたりというのが今の課題としてあって、エンタープライズの場合は、そこがシンプルにならないので、それがひとつの前提になっています。

白石：なるほど。そのシステム間連携がさきほどおっしゃっていたようにXMLベースだったり、RESTだったりという感じですね。

鈴木：はい。企業って、いろんなユーザーといろんなシステムがあるので、いわゆる一般コンシューマー向けのECサイトのようなシステムもあれば、例えば人事システムみたいなものもありますよね。人事システムだと、人事部だけが使うのでユーザーが10人しかいなかったり、でも社員数10万人を支える人事システムっていうと相当でかいっていうものだとか。じゃあその2つが同じアーキテクチャで、同じ作り方でいいんですかっていうと全然そうじゃないですよね。

企業の中のさまざまなシステムの中で、HTML5に合うものもすごく増えてますし、HTMLの可能性が広がったことでやれることもすごく増えましたが、一方でそれが銀の弾丸ではないです。ここはRESTでつくったらいいよねとか、ここはWSDLがちゃんとあってSOAPでやったほうがいいよねっていうのがある。そこは全体の中での選択してやっていけばよいことです。エンタープライズの人って古めかしい人印象があるかもしれないですけど、新しいことも古いこともやらきゃいけないので、そういう意味ではちゃんとまともにやっている人は、それを両方うまくバランスよくやっていますね。

エンタープライズとモバイル

白石：最近のエンタープライズ業界に疎くて、初心者的な質問で申し訳無いのですが、モバイルをエンタープライズで使うというのはもうかなり普通に行われていることなんでしょうか。

鈴木：そうですね。モバイル、タブレット、PC、専用の機器とか、何を何に使うといいよねっていうユースケースはちゃんと考えなきゃいけないですが、モバイルはものすごく重要なツールとして使われています。

白石：エンタープライズでモバイルといえば結構HTML5が使われているという話を聞くのですが、実際そうなんですか？コンシューマ向けだと、ネイティブアプリが全盛です。

鈴木：そもそもモバイルという文脈で求められる操作性とか機能が、エンタープライズの場合はそんなにネイティブでやらなくてもいいようなものが多いので、HTML5がフィットしてるんじゃないかと思います。例えば、ゲームはネイティブアプリがいいといわれますが、別にあそこまでビジュアル的なものとか、細やかな操作性はあんまり求められることはないと。

なので、HTML5でやるっていうのは多いんじゃないでしょうか。Webアプリであれば、リリースも楽ですしね。去年ぐらいまでは写真とか音声とかでいろいろやろうとすると、まだまだHTML5では制約が多いということでネイティブアプリという選択もありましたが、そうした制約もブラウザが進化してきてだんだん問題にならなくなってきています。

白石：なるほど。ちなみに、そうしたHTML5で書かれた業務アプリは、ハイブリッドアプリとしてインストールする形が多いのか、それともWebサイトとしてURLでアクセスする形で作るんでしょうか。

鈴木：それは両方あります。どちらにも利点があるので。

クラウドがアーキテクチャに与えた影響は？

白石：これも初心者的な質問で恐縮です。クラウドがエンタープライズのアーキテクチャに与えた影響はありますか。

鈴木：もちろんあります。クラウドができたことで一番大きかったのは、PaaSという概念ができたことですね。あるニーズに特化したものっていうのは共有化されたものが使われるべきだっていう概念がはっきりしたのはPaaSのおかげです。例えばAWSのラインナップを見て貰うとわかるんですが、CDNありますねだとか、ロードバランサありますねだとか、ストレージ、サーバーノード、認証認可とか、メールの配信サービスとか、ああいうものはPaaSとしてみんなが共有して使うべきだという概念ができた。

なので、そういうプラットフォームを用意してその上にアプリケーションを作って、アプリケーションはUIを含めてそれだけに特化して、なるべくプラットフォームの機能をうまくつかってやっていくていうアイデアは、今のエンタープライズでも浸透している考え方だと思います。

細川：開発者視点でいうと、開発者ができる領域が増えてきましたね。従来だと、サーバ構築とソフトウェア開発は別々のものでしたが、プログラマーがだんだんとクラウドを前提にして、環境を構築するようになってきた。そうすると、同時にパフォーマンスだとかセキュリティだとかをエンジニアが自分で考えなきゃいけない時代になってきていて、Webエンジニアだとかエンタープライズエンジニアとかの区別はなくなってきている。そういう意味では、フルスタックで両方できなきゃまずいんじゃないでしょうか。

鈴木：もうそれはエンタープライズでも間違いなくそうですね。

細川：もうひとつの特徴としては、昔は大規模＝エンタープライズということが多かったんですが、今ではコンシューマー向けとかゲームだとか、そっちのほうがより大規模なんですよね。それを実現しているのがやっぱりクラウドなのかと思っています。そういった意味でも、これからはWebエンジニアこそ大規模を得意にならなきゃいけないんじゃないかと。サーバーとクライアントのメッセージの単位なんかもパフォーマンスに大きく影響するので、そういったところも、かなりノウハウを積まないといけなくなってきています。

エンタープライズ・アーキテクチャの未来像

白石：IoTとかウェアラブルとかを見据えて、今後どういうふうにエンタープライズ・アーキテクチャが変わっていくべきか、ご意見はありますか？

鈴木：IoTを真剣にやろうとすると、先ほど細川さんが言っていた大規模っていうのがエンタープライズに戻ってくるんですよね。対応するデバイスの数が、今まではユーザーが数万人ですんだのが、億になるかもしれない。例えば、すべてのダンボール箱にチップがついたらどうなるんだろうっていう世界を考える。そうすると日本で流通しているダンボール箱は何箱あるんだとか、ものすごいクライアントの数になってしまう。そうなってくると、エンタープライズがまた大規模な性能を頑張らないといけなりますね。

例えば、わかりやすい例でB2Bのケースを考えると、トラックをトレースする仕組みを作ることになったとします。じゃあ全国にあるトラックを全台管理しますとなったときに、全部で何台あるのか。1台のトラックにセンサーがいくつついているのかということになると、センサーが車輪それぞれにあって、それぞれのタイヤのすり減り方を計測して、運転手が寝てるんじゃないかというのを監視するセンサーがあって、速度・加速度をとるセンサーがあって…というようにトラックにすごい数のセンサーがある。

そして、トラックを1万台管理します、データを500msごとに取るとすなると、ものすごい数になる。つまり、B2BでIoT、ウェアラブルというのはB2Cのスケーラビリティをエンタープライズでもう1回頑張らないといけないということになる。今、Webの人が大規模で頑張っているテクノロジーセット、例えば大量のストリームを処理しながらイベントドリブンでやるっていうのは昔からエンタープライズにあって、それがWeb側ですごく実用化されて使われていたのが、またエンタープライズに戻ってくる。そういう流れが未来にはやってくるんじゃないかなと考えています。

白石：なるほど。ちなみに、もう実際にIoTの案件とか発生しているんでしょうか。

鈴木：相談はかなり増えてきてますね。まだ実証実験ぐらいが多いという感覚ですが。今は車がうまくいっていて、ホンダの事例がわかりやすいです。日本中の車のブレーキの発生情報を集めてるんですけど、それを解析すると事故が発生しやすい曲がり角がわかるんですよね。みんながたくさんブレーキを踏んでいる曲がり角がどこかっていうのを提供しているんですよ。そしたらそれを元に道路の信号とか標識とかを改善するってことをやっています。

まとめ

白石：本日は、エンタープライズ・アーキテクチャについて様々なご意見をいただき、誠にありがとうございました。最後に、読者に向けて一言お願いします。

鈴木：自分たちの生活を考えると、やっぱりエンタープライズ業界の会社が自分達の生活を支えてるわけじゃないですか。それがより便利になったり、役立つようになったり、世の中が進化するっていうのはとても大事なことだと思うんですよ。なので、それが実現されるためにはどうしたらいいのかっていうときに、エンタープライズとかWebとかそういう区切りはどうでもよくて、どうやれば本当に価値がでるのか、そういうのを考えるのが面白い。

ただ、社会基盤として変えてはいけないところもエンタープライズにはどうしてもあるので、それをどのように変えずに、より新しいことにトライしながら今あるものの価値をより高めるのかというところが大事ですね。なので「エンタープライズwww」という風潮はよろしくないと思います（笑）。

細川：2点あって、ひとつは、今までのエンタープライズ開発は、ユーザーの言われたものを作るという風潮が多かったんですが、今後はユーザーと一緒につくるっていうのは大事になってくるんじゃないかと考えています。そういう意味ではエンタープライズ業界もWeb業界と同じようにUXとか、よりユーザーが求めるものは何かというところを柔軟に対応してかなきゃいけない。エンタープライズもWebに学ばなきゃいけないということ。

もうひとつは、今後、変化がたくさんあって、それに対応するためにエンタープライズ側、Web側が両方対応しないと対応できないんじゃないかなと思う。これらの技術の変化に対応できるようにフルスタック、両方できるようなエンジニアが増えてくると心強いんじゃないでしょうか。

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、今話題のAngularJSなどのJavaScript MVCフレームワークの台頭と進化、そして新しいアーキテクチャであるFluxとそのフレームワークであるReactなどについて、既に先行して学んでいるエキスパートたちにその知見を聞いてみました。

今回はフレームワーク対決ということで、エキスパートたちがAngularとReactという陣営に分かれ、それぞれのフレームワークについて疑問点をぶつけたり、議論したりする仮想パネルディスカッションという形式でお伝えします。単なるパネルディスカッションとは違って、キーワードは「プロレス」です。まさかりの投げ合い、disり合いOKという形で、NGワードは「適材適所」「ケースバイケース」などです。白熱した議論をお楽しみください！

　　▲議論が白熱する選手たち。左から、久保田光則さん、金井健一さん、増井雄一郎さん、小林徹さん

選手入場（自己紹介）

白石：さて、それではプロレスを始めていきましょうか（笑）。まずは、皆さんの簡単なプロフィールと一押しのフレームワークなどを教えてください。

（React陣営）
小林：小林徹（@koba04）と申します。前職でソーシャルゲームを作っていました。そのときはBackboneとかAngularとかを使っていて、今はReact.jsに興味があって、業務でも使っていこうかと思っています。　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
増井：増井雄一郎（@masuidrive）です。一押しのフレームワークは、ReactとFluxなんですが、ReactはViewのライブラリなので、Fluxになるのかなと。複雑なことをやるのは嫌いなので、なるべくシンプルに書けるということでReactとFluxの組み合わせは気に入っています。あとは自由度が高いという点も気に入っています。

（Angular陣営）
金井：金井健一と申します。フリーランスで、AngularJS Japanユーザーグループの管理人をしています。一押しはAngularですね。Angularは何がいいかというと、フルスタックなところで、悪い面もありますが良い面のほうが多いんじゃないかと思います。学習コストが高いというのもよく言われますが、それだけ機能が多岐に渡っているということなので、いったん使いこなせればすごくいいフレームワークだと思います。

久保田：久保田光則と申します。アシアルという会社でエンジニアをやっています。会社ではOnsenUIというフレームワークを作っています。3年か4年くらい前からずっとJSとかフロントエンドばっかりやってきていて、ちょっと前はKnockoutJSがいいなと思っていたんですけど、気がついたらずっとAngularJSばっかり書いていました（笑）。Angular2は野心的な方針で、いろんなものを取り込んで最高のものにしていこうという気概が感じられるので注目していかないとなと思っています。

お互いのフレームワークへの疑問点など

白石：このパネルディスカッションの今後の流れとしては、僕のほうからは何かコントロールするということはないので、レフェリーみたいなものだと思ってください（笑）。自由にやっていただければと思います。それでは、今回の本題ということで、お互いのフレームワークについて疑問点だったり、disったりということをお願いします。

小林：Angularは、1.04ぐらいのときに使っていて、実際にプロダクトに使ったんですが、結構情報がなくて辛かった思い出があります。DirectiveってよくわからないのでシンプルにControllerとかScopeとかで頑張ってやったという印象がありますね。

金井：当時は、結構そうかも。ただ今は、ドキュメントも充実してきているので今はさほど辛くはないかなと思いますね。Reactはルーティングとかバインディングとかその辺はどこまでできるんですか？

増井：React自体はほんとにViewだけなので、まったくそこはケアしないですね。Fluxは考え方なので、実はすごい小さいんですよ。Dispatcherだけなので数百行ぐらいしかない。あとそこにどうやってルーティングをやるかというのは、React Routerとか外部のコンポーネントを組み合わせて使うので、標準では持っていないです。そこは大きく違いところだと思います。

僕はAngular使っていないんですが、会社（トレタ）のほうでは、PC向けの機能は全部Angularで作ってるんです。でもそこの中の人に聞くと、CRUDみたいなよくあるアプリケーションは結構楽にできて、Angularがなかったら短期間では作れなかったと思うと言われました。ただ、そういうパターンからはずれてしまうとすごい書きにくいかもしれなくて、拡張していくとき、パターンが複雑化してきたときに本当に耐えうるのかが不安と聞きました。そういう傾向ってどうなんですかね？

久保田：何もかもScopeとかで管理しようとすると結構はまりどころ多いなというイメージがありますね。細かいインタラクションとか、例えばドラッグ＆ドロップを直接使いたいときって、結局DOMを触るしかなくて、DOM触るにはDirectiveっていうものが用意されています。Directiveは、ある程度DOMに対してのいろんな機能を追加するとか、細かいDOMの操作を担当するものなんですよ。全部Controllerで管理しようとするとすごいぐちゃぐちゃになったりするんですけど、ちゃんと自分でDirectiveを作って管理すると扱いやすいと思います。

増井：なるほど。あと、Angular1系と2系ってはたから見てると、2系が年末だか来年だかに出て、結構互換性がないっていう話で、1系は捨てちゃうっていうことを聞いてそこはちょっと怖いかなっていう印象はありますね。

金井：2系が主流になって、1系が減ってこない限りはサポートするという話ですね。なので、そこは早いうちにアップデートしないといけないかもしれません。

増井：でもアップデートってまるまる書き直しなんですよね？

久保田：ng-japanでもアナウンスされてましたが、Angular2とAngular1を共存する方法はあって、1系のコードと2系のコードを混在させることができるようですね。

今からフレームワークを採用するとしたらどちらを使う？

増井：今から新しくプロジェクト始めるときにどのフレームワークで作ろうかみたいなときに、実際に作る人は悩むんですかね。

白石：実際、今作ろうと思っているものがあるんですが、悩みますね。

金井：なんでそこはAngularじゃないんですか（笑）。

白石：Angularはでかくて複雑すぎて怖いんですよね。しかもAngular2が迫っているという。この今のタイミングで採用するのはちょっと怖い。

増井：そういう意味では、僕はReact.jsがなくなっても、React.jsと同じものを書ける自信があるんですよ。FluxとReact.jsをまるっとFacebookがやめました、明日からReactはありませんと言われたときに、僕はReact全体をメンテナンスできる。まるっと同じものを作れっていわれたら、まあ頑張って作れる。Angularは作れる気がしない。

金井：作れる気はしないですね（笑）。

増井：僕は結構そこが怖くて。なので、大きいフレームワークは採用しにくいっていう面があります。あと、MVCの上にMVCを乗っけるというのは、その考え方はすごくToo Muchかなと。サーバーサイドは、サーバーサイドでMVCを作っていて、さらにクライアントサイドでMVCを作るわけじゃないですか。MVCの2階建てはアーキテクチャとして本当にいいのかっていうのはすごく思っていますね。

そもそもモデルをデータベースから作って、ちゃんとAPIにしているはずなのに、それをさらにもう一回モデルとして扱う、あんまり効率的じゃないんじゃないかっていう。Reactだけに限ると、MVCのVしかないので、そもそも書いて読んだJSONをそのままViewで表示するってことをやったりするんです。だけど、実はAPIが揃ってると結構なWebアプリケーションで、そもそもモデルまでおこさなくてもいいんじゃないかっていう気がするんですよ。

金井：JSONをとってきて出すっていうのはAngularでもできるので、それはアプリの設計によるのかなという気がしています。Angularの場合は、さらにそこから変更もできるという利点があります。

増井：それにしてはToo Muchすぎるんじゃないかと。

金井：それだけしたい場合には確かにそうですね。

増井：結構なケースがそれで済むんじゃないかっていう気はしていて。実はクライアント側でMVCが必要なほど複雑な処理するケースってそんなに多いのかなと。

久保田：まあでも実際には、もちろんアプリの要件によると思います。ハイブリッドアプリって結局JSでなんでもやるので、API叩けばそれで終わりというわけじゃなくて、むしろJSのほうでいろんなことを書かなきゃいけないって感じになるので、API叩けばそれで終わりっていう感じにはならないですよね。

APIってネットワーク越しにやるんでそれってすごく重たいし、あんまりやりたくないっていうのはモバイルアプリだと多いです。そもそもモバイルアプリだとネットワーク繋がらないってこともあるので、それを解決するにはローカルのほうでデータを保持して、繋がったら同期をとるっていう感じになるので、モデルがないとちょっと辛いという感じになりますね。

JSXは気持ち悪い？

白石：JSXがキモいんですけど…。

増井：あれは気持ち悪いんですよ実際（笑）。キモいっていうのはまったく異論ないんですけど、あれはあれで理にかなっていると思っています。DOM操作がなんで難しいかっていうとそもそもこのDOMをみたときに、これがいつどこで書き換わるかわからないし、さらにこのボタンを押したときにどこで何が起こるかわからない、イベントは1個じゃなくて100個でも張れるので。っていうのに対してJSXの場合はそういうのを一応ビューとロジックを同じところに書くことで、さらにイベントリスナーを1対1にすることによって、そういう複雑性を省きましょうという考え方なので、気持ち悪いことは認めつつ、理にはかなっているかなと。

1番の問題は、HTMLしか書けない人がこれを触れないっていう。コーダーと分離ができないっていう点ですよね。ただこれはもっと根本的な問題で、Reactは画面の一部をコンポーネントとしてスコープを作りましょうっていう考え方で、HTMLを切ってるんじゃなくて、プログラミングスコープを切ってるんですよ。それって見た目のデザインとはちょっと違って、アーキテクチャのデザインの話なので、見た目とロジックを切り離すっていうところに、そもそも無理があるじゃないかっていうことですね。

金井：そこらへん（画面の一部をコンポーネントとしてスコープを作る）は、Angularも目指すところは同じかもしれないですね。

増井：そのやり方が違うってだけなんでしょうね。

久保田：ちょっといいですか。別にJSXって気持ち悪くなくないですか。

小林：私も全然違和感ない（笑）。

白石：人によるんだ。

増井：僕も去年からReactを知ってたのに触ってなかったのは、JSXです（笑）。あれで毛嫌いして触らなくて、でもあんまり話題になってるので去年の年末年始から本格的に触ってみたというのがあります。あれは僕個人も気持ち悪いです（笑）。

小林：ぱっと見たときに、あれ（JSX）がやりたいフレームワークなのかなと思っちゃうんですよね。

増井：日本でのReactの評価は、Virtual DOMっていう技術キーワードとJSXという見た目にすごく左右されている印象がありますね。

Virtual DOMって本当に早いんですか？

白石：Virtual DOMって本当にそんなに早かったりするんですか。ぱっと考えると差分をComputeとする計算処理も必要だし、フロントのDOMと仮想DOMって2つ持っているメモリも喰いそうだなと思うんですけど、実際はどうなんですか？

小林：実際は何が一番早いかっていうのはやっぱりDOMを直接触るのが一番早いっていうのは間違いなくて、でもそれってコードとしても複雑になるじゃないですか。モデルのデータの変更された部分だけをどういう風に反映するのかっていうところが煩雑になる。Virtual DOMだと、ひとつの状態をもっておいて、パっと更新すると差分だけを綺麗に反映してくれるので、DOMを直接触るよりは遅いですが、該当部分のDOMを全部入れ替えるよりは早いという感じです。最速ではない。

白石：最速ではないと。わりとプログラマーがいい加減な処理をしてもいいってことですね。

増井：Reactはとりあえずざっくり書けば、そこそこ速いっていうような考えですね。

久保田：最近、Atomで内部でReact使ってたけどパフォーマンスのために削除したっていう話がありましたね。

白石：え、そうなんですか。もう使わなくなっちゃったんだ。

小林：最初のやつがちゃんと構造化されていなくて遅かったのをReactにして、ちょっと速くなって。そこをベースにDOM職人が頑張ってやったらさらに早くなったっていう感じですね。

Angularは謎のルールが多い

白石：Angularを触ったり調べたりしたときに僕的には謎のルールがすごい多くてとっつきにくかった。例えば、$変数が多すぎ。何々のときは$なんとかが多くて、なんだこれはっていう（笑）。

金井：あれ何なんでしょうね。$$とかあるしね（笑）。

白石：Dependency Injectionを実装したのはいいんだけど、まず引数の名前で当てるからminifyしないでねとか、minifyしてもいいように別の書き方も発明したよとか配列で指定できるようになったりとか。なんかもう歴史上の問題かもしれないんですけど、謎ルールが多すぎる感があるんですけど。そこらへんはどうなんでしょう？

久保田：やっぱりそこは気持ち悪いなと思います。でも昔からずっと実務上の必要からそういうのが増えてきたのかなと思いますね。あとから来た方がどうしたもの洗練されたものになっていくので…。

増井：Angularっていつできたんでしたっけ？

金井：結構前で、2009年ですね。

増井：そんなに前なんだ！

金井：Angular1が2012年ぐらいなので、そこで注目された感じですね。2009年にできたフレームワークが5年くらい経って実用になりつつも、辛くなってきたということでAngular2を開発しているということだと思います。Angularのいいところっていうのは、その時々で結構先のことを見据えてやろうとしていて、1系だとWeb Componentsを実装したくてDirective作ったりしてるし、Object.observe()欲しいよねっていって2way bindingを実装してみたりとか。どんどん攻めてるんですよね。

増井：そういうイメージはありますね。

実はReactは大きい

白石：ちなみにフレームワークの大きさでいうとどうなんでしょう。

増井：ReactってViewのライブラリだけのくせにすごいでかいんですよ。へたしたらjQueryよりでかい。

金井：フレームワークのサイズが大きいと、モバイルのユースケースで叩かれませんか、重いとか。Angularは相当叩かれた覚えがあります（笑）。

増井：とはいっても画像ひとつ分ぐらいですからね。Reactも実際よくあるReactのダメなところに「でかい」っていうのはいろいろ言われていて、でも現実ユーザーからそういう話があがってるわけではなく、数字で見てっていう部分があります。あと、Reactはサーバーサイドレンダリングを持っているので、ファーストビューはサーバーサイドで出しちゃって、その後にJS読み込むっていうことができるので、そういう意味では十分早いですね。面倒くさいですけど、やろうと思えばできます。

白石：今、ダウンロードしてみたんですけど、Angularがminify時で126KBで、Reactが121KBという結果に。

増井：しかも、AngularはMVCで、ReactはVだけで、ですからね（笑）。

金井：やれること全然違う。（Angularは）ルーティングからバインディングからすべてできるのに（笑）。

検索可能にするサーバーサイドレンダリング

増井：Reactのひとついいところは、サーバーサイド生成ができるのでぐぐったときに引っかかるんですよね。クローラーは基本的にはJSを実行しないので、みんなテンプレートにはじめから引っかかりそうなキーワードを入れたりとかして頑張るんですけど。でもReactはサーバーサイド（Node.js）でReactエンジンを実行してHTMLを生成することができるんですよ。そうすると例えば、基本的な部分をファーストビューで表示すると、JSが実行されなくてもHTMLで画面が見えて、JSが実行されると残りの部分が表示されるという段階的にできるですよ。

そうすれば、検索エンジンに引っかかるし、JSがもし（ブラウザで）動作しなくても本文はちゃんと読めるというメリットがあります。といってもそれをやるには、それなりに考えて書かなきゃならなきゃいけなかったり、その実行エンジンをいろいろセットアップしなきゃいけないので、手放しでできるっていうわけでもないんですが。

小林：海外はやっぱりReact導入してるところは、サーバーサイドレンダリングもやっているところが多いですね。海外のほうがサーバーにNode.jsを使うのは結構一般的で、日本だとあんまりないから意外なんですけど。サーバーサイドレンダリングできるからReact採用してるっていうとこも結構ありますね。BBCとか。

増井：ぐぐれるっていうのはでかいですからね。

白石：なるほど。じゃあAngularのほうは、どうですか？

久保田：まあAngular2に期待ですね。Angular2のレンダリングのアーキテクチャについて設計文書が公開されていて、その中でVirtual DOMを使いますと言っています。

小林：Ember.jsも次のバージョンでHTMLbarsとsimple-domを組み合わせてサーバーサイドレンダリングできるようになる予定で、これからのフレームワークはサーバーサイドレンダリングはついてきそうな気がしますね。

久保田：あと、ちょっと面白いと思ったのがサーバーサイドレンダリングだけでなく、Viewの処理をWeb Workerでやりたいっていう点ですね。

増井：Web WorkerはReactでもやるっていってますね。そんなに進んでないですが。

白石：確かに仮想DOMは、本物のDOMじゃないからWorkerでいじれるし、間のメッセージングにコストがかからなければ割と早そうですね。

増井：そこ（Reactの仮想DOM）の差分の計算までWorkerでやってしまうので、それなりの速度がでるはずですね。ChromeもServiceWorkerとか機能を強化してるのでたぶんそういうのに合わせてるんだろうなと思います。

開発速度・生産性の比較

小林：たぶんReact使っても開発速度って上がらない。書く量も結構増えますね。

増井：むしろ下がります（笑）。プログラムでひとつ大事なところは、1年後に触れるかどうかだと思っていて、よくプログラムは書くより読む時間、回数のほうが多いので読むことを考えて書くべきだって言う考えがありますよね。時間がかかっても読みやすく書いて、それによってコード量が増えるのはプログラムとしてしょうがないんじゃないかっていう考えがあって、Reactはそういう考えに近いですね。なので記述量は減らないし、同じの書いたら5〜10倍ぐらいになっちゃっていう話もあって、あきらかにめんどくさいです。

金井：AngularJSは、預ける部分が大きいので、勝手にやってくれる。コード量は圧倒的に減りますね。なのでCRUD系作るときはすごく早いです。

おわりに

このように議論はすごく白熱して、興味深いトピックスが目白押しでした。楽しんでいただけましたでしょうか。今回は「議論は平行線だった」ということで終わりたいと思います。

今回の前提条件と改善ポイント

実際の改善を行う前にいくつか前提条件を説明しなければいけません。まず動作環境ですが、HTML5 Experts.jpは、WordPress上で動作しており、改善内容はプラグインの導入やPHPのコード修正が主になっています。ただ、そういったWordPressの泥臭いチューニングは本題ではないので、細かく解説するのではなく大まかな改善内容とその方針を説明したいと思います。また、改善内容に関しても費用対効果がある程度高いものを優先しているため、まだまだ改善できるというところも、あえてそのままにしているところもあります。

今回の改善内容は、前回の分析結果から以下のようになっています。その分析内容などについては解析編をご確認ください。以下の改善ポイントとその順番に沿って解説していきます。（順番は、改善内容の導入のしやすさや影響の大きさなどを考慮して実際に実施した順序になっています）

改善ポイント

1. ソーシャルメディア系サービス（シェアボタンなど）のパフォーマンスを改善する
2. 実際の表示サイズより大きな画像は適正なサイズに変更する
3. マークアップを改善する（書き方やJSのミニファイ等）
4. WordPressのキャッシュを導入する
5. Keep Aliveが全ての環境で効いているか、設定時間は適切かを確認し、コンテンツダウンロード時間を最適化する

ソーシャルメディア系サービスのパフォーマンスを改善する

まず最初に着手したのは、ソーシャルメディア系のガジェットなどです。HTML5 Experts.jpでは、トップページにはTwitterのタイムラインとFacebookのウィジット、記事ページには、各種シェアボタンとFacebookのコメントを埋め込んでいました。これらのソーシャル系のガジェットは、多数のリソースを読み込んだり、スクリプトによるメインスレッドのブロッキングなどでユーザーの体感スピードを劣化される主たるものです。まずは、不要なガジェットの整理ということで、ほぼ利用がなく効果が不明なTwitterのタイムライン、Facebookのウィジット、Facebookのコメントは完全に削除することにしました。これだけで、トップページからはソーシャル系のガジェットが完全になくなることになります。次に記事ページのソーシャルボタンですが、ソーシャルボタンのスクリプトを読み込まないように自作することにしました。現在（改善後）のソーシャルボタンは次のようになっているはずです。

PC版ソーシャルボタン

モバイル版のソーシャルボタン

これらのソーシャルボタンでは、例えばTwitterのツイートなどを直接リンクで指定しており、onclickで小さいウィンドウが開くように変更しています。そのため、APIを利用しなければ実現できないFacebookの「いいね」と、Google+の「+1ボタン」は、いずれもシェアボタンに変更しています。各ボタンのカウント数については、サーバー側でキャッシュして表示する「SNS Count Cache」というプラグインを導入して利用しています。

ソーシャルメディア系のガジェットの改善は非常に効果が大きく、以下のようにPC版の記事ページでは、ページの読み込み時間が5秒近辺だったものが、2.5秒のほどに劇的に改善しています。また、バラツキがあった計測時間が小さい範囲に収まるように収束しています。

PC版記事ページの読み込み時間（折れ線グラフ）

PC版記事ページの読み込み時間（スキャッタプロット）

実際の表示サイズより大きな画像は適正なサイズに変更する

次は画像サイズの縮小です。HTML5 Experts.jpでは既に画像の最適化を行う「EWWW Image Optimizer」プラグインを導入済みでしたが、画像のサイズ自体はあまりケアしていませんでした。そのため、記事によっては原寸サイズの画像を貼り付けているものもあり、ダウンロード容量が非常に多いページもありました（WordPressの場合、画像を挿入する際にサイズを選択できます）。また、お恥ずかしながら、アイキャッチ画像を設定している記事については、記事一覧でサムネイルに原寸サイズの画像が表示されるというバグも見つかりました。そこで、以下のように対応することに決めました。

• 画像の最大サイズをPC版記事ページの横幅に合わせ640pxとする
• 画像の最大サイズより大きな画像がアップロードされた場合、強制的にリサイズする
• 記事一覧で、適切なサイズのサムネイル画像を表示するように変更

画像の最大サイズ

記事一覧のサムネイル画像

まず初めに、画像の最大サイズを変更します。WordPressでは画像のサイズを設定画面で変更することができ、デフォルトでは「大サイズ」の設定値は1024×1024に設定されている部分を640×640に変更します。しかし、これだけでは編集者が誤ってフルサイズの画像を挿入することができてしまうため、それより大きい画像がアップロードされた場合に強制的に640×640にリサイズするようにします。これは、「Imsanity」というプラグインを導入することで解決しました。

次に、記事一覧で適切なサイズのサムネイル画像を表示するように変更します。PC版の場合、サムネイル画像の表示サイズは幅207pxとなっていたため、それに合わせて画像をアップロードする際に自動的に幅207pxのサムネイル画像を作成するように変更しました。同時に、記事一覧を出力する際にサイズを指定して画像を表示するようにコードを修正しています。（これらの詳細なコードは例示しませんが、add_image_size the_post_thumbnail wp_get_attachment_image_src 等のキーワードを調べていただければ見つかるかと思います）

ここでモバイル版について考慮されていないと気がついた方がいらっしゃるかもしれません。モバイル版のサムネイル画像のサイズは、幅93pxとなっていましたが、これをこのまま適用してしまうと高精細なディスプレイではぼやけてしまうため、そのままPC版と同じものを表示するようにしました。本来であれば、レスポンシブイメージを採用するのが理想だと思いますが、この時点ではリソースの問題から断念しています。

最後に、既存の画像ファイルに対して、これらの変更を反映する必要があります。最大サイズの変更と新たなサムネイル画像の表示サイズの追加については、「AJAX Thumbnail Rebuild」というプラグインを使ってバックグラウンドですべて処理しました。その後、「Imsanity」、「EWWW Image Optimizer」プラグインについても、既存の画像に対するオプション機能を使って再処理を実施しました。これで、すべての画像は適正なサイズに変更されたことになります。

マークアップを改善する（書き方やJSのミニファイ等）

ここで実施するのは、不要なスクリプトやスタイルを整理したり、ファイルの結合やミニファイなど、一般的なWebパフォーマンスのベストプラクティスに近いものです。しかしながら、WordPressではすべてのページでjQueryを読み込んでいたり、いろいろなプラグインがそれぞれファイルを読み込んでいたりと、かなり奔放な状況です。そのため、実際の作業はここが一番泥臭く、複雑なものになりました。改善内容は、主に以下のようなものです。

1. すべてのページで読み込んでいるスクリプト、スタイルを調査する
2. 不要なスクリプト、スタイルを削除する
3. スクリプト、スタイルの移動、結合とミニファイ（「Autoptimize」プラグイン）

まず、1番と2番ですが、初めにすべてのページで読み込んでいるスクリプト、スタイルを調べます。HTML5 Experts.jpの場合、主にトップページ、記事ページ、その他のページの3種類になります。その他のページにもいくつか種類がありますが、スクリプト・スタイル構成は似たようなものになるので、ここでは省略しています。また、上記3種類がそれぞれPC版、モバイル版とあるので計6種類ということになります。これらの各ページでは、HTMLソースコード内のべた書き（scriptタグなど）やWordPress上で読み込まれているリソース、実際にブラウザに表示されているページ上で読み込まれているファイルなどを調べます。（WordPress上では、wp_enqueue_scriptsをフックしてそれぞれのハンドル名を表示します）

その後に、どのプラグインが読み込んでいるのか、それらは本当に必要かどうかを判断します。プラグイン自体が不要であればプラグインを削除し、スクリプトやスタイルの読み込みのみを止めたいのであれば設定変更で対応可能か判断し、最終的にはWordPress上で個別の種類のページに対してスタイルを削除します。例えば、「Facebook」公式プラグインは、すべてのページでFacebookのスクリプトを読み込むようになっており、ソーシャルボタンを廃止した関係もあって完全に削除しています。その際にプラグインが提供していたOGP設定などは手動で追加しています。また、モバイル版のトップページではjQueryは不要のため、トップページでのみjQueryを読み込まないといった形になっています。（WordPress上では、wp_enqueue_scriptsをフックしてif文でそれぞれのページ上でwp_dequeue_scriptやwp_dequeue_styleなどでスクリプトやスタイルを読み込まないようにしています）

そして肝心の改善結果ですが、実は問題があり、ページのHTTPリクエストから最初のデータが返ってくるまでの時間（TTFB: Time To First Byte）が遅延するという事象が発生しました。これは、元々WordPressではDBアクセスなどがあり、時間がかかっていた箇所でしたが、加えて今回のAutoptimizeがファイルの結合、ミニファイを行うためにバッファを読み込んで処理している関係でさらにTTFBが伸びるという結果になりました。そのため、スクリプト・スタイルのファイル数とサイズが減ったにも関わらず、結果としてパフォーマンスは相殺され、逆にロード時間が若干長くなるという状態になりました。そのため、Autoptimizeを導入する場合は、基本的には後述するキャッシュを導入する必要があるという結論となりました。

TTFBの遅延（ウォーターフォール図）*青い部分がTTFB

WordPressのキャッシュを導入する

WordPressは、簡単にページを構成して表示できる反面、PHPの処理やDBアクセスが発生するため、TTFBが遅くなりがちです。そのため、HTML5 Experts.jpのような、ある程度表示内容が変わらないサイトの場合はキャッシュプラグインを導入するのが望ましいでしょう。今回、キャッシュプラグインには、ページキャッシュ、オブジェクトキャッシュ、DBキャッシュの3つが可能な「W3 Total Cache」と、WordPressのUIの日本語化のための翻訳ファイルをキャッシュする「MO Cache」を導入しました。いくつかあるキャッシュプラグインのうち、W3 Total Cacheを採用した理由は、現在PC版、モバイル版のテーマを「Multi Device Switcher」でブラウザ（UA）によって切り替えていますが、W3 Total CacheにはUser Agent Groupごとにキャッシュできる仕組みがあることです。

これにより、現在はアクセスのある記事ページなどは、キャッシュが1時間保持されるような設定になっています。キャッシュは記事が公開されるとクリアされ、再度アクセスがあるとキャッシュされるようになっています。そのため最初に記事にアクセスした人は若干遅いと感じることがあるかもしれません。また、ソーシャルボタンなどのカウント数も即時には反映されなくなっています。

キャッシュを導入した結果、なんと2〜3秒かかっていたTTFBが100ms前後にまで改善しました。体感速度でもかなり快適に表示されるように、非常に高い効果がありました。

TTFBの改善（ウォーターフォール図）

Keep Aliveが全ての環境で効いているか、設定時間は適切かを確認し、コンテンツダウンロード時間を最適化する

モバイルでKeep Aliveが効いていない問題については、結論からいうと、HTML5 Experts.jpで利用しているHTTPサーバーであるnginxの仕様が問題となっていました。元々、SafariにはKeep-Aliveが効いていると、ファイルがアップロードできないというバグ（該当のissueはこちら）があり、それに対応する形でnginx側はSafariに対してデフォルトでKeep-Aliveを無効にするという対策を取っています（keepalive_disableの設定）。HTML5 Experts.jpでは、ユーザーがファイルをアップロードするユースケースはないので、nginxの設定に”keepalive_disable none;”を指定してKeep-Aliveの無効を取り消しています。また同時に、Keep-Aliveのタイムアウトをデフォルトの75秒から20秒に変更しています。これは、現状の読み込み完了までの時間が20秒を超えることはほぼないためです。

その結果、モバイルでも同時接続数分のコネクション（別ドメインの接続を除く）を確保した以降は、Initial Connectionが消え、全体で2秒近く高速になりました。これを見ると、別ドメインへのアクセスを整理することによってもう少し効率化できそうではありますが、今回はここまでとしました。

モバイルのタイムライン（ウォーターフォール図） *Initial Connecctionはオレンジ色の部分

まとめ

これまで5つの改善ポイントについて、記事中の通り改善を実施してきました。これによってどのようにパフォーマンスが改善したのかを、この企画における全期間中のパフォーマンストレンドの推移でご覧いただきたいと思います。

全期間中のパフォーマンストレンドの推移（PC版）

全期間中のパフォーマンストレンドの推移（モバイル版）

いずれも大きく改善され、PC版では5秒台から2秒以下に、モバイル版では20秒前後で大きく揺れていたものが安定して8秒近辺に落ち着いています。これらの結果を受けて、解析編で掲げた改善目標が達成されているかどうかを、個別のデータで確認していきたいと思います。

改善目標

1. Total Time（サイトにアクセスした時点からブラウザ上でコンテンツ表示が完了するまでの時間）は2秒を切る
2. アクセスした際のTotal Timeに関する品質を一定にする（ばらつきをなくして一定にする）
3. 3G回線からのTotal Timeに関するアクセス品質をブロードバンド回線のそれに近づける

まずは、改善後のPC版の各ブラウザの計測結果を見ていきましょう。 次のグラフは、トップページの1日の計測結果です。（時間帯によってはネットワーク品質に揺れがあり、計測結果が多少上下します。）

PC版のTotal Time（折れ線グラフ） *Chrome:黄色、Firefox:青、IE:赤

それぞれの平均Total Timeは、Chromeが1.59秒、Firefoxが1.657秒、IEが1.125秒という結果となりました。当初目標の「Total Timeは2秒を切る」という点では、余裕を持ってクリアしています。特にIEの場合、1秒を切るケースもあり非常に高速です。次に同じデータをスキャッタプロットで分布を見てみましょう。

PC版のTotal Time（スキャッタプロット） *Chrome:薄緑、Firefox:オレンジ、IE:青

スキャッタプロットで見ると、各点がきちんと下に寄っているのがわかります。はずれ値も少し見られますが、およそ95%の計測値が2.5秒以下の範囲に収まっています。そのため、「アクセスした際のTotal Timeに関する品質を一定にする」も達成していると言えるでしょう。

最後に改善後のモバイル版のトップページの計測結果を見ていきます。次の2つのグラフは、3G回線でのXperiaとiPhone6S、参考としてLAN環境でのiPhone6を加えたものです。

モバイル版のTotal Time（折れ線グラフ） *Xperia(3G):オレンジ、iPhone6S(3G):赤、iPhone6(LAN):青

モバイルの場合、ネットワーク品質の揺れ幅が大きくなりますが、平均ではXperiaが12.863秒、iPhone6Sが8.601秒となっています。参考値であるLAN環境のiPhone6が平均0.486秒であることを考えると、3G回線がパフォーマンスに大きく影響していることがわかります。これは、画像ファイルの数、ダウンロード容量が多いためで、ネットワークに遅延が発生すると大きく影響します。この時の画像ファイル数は38で、サイト全体の容量は400KB程度になっています。これは、HTML5 Experts.jpのメディアの特性を考えると、ある程度はやむ得ないと思いますが、もう少し減らせるように工夫すべきかもしれません。救いとしては、遅延の原因が画像ファイルにあるので、ファーストビューへの影響は比較的少なく、体感速度は数値よりも早く感じるという点でしょうか。

モバイル版のTotal Time（スキャッタプロット） *Xperia(3G):薄緑、iPhone6S(3G):オレンジ、iPhone6(LAN):オレンジ

スキャッタプロットのほうを見ると、3G回線のために値の範囲が広がっていますが、概ね下に寄っているように見えるので許容範囲内であると言えるかと思います。しかしながら、前述の問題から「3G回線からのTotal Timeに関するアクセス品質をブロードバンド回線のそれに近づける」については、大きく改善してはいるものの課題が残っているという結論としたいと思います。

皆さん、いかがでしたでしょうか。本記事で改善した結果は是非、皆さんの手で体感していただければと思います。HTML5 Experts.jpでは、これからもパフォーマンス改善を続けていきますので、HTML5 Experts.jpを今後とも宜しくお願いいたします。また、この企画に大変なご協力をいただいた株式会社Spelldataの竹洞陽一郎さんにこの場を借りて厚くお礼申し上げます。ありがとうございました！！

補足事項

本記事で扱っている計測結果は、改善実施直後の数値です。現在の数値とは異なることがあることをご了承ください。特に本記事の内容より以降に、HTTPS（SPDY対応）化を実施しており、Total Timeは全体的に伸びています。そのあたりの対応についても、別の機会で紹介できればと思います。

ハイブリッドアプリ開発の手法のひとつして、Chrome Appsをモバイルアプリに変換するApache CordovaベースのChrome Apps on mobileについて解説します。これによって、Chrome Appsとして作成したWebアプリがAndroidやiOS向けのネイティブアプリとして公開、インストールすることができるようになります。

Chrome Apps on mobileは、まだデベロッパープレビュー版で、GitHub上でプロジェクトが公開されています。まだデベロッパープレビュー版ということで、Chrome AppsのすべてのAPIを利用できるわけではありませんが、順次対応される予定です。本記事では、そもそも「Chrome Appsとは何なのか？」というところから、Chrome Apps on mobileの開発環境の構築やビルド、実行までひと通り見ていきます。

Chrome Appsとは？

Chrome Appsとは、単にChromeで動作するWebアプリというわけではなく、Chromeウェブストア上で配布・販売できるアプリケーションプラットフォームです。通常のWebアプリをChrome Appsとしてそのまま公開することもできますし（若干のマニフェストファイルを書く必要はあります）、Chromeに実装されている高機能なAPIを利用して、よりリッチなWebアプリを作ることもできます。

Chromeウェブストア

例えば、通常のWebアプリをChrome Appsとして公開する場合（Chrome独自のAPIを利用しないケース）、次のようにマニフェストファイル「manifest.json」とバックグラウンドで動作するJavaScriptファイル「background.js」を記述し、Webアプリのファイル一式と同梱することによって簡単にChrome Appsとして動作させることができます。

ChromeAppSample （任意のフォルダ）
      ├── index.html （Webアプリ本体一式を同梱する）
      ├── manifest.json
      └── background.js

{
  "name": "Chrome App Sample",
  "version": "0.1",
  "app": {
    "background": {
      "scripts": ["background.js"]
    }
  }
}

chrome.app.runtime.onLaunched.addListener(function() {
  chrome.app.window.create('index.html', {
    'bounds': {
      'width': 400, 'height': 500
    }
  });
});

また、Chrome Apps上では、独自のChrome APIを使って、さらにリッチなWebアプリを作ることも可能になっています。Chrome Appsの作成方法についてのより詳細な情報は、公式ページの「What Are Chrome Apps?」にまとまっていますので、参考にしてください。簡単に試してみたいという場合は、「Create Your First App」を試してください。

開発環境の構築

まずは、Chrome Apps on mobileの開発環境を構築します。Chrome Apps on mobileは、iOSのバージョン6以降、Androidのバージョン4.0以降を対象にしています。どちらを対象にするかによって必要なツール・ライブラリが異なりますので、対象に合わせて準備しましょう。いずれの環境でも必要なのは、Node.js (バージョン0.10.0以降)です。既にインストールされている場合は必要ありませんが、まだの場合はWindows、Mac（またはLinux）いずれでも、こちらからダウンロードしてインストールしておきましょう。さらに環境によって次のようなツール・ライブラリが必要になります。

Androidの場合

• Java JDK7 以降
• Android SDK 4.4.2 以降（ sdk/tools と sdk/platform-tools をPATHに追加する）
• Apache Ant（ apache-ant-x.x.x/bin をPATHに追加する）

iOSの場合

• Xcode 5 以降
• ios-deploy（iOSデバイスにデプロイする際に必要です）
  > npm install -g ios-deploy
• ios-sim（iOSシミュレーターにデプロイする際に必要です）
  > npm install -g ios-sim`

※ Appleストアに公開する場合は、iOSデベロッパー登録が必要です

ccaコマンドラインツールのインストール

最後に、Chrome Apps on mobileのツールとしてccaコマンドラインツールをインストールします。

> npm install -g cca

既に、ccaがインストール済みでアップデートをする場合は、npm update -g ccaを実行しましょう。ccaのインストール後に、次のコマンドでAndroidおよびiOSの開発環境が揃っているか確認できます。

Android SDK detected. Xcode detected.

「Android SDK detected.」と「Xcode detected.」という結果が表示されればOKです。片方のみの環境であれば、いずれか片方だけが表示されます。例えば、Android環境のみの場合は、「Android SDK detected.」だけが表示されます。

プロジェクトの作成とビルド、実行

開発環境の構築が終わったら、実際にプロジェクトを作成してビルド、実行してみましょう。ccaコマンドツールを使って次の手順で行います。

プロジェクトの作成

• 新規にプロジェクトを作成する場合 > cca create ChromeSampleApp カレントディレクトに ChromeSmapleApp というフォルダが作成され、プロジェクトが作られます。

• 既にあるChrome Appsを元にプロジェクトを作成する場合

既にChrome Appsを作成済みであれば、オプションでそれを指定します。指定方法には、次の2種類があります。

> cca create ChromeSampleApp --link-to=path/to/manifest.json

作成済みのChrome Appsのマニフェストファイルの場所を指定します。 path/to/を皆さんの環境に合わせて置き換えてください。--link-toオプションでは、指定したフォルダへのシンボリックリンクでプロジェクトが作成されます。

> cca create ChromeSampleApp --copy-from=path/to/manifest.json

--copy-from オプションでは、指定先のフォルダをコピーしてプロジェクトが作成されます。

ビルド、実行

プロジェクトの作成が終わったら、いよいよビルドし、実行してみます。こちらも非常に簡単で、プロジェクトのルートフォルダ上で、次のようにccaコマンドを実行するだけで済みます。

• Androidのエミュレータで実行

> cca emulate android

※ Androidのエミュレータが設定されていない場合、android avdコマンドでセットアップする必要があります

• Androidの実機で実行（デバイスをUSBデバッグモードで接続します）

> cca run android

• iOSのシミュレーターで実行

> cca emulate ios

• iOSの実機で実行（デバイスをUSBで接続します） > cca run ios

それぞれの環境に合わせて、cca emulate または、cca runで簡単にビルド、実行することできます。単純にビルドするだけであれば、 cca buildで可能です。是非試してみてください！

iOSシミュレーターで実行

Chrome App Developer Tool

Chrome Apps on mobileには、実際のデバイス上でChrome Appsを動作させつつ、開発（修正）＞ビルド＞実行のイテレートを高速に回すことができる開発ツール「Chrome App Developer Tool」が用意されています。

Chrome App Developer Toolは、モバイルアプリですので、実機にインストールする必要があります。Androidの場合は、こちらからapkファイルをインストールして使用することができます。（iOSの場合は、ソースコードからビルドする必要がありますので、公式サイトの「Building from Source (iOS or Android)」を参考にインストールしてください）

Androidの場合、Chrome App Developer ToolをインストールしたデバイスをUSBデバッグモードで接続し、次のようにコマンドを実行します。

> adb forward tcp:2424 tcp:2424

cca push

adb forwardコマンドは、デバイスを接続後に1回だけ実行します。その後cca pushコマンドで、Chrome App Developer Tool上でChrome Appsが動作します。これは、ビルドせずにChrome AppsをそのままChrome App Developer Toolに転送して動作するため非常に高速です。

Chrome App DevTool起動

cca push後

Chrome App Developer Toolで動作しているChrome Appsを終了するには、2本指で同時にダブルタップします。

また、cca push --watchコマンドでプロジェクトに変更があれば自動的にpushするということも可能です。ソースコードを修正しながら実機で逐次、動作確認できるのでおすすめです。

まとめ

Chrome Apps on mobileは、デベロッパープレビュー版ということで、まだまだこなれていない面もありますが、Chrome Appsがそのままモバイルで動作するということで非常に楽しみなプラットフォームです。単なるWebアプリをモバイルアプリにするのであればPhoneGapなどの方が簡単ですが、Chrome APIを利用したパワフルなChrome Appsを作って、Chrome Apps on mobileにチャレンジしてみてください！

現在対応している・今後対応するChrome APIのステータスは、こちらから確認することができます。高機能なAPIの多くは、これからの対応に期待ですが、ぜひ楽しみにしていただきたいと思います。

連載「Webサイト・アプリ高速化テクニック徹底解説」の第5回は、前回の「DOM操作の最適化によるJavaScriptチューニング（前編）」に続く後編です。後編では、createElement()などのDOM操作メソッドを使ったさまざまなテクニックや、パフォーマンスを劣化させるよくあるパターンについて詳しく解説します。

DOM操作の最適化によるJavaScriptチューニング（後編）

前回は、DOM操作が遅い原因と仕組みについて簡単に説明し、チューニングのサンプルをいくつか解説しました。その中で、innerHTMLを利用したコードをサンプルにあげていますが、innerHTMLを利用する場合、いくつかの点で注意が必要です。

• HTMLの文字列を扱うため単純な子要素の追加ができない（子要素をすべて書き換えることになる）
• 追加する要素が多くなると、文字列連結のコストやHTMLをパースするコストが膨れ上がる
• HTMLを直接扱うため、きちんとエスケープしないとクロスサイトスクリプティングの脆弱性を作りこむ可能性がある

以上の点から、特に理由がなければinnerHTMLよりもDOM操作メソッドを使ったほうが良いでしょう。今回は、DOM操作メソッドを使ったさまざまなテクニックや、パフォーマンスを劣化させるよくあるパターンを紹介し、そのチューニング方法を見ていきます。

また、前回の記事のinnerHTMLを使ったサンプルでは、上に挙げたような複数の要因でパフォーマンスに影響与えていることから、レイアウト・レンダリングの遅さのみを理由とするには、あまり適切ではありませんでした（チューニング自体には問題はありませんので心配しないでください）。折を見て改訂したいと思います。ご指摘して頂いた方々、ありがとうございました。 本連載では、より良い情報を皆さんに届けるため、ご指摘や疑問点などがあれば是非フィードバックを頂ければと思います。フィードバックを受け、できるかぎり記事を更新していきたいと思います。

DOM操作メソッドを使ったテクニック

createElement()やappendChild()などのDOM操作メソッドを使った方法では、単純にinnerHTMLによるコードを置き換えるだけでなく、さまざまなテクニックがあります。ここでは、DOM操作メソッドを使う際に覚えておいた方がよいテクニックをいくつか紹介します。

複数の要素をまとめて追加する

複数の要素を追加する場合、構造によってはそのままでは一度に追加できないことがあります。例えば、次のサンプルのようにul要素にli要素を追加していくようなケースです。

:javascript:
// サンプル1: ul要素にli要素を追加していく（低速）
var ul = document.querySelector('#output');
for ( var i = 0; i < data.length; i++ ) {
  var li = document.createElement('li');
  li.textContent = data[i];

  // ループのたびにli要素を追加
  ul.appendChild(li);
}

このサンプルでは、ループのたびにli要素を追加していますので、DOMツリーへ更新が何度も発生します。こういった場合には、DocumentFragmentを利用して複数のli要素をまとめて追加することができます。次のコードは、DocumentFragmentを利用して書き換えたコードです。

:javascript:
// サンプル1: ul要素にli要素をまとめて追加（高速）
var ul = document.querySelector('#output'),
    fragment = document.createDocumentFragment();

for ( var i = 0; i < data.length; i++ ) {
  var li = document.createElement('li');
  li.textContent = data[i];

  // いったんDocumentFragmentに追加する
  fragment.appendChild(li);
}

// 最後にDocumentFragmentをul要素に追加する
ul.appendChild(fragment);

DocumentFragmentは、従来のDOMツリーとは分離された独立した小さなDOMツリーです。createDocumentFragment()メソッドを使って作成します。DocumentFragmentに追加された要素は、そのままでは見た目に影響を与えないため、まずはDocumentFragmentにli要素を追加していきます。そして、最後にul要素にそのDocumentFragmentを追加し、反映します。こうすることで、元のDOMツリーへの更新が1回だけで済みます。

繰り返し同じような要素を追加する（テンプレート化）

同じような要素を繰り返し追加する場合、要素をまた一から作成していくのは面倒です。また、要素が多くなってくるとパフォーマンス的にもあまり良くありません。例えば、ボタンが押されるたびに、次のような構造を持つli要素を追加していくことを考えてみましょう。

:html:
<li>
  <artcile class="item">
    <h1 class="title">アイテム</h1>
    <p class="detail">詳細</p>
  </artcile>
</li>

これを素直にDOM操作メソッド使って構築すると次のようにボタンが押されるたびに毎回要素を生成して構築する形になります。

:javascript:
// ボタンがクリックされる度に複雑な要素を追加
button.addEventListener('click', function(){

  // 各要素を生成
  var li = document.createElement('li'),
      article = document.createElement('article'),
      h1 = document.createElement('h1'),
      p = document.createElement('p');

  // 各要素のプロパティを設定し、組み立てる（省略）

  ul.appendChild(li);
}, false);

サンプルでは、コードが多い部分を省略していますが、多くのDOM操作をしています。このような場合、構築される要素をテンプレート化して、それをcloneNode()を使ってコピーするようにすれば、DOM操作の数を減らすことができます。cloneNode()を利用すると次のようなコードになります。

:javascript:
// テンプレートとしてli要素を構築
var template = document.createElement('li'),
    article = document.createElement('article'),
    h1 = document.createElement('h1'),
    p = document.createElement('p');

// 各要素のプロパティを設定し、組み立てる（省略）

// ボタンがクリックされる度にテンプレートから要素を追加
button.addEventListener('click', function(){

  // テンプレートから要素をコピー
  var li = template.cloneNode(true);

  // 一部書き換えて追加
  li.querySelector('.title').textContent = 'アイテム';
  li.querySelector('.detail').textContent = 'アイテムの詳細'
  ul.appendChild(li);
}, false);

こうすると、ボタン押すたびにテンプレートからコピーするだけなので効率的です。構築する要素が複雑になればなるほど、cloneNode()を利用する方が高速になります。cloneNode()の引数は、子要素を一緒にコピーするかどうかなので、trueを指定しておきます。また、cloneNode()ではイベントリスナーをコピーすることはできませんので注意してください。

複数の要素をまとめて置き換える

既に表示されているインターフェースに対して最新の情報を反映するような場合があるかと思います。その際に、表示するデータが細かいとDOM操作も細かくなってしまうことがあります。例えば、次のようなHTMLの各p要素の内容を書き換えることを考えてください。

:html:
<div class="results">
  <p>結果1</p>
  <p>結果2</p>
  <p>結果3</p>
</div>

これを単純に書き換える場合は、次のようなコードになりがちです。

:javascript: 
var elements = document.querySelectorAll('.results p');
elements[0].textContent = '結果a';
elements[1].textContent = '結果b';
elements[2].textContent = '結果c';

この場合、3つのp要素を順に書き換えているので、DOMツリーへの更新が3回発生してしまいます。このような場合、replaceChild()を使って一度に置き換えることができます。

:javascript:
var origin = document.querySelector('.results'),
    clone = origin.cloneNode(true);

// コピーした要素を更新する
var elements = clone.querySelectorAll('p');
elements[0].textContent = '結果a';
elements[1].textContent = '結果b';
elements[2].textContent = '結果c';

// 元の要素とコピーした要素を入れ替える
origin.parentNode.replaceChild(clone, origin);

この方法であれば、DOMツリーへの更新は1回で済みます。また、先ほどのサンプルと同様にcloneNode()がイベントハンドラーをコピーできないことに注意しましょう。

パフォーマンスを劣化させるよくあるパターン

ここからは、パフォーマンスを劣化させるよくあるパターンや、そのチューニング方法を紹介します。

複数のスタイルの書き換え

ある要素のスタイルを複数書き換える場合に、ついやってしまいがちなのが次のコードです。

:javascript:
// 複数のスタイルの書き換え（低速）
element.style.background = 'gray';
element.style.border = '1px solid black';

この場合も、レイアウトが複数発生する可能性があるので、次のように記述しましょう。

:javascript:
// 複数のスタイルの書き換え（高速）
// style属性で一度にすべて指定する
element.setAttribute('style', 'background: gray; border: 1px solid gray;');

setAttribute()を使ってsytle属性を使って一度に複数のスタイルを指定しています。また、あらかじめ指定するスタイルがある程度決っているなら、可読性やメンテナンスを考えてclass属性を使っても良いでしょう。

:javascript:
// classを指定して複数のスタイルを適用する
element.className = 'hoge';

アニメーション

ある要素の位置やサイズを動かしてアニメーションさせるような場合、スタイルでposition: absoluteやpositon: fixedを指定しておくと良いでしょう。これは、レイアウト・レンダリングの範囲を最少化するためです。position: absoluteなどを指定すると他の要素との位置関係やサイズ計算から切り離されるため、その要素に対する変更が他の要素に影響しなくなります。そのため、レイアウト・レンダリングのコストが小さくなり、パフォーマンスが向上します。アニメーションのチューニングについては、また別の記事で触れますので楽しみにしていてください。

スタイル情報の取得

多くのDOM操作によるスタイル情報の取得の中でも、次に挙げるプロパティ、メソッドについては特に注意が必要です。

• getComputedStyle()
• offset*系のプロパティ
• client*系のプロパティ
• scroll*系のプロパティ

（offset*系のプロパティとは、offsetという単語を含むoffsetTop、offsetLeft、offsetHeight、offsetWidthなどのプロパティです）

これらのプロパティ、メソッドは、現時点での最新の情報を返そうとするため、それまでに実行したDOM操作があれば、すぐさまレイアウト・レンダリングを実行します。本来であればブラウザが自動的に最適化し、非同期に実行しているものを強制的に実行してしまうため大きなボトルネックになります。例えば、あるブロックを単純に右に動かすだけのコードを見てみましょう。

:javascript:
// あるブロックを右に動かす
setInterval(function(){
  block.style.left = block.offsetLeft + 1 + 'px';
}, 1000 / 60 );

ここでは、あるブロックのoffsetLeftを取得し、1を加えてスタイルのleftに代入しています。leftの値を更新した後に、またすぐにoffsetLeftを参照しているので、その時点でレイアウト・レンダリングが発生し、遅くなります。そのため、offsetLeftの値をキャッシュしておき、以降はそれを利用するように変更しましょう。

:javascript:
// あるブロックを右に動かす
// offsetLeftの値を一度キャッシュして以降は使いまわす
var left = block.offsetLeft;
setInterval(function(){
  left++;
  block.style.left = left + 'px';
}, 1000 / 60 );

このように、上記であげたプロパティ、メソッドは、多くのDOM操作をしているような箇所では特にボトルネックになりやすいので注意しましょう。（サンプルでは、JavaScriptを使っていますが、もちろんCSSで記述しても良いでしょう。）

要素の取得

それほど気にするほどの差ではありませんが、要素を取得する際にquerySelector()やquerySelectorAll()よりも、getElementById()やgetElementsByTagName()、getElementsByClassName()を利用した方が若干速くなります。

:javascript:
// div要素をすべて取得
var elements = document.querySelectorAll('div');

// querySelectorAll()よりも若干速い
var elements = document.getElementsByTagName('div');

その他の違いにも、getElementsByTagName()などは、結果として返るリスト（NodeList）が常に現在のDOMツリーを反映したものになるのに対して、querySelectorAll()などは取得した時点のものになります。例えば、これらのメソッドで要素を取得した後に、要素が追加された場合、getElementsByTagName()で取得したリストではリストにその要素が自動的に追加されますが、querySelectorAll()ではリストに変化はありません。そういった違いも覚えておくと良いでしょう。

まとめ

ここまで前編、後編にわたってDOM操作の最適化について解説しました。いくつかのサンプルやパターンを交えて、チューニング方法を紹介してきましたが、もちろんこれ以外にもたくさんのテクニックがあります。細かいテクニックをあげていくときりがありませんが、重要なのはDOM操作自体の回数を減らすことと、DOMツリーへの更新とレイアウトやレンダリングなどの範囲、回数を減らすことです。それさえ覚えておけば、自分でいろいろなコードに応用できるかと思います。自分自身で考えてチューニングしていきましょう。

連載「Webサイト・アプリ高速化テクニック徹底解説」の第4回は、JavaScriptのチューニングのうち、ボトルネックになりやすいDOM操作の最適化について解説します。前編・後編にわたって、DOM操作が遅くなる原因と仕組み、その解決策について詳しく解説します。

DOM操作の最適化によるJavaScriptチューニング（前編）

DOM（Document Object Model）とは、HTMLをアプリケーション（ここではJavaScript）から利用するためのAPIです。JavaScriptによるユーザーインターフェースの構築やレスポンスの表示など、インタラクティブな部分はほとんどがDOM操作によるものでしょう。このように、非常に利用頻度の高いDOM操作ですが、同時に性能的にボトルネックになりやすい箇所でもあります。これらのDOM操作の最適化について、今回から前編・後編にわたって詳しく解説していきます。

DOM操作は書き方によってスピードに数十倍の差が出る

DOM操作は、書き方によって非常にパフォーマンスに差が出ます。例えば、次のようなコードを見てみましょう。id属性に”output”と指定された要素に、data配列の中身を単純にリスト表示するだけのものです。

:javascript:
// サンプル1: パフォーマンスが悪い
var ul = document.querySelector('#output');
for ( var i = 0; i < data.length; i++ ) {
  ul.innerHTML += '<li>' + data[i] + '</li>';
}

これは、非常にパフォーマンスが悪い例です。これを次のように書き換えるだけで、環境にもよりますが速度は数十倍にもなります。

:javascript:
// サンプル2: サンプル1に比べてパフォーマンスが良い
var ul = document.querySelector('#output');
var html = '';
for ( var i = 0; i < data.length; i++ ) {
  html += '<li>' + data[i] + '</li>';
}
ul.innerHTML = html;

このように、ボトルネックとなっているDOM操作をチューニングすれば、パフォーマンスが大きく改善する可能性があります。ここからは、DOM操作が遅くなる原因と仕組みを解説しながら、対応策を見ていきます。

なぜDOM操作は遅いのか？

DOM操作はなぜ遅いのでしょうか。それには、大きく2つの理由があります。1つ目は、DOMの実装方法によるものと、2つ目は、DOM操作によるレンダリングのコストが非常に高いということが挙げられます。この2つの理由と対応方法を覚えておけば、さまざまなコードに応用できます。それぞれ見ていきましょう。

ブラウザの実装による遅さ

元々DOMは、特定のプログラミング言語を対象としたものではなく、別々の言語から汎用的にアクセスできるような仕様になっています。そのため、多くのブラウザでは、HTMLのレイアウトや描画を担当するレンダリングエンジンと、JavaScriptを担当するスクリプトエンジンに分かれています。このようにスクリプト部分をモジュール化することによってDOM操作に別のプラグラミング言語を使うことも容易になっています。しかしながら、そのデメリットとして、JavaScriptからDOM操作を行うということは、モジュール間をブリッジするコストが発生することにもなります。そのため、DOM操作自体がプリミティブな操作に比べて非常に低速になっています。そういった観点から、HTMLの要素の単純なプロパティ参照なども含めて、極力DOM操作を減らすようにすることが重要です。

レイアウト・レンダリングによる遅さ

DOM操作の結果は、実際のHTMLに反映される際に、ブラウザでさまざまな処理が起こります。例えば、要素が追加された場合には、それによって発生する各要素の大きさや位置といったレイアウトを他の影響する要素を含めて、すべて再計算しなければなりません。また、レイアウトの再計算が終わったあとには、それらを画面にレンダリングする必要もあります。そして、これらの処理は非常にコストが高いものです。そのため、DOM操作によってレイアウトやレンダリングに影響がある範囲、回数をなるべく減らす必要があります。

例えば、冒頭に示したサンプル1のコードでは、次のようにli要素をループが回るたびに追加しているため、レイアウトとレンダリングが何回も発生して非常に遅くなってしまう可能性があります（レイアウトやレンダリングは非同期で処理されるため、実際にはブラウザがある程度、自動的に最適化してくれます）。

:javascript:
// 複数回、レイアウト、レンダリングされる可能性がある
for ( var i = 0; i < data.length; i++ ) {
  ul.innerHTML += '<li>' + data[i] + '</li>';
}

innerHTMLを利用しているため、少なくてもHTMLのパースはループのたびに発生します。また、古いブラウザでは文字列の連結自体が問題になることもあります。このコードを、レイアウトとレンダリングが1回になるように書き換えると次のようになります。（その他にも、innerHTMLを「+=」演算子で余分に参照していることや、innerHTMLの中身を毎回すべて書き換えていることも遅さの原因になっていますが、次のコードではそれらも改善しています。）

:javascript:
// 変数にHTMLを格納しておき最後に1回だけ書き換える
var html = '';
for ( var i = 0; i < data.length; i++ ) {
  html += '<li>' + data[i] + '</li>';
}
ul.innerHTML = html;

最終的に、結果が表示されれば良いので、li要素のHTMLは、いったん別の変数に格納しておき、最後に1回だけinnerHTMLへ代入しています。これによって、DOM操作の回数もレンダリングの回数も以前のコードに比べて1回で済みます。

innerHTMLとDOM操作メソッド

ここまでのサンプルでは、innerHTMLを使ってDOM操作を記述していますが、createElement()やappendChild()などのDOM操作メソッドを使う方法もあります。次のサンプルは、サンプル2をDOM操作メソッドを利用して記述した例です。

:javascript:
// サンプル3: createElement()を使った例
var ul = document.querySelector('#output');
var fragment = document.createDocumentFragment();
for ( var i = 0; i < data.length; i++ ) {
  var li = document.createElement('li');
  li.textContent = data[i];
  fragment.appendChild(li);
}
ul.appendChild(fragment);

innerHTMLとDOM操作メソッドは、それぞれ良い点がありますが、基本的にはDOM操作メソッドを使っていくほうがクロスサイトスクリプティングの脆弱性を作りこみにくいので安全です（innerHTMLは、文字列をパースするためユーザーの入力値を使う場合はエスケープする必要があります）。これらのDOM操作メソッドを利用する方法は、次回で詳しく取り上げていきます。

innerHTMLとDOM操作メソッドのスピード

innerHTMLとcreateElement()などのDOM操作メソッドは、どちらが速いかといった形でよく比較されることが多いですが、パフォーマンスという観点からはそれほど気にしなくても良いでしょう。モダンな環境では、お互いの速度差はそれほど大きくありませんし、ブラウザは常にバージョンアップされていますのでベンチマークの結果はすぐに変わります。特定の環境に特化したチューニングを行うのでなければ、細かい速度差を気にするよりは、機能の違いで使い分けていきましょう（ちなみに、現在はIE、FirefoxはinnerHTMLの方が若干速く、Chrome、SafariはDOM操作メソッドの方が若干速くなっています）。

次回の内容について

今回は、DOM操作が遅くなる理由と、その対処方法について簡単に解説しました。次回は、createElement()によるDOM操作と、チューニングのためのさまざまなTipsを紹介していく予定です。お楽しみに！

連載「Webサイト・アプリ高速化テクニック徹底解説」の第3回は、前回の「ユーザーの体感速度を高めるためのJavaScriptチューニング（前編）」の続きです。この後編では、「ユーザーの操作を阻害しない」方法についてJavaScriptのシングルスレッドやイベントループを交えて解説し、HTML5のWeb Workersについても紹介していきます。

ユーザーの体感速度を高めるためのJavaScriptチューニング（後編）

前回は、ユーザーの体感速度を向上させるための方法として、3つのうち「ページを素早く表示する」と「ユーザーに素早くインタラクションを返す」を解説しました。今回は、最後の「ユーザーの操作を阻害しない」について詳しく解説していきます。

ユーザーの操作を阻害しない

JavaScriptによる処理が重くなると、いつまでも画面が更新されなかったり、ユーザーの操作が止まってしまったりということがあります。止まっている時間が長すぎると、ブラウザから応答がないという警告がでることもあります。それほどひどくなくても、ページのスクロールが途中でつっかかったり、アニメーションがとぎれとぎれになったりといったことは、皆さん経験があるのではないでしょうか。こういった状態は、ブラウザのユーザーインターフェース周りの処理とJavaScriptが同じシングルスレッドで動作していることに原因があります。このようなブラウザにおけるシングルスレッドとイベントループという仕組みを先に簡単に解説しておきましょう。

シングルスレッドとイベントループ

通常、ほとんどのブラウザはシングルスレッドで動作しており、JavaScriptのコードや画面の描画、ユーザーの操作（ページのスクロールやマウス操作など）を同時に処理することはできません。そのため、JavaScriptの処理に時間が掛かってしまうと、その間は画面の描画も、ユーザーの操作も止まってしまいます。これらの処理は、イベントループと呼ばれる仕組みで動作しています。

イベントループのイメージ図

イベントループは、イベントを監視する無限ループを持ち、イベント（またはそのコールバック）が発生すると、発生順にそのイベントを処理していきます。ここでいうイベントには、JavaScriptのイベントに加えて、ブラウザのレイアウトイベントや描画イベントなども含まれています。そのため、JavaScriptの実行に時間がかかると、その間に発生した描画イベントなどの他のイベントが実行キューに登録され、いつまでも処理されないということになります。根本的な対応方法は各処理を短くすることですが、このイベントループの仕組みうまく利用すれば、大きな処理を細かく分割することもできます。

setTimeout関数などによる擬似的な並列処理

イベントループの仕組みを考えると、JavaScriptの処理に時間がかかる場合は、その処理をいったん終了させて、別のイベントで続きを実行すれば処理を分割できることになります。この分割した処理の間に、ブラウザの描画イベントなどが発生すれば、正常に画面が更新されることになります。

例えば、JavaScriptで時間のかかる処理の前に、先に見た目を更新するという方法（前回の「ユーザーに素早くインタラクションを返す」）を挙げましたが、次のようなコードでは画面がすぐには更新されず、JavaScriptの実行が終わるまで反映されません。

:javascript:
// id属性に"output"を指定した要素にメッセージを表示するコード
var output = document.querySelector('#output');
output.textContent = 'メッセージ';

// ~なんらかの時間がかかる処理~

これを、メッセージがすぐに画面に反映されてから、時間がかかる処理をするように変更するには、次のように記述します。

:javascript:
// id属性に"output"を指定した要素にメッセージを表示するコード
var output = document.querySelector('#output');
output.textContent = 'メッセージ';

setTimeout(function(){

  // ~なんらかの時間がかかる処理~
}, 0);

setTimeout関数を利用して、時間のかかる処理を実行しています。setTimeout関数は、一定時間後に指定したメソッドを実行する関数ですが、ここでは0ミリ秒後に指定しています。これは、実際にはすぐに実行されるわけではなく、イベントループの実行キューに登録されることになります。そのため、上で表示しているメッセージの描画イベントが先に実行され、その後にsetTimeout関数で指定した処理が実行されます。

このようにして、setTimeout関数を使って、明示的に大きな処理を分割し、擬似的な並列処理を実現することができます。あまり多用するとコードの可読性やメンテンナンス性などが落ちるので注意が必要です。また、setTimeout関数以外でもイベントやコールバックであれば良いので、XMLHttpRequestやその他のイベントハンドラでも同様のことができます。JavaScriptでは、もともとそういった記述が多いので、意図的ではなくても自然とそういったコードになっていることが多いと思います。しかしながら、こういった仕組みを知っておくことでうまく問題が解決できることもありますので、覚えておくと良いでしょう。

実は、このsetTimeout関数を使った特定の処理を実行キューの最後にスタックする方法は、setImmediate関数として標準化が議論されています（仕様はこちら）。現在は、IE9以降で実装されています。

バックグラウンドでJavaScriptを実行する「Web Workers」

HTML5には、setTimeout関数などによる擬似的な並列処理ではなく、本当の並列処理を行うためのWeb Workersという仕様があります。このWeb Workersでは、JavaScriptの処理をブラウザのメインスレッドとは別に、バックグラウンドで処理することができるようになります。そのため、画面の描画やユーザー操作を阻害せずに、時間のかかるJavaScriptを実行することができます。

早速、Web Workersの利用方法を見ていきましょう。Web Workersを利用する場合、バックグラウンドで処理するためのJavaScriptファイルを別に用意します。ここでは、表示するページで読み込むmain.js、バックグラウンドで動作するworker.jsの2つに分けています。それぞれのファイルの内容は、次の通りです。

main.js

:javascript:
// ワーカーの作成
var worker = new Worker('worker.js');

// メッセージ受信イベントの登録
worker.addEventListener('message', function(e){
  console.log(e.data);
});

// メッセージ送信
var message = 'test';
worker.postMessage(message);

main.jsでは、バックグラウンドで動作するWorkerオブジェクト（以下、ワーカー）を引数にworker.jsを指定して作成します。そして、ワーカーとのデータの送受信には、お互いにメッセージをやり取りして行います。ワーカーのpostMessage()メソッドで加工するデータなどを送信し、messageイベントでワーカーから戻ってきたデータを受信します（データはコピー渡しとなります）。送受信できるデータは、基本的な型やオブジェクトなどが可能ですが、Errorオブジェクトや関数（Functionオブジェクト）、DOMノードなどはエラーとなります。

worker.js

:javascript:
self.addEventListener('message', function(e){

  // メッセージを受信して、そのまま返す
  self.postMessage(e.data);
});

worker.jsでは、main.jsと同じようにmessageイベントとpostMessage()メソッドを利用してメッセージをやり取りします。ここでは、messageイベントでデータを受け取り、受け取ったデータをpostMessage()メソッドでそのまま返しています。例えば何らかの処理をする際には、ここでデータを加工して送り返すといったように変更すると良いでしょう。ワーカー自身にアクセスするには、self変数を利用します。また、ワーカー内では、windowオブジェクトやページのDOMツリーにアクセスすることができませんので注意してください。

このようにして、main.jsでは基本的にユーザーインターフェースの作成やワーカーでの処理結果を反映するだけにとどめ、ワーカーで実際の処理をバックグラウンドで行うようにすると、ユーザーの操作を阻害しないような作り込みができます。また、Web Workersを利用することで、自然とビジネスロジックなどのコードを切り分けることできるので、MVCモデルのような構成を取りやすいこともメリットのひとつでしょう。是非、チャレンジしてみてください。

以降は、Web Workersの対応状況や制限事項などを載せておきますので、参考にしてください。

Web Workersの対応状況

デスクトップ向けであれば、IE9を除くすべてのモダンブラウザ（IEはバージョン10より対応）で利用することができます。モバイル向けでは、iOSは対応していますが、残念ながらAndroidの標準ブラウザが未対応です。そのため、Androidに対応するためにはfakeworker-jsなどのPolyfillを利用しましょう。

メッセージで交換できるデータの種類

メッセージで交換できるデータについては、Boolean、Number、Stringオブジェクトなどの基本的な型に加え、Date、RegExp、ImageData、File、Blob、FileList、Array、Objectオブジェクトなども可能です。逆に扱えないデータとしては、Error、FunctionなどのオブジェクトとDOMノード、RegExpオブジェクトのlastIndexプロパティなどです。また、setterやgetter、prototypeなどはコピーされません。詳しくは、Structured Cloneというアルゴリズムで定義されています。

ワーカー内で利用できる機能

ワーカー内では、DOMツリーやwindowオブジェクト、doucmentオブジェクト、parentオブジェクトにアクセスすることができません。ワーカー内で利用できる機能としては、navigatorオブジェクトやlocationオブジェクト（読み取り専用）、XMLHttpRequest、setTimeoutとsetInterval関数、Application Cacheなどです。また、さらに他のワーカーを作成することもできます。ワーカーで利用できる独自の機能には、外部スクリプトをインポートすることができるimportScripts関数などがあります。

おわりに

前編と後編にわたって、ユーザーの体感速度を向上させるJavaScriptのチューニング方法について詳しく解説しました。次回からは、引き続きJavaScriptの高速化をテーマに、DOM操作の最適化について解説していく予定です。お楽しみに！

★「ユーザーの体感速度を高めるためのJavaScriptチューニング（前編）」を読む★