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

29

第 1章はじめに
1995 年 1 月に起きた阪神淡路大震災は、情報ネットワークに関して、その重要性を再認識させるとともに、多くの課題を我々に示した。情報は特に大都市において、電気、水道、ガスなどのいわゆるライフラインに準じた重要な役割を担いつつあることを明らかにした。
また、電話中心の情報伝達手段やマスコミといった従来の情報ネットワークに対して多くの問題を提起したが、一方で、インターネットに代表されるコンピュータネットワークの可能性と重要性を示した。
災害時および復旧時に発生する大量の情報を集め、適切に処理し 、必要な人に配布することは、コンピュータネットワークのサポートなしには不可能な状況になっている。しかし 、必要な機能を災害時にも提供するためには、現在のコンピュータネットワークの状況
は多くの課題を抱えており、このギャップを埋める努力が急務になっている。
ライフラインタスクフォースでは、社会情報基盤としてのインターネットを技術的、運用的側面から見直し 、社会基盤としての可能性とそれを実現するための課題を整理し検討している。また、災害時におけるインターネットの役割についての検討を進め、インター
ネット上での災害訓練を実施することで、インターネットコミュニティへの問題意識の喚起、実用的なシステムの研究・開発を進めている。
1995 年度は、特に次の点を中心に活動した。

 災害時の情報システムを生存者データベース (IAA) を例にあげてその機能要件の検討／試作

 バックボーンの障害時の衛星によるバックアップの問題とそのための技術上・運用上の課題の整理と、具体的なバックアップ手順の確立

 頑強なメールシステム (ロバストなメールシステム)
これらの成果を用いて 1996 年 1 月 17 日の第 1 回インターネット災害訓練を行なった。
今年度の報告書ではこれらを中心に報告する。
本報告では、２章でインターネット防災訓練の内容を述べ、３章ではインターネット防災訓練では扱えなかったがこのライフラインタスクフォースが扱っていくトピックについて中心に述べることとする。

31

第 2章
第 1 回インターネット 防災訓練について

2.1

防災訓練の狙い1996 年 1 月におこった阪神・淡路大震災のような都市型の大規模災害においては、安否情報や被災者の衣食住に関する生活情報の伝達が重要である。テレビやラジオ、新聞といった従来のマスコミは、このような個人的な生活情報を伝達する手段として必ずしも有効に機能しない。また、災害情報や生活情報は大量であり、刻一刻と変化する。震災時に行なわれたインターネットやパソコン通信を中心とする情報伝達は、十分とは言えないものの、
このような情報を伝達する手段としてコンピュータネットワークが有効であることを示唆した。さらに、インターネットの広域性、同報性、蓄積性は、国内および海外に対して、状況を効率よく的確に伝える手段として注目された。
一方、日常生活の中で利用していないシステムは、災害時のような寸秒を争う事態となった場合に使い物にならない。災害時に被災者の生存に関わる情報伝達をサービスしようとする情報伝達サービスや、そのメディアとしての価値を担うべきコンピュータネットワー
ク自体も同様のことがいえる。しかも、被災者が広く一般に利用可能であるためには、コンピュータネットワークへのアクセスを容易にする環境が被災地において遍在し、また、その操作が簡単である必要がある。こういった情報アクセスや情報発信方法は、災害時だけに存在する／利用するような方法であってはならない。つまり、日常から利用しているものであって、平常時と同じ操作や同じ知識で災害時にも利用できるように設計されている必要がある。
そのために、インターネットをライフラインとして位置づけることを可能とするさまざ
まな要素技術やアプリケーションの実用性を検証するために十分な広域性と一般性を持つ
実験運用基盤が必要不可欠である。そこでその実験運用基盤にあたるものとしてインターネット防災訓練が 1996 年の 1 月 17 日および 1 月 18 日に国内コンピュータネットワーク
利用者を対象に実施された。図 2.1に WWW で公開された第 1 回インターネット防災訓練のホームページを示す。第 1 回目にあたるこのインターネット上の防災訓練では、生存者
情報データベースシステムの利用訓練 (IAA 訓練) 、ならびに地上の幹線経路が損壊した
際の通信衛星による幹線迂回経路への切替訓練 (WISHBONE 訓練) の２つの訓練メニューが準備された。そこで IAA 訓練と WISHBONE 訓練について報告する。

32

第 2部

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

図 2.1: 第 1 回インターネット防災訓練のホームページ

33

1995 年度 WIDE 報告書

34

2.2 IAA 訓練

2.2.1 IAA データベースシステムの意義
災害時にインターネットを利用して生存者情報を登録、検索できるようにすることを目的として、生存者から発信された生存者情報を管理するデータベースを、IAA データベー
ス (生存者情報データベース) と呼ぶ。IAA とは I Am Alive (私は生きている) の略称である。
阪神・淡路大震災では、被災地に居住する親類や知人の安否を確認する電話が殺到して公衆電話網がマヒしてしまった。その結果、被災地内の緊急連絡や被災地外への状況報告などに公衆電話網が利用できないという事態を招いた。一方、コンピュータネットワークは電話やファクシミリと異なり、同報性と蓄積性という特徴を兼ね備えている。被災地域の内部に本質的に存在する情報を、コンピュータネットワークを利用して外部へ効果的に逃してやることにより、被災地の外側から内部へと発生する大量の情報アクセスを被災地から逸すことができる。この結果、被災地内部の通信資源を本来の主たる利用者であるべき
被災者に対して開放することにつながる。そこで被災地域内の生存者情報を被災地域外において蓄積し 、生存者情報の大量の問い合わせに対して効果的に応答するシステムが IAA
データベースシステムである。

2.2.2 IAA データベースシステムの設計方針
IAA データベースシステムの設計方針を述べる。
1. 生存者情報の検索
被災者のおかれた生存状況を生存者情報という情報単位として扱い、データベース化
し 、ネットワークを通じて検索サービスを提供する。

2. 頑健なサービスの提供
常に IAA データベースをサービスし続けるというシステム特性をもつ。
3. 被災地発の生存者情報の自動処理
さまざまな条件下で入力、発信される可能性をもつ生存者情報を自動処理できるように入力情報の正規化や情報の補完等をおこなう。

4. プライバシ保護に対する配慮
生存者情報に含まれるプライバシを保全するべく適切な対策を講じる。

2.2.3 システムアーキテクチャ
IAA データベースシステムを支える IAA システムアーキテクチャは次のようにシステ
ムを構成する５つの機能系と１つの分散機構から特徴づけられる。なお、IAA データベー第 2部

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

35

スのサービスを独立して提供可能な機能単位 (ネットワークに接続された計算機システム)
を IAA クラスタ (IAA cluster) とよぶ。また被災者から IAA データベースシステムへ寄せられた生存者情報をシステムの自動処理に適した形へ変換したものを IAA 情報と定義する。

3q lH

óèq

4¯
4¯!!Á
ÏÁ óèÁ
*ÁË«ÌëÕÍ'_Í
V»í»FÂi

IAA cluster
IAA cluster

7
8Ï

IAA cluster
IAA cluster

)A0=B?>AC

図 2.2: IAA システムアーキテクチャ 入力系

電子メールや WWW といった複数の入力ストリームから送信されてきた生存者情報の登録要求または検索要求を受け付ける処理系。被災者から発信された情報はまず入力解析器で標準形に整形されたのちに正規化処理される。例えば今回のプロトタイプ
システムで整形対象となったのは主として文字コードの扱いと冗長な記述の削除、タ
イムゾーンの統一などである。またこの系では生存者情報を記述する言語の意味解析を行ない、同じ意味を表す表現の統一を試みる。IAA 情報というシステムに適した情報単位へ整形・正規化された生存者情報は、登録要求なら配送系へ渡され、検索要
求なら検索系へ渡される。

 配送系

ある IAA クラスタの入力系から他の IAA クラスタの蓄積系に対して生存者情報を配送する処理系。複数の IAA クラスタから構成される IAA データベースシステムが全体として一貫した動作をするには、各クラスタが参照するデータを一致させる必1995 年度 WIDE 報告書

36要がある。IAA 情報はプライバシに関わる情報を含むことが多いため、WAN を通じてクラスタ間でやりとりされるデータは暗号化される。この WAN 上に張り巡らされた IAA クラスタ間を結ぶ IAA 情報の転送ネットワークを IAA Transport と名付ける。また IAA クラスタ間で正確にデータの同期を取らなければならないため、配送データの再送機構や大量のデータ転送能力および一時的なデータ蓄積能力を持つ。

 蓄積系

IAA 情報を効率良く蓄積する処理系。IAA 情報から検索用のインデックス情報を作成してデータベース化する。データベース処理に対して大量レコード 処理、高速検索処理を要求される他、損壊したデータベースの自動修正機能などが望まれる。また蓄積可能なデータ数や検索処理能力に対して、さまざまな災害規模に対応できるように
スケーラブルな設計が必須となる。

 検索系
実装された適切な検索ポリシのもと、検索者が入力した検索条件から蓄積系で提供されるデータベースに依存した検索命令を生成する処理系。検索パターンが生成されると IAA クラスタ内のデータベースに接続して検索を開始する。検索結果が得られると返答文を生成して検索者へ返答する。適用される検索ポリシとしては、例えばプライバシ保護に関わるもの、検索負荷を軽減するもの、情報のフィルタリングに関するものなどがあると思われる。

 出力系

電子メールや WWW といった複数の出力ストリームを通じて生存者情報の検索結果
を検索者に対して返送する処理系。返送時に選択される出力ストリームは、検索要求者が利用可能な通信メディアへ最終的に結合している。また検索者に対して複数の冗長な返送経路が選択可能な場合、要求に応じて冗長な返送方式をサービスする。

 危険ならびに負荷に対する分散機構
入力系、配送系、蓄積系、検索系、出力系の５つの処理系から構成される災害に対する地理的危険分散ならびに組織的危険分散を目的として広域に分散配置された IAA
クラスタ群を広域分散システムとして結合する分散機構。インターネット全域から生成されるアクセス負荷を各 IAA クラスタに対して均一に分散したり、IAA クラスタをシステムへ柔軟に追加できるように働く。

2.3 IAA データベースシステムの実装と防災訓練の実施
第 1 回インターネット防災訓練という枠組みの中で IAA 訓練が 1996 年 1 月 17 日午前 5時 45 分をもってスタートした。この IAA 訓練のシナリオとして、訓練参加者全員が被災者であるという前提のもとに IAA データベースシステムを用いた登録訓練ならびに検索

第 2部

37

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

訓練が計画された。このため 1 月 17 日までに WIDE Project ライフラインタスクフォー
スによって IAA データベースシステムのプロトタイプが 準備された。図 2.3にそのプロト
タイプシステムの全体像を示すとともにシステム実装時に検討された実装方針について触れる。

2.3.1 システムの全体像
SPARCstation 2

JAIST
Kyoto

ÊVÂÜV¼·

4¯!·
SFC
NAIST

 lH

IAA Cluster

JAIST

Kyoto

IAA
cluster

IAA
cluster lH

IAA Transport
IAA
cluster

IAA
cluster

NAIST

SFC

RR rotation when querying to DNS

ÂäVî

,,,

Ç}ü&q
図 2.3: IAA データベースシステム
図 2.3にあるように IAA 訓練では地理的に離れた 4 箇所へ IAA クラスタを分散配置した。この IAA クラスタの運用サイトを選ぶ時に、同時に実施された WISHBONE 訓練 の
内容1も考慮した。その結果、両訓練に深く関与している 4 つの WIDE NOC から選ぶこととなった。

 北陸先端科学技術大学院大学 (JAIST)
1 京都を被災地と仮定し 、WIDE 京都 NOC へ接続する WIDE Internet の全ての地上回線を故意に切断後、通信衛星を利用して WIDE Internet のバックボーンを修復しようという訓練内容。

1995 年度 WIDE 報告書38

 奈良先端科学技術大学院大学 (NAIST) 慶應義塾大学湘南藤沢キャンパス (SFC) WIDE 京都 NOC (Kyoto)
訓練参加者からこれら 4 つの IAA クラスタへのアクセスは、DNS のラウンド ロビン機能によって自動的に各 IAA クラスタへ振り分けられるため、情報の入力・検索要求時にシステム全体のクラスタ構成を意識する必要はない。クラスタ追加を容易にすることで IAA
データベースシステムにとってスケーラブルな設計を可能とすると同時に、IAA クラスタ
へのアクセス負荷分散が実現されることを目指した。

DNS のラウンド ロビン機能を通じて接続される IAA クラスタでは、個々に独立して生存者情報の入力を受け付けた。またあるクラスタから生成された IAA 情報は他の全てのクラスタに向けて速やかに同期転送された。一方、全ての IAA クラスタ間で同一の情報を共有していることから、検索処理もクラスタ単位で独立してサービスを提供した。こうして
IAA クラスタが災害時に 1 つでも生き残っていさえすれば 、ネットワークを介して生存者情報を蓄積、検索することが可能となる。
今回の訓練では、訓練参加者が IAA データベースシステムを通じて生存者情報をやりとりするための入出力インターフェースとして、電子メールと WWW を採用した。その理由は両者のサービスが現在のコンピュータネットワークにおいてもっとも普及しているからである。とくに電子メールによるシステムの利用手段は今回の訓練システムでは重視された。たとえば直接インターネットに接続できない利用者がパソコン通信などを利用して訓練システムに参加できるようになることを考えた。
生存者情報の登録・検索要求の入力が電子メールおよび WWW であった一方で、検索結果は一様に電子メールによって検索者に結果が通知された。訓練時に利用された主な電子メールアドレスと WWW アドレスを表 2.1に紹介する。このアドレス以外にも送信時にアドレスタイプミスが起こることを想定していくつかのアドレスパターンを受け付けるよ
うに工夫した。この背景には、災害などの緊急時は利用可能な通信資源が制限されることから一旦発信された情報は可能な限りシステムに受けつけようという配慮がある。
表 2.1: 登録または検索用アドレス
種別
登録用アドレス
検索用アドレス

World Wide Web
touroku@iaa.wide.ad.jp http://www.iaa.wide.ad.jp/touroku.html
kensaku@iaa.wide.ad.jp http://www.iaa.wide.ad.jp/kensaku.html
電子メール

第 2部

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

39

2.3.2 IAA 情報
IAA システムで扱われる生存者情報すなわち IAA 情報は、情報提供者側で生成される
入力必須項目と入力任意項目および IAA クラスタで生成されるシステム付加項目から構成された。表 2.2に全ての必須項目を示し 、他の項目に関しては一部抜粋して示す。
表 2.2: IAA 情報の内容
情報提供者側で生成される入力必須項目
本名
生存者の主たる索引キー情報
状況
生存者の生存状況に関する情報
確認手段
情報源の信頼性の尺度[1]
情報提供者
情報源の信頼性の尺度[2]
情報提供者側で生成される入力任意項目
通称
生存者の二次的な索引キー情報
年齢、性別、生存者の検索時にヒットする情
住所、…
報を絞り込むフィルタで利用
ご意見欄

訓練やシステムへの意見、提案等

IAA クラスタで生成されるシステム付加項目
IAA ID
IAA 情報の一意性の保証
発信ホスト名IAA 情報の発信位置の記録
インターフェース種別 IAA 情報の入力インターフェースタイプ
必須項目が提供されない IAA 情報の登録要求は、生存者情報として必要最低限と考えられる品質を満たしていないとみなして IAA クラスタで登録拒否することとなった。この処理を通じて生存者情報データベースへ蓄積される IAA 情報はデータベースの目的に合致するレコードを持つ登録情報となる。まず生存者情報として必須であると思われたのは、「本名」と「状況」というデータ項目である。しかしながら生存者情報は必ずしも本人から寄せられるものとは限らない。生存者情報という情報の本質に対する議論の結果、今回訓練用として準備したシステムがデータの信頼性を保証することができない以上、検索結果として提供された IAA 情報を検索者側で正確かど うか、またはどの程度信頼できそう
かど うかを検索者が判断できるようにするべきであると考えられた。そこで必須項目として追加されたのが「確認手段」と「情報提供者」である。情報源と確認の手段を明示する
ことにより検索者側の判断の一助とした。
また IAA データベースの実用性を高めるために、上記以外に入力任意項目が用意された。例えば「通称」などは本名を正確に知らない人からもニックネームで検索できるようにと４つのパターンまで入力を許した。

40

1995 年度 WIDE 報告書

IAA 情報の入力項目全てに対して公開、非公開の是非の検討もおこなわれた。IAA 情報
は個人情報の集合体である。そのような情報を無制限に解放することは非常に危険となる。
特に問題となるのは広範囲で無差別な検索である。そこで IAA 情報のプライバシにあたる部分を検索時に効果的に隠蔽する工夫をおこなった。また、ある一個人を特定するような検索パターン以外はシステムとして取り扱わない方針を採用した。
IAA データベースシステムにおいて自動的に生成された IAA システム付加情報は、IAA
情報の流れをトレースしたり、IAA システム全体のスループットや振舞いを導出するために利用された。また IAA クラスタ間を同期転送される IAA 情報の重複を許さないために、一意の IAA ID を添付した。

IAA 情報の任意項目に属する「ご意見欄」は訓練開始間際となって追加された入力項目である。ここには訓練参加者からの意見や感想、システムへの提案、要求などの自由な記述を許した。この入力項目を通じて、システム設計・運用者と訓練参加者（システム利用者）間の意識の溝を埋め、より利用者主体の実用的なシステムへ近づけることを意図した。

2.3.3 IAA クラスタ
広域にまたがる 4 サイトへ分散配置された IAA クラスタは 1 クラスタあたり 2 台の計算機 (SPARCstation2) から構成された。1 台は IAA システムアーキテクチャにおける入力系、出力系と検索系の機能を提供する入出力処理用計算機として機能実装された。残る
1 台は配送系と蓄積系の機能を提供するデータベース処理用計算機として実装された。
入出力処理用計算機では Perl script で実装された入力整形器を用いて電子メール、WWWの 2 つの入力インターフェースから着信した情報をある一定の変換ルールのもと記述形式
を自動整形した。整形処理の例として、大文字を小文字へ変換したり、全角文字を半角へ統一する処理が考えられた。同様に Perl script で実装された入力正規化器を用いて、発信された情報の中に存在する表現のゆらぎを吸収する。同じ意味を表す単語でも自然言語では複数の表現方法がある。入力正規化器では同一意味は同一表現へと置換を試みることで蓄積系の検索効率をあげることを目指した。さらに電子メール、WWW それぞれのフォー
マットから IAA 情報を抽出し 、同計算機上で生成されたシステム付加情報を自動的に添付した。
危機的状況下におかれた人間が発信する情報には入力時の誤りや勘違い、情報の欠落等が存在することが予想される。そこで機械処理が不可能な記述内容に関しては、人間が不完全な情報の補足作業や記述誤り訂正を臨機応変に対応することを考えた。この作業者をIAA オペレータと呼ぶ。IAA オペレータは入力整形器および入力正規化器の両者で自動処理できなかった情報を電子メールとして受けとり、各自で修正後再び電子メールによりシステムへ転送、再入力を試みた。
データベース処理用計算機では広域に分散配置された IAA クラスタ間で IAA 情報の同期配送を受け持つ。同期配送をおこなうために今回の訓練システムでは NetNews のihave/sendme 機能を利用した。入出力処理用計算機で生成された IAA 情報は、データベー第 2部

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

41

ス処理用計算機で動作中の NetNews システム (INN) の記事形式へ即時に変換された。また、WAN 上を流れる IAA 情報の暗号化のため、IAA 情報は記事形式への変換時に同時に DES 方式で暗号化された。
記事形式となった IAA 情報は、NetNews の ihave/sendme 機能により他の IAA クラス
タへ数分程度の遅延時間をもって同期配送された。クラスタへ着信後、復号処理を介してクラスタ内のデータベースへ登録された。
データベースでは配送されてきた IAA 情報から検索用のインデックス情報を取り出してデータベース化する。各 IAA クラスタのデータベースシステムは同一である必要はなく、今回のシステムでは全 IAA クラスタを通じて合計 3 種類の異なるデータベースシステムの提供を試みた。一つは NDBM ライブラリを利用した独自のデータベースシステムであり、もう一つは Oracle7 を利用した商用データベースシステムであり、残る一つは、WAIS
検索を利用したデータベースシステムであった。このようにクラスタによっては異なることが可能であるようにデータベースシステムを採用することにより、n-version プログラミ
ング手法に基づく開発を試みた。仮にあるデータベースシステムが仕様上の問題で利用不可となっても、残るデータベースシステムが最終的に機能することでシステムの目的を完遂することが可能となるためである。また、このように複数データベースシステムを組み込むため、データベースシステムに対する API を設計、利用した。
またデータベースのトランザクション処理の負荷を軽減するため、データベース用計算機では非同期処理に基づくプロセス処理をおこなった。

2.3.4 訓練当時の登録画面と検索結果の例
WWW を利用した登録時の画面サンプル (図 2.4) と電子メールで受け取った検索結果
例 (図 2.5) をそれぞれ示す。図 2.5では、28 才以上 32 才の男性で地域が 630-01 地区にあたる住所で生存者情報を登録している「ありばば 」さんを検索しているが、その結果 IAA
データベースシステムより検索者の baba さんへ電子メールで回答が返送されてきたことを示している。例では SFC に設置された IAA クラスタが応答していることを接続サーバ
名から読み取れる。

2.4

第 1 回インターネット 防災訓練から得られた経験と考察

ここでは 2 日間にわたって実施された IAA 訓練から得られた経験にもとづいて、考察を交えながら評価を試みる。

2.4.1 IAA 訓練アナウンスと参加人数
IAA 訓練では IAA データベースシステムを実際に利用して生存者情報の登録訓練と検索訓練をおこなった。国内のネットワーク管理者各位へは 1ヶ月以上前に同訓練のアナウ

421995 年度 WIDE 報告書

図 2.4: WWW を利用した登録時の画面サンプル

第 2部

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

43

To: baba@is.aist-nara.ac.jp
From: help@iaa.wide.ad.jp
Subject: [IAA]RESULTIAA データベース検索結果 データ 1 件
接続サーバは iaa-sfc-db.iaa.wide.ad.jp です。
===検索キー===【名前】ありばば【性別】M【年令】28-32【郵便番号】630-01============------

ばば ともみつ
馬場 始三 (30 歳の男性) 状況:起きていた。
【通称】 ありばば , ばに , ばばちゃん【住所】 〒 630-01 奈良県生駒市高山町【確認】 [1996/01/17 05:55] 本人【所属】 奈良先端科学技術大学院大学【備考】 大学の中にいます。
この内容は <奈良先端科学技術大学院大学>から<96 年 1 月 17 日 5 時 58 分 38 秒>に <本人>によって発信されました。

-----以上です。御協力ありがとうございました。

図 2.5: 生存者情報の検索結果の例
ンスがされたのに比べて、一般の参加者への呼びかけはシステム開発スケジュールの都合
により、訓練日の一週間前と遅くなった。このように一般へのアナウンスは遅かったにもかかわらず、IAA 訓練がおこなわれた 2 日間を通しての参加者は集計すると約 6,000 人にのぼった。

IAA データベースシステムへの登録推移を図 2.6に示す。

2.4.2 システム負荷と IAA クラスタ資源の十分性
今回訓練用に準備された IAA クラスタ資源が十分であったかど うかを検討する。

1995 年度 WIDE 報告書

44
↑登録件数

300
250
200

150
100
50
0
6

12

18

0

6

12

0

18

時刻→

図 2.6: IAA データベースシステムへの登録推移

1. 入出力処理用計算機

入出力処理用計算機は高い CPU 負荷に長時間されされた。これは入力整形器と入力正規化器の実装が悪く、何度も生存者情報の解析中にプログラムが暴走したためである。暴走の理由は主に２点あり、一つは開発期間が短かったためという点。もう一つは予め準備された電子メールの入力フォーマットが参加者一般にとってわかりにくい
ために、開発者が予期せぬ入力パターンにさらされたプログラムが正しく働かなかったためである。入出力処理用計算機の CPU 高負荷は WWW の入力受付処理にも深い影響を与え、http セッションを張れないケースが何度もあったようである。

2. データベース処理用計算機
約 6,000 件のデータベース処理と 4 台間の同期配送処理は十分こなせた。

2.4.3 DNS による広域アクセス負荷分散と広域サーバ資源選択
4 つの IAA クラスタへのアクセス負荷分散は次の仕組みで対応した。
1. 複数 A レコード のラウンド ロビン型ローテーション提供
2. 複数 MX レコード の同一プリファレンス値設定
ここで図 2.7をみてもらえばわかる通り、IAA クラスタへの登録負荷分散は計画通りの成果をおさめた。しかし一部の訓練参加者からの報告によると、WWW サーバの反応や処理が遅いため WWW サーバへの登録接続や検索接続を諦めたことが何度もあった。この理由として、前節のシステム負荷によるサーバ処理の遅さがあげられる他に、たまたまサー
ビス提供先として DNS から指示されたサーバへのネットワーク的に遠いためだったとも第 2部

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

Kyoto
32%

SFC
22%

45

JAIST
26%

NAIST
20%

図 2.7: IAA クラスタごとの登録受付数の比較考えられる。事実、IAA クラスタのうち SFC からサービスを受ける場合は、WNOC-東京と WNOC-SFC 間の通信トラヒックの混雑からサービス品質が大きく低下した。

DNS によるサーバ資源のラウンドロビン選択方式は、ローテーション提供される各サー
バ資源がサービス対象とするクライアントから見て全て等価の場合には適切な方式である。
例えば LAN の中の同一サブネット内に設置されたサーバ複数台と LAN 内のクライアント群のような関係に合う。一方、広域におけるサーバ資源の選択方式としてはアクセス負荷分散は実現する代わりにクライアントとサーバ間の通信品質は保証されない。広域における頑健で品質の高いサーバ選択システムが必要と思われる。

2.4.4 訓練参加者の反応
図 2.8に訓練参加者から IAA 登録訓練時によせられた意見分析図を示す。
総件数 4119 件中、ご意見欄にてコメントが寄せられた有効コメント率は登録された IAA
情報の全体の 43% にあたる 1791 件であった。これをみると、今回準備された IAA デー
タベースシステムへの要望、ユーザインターフェースへの意見、トラブル報告が合わせて719 件となっており、有効コメント数の約 40% を占めた。このことから、IAA データベー
スシステムの完成度が訓練参加者にとりあまり満足のいかなかったものと読みとることができる。一方で、IAA 情報の登録をおこなった約半数近くからこのようにコメントをいただけただけではなく、提案、はげましなどこのシステムの設計や存在を支持する意見を得られたことは、我々にとって今回貴重な経験となった。

1995 年度 WIDE 報告書

46

µN

ËìÙîH`yfÑ´à¹òðâï æëñâïãÞàâ

gí
y
®
­

®­­

¯­­

°­­

±­­

¢Ð¿y»õ²­­³­­

図 2.8: 訓練参加者からの意見分析

2.4.5 システムの目標達成度
IAA データベースシステムの設計目標について今回のプロトタイプがどの程度満足できるものであったかを検討する。

1. 生存者情報データベースの提供
n-version プログラミングの手法を用いて開発段階では 3 種類のデータベースの開発
を平行しておこなった。3 種類とは 1) WAIS 検索を組み合わせたもの 2) ndbm ライ
ブラリを利用したもの 3) Oracle データベースである。このうち WAIS ベースの実装は性能問題から途中で開発を断念したものの、ndbm を利用したデータベースは訓練開始から終了時まで十分に役目を果たした。Oracle データベースは訓練開始時には間に合わなかったが訓練期間の最後の段階でシステムへ組み込むことができた。したがって数千件オーダの訓練参加者に対しては十分な生存者情報データベースを提供
できたといえる。
一方で訓練参加者のオーダが訓練が実施されるまで予想できなかったことを考えると、数千件オーダに耐える ndbm 版と数十万、数百万オーダに耐える oracle 版が同時に平行開発された n-version プログラミングのアプローチは今回成功したものの一つと考えてよいと思われる。

2. システムの頑健度

訓練期間中、何度か IAA クラスタが一部停止したもののシステム全体としてはデー
タベースを提供し続けることができ、システムの頑健度として必要最低限度の頑健さ

第 2部

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

47をもっていたといえる。一方で IAA クラスタのうち、入出力処理用計算機ではプロ
グラムの暴走により CPU 資源が高負荷にさらされ、結果として入力系の処理に大きな遅延が生じた。プログラムの欠陥は別として、残念ながら今回の IAA クラスタの計算機処理能力では不十分であった。

3. 生存者情報の自動処理
大半の生存者情報は自動処理できたものの、電子メールによる予期せぬ入力パターンに対して、入力系の自動処理プログラムが迅速に対応できなかった。対応できないものに関しては IAA オペレータが対応しようと努力したものの、待機するオペレータ数の絶対的不足や IAA クラスタの計算機能力不足のため、リクエストがピーク時の自動処理はあまりうまくいかなかった。被災情報の類いは通信線の回復とともにバースト的な送信を引き起こす可能性が高いことを考慮すると、自動処理機構に関してさらなる工夫が必要だと思われる。

4. プライバシの保護

生存者情報を広域ネットワークを通じて転送する配送系では DES 暗号化によるプラ
イバシの保護が問題なくおこなわれたとみてよい。一方、検索系においては、個人名を検索キーへ必ず入力させる方法をとることで無制限の検索機能を提供しなかった
り、住所を始めとする情報をある程度隠蔽するような工夫を導入した。しかしながら、1) 使い勝手とのバランス 2) 生存者と検索者の関係にもとづく情報検索 (例えば家族、親戚に対しては登録情報をより詳細に公開する) といった点を考慮した時、検索時におけるプライバシの保護に対してはまだ多くの検討課題が残されている。

1995 年度 WIDE 報告書

48

2.5 WISHBONE について災害が発生した場合、その回線が回復するのにかなりの時間がかかって、被災地が孤立してしまうという状況が発生する。さらに悪いことには、安否を気遣って、被災地外から被災地への問い合わせが集中して被災地以外からの問い合わせの洪水によって、被災地内部同士の通信ですらできなくなってしまうことになる。
先にあげた IAA システムは分散データベースによって被災地への問い合わせの集中を軽減する役割を果たすシステムのひとつである。IAA システムとは別に、災害が発生しても安定して通信を続けることのできるネットワークが必要である。
衛星回線は、地上に災害が発生しても比較的そのダ メージを受け難いという特性を持っている。WIDE プロジェクトでは、通信衛星回線とインターネットとの融合を目的として
WISH タスクフォース (以下、WISH-TF と記す) を運営しており、この WISH-TF の行動計画にも「地上網のバックアップ 」という内容があげられている。そして今回、WISH-TFと日本サテライトシステムズ社の協力を得て、インターネット防災訓練の中のひとつの訓練として衛星回線による地上網のバックアップが行われた。
この訓練は、実際に運用状態にあるネットワークのバックボーンを切断して行うことになった。この訓練を WISHBONE と呼ぶ。

2.5.1 被害想定/準備
現在、日本のインターネットは東京を中心に構成されており、WIDE プロジェクトが運営する WIDE インターネットも同様に東京にアクセスが集中している。この東京周辺のネットワークがダウンしたことを想定できればいいのだが、今回の訓練は第一回目ということもあり、東京のリンクを切断して訓練を行うことは規模が大きくなりすぎるため、２番目に規模の大きい京都のリンクを一時的に切断して、衛星回線を利用してバックボーンを回復する訓練を行うことにした。
衛星リンクのための設備はそれぞれのサイトで次のものを用意した。

 直径 1.8 m の VSAT アンテナ
 衛星用モデム 2 Mbyte=s の衛星回線
 WISHBONE ルータ

Sun Sparc Station, HSI S-bus board, Gated (Version 3), SunOS 4.1 (VLSM が扱えるようにカーネルは変更されてたもの )広島 NOC（ 広島市立大学）では、直径 75 cm のポータブル VSAT が事前に用意された。また、インターネット防災訓練を行う前に事前に各サイトではそのリンクテストが行
われた。

第 2部

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

49

2.5.2 実験経過
衛星回線が立ち上がるのにはほとんど時間がかからないが、OSPF のデータベースが同期し 、新しいルータとのコネクションを確立するのには数分かかった。
地上ベースのリンクの場合には 、このように数分の時間を要することはない。これは、OSPF の Database Description Packet が１パケットで送るしかなく、RTT 500 msec という特性をもつ衛星リンクでは、この処理に多くの時間がかかってしまったのである。
午前６時に再び 、WIDE バックボーンは全体のコネクティビテぃを回復したように見えた。しかし 、いくつかの予想されなかった状況があり、その回復のためにさらに約 45 分を要した。結局、午前７時頃にネットワークを回復させることができたのである。

2.5.3 予想されなかったできごと
1. OSPF のエリア分割
被害に遭うリンクに繋がっているルータと、WISHBONE リンクに繋がっているルータとを持つ (バックボーン以外の) エリアは注意深く設計されていなければならない。
これらの二つのルータではバックボーンに対する Virtual Link が設定されている必要がある。さもないと、OSPF のエリア分断が起こり、被害にあうリンクを持っているルータは、WISHBONE ルータからのそのエリアにアナウンスされるべき経路をアナウンスしない。

2. BGP peer address 問題
九州大学のルータも BGP speaker であり、そのシリアルインタフェースに BGP peer
アドレスをもっている。
地上網がダウンした結果、BGP peer はルータへの接続を失い、九州大学内部のいく
つかのサイトや九州大学を経由して繋がっているいくつかのサイトが WIDE プロジェ
クトによって運営されているネットワークを経由して接続することができなくなった。
この結果から、われわれは次の教訓を得た。

BGP の peer address は、もっとも安定して運用されるインタフェースにつけるべきである。たとえば 、イーサネットのインタフェースに BGP の peer アドレスをつける方が、シリアル回線のインタフェースにつけるよりも安全である。おそらく、ルータのソフトウェアループバックインタフェースに BGP の peer アドレスをつけるのが 、最も良いのであろう。
これまで、われわれは、ソフトウェアループバックインタフェースにアドレスを付与することはアドレス空間の無駄遣いだと考えていたが、頑強なネットワークを構築するためには決してダウンしないインタフェースにアドレスを付与することも重要であることを知った。

50

1995 年度 WIDE 報告書
3. テストは何度やってもよい。
訓練が始まって後で、われわれは、VLSM をサポートする gated が動作していない
WISHBONE ルータがあるのを発見した。このことにより、多くのルータが VLSM
化されたネットワークへの経路を失うことになった。そして、WIDE の大部分に経路の配送ができなかった。
先に書いたように、訓練の前に先だってそれぞれリンク上で行ったテストではこのことを見つけ出せなかった。

2.5.4 WISHBONE の今後の計画
今回は、京都がダウンしたことを想定して訓練を行ったが、京都以外の NOC がダウンした場合にどのようにに対応するのかについても、それぞれ訓練しておかなければならない。いざと言う時には間に合わないものになってしまう。実際に被害が起こってからいろ
いろ設定内容をやりとりしているようでは、そのシステムは動かないだろう。
各 NOC の管理者などとの連携をとって定型化した動作が行えるようにしていく必要が
ある。

第 3章
その他のトピック
ここでは、インターネット防災訓練以外にライフラインタスクフォースが取り組んでいる、またはこれから取り組もうとする内容について述べる。

3.1

頑健なメールシステム

インターネット自体は、その管理機構が徹底した分散指向により構成されていること、信頼性を前提としないトランスポートプロトコルを利用していることなどからわかるように、障害に強い通信基盤となりうる。
しかし 、現状では、その上で提供されるサービスやそのサービスを提供するための機構は、必ずしも頑健性を持つとはいえない。そこで、インターネット上で起こりうる障害を考慮した技術を導入することを考える。
本節では、電子メールサービスを提供する電子メールシステムに対して、冗長度の高いシステムを設計を行うことで、頑健な電子メールサービスを実現するための方法を論じる。
必要性を認識し研究を開始してから日が浅いため、ここでは方向性の指摘にとどまる。

3.1.1 電子メール
電子メールサービスはインターネット上で提供される代表的なサービスであり、インター
ネット上のコミュニケーション手段として広く利用されている。電子メールはテキストベー
スの伝達手段であり、利用するために必要な資源 (計算機/ネットワーク) が少ないため、1996 年初頭に行われた IAA 訓練においても主たる入出力手段として利用された。
しかし、現在の電子メールサービスは決して確実なものではない。配送経路のネットワー
ク障害や、配送先のメールボックスの事故などによって、容易に到達性が無くなってしまう。また、障害時の対処に関してはあまり考えられていないのが現状である。たとえ配送先の利用者が、ネットワーク接続性を別の場所から復帰できたとしても、一度あるメール
ボックスに宛てて送られたメールを受け取ることは不可能である。

51

1995 年度 WIDE 報告書

52
頑健性の向上

電子メールシステムとは、ユーザからユーザへメッセージを伝達する機構であるのと同時に、実時間型のメディアではなく、蓄積型のメディアであるという特性をもっている。
頑健な電子メールシステムとは、この 2 点において頑健性を保証できるシステムである。
すなわち、

 電子メールの配送経路を冗長化することによって、配送経路上に発生する障害に強い配送を可能とすることができる。

 配送先の障害時にも、ユーザに電子メールを配送する手段を提供することができる。
(到達性の向上)という機能を提供できるものを指す。
到達性の向上メッセージの伝達手段としての電子メールの役割から考えると、『電子メールが到達した』状態というのは、『ユーザが扱える (読める) 範囲に電子メールが到達したとき』であるべきである。
なんらかの方法を利用して、電子メールを利用者に到達させることができれば 、たとえ本来の配送先に配送されなくても、使命を果たしたことになる。すなわち、到達性の向上
によってシステム全体の頑健性を向上させることができる。
本来の配送先へのネットワーク的接続が無い場合、利用者が持つ他のメールボックスに配送を行うための機構は現在存在しない。それは、配送先に存在する利用者情報を取得する手段が存在しないからである (.forward は役にたたない)。その場合の到達性を向上させるためには

 本来配送する場所以外に配送させる (横取り) 受け取るまで、ネットワーク上のどこかに保存しておく (コピー)ということを考えることができる。
ど ちらにしても、これらの実現にはより堅牢なユーザ認証と暗号化、広域に分散した利用者情報のデータベースが必要であろう。
メールボックスの補完機構
ライフラインとしてのネットワークを考えるとき、そのネットワークがはたして非常時に使うことができるのかと言うことが最大の問題となる。ネットワークの大部分は動いているのに、利用者が使用する部分のみが利用不可能である場合が多いと考えられる。電子第 2部

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

53

メールサービスは場所を指定して配送を行うために、このような場合には到達性が著しく下がってしまう。
その解決策として『代替メールボックス』というものを考えてみる。
『代替メールボックス』とは、利用者へのメール配送が不可能な際に一次的にメールを保持するための機構を指す。ネットワーク全体が復旧しなくても、この機構を提供する部分だけが回復すれば電子メールの到達性を補完することが可能である。
そのための機構をメールシステムに組み込む方法を現在研究中である。更に、メールボッ
クスを現在のように単一ホスト (もしくはサイト内の幾つかのホスト ) のみに置くのではな
く、ネットワーク上に分散して存在するようなメールボックスを実現することで、より高い頑健性を提供できる。IAA 訓練で利用された高度に冗長化されたシステムをこのような用途で役立てることができないかの検討も行っている。

3.1.2 メーリングリスト
電子メールを利用するアプリケーションとしてもっともよく利用されているのは、メー
リングリストである。メーリングリストは電子メールを利用した同報機構である。しかし 、その本質はグループに対する配送を行うという点にある。
現在は、メーリングリストに対して出された電子メールは、メーリングリストサーバに一旦配送され、一定の処理 (シーケンス番号の付加、サブジェクトの正規化、保存) を行ったあと、メンバーに向けて再配送される。このようなメールの流れは、サーバ部分がボト
ルネックとなり、たとえネットワーク自体や、電子メールの配送機構が頑健であったとしても、メーリングリストはその頑健性を享受できない。そのため、メーリングリスト自体に頑健性を付加する必要がある。
なぜ、メーリングリストサービスが現在の様な構成で行われている理由を考えてみると、前述したメーリングリストの本質的特性である『グループ 』という概念が現在の電子メー
ルの配送システムに無いことが挙げられる。
しかし 、電子メールにグループという概念を導入することは非常に困難であると思われる。インターネット上で利用されているプロトコルである IP 上ではグループを扱うためにマルチキャストの概念と専用の機構を導入しなければならなかった。同様に、メーリング
リストを扱うために電子メールの配送システムを拡張する必要がある。
メーリングリストの頑健性を向上させるためには、

1. サーバの数を増やし 、サーバ間を協調させることでシステムとしての冗長性を増す。
2. 電子メールシステムにグループという概念を導入することでその頑健性を利用できる様にする。
ということが考えられる。
いずれにしても、サーバの構成方法から配送系自体の改善まで、様々な課題が存在がするため、今後の研究が必要である。

1995 年度 WIDE 報告書

54

3.2

被災地における情報の入力

災害時に必要な情報は、"被害者の生存情報 、"各地の被害の状況" 、"生活物資の情報"など 、ほとんどが被災地からの情報であるので、被災地においての情報の収集・入力を如何に迅速に正確に行なうかは非常に重要である。
被災地における情報入力手段に必要と考えられる要件としては、つぎのような点があげられる。

 簡単でわかり易い操作で入力が行なえること
災害時に情報入力を必要とする人は、普段、コンピュータに接していない人がほとん
どであり、誰でもが素早く正確に情報入力が行なえるインタフェースを持った入力手段であることが必要である。

 迅速な情報入力が行なえること
広域の災害においては非常に入力しなければならない情報件数が非常に多くなることが予想されるために、迅速に入力が行なえる必要がある。また、あらかじめ、災害時に入力したい情報をあらかじめ用意しておくなどの準備も必要である。

 既存の情報機器の活用ができること混乱した状態において間違いが少なくなるように情報を入力するには、普段から使用している機器を使えることも大事である。

 情報発信出来るポイントが多いこと
情報へアクセス出来る場所が限られていたのでは、発信する情報量が限られ、必要な情報や、より詳細な情報を伝えることが出来なくなってしまい、その有用度は減ってしまうことになる。

 災害時の環境で機能すること
災害時の電話・電力などの設備がない状況下でも、電池で駆動などで、利用できるよ
うになっていなければ 、役に立たない。

 救援活動現場からのダ イレクトな情報発信可能であること
各地の被害状況や、急を要する情報を現場から直接にオンライン化された情報として発信できることでより有用な情報の活用が可能になると考えられる。

 デマにならないような情報の書き方への考慮がしてあること
推測や伝聞を曖昧に書くとデマの元になる可能性があるので、定型フォームを用意
し 、情報源や信頼度などの情報を必ず示すことを促し 、要約を最初に書くことが自然に行なえるなどの配慮をすることが必要である。

第 2部

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

 情報発信元がわかるような仕組みがあること
ネットワークによる情報は、公的機関からの情報と違って、誤った情報であることや、デマなどの危険性がある。それらへの配慮から、実際にどこから誰が発信したものであるかの確認がとれ、また、途中で変更されたり、発信者以外によって情報が追加されているかなどの確認が取れる手段が必要である。
また、情報入力者としては、つぎのような人が考えられるが、各々の入力者が使用する状況を想定した入力手段が必要である。

 被災者本人
 避難所におけるオペレータ
 警察、消防署
 自治体などの公的機関
情報入力機器の設置場所としては、被災者が集まる場所や救援活動の中心になることが予想される、次のような場所が考えられる。

 避難所
 学校
 役所
 公共の施設
これらを踏まえて、いくつか考えられる入力方法の例としては、次のようなものが考えられる。

1. 既存のパソコンの利用
WWW やメールなどによるデータ入力は、十分活用可能である。
2. 電話から、PhoneShell の技術を活用してのプッシュホンによるデータの入力を行なう。
この方法により、多くの情報を入力することは難しいかも知れないが、電話があればどこからでも情報の入力ができることから情報へのアクセスポイントを増やすことに有用である。また、ファクシミリと併用することで、キーとなる情報はプッシュホン
で入力した後にそれに付随した情報をイメージデータとして送れば 、WWW ブラウ
ザなどのイメージを表示できるツールから検索する場合には、有効な入力手段となり得る可能性がある。

1995 年度 WIDE 報告書

56
3. 学校の施設の利用

学校は災害時には避難所になることが予想される。また、今後、教育環境の整備の一貫としてコンピュータ端末を整備し 、インターネットに接続して利用する計画が進められており、それらを災害時の情報発信のために活用できるように準備をしておくことができれば 、かなり、有効な入力ポイントとなり得る。

4. ゲーム端末の利用
ネットワークへの入力手段となり得るもので家庭に最も普及している電子機器としてゲーム端末がある。これをうまく利用できれば 、操作の容易な入力装置とすることができる。そのためには、それらで利用できる災害・緊急用ソフトウェアを作成しCD-ROM 化して配布することも考えられる。

5. マークシートの利用
避難所などで非常に多くの被災者の情報を集める手段としては、いちいちオンライン
で情報を処理するのでは限界がある。そこで、マークシートを利用して、オフライン
で情報を入力してもらい、避難所のオペレータが回収して、バッチ処理するような入力手段も有効である。

6. 身分証明証、クレジットカード の利用
迅速に正確に情報を入力するためには、氏名や年齢、血液型などあらかじめ準備しておくことが可能な情報の項目を社員証や学生証などに磁気情報として保持し 、カードリーダなどで入力できるようにしておく。また、現状では難しいが、所持しているクレジットカードにより、クレジットカード 会社のデータベースから情報提供が行なわ
れば 、身元確認などが正確に行なうことも可能である。

7. IC カード の利用
情報発信元がわかるような仕組みとしては、将来、電子マネーなどでスマートカード
や IC カード 化されたキャッシュカードなどが普及すれば 、それらと認証技術を用いることができる。

8. ヘビーデューティな端末の利用
救援活動現場からのダイレクトな情報発信を可能にするためには、救援活動者が利用できる 耐故障性のあるディスプレ イやその他いろいろ被災を受けたときにでも大丈夫な端末が必要であるが、既に、軍用の機器として開発されており、液晶を利用した
ヘッド マウント可能な情報表示装置なども市販されており、こういった端末などの利用も可能である。
今後の情報の入力の際の課題としては、次のような点があげられる。

 電源や電話網が被害を受けた場所での電源・通信路の確保を行なう方法の検討

第 2部

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

57

 災害時に混乱した状態で情報を送ることが出来るように、普段からの訓練により、情報の送り先の周知徹底を行なっていくこと 非常時に必要な情報の項目とはどのようなものであるかの整理と、それらの情報を正確に発信できるような情報入力用の専用ソフトウェアの開発の必要性の検討

 情報の信頼度を保つための方法として、認証技術などの利用の検討。発信された時点
では、その情報は正確であったとしても、時間が経過すると状況の変化によっては変更や修正が必要になる。こういった情報の鮮度を保つためのは、入力時点でどのような属性を情報に持たせれば良いかなどの検討

3.3

マルチキャスト の利用について

今回のインターネット防災訓練では IAA 情報の IAA クラスタへの配送機構としてニュ−スシステムを利用し、IAA システムの配送系に冗長度をもたせることを実現した。具体的には、ニュースシステムの NNTP (= Network News Transfer Protocol) の IHAVE/SENDMEの機能を利用することで、データベースの同期を図って稼働する仕組みを構築した。
このような複数の IAA クラスタ間での配送は、マルチキャストを利用した形態でも実現できるだろう。ライフラインタスクフォースでもその可能性について考え、その実用性も検証しておく必要があるだろう。この場合、IAA クラスタ間では事前にマルチキャストのパケットを受け取れるような設定 (例えば 、トンネリングの設定など ) をしておく必要がある。
マルチキャストを利用した情報伝達網は、あらかじめ考慮して設計しておくことによって、災害時において特に有効な情報伝達・共有のための手段なるだろう。
現在、マルチキャストのネットワークとして MBONE があるが、この MBONE では nv 、
vat に代表されるようなアプリケ−ションを使って、さまざまなイベントの映像や音声などがインターネット上に流されている。
マルチキャストのあるグループへの配送するという機能から考えると、テレビなどが緊
急メッセージを流すように非常用のチャネルを確保しておくことができれば有用ではないか。もちろん、そのチャネルに流すべき情報は何か、といったことは議論されるべきである。これらの内容については、マルチキャスト WG と連携をとりながら進めていきたいと
考えている

3.4

ライフラインの各種要素技術とインターネットレ イヤモ
デルインターネットではいわゆる層（レ イヤ）という概念がある。ここでは、ライフライン
で取扱う要素技術とインターネットレイヤモデルとの関係を捉えた上で、ライフラインタ

58

1995 年度 WIDE 報告書

スクフォースで扱う技術が、インターネットのどの層に関連しているのかを考えてみる。
このことにより、インターネットをライフラインとして活用できるようにするための技術が、ある特定の層にだけ集中してしまうことを避けることを目指す。すなわち、インター
ネットをライフラインとして利用できるように、各層におけるライフラインとして必要とされる技術を整理しておく。

3.4.1 物理層/ネット ワークインタフェース層
ライフラインカーなどの実際の IAA 情報やその他システムへのアクセスするための入力デバイス、また、衛星回線の利用や無線ネットワークの利用などがこの層の範疇に入る (実際のユーザインタフェースはアプリケ−ションになる)。
電話、FAX といった既存の通信手段に加えて、クレジットカードなどによるカード 読み取りなどもその簡易性から有効な方法になるだろう。

3.4.2 インターネット (ネット ワーク) 層
ネットワーク層における技術としては WISHBONE 訓練で行ったように、衛星回線を利用した災害時におけるバックボーンの再構成など 、災害時にも利用できるネットワークを構築する技術があげられる。

3.4.3 ト ランスポート 層
トランスポート層というと「運ぶレイヤ」であるが、ライフラインという見地にたつと、障害時に冗長な経路をもって運べるような仕組みがこの層での技術といえる。そういった意味において、マルチキャストもトランスポート層の技術といえるだろう。
また、純粋にトランスポート層のプロトコルとしては TCP と UDP が代表的なものであるが、緊急時や災害時に利用するトランスポート層のプロトコルとはど ういったことが必要なのか、などと考える必要があるだろう。

3.4.4 アプリケーション層
今回行った IAA の訓練などはアプリケーション層の技術である。前述したように IAA
内部においては、入力系、出力系、配送系、蓄積系、検索系などにわかれている。
また、物理層で提供する対する機器のユーザインタフェースとしてのアプリケーションも必要になる。その他、Internet Phone などのインターネット上で登場してくる新しい技
術も検討していく必要がある。
結果として、ライフラインタスクフォースが扱っていく技術を表にまとめると表 3.1 のようになる。

第 2部

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

表 3.1: インターネットレイヤとの関係

Application Layer WWW 、 MAIL interface、 Phone-Shell
IAA 、 Robust-Mail
Transport Layer MULTICASTInternet Layer
WISHBONE
Network Interface Lifeline-Car, 電話, FAX

59

第 4章
投稿した文書などの実績
ライフラインタスクフォースの活動を通じて雑誌等に投稿された文書の一覧を示す。

 WIDE スナップショット (第 23 回) / 「第１回インターネット防災訓練」報告UNIX MAGAZINE 1996 年 3 月号, pp.121 { pp.124,
著者: 多田 信彦, 馬場 始三

 WIDE スナップショット (第 24 回) / 「第１回インターネット防災訓練」報告 (2)UNIX MAGAZINE 1996 年 4 月号, pp.86 { pp.89,
著者: 多田 信彦, 馬場 始三 「第１回インターネット防災訓練」の裏側

INTERNET magazine 1996 年 4 月号, pp.210 { pp.218,
著者: 篠田 陽一, 宇夫 陽次朗

60

第 5章
おわりに
おわりに、今一度、ライフラインタスクフォースの活動の内容について考えて見る。昨年度の報告書では、ライフラインタスクフォースの当面の活動内容として、次のことがらをあげた。

 カラーブックの作成
 安否情報データベースを作成して、IAA 訓練の実施
そして、「安否情報データベースを作成して、IAA 訓練の実施」については、インターネット防災訓練の中で WISHBONE 訓練と同時に行うことができた。引続きライフライン
タスクフォースが扱うべき課題としては次のことがあげられる。

 災害時における現状のインターネットの問題点の明確化
 現状のインターネットに欠けている機能付加を行ったり、機能改善したシステムの提案 システム開発、評価 一般ユーザへの提言
 インタ−ネットサービスプロバイダーらを通しての提言
 カラーブックの作成
新たなシステムの提案／開発としては、情報入力のための機会を増やすため、被災地へのライフラインカーの導入等も検討課題としてあげており、現在、その準備を行っている。
また、被災地内、被災地外での情報の流れの制御などを行う仕組みとしてファイアウォー
ルの技術などの利用も検討していく必要がある。
災害時に活用されるシステムは、日常生活の中で利用できるような仕組みになっていな
ければならない。普段利用していないシステムは、「いざという時」には役に立たないことが多い、と感じているからである。第 1 回のインターネット防災訓練の結果を教訓としながら、第 2 回目の防災訓練に向けてよりよいシステムを作り上げていこうと考えている。

61

62

1995 年度 WIDE 報告書

最後に、３章で述べたロバストなメールシステムについては別ワーキンググループとしてあらたに活動を行う予定となっている。また、ライフラインタスクフォース自身も、ライフラインワーキンググループとしてあらたに活動をはじめることになっている。