前回（第29回）、私が地震防災、というより地震発生後の被災を減らす減災のプロジェクトに関わっていたと書いた。今回の熊本地震ほど、強い余震で大勢の人々を不安に陥れた地震は珍しい。実際、同じ地域で3日間に震度7が連続したことは観測史上なかったとのこと（※1）。早期の収拾と現地の復旧・復興を心から祈る。

私が地震減災研究プロジェクトに関わっていたころ、講演でよくこんな話をした。情報でお腹はふくれないし、怪我も治らない。しかし、情報の欠如は被害を拡大し（安全を削る）、人々を不安に陥れる（安心を阻害する）。逆に言うと、情報で腹が減らないように行動できるし、怪我しないように準備できる。

災害時の減災活動には関係機関および被災住民の間での的確な情報共有が必要なのは言うまでもない。多数の災害対応機関は、的確な情報共有がないと、それぞれの限られたリソースを最も適切な対応行動に割り当てる戦略が立てられない。そもそも的確な情報共有が必要でないのは、情報が共有されないことが面白みにつながるトランプなどのゲームだけだろう。

的確な情報共有は、情報共有することが役に立つ範囲で行わないといけない。過剰な情報共有はノイズになり、判断を遅延させたりする。それでも、できるだけ情報は共有するほうがいい。ノイズフィルタはそんなに難しくない。また、情報共有のための「言語」自体の共有というか、共通化を忘れてはいけない。

とても簡単で分かりやすいエピソードを紹介しよう。10年ほど前、自宅に帰る夜道を歩いていたら、目の前の駐輪場からフラフラと出てきた女性の自転車と私の後ろから走ってきた原付バイクが接触した。女性が転んで怪我をしたので、私は救急車を呼ぶために携帯で119番した。かくかくしかじかと言ったのだが、場所の情報がなかなか伝わらない。駐輪場といってもたくさんある。

ふと目の前の電柱を見ると、東京電力の電柱IDとも言うべき番号が振ってある。これを読んで「この番号の電柱の前です」と言ったが、まったく通じない。当時、まさに減災のための情報共有の仕事をしていたので、なるほどこれはダメだなと思った次第。

今どきだったら、スマホのGPSの緯度・経度情報を送ればいいのかもしれないが、そう昔でない2003年、以下のようなニュースがあった。政府が警察や消防、自衛隊などの間で異なっている用語の統一に乗り出したというのだ。言語の共通化である。

例えば、自衛隊はパトロール活動を「巡察」と表現するが、警察は「警ら」、消防は「巡回」という用語を使う。場所を表現するのに、自衛隊が緯度・経度で表記するのに対し、警察と消防は住所を使う。道路管理機関は道路上の特定のポストからの道路に沿った距離「地先何km」という言い方をする。なので、共同で図上演習を行うと、やり取りが混乱したらしい。

減災プロジェクトの関係で知己を得た、以前市ヶ谷にいらっしゃった自衛隊北部方面隊総監に自衛隊の災害対応行動について教えてもらいに行ったとき、帰り道、運転していただいた隊員の話す言葉に分からないものが多く、いちいち聞き返してしまった。その都度、言い直してもらえたが、なるほどこのことかと思ったものだ。自衛隊が緯度・経度なのは、道なき山や野での活動が多いから当然なのだろう。

言語の共通化が現在どうなっているのか、ちょっと検索しても分からなかった。これも今は違うのかもしれないが、警察と消防の間の意思疎通も良くないという話を聞いた。実際、阪神・淡路大震災のときは、両者で死者等の発表数値が異なっていた。

こういうレベルで情報共有が阻害されているとしたら、困ったことだ。

さて、実際に災害が起こると少なくとも数年前までは（多分今も同じだろう）、役場に設置された災害対策本部に大きな紙地図が広げられ、その上で赤鉛筆とか、駒のようなもので災害対応戦略が検討される。壁には電話連絡で届いた災害状況がなぐり書きされた付箋紙がペタペタと貼られる。どう見ても、500年前の戦国部将たちの作戦会議とまったく同じ情景。地図の精度と付箋紙以外、見事に進歩していない！

縦割り行政の間の情報共有促進には政治的なことが一杯からんでくるので、IT研究者としては言いたいことは言うものの、結局埒があかない。だから、技術サイドで何ができるかを真面目に考えるしかない。

その中で目玉だったのが、学生の上田真史（まさふみ）君が開発した、マルチマウスと、どこでも簡単大画面システムである。

マルチマウスは、USBハブでつないだだけの多数のマウスを、ひとつの画面にそれぞれカーソルや意味を変えて表示して、マウス動作を可能にする技術である。

これがあると1個のマウスを奪い合いすることなく、画面に表示された地図上で各担当者が独立に書き込んだり、情報を参照したりすることができる。実は前回の遺言状の写真2でもマルチマウスシステムが使われていて、多数の消防団員が予め与えられた紙に書かれた情報を入力するのに並列入力してもらったところ、とても早く入力が終わったという実験結果が得られている。

これを愛知県豊橋市のとある町内会での避難訓練に応用したのが写真1と図1の画面である。

ここでは避難所に避難して来られた方々数人同時に、自宅の表示場所をキーとして、家族の避難状況などを入力してもらった。そもそもマウスに初めて触ったというお年寄りもいらっしゃったが、近隣の人の手助けでちゃんと入力が完了した。

なお、これと同じ地図をベースに災害対応現場隊員5名と本部4名（消防、救急、土木）が情報共有をする仕掛けも用意した。実際、当日は現場隊員役の学生たちが、私が昨晩のうちに秘密裡に書いた（隊員ごと別々の）被害状況シナリオを持って、あちこちを歩き廻り、携帯デバイスで本部に逐次報告を入れ、本部担当の学生（彼らはシナリオを知らない）がマルチマウスを使って被害状況を集約するという作業をした。最後は私の書いたシナリオ全体とほぼ一致したので実験は成功だった。

また、新潟県見附市で行った防災訓練でもマルチマウスを利用した。いろいろな部署の方がそれぞれのマウスを使ってひとつの画面で共同作業できるようになっている（写真2）。

マルチマウスは、何も面倒なことをせず、USBマウスとUSBハブさえあればすぐ可能になるところがミソである。これだったらお金の余裕のない自治体でも利用できる。マルチマウス自体は汎用的な技術なので、上田君は多人数で遊べるマインスイーパを作った。これはリアルタイムの競争ゲームなので、みんな焦りながら楽しんでいた（図2）。

広域災害に対応するためには、大きな地図を表示したくなる。これが上田君のもうひとつの作品、どこでも簡単大画面システム「天窓」である。天窓を使えば、その辺にあるWindows PCとプロジェクタをかき集めてくれば、簡単に災害対策本部用の大画面が作れる。写真3は初期の実験で、1台のPCにある映像（仮想画面）を6台のPCにネットワーク分配し、6台のプロジェクタで壁に投影したものである。天窓はその名の通り、それぞれのPCが巨大な仮想画面の一部を切り取って表示できるという仕掛けである。

天窓の例をもう2つ紹介しておこう。写真4は2560×1600の30インチ液晶ディスプレイを横に3つ並べて東京駅から国立駅付近までの中央線沿線のGoogle Earthを表示したもの。写真5は学生たちの持っているノートPCを4台並べてひとつの画面にした例。写真6は余談。

今だったら4Kとか8Kのディスプレイもあるのだろうが、災害対策本部で多人数が見て共同作業するとなったら、大きな画面が容易に得られるこの技術はやはり捨てがたい。プロジェクタを使えば、レーザーポインタを使っても場所の指示が共有できるし、戦略会議向けだ。何しろ機器は寄せ集めでよく、専用ハードが不要で安上がりであることが、地方自治体にはとてもありがたいはず。必要なのは災害対策本部向けのソフトだけである。

それにしても上田君は実に勇猛果敢にWindowsと挌闘した。当時はWindows XP。特に天窓では、Windowsのディスプレイドライバが、ほかのデバイスドライバと異なり、二重の仕掛けになっていて苦労したと言っていた。仮想マシンでデバグをしたのだが、1日に両手回数、ブルースクリーン（Windowsが死ぬときの画面）と等価なものを見たという。彼の華奢な体形のどこにそれを乗り越える馬力があるのだろうと思ってしまう。しかし、持ち前のユーモア精神がそれを支えた。

それを物語るのが、研究室のゼミで発表したときのおまけスライドだ。どうも原本が発掘できないので、上田君に提供してもらったボカシ入り画像（図3）と、苦労談を引用させていただこう。

ところで、私がこれまで開発してきたモノは概ねすべてがそうなのですが、完成までにだいぶツラい目に遭わせてくれます。未踏ユース現役時のブースト会議では、私はこの状況を「クソゲー」と銘打ち、以下のような画像にて紹介しました。

図3：とある有名ゲームの復活の画面のパロディ（上田真史君提供）。

なぜクソゲーかと申しますれば、つくっているものがバグもないのに何故か動かないとき、それがどうしてなのか誰もわからず、webを掘っても微かなヒントにたどり着ければいい方、という状況に陥るからです。理論上は動くはずのものが動かないなど日常茶飯事で、挙句の果てには画面が青くなるなど、図の通りまさに死屍累々です。

そうこうしているうちに結局敵は、最低限この部分は信用できる、これを変更すると影響が著しく広範囲に及ぶ、そんなふうに思っていたところに潜んでいることがわかります。ゲームならラスボス直前にて、味方が裏切ったり、レベル1の時点での選択肢を間違えていたことが今更わかったり、コントローラを投げたくなります。

ゆえに全てに対し疑心暗鬼になり、膨大な修正作業に身を投じることになるわけです。

こういう境地に達することができるとは大変なことだ。実は私も1990年代、デバグの最後はハードを疑わないといけないという開発をしたことがあるが、上田君も現代の巨大「ハードウェア」であるWindowsに疑心暗鬼になったわけである。「なあに、そんなの最初から分かっているよ、再起動すればいいのだよ」では済まないのだ。

私の場合、LSIの中のバグはもうデバグできないので、ソフト（マイクロコード）のほうでそれを回避するようにした。幸い、ほんの僅かの性能劣化で済んだ。

地震は、我々が住んでいる地球というハードウェアのバグである（※2）。これはどう見てもデバグできないので、その被害拡大を回避する減災には何回ブルースクリーンを見てもくじけないソフト屋魂が必要なのだろう。

最後になるが、このような成果を上げ、この記事のためにいろいろな資料を提供していただいた上田君に感謝する。（つづく）

※1：そもそも震度7を正規の震度計で実際に観測したのが東北大震災が最初なのだからという理屈を超えていると思う。
※2：いや、これはバグではなく仕様です、という感想を述べた方がいた。遺言状第20回に登場していただいたサイボウズ・ラボの川合秀実君である。なるほど、こちらのほうが人生達観できているかもしれない。デバグできないバグは仕様である！

竹内先生への質問や相談を広く受け付けますので、編集部、または担当編集の風穴まで、お気軽にお寄せください。（編集部）

この記事を、以下のライセンスで提供します：CC BY-SA
これ以外のライセンスをご希望の場合は、お問い合わせください。

SNSシェア

• シェア
• Tweet