第 1部
ライフラインとしてのインターネット に関
する考察

1

第

1章

はじめに
ライフラインワーキンググループでは、社会基盤としてのインターネットの役割はど う
あるべきか、特に災害時のインターネットの活用と災害にも耐えられるシステムの技術的な課題について研究を進めている。
1995 年の阪神淡路大震災から 3 年が過ぎ 、WIDE プロジェクト以外にもインターネッ
トを利用することを想定した災害時システムの実験を行ったり、具体的なシステムとして構築する組織が現れてきていることをみても、災害時のインターネットの活用についての関心は高くなってきている。
1997 年度は、「普段使っていないシステムは、いざというときに使い物にならない。」という考え方から、" 定常的に動作するシステムの構築" を中心として活動を行ってきた。また、構築したシステムをライフラインワーキング以外から利用可能とする API を公開することも検討してきた。
これらの活動を下に行った「第 3 回 インターネット災害訓練」での報告を中心に、\定常運転" と今回初めて実質的な活動となった \他組織との協力体制" についても述べる。
WIDE プロジェクトでは、引続き定常運用環境を整備し、社会情報基盤としてのインター
ネットを技術的、運用的側面から見直し 、社会基盤としての可能性とそれを実現するための課題を整理し検討していく。また、災害時におけるインターネットの役割についての検討を進め、1998 年度も、インターネット上での災害訓練を実施することで、問題意識のイ
ンターネットコミュニティへの喚起、実用的なシステムの研究、開発を進めていくつもり
である。

3

2章
第 3 回インターネット 災害訓練報告
第本章では、1998 年 1 月 17 日、18 日に行った第 3 回インターネット災害訓練について報
告する。

2.1

訓練の目的

従来の第 1 回、第 2 回のインターネット災害訓練と同様に、この訓練の目的は大きく次の 2 つにある。

 実際に稼働するネットワークを利用して行うことにより、システムの実用性を高める
とともに、問題点を明らかにして今後の活動にフィードバックしていくこと インターネット、およびその他ネットワークに関係しているできるだけ多くの方々に関心を持ってもらい、災害時におけるネットワークコミュニティのあり方を考え、予期せぬ災害に備えるためのきっかけとなること
今回の訓練で新たに加えた機能などの検証はこの目的の 1 つ目に含まれる。

2.2

訓練の内容

第 1 回、第 2 回を通じて行ってきている「生存者情報データベースへの登録および検索
訓練」である。
今回の訓練では、全国 3 箇所に配置された IAA サイトと、3 箇所の公開実験会場と連携をとりながら運営することとなった。詳細は別途述べる。

2.3

主催・共催・協力組織・後援組織

今回の訓練の主催・共催・協力組織・後援組織を述べる。

 主催 WIDE プロジェクト
4

第 1部

ライフラインとしてのインターネット に関する考察

 共催{ 被災者支援広域情報ネットワーク推進協議会{ 新潟インターネット研究会{ インタービジネスネットワーク (IBN) 協力組織 (順不同){ (株) 日本サテライトシステムズ (JSAT){ 日本電信電話 (株){ 日本電信電話 (株) 新潟支店
{ NTTDoCoMo 新潟支店
{ ド コモショップ新潟店{ 東京電力{ 三菱商事 (株){ 三菱電機 (株){ 松下電送 (株){ ハイウェイ・トール・システム (株)

 後援
{ 東京都
{ 千代田区
2.3.1

公開実験会場 1 月 17 日 (土) 9 時〜 17 時
新潟会場
日本電信電話 (株) 新潟支店プラザビル 1 階

 1 月 17 日 (土) 11 時〜 17 時
神戸会場
神戸ハーバーランド、キャナルガーデンの「せいでん」前 1 月 18 日 (日) 11 時〜 15 時

(悪天候のため中止) 秋葉原駅前広場

5

1997 年度 WIDE 報告書

62.4

システム全体

第 3 回の訓練において構成された IAA システムについて述べる。

2.4.1

ネット ワーク構成

図 2.1: IAA システムの概要
システム全体のネットワーク構成を図 2.1 に示す。

2.4.2

システム構成次にシステムの構成を図 2.2 に示す。

2.4.3

前回訓練システムとの相違

基本的な訓練内容は前回とほぼ同様だが、前回の訓練で得られた経験を踏まえて、シス
テムの改善および強化を行った。

 入力インターフェースの改善
 CGI プログラムの改善

第 1部

7

ライフラインとしてのインターネット に関する考察Æ¾¾º¼Éã7ê9y
G3

 B

FAX

FAXB

G3
FAX

G3

DTMF

Internet FAX±º¯§Ãö¼ Õóè¯§Ãö¼

OCR/OMR BOX

G3
FAXLLDBÚðË¶î

SMTP

IAA
Windows
Client;±ºPhone Shell

FAX

FAX;Web
Õóè

SMTP

§öÂVÐÆËHTTP
Web
Client

SMTP

SMTP
LLDB

HTTP

ÚðË¶î
Mail

´
LLDB
Å
LLDB

HTTP

LLDB

ÚðË¶î
Mail

CGI

ÚðË¶î

´
LLDB
Å
LLDB

Mail

´
Å

CGI

ÚðË¶î

LLDB

CGI

ÚðË¶î

LLDB

IAA
DB

IAA
DB

IAA
DB

íà!~
ÊØ­Ë
ÚØÚØ
IAA²ì¼Â©!~ÊØ­Ë
NNTP ÚØÚØ
IAA²ì¼Â

Ê{ÚØIAA²ì¼Â

NNTP

NNTP

IAA Transport§öÂVÐÆËÕÓËáîÄ°æ¼Ë

図 2.2: IAA システムの構成

1997 年度 WIDE 報告書

8 DNS による広域負荷分散機能
 衛星回線を用いたマルチキャスト通信 IAA データベースの構築
 CHECKER モジュール機能
2.4.4

入力インターフェースの改善

前回の訓練では、屋外での公開実験の際に問い合わせ手段として WWW (ワールド ワイ
ド・ウェブ ) による入力インターフェースを提供したが、今回の訓練では電話や FAX とイ
ンターネットを巧みに協調させた。
次に今回の登録・検索のユーザインタフェースをしめす。

 登録のためのユーザインタフェース{ WWW (従来からの提供機能){ WWW 英文ページ (追加){ FAX (追加)
{ 電話 (追加){ Windows 用専用クライアント (追加)

 検索のためのユーザインタフェース{ WWW (従来からの提供機能){ WWW 英文ページ (追加)
{ 電話 (追加)
新しく追加されたインターフェースについて簡単に説明しておく。

 WWW からの英語画面での登録・検索
従来から提供している登録・検索ページの英語バージョン

 Windows95/NT からの被災者情報の登録 (専用ソフトウェア)

被災者情報登録のための Windows95/NT 用クライアントソフトウェア。

 電話からの被災者情報の登録

音声ガイダンスに従い、トーン (DTMF) で登録を行う。氏名等の文字入力は、ポケッ
トベルの文字入力方法と同等の入力方法。

第 1部

ライフラインとしてのインターネット に関する考察

9 電話からの被災者情報の検索 (FAX からの取り出し )登録と同様の入力方法で検索情報の登録を行って、検索結果を FAX で取り出す。

 FAX からの被災者情報の登録

音声ガイダンスに基づき IAA 登録シートを取り出して、その登録シートに記入してFAX を送信して登録を行う。

OCR や OMR の自動認識に失敗した時の場合を考慮して、ボランティア (IAA オペ
レータ) による登録情報の修正を行えるようになっている。
FAX 情報をインターネット上に流すために InternetFAX を使用した。
2.4.5

IAA クラスタを構成する計算機スペック

 東京大学{ UNIX PC サーバ 2 台 (IAA DB マシン、IAA 衛星マシン ){ IAA DB マシン
CPU Pentium/200 MHz
MEMORY 128MB
HD 20GBOS BSDI BSD/OS 3.1

 北陸先端科学技術大学院大学{ UNIX PC サーバ 2 台 (IAA DB マシン、IAA 衛星マシン ){ IAA DB マシン
CPU Pentium/166 MHz
MEMORY 64MB
HD 2GBOS BSDI BSD/OS 3.1

 奈良先端科学技術大学院大学{ UNIX PC サーバ 2 台 (IAA DB マシン、IAA 衛星マシン ){ IAA DB マシン
CPU Pentium/200 MHz
MEMORY 128MB
HD 4GBOS BSDI BSD/OS 3.1

1997 年度 WIDE 報告書

10

2.5

ユーザインターフェイス

本節では、用意した各ユーザインタフェースの詳細について述べる。
今回の訓練では、利用者が、登録、検索をおこなう手段として、以下の 4 つのユーザイ
ンタフェースを用意した。

種類

FAX
電話

WWW
Windows クライアント

登録
○
○
○
○

検索
×
○1
○
×

2.5.1章2.5.2章2.5.3章2.5.4章表 2.1: ユーザインタフェースの種類
今回の訓練で、検索インタフェースを電話、WWW の 2 種類に限定したのは、多くの検索用インタフェースを準備するよりも、より多くの登録インタフェースを準備することの方が重要であると考えたからである。これらの理由として、

1. 電話や WWW は、一般的なインタフェースである。
2. 被災地外 { 被災地外での通信手段は、ある程度確保されていると考えられる。
3. 被災地外に設置されたサーバ機材がすべて壊れる可能性は少ない。
4. 被災地が、どのような状況に陥るのかを予想することは非常に困難であり、多くの登録インタフェースを準備しておくべきである。
などがあげられる。

2.5.1

FAX を利用した登録ユーザインタフェース

通常コンピュータを利用しない人がいきなりコンピュータの操作を行うことは非常に困難である。そういった人たちのためにコンピュータを利用せずに安否情報を登録することができるシステムが必要となる。そこで 、FAX を利用した登録システムを用意し 、コン
ピュータに不馴れな人へのユーザインターフェースを提供した。
FAX は一般の家庭にも広く普及しており、コンピュータよりも扱いが容易である。危機の破損においても、コンピュータと比べて修理が容易であると思われる。
したがって、一般の人が安否情報を登録するためのユーザーインターフェースとして有効であると考えられる。

第 1部

ライフラインとしてのインターネット に関する考察

11

FAX による登録

FAX を使った登録システムを、次のような 3 つのシステムで構成する。

 インターネット FAX (Server)
FAX 画像として送られてきたユーザの安否情報を OCR/OMR BOX に出力する

 OCR/OMR BOX
インターネット FAX のデータを受け付け、文字やマークの認識処理をおこない、認
識情報修正 WWW サーバへ情報を出力する

 認識情報修正用 WWW サーバ
OCR/OMR BOX で認識した情報を受け付け、誤った認識情報の修正をおこなう HTML
データを出力する。Web クライアントから情報の修正完了時点で、IAA システムに情報を登録する。

FAX から IAA システムへ安否情報を登録するため、IAA システム専用の登録用紙 (図2.3) を作成した。ユーザがこの IAA 登録用紙に安否情報を記入し 、FAX 登録システムに
FAX を送ることで、IAA システムに情報を登録することができる。(図 2.4の (1))
FAX 登録システムは、ユーザから受信した IAA 登録用紙の画像をコード 情報に変換するために、手書き文字認識 (以後 OCR) やマーク認識 (以後 OMR) などの技術を利用する。
(図 2.4の (2) 、(3))
現在の文字認識技術では、人が記入した手書き文字を人と同じようにコンピュータで認
識・判断することは難しく、認識した情報の中に誤った情報が含んでしまう。
そこで誤った情報を修正するシステムとして、認識情報修正用 WWW サーバのシステムを設計した。(図 2.4の (4) 、(5))

 インターネット FAX の利用
FAX とインターネット FAX の両方から情報を入力する装置として、インターネット
FAX を利用した。
インターネット FAX のプロトコルは、IETF( インターネット・エンジニアリング・タ
スク・フォース) にて WIDE プロジェクトの WT ワーキンググループなどが標準化を進めている。
第 3 回インターネット災害訓練では、そのインターネット FAX のプロトコルをサポートした製品の一つである UF-770i(松下電送システム製) を使用した。

FAX 登録システムとして、一般公衆回線網から受信した G3FAX の画像をインター
ネット FAX のデータフォーマットに変換し 、OCR/OMR BOX に出力する。

121997 年度 WIDE 報告書

図 2.3: FAX による IAA 情報登録用紙

第 1部

ライフラインとしてのインターネット に関する考察

インターネットFAX

ユーザ
ユーザ
(1)
インターネット

(1)
PSTN
FAX

G3FAX
インターネットFAX
Server

LAN

(2)

(3)

認識情報修正用
WWWサーバ
httpd

OCR/OMR
BOX

(5)
(4)
(4) インターネット

情報修正ボランティア

安否情報の登録
情報修正ボランティア

IAA
System

図 2.4: FAX による安否情報の概要

13

1997 年度 WIDE 報告書

14 OCR/OMR BOX の利用
OCR/OMR BOX は、文字やマークを認識する機能と、文字やマークを認識した場
所の画像データや、特定の場所の画像データを切りぬく機能を保有したシステムである。それらの画像を認識処理した結果と一緒に、画像データを出力する。

FAX 登録システムとして IAA 登録用紙のフォーマット情報を認識処理するため、あらかじめ決定した記入欄やマークの位置や条件を OCR/OMR BOX に登録する。ユーザが記入した IAA 登録用紙の情報を、インターネット FAX を経由して OCR/BOX
BOX で受け付け、あらかじめ登録した認識情報にしたがって文字やマークの認識処理をする。OCR/OMR BOX は、それらの認識結果や切り出した画像に加えて、認識処理した際の認識ステータス情報を付加して認識情報修正用 WWW サーバへ出力する。
手書きの文字認識は、認識した結果の中に誤認識を含んでしまう。そのため、認識した情報を修正する必要がある。しかし 、人手を期待したシステムでは、入力する情報に対して充分な人員の確保を保証できない。FAX から入力される情報量をあらかじ
め見積もることができないため、修正作業に参加している人員の作業量で賄えない場合が考えられる。したがって認識する情報や方式を工夫し情報に制限を加えること
で、人による作業量を減らす必要がある。そこで、IAA システムの FAX 登録用紙では、認識率が悪くなるような情報の記入方式を排除して、修正作業者への負担を減らした。
マーク認識 (マークシート方式) は、文字認識に比べて高い精度で認識処理が得られるため、あらかじめ決めた情報の場合はこちらを用いるべきである。文字認識は、ひらがなや漢字による記入をすると、人が確認しても判断できない場合がある。そのため、IAA 登録用紙を設計するにおいて、数字と英文字 (大文字) が同一の記入欄に混在しないようにした。

 認識情報修正用 WWW サーバ
システムとしてはオペレータを必要としないシステムの方が好ましいが、文字認識が人と同じように認識できるレベルにまで至っていない。
認識技術を進めることは重要であるが、災害の発生するまでに開発が間に合わないの
では 、IAA システムとして意味がない。また、安否情報という重要な情報を扱うため、登録・検索のクオリティを保つためには、間違った認識をすることは許されない。
そこで、IAA システムにおける FAX 登録システムは、OCR/OMR BOX で認識した情報を IAA システムに登録する前に、誤った情報を修正するシステムを併せて構築した。
情報の修正をするシステムでは、作業する人手が不足することが考えられ、それらの解決手段として、ネットワークを介して修正作業をするシステムを構築する必要が第 1部

ライフラインとしてのインターネット に関する考察

15

あった。
阪神淡路大震災では、ボランティアの活動が、復旧に大きな貢献をした。近年、多くの人々にボランティア活動への興味や、参加意識が高まりつつある。しかし 、実際にボランティアとして参加するには交通手段や宿泊場所の問題が大きく、ボランティア活動の妨げになる。
そこで、ネットワーク上から参加するボランティアとして、人々の協力を得ることを前提としたシステムとして認識情報修正用 WWW サーバを構築した。
認識情報修正用 WWW サーバは、OCR/OMR BOX から出力した認識処理に応じて、認識処理の結果が不良と返した場合と、良好と返した場合の、2 つの処理に分かれる。

{ 認識処理が不良な処理を返した場合
ボランティア情報修正者が、IAA 登録用紙の 1 ページの画像情報をすべて入力する。

{ 認識処理が良好な処理を返した場合
ボランティア情報修正者が、認識時に出力した画像データと認識結果を確認して、情報修正をする。
ネットワークを介してボランティアとして自由に参加できる環境を提供することで、不特定多数の人が参加でき、故意に誤った情報を入力する人でも参加できる。そのため、ボランティアが入力した内容を最終的に確認をする人員を設け、情報の確認をした後、IAA システムへ登録した。

第 3 回インターネット 災害訓練での登録方法
第 3 回インターネット災害訓練では、IAA 登録用紙の配布方法を 2 種類用意した。IAA
システムの音声サービ スから 、音声メッセージにしたがい、プッシュトーンを入力して、FAX から IAA 登録用紙を取り出す方法と、ホームページから PDF 形式や PS 形式や TIFF
形式で作られた、IAA 登録用紙をダウンロードしてから、プリンタで印刷する方法。
ユーザは、入手した IAA 登録用紙に安否情報を記入し 、FAX 登録システムに FAX を送信する。
認識情報修正用 WWW サーバは、パスワードによる制限をおこない、運用した。

第 3 回インターネット 災害訓練での結果
登録情報の中にプライバシ情報が含まれることをあまり好ましく思わない人たちがいることは確かである。そこで、FAX の登録システムでは、認識情報修正用 WWW サーバをファイヤウォール内のネットワークに接続し 、訓練することで対処した。

1997 年度 WIDE 報告書

16

認識情報修正用 WWW サーバで、必要となる人員を把握するため、あらかじめ実験をおこなった。実験では、FAX 1 ページ分を修正するのにどれだけの時間がかかるかを計測した。この結果、1 ページ分の FAX を受信する間に、修正しなければならない FAX 1 ペー
ジ分を修正できることがわかった。すなわち、1 回線あたり一人の人員で対応可能であるといえる。
しかし 、実際の訓練では、情報の入力装置である FAX や、電話回線の状態が異なり、想定していた画質が得られなかった。このため、OCR/OMR BOX による認識処理がうまくいかないものが頻発し 、認識情報を修正する人員への負担が増した。
今回初めて導入した FAX 登録システムの問題点や不足している技術を明確にすることができた。今後は、それらを改善するための検討をおこなっていかなければならない。また、利用者への対応として、IAA 登録用紙の記入欄を利用者が容易に理解できるような配置についても考えていく必要がある。
さらに、情報修正に参加しているボランティアの参加数が少ない場合に、登録情報のクオリティを極力落さず登録するための方法や、逆にボランティアが多い場合を想定し 、一つの情報を複数の人に、修正、登録してもらい、自動的にそれらの情報が統合するための方法についても検討していきたい。

2.5.2

電話を利用したユーザインタフェース

1997 年 9 月 1 日に行われた被災者支援広域情報ネットワーク実験のアンケート結果によると、操作性に問題があると感じた人は、29% であった。この傾向は高齢者ほど強く、60代以上の高齢者では 41% に及ぶ。そこで、比較的身近な機器である電話を利用して公衆電話網から生存者情報の登録、検索を行うシステムを構築した。

電話を利用した生存者情報登録機構
電話を利用した登録方法として音声認識の利用が考えられる。しかし 、現在の技術では不特定多数の人間を相手にした音声認識は困難であり、生存者情報を正確に登録できない。
そこで、簡単に人間が入力できて、かつシステムの側で認識の容易なタッチトーンを用いた登録を行った。
タッチトーンから入力できるのは、数字と#と のみである。その限られた要素を組み合わせて、生存者情報を入力する必要がある。生存者情報として、個人を特定するための氏名、性別、住所等と個人の状態を入力することにした。
氏名の入力に関しては、ページャに平仮名を送る方式を採用した (表 2.2)。また性別や現在の状態の入力は音声ガイダンスによりいくつかの選択肢を読み上げ、タッチトーンを利用して選択することにより行う。
このシステムは、テレフォンサービス部とデータベース登録部から構成される (図 2.5) 。

3

 テレフォンサービス部
音声ガイダンスの再生やタッチトーンの認識処理を行い、データベースの処理できる第 1部

ライフラインとしてのインターネット に関する考察

1
2
3
4
5

1

2

3

4

5

6

7

8

9

0

あ
い
う
え
お

か
き
く
け
こ

さ
し
す
せ
そ

た
ち
つ
て
と

な
に
ぬ
ね
の

は
ひ
ふ
へ
ほ

ま
み
む
め
も

や

ら
り
る
れ
ろ

わ
を
ん
゛
゜

ゆ
よ

17

表 2.2: タッチトーンからひらがなへの変換表
形式に変換してデータベース登録部へ送る。これらの機能は WIDE/PhoneShell[18]を利用して実現している。

 データベース登録部
テレフォンサービス部から生存者情報を受取りインターネット上のデータベースに登録する。

電話と FAX を組み合わせた検索
検索も同様に、コンピュータを用いない手段が必要である。しかし 、音声によって検索結果を表現するのは、検索結果が大きいものであった場合に問題が生じる。そのため、検索者は電話で検索に必要な情報を入力し 、結果を FAX で受け取る。図 2.5.2は FAX による検索結果の例である。また、検索に時間がかかった場合の電話回線の占有をさけるために、検索に必要な情報を入力後、いったん電話を切り、改めて電話をかけなおし FAX で取り出す仕様となっている。
検索に必要な情報は、入力の手間や検索効率などを考慮して、氏名、年齢、性別、郵便番号の 4 項目とした。検索するための情報の入力方法は、電話による登録システムと同じ方法である。

2.5.3

WWW インターフェイス

今回の訓練では、利用者は、http://www.iaa.wide.ad.jp/DB/IAA-1998/ から、登録、検索を選択する形をとったが、これまでの訓練参加者のことを考慮し 、前回と同様に、登録 http://www.iaa.wide.ad.jp/touroku/
検索 http://www.iaa.wide.ad.jp/kensaku/
からの利用も可能とした。
登録において、今回の訓練で前回までと大きく異なる点は、本人による登録フォームと他人による登録フォームを分割したことにある。これは、「登録者本人が死亡した」などと18

1997 年度 WIDE 報告書

生存者情報データベース

生存者情報登録

インターネット

データベース登録部

生存者情報

テレフォンサービス部

氏名： ○○××
年齢： ２０
性別： 男性〒 ： 1510002
状態： 無事

音声ガイダンス

公衆電話網

タッチトーン

名前を登録して下さい

51513255#...

図 2.5: 電話を利用した生存者情報登録機構の構成図

第 1部

ライフラインとしてのインターネット に関する考察

図 2.6: 電話・FAX による検索結果

19

20

1997 年度 WIDE 報告書

図 2.7: WWW 本人用登録画面

第 1部

ライフラインとしてのインターネット に関する考察

21

いった論理的矛盾のある情報を入力できなくすることで、入力ミスを防ぐためである。また、登録者名など登録者本人であれば入力しなくてもよい項目を減らすことで、登録者への負担を軽減することになるという考えによる。図 2.7に本人登録用のフォームを示す。また、在日外国人の利用を考慮し 、英語ページからの登録、検索も可能とした。
今回の訓練では、1998 年 2 月より導入された 7 桁郵便番号を利用している。このため、被災者の住所をより細かい地域に特定できるようになった。しかし 、実際には、検索結果に郵便番号を示したとしても、多くの場合、その番号から地域を特定することは難しいと考え、登録時に郵便番号が登録されていれば 、郵便番号の逆引きをおこなうサービスも実験的に導入している。
登録、検索の情報を受ける CGI では、より多くの処理が行えるように mod-perl を利用
し 、CGI の実行にかかるコストを下げ、より多くの処理が行えるようにした。また、後述の IAA-DB へのアクセスプロトコル (2.7 章参照) を規定したことにより、インタフェース
部では、一切内容に関するチェックはおこなっていない。これによって、これまでのシス
テムではおこりがちだった各モジュールでの多重チェックといった無駄な処理を省き、効率の構造を目指した。

2.5.4

Windows クライアント

第 1 回、第 2 回の災害訓練の経験をふまえ、さらなるユーザインタフェースの多様化、そして電子メールを用いたインタフェースは、オペレータの負荷が高いことへの対策の一つとして、パソコン上で動作する IAA 情報入力専用システムが検討された。
今回、Microsoft Windows 95/NT 上で動作する専用の Windows クライアントを実装するにあたり、特に留意した点について、そして今回の実験によって発見、指摘された問題点について述べる。

Windows クライアント 導入のメリット
第 2 回災害訓練までの電子メールを利用したユーザインタフェースでは、特定のメール
フォーマットを指定し 、書式に準じた記入を行なってもらう必要があり、意図しない書式で記入された場合などに手作業で修正、登録するオペレータを必要とした。
今回、Microsoft Windows95/NT 上で動作する IAA 情報登録専用フォームを用意し (図2.8参照)、クライアント側で整形し 、IAA サイトに送信することで、登録情報修正オペレー
タを不要とした。
そして、クライアント側でデータ処理が実現できることを利用して、入力データの切りわけ処理のほか、今後ネットワークに接続が困難な状況下で、クライアント内部に登録情報を蓄積し 、ネットワーク接続が確保できる場所で一括送信ができるようにすることにより、より多くの IAA 生存者情報を収集することが可能となる。

22

1997 年度 WIDE 報告書

図 2.8: 日本語版 Windows クライアント情報登録画面

第 1部

ライフラインとしてのインターネット に関する考察

23

また、登録に必要な情報のみを高速に入力できるよう、入力コントロールを配置することにより、登録情報入力の際の負荷を軽減した。

Windows クライアント の利用
今回の訓練では、Windows クライアントの配布方法を、WWW 上でネットワーク経由で配布する形式を採用したため、利用したユーザ層が最低限 WWW ブラウザや電子メールなどを利用でき、インストールができない、キー入力 (特に漢字入力方法) が困難だという例は少なかったと思われる。
しかし 、あまりコンピュータの操作方法を知らない層に導入し 、一般的に常時普及させるためには、インストール手順の容易さ、操作方法の簡易さ、操作方法の手引となるヘルプファイルの充実といった改善が必要である。

国際化対応
第 2 回災害訓練での登録情報では、氏名の姓名、及びふりがなを必須項目としていたた
め、データ登録対象者を日本人、もしくは日本語が理解できることを前提として実装されており、在日外国人などの登録、検索について考慮されていなかった。
今回、外国人登録者を登録検索の対象とするために、データレコードとして国際名の導入を行ない、またユーザインタフェース側の対応として、英語インタフェースおよび英語
ドキュメント添付することにより、国際化対応を実現した。(図 2.9参照)

今後の課題
今回、Windows クライアントの導入により、登録時のオペレータを不要とし 、運用側の負荷を軽減できたが、同時にさまざまな課題も発生した。
特に今後、重点的に取り組む必要があるものを、以下に述べる。

 送信時の暗号化
各 IAA サイト間でのデータ配送には、暗号処理を行ない、万一のデータ外部流出やデータ改変などの問題は解決されているが、今回、クライアントから SMTP で IAA
サイトまでの通信データは、特に暗号化がされておらず、経路間に悪意をもったサイトが存在する場合、プライバシ情報の流出やデータ改変の可能性は否定できない。そのため、IAA サイト間のデータ配送と同様に、クライアント -IAA サイト間で暗号処理を施す必要があると思われる。

 クライアント内部への蓄積、一括送信
現在のクライアントの実装は、登録情報送信時にネットワーク接続が確保されている必要があり、例えば災害地の中心部などのネットワーク接続の確保が困難な地域の24

1997 年度 WIDE 報告書

図 2.9: 英語版 Windows クライアント情報登録画面

第 1部

ライフラインとしてのインターネット に関する考察

25

場合、情報登録に支障をきたす場合が考えられる。実際の利用方法としては、例えばWindows クライアントの動作しているノート PC などを災害地に持ち込み、IAA 生
存者情報の収集活動を行ない、ネットワーク接続を確保できる場所にノート PC を持ち出して、一括して IAA サイトに送信することになると思われる。そのため、クライアント内部で処理を実現できることを利用して、登録情報をクライアント内部に蓄積しておき、ネットワーク接続を確保した段階で一括して送信できるようにする必要がある。

 さらなるユーザインタフェースの改善
今回は操作方法をある程度理解しているユーザ層を仮定した場合、良好な動作を実現できたが、災害時に使用する利用層を考えると、今以上に親切な操作手順を実現す
る、もしくは操作方法がわからない場合に適切な支援を自動的に行なう必要がある。
そのため、各項目に対するヘルプ メッセージの充実、ユーザレベルに応じたインタ
フェースの使い分けなどを実現する必要がある。

2.6

広域負荷分散第 3 回訓練における IAA クラスタは WIDE インターネットの 3 箇所に設置され、各クラスタごとに WWW サーバを 1 台ずつ提供する。これら合計 3 台の WWW サーバに対して予測される大量の処理要求を分散するために、IAA システムは広域負荷分散機構を持つ。
広域負荷分散技術としては 、WWW サーバに対する大量のアクセス負荷を分散するた
めに、BIND 4.9.3 以降のネームサーバのラウンド ロビン機能を利用して、WWW ブラウ
ザからの大量アクセスを複数の WWW サーバに対して分散する方法が広く一般的に用いられている。この他、シスコシステムズの DistributedDirector[19] や NTT のサーバトラ
ヒック分散制御システム DyMS[20] などがある。
第 3 回訓練では、ネームサーバのラウンド ロビン機能を利用したアクセス負荷分散の手法を採用した。この際、不均一な処理能力を持つサーバ群を対象として、サーバ処理性能を考慮した重み付けラウンド ロビン処理を行なった。以下、広域負荷分散機構の設計と実装に触れた後で第 3 回訓練における結果とその考察を述べる。

2.6.1

負荷分散比率の設計と実装

今回の IAA システムを構成する IAA クラスタは表 2.3 に示すように不均一な IAA デー
タの登録処理性能を持つ。このような不均一なデータ処理性能を持ち、IAA トランスポー
トにより同一コンテンツを提供可能な複数の IAA クラスタを対象に、アクセス負荷分散を目指す。主たる設計方針を次に示す。

 ネームサーバにおける WWW サーバの複数 A レコードから重み付けラウンド ロビ
ンにより、サーバを選択1997 年度 WIDE 報告書

26

IAA クラスタ
奈良
東京
北陸
サーバ OS
BSDI BSD/OS 3.1
サーバ CPU Pentium/200 MHz Pentium/166 MHz Pentium Pro/200 MHz
サーバ メモリ
128MB
64MB
128MB
負荷分散比率421
表 2.3: IAA クラスタ間の広域負荷分散比率

 事前に計測されたサーバの処理性能に基づく静的分散比率の導入
 各 WWW サーバへ複数 IP アドレスを用いた IP 到達性の提供
IAA クラスタの登録サービス性能を事前に登録シミュレータを用いることによって計測した結果を図 2.10 、図 2.11 に示す。次に、この相対的な登録性能指数にもとづき、広域に配置された 3 台の IAA クラスタ間の負荷分散比率を表 2.3 のように決定した。またその比率にしたがって WWW サーバの A レコードが図 2.12 のように重み付けラウンド ロビン
するようにネームサーバの A レコードを定義した。
複数の IP アドレスを用いて個々の WWW サーバへアクセスするために、BSDI BSD/OSの ifcon g コマンド オプションの一つ、alias 機能を用いて、複数 IP アドレスを各サーバへ割り当てた。

2.6.2

負荷分散結果と考察訓練を通じての負荷分散結果を図 2.13 ならびに図 2.14 に示す。このデータは IAA クラ
スタの WWW サーバアクセスログから算出した。
奈良の IAA クラスタが 17 日の午後 3 時から午後 4 時までの 1 時間近く、動作不安定に陥ったことを除き、他の IAA クラスタは継続してサービスを提供した。訓練期間の 2 日間を通してまとめると、奈良の IAA クラスタの停止時間も含めたアクセス分布の場合、2日間を通して 3% の幅で分布が目標値に近付いた。奈良の IAA クラスタの停止時間を除いたアクセス分布の場合は、さらに 2 日間を通して 2% の幅で分布が目標値に近付くことができた。
一方、1 時間単位で実際のアクセス数の分布がどのように推移しているのかをまとめてみた (図 2.15 参照)。処理率の分布は 17 日の 15 時台に奈良の IAA クラスタがサービスを一時的に停止していたことを示している。また、18 日の早朝に東大の IAA クラスタの処
理率が落ち込んでいるが、この時間帯はサンプル数が少ないことと、開発者が特定の IAA
クラスタへ直接アクセスする行為によって、分布がひずんでいると考えることができる。
以上より、ネームサーバの重み付けラウンド ロビンによる広域負荷分散は目標をほぼ達成したといえる。

6

6

第 1部

ライフラインとしてのインターネット に関する考察

図 2.10: 100 件単位の登録処理時間

図 2.11: 相対的な登録性能指数

図 2.12: 広域負荷分散の実装

図 2.13: 分散結果 (1)図 2.14: 分散結果 (2)

27

28

1997 年度 WIDE 報告書

図 2.15: 1 時間単位の分散結果

第 1部

2.6.3

ライフラインとしてのインターネット に関する考察29

課題

1. 今回は静的な負荷分散比率を導入したが、訓練時に発生したようにサーバの障害時や新たな IAA クラスタの組み込みに対応するためには、動的に負荷分散比率を制御できることが望ましい。

2. 分散比率の決定尺度としてサーバの登録性能を利用したが、サーバ間で OS やデータベースが異なる場合は、ネットワーク処理能力や検索性能も尺度として検討する必要がある。

3. IAA システムを構成する IAA クラスタの障害発生時に、サーバの切り離しやサーバの追加を手動で行なうのではなく、障害の自動検知機構とともにサーバ単位のプラグ
イン、プラグアウトが行なえることが望ましい。

4. IAA クラスタへ複数 IP アドレスを割り振るためには 、クラスタを接続するネット
ワークセグ メントのアドレス空間に余裕を持たせる必要がある。

5. IAA クラスタ数の増加やクラスタ間の処理能力の差が広がる場合、BIND 4.9.3 以降のネームサーバにおける A レコード の記述数の限界から、重み付けラウンド ロビン
を正確に実装することができない。そのため、第 2 回訓練で利用された横河電機のSuMiRe やシスコシステムズ社の LocalDirector[21] を利用するなどして、同一クラ
スタ内に存在する複製サーバ群を他のクラスタから見て隠蔽するといった工夫が必要
となる。

2.7

アクセスプロト コル

IAA システムは、様々なユーザインタフェースを備えている。これらのユーザインタ
フェースに対し 、IAA システムが提供するデータベースへアクセスするための共通仕様として、アクセスプロトコルを定義した。

IAA システムのデータベースを利用するために、LLDB プロトコルを定義した。したがって本プロトコル仕様を公開することによって、IAA システムを利用するクライアントアプ
リケーションを誰もが作成できる。
現在提供しているユーザインタフェースだけではまだ不十分であり、よりユーザにとって使いやすいインターフェースを提供していく必要がある。
しかし 、すべてのユーザインタフェースをライフライン分科会だけで実現するのは、現状では困難であり、またライフライン分科会の目的は実装だけではなくその枠組みを提供することにあるため、プログラム作成には外部の協力が必要と考えられる。IAA システムにアクセスするための共通仕様として本プロトコルを定義することで、様々なユーザイン
タフェースの提供を促すことが期待できる。

1997 年度 WIDE 報告書

30

本プロトコルは、現時点で公開していない。しかし 、将来的には一般に公開する予定で
ある。

2.7.1

アクセスプロト コル仕様の概要

本プロトコルは 、FTP や SMTP のようにテキストベースで、コマンドに対する応答も3 桁の数字で表されたステータスコードを返す。
本プロトコルは、プロトコルのバージョンや、データベース種別をチェックする「コネクションの確立」部と、登録や検索、コネクションの終了処理を行なう「コマンド 処理」部の 2 つのパートで構成されている。
以下に、各パートにおけるメッセージの流れの例を示す。ただし 、正常な場合のみ示し 、
エラーの場合は省略する。

 コネクションの確立

データの流れクライアントconnect→←→→←"proto-ver=1.0nn""db-name-ver=IAA/0.1nn"

サーバ

100 "welcome lldbnn""105 waiting for your operationnn"

 コマンド 処理

登録 (registry)
クライアント"registry""LYOMI=yamadann""FYOMI=taronn""AGE=25nn"".nn"(データの流れ) サーバ
→
←
→
→
→
→
←

"101 registry: startnn""105 registry: successnn"

第 1部

ライフラインとしてのインターネット に関する考察

検索 (query 、get)
クライアント"query 2 0nn"

(データの流れ) サーバ
→
←
→
→
→
←
←
←
←
←

"LYOMI=yamadann""FYOMI=taronn"".nn""get 23""quitnn""104 3 item hitnn""23nn""186nn"".nn""105 query: success"

→
←
←
←
←
←
←
←
→
←
←
←
←
←
←

"get 186"

終了
クライアント"101 query: startnn""103nn""LYOMI=yamadann""FYOMI=taronn""AGE=32nn""PLACE=osakann"".nn""get: successnn""103nn""LYOMI=yamadann""FYOMI=taronn""AGE=25nn"".nn""get: successnn"(データの流れ ) サーバ→←"106 quit: successnn"(close)31

1997 年度 WIDE 報告書

32

2.8

ト ランスポート

2.8.1

設計の方針

IAA システムは広域分散データベースを中核とするシステムである。本システムが災害時に利用され、その範囲も特定できないことから、

 十分なスケーラビリティをもっていること、
 システムの分断や部分的な障害、局所的な負荷の集中に対して、その影響がシステム全体に影響しないこと (頑強性) 、が要求される。一般的に分散データベースは、個々のデータベースの同期に関する時間的制約が強いほど 、また排他制御やアトミックオペレーションなどの要求が強いほど 、プロトコルは複雑になり、集中化するため、上述の要件を満たすことは困難となる。そこで、このようなコンシステンシに関する制御をできるだけ簡略化し 、十分なスケーラビリティと頑強性を確保することとした。
図 2.16は本システムの概念図である。

APP

APP

APP

APP
DB

図 2.16: IAA システム概念図

分散されたデータベースがネットワーク上に配置され、それぞれにアプリケーションが動いている。アプリケーションはデータベースと直接接続する。このデータベースは、

 個々のデータベースはすべて同じ内容である。
 データベースに対する操作は参照と追加のみである。変更と削除はない。
 あるデータベースにデータの追加があると、その内容を放送型の通信によって他のデータベースに伝えるという方法で整合性の維持を行う。放送型の通信機構の信頼性が確保できれば、データベースの整合性も確保できることになる。
以下では、今回用いた放送型の通信の機構を中心に述べることにする。

第 1部

2.8.2

ライフラインとしてのインターネット に関する考察

33

ニュースとマルチキャスト による同期機構

IAA システムでは、データベースの同期機構にネットニュースシステムを利用している[22][23]。ネットニュースは、記事を蓄積転送型で広範囲に配布するシステムである。また、サーバ間を冗長に接続することで回線切断のような障害に強いのも特徴である。
加えて、今回の実験では、ニュースの配送機構の一部に衛星を用いた配送機構を採用した。この機構は、衛星回線の特徴の一つである単方向リンクにおける単方向ファイル転送機構である。さらに、衛星の同報性も利用してマルチキャストによるファイル転送を実現した [24]。以下の特徴を持つ。

 単方向リンクで動作 (送達確認が不要)
 UDP を利用 (マルチキャスト環境で動作) 簡単な輻輳回避
この機構の基本的な動作は、送信対象のファイルを複数の断片に分割し 、これを衛星リ
ンク (一方向) を通じて転送する。TCP のような送達の確認を行わないので、転送中にエラーが生じると、正常にファイルが転送されない。そのため、同一ファイルを繰り返し転送することで、エラーが生じても最終的には受信者にすべてのファイルの断片が到達し 、ファイルを転送できる。また UDP を利用していることからマルチキャスト通信へ応用で
きる。

2.8.3

プロト コル

一連のファイル転送では、複数のコマンドとデータが転送される (図 2.17 )。コマンドには、以下の 4 種類ある。

 FILENAME
 ATTRIBUTE DATA PAUSEATTRIBUTE と FILENAME はファイル転送の開始時に送信され、それぞれファイル
属性とファイル名を受信者に通知する。DATA は 、ファイルの断片とともに送信される。
PAUSE は、すべての断片を送信した後に送信される。
受信側では、上記のコマンド、データがすべて受信されると、ファイルが完成する。どれか、一つでも受信できなかった場合、一時ファイルとして保存され、欠けているコマン
ド あるいはデータの受信を待つ。

1997 年度 WIDE 報告書

34

file

attribute command
filename commanddata command
data
pause commandgap

図 2.17: コマンド パケット

2.8.4

再送機構

ファイルは常に再送されるが、送信待ちの行列を一つにすると、行列の長さが長くなると、新規に待ち行列に入るファイルは、送信開始までの時間が長くなる問題がある。そこ
で、優先度付の待ち行列を 3 つ用意し 、新規に到着したファイルを優先的に送信する機構を実現した (図 2.18 )。

記事

Q2

Q1

送信プログラム

図 2.18: 再送機構

Q0

第 1部

2.8.5

ライフラインとしてのインターネット に関する考察

35

輻輳回避

本プロトコルでは、送信者は、送信経路上の輻輳の発生が分からない。そこで、ファイルの断片の送信間隔を、断片の大きさ、衛星回線速度、予備実験の結果から決定し 、輻輳が起こらないように実装した。今回の実験では 100 ミリ秒に設定した。

2.9 IAA データベース
本節では、第 3 回インターネット災害訓練の IAA システムにおけるデータベースシステ
ムの特徴とシステム構成について説明する。また、実験結果についての評価を行い次回への課題を考える。

2.9.1

特徴

第 3 回インターネット災害訓練におけるデータベース部の特徴は以下のようである。
単一種類のデータベース すべての IAA クラスタのデータベースシステムとして PostgreSQL を使用した。
仮想データベースのためのアプリケーションインターフェースを統一

LLDB という、 LLDB プロトコルでアクセス可能な仮想的データベースシステムを提供した。LLDB は LLDB プロトコルでアクセスできるメタデータベースを指している。

DB 入力時の IAA 情報の完全性のチェック IAA データを NetNews の記事としてトラン

スポート部が配送する際に、X-Digest:ヘッダに IAA データの MD5 を付与し 、これを DB に入力する際に再計算し 、データに誤りが生じていないかをチェックした。

IAA データベースの修復機構 万が一、IAA データベースが破壊した場合を考慮し、ニュー
ススプールに存在する記事から IAA データベースを修復する機構 db-recover を用
意した。

2.9.2

データベースシステム

従来の IAA システムでは、第 1 回は、NDBM ライブラリを利用した独自のデータベー
スシステム (ssdb),Oracle7,WAIS 、第 2 回は、ssdb,Oracle7 といった複数のデータベースシ
ステムを使用し 、いわゆる n-version プログラミング手法をとってきた。
これは、データベースシステム固有の問題によって IAA システム全体が稼働しなくなることを避けるためである。

1997 年度 WIDE 報告書

36

しかし今回はあえて PostgreSQL のみを使ってデータベース部を構築した。これには以下のような理由がある。

 PostgreSQL が十分高速で稼働することがあらかじめ確認されていた。
 複数種類のデータベースシステムを用いた場合に、データベースシステムの種類だけ管理する人的資源が必要になり、管理コストが高くつくことが問題になっていた。

 全く同じソフトウェアコンポーネントを、それぞれ性能の違うマシンで稼働させた場
合に、何を考慮すべきなのかを明らかにするため。

 その他の DB が稼働させられるか直前まで決定しなかった。
PostgreSQL というフリーのデータベースシステムに、pg-server というアプリケーショ
ンインターフェースを経由してアクセスすることで、データベースシステムに依存しない
インターフェースを提供した。当然だが、pg-server はデータベースシステムに依存したものになる。

2.9.3

システム構成図 2.19に、データベース部のシステム構成を示す。
トランスポート部に IAA データが流れると、news2db がデータの完全性のチェックをし 、チェックの結果、完全であればそのデータを pg-server へ LLDB プロトコルを使って送信する。もし 、IAA データの破損を検出した場合は、pg-server へはデータを送らず、欠損した IAA データのメッセージ ID をログに書き出す。
pg-server は LLDB プロトコルから PostgreSQL との通信を行うためのプロトコルへの変換を行うためのプログラムである。この方式を用いることによって、どのようなデータ
ベースシステムを用いた場合にも、見掛け上は、LLDB に見せかけることができる。
DBrecover.pl は、ニューススプールには、IAA デーがあるが 、LLDB のデータベース
システムが破損し 、データベースを失った場合にこれを補完するものである。
DBrecover.pl はこのほかに、LLDB とのレコード 数の差を調べ、もしレコード 数に差がある場合には、Message-ID による比較を行いながら、LLDB にのみ存在しない IAA デー
タを news2db に投入することもできる。

2.10

公開実験

公開実験は、特定地域が被災したという想定で屋外でインターネットへアクセスできる空間を作り、一般の方に実際に生存者情報データベースへの登録および検索を行ってもらうことで、ユーザインターフェイス改善やその他の問題へのフィードバックを得ることとを目的としている。

第 1部

ライフラインとしてのインターネット に関する考察

37

IAAクラスタTransport部
news2db
スプールからの記事
DBrecover.pl

レコード数やmessage-ID

LLDB Protocol

virtual LLDB
pg-server

PostgreSQL専用のプロトコル

PostgreSQL

図 2.19: DB 部のシステム構成
第 2 回インターネット災害訓練では、日比谷公園においてインターネットカーを使って接続性を確保し 、数台のラップトップパソコンで一般の方に IAA システムを体験してもらった。
今回は他組織の協力を得て、新潟・神戸・秋葉原の 3 個所での公開実験を計画し 、悪天候のために中止になった秋葉原を除く 2 個所で実際に公開実験を行った。

2.10.1

ネット ワーク構成/機器構成

会場毎に次のような構成で実験を行った。

 インターネットへの接続性の確保
新潟会場 NTT DoCoMo 衛星電話および公衆電話回線モデムによる Dialup PPP
神戸会場 PHS および公衆電話回線とモデムによる Dialup PPP

 ユーザインターフェイス
新潟会場 音声/FAX 、WWW 、Windows クライアント
神戸会場 WWW 、Windows クライアント

1997 年度 WIDE 報告書

382.10.2

今回の特徴

新しい試みとしては次のような点が挙げられる。

 ユーザインターフェイスの試み
前回の WWW による 登録検索画面に加えて、FAX 、電話 (音声) 、IAA 専用クライ
アント for Windows など複数のユーザインターフェイスを提供した。また、キーボー
ド 入力に代わるものとして、手書き入力も提供した。

 複数個所での開催
WIDE プロジェクト以外の組織に共催として参加して頂き複数個所で公開実験を行った。

 一般参加者への説明
昨年の日比谷公園での公開実験での反省をもとに、{ WIDE プロジェクト{ ライフラインワーキンググループの活動{ インターネット災害訓練の主旨などを解説したパネルやパンフレットなどの資料を用意して、実験に参加して頂いた
一般の方に解って頂くことに力を入れた。

2.10.3

気付いた点と反省

 利用者の反応
新潟会場でのアンケートから利用者の反応には次のようなものがあった。

{ 今回新たに用意した FAX、Windows クライアントウェアなどは利用しやすい。
{ 「安否確認」以外で必要と思う情報はなにか
1. 自分や家族の周辺の被害状況
2. 避難場所からの各種要請 (救援物資、救護、ボランティア)
3. 交通機関、道路の状況
4. 電気、水道、ガスなどのライフラインの復旧状況
5. 行政機関からの案内{ 設置場所としては、避難所、公的機関 (区市町村役場、公民館等) 、コンビニエ
ンスストアなどの意見が多かったが、ボランティア団体の事務所、テレビ局、新聞社、病院、公衆電話などの意見もあった。

第 1部

ライフラインとしてのインターネット に関する考察

39{ 問題点としては、

3 電源の確保が難しいのではないか
3 災害時にパソコンがすぐに準備できないのではないか
3 情報ボランティアのような詳しい人のサポートが必要なのではないか
3 情報が正しいものかど うか判別できないのではないか
3 普段から動いていないシステムでは災害時に動く保証がないのではないかなどの指摘が多くあり、また、その他

3 自治体等の公的機関との連携
3 住民基本台帳からの一括登録などが必要との意見もあった。

{ ユーザインターフェイスの比較では、FAX と IAA Windows クライアントが操

作方法が判りやすく好評であった。WWW も判りやすいという意見が多かった
が、反応速度が遅い点が指摘されていた。新潟会場は通信回線が高速ではなく、
WWW ブラウザが WWW サーバとインタラクティブに通信しながら処理を行うことが影響している。反対に Windows クライアントは電子メールによって非同期に IAA システムに情報を登録するため、ユーザからみたときに無理がなかったためと考えられる。

 悪天候対策
秋葉原会場は屋根のないオープンスペースで、数日前に積もった雪が残っていたことと。当日、雨が降っていたために一般の方が利用できる状況になかったことに加えて、{ 会場内での電源の処理が十分な降雨対策をとっておらず、安全上問題があった。
{ 気温が低く、ボランティアを含めたスタッフの健康への対応が十分でなかった。
{ IAA データベース登録・検索用の端末として用意したパソコンなどの機器は、通常のオフィスを利用環境として想定しており、当日の天気の下では利用しにくかった。
などの理由から 、中止せざるを得なかった。災害時に利用するシステムでありながら、天候に左右されることは問題と思われる。今後、悪天候に対する対応を今後検討する必要がある。
また、ノートパソコンなど一般のコンピュータ機器等を利用する限りは、今回の秋葉
原会場のような屋外において災害時の登録・検索所を設けることは、所詮無理である
として、実際の災害時においても、最初から屋内あるいは半屋内で利用することを想定しておいたほうが良いとも考えられる。災害時に、IAA システムが展開できる
ような場所を他組織の協力などにより、あらかじめ確保しておくような方策も必要である。

1997 年度 WIDE 報告書

40

 他組織との連携

災害時にネットワークをしっかり活用していくためには、IAA システムを社会システムとして運用していくことも考えていく必要がある。その点において、今回他組織との連携が行えたことは、今後の展開において重要であった。

2.11

評価

本節では各モジュールでの評価について述べる。

2.11.1

電話を利用したユーザインタフェース

1 月 17 日 11 時から 20 時、1 月 18 日 9:00 から 15:00 の期間、これらのシステムの運用結果を表 2.4に示す。

電話を利用した登録
電話・FAX を利用した検索

件数
23 件
12 件

所要時間
5 分 11 秒
4分6秒

表 2.4: 電話による登録・検索回数と所要時間
今回の運用で、コンピュータを利用しないで電話、FAX を組み合わせることによって生存者情報の登録、検索が可能なことが示せた。
また、電話を利用した登録・検索システムは、利用者から以下の指摘を受けた。

 音声ガ イダンスが聞き取りにくい 氏名の入力が分かりにくい
今後、操作性に関して再検討していく必要がある。
また、災害時には電話による登録が集中することも予想される。これに対処できるように登録時間の短縮化についても検討していかなければならない。

2.11.2

WWW インタフェース

表.2.5に WWW インタフェースからの登録総数、検索総数を示す。括弧内は、(日本語
フォーム+英語フォーム) を意味している。
表.2.6に WWW インタフェースからの登録、検索の成功率を示す。検索 A は、未登録データの検索による失敗も「成功」と見なした場合、検索 B は、未登録データの検索によ第 1部

ライフラインとしてのインターネット に関する考察

41

る失敗を「非成功」と見なした場合を意味する。これらのデータから、約 80% が成功であり、インタフェースとしては、比較的わかりやすいものになったと考えられる。しかしならが、訓練では、登録者が自分の情報を検索してみることが多いことを考慮すると、検索
B での 35% は 、非常に低い成功率だといえる。利用者が誤った情報を登録したことにより、その検索に失敗しているのか、検索の際に、誤ったキーによって検索したことにより、失敗しているのかを見極め、早急な改善が必要だと思われる。

クラスタ

pc1
pc2
pc3
合計

登録

463
259
156
878

検索

合計

(450 + 13) 1754 (1720 + 34) 2217 (2170 + 37)(250 + 9)853 (830 + 23) 1112 (1080 + 32)(148 + 8)
513 (506 + 7)
669 (654 + 15)(848 + 30) 3120 (3066 + 64) 3998 (3904 + 84)

表 2.5: WWW インタフェースへのアクセス総数

クラスタ

登録

pc1
pc2
pc3

77:1%
79:5%
76:9%
77:8%

合計

検索 A

82:4%
82:8%
87:5%
83:4%

検索 B

33:7%
36:9%
45:3%
35:0%

表 2.6: WWW インタフェースからの成功率

2.11.3

Windows クライアント

日本語版と英語版を含めた各クラスタ別の登録状況を表 2.7 に示す。
Windows クライアント全体としては 75 件の登録が行われた。しかし 、今回の訓練では、国際化対応クライアントのアナウンスが徹底せず、英語版クライアントを利用した登録は1 件しか存在しなかった。

2.11.4ト ランスポート

前回から、衛星を用いたデータ配送機構を追加した。今回の実験では、ほとんど衛星経
由でデータが配送され、ほぼ期待通りに動作した。
ここでは、運用という観点から今回の実験について考察する。

1997 年度 WIDE 報告書

42

クラスタ

登録件数

pc1
pc2
pc3

29 (29+0)
27 (26+1)
18 (18+0)
75 (74+1)

合計

表 2.7: Windows クライアントによる登録状況
設定・構築: 今回の実験では、ニュースサーバ、データベースサーバ、衛星などの設定をすべて静的に行った。しかし 、災害時では、あらかじめネットワークの構成やシステムの設定を行うのは不可能である。また、システムを止めることなく、構成や設定の変更も要求される。災害が起きてから、迅速にシステムを構築、設定する機構が必要と考えられる。
セキュリティ: 本システムで、扱うデータは個人情報である。そこで、送信経路での盗聴や設定ミスによるデータの漏洩事故に対処するため、データを暗号化して送信している。この暗号鍵は、あらかじめ各サイトに配付している。しかし 、この作業も設定問題と同様に現実的ではない。
現在、設定・構築に関する問題の解決方法の一つとして「定常システムの運用」を検討中である。何もない状態から大規模なシステムを短時間で設定・構築するのはコストがかかるので、基幹的なトランスポート部分をあらかじめ構築しておき、災害時には、この基幹部分を中心にシステムをスムーズに拡張する方法である。定常運用の、もう一つの意味
として常に動作しているシステムで、運用の経験を積んでおかないと、災害時に効率の良い運用が期待できない点があげられる。
鍵配付の問題は、本システムだけでなく、一般的なセキュリティシステムにおける問題である。この問題の解決方法の一つに、公開鍵暗号系を利用した証明書発行局 (CA)[25] を使う方法があり、CA を用いる方法も考えられる。

2.11.5

データベース

データベース部は、非常に安定して稼働した。これは、単位時間当りのデータ登録件数
およびデータ参照件数が少なかったことに起因しているほか、PostgreSQL という比較的安定したデータベースシステムを選択したことも一因となっている。
また、今回の実験中奈良の IAA クラスタが、一時的にシステムダウンするといったハプニングが起ったが、この際にネットニュースのスプール間で同期がとれないという問題が発生した。この問題に対して、手作業で回復作業を行った。その他、news2db が、MD5 の第 1部

ライフラインとしてのインターネット に関する考察

43

値が合わず、pg-server へ送信しなかったニュースの記事も、同様に手作業で別の IAA ク
ラスタからニュースの記事として転送した。
今後の課題としては、以下のことが挙げられる。

 PostgreSQL 以外のデータベースシステムを使った IAA クラスタ
 LLDB プロトコルの見直し
 破損した IAA データの自動復旧機構
 ネットニュースのスプールの間の同期を監視する機構
今後はデータベース部に蓄積された IAA データをどの程度の時間保持し続けるべきなのかといった、運用に基づいた検討を行う必要がある。

第

3章

定常運用
本章では、IAA システムの定常運用に関する議論について記述する。

3.1

定常運用に関する課題

ライフライン分科会では、これまで、IAA のような非常時に利用するシステムは普段から動いていなければならないという考えに基づいて、インターネット災害訓練を行ってきた。そして、インターネット災害訓練を実施する数日だけではなく、常に利用できるシステムとしての実験をしなければならないという考えから、インターネット災害訓練で運用した IAA システムを定常的に運用することについても議論を重ねてきた。IAA システムの定常的な運用に対する課題としては少なくとも次の 2 つがある。

1. システムの維持管理に関する問題
2. 登録データの保持に関するプライバシの問題
システムの維持管理に関する問題については、本質的には人的資源といった問題があるが、稼働管理など運用をサポートするシステムを構築することによって工数軽減が図れると考えている。また、毎日生成されるログの管理などもできるだけ人手を介さずに行えるようにパッケージ化していくことを考えている。
また、プライバシの問題は難しい問題を抱えているが、定常的な運用時に関するデータ保持の期間を限定することや、定常運用時の必須項目としての登録内容を再検討すること
によって対応可能だと考えている。

3.2

定常運用へ

第 3 回の訓練終了後も訓練で動いていたシステムをデータベースなどは新しく作成して
1 月 31 日までの間動作させていた。
これには、訓練期間中にアクセスできなかった方々のためという意味もあったが、定常運用するための課題を抽出するという意味もあった。

44

第 1部

ライフラインとしてのインターネット に関する考察

45

そして、定常運用することによって、「普段から動いているシステム」になり、我々が現状では想定できていない課題も新たに見出す事ができると考えている。IAA システムは、
1998 年 5 月から定常運用を開始している。

第4章

他組織との協力体制について
今年度のインターネット災害訓練は、公開実験を中心に 3 つの団体の協力とそれに関連する多くの組織の協力により実施された。ここでは、各団体の役割について述べるとともに、ライフラインワーキンググループとして、今後の他組織との協力体制の取り方につい
て述べる。

4.1

公開実験に関連した協力組織

第 3 回インターネット災害訓練では、昨年度に引続いて屋外での公開実験を行った。昨年度は、WIDE の共同研究組織の協力を中心として公開実験を行ったが、今年度は以下に挙げる 3 つの他の団体の協力により実施された。

4.1.1

被災者支援広域情報ネット ワーク推進協議会「被災者支援広域情報ネットワーク推進協議会」は災害時における被災者の安否情報や生活情報等の提供を行う情報ネットワーク構築実現に寄与することを目的とした任意団体
で、本目的に賛同する防災機関並びに非営利団体で委員が構成されている。今年度は、この協議会と 2 度の協力体制で実験を行なった。

まず、1997 年 9 月 1 日に協議会が中心となって、「被災者支援広域情報通信実験」が行われた。この実験では、Lotus Domino Server を用いて構築された実験システムをサーバとし 、衛星回線や電話回線などを用いて 2 箇所の想定被災地 (東京都立川市合同総合訓練
会場と千代田区総合防災訓練会場が使われた ) から生存者情報や被災地の画像情報などの登録・検索が行われた。WIDE からは、音声応答による電話での情報入力システムによる実験と電子メールからポケベルへの情報転送システムを用いた想定被災地への情報伝達の実験への参加による協力を行った。
また、第 3 回インターネット災害訓練は、逆に WIDE が中心となった実験であり、(あいにくの天候不順により中止となったが ) 秋葉原駅前広場での公開実験に関連した協力を協議会から受けていた。具体的には、公開実験会場の借用許可や秋葉原商店街への実験協
力要請、臨時電話回線や電源の手配、IAA 情報入力・検索用の携帯端末機器の手配、公開

46

第 1部

ライフラインとしてのインターネット に関する考察

47

実験会場での実験説明やアンケート回収などに要する人員手配などである。

4.1.2

新潟インターネット 研究会「新潟インターネット研究会」は、インターネット利用技術の個人レベルでのスキルアップを目的とするユーザ会で、エンド ユーザとしてネットワークをど うすれば良いかといった情報交換の場の提供などを行っている。今回の災害訓練では、NTT 新潟支店プラザ 1 階の公開実験会場から IAA 情報の登録・検索の実験が行われた。
新潟の公開実験会場では、Web/Windows クライアント /FAX/電話のそれぞれのユーザ
インタフェースの実験について説明をしてもらうとともに、アンケートの回収ならびに集約の協力を得ることができた。また、公開実験と事前の内部公開実験に際して、実験シス
テムの問題点の指摘などにも協力を得ることができた。

4.1.3

インタービジネスネット ワーク (ibn)「 インターネットビジネスネットワーク」は、ネットワークやディジタル技術により復興支援を行おうという NPO グループの任意団体。今回の災害訓練では、神戸ハーバーラ
ンド キャナルガーデン「せいでん」前の公開実験会場から IAA 情報の登録・検索の実験が行われた。
神戸の公開実験会場では、Web/Windows クライアントでの情報登録・検索の実験について、一般参加者への説明と実験参加呼びかけの協力を得ることができた。

4.2

今後の他組織との協力体制について

上述した他組織との共催による公開実験会場に伴い、複数の実現方式・母体による IAA
システムの存在に関する協力体制や、NGO のボランティア組織や災害訓練に協力を申し出てくれる他の団体との協力体制について、今後どのように進めるべきかという議論がワー
キンググループ内で進められた。ここでは、それぞれに分けてまとめている。

4.2.1

各種の IAA 関連システムとの関係

9 月 1 日の実験で被災者支援広域情報ネットワーク推進協議会が用いた IAA システムは、
Lotus Domino Server 上に構築されたシステムであった。そこでは、広域避難所などに集まった被災者の安否情報を登録・検索するシステムの他に、行政職員・避難所に関する情報や避難所の画像情報や物資要求配送に関する情報、被災地での生活関連情報などもデー
タベース管理することができるシステムとなっており、主に自治体向けでの利用を前提として開発されたものを、インターネット上からも Web 経由でアクセスできるように機能拡張されたものである。

1997 年度 WIDE 報告書

48

また、「東京 23 区ホームページの防災コーナー」1 では、震災時に機能させる災害情報のページを用意し 、生存者情報の登録や検索を Web 経由で行なうことができる仕組みを構築している。
「東京大災害対策 Web 」2 でも震災時に機能させる災害情報のページを用意しているが、こちらは 23 区の災害状況に関する情報を連絡し合う掲示版の役割を果たそうとしている。
このように、複数の実現方式による IAA 関連のシステムが各地で機能し始めた場合、利用者同士がどのシステムを使うかを事前に打ち合せておかないと、うまく情報伝達の機能を果たさないことが予想される。これを回避するために、各システム間で協調して登録されたデータの交換を行なう方法も考えられるが、各システムで利用できる登録・検索のキー
ワードや範囲が異なる場合の対策など 、解決すべき問題点は多い。
そこで、これらの問題点を整理して、IAA システムの実装を行なっている者同士の共通の認識を持つことができる機能の提供が必要になると考えている。

4.2.2

NGO などの関連団体との関係

今回の訓練では、公開実験の協力を他の組織と行ったが、この他にも阪神淡路大震災以降、世界各地で起こっている震災に関連する情報の収集と提供の活動を行なっている WNN(World NGO Network) や NVNAD (日本災害救援ボランティアネットワーク) 、インターC ネット (Inter-Community Network) など 、多くの NGO 団体がインターネットを利用した各種の活動を行っている。
IAA システムについては、災害時に有効に機能するためのシステム設計と改良を災害訓練毎に繰り返してきたが、これらの団体と協力体制を確立することで、より多くの利用者
からの feed back が期待できるとともに、実際の災害時にも情報ボランティアが操作方法に慣れておくこともできる。このため、今後、これらの関連団体とも相互に協力体制を確立することを活動の視野に入れることを考えている。

1 http://www.nihon.net/tokyo23/bousai/bousai.html

2 http://www.famousdoor.co.jp/seiko/cen/

第5章

今後の活動方針
ライフライン分科会の今後の活動内容とその活動予定スケジュールを示す。

5.1

活動内容

引続き以下の内容を目標として分科会としての研究活動を続けていく。

 災害時にインターネットをど う活用すべきか/できるかの検討
 災害時のインターネット利用の指針となるカラーブックの作成
 インターネット上の頑健なアプリケーションの検討
これ以外にも、第 3 章で述べたように定常運用を行っていくので、その運用の中で我々が想定していなかった課題の抽出、およびその解決策を検討する。さらに、分散システム
を分散環境で開発・運用することに対する課題 [26] についても解決をはかっていく。また、災害時に備えてインターネット上でのコミュニティにのあり方ついても検討して提案していきたいと考えている。

5.2

スケジュール

以下のようなスケジュールで来年度 (1998 年度) の活動をすすめていく。

 98/05: IAA 定常運用開始

DSM 研究会/WIDE 研究会・オフラインミーティング 98/07: WIDE 研究会
 98/09: 防災の日対応・WIDE 研究会 (合宿)
 98/11: WIDE 研究会
49

50

1997 年度 WIDE 報告書

 98/12: WIDE 研究会
 99/01: インターネット災害訓練の実施 (未定) 99/03: インターネット災害訓練の報告 (未定)