第 16 部
さまざまなメディアとインターネット との連携

399

第 1章はじめにWIDE プロジェクトでは、既存のさまざまな通信サービスや通信メディア (以下、「既存のメディア」) との連携について検討しさまざまな実装を行なって来た。たとえば、WIDE プロジェ
クト発足当時からのメンバである中村が 1980 年代末に勢力的に研究していた「 UNIX ワーク
ステーションから FAX を制御する機構」の研究は、FAX モデムがまだ存在しなかった当時
としては先駆的な研究であった。また、大野が 1990 年から手掛けている WIDE/PhoneShell
プロジェクトでは、プッシュホンを計算機の入出力インターフェースとする機構の研究開発をつづけており、近年では、視覚障害者の計算機利用支援機構や災害時生存者情報登録システム (IAA) におけるユーザインタフェースとして、今まで以上に注目を浴びている。
また、インターネット上のメッセージをページャに転送する機構として 1991 年に誕生した
WIDE/PCS は、同じような内容の商用サービスが国内で始まるより 5 年も早く実装されていた。このように、既存のさまざまなメディアとインターネットとを連携させる研究はWIDE プロジェクトにとって歴史のあるテーマである。
このテーマに属する研究は、WIDE プロジェクト参加組織のあちこちで行なわれているが、本稿では、慶應義塾大学の徳田・村井・楠本研究室の新美が行なった研究と、東京工業大学の大野研究室で行なった研究に的を絞った。その結果本稿では、全部で 9 人の研究者が 10 の独立した報告を行なうことになったが、本来ならこれらはいずれも１編の卒業論文あるいは修士論文になる研究である。したがって、これら 10 の報告をたかだか数 10
ページの本稿に収容するにはかなり無理な圧縮を行なったことをあらかじめお詫びしておきたい。
本稿の執筆には 10 人が関与した。具体的には、第 1 章を大野が、第 2 章を新美と本庄が、第 3 章を木本と野田が、第 4 章を成田、多田、酒井、門間、田中 が、第 5 章を大野が
担当した。

401

第 2章
既存のメディアとインターネット の融合
本章では、既存のメディアとインターネットの融合を目的とする 2 つの研究に関して報告する。
はじめに、メディア間の融合をはかるためにインターネットをメディアバックボーンとして利用しようとする動きに着目し 、そのためにインターネットが満たすべき要件について述べる。
次に、インターネットと既存のメディアを組み合わせて、誰もがインターネットを利用したコミュニケーションができる環境を提供するためのシステム CIDS について報告する。

2.1

メディアバックボーンとしてのインターネット 機構の研究

2.1.1

背景

人と人とがコミュニケーションをするための手段、つまり互いに情報のやりとりを行う
ための手段がメディアである。電話、ファクシミリ、ラジオ、テレビ 、ポケットベル、手紙などさまざまなメディアがそれぞれ人の持つコミュニケーション能力を増強させている。
しかし 、現在ではこれらほとんどのメディアが独立して存在しており、異なったメディア
間で相互にコミュニケーションをしたり、複数のメディアが連携して人間のコミュニケー
ションを助けたりすることは少ない。しかし 、これらが実現されれば 、より優れたコミュ
ニケーションが可能になり、また、インターネットを利用すれば 、それが可能である。そこで、複数のメディアを融合させ、より優れたコミュニケーションの手段として利用可能にするのが本研究である。また、そのメディア融合の場として、インターネットが有用と考え、それを実証していくことも本研究の目的である。
コンピュータ以外のメディアとも相互に乗り入れ、融合し 、取り込んでいくことにより、ますます有用なものとなっていくものとして、例えば以下のものが考えられる。

 何も持たずに外出した先で、インターネット上にある情報を取り出したいと入った場
合に、電話と FAX があれば取り出せる [?] 。

402

第 16 部

さまざまなメディアとインターネット との連携

403

 移動中でも電子メールをページャ1で受信したい。
 遠く離れたコンサートをインターネットを通じ鑑賞し 、その感動をリアルタイムでステージ上のミュージシャンにフィードバックできる [?]。

 国際電話の通話料金や国際 FAX の通信時間を節約できる。
 パソコンが使えない人でも FAX 感覚で電子メールが送れる。
また、災害時の情報提供や生存者データベースの作成にインターネットを使用する動きがあるが、電話や FAX でもこれらの情報を引き出したり、登録したりすることができれ
ば 、より多くの人が利用できる [?]。
そこで本研究では、多様なメディアがつながるバックボーンとしてのインターネットの役割を考え、それを実現するのに必要なインターネット機構を提案する。
その上で、既存メディアの例として、以下の４つのメディアを取り上げ、各々について
インターネットとの融合について考え、実際に実験を行い、有用性を述べる。

1. ページャunidirectional communication(片方向のコミュニケーション) の代表例としてとりあ
げた。

2. 放送
１対多のコミュニケーションの代表例として取り上げた。

3. 電話
既存のコミュニケーションの道具としては代表的、かつ身近な物である。また、電話は放送と同様、リアルタイム性の高い通信の１つである。

4. ファクシミリ
ファクシミリは、通常の利用方法ではリアルタイム性が高いメディアである。しかし 、インターネットと通信を行う際に、プロトコル変換を行うことによって非リアル
タイムな通信にすることが可能なメディアであり、そのようなメディアの代表例として取り上げた。
2.1.2

インターネット と既存メディアの共存

インターネットはコミュニケーションの道具、知識の共有の道具として発展を続けて来ている [?] 。現在、インターネットには 1000 万台以上のコンピュータがつながっている。この規模はいままでの他のメディアには無い規模を持っている。
1ポケットベルのこと。ポケットベルは商品名で、和製英語である

404

1996 年度

メディアA

WIDE 報告書

メディアB

メディアC

インターネット

図 2.1: インターネットの上にメディア

さらに、他のメディアと違う点としては、インターネットは「双方向性」を持つ点である。この双方向性に関しては他のメディアが規模を拡大する際に捨て去ってきたものであるが、インターネットに関しては現在の規模でも、この双方向性が残っている。
また、インターネットにはつなげばすぐに特別な準備をせずに情報交換ができるという「日常性」もある。
地球全体に広がる情報交換基盤として、インターネットは存在している。

視点 1:インターネット の上にメディア
インターネットは必要最小限の機能で構成されている。複雑な機能は要求されないので色々なメディアをインターネットに乗せるのには比較的簡単である。

(図 2.1)。

視点 2:インターネットが結ぶもの
インターネットはデジタルデータを共有、交換するのに使われて来た。インターネットが結ぶのは、メディアと人、人と人、メディアとメディアである。(図 2.2)。
この図 2.2のメディア C とメディア C' との関係は、インターネットをトンネルとして利用する場合である。たとえば 、メディア C は日本国内の公衆電話網、メディア C' をアメ
リカ国内の公衆電話網とする。日本からアメリカに電話する場合は、通常だと国際電話を使うわけであるが、インターネット電話を使えば 、日本から日本国内にある変換ノード ま
で電話をかけ、そこからアメリカの変換ノード まではインターネットを通り、アメリカの変換ノードから、目的地まで公衆電話網を通って、相手に継ると言ったことが可能なのである。特に、変換ノード の数が増えれば 、必要になる電話料金は全て安価なローカルコー
ルの料金ですませるようにもできる。

第 16 部

さまざまなメディアとインターネット との連携

405

インターネット
メディアB

メディアA

メディアC’
メディアC

図 2.2: インターネットが結ぶもの

視点 3:相互運用性異ったメディアが最小限の約束ごとを共有し 、お互いに正しく協調してコミュニケーショ
ンがとれることを相互運用性という。インターネットでは、各々の自律性、独立性を維持しながら相互運用性を確保しながら発展してきている。インターネットと他メディアとが結び付く際にも相互運用性については充分考慮しなければならない。
2.1.3

メディアバックボーンとしてのインターネット 機構の設計

前節で述べたような点に注意すれば 、インターネットはメディアバックボーンとして機能する。
インターネットと他のメディアとの双方向のコミュニケーションには、以下の点について検討する必要がある。

1. 名前空間の定義、指定方法
2. データ転送プロトコルの検討
3. プロトコルの変換
4. プロトコル補完
5. 変換ノード の発見
6. 課金とセキュリティ
本報告では詳細は省略するが、新美の修士論文 [?] にて検討し 、実際に実験を行い、実証し
ている。

406

1996 年度

WIDE 報告書

表 2.1: 6 つの留意点
メディア

1. 名前空間の定義

WWW → FAX
URL の数字化
モールス符号

2. データ転送
プロトコル

HTTP
FAX

3. プロトコル変換
html → fax
4. プロトコル補完|
5. 変換ノード の発見 はろーダ イアル
6. 課金と|ページャ

放送

メールアドレス

URL
WWW

TPC.INT

電子メール (SMTP)

マルチキャスト
衛星マルチキャスト
資源予約 (実時間)

電子メール→ページャ
ステータスをメールで|DNS, TPC.INT

URL

○

○

双方向通信

セキュリティ
メディア

ファクシミリ

1. 名前空間の定義

TPC.INT
改良型 TPC.INTMIME+SMTP
独自 (実時間)

2. データ転送
プロトコル
3. プロトコル変換
4. プロトコル補完
5. 変換ノード の発見
6. 課金とセキュリティ

2.1.4

電話

FAX → MIME+SMTP 独自
受領メールなど
voice mail
DNS, TPC.INT
DNS, TPC.INT
○

○

まとめ

2.1.3で定義した 6 点について、各々のメディアについて表にまとめてみる (表 2.1)。
今回取り上げた５つのメディアはこれら６つの留意点を配慮し 、インターネットと接続することにより、インターネットと融合できたと考えられる。今後、別なメディアをイン
ターネットに接続しようとした場合も、この６つの留意点に注意して接続すれば 、相互運
用性なども保ちながら、うまく融合することができると考える。
2.1.5

今後の課題

よりメディアの融合がより起きやすくするには、特に以下の４点を検討すべきと考える。

 リアルタイム通信と帯域予約

第 16 部

さまざまなメディアとインターネット との連携

407

 コスト問題など社会的問題の検討
 デジタルデータの著作権問題
 インフラストラクチャとなるための検討
今後はこれらに重点を置き、メディアの融合について検討を続けていく。

2.2

CIDS:さまざまな入出力方式を備えた情報システム

2.2.1

はじめに

インターネットに代表されるコンピュータネットワークの普及に伴ってコンピュータネッ
トワークを利用したコミュニケーションに注目が集められている。大学キャンパスにおいてもキャンパスネットワークを利用したコミュニケーションが行われつつある。現在、キャンパスネットワーク上では主に電子メール、ネットニュースなどを利用したコミュニケー
ションが行われている。
しかし 、これらのコミュニケーションを利用するためには当然のことながらネットワー
クに継ったコンピュータが必要である。このため利用可能な場所や時間が制限されることがしばしばある。また、初心者にとってはこのようなコミュニケーションを利用するためにコンピュータの利用方法を学ばなければならないという問題点もある。このため特に非専門家の間への普及が遅れている例も多い。
このような問題点を解決するために、既に筆者らのグループでは PICKLES プロジェク
ト [?] と呼ばれる公衆情報端末を設置する活動が行われており学内の随所でネットワークを利用できる環境が整いつつある。しかし 、学外や公衆端末を利用できない環境下からはネットワークを利用できないという問題は残されている。
そこで、電話や FAX などの既存のメディアおよび公衆情報端末の双方から利用可能なコミュニケーション支援システムを提案する。
本報告では、まず大学キャンパスにおけるキャンパスネットワークを利用したコミュニ
ケーションの問題点およびコミュニケーション支援システムの必要性について述べる。次に、CIDS と呼ばれるシステムを提案し 、その概要および設計と試作について述べる。
2.2.2

大学キャンパスにおけるコミュニケーション支援システム

大学内におけるコミュニケーションをコンピュータネットワークを用いて円滑に進めようという取り組みはこれまで多く行われてきた。一例としては、MIT の Athena[?][?] 、CMUの Andrew[?] 、慶応義塾大学湘南藤沢キャンパス (SFC)[?] などが挙げられる。しかしコンピュータネットワークを利用したコミュニケーションが全学的に利用されるようになった例は少ない。特に非専門家の間への普及が遅れていることが多い。

408

1996 年度

WIDE 報告書

例えば筆者らの所属する東京工業大学では高速バックボーンである Titanet[?] が 1994
年より稼働しており、ネットワークのインフラストラクチャの整備は進んでいる。
しかし現在のところ学部生の多くはネットワークに接続された計算機へのアカウントを持っていないため学部学生間でのコミュニケーションに利用されることは少ない。学部学生の中でも情報処理演習などのコンピュータを使用する講義を受講する者には計算機セン
ターにおいてネットワークに接続されたコンピュータへのアカウントが与えられる。このためネットワークを利用したコミュニケーションを行うことが可能になる。しかし 、現状
では講義の連絡やレポートの提出などの限られた用途で利用されることが多い。この理由としては、週に数時間しか利用しないコンピュータでは実用的なコミュニケーションはできないということが挙げられる。また、コミュニケーションを取りたい相手が必ずしも全員コンピュータが利用可能とは限らないという理由も挙げられる。このため学部学生間でのコミュニケーション手段としては電話や FAX などの既存のメディアが利用されることが多い。
研究室に所属するようになると各研究室の計算機にアカウントが与えられるため所属する前よりも多くの頻度でコンピュータによるコミュニケーションが行われるようになる。
これは大学キャンパスでの生活時間の多くを占める研究室で利用可能であるという理由が挙げられる。しかし 、研究室という限定された場所でしか利用できないという場所の制約がある。このためネットワークをつかったコミュニケーションと電話や FAX などの既存のメディアを使ったコミュニケーションを併用するケースが多い。
また、コンピュータを利用したコミュニケーションが利用されていく過程での問題点もある。それは利用できる人と利用できない人の間で情報の格差が生ずる [?] という問題である。利用できる者の間のみでコミュニケーションが行われ、利用できない者には情報が伝わらないということである。
このような問題は東京工業大学のみならず他の多くの大学でも同様の問題を抱えていると思われる。以上のような問題を解決する方法として、単に端末室を用意して全学生にアカウントを与えるという方法が考えられる。しかし 、この方法では利用できる場所や時間が制限されるため上記のような問題の解決方法にはならないと考えれる。そこで筆者らは大学キャンパスの特徴を考慮した大学キャンパスにおけるコミュニケーション支援システ
ムが必要であると考えた。
2.2.3

CIDS の概要

CIDS におけるコミュニケーションのモデル

上記のような問題を解決する方法として筆者らが提案するコミュニケーション支援シス
テムが CIDS[?] である。CIDS は、電話や FAX などの既存のメディアと公衆情報端末の双方から利用可能なコミュニケーション支援支援システムである。CIDS では、利用者同士の第 16 部409

さまざまなメディアとインターネット との連携
私書箱

メッセージ

FAX
公衆端末

電話

利用者

利用者

利用者

図 2.3: CIDS におけるコミュニケーションのモデル

リアルタイムなコミュニケーションではなく、メッセージを交換することによる間接的なコミュニケーションを支援する。この CIDS におけるコミュニケーションは私書箱と同様のモデルで説明することができる。(図 2.3) 発信者は、目的の相手もしくはグループ宛の私書箱にメッセージを登録する。そして、受信者は自分の関係する私書箱からメッセージを取り出すことによってメッセージを受け取る。私書箱と違う点は、私書箱からメッセージを取り出しても消えることはなく複数人で一つの私書箱を共有することが可能な点である。

CIDS が提供するサービス

CIDS が利用者に提供するサービスはメッセージの登録、メッセージの取り出しの２つである。
利用者がメッセージを登録する際には、利用者が利用可能なメディアを使ってメッセー
ジを登録する。例えば 、電話であれば音声によるメッセージ、ページャ2にメッセージを入力するときと同じようなタッチトーンによるメッセージ、FAX であれば静止画によるメッ
セージを登録する。メッセージの登録の際に、CIDS では別々のメディアで登録したメッ
セージを組み合わせる機能も提供する。例えば 、電話で登録した音声メッセージと FAX で登録した画像メッセージを組み合わせたメッセージを登録することが可能である。

CIDS では、これらの登録されたメッセージをデータベース化して保存する。データベー
2 一般的にはポケットベルと呼ばれている410

1996 年度

WIDE 報告書

ス化して保存する際に、さまざまなメディアから取り出されることを考慮して情報の表現
形式の変換作業を行う。この作業では、テキストによるメッセージをテキスト音声合成装置を使って音声に変換するというような機械を使って実現できる作業は機械を使って行う。
しかし 、画像によるメッセージをテキストや音声に変換するというような機械では行いにくい作業には 、どのような表現形式で情報が登録されたかを示す情報のみが登録される。
したがって、受信者には情報が登録されていることしか分からない。また、CIDS ではオ
ペレータを用意して、利用者の希望に応じて人の手による情報の変換を希望することもできる。
また、利用者がメッセージを取り出す際にも同様に利用者が利用可能なメディアを使ってデータベースに登録されたメッセージを取り出す。CIDS では利用者が利用しているメ
ディアに合わせた形でメッセージ取り出し方法を提供する。例えば、電話では、簡単なタッ
チトーンの操作によるインタラクティブなメッセージの取り出しを提供し 、FAX について
は、一括処理によるメッセージの取り出し方法を提供している。CIDS では、メッセージの取り出しに関して検索機能なども提供する。
以上のように CIDS では、利用者同士のメッセージ交換サービスを提供する。
CIDS の利用例

筆者らは、大学キャンパスにおいては、特別な機材を必要とせず、使い方が簡単で「いつでも」「どこでも」「だれでも」利用できるシステムが受け入れられやすいと考える。このような考えに基づいて考案された CIDS の大学キャンパスにおける利用例のいくつかをあげる。
たとえば 、サークルにおける連絡に利用することを考える。大学生の生活時間帯や生活場所について考えると授業やゼミなどの特定の時間を除いては、各学生の生活時間帯や生活場所はばらばらである。特に長期休暇中などは連絡を取ることが不可能な場合がしばしばある。このような大学生間における連絡方法には、従来から電話連絡網をもちいることが多かった。しかし 、上記のような理由から電話では連絡がつかなかったり、連絡する者に負担をかけることがしばしばである。全員が携帯電話を持ち歩けば解決することではあるが、大学においては主に経済的な理由から現実的ではない。そこで、CIDS を利用すると上記のような問題を解決することができる。連絡したい者は、サークル用の私書箱にメッセージを登録する。そのサークルに所属する人は自分の都合のよい時間に CIDS からメッ
セージを取り出すことによって情報を得ることができる。しかも、大学キャンパス内にいなくても電話や FAX が利用可能な場所からメッセージを取り出すことが可能である。
また、サークルなどで学外のある場所に集合することを考える。急な集合場所や時間の変更、集合場所への遅刻の連絡などははしばしば起こるが解決しにくい問題である。このような場合に CIDS を利用すると携帯電話やポケットベルなどのような携帯型の通信機器を利用することなく公衆電話や公衆 FAX などを使うことによっても連絡を取ることが可能である。

第 16 部

さまざまなメディアとインターネット との連携

オペレータ部

データベース部

Mew
MIME

DataBase
インターフェイス部

HTTPD

WIDE/PhoneShell

WIDE/PhoneShell
HylaFax

キャンパスネットワーク

公衆電話網

公衆電話網

公衆端末

公衆端末

FAX
電話

利用者

利用者

利用者

図 2.4: CIDS の全体像

利用者

411

412

1996 年度

WIDE 報告書

また、学生間のコミュニケーションのみならず事務などからの業務連絡にも利用できる。
現在では、講義の休講などの事務からの連絡は掲示板を通して行われている。このため掲
示板の前まで移動しなければ情報を得ることができない。このような場合に CIDS を利用すると学内の随所に設置された公衆端末から情報を得ることができたり、また学外からでも電話や FAX などを使って情報を得ることができる。
2.2.4

CIDS の設計

CIDS の設計について述べる。本システムは、「データ管理部」「インターフェース部」「オ
ペレータ部」の３つから構成される。(図 2.4) データ管理部では、利用者が登録したメッ
セージを管理する。データ管理部では、後述する CIDS メッセージクラスタと呼ばれる情報を単位にしてデータベースを作成し メッセージの管理を行う。インターフェース部は、利用者に対して各メディアに合わせたデータ管理部へのアクセス方法を提供する。インターフェース部は、利用者が使用しているメディアに合わせた形でメッセージの受渡しを行う。
オペレータ部では、利用者から登録されたメッセージをさまざまなメディアで取り出せる
ように情報の表現形式を変換する機能を提供する。登録者の希望に応じて画像によるメッ
セージをテキストや音声に変換するというような機械では行いにくい作業はオペレータが手作業で行う。以下では、各部の設計について述べる。

データ管理部
データ管理部では、CIDS メッセージクラスタを単位として利用者のメッセージを管理する。CIDS メッセージクラスタは「発信者」「宛先」「作成日時」「テキスト メッセージ」「音声メッセージ」「静止画メッセージ」の 6 つの情報から構成される。発信者名とは、そのメッセージを登録した人を識別するものである。宛先とは、後述する CIDS メッセージ
ボックス名を指定する。これはモデルのところで述べた私書箱に相当する。作成日時とは、
そのメッセージが作成された日時である。メッセージ本体はどのようなメディアからでも取り出せるように３種類の表現形式を用意する。しかし 、前述したようにメッセージの中には登録されていることを示す情報のみが入る場合もある。
データ管理部では、メッセージの各宛先に応じて CIDS メッセージクラスタの保存場所を用意している。この保存場所を CIDS メッセージボックスと呼ぶ。この CIDS メッセー
ジボックスには、到着した順番に CIDS メッセージクラスタが蓄積されていく。

インターフェース部
公衆情報端末 公衆情報端末によるインターフェース部を実現するために、 WWW システ
ムを利用する。利用者から入力された情報は CGI を使って登録される。利用者がメッ
セージを取り出す場合は通常の WWW をブラウズするのと同じようにメッセージを

第 16 部

さまざまなメディアとインターネット との連携

413

表したアイコンをクリックすることによって簡単にメッセージを見ることができる。
これを実現するためにインターフェース部では定期的にデータ管理部にアクセスしてデータベースに登録されている全てのメッセージを取り出し HTML 形式に変換する作業を行なう。PICKLES で実現されている公衆情報端末は IC カード の抜き差しによってログ インおよびログアウトを実現している。したがって、ログ インの際にWWW クライアントが立ち上がるように設定しておくことによって初心者でもマウスだけで容易にメッセージを見ることが可能になる。
電話 電話によるインターフェース部を実現するために、WIDE/PhoneShell[?] [?][?] を利用する。WIDE/PhoneShell を利用することによって、電話回線の制御および DTMFの検出等を実現することが可能である。利用者は、音声ガ イダンスにしたがって必要事項をタッチトーンを使って入力する。それに続けて、メッセージの登録の場合は音声によるメッセージもしくはタッチトーンによるメッセージを選択してから実際にメッセージの入力を行う。[?] タッチトーンによる入力はページャにメッセージを入力する操作と同様である。受け取りの場合は、さらに音声ガ イダンスにしたがって
タッチトーンを使って選択しながらインタラクティブにメッセージを聞く。
FAX FAX によるインターフェース部を実現するために、HylaFax および WIDE/PhoneShellを利用する。利用者は電話の場合と同様に音声ガイダンスに従って必要事項の入力を行う。それに続けて、メッセージの登録の場合は FAX を送信し 、受け取りの場合はFAX を受信する。電話と違う点はメッセージを取り出す際にはインタラクティブに行われるのではなくて、一括処理によって行われる。

オペレータ部
オペレータ部では登録者の希望に応じてメッセージの表現形式の変換を行う利用者からオペレータによる情報の表現形式の変換作業を要求されたなメッセージは、オペレータにMIME 形式のメールとして届けられる。オペレータは Mew[?] などの MIME 形式のメールを扱えるメールリーダを使用して情報の変換作業を行う。作成されたメッセージは、データ管理部に渡され CIDS メッセージクラスタに変換されてデータベースに登録される。
CIDS の試作

CIDS で提案するコミュニケーション支援システムの妥当性を確認するために既存のさまざまな技術を組み合わせてプロトタイプシステムを作成することにした。プロトタイプ
システムでは、以下のことを実現した。

 WIDE/PhoneShell の技術を利用した音声によるメッセージの登録 HylaFax を利用した FAX によるメッセージの登録414

1996 年度

電話

WIDE 報告書

Netscape
Mosaicetc.

WIDE/
PhoneShell

CIDSメッセージ
FAX

HylaFax

E-MailSendmail

登録プログラム

HTTPD

スプール

データベース

図 2.5: プロトタイプの全体像

図 2.6: CIDS のホームページ

第 16 部

さまざまなメディアとインターネット との連携

415

図 2.7: FAX によるメッセージ

 WIDE/BBS を利用したプッシュフォンによるメッセージの登録 電子メールによるメッセージの登録 World Wide Web ブラウザを利用した情報の閲覧
現在のプロトタイプシステムでは、ファイル名に情報の種類を表す拡張子を付けたファイ
ルをスプール用のディレクトリに置くと監視プログラムがそれを取り出して、World Wide
Web のページに登録する仕組みになっている。プロトタイプシステムの全体像を図 2.5に示す。
音声によるメッセージは、WIDE/PhoneShell システムを用いて留守番電話と同様のシステムを実現し、利用者が吹き込んだ音声を au 形式の音声ファイルに蓄積した上でスプールに登録する。FAX によるメッセージは、FAX モデムで受け取った画像イメージを画像ファイルに落した上でスプールに登録する。プッシュフォンによるメッセージは、WIDE/PhoneShell
システムを用いて利用者が入力した DTMF によるメッセージを解釈してテキストファイ
ルにした上で、スプールに登録する。
電子メールによるメッセージは、CIDS 用の疑似ユーザに送られたメッセージをスプー
ルにコピーすることによって登録する。そして、スプールに登録された情報は情報の種類
および日時を見てデータベースに登録する。その際、音声によるメッセージは、wav 形式、
ai 形式にも変換され、３種類の音声ファイルとして登録される。

416

1996 年度

WIDE 報告書

図 2.8: 電子メールによるメッセージ
利用者からどのように見えるかを画面のダンプを追って説明する。図 2.6は、CIDS のホームページである。まず、情報が登録されると図 2.6のように情報の形式を表すアイコンと日時が表示される。音声によるメッセージにアイコンが３種類あるのは、それぞれ au 形式
wav 形式、ai 形式の３つを表しているためである。
図 2.7は、１番上の FAX のアイコンを押したときの様子である。図 2.7のように、FAXで登録されたメッセージを見ることができる。図 2.8は、上から２番目のメールのアイコンを押したときの様子である。図 2.8のように、メールで登録されたメッセージを見ることができる。図 2.9は、上から３番目のアイコンを押したときの様子である。図 2.9は、音声ファイルをダウンロードしているところである。このダウンロードしたファイルを再生す
れば 、メッセージを聞くことができる。
2.2.5

まとめ

本報告では、大学キャンパスにおいてキャンパスネットワークを利用したコミュニケー
ションに着目し 、その問題点および解決方法について検討した。その解決方法の実現の１つとして CIDS を提案し 、設計および試作システムの作成を行った。今後は、公衆情報端末と併用して CIDS を多くの人に利用してもらい、有効性を実証していく予定である。

第 16 部

さまざまなメディアとインターネット との連携

図 2.9: 音声によるメッセージ

417

第 3章
情報提供サービス
本章では、PICKLES 、CITRUS 、DENKO と呼ばれる各プロジェクトについて述べる。
これらは情報提供システムに関するプロジェクトであり、それぞれ公衆情報端末、カード型携帯端末、電光掲示板を利用しているという特徴を持つ。

PICKLES は 、誰もが必要な場所でインターネット上のサービスを利用可能にするために街角に公衆情報端末を設置し 、初心者がインターネットへの第一歩を踏み出す足掛かりになる計算機環境を提供する。

CITRUS は、大学内で快適な情報サービスを提供するために、カード 型携帯端末と公衆情報端末を組み合わせ、大学のように地理的に広い空間でも、大学内の誰もが平等に情報サービスを受けることができる環境を提供することを目指している。である。

DENKO は、畳大の電光掲示板を用いて、コンピュータネットワーク上の情報を、ある
特定の集団にブロードキャストすることができる環境を目指した研究である。

3.1

PICKLES

3.1.1

はじめに

インターネットの利用者は近年著しく増加しているが、多くの人にとってはいまだ日常的に利用できるわけではない。またインターネットを利用している人にとっても、利用できる場所は自宅やオフィスの端末の前に限られており、必要な時に必要な場所で必要な情報を参照できるわけではない。現在インターネットを「いつでも、どこでも、だれでも、快適に」利用できる環境が求められており、今後もこの需要は増加するものと考えられる。
この要求に対して著者が提案するのは、多人数で共有するインターネット向け公衆端末
を、街角など公共の場にひろく設置するという方法である。著者がすすめる PICKLES プ
ロジェクトでは、公衆端末を随所に設置することで、場所の制約をうけずにインターネッ
トを利用できる環境の実現を目指している。現在実験段階として、東京工業大学内での環境構築をすすめている。PICKLES プロジェクトの目標は、単に多人数での利用に適した端末の開発に留まらず、目標とする「環境」、環境を実現するための「多数の要素技術」、要素技術を稼働させるための「プラットホーム」のすべてを視野にいれたシステム設計を

418

第 16 部

さまざまなメディアとインターネット との連携

419

行なっており、この点に特徴がある。
著者はこれまでにプラットホームである公衆端末と、いくつかの要素技術の開発を行なった。PICKLES プロジェクトが開発した端末 (PICKLES 端末) は管理の容易さや ID カードの利用など 、多くの特徴を持つ。
著者はこれまでにプラットホームである公衆端末と 、いくつかの要素技術の開発を行なった。本報告は 1996 年度において、PICKLES プロジェクトが行った活動について述べる。最初に PICKLES プロジェクトの概要を述べ、PICKLES プロジェクトが開発した端末(PICKLES 端末) が持つ管理の容易さや ID カードの利用などの特徴について述べる。最後に利用者を対象として行なっている試験運用について述べる。
3.1.2

PIKCLES プロジェクト

インターネットの普及は確実に進んでいるとものの、現実には全ての人が平等に利用できる環境になっているわけではなく、実際に利用できるのは未だ一部の人に限られている。
また大抵の場合、利用できるのはは自宅やオフィスの端末の前に限られてしまい、必要な情報を必要なときに参照できるわけではない。インターネットが真に普及し 、日常的なコ
ミュニケーションの手段となるためには、それがいつでも、どこでも、だれでも、快適に利用できるようになることが必要であるといえる。
こういった問題を解決するために著者らは 1995 年より PICKLES プロジェクト [?] [?][?] [?] をすすめている。PICKLES プロジェクトでは多くの人が場所に依存せずインター
ネットを利用できる環境を構築するために、「公衆端末」の開発と設置を行なっている。こ
こでいう「公衆端末」とは街角など随所に設置され誰もが使える、インターネットを利用するための端末である。PICKLES プロジェクトでは著者らが所属する東京工業大学 (以下東工大) 学内での環境構築を当座の目標としている。

PICKLES プロジェクトの中心的課題は公衆端末の開発であるが、単に多数の利用者を対象とした端末の開発だけを目指すものではない。まず多くの公衆端末を円滑に運用するためには、そのための管理技法を確立しなければならない。また誰もが公衆端末を利用できるようにするためには、使いやすいインターフェースの採用などとともにその学習手段の提供も求められる。場合によっては、利用者に対する教育が効果的な対処法となることもある。公衆端末の開発はそういった要素すべてを視野にいれて行なう必要がある。したがって、公衆端末ハード ウェア、ソフトウェア、管理手法、利用者教育などを含めた、全体のシステム設計開発が PICKLES プロジェクトの課題になる。
公衆端末を学内に設置することで、任意の場所でインターネットを利用できる環境を実現するほか、さまざまなサービスを提供することができる。例えば大学においては、「学内の掲示板の電子化」「学生間の情報交換システム」「事務手続きの窓口」などがその例である。また熟練していない利用者にとっては、所属組織などの変化によって利用する計算機環境が異なり、対応するためには大きな労力を要するという問題がある。PICKLES 端末を
学内共通のプラットホームとし 、コンピュータリテラシー教育や管理者育成のための統一420

1996 年度

WIDE 報告書

カリキュラムを実現することで、学内のどこでも同じ知識、経験が活用できるようになる。

PICKLES プロジェクトを普及の推進活動という視点でとらえると、少数の利用者を対象とした試験運用から実際の公衆端末の設置までのいくつかの試験運用を中心に考えることができる。試験運用として次の 3 段階を定めた。

1. 特定の少数の初心者に対する公衆端末の試験的な提供
2. 特定多数を対象とした運用実験のための公衆端末の提供
3. 不特定多数に対しての公衆端末の提供
PICKLES プロジェクト全体の目標を念頭において公衆端末の設計を行なうことで、いずれの段階でも用いることができる共通のプラットホームとしての端末の設計が可能になる。これには最初の試験運用で操作方法を憶えた利用者が、そのまま実際の公衆端末を利用することもできるという利点がある。以降では PICKLES 端末の設計、そこで用いられている管理技法について述べる。

3.1.3

端末設計

PICKLES プロジェクトではプラットホームとなる端末に必要な機能を、仕様書として規定しており、仕様書に則った端末を PICKELS 端末と呼ぶ。ここでは PICKLES 端末仕様を定めた目的と、その効果について述べる。ここで述べる事柄の多くは PICKLES プロ
ジェクトに特化したものではなく、一般的な計算機の仕様決定の際にも考慮にいれられる内容である。PICKLES プロジェクト全体からみた公衆端末設計の位置付けは、プロジェク
トで共通して利用するプラットホームの設計である。この端末は小規模な試験運用のみならず、広範囲での運用にまで用いられる。したがって PICKLES 端末は、低価格で高い保守性を持ち、容易に端末の導入が行なえる必要がある。
現在家庭用の低価格インターネット端末が注目をあびている。これらは「 500 ド ルコン
ピュータ」と呼ばれることから、概ね 5 万円前後の価格で販売される。対して PICKLES
端末は一台 50 万円程度を目安としている。しかし 、前者が家庭で数人規模で共有することを前提としているのに対し 、PICKLES 端末は数十人から数百人で共有することを前提としている。概算すれば 、前者が 5 人で 5 万円の機械を共有するのに対して、PICKLES 端
末は 50 人で 50 万円の機械を共有するというコンセプトである。
またシステム開発のコストのうち、開発後の保守に費やされる割合は大きい。保守性を上げることはシステム開発全体のコストを下げることにつながる。故障の回復の際には 、作業量の軽減とともに作業時間を短縮することも重要である。なぜなら、作業中には利用者へのサービスが停止することになるからであり、代替サービスを容易に提供できるような体制も求められる。

第 16 部

さまざまなメディアとインターネット との連携

421

端末仕様
PICKLES プロジェクトで用いる公衆端末の試作機は IBM-PC/AT 互換の計算機 (以下AT 互換機) を元にしている。AT 互換機には、市販の部品の組み合せで任意の構成の計算機を組み立てられるという特徴がある。また、さまざまな部品が多くのメーカから提供されており、誰でも低価格で入手できる。これは上記の条件 1 を満たす。
しかし公衆端末に任意の構成を認めると、その選択肢の多さから機能にばらつきを生じることになる。そこで PICKLES プロジェクトでは端末の構成についてのガイドラインとして「 PICKLES 端末仕様書」を作成した。仕様書に基づいて制作された端末を「 PICKLES
端末」と呼ぶ。仕様にもとづいて開発した PICKLES 端末の試作機が図 3.1である。

図 3.1: PICKLES 端末
仕様書では端末の処理能力や表示能力などが規定されている。幾つかの部品については、その設定なども細かく規定されている。仕様書では端末の処理能力や表示能力などが規定

422

1996 年度

WIDE 報告書されている。幾つかの部品については、その設定なども細かく規定されている。PICKLES
端末の特徴として PC カード インターフェースの搭載や着脱式ハードディスクケースの採用が挙げられる。PC カード インターフェースは利用者認証のための ID カードや、外付け
救急箱 (後述) を利用するために用いる。また PICKLES 端末ではハードディスクを 2 台搭
載し 、それぞれを容易に着脱可能な引出し型のケースに格納する。このような構成にしたことによる利点は後述する。さらに PICKLES 端末では大型のディスプレ イ装置の利用を薦めており、実際図 3.1の試作機は 20 インチのディスプレ イを採用している。これは複数の利用者が同時に画面を見ながら作業することを考慮にいれたためである。
3.1.4

管理技法

ハード ディスク管理技法
高い保守性を実現するために PICKLES 端末に導入された管理技法について述べる。
PICKLES 端末は管理作業の省力化、「管理作業に要する手間を軽減すること」「管理保守
作業に要する時間を短縮すること」「端末の導入が容易であること」の実現を念頭において設計されている。端末の保守作業の多くは広い意味でハードディスクの保守である。OS のインストールからアプリケーションのインストール、バージョンアップなど 、すべてハードディスクの内容の保守であるといえる。したがって、ハードディスクの保守性を上げる
ことが、管理作業の省力化につながると考えられる。例えば端末の故障時にハードディス
クだけを取り出して代替機に移し換えることで再起動できれば 、復旧までの時間は短縮できる。そこで、ハードディスクに記録される情報のうち、端末間で共有できる情報とできない情報を分離しるために、OS が管理している情報を次の 4 種類に分類した。
A. 端末ハード ウェア固有の情報

PICKLES 端末の仕様では、ハード ウェア構成に適度な自由度を持たせている。 そのため端末ごとに異なる情報が存在する。 イーサネット
インターフェースやビデオボードの種類といった情報がこれに含まれる。
B. ホスト 固有の情報

IP アドレスやホスト名などの、ホストを識別するための情報がこれに含まれる。
C. 利用者が管理する情報

ホームディレクトリやスプールディレクトリ のように、利用者が持つ情報がこれに含まれる。

すべての端末で共有可能な情報である。OS やアプリケーションプログラ
ムの多くはこれに含まれる。

D. 共通の情報

PICKLES 端末には 2 台のハードディスクが搭載されており、2 台はそれぞれ「システムディスク」「ユーザディスク」と呼ばれる。システムディスクにはすべての端末で共有可能な情報 (D) のみを格納し 、ユーザディスクには A,B,C の情報を格納する。通常の運用では
PICKLES 端末はユーザディスクとシステムディスクの組みを装着して動作する。

第 16 部

さまざまなメディアとインターネット との連携

423

現在 PICKLES 端末は OS として BSD/OS を用いている。BSD/OS では上記の A〜D の情報は、それぞれ概ね異なったディレクトリに格納されている。例えばホスト固有の情報
B は/etc/ 、利用者が保持する情報 C は /home や/var といったようにディレクトリごとに情報が分けられている。そこで、これらの情報をユーザディスク中の異なるパーティションに置いた。
/etc/のディレクトリには共通の A,B,D が混在しているので、A と B だけ /etc3/というディレクトリに格納し 、ユーザディスクにおいた。各ファイルには/etc/からシンボリック
リンクを張り、通常のパスでも参照できるようにした。
図 3.2に標準的な PICKLES 端末のディスクのパーティション構成の一例を示す。

wd0 (system disk)
wd0a /
48MB
wd0b swap 96MB
wd0e /usr 372MB
wd1 (user disk)
wd1e /etc3 6MB
wd1f /var 96MB
wd1g /local 414MB
図 3.2: デ ィスクパーティション構成
このような構成にしたことによって次のような利点がある。

 あらたに PICKLES 端末を立ち上げる時に必要な作業は、あらかじめその端末用に作成したユーザディスクと、すべての端末の共通なシステムディスクの組を端末に装着するだけである。システムの設定、立ち上げに要する労力は従来のものに比較し 、大幅に減少している。

 システムディスクとユーザディスクを分離したことにより以下の特徴が生じた。
{ システムディスクが破損したときには交換するだけで修理ができる{ 災害などの非常時にはユーザディスクだけを退避させればよい。
{ PICKLES 端末本体を修理することになっても、利用者の情報が入ったユーザ

デ ィスクは手元で管理しておくことができる。
現状ではハード ウェア固有の情報 (A) が明確に分離されていないという問題がある。情報 (A) は本来ハード ウェアに不揮発性メモリなどを持たせて記録するべきものであるが、現在はユーザディスクに記録されている。このため、例えば全く異なったビデオカードを

424

1996 年度

WIDE 報告書

持つ端末間ではユーザディスクを入れ替えることができない。端末間のディスクの交換を可能にするために、現在の仕様ではビデオボード の種類を限定するなどの、不必要に厳しい制限を設けている。この問題を解決する方法としては、以下の 3 つがある。

1. ハード ウェア構成の動的検出および自動設定 (Plug and Play) に完全に対応した構成にする。

2. PC カード の不揮発性メモリなどに情報を記録し 、カードを端末に付属させる。
3. フロッピーディスクを有効活用する。
現状では Plug and Play に対する製品と OS の対応が不十分であるので、1 番目の方法は適当でない。2 番目と 3 番目の方法は基本的には同じ方針である。ハード ウェア固有の情報は、外部の記憶媒体に記録しておき、端末本体に付随させる。端末起動時に必要に応じてその情報を参照するのである。実現の容易さ、記憶媒体のコストの点から 3 番目の方法を用いる予定でいる。

端末設定の省力化
PICKLES 端末ではハードディスクの構成を工夫することで、ホストに依存する情報すな
わち端末の設定に関る情報を切り分けた。また設定情報が書かれているファイルや設定の為の処理にいくつかの変更を加えた。方針としてネットワーク上の何らかのサーバに依存しないことを前提とする。これは端末設計のところで述べたように、PICKLES 端末での「導入の容易さ」には従来のネットワークの管理運用形態に大きな変更を加えずに PICKLES
端末を導入できるという事柄も含まれるからである。
PICKLES 端末は起動時に以下のような処理を行なう。

 ユーザディスクの自動検出 ユーザディスクとシステムディスクのバージョンの整合性の検査
 ネットワークインターフェースの自動検出
PICKLES 救急箱

PICKLES 端末には光磁気ディスク装置やテープ装置などの取り外し可能な外部記憶装置を搭載していない。また、OS のインストール作業などに不可欠な光ディスク装置も標準仕様に含まれていない。これはコストを抑えるためであるが、実際ユーザディスクのバッ
クアップなどを行なう際にはバックアップ装置を利用した方が効率的である。そこで、外付けの SCSI デバイスを収めたケースを用意した。このケースは 30cmx20cmx20cm の大きさ
で 5 インチサイズの SCSI 機器を 3 台を搭載できる。これに PCMCIA 型の SCSI インター

第 16 部

さまざまなメディアとインターネット との連携

425

フェースカードを併用することで、必要に応じて PICKLES 端末で外付けの SCSI 機器を利用できる。このケースを「 PICKLES 救急箱」と称している。

システム管理エージェント の利用
複数の端末を管理する手段として、筆者の研究室で開発中の magP[?] [?] 、NMW [?] [?]といったネットワーク管理のためのエージェントシステムとの連携を図っている。公衆端
末では管理対象の端末が遠隔地に分散している運用形態が想定されるため、自律的プログ
ラムによる管理システムの利用は必須である。
また、公衆端末にはさまざまな設置形態があり、端末と管理システムとの間にファイアウォールがあるために通常の通信が不可能で、かつファイアウォールの管理方針の変更が困難という場合がありうる。これが従来行なわれてきたファイルシステムを共有することによる端末管理を不可能にしている原因であり、またそのような環境では動作記録などの管理情報の伝達も出来ない。しかしこのような環境でも HTTP[?] を用いた通信だけは可能な場合が多い。そこで管理エージェントが用いるメッセージ交換や、エージェント自体の伝達に HTTP を用いる方法を検討している。
3.1.5

利用者サービスID カード を用いた認証サービス

従来 UNIX ではパスワードを用いた認証方式がとられてきた。この方式は認証に特殊な機材を必要としないという利点がある反面、情報の漏洩に弱い。特に利用者が初心者でセキュリティに対しての意識が低いと、自分のパスワードを他人に教えたりといった問題が起きる。そこで PICKLES では ID カードと暗証番号を組み合わせる方式を採用した。ID
カードには PCMCIA 型のカードを用いる。PICKLES 端末仕様には PCMCIA を搭載することが規定されているため、ID カードを用いる際に新たに読みとり装置を追加しなければならないといった問題はおこらない。
PICKLES システムでは、ID カードとして IBM ChipCard を用いている。このカードはROM にカードごと固有の ID 番号が記録されており、その ID 番号を用いてカード の識別ができる。またそれ以外にもメモリ内に氏名、login 名、パスワード 情報、利用可能時間、利用可能時刻などが記録されている。

バーコード を用いた認証サービス
廉価版の ID カードの一例として、バーコードを用いた ID カード の試作を行った。実験は開発用の PICKLES 端末にバーコード 読みとり装置を接続して行なった。この読みとり
装置は AT 互換機のキーボード インターフェースに接続する方式を用いている。バーコードに記録された文字列をキーボードからの入力として扱うことができる。キーボードとバー426

1996 年度

WIDE 報告書

コード 読み取り機からの入力を切り替える装置と併用することで ID カードからの入力を待っているときには、キーボードからの入力を無視することができる。
実験系ではいくつかのバーコード 体系のうち、最も一般的に用いられている CODE39 というコード 体系を用いた。CODE39 は ANSI 標準 MH10.8M-1983 で規定されている。実験系では xdm に対して、バーコード 読みとり装置からの入力をログイン名とパスワードとして解釈する機能を追加した。バーコード を用いた ID カードを用いることは、実はパスワードをそのまま紙に書いているのことに等しい。しかし例えば使い捨てパスワードを利用する際には有効である。現在使い捨てパスワード の計算機を持ち歩かない場合、使用する回数分のパスワードを紙に書いて持ち歩くことが行なわれている。この方法だと入力に手間がかかるという欠点があるが、紙の代わりにバーコード の形で持ち歩けば入力の手間は省ける。セキュリティ面では本質的に紙に書く方法と変わらないものの、人間が目でみて読みとることは難しくなるので、コピーされにくくなるという利点がある。
またパスワード 以外の文字列を記録する手段としてもバーコードは有効である。例えばURL を記録したカードを利用者に配ることで、利用者はそのカードを読みとり装置にかけるだけで目的の URL を入力することができる。
ID カード システムを実現するプログラム

PICKLES 端末で認証に用いるさまざまな機器を扱うため、X- Window System 付属のディスプレイマネージャ(xdm) を改造し 、pxdm を開発した。また ID カードの抜出を検出してログアウトを行なうために、X- Window System 付属のセッションマネージャ (xsm)を改造し 、pxsm を開発した。
pxdm はさまざまな認証のための機器を扱うことができなければならない。現在のところ
PICKLES 端末では ChipCard を用いた ID カード とバーコード を用いた ID カードを利用できる。pxdm は両者のデバイスからの入力を受け付ける。pxdm は X-WindowSystem 標
準添付の xdm を部分的に修正することで実装した。パスワード 入力要求のウインドウを生成する際に、PCMCIA スロットを監視するデーモン (mcmd) と通信を開始する。PCMCIA
スロットに ChipCard が挿入されたら、pxdm は ChipCard の内容を読み取りあたかもログ
イン名とパスワードがキーボードから入力されたかのように処理を行なう。今後 pxdm は
磁気カード リーダなどにも対応する予定である。
PICKLES セッションマネージャ

pxsm は PCMCIA スロットを監視して、利用者の ID カードが抜かれると同時に強制的にセッションを終了させる。また ID カードの記録されている利用制限時間をよみこみ、利用可能時間をしらべて時間がなくなったら強制的に終了させる。画面上にボタンを表示し 、これが押された場合でも終了させる。また利用時間に制限があるカード の場合は、残り時間を常時画面の表示させておくこともできる。pxsm は PCMCIA スロットを監視するプロ

第 16 部

さまざまなメディアとインターネット との連携

427

グラム (mcmd) と通信し 、ID カードが抜かれた場合のログアウト処理や、カードに記録されている時間制限情報に基づいたログアウト処理を行なう。
3.1.6

試験運用

特定少数を対象とした試験運用
かねてより事務職員と教官との間の連絡に電子メールを使えるようにしたいという要望があった。それに応えるかたちで 1996 年 3 月に東工大 情報理工学研究科の事務室に PICKLES
端末を設置した。現在 PICKLES 端末は 4 名の職員の間で共有されており、電子メールを用いた職員間や職員教官間での情報共有を実現している。この試験運用は PICKLES プロ
ジェクトにおける特定少数の利用者を対象とした試験運用にあたる。
導入の際の設置先ネットワークの管理者との折衝などを通して、管理ポリシーの異なる
ネットワークへ設置手順の確立や遠隔管理の実現の必要性など 、幾つかの課題が明らかになった。

特定多数を対象とした試験運用
PICKLES プロジェクトをすすめる過程で、多数の人を対象とした提供の場として東工大図書館に端末を設置し 、試験運用する機会を得た [?] 。図書館の役割の一つに「提供された情報を求めて人々が集まる場」というものがある。その延長線に「 インターネットに接する場」としての図書館があると著者らは考える。
PICKLES 端末の技術を用いた WWW 端末の試験運用が付属図書館と著者らとの共同により行なわれることになった。現在 PICKLES 端末を用いた WWW 端末が大岡山本館に 3台、長津田分館に 2 台設置されている。端末ハード ウェアは PICKLES 仕様に基づいたものが購入された。そのため動作試験は、あらかじめ用意したディスクを装着するのみで終了し 、PICKLES 端末の特徴である導入の容易さが実証された。
PICKLES 端末は IBM ChipCard を用いた ID カードによる認証システムを搭載している。このシステムではパスワードを用いた通常の方式と異なり、端末本体のキーボードを操作する必要がない。そのためキーボードに不慣れな初心者でも容易に扱うことができる。
また一回の利用時間を制限できるので、今回の運用のように、一時的な利用者を対象とし 、且つ無制限な利用は禁止したい場合に、このシステムは特に有効である。
3.1.7

PICKLES 端末仕様

ここでは PICKLES 端末ハード ウェアに求められる条件について述べる。まず各部品の選択肢についての一覧表を示し 、続いて各部位について個別に述べる。なお、この仕様は1996 年でのものであり、今後予告なしに変更する可能性がある。部品ごとに条件の強さを次の 5 段階で表す。

428

1996 年度

WIDE 報告書

class A 絶対にこのメーカのこの型番でなければならないもの
class B

メーカー型番不問だが、条件を要するもの

class C

メーカー型番不問だが、設計変更を (店などで ) 行ってもらう必要あるもの

class D

メーカー型番不問だが、こちらで何らかの設定変更が必要であるもの

class E

メーカー型番はまったく不問

class
CPU
B
memoryB
BIOS
B
MotherBoard
B
2ndCacheE
拡張バス
B
ChipSetE
VideoCard(Chip)
B
VideoCard(RAMDAC) B
HDD
A
FDD
E
PCMCIA
A
SerialControler
B
PararelControlerB
IDE InterfaceE
HDD CaseA
PC CaseE
FaxModem
C,D
Mouse or TrackballE
KeyBoard
B
Soundcard
B
EthernetCard
B
DisplayE
SpeakerE
Microphone
E
部品

名称

条件

参照機

Pentium

90MHz or over
32MB 以上

PCI/ISA

Pentium90MHz
32MB
Phoenix
Micronics M54Pi
SRAM 256KB
PCI*3,ISA*4

WD2540S3 86C968
WD2540
WD25403.5" 2HD 2mode
16550 を使用
双方向通信可能101 キーボード
SoundBlaster16 PnP 非対応
後述
21 インチサイズ

Bullion II
onboardonboardonboard
SI-115A
PRAGMATIC H1428
Genius EasyTrak
SoundBlaster16 /V
SMC ElitePlus16T
NANAO 77F

CPU Intel 製 Pentium 90MHz よりも高速なものである必要がある。これは利用者に対して端末の処理能力が低いことによって、ネットワーク自体に対して誤った認識を与え

第 16 部

さまざまなメディアとインターネット との連携

429

ないためである。また他社の Pentium 互換 CPU についても、BSD/OS で動作が確認されているものは利用可能である。
メモリ 32MB 以上である必要がある。上限は設けていない。可能であれば EDO-RAM を推奨するが限定はしない。
BIOS IDE HDD のパラメータを自動的に検知してくれるものを推奨する。設定されているパラメータと実際が異なっている場合でも問題なく起動できるものを推奨する。大抵の場合は新しい BIOS にしておけばよい。
MotherBoard 特に指定はないが、今後は ATX 準拠のもので電源の制御ができるものが望ましい。
2 次キャッシュ 最低でも SRAM 256KB は搭載することを推奨する。512KB あっても実質的に効果はないという報告がある。可能であれば PB-SRAM を推奨する。

拡張バス 現状では PCI と ISA の両方を搭載しているもの。個数に指定がある。例えば
MultiI/O や SoundBlaster は最近では OnBoard のものも増えているが、PCMCIA ス
ロットや Modem カード、Ethernet を使うのであれば、注意が必要。仮に MotherBoardになにもない場合、ISA 上には Ethernet,PCMCIA,Multi I/O,Modem,SoundBlasterで 5 枚のボードが差されることになる。多くのマザーボードにはマルチ I/O ボードの機能が搭載されていることと、外付けモデムを使用することを考慮すると、ISA バ
ススロットは最低 3 つ必要である。
ChipSet ChipSet はシステム全体の動作速度などに影響をおよぼすが、安定して動作する

ものであればよい。
ビデオカード Xaccel 1.2 が対応しており、1152 ド ット x 900 ドット 65536 色表示可能なものである必要がある。評価用の端末では S3 社の 85C968 を搭載したカード を利用している。これ以外のビデオカードを用いる場合は端末の設定を変更する必要がある。
ハード ディスク HDD は WesternDigital 社の WD2540 である必要がある。なぜならばディスクのパラメータを揃える必要があるからである。しかし 、現在 WD2540 は入手が困難になっている。幸いなことに現在多くの BIOS はハードディスクのパラメータを自動検出できるので、この制約はほぼなくなったものと考えられる。
フロッピーディスクド ライブ 3.5" 2HD 2 モード または 3 モードであればよい。
PCMCIA インターフェース BullionII 以外の外付け PCMCIAドライブであっても、WILD-

BOAR で動作が確認されているものであればよい。Vadem の VG468 を用いているものはこれにあたる。TwinCabin や EPSON の DYO-211 などがこれにあたる。

430

1996 年度

WIDE 報告書

シリアルインターフェース まったく不問。ただしモデムを内蔵する場合、com2 を無効に出来なければならない。
パラレルインターフェース 双方向通信可能なものを推奨。
HDD ケース HDD を着脱可能なものにするための、引出し式ケースである。これは SI-

115A でなければならない。

ファックスモデム V34 対応の faxmodem。内蔵でも外付でも構わないが、スペースや電源のひきまわしを考えると内蔵をすすめる。内蔵モデムの場合は com2 に設定できる事。
また出荷時に com2 に設定すること。
マウス シリアルの 3 ボタンのものを推奨する。3 ボタンでもものによっては 2 ボタンしか認識しない物もあるので、「 UNIX3 ボタン対応」をうたっているものか、MouseSystem
完全互換品というのが一つの目安になるだろう。PS/2 でも可。
キーボード 利用者の嗜好による。
SoundCard SoundBlaster 16 完全互換品である必要がある。純正品である必要はないが、ハード ウェアのレベルで完全に互換性をもっていなければならない。PnP の製品は利用できない。

EthernetCard 以下にあげるカードは動作実績がある。しかし導入の時点で、後述するように IRQ と I/O メモリアドレスを設定する必要がある。

 SMC Elite plus16 T
 3COM 3C509B
SMC Elite16 の場合は、irq 10 i/o 0x300 maddr 0xcc000-0xcffff に設定しておくこと。3C509B の場合は irq 10 i/o 0x250 に設定すること。
NE2000 はいくつもの互換品で動作実績があるが、正式にはサポートしていない。
ディスプレイ 大人数がいる環境で用いる場合 (同時につかうのが何人かが問題ではなく、多くの人がのぞきこみやすいようにという意味をこめて) 現時点で最大の 21 インチのマルチシンクのモニターを薦める。高いものの方がいいものらしい。
3.1.8

まとめ

公衆情報端末を用いた大学内のネットワーク利用環境の構築について述べた。本文中でも述べたように、PICKLES プロジェクトは大規模なプロジェクトである。本論文では
PICKLES プロジェクトの目標および全体像について述べ、それを実現するための要素技

第 16 部

さまざまなメディアとインターネット との連携

431

術について述べた。これまでの PICKLES プロジェクトの活動は、確実な成果を挙げており学内学外で評価を受けている。
しかしプロジェクト全体の規模から考えると、これまでの活動は目標実現のための足場を築いてきたにすぎない。全体としてみるとプロジェクトの進行に遅れがあることは否めないものの、確実に前進し 、成果をあげているといえる。
むしろ本格的なプロジェクトの活動は今後であり、引続き PICKLES プロジェクトを推しすすめていきたいと考えている。
3.1.9

これまでの活動

これまでの活動について述べる。
1995 年度は主にプロジェクトの立ち上げに費した。1995 年 8 月より公衆端末の試作機の開発の着手した。1995 年 12 月の WIDE 研究会と 1996 年 1 月の PTT で発表を行ない、ともに参加者の諸氏から多くの示唆を得ることができた。1996 年 3 月の情報処理学会第 52
回全国大会では、関連研究とあわせて 2 件の講演をおこなった。関連研究の講演では大会優秀賞を授与された。
1996 年度はプロジェクトの拡充に主に費した。7 月の情報処理学会分散システム運用技術研究会では、PICKLES 端末の管理技法について発表した。9 月の情報処理学会第 53 会
全国大会では図書館での応用について発表した。PICKLES 端末は 9 月より東工大図書館
において試験運用を開始している。
1997 年 1 月より、著者らの研究室内の利用者端末を PICKLES 端末相当の構成に変更している。これは PICKLES 端末を元にした研究室ないのネットワーク環境の試作を目的としたものである。

3.2

大学内情報システム{CITRUS

3.2.1

はじめに

大学や企業内で日常的に行なわれている情報交換を、ネットワークを用いて円滑に行ないたいという要求は多い。しかし多数の構成員からなる組織では、すべての利用者に対して平等にサービスの利用の機会を提供することは難しい。このような問題を解決するために、著者らは非常に小型の携帯端末と、学内随所に設置された公衆端末を組み合わせた利用環境を提案する。
本報告ではまず大学内の情報システムの特徴と、それに即したサービスの提供方法について述べる。次にその結果に基づいて大学内情報システム CITRUS を提案し 、その概要および設計と実装について述べ、CITRUS が大学内情報システムの提供手段として有効であることを示す。なお、この研究についての講演は情報処理学会第 52 回全国大会において大会優秀賞を受賞した。

432
3.2.2

1996 年度

WIDE 報告書

大学内情報システムの特徴

大学内の情報交換をコンピュータネットワークを用いて円滑に行なおうという取り組みはこれまで多く行なわれており、全学的なネットワーク環境の構築が成功した例はある。
しかし特に非専門家の間へのネットワークの普及が遅れている例も多い。例えば著者らが所属する東京工業大学（以下東工大）では高速バックボーンである Titanet が 1994 年度より稼働しており、ネットワークインフラストラクチャの整備が進んでいる。しかし現在のところ学部学生の多くはネットワークに接続された計算機のアカウントを持っていないた
め、構成員の多数を占める学生間での情報交換に、電子メールなどのネットワーク上の通信サービスが活用されている例は少ない。また事務処理における部署間での情報交換にも、
ネットワークが有効利用されているとはいえない。学生に対しての事務からの通知などは旧来通りの物理的な掲示板を用いた方法が中心であり、事務と学生間の情報交換を円滑に行なう手段が求められている。学生間の情報交換と、事務と学生間の情報伝達を合わせた「学生を中心としたオンライン大学内情報システム」には、非常に多数の離散して活動している利用者が任意の場所で任意の時に情報システム利用できることが求められるという特
徴がある。
3.2.3

情報サービスを提供する手段

提供手段の比較
多数の利用者を対象とした情報サービスの提供方法には、さまざまな形態が考えられる。
例えば「方法 1：多数の端末を設置した端末室を設ける」や「方法 2：低価格ネットワーク
端末を用いた端末室を設ける」が挙げられる。これは従来からみられる方法で、ワークス
テーションやパソコンを多数設置した端末室を設ける方法である。後者は最近注目をあつめている低価格インターネット端末を利用する方法である。方法 1 にくらべて導入コストが押さえられること、管理に費やされる労力を押さえられるといった利点がある。いずれにせよ端末室の場所の確保や、利用者は端末室まで移動しなくては利用できないといった問題点がある。
また「方法 3：利用者に携帯端末を常時携帯させる」という方法もある。無線通信機能を持った携帯端末を用いることで、学内の任意の場所でサービスを享受することができる。
しかし携帯端末を持ち歩く煩わしさや、任意の場所での無線通信が可能な環境を準備するためのコストなどの問題がある。そのように大きなコストをかけて導入しても、得られる
通信速度は一般的に有線のものに劣る。
「方法 4：キオスク端末を設置する」はキオスク端末あるいは公衆端末と呼ばれる端末
を学内の随所に設置して利用者に提供するものである。ここでの公衆端末とは屋外に設置することも考慮して開発されたネットワーク端末で、低価格ネットワーク端末が数人程度の利用者で共有することを想定しているのに対し 、公衆端末は数十人から数百人の利用者を想定している。公衆端末では一台の処理能力や価格をあげる代わりに共有する人数を増

第 16 部

さまざまなメディアとインターネット との連携

方法 1
方法 2
方法 3
方法 4
方法 5

条件 A
×
×
◎
△

条件 B
◎
◎
△
◎

条件 C
◎
◎
×
○

条件 D
×
×
◎
△

○

○

○

○

433

表 3.1: 情報サービスを提供する方法の比較
やしてコストの分散を図っている。
最後にあげる「方法 5：キオスク端末と超小型携帯端末とを組み合わせる」は、著者らが本論文で提案する CITRUS を用いてサービスを提供するものである。この方法は、公衆端末の場所と端末数に関する制約を、超小型の携帯端末を併用することで解決しようというものである。ここで想定している超小型携帯端末とは、すべての利用者が常時携帯できる重量と大きさのものである。この端末には無線通信機能は持たせず、公衆端末に接続して直接通信できる機能を持たせる。公衆端末から必要な情報を随時転送することで、任意の場所で情報を閲覧できるし 、結果的に公衆端末の占有時間を減らすこともできる。
以上の比較をまとめると表 3.1になる。表中の◎, ○, △, ×はこの順に、条件をより満たしていることを表す。条件 A〜D は以下の内容である。この表は著者らが提案する方法 5が、バランスがとれた方法であることを示している。
条件 A 場所の制約をうけずにサービスを利用できること。
条件 B 携帯するものの重量などの点で、利用者に負担をかけないこと。
条件 C 導入の際のコストが低いこと。
条件 D 一部の利用者による端末の占有が起こらないこと。

コスト の比較
著者らが提案する方法 5 のコストについて、低価格ネットワーク端末を用いた場合との比較を行なった。低価格ネットワーク端末は「 500 ドル端末」と称されていることから、500ドル前後の価格を想定する。著者らは公衆端末と超小型携帯端末の価格をその 10 倍と 10分の 1 、すなわち公衆端末が約 5000 ドル、超小型携帯端末が約 50 ド ルと見積もっている。
実際、PICKLES プロジェクトで開発した公衆端末は日本国内で 50 万円以内で購入できる。
また超小型携帯端末の要求仕様をほぼ満たすと思われる玩具が数千円以下で販売されてい434

1996 年度

WIDE 報告書ることから 、これを 50 ド ルと見積もることも妥当である考える。以下では低価格ネット
ワーク端末を用いた場合を A 、方法 5 を B として比較する。
主な利用者として学生を想定すると、時刻ごとの利用率に大きくばらつきが生じることが予想される。休み時間など 、利用が殺到したときに最低限の検索参照のサービスを提供するためには、A では参照閲覧の間端末を占有する必要があるが、B は超小型携帯端末に必要な情報を転送するだけでよい。両者の利用時間には、例えば A が 20 分に対し B が 1
分というような大きな差が生じることが予測できる。ここで A の利用時間が B の a 倍であると仮定すると、全利用者 N に対し A が m 人に 1 台の端末を要するのであれば 、B はam 人に 1 台の端末でよい。利用者が N=a 人を下回るような時間帯は、A と B ともに同じように公衆端末を利用しても利用者の待ち時間には影響がない。この場合、公衆端末の機能は B の方が高いため利用者に提供できるサービスの質は高い。さて、このときに全体のコストを計算すると次のようになる。

2AB

2 台数 = 50000 2のコスト : 公衆端末の価格 2 台数 + 携帯端末の価格 2 利用者数 =500000 2
2 + 5000 2
Nのコスト : ネットワーク端末の価格
N

a

m

N

m

となり、両者の差は

Aのコスト

0 のコスト = 50000 2 2 ( 1 0 10 0 101 )
B

N

m

am

となる。したがって A よりも B のコストの方が低くなるような a; m の値は
m

0 10 + 100a<0の条件を満たす。低価格ネットワーク端末は数人で共有するような使いかたを想定している。仮に 5 人に 1 台の割合で低価格ネットワーク端末を導入する（ m = 5 ）とすると、a > 20であれば B のほうが A よりもコストを低くできる。
実際にサービスが活発に利用されるようになると、交換されるメッセージの数も増える
ため、a の値はさらに大きくなることが予想される。したがって、上の条件のもとでは低価格ネットワーク端末と公衆端末とでは、コスト面で大きな優劣があるとは言いがたい。
3.2.4

CITRUS の概要

CITRUS が提供するサービス

以上の考察に基づいて著者らが 1995 年より開発を行なっているのが CITRUS[?] である。
CITRUS は公衆端末と超小型携帯端末の連携によって、大学内の円滑な情報交換を実現す

第 16 部

さまざまなメディアとインターネット との連携

435

る。対象とする利用者は学生を中心とし 、学生と大学事務間の情報交換、および学生間の情報交換を円滑におこなうことを目指している。CITRUS はこの 2 種類の情報交換を掲示
板という単一のモデルによって処理する。複数の学生に対しての告知なども個人宛てのメッ
セージも、共に一旦掲示板に書き込まれる。受け取る側は自分が必要とするメッセージを掲示板から検索し受け取る。CITRUS の主な機能は「利用者への情報伝達」「利用者間のメッセージ交換」「定型文書の送受信」である。
CITRUS を用いて伝達される主な情報は、講義内容や休講案内などの利用者に対しての告知である。利用者は空き時間などに自分の超小型携帯端末を公衆端末に接続し 、必要な情報を検索して携帯端末に転送する。転送した情報は、携帯端末上で任意の時に任意の場
所で参照できる。個人対個人、グループ間でのメッセージ交換も同様である。返信を含めメッセージを送信する場合は、公衆端末を用いてメッセージを編集することもできるし 、携
帯端末上で編集したメッセージを公衆端末を介して送信することもできる。
また利用者から大学事務などへ定型文書を送信する例として、履修申告などの書類提出が挙げられる。その形式は年ごと、季節ごとに変化する場合がある。CITRUS では必要に応じて書式情報を獲得し 、必要な箇所を編集し送信する。
CITRUS における超小型携帯端末

前述のように、CITRUS での超小型携帯端末は重量や大きさ、価格を抑えることに重点を置いた。現在の主流である携帯末端と携帯電話などの通信機器を組み合わせる方法では端末の小型化には限界がある。すべての人がつねに携帯できる大きさと重さを考えて、著者らは CITRUS での超小型携帯端末の条件として以下の内容を定めた。

 名刺大である。（ 90mm × 55mm ） 軽量である。 （ 100g 以下）
 端末自体が利用者へのユーザインターフェースを持つ。
 公衆端末との間で通信を行なう方法を持つ。
 利用者認証に用いることができる。
CITRUS における公衆端末

CITRUS を実際に運用するためには、公衆端末を学内に広く設置する必要がある。著者
らがすすめる PICKLES プロジェクト [?] [?] [?] は、公衆端末を用いたインターネット利
用環境を目的としており、CITRUS 運用のためのプラットホームととらえることができる。
PICKLES プロジェクトで開発された公衆端末は既に学内の複数箇所に設置され運用されており、CITRUS を運用するための下地は整っている。

436
3.2.5

1996 年度

WIDE 報告書

実験系の設計と実装

実験系の設計CITRUS で提案する情報システムの妥当性を示すために、実験系の設計および実装を行なった。実験系では利用者への情報伝達および 、利用者間のメッセージ交換の実現を目的とした。実験系は「掲示板部」「公衆端末部」「超小型携帯端末部」「認証部」の 4 部分から構成される（図 3.3 ）
。
認証部

利用者

pinm
認証用個人情報

cctr

ctrss
ctplm
PCMCIA

mcmd

個人情報
検索結果
送信メッセージ

メッセージスプール

掲示板部

超小型携帯端末部

公衆端末部

図 3.3: 実験系の構成交換される情報はメッセージという単位で処理される。メッセージはヘッダ部とボディ部からなる。ヘッダ部には一行ごとに送信元、送信先、日付などの情報が記述され、ボディ部には任意のテキストが記述される。後述する ChipCard の標準的な表示能力の制限により、実験系ではボディ部に含めることのできる文字を英数字と片仮名のみに限定している。
メッセージの例を図 3.4に記す。
from:kimoto@is.titech.ac.jp
to:ohnolab
ID:test961207002756.5476
date:Sat Dec 7 00:27:56 JST 1996
limit:Sat Dec 7 18:00:00 JST 1996

5:00 303 ゴウシツ ニ シュウゴウ
ヒッキヨウグ ヲ ジサンスルコト

図 3.4: メッセージの例
利用者は自分が必要とする情報を指定するために、検索条件を記述する。検索条件はヘッ

第 16 部

さまざまなメディアとインターネット との連携

437

ダまたはボディ部に含まれるキーワードを指定する。検索条件は、結果を表示するためのメニューの構造と併せて、図 3.5のような形式で記述される。検索条件はこの記述形式で記述され、携帯端末中に記録されている。利用者が携帯端末を公衆端末に接続した際に、検索条件が公衆端末側に読み込まれ、条件に基づいてメッセージが検索され、結果はこの記述形式に基づいてメニューに表示しやすいような形式で携帯端末に転送される。

実験環境
実験に用いた環境について述べる。公衆端末には、別記の PICKLES プロジェクトで開発された PICKLES 端末を用いた。PICKLES 端末には PC カード [?] インターフェースを搭載することが仕様として規定されているため、全ての公衆端末で PC カード の利用ができる。現時点での PICKELS 端末は OS として BSD/OS 2.1 を採用している。さらに
BSD/OS 2.1 で PC カード インターフェースを扱うために、WIDE プロジェクト、北陸先端科学技術大学院大学などが中心になって開発し 、株式会社フォアチューンより配布されている WILDBOAR[?] を用いている。
携帯端末には IBM ChipCard TC-100（以下 ChipCard ）を用いた。ChipCard は PCMCIA
TypeII のカードで、8bitCPU と 128KB の SRAM を内蔵し 、液晶ディスプレ イと簡単なキーボードを搭載している。またカードごとに固有の番号が ROM に記録されており、IDカードとしても利用可能である。単体で使用する場合 ChipCard は 8bit のコンピュータとして動作し 、内蔵メモリに記録されたプログラムを実行することができる。ChipCard を他のコンピュータの PCMCIA スロットに装着した場合、ChipCard はメモリカードとして扱
われ、コンピュータ側から ChipCard 内蔵のメモリに対して読み書きができる。これを用いて公衆端末側から ChipCard に情報を書き込み、その情報を ChipCard 単体で参照することが可能になる。ChipCard は標準では英数字と片仮名のみ表示できる。漢字を表示する
ソフトウェアも公開されているが、実験系では扱う情報を英数字と片仮名のみに限定した。
ChipCard で動作するプログラムの開発環境としては、MS-DOS 上で動作するクロスア
センブラが提供されている [?]。著者らは独自に BSD/OS での開発環境を構築した。特に X-WindowSystem で動作する ChipCard エミュレータはデバグ作業の効率化に有効であった。

実験系の実装実験系を構成する各部について述べる。
掲示板部 掲示板部は、メッセージを保存するスプールと、これを管理するプログラム（
ctplm ）からなる。スプール内では一つのメッセージが一つのファイルに保存されている。ctplm はメッセージの登録（書き込み）と検索（読み込み）を処理する。ctplm
は書き込みの要求を受け取ると、スプール内で一意のファイル名を決定し 、メッセー
ジの内容をそのファイルに書き込む。読み込みの要求と検索条件を受け取ると、ス438

1996 年度

WIDE 報告書

def retrieve {name("ジムカラ")
from:jim} JIM
def retrieve {name("キュウコウ")(keyword:kyuko) && (from:@lectures)} KYUKOdef retrieve {name("ソノホカ")
retreive("サークル") :CIRCLE} MISC
def main {name(" メイン ")retrieve("キュウコウ") :KYUKO
retrieve("ジムカラ") :JIM}....

図 3.5: 検索条件の例
プール内のファイルを検索し 、条件に合致するものを返す。また定期的にメッセージを調べ、有効期限を越えたものは削除する。
認証部 認証部は、認証用情報のデータベースとこれを管理するプログラム（ pinm ）からなる。認証情報は ChipCard の正当性の確認に用いられる。実験系ではデータベースには ChipCard 内の利用者情報の MD5[?] の結果が保存されており、公衆端末部から送られてきた値と保存されている値を比較し正当なカード か否かを判別する。また
pinm は大学事務などが所持している個人情報などの管理提供を行なう。現時点では個人情報として利用者が申告している講義の一覧を管理している。
公衆端末部 公衆端末部は、装備されている PCMCIA インターフェースを管理する mcmdと、超小型携帯端末と掲示板部とのメッセージの仲介を行なう ctrss という二つのプ
ログラムから構成される。また利用者とのインターフェースも ctrss の機能に含まれる。利用者が ChipCard を公衆端末に挿入すると、ctrss は以下の処理を行なう。まずChipCard の ID と利用者情報を読み込み、ID と利用者情報から正当なカードであるか否かを認証部と通信することで調べる。次に ChipCard のメモリを調べ、送信メッ
セージがあったら掲示板部に送信し書き込む。続いて ChipCard から検索条件を読み込み、掲示板部から条件に合ったメッセージを検索し 、検索条件に記述されているメ
ニュー形式の情報に基づいて、メッセージを ChipCard に書き込む。

第 16 部

さまざまなメディアとインターネット との連携

439

超小型携帯端末部 超小型携帯端末部には利用者の氏名などを記した利用者情報が記録されており、またメッセージの閲覧/送受信を行なう cctr が稼働する。cctr の閲覧機能
は ChipCard 内に書き込まれたメッセージをメニュー形式で表示する（図 3.6 ）。検索
条件は表示するメニューの構造も表しており、ctrss は表示に適した形式で ChipCardに結果を転送する。これは ChipCard への処理の負担を軽減させるためである。また
cctr には送信するメッセージの編集や検索条件の編集機能も含まれるが、実験系では両者は未実装になっている。

図 3.6: 超小型携帯端末部

3.2.6

実験系の評価と議論

実験系の評価と問題点試作した実験システムを用いた実際のメッセージ交換では、携帯端末を公衆端末に接続し必要な情報を転送し終えるのに要した時間は数十秒程度であった。また、ChipCard の表
示能力であっても、従来掲示板を用いて伝達されていた類の情報であれば 、十分表現可能であった。実際 ChipCard の表示能力は、現在の多くのページャと同等かそれ以上であり、日常的な情報交換においても CITRUS は有用であると考えられる。
しかし実験系にはいくつかの問題点がある。まずメッセージのスプールが単一のサーバで管理されているため負荷が集中してしまう。またスプール内のメッセージには、個人間でのみ共有されるべき情報が含まれるにも関らず、暗号化されていない。公衆端末と掲示板部との間にファイアウォールが存在する場合があり、直接通信するためにはファイアウォールの設定を変更しなければならない。認証が ChipCard の情報のみを用いているため、ChipCard
を持ってさえいれば情報を検索できてしまう。ChipCard と公衆端末との接続に用いられている PC カード インターフェースは、PC カード インターフェースは電気的に接続するものであるため、 耐久性や使い勝手に問題がある。

440

1996 年度

WIDE 報告書

今後の課題
実験系の運用経験をふまえ、問題点を改良した実験系 2 の開発を現在行なっている。実験系 2 には以下に挙げるような特徴がある。

 メッセージのスプールを他のデータベースシステムに置き換える。これによりこれに
より処理の分散化などをデータベースシステムに任せることができる。

 ファイアウォールを越えるための通信方法を導入する。 必要に応じて電子メールやHTTP[?] を用いてメッセージを交換する方式を検討している。

 公開鍵暗号方式を用いて秘密性を確保する。ChipCard 内に利用者の秘密鍵を 記録しておき、プライベートなメッセージには署名暗号化して送信する。 このため pinm の機能として公開鍵の管理が追加される。 また必要に応じて全部あるいは一部の情報については暗証番号を入力しないと 検索できないような機構を導入する。

 実験系では ChipCard 内の情報の記録形式は独自のものを用いている。しかし著者らのとりくみとは別に ChipCard 内に MS-DOS のファイルシステムを構築してしまう
方式 [?] が現在主流となっており、CITRUS もその方式に 移行する。

実験系では特に大きさを重視して ChipCard を選択したが、その他の多くの携帯端末での利用も検討する必要がある。その際には各端末の異なった表示能力に対応できるようなメッセージの形式の設計も検討しなければならない。また現時点では価格や開発環境、入手の容易さの点で PCMCIA 型の ChipCard を選択したことは妥当だが、今後非接触型の
カード の採用も検討する必要がある。

3.2.7

まとめ

大学内情報システムとして公衆端末と携帯端末との連携による方式を提案し 、その有効性について議論し 、その方式を実現する CITRUS の設計と実装について述べた。CITRUS
によって場所の制約をうけずに利用可能な情報サービスを、利用者に平等に提供できることを示した。この方式は本文中で述べた条件下においてはコスト的にも優れている。
現在ネットワークを用いた情報システムの利用形態として、さまざまなものが提供されている。場所に依存せずに利用可能な環境を目指した場合、「どれだけのものを持ち歩くべ
きなのか」という点が問題になる。これについては利用者の生活様式や嗜好にもよるため単一の手段では解決できず、いくつもの手段が互いの利点欠点を補いつつ共存し 、全体として快適な利用環境が構築できると著者らは考える。CITRUS が提案する、最小限の携帯端末と遍在する公衆端末との連携方式はそういった手段の一つであり、今後も情報システ
ムの一手法として発展していくものであると考えている。

第 16 部

さまざまなメディアとインターネット との連携

3.3

DENKO:電光掲示板制御プロジェクト

3.3.1

はじめに

441

インターネットの急速な普及によりさまざまな情報がその上で提供されるようになった。
しかし現状では一部の利用者がオフィスや家庭の端末の前でその情報を参照しているにすぎない。例えば図書検索サービスなどの場合は、端末の前で個人で利用するのが適してい
るが、天気予報のように端末の前に限定せず多くの人に伝達したい同報型のサービスもある。情報の種類に応じた提供手段が必要である。そのための方法としては、情報の入出力
手段を通常の端末に限定せず、電話や FAX やラジオなどの多数の入出力手段を積極的に利用するというものがあげられる。
今回 NTT 移動通信網株式会社, シャープ株式会社と大野研究室との共同研究として大型
電光掲示板を用いた情報提供システムの開発を行なう機会を得た。このシステムは上で述
べたさまざまな機器を用いた情報システムの一端を担うものである。
本報告では、まず複数の情報伝達手段を相互接続することの利点と、その中での電光掲
示板システムの位置付けについて述べる。次に今回行なわれた電光掲示板システム開発の実際について報告する。
3.3.2

インターネット 上での情報伝達

インターネット 上での情報伝達の現状
近年のインターネットの普及は著しい。その上では WWW,e-mail,NetNews などさまざ
まな方式による情報交換が行なわれている。しかしその普及の度合が完全でないことから、
以下のような問題が生じている。

 多くの場合、会社や大学を離れてしまうと、インターネットの利用ができなくなる。
最近では家庭での利用も増加しているとはいえ、パソコンやワークステーションの前での利用に制限されることに変わりはない。

 すべての人がインターネットの利用者であるとは限らないため、情報交換が可能なのは、その利用者間に限られてしまう。また新規に利用を開始することは、初心者にとっては容易ではない。
上記の問題を解決するには以下の方法が例として挙げられる。

1. 通信機能を有する携帯型の端末を常に持ち歩く。
2. 携帯機器を持ち歩かなくとも行く先々で常にインターネットが利用できる普遍的な環
境を実現する。

442

1996 年度

WIDE 報告書

方法 1. としては VIP[?],DHCP[?] を始めとして多くの取り組みが世界的に行なわれている。方法 2. としては UbiquitousComputing[?] での取り組みが挙げられる。また著者らによる取り組みとして以下のようなものが進められている。
WIDE/PhoneShell 通常の電話網とインターネットを結びつけ、両者のあいだの情報交換を可能にするシステムの研究開発を行なっている。また、そのシステムを利用したネットワーク管理システムの研究開発をしている [?]。
PICKLES 「いつでも、どこでも、だれでもインターネットを利用できる環境」の構築を目指し 、公衆情報端末を設置するプロジェクトを進めている [?]。
CITRUS カード 型端末とキオスク端末を組み合わせることで、あらゆる場所で手軽に情報にアクセスできる、大学内情報システムを開発している [?]。
CIDS 既存のメディアおよびコンピュータの双方から、データベースを介した間接的な情報伝達を可能にするシステムを開発している [?]。
文献 [?] では、複数のメディアとインターネット上のサービスとを有機的に結合する方法について述べている。インターネット上のサービスを利用するための入出力機器として、電話、FAX などの既存のメディアを利用することが特徴である。それらのメディアは既に遍在しており、これによって場所に依存しないサービスの享受が可能になる。また、日常的にはインターネットを利用していない人でもその恩恵を受けることが可能になる。また、この枠組は従来からあるインターネット上のサービスや、その他著者らの活動などを相互に結びつけるものであるとも言える。
DENKO プロジェクト

これまで著者らが扱ってきたメディアは主に個人での利用を想定したものであった。しかし インターネット上で交換されている情報のなかには、放送型の伝達手段が適したものも存在する。例えば掲示板のような手段を用いた実験が求められていた。今回 NTT 移動通信網株式会社、シャープ株式会社、大野研究室との共同研究として、大型の電光掲示板
を利用する機会を得た。そこで電光掲示板を用いた情報提供システムの開発を目的としたプロジェクトを「 DENKO プロジェクト」として立ち上げた。
DENKO プロジェクトの目標には次にあげるものがある。

 コンピュータ (特に BSD/OS が稼働している計算機) から、電光掲示板を制御する
 インターネット上で提供されている情報や他のメディアでの情報を統括的に扱うための表現形式を作成する

 その表現形式に基づいて、電光掲示板を用いた情報提供システムを開発する

第 16 部
3.3.3

さまざまなメディアとインターネット との連携

443

開発方針と設計

この節では複数のメディア間で相互に情報をやりとりする利点と、その方法について述べる。

メディア間での情報流通の方法
現在用いられている情報伝達の手段として、電話、FAX 、ラジオ、テレビ 、新聞などが挙げられる。個々の手段を用いて送ったり受け取ることのできる情報の形式は、それぞれ異なっている。伝達に用いられる情報の形式もそれぞれ異なっている。そのため、異なる
メディア間で情報の送受を行うことは容易ではない。
メディア間での情報の相互交換を可能にすることで、特定のメディアにしか流れていな
かった情報を、複数のメディアに流すことが可能となる。これにより、利用者が受け取ることのできる情報の量は増加するとともに、受け取る手段の選択の幅を広げることもできる。
異なるメディア間で情報を授受するには、以下の 3 つが必要である。

1. メディアに依存せず扱うことのできる抽象的な情報形式（以下抽象情報形式と呼ぶ）の定義

2. 抽象情報形式と個々のメディア固有の形式との間で、情報を相互変換する機構
3. 個々のメディアを用いて情報を伝達する機構
以上を図示すると図 3.7になる。図 3.7ではメディアとして「電光掲示板」「 FAX 」「 WWW 」の 3 つについてのみ示してあるが、これ以外のメディアを用いる場合も同様である。今回の電光掲示板を用いた情報伝達システムの開発も、これに則って行なった。

電光掲示板による情報流通
電光掲示板を用いた情報提供システムを開発するためには、以下の 3 点を実現する必要がある。

1. 抽象情報形式の定義
2. 抽象情報形式から電光掲示板の制御プロトコルへ変換する機構
3. 電光掲示板の制御
DENKO プロジェクトでは 、電光掲示板の制御方式に依存する 2. および 3. を手がけることにした。また 2. を「抽象情報形式から電光掲示板制御形式へ変換する機構」「電光掲
示板制御形式から制御プロトコルへ変換する機構」の 2 段階に分離した。
「電光掲示板制御
形式」は電光掲示板の持つ機能をすべて利用できるようにするために、制御プロトコルに対応した形をとっている。
「電光掲示板制御形式」は後述する「電光掲示板表示内容記述言語」と「電光掲示板制御シェル」の組み合わせによって実現される。

444

1996 年度

WIDE 報告書

抽象情報形式

抽象情報形式から電光掲示板で扱う
情報の形式への
変換機構

電光掲示板

抽象情報形式からFAXで扱う情報の形式への変換機構

FAX

抽象情報形式からWWWで扱う情報の形式への変換機構

WWW

図 3.7: 複数のメディア間での情報流通の方法

3.3.4

今回の実装

ここでは、BSD/OS が稼働する IBM-PC からの電光掲示板の制御の実装と、電光掲示板
表示内容記述言語 (DESC) 、電光掲示板制御シェル (danish) の実装について述べる。また、他のメディアと情報の相互交換の例を紹介する。
BSD/OS を用いた電光掲示板の制御

電光掲示板の BSD/OS からの制御は RS-232C 経由で行なった。試行の結果、以下のあげる作業を必要とした

 電光掲示板側の設定をモデムモードにする。
 CD(Carry Detection) 信号を発生させるための接続ケーブルを作成する。
接続ケーブルの両端は D-Sub の 9pin タイプである。接続図を図 3.8に示す。

電光掲示板表示内容記述言語
電光掲示板に表示する内容を記述するための記述言語のプロトタイプとして、DESC を実装した。DESC を用いることで、ユーザは制御プロトコルの形式をあまり意識せずに電光掲
示板の表示内容を記述できる。

第 16 部

さまざまなメディアとインターネット との連携

D-sub9pin

445

D-sub9pin

DTR

1

1 DTR

RD

2

2 RD

TX

3

3 TX

CD

4

4 CD

GND

5

5 GND

DSR

6

6 DSR

RTS

7

7 RTS

CTS

8

8 CTS

RI

9

9 RI
図 3.8: 接続ケーブルの結線

DESC では、電光掲示板に表示する情報を「スクリーン」という単位で扱っている。スク
リーンは文字列、ビットマップのいずれかからなる、ひとまとまりの「画面」である。表示位置、動作などの指定は各スクリーンに対して行なわれる。スクリーンに対する動作列(シナリオ) とスクリーンを指定することで、電光掲示板に情報が表示される。
これらの一連の動作や画面の情報は一つのファイルとして一旦ディスク上に記録しておく。後述する電光掲示板制御シェル danish を用いてファイルの内容を電光掲示板に送信
し 、DESC による電光掲示板の表示を実現している。
図 3.9に DESC の例を示す。

電光掲示板制御シェル
DESC に記述されたデータを表示したり、電光掲示板の制御を行ったりするためのシェルとして、danish を実装した。danish を用いれば 、電光掲示板上のコントローラボード へのコマンド 送受信を簡単に行うことができる。danish は命令を逐次実行していく。命令は一行につき一つ指定される。命令は例えば「時間の設定」「表示内容の指定」などである。
コマンド 体系 danish のコマンドは基本的に、命令 (command)・対象 (object)・引数 (argument) の組み合わせである。命令・対象と、それに対応した引数を組み合わせるこ

446

1996 年度

WIDE 報告書## sample data
# この例では上段に「 DENKO 」下段に「電光掲示板」が表示され、# それぞれが左右に振幅する#
label = DENKODEM
block = 1
code = 1
time = fromto(3,8,12,30,3,8,13,0),\
fromto(3,8,20,0,3,8,21,0)
screen WIDE = ("ＤＥＮＫＯ",14,1,0,5,12,4)
screen HOHNO = ("電光掲示板",14,1,0,5,12,4)
seq = {scrleft(WIDE,160,0,160,1,1),scrright(HOHNO,0,32,160,1,1)},\{scrright(WIDE,0,0,160,1,1),scrleft(HOHNO,160,32,160,1,1)}
図 3.9: DESC の例とで、電光掲示板の制御を行うことができるようになる。

danish の使用方法 danish を起動するには、% danishと入力する。danish が起動すると、行頭に>が表示される。この状態が、コマンド 受
け付け状態である。
図 3.10に danish の実行例を示す。

他のメディアとの融合・FM 文字多重放送とのリンク
FM 文字多重放送と電光掲示板の相互接続の実験を行なった。この実験の目的の一つに、
メディア間での情報の変換作業の試行がある。この実験では FM 文字多重放送の形式から
電光掲示板への直接の変換を行なったが、そこでの経験は抽象情報形式の設計の際の手助けとなる。
FM 文字多重放送の正式名称は「移動受信可能な FM 文字多重放送」である。FM 文字
多重放送とは、通常のステレオ音声放送の他に、音声や文字、図形などを多重した放送形態の一つである。
FM 文字多重放送には以下に示す３つのレベルがある。

第 16 部

さまざまなメディアとインターネット との連携

447

> reset> set clock on> get time
1996/3/9 (Sat) 23:55> set data DENKODEMO.desc> get list
DENKODEM> set order DENKODEM> get order
DENKODEM> quit
図 3.10: danish の実行例

2

レベル１ 本文 (15 文字 2) およびヘッダ行の表示ができる受信機に向けたサービスで文字による情報が中心である。図形は、パターン図形を用たもののみ送信可能。

2

レベル２ 本文 (15.5 文字 8) およびヘッダ行の表示ができる受信機に向けたサービスである。図形はパターン図形の他にジオメトリックによる図形1も送信できる。
レベル３ レベル１、レベル２に示した文字や図形のサービスとは異なり、CD-ROM による地図の表示ができる受信機に向けて交通情報データのサービスを行うものである。
現在、エフエム東京で行われている放送はレベル１である。
今回の実験では、(株) 日出ハイテックの VR-A を使用した。この VR-A は RS-232c 経由
でコマンドを送信することによってレシーバの周波数、音量、FM 多重放送のデータの送信等をコントロールできる FM 文字多重放送受信機である。

FM 文字多重放送と電光掲示板とのリンクを以下の手順で進めた。(図 3.11)
1. VR-A を制御するプログラムを作成する。

2. FM 文字多重放送から得られる文字による情報 (レベル１による放送の「本文」と呼ばれる部分) を取り出すせるようにする。
3. 取り出した文字情報を danish を使って、電光掲示板に表示させる。
1 および 2 は実装済である。3 は表示方法や送信のタイミングなどを検討中である。
1 線分、円弧などのコマンドにより図形を描画するもの

448

1996 年度

FM文字多重
放送受信機

WIDE 報告書

電光掲示板システム

VR-A
制御用
コマンド

コマンドに
対する返答

FM文字放送受信機制御
プログラム

Danishなど
文字による情報

抽象記述形式

ただのバイト列

電光掲示板
電光掲示板
制御部分

図 3.11: FM 文字多重放送と電光掲示板のリンク実験

3.3.5

現状の考察と今後の課題

考察
将来的な目標は、インターネット上の情報と他のメディアとの有機的な結合にあり、今回の研究はその一部を担うものである。
今回は、電光掲示板への出力内容を記述するための記述言語と、電光掲示板の制御を行なうためのシェルの実装を行なった。これによって BSD/OS を搭載した IBM-PC からの電光掲示板の制御が可能になった。また、FM 文字多重放送受信機によって得られた情報を電光掲示板に表示するための機構を設計し 、一部実装した。
借用した電光掲示板について、以下のような問題点が開発を行なう過程で明らかになった 電光掲示板本体に搭載されているコントローラボードの機能は、今回のような利用方
法では多機能すぎる。コンピュータ側の処理の負担を上げても、細かな操作ができる
ような制御方法も欲しい。

 制御プロトコル中にいくつか重複して記述しなければならない部分がある。

第 16 部

さまざまなメディアとインターネット との連携

449

 制御プロトコル仕様に合わないデータを送信した際のエラー機構が不充分である。
課題
下位層は既に整っているので、今後の主な課題は抽象度の高い上位層のものであり、具体的には以下のものが挙げられる。

 各メディアから取り入れた情報を表示するための抽象度の高い言語を扱う制御機構を実装する。

 さまざ まなメディアの情報を、電光掲示板表示内容抽象言語に変換する機構を実装
する。

第 4章
メディアを活用するための要素技術
本章ではメディアを活用し 、インターネットをより一層利用する試みの一環として行われている 5 件のプロジェクトについて報告する。これらはそれぞれ stetho 、c-pon 、「アン
ケート調査システム」、もんじゅ、「状態を持つ HTTP 」と呼ばれている。

stetho は 、ネットワークトラフィックを音声で表現するシステムである。ネットワーク

上を流れるパケットごとの情報を音声で表現し 、ネットワークトラフィックに関する情報を容易に把握できる環境を提供する。

c-pon は 、計算機ネットワークを利用してさまざまな電気機器を一元管理するシステムである。多数の電気機器を操作することができるユーザインターフェースと、遠隔地からの電気機器の操作により、より快適な生活環境を提供することを目指した研究である。
アンケート調査システムとは、インターネットを利用してアンケート調査を効率的に実施するシステムである。インターネットを利用してアンケート調査の各過程における作業を自動化することにより、調査実施者の負担の軽減、回収率の向上、回答者のプライバシーの保護を実現する。
もんじゅは、ネットワーク上での協同執筆支援システムである。情報提供者から提供された情報を、管理者がまとめる際に生じるさまざまな問題を解決することを目指している。
状態を持つ HTTP とは、HTTP に状態を持たせることにより、他のメディアで行われている状態を持った情報提供を WWW で行うためのシステムである。従来の WWW では不可能であったより柔軟な情報提供サービスが行える環境を提供する。

4.1

stetho:音声を利用したネットワーク可聴化システム

4.1.1

はじめに

ネットワーク管理は、管理者に大きな負担がかかる作業である。それは多くの経験と知識が必要な上に、管理作業に必要となる情報の種類や量が多いことが原因である。この管理作業に必要となる情報は時間と共に変化する傾向をもち、音を利用して表現すると把握が容易になる。
そこで、著者らはネットワークトラフィック可聴化システム stetho を開発した。

450

第 16 部
4.1.2

さまざまなメディアとインターネット との連携

451

ネット ワーク管理作業における音の利用

ネットワークトラフィックを調査するための代表的な UNIX コマンドに tcpdump がある。
tcpdump は、大量の情報が出力され管理者が読み取るより前に画面上から消失してしまう
ため、視覚によって状況を把握するのが困難になる。
ネットワークトラフィック情報が持つ傾向と聴覚の特徴を合わせて考えると、ネットワー
クトラフィック情報は音で表現すると把握しやすくなる可能性が高いと考えられる。そこで、著者らはパケットの情報を音声を利用して表現する stetho システム1を開発した。
ネットワークトラフィック可聴化システム

1995 年度版 stetho システムは、ネットワーク上を流れる情報の単位であるパケットに注目し 、その情報を音で表現することによってネットワークトラフィックを表現する。

stetho システムの構成
stetho システムは、2 つのプログラム stetho と stethoc から構成される。stetho
は、stetho システムの中心となるプログラムである。stetho は、tcpdump を制御して情報を受け取り、それに応じて音声を発生する。管理者は、パケットの種類ごとに判別用の正規表現を stetho に設定する。stetho は 、tcpdump の出力と正規表現がマッチした場合に、その種類のパケットが発生したことを認識する。そして、対応するメロディーを演奏する。さらに、tcpdump の出力に含まれるパケットの観測時刻を参考にして、実際のパケットの発生間隔に等しくなるように音声の発生間隔を調整する。

stethoc は、管理者が stetho をコントロールするためのプログラムである。管理者
は、stethoc を使って、開始、停止、再開、中止などの指示を stetho に与えることができる。また、あるパケットに対応した音声が鳴ると同時に、そのパケットについての tcpdump の出力を表示するように指示することもできる。

stetho システムのハード ウェア構成
stetho システムを構成するハードウェアは、コンピュータ、MIDI 音源、スピーカである。MIDI 音源とコンピュータは、シリアルデバイス2 または、MIDI で接続されている。MIDI 音源は、信号をコンピュータから受け取り、信号通りに演奏した音声信号を出力する装置である。MIDI 音源から発生した音声信号は、スピーカによって音声に変換される。
遠隔地からの電話を利用したネットワーク観測

WIDE/PhoneShell を用いれば 、stetho システムの音を電話を通じて聞くことができる。つまり、電話越しにネットワークの状況を知ることができるようになる。
1 stethoscope = 聞診器から命名した。本来の発音を無視して、「すてぞー」と読む。
2 音源の機種によっては接続可能

4521996 年度

WIDE 報告書

そこで、我々は実験系を構築し実験を行なった。その結果、stetho システムの音を電話越しに聞いて、ネットワークの状況を知ることができることを確認した。ただし 、電話での可聞帯域は限られているので、音の設定を電話向けに調整する必要があることが分かった。
また、電話では複種類の音が同時になった場合に聞き取りづらくなることが判明した。そこで、どのプロトコルについての音を聞くのかをユーザが DTMF 信号を用いて切り替える機構を試作し 、実験を行なった。この機構によって、電話越しにネット
ワーク状況をより把握しやすくなった。
ネットワーク管理作業支援システム

1995 年度版 stetho システムには、問題点がいくつか存在する。記録したネットワー
クトラフィックの状態を再現し、再び観測するための機構が装備されていないことや、システムが稼働するホストが属するローカルネットワークのみを観測可能で、リモー
トのネットワークの観測ができないことなどが挙げられる。そこで、より汎用的にさ
まざまな管理作業に対して音を利用するためのシステムへ stetho システムを拡張し 、
1996 年度版とした。
システムの分割

1996 年度版では、stetho システムを「観測部」と「表現部」に分離する分割型モデルを採用した。分割型モデルでは、情報の種類ごとに観測部が実装され、表現部を共有する。また、観測部を新たに実装すれば扱うことのできる観測対象を追加できる。
観測部は、情報を観測して分析した結果を表現部に送信する機構である。一方、表現部は観測結果を音で表現する機構である。1 つの観測部は同時に複数の表現部に情報を提供できる。同様に、1 つの表現部は同時に複数の観測部から観測結果を得ることができる。これにより、複数の対象を同時に観測することが実現する。また、異なる種類の観測部から受けた観測結果を総合した表現が可能になる。

stetho プロトコル
観測部と表現部を stetho システムの構成部分として決定するのは、観測部と表現部の通信方法である。1996 年度版 stetho システムでは、この通信方法を stetho プロト
コルとして以下の事項を制定している。

 表現部が観測部に送る要求の形式
 要求に対する観測部の対応
 観測部から表現部に送る返答の形式
 観測部から表現部に送る観測結果の形式

第 16 部

さまざまなメディアとインターネット との連携

453

1995 年度版 stetho システムがもつ問題点の改善
分割型モデルを採用したことにより、1995 年度版がもつ問題点のうち以下の点が改善された。
まず、1995 年度版では同時には 1 つの対象しか観測できなかったが、1996 年度版では 1 つの表現部が同時に複数の観測部から情報を得て表現することが可能なためこの問題点は改善される。さらに、複数対象の観測結果を総合した表現が可能になった。
次に、観測部を表現部のリモートで稼働するとリモートの対象を観測できる。しかし、情報をネットワークを通じて送信する必要があり、観測する行為自体が観測対象に影響を与えてしまう。そこで、必要な情報だけをまとめて送信する工夫が必要である。

4.1.3

NetSound:stetho システムの応用例

1996 年度中に開催された Internet World Exposition '96(以下 IWE'96)[?] のテーマパビ
リオンとして \sensorium" というホームページが設けられていた。その中に、インターネッ
トを単なる情報伝達手段としてだけでなく世界の動きを表す指標として捉えて、その変化を音楽で表現するホームページ \NetSound" を設置した。

NetSound では、観測する対象として比較的小規模なネットワークを選択した。これは、利用者の活動が直接影響する小規模なネットワークのトラフィックからは、興味深い結果が得られるのではないかと判断したからである。また、インターネット上での活動は、末端の各ネットワーク上での活動が総合されたものだと考えられる。よって、小規模なネッ
トワークの活動状況を表現することは、インターネットの活動状況を表現することにもつながると考えた。

NetSound の構成
NetSound は 、WWW ページとして実装されたユーザインターフェースと、ネット
ワークトラフィックを観測し音楽で表現する観測ユニットから構成される。
まず、ユーザインターフェースとなる WWW ページは IWE'96 の WWW サーバに保存され、ユーザは WWW ブラウザを用いて閲覧する。一方、観測ユニットは観測対象として選ばれた複数のネットワークに設置され、ネットワークを表現した音楽をRealAudio を利用してユーザに送る。(図 4.1)
観測ユニット
観測ユニットは、2 台の PC と 1 台の MIDI 音源によって構成され、それぞれ BSD/OSと Windows95 が搭載されている。MIDI 音源は、BSD/OS 側の PC から MIDI で制御され、発した音は Windows95 側の PC に出力される。なお、MIDI 音源には楽器
音に限らずさまざまな音が出力できるサンプラが採用された。

454

1996 年度

WIDE 報告書

観測ユニットＡ
観測ユニットＢ
Network A
Network B

RealAudio data

Internet

Network

HTTP
IWE’96WWW server

ユーザ
図 4.1: NetSound の構成

BSD/OS 上では、RealAudio Server と stetho システムが稼働し 、一方 Windows95 上
では、RealAudio Live Encoder が実行される。
stetho システムはネットワークを監視し 、得られた情報をもとに MIDI 信号を発信する。その MIDI 信号を受けた MIDI 音源が発した音声は、RealAudio Live Encoder によってエンコード される。エンコード されたデータは RealAudioServer によってユーザに送られ、ユーザ側の RealAudio Player によって音声に戻る。
まず、観測対象となるネットワークを指定するための地図がある。この地図上には、観測対象となるネットワークの候補が示されていて、ユーザがいずれかを指定すると、それぞれの観測ユニットに関するページに表示が切り替わる。
各観測ユニットについてのページには、プロトコルと音の対応表があり、ユーザはこの表を見て、どの音がどのプロトコルを表しているのかを確認できる。また、表には各プロトコルの簡単な説明も添えられる。
さらに観測ユニットのページには、観測を開始するためのボタンや、現地の時刻を表
す時計が設けられる。ユーザが演奏開始ボタンを操作すると RealAudio Player が起
動し 、指定された観測ユニットの RealAudio Server に接続して演奏を開始する。
まず、観測対象となるネットワークを指定するための地図がある。この地図上には、観測対象となるネットワークの候補が示されていて、ユーザがいずれかを指定すると、それぞれの観測ユニットに関するページに表示が切り替わる。
各観測ユニットについてのページには、プロトコルと音の対応表があり、ユーザはこ第 16 部

さまざまなメディアとインターネット との連携

455の表を見て、どの音がどのプロトコルを表しているのかを確認できる。また、表には各プロトコルの簡単な説明も添えられる。
さらに観測ユニットのページには、観測を開始するためのボタンや、現地の時刻を表
す時計が設けられる。ユーザが演奏開始ボタンを操作すると RealAudio Player が起
動し 、指定された観測ユニットの RealAudio Server に接続して演奏を開始する。
ユーザインターフェース

NetSound のユーザインターフェースは、以下に挙げる内容で構成される。
各観測ユニットについてのページには、プロトコルと音の対応表があり、ユーザはこの表を見て、どの音がどのプロトコルを表しているのかを確認できる。また、表には各プロトコルの簡単な説明も添えられる。
さらに観測ユニットのページには、観測を開始するためのボタンや、現地の時刻を表
す時計が設けられる。ユーザが演奏開始ボタンを操作すると RealAudio Player が起
動し 、指定された観測ユニットの RealAudio Server に接続して演奏を開始する。
音楽の設計

NetSound では、複数のネットワークを観測対象としている。もしも、パケットと音
色の割り当てを全てのネットワークにおいて全く等しく設定すれば 、音楽の特徴のみ
がネットワーク利用者の活動状況の特徴を表すことになる。
しかしこの場合、あるネットワークについて調整した設定では、他のネットワークで演奏される音楽が音楽として成立しなくなる可能性が高い。ユーザが音楽を聞いて楽しめる、娯楽性の高いものでなければ 、IWE'96 のテーマパビリオンのコーナーとしては不適格である。
そこで 、ネットワークごとに各ネットワークを調整する音色を割り当てて音楽を調整することにした。例えば 、大学の研究室のネットワークには電子音を割り当て、一方、小学校のネットワークには子供の歓声を割り当てる。これにより、ネットワークの利用者についての連想を音色を手掛りにして行なえるようになり、娯楽性が高まった。ただし 、各ネットワークの活動状況を、音楽の特徴から比較することは難しくなった。実際には、観測ユニットは大野研究室に設置されているものだけであった。
評価

NetSound は 、開設した 1996 年 7 月 24 日から 1997 年 1 月 7 日までの 171 日間で、延べ 2872 人から利用された。接続に利用されたホスト別に集計すると、1227 ホストであった。一つのホストを一人が利用すると仮定すると、平均して 2.34 回利用したことになる。ホスト別の利用回数を統計してみると、表 4.1のようになる。56%のホ
ストからは一度しか利用されていないが、これは半数近く (44%) の利用者が 2 回以上利用していることも示している。一度 NetSound を利用した利用者のうち、半数近456

1996 年度

WIDE 報告書

くがもう一度利用しようと思ったということなので、評価は高かったのではと予想できる。

1 回 2 回 3 回 4 回 5 回 6 回 7 回 8 回 9 回 10 回
695 260
116
57
27
17
11
4
8
9
11 回 12 回 13 回 14 回 15 回 16 回
20 回以上
ホスト数
2
7
1
4
2
5
5
回数
ホスト数
回数

表 4.1: 利用回数別ホスト数

NetSound の stetho システムに対する意義
NetSound では stetho システムを本来のネットワーク管理ツールとしてではなく娯楽のために利用している。しかし 、NetSound を機会にして多くの人が stetho システムに触れ、意見を寄せることは、ネットワーク管理支援ツールとしての stetho システ
ムを開発する上でも十分に有益であると考えている。
4.1.4

stetho システムのこれから

stetho システムの今後の展望について述べる。
管理コマンド の出力を汎用的に扱う観測部
管理作業に従来用いられてきたコマンド の出力を扱うための観測部は多く考えられる。各コマンドごとに観測部を実装すれば 、そのコマンドの情報を音で表現することが可能である。
音以外の手段による表現
これまで、表現部は情報を音で表現するためのものであると述べてきた。しかし 、観測部とのプロトコルにしたがって情報を得て、音以外の方法で表現を行なう表現部も考えられる。表現方法として、文字やグラフを用いる方法が挙げられる。
また、聴覚と視覚を両方利用すると、認識率が高くなるという研究結果もある。双方の特徴を活かせば 、よりネットワーク管理の負担を軽減することができるだろう。
4.1.5

まとめ

今後は、より実用的なシステムをめざして、実際にネットワーク管理に役立つか、役立
つにはどのように改良するべきかを考えていきたい。

第 16 部

4.2

さまざまなメディアとインターネット との連携

457

C-Pon:計算機ネットワークを利用してさまざまな電気機

器を一元管理するシステム
4.2.1

はじめに

家庭やオフィスではさまざまな電気機器が導入されている。電気機器の普及により日常生活はあらゆる面で飛躍的に向上した。しかし 、いくつかの改善により現状をより快適にすることが可能であると考える。その方法の 1 つとして、筆者は計算機を利用して電気機器を一元的に管理するシステムを考案した。著者はこのシステムを C-Pon システムと名付けた。
本研究でいう電気機器とは、主に一般家庭やオフィスで利用されるテレビやオーディオ
機器、洗濯機、掃除機等の家電製品を対象とする。
4.2.2

研究の背景

科学技術の発展にともないさまざ まな電気機器が開発されている。電気機器の利用は、家庭やオフィスの日常生活に大きな影響を与えている。テレビやラジオは、新聞や雑誌にかわり即時性をもった情報収集源として、洗濯機や掃除機は、日常生活での人間の負担を軽減する機器として、エアコンは、生活環境を快適にする機器として、定着してきた。人間の日常生活は、電気機器に大きく依存しており、生活を営む上で電気機器はもはや欠かせない存在になっている。
しかし筆者は、身の回りで電気機器を使用する際、いくつかの改善をすることによりより快適な生活環境を得ることができないかと考えている。まず、各電気機器はその製品の種類や製造元の違いにより操作法が統一されていない点に着目した。オーディオ機器を例に挙げると、どの製品も基本となる動作はほとんど変わらないが、各機器ごとに操作法が異なり利用者への混乱を与えやすい。したがって、さまざまな電気機器に対して統一された操作系を提供することが必要であると考える。
次に、各電気機器それぞれに用意されたユーザインターフェースを 1 つにまとめることを考えた。家電製品には、ユーザインターフェースとしてリモコンが採用されているものが多い。しかし一般に、各製品のリモコンには互換性がないため、利用者はそれぞれのリ
モコンを別々に操作しなければならない。したがって、利用者に対して、全ての電気機器を操作することができるユーザインターフェースを提供することが必要であると考える。
また、遠隔地から操作できる電気機器が普及してない点に着目した。遠隔地からの電気機器の操作は、日常生活の改善に大きく貢献すると考える。例えば 、利用者は外出先から自宅のビデオを操作して録画予約をすることができる。遠隔地からの電気機器操作を可能にするために、離れた場所にある機器が情報のやりとりを行なうための媒体を用意する必要があると考える。
以上の問題を改善する方法の 1 つとして、計算機ネットワークを利用することが有効であ4581996 年度

WIDE 報告書る。市販されている電気機器には、RS-232C 規格のシリアルインターフェースを備えた製品が存在する。また、将来 USB(Universal Serial Bus) や IEEE1394 規格のインターフェースによって計算機に接続できる電気機器が増加していくと予想される。このような電気機
器は、計算機にユーザインターフェースを用意することにより、利用者に対する統一された操作系をもつことが可能にある。また、計算機ネットワークは、遠隔地にある電気機器との情報交換を行なうための媒体として十分な機能と持っている。
4.2.3

C-Pon システムの設計

C-Pon システムでは、離れた位置に存在するオフィスや研究室で人が共同作業を行なう
環境で、それぞれのオフィスや研究室は、「部屋」という単位で扱うものとする。部屋の定義を以下に示す。

1. 全ての部屋では、電気機器を操作するためのユーザインターフェースを統一する。全ての電気機器を計算機に接続し 、利用者は計算機に命令を与えることにより電気機器を操作する。

2. それぞれの部屋は計算機ネットワークを介して情報のやりとりを行なう。各部屋に存在する電気機器は、ネットワーク経由によりどの部屋からも操作することができる。

3. 各部屋に存在する電気機器の管理はその部屋の計算機が行なう。
上で定義した部屋から構成される環境を実現するためには、次の 3 つの機構が必要である。まず、利用者へのユーザインターフェースを提供する機構。これを「利用者層」と呼ぶ。次に、部屋同士で情報のやりとりを行なう機構。これを「連絡層」と呼ぶ。最後に、ある部屋において全ての電気機器を管理し制御を行なう機構。これを「部屋管理層」と呼ぶ。
システムは、図 4.2に示すような利用者層、連絡層、部屋管理層の 3 階層構造から構成される。
次に利用者層、連絡層、部屋管理層についての説明を述べる。
利用者層
利用者層の役割は、利用者へ電気機器を操作するためのユーザインターフェースを提供することである。利用者は、「自分（利用者）の名前」、「対象となる部屋」、「操作対象の機器」、「機器への詳しい命令」の 4 つの情報を利用者層へ指定することによってどの部屋からも目的の電気機器を操作することが可能である。
逆に、利用者層では電気機器から利用者に対するメッセージの出力も行なう。
連絡層
連絡層の役割は、システム内でやりとりされる情報を正しく中継することである。連
絡層での情報とは、利用者層で利用者が指定した「利用者名」「対象となる部屋」「操第 16 部

さまざまなメディアとインターネット との連携

部屋２

459

部屋３
部屋１

利用者層

連絡層

部屋管理層

電気機器
電気機器

図 4.2: C-Pon システムの 3 階層モデル

作対象の機器」「機器への詳しい命令」や、逆に部屋管理層で電気機器から出力されるデータのことを指す。
連絡層には、「利用者・管理中継部」と「部屋間中継部」の 2 つの機構を用意する。
利用者・管理中継部は、利用者層と部屋管理層との情報の中継を行なう。部屋管理層
は、各部屋同士の情報の中継を行なう。
部屋管理層
部屋管理層の役割は、1 つの部屋内にある電気機器全ての管理、制御を行なうことである。部屋管理層には、「管理部」、「命令解析部」、「制御部」の 3 つの機構を用意する。管理部は、電気機器に対する利用者の操作許可の確認を行なう。命令解析部は、利用者が指定した機器への命令を各電気機器が認識できる情報に変換する。制御部
は、電気機器に情報を送り操作する。また、電気機器から出力された情報を入力する。

3 つの機構のうち、管理部は各部屋に 1 つずつ用意する。命令解析部と制御部は部屋に存在する全ての電気機器に用意する。
4.2.4

実装

システムの試作に先立って部屋管理層の実装を行なった。計算機には AT 互換機、また、OS には BSD/OS 2.1 を使用した。本実装では、管理部、命令解析部、制御部にプロセス

460

1996 年度

WIDE 報告書

を 1 つずつ用意し 、各プロセス間で通信を行なっている。
管理部
管理部には、admin というプロセスを用意した。admin は、連絡層に対するサーバプ
ロセスである。また、部屋にある全ての電気機器を参照するためのファイル「電気機器テーブル」を用意した。電気機器テーブルには、各電気機器に指定された固有の名
前とその電気機器に対する操作の許可が与えられたユーザ名が記述されている。

admin は、クライアントから「利用者名」「操作対象の機器」「機器への詳しい命令」
を ASCII コードの文字列として読み込む。admin は、与えられた文字列のうち、「利用者名」と「操作対象の機器」を電気機器テーブルと照合し 、操作対象の電気機器に対して利用者名で記されたユーザが操作可能であるかを調べる。ユーザが機器を操作可能である場合、admin は「機器への詳しい命令」を制御対象となる電気機器の命令
解析部へ出力する。
命令解析部
命令解析部には、kaiseki-*というプロセスを用意した。*の部分には各電気機器に指定された名前がつく。kaiseki-*は、admin から「機器への詳しい命令」を読み込む。
admin から読み込んだ命令を、各電気機器に依存した命令文字列に変換するためのファイル「命令テーブル」を用意した。kaiseki-*は、命令テーブルにしたがって adminから読み込んだ文字列を変換し 、制御部へ出力する。
制御部
制御部には、control-*というプロセスを用意した。*の部分には各電気機器に指定された名前がつく。control-*は、kaiseki-*から読み込んだ文字列を電気機器が接続しているインターフェースに出力する。また control-*は、電気機器が接続しているイン
ターフェースから文字列を読み込むと、連絡層に出力する。
4.2.5

実験と評価

実験
実装したプログラムの試験運用を行なった。試験運用に際して大野研究室 303 号室
を「対象の部屋」とした。実験機材には、RS-232C シリアルインターフェースを備えたビデオデッキと、筆者が開発した複数の電源の ON/OFF を制御する装置を用いた。ビデオデッキを指定する名前を"CVC"とし 、命令解析部は kaiseki-CVC 、制御部
は control-CVC とした。同様に、電源制御装置を指定する名前を"genko"とし 、命令
解析部は kaiseki-genko 、制御部は control-genko とした。
以上の環境で、下に示す実験を行なった。

第 16 部

さまざまなメディアとインターネット との連携

461

1. 管理部プロセス admin は host:taiko で起動した。
2. ビデオデッキは研究室内の host:clarinet に接続、電源制御装置は同研究室内のhost:chobi に接続した。
3. clarinet 上で kaiseki-CVC、control-CVC を起動、また、chobi 上で kaiseki-genko、
control-chobi を起動した。
4. telnet から admin にアクセスし 、「利用者名」「操作対象の機器」「機器への詳しい命令」を入力する。正しく各電気機器を操作できるかを確認する。
評価
管理部を部屋に 1 つ用意した。したがって部屋管理層へのアクセスを 1 つのホストに限定できる。管理部プロセスを起動したホストを中心に部屋内の電気機器の管理、操作が可能となった。
部屋管理層を 3 つの機構に分割したことにより、電気機器ごとに別々のプロセスを起動することができる。システム全体として、電気機器の追加、削除が容易に行なうことが可能である。
また、kaiseki-* 、control-*を分割したことにより、計算機に接続するためのインターフェースの変更等にも control-*のみを変更することにより容易に対応できる。
4.2.6

おわりに

本報告では、日常生活に普及しているさまざまな電気機器を、計算機を利用することにより一元管理、操作するシステムの設計を行なった。C-Pon システムは、利用者層、連絡層、部屋管理層の 3 階層から成る。また、部屋管理層を試作し 、試験運用を行なった上でその評価を述べた。今後、利用者層および連絡層を実装してシステムの完成をする予定で
ある。

4.3

インターネット を利用してアンケート 調査を効率的に実
施する機構

4.3.1

はじめに

アンケート調査は、問題解決の 1 つの手段として有効である。しかしアンケート調査は、
直接回答者から回答を得るという特性から、調査実施者・回答者双方に手間がかかる。現状では、調査実施者はアンケート調査に多くの費用・時間・人手・手間を費やしている。また、回収率を向上させようとすれば 、さらに調査実施者の負担が重くなる。

462

1996 年度

WIDE 報告書

そこで、インターネットを利用してアンケート調査の各過程における作業を自動化することにより、調査実施者の負担を軽減する。また、回収率を向上させるために、回答に手間のかからない調査票を作成し 、回答者のプライバシーを守る調査を実施する。以上の方法で、アンケート調査を効率的に実施するシステムを設計・実装した。
本報告では、システムの構成とその機能について述べる。
4.3.2

システムの構成

本システムは次のような特徴を持つ。

 標本抽出の自動化
 調査票の配付、回答データの回収の自動化
 回答者のプライバシーの保護
 二重回答の防止
 調査実施者が容易に調査票を作成できる機構
本システムはインターネットを利用して標本抽出、調査票の配付、回答データの回収を自動化することにより、調査実施者の負担を軽減する。また、回答者のプライバシーを守る。さらに同一回答者からの二重回答も防止できる。
本システムでは、回答に手間のかからない調査票を「楽々調査票」と呼ぶ。調査実施者
は楽々調査票記述言語を用いて楽々調査票定義コードを記述するだけで楽々調査票を作成できる。
本システムは調査代行サーバと回答代行サーバの 2 つのサーバから構成される（図 4.3 ）。
調査代行サーバは中立的な第三者機関で動作するサーバである。回答代行サーバは各組織で動作するサーバであり、組織に属している調査対象者の個人情報が登録された回答者
データベースを管理している。調査実施者は、調査代行サーバにアンケート調査を依頼し 、調査代行サーバから回答データを受け取る。回答者は、回答代行サーバから届いた調査票の質問に回答し 、回答代行サーバに対して回答データを送る。
4.3.3

調査代行サーバの動作

調査代行サーバは、調査実施者からアンケート調査の依頼を受けると、まず各回答代行
サーバに対し調査対象の定義を満たす調査対象者の人数を尋ねる。その後、各回答代行サー
バからその人数を得て、回答代行サーバごとの標本数を決定する。続いて、各回答代行サーバにアンケート調査を依頼する。そして各回答代行サーバから回答データを回収する。
調査実施者が回答データを得る際には、調査実施者が調査代行サーバに回答データを送るように要求する。その依頼を受けた調査代行サーバは調査実施者に回答データを送る。

第 16 部

さまざまなメディアとインターネット との連携

463

楽々調査票
回答

回答者

回答代行
サーバ
調査代行
サーバ

・
・
・

調査の 回答
依頼 データ

回答代行
サーバ

回答者

回答者

回答者
調査実施者

・
・
・

図 4.3: システムの構成

4.3.4

回答代行サーバの動作

回答代行サーバは、まず調査代行サーバから調査対象の定義を満たす調査対象者の人数を聞かれ、調査代行サーバにその人数を教える。その後、調査代行サーバからアンケート
調査の依頼を受けると、回答者データベースに登録されている調査対象者の中から回答者を無作為に抽出し 、回答者に楽々調査票を電子メールで送る（図 4.4 ）。回答データは、回答者が調査票の質問に対して回答すると、自動的に回答代行サーバに送られる。そして回答代行サーバはその回答データを匿名で調査代行サーバに送る。
回答代行サーバの調査票作成部が 、楽々調査票定義コードから楽々調査票を作成する。
楽々調査票を回答者に送ることにより、回答者は該当する回答選択肢ボタンをマウスでクリックするだけで回答できる。楽々調査票定義コードは楽々調査票記述言語で記述されている。楽々調査票定義コードには、楽々調査票を作成する上で必要な情報を記述する。
調査票作成部は、単一回答形式、複数回答形式など 、さまざまな回答形式の質問を作成できる。回答形式の指定は楽々調査票定義コードに記述する。
4.3.5

今後の課題

回答形式の充実 調査票作成部はさまざまな回答形式を用意している。今後さらに回答形式を充実させる。また図 4.5のような、紙のアンケートでは実現できなかった回答形式

464

1996 年度

WIDE 報告書

図 4.4: 回答者に電子メールで送られてきた楽々調査票

第 16 部

さまざまなメディアとインターネット との連携

465も開発していく。そのために、より正確な回答データを回答者から得られる回答形式を考察していく必要がある。

今の世の中に満足ですか不満

満足

図 4.5: グラフを用いた調査票

セキュリティの強化 本システムは、調査代行サーバ・回答代行サーバを用意することにより、回答者のプライバシーを守る調査の実施を実現している。しかし現在では、回答代行サーバの不正、第三者の侵入に対して、個人情報・回答データの漏洩を防止できる保証はない。
今後、ユーザ認証の強化、暗号化などにより、セキュリティの強化が必要である。
調査対象の指定 現在では、「 20 才の学生」などの調査対象の条件を指定できない。今後、回答者データベースに職業、年齢などの情報を登録することにより、調査対象の条件を指定できるようにする。
4.3.6

おわりに

本報告では、インターネットを利用してアンケート調査を効率的に実施するシステムの概要および構成とその機能について述べた。
本システムは、インターネットを利用することで、標本抽出、調査票の配付、回答デー
タの回収を自動化した。また調査実施者が楽々調査票を容易に作成できる機構を用意した。
さらに楽々調査票を回答者に配付し 、回答者のプライバシーを守る調査の実施を実現した。
同一回答者からの二重回答も防止できる。
その結果、調査実施者の負担が軽減された。回答者に対しては、回答に手間がかからな
い、プライバシーを侵害されないなどの利点がある。さらにインターネットを利用しているので、大規模なアンケート調査を実施できる。

4.4

もんじゅ :ネットワーク上での協同執筆支援システム

ネットワークの利用者は多種多様であり、彼らが持つ情報もさまざまである。これらの情報を集め、まとめあげることは非常に有意義である [?]。

466

1996 年度

WIDE 報告書

そこで、筆者らはネットワーク上での協同執筆作業支援システム、「もんじゅ」3を開発している。本システムは、「同じ メーリングリストに所属する人々」、「同じ World Wide
Web(以下、WWW) のページを見る人々」といった共通の関心によって結びついた人々によるグループに注目し 、彼らが持つ多種多様な情報を集積するための、協同執筆によるハ
イパーテキストデータベース作成を支援する。
本システムの特徴は、利用者が電子メールのような既存の手段を用いて文書作成作業に参加できる仕組みを提供していること、及び文書の更新作業を自動化していることである。
本報告では、「もんじゅ」の概要と現状について述べる。
4.4.1

既存の作業形態と問題点

われわれが注目したグループは規模や質の点から、グループ内の人々に協同作業用の文書 (以下、「協同文書」4 ) を直接操作させるのは現実的ではないと考える。
そこで、協同文書を「主催者」と呼ばれる特定の人が所有・管理する場合を想定する。このとき、グループ内の他の人々(以下、「情報提供者」) は協同文書を直接ではなく、主催者に対して何らかの働きかけを起こすことによって間接操作することになる。
しかし 、従来は働きかけの方法に統一性がなかった。また、主催者側でも、情報提供者
からの働きかけを受け、それを協同文書に反映させるという作業を、連続した過程として行うことができなかった。したがって、主催者は多大な労力を強いられていた。
4.4.2

もんじゅシステムの概要

これらの問題に対し 、計算機支援による解決を試みた。まず、後述する作業モデルを考案し 、モデル中の各作業に計算機支援によって連続性を持たせ、同時に作業における負担の軽減をはかった。特に、主催者に強く負担となっていた、文書の更新作業の自動化を実現した。あわせて、主催者の元で行われる協同文書の管理を支援する文書管理系を実装した。これらの支援系をまとめて「もんじゅ」と名づけた。

作業モデル
例として主催者は協同文書の公開に WWW を用いるものとする。また、情報提供者は、主催者から入手した協同文書に加筆や訂正などの「変更」を加えることによって、文書作成作業に参加するものとする。
更新作業を自動化するためには、機械的に処理しやすい形式で情報提供者が主催者に変更内容を伝える必要がある。そこで、変更内容を表す形式を統一し 、これを「差分」と呼ぶことにした。
3 諺「三人寄れば文殊の知恵」より

4 単に「内部に複数の人が書いた部分が混在する文書」という意味で用いる。

第 16 部

さまざまなメディアとインターネット との連携

467

その上で、図 4.6に示すような作業モデルを考案した。

情報提供者
１差分作成
２連絡

WWW
４差換

Database

３承認

〒

承

主催者

図 4.6: 作業モデル

1. 差分作成 情報提供者は、適当なエディタなどを用いて文書に変更を加え、新しい版の文書を作成する。変更内容は、変更前後の文書の相違、すなわち差分の形で保存される。

2. 連絡 次に、作成した差分を主催者へ送付する。
3. 承認 主催者側では、送付された差分を見て、この変更を受け入れるかど うかを判断する。

4. 差換 変更が承認された場合、差分を元に変更後の文書を復元し 、新しい版として文書を更新する。
主催者と情報提供者側で上記の一連の作業を繰り返すことによって、協同文書は次々と更新される。

システム構成われわれは、更新作業の自動化を実現するにあたり、協同文書を管理するための保存方法を重要視した。したがって、本システムは、協同文書の管理を司る「文書管理部」を根幹とする。さらに、作業モデルにおける４つの作業に対する支援系を合わせた５つの部分からなる。

 文書管理部 協同文書を管理するハイパーテキストデータベース管理プログラムである。外部に対するインターフェースとして、データに対する操作を提供する。

468

1996 年度

WIDE 報告書

 差分作成支援部 情報提供者による変更前後の文書の差分を、差分解析部が理解する形式で生成する。

 連絡支援部 既存の MTA5である (連絡手段として電子メールを利用する場合)。
 承認支援部 主催者による承認作業を支援する。差分が電子メールで送信される場
合、メールリーダの一部として実現される。

 差換支援部 送付された差分を解析し 、文書の更新に必要な、文書管理部が提供する操作の列を生成する。

4.4.3

試作版の実装対象をテキストに限定した上で、文書管理部の実装を行った。
文書管理部は、ハイパーテキストデータベースにおけるノードやリンクなどのハイパー
テキスト情報を管理する [?] 。文書内に複数の著者によって書かれた部分が存在する場合は、それらを別のノードとみなして別々に保存する。これらのノード 群は、参照の際には１つの文書として見えるようにリンク付けされる。たとえば 、差分を元に差し替えが起こった
場合、文書は実際に上書きされるのではなく、ハイパーテキスト構造を変化させることによって上書きされたように見せることになる。したがって、元の版はそのまま残され、参照することも可能である。
外部に対しては、ハイパーテキスト情報を変化させる操作を提供している。

4.4.4

まとめ

本報告では、もんじゅシステムの概要とその試作について述べた。本システムの導入により、管理者の負担の軽減が実現され、それに伴うネットワーク利用者による情報収集活動のさらなる活発化が期待できる。
現段階では、試作版の運用を十分に行い、システムの有用性を検証する必要がある。
今後の予定としては、電子署名の技術と組み合わせることにより、送付内容の主催者による改竄を防ぐ 手法の導入、また、FAX などの手段を用いて WWW を利用している人々
も作業に参加できるように、入力方式の多様化を考えている。
5 Mail Transfer Agent. メール配送プログラム

第 16 部

さまざまなメディアとインターネット との連携

4.5状態を持つ HTTP

4.5.1

はじめに

469

WWW では通信プロトコルとして HTTP が使われる。HTTP は状態を持たないプロト
コルなので、対話的な情報提供を WWW で行おうとすると面倒な作業が伴う。そこで筆者らは、状態を持った HTTP を提案し 、対話的な情報提供を支援するシステムを開発して
いる。

4.5.2

WWW の問題点

WWW は、インターネットで情報を提供する手段として、広く使われている。しかしさまざまな問題点があり、それを改良する研究も盛んである [?]。それらの問題点の中から、HTTP が状態を持たないという点に筆者らは注目した。
WWW での情報提供はブラウザからサーバへの 1 回のリクエストとサーバからブラウザ
への 1 回のレスポンスの組で行われ [?] 、その度に接続が切断される。また、WWW サー
バは、どのホストからアクセスしてきたかを知ることはできるが、そのホストを誰が使っているかを特定できない。これらの理由から、WWW サーバに複数回のアクセスがあった
場合に、同じユーザからのリクエストか、違うユーザからのリクエストかを正確に区別することは不可能である。つまり、WWW サーバは状態を持つことはできない。

WWW 以外に目を向けると、インターネット上には状態を持ったサービスが存在する。
例えば 、ユーザが telnet を使って情報提供者のコンピュータにログインして、検索プログ
ラムを操作するという方法で情報提供が行われている。これらのサービスは、検索結果を再利用することによって高速な検索を可能にしている。WWW で状態を持つ情報を提供することができれば 、このような柔軟な情報提供サービスを行うことが可能になる。

4.5.3

状態を持つ HTTP

session-ID を使った、状態を持つ HTTP の実現 筆者らが開発しているシステムでは 、

ブラウザとサーバが共通の session-ID を保持し 、お互いにそれを確認しながら通信するという方法で、状態を持つ HTTP を実現している。
状態を持つページにブラウザが最初にアクセスすると、サーバは session-ID を生成する。そして、それ以降にサーバとブラウザの間でメッセージをやり取りする場合は必ず session-ID の情報を相手に送信する。この方法でサーバはユーザを区別することが可能になり、ユーザ側の視点では状態を持った情報提供が行われているようにみえる。session-ID は同じものが重複して発行されないように、サーバの名前と時刻情報を含んでいる。

470

1996 年度

WIDE 報告書

session-ID を使って状態をシミュレートするこの方法の特徴の一つは、厳密なユーザ認証を行なわないことである。したがって、ユーザがサーバにアクセスするときの匿名性が保たれる。また、 4.5.5 で述べるような長期的に状態を保存するサービスを提供することが可能になる。
session-ID の破棄 このシステムを利用するサーバに非常に多くのユーザがアクセスすると、そのサーバが保持している状態の情報の量が増加し続け、二次記憶装置を圧迫する。そこで、適当な時に状態の情報を消去する必要がある。本システムでは session-IDを破棄するためのプロトコルを定義してあり、サーバとブラウザが一連の情報提供を終了できるようになっている。
4.5.4

システムの構成

本システムでは、ブラウザとして NCSA Mosaic-2.6-l10n+ を、サーバとして NCSA httpdversion 1.5 を採用し 、それらを改良して用いている。また、サーバ側は apache 1.1.1 に対して移植を行なうことを検討している。
4.5.5

応用例

状態を持つ HTTP は様々なシステムに対して利用することができる。

 ショッピングシステムへの応用
WWW をショッピングシステムとして利用することがある。普通は CGI を使って購入のシステムを構築するが、状態を持つ HTTP を利用すると簡潔に実装することができる。
今回、実際にレコード 店のプロトタイプを作成して実験した。この架空の店では、商品がいくつかのページに分かれて置いてある。ユーザが商品を購入すると、サーバはユーザごとにその購入した商品名を記憶する。この商品名のリストがサーバの状態となる。
サーバはユーザを区別する必要があるので、状態を持つ HTTP を使った方が簡単に実装できる。

 教育への応用
WWW で個人指導方式の教育を行うシステムを考える。このシステムでは、ユーザのレベルに応じたドキュメントが表示され、ユーザはそれを使って学習する。また、学習を再開したときにはいつでも続きから始められる。
このような情報提供を行うためには、ユーザの状態をサーバが長期的に保存することが必要である。

第 16 部

さまざまなメディアとインターネット との連携

471

 ユーザがカスタマイズ可能なページ
WWW のページは、 HTML(HyperText Markup Language)[?] と呼ばれる言語で記述されたものが多く使われる。HTML はユーザがある特定の環境にいることを想定していないので、HTML が使われたページならば環境に最適なレイアウトでその内容を表示されるはずである。しかしながら、最近、さまざまなブラウザが HTML を独自に拡張して新しい機能を導入しているため、上記のようなことが成立しなくなっている。ブラウザの種類を自動的に判定して、ブラウザに適した情報を提供することもあるが、ブラウザの種類だけではユーザの環境を正確に判定することができない。
そこで、ユーザが自分の環境をサーバに指定するという方法を考えた。この場合、サーバがユーザの好みを状態として記憶することにより、ユーザがカスタマイズすることが可能なページを実装することができる。
4.5.6

課題と今後の予定

現状では、情報提供者が session-ID の管理を行なう必要があるので、状態を持つ情報を簡単に提供できるようになったとはまだ言えない。session-ID の管理の仕組みを WWW
サーバのシステムの中に組み入れるか、記述を簡単にするためのライブラリを用意する必要がある。
また、セキュリティに関する問題がある。session-ID がその所有者以外に知られ、それを使用された場合、混乱がおきることが予想される。特に、提供するサービスの内容によっては、他人にプライバシーに関する情報を引き出せてしまう可能性がある。現在は session-ID
ファイルのアクセス権を他人に与えないことで対処しているが、これでは不完全であると思われる。将来的には、session-ID を暗号化する、ユーザ認証を行う HTTP を使用する、などの対策を講じる必要がある。
本システムでは、状態を持つページにアクセスするときに、キャッシュサーバの情報を使用しない。このことがネットワークのトラフィックを増加させる恐れがある。状態を持ったページを効率よくキャッシュするためのキャッシュサーバを作成する必要がある。
現在はユーザ側のインターフェイスは Mosaic だけに限られているが、多くの人々に利用してもらうためにはさまざまなブラウザにたいして移植する必要がある。一例として、
Netscape Navigator のプラグイン機能を利用して移植する方法が考えられる。
4.5.7

まとめ

本報告では、状態を持つ HTTP に関する研究の現状について述べた。本システムの開発により、WWW を使った対話的な情報提供を簡単に行うことが可能になると期待できる。
現段階ではセキュリティなどの面に関して問題が多いが、今後はそれを解決し 、実用に耐え得るシステムとなるように研究を進めていきたい。

第 5章
おわりに
本稿に収録した研究の大半は、来年度も引続いて研究される予定である。すなわち、本稿に収録された報告は、1996 年度末の時点のスナップショットに過ぎない。最新の情報はWIDE プロジェクトホームページや、徳田・村井・楠本研究室や大野研究室 のホームペー
ジなどから得られる。
ここに収録された報告は、一見するとばらばらで相互の関連性が見出せないかもしれな
い。しかし 、大野研究室ではこれら全ての研究テーマを連携させて考えている。今年度の報告書では、これらの「連携プレー」を披露することは出来なかったので、この点については来年度の報告書に収録したい。

472