震災は、予知できなかったのか？ ～メルマガ連載記事の転載 （2011年4月18日配信分） ～
この記事は、メルマガ「デジタル・クリエイターズ」に月1回連載中の「データ・デザインの地平」からの転載です。今月で10回目になりますので、まとめて載せています。
連載「データ・デザインの地平」
第5回 「震災は、予知できなかったのか？」 （2011年4月18日配信分）
復旧が遅々として進まない東日本大震災。まだ辛い暮らしをよぎなくされている人々にかける言葉もありません。
未曾有の大災害であるにもかかわらず、なぜ、多少なりとも事前に注意を喚起することができなかったのでしょうか？
それは、複数の予知情報を集約して公開する、広く周知されたシステムが、我が国には存在していなかったからではないかと、私は考えています。
今もとめられる、複数の予知情報の統合
地震予知には数々の方法があり、学術機関だけでなく、多くの団体や個人が独自の研究に励んでいます。
有名なものの一つに、NPO法人大気イオン地震予測研究会e-PISCOがあります。この団体では、イオン濃度の観測結果を軸に、市民メンバーから報告される宏観異常現象（動物、気象、家電製品などにみられる地震発生前の異常現象）を公開しています。ところが、東北地方東部には、大気イオン濃度の正規測定点はありません。そのため、東北エリアの予知については、会員が自主的に報告する宏観異常現象頼みになります。
その宏観異常現象のリストは、PISCOのWebサイト開設当初、SVGで描画された日本地図上に表示されていました。それを閲覧するには、Adobe社のSVGビューアが必要でした。
ところが数年前、Adobe社が突然SVGビューアのサポートを中止。宏観異常現象の地図上表示のページは事実上、閲覧不可能となりました。しばらく表示できない状態が続くと、ユーザーの足も遠のきがちになります。筆者も、その一人です（SVGが閲覧可能だった頃までは市民メンバーとして時折ポストしていました）。
最近になって、PISCOでは、一部のSVG部分をビットマップ画像に切り替えたようですが、もし、SVGビューアのサポートが継続されていたなら、どのような経過をたどっていただろうかと考えます。東北の市民メンバーが増えていたかもしれませんし、そうならなかったかもしれません。今回の地震前に、掲示板に投稿された2件の報告（オーロラに関する報告と、2日前の地震の仙台管区気象台の発表）以外にも、何か情報が報告されたかもしれません（現在、同サイトでは、事後報告を受け付けています）。
では、PISCO以外に、宏観異常現象を公開したブログやTweetはなかったのでしょうか？
私は震災後に、イルカの座礁を、msnのニュース記事で知りました。
予知を研究する学術機関、団体（例「関西サイエンスフォーラム」）、個人は数多く存在します。
たとえば、宏観異常、地下水（※1）、太陽活動、ラドン濃度、耳鳴り、発生周期など、さまざまです。
それらをすべてチェックすれば、もっと多数の情報を得られるかもしれません。
そこで考えてしまうのは、情報の統合についてです。
ポータルサイトのような大それたものは必要ありません。ただ、さまざまな予知情報を統合して提供するシステムがあったなら、多少なりとも被害の軽減につながったのではないかと思うのです。
予知データの標準化と公開の方法
各機関や個人が蓄積・管理しているデータベースの構造は、一様ではありません。
それらの中から予測発生年月日や、予測マグニチュードといったデータを抽出して統合するには、共通のデータ・デザインに基づいてデータを標準化し、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 私の住む地域で言えば、南海地震の際に道後温泉の水位が変わったという話は、かつては地学の参考書にも載っていたほどで、地下水データベースには実施前から期待していて、しばしばアクセスしていました。が、グラフが見にくく、目をしばたたいて呻吟しなければなりません。当市の場合、大きな変化があれば消防メール（私も受信しています）で配信されるといいのですが。
※ 防災対策の参考にご利用ください。
・緊急時持ち出し品リスト（筆者の独断による）
・非常時に備えての、情報の保管および持ち出し方法（ITエンジニア向け）
≪ 第1回 UXデザインは、どこへ向かうのか？ (2010/12/20)
≪ 第2回 そのデータは誰のもの？ (2011/01/24)
≪ 第3回 子ノード化する脳 (2011/02/20)
≪ 第4回 多重CRUDの脅威（2011/03/14）
≪ 第5回 震災は予知できなかったのか（2011/04/18）
≪ 第6回 永代使用ポータル、クラウドがつなぐ生者と死者の世界（2011/05/16）
≪ 第7回 「脳活動センシングの進化が、作曲を変える」(2011/06/13)
≪ 第8回 「死にゆく者の意思は守られるか」 (2011/07/11)
≪ 第9回 Windows Phone 7.5 に見る"ヒトとコミュニケーションの形"(2011/08/29)
≪ 第10回 データ設計者は、ヒトを知れ、脳を知れ(2011/09/26)