NewsInsight

[Analysis]

進化するHTML 5、OS化するChrome

2009/07/13

　2009年5月末に米サンフランシスコで開催された開発者向けイベント「Google I/O」ではHTML 5が1つの話題だった。基調講演でグーグルは主要なWebブラウザで実装済みのHTML 5関連機能を紹介。WebアプリケーションのプラットフォームとしてHTML 5が確実に進化していることを印象付けた（関連記事）。

　基調講演のデモンストレーションだけで“おなかいっぱい”だった私は、個別に行われたHTML 5関連セッションは（動画リンク）、念のためにその場にいただけ。講演が始まっても原稿執筆にいそしんでいた。もうHTML 5の解説は食傷気味。講演内容は上の空だった。

　HTML 5の大きな機能追加といえばWebアプリケーションから利用できるローカルストレージや、スクリプトで生成・操作可能な2DベクトルグラフィックのCanvas、プラグインなしに動画プレーヤーを実現できるvideo/audioタグの存在が注目されている。ドキュメント関連では、従来よりもさらに意味的な構造をマークアップするための新しいタグ群や、意味情報をマークアップするRDFaの仕組みなどもWebサイト作成や情報検索といった用途では注目だ。

　こうした話であれば聞く必要はないと、私は講演内容に注意を払っていなかった。ところが、講演の中盤を過ぎて耳に飛び込んできた言葉の数々に思わず顔を上げた。HTML 5の枠組みで、ノーティフィケーション、P2P、Webカメラ、ドラッグ＆ドロップ、リッチテキスト編集のAPIを標準化するというような話をしていたのだ。極めつけは、質疑応答での次のようなやり取りだった。Webブラウザ内の複数ウィンドウ管理のAPIを標準化してはどうか、という聴衆の提案に対して「それは考えたことがなかったが、確かにいいアイデアだ」とグーグルの担当者が即答していた。HTML 5には、このまま行けばかつてデスクトップOS上のアプリケーションだけが利用できた機能が次々と取り込まれていきそうだ。

NaClでネイティブと遜色ない実行速度

　Webアプリケーションの応用範囲が広がる一方、ネイティブアプリケーションとWebアプリケーションのギャップは、今後ますます広がっていく。こう指摘するのはグーグルのエンジニアリング・マネージャで「Native Client」（NaCl）開発に取り組むブラッド・チェン（Brad Chen）氏だ。Chromeに搭載されるJavaScriptエンジンのV8は、競合ブラウザよりもパフォーマンスでも、多量のオブジェクトを扱ったときのスケーラビリティでも先行しているが、それでもネイティブコードより2桁遅い。その上、今のところSIMD系命令やネイティブ・スレッドがWebブラウザからは扱えない。

　これを解決するのがNaClだ（余談だがNaClは食塩、塩化ナトリウムの化学式。チェン氏はナックルと発音していた）。NaClはグーグルが2008年12月に発表したオープンソースプロジェクトで、主にx86バイナリをWebブラウザ上で実行できる仕組みだ。もともと研究開発プロジェクトとしてスタートしたたが、リリースから半年後の2009年6月には研究開発プロジェクトから開発プラットフォームへと昇格することを発表。すでにChromeのオープンソース開発版「Chromium」のコードにはNaClの統合を開始している痕跡が見て取れる。

　NaClではx86アーキテクチャ向けにコンパイルされたソフトウェアが使える。画像処理や自然言語処理、暗号、圧縮、コーデックの処理といった重たい計算をネイティブアプリケーションと同等の性能で行える。スレッド処理については、POSIXに似たスレッドプログラミングが可能なほか、インテル・スレッディング・ブロックスのような抽象度の高いスレッドプログラミングもサポートするという。

　NaClは、高いパフォーマンスが求められる用途での利用というほかにも、JavaScript以外の開発言語が利用できるということと、既存資産を活用できるというメリットがある。チェン氏が示したデモでは、Linux向けのH.264対応動画プレーヤーをNaCl対応としてWebブラウザで表示させるのに、約20行のコードしか必要なかった。同様にLinux向けのライブラリは、ファイルシステムにアクセスするようなものをのぞけば、ほとんど改変なくNaCl向けにコンパイルできるという。

　将来的には64ビット対応や、ARM対応を進めるほか、3DグラフィックスのAPIを標準化するO3Dプロジェクトとも協調することで、CADやゲームのようなアプリケーションもWebブラウザで開発可能となるという。ActiveXの再来のように見えるNaClだが、OSやブラウザに依存せずに動作することと、静的解析によるバイナリの安全性検査を事前に行う点などが異なる。

NaCl＋Web Workersで、Webアプリでもネイティブスレッド

　研究開発プロジェクトから開発プラットフォーム提供を目的とするとした6月の発表で目を引くのは、NaClをHTML 5で取り入れられるWeb Workersと結びつける提案をWHATWGに対して行うとしている点だ。

　Web WorkersはJavaScriptでスレッドプログラミングを可能とする新しいAPIで、特定のタブに結びついたスレッドだけでなく、複数のタブと通信するスレッドや、タブやブラウザと無関係にバックグランドで処理を行うスレッドをJavaScriptだけで実現できる。つまり、JavaScriptだけでネイティブのマルチスレッドプログラミングができるし、重たい計算処理が必要な場合にはネイティブのライブラリを活用できるようにもなるということだ。NaClに言語処理ランタイムを加えればCやC++だけでなく、Rubyのような言語処理系を使ったネイティブのWeb Workersも実現できる。

　「NaCl＋Web Workers」というモデルが、ほかのブラウザベンダにも支持されるかどうかは未知数だが、Canvasなどと同様に、グーグルはこれをオープンなWeb標準としてWebプラットフォームの一部にしていくつもりのようだ。

通信モデルにも変革

　冒頭に紹介したように、グーグルは今後もHTML 5に対してAPIの提案を続けるつもりだという。すでにAPIがほぼ固まって実装フェイズにあるHTML 5の機能に加えて、現在検討を始めている機能も多い。

　例えば、ユーザーが複数のタブを開いていて、タブが見えない状態となっていても、メールが届いたことをユーザーに知らせるような「ノーティフィケーション」の仕組みについて、プロトタイピングを行っているという。ポップアップウィンドウのようにUIをロックせず、なおかつ確実にユーザーの目にメッセージが触れるようにするには、どういう実装があり得るかを検討しているという。

　現在HTML 5関連技術として「Web Sockets」の策定が進んでいる。これはサーバ・クライアント間で双方向通信を行うための通信規格だ。現在のHTTPの枠組みではXMLHttpRequestやCometなど、不自然な形で実装する必要がある通信モデルも、Web Socketsを使えばシンプルに実現可能となる。Web Sockets、Web Workers、ノーティフィケーションをうまく組み合わせれば、サーバ・クライアントモデルで、今までとかなり異なるWebアプリケーションが登場しそうだ。

　Operaソフトウェアが発表したOpera Uniteと発想が似ているが、Webブラウザ間でピア・ピア通信を行うAPIも、HTML 5で検討中という。確かにIMのようなアプリケーションで、隣の席に座った人同士がサーバを経由するのは無意味で、APIのニーズがあるのは間違いない。

Webアプリに何が必要か？

　HTML 5の関してグーグルの立場はハッキリしている。HTML 5の講演で同社が繰り返すメッセージは、Webアプリケーションで何かできないことがある場合、それがなぜかといえば単にAPIがないからだというものだ。例えばUSBドライブに入った写真をダイレクトにWebサービスで開けないのはなぜかといえば、バイナリをまとめてアップロードするAPIがないからで、どうAPIを設計すべきか、UIはどうあるべきか、そういったことをグーグルでは真剣に検討し始めているという。リッチテキスト編集のために、なぜブラウザが毎回200KBもあるJavaScriptのコードをダウンロードしていて、しかも互換性がライブラリが乱立しているかといえば、それは標準APIがないからに過ぎない、とも指摘する。

　同様に、Webカメラやマイクが使えないのも、ローカルファイルをクリックしたときにWebアプリが開けないのもAPIがないからに過ぎず、こうした問題にもHTML 5で取り組んでいくという。ファイルタイプとWebアプリケーションを関連づけられれば、DOC文書をクリックして、「Google Docs」で開くこともできるようになるだろう。

　Webアプリケーション開発者が歯がゆい思いをしているところのすべてをグーグルは潰していくつもりなのだろう。すでに書いたように、Webブラウザ上で複数のウィンドウを開いたときに、特定のウィンドウをグループとしてまとめて扱ったり、特定の名前を持つウィンドウを指示したりといったデスクトップOSでは当たり前のAPIも、標準化・実装していく可能性がある。

　Chromeでは現在エクステンションの実装が進められている。エクステンションはJavaScriptとHTMLで構成する“ミニWebアプリケーション”をアーカイブして配布、インストールできるようにする仕組みだ。いまのところJavaScriptと聞くと、実現可能な機能が限定的に思えるかもしれないが、今後はネイティブライブラリ、2D・3Dグラフィックス、GUIライブラリなど利用可能なスクリプティング環境として、もっと注目されるようになるだろう。

Opera OSやMozilla OSは登場するか？

　グーグルが先週の2009年7月7日に発表した「Google Chrome OS」が話題を呼んだ。まだほとんど情報がないに等しいが、「（Webブラウザの）Google Chromeの自然な延長」と発表文にある。2010年後半という最初のバージョンは「高速に起動するLinux＋Chromeブラウザ」という順当なものになるかもしれないが、すでに書いてきたHTML 5やNaClの仕組みを徐々に取り入れていけば「次世代Webアプリケーション」のプラットフォームとして進化していくことになるだろう。

　本当の疑問はここからだ。現在グーグルが取り組むChrome OSというのは、「OS＋ブラウザ」という現在のクライアントPCのソフトウェア構成が「ブラウザOS」という世界へと進化する先駆的存在なのか、ということだ。Chrome OSに続いて「Opera OS」や「Mozilla OS」は登場するだろうか。

　Webアプリがグラフィカルでパワフルになり、ほかのサーバやクライアントと自由に通信できるようになるのなら、ネイティブアプリは不利だ。ネイティブアプリはOSやアーキテクチャへの依存性が高く、ネットワーク配布に向かない。インストールやアップデートの煩雑さもある。セキュリティ面でもバッファオーバーフローやスタック破壊といった問題が絶えない。ネイティブアプリは、実行環境を維持するためのメンテナンスコストが大きい。今のところ、そのコストは払うに値すると考えるユーザーが多いかもしれないが、Webアプリの開発・実行環境が充実してくれば、そのバランスが変わる可能性は非常に高い。そうなれば、Linuxベースの統合WebブラウザOSと呼ぶべきものがChrome以外でも登場するかもしれない。

　ユーザー体験という意味でも、Chrome OSのようなアプローチのほうが合理的な面もある。ブラウザだけを動かすのであれば、カーネルもウィンドウシステムも最小限にストリップダウンできるし、起動するデーモン数も抑えられる。発表文にある「新しいウィンドウシステム」がGUIツールキットを指しているのか、X Window Systemに代わる何かを指しているのか不明だが、もし後者なら、現在高速起動ソリューションとしてビジネス向けノートPCで採用されているDeviceVMのSplashTopのようなLinuxよりも、さらに高速な起動が実現するかもしれない。必要なセキュリティパッチやアップデートはバッグラウンドで自動的に行える。長らく噂されているオンラインストレージ「GDrive」の統合提供や、擬似的なシングルサインオン環境の実現も可能かもしれない。

　Webアプリケーションのプラットフォームとしてより進化したものがHTML 5。私はそういう理解でいたのだが、グーグルがHTML 5に盛り込もうとしていて、Chrome OSで実装を進めているものは、Webの進化系というよりも、旧来のデスクトップOSを置き換える野心的なプラットフォームであるように思われる。

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）