ガジェット通信

見たことのないものを見に行こう

ブラウザ戦争、HTML5の標準化、ブラウザの未来──歴史を語り尽くすWebブラウザ談義【後編】

DATE:
  • ガジェット通信を≫

「ブラウザ戦争」とは何だったのか

Webブラウザの歴史を辿ると、歴代のブラウザが、技術的にもビジネス的にも激しい覇権競争を繰り広げたことが、結果としてWebの普及を促したことがわかる。

94年12月にリリースされた Netscape Navigatorは順調にバージョンを重ねるが、これに対抗して、Microsoftは95年8月に Internet Explorer(IE)を発表する。後世に第一次ブラウザ戦争として記憶される闘いの幕開けだった。

97年には、Microsoftはその陣営を拡大するため、当時、独自のブラウザを持たなかったAppleと業務提携。IEはMacでも標準ブラウザに昇格する。

一方、Netscape Navigatorは、97年にはメールクライアントやWebページ作成ソフトを含む、統合アプリケーションNetscape Communicatorとしてもリリースされるようになる。

しかしIEのシェア拡大につれ、98年後半にはシェア半分を割るようになった。この中で98年3月に「将来のすべてのバージョンを無償で提供し、コミュニティによって開発と保守を行う」という宣言を行い、ブラウザのオープンソース化の先駆けともなった。

しかし企業買収はインターネットビジネスの常でもあり、Netscape CommunicationsはAOLに買収され、Netscape Communicator5.0の開発は中止された。

第一次ブラウザ戦争は、IEがOSの一機能として搭載され、CSSの処理もNetscapeに先んじていたことなどから、次第にIEの優勢が強まり、2000年ごろにはIEが市場シェアのほぼすべてを獲得することで、第一次ブラウザ戦争は終結した。

▲下農淳司氏(東京大学国際高等研究所カブリ数物連携宇宙研究機構特任研究員)

「ただ、NetscapeのコードはMozillaプロジェクトに移管され、Mozillaブラウザの開発はずっと続いていた。Netscape NavigatorとしてもMozillaブラウザをベースとして新バージョンがリリースされていたし、その技術の系譜はFirefoxとして今も続いている」(下農氏)という事実も押さえておきたい。

この頃のブラウザ開発者たちは、それぞれ独自の拡張仕様を実装することで、機能的差別化を図るという戦略を優先した。

そのため、Web標準とは異なるHTMLレンダリングエンジンが登場することになり、ユーザーに混乱をもたらすことにもなった。相次ぐ独自仕様の拡張は、ブラウザの安定度を低める結果にもつながった。

座談会ではブラウザ開発の年表を行きつ戻りつつ、ザッピングしながら、この間のブラウザ開発者の意図を推し計る議論が続けられた。

実装主義が切り拓いた、HTML5への道

ブラウザ戦争の裏側ではHTMLの標準化作業が進んでいた。
HTMLの標準化作業は当初はIETFで進められていたが、94年にW3Cに設立されると、W3Cは手探りで独自の標準化プロセス運営方針を確立していった。

W3Cで最初に策定された仕様であるHTML3.2でも、次いで策定されたHTML4.0においても、基本コンセプトは、当時の主要ブラウザが独自実装していた機能をできるだけ標準化することで、相互可用性(インターオペラビリティ)を確保することにあった。その目的を突き詰めたのが「実装主義」と呼ばれる標準化プロセス運営ルールである。

実装主義とはW3Cのプロセス運営ルールであるProcess Documentに定められた、「二例以上の独立した相互可用性のある実装事例の存在なしには、標準として認めない」という決まりである。

実際には二例というよりも、多様な企業が実装することで普及可能性が明確に見えてくる仕様のみが標準化プロセスを進んでいく。これにより、仕様提案者は自社以外の多様な企業や個人の実装を促す活動への取り組みを進めることとなり、ニーズに即した仕様が選ばれ、残ることとなる。

このようなメカニズムにより、実装主義は着実な技術革新を促す孵卵器(インキュベーター)になったのである。

▲深見嘉明氏(立教大学大学院ビジネスデザイン研究科特任准教授)

「97年12月にHTML4.0がW3Cより勧告された後にも、DOMとかXMLとかWebFormsの原型とか、20世紀のうちにさまざまな実装の試みがあった。こうした種まきの成果が2004年ごろに一斉に花を開いた。

実際のWebアプリケーションでのユースケースが増加し、普及していったことを実績を踏まえ、実装をベースにした標準仕様開発の提案が勢いを増すこととなった。その流れがWHATWGの設立にもつながっている」と深見嘉明氏は指摘する。

2004年に設立されたWHATWG(Web Hypertext Application Working Group)は、HTMLの開発やその関連技術に興味を持つ人々のコミュニティである。

W3CがHTML4以降はXHTMLへ注力していたため、それとは別にHTMLを発展させていこうと考えたWHATWGによって開発が進められていたWeb Applications 1.0やWeb Forms 2.0といった技術仕様がHTML5の源流となっている。

その後WHATWGとW3Cは共同でHTML5の標準化を進めるようになったが、HTML5仕様をめぐるW3CとWHATWGの間の議論は常に激しいものがあった。

そこにはWebというものについての考え方の基本的な相違があったと指摘するのは、清水智公氏だ。

▲清水智公氏(html5j Web プラットフォーム部)

「その頃のW3Cは、Webは宣言的なものと考える傾向が強かった。Webは情報のレポジトリなので変わらないし、変えてはならないというのがポリシーだった。だからサーバーサイドのプログラムで変更可能になってしまうようなHTML5の考え方は許せなかったと思う。Webが知識を集めるものだとすると、行き着く先は、セマンティックWebのようなものになるが、手続き的なものだと考えると、また違った方向になる」(清水氏)


「理論的に考えると、セマンティックWebのほうが、美しいとは思うけど」

「ただ美しいんだけれど、設計ができない。宣言的なものは設計を見せられないという弱点があって、頭のいい人が緻密に計画して設計しないとアプリケーションが書けない。型が強い言語の場合、設計をミスると取り返しがつかなくなるというのと同じですね」

「きれいな世界を描こうとすると、制約条件がでてきて守備範囲が狭くなる。セマンティックWebは推論して答えを出すのだけれど、その前提条件があらかじめセットしてあることが必要だ。その反対に、データの定義を曖昧にしておいたほうが、守備範囲が広がる。

どちらがいいというよりは、その両方の極端を振り幅にしながら、バランスをとっていくというのが、これまでの、そしてこれからもWeb技術の流れだと思う」

と深見氏が議論を整理する。

インターオペラビリティ確保のための苦闘

3時間に及んだ座談会の議論をすべて採録することは困難だが、ここでは終盤の方で、今後のWebブラウザのあり方をめぐって繰り広げられたトピックを2つ採り上げたい。

1つは、標準化とインターオペラビリティについて。


「WWWは標準技術とはいうけれど、他のハードウェアやネットワーク技術とは違う、ソフトウェアの標準化における特性を無視することはできない。

Web技術では、独自機能を搭載したメジャーブラウザであっても、可能な限り同じような形で動くことを前提にしている。だからこそ、ワーキングドラフトを詰めてラストコールされたからそれで確定というわけではなく、その後も実装と改善の出戻りはしょっちゅうある。

すべてのブラウザベンダーが一度で全部を正しく実装するなんて不可能だしね。それぞれの実装のインターオペラビリティを検証するのはさらに時間がかかるし……。

もちろん先に実装がないと何も進まないから、まずは実装事例を出してWeb上で使ってみて、後はアップデートしていけばいい、というのがWebの考え方」(深見氏)


「ブラウザベンダーが実装していく段階で、この仕様では実装できないということも実際出てくるしね」

「コンピュータはマシンコードで動くけど、これはコンピュータごとに違っている。それをどこでやっているかというと、今はWebブラウザがやっている。だからこそ、今日僕たちはずっとインターオペラビリティという話をしてきた。それを大事にしてきたブラウザだけが今も生き残っている、ということは言えると思う」

まさに、ブラウザの歴史はインターオペラビリティを追求する歴史でもあったのだ。

レイヤーの境界を越えて進化するこれからのブラウザ

さてそれでは、これからのWebブラウザはどんなカタチになるのだろうか。これが2つめのトピックだった。

Progressive Web Apps、WebRTC、HTTP2.0など検討すべき技術はいくつかあるが、それらを含めて、これからブラウザはどういう方向に変わっていくのか、と物江氏が問いかける。

▲物江修氏(日本マイクロソフト・エバンジェリスト)

「ブラウザを単なるバーチャルマシンだと考えれば、もっとコンピュータ技術的な意味での低レベルのこともやりたくなる。通信、キャッシュコントロール、ストレージを触ろうという欲望が出てくると思う。ネットワーク・レイヤーをコントロールするようなブラウザがいずれできるんじゃないか」


「ブラウザがネットワークをカバーするって、どういうこと?」


「例えば、リアルタイムコミュニケーションの通信のコントロールをしたくなる。パケットサイズを変えちゃうとか」


「なんでそこまでブラウザでしなきゃいけないの?」


「そこにブラウザがあるから(笑)」


「これもインターオペラビリティの追求ですよ。下層レイヤーを握れば、どれも同じ仕様で動かせるようになるから」


「まるで、Javaみたいだ」


「そう。昔、JavaのVMがやろうとしていたことを、今ではJavaScriptがやっている。だったら、Webブラウザが下のレイヤーの面倒を診るということがあってもいい、と僕も思う」


「今のコンピュータネットワークのアークテクチャは、レイヤーが積み上がった重層的なモデルなわけだけれど、レイヤーが増えていくと、次第に上のレイヤーが下のレイヤーの機能を食っていく、ということが始まるわけだね」

「ハードウェアがあって、デバドラがあって、さらにOSがあって、OSを仮想化するブラウザができてみたいな流れ。実は、マシンや通信のパフォーマンスを上げるためには、レイヤーを壊すほうがいい。レイヤー間の垣根がどんどんなくなっていく方向がこれからも見られると思う」

「仮想化だって最初はエミュレータにすぎなかったのが、次第にCPUやI/Oに直結するようになった。ブラウザもOSの上で動くアプリケーションだったのが、今はブラウザ自体がOSになっている。それが今度はネットワークをも支配するようになる」


「方向性としてはフル機能のブラウザOSが、PCのOSの機能をすべて代替する方向か、それとも小さくて安いチップに組み込んでばらまくというエンベディッドな方向、その2つが並行して進んでいくと思う」


「いずれにしても、ブラウザがすべてを実行するような存在になる。これはある意味、ロマンですね」

こうしてWebブラウザの技術革新とその未来が肯定的に語られたところで、座談会はようやく終了した。

時計の針はもう21時を回っていたが、出席メンバーの表情には疲れというよりは、まだ語り足りないというふうの興奮が冷めやらなかった。

前編「インターネットとWebの誕生が、いつか知ってる?」を読む

(執筆:広重隆樹 撮影:延原優樹)

カテゴリー : デジタル・IT タグ :
CodeIQ MAGAZINEの記事一覧をみる ▶
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。

TOP