(57)【要約】      （修正有）【課題】情報セキュリティ事故情報を用いて組織内の事故リスクを検出し、事故を防止、低減する装置を提供する。【解決手段】事故事例データベースに含まれる、事故発生組織と、事故種別と、事故誘発要因のデータを用いて、各組織がもつ事故誘発要因と、各事故種別の事故誘発要因とを明らかにし、各組織がもつ事故誘発要因と各事故種別の事故誘発要因とを比較する。これにより、他の事故発生の可能性や、これまで明らかにされていなかった組織の事故誘発要因を明らかにする。【選択図】図１
2011258088.tif 000002
【特許請求の範囲】
【請求項１】
情報セキュリティ事故の防止、低減のためのインシデント管理システムであって、
事故事例データベースと、組織ごとのこれまでに発生した事故種別を格納する組織別事故種別データベースと、組織ごとのこれまで発生した事故種別の事故誘発要因を格納する組織別事故誘発要因データベースと、事故種別ごとの事故誘発要因を格納する事故種別別事故誘発要因データベースと、
事故入力者からの事故情報の入力を受け付け、前記事故事例データベースに格納する事例登録手段と、
前記事故事例データベースに格納されるデータを用いて、前記組織別事故種別データベースと、前記組織別事故誘発要因データベースと、前記事故種別別事故誘発要因データベースとを更新するデータ更新手段と、
前記組織別事故種別データベース、前記組織別事故誘発要因データベース、前記事故種別別事故誘発要因データベースのデータから、現段階で未発生ながら今後発生する可能性のある事故種別を検出する事故リスク検出手段と
前記の検出された事故種別とその事故誘発要因を、当該事故が発生する可能性のある組織へ警告する警告発信手段とを備える
ことを特徴とするインシデント管理システム。
【請求項２】
情報セキュリティ事故の防止、低減のための誘発要因検出システムであって、
事故事例データベースと、組織別事故種別データベースと、組織別事故誘発要因データベースと、事故種別別事故誘発要因データベースと、
事例登録手段と
事故事例データベースに格納されるデータを用いて、組織別事故誘発要因データベースと、事故種別別事故誘発要因データベースとを更新するデータ更新手段と、
事故事例データベース、組織別事故誘発要因データベース、事故種別別事故誘発要因データベースのデータから、格納された１件１件の事故の事故誘発要因の抜けもれの可能性を検出する誘発要因検出手段と、
検出された事故種別とその事故誘発要因を、当該事故が発生する可能性のある組織へ警告する警告発信手段とを備える
ことを特徴とする誘発要因検出システム。
【請求項３】
請求項１に記載のインシデント管理システムにおいて、
前記データ更新手段は、これまでに発生した事故種別、事故誘発要因に１、これまでに発生していない事故種別、事故誘発要因に０を格納する
ことを特徴とするインシデント管理システム。
【請求項４】
請求項１に記載のインシデント管理システムにおいて、
前記データ更新手段は、前記事故事例データベースに格納された事故種別、事故誘発要因の件数を格納する
ことを特徴とするインシデント管理システム。
【請求項５】
請求項２に記載の誘発要因検出システムにおいて、
前記データ更新手段は、これまでに発生した事故種別、事故誘発要因に１、これまでに発生していない事故種別、事故誘発要因に０を格納する
ことを特徴とする誘発要因検出システム。
【請求項６】
請求項２に記載の誘発要因検出システムにおいて、
前記データ更新手段は、前記事故事例データベースに格納された事故種別、事故誘発要因の件数を格納する
ことを特徴とする誘発要因検出システム。
【請求項７】
請求項１に記載のインシデント管理システムにおいて、
前記事故リスク検出手段は、事故種別の事故誘発要因と当該事故種別が発生していない組織の事故誘発要因の非類似度を算出することにより、現段階で未発生ながら今後発生する可能性のある事故種別を検出する
ことを特徴とするインシデント管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インシデント情報を分析する技術、特に情報セキュリティにおけるインシデントを分析する技術に関する。
【背景技術】
【０００２】
近年、情報セキュリティ事故（以下、単に「事故」と称する場合がある。）に関する社会的関心が高まっている。情報セキュリティ事故を防止するためには、事故が起きるしくみを理解し、考えられる事故リスクを洗い出し、それらを排除する取り組みが行われる。しかし、事故リスクを完全に洗い出すことが極めて困難である、事故リスクを適切に評価することが困難である、対策にかけられるコスト等の制約により全てのリスクに対策を実施することが困難である、などの理由により、事故リスクの完全排除は極めて困難である。そのため、情報セキュリティ事故の防止、低減のためには、継続的な対策活動が不可欠である。
【０００３】
これに対し、事故リスクを継続的に改善し、事故を防止、低減するためのシステムが提案されている。例えば、特許文献１、特許文献２では、医療過誤の内容をレコード単位としたデータベースを作成し、評価基準に基づくランク付けを行った結果、発生可能性が特定ランク以上となった医療過誤に対して、Ａ対策立案過程、Ｂ対策実践課程、Ｃ活動評価過程、Ｄ結果反映過程を繰り返すことで医療過誤の発生する可能性を低減し、この医療過誤の発生を未然に防止又は皆無に向けて低減する医療過誤防止システムを提供している。また，非特許文献１では，事故はいくつかの事象が連鎖して発生するという事故の構造の考え方やヒューマンファクター工学をベースに開発されたＰ−ｍＳＨＥＬＬモデルを活用して周囲の環境に目を向けた多重の対策を検討することにより、事故の再発防止や未然防止に繋げるシステムを提供している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−１３２９５５号公報
【非特許文献】
【０００５】
【非特許文献１】"ePower/CLIPの特長"，[online]，株式会社テプコシステムズ，[２０１０年２月２４日検索]インターネット＜URL：http://www.tepsys.co.jp/service/clip/ feature.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
人間工学、心理学の分野で、人間の行動は人間自身の特性と人間を取り巻く周辺環境との相互作用により決まることがわかっている。また、事故が発生するまでには、いくつかのエラーが重なって起きる場合が多いことがわかっている。しかしながら、特許文献１、非特許文献１のシステムは、対策活動を実施する必要があるか否かを事故の発生可能性によって判断しており、事故誘発要因には着目していない。そのため、同じ事故誘発要因によって引き起こされる他の事故の可能性を把握することが困難である。また、特許文献１、非特許文献１のシステムは、データベースに入力する評価基準や対策活動内容、対策評価方法などが人に任されており、活動内容や評価方法などに個人差が生じる可能性があり、それらの差に気づくことも人に委ねられている。
【課題を解決するための手段】
【０００７】
前記課題を解決するために、本発明では、情報セキュリティ事故情報を用いて組織内の事故リスクを検出し、事故を防止、低減する装置を提供する。
【０００８】
より具体的には、本発明は、組織内外で発生した事故の事故誘発要因の情報を比較し、これまでに発生していないが、今後発生する可能性のある事故を明らかにすることで、事故を防止、低減する装置を提供する。
【０００９】
本発明は、事故事例データベースに含まれる、事故発生組織と、事故種別と、事故誘発要因のデータを用いて、各組織がもつ事故誘発要因と、各事故種別の事故誘発要因とを明らかにし、各組織がもつ事故誘発要因と各事故種別の事故誘発要因とを比較することにより、事故単体の情報だけでは把握が困難な、まだ発生していないが組織がもつ事故のリスクを検出することを特徴とする。
【発明の効果】
【００１０】
本発明では、発生した事故情報から、他の事故の可能性やこれまで明らかにされていなかった組織の事故誘発要因を明らかにすることにより、事故を防止、あるいは低減できるという利点がある。
【図面の簡単な説明】
【００１１】
【図１】インシデント管理システムの全体構成図である。
【図２】インシデント管理サーバ及びクライアントのハードウェア構成図である。
【図３】事故事例データベースのデータ構造の一例である。
【図４】組織別事故種別データベースのデータ構造の一例である。
【図５】組織別事故誘発要因データベースのデータ構造の一例である。
【図６】事故種別別事故誘発要因データベースのデータ構造の一例である。
【図７】警告データベースのデータ構造の一例である。
【図８】事例登録の処理を示すフローチャートである。
【図９】データ更新の処理を示すフローチャートである。
【図１０】事故リスク検出の処理を示すフローチャートである。
【図１１】警告発信の処理を示すフローチャートである。
【図１２】要因分析評価システムの全体構成図である。
【図１３】要因分析評価システムにおけるデータ更新の処理を示すフローチャートである。
【図１４】要因分析評価の処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
次に、本発明を実施するための形態（以下、「実施形態」という。）について、適宜図面を参照しながら説明する。
【００１３】
≪実施形態１≫
実施形態１として、まず「インシデント管理システム」の全体構成を、図１を用いて説明する。インシデント管理システム１００は、インシデント管理サーバ１１０と、クライアント１２０と、クライアント１２１とを含んで構成される。これらは、通信媒体（ネットワークまたはネットワークを伝播するデジタル信号や搬送波）を介して接続される。
【００１４】
インシデント管理サーバ１１０は、事例登録部１１１と、データ更新部１１２と、事故リスク検出部１１３と、警告発信部１１４と、事故事例データベース１１５と、組織別事故種別データベースと１１６と、組織別事故誘発要因データベース１１７と、事故種別別事故誘発要因データベース１１８と、警告データベース１１９とを含む。インシデント管理サーバ１１０において、事例登録部１１１と、データ更新部１１２と、事故リスク検出部１１３と、警告発信部１１４は、図２に示すメモリ２０３またはストレージ２０２に備えられる。また、事故事例データベース１１５と、組織別事故種別データベース１１６と、組織別事故誘発要因データベース１１７と、事故種別別事故誘発要因データベース１１８と警告データベース１１９は、図２に示すストレージ２０２に格納される。
【００１５】
事故事例データベース１１５と、組織別事故種別データベースと１１６と、組織別事故誘発要因データベース１１７と、事故種別別事故誘発要因データベース１１８、警告データベース１１９は、例えばＲＤＢ（Relational Database）により構成される。
【００１６】
クライアント１２０は、ＰＣなどの端末などにより構成され，事例入力部を含む。
【００１７】
クライアント１２１は、ＰＣなどの端末などにより構成され，警告受信部を含む。
【００１８】
図２は、インシデント管理システムを構成するインシデント管理サーバおよびクライアントのハードウェア構成を示す図である。このハードウェア構成２００（以下、単に「コンピュータ」と称する場合がある。）は、ＣＰＵ（Central Processing Unit：制御部）２０１、ストレージ（記憶部）２０２、メモリ（記憶部）２０３、入力装置（入力部）２０４、出力装置（表示部）２０５、通信装置２０６等を有する。ＣＰＵ２０１、ストレージ２０２、メモリ２０３、入力装置２０４、出力装置２０５、通信装置２０６等はバスなどの内部通信線２０７によって互いに接続されている。
【００１９】
ＣＰＵ２０１がストレージ２０２やメモリ２０３に格納されているプログラムを実行することにより、通信装置２０６は、前記通信媒体を介してデータのやり取りを行う。また、そのプログラムの実行により、事例登録部１１１、データ更新部１１２、事故リスク検出部１１３、警告発信部１１４等の処理部による機能が実現される。
【００２０】
図３に、事故事例データベース１１５のデータ構造の一例を示す図である。図３において、テーブル３００の各レコードは、一件の情報セキュリティ事故情報を記録したデータであり、フィールド３０１、３０２、３０３、３０４を有する。
【００２１】
フィールド３０１は、事故事例を識別するための事故番号を表す。フィールド３０２は、事故が発生した組織（部署）を表す。フィールド３０３は、事故種別を表す。フィールド３０３は、メール誤送信、ＦＡＸ誤送信といった事故分類を詳細化した、宛先（Ｔｏ、Ｃｃ、Ｂｃｃ）の選択ミスによるメール誤送信、送信時のＦＡＸ番号入力間違えによるＦＡＸ誤送信、等が登録される。フィールド３０４は、事故の誘発要因を表す。フィールド３０４は、例えば、勤務状況、作業時間帯、作業方法などが登録される。
【００２２】
なお、テーブル３００には、例示したフィールド以外に、事故分析者、事故当事者、事故の関係者、事故の経緯、事故の背後要因、事故対策案など、情報セキュリティ事故の管理上必要なフィールドや、事例登録日時など、インシデント管理システムの管理上必要なフィールドを格納することができる。
【００２３】
図４は、組織別事故種別データベース１１６のデータ構造の一例を示す。図４において、テーブル４００の各レコードは、一つの組織のこれまでに発生している事故種別を示しており、フィールド４０１、４０２、４０３、４０４等を有する。
【００２４】
フィールド４０１は組織を表す。フィールド４０２、４０３、４０４は、事前に分類を定義した事故種別を表す。フィールド４０２、４０３、４０４の各フィールド値は、当該フィールドに分類される事故が事故事例データベースに登録されているかどうかを示し、１か０の値で示す。フィールド値が１の場合は、当該事故が事故事例データベースに登録されていることを示し、フィールド値が０の場合は、これまでに当該事故が登録されていないことを示す。ただし、フィールド値は０か１に限定されるものではなく、例えば、同種の事故が一つの組織で複数登録されている場合は、登録件数を格納してもよい。
【００２５】
図５は、組織別事故誘発要因データベース１１７のデータ構造の一例を示す。図５において、テーブル５００の各レコードは、一つの組織でこれまでに発生した事故の事故誘発要因を示し、フィールド５０１、５０２、５０３、５０４、５０５等を有する。
【００２６】
フィールド５０１は組織を表す。フィールド５０２、５０３、５０４、５０５は、事前に分類を定義した事故誘発要因を表す。フィールド５０２、５０３、５０４、５０５のフィールド値は、当該フィールドに分類される事故誘発要因が過去に発生した事故の事故誘発要因として登録されたことがあるかどうかを表し、１か０の値を持つ。フィールド値が１の場合は、当該組織において当該事故誘発要因が過去に事故の誘発要因として事故事例データベースに登録されたことを示し、フィールド値が０の場合は、当該組織においてこれまでに当該事故誘発要因により事故が発生していないことを示す。ただし、フィールド値は０か１に限定されるものではなく、例えば、同種の事故誘発要因が一つの組織で複数登録されている場合は、登録件数を格納してもよい。
【００２７】
図６は、事故種別別事故誘発要因データベース１１８のデータ構造の一例を示す。図６において、テーブル６００の各レコードは、一つの事故種別に分類される事故で、これまでに発生した事故の事故誘発要因を示し、フィールド６０１、６０２、６０３、６０４、６０５等を有する。
【００２８】
フィールド６０１は事故種別を表す。フィールド６０２、６０３、６０４、６０５は、フィールド５０２、５０３、５０４、５０５と同様に、事故誘発要因を表す。フィールド６０２、６０３、６０４、６０５のフィールド値は、当該フィールドに分類される事故誘発要因が過去に発生した事故の事故誘発要因として登録されたことがあるかどうかを表し、１か０の値を持つ。フィールド値が１の場合は、当該事故種別において当該事故誘発要因が過去に事故の誘発要因として事故事例データベースに登録されたことを示し、フィールド値が０の場合は、当該事故種別においてこれまでに当該事故誘発要因により事故が発生していないことを示す。ただし、フィールド値は０か１に限定されるものではなく、例えば、同種の事故誘発要因が一つの事故種別で複数登録されている場合は、登録件数を格納してもよい。
【００２９】
図７は、警告データベース１１９のデータ構造の一例を示す。図７において、テーブル７００の各レコードは、１件の警告事例を示し、フィールド７０１、７０２、７０３、７０４等を有する。
【００３０】
フィールド７０１は警告番号を表す。フィールド７０２は警告先の組織を表す。フィールド７０３は警告する事故種別を表す。フィールド７０４は、警告する事故種別の事故誘発要因を表す。
【００３１】
次に、図面を用いて本実施形態の処理の詳細を説明する。本実施形態の処理は大別すると、事例登録部１１１による事例登録処理と、データ更新部１１２による登録された事故事例を用いた、組織と事故種別と事故誘発要因との関係を表すデータの更新処理と、事故リスク検出部１１３による前記データ更新処理により更新されたデータを用いた事故リスク検出処理と、警告発信部１１４による前記事故リスク検出で明らかになった事故発生の可能性のある未発生の事故情報の警告発信処理の４つの処理からなる。
【００３２】
図８を用いて、事例登録の処理を説明する。本処理では事故事例データベース１１６に情報セキュリティ事故事例を登録する。本処理は情報セキュリティ事故の事例入力者からの要求により実行される。
【００３３】
８０１では、事故事例登録部１１１がテーブル３００のフィールド３０２、３０３、３０４、３０５、３０６、３０７、３０８に対応する入力欄を出力装置２０５に表示する（図示略）。
【００３４】
８０２では、事例入力者が、クライアント１２０の入力装置２０４を通じて、各入力欄に該当するデータを入力する。ここで入力する事故の誘発要因は、例えば非特許文献２が提示する事故分析手法により、あらかじめ抽出しておく。
【００３５】
【非特許文献２】冨樫由美子，藤井康広，佐藤嘉則，「企業の情報セキュリティ対策におけるヒューマンエラー管理実践に向けた検討」，情報処理学会誌Vol.2009-CSEC-45 No.1，2009  ８０３では、事例登録部１１１が、８０２において事例入力者が入力した事故事例データを事故事例データベース１１５に登録する。具体的にはまず、テーブル３００のフィールドを参照して最も大きな事故事例番号Ｎを判定する。次に、８０１で事例入力者が入力した事故事例に対してＮ＋１を事故事例番号として与え、新たなレコードをテーブル３００に追加する。
【００３６】
以上が、事例登録の処理の詳細である。
【００３７】
図９を用いて、データ更新部１１２の処理を説明する。本処理では、事故事例データベース１１５に登録されたデータを用いて、組織別事故種別データベース１１６、組織別事故誘発要因データベース１１７、事故種別別事故誘発要因データベース１１８を更新する。本処理は、前回処理を行ってから所定の時間が経過した場合に起動される。ただし、起動タイミングはこの限りではなく、インシデント管理システム１００の管理者が任意の時点で起動する、あるいは事故事例データベース１１５が更新された場合、あるいは事故事例データベース１１５に新たに格納されたレコード件数が所定の値に達した場合等でも良い。
【００３８】
９０１では、データ更新部１１２が、事故事例データベース１１５の格納レコードを検索し、前回データ更新処理開始後に新たに格納されたレコードを判定する。判定処理は任意の方法でよく、例えば前回データ更新処理開始日時をストレージ２０２に記憶しておき、また、テーブル３００に事例登録日時を表すフィールドを設けておくことで、前回データ更新処理開始後のレコードを判定することができる。９０２以降は、前回データ更新処理開始後に新たに格納された事例が１件以上ある場合に実行される。新たに格納された事例が０件の場合は、処理を終了する。
【００３９】
９０２では、９０１で新たに格納されたと判定されたレコード（以下、更新対象レコードと呼ぶ）を参照して、組織別事故種別データベース１１６を更新する。具体的には、更新対象レコードのフィールド３０２のフィールド値を用いてテーブル４００のフィールド４０１を検索し、フィールド３０２とフィールド４０１のフィールド値が一致するレコードを判定する。一致するレコードがテーブル４００に存在しない場合には、テーブル４００のフィールド４０１の値をフィールド３０２のフィールド値、フィールド４０１以外のフィールドの値を０とする新たなレコードを追加する。次に、更新対象レコードのフィールド３０３を参照し、テーブル４００の対応するフィールドのフィールド値が０の場合は１に更新する。
【００４０】
９０３では、更新対象レコードを参照して、組織別事故誘発要因データベース１１７を更新する。具体的には、更新対象レコードのフィールド３０２のフィールド値を用いてテーブル５００のフィールド５０１を検索し、フィールド３０２とフィールド５０１のフィールド値が一致するレコードを判定する。一致するレコードがテーブル５００に存在しない場合には、テーブル５００にフィールド５０１の値をフィールド３０２のフィールド値、フィールド５０１以外のフィールドの値を０とする新たなレコードを追加する。次に、更新対象レコードのフィールド３０４を参照し、テーブル５００の対応するフィールド値が０の場合は１に更新する。
【００４１】
９０４では、更新対象レコードを参照して、事故種別別事故誘発要因データベース１１８を更新する。具体的には、当該レコードのフィールド３０３を用いてテーブル６００のフィールド６０１を検索し、フィールド３０３とフィールド６０１が一致するレコードを判定する。一致するレコードがテーブル６００に存在しない場合には、テーブル６００にフィールド６０１の値をフィールド３０３、フィールド６０１以外のフィールドの値を０とする新たなレコードを追加する。次に、フィールド３０４を参照し、テーブル６００の対応するフィールド値が０の場合は１に更新する。
【００４２】
以上が、データ更新の処理の詳細である。
【００４３】
図１０を用いて、事故リスク検出部１１３の処理を説明する。本処理では、組織別事故種別データベース１１６、組織別事故誘発要因データベース１１７、事故種別別事故誘発要因データベース１１８を用いて、これまで発生していないが、発生する危険性の高い事故を検出する。本処理は、データ更新処理終了後に起動される。ただし、起動タイミングはこの限りではなく、インシデント管理システム１００の管理者が任意の時点で起動する、あるいは前回処理を行ってから所定の時間が経過した場合、あるいは事故事例データベース１１５に新たに格納されたレコード件数が所定の値に達した場合等でも良い。
【００４４】
データ更新部において、データ更新が行われなかった場合は、事故リスク検出部の処理を終了する。
【００４５】
１００１では、組織別事故種別データベース１１６から組織で未発生の事故種別を検索する。具体的にはテーブル４００のレコードを参照し、フィールド値が０となっているフィールドを検索する。ここで、フィールド値が０となる事故種別を持つ組織を検出対象組織、フィールド値が０となる事故種別を検出対象事故種別と呼ぶ。
【００４６】
１００２では、組織別事故誘発要因データベース１１７から、検出対象組織の事故誘発要因レコードを検索する。具体的には、テーブル５００のフィールド５０１を参照し、検出対象組織と一致する組織のレコードを検索する。
【００４７】
１００３では、事故種別別事故誘発要因データベース１１８から、検出対象事故種別の事故誘発要因レコードを検索する。具体的には、テーブル６００のフィールド６０１を参照して、検出対象事故種別と一致する事故種別のレコードを検索する。
【００４８】
１００４では、１００２と１００３で得られた検出対象組織の事故誘発要因レコードと検出対象事故種別の事故誘発要因レコードの各フィールド値から、検出対象事故種別の事故誘発要因と検出対象組織の事故誘発要因との非類似度を算出する。具体的には、１００３で得られた検出対象事故種別の事故誘発要因レコードのフィールド値が１となるフィールドを対象として、事故誘発要因の非類似度を算出する。本実施形態では、前記非類似度を（数１）で与える。ｉはテーブル６００中の検出対象事故種別の事故誘発要因レコードを示し、「１≦ｉ≦事故種別数」の条件を満たす整数値をとる。ｊはテーブル６００中の検出対象組織の事故誘発要因レコードを示し、「１≦ｊ≦組織数」の条件を満たす整数値をとる。ｋはテーブル６００中の検出対象事故種別の事故誘発要因レコードのフィールド値が１となるフィールドを示し、「１≦ｋ≦誘発要因数」の整数値を取る。Fi,kはテーブル６００中の検出対象事故種別のレコードの算出対象フィールドのフィールド値を表し、Fj,kはテーブル５００中の検出対象組織のレコードの算出対象フィールドのフィールド値を表す。Fi,k 、Fj,kは平均０、分散１に正規化してもよい。
【００４９】
【数１】
2011258088.tif 000003
１００５では、１００４で算出した非類似度が、あらかじめ定義した規定値以下となるかどうかを判定する。非類似度が規定値以下となる場合（１００５の判定がＹＥＳの場合）は１００７へ進み、非類似度が規定値を超える場合（１００５の判定がＮＯの場合）は１００６へ進む。例えば、規定値を０とすると、検出対象組織の事故誘発要因レコードのフィールド値が１となるフィールドと検出対象事故種別の事故誘発要因レコードの対応フィールドが全て１となっていなければ非類似度が規定値を超えることになる。
【００５０】
１００６では、事故発生の可能性を有すると判定された事故情報を警告データベースに追加する。具体的には、フィールド７０２、７０３、７０４にそれぞれ、未発生の事故種別の事故発生の可能性がある組織、事故種別、当該事故種別の事故誘発要因を格納する。
【００５１】
１００７では、テーブル４００に格納されている全ての事故種別、全ての組織を探索したかどうかを判定する。全ての事故種別、全ての組織の探索が済んでいない場合は（１００７の判定がＮＯの場合）、１００１へ戻る。全ての事故種別、全ての組織の探索が終了した場合（１００７の判定がＹＥＳの場合）は、処理を終了する。
【００５２】
以上が事故リスク検出の処理の詳細である。
【００５３】
図１１を用いて、警告発信部１１４の処理を説明する。
【００５４】
１１０１では、警告データベース１１９にレコードが存在するかどうかを確かめる。警告データベース１１９にレコードが存在する場合（１１０１の判定結果がＹＥＳの場合）は、ステップ１１０２へ進み、警告データベース１１９にレコードが存在しない場合（１１０１の判定結果がＮＯの場合）は、警告発信の処理を終了する。
【００５５】
１１０２では、警告データベース１１９を参照して事故リスクが検出された組織に警告を発信する。具体的には、テーブル７００のフィールド７０２を参照して、警告を発信する対象の組織を判別し、フィールド７０３、７０４に格納される情報を当該組織へ発信する。発信方法は、任意の方法でよく、例えば、メールを送信する、組織のイントラＨＰなどに情報を提示するなどの方法がある。
【００５６】
１１０３では、警告データベースのレコードを消去する。
【００５７】
以上が、警告発信の処理の説明である。
【００５８】
本実施形態によれば、事故１件１件でなく、同種の事故における事故誘発要因、あるいは、同組織で発生した別の事故における事故誘発要因の情報を用いて事故リスクを検出することで、組織が持つ事故誘発要因に起因する他の事故発生の可能性を検出できるという利点がある。
【００５９】
≪実施形態２≫
実施形態２として、事故事例データベースに登録された情報を用いて、登録された事故の誘発要因の分析に抜けもれがないかを検出する誘発要因分析評価システムの全体構成を、図１２を用いて説明する。誘発要因分析評価システム１２００は、インシデント管理サーバ１２１０と、クライアント１２２０と、クライアント１２２１とを含んで構成される。これらは、実施形態１と同様に、通信媒体（ネットワークまたはネットワークを伝播するデジタル信号や搬送波）を介して接続される。誘発要因分析評価装置１２１０、クライアント１２２０、クライアント１２２１のハードウェア構成は実施形態１と同様である。
【００６０】
インシデント管理サーバ１２１０は、事例登録部１２１１と、データ更新部１２１２と、要因分析評価部１２１３と、警告発信部１２１４と、事故事例データベース１２１５と、組織別事故誘発要因データベース１２１７と、事故種別別事故誘発要因データベース１２１８、警告データベース１２１９とを含む。インシデント管理サーバ１２１０において、事例登録部１２１１と、データ更新部１２１２と、事故リスク検出部１２１３と、警告発信部１２１４とは、図２に示すメモリ２０３またはストレージ２０２に備えられる。また、事故事例データベース１２１５と、組織別事故誘発要因データベース１２１７と、事故種別別事故誘発要因データベース１２１８と警告データベース１２１９は、図２に示すストレージ２０２に格納される。
【００６１】
クライアント１２２０は、実施形態１と同様に事例入力部を含む。
【００６２】
クライアント１２２１は、実施形態１と同様に警告受信部を含む。
【００６３】
事例登録部１２１２と、警告発信部１２１４は、それぞれ事例登録部１１２と、警告発信部１１４と同等の機能を有する。事故事例データベース１２１５と、組織別事故誘発要因データベース１２１７と、事故種別別事故誘発要因データベース１２１８は、それぞれ事故事例データベース１１５と、組織別事故誘発要因データベース１１７と、事故種別別事故誘発要因データベース１１８と同等の機能を有する。
【００６４】
警告データベース１２１９のデータ構造は警告データベース１１９と同様である。ただし、警告データベース１２１９では、フィールド７０４に該当するフィールドは、抜けもれの可能性のある事故誘発要因を表す。
【００６５】
次に、図面を用いて本実施形態の処理の詳細を説明する。本実施形態の処理は大別すると、事例登録部１２１１による事例登録、データ更新部１２１２によるデータ更新、誘発要因評価部１２１３による誘発要因評価、警告発信部１２１４による警告発信の４つの処理からなる。
【００６６】
図１３を用いて、データ更新部１２１２の処理を説明する。本処理では、事故事例データベース１２１５に登録されたデータを用いて、組織別事故誘発要因データベース１２１７、事故種別別事故誘発要因データベース１２１８を更新する。実施形態１と実施形態２におけるデータ更新部の違いは、組織別事故種別データの更新を行うか行わないかであり、１３０１、１３０３、１３０４は、９０１、９０３、９０４と同様である。
【００６７】
本処理は、前回処理を行ってから所定の時間が経過した場合に起動される。ただし、起動タイミングはこの限りではなく、誘発要因分析評価システム１２００の管理者が任意の時点で起動する、あるいは事故事例データベース１２１５が更新された場合、あるいは事故事例データベース１２１５に新たに格納されたレコード件数が所定の値に達した場合等でも良い。
【００６８】
図１４を用いて、誘発要因評価部１２１３の処理を説明する。本処理では、事故事例データベース１２１５、組織別事故誘発要因データベース１２１７、事故種別別事故誘発要因データベース１２１８を用いて、事故事例データベース１２１５に登録された事故の事故誘発要因分析結果の抜けもれの可能性を抽出する。本処理は、データ更新処理終了後に起動される。ただし、起動タイミングはこの限りではなく、インシデント管理システム１２００の管理者が任意の時点で起動する、あるいは前回処理を行ってから所定の時間が経過した場合、あるいは事故事例データベース１２１５に新たに格納されたレコード件数が所定の値に達した場合等でも良い。
【００６９】
データ更新部において、データ更新が行われなかった場合は、誘発要因評価の処理を終了する。
【００７０】
１４０１では、誘発要因評価を行う事例を選出する。具体的には、テーブル３００から評価を行うレコードを一つ選出する。以下では、選出したレコードを評価対象レコードと呼ぶ。
【００７１】
１４０２では、組織別事故誘発要因データベース１２１７から、評価対象レコードの組織が持つ事故誘発要因のレコードを選出する。具体的には、テーブル５００のフィールド５０１を参照して、評価対象のフィールド３０２と一致するレコードを検索する。
【００７２】
１４０３では、事故種別別事故誘発要因データベース１２１８から、評価対象レコードの事故種別が持つ事故誘発要因のレコードを選出する。具体的には、テーブル６００のフィールド６０１を参照して、評価対象のフィールド３０３と一致するレコードを検索する。
【００７３】
１４０４では、評価対象レコードのフィールド３０４と、１４０２、１４０３で検索したレコードの各フィールド値とを比較し、評価対象レコードの事故誘発要因の抜けもれを判定する。具体的には、１４０２および１４０３で検索したレコードにおいてフィールド値が１となっている事故誘発要因が、評価対象レコードのフィールド３０４に格納されているかどうかを判定する。抜けもれの可能性のある事故誘発要因が存在する場合（判定結果がＹＥＳの場合）には、１４０５へ進み、抜けもれの可能性のある事故誘発要因が存在しない場合（判定結果がＮＯの場合）には、１４０６へ進む。
【００７４】
１４０５では、抜けもれの可能性があると判定された事故誘発要因情報を警告データベースに格納する。具体的には、フィールド７０２、７０３、７０４にそれぞれ、組織、事故種別、抜けもれのある事故誘発要因を格納する。 
１４０６では、テーブル３００に格納されている全ての事例を探索したかどうかを判定する。全ての事故種別、全ての組織の探索が済んでいない場合（１４０６の判定がＮＯの場合）は、１４０１へ戻る。全ての事故種別、全ての組織の探索が終了した場合（１４０６の判定がＹＥＳの場合）は、処理を終了する。
【００７５】
以上が誘発要因評価の処理の詳細である。
【００７６】
本実施形態によれば、事故種別ごと、あるいは組織ごとにまとめた事故誘発要因と１件の事故の事故誘発要因とを比較し、事故誘発要因の分析の抜けもれの可能衛を指摘することで、事例入力者の事故分析能力を高めることが可能になる。
【符号の説明】
【００７７】
１００    インシデント管理システム
１１１    事例登録部
１１２    データ更新部
１１３    事故リスク検出部
１１４    警告発信部
１１５    事故事例データベース
１１６    組織別事故種別データベース
１１７    組織別事故誘発要因データベース
１１８    事故種別別事故誘発要因データベース
１１９    警告データベース
１２０    クライアント
２０１    ＣＰＵ（制御部）
２０２    ストレージ（記憶部）
２０３    メモリ（記憶部）
２０４    入力装置（入力部）
２０５    出力装置（表示部）
２０６    通信装置
２０７    内部通信線
【図１】
2011258088.tif 000004
【図２】
2011258088.tif 000005
【図３】
2011258088.tif 000006
【図４】
2011258088.tif 000007
【図５】
2011258088.tif 000008
【図６】
2011258088.tif 000009
【図７】
2011258088.tif 000010
【図８】
2011258088.tif 000011
【図９】
2011258088.tif 000012
【図１０】
2011258088.tif 000013
【図１１】
2011258088.tif 000014
【図１２】
2011258088.tif 000015
【図１３】
2011258088.tif 000016
【図１４】
2011258088.tif 000017