集中と分散を繰り返すクライアント環境の歴史：21世紀はじめのWeb技術史（1）（2/2 ページ）

[原 幹（NTTデータ ビジネスコンサルティング ），＠IT]

中央集権から分散処理へ――クライアント／サーバアーキテクチャ

　2000年前後より少し歴史をさかのぼってみる。メインフレーム主流の時代は、中央集権アーキテクチャのもとにクライアント環境（いわゆるシステム利用者の操作端末の環境）での操作は極めて限定されていた。ダム端末（「ダムたん」と俗称された。黒バックに緑色の文字という画面が多かったため筆者は「緑画面」と呼んでいた）と呼ばれる味気ないコンソール画面から、ホストコンピュータに指示を出すだけの機能しかなかったのだ。いまでこそ当たり前になったグラフィカルユーザーインターフェイス（GUI）も皆無で、コマンド入力が基本であった。もっともこのアーキテクチャが悪なのではなく、中央集権アーキテクチャの安定性・信頼性がクライアント環境の不便さを補ってあまりある利便性を提供していたものと理解すべきだろう。

　このような不満を解消する手段として、分散処理アーキテクチャの一形態としてクライアント／サーバアーキテクチャが出現する。クライアント環境に画面表示や処理機能を実装し、処理結果をサーバ側に返すアーキテクチャだ。Visual Basicなどによるクライアントアプリケーションの開発も盛んに行われ、従来の中央集権型アーキテクチャの時代には得られない利便性をシステム利用者は享受できるようになった。

　しかし、クライアント／サーバアーキテクチャにも限界はあった。クライアント環境の互換性問題だ。企業システムでは、システムのバージョンアップが行われると必然的にクライアント環境におけるアプリケーション更新・配布作業が発生する。これに要する工数が無視できないボリュームになり、またダイナミックリンクライブラリ（DLL）と呼ばれるクライアントアプリケーション制御モジュールの依存関係がシステム動作の不具合につながるという問題も顕在化する（いわゆるDLL互換性問題）。

　このようなクライアント／サーバアーキテクチャの限界を克服する手段として、主にWebブラウザをクライアント環境に用いる「シンクライアントアーキテクチャ」が出現する。折しも2000年前後は日本もブロードバンド時代で、Webブラウザでも企業システムを構築･利用できる環境が整いつつあった。

中央集権の復権再び−シンクライアントアーキテクチャ

　個人や企業向けのWebサイト（ホームページ）が広く普及し、PCに標準でWebブラウザが実装されるようになった時期を経て、業務アプリケーションにもインターネット技術が導入される端境期が2001年ごろのこと。いわゆるMVCモデルに基づき、クライアント／サーバアプリケーションの限界を克服する「サーバサイド・アーキテクチャ」が広く普及する時期でもあった（3層モデル、3層アーキテクチャとも呼ばれる）。

　サーバサイド・アーキテクチャにおいてはクライアント環境としてWebブラウザ（Webクライアント、HTMLクライアント）が採用された。ビジネスロジックの処理・データの制御・表示の制御を明確に分離することでサーバ側に処理を集中させ、システム全体の保守性および拡張性を高めることができるというメリットが得られるようになった。クライアント／サーバアーキテクチャにおけるクライアント環境を「ファット（太った、肥大した）クライアント」と呼ぶのに対し、主にWebブラウザを利用するクライアント環境「シン（やせた、小さい）クライアント」と呼ぶ。役割を明確に分担させつつサーバ側に処理を集中させる「中央集権」型システムの復権である。

　一方で、この方式にも限界はあった。HTMLという静的なコンテンツを前提としたマークアップ言語では、クライアント環境での表現力に制約が起きる。特にユーザーの操作に連動して動的にコンテンツを生成する要求に対してはHTMLでは十分に応えることができなかったのである（この限界についてはJavaScriptやDHTMLによる克服がなされ、動的なコンテンツをクライアント側で生成できるような工夫が取られる）。

　また、ブラウザ同士の互換性による表示面の不具合なども顕在化した。2007年になったいまでこそマイクロソフトのInternet Explorerがブラウザ市場の8割以上のシェアを握って事実上の標準とされているものの、2000年前後はまだ「Netscape Navigator」「Internet Explorer」が企業のWebブラウザ環境として混在していた状況があった。これらは同じHTMLという言語で表現されたコンテンツを表現するアプリケーションでありながら、構文解釈の違いから同じHTMLで記述されたコンテンツも使用するブラウザによって表示結果が変わるという現象が起きたのだ。

　この時期の業務システムの構築においては、いずれのブラウザ環境も想定した検証を行う必要があった。またOSとブラウザの組み合わせによって期待した表現や機能が実現されないなど、クライアント環境における混乱が見られた。筆者はNetscape Navigatorでのクライアント画面の表示検証に携わった際に、Webブラウザメーカー同士のシェア争いがユーザーや構築ベンダにいたずらにツケを回している実感を持った。そこではユーザーの利便性は横に追いやられ、メーカーの論理が常に幅を利かせていた。

いいとこどり−リッチクライアントアーキテクチャ

　かつてクライアント／サーバアーキテクチャに慣れ親しんだユーザーは、当然の要求としてクライアント画面による高機能処理の実現を求めるようになる。「こんなこともできないの？」とは実際に筆者が情報システムのエンドユーザーの方から何度も聞いた言葉だ。一度味わった快適さを容易に手放せない業のようなものかもしれないが、当然の要求ではある。

　このような要求に応える要素技術として出現したのが「リッチクライアントアーキテクチャ」である。リッチクライアントアーキテクチャでは、必要に応じてアプリケーションをサーバからダウンロードし、クライアント環境で処理を実行させることができる。文字通りリッチ（豊富）な処理能力をクライアント環境に実装するものだ。クライアント／サーバアーキテクチャにおける大きな課題であったアプリケーション配布やバージョン管理の問題は、使用時にサーバから最新アプリケーションをダウンロードさせることで克服することができるようになり、一方でシンクライアントアーキテクチャにおけるクライアント側の処理能力の限界を克服できる「いいとこどり」の方式を実現することができたのである。リッチクライアントアーキテクチャは、かつてのクライアント／サーバアーキテクチャへの一部回帰といえる。

最近の動向――さらなる進化を遂げたクライアント環境

　2004年ごろから、サーバサイド・アーキテクチャを踏襲しつつ、標準的なインターネット技術を組み合わせた新たなアーキテクチャが広く世に出回る。サーバ側であらゆる処理を実装してしまい、クライアントはWebブラウザのみであたかもクライアント／サーバで並みの処理・表示能力を実現する方式だ。ここではAjax（エージャックス）について簡単にふれる。

　Ajaxとは、Webブラウザに処理プログラムを組み込んで、サーバと非同期に連携して動作させることで、体感的・視覚的なWebサイトを開発する手法だ。例えば、ユーザーが次に行う操作や動きに合わせて非同期通信を用いて先行処理しておくことで、ユーザーを待たせるような操作感を持たせず、あたかもリアルタイムで処理しているような操作感覚を実現することができる。業務システムでのAjax実装例はまだまだ少ないが、徐々にエンドユーザーにもその利便性が享受できるようになることだろう。

---

　以上、今回は「中央集権（メインフレーム）→分散（クライアント／サーバ）→再び中央集権（シンクライアント）→いいとこどり（リッチクライアント）→さらなる進化（Ajaxなど）」というクライアント環境の歴史を振り返った。次世代のアーキテクチャが何かは予想し難いが、共通しているのは業務システムの提供側（情報システム部門、開発ベンダ）の視点からではなく、利用側（特にエンドユーザー）のニーズに合わせて要素技術が進化しているという点だ。一度獲得した利便性をユーザーは容易には手放さない。この当然な要求をかなえるためにクライアント環境の進化はユーザーの視点に基づいて今後も続いていくはずである。

「21世紀はじめのWeb技術史」バックナンバー

• 最小限の手間でシステム間連携を実現する〜疎結合アーキテクチャの登場
• 開発の標準化とフレームワークの普及
• 集中と分散を繰り返すクライアント環境の歴史