阪神・淡路大震災と3.11を経て ～ ITが人を救う日、24時間戦えますか？ ～

[Masazumi_Koga]

●個人の災害対策：レスキューキット

皆さんは、レスキューキットを持っていますか？筆者は、定期的に、自宅のレスキューキットの定期点検を行い、古くなった食糧を新品に交換しています。

災害時の行動指針としては、エレベータの使用がNGとか、携帯型バッテリーの確保、火元チェック、高台への避難等、いろいろありますが、最低限の食糧、水、防寒具を確保し、すぐに使用できることは、非常に重要です。

レスキューキットは、大きさや内容物によってピンキリなのですが、いくら高価なものを持っていても、いざとなったときに、すぐに取り出して、すぐに携行でき、すぐに使える状態になっていないと意味がありません。また、災害対策用の食糧は、保存がきいて火を使わずに食べられるものを確保しておくことが必要です。水や栄養ドリンクも重要ですし、非常用防寒具は、コンパクトに折りたためるものがよいでしょう。

よく「近くにコンビニがあるから大丈夫じゃない？」と言う方がいますが、3.11のときのように、大災害の時は、スーパーやコンビニの食料品や自販機の飲み物や生活用品が、瞬く間になくなってしまいます。

また、建物、道路、電線などが大きく破損した場合は、外に出られずに閉じ込められることも想定されるので、コンビニに行けない状態もありえます。そのため、「コンビニはないものとして考える」が災害時の基本です。

なので、最低限、レスキューキットは、手元に必要なのです。皆さんも、災害対策用のレスキューキットをいつでもすぐに使えるようにし、食糧の消費期限、防寒具、電池など、定期点検することをお勧めします。

■阪神・淡路大震災で被災した祖父母の家

「レスキューキットを点検っていうけど、ちょっと神経質に心配しすぎでは？」と言う人もいます。しかし、筆者は、学生時代からレスキューキットを持っています。

レスキューキットを持ち続ける理由、それは、1995年1月17日に発生した兵庫県南部を震源とする「阪神・淡路大震災」です。

阪神・淡路大震災は、ビルや地域インフラなどの巨大建造物の倒壊の被害が大きかった大都市災害で、実際、多くの道路が大量のガレキでふさがりました。また、あまり知られていませんが、大規模な地滑りも発生しています。

当時、筆者の実家は、大阪駅からJR福知山線で50分ぐらいの兵庫県三田（さんだ）市という神戸市の北に位置する畑と山だらけの山奥の田舎にありました。

そんな兵庫県三田市の山奥にある一戸建ての実家も被害が出て、庭の塀やカースペースも崩れ、家の外装や内装にもかなりのひびが入りました。さらに、実家よりも被害が大きかったのが、兵庫県伊丹市にある祖父母の家でした。

祖父母の家は、いつ建てたのかわからないくらい古い木造の家でしたので、震災の日は、祖父母と電話も通じず、家族全員が「伊丹の家は、アウトかもしれない」と思っていました。

安否確認や物資を家族に届けようとした人で自家用車の大渋滞が発生していたため、父は、車ではなく、自宅にあるオフロードバイクで祖父母の家に向かわざるを得ませんでした。

奇跡的に祖父母も無事だったのですが、家自体が今にも崩れてきそうで非常に危険な状態で、家の中に入れない状態だったので、結局、祖父母の家は、伊丹市から「全壊」扱いで処理されました。

阪神・淡路大震災に限らず、メディアでは、地震発生時に、家の電灯が揺れたとか、食器が落ちたり、コンビニの商品がけっこう散乱したなどの光景がニュースなどで流れるので、そういう規模感の地震をイメージしがちです。しかし、阪神・淡路大震災は、電灯が揺れたとか、皿が割れたとか、モノが落ちたとか、そういうレベルではありません。

ドン！ドン！ドン！と下から突き上げる巨大な音と衝撃で、奥行きのある重いブラウン管の大型テレビが、勢いよく空中に浮き、浮いた後に真横にぶっ飛んでくるといった、そういうレベルです。

大型テレビやタンスが「倒れてくる」のではなく、空中に浮いて真横に飛んできて、部屋の反対側のベランダのガラスを突き破り、外は、ガレキと倒れた電柱で道がめちゃくちゃになっているという、そんな状態です。

安否確認と食糧と水を確保することしか思いつかない状態の人々で溢れかえり、「なんかもう、家も街も人も、ひっちゃかめっちゃか」というのが阪神・淡路大震災だったわけです。

なので、「コンビニが近くにあるから、大丈夫じゃない？心配しすぎじゃない？」と言い放つ人の災害対策の考えがいかに甘いか、筆者は、レスキューキットを点検するたびに感じるわけです。

ちなみに、阪神・淡路大震災の教訓から、日本では、大地震に耐えられるように道路・建物の設計の見直しや法整備が行われ、耐震改修促進法（建築物の耐震改修の促進に関する法律）も制定されました。

また、阪神高速道路の倒壊の教訓から、全国の高速道路の強度の全面的な見直しにより、高速道路の柱を鉄板で覆い、その中にセメントを流し込むという耐震補強が施され、道路等の物流のライフラインの災害対策が施されました。

■新幹線における安全設計に関する技術的思想

2022年3月16日に発生した福島県沖地震では、東北新幹線脱線事故が発生しました。地震により、電車の本体が線路から脱線した事故ですが、死者ゼロで、大事故には至りませんでした。新幹線の脱線事故は、2004年10月23日に発生した新潟県中越地震の際に、上越新幹線でも発生しており、2022年の地震で、新幹線の脱線事故は、2例目です。

2004年に発生した新潟県中越地震の新幹線脱線事故は、日本の新幹線の営業運転中の初めての脱線事故であったため、メディアは、「新幹線の安全神話が崩れた！」と一斉に報じました。この「安全神話が崩れた！しかし、幸いにも大事故に至らなかった」というフレーズをメディアが流しまくり、それ以降、皆さんも、もしかしたら、そんな感じのニュースをたびたび耳にしたことがあるかもしれません。

このメディアの発信は、あたかも「たまたま大事故にならなかった」という印象を受けた方も多いかと思います。しかし、2004年の上越新幹線の脱線事故は、本当に「たまたま大事故にならなかった」のでしょうか？

そして、メディアが言う「安全神話」は、本当に崩れたのでしょうか？

実は、日本の新幹線は、当時すでに、走行中に脱線が発生しても、脱線した車輪と車両底部のギアボックスと車両先頭の排障器で線路をはさみ込む形で滑走することで、車体が大きく線路から離脱しない設計になっていたのです。

すなわち、脱線したとしても大事故にならない車両をすでに採用していたわけです。この仕組みのおかげで、あれだけの地震が発生したにもかかわらず、日本の新幹線の脱線事故では、一人の死者も出していないのです。

このように、「脱線させない対策」ではなく「脱線しても大事故にならない対策」、すなわち、被害が発生しても被害を最小限に留めるという「フェールセーフ」の技術的思想は、様々な製品や社会インフラ等で実装されています。

ちなみに、この脱線した車輪と車両本体で挟み込んで滑走し大事故にならない仕組みを成立させるためには、新幹線の線路が敷いてある高架橋自体が耐震補強してあることが前提です。なぜなら、脱線した新幹線がいくら車輪と筐体でうまく挟み込んで線路を滑走できたとしても、下の線路に大きな損傷があると、大事故につながる恐れがあるからです。そのため、2004年よりもずっと前の時点で、上越新幹線の線路の高架橋の柱には、阪神高速道路倒壊の教訓で学んだ「鉄板とセメントによる耐震強化」がすでに施されていたのです。これにより、高架橋のまわりの土地が液状化現象でぐちゃぐちゃになっていたにもかかわらず、線路が敷いてある高架橋は全く影響を受けず、かつ、上述の車輪の挟み込み滑走の仕組みのおかげで、大事故に至らなかったわけです。

メディアが言う「幸いにも大事故にならなかった！」ではなくて、「すでに大事故にならない災害対策の仕組みが高架橋と車両に施されていて、うまく機能した」ということなのです。

フェールセーフの仕組みが新幹線の車両に取り入れられていることを知っている人からすれば、「新幹線が脱線したから、安全神話が崩れた！」とか「ロケットエンジンが点火しなかったから、失敗だ！」と騒ぐ人は、非常に奇妙に見えます。

「新幹線が脱線したから、安全神話が崩れた！」とか「ロケットエンジンが点火しなかったから、失敗だ！」を騒ぐ人は、おそらく、新人研修で学ぶレベルの「フェールセーフ」というものを知らないか、あるいは、「社会システムは絶対に完全なものが必要だ！」という思想の持ち主の方か、あるいは、「システムが止まる＝失敗作品」と決めつける人のどれかです。なので、そういう偏った視野の狭い考え方にならないように、昔から、製造業やIT企業の新人研修などでは「フェールセーフ」を学ぶのです。

このように、事故が発生しても、できるだけ大事故にならない方向に自動的に遷移させるフェールセーフの設計以外にも、様々な障害対策や災害対策の考え方があります。

例えば、寿命内で損傷が発生しないことを目指すセーフライフ（安全寿命設計）や、寿命前に損傷が発生しても、損傷が広がらずに通常利用を継続できるように設計するダメージトレランス（損傷許容設計）もあります。また、セーフライフで設計されていたものが、現在はダメージトレランスで設計されているものなども存在します。 

●【参考情報】フェールセーフ（機能停止時に、安全性を確保するために、自動的に安全な状態に移行する仕組み）の例：

・踏切の遮断機（電力を失っても、踏み切り自体が下りてきて、人や車両が線路へ誤侵入するのを防ぐ）

・転倒時にスイッチが自動的に切れる電気ストーブ

・電子レンジのドア

・ロケットエンジンの着火装置

●【参考情報】安全寿命設計（セーフライフ）の例：

・木製の椅子

・はしご

・杖

・消火器

●【参考情報】ダメージトレランス（故障しても、継続して機能するための仕組み）の例：

・航空機（機体のダメージをチェックし、飛行が可能かどうかを判断する。ボーイング767以降、エアバス310以降は、ダメージトレランス設計。旧世代のボーイング747は、フェールセーフ設計）

・ランフラットタイヤ（パンクしても、ハンドル操作を取られずに走行できる仕組みがタイヤ自体に施されている）

■90年代からすでに世界最強の24時間365日連続稼働の災害対策マシンは、「NonStopサーバー」

ITの災害対策といえば、皆さんもご存知、昭和と平成時代を代表する「24時間戦えますか？」のキャッチフレーズで世界的に有名になった栄養ドリンク「リゲイン」のCMを彷彿とさせる、HPE最強の24時間戦う無停止型マシン「NonStopサーバー」ですよね。WindowsでもUNIXでもLinuxでもMacでもない特殊な無停止OSである「NonStop OS」が搭載されており、24時間寝ずに動き続けるマシンです。金融や社会インフラの基幹系など、止まってしまうと新聞沙汰になるようなITシステムで採用されています。

実は、筆者が初めてこのNonStopサーバーに出会ったのは、学生時代です。

阪神・淡路大震災から数年が経過し、筆者が大学院生の時に、大学の所属学科の事務局や別の階の研究室に、やたらと弊社の合併前の会社のDEC（Digital Equipment Corporation.：通称、デック）と、Compaq Computer Corporation（コンパックコンピュータ）とTandem Computers（タンデムコンピューターズ）の製品カタログがあるのを見つけます。

実は当時、旧タンデムコンピューターズの社長室長と筆者の大学の教授がずっと昔から繋がっていて、そのご縁で、DEC、Compaq、Tandemのカタログが、うちの学科にやたらとストックされていました。研究室や大学の事務局などにあるカタログを見て、なにやらタンスぐらいの大きさのデカいコンピューターをやっているDECやタンデムっていうIT系の会社があるっぽい、というのは、ぼやっとですが知っていました。

（まさか、DEC、Compaq、Tandemが合併してHPになり、その合併した会社に自分が新卒で入社するとは全く思ってなかったのですが。）

結局、筆者が内定した後、DEC、Compaq、Tandemのカタログを読みまくりました。すると、カタログには、当時の無停止型サーバーの「NonStop Himalaya」の「災害対策」「無停止」という、自分がやっているAIや情報工学・情報科学とは全く違う世界のITの災害対策の世界を知ることになったのです。正直、ITの世界で「災害対策」というのがあることなど、これっぽっちも頭にありませんでした。

筆者は、カタログに記載された「災害対策」の意味を理解した時、祖父母の家の全壊処理や自宅の修繕に忙殺される父親がシンクロし、自分がいかに狭いITしか知らなかったか、愕然としたことを今でも鮮明に覚えています。　

（上記の写真は、タンデムコンピューターズ（現HPE）のNonStop Himalayaの1998年当時の製品画像。前世紀から「24時間無停止で働くマシンといえばタンデム」というイメージを確立していた。筆者の狭い視野を広げたマシン）

ちなみに、その後、「24時間動き続ける三重化された無停止サーバー」という異世界のITを知った筆者は、ITシステムに限らず、あらゆる分野の災害対策の手法に関する記事を幅広く見るようになりました。そして、筆者が新卒で名古屋に配属されて最初に製造業のお客様に提案したシステムも、旧DECのTruCluster（トゥルークラスター）呼ばれるUNIX系OSの災害対策機能を有した高可用性クラスターソフトウェアを使ったサーバーシステムでした。また、後に東京に転勤後も、筆者は、高可用性クラスターソフトウェアの「Serviceguard for Linux」（サービスガード・フォー・リナックス）の技術を担当しました。

日本のような災害大国では、Serviceguardのような高可用性クラスタや、NonStopサーバーなどの無停止型のシステム採用は、今後も続くことでしょう。「24時間戦えるIT」を提供できるソリューションやハードウェア製品やソフトウェア製品を自前で持っているのは、HPEの大きな強みだと、今でもつくづく思います。

■ITを駆使した災害対策は、リアルタイム化が課題

先述の弊社のNonStopサーバーのような多重化の話や、ServiceguardのようなHAクラスタソフトによるIT基盤の災害対策の話は、今後も決してなくなることはありません。

しかし、IT基盤の災害対策だけでなく、祖父母の安否をオフロードバイクで確認しに行った私の父のように、災害時の避難経路をどのように見つけるのかといった最短経路探索の問題も、国や自治体から見ると災害対策の一つです。

例えば、ビルの倒壊で道が塞がっている、あるいは、橋などが大きく損壊している場合、どのようにすれば帰宅困難者を減らせるか、あるいは、帰宅せずとも、一番近い安全な避難場所に退避させることができるか。または、最短の迂回路をこれらの帰宅困難になりそうな人々にリアルタイムで提示するには、どのようにすればよいのか、といった、災害対策用の社会システムのITが必要です。

一般に、帰宅困難者の話などで出てくる「経路探索」の世界では、「グラフデータ処理」と呼ばれる計算が行われます。グラフデータ処理といっても、よく見るエクセルの棒グラフや円グラフのことではありません。グラフデータは、大量の点（場所や人）と線（経路やSNSの友達繋がり）が複雑に繋がったもので、その膨大な点と線の繋がりに対して、最短経路や最低運賃などの最適解を見つける処理が、グラフデータ処理です。SNSであれば、人と人の友達の繋がりから最も購買確率の高い興味のある商品を提示することや、災害対策であれば、最短経路、航空などの流通業であれば、ハブ空港の提示や最低運賃の算出などが代表的な例として挙げられます。

「それって、乗り換え案内アプリのこと？そんな膨大な計算なの？」と思われるかもしれませんが、乗り換え案内のような一人の最短経路や運賃を求めるだけなら、非常に単純な処理で、結果もすぐに得られます。しかし、災害時に数百万人（＝数百万の点）が絶えず移動し、大量の危険情報が追加された状態で、その数百万人が安全な場所に最短経路で到達できるかどうかを割り出すためには、膨大な計算が必要なのです。

都市計画における災害対策の研究では、スーパーコンピューターなどを使って経路探索の計算が行われますが、近年の研究では、現実の社会実装を見据えた形で、自治体の比較的小規模な計算環境でも実装できる高度なアルゴリズム（計算手順）が期待されています。すなわち、計算機パワーまかせでの処理ではなく、数理的な処理の改善にも大きな期待が寄せられているのです。

数理的なアルゴリズム（計算手順）の改善は、なにか使いやすいソフトを入れれば終わりということではなく、純粋に数理的な話であるため、数学理論などを駆使する必要があり、産学共同による開発は、避けられない分野です。このような、経路探索の処理を数理的な改善でカバーしようとする試みは、HPEの九州大学の基盤導入事例ですでに公開されています。

この九州大学の事例でもそうですが、企業側としては、そのような、数理的な改善を後押しするためのハードウェアとソフトウェアの両方を含めた使いやすい開発環境・実行環境を提供することが求められます。

例えば、代表的なグラフデータ処理用の基盤ソフトウェアとしては、Apache Spark（アパッチ・スパーク）とよばれるオープンソースソフトウェアが有名です。Apache Sparkには、グラフデータ処理のコンポーネントがあり、グラフデータ処理用のプログラムを分散並列処理する環境を提供します。Apache Sparkは、HPEが提供するスケールアウト型のビッグデータ基盤ソフトウェアの「Ezmeral Data Fabric」（通称、EDF、旧称、MapR）上で、スケールアウトさせて計算できる点も見逃せません。

また、以前にも紹介しましたが、Apache Sparkは、HPEが提供するオープンソースソフトウェア集であるEzmeral Ecosystem Packs（エズメラル・エコシステム・パック、通称、EEP）にも含まれており、EDF上に簡単にインストールできます。

さらに、EDFには、データを多重化してもつ仕組みが搭載されており、マシンが1台壊れても、他のマシンで頑張って動き続け、利用者のデータを守るのです。EDFは、大量のマシンを搭載した冷蔵庫ぐらいある大きさのラックが壊れても、別のラックのマシンにデータがあるため、それでもデータ保管庫として動き続ける仕組み（ラック・アウェアネス機能）や、遠隔地にデータをコピーする仕組みも搭載しています。EDFが提供する様々なデータを保護の仕組みを知れば、データを守るといったITにおける災害対策がどのようなものか理解できます。

ちなみに、筆者が執筆したMapRの書籍「Hadoopクラスター構築実践ガイド」でも、MapR（現、EDF）で動くApache Sparkを使って最短経路を算出するフライトデータ分析のプログラム例や実行方法、データ保護の仕組みを掲載しています。一読いただけると幸甚です。

問題は、このようなグラフデータ処理が、災害時にリアルタイムに提供できるかどうかという点です。バッチ処理で、120時間かかって結果が出ましたでは、帰宅困難者や負傷者は救えません。監視カメラ映像やIoTを絡めたリアルタイムデータを取り込み、かつ、リアルタイムでシミュレーション結果を算出する。しかも、すぐに結果を可視化して、スマホに避難経路や有益な情報を提示する。そんなシステム構想を聞くと、もう神業としか思えませんが、日本全国の自治体の真のニーズは、そこにあります。

災害発生時に、グラフデータを処理し、結果を市民に可視化し、帰宅困難経路や物資をリアルタイムに確保できる超高速計算が可能なITシステムとなると、かなりハードルの高い大きなチャンレンジに間違いありません。しかし、最近は、グラフデータ処理だけでなく、AI（人工知能）も同時に活用しようという動きが見られ、防災向けのAIも、徐々に開発が進められています。なんでもかんでもリアルタイム化が実現できるわけではありませんが、日本でも自治体における「AI防災」と呼ばれる活用事例も増えてきています。災害対策におけるITの世界では、無停止型システム、高可用性クラスタソフトウェアの活用、そして、シミュレーション計算処理による都市計画だけでなく、AI、IoT（Internet of Things：モノのインターネット）の活用も、徐々にですが、広がってきています。このように、無停止技術、最短経路の算出、リアルタイム化、AI・IoTの活用、スマホへの可視化など、まさに、日本の災害対策において、ITは、今後、ますます欠かせないものになっていくでしょう。

しかし、阪神・淡路大震災の時に、オフロードバイクで私の父が、伊丹にある祖父母の古い木造の家をすぐに確認しに行ったように、これから起こるであろう大災害が発生した時、家族の安否を会って直接確認したい、食糧や水や防寒具を届けたいと思うのは、当然のことでしょう。

大量のガレキと倒れた電柱と自家用車の渋滞で道が塞がり、バイクにも乗れず、電気もガスも水なく、津波も来ているとき、自分や家族を守るための災害対策として、ITは、どのように貢献できるのでしょうか。脱線しても大事故ににならない日本の新幹線のようなフェールセーフの仕組みや、ボーイング767のようなダメージトレランスを盛り込んだ災害対策システムは、どうすれば実現できるのでしょうか。

今一度、災害とITの在り方について、24時間寝ずに、ではなくて、寝る前に数分だけでも考えてみてください。

（執筆日：2023年3月11日）

Masazumi Koga (Twitter:  @masazumi_koga)

【構築手順書のご案内】

ビッグデータ基盤ソフトの「Ezmeral Data Fabric 7.0」の構築手順書をPDFで公開しています。是非ご活用ください。構築手順書は、こちら。