JP6473059B2 - 査定装置、査定方法、および査定プログラム - Google Patents

Description

本発明は、査定装置、査定方法、および査定プログラムに関する。

一般に、損害保険の保険料は、将来生ずる被害額を補償するために、事前にリスク分析を行って得られた統計情報に、利用状況を照らして被害額を推定することにより査定される。例えば、自動車の事故で生ずる被害額を補償する損害保険料を、過去の多数の事故データを用いてリスク分析し、個々の車両の走行時間や走行ルート等の利用状況を正確に把握することにより査定に利用する技術が知られている（特許文献１参照）。

一方、自然災害等の災害による被害額を補償する損害保険の保険料については、災害そのものがごくまれにしか発生せず、リスク分析が困難であった。そこで、被保険者の防災状況等を防災設備投資の有無や災害訓練の有無等のごく粗い事象の聞き取り調査で把握した情報のみに基づいて、損害保険料が査定されていた。

特開２００５−３２７２０９号公報

しかしながら、自然災害等の災害による被害額は、災害の種別や大きさ、事前の防災設備投資の有無のみで決まるものではなく、災害対応者の熟達度や迅速性、精確性等の運用品質により大きく異なる。一方で、そのような運用品質を客観的に把握することは困難であった。

本発明は、上記に鑑みてなされたものであって、災害による被害額を補償する損害保険の保険料を、運用品質を加味して査定することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る査定装置は、災害による被害額を補償する損害保険の保険料を査定する査定装置であって、損害保険での査定利用対象の災害に備えた平常時の運用に関するログ情報と、運用品質を判定するための判定基準と、該運用品質に応じた保険料を算定するための算定基準とを記憶する記憶部と、前記ログ情報と前記判定基準とを用いて運用品質を判定し、判定された運用品質と前記算定基準とを用いて保険料を算定する査定部と、を備えることを特徴とする。

本発明によれば、災害による被害額を補償する損害保険の保険料を、平常時の運用品質を加味して査定することができる。

図１は、本発明の一実施形態に係る査定装置を含む運用管理システムの概略構成を示す模式図である。 図２は、本実施形態の活動ログを例示する図である。 図３は、本実施形態の活動ログを例示する図である。 図４は、本実施形態の運用コミットメント定義を例示する図である。 図５は、本実施形態の運用コミットメント定義を例示する図である。 図６は、本実施形態の保険コミットメント定義を例示する図である。 図７は、本実施形態の保険コミットメント定義を例示する図である。 図８は、本実施形態の運用品質の達成度合いの判定方法を説明するための説明図である。 図９は、本実施形態の査定処理手順を示すシーケンス図である。 図１０は、他の実施形態の査定装置を含む運用管理システムの概略構成を示す模式図である。 図１１は、査定プログラムを実行するコンピュータを示す図である。

以下、図面を参照して、本発明の一実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

本実施形態では、災害時において、災害対策本部や現場等の各所での連絡・指示内容や対応状況を示す大量の情報を可視化して管理することにより危機管理対応業務を支援する運用管理システムを損害保険での査定利用対象とする。なお、災害による被害額を補償する損害保険での査定利用対象は、災害に備えた平常時の業務やシステム等の運用に関するログ情報または準備状況を取得できるものでもよく、上記のような運用管理システムに限定されない。また、災害とは、地震や台風等の自然災害の他、サイバーテロ等の人的災害も含む緊急事態を意味する。

［運用管理システムの構成］
まず、図１を参照して、本実施形態に係る査定装置を含む運用管理システムの概略構成を説明する。本実施形態において、査定装置は、査定利用対象とする運用管理システム１０の管理装置と同一のハードウェアに組み込まれて構成されている。

運用管理システム１０は、管理装置としてのサーバ装置１と、災害対策本部等の危機管理対応業務を行う運用現場に設置される複数のクライアント端末２ａとを含んで構成され、災害対策業務等の危機管理対応業務を支援する。具体的に、サーバ装置１は、ワークステーションやパソコン等の汎用コンピュータ等で実現され、管理装置として、台風等の災害や、災害を想定した訓練等のインシデント毎に、各現場間の連絡内容や指示内容、各現場での対応状況等の情報を管理する。クライアント端末２ａは、パソコン等の汎用コンピュータで実現され、ＬＡＮ（Local Area Network）やインターネットなどの電気通信回線３を介して管理装置としてのサーバ装置１に接続して、サーバ装置１で管理されている情報を参照したり、各現場での対応状況や他の現場に対する連絡内容や指示内容を示す情報を入力したりする。

なお、本実施形態の運用管理システム１０には、保険会社等に設置されるクライアント端末２ｂが含まれる。このクライアント端末２ｂは、パソコン等の汎用コンピュータで実現され、ＬＡＮやインターネットなどの電気通信回線３を介して、査定装置としてのサーバ装置１に接続される。

サーバ装置１は、ワークステーションやパソコン等の汎用コンピュータないしスマートフォンやタブレット等のデバイス並びにクラウドシステム上の仮想化された計算機資源で実現され、入力部１１と、出力部１２と、通信制御部１３と、記憶部１４と、制御部１５とを備える。

入力部１１は、キーボードやマウス等の入力デバイスを用いて実現され、操作者による入力操作に対応して、制御部１５に対して各種指示情報を入力する。出力部１２は、液晶ディスプレイなどの表示装置、プリンター等の印刷装置、情報通信装置等によって実現され、後述する分析処理の結果等を操作者に対して出力する。通信制御部１３は、ＮＩＣ（Network Interface Card）等で実現され、ＬＡＮ（Local Area Network）やインターネットなどの電気通信回線を介したサーバ等の外部の装置と制御部１５との通信を制御する。

記憶部１４は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、活動ログ１４１と、運用情報１４２と、アクセス範囲定義１４３と、運用コミットメント定義１４４と、保険コミットメント定義１４５とを記憶する。

活動ログ１４１は、災害に備えた平常時の運用に関するログ情報であって、例えば、災害を想定した訓練等のインシデント毎の各運用現場での対応状況を示すアクティビティレコードの集合で表される。この活動ログ１４１には、危機管理対応のＢＣＰ（Business Continuity Plan；事業継続計画）関連の活動、例えば、ＢＣＰの作成、訓練、現状棚卸、対策費見直し等に関するログ情報が含まれてもよい。また、運用情報１４２は、活動ログ１４１の各インシデントレコードあるいはアクティビティレコードに関連付けされている文書、写真、映像等の情報マルチメディアデータを意味する。活動ログ１４１並びに運用情報１４２は、データベースとしての実装ないしはディレクトリー構造をもつファイルシステムないしは両者の組み合わせでもよい。

図２は、活動ログ１４１に含まれる複数のインシデントレコードを例示している。また、図３は、図２に例示した各インシデントレコードに含まれる複数のアクティビティレコードを例示している。例えば、後述する査定処理において、図２に示した複数のインシデントの１つが選択された場合、図３に示すように、選択されたインシデントに含まれる複数のアクティビティレコードが参照され、査定者向けに提示する情報の作成に利用される。

ここで、各インシデントレコードは、例えば、図２に示すように、インシデントＩＤ、設定者ＩＤ、管理グループＩＤ、設定日、終了日、ステータス、緊迫度、インシデント名称、レコード数、およびフォトデータ等個数等の情報を含む。インシデントＩＤとは、各インシデントを識別する情報を意味する。設定者ＩＤとは、インシデント情報を生成した設定者を識別する情報を意味し、管理グループＩＤとは、設定者が属する組織を識別する情報を意味する。設定日とは、各インシデントを設定者が設定した日を意味し、終了日とは、各インシデントに対する各運用現場での対応が完了した日を意味する。ステータスとは、各インシデントの状態を意味し、完了またはオープンで表される。

緊迫度とは、各インシデントの属性を意味し、訓練、発災、シミュレーション、平時利用等が例示される。ここで、訓練とは、想定された災害に対する訓練活動を意味し、発災とは、災害の発生を意味し、シミュレーションとは、過去の災害を再現した活動を意味し、平時利用とは、災害に対する備えに含まれない平常時の活動を意味する。インシデント名称は、各インシデントの内容を総括して表す名称であり、例えば、「［発災］台風９９号による東京湾高潮０８０８」が例示される。レコード数とは、各インシデントレコードに含まれるアクティビティレコード数を意味する。フォトデータ等個数とは、運用情報１４２に含まれるデータの個数を意味する。

また、各アクティビティレコードは、例えば、図３に示すように、ＩＤ、Ｔａｓｋ＿ＩＤ、Ｏｒｇ＿ＩＤ、レイヤー、依頼日時、依頼元、依頼先、件名、内容、重要度、緊急度、対応状況、更新日時、対応開始日時、対応完了日時、および回答等の情報を含む。ＩＤとは、各インシデントにおいて各アクティビティレコードを識別する情報を意味する。Ｔａｓｋ＿ＩＤとは、インシデントを識別する情報を意味する。Ｏｒｇ＿ＩＤとは、各アクティビティレコードを生成した組織を識別する情報を意味する。レイヤーとは、インシデントにおける階層を意味する。

依頼日時、依頼元および依頼先とは、それぞれ対応を依頼する日時、依頼の発信元の組織、依頼の宛先の組織を意味する。件名は、依頼内容を総括して表す件名であり、例えば、「避難所の開設準備について」が例示される。内容とは、依頼内容を意味し、例えば、「暗くなるまでに、○○地区への避難勧告を出す準備を進めたいと思います。○○地区の避難所の開設準備を進め、完了報告をお願いします。」等が例示される。重要度および緊急度は、それぞれ各アクティビティレコードの内容の重要度、緊急度が高いか否かを示し、例えば、図３の例では、重要度、緊急度が高いものに★印が付与されている。対応状況は、依頼に対する各宛先組織での対応状況を意味し、例えば、対応中、未対応、対応完了等で表される。更新日時、対応開始日時、対応完了日時は、それぞれ、アクティビティレコードを更新した日時、依頼に対する宛先組織で対応を開始した日時、対応が完了した日時を表す。回答とは、依頼に対する宛先組織の回答を意味する。

なお、活動ログ１４１と運用情報１４２とは、後述するように、管理装置としてのサーバ装置１により収集され、記憶部１４に格納される。

アクセス範囲定義１４３は、査定装置の利用者、すなわち、運用現場の外部である保険会社等に設置されるクライアント端末２ｂが利用できる範囲を示す。アクセス範囲定義１４３には、例えば、活動ログ１４１の各アクティビティレコードの依頼日時と対応完了日時のみ、というように、クライアント端末２ｂからアクセス可能な情報やアクセス可能な範囲が設定される。アクセス範囲定義１４３には、各情報それぞれについての閲覧条件が付加されてもよい。このアクセス範囲定義１４３は、例えば、運用現場および保険会社等の双方により適正に設定される。

運用コミットメント定義１４４は、運用品質を判定するための判定基準すなわち平常時の運用目標を表す。運用コミットメント定義１４４には、訓練や平時利用に関する運用品質の目標値が設定される。例えば、図４に例示するように、訓練に関して、運用現場で実施する訓練の回数や規模の目標値、平均応答時間や対応漏れ率等の訓練品質の目標値等が定義される。図４では、例えば、訓練の年間訓練回数は４回、訓練品質として平均応答時間は５分以下とする等の目標値が定義されている。この運用コミットメント定義１４４には、ＢＣＰ導入の有無や、ＢＣＰの作成、訓練、現状棚卸、対策費見直し等のＢＣＰ関連の活動の目標値が含まれてもよい。これにより、ＢＣＰ導入の有無やＢＣＰ関連の活動が運用品質として判定され得る。なお、運用コミットメント定義１４４は、具体的には、図５に例示するように記述される。この運用コミットメント定義１４４は、予め、例えば、災害対策本部等の運用現場により設定される。

保険コミットメント定義１４５は、運用品質に応じた保険料を算定するための算定基準すなわち運用目標の達成度合いに応じた保険料の算定方法を表す。保険コミットメント定義１４５には、例えば、図６に例示するように、各運用品質の目標値に対する達成度合いの判定値ごとの保険料の割引率が定義される。図６では、例えば、訓練品質がＡクラスの場合に保険料の割引率を−２．５％とすること、すなわち、保険料を２．５％割り引くことが定義されている。なお、図６において、割引率のマイナス表記は割り引きを意味し、プラス表記は割り増しを意味する。

また、図６には、保険料の基本査定価格に対する割引率は、例えば、割引条件ごとの割引率の数値を合計して算定する、とする割引決定法が定義されている。例えば、割引条件Ａ（訓練の良好さ）、割引条件Ｂ（訓練品質）、割引条件Ｃ（平時利用の良好さ）、割引条件Ｄ（平時利用品質）の各割引率が−２．５％，−２．５％，０％，３％と判定された場合に、保険料の基本査定価格に対する割引率は、−２．５％＋（−２．５）％＋０％＋３％＝−２％と算定される。

なお、保険コミットメント定義１４５は、具体的には、図７に例示するように記述される。この保険コミットメント定義１４５は、予め、例えば保険会社により設定される。

制御部１５は、ＣＰＵ（Central Processing Unit）等の演算処理装置がメモリに記憶された処理プログラムを実行することにより、図１に例示するように、管理部５１および査定部５２として機能する。

管理部５１は、インシデント管理部５１１と、ユーザ管理認証部５１２とを含み、管理装置としての入力部１１、出力部１２、通信制御部１３、および記憶部１４の各構成部を制御する。

インシデント管理部５１１は、台風等の災害や、災害を想定した訓練等のインシデントごとの各運用現場間の連絡内容や指示内容、各運用現場での対応状況等の情報の入力を受け付け、活動ログ１４１として記憶部１４に格納する。

ユーザ管理認証部５１２は、管理装置の利用者、すなわち、災害対策本部等の運用現場等に設置されるクライアント端末２ａを認証する。ユーザ管理認証部５１２は、例えば、予め設定されたパスワード等の認証情報を用いて、クライアント端末２ａの認証を行う。

査定部５２は、査定者認証部５２１と、査定情報参照部５２２と、自動査定部５２３と、フィードバック部５２４とを含み、査定装置としての入力部１１、出力部１２、通信制御部１３、および記憶部１４の各構成部を制御する。これにより、査定部５２は、運用管理システム１０の平常時の運用に関するログ情報すなわち活動ログ１４１を用いて、災害による被害額を補償する損害保険の保険料を査定する。

なお、査定部５２は、管理部５１とは別のハードウェアの査定装置として構成してもよい。その場合、この査定装置は、適宜なタイミングで通信制御部を介して管理装置としてのサーバ装置１と通信し、災害に備えた平常時の運用に関するログ情報すなわち活動ログ１４１を取得して、査定装置の記憶部に格納する。

査定者認証部５２１は、査定装置の利用者を認証する。具体的に、査定者認証部５２１は、保険会社等に設置されるクライアント端末２ｂを認証する。査定者認証部５２１は、例えば、予め設定されたパスワード等の認証情報を用いて認証を行う。査定者認証部５２１は、厳密な認証情報による認証の他、時間制限や端末制限等を行ってもよい。これにより、運用現場とは異なる外部の保険会社に設置されたクライアント端末２ｂから、運用中の運用管理システム１の活動ログ１４１や運用コミットメント定義１４４等を参照することが可能となる。

査定情報参照部５２２は、保険会社等に設置されるクライアント端末２ｂに、アクセス範囲定義１４３を参照して記憶部１４の情報を参照させる。すなわち、査定情報参照部５２２は、アクセス範囲定義１４３を参照し、記憶部１４から読み込んだ活動ログ１４１や運用コミットメント定義１４４等の情報を用いて、例えば訓練品質としての平均応答時間や対応漏れ率等を算出し、その結果を保険会社等のクライアント端末２ｂに表示する。

なお、査定情報参照部５２２は、マスク処理部５２５を含んでもよい。マスク処理部５２５は、クライアント端末２ｂに提示する情報にマスク処理を施す。これにより、個人情報保護や営業秘密保持の観点から、固有名詞や特定名称を匿名化する。具体的に、例えば、クライアント端末２ｂに出力する際、文書解析技術等を用いて、０１２−３４５６−７８９０等の電話番号とパターンが合致する情報を、自動的に「電話番号」に変換する。あるいは、事前に指定された情報を出力する際にマスク処理を施すようにしてもよい。

自動査定部５２３は、活動ログ１４１と運用コミットメント定義１４４とを用いて運用品質を判定し、判定された運用品質と保険コミットメント定義１４５とを用いて保険料を算定する。具体的に、自動査定部５２３は、活動ログ１４１に示される平常時の運用状況の運用コミットメント定義１４４の運用目標に対する達成度合いを判定し、判定された達成度合いに応じた保険料を保険コミットメント定義１４５を用いて算定する。

例えば、自動査定部５２３は、図４に例示した運用コミットメント定義１４４で定義される運用目標のうち、平均応答時間、最長応答時間、および３０分間の対応漏れ率で定義される訓練品質について、以下のように判定する。すなわち、自動査定部５２３は、以下に例示するように、予め設定された観点１〜３の１つまたは複数を用いて、活動ログ１４１に示される運用状況の運用目標に対する達成度合いを判定する。

観点１：平均応答時間が目標値５分の１１０％より長ければＣクラスと判定する。平均応答時間が目標値の８０％より短ければＡクラスと判定する。平均応答時間が目標値の８０％〜１１０％の間であればＢクラスと判定する。

観点２：平均応答時間が目標値の１１０％より長ければＣクラスと判定する。平均応答時間が目標値の８０％より短ければＡクラスと判定する。平均応答時間が目標値の８０％〜１１０％の間であればＢクラスと判定する。ただし、最長応答時間が目標値２０分を超えればＣクラスと判定する。

観点３：平均応答時間が目標値の１１０％より長ければＣクラスと判定する。平均応答時間が目標値の８０％より短ければＡクラスと判定する。平均応答時間が目標値の８０％〜１１０％の間であればＢクラスと判定する。ただし、３０分間の対応漏れ率が目標値０％を下回ればＣクラスと判定する。

そして、自動査定部５２３は、図８に例示する判定表を参照して、訓練品質の運用目標に対する達成度合いを判定する。図８の判定表では、例えば、観点１による判定がＡ、観点２による判定がＢ、観点３による判定がＢの場合に、訓練品質の運用目標に対する達成度合いはＢと判定される。

なお、運用品質の運用目標に対する達成度合いの判定法については、上記に限定されない。例えば、判定表に代えて、判定対象の運用品質に応じて、２次元グラフ、折れ線グラフ、数式等を用いて判定できる。

フィードバック部５２４は、自動査定部５２３が判定した査定結果を損害保険での査定利用対象である運用管理システム１０の運用者や保険会社の査定者等に出力する。具体的に、フィードバック部５２４は、算定された保険料を運用現場のクライアント端末２ａに出力する。フィードバック部５２４は、併せて保険会社等のクライアント端末２ｂに査定結果を出力する。その際、フィードバック部５２４は、算定された保険料の代わりに、あるいは算定された保険料に併せて、保険料の割引率を出力してもよい。フィードバック部５２４は、査定結果に併せて、運用品質の判定結果を出力してもよい。これにより、運用現場でも運用品質を客観的に把握して運用品質の向上を図ることができる。

［査定処理］
次に、図９のシーケンス図を参照して、査定部５２よる査定処理手順について説明する。図９のシーケンス図は、例えば、保険会社等に設置されるクライアント端末２ｂが査定処理の開始を指示したタイミングで開始となる。

まず、クライアント端末２ｂが、査定部５２の査定者認証部５２１にアクセスする（ステップＳ１）。査定者認証部５２１がクライアント端末２ｂを認証したら（ステップＳ２）、査定情報参照部５２２が、記憶部１４を参照して（ステップＳ４）、アクセス範囲定義１４３を取得する（ステップＳ３）。次に査定情報参照部５２２は、アクセス範囲定義１４３に従って記憶部１４を参照して（ステップＳ６）、活動ログ１４１および運用コミットメント定義１４４を取得する。また、査定情報参照部５２２は、活動ログ１４１を用いて運用コミットメント定義１４４に定義されている訓練品質としての平均応答時間や対応漏れ率の算出等の事前加工を行う（ステップＳ５）。

次に、自動査定部５２３が、査定を実施する（ステップＳ７）。すなわち、自動査定部５２３が、活動ログ１４１と運用コミットメント定義１４４とを用いて運用品質を判定する。また、記憶部１４を参照して（ステップＳ８）、保険コミットメント定義１４５を取得して、判定された運用品質と保険コミットメント定義１４５とを用いて保険料を算定する。

そして、フィードバック部５２４が、運用現場のクライアント端末２ａ、保険会社等のクライアント端末２ｂに査定結果を出力するフィードバックを実施する（ステップＳ９）。運用現場のクライアント端末２ａおよび保険会社等のクライアント端末２ｂが出力された査定結果を確認する（ステップＳ１０，Ｓ１１）。これにより、一連の査定処理が終了する。

以上、説明したように、本実施形態の査定部５２では、記憶部１４が、損害保険での査定利用対象の災害に備えた平常時の運用に関する活動ログ１４１と、運用品質を判定するための判定基準である運用コミットメント定義１４４と、該運用品質に応じた保険料を算定するための算定基準である保険コミットメント定義１４５とを記憶し、自動査定部５２３が、活動ログ１４１と運用コミットメント定義１４４とを用いて運用品質を判定し、判定された運用品質と保険コミットメント定義１４５とを用いて保険料を算定する。

これにより、災害等の危機による被害額を補償する損害保険の保険料を、平常時の運用品質を加味して査定することができる。すなわち、平常時の運用目標等の運用に関する制度を柔軟に利用して判定ロジックを定義して、運用状況を精確に把握して運用品質を判定できる。したがって、災害に関する過去のデータに乏しくリスク分析を十分に行えなくても、災害に備えた運用品質に応じて保険料の割引等のきめ細かい査定を行って、低廉かつ適正な保険料を設定でき、さらに潜在顧客を取り込む市場拡大効果も期待できる。

また、査定情報参照部５２２が、損害保険での査定利用対象である運用管理システム１０の活動ログ１４１を運用中に任意の短い周期で収集し、随時、自動査定部５２３が損害保険料の査定を実施できる。また、査定者認証部５２１が、運用現場の外部である保険会社等の査定者のクライアント端末２ｂを認証し、運用現場に非公開の周期で損害保険料の査定を実施できる。さらに、査定情報参照部５２２は、保険会社等に開示するログ情報等のうちアクセス範囲定義１４３に設定されている範囲のみを開示する等の適切なセキュリティ対策を施すことができる。このクライアント端末２ｂを利用して、保険会社等が保険コミットメント定義１４５を設定できる。したがって、運用中の損害保険での査定利用対象について、運用品質と保険料算定基準との関係を運用現場に非公開にして、非公開かつ任意の短い周期で保険料の査定を実施できる。これにより、運用現場での恣意的な実績作り等を排除して査定精度の低下を回避できる。

また、運用現場に査定結果をフィードバックできるので、運用現場でも運用品質を客観的に把握して運用品質の向上を図る等、運用現場の運用者の行動に変革をもたらす効果が期待される。

なお、本実施形態の査定装置を用いて、多数の運用管理システム１０のそれぞれについての運用コミットメント定義１４４、保険コミットメント定義１４５、および査定結果等を収集するビッグデータ解析サーバ４を実現できる。例えば、図１０に例示するように、査定部５２に、ビッグデータ解析サーバ４の収集要求に応答するビッグデータユニット５２６を備えればよい。ビッグデータ解析サーバ４に収集された各運用管理システム１０の保険契約の状況に関する情報を解析することにより、各運用管理システム１０の運用状況の良否や類似点の分析や、保険料査定の根拠の分析を行える。これにより、より適正に保険コミットメント定義１４５を設定して、さらに精確に損害保険料の査定を行うことができる。

［他の実施形態］
［プログラム］
上記実施形態に係る査定部５２が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、係るプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、査定部５２と同様の機能を実現する査定プログラムを実行するコンピュータの一例を説明する。

図１１に示すように、査定プログラムを実行するコンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。ディスクドライブ１０４１には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１０５１およびキーボード１０５２が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１０６１が接続される。

ここで、図１１に示すように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０３１やメモリ１０１０に記憶される。

また、査定プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュール１０９３として、ハードディスクドライブ１０３１に記憶される。具体的には、上記実施形態で説明した査定部５２が実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０３１に記憶される。

また、査定プログラムによる情報処理に用いられるデータは、プログラムデータ１０９４として、例えば、ハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。

なお、査定プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、ログ判定プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述および図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例および運用技術等は全て本発明の範疇に含まれる。

１０ 運用管理システム
１ サーバ装置
１１ 入力部
１２ 出力部
１３ 通信制御部
１４ 記憶部
１４１ 活動ログ
１４２ 運用情報
１４３ アクセス範囲定義
１４４ 運用コミットメント定義
１４５ 保険コミットメント定義
１５ 制御部
５１ 管理部
５１１ インシデント管理部
５１２ ユーザ管理認証部
５２ 査定部
５２１ 査定者認証部
５２２ 査定情報参照部
５２３ 自動査定部
５２４ フィードバック部
５２５ マスク処理部
２ａ クライアント端末（運用現場）
２ｂ クライアント端末（保険会社等）
３ 電気通信回線

Claims (5)

1. 災害による被害額を補償する損害保険の保険料を査定する査定装置であって、
   損害保険での査定利用対象の災害に備えた平常時の運用に伴って動的に変化するログ情報と、運用品質を判定するための判定基準としての前記査定利用対象の平常時の運用目標と、該運用品質に応じた保険料を算定するための算定基準としての該運用目標の達成度合いに応じた保険料の算定方法とを記憶する記憶部と、
   前記ログ情報と前記判定基準とを用いて運用品質として前記ログ情報に示される平常時の運用状況の前記判定基準の運用目標に対する達成度合いを判定し、判定された運用品質と前記算定基準とを用いて判定された達成度合いに応じた保険料を算定する査定部と、
   を備えることを特徴とする査定装置。
2. 前記記憶部は、利用者が参照可能な情報の範囲示すアクセス範囲情報をさらに記憶し、
   前記利用者を認証する認証部と、
   認証された前記利用者に、前記アクセス範囲情報を参照して前記記憶部の情報を参照させる参照部と、
   をさらに備えることを特徴とする請求項１に記載の査定装置。
3. 前記査定部が算定した保険料を前記査定利用対象に対して出力するフィードバック部をさらに備えることを特徴とする請求項１または２に記載の査定装置。
4. 災害による被害額を補償する損害保険の保険料を査定する査定装置で実行される査定方法であって、
   前記査定装置は、損害保険での査定利用対象の災害に備えた平常時の運用に伴って動的に変化するログ情報と、運用品質を判定するための判定基準としての前記査定利用対象の平常時の運用目標と、該運用品質に応じた保険料を算定するための算定基準としての該運用目標の達成度合いに応じた保険料の算定方法とを記憶する記憶部を備え、
   前記ログ情報と前記判定基準とを用いて運用品質として前記ログ情報に示される平常時の運用状況の前記判定基準の運用目標に対する達成度合いを判定し、判定された運用品質と前記算定基準とを用いて判定された達成度合いに応じた保険料を算定する査定工程を含んだことを特徴とする査定方法。
5. コンピュータを請求項１〜３のいずれか１項に記載の査定装置として機能させるための査定プログラム。

Images