【前へ】

3.6 知的文書インタフェース

3.6.1 先端技術の大衆化

 コンピュータ技術は社会のあらゆる分野での情報化に必須の重要基盤技術であり、「高度情報化社会」を目指してその技術開発推進はこれまで我が国の重要な政策課題であった。例えば通産省大型プロジェクトや第五世代コンピュータ研究開発プロジェクトはわが国の先端コンピュータ技術研究開発の牽引力であった。同様に欧米諸国でも政府の援助で多くの新しい技術が開発されてきた。インターネットがもともと米国における軍事コンピュータ間通信のために DARPA の資金で研究開発されたものであることもその一例である。

 このような開発努力の上に今日の高性能パソコンの出現とインターネットに代表されるコンピュータネットワークの普及が成り立っていると言える。特にコンピュータの価格/性能比の向上は著しく、車に例えると「ベンツが数千円で買えるようになったのに等しい」と言われている。今や、大衆が使用するコンピュータは企業の価格競争の対象となり、もはや国のすることは無くなったかのように見える。国の支援は先端技術をさらに押し進める、例えば超並列マシンの研究などに必要と一般には考えられている。

 本当にそうであろうか?高性能のコンピュータを普通の人が気軽に使えるようになった今こそ「本当に使い易い」コンピュータが期待されているのではないだろうか?大勢の人が使う技術程その社会的影響力は測りしれない。

 現在のパソコンは形も内部アーキテクチャも昔のコンピュータから基本的に何ら変わっていない。たとえノート型と呼ばれようとも相変わらず周辺装置をぶらさげたスタンドアロン指向であり、ソフトに関してもOSと個々のアプリケーションソフトを熟知していないと使いこなせない旧態依然とした使い難いコンピュータのままである。このような状況ではマルチメディアやインターネットも社会の一部にしか浸透しないであろう。21世紀に豊かな国であるためには社会の隅々まで情報化を普及させることが必要であり、それはすなわち裾野ユーザへのコンピュータの利用促進に他ならない。

3.6.2 現状の問題点と将来技術動向

 技術の進歩によりコンピュータやネットワークという先端技術が誰にでも手の届く存在になってきたが、決して使い易くなっているわけではない。

(1)相変わらず紙をベースとした企業活動

 パソコンや携帯端末が普及したといっても企業内部の情報処理や企業間取り引きの多くは相変わらず紙に印刷された文書をベースとして行われている。電子メールによる情報交換の効率アップや WWW をベースとしたイントラネットの活用がはやりつつあるが、社会全体で見るとまだ一部での利用と言わざるを得ない。また、本格的に現行の書類にとって代わるにはパソコンでの文書の扱いはまだ制約が多く、複雑過ぎる。

 そうは言っても、情報の電子化が着実に進んでいることも事実である。理由は情報はひとたび電子化されると、ネットワークにより一瞬にして遠隔地に送ることができ、また様々な加工/分析が可能となるという、紙では到底実現できない便利さが生まれるからである。

 インターネットの出現により情報の電子化は急速に押し進められることになった。WWW により突如として誰もが簡単にアクセスできる広大な情報空間が現出し、各種の新しい情報サービスが台頭しつつある。紙のチラシを配るよりも廉価なコストで何百万人という人に広告することが可能となった。例えば電子新聞もこのような新しい電子情報サービスの一例であるが、紙の新聞の単なる電子化から一歩進んで、個人の興味に合わせて記事を掲載できるパーソナライズ技術が実用化されようとしている(図3.6-1)。

図3.6-1 パーソナル電子新聞

 同様に電子図書館やディジタルライブラリを構築する動きも活発である。これによりどのような山奥に住んでいようとも国会図書館の蔵書にアクセスできる時代が近づいている。

 しかしながらこれらの電子情報を「読む」ためのパソコンは存在しない(注1)。現行のパソコンモニタはテレビの発想で作られており、眺めるには良いが文書を読むには適していない。表示解像度も100dpi前後であり、印刷品質として最低限と言われている300dpiには遥かに及ばない。

 情報電子化を促進するなら同時に紙の品質を実現する新しいディスプレイの開発がなければ片手落ちである。

------------------------------
注1)唯一の先駆的な試みは NeXT マシンであり Adobeと一緒に開発したDisplayPostScriptと高精細 CRT モニタにより真の WYSIWYG の実現を試みた。

 

(2)分散から再び集中へ

 パソコンの普及やダウンサイジングの流行により、メインフレームで集中管理されていた情報が個人の手元や担当部署で処理できるようになってきた。メインフレーム+ダム端末からくる使い難いインタフェースやMIS 本部に牛耳られた自由のきかない情報システムを押しつけられていたエンドユーザにとっては、新たな自由を獲得したことになる。

 しかしながら企業活動の本質が情報管理/情報交換にある以上、分散されたパソコン上の情報がネットワークで流通しなければ価値がない。その実現には実は多くのノウハウが必要であり、安易なダウンサイジングやクライアント/サーバ化が破綻しているのは周知のごとくである。また個人のパソコンが増えるに従ってマシン管理、いわゆるシステムアドミニストレーション工数が急増しているのが実情である。コンピュータの利用技術は進歩したが、コンピュータシステムそのものは本質的に変わっておらず、ネットワーク管理やマシン管理には相変わらず専門の知識が必要とされる。

 結局インターネットの普及によりパーソナル化による分散化と共通サーバ化のトレードオフの再考が求められている。

(3)情報アクセス端末への期待

 情報のサーバ化が進むと必然的にユーザのパソコンはネットワーク経由でのサーバアクセスの道具になって行く。スタンドアロンのコンピュータである必要はなく情報アクセスのためのビューワーであれば良い。

 ワークステーションの世界では早い段階から X Window System によるアプリケーションの遠隔実行が可能であったため、ウィンドウシステムだけを実行する上記ビューワーコンセプトの X 端末が商品化されている。しかしながら自分の端末が「コンピュータではない」ことに心理的な抵抗があったようで期待したほどは市場が伸びなかった。当時はワークステーション全勢の時代であり、利用者の多くがコンピュータの専門家であったことは X 端末にとって不幸であった。

 一方、スタンドアロンで使われることが主だったパソコンには X Window System のようなクライアント/サーバ型のウィンドウシステムが存在せず、手元のパソコンから他のパソコン上のアプリケーションを遠隔実行することはできなかった。しかし、パソコンもLANに接続されるのが普通になった今日ではアプリケーションとウィンドウシステムとの間のインタフェースを横取りして別のマシンのウィンドウシステムに転送するリモートアクセスコントロールソフト[2]が普及してきた。さらに Windows を X Window のようなクライアント/サーバに分離する Intelligent Console Architecture[3]の提案やWebブラウザのプラグインとしてJavaで記述された非常に軽いウィンドウインタフェースを組み込む方法などが提案されている[4]。自宅から会社のコンピュータにアクセスして仕事をするという新しいライフスタイルが浸透しつつあり、会社のパソコンを自宅で、あたかも会社にいるがごとく利用できることが要求されていることからも、今後この流れはますます重要になると予想される。

 ネットワークコンピュータはパソコンの単純化とそれによる低コスト化(500ドルパソコン)を目論んだもので、アプリケーションをJavaのアプレットとして必要に応じて持ってくるというコンセプトで登場した。ビューワーコンセプトに徹しているわけではなく、アプリケーションの動作環境は通常のパソコンと変わらないため「制約が多いだけ」という批判もあり、今のところパソコンとの差別化に成功しているとは言い難い。

 ネットワークコンピュータはしばしば Web 端末とも呼ばれ、WWW へのアクセスに特化した端末を指すのに使われることもある。Web 端末は WWW で提供される情報サービスに対する「ビューワー」という位置づけが明確であり、これからの情報社会における基盤商品になる可能性を持っている。しかしながら、WWW の情報発信は今のところ HTML によって記述されており、通常のワープロで作成される文書のようには細かいレイアウト指定ができないという問題がある。パソコンが情報アクセスの道具になればなるほど前述のごとく文書操作が重要になってくる。

3.6.3 事例紹介:複合文書分散共有システム

 このような背景から報告者等はユーザインタフェースに特化した端末による文書の共有、それによるコラボレーション技術の研究を進めている。基本となるのは考え方はオブジェクト(アプリケーション)の GUI を分離し共有するというShaped Object Model[5][6]である。

1) Shaped Object Model

 基本的なアイデアはオブジェクトのユーザインタフェース(GUI)とそれによって起動される本処理の分離である。さらに GUI 部をスクリプト言語で記述することにより安全で柔軟な共有を実現できることが特徴である。

 以降、本モデルでは GUI 部をオブジェクトの「シェイプ」、本体部を「ボディ」と呼ぶことにする。シェイプとボディはネットワークで常に結合されており、この通信チャネルでメッセージを相互にやり取りしながら処理を進めることで、あたかも完全なオブジェクトがリモート端末で動いているかのように見える(図3.6-2)。

図3.6-2 Shaped Object Model

 オブジェクトは遠隔マシンからアクセスされるとシェイプを返送する。シェイプは糸のついた凧のように通信路を伸ばしながら遠隔マシンへ辿りつく。シェイプは遠隔マシン上で解釈実行されてウイジェットとなり、オブジェクトの GUI そのものを具現化する。ボタンが押されたり、文字が入力されると、対応するウイジェットがイベントをメッセージとして送り、ボディ側で必要な処理が行われる。

2) 本モデルの利点

 本モデルの利点の一つは GUI の生成や制御がかなり利用者側のマシンにオフロードできることである。例えば、ボタンが押された場合に「ボタンが引っ込む」という3D効果はサーバ側ではなく、利用者側のマシンでローカルに処理すれば良い。すなわち、ユーザインタフェースに関わるきめ細かい応対を分散させることができる。しかもこの GUI はサーバ側から転送されるのであらかじめユーザのマシンに組み込んでおく必要がない。

 もう一つの利点はこのような形でボディを共有し、シェイプを分散させることにより、自由度の高い分散共有が実現できることである。共有しているオブジェクトの GUI は各マシンで独立に動作しており個々のユーザはオブジェクトに対して勝手な操作をすることができる。それにより同じオブジェクの違う場所を見ることが可能となる。一方、各ユーザからのイベントは一つのボディで管理されているので、操作結果は全員でリアルタイムに共有可能である。

 さらに、ボタンの位置の変更や上書きのような個々のユーザによるカスタマイズもある範囲で許すことができる。勿論、全員が同じ画面を見ることも可能であり、分散プレゼンテーションの実現にも有効である。

 このように本モデルは、オブジェクトの操作に対してはユーザごとの独立性を許しながら、一貫性を保った共有が実現できる点が特徴である。

3) スクリプトインタフェース

 またシェイプの記述にスクリプトを用いることにより以下のメリットがある。

4) 実現のためのソフトウェアアーキテクチャ

 スクリプト記述によるShaped Object Modelの実現には図3.6-3に示すようなソフトウェアアーキテクチャが必要である。

 キーとなるコンポネントは以下の3つである。

図3.6-3 ソフトウェアアーキテクチャ

5) プロトタイプ試作

 本モデルを検証するのにTcl/Tkスクリプト言語とMachマイクロカーネルを利用した。

 Tcl/Tk[7]は X 用のウイジェットをインタプリティブに簡単に作成できることを特徴とするツールで、本モデルでの「シェイプをスクリプト言語で記述する」という目的に合致している。

 一方、シェイプとボディは各々プロセスとして実行されねばならないこと、しかもボディはネットワークを介して複数のシェイプとメッセージのやりとりができなければならないこと、からMach[8]の提供するメッセージによるプロセス間通信機能を利用することにした。

 Machではプロセス間通信が全てメッセージ転送によって行われるが、その受け取り口はポートという概念で実現されている。ポートはタスクにつながれた入力ホースのようなもので、複製して別のタスクに渡すことにより、複数タスクからのメッセージを受信することが可能になる。ポートがネットワーク透明であることもMachの優れた特徴であり、これにより遠隔ホスト上のプロセスにも、あたかもローカルなプロセスと同じインタフェースでメッセージを送ることが可能である。このようなMachのプロセス間通信機構は本モデルでのメッセージ通信に必要な機能をほぼ満たしている。

 図3.6-4はShaped Objectにより会議開催通知を実現した例である。

図3.6-4 会議開催通知への応用例

 まず、オブジェクトエンジンを起動し、会議開催通知のスクリプトを入力するとそれが開催通知を一括管理するサーバオブジェクトとして振舞う。

 一方、スクリプトのシェイプ部分は出席予定者に送付され、各自のマシン上で開催通知のイメージを表示する。ボディとシェイプは2本のポートで結合されており、ユーザが出席ボタンを押下するとボディ側に「出席」の情報が伝達される。ボディの受信ポートは複数ユーザに共有されている。ボディは出欠等の情報を受け取ると、名前部分の背景色を変えるなどのウイジェットの属性を変更するために必要なスクリプトを全シェイプにブロードキャストし、これにより出席予定者全員が、誰が開催通知を見たか、誰が出席するのか、を知ることができる。また、ユーザが開催通知を開く度に最新のスクリプトが転送されるので、常に最新情報を表示することができる。

6) 文書共有への拡張

 Tcl/Tkで作られるウィジェットベースの GUI は例に挙げた会議開催通知のような定型文書やチケット予約のような情報サービスの実現には適しているが、普通の文書を扱うには単純なテキストウィジェットでは無理があり、やはりワープロ機能が必要となる。一方、HTML はスクリプトによる文書表示を可能としているがワープロがサポートするきめ細かいレイアウトを実現できない。このような文書表示/操作の立場からはOpenDocやOLE2に代表される複合文書のアプローチが有望である。

 複合文書はこれまでのアプリケーション中心から文書中心のユーザインターフェースを実現する。複合文書は異なるアプケーションで作成されたテキスト、図、表、動画などをひとつのページにまとめることができ、ユーザが特定のコンポーネントをアクセスするとそれを作成したアプリケーションが自動的に起動され、必要な編集操作が可能となるものである。

 このような文書操作をShaped Object Modelで考えると、文書がシェイプに、ワープロがボディに相当すると見なせる[9][10]。すなわち文字の追加/削除のような文書への入力操作はシェイプで扱われ、イベントとしてボディに送られてから実際の編集作業が行われることになる(遠隔サーバによる編集は既に、例えばEmacsをリモートの X Window端末から利用するというようなLAN環境で実際に行われている)。さらに、複合文書ではユーザの入力がどのコンポーネントに対してなされているかを決めるためにシェイプ側にも文書構成の情報(シェル機能)を持つ必要がある。複合文書の各コンポーネントが一つのウィジェットに相当していると考えてもよい。このような表示/イベント操作の観点から文書中心インタフェースとは

  • 従来のウィンドウシステム  →  複合文書
  • 従来のウィンドウマネージャ →  複合文書シェル
  • という新しいアーキテクチャへの移行と見なすことができる。

    図3.6-5 複合文書の分散共有メカニズム

     まとめると複合文書の分散共有のためには複合文書シェル、文書を構成するコンポーネントがそれぞれ GUI が分離されて端末で動くことになる(図3.6-5)。現在、アイデア検証のためJava を用いてプロトタイプを試作中である。

    3.6.4 文書技術の課題

     情報ビューワーとしての端末コンセプト、文書表示のための複合文書技術を深めていくといくつかの課題にぶつかる。

    1) ポータブルドキュメント

     PostScriptやその後継である PDF は高品位の印刷品質の実現とプリンタに依存しないデータ表現からポータブルなドキュメント、すなわちどこででも印刷可能な出力形式として普及している。しかしながら、これらの技術は全て「紙への印刷」を目標としておりそれを直接編集することは考慮されていない。すなわち編集は表示イメージに対してではなく、インタプリタの入力となるソース記述に対して行われる。

     一方、ワープロソフトは印刷イメージを画面に表示して直接編集可能であるがワープロごとに独自のデータ構造を持ち、互いに互換性がないのが普通である。従って、受け取り手はその文書の作成に使用されたのと同じワープロソフトを持っていないと見ることができない。

     このように文書の交換が日常業務の基本であるにもかかわらず、コンピュータ上での文書の交換は自由にはいかない。実際には使用するワープロや表計算ソフトを特定メーカーのものに限定するという現実的手段が取られているが、これでは技術の健全な発展は望めない。また、市販ワープロソフトはユーザからの多様な要求に応えるために年々複雑/多機能化の一途であり、かえって使い難くなっている。

     そもそも文書作成はビジネスの基本である。「ビジネス文書の書き方」は習うとしても「紙にどうやって字を書くか」について改めて勉強している暇はない。「文書作成」という行為は情報発信の最も基本形であり、そういう観点からワープロソフトがいかに重要な位置を占めているかを我々はもっと認識すべきであろう。

     ワープロを使いこなすことが企業人として習得すべき必須技術の一つとしてやむ得ないとしても、情報交換の基本である文書は誰がどんなツールで作成しようとも自分の慣れているワープロで直接編集できるべきである。そのためにはワープロに共通する中間的なデータ表現が必要となる。これにはワープロ固有の拡張機能(例えば作表機能など)をどこで実現するかという課題がある。共通機能にしようと思えば誰もが納得する範囲に制約せざるを得ないし、便利な機能を実現しようとすればするほど共通機能としての統一が難しくなる。また、WWW での標準記述言語である HTML がどこまで進化するか、複合文書技術との融合も気になるところである。

    2) 手書き文字認識からユーザの意図の理解へ

     ワープロをもっと簡単化しようと思えば、普段人間が「紙と鉛筆」で行っている自然な操作に近付くことが必要である。この実現にはより高度な手書き文字認識技術が必要となる。例えば入力枠を使わない位置/大きさ自由の文字入力や、文字と図形の自動判別などである。ユーザはいちいち入力モードを切替えたりしたくない。システムがユーザの意図を汲んで自動的に対応すべきである。

     もう少し飛躍して捉えれば、ペン入力とはコンピュータの網膜への直接書き込みに他ならない。人間が描くストロークを「見る」ことにより「ユーザが何をしようとしているのか?」というユーザの意図を理解することが最終的には必要となる。それには音声や画像等の別メディアも駆使する必要があり、いわゆるマルチモーダル対話技術の確立が必要となる。

     そしてこれら手書き文字、音声、画像の認識は結局入力信号の表面的な分析のみでは限界があり、最終的には「文脈理解」という人工知能の積年の課題に再び挑戦することを要求している。

    3.6.5 国が支援する理由

     本稿が対象としている一般ユーザ向けのコンピュータ環境に関して、企業間の健全なる技術競争により技術革新、新市場が創造されることが基本であることは論を待たない。特に製品の成否を決定する標準化はユーザの選択に任せるべきであり、国が押しつけるものであってはならない。

     しかしながら、パソコン市場が一部の米国企業による寡占状態にあることも事実である。厳しい競争のなかで利益を出し企業を存続するためには、技術よりビジネスが優先されるのが当然ではあるが、結果として新しい技術が育たない現状が作り出されてしまった。Appleの創業者であり NeXT で高い先見性を見せたSteven Jobsも「この10年は何も革新がない。Intellectual Boaring」と嘆いている。一企業の力では新しい流れを作る事が非常に困難になりつつある。本稿で述べたような文書中心システムは古くて新しいエディタの問題の再考であり、さらに突き詰めていけば再び AI 研究への挑戦を必要としている。このような技術課題を市場原理の元に研究開発できるとは思えない。このような状況を打開し、将来技術の開発を促進することは重要な課題であり、新しい技術創造による国際貢献にもつながる。

     具体的な支援方法であるが、基本は個々の研究者/技術者の競争であるから国が民間を束ねるような従来方式は望ましくないであろう。むしろベンチャー的な芽を育てることが期待される。例えば小規模研究チームを構成してオフィスを構えるなど、企業や大学の枠からはみ出すような制度も必要であろう。

     米国における技術革新がベンチャー企業により牽引されていることは周知の事実であるが、コンポーネントウェアの実現を狙ったTaligent社、エージェントソフトをいち早く実現した General Magic社、複合文書技術 OpenDocを開発したCIラボ等の存在は改めて米国の将来技術を創造する活力がまだ健在であることを思い知らされた。ビジネスとしては成功していないし、当初から成功は難しいと予想される中でもこれらの企業に夢を託した投資家の存在とそれによって蓄積されたノウハウの将来価値は大きいと言わざるを得ない。

    <参考文献>

    [1]
    坂上、神場、古関、パーソナル電子新聞 ANATAGONOMY の開発と評価、インタラクティブシステムとソフトウェアIV、日本ソフトウェア科学会WISS'96論文集、pp.21-30, December 1996
    [2]
    リモートコントロールソフト、日経バイト、December 1996
    [3]
    Citrix Systems Inc. ICA Technical Paper. http://www.citrix.com/icatech1.htm, March 1996
    [4]
    K.R. Wood, etc. Global Teleporting with Java : Toward Ubiquitous Personalized Computing. IEEE Computer, February 1997
    [5]
    横田、“Shaped Object による情報の分散共有”、情処マルチメディア通信と分散処理研究会 95-DPS-73, pp.69-74, December 1995
    [6]
    横田、“Multimedia User Interface Terminal based on Shaped Object Model”, Proc. of IPSJ Multimeida Japan 96, pp.249-254, March 1996
    [7]
    J. Ousterhout, “Tcl: An Embedded Command Language”, Proc. of Winter USENIX Conf., January 1990
    [8]
    R. Rashid, et.al., “Mach: A New Kernel Foundation for UNIX Development”, Proc. of Summer USENIX Conf., July 1986
    [9]
    羽根、河村、横田、“分散共有アクティブドキュメントの実現方式”、情処、第53回全国大会、3J-6, September 1996
    [10]
    羽根、河村、横田、“情報端末のための複合ドキュメント分散共有方式”、情処、第52回全国大会、2F-5, March 1996

    【次へ】