第1章 総論

1.1 規格の社会学への視座

1.1.1 「役割」という視点の導入

 本委員会は,「規格の社会学」を目指し,電子化文書の動向を見極めるための指針を確立することを目標として活動している。本年度は,さまざまな電子化文書に対し,その成立過程や普及に至るまでの経緯についてを主なポイントとして,ヒアリングを繰り返してきた。

 こうして事例をいくつか見ていくうちに,電子化文書の動向は,それをとりまく人々の関わりあい方によって大きく左右され,方向づけがなされていることが分かってきた。もちろん,実際に現れてくる人物やその行動は個々の規格や製品ごとにさまざまであり,簡単に特定のパターンに収まりきるようなものではない。しかし,規格の社会に登場する人物にはそれぞれ何らかの役割があり,その役割に従った目的,ニーズ,物の見方といったものを持っているはずである。これを押さえれば,ある程度の傾向はつかめるのではないだろうか。

 そこで,本報告書では「役割」という視点により登場人物を把握し,その動きを追ってみることにした。どのような役割を持った人々が,どのような思惑で行動し,どのようなタイミングで関わり合うことで,状況がどのように変化していくか。これを分析することで,電子化文書をめぐる状況を把握し,その行く末を占うポイントを見つけ出すことができないかという狙いである。

1.1.2 どのような役割があるか ─ 作る,使う,そして,かつぐ ─

 それでは,実際に,電子化文書をめぐる人々の役割にはどのようなものがあるだろうか。人間が取り扱う人工物であるから,当然作り出す人と利用する人が存在するが,これだけではうまく機能しない。両者の間を取り持ち,結び付ける役割を果たす人がいるはずである。個々の規格やその規格に基づく製品ごとにいろいろな登場人物が考えられるが,本質的にはこの3種類の人々,すなわち

に集約することができるだろう。

 先ず「作る人」は,文字通り,規格なり製品なりを開発する人である。規格制定者の中には,公的規格を作るために企業や学術関係から集まってできた機関もあれば,規格作りを専門とするヨーロッパの「規格屋」のような人もいるし,共通のドメインに属するいくつかの企業が集まって規格を決めるコンソーシアム形式もある。

 次の「使う人」には,規格や製品を自分が使うことで完結してしまうエンドユーザの他に,これらを使って製品を作り,さらに別の人に提供するプログラマも入るだろう。

 そして「かつぐ人」とは,規格や製品を掲げて,「作る人」と「使う人」の間を結びつける人である。製品を売り広めることを目的とするマーケッタはもちろんのこと,エンドユーザの代わりにアプリケーションソフトを導入したり情報システムを構築したりする情報システム部門のような人も「かつぐ人」に入るだろう。

 このように,具体的な登場人物は規格や製品によってさまざまであるが,その役割は前述の三つに大別できる。ただし,これらは必ずしも別々の人間とは限らない。同じ人が見方を変えると別の役割を果たしていることもあるだろうし,意図的に複数の役割を兼ねることもあるだろう。例えば,製品を開発するプログラマは,製品から見れば「作る人」であるが,その製品が基づいている規格から見れば「使う人」である。また,何らかのニーズを持った「使う人」が,シーズが存在しないがために自ら「作る人」になることもある。

1.1.3 役割に注目した分析

 本報告書では,この「作る人」「かつぐ人」「使う人」を用いて分析を行っていくわけであるが,その最もプリミティブな例を以下に挙げておく。実際にはこれに具体的な登場人物が入り,流れの構成も変わってくるはずである。

(1) 基本

 規格あるいは製品を単独で見た場合,また,規格と製品の区別が曖昧であるような場合の最も単純なパターンは,「作る→かつぐ→使う」という流れであろう。

(2) 規格が先にある場合(デジュア)

 規格を先に制定し,その後それに基づく製品を作る場合は,規格の利用者がすなわち製品を作る人であり,「規格→製品」の順に流れていく。

(3) 製品が先にある場合(デファクト)

 製品が先にあり,それが規格(標準)となるような場合は,まず製品に対して,「作る→かつぐ→使う」という流れがあり,その後,製品の作成者が規格を作る人にもなり,規格の利用者にもなることになる。

1.1.4 役割による分析の具体例

 役割に注目した分析をより具体的にするために,昨年度おこなったヒアリングの中からPhoto-CDとAdobe Acrobatについて,この視点でもう一度見直してみる。

(1) Photo-CDの場合

 Photo-CDは,画像を取り扱う産業に身をおくコダック社が,画像をとりまく環境がデジタルへの要求を強めていくことを見据え,実質的なCDの標準となっているフィリップ社と共同で規格を作ることから始まった。Photo-CDのコンセプト自体は,フィルムの高画質とデジタルの利便性を生かしたトータルシステムというもので,開発者側のビジョンである。

 コダックのマーケッタは,これを最初はコンシューマ(一般のエンドユーザ)をターゲットに展開しようとした。しかし,マーケッタが意図した「自分の写真をテレビに写して楽しむ」という利用方法は,実際の日本のコンシューマには浸透しがたいものであった。それだけのために専用機を買うほどの魅力もニーズもなかったのである。

 次にコダックは,コンピュータ,ゲーム,マルチメディアの世界にターゲットを切り替え,サポート企業の獲得に注力した。ちょうどその頃,世の中は,ハードウェアの進歩に裏打ちされてマルチメディアへ向かっており,その一環として画像に対する要求も強まっていた。ゲーム機や家電,コンピュータのメーカにとって,高画質の画像を扱えるということがマーケティング上のニーズになってきていたのである。

 こうして,サポート企業という利用者を獲得したことにより,漠然としていた「使う人」を具体化することができ,成功につながった。また,サポート企業を間に挟みワンクッション置く

ことで,始めは直接押さえようとして失敗したコンシューマも,間接的にではあるが利用者として押さえることができている。

 開発者側のコンセプトを,サポート企業のニーズとうまく結び付けることができたことが,コダックのマーケッタの成功のポイントであろう。

※ サポート企業は,Photo-CDから見た場合には「使う人」,Photo-CD利用製品から見た場合には「作ってかつぐ人」。

(2) Adobe Acrobatの場合

 アドビシステムズは,PostScript技術を開発し,電子的に作成したドキュメントをプラットフォームを限定せずに出力することのできる環境を提供してきた。しかし,その自分たちでさえ,せっかく電子的に作ったドキュメントを紙に出力して郵便やFAXで配布しており,電子化の特質を生かしきっていない。そこで,電子化したドキュメントをそのまま電子的な手段で伝達する際のソリューションとして,PostScriptのサブセットであるPDFというファイル形式を核とするAcrobat製品群を開発した。

 自社の市場(すなわちPostScriptの市場。プリンタメーカーやDTPソフト開発者)を広げようとした時に,自らが利用者の立場で考え,必要であるが存在しないものを作るという戦略をとっているところが特徴であろう。また,PDFを利用するためのツール群Acrobatを開発してはいるが,アドビシステムズの主目的はPDF自体をデファクトスタンダードとして確立させることで,それにより,第三者がより有効なPDFの利用方法を編み出し,市場を拡大してくれることを狙っている。

1.1.5 まとめ

 以上,「作る」「使う」「かつぐ」という役割に注目して電子化文書をめぐる状況を把握しようと提案し,昨年度のヒアリング内容で実際に分析を試みた。

 近年のコンピュータ関連技術の急速な進歩や,インターネットに代表されるネットワークの普及により,一昔前とは比べ物にならないくらい多くの人が電子化された情報を扱うようになってきた。中でも「使う人」の比率が高く,「作る人」との間をつなぐべき「かつぐ人」の立ち回りかたがより重要になってきている。

 本報告書の以降の章も,この「作る」「使う」「かつぐ」という役割を持った人々の動向に留意して読み進めていって欲しい。

1.2 近年の電子化文書の動向

1.2.1 HTML

 HTML(HyperText Markup Language)は,WWW上での文書記述用言語の一つである。

 HTMLによって文書を作成する場合,タグと呼ばれる記号を文書中に埋め込むことにより,そこに書かれている語,文,文章の意味や表示の際の特殊効果を指定する。

 HTMLの公的仕様は,World Wide Web Consortium(W3C)のHTML Working Groupが制定している。W3CはMIT/LCS(Massachusetts Institute of Technology, Laboratoryfor Computer Science)とINRIA(The French National Institute for Research inComputer Science and Control)によって共同運営されている。W3Cの会員は,1997年1月24日で159であり,WWW業界に参入している主要なベンダは参加している。W3Cは,HTMLの規格制定以外にも,電子決済,セキュリティ,知的所有権とライセンス,分散コンピューティングなどWWWに関する幅広い分野で活動している。

 W3CによるHTMLの最新バージョンは,1997年1月に標準として制定されたHTML3.2である。HTML3.2では,WWWブラウザで広く使用されているテーブル,Javaアプレットの埋め込みなどが仕様として組み込まれた。また,スタイルシート,JavaScriptなどのスクリプト言語の埋め込みなどがサポートが表明され,仕様が検討されている。

 HTMLには,W3Cの定める仕様以外にも,各WWWブラウザメーカが独自に拡張したHTMLの仕様が存在する。これは,自社のWWWブラウザが表示する画面をより見栄えのよいものにするために,WWWブラウザのメーカがたび重なる仕様拡張が行われてきたからである。そのため,同じHTMLで記述された文書をA社のWWWブラウザでは読むことができるがB社のWWWブラウザでは読むことができないといった混乱をまねいている。

 しかし最近では,W3Cの定めた公的なHTML仕様と各社WWWブラウザ用のHTML仕様の差がなくなりつつある。

 表1.1と表1.2に1995年と1996年におけるW3Cの定めたHTML仕様と,各社WWWブラウザのHTML仕様におけるHTMLタグのサポート状況を示す。表中のタグのサポートパターンは,特定のタグがそれぞれの仕様においてサポートされているかどうかを表す。タグ数はそのパターンと一致するタグの種類を示す。なお,タグに付与する属性の種類は無視している。

 この表から,1995年におけるすべての仕様でサポートされるタグ(例えば<LI>)は全部で45個あり,調査した全タグの60%に相当し,残り40%は各仕様でサポート状況がまちまちであることがわかる。これに対して,1996年においては,すべての仕様で共通しているタグは64個,79%となり,仕様のばらつきが減っていることがわかる。

表1.1 1995年時点でのHTMLタグサポート状況

※その他,サポート状況不明のタグ13個

表1.2 1996年時点でのHTMLタグサポート状況

※その他,サポート状況不明のタグ8個

 公的HTML仕様に収束しつつある背景には,WWWブラウザの優位性を決定する基準がHTMLの独自拡張機能から,HTML文書に埋め込むデータやオブジェクトのサポートへと移行しつつあることが考えられる。この場合,HTML自身はオブジェクトを埋め込むコンテナとしての役割を果たすことになる。

 HTML文書に埋め込んだデータやオブジェクトをサポートする手段として,WWWブラウザのplug-inが広く使用されている。HTML文書からのリンク先,または埋め込みデータがHTML文書以外である場合,WWWブラウザはそのデータフォーマットの種類を判断し,そのデータ処理をplug-inに委ねる。plug-inでサポートされる主なデータ形式を表1.3に示す。

表1.3 plug-inでサポートされる主なデータ形式

 plug-inの入手方法には,
  (1) WWWブラウザに標準装備
  (2) ソフトメーカが無料で提供
  (3) ソフトメーカが市販
の3種類がある。この中で,(2)は自社のアプリケーションで作成したファイルをWWWを使用して公開・閲覧できるようにようにすることにより,アプリケーションの販売を促進させるねらいがある。

1.2.2 XML

 HTMLはWWW上での文書フォーマットの事実上の標準として広く利用されている。しかし,HTMLは1.2.1節で述べた様に,HTML仕様の互換性の問題は解消される方向にあるものの,いまだに互換性の問題は残っている。これは,HTMLの仕様(SGMLでのDTD)がユーザからは再定義不可能であり,WWWブラウザメーカの競争により面白いが互換性に問題のある改良が過剰になされたことによる。

 この問題を解決するために,XML(Extensible Markup Language)と呼ばれる文書フォーマットが検討されている。XMLの規格制定はW3CのSGML Working Groupが行なっており,現在Draftが公開されて段階である。

 XMLは,Web上でSGMLを簡単に使用できるようにSGMLをかなり単純化した方言の一つである。XMLは,現在HTMLで可能となっているWWW上でのドキュメント交換のようにSGML文書を交換できるようにすることを意識している。そのため,SGML仕様から実装が困難なもの,インターネット上での利用の際に意味がないものを大幅に取り除き,リンクやスタイルシートなどの機能を拡張している。

 XMLは,HTMLとは異なり,SGMLのサブセットである。そのため,XMLはSGMLと同様にユーザがドキュメントタイプを定義することが可能である。例えば,グループ,あるいは組織が目的に応じてXMLを基礎とした独自のマークアップ言語を作成し,情報交換することが可能である。

 XML仕様設計においては,HTMLやSGMLとの相互運用が配慮されている。そのため,SGMLパーサなどの従来のSGMLツールを使用することができる。また,XMLブラウザなどのXMLツールでHTMLを取り扱うことができるよう配慮もされている。

1.2.3 VRML

 VRMLは,3次元空間およびオブジェクトを記述するための文書フォーマットである。VRMLで作成した3次元アプリケーションはプラットフォーム非依存であり,WWWと統合した形で使用されることを想定している。VRMLファイルは,HTMLと同様にアスキーテキストで記述され,ノードという3次元イメージを生成するコマンド群で構成される

 VRMLの仕様制定に関してはVAG(VRML Architecture Group)が活動している。

 VRMLは,1996年8月にバージョン2.0が制定された。VRML2.0では1.0から下記の機能拡張が行われた。

 これにより,VRML1.0では3次元空間内を動き回ることしたできなかったが,2.0になって表現力や対話性が強化され,複雑な3次元アニメーションやシミュレーションが可能になった。

 現在,VRMLの次の機能拡張として以下の項目が検討されている。

1.2.4 Java

 Javaはオブジェクト指向言語の一つである。Javaを使用して作成された「アプレット」と呼ばれるプログラムをHTML文書に埋め込むことにより,HTMLだけでは不可能であったインタラクティブなページを作成することが可能になる。

 現在では各社からJava言語によるプログラム開発環境が販売されており,Javaにより作成されたアプリケーションも販売され始めている。また,現在では主要なWWWブラウザはJavaアプレットをサポートしている。

 最近,Javaの標準化作業を行なっているJavaSoft社では,JDK(JavaDeveloper's Kit)の新バージョンである1.1を発表し,1996年12月からベータバージョンをインターネット上で配布している。JDK1.1における主な新機能を以下に示す。新機能追加の他に,性能や品質の改善がなされている。

 この中でも,分散オブジェクトシステムへの対応は,下記の様にJDK1.1のベータバージョン公開以前に仕様が公開されており,ここ1年で急速に進んでいる。

 JavaIDLはJavaアプレットがOMG(Object Management Group)のCORBA(Common Object Request Broker Architecture)準拠オブジェクトと通信するためのインタフェース記述言語である。CORBAについては1.2.6節で説明する。

 JavaRMIはネットワーク上のアプレット同士の通信機構である。

 JavaRMIと同様のシステムとしては,1995年12月に通産省工業技術院電子総合研究所で開発されたHORBがある。HORBはJavaの上位互換であり,Javaが動作する環境であればどこでもJavaと相互に接続して運用が可能である。

 JavaBeansは同一マシン上のアプレット同士の通信機構である。Microsoft社のCOM(Component Object Model),Netscape Communications社のLiveConnect,Apple Computer社やIBM社のLiveObjectのいずれとも相互に通信することができる仕組みが組み込まれている。JavaBeansはJavaRMIと組み合わせることによりネットワーク上に分散したJavaアプレット同士を連係させることが可能になる。

1.2.5 JavaScript/JScript

 HTMLは,単なる文書フォーマットであるため,画面でデータを処理することはできない。インタラクティブなWWWページを作成するにはユーザーの入力や時刻に対して動的な処理を行なう機構が必要になる。

 従来,このような処理はCGI(Common Gateway Interface)と呼ばれる機構を用いて実現されてきた。CGIを使用する場合,その処理はWWWサーバ側で実行されるため,WWWサーバマシンに大きな負担をかけてしまい,ネットワークの処理効率が低下する場合がある。

 同様な動的な処理は1.2.4節で述べたJavaアプレットをHTML文書に埋め込むことによっても実現可能である。Javaアプレットを使用する場合,JavaアプレットはWWWクライアントが実行するため,WWWサーバには負担がかからない。しかし,Javaは本格的なプログラミング言語であり,CGIで使用するPerlなどのスクリプト言語と比較して習得が困難である。

 WWWサーバに負担をかけず,Javaよりも容易に習得できるプログラム言語として,Netscape Communications社とSun Microsystems社が共同でJavaScriptと呼ばれるスクリプト言語を開発した。JavaScriptは,HTMLドキュメントに直接組み込むことができる。JavaScriptはJava言語のサブセットにあたるオブジェクト指向スクリプト言語であり,C言語に似た言語構造を持つ。

 本来,JavaScriptはHTML文書に埋め込まれWWWクライアント側で処理する。しかし,Server-Side JavaScriptと呼ばれるサーバの処理を行うためのサーバで動作するJavaScriptも存在する。Server-Side JavaScriptはLiveWireと呼ばれるServer-Side JavaScriptを動かすためのソフトウェアと,Netscape社製のサーバソフトウェアが動作している環境でのみ使用することができる。Server-Side JavaScriptを使用すると,SQLサーバやODBCデータベースへのアクセスといったCGIを使わなければできなった事ができるようになる。

 JavaScriptはJavaScriptを開発したNetscape Communications社のNetscape Navigatorだけでなく,Microsoft社のInternet Explorerでも使用可能である。しかし,Microsoft社はJavaScriptを自社のInternet Explorer3.0用に独自の機能拡張しており,その言語をJScriptと呼んでいる。

 Internet Explorer3.0ではJScriptの他に,VBS(Visual Basic Scripting Edition)と呼ばれるスクリプト言語をサポートしている。VBSはVBA(Visual Basic for Applications)からセキュリティに問題のあるメソッドを削ったサブセットで,言語仕様はこれに準拠している。

参考文献
 [1] http://www.w3.org/
 [2] http://home.netscape.com/
 [3] http://www.microsoft.com/
 [4] http://www.microsoft.co.jp/
 [5] http://www.ucc.ie/xml
 [6] http://www.textuality.com/xml
 [7] http://www.iijnet.or.jp/FXIS/XSoft/sgml/xml.htm
 [8] http://vag.vrml.org/
 [9] http://www.javasoft.com/
 [10] http://www.sun.co.jp/java.jp
 [11] http://ring.etl.go.jp/openlab/horb-j

1.2.6 複合ドキュメント関連(構造記述)

(1) ODA

 ODAは開放型文書体系(Open Document Architecture)は文書電子化の国際規格であり,文書の互換性,交換性などを重視して,1989年にODA規格の第1版が発行され,それ以来逐次規格の修正,追加が行われている。1989年に発行された第1版に引き続き,1994年に第2版にて大きな改訂がかけられ,以降は音の取り込みや,表計算,MHSとのAPIなどの拡張がなされているが,近年は比較的落ち着いている,既に確立された(忘れられた)規格であるといえる。

 とはいいながら,ODAで作られた規格は無駄なものになってしまったかというとそうではなく,近年でも様々なところにその思想,規格が受け継がれている。例えばISO 8613-7のAmendment1にて導入されたタイル状ラスタ図形(Tiled Raster Graphics)は米国国防総省(DoD)の調達仕様とされるMIL-R-28002Bにも採用されCALSにおけるラスタイメージデータの標準と位置づけられてきている。また,ODAとSGMLの関連も深く,ODAで細かく定義された文字,外部参照などの規定はSGMLでは文書型定義(DTD)により自由に定義されることができ,ODAはSGMLに含まれていく傾向にある。文書表現形式はODIFで定義されたものが,SGMLの体裁表示の規格であるSDIF,DSSSL,SPDLに少なからず影響を与えている。さらにODAの考え方は,Microsoft WORDのRTF(Rich Text Format)を始めとして,AcrobatのPDFなどでもラスタ表示の技術として生き残っている。

 1.1節の役割分担にあてはめると,規格は既に出来上がっているが,製品を「作る人,かつぐ人」の減少により下火になっている感がある。

(2) SGML

 SGMLは構造化文書を記述するための,マークアップ記述言語(Standard Generalized Markup Language)のことをいう。ここ最近のHTML人気に伴って,SGMLの知名度も上昇してきている。HTMLとSGMLはよく対比されることが多く,「HTMLはSGMLのサブセットである」とか,「SGMLとは異なりHTMLは簡易なタグセットのみで記述されているため普及した」といったように使われている。ただし,ここで引き合いに出されているのは「SGML=使われていない,HTML=使われている」の構図であり,SGMLが必ずしも使われて有名になっているわけではない。だが,知名度があがったということは,それだけで意味のあることではある。

 SGMLは国際規格ISO 8879にて1986年に規定されており日本でもJIS X 4151として1992年に制定されている。規定後,現在まで大きな変更は加えられていない。

 SGMLの規格があまり変更されていない理由は,SGMLがDTDと対になり,かなりの必要とされる文書の表現に対応することが可能であるからだと思われる。SGMLでは,構造のみをもつ文書インスタンスであるSGML文書そのものと,文書の型(フォーマット)のみを定義したDTDとにきれいに役割が分担されている。

 欧米ではCALSが騒がれて以来はSGMLの話題は下火になってきている。日本では,ここ2〜3年のCALS人気によりSGMLも話題になっていることが多いが,実際に活用されている例はまだまだ少ない。SGMLが活用されるには作成,編集,プレビュー,印刷などの周辺ツールが整備されることが必須である。米国,カナダなどは軍,政府などの主導のもとによりSGMLの利用,およびそれに付随するメーカのツール開発が行われている。言うなれば,開発費が高くても利用者がいるため特定目的利用だけで,利用者が爆発的に増えるわけではないが,継続的にツールが提供されている。近年アップデートされているツールなどに,Microstar Software Ltd.のNear&Far,Grif S.A.のGrif SGMLなどがある。

 近年日本で発売されたツールの有名なものとしては,SGML作成ツールInContext2.1日本語版(開発元Xsoft社,日本代理店富士ゼロックス情報システム)などがある。国産ソフトウェアとしては,JustSystem社の一太郎がSGML変換の機能をもつようになったのをはじめ,富士ゼロックス情報システムのAkaneや,日立のDocIntegraなどのメーカが日本語対応のSGML対応エディタ(ワープロ)を提供しはじめた。また,本委員会のヒアリングに協力いただいたアンテナハウス社のTagme(様々なワープロ文書をSGMLに変換するツール)が近年リリースされたのも記憶に新しい。ツールの整備に伴って,日本でもSGMLの利用者は増えてくるはずである。

 以上を踏まえて役割分担にあてはめると,規格は既に出来上がっており,製品を「作る人」「かつぐ人」が徐々に増えつつある。

 なお,ここでの役割分担は3章のSGMLにおける役割分担とは視点が異なっているため3章のSGMLで考えている役割分担とはまた違ったものになっている。

(3) OMG

 OMG(Object Management Group)は1989年に設立され,オブジェクト指向技術の標準化と普及をめざし分散オブジェクトの規格を制定するなど,現在も活動を続けている。OMGではOMA(Object Management Architecture)ガイドを定めて,OMA参照モデルを四つの部分に分けている。その中でも特に重要なモデルがORB:Object Request Brokerと呼ばれており,オブジェクト間のリクエストやレスポンスのやり取りを行なう通信機能を提供するものである。

 ORBの仕様を定めたものがCORBAと呼ばれている。1991年のCORBA1.1に続き,1994年の12月にはCORBA2.0が制定されている。CORBA1.1ではORBのためのIDL(Interface Definition Lnaguage)言語やORBインタフェースなどが定められている。また,CORBA2.0では異なるORBの相互接続と,相互運用のための仕様で,ORB間のインタフェースが定義されている。

 本OMGの日本における状況としては,1995年6月,OMG Japan SIGが設立され,日本およびアジア・非西欧のマルチバイト系の文字を扱うための検討がテーマとして与えられた。日本はUNICODEの例もあるが,アジアにおけるマルチバイトの扱いのリーダとして期待がよせられている。標準化世界のなかで,日本はますますリーダシップを発揮していく必要がある。ちなみに,OMG Japan SIGの議長は土居範久慶応大学教授,事務局は(株)創研プランニングが担当している。

 OMGのCORBAを用いて具体的に運用されている事例は少ないが,コンソーシアムとしての活動は着実に進展している。ローカルな処理については,マイクロソフトのWindowsがデファクト標準の地位を確保しているが,WebブラウザやWeb,DBサーバ,さらに,ワークフロー管理やグループウエア,ビジネスオブジェクトなどのミドルウエアに関しては,OMGの存在は極めて大きなものになりつつある。特に最近,ビジネス・オブジェクトとエージェントに関する動きについては,OMGが主導権を握りつつあります。

 以上を踏まえて役割分担にあてはめると,規格はほぼ出来上がっており,製品を「作る人,かつぐ人」が徐々に増えつつある。ただし,現在のところ目にみえた製品化までは行われていない。

(4) ActiveX

 ActiveXとはMicrosoft社が提唱しているクロスプラットフォームの統合環境のことをいいます。ただし,世の中の人はActiveXを狭義にActiveXはjava+OLEといったアプリケーション間のデータ連携をインターネット上でできるものと考える人が多いようです。開発者から見ると開発ツールはMicrosoft Visual Basic,Visual C++などのツールがそのまま使えるということもあり,現在のツールの延長であり,Javaを知っている人はアプレットの動作と変わりないためそれほど意識されることはないように見える。Microsoftの唱えるには,大きな違いはJavaと対抗するためではなく,Javaと協調,統合を行ったということのようである。

 ActiveXはここにあげている他の標準規格とは異なり,Microsoft社が提供する統合開発環境のことを指す。そのため,Microsoft Windowsで動作するアプリケーションを開発するサードベンダーはこの「提示された標準」に従わざるをえない。

 ただし,ActiveXが取り込んでいく環境の広がりはすざましいものがあり,インターネット,Javaをはじめ,暗号化認証技術から,音声,ビデオを含めたマルチメディア環境まで統合している。

 MicrosoftはActiveXに関するパートナーシップとして,サン・マイクロシステムズ社,Spyglass社,オラクル社,CompuServe社,IBM社などと技術提携をしてさまざまな方面でActiveXコントロールとVisual Basicスクリプトの裾野拡大を目指している。

 逆に各ベンダーはjava,CORBAとは別にActiveXをサポートすることによって,インターオペラビリティとして同様の効果を期待している。標準は皆がサポートすることによって一層の効果が現れるからである。

 以上を踏まえて役割分担にあてはめると,規格はMicrosoft社により一方的に逐次発表され,Microsoft社の戦略によりパートナは増えつつある。それと同時にサードパーティではActiveXをサポートメニューに加えるツールが増えつつあり「作る人,かつぐ人」は徐々に増えつつある。

(5) OpenDoc

 Opendocはテキスト,グラフィック,ビデオ,帳票などを含む複合化文書(compound document)を扱える形式のことをいう。また,さらには「コンポーネントソフトウェア」といった概念を基本に,いままでのソフトウェアを部品(コンポーネント)に分けて,自由に組み合わせることが可能となっている。さらにユーザインタフェースはコンポーネント毎に作成する必要はなく,必要に応じて必要な機能(コンポーネント)を組み込んで使うことができる。

 OpenDocはマルチプラットフォームを特徴としている。CI Labs(Component Integration Laboratories)という非営利の業界団体が,1993年9月にApple社,IBM社,WordPerfect/NOVELL社などによって設立され,それ以降CI LabsはOpenDocの最新の仕様の公開,およびソースコードのライセンス,様々なプラットフォーム上での動作の検証などを行なっている。CI Labsのメンバーには現在IBM,WordPerfect/Novellの他,Adobe,Oracle,Lotus,Taligent,Justsystemなど名だたる企業および,OMG,X Comsortiumといったような特定企業に偏らない団体も含まれている。現在Apple,Windows,Windows NT,OS/2,AIXなど様々なプラットフォーム上に移植されている。またUNIXにも移植されているところである。OpenDocは1994年より順次リリースされ,現在では1995年11月にV1.0がSDKとしてリリースされているのが最新版となっている。MacOS 7.6にはOpenDoc1.1が含まれOpenDoc1.2が次のMacOSリリースにて計画されている。また,開発ツールとしてCyberdocもリリースされている。

 OpenDocはMicrosoftのOLEと同じようなものと考えられ対比させられることが多いがAppleではActiveXとOpenDocの比較を次のように説明している。

 また,OpenDocはActiveXのいうWindows上でのOpenとは異なり,マルチプラットフォームであり,ベンダ依存しないOpenであることを強調している。

 以上を踏まえて役割分担にあてはめると,規格はCI-Labsにより議論され,逐次改版されている。市場のオブジェクト指向の高まりにより,パートナ,およびベンダは増えつつある。

(6) DMA

 DMA(Document Management Alliance)とはデータベースアクセスのための共通APIの標準化のことを指す。DMAは米国に本拠を置くドキュメント関連の業界団体AIIM(Association for Information & Image Management International)によって標準としてまとめられている。DMAではクライアントからアクセスするためのAPIとOS,DBMSにアクセスするDBに関連するライブラリツール群のためのSPIを定義している。ツール群では検索,分散ネットワーク,サマライゼーションなどをDMAにあわせて,種々のDBやDBをアクセスするためのツールを作成しておけば,DBの種類やネットワークを意識することなく検索などの機能を使うことができる。つまり,DBやDBアクセスツールの効率よいパッケージ化を図っている。また,クライアントアクセスAPIでは,ODMA(Open DocumentManagement API)というのもあり,主にWindwosのためのデータベースアクセスインタフェースを定義している。これにより,同じくさまざまなクライアントからDBの種類やネットワークを意識することなく共通にアクセスすることができる。

 DMAは1995年4月にAIIMのタスクフォースとして発足され,つい先ほどの1997年1月にDMA1.0が発表された。非常に出来立ての規格といえるが,さらに次のDMA2.0に向けて作業が続けられている。AIIMは600の企業が参加する団体であり,DMAの標準化を含め,中心メンバはXEROX,IBM,Interleaf,FileNetなど主要なドキュメント関連メーカが核となって積極的に議論されている。

 日本としても富士ゼロックス情報システムを中心にDMAに深く関わっており,1995年末にDMA-JAPAN準備会を行い,将来にはDMA-JAPANを発足させる予定である。日本からはNational Language Supportサブワーキンググループに働きかけDMA1.0ではUnicodeによる日本語対応が可能となっている。国際規格に日本が早期に働きかけ日本語化を規格に盛り込ませることのできた一つのよい例である。

 以上を踏まえて役割分担にあてはめると,規格はようやく出来上がったばかりであるが,これから製品を「作る人,かつぐ人」と「規格を作る人」とは同一であるため製品はこれから徐々に増えていくことが予想される。

参考文献
 [1] http://www.sil.org/sgml/related.html#oda
 [2] http://www.intap.or.jp/index.html
 [3] http://www.iso.ch/liste/JTC1SC18.html
 [4] http://www.sil.org/sgml/
 [5] http://www.ncals.cif.or.jp/
 [6] http://www.omg.org/pr96/ibm.htm
 [7] http://www.w3c.org/pub/WWWW/OOP/
 [8] 大野邦夫:「転機を迎えた分散オブジェクト」,Computer Today,1997.1 No77,サイエンス社
 [9] 鈴木純一:「CORBA,Web,Java ORB − その統合とWebの可能性」,Computer Today,1997.1 No77,サイエンス社
 [10] http://www.microsoft.co.jp/internet/activex/
 [11] http://www.apple.co.jp/Opendoc/
 [12] http://www.opendoc.apple.com/
 [13] http://www.aiim.org/dma

1.2.7 エージェント関連技術の動向について

 電子化文書の動向において,エージェント技術が取り上げられることを奇異に感じられる方もおられるかもしれないが,今後エージェントと電子化文書は大きな関わりを持つことになりそうなのでここで解説する。

 エージェントとは,本来,代理人という意味であるが,情報処理分野での意味付けは大きく二つに分けられるであろう。一つは従来の人工知能の延長的な見方で,人間の電子的な代理人を意味するものである。もう一つはオブジェクト指向技術の延長としてのエージェント指向技術とも言うべきもので,オブジェクト指向技術をベースとした自律分散ソフトウエアシステムである。エージェント通信といった技術も後者に含まれる。

 エージェント技術は完成されてはいないが,その標準化の動きがすでに顕在化している。前者の人工知能の延長的な標準化組織としてFIPA[1]やAgent Society[2]が設立され,後者のエージェント通信を含む自律分散ソフトウエアシステムとしては,OMGのコモンファシリティにおけるMobile Agent Facility[3][4]の規格案が挙げられる。この両者の概念は異なるようでいて,実はシームレスに連続している。以下にその内容を紹介しよう。

(1) 自律分散ソフトウエアシステムとしてのエージェント(エージェント通信)

 この意味におけるエージェントは,古くはActorモデル[5]などが挙げられるが,最近は,インターネットの爆発的な普及とそれを実行環境とするプログラミング言語のJavaによる影響が極めて大きい。オブジェクト技術の標準化を指向するコンソシアムであるOMGも,エージェント技術の標準化に向かって動きはじめている[3]。

 OMGが取組もうとしているエージェントの標準化とは,クライアントから見たネットワークを通じたエージェント機能をインタフェース(API)として定めることである。この考え方は,クライアント・サーバ方式の考え方によるオブジェクトの実装に対するインタフェースの考え方を踏襲しているが,これは,従来のORBを中核とするOMGのアーキテクチャを一歩踏み出すものである。

 従来のORBは,クライアントから見たネットワーク上の分散資源を透過的に一元的に扱うことを可能にする枠組みであった。すなわち高速のLANやWAN,さらには情報ハイウエイなどを通じて,ORBは遠隔のコンピュータ上の処理があたかも自分がロクインしているローカルなマシンにおける処理であるかの如き幻影を与えるものであった。

 それに対して,エージェントは,クライアントの要求を引き受け,自ら移動して遠隔のコンピュータ上で実行する。従って,ネットワークを透過的に一元的に見るようなメカニズムとは全く異なる全く新たな分散処理のモデルなのである。従って,電子化文書の効果的な配付や配付先で何らかの処理を実行するような文書(リモート・アクティブ・ドキュメント)には,エージェント技術が適用されることになるであろう。

 ところで,エージェント技術が注目を集めるようになったことに関しては,時代的な背景が存在する。それは,インターネットである。ORBが構想された当初は,ネットワークはいずれ高速化されるという極めて楽観的な見通しがあった。企業や公共機関等における構内LANの普及が進んでいたし,クリントン政権のアル・ゴア副大統領による情報ハイウエイ構想が華々しく打ち上げられていた。しかしながら,WWWを中核とするインターネットは,従来の電話網を使って急速に普及し,一瞬のうちに巨大なインフラを作り上げてしまったのである。

 電話網のような低速かつ低品質なネットワークにおいては,ORBのようなメカニズムは本質的に整合が取れない。しかしながらこのインフラを使って高度なサービスを効果的に実現したいというのが世の中のニーズである。それに応え得る技術としてエージェント技術が登場したと見ることが可能であろう。さらにJavaという言語がそのための道具としてタイムリーに提供されたことも見逃せない。

 ORBであれば,通信を継続したままで遠隔での処理が実行されるが,エージェントであれば,プログラム自体が転送され目的地で実行されるので通信を継続する必要は無い。したがって通信量を劇的に減らすことが可能になる。ORBの場合は,(同一のORBにしろ,異なるORB間にしろ)CORBA準拠のアーキテクチャーをサポートする通信網が前提になるが,エージェントの場合は,そのような制約は無い。デジタル網であろうがアナログ網であろうが通信速度に制約されることなく適応して移動することが可能である。

 数年前に出現したGeneral MagicのTelescript[6]は,エージェント通信メカニズムに関しては先駆的な意味合いを持つものであったが,現在は影響力を失っている。その理由は明白である。インターネットのような開放的な枠組みの中にあって閉鎖的な方針で技術開発,マーケッティングを行ったからである。インターネットにおいては,先にユーザを掴んだ方が勝ちである。ネットワークによる製品の配布によりデファクト・スタンダードが一瞬のうちに確立されてしまうからである。その状況は,JavaやNetscapeのビジネス展開が雄弁に物語っている。

 次に電子化文書とエージェントとの関係を述べる。エージェントの活躍の場がインターネットであるとすると,WWWのウエブ・サーバこそエージェントの生息地になるはずである。ウエブ・サーバとは,基本的にHTML文書のデータベースでありインターネット上のエージェントは,URLアドレスを辿りながらウエブサーバ上を移動することになる。HTMLフォーマットとHTTPプロトコルに基づくWWWの枠組みは,ネットワーク上の分散電子化文書の枠組みを超越したエージェント通信のインフラになっていることを認識する必要がある。現にOMGのMobile Agent Facilityは,インターネットを強く意識したアーキテクチャになっている。JavaのAppletsやJavaBeansは,遠隔での実行機能を実現する道具であり,先に述べたリモート・アクティブ・ドキュメントの構築・カスタマイズ・ツールと考えることが可能である。

 エージェント通信のような自律分散処理系において考慮せねばならない課題はセキュイティである。エージェントには代理人という意味の他に,スパイという意味もあるように,ソフトウエア・エージェントの場合にも危険なエージェントが存在する。ウイルスはその典型であるがまだ単純な例である。因みに,1997年の今年は「2001年宇宙の旅」における超コンピュータHALが完成したことになっている年である[7]。高度な知的存在は,未知であるが故に恐怖の対象になりえることをこの作品は示してくれたが,エージェントとは本質的にそのような側面を持つのである。従って,OMGのMobile Agent Facilityも,OMGのCORBA Security Service[8]を抜きには考えられないことを指摘しておきたい。

(2) 人工知能の延長としてのエージェント

 一昔前の人工知能の応用分野はエキスパートシステムであったが,ハードウエア,ソフトウエア,ネットワーク,GUIが飛躍的に向上した現在,その応用分野は全く異なる様相を呈している。エージェントの標準化組織であるFIPAは,エージェントの応用分野を以下の4分野に絞り規格化をすすめようとしている。

  1. Personal Assistance
  2. Personal Travel Assistance
  3. Network Management
  4. Audio Visual Entertainment

 Personal Assistanceは,個人秘書のようなものである。コンピュータをこの分野に適用しようとした試みは古く,アラン・ケイのダイナブック[9]にまで溯ることが可能である。古典的な人工知能システムにより構築されたナッジ[10]と呼ばれる電子秘書システムは,秘書の役割を知識ベース化したエキスパートシステムであったが,実用になるものではなかった。

 最近のPersonal Assistance技術は,アップルのニュートン[11]に端を発するPDA端末がベースとなっている。なお,アップルは,ナレッジ・ナビゲータ[12]と呼ばれる電子秘書のコンセプトを1980年代の半ばに発表し,このコンセプトをニュートン乃至はその後継機種に実装することを狙ったのであろう。しかし経営危機のアップルが電子秘書の開発を継続できるわけがなく,ニュートンのコンセプトは浮上することなくニュートンのりんごと同様に地に落ちてしまった。

 PDAは,今後の家電業界が期待する典型的な情報家電製品である。そのような観点で見ると,エージェント技術は,インターネットテレビなどと共に,家電業界が通信ネットワーク分野に進出するための戦略的な突破口と見ることも可能である。従って,FIPAに情報処理関係の企業よりも放送・家電業界の企業が進出しているのは驚くにあたらない。

 しかしながら,シャープのザウルスの例に見られる通り,現状のPDAは高級電子手帳でしかない。その機能は,スケジュール管理,住所録,簡単な文書作成,忘備録などである。通信機能を持ったものは,さらにメールの受発信,インターネットアクセスなどの機能を持つ。FIPAのPersonal Assistanceは,前項で述べたエージェント通信機能を用いてPDAの機能と情報通信システムを結合させ,個人への支援機能を高度化させようと指向する。そこで高度化とは何かが問題であるが,その回答は今後の課題である。その意味は,現実の人間の秘書業務からヒントが得られると思われるが,音声認識などのようなヒューマンインタフェースの向上[13]とともに,何時でも何処でも情報が得られるといった,通信に対するロバスト性,KQMLのような知識に対する照会機能[14]などが課題になるであろう。以上のように,Personal Assistanceは,個人秘書の機能の電子化を指向しているのであるが,高級電子手帳であるPDAの発展として位置付けられるように,電子化ドキュメントの一種であることには間違いない。端的に言うと,アクティブな知識を持った電子化ドキュメントということであろう。

 Personal Travel Assistanceは,Personal Assistance機能に旅行の際の情報アクセスとその知的な処理機能(例えば,ホテル予約,エアライン予約等とPersonal Assistance機能のスケジュール管理をリンクさせ,クレジットカードにより決済する等)を追加したものである。

 ネットワーク管理は,前項のエージェント通信の分野に属する機能である。オーディオ・ビジュアル・エンタテーメントは,エージェント機能とマルチメディアの融合した分野で,コンピュータゲームにおけるキャラクタなどはある種のエージェント候補と見なすことが可能である。そのような観点から察すると,最近流行の「タマゴッチ」なども将来のこの分野のエージェントの一つの側面を示していると見ることも可能であろう。

(3) 標準化組織

 以上,エージェント通信的なインフラとなるソフトウエア技術,人間の代行を目指す人工知能の延長的な技術両面からエージェントについて述べた。この内容において,標準化組織としてはOMGとFIPAが登場している。ともに業界の会員企業から構成されるコンソーシアムである。以上の他に,Agent Societyと呼ばれるコンソーシアムもある。これらのコンソーシアムについて簡単に述べる。

(a) OMG

 OMG(Object Management Group)は,600社以上の会員企業を擁する世界最大のコンソーシアムである。設立目的は,オブジェクト技術を用いた異機種分散環境の相互運用を実現すると同時に,オブジェクトをコンポーネントウエアとしてモジュール化し,プラグ&プレイを実現することにある。前者(相互運用)については,CORBA(Common Object Request Broker Architecture)およびObject Serviceとして規格化が進展し,壮大な試みが実現されつつある。後者(プラグ&プレイ・モジュール)についても,コモンファシリティ,ビジネスオブジェクトなどの枠組みで仕様が固まりつつある。エージェントファシリティは,コモンファシリティに含まれ(RFP3)[3],現在下案が出され[4],規格化の途上にある。

(b) FIPA

 FIPA(Foundation for Intelligent Physical Agents)は,主に欧州と日本の放送家電業界の企業を中心としたエージェントに関するコンソーシアムである。頭文字のPを代表するPhysicalの意味合いから分かる通り,このエージェント・コンソーシアムは,物理的なロボットを含む幅広い分野を規格化の対象としている。従って,先に述べた4項目は今後の規格化の前段に過ぎない。

(c) Agent Society

 Agent Societyは,主に米国と日本を中心とする,情報通信業界の企業を中心としたエージェントに関するコンソーシアムである。General Magicを含むエージェントに関する先進企業が集まっているが,具体的な動きは不明である。

(4) エージェントの規格の問題点

 エージェントに関しては,先に述べた通り,General MagicのTelescriptが具体的な製品となっているが,技術をパートナーとなった少数の企業に対してしか開示しなかった。しかもその技術開示も厳格な守秘契約の下に行われ,世の中に幅広く知られるには至らなかった。その結果,マーケッティングを通じて製品を幅広く世に問う機会を失い,先導的な優れた技術でありながら世の主流になる機会を失ってしまったように思われる。

 それならば,オープンな戦略を取れば良かったかと言うとそうも言い切れない。エージェント技術のように,極めてインパクトの大きな製品は,市場予測も極めて難しい。巨大企業ならいざ知らず,ベンチャー企業では,低価格で開放的なリスクの大きな戦略を取るのは困難であろう。先導的な製品は,コンセプトを主張し,その情報を開示しただけでマイクロソフトのような強力な企業に容易に真似られてしまい世の主流としての地位を奪われかねない。すなわち,特許や著作権で保護されるものは良いのだが,商品コンセプトや市場戦略のような情報は知的所有権としては保護され得ないのである。

 従って,General Magicの閉鎖的な方針は,ベンチャーとしては選択の余地のない当然な行き方であった面もある。そのような意味で,Telescriptの事例は,先導的な技術が規格となって世の中に普及していくための重要な教訓を与えてくれていると思われる。将来の規格に関係するするような,システムがらみでインパクトの大きな領域は,ベンチャーが単独で技術と市場をコントロールするのは本質的に無理がある。特にネットワークに関係するような規格は,既存のプロトコルなどとの関係から,先導的な技術を独自に導入し普及させるのは,極めて難しく,政府機関,コンソーシアム,または巨大企業でなければ不可能とさえ言えるであろう。エージェント技術は既にこの領域に含まれるのである。

(5) 作る人,かつぐ人,使う人

 結局,エージェントに関しては今のところ先に述べたTelescript程度しか具体的な製品が出現しておらず,コンソーシアムによる規格案のみが先行している段階にある。規格案についても,エージェント通信的な分野の規格案(OMG)と個人秘書的な分野の規格案(FIPA)とでは,かつぐ人と使う人が異なってくる。

参照情報
 [1] http://www.cselt.stet.it/fipa
 [2] http://www.agent.org/
 [3] OMG TC Document 95-11-03
 [4] OMG TC Document cf/96-08-01
 [5] TBD,Re.actor
 [6] http://telescript.com/
 [7] TBD,2001
 [8] OMG TC Document 96-08-03 through 96-08-06
 [9] A.Kay,et.al.:"Personal Dynamic Media",IEEE Computer,March,1977,pp31-41
 [10] TBD,Nudge
 [11] TBD,Newton
 [12] TBD,Knowledge Navigator
 [13] R.A.Bolt:"Sppech at the Interface",Proc. Canadian Man-ComputerCommunications Society,June,1981,pp.209-215
 [14] TBD,KQML

1.2.8 レイアウト系電子化文書

 前項の構造指向の複合ドキュメントが,電子化文書を文字,図形,画像,映像,音声などの各種情報の容器として扱うのに対し,レイアウト系電子化文書は,主に配布を目的とした従来の紙に代わる電子的な表現手段に過ぎない。歴史的には,プリンタや写植機に印刷情報を提供するための制御コードとデータの構文の端を発するページ記述言語(PDL)がレイアウト系電子化文書の仕様の基本的な枠組みであろう。この標準化をねらったISOのSPDL(Standard Page Descriptipn Language)の規格化がもたついている間に,AdobeのPostScriptがパソコンやワークステーションによるDTPシステムの普及に伴い,デファクト・スタンダードの地位を確立してしまった。

 ところで,PostScriptが,主にハードコピーを対象にしたページ記述言語であるため,ディスプレイを対象にした電子化文書には必ずしも適合しない。(Display PostScriptというものがあるが,これはウインドウシステムである。)レイアウト系電子化文書は,特に検索手段を含むヒューマンインタフェースを考慮したシステムとして提供する必要がある。Acrobatは,そのような目的のビューワであり,PDFはAcrobatのための電子化文書のフォーマットである。PDFの詳細に関しては,昨年度のヒアリング結果を参照して頂きたい

1.2.9 まとめ

 以上,電子化文書の動向について述べたが,この分野が極めて大きな変化の途上にあることがお分かり頂けるであろう。文書電子化の波は,まずは印刷文書の作成過程に現れ,ワープロやDTPの世界とそれを結ぶプリンタの世界に規格をもたらした。ODAやPostScriptはこの時代を反映した規格である。そのころ文書の論理構造とレイアウト構造,その相互関係に着目し,ISOは総合的な文書の規格の制定を試みた。SGML,SPDL,DSSSLはそのための規格である。その後,パーソナルコンピュータの普及に伴い,電子化された文書は社会的な認知を受けるようになった。例えば,FDDによる文書の入稿や配布はその現れである。ところが,ワープロやDTPの文書格納形式は統一されておらず,相互の変換が問題となった。今回ヒアリングを行なわせて頂いたアンテナハウス社の製品などは,そのための変換ツールであると言える。

 企業にLANが導入されるに従い,ネットワークを通じた文書のワークフロー管理の需要が顕在化した。ロータス・ノーツはそのニーズに応え得る製品として位置づけられるであろう。そのような状況になると,文書データベースが必要とされるようになり,クライアント・サーバ・システムとして文書を管理する必要が生じた。DMAはそのためのコンソーシアムである。オブジェクト指向技術のコンソーシアムであるOMGも,電子化文書であるコンパウンド・ドキュメントの規格を制定している。コンパウンド・ドキュメントは,文書を各種情報の容器(コンテナ)と見做し,文書は情報要素のインタフェースを保有する。このインタフェースは,OMGのインタフェース定義言語,IDLにより定義され,OMG準拠のサーバ上のオブジェクトを呼出すことが可能である。OMGのコンパウンド・ドキュメントは,狙いは壮大であるが現実の実装が追い着かず,実現されていない。一方,マイクロソフトのOLEもコンパウンド・ドキュメントであるが,これは私企業の製品である。OLEはマイクロソフトの製品のMS Word以外にも数多くのワープロやDTPに採用され,コンパウンドドキュメントとしてのデファクト標準の地位を獲得したといえる。OLE等による各種アプリケーションと文書とのリンクやデータの埋め込み等の影響もあって,電子化文書のコンテンツにも変化が見られるようになった。媒体が紙からディスプレイに変わったため,色彩や映像が用いられるようになり,情報としての認知効果が高められた。コンテンツのマルチメディア化である。情報の配布形態も紙からネットワークやCD-ROMに変化した。この時点で,コンピュータ画面そのものが電子化文書化したと見ることが妥当であろう。そうなると,文書の検索手段やハイパーリンクのようなナビゲーション手段も電子化文書の一部になったと言えるであろう。

 丁度そのころ,WWWによるインターネットの爆発的なブームが生じた。SGMLのDTDの一種に過ぎないHTMLが,ブラウジング用電子化文書のフォーマットとして一挙に普及した。このHTMLは,機能こそ貧弱であるが,上記の文書の検索手段やハイパーリンクのようなナビゲーション手段を包含した電子化文書である。さらに,これのカスタマイズ用の言語として登場したのがJavaやJavascriptである。これらは,HTML言語の機能を拡張し,エウブ・ブラウザーを一般のクライアント・プラットフォームとすることを可能にした。

 以上の技術を企業システムも放置しておく理由はなく,LANやRDBとエウブ・ブラウザーを結び付け,イントラネットのブームとなった。その状況が,現在,1997年の現状であろう。

 以上を,規格の面から概観すると,当初は,AdobeのPostScriptを除くと,ODAやSGMLのようなISOによるデジュアな規格が先行していたと見ることが可能であろう。その後は,マイクロソフト製品の普及とOLEによるインタフェース仕様のデファクト・スタンダード化が進む一方で,DMA,OMGなどのようなコンソーシアムの規格が浮上してきた。ローカルな処理環境の製品は,マイクロソフトの場合のように製品仕様が規格となり得るが,クライアント・サーバのような,ネットワークやデータベースが問題となる規格は,コンソーシアムのような場での議論を通じて決まるようになりつつある。

 一方,インターネットの普及は,規格の決定に関して新たな力学を提起した。製品の宣伝と配布をインターネットを通じて迅速かつ効率的に行えるようになったからである。そのため,力ある製品の場合は,一瞬にしてデファクト標準が確立されてしまうような状況が生まれつつある。Netscape,Java,PDFなどはその具体例である。このことは,別の見方をすると,無償で配布することを通じてデファクト標準を手に入れることに通じるであろう。エンドユーザから見ると,無償で高機能なソフトウエアを利用できるのでありがたい話であるが,数多くのソフトウエアハウスが消えてゆき,限られた強者のみが生き残る構図が見えてくる。

 以上を概観すると,ISOなどのデジュア規格は殆ど意味を失うに至ったと言えるであろう。これは,経済活動のボーダレス化に伴う,情報通信処理のグローバル化が進展し,コンピュータ画面そのものとなった電子化文書は国家主権の枠組みを超えて流通せざるを得ないためである。このように規格を作る人が,ISOや国家機関からコンソーシアムや私企業に変わりつつある。規格をかつぐ人,使う人は,その規格の制定に関係したコンソーシアムや関係企業の人達であろう。また,特定の私企業の規格であっても,それを普及浸透させるためには,何らかのコンソーシアム的な組織を必要とするであろう。そのような意味では,数多くの会員企業を擁するコンソーシアム的な組織が,規格を作り,かつぎ,使う上で重要な役割を演ずるようになってきたと言えるであろう。

(c)1996 JEIDA