Googleの次世代ウェブ・プラットフォーム、Gearsについては、ウェブ・アプリケーションをオフラインで利用することだけが（あるいは主にそれが）目的だという誤解が広まっているようだ。事実は、Googleの野望はとてもそんなところに収まってはいない。Gearsのブラウザ拡張機能はそのような誤解をはるかに超えて多機能であり、広範囲な影響を与えるものだ。MySpaceが実装しているGearsはオフライン機能などとはほとんど無関係なのがなにより良い例だ。

Gearsが登場してまだ1年少々しか経っていない。最初のバージョンがリリースされたのは、2007年5月だった。バージョンアップの経過は ここにまとめられているが、要約すれば、Gearsには4回の主要なアップデートで順次機能の拡張が行われている。今年に入ってからも6月と8月にバージョンアップが行われている。

Gearsの全体としての目標は、ウェブ・アプリケーションにデスクトップ・アプリケーションと同等の機能を与えることにある。その手段として、さまざまな種類のOS（Windows、WindowsMobile、Mac OS、Linux）上のさまざまな種類のブラウザ（Firefox、Safari、IE）のエクステンションがサポートされている。Google独自のブラウザ、Chromeがリリースされたが、ChromeにはGearsがあらかじめインストールされているため、ユーザーは後からGearsをインストールする必要がなくなった。 これによってChromeは一種の「スーパー・ブラウザ」となっている。

Gearsというテクノロジーが長期的に意味するところは明らかだ。Gearsのような拡張機能の助けを借りて、ブラウザがますます強力になるに連れて、デスクトップ・アプリケーションをインストールする必要がますます薄れていく。（つまりWindowsとOfficeというMicrosoftの2大「金の成る木」が絶滅危惧種に転落する）。.

しかし、事態が本当にそこまで行くには、Gearsや同種のテクノロジーは現実にブラウザにデスクトップと同等の機能を与えることを実現する必要がある。（もう少し詳しくいえば、従来はブラウザの中だけで作動していたウェブ・アプリにデスクトップ・アプリ並の機能を与える必要がある）。

それでは、現状はどうなっているのか確認してみよう。現在、Gearsは以下のような分野でウェブ・アプリケーションの機能強化に利用できる。（デスクトップと携帯の双方で）。

• クライアント側でのデータベース管理 – ほとんどの対話的なウェブサイトは、サイト内で生成される情報とユーザー側で生成される情報の双方を収集、管理するためにデータベースに頼っている。現在、このデータベースはほとんど全ての場合、サーバ側に置かれている。ごく簡単な処理を除いて、なんらかの対話的処理を行うにはユーザー側から処理要求をサーバに送り、サーバ側で処理が行われるのを待つ必要があった。これに対して、GearsのデータベースAPIを利用すると、ウェブサイトはクライアント側（つまりユーザーのコンピュータ上）にデータベースを構築できる。これによって処理の実行速度をアップできる他に、オフライン機能も提供される。（サーバのデータベースにアクセスできない場合でも処理が可能になる）。
• クライアント側でのウェブ・ページ生成 – 簡単にいうと、Gearsは、サーバ側のウェブサイトにアクセスできない場合でもローカルに利用できる、ウェブ・サーバを設置することができる。このLocalServer APIを利用すると、ウェブサイト側ではオンライン状態の間にページのキャッシュをユーザー側に置き、オフライン状態でもサイトの表示を継続することができる。同時に、オンライン状態でも、キャッシング機能によって反応・処理を高速化することが可能だ。
• デスクトップ・ショートカット – ウェブ・アプリがデスクトップ・アプリのように機能するには、デスクトップ・アプリと同じように起動できる必要がある。そこでGearsでは、デベロッパーがウェブアプリのショートカット・アイコンを簡単に作れるようにしている。ユーザーはデスクトップやローンチ・バーにアイコンを置いてダブルクリックでオープンできる。従来もデスクトップ用のショートカット・アイコンを作ることは不可能ではなかったが、Gearsの機能を利用すると、ユーザーがアイコンを直感的な操作で簡単に設置することができるようになる。またグラフィックスの品質も高く、複数のサイズがサポートされる。また将来はアイコンに対話的機能が付加される予定だ。（たとえば、ウェブ・メールの場合、未読メッセージの数が表示されるなど）。
• 複数ファイルのアップロード – 現在、ウェブサイトに複数のファイルをアップロードしようとする場合、ユーザーはファイルを一つずつ選択して処理していく必要がある。（ウェブサイトがFlashやJavaベースのファイルローダーを実装していない場合）。Gearsを利用すると、ユーザーが複数のファイルを選択して一度にアップロードすることでき、手間と時間が大いに節約される。
• 位置情報の利用 – ユーザーの現在位置を知ることができる携帯デバイスの場合、Gearsはブラウザがこの位置情報を利用したアプリケーションを走らせることを可能にする。位置情報APIは、一回ごとに位置情報を利用することもできるし、ユーザーがあちこち動き回るのを連続的にモニタすることもできる。ユーザーの位置情報にアクセスするには、ユーザーの意に反したスパイ行為を防ぐために、特別の許可ダイアログが用意される。
• バックグラウンド処理 – 複雑なJavaScriptを利用したアプリケーションを利用していると、ユーザーは往々にして処理が終るまでかなりの時間待たされることになる。これに対して“WorkerPool” APIと呼ばれるAPIを利用すると、時間のかかる処理をバックグラウンドで実行させることによって、ユーザーのアプリケーション利用の体感速度をアップすることができる。その結果、ウェブ・アプリが固まる回数が少なくなり、きびきびとした使用感に改善される。

GoogleのGears開発チームはユーザーの声を反映して新たな機能を次々に追加してきた。ユーザーから要望されている以下のような機能も将来のアップデートで追加されるものと思われる。

• プログレスバー – 巨大なファイルを1個、あるいは小さいファイルをいくつもアップロードしているような場合、処理がどのあたりまで進んだのか知りたい場合がある。これまでは、ユーザーはカーソルがぐるぐる回ったり砂時計が動いたりしているのをじっと見ている以外方法がなかった。Gearsでは、データがサーバにどれほど転送されているか知ることができるようになる。
• ファイル転送の再開 – 巨大なファイルのアップロードが何らかの理由によって中断された場合、すべてご破算にして、一からアップロードをやり直す他なかった。Gearsではアップロードが中断したところから再開できる機能を追加するとしている。
• ライブのポップアップ表示 – GrowlやTwhirlのようなマイクロ・ブログ・ツールを利用しているユーザーは、何か新しいメッセージが投稿されるたびに、画面の隅にポップアップ表示されるのに慣れている。将来のGearsでは、どんなウェブサイトも、ユーザーがブラウザを開いていないときでもこういしたポップアップを表示させることができるようになる。（ただし、クリックすると送信者のウェブサイトに飛ばされるスパムがうるさくなりそうなので、メールの受信ポップアップ機能はユーザがオフにできるようにしてもらいたい）。

長期的にみると、現在われわれが使っている強力なグラフィックス・カードの能力を十分に生かすような高度な3Dグラフィックスのサポートも行われるだろう。また、ファイルを右クリックするとメニューにGearsを利用したアップロードのオプションが現れるようになる。ウェブ・アプリはOSの起動と同時に、あるいは（ネーティブなデスクトップ・アプリと同様）、OSの機能が許すかぎりさまざまな方法で自動的にロードされるようになる。

GoogleのChris Princeが去る5月にGoogleのI/Oデベロッパー向けカンファレンスで行った、Gearsに関する情報豊富なレクチャーのビデオを下にエンベッドしたので、時間があればご覧になるとよい。

Nik Cubrilovicの次世代ウェブについての記事も、現在熾烈化しつつあるプラットフォーム戦争を展望する上で有益だ。（ウェブ・アプリケーションの機能を強化しようと試みている大手テクノロジー企業はGoogleだけではないことに注意）。

[原文へ]

（翻訳：Namekawa, U）

6月の記事でブラウザおよびプラグインがHTML5のドラフト仕様で定義されているストレージ関連APIをどのように実装しているのかを見た。Gears、Opera、およびWebkitでは構造化ストレージAPIは採用しているが、HTML5仕様の他の部分についてはほとんど実装されておらず、未だ流動的な状態だ。HTML5はすべてのブラウザが採用するひとつだけの標準的マークアップ言語およびAPI群を定めようという壮大な試みではある。しかしマイクロソフト、Adobe、その他が独自の次世代ウェブ技術で鎬を削る中、ほんとうにHTML5標準を目にする日がやってくるのだろうか。

歴史から学ぶ

HTML5が対象にする範囲や標準化に向けての努力は、ひと世代前のHTML 3.0仕様を巡るものと比較することができる。1995年4月、HTML 3.0仕様はHTML 2.0への下位互換性を意識しつつ新機能を実現する設計を行った（テーブルタグ等）。W3Cは設立されたばかりで、HTML 3.0はW3Cの初期に生まれた仕様のひとつとなった。ブラウザ戦争はほんの少し先の話。Navigatorはリリースされて5ヶ月で既に80%のシェアを手中にしていた。これにはマイクロソフトも注目して、あわててInternet Explorer 1.0の開発を開始する。そしてわずか数ヶ月後にリリースされることになる。

影響は今日まで残っているが、1995年にはブラウザが異なればマークアップ言語も異なるという状態だった。Netscape 1.1では、他に先んじてテーブル、フローティングイメージ、およびナビゲーション用のエレメント（訪問済リンク等）を実装した。IEの最初のバージョンは裏技の集大成といった感じで「何が何でも表示する」という戦術をとっていた。つまりHTMLが不適切な場合でもブラウザ側で最適と思われる解釈を行って、とにかく何かを表示していた。IE側で誤りを補正してくれるので開発者が気を遣う必要がなくなり、これによってタグの不適切なネスティング（例：<b><p>Header</b></p>）問題が生じることとなった。

Internet Explorerのシェアは着実に大きくなり、Netscapeおよびマイクロソフトからはともに細かな改訂版がリリースされ続け、両ブラウザは徐々に別物となっていって利用者の側も両陣営に分かれていくこととなった。そこで以前はRFCの形で行われていたHTML仕様確定への動きがブラウザの互換性を保ち、かつ両陣営がそれまでに発表した新機能を正式に統合することが期待された。しばしばNetscapeおよびExplorerの両陣営が実装する新機能について、どちらがより正しく行っているのか大きな議論になることもあった。たとえばNetscapeとExplorerはイメージマップについて全く異なるアプローチを採用し、相互に互換性はなかった。またマイクロソフトは<top> や <bottom>など、ページ内の特定部分を指すHTMLタグを勝手に作ってしまうこともあった（これは後にNetscapeの非常に使いにくいframesetタグへと繋がった）。

ここでの問題は、新機能が勝手に野に放たれてしまったことではなく、マーケットシェア維持のためないしはウェブ界での主導権を維持するために、独自の実装を続ける2つの競合プロダクトが存在したことだ。最終的にNetscapeとマイクロソフトの両者はHTML 3.0を正しく実装することを放棄してしまう。たとえば、その際のNetscape側の言い分はこちら。

NetscapeはHTML 3.0をサポートし続けます。そのために安定的なものであれば提案段階のものも近々承認されることを見越して実装しています。Netscape Navigator 2.0は、一般向けのどのクライアントよりもHTML 3.0仕様を広くサポートしているはずです。

加えて、Netscape Navigatorには現行のHTML 3.0仕様には含まれていない新たなHTMLの機能分野についても、多く組み込んでいます。それらの機能は当然に必要なもので、標準化作業においてもそれらの機能が含まれるように提案を行っていきます。

マイクロソフトはHTMLの実装面では遅れを取っていた。

Netscapeはブラウザ市場で事実上の独占状態（ある調査によればシェアは90%）にあり、非公式ないし「拡張した」HTMLタグを採用することによりその地位を確固たるものにしようとしている。結果としてウェブページにはNavigatorで見ないとわけのわからない記号にしか見えないようなものが増えている。他のブラウザがNetscapeのタグに対応する前に、さらに独自のタグを加えていってしまう。

しかしこの状態は長くは続かなかった。マイクロソフトはこの手の競争に飽きてしまい、次のリリースではHTMLについて言及もせず、マイクロソフトの独自技術によって構築されたウェブを紹介している。

マイクロソフトのInternet Explorer 3.0はActiveX™技術を組み込んだ最初のインターネットクライアントで、インターネット上でよりインタラクティブなアプリケーション及びコンテンツを作成することができる。この技術を利用することでWorld Wide Webサイトをアクションゲームやマルチメディア百科事典、あるいは生産性アプリケーションのように優れたインタフェースを持つ、インタラクティブなものにすることができるのだ。ウェブサイトにも技術による制約から逃れ、制作者の想像力によってのみ制限を受ける時代がやってきた。

ブラウザ戦争はその初期段階において、HTMLタグのサポートを云々するところからから、優れたインタフェースを持つクライアントサイドアプリケーションを構築するフォーマットや言語を巡る争いへと移っていった。1996年8月に発表されるInternet Explorer 3.0に伴うJavascript（Netscape所有のクライアントサイドのスクリプト言語）とActiveX（マイクロソフト所有のオブジェクトコンテナ）間の争いもすぐそこまで来ていた。

マイクロソフトがブラウザ戦争に勝利し、またいったいどのように勝利したのかという興味深い話は歴史に残っている。ウェブの世界は大きく2つに分かれ、その波及効果として数千もの開発者がクロスブラウザの技やライブラリを生み出すのに膨大な時間をかけるという時代が十年以上続いた。マイクロソフトがブラウザ市場における支配権を徐々に確立し、ウェブアプリケーションの構築に独自技術を用いた多階層モデルを提唱したりもしたが、より簡単なHTML、JavascriptおよびCSSが勝利を収め、Web 2.0はActiveXの天下とはならなかった。

それから10年、駆け足レビュー

Netscapeが消えFirefoxへ引き継がれるという流れの中、ウェブ界での戦争はブラウザに限られたものではなくなり、新しいウェブプラットフォーム及びウェブ技術全体に広がるものとなった。ある調査によればInternet Explorerのシェアは78%への低下傾向を刻んでおり（2004年には95%だった）、Firefoxが16%、そしてSafari、Opera、その他が残りの6%を分け合っている。HTML 4.01は1999年12月に公表され、ISO標準ともなって主力ブラウザもこれをサポートした。HTML 4.01は現在にいたるまで質量面ともにもっともサポートされたHTML標準だが、論点はCSSやDOMアクセス等、ウェブ技術層の他の面に移ってきている。

数千ものウェブアプリケーションが、Web 2.0の名の下で、HTML、CSS、XMLを利用して構築されている。この3つの組み合わせは一般的にAjaxと呼ばれる（皮肉なことにAjaxのaとxの部分はxmlhttprequestにおけるInternet Explorerのアドオンとしてスタートしたものだった）。Ajaxアプリケーションは、すぐに現在の技術的限界に到達してしまったが、デスクトップアプリケーションとウェブアプリケーションのギャップを埋めるものだった。そしてAdobeのFlashやマイクロソフトのSilverlight等、いくつものベンダーがブラウザの上位レイヤーに位置するウェブクライアントのプラットフォームを提供し始め、開発者にもウェブアプリケーション開発用の、デスクトップアプリケーション並のインタフェースを備える開発環境を提供し始めた。これら新たなプラットフォームは既存ブラウザにプラグインを追加することで動作し、これら商用ソリューションが採用され始める中、現在のところはAjax以降を見据えたオープンソースやオープンな標準は生まれていない。

W3によるHTML5の進捗の遅れに苛立ち、ブラウザ開発グループはW3とは別に仕様策定を目指すWHATWGを立ち上げた。HTML5の最初のミッションは、ウェブの現状が最初にHTMLの仕様を定めたときとは大いに異なり、非常に複雑なインタフェースを実装し、さらに複雑なシステムの機能を利用できるようになっていることを認識することだ（Flex/FlashはMXMLを利用し、SilverlightはXAMLを利用している）。HTML5の新しい仕様を作成するのではなく、CSS2やDOM5、ECMAv4や新しいAPIコール（ローカルのブラウザストレージ関連等）などを含めて定義することを示すため、仕様はWeb Applications 1.0と名付けられた。

WHATWGワーキンググループの仕様は結果的（4年後）にW3に統合され、マイクロソフトも再び加わることとなった。Ajax後のリッチウェブアプリケーションプラットフォームを求める開発者に、取りあえずしばらくの間はマイクロソフト陣営にもAdobe陣営にも加わないで済む可能性を提供することになった。HTML5仕様策定の歩みは相変わらず遅々としており、マイクロソフトやAdobeによる独占に警戒感を持ったGoogleはGearsの開発に踏み切った。Gearsは現状のブラウザにHTML5風の機能を持たせるためのGoogle流のやり方だ。そしてGmailやReaderに新たなAPIコールを順次実装することで、Gearsの普及を試みている。

Appleもインターネット上のリッチアプリケーションを実装するためにHTML5に代わるオープン技術を採用している。数年前までAppleのホームページにいくとFlashとPDFファイルばかりが目に付いた。しかし現在は自身でオープンスタンダードのSafariブラウザを所有し、Webkitというオープンスタンダード技術を採用しようとしている。またウェブサイトやアプリケーションで独占的技術であるFlash等に代えてAjaxの利用を推進し始めてもいる。

1996年に戻って、HTML5がHTML 3.0の繰り返しであることを見てきた。しかし今回は2つのブラウザベンダーの争いではなく、非常に多くの人々が新たなAPIや仮想マシンの行く末に注目している。1990年代の争いでは、最終的にはオープンスタンダードが勝利を収めた。それでマイクロソフト及びAdobeの双方ともプラットフォームの一部分についてはソースコードやAPIの詳細を公開するようになっている。

ウェブの歴史を振り返ると、勝者は通常ひとりだけであることを教えてくれる。勝利をおさめたひとつが標準となり、徐々にユーザを集めて標準としての地位を獲得する（今日のいわゆる標準の多くが、最初は独占的技術であったことを思い起こして欲しい）。Windowsオペレーティングシステムが標準の地位を占めることと、HTML5のようなオープンスタンダードが標準として存在することの間には大きな違いがある。GoogleやAppleはWindows的標準の再来をもっとも恐れているのだ。

前回のローカルなブラウザストレージに関する次世代ウェブの記事はこちら。

［原文へ］

（翻訳：Maeda, H）

グーグルがGearsを立ち上げたのは昨年5月。リリース1年目は、Webアプリをオフラインで使いたい一部デベロッパーとユーザーが利用する程度のマイナーでニッチな製品と思われた。

きっとみなさんも当時こんな議論があったのを覚えているのではないか。「オフラインのアクセスなんて誰が要るの？」、「どのみちどこでも接続できるわけだしね」、「こんなの、対応するアプリだってロクに揃わんだろう」などなど。

グーグルがエースのカードを切ったのはそれから1年後。この何週間か前になってからだった。：MySpaceメッセージがGears実装で超高速になった。そう。Googleは新Web APIプロバイダのレースに参入していたのだ。そしてこの1年の間ほとんど誰一人としてそれに気づかなかった。

未来のブラウザはバーチャルマシンになる公算が高い。バーチャルマシンがほぼ全アプリをホストする。このシナリオが現実になればOSは透明になる。従ってマイクロソフトに死守すべき牙城を抱えていることになる（＝自社利益源）。今最も広く普及し、堅実なWebバーチャルマシンをFlashで提供しているアドビにしても、それは同じだ。グーグルはマイクロソフトを標的に危害を加える計画を秘密にはしていない。それを実行に移す最善の道が、レイヤーを上に動かし、ブラウザを標準の、しかしパワフルなアプリケーション用バーチャルマシンに作り変えることでOSを骨抜きにしてしまうことだというのも、彼らは知っている。

GearsがWebアプリの機能をどう変え、どう加速するのか。これをレビュー記事でお伝えするのは難しい。ブラウザベースのJavascriptの時は、MySpaceの機能、例えばメールのリスティングやソート、友だちリストのフィルタリングなど含め、とても遅く感じられた。ブラウザがサーバーに複数のリクエストを出すと、砂時計が回りっ放しのままロード表示バーがフリーズしたりした。それがGearsをちょっとの時間でさっとインストールして、確認をクリックし、ロード時間数秒待つだけで、どうだろう。それまでは使ってるこちらまで発狂寸前だった同じ機能が、あたかもブラウザの一部みたいな感じで使えるのだ。 グーグルはGearsができることが何か、このMySpaceで見せつけた。これで俄然みんな残らずこの製品に込められた本当の意図に目覚めた。「これはもはやオフラインのブラウジングなんて代物ではない。アドビとマイクロソフトに直接狙いを定めた一撃なのだ」と。

最後に僕が数えた時には、グーグルのWebベースのアプリケーションスイートには計28種のアプリがあった。どれも世界中の何百万人という人々に利用されている。彼らがウェブアプリ実行で使う技術は常に標準ベースのHTML、CSS、Javascriptである。単にベストなソリューションでいいならAjaxを選ぶことも考えられそうなものだが、なにしろ他のWeb開発技術のスタックはほぼ全て直接のライバルが製作・コントロールしているので、むしろそちらの懸念の方が大きいのだろう。

グーグルはオープンソースのWebブラウザ「Firefox」の開発を強力に後押しし、自社が選ぶ技術スタックとしてオープンなWeb標準もサポートしてきた。その理由は単純で、自社のWebアプリケーションがこれに依存していたからだ。Firefoxが軟弱ではインターネットエクスプローラ（IE）の復活を招き、引いてはWebの支配をマイクロソフトの手に戻す結果に繋がりかねない。

前はWebアプリがブラウザベースのJavascriptだけで走っても、グーグルにとって特に問題はなかった。しかしそれも競合他社が1歩踏み込んで各自個別の第2世代WebプラットフォームをFlex/AIRとSilverlightというかたちでリリースするまでの話だった。　マイクロソフトとアドビはこれでデスクトップライクなインターフェイスと機能を打ち出し、Webベースのアプリに実現可能なものという面で、大きな1歩を踏み出した。大手も中小もライバルはこぞって（グーグルに）競合する技術プラットフォームを使って競合するアプリを作るだろう。そうすればGoogleアプリスイートはまるで1990年代で時間が止まった過去の遺物のようになり果てる。そうなるのは時間の問題だ。

グーグルに残された選択は明白だった。：ブラウザベースのJavascriptおよび標準の開発を投げ出して新技術のうち一つを採るか、あるいはこれにしがみつき、他社に対抗しうるオルタナティブになるところまでコアのWeb技術を育てていくか。グーグルにとって差し当たっての問題は、新標準も発表され、計画ではリッチなWeb技術をすぐ実現できるブラウザ機能もあるのはいいんだが、こうした標準の開発の進捗が遅く、広い普及を見るまでにまだ何年もかかりそうなことだった。その点、新HTML標準「HTML5」なら、プロプリエタリのランタイム追加の必要性抜きにネイティブのブラウザ内でWebアプリのケーパビリティが拡大できることを特に目指したものなので、これと同じ機能に他の機能を加えたらそれで新たなGoogle Web APIの基礎固めができる。

標準開発作業の遅れが、よりベターで、より高速な、それでいて無料＆オープンなWebアプリ開発への道を塞ぐ中、グーグルは独自にその市場に参入することを決断した。Google Gearsを通してね。アイディアはシンプルだ。「明日のWebテクノロジーの機能を今のブラウザで提示すること」。　具体的な機能の大半は、標準化団体が何年も費やして開発した新HTML5の仕様規格から取った。彼らが製作着手するのを手をこまねいて待つ代わりに、グーグルは単にプラグインでブラウザを拡張しながら可能な限り最善を尽くし、これを実装した。自社Webアプリを、FlashとSilverlightに反抗する恐れもあるリッチな次世代標準で走らせるとなれば、短期的には標準を犠牲にすることになる（つまり“考えるのは後回し”ということ）。

Gears開発を担当するのは、グーグル内部のオープンソース団体に属する30人かそこらのデベロッパーだ。皮肉なことに、グループを率いる長のVic Gundotra（写真）は、グーグル入社前マイクロソフトでデベロッパーエバンジェリズム（開発者啓蒙）をリードしていた人である。この少数精鋭のデベロッパー集団が、Javascriptおよびオープンブラウザ・バーチャルマシンにおけるグーグルの利益の選抜・温存を手がける。 マイクロソフトとアドビは各々、湯水のごとくプラットフォームに予算を注ぎ込んでいる。書類上は、大手グループに軍事力・予算ともに敵わないように見える。そこでグーグルは自社の置かれた状況に弾みをつけようと、Gearsをグーグル本体から切り離し（文字通りの意味でも。－本プロジェクトの名前も“Google Gears”から単なる“Gears”に改称となった）、オープンソースライセンスのもとコード公開に踏み切った。

最初のリリースでは、HTML5で提案され、最重要と見なされてきたいくつかの機能にフォーカスした。つまり、クライアントベースの構造化データとオブジェクトストレージだ。このように最初に実装するものにクライアントストレージを選んだことで、Gearsは続く年のオフラインのアプリケーションソリューションという枠組みで世間には見なされた。意図したものではなかったにせよ、結果的にはこれで競合他社がもっと大きなゴールに気づけなかった可能性もあり、その点ではグーグルに非常に有利に働いたことは確かだ。グーグルなら自社独自のブラウザを開発し公開することもできたし、まさにその通りの未確認情報や噂もブログに出回った。が、ブラウザ市場は競争が激しく、退屈で、総じて厄介なものだ。しかも、新ブラウザ開発完了後もユーザーをブラウザ導入に誘導しながら、市場規模がクリティカルマス（全体に影響を与える人口）に達するまで待たなくてはならない。そこまでやっても相変わらず市場の残り70%、80%、下手したら90%は「Googleのブラウザは使ってくれないのにGoogleアプリだけは使いたがる人たち」ということだって充分考えられる。

むしろ一番の近道は、こうしたブラウザを一跨ぎに飛び越えて、その上に新たなレイヤー…つまりGoogleのWebレイヤーを追加することだった。人気ブラウザはどれも、デベロッパーがブラウザ機能を拡張できるメカニズムを提供しているので、グーグルは単に各ブラウザ対応プラグインを開発するだけで良い。　これならユーザーにわざわざブラウザ乗り換えを頼まなくても、自分たちの新Web APIを下手すると100％のブラウザにも実装が可能だ。何よりも重要なのは、ブラウザ市場に参入するより迅速かつ面倒のない方法でそれが実現できることだった。このプラグインを入れると、HTMLのレンダリング、インターフェイス提示、ユーザーオプションといった退屈な部分はすべてブラウザがやってくれて、その間、グーグルは既にそこにあるものをレバレッジして猛ダッシュをかけていける。

今やGearsはたくさんの新機能をサポートしている。中にはマイクロソフトやアドビの次世代Web API推進事業と共通のものもあるし、自社独自の技術革新の成果も。 デベロッパーに入手可能なファンクションコール（関数呼出し）には、バックグラウンド処理（砂時計アイコンよ、さようなら）、クライアントサイドの画像修正（処理）、位置認識、より優れたファイルアップロード、ブラウザ内ローカルデータベースなどある。

新APIと開発プラットフォームの採用には2つの面がある。 ひとつはユーザーサポートで、今回の場合それを受けるにはプラグインのインストールが必須だ。もう片方はデベロッパーサポートだが、Gearsではこれがこの上なく簡単にできる。アプリは他のアプリ同様、ブラウザベースのJavascriptを使っているので、サポートと言ってもただブラウザ内でできることをもっと沢山デベロッパーに提供するだけでいいのだ。JavascriptとWebのデベロッパーには新しく学ばなくてならないことは何もない。ユーザーとはプラグイン1個の隔たりがあるだけだ（バンドルの契約が出てくるのは必至だが、それさえも妨げにはならない）。　普及が行き渡り、デベロッパーも自信をもってターゲットにできるところまでなるのに、Flashは5年か6年かかった。Googleの応援もあってそれだ。Gearsならその半分もかからないかもしれない。

この競争では、グーグルに失うものは何もなく、得るものは山とある。グーグルはたった一発のショットで、標準ベースのオープンソースなオルタナティブの新Web APIを大変な初速でスタートさせた。競合他社と違い、グーグルにはプラットフォームを支配することにも、そこから直接利益を得ることにも関心がない。彼らが追求しているのは、むしろ今あるステータスクオー（体制）を維持していくことだ。：ブラウザのJavascriptで大体のアプリが使えて、それでちょっと足りない時はFlashか別の手段を使う―。

最後のプラットフォーム戦争から随分長い年月が経ったが、テクノロジーにこれが起こる時は決まっていつも、最も大きな企業が陥落し、最も小さな企業が栄える下克上が見られる。この方程式にオープンソースを加算したところで「一社単独で独占できる企業が皆無」という結果に変化は起こらないかもしれない。が、これだけ多くの物事の行方を左右し、これだけ大きな企業が絡んでいることだけに、戦いは確実に長期化の様相を呈するだろう。Webを次段階に進めるグーグルのアプローチは果たしてうまくいくだろうか？　それを教えてくれるのは、時だけだ。

（本稿は、次世代ウェブを説くNik Cubrilovicの連載特集の一部です。他のシリーズはこちらでどうぞ）

[原文へ]

（翻訳：satomi）

次世代ウェブが加速しはじめている。今週、MySpaceがGoogle Gearsを統合し、Yahoo! が新製品BrowserPlusを発表、Googleはブラウザー版の3D Earth製品を公開した。テクノロジーと規格についても、AIR、Silverlight、JavaFX、Gears、XUL、Web Applications 1.0（DOM5、HTML5等）などが揃い、開発者たちはAJAXの先へと加速され、高性能、多機能でデスクトップと密に連携した新世代のウェブアプリケーションへと導かれていく。

今、開発者とユーザーはともに、以前にはなかったウェブ技術の選択肢を与えられている。さまざまな会社がそれぞれに「次世代ウェブはこれだ」と見せつけるにつれ、「DLL地獄」は「プラグイン地獄」に取って代わられた。しかし、ウェブではこうした選択がユーザーと開発者双方にとって負担となる。ウェブのフォーマットを巡る最初の戦いから10年以上が過ぎた。当時はMicrosoftや、Netscape、Apple、AOLなどが、ブラウザーやスクリプト言語、ウェブサーバー等の形でさまざまな基盤を作った。あの戦いの遺産は今も感じられる。Javascript開発者たちは、ブラウザー無依存のコードを書くためにまるまる ライブラリーに依存し、CSSの開発者は、異なるブラウザーでもサイトが一貫性を保つようにと一連のハックに頼っている。

新しいリッチウェブアプリケーションの技術が未だに発展段階にある今なら、過去の失敗を繰り返すことなく、標準に沿ったアプローチを取れるチャンスがある。ありがたいことにこの10年間で、Microsoftをはじめとする各企業に、以前よりもオープンスタンダードを受け容れる下地が出来てきた。オープンスタンダードの支持が広がることによって、技術はユーザーにとっても開発者にとってもわかりやすいものになるが、たとえば上に挙げたような現在公表されている技術がみんなそうであるかどうかはわからない。

ここTechCrunchの一連の記事を通じて、われわれは次世代ウェブを構成するさまざまな要素に目を向け、その選択肢や現状のサポート、どこまで標準に準拠しているかなどを評価する。MySpaceが最近、同サイトのアプリケーションがGoogle Gearsを使用すると発表したことを踏まえ、第一回ではブラウザーベースのローカルストレージとキャッシュを評価することにする。

ブラウザーベースのローカルストレージ

ウェブアプリケーションが普及してくるにつれ、ウェブベースのアプリケーションをローカルで走らせたいという要求が高まってきた。この種の最初の解は、ブラウザーのプラグインも、別アプリケーションも必要とせず、HTTP中のヘッダーがキャッシュされることを利用してオブジェクトをブラウザーのキャッシュに保存するというものだった。JavascriptライブラリーではDojo が同じ原理を使ってオフラインウエブアプリケーションのサポートを実現したが、ブラウザーに構造化データを保存する手段がないため、アプリケーションの範囲はきわめて限られていた（Dojoは現在、 Gearsをはじめとするさまざまなストレージエンジンの抽象化も行っている ― 情報提供：Dylan）。

2007年5月、GoogleはGoogle Gearsを公開した。ウェブアプリケーションがデータをローカルに保存し、ウェブアプリケーションがローカルで動作できるようにするための、ブラウザープラグインだ。Gears公開時、Google ReaderがGearsをサポートするように改訂され、Gearsのウリとしてオフラインでのアプリケーションアクセスが強調された。あまり知られなかったのは、Gearsがオフラインアクセスだけのものではないことで、主要な機能が3つあった。

• リソース（HTLMページ、画像等）のキャッシュ
• データベースの構造化データストレージ
• 非同期バックグラウンドワーカースレッド

この中で今回われわれが注目するのは、ローカルオブジェクトと構造化データストレージだ。Gearsはこの2つの機能をJavascript API経由で提供しているので、あらゆるウェブアプリケーションからアクセスできる。構造化ストレージは、軽量RDBMSで評判のいいSqliteが提供している。ローカルデータベースと組み合わせることによって、開発者はクエリや挿入を実行して新規データを登録するだけでなく、テーブル間のJOINなど複雑なSQLも実行することができる。Gearsを使ったアプリケーションを複数走らせることができるが、アプリはそれぞれ、ドメインベースのセキュリティーモデル（cookieとAjaxリクエストに似ている）のサンドボックス環境下で実行される。Sqliteは、Firefoxにバージョン2.0から組み込まれているが、APIはアドオンまたはFirefoxのコア部品からしかアクセスできない。Gearsのプラグインは、このギャップを埋め、クライアントスクリプト環境で利用できるようにする。

Gearsが公開される前から、ウェブ・ハイパーテキスト・アプリケーション・ワークグループ（WHATWG）がウェブアプリケーション1.0のドラフト仕様の作業を開始しており、そこにはHTML5の一部として構造化データストレージが含まれていた。同ワークグループの現ドラフト仕様には、ローカルデータストレージのアクセスおよびクエリのためのデータベースオブジェクト定義が含まれている。実装の詳細はベンダーに任されているが、APIは仕様に詳細に書かれている。Firefoxは、WHATWG仕様の同じストレージAPIの一部をブラウザーのV3.0に実装する予定で、現在プレビューリリースが入手可能だ。WHATWGの仕様の主なコンポーネントは以下のとおり。

• アプリケーションキャッシュ - ローカルのブラウザーキャッシュにオブジェクトを保存（およびチェック）するため
• navigator.onLine – ブラウザーがオンライン状態かどうかをチェックする（そして、必要に応じてキャッシュとローカルデータストアを使用する）
• ストレージインターフェースおよびイベント – sessionStorageのDOM属性経由で名前と値のペア保存するために使用する
• データベース インターフエース – ローカルデータベースへの接続に使用する。SQL（またはそのサブセット。使用するサーバーによる）、バージョニング、コールバック経由のエラーイベントをサポート
• スレッド化とコールバック – 複数のリクエストを非同期に、ローカルデータストアに送るため

ローカルストレージやキャッシュ、オフラインアクセスなどの実装は比較的容易だ。アプリケーションはまず、その機能がサポートされているかどうかを調べ、次に、バックグラウンドでユーザーデータを同期させることによって、ローカルキャッシュを構成する。アップロードでもダウンロードでもスレッドの実行中、ステータスを調べてユーザーにフィードバックすることができる（プログレスバー等）。ひとたびデータがローカルにやって来れば、開発者はローカルマシン上でデータベースクエリを実行することによって、飛躍的に性能を向上させられる。現在、多くのウェブアプリケーションが、ブラウザーをプレゼンテーションレイヤーとしてのみ使っている。たとえば、表計算アプリケーションなら、=1+1などの基本的な計算であっても、処理のためにサーバーと往復することがある。ローカルデータストアとクライアントサイドコードを利用すれば、開発者は処理とストレージをクライアント負荷分散できるとともに、スムーズなデスクトップライクな体験の提供が可能になる。

サポートの現在と将来

問題は、WHATWG仕様の大部分が、Gearsがリリースされた後に書かれていることで、このためGearsで使用されているデータベースとローカルサーバーは、WHATWG仕様と互換がない、少なくとも現時点では。期待できるのは、GoogleがWHATWG HTML5仕様のストレージ部分を全面的に支持すると表明していることで、これでGearsをインストールしたFirefox 3で動くアプリの開発者は、ネイティブの実装を使うか、Googleの実装を使うかを選ぶことができる。Googleはさらに、追加機能を提供することによって、開発者がHTML5の実装に加えてGearsをターゲットにし続けるインセンティブを与える（デスクトップショートカットなどの機能）。

ローカルデータストレージの他の選択肢、たとえばFlashローカルストレージは、WHATWG仕様と全く互換かない。WebKitの開発者は実にすばやくHTML5仕様のストレージ部分の実装も開始したことを発表した。現在毎日ビルドを入手できる状態なので、近いうちにKonquerorとSafariの両方でサポートされるだろう。Operaも同じような計画を発表しているが、実はHTML5とウェブフォームの実装に関しては他より先を行っている。Yahoo!のBrowserPlusはきのう発表されたばかりで、その中のローカルストレージサポートがWGの決めた仕様と互換性があるかどうかはまだわかっていない。

ローカルストレージは、新しいウェブAPIの主要な新機能であり、開発者はブラウザーに依存しない一貫性のあるサポートが可能になるだけではなく、Google Gears（既に利用可能）やYahoo! BrowserPlus（どう動作するかによるが）という選択肢も手に入れることができる。この議論の中で、ブラウザーのメーカーで1社だけ抜けているところがあるが、それはMicrosoftだ。MicrosoftはIE8の早期プレビューをリリースし、山ほどの新機能を発表したが、その中の多くは、CSSの改良やJavascriptのサポート（標準オブジェクトモデル強化）等、オープンスタンダードに基づいたものだ。大きな問題は、IE8が他のブラウザーベンダーと同じ仕様の一貫性のあるローカルストレージのサポートを行うかどうかだ。IEチームは、IE8がDOMストレージをサポートすると発表しているが、これはローカルストレージ仕様全体のほんの一部でしかない（即ち、上に書いたストレージオブジェクトのみ）。

現在と将来のサポートの概要

注：BrowserPlusの詳細がわかり次第、表の空所を埋める予定。Gearsは標準に準拠することを約束している。IE8は部分的サポートのみを表明。WebKitのナイトリービルドにはほぼ全機能が含まれる。FlashとSilverlightいずれもローカルストレージの一種を持っているがHTML5の標準APIとは異なる。

ブラウザーのローカルストレージのような新技術が、ここまで支持され、ほぼ単一の仕様が採用されるのはきわめて珍らしいことだ。Microsoftはまだ全面サポートを表明していないが、正しい方向に進んでいることは間違いない。また、Google GearsとFirefox 3のHTML5の実装が、ワーキンググループ仕様に沿っているのも心強い。ブラウザーの新バージョンが広く行き渡るまでにはしばらく時間がかかるだろうが、Google Gearsは現在入手可能であり、どの開発者も同じAPIをターゲットにしているので、今開発者は安心してGearsのストレージAPIをターゲットにしてコードを書くことができる。これは、少し前にはほとんどあり得なかったことだ。

ローカルブラウザーストレージとキャッシュに関して、オープンスタンダードが今の勝者だ。他のソリューションは、消えていくか、同じAPIを実装することになるだろう。

[原文へ]

（翻訳：Nob Takahashi）