(57)【要約】【課題】大規模な地震災害が発生した場合、企業内のITシステムに被害が発生し、これにより、企業活動が復旧するまで事実上停止する事が考えられる。このため、地震による被害を最小限に食い止めるため、発生直前にデータの退避やシステムの切り替えなどを行うことが必要であるが、今のシステムではそのような対応が出来ない。【解決手段】本発明は、大規模な地震災害が発生する直前に、気象庁が新たに提供する「緊急地震速報」を利用し、ITシステムに対して被害が最小限になるような作業を地震の震動が来る前に行い、被害復旧が最短になるようなすることを目的としたシステムである。【選択図】図１
2009115625.tif 000002
【特許請求の範囲】
【請求項１】
緊急地震速報を受信する手段と、受信した緊急地震速報の情報から一定以上の震度と該当地域かどうか、あるいは、一定以上のマグニチュードと該当地域であるかどうかを判断する手段を備えたシステム。
【請求項２】
請求項１の手段において、一定以上の震度と該当地域である場合に、ITシステム、あるいは、その他の企業システムに対し、地震に対する予防的な措置が実行できる手段を持ったシステム。
【請求項３】
請求項１の手段において、一定以上の震度と該当地域である場合に、企業内の在籍管理システムや監視カメラなどから、企業内人員の状況をあらかじめ決められた端末に送信する手段を持ったシステム。
【請求項４】
請求項１の手段において、一定以上のマグニチュードと該当地域であった場合に、ITシステム、あるいは、その他の企業システムに対し、津波に対する要望的な措置が実行できる手段を持ったシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ITシステムを地震災害から保護あるいは迅速な復旧支援に関するものである。
【背景技術】
【０００２】
緊急地震速報とは、気象庁が2005年から試験運用を開始し、実用化を目指しているシステムである。このシステムは、広域に置かれた多数の地震計のネットワークを活用し、地震発生時に震央から伝搬する地震波のうち、伝搬速度は速いが大きな地震動は伴わない特長のあるP波を観測することで、その地震による各地の震度、主要な地震動（S波）が到達する大まかな地震を予測し、関係各所に防災無線、インターネットその他の手段で通知するシステムである。このシステムに関しては、特開2006-112922号公報にてすでに知られている。
【０００３】
この緊急地震速報は、すでに高速交通機関（新幹線、鉄道）や、ガスなどの公共のインフラシステムなどで応用されており、大規模な地震発生時に、速やかに対応することで災害を少なくするシステムが構築されている。また、2005年の試験運用にて、民間企業でも希望をすれば利用できるようになったため、この緊急地震速報を応用したさまざまなシステムやサービスが提案されている。例えば、主に個人向けを想定した緊急地震速報の情報を知らせる端末に関しては、特開2006-145234号公報にてすでに知られている。また、防災無線などを利用した緊急地震速報の通達なども、今後始まる予定である。
【０００４】
【特許文献１】特開2006-112922号公報
【特許文献２】特開2006-145234号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
現在のITシステムは、企業のビジネス活動に密接に関連しており、ITシステムが何らかの原因で停止すると、その企業のビジネス事態が停止してしまう状況ある。このように「企業ビジネスの生命線」となりつつあるITシステムであるが、潜在的に自然災害に弱いという問題がある。
【０００６】
日本では、さまざまな自然災害が発生するが、この中でも大規模な地震は、ひとたび発生すれば、広範囲の地域に大きなダメージを与え、復旧に長時間かかる場合がある。
【０００７】
本発明は、このような大規模な地震災害が発生する直前に、気象庁が新たに提供する「緊急地震速報」を利用し、ITシステムに対して被害が最小限に、また、被害復旧が最短になるようにすることを目的としたシステムである。
【課題を解決するための手段】
【０００８】
本システムの説明の前に、前提となる「緊急地震速報」について記載する。
【０００９】
大規模な地震の発生を予測する科学的に検証された方法は、現時点では確立されていない。しかし、気象庁が新たに提供する「緊急地震速報」は、日本全国に張り巡らされた高精度の地震観測網を使い、地震が発生したことを観測した時点で、いち早くその地震の規模や到達時間を算出し、「地震速報」としてインターネット、無線、FAX、公共放送などの手段により情報提供するものである。
【００１０】
「緊急地震速報」は、地震が起きたときに発生する二つの性質の異なる地震波を利用し、さらに地震波の伝搬速度が電気による情報伝達の速度より遅い、という性質を利用することで大規模な揺れを伝える地震波が到達する数秒〜数十秒前に、地震発生を知らせることが出来るシステムである。その原理は下記の通りである。
【００１１】
地震が起きたときに発生する地震波は、伝搬速度は速いが、地震波のエネルギー小さい（従って揺れも小さい）P波と、地震の伝搬速度は遅いが、地震波のエネルギーは大きい（従って揺れも大きく本震となる）S波の波が発生する。気象庁の「緊急地震速報」システムは、伝搬速度の速いP波を観測し、その大きさや性質などから発生した地震の大まかな規模（マグニチュード）や地震波が到来した方向などを推測し、ある一定の震度以上の地震発生があると算出された場合は、該当地域に第一報を出す。さらに詳細な推測をするために、他の観測点でもP波を観測した後、その二点の情報を比較・処理しより正確な情報として第二報を出すものである。
【００１２】
これにより、震源からの距離にも依存するが、地震波の主要な波であるS波が到達する数秒〜数十秒前に、地震発生の第一報である「緊急地震速報」が各所に伝達され、地震発生に対する予防措置がとれるようになる。
【００１３】
本システムは、気象庁から送信される「緊急地震速報」を受信し、電文の解析を行う手段と、地震が発生する直前に行うべき緊急操作の手順などの実行手段を記述・記憶させた実行内容DBを備え、「緊急地震速報」を受信した際に、電文の解析結果から適切な内容を実行することが出来る実行制御手段を備え、地震が発生し「緊急地震速報」が発令された際に、地震の揺れが予測される地域において地震に対する予防措置を実施することで、上記の課題を解決するものである。
【発明の効果】
【００１４】
本発明により、地震災害による企業内のITシステムへの被害を軽減できるため、地震災害に被災した場合でも、効率よくITシステムの継続あるいは復旧を行うことが出来る。
【発明を実施するための最良の形態】
【００１５】
以下、図面を用いて発明の詳細を説明する。
【００１６】
図１は、発明を用いた全体のシステムを表わすシステム構成例の図である。
【００１７】
本発明は、気象庁より配信される「緊急地震速報」を受信し、それを解析する「電文解析・制御」装置(1001)と、どういうときに実行をさせるのかなどのパラメータテーブルを収めている「実行内容DB」(1002)、解析後、実際にITシステムなどに対して何らかの処理を行う「実行制御」装置(1003)に大きく別れる。「電文解析・制御」装置(1001)は、コンピュータであり、装置の内部に「CPU」（1006）と「内部メモリ」（1004）を実装し、その中で「電文解析・制御プログラム」（1005）が実行される。また、「電文解析・制御」装置（1001）は、一企業、あるいは、一拠点について一台配置され、それに付属する「実行内容DB」(1002)も、一台配置される。これにつながる「実行制御」装置(1003)は、実際に実行されるITシステムの数や配置に合わせて、「電文解析・制御」装置(1001)の下に複数台接続するような形態を取ることが可能である。
【００１８】
これらのシステムで使用される各種のテーブルは、以下の通りである。
【００１９】
図４は、本発明におけるデータテーブルの構成を表わす一覧図である。
【００２０】
気象庁から送付されてくる「緊急地震情報」の電文の形式(4001)は、「予測震度」「予測地域名」「予測マグニチュード」「到達予測時刻」「震源の位置情報（緯度・経度・深さ）」によって構成される。また、実行内容DB内のデータテーブル(4002)は、「実行名」「震度」「地域」「マグニチュード」「緯度・経度」「実行ジョブ」などであり、これらを一組として、一つの実行データのセットとなっている（4003）（4004）(4005)。
【００２１】
ここでは、二つの実施例をあげる。一つは、ITシステムなどで使われているオンライン・トランザクション処理システム（以下OLTPと略）において、被害を最小限に食い止めるための実施例。二つめは、企業内の職場において、被災後の人員チェックを容易に行うための実施例である。
【００２２】
一つめのOLTPシステムの実施例は以下の通りである。
【００２３】
OLTPは、銀行のATMなどの基幹システムに使われており、間違いを起こしてはいけないだけでなくネットワークを経由した処理でありながら、実時間処理が必要なシステムである。また、大量の実行要求が短い時間に発生するだけでなく、処理がどこまで進んだかを確実に把握しておく必要がある。
【００２４】
このようなシステムのため、地震災害が発生する直前でも、それまでにやっていた業務に区切りを付ける（同期点を取る）ことと、メモリ内などに展開されているデータをどこかに記録すること。必要に応じてバックアップを取ることなどが出来れば、地震災害からの復旧も迅速に進めることが可能となる。
【００２５】
本発明にて、上記のことを実施するには、まず、あらかじめどういう条件の時に何を実行するのかを、「実行内容DB」(1002)内の各種パラメータに割当をしておく。
【００２６】
例えば、震度５強の地震が、サーバが設置されている東京・神奈川地域で発生した場合に、上記のような処理を行わせるには、図４のパラメータNo1（4003）のように設定する。
【００２７】
この実施例では、実際に作業を行う部分は、「ジョブ実行」あるいは「バッチ処理」、「ファイル実行」の形で登録するようにしている。どの方式も、実際に実行する装置を呼び出して、作業の実行を行うことになる。
【００２８】
「ジョブ実行」とは、ITシステムの運用管理製品の分野に存在する、一定の手続きを自動的に行うための「ジョブ管理ソフトウェア」に登録してある、手続きを記したものを（ジョブスクリプトなどと呼ぶ場合もある）を実行することを指す。
【００２９】
「バッチ処理」とは、ある実行手続きを書いたテキスト文書を元に、UNIX（登録商標）などのOSが持っているシェル上で、その実行手続きを書かれている順番に行わせて、一連の処理を行うものを指す。
【００３０】
「ファイル実行」は、その名の通り、実行可能形式などのファイルを、直接実行させ、一連の作業を行う方式を指す。
【００３１】
OLTPシステムの実施例では、「ジョブ実行」方式を例に挙げる。
【００３２】
図５は、本発明の共通部分に関する動作を表わすフローチャートである。
【００３３】
地震発生が、気象庁のどこかの地震計で感知されると、直ちにその情報を解析し「緊急地震速報」を作成し、インターネットなどの電子データとして送出する。本システムはこの電文データが受信されたところから始まる(5001)。
【００３４】
データが受信されると、「電文解析・制御」装置(1001)は、以下の方法で何を行うべきなのかの電文の解析を開始する（5002）。まず、「実行内容DB」(1002)から、パラメータのテーブル一行分を読み込む(5003)。読み込んだパラメータ(4003)の中から、まず、設定されている「マグニチュード」のデータの欄を見て、ここに何らかのパラメータが入っているか、入っていない（NULL）なのかを判別する(5004)。この理由は以下の通りである。
【００３５】
地震によって想定される災害は、地震の揺れによるものと、地震によって引き起こされる津波によるものと二種類ある。地震の揺れによって発生する災害は、「緊急地震速報」のデータのうち、予測震度と予測地域を見ることによって、どこでどれぐらいの揺れが発生するのかを把握することが出来る。しかし、津波に関してはこれらのデータでは分からない。津波に関しては、気象庁から発令される「津波警報・注意報」を待つことも出来るが、日本で発生する地震の場合、経験的に震源が海域にあり、かつ、マグニチュードがそれなりに大きい（おおむねＭ６〜Ｍ６.５以上）であれば、津波の発生の可能性が高くなることが知られている。
【００３６】
ITシステムは、津波による被害よりも地震動によって発生する被害を受ける可能性が大きいと思われるが、企業によっては津波に対する防災策を緊急に講じる必要がある場合もあると考えられる。今回の実施例では、津波による被害を事前に小さくする方法については記していないが、本発明を使用する場合に、津波についても考慮する場合もあると考え、あえて判定できるような方式を入れている。
【００３７】
マグニチュードのパラメータが「実行内容DB」(1002)から取りだしたパラメータ(4005)に存在する場合は、次に予測マグニチュードと設定されているマグニチュードを比較する(5005)。予測マグニチュードが設定マグニチュード以上だった場合は、次に震源の位置情報（緯度、経度）が、設定されている位置情報（4005）の中にあるのかどうかを判別する(5006)。設定されている位置情報は、例えば３点あるいは４点の緯度・経度を指定し、これらの点で囲まれた範囲内に、発生した地震の震源が入るかどうかを判定するなどの形で判別を行う。この二つの判別が、両方ともYesの場合は、設定されているパラメータの「実行ジョブ（「警告.exe」（4005））」に書かれているものを実行する(5007)。一つでもNoがある場合は、今回は特に何もやる必要がないものとして何も実行しない。
【００３８】
次に「実行内容DB」(1002)のテーブルを全部読んだかどうかを判断し(5010)、読んでいなければ読み込むところに戻り(5003)、次のテーブルの読み込み作業を続行する。読み込みが終わっているならば、作業を終了し(5011)、緊急地震速報の受信体制に戻る。
【００３９】
マグニチュードのパラメータが入っていない(4003、4004)場合（5004)、次に「緊急地震速報」の予測震度と設定震度の比較をし(5008)、予測震度が設定震度以上であった場合は、次に予測地域と設定地域の比較をする(5009)設定地域が予測地域に含まれている場合は、設定されている実行ジョブを実行する(5007)。設定震度が越えてない場合や、設定地域が含まれていない場合は、実行内容DB内(1002)に次の行があるかチェックし(5010)、実行内容DB(1002)にまだデーブルがある場合は、テーブルの読み込みに(50033)にもどり、無い場合は次の「緊急地震速報」が届くまで受信待機状態となる(5010)。
【００４０】
以上が、「電文解析・制御」装置（1001）部分で行われる内容である。
【００４１】
「電文解析・制御」装置（1001）にて、何らかの実行をする指示が出た場合、その指示内容に応じて適切な「実行制御」（1003）が起動される。この「実行制御」（1003）は、論理的には「電文解析・制御プログラム」（1005）とは、別のプログラムであるが、ITシステムの構成によっては、「電文解析・制御プログラム」（1005）と物理的に同じサーバ上に存在する事も可能である。この「実行制御」（1003）部分は、「ジョブ実行」「バッチ制御」「ファイルの実行」などのパターンがあり、どのパターンを取るのかは、実際に使用されているITシステムの構成などによって決められる。
【００４２】
実施例１の場合は、以下のようになる。
【００４３】
図２は、「実施例１」の全体システムの構成図を表したものである。
【００４４】
システムの構成は以下の通りである。
【００４５】
実施例１で想定している業務は、「業務サーバ」（2005）によって実行されている。業務サーバには、実際のOLTP業務を実行している「業務AP」（2007）がインストールされ、業務を実行している。また、この業務に必要なデータ類は、「業務DB」（2006）に入れられ、業務の実行により随時更新が行われている。
【００４６】
このシステムは、バックアップサーバ（2001）により、定期的に「業務DB」（2006）をバックアップしている。バックアップは、バックアップを管理する「バックアップマネージャ」（2003）と、「バックアップマネージャ」（2003）から制御され、バックアップを実行する「バックアップエージェント」（2008）により構成されている。また、バックアップされたデータは、媒体（2004）に保存される。媒体は、テープ、光磁気ディスク、ハードディスクなど、さまざまなものが使われる想定である。
【００４７】
「緊急地震速報」を受信した時に行う作業は、「実行制御」（1003）から出された指示に基づき、「エージェント」（2002、2009）が行う。「エージェント」（2002）は、バックアップに関する指示を受け取り、「バックアップマネージャ」（2003）にバックアップの指示を与える。また、「エージェント」（2009）は、バックアップの指示を受け、「業務AP」（2007）に対して、バックアップに必要な動作を行うように指示を出す。図６は、本発明の「実施例１」のフローチャートを表したものである。
【００４８】
「電文解析・制御」装置（1001）から指示が来た「実行制御」（1003）は、あらかじめ設定されているジョブ（「JOB_OLTP」（4003））を実行させる（6001）ことによって、以下の手順を開始する。
【００４９】
まず、「実行制御」（1003）から、業務サーバ（2005）のエージェント（2009）に、OLTP同期点を設定するよう指示を出す（6002）。この同期点は、地震によってシステムが停止し、それを復旧したときの復旧ポイントとなる。次に、同期点までに処理したデータで、物理的なHDなどにデータを記録する（6003）。その後、バックアップマネージャ（2003）の指示により、バックアップエージェント（2008）を起動。バックアップのためのテープやHDDなどの媒体（2004）にバックアップを開始する（6004）。ただし、全体をバックアップするのでは短時間で終わらないため、差分バックアップなどの方式を実施するか、あるいは、本当に重要なデータのみをバックアップするような形で実施することも考えられる。
【００５０】
これらの手順を実行した後に、「実行制御」（1003）は、地震波が到達する予測時間＋α（これは、地震による揺れが終わると予想される程度の待ち時間（おおむね３分程度）を設定し、設定した時間まで待ち（6005）、その時間が経過した後に、該当するOPTPシステムの正常動作が続いているかどうかチェックする（6005）。これは、地震の揺れが予測値よりも小さい場合、あるいは、大きな地震動が来たが、ITシステムには被害が発生せず耐えた場合、OLTPシステムの実行をそのまま継続させるための配慮である。もし、問題なく稼働していると判断した場合は、設定した同期点の解除などを行い、通常の運用に戻すための処理を行い（6006）、終了とする（6007）。問題があった場合、あるいは、そもそも反応しない場合などは、そのまま終了とする（6007）。
【００５１】
次に、二つめの実施例として、企業内の職場において、被災後の人員チェックを容易に行う場合の例をあげる。
【００５２】
図３は、実施例２の全体システム構成図を表したものである。
【００５３】
実施例２は、従業員の在籍管理などを目的としたシステムの例である。
【００５４】
「拠点システム」（3001）は、「緊急地震速報」が受信され、実施例２を行う「実行制御」（1003）が起動された後、「実行制御」（1003）からの指示を受け、一連の作業を制御するシステムである。
【００５５】
「在籍管理システム」（3003）は、従業員の在籍を電子的な手段で管理するシステムである。詳細は後述する。また、「従業員DB」（3005）は、この「在籍管理システム」（3003）によって得られた在籍情報などのデータを補完するデータベースである。
【００５６】
「職場設置のカメラ」（3004）は、職場内に設置されたカメラである。詳細は、後述する。
【００５７】
「遠隔地の拠点など」（3002）は、実施例２において、管理している職場とは、物理的に距離があり、実施例２で想定している地震による被害が及ばない場所、あるいは、及ばない場所の人が所有している受信システムを指す。図７は、実施例２のフローチャートを表したものである。
【００５８】
この実施例２の場合でも、「電文解析・制御」装置（1001）のロジックは、実施例１と同じなので割愛する。以下は、「実行制御」（1003）が呼び出された後の実施例である。
【００５９】
「実行制御」（1003）にて、指定されたバッチファイル（「チェック.bat」（4004））を実行する（7001）。その後、そのバッチファイルの手続きに従って処理が進む。実施例２では、企業内に「在籍管理システム」（3003）が設置されており、さらに職場内の様子が分かるカメラ（3004）が設置されていることを前提とする。「在籍管理システム」（3003）は、フリーレイアウトのオフィスなどを対象に、誰が現在在籍していて、どこに座っているのかなどの在籍情報をリアルタイムに表示するために使われ始めたシステムである。「在籍管理システム」（3003）の実現方法はいろいろあるが、ここでは、従業員に一人一台配られているPCの使用状況と、使用場所を電子的に調べることで、その従業員が在籍しているかどうか、どこに座っているかどうかをチェックするシステムである。実施例２では、このシステムを使用することで、地震が発生する直前に、職場内に誰がどのあたりにいたのか、いなかったのかなどを把握するために使用する。また、職場内の様子が分かるカメラ（3004）は、通常時は防犯カメラとして設置され、必要なときのみ（通常時は、全員が退勤した後など）使用されるものを流用することを想定し、地震発生直前の職場内の状況を知る手がかりの一つとして使用する。
【００６０】
バッチファイル始動後、まず、「在籍管理システム」（3003）にアクセスして、現在在籍している従業員の一覧を収集する（7002）。次いで、このデータを指定された宛先に、このデータを送信する（7003）。宛先としては、例えば、離れたところにある別の事業所の防災担当者のメールアドレスや、同じ事業所の防災担当者の携帯電話のアドレスなどに送信する事が考えられる。これにより、被災後の人員確認が、迅速に出来るようになる。
【００６１】
ついで、職場に設置されたカメラ（3004）を起動し（7004）、職場内の画像の録画（あるいは撮影）を行う（7005）。この画像データも、上記にあげた宛先に送信する（7006）。目的は、実際に誰がいたのかを、被災直前の該当職場の状況はどのような状態であったのかを、画像から判定するためである。また、録画データをストリーミング技術を使い、別の事業所の防災担当者のところに送信することも考えられる。これにより、実際に地震の揺れによってどの程度の被害が出たのかを把握し、被災後の救助・復旧などを迅速に行うことが可能となる。
【００６２】
以上の手順を行った後、バッチファイルは終了となり（7007）、実行制御システムも停止する。
【００６３】
以上、実施例を二つあげたが、基本的には「電文解析・制御」装置（1001）までの流れは共通で、その後の実際の「実行制御」(1003)の部分は、個々のシステムによって使用者が設定をすることが前提となる。これは、システムによって地震に対する対応方法が違うためである。
【００６４】
また、「実行制御」（1003）は、数秒以内に実行できて実効性があるものを設定する必要がある。「緊急地震速報」によって地震の揺れの発生が予測できるとはいえ、実際には数秒〜数十秒しか余裕がない。この間に実効性があるものは何かを考えて、設定することは、個々のシステム運用管理者が設定することになる。今回の実施例ではあげていないが、この他に、クラスタシステムをすでに構成し、遠隔地にサブシステムをおいている企業の場合、メインとサブのシステムの切り替えとデータの引き渡しを行うとか、バックアップシステムなどの場合は、バックアップシステムの立ち上げを行うなどの対応も考えられる。現在の企業のITシステムにおいては、緊急時の対策を考えてシステムを構築しているものも多い。この場合は、この対策の中で短時間に実効性が上がるものに焦点を絞り、本発明の中の「実行制御」（1003）の一つとして、組み込む事が考えられる。
【００６５】
また、直下型地震の場合、「緊急地震速報」の性格上、速報が届く前、あるいは届くとほぼ同時に地震動が発生する場合もある。この点も本発明では救うことの出来ない部分である。
【００６６】
なお、前述したとおり、実施例にはあげていないが、発生した地震のマグニチュードと、震源の位置によって津波発生の危険性を判断させることも可能である。実際の企業システムなどにおいては、津波による被害を想定することは難しいが、例えば、海沿いにある事業所の場合、防潮堤を閉めるとか、海岸沿いにいる従業員に避難指示を出すなどにより、実際に津波が発生した場合の被害を最小限に食い止める事が出来ると思われる。
【図面の簡単な説明】
【００６７】
【図１】全体システム構成図。
【図２】実施例１の全体システム構成図。
【図３】実施例２の全体システム構成図。
【図４】本発明におけるデータテーブル一覧。
【図５】本発明のフローチャート（共通部分）。
【図６】本発明のフローチャート（実施例１）。
【図７】本発明のフローチャート（実施例２）。
【符号の説明】
【００６８】
CPU…Central Processing Unit、DB…Data Base、OLTP…OnLine Transaction Processing、緊急地震速報…気象庁より、地震発生時に地震波の到達時間と大きさを速報するもの、マグニチュード…Magnitude。地震が発生させるエネルギーを表す。
【図１】
2009115625.tif 000003
【図２】
2009115625.tif 000004
【図３】
2009115625.tif 000005
【図４】
2009115625.tif 000006
【図５】
2009115625.tif 000007
【図６】
2009115625.tif 000008
【図７】
2009115625.tif 000009