GoogleはモバイルOS分野では、AndroidでAppleのiOSと激しいシェア争いをしているように見える。そうした場合、一般的なソフトウェア企業は自社OSのアドバンテージを高めて、自社OS上でしか使えないサービスやアプリを強化する。ところが、Googleは積極的にiOSにも、自社のサービスやアプリを提供している。最近では、ChromeとGoogle+をiOSに提供した。こうした行動は、OSへのアプリの依存に立脚する旧来のソフトウェア戦略とは異なる。iOSにAndroidを喰われることは危惧しないのだろうか。

Sundar Pichai氏

　GoogleでChromeを統括するSundar Pichai(スンダー・ピチャイ)氏(Senior Vice President, Chrome & Apps, Google)は次のように答える。

　「我々は、(iOSとAndroidで)コンフリクトが起こるといった見方はしていない。同じクラウドアプリを、全てのプラットフォームに提供することこそ重要だと考えているからだ。GmailアプリはiOSとAndroidに提供され、今ではGoogle+やChromeも同様だ。全てのプラットフォームにまたがることが重要だと考えているため、iOSにも提供する。

　特に、ChromeはWebの基礎となるものだ。ハードウェアを問わずに、全てをクロスプラットフォームとし、どの国からでも、あらゆるものを使うことができる。これは、オープンプラットフォームで、我々のゴールは、その中で、できる限り多くのユーザーにリーチすることだ。Googleは常に、それ(多くのユーザーにリーチすること)をコミットしている」。

　Web企業であるGoogleは、Webによるクロスプラットフォームの強味を活かすことをポイントとしている。OSに縛ることを前提とした企業とは、姿勢が異なる。HTML5、CSS3、JavaScriptといったWebスタンダードの上のアプリは、クロスプラットフォーム/クロスブラウザで走り、GoogleはそうしたWebアプリの強味と勢いを利用している。

　ただし、Web企業は、クロスプラットフォームのWebの中で、自社の差別化を図る必要がある。そこが常にWeb企業にとって足かせとなる。差別化の最大のポイントは、言う間でもなくブラウザ自体だ。

　「Chromeでは、我々は3つのエリアにフォーカスした。スピードとシンプリシティ(簡素さ)、セキュリティだ。

　まず、我々は、高速なブラウザとしてChromeを開発した。これは大きな差別化になったと考えている。実際、高速なブラウザであることは、新興市場で大きな力となった。そうした市場では、低速なコンピュータと低速なネットワークしかなかったからだ。Chromeは、まず、成熟した市場より新興市場で急速に成長始めた。

　シンプリシティについては、私は、多くの人々はWebアプリを使うためだけにブラウザを使うと、考えている。複雑なブラウザは望んでいないはずで、そのためにChromeはできる限りシンプルに保っている。

　セキュリティについては、人々はそれほど明確に意識はしていないかも知れないが、我々はChromeをセキュアに保ってきた。バグを発見したら24時間以内にパッチを当てている。こうした組み合わせが、Chromeを成功に導いてきたと考えている」(Pichai氏)。

　先週このコラムで、“Webプログラミング対ネイティブプログラミング”という、プログラミングモデルの戦いの話を書いた。特に、ネイティブコード実行モデルで書いてきたプログラマーの側に、こうした対立の存在を意識している人が多い。そして、ネイティブ派がWebプログラミングで常に問題とするのは、プログラムの実行パフォーマンスだ。そして、Webプログラミングのパフォーマンスのカギとなるのは、JavaScriptのパフォーマンスだ。

　JavaScriptは、スクリプト言語で、Webブラウザにエンジンが組み込まれている。動的なコンパイルを行なうJavaScriptでは、ネイティブコードに対して、どうしてもパフォーマンスが劣る。そこで、WebブラウザはそれぞれJavaScriptを高速化することに力を注いでいる。特に、Googleは「V8 JavaScript Engine」と呼ぶ、ダイレクトなJIT(Just In Time)エンジンで、Chrome上でのJavaScriptを高速化してきた。しかし、V8で高速化手法をやり尽くしたため、JavaScriptは、これ以上の飛躍的な高速化は望めないのではないかという声もある。JavaScriptの高速化が鈍化すると、Webアプリの進化に影響する。

JavaScriptエンジンの高速化

　Pichai氏は次のように答える。

　「JavaScriptを、今以上に高速にする余地はある。過去にも大きくパフォーマンスをジャンプさせたが、今後も、再び大きなジャンプが可能だ。

　ただし、そのためには、スクリプティング自体の改革が必要だと考えている。我々が新しいスクリプティング言語『dart』に取り組んでいるのはそのためだ。(パフォーマンスの)次の大きな飛躍には、プログラミング言語そのものの革新が必要で、それが、dartだ」。

　dartはGoogleが昨年(2011年)発表した新しいプログラミング言語で、JavaScriptと同様にエンジンがWebブラウザに組み込まれることを前提としている。dartは、JavaScriptの代替であり、Pichai氏の言葉からも、Googleの「JavaScript→dart」という位置づけは明らかだ。

新しいプログラミング言語「dart」

　Googleは、そもそもスクリプト言語の互換性のために策定されて来た「ECMAScript」スペックでは、高速化が難しいと見ている節がある。そのため、船頭が多いECMAScript系とは別に、平行して新言語dartを開発したと見られる。Pichai氏の言葉からは、Googleがdartで次の大きなパフォーマンスジャンプを成し遂げようとしていることがわかる。

　しかし、dartの戦略には、Googleの基本戦略と矛盾するように見える面もある。GoogleはWebスタンダードの普遍性と勢いを利用しているが、dartは、当面はGoogleだけのソリューションとなる。もし、他社のブラウザがGoogleに追随してdartエンジンを実装し、dartが業界スタンダードになって行くという展開になるとしても、それには長い道のりが必要となる。

　もちろん、短期的にはdartのコードをJavaScriptエンジンに渡すクロスコンパイラで解決できるが、dartのそもそもの目的はパフォーマンスのジャンプであるため、それではdartの意味が薄れてしまう。Googleは次期JavaScriptである「Harmony」も推進しつつ、dartの浸透を図るという二方面戦争をしている。ここには、Webアプリの進化(スクリプト言語のパフォーマンスジャンプ)と、Webの理念(クロスブラウザで同じコードが走る)の間で苦しむGoogleの姿が見えるようだ。

　ちなみに、Googleは、サンドボックスでネイティブコードを走らせる「Native Client(NaCl)」も推進している。これも、ネイティブコードのパフォーマンスを、Webプログラミングの世界にもたらすためのアプローチと見ることができる。さらに、NaClでは、LLVM (Low Level Virtual Machine)バージョンの「Portable Native Client(PNaCl)」も開発されている。ハードウェアを抽象化するソフトウェア層は、現在、Webブラウザ(あるいはそれに相当する層)とLLVM(あるいは同レベルのランタイム)の上下2つのレイヤーに集約されつつあるが、そのブリッジも渡そうとしている。ただし、NaClもオープンソースとはいえ、今のところGoogleのプロジェクトであり、dart同様に他社を巻き込んだ動きになるのかどうかが見えない。

　「WebGL」は、Webプログラミングの世界に、シェーダプログラミングの3Dグラフィックスを持ち込んだ。Googleは昨年のGoogle I/Oでは、WebGLを強く打ちだし、ゲームをWebGLで書くように促した。

　しかし、WebGLには、普及に大きな壁がある。WebGLは、言ってみればシェーダコードをHTML5に埋め込むような仕様となっており、JavaScript中心のプログラマーにとっては、馴染みが薄いからだ。シェーダプログラミングについての知識がある程度必要で、一般的なフロントエンドエンジニア(Webプログラマー)に、新しいスキルを要求する。

WebGLへの対応

　そのため、WebGLを扱いやすくするための抽象化レイヤーを設けようという動きが起きている。典型的には、WebGLをカバーするラッパーライブラリを、JavaScript APIとして作ろうといった活動となっている。複雑なWebGLを意識せずに、JavaScriptで簡単にシェーダ3Dグラフィックスを扱えるようにしている。

　しかし、こうしたWebGLを抽象化する動きは散発的で、WebGLを牽引する企業の1つであるGoogle自体の動きが見えてこない。Google自体は、「O3D」と呼ぶJavaScript APIによるWebGLに対するラッパーのプロジェクトを持っているが、その位置づけが明瞭ではない。つまり、Googleが、WebGLをWebプログラマーに対して使いやすくしようとする公式な動きが見えない。

　そのために、Googleの下でWebGLが広く普及できるのか、疑問を抱く開発者も多い。コアなゲーム開発者にはWebGLが普及しても、その先に広がらない懸念がある。この問題について、Pichai氏は明瞭な見解を語った。

　「Google I/Oのキーノートスピーチで行なった『Cirque du Soleil(シルク・ド・ソレイユ)』のデモのように、我々はWebGLを使わなくても3D表現をできる方法を提示している。Cirque du Soleilのデモでは、HTML5とCSS3を使うだけで、イメージを3D的に扱えることを示した。この方法なら、Web開発者が、WebGLを使う必要はない。

HTML5の位置づけ

　しかし、WebGLが必要な開発者もいる。確かに、Web開発者は、WebGLにあまり慣れていない。しかし、OpenGLやOpenGL ESを扱ったことがある開発者にとってはWebGLは非常に馴染み深い。WebGLとOpenGL/OpenGL ESの間には、多くの親和性があるからだ。そうした開発者のためにWebGLも推進する。

　我々の見方では、3D表現を実現する方法は、HTML5/CSS3とWebGLの2つの道となる。2つの方法があること自体に問題はないと考えている。それぞれ用途が異なるからだ。だから、我々はWebGLのためにこれ以上の抽象化レイヤーを提供するプランは持っていない。WebGLを必要とする開発者には、そうしたレイヤーは必要ないと考えている」。

HTML5とCSS3によるCirque du Soleilのアプリ

　この説明からGoogleの方向性が明瞭に見えてくる。簡易な3Dと、シェーダレベルでの本格的な3Dプログラミングの2層に分けて、後者はWebGLにまかせる。WebGLの領域は、ゲームプログラマーなどの世界で、WebGLをより簡易に扱うためのライブラリは、当面は設けない。つまり、GoogleでのWebGLの位置づけは、一般的なフロントエンドプログラマーのためのものではなく、グラフィックスにある程度特化したプログラマーのためのものだ。この姿勢が、今後も継続するかどうかはわからないが、現状ではそうなっている。

　GoogleのWebGLに対する姿勢は、ハードウェア業界にとっても非常に重要だ。なぜなら、WebGLの後に、さらにWebCLが控えているからだ。WebGLがOpenGLのWeb版といった位置づけのグラフィックス用APIであるのに対して、WebCLはOpenCLのWeb版で汎用コンピューティング用APIとなっている。

　将来的には、ダークシリコンの制約から、GPUコアの用途の多くが、CPUコアからのオフロードになって行くという予想に立つなら、Webプログラミングモデル内で柔軟なGPUへのアクセスを可能にするWebGL/WebCLは重要となる。そして、CPUからGPUへのオフロードは、電力の制約がきついモバイルでこそ重要となる。つまり、Googleが切り開きつつある市場でこそ、GPUコンピューティングが求められている。Googleがこうした、ハードウェア側の変化にどれだけ気がついているかは、まだ、今の段階ではわからない。