株式会社キールネットワークス 技術最高責任者 加賀 誠人 氏
Web2.0というとCGM（Consumer Generated Media）等、ユーザーが参加するものと言われている。そういった面で、SNSを厳密にWeb2.0と呼んでいいのかどうかわからない部分もある。
その他、Ajaxに代表されるようなライトウェイトなインターフェース、Webブラウザで使えるもの、あとはAPIを提供することで、例えばGoogle MapsのAPIを使うと自社のWebサイトに地図を簡単に取り込めるとか、そういう形の連携もWeb2.0の特徴である。ここでは、Ajaxを中心に解説したい。
Ajaxで開発した「nuco」
最初に、キールネットワークスで開発中のnucoを紹介する。
Ajaxで開発したものだが、キールネットワークスでは敢えてSocialwareと呼んでいる。いわゆるSNSも含めた、個人がドキュメントを書いて、それをコラボレーションして、お互いにコメントしてブラッシュアップしていく過程とか、それをパブリッシュするためのプラットフォームとして考えている。
SNS的な機能も包含しているほか、ブログのアーキテクチャ、ポータルになる部分もある。ポータルと関わる部分で、いわゆるRSS Aggregationもある。既にWebベースのRSSリーダーがいろいろあるが、そういうものも内包しようとしている。
基本になる考え方は、ブラウザに依存しないユーザーインターフェースを提供したいということである。その最初の選択肢として、AjaxによるWebアプリケーションを作っている。今後は、普通のクラシカルなWebベースのXHTML＋CSSで作られたバージョンも考えているし、Apollo（講演時の呼称。現Adobe AIR）というプラットフォームでも積極的に展開していきたいと考えている。
サーバとクライアント間は、HTTPで通信しているが、やりとりしている内容はHTMLではなく、現状はXMLで実装している。これについてはいろいろなオプションがあるので、後ほど説明したい。
複数のSNSを１つに
nucoの画面部分はごく普通のWebのフォームになっている。ログインすると、Ajaxベースで書かれている部分になる。サーバからJavaScriptで書かれたクライアントで動くアプリケーションがダウンロードされて、描画される。
画面の左に履歴が出るが、そこで1回ページの推移が発生している。アドレスバーを表示すると、履歴が普通と少し違うことがわかる。最初にロードしたURLの後にハッシュで付いているURLで推移している。基本的には全部同じHTMLで動いているということである。 普通のWebサイトでページのソースを表示すると、画面上で表示されている内容が出てくるが、nucoで現状表示されている内容はHTMLのソースを表示しても出てこない。これがAjaxのアプリケーションの場合、かなり特徴的な部分になる。
その他の特徴としては、よくJavaScriptなどで書かれているドロップダウンメニューなどが実装できる。実際にはユーザービリティとかアプリケーションの位置づけを今後考えていかなければいけないが、従来のWebページとは違うようなユーザーインターフェースを既存の技術で実現できる。
nucoはSNSのツールではあるが、最大の特徴は複数のSNSを1つのnucoというプラットフォーム上で実装するという考え方である。例えば社内のコミュニケーションのSNSとパブリックなものがあった場合、社内では実名を使うが、パブリックでは匿名で参加するという形があると思う。そういうところで、SNSごとにプロフィールが変えられる。
Apolloへの対応
Apolloへの対応を考えている理由だが、普通SNSというと、基本的には日記とかコミュニティのやりとりでコメントを書いたりすると思う。現状のWebベースのサービスは、あくまでもオンラインの状態で書かなければいけない。書いている間はオフラインでもいいが、ワープロ等でローカルで書いたものを後でブラウザにコピー＆ペーストして送信するとか、ブラウザを開いたままにしてやるという形になると思う。
現状のnucoも普通のWebタイプなので、同じような形になる。例えばここで書いて送信すると、当然サーバとのやりとりがあるので、オンラインである必要がある。だがニーズとしては、例えば打ち合わせ先に行って、その議事録を取った後でnuco上にアップロードしたいというケースもあるだろう。
従来だと、エディタ等で書いたものを後で貼るとか、後でアップロードする必要があった。Apolloに期待しているのは、その部分を完全にオフラインの状態で書いて、後でオンラインになった時点で自動的にアップロードできるというところである。Apollo自体はFlash、Flexのアプリケーション以外に、Ajaxのアプリケーションも動くので、非常に期待している。
Ajaxの基盤技術
Ajaxは、Asynchronous JavaScript＋XMLの頭文字をとったものである。Adaptive Pathというアメリカのコンサルティング会社の人が名付けたということだが、その人が開発したのではない。もともと、既存の技術が幾つかあった。
まず、XHTML＋CSSというのは、現在のモダンブラウザ向けにWebサイトを構築する普通の部分である。
DOMは、現状、Web開発者から見て一番身近なものとしては、JavaScriptに組み込まれている。これはJavaScriptからHTMLにアクセスして新しい要素を動的に追加したり、削除したり、中身を変更するためのインターフェースである。
それだけではサーバとのやりとりができないが、XMLHttpRequestというものがJavaScriptで実装されており、JavaScriptの中からWebサーバにデータを送受信できるようになっている。サーバとのやりとりにはXMLを使う。
Ajaxのメリット
従来のWebページは、ページ推移とデータ通信が完全に一致していた。ページを表示している状態では、サーバとのやりとりは一切なく、次にユーザーが何かクリックしたり、フォームの送信ボタンを押したりした時点でまたサーバとの通信があって、そこでページも更新される。即ち、同期している。ところが、AjaxではAsynchronous（非同期）が意味するように、通信とページ推移が完全非同期で行われている。
もともと、サーバ間でいろいろ分散するテクノロジーとして、SOAPがあった。最近はCOMETというテクノロジーも出てきている。COMETはAjaxをベースに、よりリアルタイム性を上げた技術で、基本的にはAjaxと変わらない。
Ajaxのメリットは、より対応しているプラットフォームが広いというのが特徴である。Mozilla/Firefoxもあるし、Operaの場合はPCだけでなくSmart Phoneでも使える。ただし、Smart Phoneの場合は、JavaScriptの実装が限られているものも多いので、必ずしも使えるわけではない。
国内で普及しているW03（W-ZERO3）に乗っているOperaでも、結構動く。Wiiというゲームコンソールなどでもベータ版のOperaが提供されており、その上でも、nucoも含めてAjaxアプリケーションは動いている。SafariというMac OS上で展開されているブラウザ上でも動くし、Internet Explorer（IE）上でも当然動く。
Mozilla/Firefoxは同じレンダリングエンジンを使っている。Opera、IEはそれぞれ独自に持っている。Safariに関しては、Apple Web Kitが表示をしており、Apple Web KitをベースとしたWeb Kitというオープンソースの実装もある。Web Kitが今後普及していく部分というのはApolloにある。ApolloのHTMLとかAjaxの表示する部分は、Safariと同じくWeb Kitをベースに投入されてくると言われている。
実際にはそれぞれに対応するのは大変だが、その気になれば、少なくともPC上で動くもの、Windows、Mac OS、Linuxだけでなく、SolarisやFreeBSD等、マイナーなプラットフォームでも確実に動作する。
一部分のみを動的に更新
もう1つの特徴は、ページの一部分のみを動的に更新できる。例えばあるトピックの表示を切り替えた場合、従来はメニューからフッタからすべてダウンロードする必要があったが、更新された部分だけをダウンロードできる。
リンクをクリックして非常に長い時間かかる場合がある。そういうときはブラウザは一見固まっていて、IEでは右上のロゴだけが変化していて、とりあえず通信はしていることがわかる程度であった。それがアプリケーション側で実装することにより、「ちゃんとやっている」とプログレスメーターのようなものをユーザーに提示することもできる。
マウスのドラッグを使ってのユーザーインターフェースも提供できる。ただ、これに関してはローカルのリソースにアクセスできない。例えばデスクトップのファイルをドラッグ&ドロップしてアップロードするようなことはできないのが現実である。この辺りはApolloで変わってくると考えている。
ブラウザのナビゲーションで、例えばユーザーは「戻る」ボタンをよく使うが、その辺に注意を払わないでFlashのサイトが作られているケースが多い。「戻る」を押すと前ページに行ってしまい、ユーザーがアクションする直前の画面に戻らないことがある。
また、文字サイズを大きくする、小さくするというのもブラウザの機能としてあるが、Flashのアプリケーションは互換性がない。ブラウザで文字サイズを大きくしている場合でも、その辺は反映されないが、Ajaxの場合、基本的にはXHTMLとCSSで表示を制御しているので互換性がある。
既存のWebサイトとの違い
Ajaxと既存のWebサイトとの違いは、ページの推移と全く非同期ということである。ページの推移なしにコンテンツが変わっていく。
従来のWebの画面推移というのは、最初にHTMLが読まれる。それに続いてスタイルシートや画像が読み込まれてページが表示される。この場合、ページ全体がサーバからダウンロードされて表示された時点で、サーバとの接続は完全に切れている。ユーザーが何かアクションするまでは何も起こらない。例えばユーザーがリンクをクリックしてページ推移が発生すると、またページ全体をリクエストして、サーバから戻ってきてブラウザが表示する。その繰り返しになっているというのが従来のWebである。
Ajaxの場合、最初にページをリクエストする部分はブラウザベースなので変わらない。nucoの場合はログインフォームを含んだHTMLがダウンロードされる。見映えを決めるのにスタイルシートを使っているので、CSSも画像も読み込まれる。
最大の違いは、そこでJavaScriptのコードをブラウザに読み込むことである。以降の、ユーザーがリンクをクリックするといったイベントは、Ajaxエンジン（JavaScriptで書かれたブラウザ上で動くコード）のほうで処理をする。だからリンクがクリックされたら、そのリンクに必要なデータをサーバ側にリクエストして受信するということは、全てJavaScriptで書かれたプログラムが行う。
表示自体はいろいろある。XMLベースでやっている場合は、サーバから来たデータをJavaScriptで解釈して、DOMを使って、例えばテーブルを新しく生成したり、Div要素のようなものを新しく作って、その中身のHTMLを入れたりする。テキストの中に、例えばstrong要素があって強調表現があった場合は、DOMを使ってstrong要素をDivの1個下に生成し、そこの中身を設定するというような形で画面の更新をしていくということになる。
サーバとの通信
サーバとの通信に関しては、XMLHttpRequestオブジェクトというものがJavaScriptで定義されている。もともとはMicrosoftがInternet Explorerのために提供したもので、IE 6.0まではActiveXコントロールとして提供されていた。
これがないとAjaxはほぼ成立しない。JavaScriptからサーバにデータをやりとりする手段なので、これが非常に重要になってくる。
現状、Mozilla/Firefox、Opera等、主要なモダンブラウザと言われているものでは、全て組み込みオブジェクトとして実装されている。IE 7に関してもActiveXコントロールではなく、ブラウザ自身の機能として組み込まれる形になる。
通信自体はHTTPで行う。サーバ側は従来のWebサーバと、例えばnucoの場合はPHPでサーバ側のコードを書いているので、サーバのプログラマから見ると、今まではページ全体をHTMLなりXHTMLで返していたものをXMLで送ればいいというだけである。従来のWebアプリケーションの開発者から見ると、サーバ側に関しては今までのテクノロジーと特に変わらない。
実際、XMLHttpRequestを使ってどういうデータをやりとりしているか。nucoの場合は、XMLのデータで非同期にやっている。HTTPというのは、リクエストを投げると、それに対してデータがサーバから返ってくる。すぐ返ってくる場合もあるが、負荷が高いケースや重い処理の場合、当然、戻ってくるまで時間がかかる。
今までのブラウザの考え方だと、リクエストを投げて、返ってくるまでブラウザは黙って待っている必要があった。プログレスメーターを実装したいと思っても、そこでプログラム自体の実行が止まってしまうとユーザーは何もクリックもできないということになってしまう。
XMLHttpRequest
非同期で呼び出すことができると、リクエストを投げた時点でXMLHttpRequest自体、実行がすぐ完了してしまう。ブラウザはサーバにリクエストを投げた状態で、ブラウザ自体はサーバからのレスポンスを待っている。
非同期でやっていると、あるJavaScriptの関数を予め用意しておき、サーバとの通信の状態が変化したときにその関数を呼ぶように指定できる。この辺はブラウザによって違うが、それを使って「サーバにリクエストを送るのは完了した」とか、「データが返ってきた」というように、状態が変化するたびに設定したJavaScriptの関数が呼び出される。その中で、自分がやりたいことをする。例えばデータが返ってきたら、ある部分を更新するとか、そういうものを書くというスタイルになっている。
やりとりしているデータは、XMLだけでなく、テキストでもいい。XMLHttpRequestという名前だが、実際にはテキストデータであれば何でもやりとりできる。XMLというのはHTML、XHTMLと同じようにタグ付けしたものだが、その中から必要なデータを取り出すのはそれなりに重い処理になる。
JavaScriptの場合、DOMというインターフェースがあるので、例えばProductエレメントの下の、nameエレメントの値を取得するというのはDOMを使ってアクセスできるが、やはり処理が重い。
そこで、場合によってはサーバ側でHTMLを作って、それ自体をあるDivの中に流し込むような形で実装されるケースもある。また、JSONという、JavaScriptのデータ形式をテキスト表記したフォーマットがある。今のJavaScriptのエンジンだとテキストを基に、JavaScriptのオブジェクトが作れるというテキストの表記形式がある。それを使ってサーバから来たものをJavaScriptのオブジェクトに即座に変換する形で作られるケースもある。
JSONP(JSON with Padding)
JavaScriptなりの限界だが、XMLHttpRequestではドメインを越えられない。例えば、keel.netというドメインがあるが、www.keel.netにあるHTMLを読み込んで、そこからJavaScriptを読み込んできた場合、例えばここの部分は違う会社のサービスのサーバで提供されたデータを読み込みたいと思ってもできない。あくまでもJavaScriptを読んできたサイトの別のURLにしか、XMLHttpRequestでは通信できないので、他のサイトの中身を持ってこれないのである。
例えばサーバ側にプロキシサーバを用意して、それを経由して他のドメインのサーバへの通信は自分のサーバがブラウザとやりとりするというケースもある。こういうことが必要になると、なかなか難しい。
一部で使われているテクニックとして、JSONP(JSON with Padding)というものがある。これはHTML上にJavaScriptを埋め込むときに使うscriptエレメントだが、JSONPで表示しているページと違うドメインのURLを指定してもJavaScriptを読める。それを使って動的にscriptエレメントをDOMで生成することによって、オンデマンドに他のサーバにアクセスするようなインターフェースも使われ始めている。
Yahooローカルのサービスは、日本では提供されていないが、Yahoo.comのWebサービスとか、Googleの一部のAPIに関してはJSONPを使って、クロスドメインで、例えばnucoのページにYahooローカルの地図を読み込むとか、検索結果を読み込むようなことができるようになっている。
DOM
先述のように、Ajaxで表示内容を更新するのはDOMを使っている。DOMはXMLの部分を読み込んだり、フォームに書かれている内容を読み込んだり、中身を変更したり、要素自体を追加したり削除したりする仕組みである。
例えば、あるテーブル要素全体を削除したり、逆に新しくテーブル要素を作って適当な場所に追加できるようなインターフェースである。JavaScriptはDOMに対応した言語の1つという形になっている。
DOMは今表示しているHTMLだけでなく、サーバからもらってきたXMLのデータに関しても使える。XMLでサーバとのやりとりをする場合はDOMを使って送られてきたデータを解釈するという形になる。
例えば、Firefoxの機能でドメインスペクターというものが入っている。これを見ると、今表示しているドキュメントの階層構造がわかるようになっている。HTMLの場合、HTML要素が１番ルートにあって、HEAD、BODYがある。HEAD要素にはタイトルがあり、BODY要素があるという形で、DOM自体は階層構造で表現している。
実際のnucoの通信内容を見ると、イメージがよく伝わるかもしれない。Firebugという、Firefox用の拡張機能があり、表示しているもののDOMの構造とか中身が見られるような形になっている。
ブラウザのソースを見る機能では、この辺に対応したソースは表示されていなかったが、ツールを使うことで、動的に更新されている中身を見ることができる。Ajax以外のWebサイトでも有用なツールだと思う。例えば、「コメントされたエントリー」というインライン要素があるが、そこに適用されているスタイルシートが何かというのも同時に表示される。
Webサイトは複数のスタイルシートのファイルを使っていると思うが、条件によって上書きされたりするので、最終的にどこの部分のスタイルが使われているのかはわかりにくい。こういうツールを使うと、現実にどのスタイルが有効になっているかがわかる。
Ajaxの課題
Ajaxで陥るポイントとして困難なのはブラウザの互換性の問題である。例えば、「戻る」ボタンを実装したがSafariだと動かないとか、いろいろな問題がある。
もう1つは重さである。動作の軽さ自体も、ブラウザごとに違う。Operaではやや実行が重いというところがある。それについて解決策の明確なものはない。バラ色の世界ではなく、課題は大きい。MicrosoftがIEだけをターゲットに開発環境を提供するというのは理解できる部分でもある。
また、開発環境、デバッグ環境の整備が必須である。ブラウザ1本とエディタ1本ではやはり厳しいというのが現状である。ブラウザ本来のナビゲーションと矛盾なくやるというのも課題である。「戻る」ボタン、履歴というのは、何も考えずに実装すると、同じURLで常にやりとりしているので、履歴に残らない。それなりに実装されているnucoも含めたAjaxの実装例では、JavaScriptから履歴を作り出すことによって「戻る」ボタンのナビゲーションとか、そういうものを実現しているのが現状である。
マウス操作やキーボード操作も基本的にJavaScriptで全部処理できるので、やり方によってはユーザーが期待しているブラウザ本来のキーボードショートカットとAjaxで作ったアプリケーションのショートカットがぶつかってしまうとか、そういった問題もケアすることが必要になる。
フレームワークと履歴
開発現場で1から作るのは結構大変なので、幾つかメジャーなフレームワークというか、一種のライブラリを紹介する。有名なのはPrototype.js、script.aculo.usだが、ほかにも大量のフレームワークがある。
こういうものは、ある程度ブラウザごとの差を吸収してくれる部分がある。XMLHttpRequestに関しても、IE 6だとActiveXコントロールになっているので、呼び出しをそれ用に書かなければいけないが、この手のフレームワークは予め決められた形で呼び出すとブラウザの差を吸収して、後は同じようにやれるようになっている。 もちろん、必ずしも既存のフレームワークを使う必要はない。1から書くことも可能ではあるが、ライセンスと自社の開発ポリシーに問題がなければ、こういうものを使ってもいいだろう。
サーバ側は、従来どおり、PHP、Perl、Javaなどでアプリケーションを作っていくという形になる。
「戻る」、ブックマーク部分だが、画面推移がないので、履歴として残らない。これはアプリケーションを設計する側が決めることだが、例えば別のメッセージを表示するというクリックをした場合、ユーザーはそこで「戻る」を押すと、先ほどまで表示していたメッセージを出してほしいという期待があると思う。
そこはアプリケーション開発者側がある程度考えて、履歴として残したいポイントでlocation.hashというプロパティを使う方法がある。ブラウザのURL部分の、しかもハッシュと呼ばれている、普通はページ内の特定のIDとかネームを指定するためのものである。特定のページの、非常に長いページのある部分を指し示したいという場合に使うものがハッシュだが、これを動的にJavaScriptから書き換えることで、ブラウザの履歴に残していく。
ただし、Safari等ではこれを書き換えても履歴として残らない。もちろん、location自体を書き換えてしまってもいいが、そうするとページ読み込み直しに行く必要があるし、場合によってはローカルでプライベートに持っておきたい情報をサーバ側に送信してしまうこともある。
ハッシュ部分はサーバに送信しないので、ある程度プライベートな情報を入れても問題は起こりにくい。ただ、ブックマークとか履歴に残るので、そこは程度問題だが、現状は問題がある。
2007年2月9日PAGE2007コンファレンス「C4 Web2.0時代のサイト構築」より（文責編集）
会報「VEHICLE」2007年4月号 Vol.19 No.1通巻217号
2007/08/15 00:00:00