連載インデックスへ

HTML 5が拓く新しいWeb（1. Google編）

ネイティブアプリ級のHTML 5に
グーグルが期待すること

新野淳一 Publickey
2009/8/21

新たなアプリのプラットフォームとなるHTML 5へのWebブラウザベンダの取り組みを聞くインタビュー。まずはグーグルに聞いた

　オープンな形でHTML革新を進めなくてはいけない　

　文書を閲覧するWebから、アプリケーションのプラットフォームへと、HTML 5の登場がWebを大きく変えようとしています。そのHTML 5について主要なWebブラウザベンダはどのように考え、取り組もうとしているのでしょうか。

　今回はグーグルのシニアプロダクトマネージャ 及川卓也氏と、ソフトウェアエンジニアの田村健人氏に、グーグル、特にGoogle Chromeに関連したHTML 5の取り組みについて話を聞きました。

――― グーグルは今年のサンフランシスコでのイベント「Google I/O」や、日本での「Google Developer Day 2009」でHTML 5について大きくアピールを始めていますね。グーグルにとってHTML 5によって立ち上がるWebの世界とは、どのようなものだと考えているのでしょう？

及川　今年、グーグルはHTML 5について大々的にメッセージを発信していますが、実は昨年からHTML 5といい始めていたんです。昨年のGoogle I/O、日本ではGoogle Developer Dayでは、クラウド、コネクティビティ、クライアントという3つのCが重要です、という話をしました。その中のコネクティビティに関して、現状では環境によって安定していなかったりオフラインになったりという状況に対する回答としてGearsを紹介しました。

グーグルのシニアプロダクトマネージャ 及川卓也氏　「数年後には、これはさすがにWebでは無理だと思っていたものが、HTML 5を中心としたオープンな技術で可能になるでしょう」

　そのときのGearsの方向性としてHTML 5で標準化を進めていきます、ということを明らかにしています。そういうところでHTML 5というキーワードを出していました。

　そのときから実はメッセージは変わっていません。WebブラウザのChromeを開発しているのもまったく同じ考えからで、これからのWebは静的な情報の発信／受信だけではなくてアプリケーションを利用する場になっていきます。現実に、多くの人がPCで利用するものといえばWebブラウザとメール。そしてメールもほとんどの場合Webメールを使うようになってきています。

　こうして多くの人がWebの上でビジネスや生活をするようになったとき、ネイティブのアプリケーションでできることと同じことがWebでもできる、というのが当然の姿ではないでしょうか。

　そのときに必要なのが、HTMLの革新です。それもオープンな形でイノベーションを進めなくてはいけない。これが昨年からいい続けてきたメッセージです。

　HTML 5のスペックではネイティブアプリはまだ作れない

――― Webでもネイティブアプリケーションと同じことができて当然になるだろう、と考えていると。

及川　まったくそのとおりです。

――― 同じことができる、という点については懐疑的な人が多いと思います。ネイティブアプリケーションとWebアプリケーションでは自由度や実行速度や表現力には差があるのではないかと。しかしそれらはHTML 5を基盤にして乗り越えられる、と信じている、ということなのですか？

及川　そうですね。「HTML 5」というときに、それは時にはバズワード的に使うときもありますが、狭義のHTML 5および、それを取り巻く技術やオープンなWebテクノロジというものを使うことで乗り越えられると考えています。

　グーグルにVic Gundotraという社員がいます。彼は以前マイクロソフトに在籍していたのですが、そのときはWebアプリケーションとネイティブなアプリケーションでできることは異なると考えていました。当時彼が注目していたソフトウェアベンダの1つにKeyHoleという会社があって、そこのアプリケーションでは画面の中で立体的な地球がぐるぐる動いてすごいなと。こういうものこそWebアプリケーションではできない、ネイティブアプリケーションなんだといっていたそうです。

　それがふと気が付くとKeyHoleはグーグルに買収されていて、さらにGmailも出てきて、どんどん彼の中で「ローカルしかできない」と思っていたアプリケーションの像が打ち破られていったんですね。

　似たようなことがこれから数年で起きると思います。つまり、これはさすがにWebでは無理だろうと思われていたものが、HTML 5を中心としたオープンな技術をWebブラウザが取り入れ、それをアプリケーションで使っていくことで可能になると。

――― そうしたHTML 5を中心とした新しい標準や技術の中で、グーグルが力を入れているものはありますか？

及川　まず技術がオープンであることが非常に重要だと思っています。また、例えばGearsでやっているようなオフラインの機能や、プロセスとスレッドやスケジューリングを実現するWeb Workersといったところを、皆さんの同意を得ながら実装と標準化を進めていく、というところですかね。

　O3D（Webブラウザで高速3Dグラフィックスを実現する技術　参照記事：Webの3Dグラフィックスが変わる?! GoogleのO3Dとは？）はまだリサーチ系の色彩が強いですが、 HTML 5のCanvasで2Dグラフィックスが実現できるようになったら次はやはり3Dではないかと思いますし、これも実装を進めていくのと同時に標準化を進めていく、というふうに考えています。

――― O3Dに取り組まれているように、HTML 5にもまだ足りない部分はたくさんあると思います。HTML 5に欠けている部分があるとしたら、どのようなものだと思いますか？

田村　個人的な印象では、いまのHTML 5のスペックではネイティブアプリのようなものを作るのには全然足りないと思います。いろんな方面のAPIや機能がまだまだ求められると思います。

グーグル ソフトウェアエンジニアの田村健人氏「個人的にはHTML 5でもできることが、まだまだ足りないと感じています」

　HTML 5に足りないこと

及川　まだHTML 5に入っていないスペックでグーグルがやろうとしているのが、contentEditable機能です。

　この機能を使うと、Webブラウザ上で簡単にリッチテキストエディタが実現できるのですが、現状では標準化が十分でないため、Webブラウザごとにかなり実装が違っています。例えばこれでブログエディタのようなものを実装したとして、テキストを選んで太字に変更したとします。ところがそれを別の種類のWebブラウザで開いて太字を元に戻そうとしても元に戻らない、という可能性もあります。

　で、いまはこういったWebブラウザごとの実装の違いに対応するため、JavaScriptを使って複雑なプログラムを書かなければなりません。ところがこれがちゃんと標準化されればわずか数行で済むのです。

　これについてはもうすぐスペックの提案が出せるんじゃないか、という状況にあると思います。

　ほかにも、Notificationと呼ばれるものを検討しています。これは例えば、Google Calendarのアラートが表示されるためには、WebブラウザのどこかのタブでGoogle Calendarを開いていなければなりませんし、ほかのタブで作業していたとしても、アラートが表示されると強制的にそのタブにフォーカスが移動してしまい邪魔に思うこともあると思います。

　こうしたWebアプリケーションからのお知らせ機能は、ローカルアプリケーションのようにアプリケーション画面からは独立した形がいいんじゃないでしょうか。これは標準化作業の前にグーグルでプロトタイプを作って、それを見ながら標準化を進めていきたいと考えています。

　それ以外に、例えばまだアイデア段階なのですが、やはりPtoPのようなもの。Webアプリケーションとして必ずしもWebサーバと通信するばかりではなくて、ピアで通信するもの、そういったものも必要ではないかと思っています。チャットのときなんかは、いちいちサーバを経由しなくてもいいかもしれませんしね。

　また、ドラッグ＆ドロップの機能もまだ限定されていますし、あるいはファイルのAPIのところ、ファイル選択ダイアログボックスの出し方なども検討する余地があるかもしれません。

　例えば、Webアプリケーションのチームがいま何を悩んでいるかというと、WebブラウザとWebサーバの間で、いろんなタイプのデータ通信が発生するんですね。リアルタイムのチャットの場合だと、短いデータをすごい勢いでやりとりする。その一方で、大量の写真をドラッグ＆ドロップした場合には大きなまとまったデータを転送する。いろんなグラニュラリティ（粒度）のデータアクセスといったものが必要になると思います。

　あるいは、Webカメラやマイクへのアクセス。いまはこのためにWebアプリケーションからFlashを使ったりしていますが、ローカルなリソースに対するアクセスもできるようにしたい。

　こういったところがHTML 5に含まれていないけれども、今後標準として具体的に提案していきたいなと考えているところです。

田村　Gmailでは、添付ファイルをアップロードするときの機能として、今年の3月ごろからFlashを使って複数のファイルを扱えたり、アップロード状況のプログレスバーを出すようにしたりと、かっこよくしたのですが、特定のブラウザのバージョンとフラッシュのバージョンでうまくいかない組み合わせがあったりして、やはりプラグインの扱いは難しいなと感じました。なので、ファイルの扱いの部分は検討したいですね。

　もう1つは、GmailやDocsのプルダウンメニューがありますが、あそこはブラウザの互換性を吸収するなどで数千行というコードを書いています。これはHTML 5にメニュー機能があって簡単に実装できるようになるはずなので期待しています。

　フォームでもインプットのバリデーションなんかがHTML 5では簡単にできるようになりますし。個人的にはメールアドレスのバリデーションがWebサイトごとにまちまちで困るのですが、HTML 5のバリデーションを使えば、type=emailと書けば済むようになります。

及川　Webフォームで半角カナで入れなくてはいけないところなどは、自動的にIMEと連動してくれればいいのに、と思いますね。まだ日本とかアジアの言語に優しくないといったところもあるので、そういうのも将来的にやりたいなあと思っています。IMEの連携などは、W3Cやほかのブラウザベンダと連携してやりたいなと思って話を始めようとしています。

　われわれの夢は、ローカルなアプリケーションと同じようなことがWebアプリケーションができること。オンラインでもオフラインでもすべてできるようになることです。そこに足りないものは実装し、標準化を進めていきたいと考えています。

――― そういう技術が普及するのにどれくらいの時間がかかると予想していますか？

及川　何をもって普及とするか、という点が難しいところですね。

――― 例えばGmailやGoogle WaveがHTML 5のテクノロジを使ってオープンにリリースできる時期、とすればどうでしょう？

及川　HTML 5が使われ始めるのはすごく早いと思います。いまGoogle Waveのチームと密にコミュニケーションを取っていますが、HTML 5のテクノロジをかなり早い段階から使い始めるのではないかと思っています。

　というのも、HTML 5を語るうえで一番重要なのは、一部の仕様から使い始められるんですね。Canvasなんかは多くのWebブラウザで実装済みですので、もうどんどん使ってもらって構わない。そういったものはここ半年とかで、すごい勢いで使い始められていくのではないかと思います。

田村　Gmailも、いま各ブラウザでストレージとかアプリケーションキャッシュ機能を実装し始めているので早速使い出しています。そういうふうに、あるものから使い始める、という感じですね。
 
及川　また、Canvasが実装されていないInternet Explorerでも、ExplorerCanvasというJavaScriptライブラリを使うことによって基本的な機能をほぼ使うことがでるようになりますし、Flashで使われていたようなベクトル型のグラフィックを可能にするSVGwebというJavaScriptライブラリもグーグルではサポートしています。実はほかにもあるのですが、まだ秘密です（笑）。

――― モバイルのことを聞いてなかったですね。いままではモバイルとPCは、それぞれ技術的には分かれた世界でした。しかし最近、特にiPhoneやAndroidの登場で、PCとモバイルで同じWebの世界を見られるようになってきました。今後はモバイルとPCのWebというものが技術的には同じものになっていくと思うのですが、その辺はどう考えていますか？

田村　そのとおりだと思います。AndroidやiPhoneが普及していけば、ケータイ専用Webというのはなくなっていくと思います。

及川　まったく同意見ですね。インターネットがデバイスによって分断されているというのは非常におかしいと思うんですね。その原因には技術の問題と、ビジネスモデルの問題と2つあったわけです。

　ビジネスモデルについては各キャリアさんやコンテンツプロバイダさんが考えることなのでまた別になると思いますが、技術による分断はこれから確実になくなっていくと思います。

　ただし制約はあると思います。メモリ容量やプロセッサパワーなどは、PCのように毎年向上していく、という状態には当分ならないと思いますし、キャリアが持っているバンド幅やレイテンシの中で考えていくことになると思います。そういう面では、モバイル用のWebブラウザとPC用がまったく同じ実装になる、ということは当面あり得ないでしょう。

――― 今日のお話を聞いて思ったのは、HTML 5の仕様と実装から見えてくるのは、やはりアプリケーションプラットフォームとして標準化されていくということなんですね。まるでWindows＋.NETやJavaVM＋Java SEのようにも思えます。

及川　そうですね。グーグルはそんなきれいな言葉ではいってはいませんが、Webがプラットフォームになってきている、もう「Webブラウザ」とはいわずに「Webクライアント」といわれるようになるかもしれません。それがプラットフォームでありインフラになろうとしている、というのはそのとおりだと思います。

　インタビューを終えて

　グーグルがWebブラウザをアプリケーションのプラットフォームにすることを目論んでいる、ということは、これまで誰の目にも明らかでした。しかし、その目標が「Webブラウザ上でネイティブアプリケーションと同じことを実現する」と、ここまではっきりと明言されたことには驚きを感じずにはいられません。しかもそれを、プラグインなどの技術ではなく標準仕様の上で実現するという手段まで明確にしています。同社がここまで明言し、リソースを投入している以上、恐らくそれはいつか実現されるのでしょう。となると残る問題は、「それがいつ実現されるか」に移ってきているのかもしれません。

■ ＠IT関連記事

デザイナーのためのWeb学習帳 Webを構成する技術を超初心者向けに説明します。まずは基本の基本である「HTML」から攻略していこう！ 「デザインハック」コーナー

D89 Web標準HTMLタグリファレンス Web標準に基づいたXHTMLタグの正しいマークアップ方法のリファレンス一覧です。Web標準のタグリファレンスを7回連載でおさらいします 「デザインハック」コーナー

WebデザイナのためのHTMLチューニング入門 Webサイトを見た人の印象を良くするのか悪くするのかには“速度”が大きくかかわってきます。FirefoxのプラグインYSlowで測る7つの計測ポイントから“速い” HTMLの書き方を学びましょう 「デザインハック」コーナー

Google Chromeの隠し機能を使いこなしていますか？ 本音のWebサービスガイド（3）　「起動や読み込みがすごく速いらしい！」と評判のGoogle Chromeを使ってみました。便利なアプリのショートカットや隠し機能なども紹介 デザインハック ＜ リッチクライアント 2008/10/21

Webブラウザ非互換性の温床となったのは何か？ AcidテストとWebブラウザの仕組み（前編）　IE8.0やFirefox3.0の出現で、注目されるWebブラウザ。いまこそ、復習しよう。Webブラウザの非互換性の発生源を探ろう 「リッチクライアント ＆ 帳票」フ ォーラム 2008/7/3

Webブラウザ標準適合性のわなとAcidテストの正体 AcidテストとWebブラウザの仕組み（後編）　1つのWebページを開くだけで100項目のWebブラウザの標準適合性が検証できるAcidテスト。Acidテストの正体に踏み込む 「リッチクライアント ＆ 帳票」フ ォーラム 2008/7/31

新野淳一（にいのじゅんいち）Publickey アスキーでリレーショナルデータベースInformixのテクニカルサポートを担当し、Windows Magazine編集部でnetPCを創刊、ASCII NT副編集長となる。フリーランスを経て、2000年にアットマーク・アイティの創立に参画、取締役に就任し、Webサイト＠ITの立ち上げを行う。2008年再びフリーランスとなり、2009年、WebサイトPublickeyを立ち上げる。

[an error occurred while processing this directive]

「デザインハック」コーナーへ

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