(57)【要約】【課題】緊急時または防災訓練時における電子データを用いた通報連絡が、送信者の意図に照らし合わせ正確に伝達され、かつ通報連絡が正確に伝達されたことを監視および確認する。【解決手段】本発明に係る緊急時通報連絡確認システムおよびその確認方法は、電子データを用いた通報連絡を作成する通報連絡作成手段１と、通報連絡作成手段１により作成された通報連絡に、所定の役割分類および役割分類に対応する通報連絡の送受信者の状態を付与する役割分類付与手段１と、通報連絡作成手段１により作成された通報連絡の送受信を行う通報連絡手段３と、通報連絡手段３により送受信された通報連絡の履歴を電子情報として保存する通報連絡保存手段５と、通報連絡保存手段５に保存された電子情報から、通報連絡の送受信状況を監視および確認する監視確認手段３とを備えたことを特徴とするものである。【選択図】  図１
2009100147.tif 000002
【特許請求の範囲】
【請求項１】
緊急時または防災訓練時において電子データを用いて通報連絡を行う緊急時通報連絡確認システムにおいて、
電子データを用いた通報連絡を作成する通報連絡作成手段と、
前記通報連絡作成手段により作成された通報連絡に、所定の役割分類および前記役割分類に対応する通報連絡の送受信者の状態を付与する役割分類付与手段と、
前記通報連絡作成手段により作成された通報連絡の送受信を行う通報連絡手段と、
前記通報連絡手段により送受信された通報連絡の履歴を電子情報として保存する通報連絡保存手段と、
前記通報連絡保存手段に保存された電子情報から、通報連絡の送受信状況を監視および確認する監視確認手段とを備えたことを特徴とする緊急時通報連絡確認システム。
【請求項２】
前記役割分類付与手段は、作成された前記通報連絡の内容から前記役割分類を判定し、判定した前記役割分類を通報連絡に付与することを特徴とする請求項１記載の緊急時通報連絡確認システム。
【請求項３】
前記役割分類付与手段は、作成された前記通報連絡に付されたタイトルから前記役割分類を判定するものであって、
前記通報連絡に付されたタイトルを形態素に分割し、前記形態素の重要度と、形態素の配置順位の少なくとも一つから判定することを特徴とする請求項２記載の緊急時通報連絡確認システム。
【請求項４】
前記通報連絡作成手段により作成される前記通報連絡は、データベースに格納された入力テンプレートであって、前記通報連絡の役割分類が予め付与された入力テンプレートに入力することにより作成されることを特徴とする請求項１記載の緊急時通報連絡確認システム。
【請求項５】
前記入力テンプレートは、前記通報連絡の重要度、送信先、代替送信先、前記通報連絡が行われてから遅滞の警告を行うまでの所定時間などの通報連絡の属性情報と共に前記データベースに格納されていることを特徴とする請求項４記載の緊急時通報連絡確認システム。
【請求項６】
前記入力テンプレートと共に前記データベースに格納された通報連絡の属性情報は、任意に変更可能であることを特徴とする請求項５記載の緊急時通報連絡確認システム。
【請求項７】
前記監視確認手段は、
前記通報連絡保存手段に保存された電子情報である通報連絡の履歴に基づいて、少なくとも前記通報連絡に付与された役割分類に対応する状態が時系列の表形式で表示された監視表を出力する出力手段と、
前記出力手段で出力された監視表を閲覧可能とする閲覧手段とをさらに備えたことを特徴とする請求項１記載の緊急時通報連絡確認システム。
【請求項８】
前記監視確認手段は、前記通報連絡が行われてから任意の時間を起点として経過時間を計測し、一定時間経過後に前記通報連絡に基づく所定の処理が行われない場合、遅滞の警告を行う警告手段をさらに備えたことを特徴とする請求項１記載の緊急時通報連絡確認システム。
【請求項９】
前記警告手段により行われる警告は、前記出力手段により出力された監視表に表示された遅延を生じている状態である欄を所定の表示方法で表示すること、および警告音を発することのうち少なくとも一方により行われることを特徴とする請求項８記載の緊急時通報連絡確認システム。
【請求項１０】
前記警告手段により遅滞の警告が行われた場合、遅滞の原因に対し前記通報連絡に対する所定の処理を督促する督促手段をさらに備えたことを特徴とする請求項８記載の緊急時通報連絡確認システム。
【請求項１１】
前記通報連絡の送受信を行う通報連絡手段は、
前記通報連絡の受信側において前記通報連絡を受信できない場合に、予め設定された代替の受信先に通報連絡を送信する手段をさらに備えたことを特徴とする請求項１記載の緊急時通報連絡システム。
【請求項１２】
前記通報連絡が、誤った送信先に送信された場合、前記通報連絡は誤りである旨を判別し、前記通報連絡の送信者に対し自動的に通知を送信する手段をさらに設けたことを特徴とする請求項１記載の緊急時通報連絡確認システム。
【請求項１３】
前記通報連絡保存手段に保存された電子情報は、
防災訓練の評価やシミュレートに利用可能なシミュレート手段を備えたことを特徴とする請求項１記載の緊急時通報連絡確認システム。
【請求項１４】
緊急時または防災訓練時において電子データを用いて通報連絡を行う緊急時通報連絡確認方法において、
電子データを用いて通報連絡を作成する通報連絡作成ステップと、
前記通報連絡作成ステップで作成された通報連絡に、所定の役割分類および前記役割分類に対応する通報連絡の送受信者の状態を付与する役割分類付与ステップと、
前記通報連絡作成ステップで作成された通報連絡の送受信を行う通報連絡ステップと、
前記通報連絡ステップにより送受信された通報連絡の履歴を電子情報として保存する通報連絡保存ステップと、
前記通報連絡保存ステップで保存された電子情報から、通報連絡の送受信状況を確認および監視する状況確認ステップとを備えることを特徴とする緊急時通報連絡確認方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、緊急時または防災訓練時において電子データを用いて通報連絡を行う緊急時通報連絡確認技術に係り、特に通報連絡が送信者の意図に照らし合わせ正確に伝達され、かつ通報連絡が正確に伝達されたことを監視および確認することが可能な緊急通報連絡確認システムおよびその確認方法に関する。
【背景技術】
【０００２】
災害時に使用する通信連絡手段には、従来から電話やファクシミリなどが用いられている。また、防災訓練時でも、電話やファクシミリなどの通報連絡手段が数多く用いられている。
【０００３】
しかし、昨今、インターネットや携帯電話などを中心に新しい通信手段が出現・普及し、これら通信手段はライフラインの一部となり、情報インフラにとって不可欠となった。
【０００４】
このように、インターネットや携帯電話が情報インフラにとって不可欠な通信手段になっているにもかかわらず、いまだ慣行的に用いられず、むしろ電話やファクシミリなどが多用されているのは、災害の情報が多様になっているのに通信内容がいまだ定型化されたままになっていたり、従来の通信手段を用いることへの慣れや、固執であったり、あるいは新しい通信手段へ乗り換えることへの躊躇などが主な理由として考えられている。
【０００５】
このように、情報インフラの発達、多様化の中で、防災対応に関する情報・通信手段の発明が数多く提案されている。
【０００６】
例えば、多種類の通信手段として、通信衛星、専用線、気象衛星、文字放送、中波ラジオ、インターネットの中から複数を組み合わせることにより、伝達の確実性を確保する緊急防災情報伝達方式が提案されている（例えば特許文献１）。
【０００７】
また、電話やファクシミリなどの通信手段を改善したものとして、インターネットを利用してファクシミリを送信する場合、ｐｉｎｇにより応答の有無を確認し、確実に送信できる相手を選択してファクシミリを送信するインターネットファクシミリ（例えば特許文献２）などが提案されている。
【０００８】
さらに、電子メールを利用したシステムに関するものとして、警察などへの緊急通報を専用のサーバを設置して、電子メールを用いて緊急通報と通報確認を行う緊急通報方法およびそのセンター装置（例えば特許文献３）などが提案されている。
【０００９】
またさらに、緊急通報連絡時の中心的な機能を持たせたものとして、組織的に対策を行う必要のある緊急性対策事象、例えば災害、防犯、事故などに対する対策指示者が不在となることで生じる混乱を上位指示者へ通報して、回避するための対策指示者不在回避システム（例えば特許文献４）などが提案されている。
【００１０】
一方、防災訓練に関するシステムについては、サーバが訓練シナリオを作成して、ネットワークを介してこのシナリオを配信して訓練を行い、訓練行動を収集して評価し、新たな訓練にフィードバックする訓練システム（例えば特許文献５）などが提案されている。
【００１１】
このような従来提案された技術については、災害時における通報連絡手段として、新たな情報インフラを単に利用するという類のものが多かった。
【００１２】
これに対し、電子メールなどの電子媒体情報を扱うことにより、サーバに保存されたデジタルデータを用いて、通報連絡の履歴を監視したり、メールの返信機能により受信確認状況を監視する災害通報連絡方法などが提案されている（例えば特許文献６および特許文献７）。
【特許文献１】特開２００１−７６２６７号公報
【特許文献２】特開２０００−２５１１７４号公報
【特許文献３】特開２００２−３００３１８号公報
【特許文献４】特開２００２−１６２８９３号公報
【特許文献５】特開２００３−１８７０６４号公報
【特許文献６】特開２００６−３１４７０号公報
【特許文献７】特開２００６−７４１９８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
災害時、あるいは防災訓練時などの緊急時の通報連絡には、正確さや明瞭さなどの内容と質と迅速性が要求される。しかし通報の内容が適切であっても、通報連絡先で内容が正しく把握されなければ、通報連絡としての機能を果たしているとはいえない。
【００１４】
しかし、従来の緊急時通報連絡確認方法では、通報後にさらに通報が正しく受信されたかの確認を電話で確認するなどの冗長な確認方法がとられており、有効な緊急時の通報連絡およびその監視・確認方法は提案されていなかった。
【００１５】
本発明はこのような事情を考慮してなされたもので、災害時や交通機関の事故時などのような緊急時、あるいは緊急時を想定した訓練時において、関係者間の通報連絡が送信者の意図に照らし合わせ正確に伝達され、かつ通報連絡が正確に伝達されたことを監視および確認することが可能な緊急時通報連絡確認システムおよびその確認方法を提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明に係る緊急時通報連絡確認システムは、上述した課題を解決するために、電子データを用いた通報連絡を作成する通報連絡作成手段と、前記通報連絡作成手段により作成された通報連絡に、所定の役割分類および前記役割分類に対応する通報連絡の送受信者の状態を付与する役割分類付与手段と、前記通報連絡作成手段により作成された通報連絡の送受信を行う通報連絡手段と、前記通報連絡手段により送受信された通報連絡の履歴を電子情報として保存する通報連絡保存手段と、前記通報連絡保存手段に保存された電子情報から、通報連絡の送受信状況を監視および確認する監視確認手段とを備えたことを特徴とする。
【００１７】
また、本発明に係る緊急時通報連絡確認方法は、上述した課題を解決するために、電子データを用いて通報連絡を作成する通報連絡作成ステップと、前記通報連絡作成ステップで作成された通報連絡に、所定の役割分類および前記役割分類に対応する通報連絡の送受信者の状態を付与する役割分類付与ステップと、前記通報連絡作成ステップで作成された通報連絡の送受信を行う通報連絡ステップと、前記通報連絡ステップにより送受信された通報連絡の履歴を電子情報として保存する通報連絡保存ステップと、前記通報連絡保存ステップで保存された電子情報から、通報連絡の送受信状況を確認および監視する状況確認ステップとを備えることを特徴とする。
【発明の効果】
【００１８】
本発明に係る緊急時通報連絡確認システムおよびその確認方法においては、緊急時または防災訓練時における電子データを用いた通報連絡が、送信者の意図に照らし合わせ正確に伝達され、かつ通報連絡が正確に伝達されたことを監視および確認することができる。
【発明を実施するための最良の形態】
【００１９】
本発明に係る緊急時通報連絡確認システムおよびその確認方法の実施形態について、添付図面を参照して説明する。
【００２０】
［第１の実施形態］
本発明に係る緊急時通報連絡確認システムおよびその確認方法は、災害時や交通機関の事故発生時のような緊急時あるいは緊急時を想定した訓練時に、関係者および関係組織での通報連絡およびこの通報連絡の確認や監視を行う場合に適用される。また、関係者および関係組織は、例えば事業者、関係省庁および自治体ならびにこれらの従事者などが該当する。
【００２１】
図１は、本実施形態における緊急時通報連絡確認システムの一例である構成図である。
【００２２】
この緊急時連絡確認システムは、関係者および関係組織に備えられた計算機１と、この計算機１と電気通信回線２で接続された電子メールサーバ３とからなる。この通報連絡手段としての電子メールサーバ３および電気通信回線２は、既存のものであってもよく、また災害通報用の専用サーバおよび回線で構成してもよい。
【００２３】
計算機１は、通報連絡の作成、通報連絡に対する役割分類の付与などを行う機能を備えている。また、計算機１にはそれぞれデータベース４が備えられており、通報連絡の作成時に使用する入力テンプレートやグループ化された各種役割分類に関する情報が格納されている。
【００２４】
電子メールサーバ３は、各計算機１と電気通信回線２で接続されており、各計算機間で行われる通報連絡の送受信を行う機能を備える。また、電子メールサーバ３には通報連絡の内容や履歴などを保存し統一管理を行うサーバデータベース５が設けられている。
【００２５】
通報連絡は電子メールなどの電子データにより電気通信回線２を通じて電子メールサーバ３を介して行われ、この通報連絡には計算機１により役割分類が付与される。通報連絡に役割分類を付与するのは、通報連絡の送受信を行う関係者および関係組織間において、通報連絡の内容や通報連絡の遅滞情報などの監視および確認の容易化を図るためである。
【００２６】
通報連絡に付与される役割分類は、通報連絡の送信者によって恣意的に設定されてしまうことがあり、必ずしも通報連絡の情報を共有する関係者および関係組織間で共通した認識が得られない場合が想定される。このような場合、送受信者間の通報連絡の内容に対する認識の相違から、例えば本来は受信者からの回答が必要な通報連絡に対しても、回答がなされない恐れがある。
【００２７】
このような事態を回避するため、予め通報連絡に対し送受信者間で共通した役割分類を設定することが有効である。また、通報連絡に役割分類を付与することは、通報連絡を行う関係者および関係組織間において、受信した通報連絡の内容や、通報連絡の遅滞情報などの監視および確認の容易化を図ることができる。
【００２８】
図２は、通報連絡の送受信者である関係組織および関係者に付与される役割分類の一例を示したものである。なお、この役割分類は一例であって、この６分類に限らず他の分類も考えることができる。
【００２９】
図２における矢印の左側は送信者および送信者が通報連絡を送信したことにより発生した状態の名称、矢印の右側は受信者および受信者が通報連絡を受信したことにより発生した状態の名称を表している。また、矢印上は、通報連絡を行うことにより付与された役割分類を示している。
【００３０】
１の通報連絡に対し付与された役割分類である「指示」について説明する。
【００３１】
「指示」という役割分類は、送信者Ａ１が受信者Ｂ１に対し何らかの指示を行う通報連絡に対して付与される役割分類である。この「指示」の通報連絡が行われることにより、送信者Ａ１には通報連絡の指示を履行させる責任が発生する。これに対し受信者Ｂ１には、指示を履行する義務が発生する。
【００３２】
一方、２の通報連絡に対し付与された役割分類である「報告」は、「指示」と相反する役割分類であり、「指示」の通報連絡の受信者Ｂ１が指示を履行した後に、「指示」の送信者Ａ１に対して行う通報連絡に付与される。「指示」の通報連絡により受信者Ｂ１に発生した義務の解消は、指示を履行した「報告」である通報連絡によりなされる。同様に、「指示」の通報連絡により発生した送信者Ａ１の責任の解消は、「報告」の送信者Ｂ１による通報連絡を受けたことによりなされる。
【００３３】
ここで、「指示」の通報連絡を受けたことにより受信者Ｂ１に発生した義務は、指示の履行を行うまでは解消されない。この義務を解消するためには、「指示」の送信者Ａ１に対して、指示を履行した旨の「報告」の通報連絡が必須である。これに対し、「指示」の通報連絡により送信者Ａ１に発生した責任の解消は、自発的な行為は必要なく、受信者Ｂ１からの報告が必須である。
【００３４】
次に、３の通報連絡に対し付与された役割分類である「申請」について説明する。
【００３５】
「申請」という役割分類は、申請者である送信者Ａ２が何らかのタスクの実行権限を持っていないため、許可の申請を行う通報連絡に対して付与される役割分類であり、その実行許可の権限者である受信者Ｂ２に対しなされるものである。この「申請」の通報連絡が行われることにより、受信者Ｂ２には送信者Ａ２に対する許可を行う権限が発生する。これに対し送信者Ａ２には、権限者である受信者Ｂ２の許可を待つ必要があるため、停止（一時停止）という状態が発生する。
【００３６】
一方、４の通報連絡に対し付与される役割分類である「許可」は、「申請」と相反する役割分類であり、「許可」の送信者Ｂ２が有する権限をもとに、「申請」の送信者Ａ２に対して行われる通報連絡に付与される。「申請」の受信者Ｂ２に発生した権限の解消は、「申請」の送信者Ａ２への「許可」である通報連絡を行うことによりなされる。同様に、「申請」の通報連絡により送信者Ａ２に発生した停止は、「許可」の通報連絡を受けたことにより解消される。
【００３７】
なお、送信者Ａ２が権限者である受信者Ｂ２に対し「申請」の通報連絡を行うと、権限者の許可が必要であるタスクは停止されるが、これとは別に課されているタスクの並行実施は可能である。
【００３８】
次に、５の通報連絡に対し付与された役割分類である「質問」について説明する。
【００３９】
「質問」という役割分類は、送信者Ａ３が何らかのタスクを実行するに際して必要な知識が不足し、それを補う必要がある場合に行う通報連絡に対して付与される役割分類であり、その必要な知識を有する受信者Ｂ３に対してなされるものである。この「質問」の通報連絡が行われることは、送信者Ａ３は必要である知識を有していない無知な状態であり、受信者Ｂ３は知識を有している状態であることを示している。
【００４０】
一方、６の通報連絡に対し付与された役割分類である「回答」は、「質問」と相反する役割分類であり、知識を有する送信者Ｂ３が無知である受信者Ａ３に対し行う通報連絡に付与される役割分類である。送信者Ｂ３により「回答」の通報連絡が行われることにより、無知である「質問」の送信者Ａ３の知識が充足され、無知の状態が解消される。
【００４１】
また、「質問」の送信者Ａ３が得ようとしている知識には、その知識がタスクの実行に必要不可欠な場合と、タスクの実行には必ずしも必要ではないが、あれば有用である知識とに分類される。前者の場合には、その知識が得られない場合には質問者のタスクは停止（一時停止）の状態となる。
【００４２】
このような役割分類、および通報連絡の送受信者の状態は、役割分類付与手段としての計算機１により通報連絡の作成時に予め付与される。計算機１は、通報連絡の内容に応じて役割分類毎にグループ分けを行い、これらのグループに対応した「指示」、「報告」、「申請」、「許可」、「質問」、「回答」などの役割分類を付与する。
【００４３】
図３は、内容に応じて通報連絡のグループ分けを行い、対応する役割分類に関連付けが行われる概念図を示したものである。通報連絡の内容と役割分類とが関連付けされたデータは、計算機１に備えられたデータベース４に格納されており、例えば通報連絡の作成時などには、通報連絡の内容に対応した役割分類がデータベース４から読み出され、随時参照できるようになっている。
【００４４】
通報連絡作成手段としての計算機１には、通報様式の入力テンプレートが予めデータベース４に格納されており、緊急時である通報連絡時には入力テンプレートの必要事項のみを埋めてやればよく、迅速かつ正確に送信先に通報連絡を行うことができる。また、この入力テンプレートには、通報連絡の内容に応じて通報連絡に付与された役割分類および役割分類に対応する通報連絡の送受信者の状態が予め付与されている。
【００４５】
例えば、図４（ａ）に示すように、通報連絡の入力テンプレートの一覧を、通報名称１０、予め付与された役割分類１１および通報の重要度１２を表形式で出力可能なようにデータベース４に登録しておく。また、一の通報名称１０がさらにグループ化されている場合には、図４（ｂ）に示すように、プルダウンメニュー１３から選択可能なように出力される。通報名称１０のグループ化は、例えば、通報様式が同様であっても送信先が異なる場合などに行われる。
【００４６】
また、通報連絡に予め付与された役割分類は、通報連絡の作成時、図５に示すように、データベース４に格納された通報連絡の役割分類をプルダウンメニュー１５で表示し、この中から選択することで任意に変更が可能である。役割分類の変更に伴い、通報連絡の送受信者の状態も連動して変更されるようになっている。
【００４７】
ここで、通報様式の入力テンプレートは、通報連絡を行う際に必要な属性情報と共にデータベース４に格納されている。属性情報は、例えば、通報連絡の送信先、代替者の設定の要否、遅滞警告を行うまでの一定時間（警告時間）のデフォルト設定値といった情報である。これらの属性情報も入力テンプレートと併せてデータベース４に格納しておくことで、通報連絡の監視をより厳格に行うことができる。
【００４８】
図６は通報連絡の送信先の表示例であり、電子メールによる通報連絡の主たる受信者（ＴＯ：）２０、および確認のために同一の通報連絡が送信される参照者としての受信者（ＣＣ：）２１が表示されている。通報連絡の作成時に入力テンプレートに予め通報連絡先が入力されるようにすることで、入力操作の簡易化を図ることができる。
【００４９】
また、これらの受信者の電子メールアドレスのみならず、詳細情報２２として、電話あるいはファックス番号、ＵＲＬや、代替送信先（図示せず）なども同様にデータベース４に格納されている。これにより、電子メールが通信障害などで正常に送受信できない場合などに、電話やファックスなどの他の連絡手段で通報連絡を行うことができる。
【００５０】
また、属性情報には、通報連絡の受信者の権限の有無に関する情報を与えておくこともできる。これにより、例えば図６（ｂ）に示す詳細情報２３のように、データベース４より送信先を参照した場合に、送信に権限があるか否かが表示されるようになっている。このため、権限を有していない非権限者に対して、誤って「許可」の通報連絡を送信するような事態を回避することができる。
【００５１】
なお、入力テンプレートと共にデータベース４に格納されたこれらの属性情報は、通報連絡の作成時などにおいて適宜変更や参照が可能である。
【００５２】
一方、通報連絡の内容を作成する際に、データベース４に格納された入力テンプレートを使用しないことで、通報連絡に予め役割分類が付与されない場合には、通報連絡に役割分類を付与する必要がある。
【００５３】
このような場合、例えば電子メールを用いた通報連絡の作成時に、役割分類付与手段としての計算機１が通報連絡に付されたタイトルを読み取り、データベース４に格納された通報連絡の内容と役割分類とが関連付けされたデータを参照し、これを元に判定を行い役割分類の付与することができる。
【００５４】
具体的には、通報連絡のタイトルに、図３のグループＡに分類されるような「指示」、「召集」、「確認」、「要求」など、「指示」に分類される通報連絡であると判定可能な用語が含まれている場合、計算機１はこの通報連絡に「指示」という役割分類を自動的に付与するようになっている。
【００５５】
同様に、「報告」、「申請」などの役割分類に対しても、予め各グループ（グループＢからグループＦ）に分類される用語がデータベース４に格納されているため適切な役割分類を判定し付与することができる。
【００５６】
一方、通報連絡のタイトルに複数の役割分類に属する用語が存在する場合、例えば「指示」と「報告」が混在する「○○指示に対する報告」のようなものである場合、「指示」のグループに属するのか、「報告」のグループに属するのかを判定することができない。
【００５７】
このような場合、計算機１は、通報連絡のタイトルを、最小の言語単位である形態素ごとに分割し、形態素ごとの品詞、重要度、配置順位の認識を行う。計算機１は、予め設定された判定条件に従い、通報連絡に付与されたタイトルから役割分類を判断し、その設定を行う。
【００５８】
役割分類の判断に際する判定条件は、例えば形態素の配置順位が遅いほど判断に用いられる形態素の優先度が高いことや、予めキーワードとなる単語に重要度を設定したものをデータベース４に登録しておき重要度の重み付けを行うものなどがある。
【００５９】
通報連絡に付されたタイトルが「○○指示に対する報告」である場合、図７に示すように、タイトルが形態素ごとに分類される。これにより、このタイトルは「○○」、「指示」、「に」、「対する」および「報告」の形態素に分割される。この分割された形態素ごとに、計算機１は品詞の識別、重要度の重み付け、および形態素の配置順位の認識を行う。
【００６０】
計算機１は、これら識別された情報および予め設定された判定条件に基づき、重要度の高い「指示」および「報告」のうち、配置順位が遅い「報告」が本タイトルのキーワードであると判定し、「報告」の役割分類の付与を行う。
【００６１】
なお、通報連絡の作成時などに計算機１が自動的に通報連絡の役割分類を付与したものであっても、任意の役割分類に変更することも可能である。
【００６２】
次に、通報連絡の送信時に通報連絡に付与された役割分類を用い、通報連絡の送受信状況の監視および確認を行う方法について説明する。
【００６３】
まず、通報連絡の関係者および関係組織間で行われる通報連絡の流れの一例について説明する。図８（ａ）は、指示者Ａおよび実行者Ｂ間で行われる「指示」および「報告」の通報連絡、ならびに実行者Ｂおよび権限者Ｃ間で行われる「申請」および「許可」の通報連絡の一例を概念的に示した図である。以後の実施形態においても、特に説明はしないが指示者Ａ、実行者Ｂおよび権限者Ｃは同一であるとする。
【００６４】
指示者Ａより実行者Ｂに対し「指示」の通報連絡３０が行われることにより、指示者Ａには実行者Ｂに指示を履行させる責任が発生する。これに対し実行者Ｂには、指示を履行する義務が発生する。
【００６５】
ここで、実行者Ｂは、指示されたタスクを実行する必要があるが、そのタスクの実行権限を持っていないため、タスク実行の許可を行う権限者Ｃが存在し、その権限者Ｃに実行の許可の申請を行う必要があるとする。これに伴い、実行者Ｂは権限者Ｃに「申請」の役割分類が付与された通報連絡３１を行う。
【００６６】
実行者Ｂによる「申請」の通報連絡３１が行われることにより、権限者Ｃには実行者Ｂに対する許可を行う権限が発生する。これに対し実行者Ｂには、権限者Ｃの許可を待つ必要があるため、停止（一時停止）という状態が発生する。
【００６７】
権限者Ｃは、許可を出す場合、「申請」の通報連絡３１を行った実行者Ｂに「許可」の役割分類が付与された通報連絡３３を行う。ここで、権限者Ｃに発生した権限は、「許可」の通報連絡３３を実行者Ｂに行うことにより解消され、実行者Ｂに発生した停止の状態は、「許可」の通報連絡３３を受けたことにより解消される。
【００６８】
実行者Ｂは、権限者Ｃからの「許可」の通報連絡３３を得ることにより、指示者Ａからの「指示」の通報連絡３０に対するタスクを実行することができる。また、このタスクを実行することにより、実行者Ｂにより「報告」の役割分類が付与された連絡通報３２が指示者Ａに対して行われる。
【００６９】
「指示」の通報連絡３０により実行者Ｂに発生した義務は、指示を履行した「報告」である通報連絡３２により解消され、指示者Ａに発生した責任の解消は、実行者Ｂからの「報告」の通報連絡３２を確認することにより解消される。
【００７０】
図８（ｂ）は、前述した指示者Ａ、実行者Ｂおよび権限者Ｃの間で行われる通報連絡の履歴と各通報連絡により発生した状態を表形式で出力した一例である。縦軸に通報連絡の履歴、横軸に送受信者を示し、縦軸は矢印方向に向かって時間の流れを示している。
【００７１】
また、ドット表示されている欄３４は、通報連絡により発生した状態が継続しているアクティブ（有効）な状態であり、通常表示されている欄３５は状態が解消されたインアクティブ（無効）な状態であることを表している。なお、本実施形態ではアクティブな状態をドット表示したが、アクティブおよびインアクティブな状態を任意の色で表示したり、アクティブな状態をブリンク表示することで、視覚的に把握できるようにしてもよい。
【００７２】
例えば、図８（ｂ）における通報連絡の履歴２で「申請」の通報連絡が行われた場合、実行者Ｂには「停止」の状態が発生し、権限者Ｃには「権限」の状態が発生することから、それぞれの状態はアクティブな状態で表示されている。
【００７３】
これに対し、通報連絡の履歴３で「許可」の通報連絡が行われた場合、実行者Ｂの「停止」および権限者Ｃの「権限」の状態は解消されることから、それぞれインアクティブな表示へ変更される。
【００７４】
このようにして行われる関係者および関係組織間で行われる通報連絡によって得られる電子情報である通報連絡の履歴は、通報連絡保存手段であるサーバデータベース５に保存される。この通報連絡の履歴は、例えば通報連絡の送受信者、通報連絡の内容、通報日時などの通報連絡に関する情報などが該当する。
【００７５】
このサーバデータベース５に保存された通報連絡の履歴は、関係者および関係組織による通報連絡の送受信状況の監視および確認に用いられ、適宜閲覧可能なように構成されることで通報連絡の履歴の送受信状況の監視確認手段として構成される。なお、通報連絡の履歴は、各計算機１がサーバデータベース５にアクセスすることにより閲覧可能としたが、履歴を電子データとして各計算機１に電子メールで送信可能なように構成してもよい。
【００７６】
具体的な通報連絡の送受信状況の監視および確認方法としては、送受信者間で行われている通報連絡の役割分類および各送受信者に発生した状態が時系列の表形式で表された監視表を出力することが考えられる。
【００７７】
図９（ａ）はこの監視表の一例である。この監視表は、図８（ｂ）における表形式で表された通報連絡の履歴に加えて、一連の通報連絡の最下流に位置する（時間的に最新の）インアクティブな状態である者を右端のカラム４０に抽出して表示したものである。
【００７８】
ここで、アクティブな状態は、自らがインアクティブな状態となるために必要な他者からの通報連絡を待機している状態であるといえる。よって、通報連絡の遅滞の原因は、通報の履歴において最下流側に位置する（時間的に最新の）インアクティブな状態である者であるといえる。
【００７９】
例えば、図９（a）における通報連絡の履歴３で「許可」の通報連絡が行われた場合において、最下流側に位置するインアクティブな状態者は実行者Ｂであり、指示者Ａは実行者Ｂからの通報連絡を待機している状態に当たる。よって実行者Ｂからの通報連絡が行われない場合には、遅滞の原因は実行者Ｂとなり、通報連絡の履歴において最下流に位置するインアクティブな状態である者に該当する。以下このような遅延を生じている状態をクリティカルな状態といい、通報連絡の遅延を発生させている者をクリティカルな状態者という。
【００８０】
また、図９（ｂ）のように、通報連絡の送受信状況が直感的に把握できる監視表を用いて表すことができる。この監視表は、アクティブな状態者４１を任意の模様で表示するのみならず、クリティカルな状態者４２およびアクティブであるが実行権限が停止状態である者４３を任意の模様で表示することができ、通報連絡の送受信状況が直感的に容易に把握可能なように表示することができる。
【００８１】
さらに、図９（ｃ）のように、クリティカルな状態者４４のみを抽出した監視表とすることもでき、通報連絡の遅延の原因となっている者を把握しやすくなっている。
【００８２】
通報連絡の送受信状況の監視および確認を行う際、図９（ａ）、（ｂ）および（ｃ）のような通報連絡の履歴を表した監視表は、単独で用いても、組み合わせて用いてもよい。また、図９（ｃ）のような必要最小限の情報が表示された監視表を用いて通報連絡の送受信状況の監視および確認を行い、さらに詳細な状況を確認したい場合には図９（ａ）のような送受信者の状態などの情報が表示されている監視表の閲覧が可能なように構成してもよい。
【００８３】
このように、通報連絡に役割分類および役割分類に対応する通報連絡の送受信者の状態を付与することにより通報連絡の送受信状況の監視確認を行うことは、以下の点で有効である。
【００８４】
例えば、図１０のように、指示者Ａが実行者Ｂに対し「指示」の通報連絡３０を行い、これに対し実行者Ｂからの「報告」の通報連絡３２が必要であるとする。しかし、この「報告」の通報連絡３２が指示者Ａに対して送信されない場合、遅延の原因を把握することは困難である。
【００８５】
しかし、各通報連絡に役割分類を付与し、通報連絡の履歴を表形式で閲覧可能とすることで、指示者Ａから実行者Ｂへの通報連絡の後に行われた通報連絡の役割分類は「申請」であることから、通報者Ａは、実行者Ｂが権限者Ｃからの許可を得られていないことが原因であると推測することができる。
【００８６】
すなわち、通報連絡に予め役割分類が付与されておりされており、その役割分類を含めた通報連絡の履歴を何人も確認できるような状況にあれば、なぜ通報連絡が遅滞しているかを通報連絡の内容まで確認することなく、その役割分類によりある程度判断可能である。
【００８７】
この緊急時通報連絡確認システムおよびその確認方法によれば、通報連絡に対し通報連絡の関係者および関係組織において共通化された役割分類を予め付与し、通報連絡の関係者および関係組織が通報連絡の送受信の状況を監視および確認できるように構成することにより、通報連絡の遅滞が発生した場合に、通報連絡の内容まで確認することなくその原因を容易に推測することが可能である。
【００８８】
また、通報連絡に付与する役割分類を、通報連絡の作成時に内容に応じて付与することができるため、関係者間で通報連絡の内容や状況把握の共通化が可能であり、その共通化された通報連絡の役割分類に沿った通報履歴の監視および確認を行うことができる。
【００８９】
さらに、通報連絡の役割分類は、通報連絡の送信者によってその情報が恣意的に設定されてしまうことがあるが、通報連絡の作成時に自動的に付与されるようにしておけば、関係者および関係組織間で統一された情報を共有することができる。
【００９０】
さらにまた、通報様式の入力テンプレートや通報連絡先の情報をデータベースに予め登録しておくことで、通報作成時である緊急時には入力テンプレートの必要事項のみを埋めてやればよく、迅速かつ正確に送信先に通報を行うことができる。
【００９１】
［第２の実施形態］
第２実施形態においては、通報連絡の受信後一定時間クリティカルな状態が経過した場合に機能する警告手段について説明する。
【００９２】
第１実施形態においては、通報連絡の履歴を時系列の表形式で表した監視表を用いて通報連絡の監視および確認を行ったが、本実施形態においては、通報連絡の関係者および関係組織がアクティブな状態となってからある時間を起点として経過時間の計測を行うことで監視表に経過時間を表示し、より具体的な通報連絡の遅滞状況を把握する。
【００９３】
この通報連絡の送受信に伴い行われる経過時間の計測および管理は、電子メールサーバ３により行われるものとし、前述の監視表と同様に、関係者および関係組織による通報連絡の経過時間の監視および確認に用いるため、適宜閲覧可能なように構成される。また、通報連絡の監視および確認用の計算機およびサーバを別に設けて構成してもよい。
【００９４】
一方、電子メールサーバ３には、通報連絡の受信者がアクティブな状態となってから遅延状態であると認識されるまでの一定時間に関する情報が格納されており、この一定時間を経過し遅滞の原因となった関係者および関係組織に対し警告を行う。本実施形態における緊急時通報連絡確認システムは、遅滞が発生した際に警告を行う警告手段を備えたことで、通報連絡を遅滞なく監視することが可能である。
【００９５】
図１１（ａ）は、通報連絡の受信後にアクティブな状態５０となってからの経過時間を表示した監視表である。この場合、経過時間を表示するのみならず、アクティブな状態者５０や、クリティカルな状態者５１などを任意の色で表示することで、より明確に通報履歴の監視を行うことができる。
【００９６】
また、経過時間の表示は、通報連絡の受信後にアクティブな状態となってからの経過時間のみならず、通報連絡の受信者が通報連絡を実際に確認してからの経過時間を表示してもよい。さらに、図１１（ｂ）のように、クリティカルな状態となってからの経過時間を計測し、これを表示することで、関係者および関係組織の個々の遅滞状況をより明確に把握することができる。
【００９７】
警告は、例えば、クリティカルな状態となってから５分経過後に警告を行うという設定がなされ、設定時間である５分経過後に電子メールサーバ３が遅滞を生じているクリティカルな状態者に対し行う場合が考えられる。警告は、警告音を鳴らしたり、図１１（ｂ）に示すような監視表における遅滞を生じているクリティカルな状態である欄を任意の色で表示したり、ブリンク表示したりすることで警告を行う。
【００９８】
例えば、図１２（ａ）は、実行者Ｂにより行われた「申請」の通報連絡に対する権限者Ｃからの「許可」の通報連絡が行われず、権限者Ｃがクリティカルな状態となってから設定時間である５分が経過し、警告が発せられた監視表を概念的に示したものである。
【００９９】
これに対し、遅滞を生じているクリティカルな状態者である権限者Ｃに「申請」の通報連絡を送信した実行者Ｂや、通報連絡の送受信状況の監視および確認を行うその他の関係者および関係組織が警告の存在を確認した場合、督促手段を設けることにより遅滞を生じているクリティカルな状態者Ｃへの督促を行うことができる。
【０１００】
例えば督促を行う者が、図１２（ａ）に示す監視表のクリティカルな状態である欄５５を選択することにより、図１２（ｂ）に示す督促手段としての督促画面を表示する。この督促画面には、例えば既に行われた通報連絡の内容が表示され、さらに画面右上に設けられた督促ボタン５６をクリックすることにより、予め用意された任意の様式に自動生成された督促状を、遅滞を生じているクリティカルな状態者である権限者Ｃに送信することができる。
【０１０１】
これに対し、権限者Ｃには図１２（ｃ）に示すような督促状が送信される。この督促状には、通報連絡の内容が表示され、さらに画面右上に設けられた通報確認ボタン５７をクリックすることにより、予め用意された任意の様式に自動生成された確認状が督促を行った関係者などに対し送信される。
【０１０２】
なお、権限者Ｃの遅滞を生じているクリティカルな状態が解除されるのは、この督促状を確認し、実行者Ｂからの通報連絡の内容を履行すること、例えば実行者Ｂに対し「許可」の通報連絡を行った時点である。
【０１０３】
また、督促状を送信したにもかかわらず、権限者Ｃが実行者Ｂに対する「許可」の通報連絡を行わず、遅滞を生じているクリティカルな状態が依然解除されない場合には、再督促手段を設けることもできる。例えば、予め設定された再督促時間を経過した場合に、再督促状を送信することなどがある。
【０１０４】
この緊急時通報連絡確認システムおよびその確認方法によれば、通報連絡が行われてからの経過時間を計測することで、通報連絡に生じている遅滞状況を明確に把握することができる。
【０１０５】
また、警告手段を設けたことで、遅滞を生じているクリティカルな状況が発生した場合に迅速に対応することができ、通報連絡の送受信状況の監視および確認を正確に行うことができる。
【０１０６】
［第３の実施形態］
第３実施形態においては、通報連絡の受信者が不在である場合の対処策について説明する。
【０１０７】
第２実施形態においては、例えば通報連絡を受信してから設定された一定時間の経過後に警告を行うなどして、通報連絡の遅滞の回避を行った。しかし、遅滞を生じているクリティカルな状態者が不在であるなど、受信者が通報連絡を確認することができない状況であることも考えられる。このような場合、督促状を送信したとしても、通報連絡の進行は期待することはできず、災害時などの緊急時には回避しなければならない事態である。
【０１０８】
図１３は、権限者Ｃが不在であるなど何らかの理由で「許可」の通報連絡６２を行えない状況にある場合の一例を示した図である。このような場合、「申請」の通報連絡６３を行った実行者Ｂは権限者Ｃの許可が得られないため、タスクが実行できず、特に緊急時においてはその時間的損失が無視できなくなる。このような場合、代替者Ｄを設定しておき、権限者Ｃから許可を得られないと判明した時点で、または予め代替者Ｄに「申請」の通報連絡６４を送信するようにすることが望ましい。
【０１０９】
この代替受信先の設定は、例えば代替を希望する関係者および関係組織に備えられた計算機１が、電気通信回線２を通じて電子メールサーバ３に対し代替受信先を設定することにより行われる。
【０１１０】
図１４は、通報連絡の代替受信先の設定を行う画面を示したものである。代替受信先の設定は、通報連絡の送信者により代替ボタン６０がクリックされることにより行われ、通報連絡は予めデータベース４に格納された代替受信先６１に自動的に送信されるようになっている。
【０１１１】
また、通報連絡に対する処理が実行されず、遅滞を生じているクリティカルな状態が設定された一定時間継続された場合に、電子メールサーバ３が自動的に代替受信先に通報連絡を送信するように構成してもよい。
【０１１２】
さらに、予め不在であり通報連絡を確認できないことがわかっている場合には、受信者が自ら代替先に通報連絡が送信されるように設定可能なように構成してもよい。
【０１１３】
この緊急時通報連絡確認システムおよびその確認方法によれば、通報連絡の受信者が不在である場合には代替受信者を設定することにより予め遅滞の要因を排除することができ、一定時間遅滞を生じているクリティカルな状態が継続した場合においては、代替受信者へ通報連絡が送信可能なように構成することにより、早急に遅滞状況を回避することができる。
【０１１４】
［第４の実施形態］
第４実施形態においては、通報連絡が誤った送信先に送信された場合の対処策について説明する。
【０１１５】
図１５（ａ）および（ｂ）は、通報連絡が送受信された場合の一例であり、図１５（ａ）は権限者Ｃに対し「申請」の通報連絡３１が正しく送信された場合、図１５（ｂ）は「許可」の通報連絡３３が許可の権限を有していない非権限者Ｄに対し誤って送信された場合を示した図である。
【０１１６】
図１５（ｂ）のように、誤って権限のない非権限者Ｄに対して「申請」の通報連絡を行った場合、この非権限者Ｄは、実行者Ｂからの「申請」の通報連絡３１を受信しても許可を行うことができず、実行者Ｂに対する「許可」の通報連絡３３は行われない。よって、実行者Ｂのクリティカル状態は解除されず、通報遅滞の要因となる。
【０１１７】
このような事態を回避するため、第１実施形態で説明したように、通報連絡の作成時に用いられる入力テンプレートと共に属性情報として権限の有無もデータベース４に格納しておく対処策が考えられる。しかし、このような対処策が機能せず、通報連絡を非権限者に誤って送信してしまった場合には、非権限者が、その取り消しの返信を行うことができるような手段を設けることにより対処することができる。
【０１１８】
具体的には、計算機１のデータベース４に、「申請」の通報連絡３１を受信した場合の権限の有無を予め格納しておき、非権限者に「申請」の通報連絡３１がなされた場合には、計算機１がこの権限の有無を自動的に検知して、通報連絡の送信者に対し誤りである旨の通知を行うことにより行われる。図１５（ｃ）は、「申請」の通報連絡３１の送信者に対し、誤った通報連絡の受信者から自動的に返信される通知の一例である。
【０１１９】
なお、非権限者に誤って「申請」の通報連絡３１が送信された際、非権限者に対し、計算機１が自己には権限がないことを警告などで通知することで、通報連絡の遅滞の回避を行ってもよい。
【０１２０】
なお、本実施形態においては「申請」の通報連絡３１が非権限者に送信された場合について説明したが、この他の役割分類が付与された通報連絡が誤った送信先に送信された場合についても、同様に、予めデータベース４に格納された情報に基づき計算機１が誤りを自動的に判別し、誤りである旨の返信を行うことができる。
【０１２１】
この緊急時通報連絡確認システムおよびその確認方法によれば、誤った通報連絡がなされた場合であっても、自動的に通報連絡の正誤の判別を行い、さらにこれに対する対応を行うことで、緊急時の通報連絡に対して迅速かつ正確に対処することができる。
【０１２２】
［第５の実施形態］
第５実施形態においては、サーバデータベース５に保存・管理された通報連絡の履歴を、緊急時を想定した防災訓練の評価やシミュレートなどに利用するシミュレート手段について説明する。
【０１２３】
図１６は、サーバデータベース５に保存された通報連絡の履歴の出力形態の一例である通報履歴表である。
【０１２４】
この通報履歴表は、通報連絡の名称（通報名称６５）、通報連絡に付与された役割分類（役割６６）および添付ファイルの有無（添付ファイル６７）などが通報履歴の固有情報として表示されている。
【０１２５】
一方、通報履歴表の右側には、その通報名称ごとの送受信者６８、および送受信者６８間で行われた通報連絡の送受信時刻６９が表示される。また、各通報連絡の送受信時刻６９においては、通報連絡の送信者、通報連絡の主たる受信者（ＴＯ：）、および確認のために同一の通報が送信される参照者としての受信者（ＣＣ：）が判別できるように所定の表示方法で表示される。
【０１２６】
この通報履歴表は、通報名称６５や添付ファイル６７などの任意の欄がクリックされることにより、該当する通報連絡の詳細情報や、添付ファイルの内容をサーバデータベース５から読み出し、参照することができるように構成されている。
【０１２７】
このように通報連絡の履歴をサーバデータベース５に一括して保存し、必要に応じて図１６の通報履歴表のように出力することにより、通報連絡の履歴における時間的ロスの検証や、それを改善するためのシミュレート訓練や通報連絡手順の改良などに対する定量的評価に活用することができる。
【０１２８】
また、この緊急時通報連絡確認システムおよびその確認方法を用いて緊急時における通報連絡訓練を行った場合、この訓練で得られたデータは、電子情報である通報連絡履歴としてサーバデータベース５に保存可能である。さらに、それぞれの訓練データをタグ付けして参照可能にしておけば、必要な訓練データを表計算ソフトなどを用いて統計処理を行うことができ、通報連絡訓練の評価レポートを自動生成することもできる点で有効である。
【０１２９】
一方、保存された通報連絡訓練で得られた訓練データである通報連絡の履歴は電子データであるため、この訓練データから訓練状況をシミュレート（再現）することができる。具体的には、サーバデータベース５から訓練データを読み込み、実時間で、あるいはそれを加速させて訓練状況をシミュレートすることができる。
【０１３０】
図１７は、訓練データを用いて訓練状況をシミュレートした結果を、時系列チャート図で示したものである。このように時系列チャート図などで訓練状況をシミュレートすることにより、通報連絡訓練の進行状況や遅滞状況などを本番の訓練と同様に再現し、検証することができる。
【０１３１】
この緊急時通報連絡確認システムおよびその確認方法によれば、通報連絡の履歴を電子データとしてサーバデータベースに一括して保存・管理し、必要に応じて参照可能なように構成することにより、従来困難であった通報連絡訓練の定量的評価や、この訓練状況のシミュレートが可能となり、これに伴い通報連絡体系の改善などを行うことで現実の緊急時対応の質を向上させることができる。
【図面の簡単な説明】
【０１３２】
【図１】緊急時通報連絡確認システムの一例である構成図。
【図２】通報連絡の送受信者に付与される役割分類の一例を示す図。
【図３】通報連絡の内容が対応する役割分類に関連付けされる概念図。
【図４】通報連絡の入力テンプレートの一覧を示す図。
【図５】通報連絡の役割分類をプルダウンメニュー変更する場合を示す図。
【図６】通報連絡の送信先の表示例を示す図。
【図７】通報連絡に付されたタイトルを形態素毎に分割し役割分類を判別する図。
【図８】（ａ）は通報連絡の流れを示す概念図、（ｂ）は通報連絡の履歴と各通報連絡により発生した状態を表形式で示す図。
【図９】通報連絡の履歴を出力した監視表を示す図。
【図１０】通報連絡が遅滞している場合を示す概念図。
【図１１】（ａ）はアクティブな状態となってからの経過時間を示した監視表、（ｂ）はクリティカルな状態となってからの経過時間を示す監視表。
【図１２】（ａ）は警告が発せられた監視表の概念図、（ｂ）は送信される督促状を示した図、（ｃ）は送信された督促状を示す図。
【図１３】通報連絡の代替送信先を設定して通報連絡の送受信を行う図。
【図１４】通報連絡の代替受信先の設定を行う画面を示す図。
【図１５】（ａ）は権限者Ｃに対し「申請」の通報連絡が正しく送信された場合を示す図、（ｂ）は非権限者Ｄに対し誤って送信された場合を示す図、（ｃ）は誤った通報連絡の受信者から自動的に返信される通知を示す図。
【図１６】サーバデータベースに保存された通報連絡の履歴の出力形態の一例を示す図。
【図１７】訓練データを用いて訓練状況をシミュレートした結果の時系列チャート図。
【符号の説明】
【０１３３】
１  計算機
２  電気通信回線
３  電子メールサーバ
４  データベース
５  サーバデータベース
【図１】
2009100147.tif 000003
【図２】
2009100147.tif 000004
【図３】
2009100147.tif 000005
【図４】
2009100147.tif 000006
【図５】
2009100147.tif 000007
【図６】
2009100147.tif 000008
【図７】
2009100147.tif 000009
【図８】
2009100147.tif 000010
【図９】
2009100147.tif 000011
【図１０】
2009100147.tif 000012
【図１１】
2009100147.tif 000013
【図１２】
2009100147.tif 000014
【図１３】
2009100147.tif 000015
【図１４】
2009100147.tif 000016
【図１５】
2009100147.tif 000017
【図１６】
2009100147.tif 000018
【図１７】
2009100147.tif 000019