データ・デザインの地平［05］震災は、予知できなかったのか？
── 薬師寺　聖 ──

比較的最近になって、PISCOでは、一部のSVG部分をビットマップ画像に切り替えたようですが、もし、SVGビューアのサポートが継続されていたなら、どのような経過をたどっていただろうかと考えます。東北の市民メンバーが増えていたかもしれませんし、そうではないかもしれません。今回の地震前に、掲示板に投稿された2件の報告（オーロラに関する報告と、2日前の地震の仙台管区気象台の発表）以外にも、何か情報が報告されたかもしれません（現在、同サイトでは、事後報告を受け付けています）。

では、PISCO以外に、宏観異常現象を公開したブログやTweetはなかったのでしょうか？　私は震災後に、イルカの座礁を、msnのニュース記事で知りました。予知を研究する学術機関、団体（※2）、個人は数多く存在します。たとえば、宏観異常、地下水、太陽活動、ラドン濃度、耳鳴り、発生周期など、さまざまです。それらをすべてチェックすれば、もっと多数の情報を得られるかもしれません。

そこで考えてしまうのは、情報の統合についてです。ポータルサイトのような大それたものは必要ありません。ただ、さまざまな予知情報を統合して提供するシステムがあったなら、多少なりとも被害の軽減につながったのではないかと思うのです。

●予知データの標準化と公開の方法

各機関や個人が蓄積・管理しているデータベースの構造は、一様ではありません。それらの中から予測発生年月日や、予測マグニチュードといったデータを抽出して統合するには、共通のデータ・デザインに基づいてデータを標準化し、XMLおよびcsv形式で公開する必要があります。

公開さえできれば、あとは、プログラマ有志が、データを再利用するアプリケーションを構築し、一般住民が利用しやすい形で提供するでしょう。もちろん次のような基本的な機能は、すべて実装されることでしょう。

・データの一覧表示。クリックして特定の予知の詳細情報の表示。
・データの検索。地域、年月による絞り込み検索。
・マグニチュード、年月、の昇順／降順ソート。

公開用データの標準化の方法としては、次の4つが考えられます。

（A）各機関の扱うデータのうち、汎用性があり共通化できる部分に対してのみ、メタデータを付加する。メタデータが付加されていない部分は、アプリケーションの側で走査をスルーする。
（B）汎用性があり共通化できる部分を抽出し、管理情報として、追加しておく。管理情報とコンテンツにデータの重複を許可する。
（C）汎用性があり共通化できる部分を抽出し、標準化された構造の別ファイル、あるいは別のXML木を生成する。
（D）ヒトの手を介する。登録フォームに各情報提供者が一日一回、入力する。

このうち妥当な方法は、手間はかかりますが、（D）です。
（A）あるいは（B）あるいは（C）の自動化には、情報提供者が増える都度、
手間も予算もかかってしまい、現実的ではありません。

（D）の方法で登録する情報としては、次の6種類が考えられます。

（1）管理者情報（誰が情報を提供しているか）
名称、予知方法、主宰者名、情報提供日時、ホームページURI、連絡先メールアドレス（非表示）。

（2）時間（いつ発生するか）
年月日時分。いつ頃〜いつ頃まで、といった幅のある情報です。

（3）場所（どこで発生するか）
情報入力ページの地図上に、情報提供者の位置を始点とし、予測した方角へと、線を引くようなUIを実装します。ユーザーは、情報提供者からの複数の線の交わった部分、あるいは囲まれたエリアの情報を参考にすることができます。

（4）規模（どのくらいの大きさか）
考えられるマグニチュードを集約して、平均値、最小値、最大値を提供します。

（5）状況（何が発生するか）
具体的な数字で示される被害状況や、被害のイメージです。

（6）発生の確率（どの程度の割合で発生する可能性があるか）
確率を5段階評価で登録します。平均を★（星マーク、Rating Control）でランキング表現すると、ユーザーが判断するうえでの参考になるでしょう。

これらの情報が提供されれば、ユーザーは、独自の判断で、備蓄を確認したり、避難に備えることができます。

また、これらのデータを蓄積して、実際の地震情報と関連付けることにより、将来的な防災への利用が期待できるかもしれません。ただし、提供された情報を参考にしたうえでの判断と行動の結果に対する責任は、すべてユーザーが負うものでなければなりません。

●予知の精度を高める、欠落情報の補完

我々は、とかく一情報提供者に、前述の（1）〜（6）のすべての予知情報をもとめます。もし、「何が発生するか」はおおよそ予知できていても、「いつ発生するか」は季節程度で月日の特定には至らず、「どこで発生するか」は分かっていないとなれば、そういった情報提供者については「予知はできていない」と判断してしまいます。
挙句、各情報提供者ごとの情報が、それぞれ完璧ではないからという理由で、地震予知そのものを「不可能である」と思いがちです。

しかしながら、原発震災まで含めて「何が起こるか」の詳細を知りえた個人の情報と、「いつ発生するか」のアタリを付けた団体の情報、イルカや鳥の宏観異常現象を見て「どこで発生するか」を特定した個人の情報が結び付けば、予知の全体像が浮かび上がるのではないでしょうか。

地震は予知できないのではなく、完全ではない、あちらこちらの欠落した予知情報が、ネット上にバラバラと存在し、点と点をつなぐシステムがないために、5W1Hが明らかになっていないだけなのかもしれません。

その点、標準化されたデータが公開されるならば、アプリケーション側でそれらを集約し、各提供者の情報を補完し合い、ひとまとまりのデータとして表示することができます。

予知データの標準化と公開は、これまで発信してこなかった個人からの情報を吸い上げる意味でも有効でしょう。

一部情報を知りえた個人が、ブログやTwitterなどで情報を公開しようとしても、情報提供への感謝だけでなく、情報掲載を責める声も同時にあがることが考えられ、公開する勇気はなかなか持てないものです。完全ではない情報でも公開可能なシステムがあれば、発信しやすくなります。

それらのひとつひとつは、小さな情報かもしれません。が、それらを吸い上げ統合することによって、予知精度の向上を見込むことができるのではないでしょうか。

なお、こういった試みは、情報提供者側にもメリットがあります。部分的な情報を持ちながら、それが完全でないために公開することができず、挙句、災害が発生すると、その個人は、勇気を出しておけば、一人や二人は助かったのではないかという後悔の念にさいなまれるようになります。人的被害が大きければ大きいほど、多数の人を見殺しにしたのでは、という激しい贖罪の意識を、一生引きずるようになります。予知データの標準化と公開は、このような予知に取り組む個人の心的負担を軽減させることにもつながります。

●データ標準化、実施に向けての課題

どのような企画でも、青写真を描くことよりも、実施の方が何千倍も難しいものですが、この件に関しても、企画の実施には、多数の課題があります。

データ・デザイン、Webサーバーの構築と管理・運用、データベース構築、データ登録／公開用アプリケーション開発、といった一連のシステム構築には、とりたてて技術的に克服しなければならない課題はありません。また、手間と費用がかかるのは初回だけで、一度構築すれば、フレームワークのバージョンアップに伴うメンテナンスだけで済みます。

問題になるのは、データ提供側の作業負担と、データ精度の保証です。

まず、データの著作権の問題、データ提供者の転載許可の問題が考えられます。また、フォームへの登録は、情報提供者にとって手間のかかる地道な作業であり、大きな負担となる恐れがあります。いくら国民のためとはいえ、日々の無償奉仕を期待することは難しいと思われます。

かといって、無作為に自己申告で情報を受け付ける仕組みでは、情報の精度が維持できなくなります。ユーザーには情報の真偽を確かめる術がなく、風説飛び交う事態になりかねません。

特に難しいのは、夢などの予知による情報提供です。科学が証明したためにヒトが存在しているわけではなく、ヒトが存在し科学がそれを証明しようとしているのであって、科学でまだ証明できていないからといって否定してよいものではないのでしょうが、情報提供者として認定するかどうかの明確な基準を設けることは不可能でしょう。

信頼できる情報提供者の認定、各機関や個人に根回しをしてコンセンサスを得て、確実な登録をしていただくことに同意を取り付け、情報提供者の個人情報も管理していく作業は、ITエンジニアには手に余る作業です。これは、公共機関か、公的な色彩を帯びた団体の仕事です。

データは日々蓄積されていきます。標準化を先送りにすればするほど、それぞれが蓄積している貴重なデータは、再利用不可能な独自データとなってしまいます。標準化されていないデータが、点在するサーバに蓄積され続ける愚は避けるべきです。早急な取り組みが望まれるところです。

平穏無事な社会を維持していくためには、そのバックエンドに、プログラムから処理しやすく、バグを引き起こしにくい構造のデータ・デザイン、その構造に則って蓄積される信頼性あるデータが必要なのです。

※1　SVGは、HTML 5とともに再び脚光を浴び始めています。Microsoft社のVML、RIAのデザイン言語であるXAMLも、SVG同様、XML言語で記述されたベクターグラフィックスの仕様です。

※2　宏観異常を対象とする公的なものには、次の2つがあります。
・関西サイエンスフォーラム
「地震前兆情報の利活用に関する調査・研究と提言（第1次報告書）」
< http://kansaidoyukai.or.jp/Default.aspx?tabid=158
>
「地震前兆情報の利活用に関する調査・研究と提言（第2次報告書）」
< http://kansaidoyukai.or.jp/Default.aspx?tabid=159
>
・静岡県地震防災センター「バーチャルライブラリー 宏観異常現象」
< http://www.e-quakes.pref.shizuoka.jp/shiraberu/higai/koukan/
>

※防災対策の参考にご利用ください。
・緊急時持ち出し品リスト（筆者の独断による）
< http://sei.seindesign.net/emergency/info.htm
>
・非常時に備えての、情報の保管および持ち出し方法（ITエンジニア向け）
< http://blogs.itmedia.co.jp/seindesign/2011/04/post-e7d9.html
>

※Microsoft社の、Webの未来をフロントエンドから取り上げるカンファレンス「MIX11」（4/12〜4/14）では、HTML5やCSS3、Silverlight、Internet Explorer、Windows　Phoneについて、多彩なセッションが繰り広げられました。
< http://www.visitmix.jp/
>

【薬師寺聖／個人事業所セイザインデザイン】
個人事業所　< http://www.seindesign.net/
>
ブログ　< http://blogs.itmedia.co.jp/seindesign/
>
PROJECT KySS　< http://www.projectkyss.net/
>
< infosei@seindesign.net >

ヴィジュアル、サウンド、テキスト、コードの間を彷徨っている、四国の個人事業主。科学技術や医療・福祉分野のXML案件の企画デザインに実績があり、コラボレーションユニットPROJECT KySS名義で、XML、RIA、.NETに関する書籍や記事、多数。
Microsoft MVP for Development Platforms - Client App Dev
（Oct 2003-Sep 2011）