本対談記事は、Extensible Webが誕生してから2年で何が変わったのか、そしてこれからWebはどうなっていくのかを、有識者の方々にそれぞれの立場から語っていただこうという企画です。

後編である今回は、Extensible Webの現在、そしてWeb技術の未来にフォーカスしたお話になります。Extensible Webの概要や、Extensible Web以前からあるWebの問題点について知りたい方は、前編をご覧ください。

HTML5は（ついに）モジュール化される

白石 では、Extensible Webの考え方が提唱されてから2年が過ぎたわけですが、どのような変化が起きつつありますか？まずは皆さん、思いついたものから教えていただけると嬉しいです。

ダニエル 最近の話で言うと、HTML5の仕様がモジュール化されます。例えばTimed Media Working Groupというワーキンググループが提案されていますが、もともとはHTML5の一部でした。このように、専門的なグループに分かれて仕様策定が進められるようになろうとしています。

白石 Extensible Webは、標準化の話とも密接に関わっているかと思うので、詳しく教えて下さい。HTML5.1がバラバラになっていくということでしょうか？

ダニエル そうです。まだ詳細は決まっていませんが、今後仕様書も分割されていきます。ちょうど、CSSがバージョン3になって、多数の仕様書に分割されて、それぞれメンテナンスされるようになったのと似た感じになるでしょう。

また、ワーキンググループが分かれていくというだけではなく、もっと開発者が参加しやすくなります。その一つが、Web Incubator Community Groupの作成です。これができたのもつい最近（2015/7/2）ですね。ここは仕様を提案する場というよりは、質問してアドバイスを受けたり、デモを投稿したりと、一般の開発者のサポートが中心になります。

斉藤 これは素晴らしいですね。最近すごく思うのは、仕様書がGitHubに置かれるようになって、別にGitHubが大好きというわけでもないんですが、開発者に見られるサイトNo.1ということで、変更の履歴すらも簡単に見られるようになり、どういう経緯で仕様が変更されていったかが追えるようになったのは素晴らしいと思います。

ダニエル 10月のTPACまでに細かい作業を終えて、TPAC以降にフィードバックをもらいながら改善していくという感じだと思います。

APIの低レベルさはどこまで許容される？

浅井 最近はExtensible Webの流れを受けて、低レベルなAPIを提供して開発者に使ってもらおう、ということを意識するようになりました。例えば最近、センサー類のAPIを作ろうとしているのですが、大きく２つの方向性があるという議論になったんですよ。

一つは光センサーとか、既存のセンサーを抽象化するようなもの。またそれと合わせて、組み込み向けの通信制御のAPIを提供してはどうかというものでした。こちらはまあ、普通ですね。

でももう一つはぶっ飛んでて、Low Level File System APIっていうのを作ってしまってはどうか、と。 UNIXって、/dev 以下のファイルを通じてデバイスにアクセスできるじゃないですか。だったら、ファイルにアクセスできる手段を一つ開発者に与えてあげるだけで、どんなデバイスでも操作できるようになるじゃないか、と。本当に低レベルなものを作りさえすれば、開発者が必要なものを作れるよという考え方です。

でもこれは完全にぶっ飛んでる。だってプラットフォームに思い切り依存するじゃないですか。やり過ぎ感はすごくあるけど(笑)、それをマジメに議論できるようになったというのが、Extensible Webから来る発想なんじゃないかな、という気がします。僕としては、ちょっと低レベルすぎるんじゃないかと思いますが。

白石 そのうち、システムコールとか叩けるAPIが出てきそうですね。

浅井 あまりAPIが低レベル過ぎても、今度は（JavaScriptライブラリによる）パフォーマンスのロスが大きすぎるし、OS依存のAPIを露出するのはよくないという考え方もあるので、どこまで低レベルにいくべきかというのは、今Extensible Webの中で本当に議論していかなくてはならないんじゃないか、という気がします。

「Extensible」なAPIたち

白石 なるほど。ではここでちょっと話を変えて、実際にExtensible Webに関連するAPIといえば何があるんでしょう？まずFetch（※）とか。あと、ServiceWorker（※）もでしょうか。

斉藤 Promise（※）とかもそうだと言っていいんじゃないでしょうか。Promiseの原型になったAPI（Deferとか）は、Extensible Webの提唱以前からありますが。

小松 他には、Object.observe（※）とかもありますね。

浅井 Web Components（※）もそうでしょうね。

ダニエル Web Componentsは便利ですよね。Polymer 1.0が出た時に使ってみましたが、とてもよかった。でも、Polymer自体がものすごく巨大なので、便利さの代償も大きいな、と(笑)。

浅井 Web Components、小規模なプロジェクトならいいですが、大規模で長期的なプロジェクトとかでは、まだあまり使われてないんじゃないでしょうか。 そういう点では、Mozillaはむしろ積極的に使っています。しかも、Firefox OS本体で。本当に大事なAPIは、誰かがガチで使わないと熟成されないので、我々は必ず本番プロジェクトにガンガン入れるんです。

Firefox OS 2.5とかになると、Web ComponentsだけじゃなくてServiceWorkerとかも思い切り使って、アプリケーションのアーキテクチャを大幅に変更しようとしてます。どこよりもServiceWorkerを思い切り使って、悪いところを見つけ出そう、くらいの勢いですね。 ただ、ServiceWorkerをフルに使用して、複雑なキャッシュ処理とかを行うコードを見ていると、これはもう一般のWeb開発者が気軽に触れるレベルじゃないな、と思います。WebGLを生で扱うコードとかもそうですけど。

小松 WebRTCなんかについても、「一般のWeb開発者にとっては、使うのが難しい」という話はよく聞きます。でもWebRTCは、低レベルすぎるという意見もあれば、あれでもまだAPIのレベルが高過ぎるという意見もあって。

もともとはビデオチャットをユースケースとしてAPIを作っていたんだけど、実際にやってみると双方向のビデオチャットだけじゃなくて、例えば監視カメラみたいに「一方向だけ」というユースケースも重要だったりとか、多人数会議とかやるときは映像のネゴシエーションとかもっと柔軟にやりたい、という話が出てくると、実は今のWebRTCでも高レベルすぎると。その議論が、今のORTCに繋がったりしているわけです。しかし、APIのレベルを低くすればするほど、柔軟性は向上するんだけど取り扱いは難しくなって、一般の開発者が触るには難しいものになっていくだろうな…とは感じています。

白石 なるほど…WebRTCみたいな、高度なネットワーク処理を伴うAPIについては、TCP/UDPのソケットを直接触れるような低レベルAPIがあればよさそうですよね。Socket APIとかは既にあるんでしたっけ？

浅井 ありますよ。Firefox OSではよく使われています。

白石 ああそうか、Firefox OSやChrome OSだと、かなり低レベルなJavaScript APIが既に実装されてますよね。Bluetoothとか、シリアル通信とかも可能だったような。

ダニエル BluetoothのAPIは使ってみたんですけど、やっぱりChromeブラウザじゃなくてChrome OSでしか使えないんですよね。ブラウザで（通常のWebアプリで）使いたいとは感じましたが、それは叶っていません。「危険だ」と。

小松 APIのレイヤーを下げていくことと、セキュリティやプライバシーはトレードオフがありますよね。

※ Fetch…ブラウザがHTTPを使用してリソースを取得する操作をAPIとして利用できるようにしたもの。XMLHttpRequestに近いが、よりAPIが洗練されている

※ Web Components…カスタム要素を利用できるようにできるAPI

低レベルAPIとセキュリティ・プライバシー

ダニエル 今お話に上がったように、「低レベルなAPIは危ない」という問題もある。皆さんここはどう考えますか？

白石 僕が今回の対談を準備するにあたって、いろいろ情報を集めた中では、「そういうセキュリティやプライバシーの部分こそ、標準化のリソースを費やすべき点だ」という意見がありました。ひとりのエンジニアが、自分の力だけでセキュリティやプライバシーを完璧に実装することは不可能なので、標準化というプロセスを踏んで様々な知見を集約することで、そういったAPIの安全性を担保するという。

浅井 ただ今の時代、APIだけでセキュリティを担保するのは難しくて、結局はアプリケーションのエコシステム全体でサポートしていかなくちゃいけないんですよね。例えばWebを全てHTTPS化するとか、アプリケーションマーケットでセキュリティレビューが行われるから安全になるとか、ほかの仕組みと組み合わせることで安全性を担保するという形になってきている。

まあ、一方で、そういう他の仕組みで担保してもらえるからエンジニア自身はあまりセキュリティのことを考えなくなっている…というのもあると感じています。もし低レベルのAPIが使えるようになるなら、実際躊躇なく開発者は使うわけですよ。Firefox OSでもふんだんに使われています。セキュリティレビュー前提でね。でも、そのセキュリティレビューが、どのエコシステムでも行われるわけではない。もしそういうAPIが、（セキュリティレビューのない）一般のWebコンテンツでも使えるようになったらまずいんです。

エコシステム全体で安全性を保っているのに、エコシステム抜きでAPIだけ持ってきて使えるようにしてしまうと、安全でなくなってしまう。そこをどうやって担保していけばいいのかな、というのはすごく難しく感じています。

白石 HTTPSが前提だったり、Firefox OSみたいな環境の上でサンドボックス化されたアプリケーションであることが前提だったりとか、APIを取り囲む様々なコンテキストだったり環境を含めてこそセキュリティが担保されるのであって、APIだけ切り出して安全性を担保するというのは難しいということですね。

斉藤 なるほど… 正直、「ServiceWorkerがHTTPSのみになりました」と聞いた時「なんだとコノヤロウ」と思ったくらいなんですが(笑)。よくよく考えてみると「そうだよね」と納得は出来るんですが、一方で「誰がそのSSL証明書代払うねん」という感じでもあります(笑)。

浅井 MozillaはHTTPSの無料化を推進しようとしていますけどね。

白石 そうですよね、頑張ってくださいよMozillaさん！世界中がMozillaに期待してます(笑)！

でも、ServiceWorkerはHTTPSオンリーです、というのは少し乱暴な感じも受けるのですが。今後、Extensible Webの思想に則ったAPIがどんどん現れるとして、「とりあえず危ないかもしれないからHTTPS限定にしておこう」という感じになっちゃわないんでしょうか？

斉藤 まあ、流れとしてはWebは全部HTTPSにしていこうという感じですしねえ…

小松 そうそう。iOS9のWebViewは、デフォルトではHTTPS接続しかできなくなるしね。

ダニエル 標準化のほうでも、実際そういう流れはあります。「Secure Contexts」というドキュメントがあって、「こういう場合はHTTPS接続が必要」というシチュエーションを列挙しています。 これによると、センシティブなデータやセンサーデータにアクセスするAPIは全て対象となっていますので、（今まで非HTTPS環境でも利用できていた）Geolocation APIなども、将来的にはHTTPS限定になるかもしれません。

世界は、開発者からのフィードバックを求めている

白石 ここまでは、Extensible Webを中心として、Webの過去や現在についてお話いただきました。では、未来のWeb技術はどうなるんでしょう？

ダニエル 簡単に言うと、低レベルなAPIが増えて、高レベルなライブラリが増える、ってことじゃないかと思います。

斉藤 一般の開発者や企業もライブラリを作るようになり、もっと言えば、それで利益を上げる企業が出てきてもいいと思います。今はWebのプラットフォームやライブラリを作っているのって、結局ブラウザベンダ周辺の方々ばかりです。もしそこで利益を上げられる仕組みが出てきたとしたら、もっと一般の企業や開発者がWebのプラットフォームづくりに貢献できるようになるんじゃないかと。今は、あまり貢献できる余地がない。

浅井 （Webプラットフォームへの）貢献という点では、ブラウザベンダの立場から言うと、一番求めているのって開発者からのフィードバックなんですよね。Webブラウザのエンジニアは、フィードバックが欲しくてしかたがないんですよ。自分たちが仕様を書いても、他の人が作って使ってくれないと標準化できないんですから。そこを、どんな方法でもいいから解決したくって、だからこそこんな考え方（Extensible Web）になったという流れもあると思います。

白石 そうですよねえ…前編でいくつか挙がっていた「使われていないAPI」なんて、ほんとに使われてなさそうなので、フィードバックも何もあったもんじゃないですよね。

浅井 そうなんです。少なくとも僕らは、W3Cにインパクトを与えるためにもどんどん開発者は意見をあげていってほしいと思っていますし、ダニエルさんが紹介していたWeb Platform Incubator Groupにも参加してほしいと思っています。Mozillaに限って言えば、Bugzillaに日本語でもいいからガンガンコメント欲しいですね。「英語で書かなくちゃならない」と思って書かない方も多いんですが、翻訳サイトを使って読んでみて、わからなければ日本のエンジニアに質問が来るので。

斉藤 なるほど、そういう貢献であれば、気軽にできそうだし人にも促せそうです。

浅井 わかりにくい英語でフィードバックもらうくらいなら、専門用語満載で日本語で書いてくれたほうがありがたいんです。フィードバックをもらえないことで発生するコストに比べたら、日本語のフィードバックをもらってそれに日本のスタッフが応えるなんて安いもんです。今はそれこそ、縦書きの仕様とかあるじゃないですか。ああいうところって、日本でしか通用しない用語がたくさんある。それを無理に英語にする必要はなくて、そのまま日本語で書いてほしい。

斉藤 そうですよね…「禁則処理」とか英語でどう言えばいいのか、よく考えたら知らない(笑)。

浅井 そういうフィードバックを世界中の開発者がくれる、という未来を僕らは目指しているんです。それに、Extensible Webが進むことで、例えばライブラリやミドルウェアをビジネスにするような企業も出てきたとしたら、そういう企業ってブラウザベンダとの協業にも本気なので、更にフィードバックが熱くなって嬉しいし。

例えば3Dにしても、UnityとかUnrealとか大きな企業がガンガンフィードバックをくれるので、WebGLやasm.jsも —— 今は WebAssemblyの方向に向かっていますが —— どんどんよくなっていったわけですし。

小松 確かに、ビジネスで使われると急激にフィードバックが貰えるようになりますよね。

斉藤 「趣味」のレベルと「ビジネス」のレベルだと、フィードバックするモチベーションもぜんぜん違うかもしれませんね。

小松 そうそう。趣味でやってる時って、例えバグに遭遇したとしても「このバグは仕様である」って済ませちゃう(笑)。

斉藤 「ま、いっか」で済ませちゃいますよね(笑)。Web技術の進化がビジネスに直結するのであれば、フィードバックのモチベーションは確実に高まると思います。

今あえて問う: Web技術の進化は求められているのか？

白石 ここで一つ、ちょっと刺激的に聞こえるかもしれない問題提起をさせてください。 Web技術の進化って、今そんなに求められているのでしょうか？ 現状で言うと、Web技術って主にデスクトップブラウザで使われていて、モバイルはネイティブでいいよね、と世間に認知されている感覚が僕としてはあって。 しかも、デスクトップは進化が停滞していて、イノベーションはモバイルアプリで起こっている。WebのAPIをどんどん拡充していっているけど、それで喜んでいる人ってどれくらいいるのかな？と。

ダニエル 確かに…最近そういう議論がありましたね。ppk（※）を中心として、「Webは一年くらい開発を止めておこう」という発言がありました。

斉藤 僕もppkの発言は読みました。普通、僕らの開発でも、2年も経てばたくさん技術的負債が溜まっていってしまうものなのに、Webは壊れたままでどんどん新しい機能を追加していこうとしている。「一旦止まってしまうと死んでしまう」「止まることは後退することだ」というある種の強迫観念のようなものがあるのかもしれません。

浅井 実際には（Webの進化は）長い間止まってましたけどね(笑)。

白石 (HTML)4と5の間ね。

斉藤 あの（進化が止まっていた）悲しさを繰り返しちゃダメだと、みんな思っているんじゃないでしょうか。僕は、Webはなくなってほしくないと思っているので、Web技術の進化は続いてほしいと考えています。ただ白石さんが仰るとおり、モバイルはネイティブでいいじゃん、という流れもあるのは確かです。

白石 僕自身も、モバイルアプリであってもCordovaを使って開発していたりするので、Web技術は進化し続けてほしいと考えてはいます。CordovaやFirefox OSと言ったプラットフォームが今よりもっと力を持てば、先ほど僕が言った問題提起は不要だと思うんですけどね。

浅井 今はiOSやAndroidのシェアが非常に大きいですからね。そこら辺の状況が変わってくれば、Web技術の立ち位置ももう少し変わってくるんでしょうけどね。

また、先ほどあれだけ開発者に「声が欲しいんです」と訴えましたが、一方で仕様を作っているメンバーが念頭に置いているのは、5年10年先まで互換性を保ち、しかもあらゆるプラットフォームで動作することです。最初からこれを念頭に置いたプラットフォームは、人類にとって唯一のものだと思う。だから、5年10年先を見据えて絶え間なく技術を進化させていくというのは、誰かがやらなくてはならないと思っています。

白石 そう考えると、昔の「ユースケースありき」で仕様を決めていくというのは少し無理があったのかな、と思えますね。5年10年経ったら、ユースケースなんて同じなわけがないですし。そう考えても、Extensible Webというのは正しい方向なんじゃないかと思えてきました。

ダニエル そうですね。HTML5の世界は、長らくユースケースベースでした。例えばHTML5に何かを提案しようとすると、Ian Hickson（※）の答えは決まって「あなたのユースケースを教えて下さい」（「What’s your use case?」）でしたし。Extensible Webは、そうしたパラダイムからの脱却という面は少なからずあると思います。 ※ ppk…Peter-Paul Koch氏のこと。著名なWebエンジニアで、QuirksModeというサイトを運営している。

※ Ian Hickson…HTML5を始め、近年の様々なAPI仕様を策定するにあたって中心的な役割を果たしていた人物。相性はHixie。

新たなライブラリ、仕様書の変化 – Extensible Webがもたらしつつある変化とは

ダニエル CSSの方でも、ユースケースありきの考え方から脱却しつつあります。例えば「CSS Houdini」は、ユースケースを考えずにCSSの基盤を公開して、その上に新たな機能を載せていくというアイデアです。

例えば、「新しいセレクタが欲しい」という場合、CSSの低レベルAPIで独自のCSSセレクタを作ったり…ということが想定されています。

小松 正確ではありませんが、「Web ComponentsのCSS版」といえばわかりやすいんじゃないかな。

斉藤 「独自のCSSセレクタを作る」というのを実現するhitch.jsというライブラリはすでにありますね。

白石 （READMEの例を一見して）自分の好きなセレクタを書ける！これはすごい。いやー、未来的な話になってきましたね。

斉藤 CSSにまつわる話で言うと、CSS Element Queryっていうのもありますね。

白石 （こちらもREADMEの例を一見して）ああ、これは使いやすそうですね。メディアクエリで「巨大なif」みたいな感じになるのが防げますね(笑)。

小松 ほんとだ、これは便利そう。

ダニエル ちょっといいですか？今ここで起きていることこそが、Extensible Webが目指す形だと思いました。

これまでは、まず英語でできた仕様書しかなくて、その後コードやデモが整備されるまでは中々APIを理解できない。英語がよく読めない人たちにとってはなおさらです。

でも今ここで起きていたのは、アイデアがコードで示されていて、皆さんは説明よりも先にコードを読んでいました。そして、「これはいい」とか「これは良くない」とかそういう話で盛り上がっていた。

小松 確かに。それに、仕様書にコードスニペットが記載されるという動きも、どんどん広がってますよね。そっちのほうがずっと分かりやすいから。

白石 そうですよねー、WebIDL（※）で示されたインターフェース定義から、どう動くのか想像するのとかって、割としんどかったですからね。そもそもWebIDLの読み方を勉強しなくちゃならない。

斉藤 「仕様書の読み方」みたいな講座があってもいいかもしれませんよね(笑)。

※ WebIDL…W3Cのドキュメントで使用される、Web技術用のインターフェース定義言語（IDL:Interface Definition Language）

Extensible Webから探る、Webの未来

白石 では、最後のトピックとして、Webブラウザの未来を探ってみたいと思うのですが、いかがでしょう？例えば以前、「Webは死ぬか」という対談を行った時に、Googleの及川さんが、「ブラウザコードもコンポーネント化が進んで、必要に応じてコンポーネントがダウンロードされる」という可能性を示唆してくれたのですが。

小松 例えばLinuxディストリビューションを想定してみるのもいいかもしれませんね。Linuxのカーネルに当たるのが現在のブラウザエンジン（のコア部分）で、その他の部分、例えばJavaScriptライブラリや利用頻度がそこまで高くないAPIとかは、パッケージみたいな扱いになるとか。

ダニエル 未来のブラウザという話で言うと、もっと専門的なブラウザが出てくる可能性もあるのかな、と考えています。例えばEspialという会社がありまして、別にここは新しい会社ではありませんが、TV専用のブラウザを作っていて、結構使われています。 こういうブラウザが、TVに関係する機能だけ実装すればいいのと同じように、家電専用のブラウザとか、色んな用途に特化したブラウザが出てくる可能性は大きいと思います。

浅井 ブラウザが様々なデバイスで使われるようになっていくと、そのうちブラウザというのはユーザから見えなくなって、意識されなくなっていく。四角くなくなるとか、UIのないブラウザとかが普通に使われるようになっていく。

斉藤 ブラウザがどこにでもある、って世界ですね。

白石 ただ例えば、ウェアラブルデバイスにブラウザが乗るのは当面ないような気もしますね。パフォーマンスの問題もありますし。

斉藤 それは確かにそうかもしれません。が、何をもってブラウザと呼ぶのか、という話もありますね。例えば最近読んだのは、車通勤している最中に、Mediumの記事を読み上げてほしいという話があって。そのためのAPIを作ってはという話だったのですが、サーバ側でMediumのHTMLを解釈して、音声データだけをダウンロードしてクライアントで再生するようにすれば、HTMLを解釈する「ブラウザ」はクライアント側になくてもいいわけです。このように、Webページを「聞く」という行為、それすらも「ブラウジング」と言えると思います。

白石 なるほど、「ブラウザがどこにでもある」という世界を考えると、逆にブラウザが手元になくてもいいわけですね。HTMLが単なる音声データのためのデータソースになっている。

浅井 そういうサービスを作るにあたっても、Web技術を使うようにすると、特許の問題とかが起きにくいんです。

斉藤 ああ、それはありますね。

浅井 …新しいものを作るときに、エコシステムが広がるのをブロックしてしまう原因を、Webは比較的解決していたり、最初から意識していたりすることが多いので、Web技術が広がってくれると、

白石 広がってくれると？

浅井 より人類は幸せになれます。

白石 話でかい(笑)。〆の言葉としていい感じのフレーズが出たところで、本対談を終わりにしたいと思います。皆様、本日はどうもありがとうございました！