シナリオ情報管理システム及びプログラム
【課題】各金融機関が自前のシナリオ情報を創作するに際し、外部のシナリオ情報を参照可能とする。
【解決手段】金融機関のクライアント端末２３から送信された検索条件で共有シナリオ記憶部１７を検索し、共有シナリオ情報を抽出する手段と、検索結果画面を同端末２３に送信する手段と、同端末２３から特定の共有シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報と独自シナリオ情報とのマッチングを行い対応の独自シナリオ情報を抽出する手段と、マッチング結果画面を同端末２３に送信する手段と、同端末２３から独自シナリオの登録リクエストが送信された場合に、送信された独自シナリオ情報を独自シナリオ記憶部１４に格納する手段と、この独自シナリオ情報に基づいて共有シナリオ情報を生成し、共有シナリオ記憶部１７に格納する手段を備えたシナリオ情報管理システム１０。
【解決手段】金融機関のクライアント端末２３から送信された検索条件で共有シナリオ記憶部１７を検索し、共有シナリオ情報を抽出する手段と、検索結果画面を同端末２３に送信する手段と、同端末２３から特定の共有シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報と独自シナリオ情報とのマッチングを行い対応の独自シナリオ情報を抽出する手段と、マッチング結果画面を同端末２３に送信する手段と、同端末２３から独自シナリオの登録リクエストが送信された場合に、送信された独自シナリオ情報を独自シナリオ記憶部１４に格納する手段と、この独自シナリオ情報に基づいて共有シナリオ情報を生成し、共有シナリオ記憶部１７に格納する手段を備えたシナリオ情報管理システム１０。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はシナリオ情報管理システム及びプログラムに係り、特に、銀行業務に付随するオペレーショナルリスクの計量化に利用するシナリオ情報を、複数の銀行間で共有可能とする技術に関する。
【背景技術】
【０００２】
バーゼル銀行監督委員会によって勧告された「新しい自己資本比率規制（所謂バーゼルII）」により、各銀行は従来の信用リスク、市場リスクに加えて、オペレーショナルリスク（以下「オペリスク」）の量に見合った自己資本を確保することが求められるようになった（非特許文献１及び２参照）。具体的には、銀行が国際業務を取り扱うためには、信用リスク、市場リスク、オペリスクの合計金額に対する資本金額の比率を８％以上に維持する必要性が生じた。
ここでオペリスクとは、事務ミス、不正、法令違反、システム障害などの内部管理上の問題や、災害、テロ、犯罪などの外部要因により損失が発生するリスクを意味しており、新しい規制に対応するためには、自行のオペリスク量を具体的数値として算出することが求められる。
【０００３】
オペリスク量を算出するための方法として、バーゼルIIでは「基礎的手法（BIA）」、「粗利益配分手法（TSA）」、及び「先進的計測手法（AMA）」の３つが認定されている。
まず、「基礎的手法（BIA）」は粗利益の15％を一律にオペリスク量と認定するものであり、「粗利益配分手法（TSA）」は業務区分毎に異なる比率を粗利益に乗じてオペリスク量を算出するものである。
これに対し「先進的計測手法（AMA）」については具体的な算出手法が明確に規定されているわけではなく、自行の業務特性に適合した手法を構築することが銀行側に課せられている。
【０００４】
リスク量算出の容易さという点からは、基礎的手法あるいは粗利益配分手法が有利であるといえるが、このような定率を粗利益に乗ずる簡易的手法では、業務改善によってオペリスク量を減らしたとしても所要自己資本の低減効果が生じないため、より難易度の高い先進的計測手法を志向する金融機関が増えてきている。
【０００５】
現在、先進的計測手法の有力候補として、「損失分布手法」が多くの金融機関において試行されている。
これは、自行で過去に発生した内部損失情報（頻度及び金額）や、経験則に基づいて導出した仮想損失事例であるシナリオ情報（頻度及び金額）を多数準備し、これらを使ってモンテカルロシミュレーションにより１年間の事故頻度の分布と事故１件当たりの損失額の分布とを求め、この分布図上で１０００年に１度発生すると考えられる金額をオペリスク量と推定するものである。
【非特許文献１】企業における事業リスク管理の高度化への挑戦〜金融機関のオペレーショナル・リスク管理の手法と課題に学ぶ〜 インターネットURL:http://www.nri.co.jp/publicity/mediaforum/2010/pdf/forum124.pdf 検索日：平成２２年３月１１日
【非特許文献２】地方銀行におけるオペレーショナルリスク管理の方向性 インターネットURL:http://www.nri.co.jp/opinion/kinyu_itf/2010/pdf/itf_201001_5.pdf 検索日：平成２２年３月１１日
【発明の開示】
【発明が解決しようとする課題】
【０００６】
先進的計測手法の場合、上記のように明確な算出手法が存在しないため、算出結果であるオペリスク量の正当性を立証するためには、投入するデータの妥当性及び網羅性を確保することが不可欠といえるが、個別金融機関における内部損失データの量には自ずと限りがあり、またデータの種類についても業務内容に応じた偏りが存在している。さらに、過去に遭遇していないタイプの損失については算出結果に織り込むことができないという問題もある。
このため、実際には起こっていないが起こる可能性のある潜在的なリスクを洗い出し、その頻度と損失金額を仮定的に設定したシナリオ情報の活用が重要となってくる。
【０００７】
しかしながら、自行の業務に関係するシナリオ情報を各行が一から創作するのは極めて骨の折れる作業であり、高度の専門性を備えた多くの人員を配置させる必要が生じるため、経営基盤の脆弱な中小金融機関にとっては高いハードルとなっている。
もちろん、他行の実例を参考にできれば、一からシナリオ情報を創作する場合に比べて各行の負担を大幅に軽減することが可能となるが、秘匿性の高い機微情報を含んでおり、自行の恥部ともなる内部損失情報を外部に流出させることには大きな抵抗があるため、現実的ではなかった。
【０００８】
この発明は、このような現状を打開するために案出されたものであり、各金融機関が自前のシナリオ情報を創作するに際し、外部の情報を容易に参照することを可能とする技術の提供を目的としている。
【課題を解決するための手段】
【０００９】
上記の目的を達成するため、請求項１に記載したシナリオ情報管理システムは、少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、金融機関の規模を表す抽象表現を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた共有シナリオ情報を、共有シナリオIDに関連付けて格納する共有シナリオ記憶手段と、少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた独自シナリオ情報を、金融機関固有の独自シナリオIDに関連付けて格納する独自シナリオ記憶手段と、加盟金融機関のクライアント端末に対し、共有シナリオ情報の検索画面を送信し、検索条件の入力を促す手段と、クライアント端末から検索条件が送信された場合に、この検索条件をキーに上記共有シナリオ記憶手段を検索し、該当する共有シナリオ情報を抽出する手段と、抽出された共有シナリオ情報が記載された検索結果画面を生成し、クライアント端末に送信する手段と、クライアント端末から、抽出された共有シナリオ情報と自社の独自シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報の特定のデータ項目の値と、各独自シナリオ情報の該当のデータ項目の値とを比較して、対応の独自シナリオ情報を抽出する手段と、マッチング結果が記載されたマッチング結果画面を生成し、クライアント端末に送信する手段と、クライアント端末から独自シナリオの登録リクエストが送信された場合に、少なくともイベントタイプ、業務区分、損失種別、損失金額、発生頻度の入力項目が設けられた独自シナリオ登録画面を生成し、クライアント端末に送信する手段と、クライアント端末から独自シナリオ情報を構成する入力データが送信された場合に、これを当該金融機関固有の独自シナリオIDに関連付けて上記独自シナリオ記憶手段に格納する手段と、金融機関毎にそれぞれの規模を表す抽象表現が登録された記憶手段を参照して、この独自シナリオ情報に対して当該金融機関の規模を表す抽象表現を付加した共有シナリオ情報を生成し、上記共有シナリオ記憶手段に格納する共有シナリオ生成手段を備えたことを特徴としている。
上記の「オペレーショナルリスクの内容を表す文字列」とは、例えば「業務上横領」、「着服」、「詐欺」、「システム障害」、「地震」、「テロ」、「銀行強盗」、「クーデター」等、銀行業務の障害となり得る事象を示す用語を意味している（以下同様）。
【００１０】
請求項２に記載したシナリオ情報管理システムは、請求項１のシステムであって、さらに上記共有シナリオ生成手段が、人名辞書及び企業名辞書を参照して、上記独自シナリオ情報中に個人名または具体的企業名が含まれているか否かを判定し、含まれている場合にはこれを抽象的な人名表現（「甲」等）または企業名表現（「Ａ社」等）に変換する処理を実行することを特徴としている。
【００１１】
請求項３に記載したシナリオ情報管理システムは、請求項１または２のシステムであって、さらに、具体的な表現文字列と、その種類を示す抽象化文字列との対応関係を登録した辞書を格納する記憶手段と、電子化された記事データを形態素に分解する手段と、上記辞書を参照し、各形態素の中で少なくとも金融機関名、金額、オペレーショナルリスクの内容を表す文字列に対して、対応の抽象化タグを付与する手段と、この抽象化タグが付与された記事データを格納しておく記事データ記憶手段と、記事データ中の各文に含まれる抽象化タグの組合せ、あるいは抽象化タグと特定の文字列との組合せ毎に、シナリオ情報の構成要素として抽出すべき文字列を規定した抽出ルールを、予め複数格納しておく抽出ルール記憶手段と、上記の記事データに上記抽出ルールを適用することにより、少なくとも金融機関名を表す文字列、金額を表す文字列、オペレーショナルリスクの内容を表す文字列をシナリオ情報の構成要素として抽出する手段と、抽象化タグが付与された文字列の構成に応じて、当該シナリオのイベントタイプを判定するためのイベントタイプ判定ルールを、予め複数格納しておく記憶手段と、上記記事データにおける抽象化タグの付与された文字列の構成を上記イベントタイプ判定ルールに適用し、当該シナリオのイベントタイプを判定する手段と、抽象化タグが付与された文字列の構成に応じて、当該シナリオの損失種別を判定するための損失種別判定ルールを、予め複数格納しておく記憶手段と、上記記事データにおける抽象化タグの付与された文字列の構成を上記損失種別判定ルールに適用し、当該シナリオの損失種別を判定する手段と、各金融機関の業務区分を格納しておく記憶手段と、この記憶手段を参照し、上記金融機関の業務区分を特定する手段と、上記のイベントタイプ、損失種別、業務区分、金融機関名、金額、オペレーショナルリスクの内容を表す文字列を含むシナリオ情報を生成する手段と、このシナリオ情報を上記共有シナリオ記憶手段に格納する手段とを備えたことを特徴としている。
【００１２】
請求項４に記載したシナリオ情報管理プログラムは、コンピュータを、少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、金融機関の規模を表す抽象表現を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた共有シナリオ情報を、共有シナリオIDに関連付けて格納する共有シナリオ記憶手段、少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた独自シナリオ情報を、金融機関固有の独自シナリオIDに関連付けて格納する独自シナリオ記憶手段、加盟金融機関のクライアント端末に対し、共有シナリオ情報の検索画面を送信し、検索条件の入力を促す手段、クライアント端末から検索条件が送信された場合に、この検索条件をキーに上記共有シナリオ記憶手段を検索し、該当する共有シナリオ情報を抽出する手段、抽出された共有シナリオ情報が記載された検索結果画面を生成し、クライアント端末に送信する手段、クライアント端末から、抽出された共有シナリオ情報と自社の独自シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報の特定のデータ項目の値と、各独自シナリオ情報の該当のデータ項目の値とを比較して、対応の独自シナリオ情報を抽出する手段、マッチング結果が記載されたマッチング結果画面を生成し、クライアント端末に送信する手段、クライアント端末から独自シナリオの登録リクエストが送信された場合に、少なくともイベントタイプ、業務区分、損失種別、損失金額、発生頻度の入力項目が設けられた独自シナリオ登録画面を生成し、クライアント端末に送信する手段、クライアント端末から独自シナリオ情報を構成する入力データが送信された場合に、これを当該金融機関固有の独自シナリオIDに関連付けて上記独自シナリオ記憶手段に格納する手段、金融機関毎にそれぞれの規模を表す抽象表現が登録された記憶手段を参照して、この独自シナリオ情報に対して当該金融機関の規模を表す抽象表現を付加した共有シナリオ情報を生成し、上記共有シナリオ記憶手段に格納する共有シナリオ生成手段として機能させることを特徴としている。
【発明の効果】
【００１３】
請求項１に記載のシナリオ情報管理システム及び請求項４に記載のシナリオ情報管理プログラムによれば、各金融機関が自行独自のシナリオ情報を作成する際に、他の金融機関の独自シナリオ情報に基づいて生成された共有シナリオ情報を参照することが可能となり、独自シナリオ作成の効率化が図れる。
また、特定の共有シナリオ情報に対応する独自シナリオが存在しているか否かがマッチング結果画面を通じて確認でき、対応の独自シナリオが存在しない場合には共有シナリオ情報に基づいて独自シナリオ情報を作成・登録できるため、金融機関は自行の独自シナリオ情報の網羅性を高めることが可能となる。
しかも、独自シナリオ情報が新規登録されると、これに基づいて新たな共有シナリオ情報が生成され、共有シナリオ情報記憶手段に追加されるため、共有シナリオ情報を常時アップデートすることができる。
【００１４】
請求項２に記載のシナリオ情報管理システムによれば、独自シナリオ情報中に個人名や具体的企業名が含まれていても、自動的に抽象的な表現に変換されるため、独自シナリオを提供した金融機関の機密保持が可能となる。
【００１５】
請求項３に記載のシナリオ情報管理システムによれば、電子化された新聞等の記事データから、自動的にイベントタイプ、業務区分、損失種別、金融機関名、オペレーショナルリスクの内容を表す文字列、金額が抽出され、これらの構成要素を備えたシナリオ情報が共有シナリオ情報の一種として共有シナリオ記憶手段に格納されるため、共有シナリオ情報の網羅性を高めることが可能となる。
【発明を実施するための最良の形態】
【００１６】
図１は、この発明に係るシナリオ管理システム10の機能構成を示すブロック図であり、Webサーバ12と、独自シナリオ管理部13と、独自シナリオ記憶部14と、シナリオ加工部15と、辞書情報記憶部16と、共有シナリオ記憶部17と、シナリオ管理情報記憶部18と、シナリオ検索部19とから構成されている。
【００１７】
上記の独自シナリオ管理部13、シナリオ加工部15、シナリオ検索部19は、コンピュータのCPUが、OS及びアプリケーションプログラムに従って必要な処理を実行することによって実現される。
また、上記の独自シナリオ記憶部14、辞書情報記憶部16、共有シナリオ記憶部17、シナリオ管理情報記憶部18は、同コンピュータのハードディスク内に設けられている。
【００１８】
独自シナリオ記憶部14内には、このシステム10に加盟している各金融機関固有のシナリオ情報が、金融機関単位で登録されている。
図２(a)は独自シナリオのデータ構造を示すものであり、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口…）、金額、発生頻度、業務改善策、日付のデータ項目を少なくとも備えている。
【００１９】
共有シナリオ記憶部17内には、このシステム10に加盟している各金融機関が共有しているシナリオ情報が登録されている。
図２(b)は共有シナリオのデータ構造を示すものであり、独自シナリオ情報と同様、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口…）、金額、発生頻度、業務改善策、日付のデータ項目を少なくとも備えている。
【００２０】
上記Webサーバ12は、インターネットを介して複数のクライアント端末23と接続されており、各クライアント端末23から送信されたリクエストに応じて独自シナリオ管理部13やシナリオ検索部19に処理を依頼し、その処理結果を記載した各種画面（Htmlファイル）をクライアント端末に送信する機能を備えている（詳細は後述）。
クライアント端末23は、Webブラウザプログラムを搭載したＰＣよりなり、各金融機関の担当者（以下「ユーザ」）が操作している。
【００２１】
上記共有シナリオ記憶部17には、外部シナリオ生成システム30が接続されており、この外部シナリオ生成システム30から送信された外部シナリオ情報が共有シナリオ記憶部17に格納される（詳細は後述）。
外部シナリオ生成システム30は上記Webサーバ12とも接続されており、クライアント端末23からのリクエストに応じて、外部シナリオ生成システム30からWebサーバ12に対して外損記事データが送信される（詳細は後述）。
【００２２】
つぎに、図３及び図４のフローチャートに従い、このシナリオ管理システム10における処理手順を説明する。
まず、クライアント端末23から共有シナリオ検索のリクエストをWebサーバ12が受信すると（Ｓ10）、共有シナリオ検索画面をクライアント端末23に送信する（Ｓ12）。
【００２３】
図５は、この共有シナリオ検索画面40を示すものであり、ユーザが「前回ログイン時から現在までの新規共有シナリオをチェック」の選択肢のラジオボタン41にチェックを入れて検索ボタン42をクリックすると、この検索条件がWebサーバ12に送信される。
【００２４】
これを受けたWebサーバ12は（Ｓ14）、内部に保持している当該ユーザのログイン履歴情報から前回ログイン日時を取り出してシナリオ検索部19に送信し、当該日時以降に登録された共有シナリオの検索を依頼する。
【００２５】
これに対しシナリオ検索部19は、共有シナリオ記憶部17から検索条件にマッチする共有シナリオ情報を抽出し（Ｓ16）、Webサーバ12に送信する。
Webサーバ12は、この検索結果が記載された検索結果画面を生成し、クライアント端末23に送信する（Ｓ18）。
【００２６】
図６(a)は、この検索結果画面44を示すものであり、ヒットした２件の共有シナリオが表示されている。
この検索結果リスト45には、各共有シナリオのイベントタイプ、業務区分、損失種別、金融機関（金融機関の規模に応じた類型）、金額が表示されているため、ユーザはこれらの情報に基づいて自行にとっての必要性を判断する。
例えば、ユーザの所属金融機関が地方銀行の類型に該当する場合、「メガバンクに係る共有シナリオは不要である」と判断したり、「自行が取り扱っていない業務区分の共有シナリオは不要である」と判断したりできる。
【００２７】
リスト中に表示された情報では不足の場合、ユーザは共有シナリオのチェックボックスにチェックを入れて詳細閲覧ボタン46をクリックし、当該共有シナリオの詳細画面の表示をリクエストする。
この結果、図示は省略したが、Webサーバ12から当該共有シナリオに含まれる全データが記述された詳細画面がクライアント23に送信され、Webブラウザ上に表示される。
【００２８】
詳細に内容を検討した結果、NO.２の共有シナリオが自行にとって必要であると判断したユーザは、そのチェックボックスにチェックを入れ、マッチングボタン47をクリックする。
この結果、自行の独自シナリオとのマッチングリクエストがWebサーバ12に送信される。
【００２９】
これを受けたWebサーバ12は（Ｓ19）、ユーザが選択した共有シナリオのIDと、ユーザの所属する金融機関の識別情報をシナリオ検索部19に送信し、マッチングを依頼する。
【００３０】
これに対しシナリオ検索部19は、指定された共有シナリオに対応する独自シナリオが、独自シナリオ記憶部14内に存在しているか否かを判定し、存在している場合にはこれを抽出するマッチング処理を実行する（Ｓ22）。
【００３１】
まずシナリオ検索部19は、独自シナリオ記憶部14から当該ユーザの属する金融機関に係る独自シナリオを取り出す。
つぎにシナリオ管理部19は、ユーザが選択した共有シナリオの所定の比較対象項目と、各独自シナリオの所定の比較対象項目同士を比較し、一定基準以上の一致率に達した独自シナリオを対応シナリオと認定する。また、一定基準以上の一致率に達した独自シナリオが存在しない場合、「該当シナリオなし」と判定する。
【００３２】
比較対象項目としては、例えばイベントタイプ、業務区分、損失種別が該当し、これらのすべてが一致した場合に、共有シナリオと独自シナリオとの一致が認定される。
比較対象項目として、キーワード中の幾つかの項目（例えば「手口」や「容疑」）、あるいは金額を加えることもできる。
【００３３】
また、すべての項目の値が完全一致した場合にのみ、共有シナリオと独自シナリオ間の一致と認定する代わりに、全比較対象項目中で所定数以上一致した場合に両シナリオ間の一致を認定するように運用することもできる。
【００３４】
あるいは、各比較対象項目に重要度に応じたポイントを付与しておき、一致した項目のポイントの合計値が所定の閾値を越えた独自シナリオを共有シナリオの対応シナリオ（類似シナリオ）として認定することもできる。このように、共有シナリオに対する各独自シナリオの一致度が数値化される場合には、一致度を示す数値の大きい順に所定数の独自シナリオをリスト表示させてもよい。
【００３５】
シナリオ検索部19から、「対応の独自シナリオなし」の判定結果を受けたWebサーバ12は（Ｓ24／Ｙ）、このマッチング結果が記載されたマッチング結果（該当なし）画面を生成し、クライアント端末23に送信する（Ｓ26）。
【００３６】
この結果、図６(b)に示すように、マッチング結果（該当なし）画面50がクライアント端末23のWebブラウザ上に表示される。
この画面50が表示されるということは、ユーザが所属する金融機関の独自シナリオ中に今回選択した新規共有シナリオに対応するものが欠落していることを意味しているため、ユーザは新規作成ボタン51をクリックし、独自シナリオの作成をリクエストする。
【００３７】
これを受けたWebサーバ12は（Ｓ28）、独自シナリオ登録画面を生成し、クライアント端末23に送信する（Ｓ30）。
図７は、この独自シナリオ登録画面54の一例を示しており、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口／…）、金額、発生頻度、業務改善策、日付の項目が設定されている。
【００３８】
これらの項目の中、シナリオIDの項目には、独自シナリオ管理部13によって採番されたシナリオIDが表示されている。また、金融機関の項目には、ユーザが所属する金融機関名が表示されている。日付の項目には、当日の日付が表示されている。
そこでユーザは、残りの項目に対して具体的な値を入力することになるが、Webサーバ12によってユーザが選択した共有シナリオの値がデフォルトで入力されているため、必要な箇所のみ修正すれば済む。
【００３９】
まず、イベントタイプの項目は、当該シナリオが対応するオペリスクの分類を選択入力する箇所であり、ユーザはプルダウンメニューを開いて以下の値の中から任意のものを選択することができる。
(1)外部の不正行為
(2)内部の不正行為
(3)顧客、商品及び取引慣行
(4)事業活動の中断及びシステム障害
(5)取引実行、デリバリー、プロセスの管理
(6)物的資産の損傷
(7)労務慣行及び職場の安全
【００４０】
業務区分の項目は、当該金融機関が扱っている業務の分類を選択入力する箇所であり、ユーザはプルダウンメニューを開いて以下の値の中から任意のものを選択することができる。
(1)コーポレート・ファイナンス
(2)リテール・バンキング
(3)コマーシャル・バンキング
(4)リテール・ブローカレッジ
(5)資産運用
(6)トレーディング及びセールス
【００４１】
損失種別の項目は、オペリスクにより発生する損失の分類を選択入力する箇所であり、ユーザはプルダウンメニューを開いて以下の値の中から任意のものを選択することができる。
(1)横領・盗難
(2)損害賠償
(3)追徴課税・罰則金
(4)情報漏洩・遺失
(5)機会損失
(6)風評被害
(7)物的資産の損傷
【００４２】
キーワード／人物の項目は、当該シナリオが対応する人物を選択入力する箇所であり、ユーザはプルダウンメニューを開いて任意の値（一般行員、銀行幹部等）を選択する。
キーワード／所属の項目は、上記人物の所属を選択入力する箇所であり、ユーザはプルダウンメニューを開いて任意の値（支店、本店営業部等）を選択する。
キーワード／処罰の項目は、上記人物に対する処罰の種類を選択入力する箇所であり、ユーザはプルダウンメニューを開いて任意の値（懲戒解雇、諭旨免職等）を選択する。
キーワード／容疑の項目は、上記人物の容疑を選択入力する箇所であり、ユーザはプルダウンメニューを開いて任意の値（業務上横領、詐欺等）を選択する。
キーワード／手口の項目は、不正行為の具体的な手口をフリーワードで入力する箇所であり、想定される手口を表す文章を簡潔に入力する。
【００４３】
金額の項目は、当該リスクによって生じる損失金額の予想値を入力する箇所であり、ユーザは具体的な数値を打鍵入力した後、プルダウンメニューを開いて任意の単位（千万円、億円等）を選択する。
発生頻度の項目は、当該リスクが自行において発生する頻度の推定値を入力する箇所であり、ユーザは具体的な数値を打鍵入力する。
業務改善策の項目は、当該リスクを回避するために策定した自行内の業務改善プランがある場合に、これをフリーワードで入力する箇所である。
【００４４】
必要な項目に対する設定を完了したユーザが登録ボタン55をクリックすると、独自シナリオの登録リクエストがWebサーバ12に送信される。
これを受けたWebサーバ12は（Ｓ32）、送信された入力データを独自シナリオ管理部13に転送し、その登録を依頼する。
これに対し独自シナリオ管理部13は、Webサーバ12から渡された入力データを、当該金融機関に関連付けて独自シナリオ記憶部14に格納する（Ｓ34）。
【００４５】
独自シナリオ記憶部14に独自シナリオが新規登録されると、シナリオ加工部15が起動し、この独自シナリオに基づく共有シナリオの生成処理を実行する（Ｓ36）。シナリオ加工部15は、具体的には以下の加工処理を実行する。
【００４６】
(1)金融機関名の抽象化：
シナリオ加工部15は、個別の金融機関名と当該金融機関の規模を表す抽象表現との対応関係が予め格納されている辞書情報記憶部16を参照し、独自シナリオの金融機関の項目に記載された「四菱銀行」という固有名称を、「メガバンク」や「地方中位行」のように、当該銀行の規模を表す抽象表現に変換する。
各行の具体的な銀行名をそのまま共有シナリオに引き継がせるのは機密保持の観点から望ましくないが、かといって金融機関名を削除したり伏せ字にしてしまうと企業規模が不明となり、他の金融機関が参考にし難くなるため、シナリオ加工部15は金融機関の規模を表す抽象表現に変換することとしている。
なお、独自シナリオ情報のデータ項目として「金融機関」を最初から除外しておき、共有シナリオ情報を生成する際にシナリオ加工部15が当該金融機関の規模を表す抽象表現を付加するようにすることもできる。
【００４７】
(2)人名や企業名、地名の抽象化：
独自シナリオの手口や業務改善策の項目に、人名や企業名、地名を表す固有名称が混入していた場合、シナリオ加工部15は具体的な人名や企業名、地名と抽象表現との対応関係が予め格納されている辞書情報記憶部16を参照し、これらの固有名称を抽象的な文字列に変換する（例えば、「山田太郎→甲」、「海南銀行→地銀Ａ行」、「静岡市→中部某市」）。
人名や企業名を抽象化するのは、個人情報や企業機密を保護するためである。また、地名を抽象化するのは、金融機関の規模と地名から特定の金融機関が推定される危険性を回避するためである。
【００４８】
シナリオ加工部15によって生成された共有シナリオは、共有シナリオ記憶部17に登録され（Ｓ38）、全加盟金融機関の閲覧に供される。
つぎにシナリオ加工部15は、新たに生成した共有シナリオのIDと、この共有シナリオ生成の基になった独自シナリオのIDとの対応関係を、シナリオ管理情報記憶部18に登録する（Ｓ40）。シナリオ検索部19は、共有シナリオと独自シナリオのマッチングを行う際にこのシナリオ管理情報記憶部18を参照し、ユーザの金融機関に係る共有シナリオを抽出対象から除外することが可能となる。
【００４９】
上記のシナリオマッチングにおいて、ユーザが選択した新規共有シナリオに対応する独自シナリオが抽出された場合には（Ｓ24／Ｎ）、Webサーバ12からクライアント端末23に対し、マッチング結果（該当あり）画面が送信される（Ｓ42）。
【００５０】
図８は、このマッチング結果（該当あり）画面58の一例を示しており、２件の独自シナリオが対応シナリオ候補としてリスト表示されている。
これに対しユーザは、独自シナリオのチェックボックスにチェックを入れて詳細閲覧ボタン59をクリックし、当該独自シナリオの詳細画面の表示をリクエストする。
この結果、図示は省略したが、Webサーバ12から当該独自シナリオに含まれる全データが記述された詳細画面がクライアント23に送信され、Webブラウザ上に表示される。
【００５１】
この詳細画面の内容を検討した結果、共有シナリオに比べて自行の独自シナリオの発生頻度や金額等の設定が不十分であると判断したユーザは、修正ボタン60をクリックし、修正のリクエストをWebサーバ12に送信する。
【００５２】
これを受けたWebサーバ12は（Ｓ44）、独自シナリオ修正画面を生成し、クライアント端末23に送信する（Ｓ46）。
図９は、この独自シナリオ修正画面62の一例を示しており、図７の独自シナリオ登録画面54と同様、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口…）、金額、発生頻度、業務改善策、日付の項目が設定されている。
【００５３】
ユーザは、これらの項目の中で修正が必要な箇所について、共有シナリオを参照して値を入力し直す。例えば、金額が独自シナリオでは「２千万円」と設定されていたところ、これを「５千万円」に増額させることが該当する。
また、独自シナリオの業務改善策の項目が空欄であった場合に、共有シナリオの業務改善策に記述された文章をコピー＆ペーストして充足させることもできる。
【００５４】
必要な項目に対する修正を完了したユーザが登録ボタン63をクリックすると、修正データによる独自シナリオの更新リクエストがWebサーバ12に送信される。
これを受けたWebサーバ12は（Ｓ48）、送信された修正データを独自シナリオ管理部13に転送し、その更新を依頼する。
これに対し独自シナリオ管理部13は、Webサーバ12から渡された修正データによって、独自シナリオ記憶部14内に格納された当該金融機関の独自シナリオを更新する（Ｓ50）。
【００５５】
上記においては、ユーザが図５の共有シナリオ検索画面40において「前回ログイン時から現在までの新規共有シナリオをチェック」のラジオボタン41にチェックを入れて検索をリクエストした場合について説明したが、同画面40中の「条件で絞り込む」のラジオボタン43にチェックを入れた上で、具体的な検索条件を設定し、検索ボタン42をクリックすることにより、共有シナリオ記憶部17に格納された全共有シナリオを様々な切り口で抽出することが可能となる。
【００５６】
図５の共有シナリオ検索画面40においては、検索条件の入力項目としてイベントタイプ、業務区分、損失種別、金融機関、キーワード、登録日の範囲が設けられている。キーワードの入力項目においてユーザは、フリーワードで任意のキーワードを設定することができる。
【００５７】
また、上記においては共有シナリオと独自シナリオとのマッチングの結果に基づいて独自シナリオの登録や修正をリクエストする例を示したが、ユーザは共有シナリオの存否とは無関係に、いつでも自由に独自シナリオの新規登録及び修正をWebサーバ12に対してリクエストすることができる。
【００５８】
さらに、上記においては新規に独自シナリオが登録された場合に限り、共有シナリオが生成される例を示したが、ユーザが自行の独自シナリオを修正した場合にも、シナリオ加工部15によって修正後の独自シナリオに基づく共有シナリオが生成されるようにシステムを運用してもよい。
【００５９】
つぎに、外部シナリオ生成システム30について説明する。
図１０は、この外部シナリオ生成システム30の機能構成を示すブロック図であり、記事データ収集部65と、記事データ記憶部66と、フィルタ処理部67と、辞書データ記憶部68と、抽象化処理部69と、ルール記憶部70と、外部シナリオ抽出部71と、グループ化処理部72と、外部シナリオ記憶部73と、共有シナリオ補充部74と、記事データ配信部75と、企業情報記憶部76から構成される。
【００６０】
上記の記事データ収集部65、フィルタ処理部67、抽象化処理部69、外部シナリオ抽出部71、グループ化処理部72、共有シナリオ補充部74及び記事データ配信部75は、コンピュータのCPUが、OS及びアプリケーションプログラムに従って必要な処理を実行することによって実現される。
【００６１】
また、上記の記事データ記憶部66、辞書データ記憶部68、ルール記憶部70、外部シナリオ記憶部73、企業情報記憶部76は、同コンピュータのハードディスク内に設けられている。
辞書データ記憶部68には、具体的な表現文字列と、その種類を示す抽象化文字列との対応関係を規定した各種の辞書データが多数登録されている（詳細は後述）。
また、ルール記憶部70には、抽象化ルール、シナリオ情報抽出ルール、照応解析ルール、イベントタイプ判定ルール、損失種別判定ルールが格納されている（詳細は後述）。
【００６２】
記事データ収集部65には、インターネットを介して複数のニュースサーバ77が接続されている。このニュースサーバ77は、テキスト化されたニュース記事データをオンラインで配信する機能を備えており、新聞社や通信社などが運営している。
【００６３】
つぎに、図１１のフローチャートに従い、この外部シナリオ生成システム30における処理手順を説明する。
まず記事データ収集部65は、定期的にニュースサーバ76にアクセスし、最新のニュース記事を取得した後、記事データ記憶部66に格納する（Ｓ60）。
このニュース記事はプレーンテキストによって構成されており、記事ID、発行者、報道年月日、取得年月日等の情報が関連付けられている。
【００６４】
つぎにフィルタ処理部67が起動し、記事データ記憶部66に格納されたニュース記事について検索処理を行い、外部損失記事（以下「外損記事」）とそれ以外の「一般記事」とのフィルタリングを行う（Ｓ62）。
すなわち、フィルタ処理部67は予め辞書データ記憶部68内に格納された外損キーワード辞書を参照し、対象となる記事データ中に外損キーワードが含まれているか否かを判定する。
【００６５】
外損キーワードとしては、例えば「銀行」、「信用金庫」、「金融機関」、「逮捕」、「横領」、「持ち逃げ」、「詐欺」、「銀行強盗」、「システムダウン」など、金融機関のオペレーショナルリスクに関する用語が広く選定されている。
これらのキーワードの所定の組合せが含まれるニュース記事に対しては、外損記事であることを示すフラグがフィルタ処理部67によって設定され、後続処理の対象と認定される。
これに対し、これらのキーワードの所定の組合せが含まれないニュース記事については、一般記事であることを示すフラグがフィルタ処理部67によって設定され、後続処理の対象から除外される。この結果、後続処理の効率化が図れる。
【００６６】
つぎに抽象化処理部69が起動し、リスク記事に含まれる所定の用語に対して抽象化タグ（メタタグ）を付与する。
このために抽象化処理部69は、まずリスク記事を形態素単位に分解し、それぞれの品詞を同定する（Ｓ64）。
【００６７】
つぎに抽象化処理部69は、辞書データ記憶部68に格納された金融機関名辞書、人物名辞書、地域名辞書、業務区分辞書、損失種別辞書、金融機関組織辞書、処罰名辞書、容疑名辞書、手口表現辞書、金額表現辞書などの辞書情報を参照し、各形態素の中で該当するものに対しては対応の抽象化タグを付与する（Ｓ66）。
【００６８】
例えば図１２に示すように、ある外損記事Ｘ（記事ID:2010...）の文No.0001中に「ＯＫ信用金庫」という文字列が存在しており、金融機関名辞書中に「ＯＫ信用金庫」の文字列が金融機関名として登録されている場合、抽象化処理部69は「ＯＫ商事」の文字列に対して＜社名＞の抽象化タグを関連付ける。
【００６９】
また、同文中に「支店」の文字列が存在しており、金融機関組織辞書中に「支店→＜所属＞」の登録例が存在している場合、抽象化処理部69は「支店」の文字列に対して＜所属＞の抽象化タグを関連付ける。
【００７０】
また、同文中に「元職員」の文字列が存在しており、金融機関組織辞書に「元職員→＜人物＞」の定義が存在している場合、抽象化処理部69は「元職員」の文字列に対して＜人物＞の抽象化タグを関連付ける。
同辞書中には他にも「支店長→＜人物＞」、「職員→＜人物＞」等の定義データが登録されており、金融機関の構成員を表す異なった用語に対して、等しく＜人物＞の抽象化タグが付与されることとなる。
【００７１】
また、同文中に「２５０万円」の文字列が存在しており、金額表現辞書中に「万円→＜金額＞」の定義が存在しているため、抽象化処理部69は「万円」の文字列及びこの直前に配置された数字である「２５０」に対して＜金額＞の抽象化タグを関連付ける。
【００７２】
さらに、同文中の「着服」の文字列が存在しており、手口表現辞書中に「着服→＜手口＞」の定義が存在しているため、抽象化処理部69は「着服」の文字列に対して＜手口＞の抽象化タグを関連付ける。
【００７３】
つぎの文No.0002には、「懲戒解雇」の文字列が存在しており、処罰名辞書中に「懲戒解雇→＜処罰＞」の定義が存在しているため、抽象化処理部69は「懲戒解雇」の文字列に＜処罰＞の抽象化タグを関連付ける。
【００７４】
また、同文中に「詐欺」及び「業務上横領」の文字列が存在し、容疑名辞書中に「詐欺」と「業務上横領」の登録例が存在しているため、抽象化処理部69はそれぞれの文字列に＜容疑＞の抽象化タグを関連付ける。
【００７５】
抽象化処理部69は上記のように、まず各種辞書の登録情報を参照することにより、該当の形態素に対して抽象化タグを付与する処理を実行するが、辞書の収録語数には自ずと限界があり、辞書ベースでの抽象化処理だけでは漏れが生じる可能性がある。
そこで抽象化処理部69は、ルール記憶部70に格納された抽象化ルールを適用することにより、辞書に収録されていない文字列について抽象化タグを関連付ける（Ｓ68）。
このため、ルール記憶部70には、予め多数の抽象化ルールが格納されている。
【００７６】
図１３の(a)は抽象化ルールの一例を示すものであり、「＜company_size＞の＜country＞(＜feature:名詞＞+)」は、「company_size（企業規模を表す文字列）」＋「の」＋「country（国を表す文字列）」の直後に続く名詞を企業名と認定することが定義されている。また、「company_size」のエイリアス表現（別名）として、「首位、大手、中堅」が定義されており、「company_size」のエイリアス表現として、「米、英、欧州」が定義されている。
【００７７】
ここに、図１３(b)に示すように、「金融大手の米AAAバンクは、人員削減計画を発表した。」という文が与えられた場合、抽象化処理部69はこれを図１３(c)に示すように名詞単位のOR表現に置き換え、ルールにマッチする「金融大手の米AAAバンク」を抽出した後、正規表現の「後方参照」を用いて「AAAバンク」を取り出し、金融機関名と認定する。
この結果、AAAバンクに対しては＜社名＞の抽象化タグが抽象化処理部69によって付与される。
【００７８】
つぎに抽象化処理部69は、記事中に所定の照応詞が含まれている場合に、これを対応の先行詞に置き換える照応処理を実行する（Ｓ70）。
例えば、図１２の外損記事Ｘの文No.0002には、「同信金」という文字列が存在し、この「同信金」はルール記憶部70に格納された照応解析ルールにおいて照応詞として規定されているため、抽象化処理部69はこの照応解析ルールに従い、直近の先行文中に含まれる＜社名＞の抽象化タグが付された文字列である「ＯＫ信用金庫」を先行詞と認定し、これと置き換える処理を実行する。この結果、「同信金」は「ＯＫ信用金庫＜社名＞」と置換される。
【００７９】
つぎに外部シナリオ抽出部71が起動し、抽象化処理部69による抽象化タグの付与が完了した外損記事データから外部シナリオ情報を抽出する（Ｓ72）。この際、外部シナリオ抽出部71は、ルール記憶部70内に格納されたシナリオ情報抽出ルールを参照する。
図１４は、この外部シナリオ情報のデータ構造を示すものであり、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口…）、金額、発生頻度、業務改善策、報道日、記事ID、記事グループIDのデータ項目を少なくとも備えている。
以下、図１５のフローチャートに従い、この外部シナリオ抽出処理の具体的手順を説明する。
【００８０】
まず外部シナリオ抽出部71は、外損記事から金融機関名抽出する（Ｓ72-01）。例えば、図１２に示した外損記事の場合、文No.0001に＜社名＞の抽象化タグが付与された文字列「ＯＫ信用金庫」が存在し、同文中にオペリスクの内容を表す「着服」の文字列が存在するため、外部シナリオ抽出部71はこの文から金融機関名として「ＯＫ信用金庫」を抽出する。
【００８１】
このために、ルール記憶部70内に予め以下のように、金融機関名を抽出するためのルールが設定されている。
■同一文中に＜社名＞の抽象化タグが付与された文字列と、オペリスクの内容を表す文字列が存在する場合→＜社名＞の抽象化タグに係る文字列を金融機関名として抽出
●「オペリスクの内容を表す文字列→着服、銀行強盗、業務上横領…etc.
なお、これらのルールは、実際には所定のプログラム言語によってコーディングされている（以下も同様）。
【００８２】
つぎに外部シナリオ抽出部71は企業情報記憶部76を参照し、当該金融機関に関連付けられた業務区分を特定する（Ｓ72-02）。「ＯＫ信用金庫」については辞書記憶部68において「リテール・バンキング」の業務区分が関連付けられているため、外部シナリオ抽出部71は業務区分として「リテール・バンキング」を特定する。
【００８３】
つぎに外部シナリオ抽出部71は、所定の抽出ルールに従い、外損記事中から予め設定されたキーワードを抽出する（Ｓ72-03）。
例えば、図１２に示した外損記事の場合、文No.0001に＜人物＞の抽象化タグが付与された文字列「元職員」が存在するため、外部シナリオ抽出部71はこの文から人物として「元職員」を抽出する。
【００８４】
また、文No.0001には＜所属＞の抽象化タグが付与された文字列「支店」が存在するため、外部シナリオ抽出部71はこの文から所属として「支店」を抽出する。
【００８５】
また、文No.0002には＜容疑＞の抽象化タグが付与された文字列「詐欺」及び「業務上横領」が存在するため、外部シナリオ抽出部71はこの文から容疑として「詐欺」及び「業務上横領」を抽出する。
【００８６】
また、文No.0002には＜処罰＞の抽象化タグが付与された文字列「懲戒解雇」が存在するため、外部シナリオ抽出部71はこの文から処罰として「懲戒解雇」を抽出する。
【００８７】
また、文No.0001には＜手口＞の抽象化タグが付与された文字列「着服」が存在するため、外部シナリオ抽出部71はこの文から手口として「着服」を抽出する。
【００８８】
つぎに外部シナリオ抽出部71は、外損記事から金額を抽出する（Ｓ72-04）。
図１２に示した外損記事の場合、文No.0001に＜金額＞の抽象化タグが付与された文字列「２５０万円」が存在するため、外部シナリオ抽出部71はこの文から金額として「２５０万円」を抽出する。
【００８９】
つぎに外部シナリオ抽出部71は、ルール記憶部70に格納されたイベントタイプ判定ルールを外損記事に適用することにより、当該外損記事のイベントタイプを判定する（Ｓ72-05）。
例えば、図１２に示した外損記事の場合、「職員／元職員」による「着服／詐欺／業務上横領」事件に関するものであるため、外部シナリオ抽出部71はイベントタイプとして「内部の不正行為」を認定する。
【００９０】
このために、ルール記憶部70内には以下のイベントタイプ判定ルールが設定されている。
■同一文中に「内部者」を示す文字列と、「不正行為」を示す文字列が存在している場合→「内部の不正行為」
●「内部者」を示す文字列→職員、元職員、幹部、支店長、副支店長、行員…etc.
●「不正行為」を示す文字列→詐欺、業務上横領、窃盗、情報漏洩、横流し…etc.
【００９１】
ルール記憶部70内には、この他にも「外部の不正行為」、「顧客、商品及び取引慣行」、「事業活動の中断及びシステム障害」、「取引実行、デリバリー、プロセスの管理」、「物的資産の損傷」、「労務慣行及び職場の安全」のイベントタイプを判定するためのルールがそれぞれ格納されている。
【００９２】
つぎに外部シナリオ抽出部71は、ルール記憶部70に格納された損失種別判定ルールを外損記事に適用することにより、当該外損記事の損失種別を判定する（Ｓ72-06）。
例えば、図１２に示した外損記事の場合、「業務上横領」事件に関するものであるため、外部シナリオ抽出部71は損失種別として「横領・盗難」を認定する。
【００９３】
このために、ルール記憶部70内には以下の損失種別判定ルールが設定されている。
■記事中に「横領・盗難」を示す文字列が存在している場合→「横領・盗難」
●「横領・盗難」を示す文字列→横領、業務上横領、盗難、窃盗…etc.
【００９４】
ルール記憶部70内には、この他にも「損害賠償」、「追徴課税・罰則金」、「情報漏洩・遺失」、「機会損失」、「風評被害」、「物的資産の損傷」の損失種別を判定するためのルールがそれぞれ格納されている。
【００９５】
つぎに外部シナリオ抽出部71は、外損記事から抽出した外部シナリオ情報を、外部シナリオ記憶部73に登録する（Ｓ72-07）。
外部シナリオ情報の場合、一般に公開された記事データに基づいて生成されているため、図１４に示したように、「金融機関」として実名の「ＯＫ信用金庫」がそのまま記録されている。また、「発生頻度」の項目についてはブランクとなされている。
【００９６】
なお、図１４の「グループID」の項目には具体的な値が記載されているが、この項目に対しては次段のグループ化処理によって値が充填されるものであり、この時点ではブランクとなされている。
【００９７】
外部シナリオ記憶部73に新たな外部シナリオ情報が格納されると、グループ化処理部72が起動し、外部シナリオ情報のグループ化処理を実行する（図１１のＳ74）。
以下、図１６のフローチャートに従い、このグループ化処理の具体的手順を説明する。
【００９８】
まずグループ化処理部72は、外部シナリオ記憶部73に外部シナリオ情報が格納されると（Ｓ74-01）、この新規の外部シナリオ情報の基になった外損記事（以下「新規外損記事」）と、直近の所定件数（例えば100件）以内の外部シナリオ情報の基になった外損記事（以下「既存外損記事」）との間で、抽象化タグに基づく相互間の類似度を算出する（Ｓ22-02）。
【００９９】
図１７(a)は、このグループ化処理のイメージを示すものであり、新規外損記事と、各グループに属する既存外損記事との間で、それぞれ類似度を算出する様子が描かれている。
ここで、例えばグループＡは「ＯＫ信用金庫における業務上横領事件に対する各新聞社の記事群」を意味しており、グループＢは「ＡＢＣ銀行のシステム障害に関する各新聞社の記事群」を意味しているというように、「グループ」とは、同一のイベント（事件）に対する個別記事の集合を意味している。
【０１００】
新規外損記事と比較の対象となるのは、各グループに含まれる全外損記事データではなく、時間的に「直近100件以内」に該当する外損記事データに限定される。
したがって、グループ内に「直近100件以内」に該当する外損記事データが１件も存在しない場合には、当該グループとの比較はなされないことになる。
【０１０１】
両リスク記事データ間の類似度は、図１７(b)の計算式に従って算出される。
ここで分子の「抽象化タグ一致数」とは、抽象化タグそのものの一致数ではなく、抽象化タグ及びこれが付与された文字列間の一致数を意味している。
例えば、既存記事中に「ＹＫ信用金庫＜社名＞」が存在し、新規記事中に「ＯＫ信用金庫＜社名＞」が存在した場合に、両者の抽象化タグは＜社名＞で一致しているが、抽象化タグが付与された文字列自体は異なっているため、「抽象化タグ一致数」としてカウントされることはない。
これに対し、既存記事中に「ＯＫ信用金庫＜社名＞」が存在し、新規記事中にも「ＯＫ信用金庫＜社名＞」が存在した場合には、両者の抽象化タグは＜社名＞で一致しており、かつ抽象化タグが付与された文字列も一致しているため、「抽象化タグ一致数」としてカウントされる。
【０１０２】
また、一致数は種類単位でカウントされるものであり、同種文字列が双方の記事中に多数存在したとしても、一致数は「１」となる。
例えば、既存記事中に「ＯＫ信用金庫＜社名＞」が５件存在し、新規記事中に「ＯＫ信用金庫＜社名＞」が３件存在した場合に、「一致数＝３」とカウントされるのではなく、「同種文字列間の一致数＝１」となされる。
【０１０３】
同様に、分母の「既存外損記事中の抽象化タグ数」及び「新規外損記事中の抽象化タグ数」も、抽象化タグが付与された文字列の種類の数を意味しており、単純に記事中に含まれる抽象化タグの総数を意味しているものではない。
先の例でいえば、「ＯＫ信用金庫＜社名＞」が５件存在しても抽象化タグ数としては「１」とカウントされ、「ＯＫ信用金庫＜社名＞」が５件、「東京証券＜社名＞」が３件存在した場合には、「抽象化タグ数＝２」とカウントされる。
【０１０４】
そして、直近100件の既存外損記事の中で、類似度が最も高い記事が所属するグループが新規外損記事の所属すべきグループと認定され、当該グループに組み入れられる。
具体的には、当該新規外損記事に係る外部シナリオ情報の「グループID」項目に、所属グループの識別コードがグループ化処理部72によって記録される（Ｓ74-03）。
【０１０５】
つぎにグループ化処理部72は、同一グループに属する外損記事間で、欠落しているデータ項目のマージ処理を実行する（Ｓ74-04）。
例えば、既存外損記事から抽出した外部シナリオ情報では「処罰」の項目の値が欠落していたところ、同グループに加えられた新規外損記事に係る外部シナリオ情報が「処罰」の項目に値を有していた場合、グループ化処理部72は新規外部シナリオ情報の「処罰」の値を既存外部シナリオ情報に追加する。
なお、既存外部シナリオ情報のデータと新規外部シナリオ情報のデータ間に矛盾（金額の不一致等）が存在する場合、グループ化処理部72は外部シナリオ情報間でデータの調整を行うことはせずに、そのまま放置する。
【０１０６】
外部シナリオ記憶部73に格納された外部シナリオ情報は、共有シナリオ補充部74により、シナリオ管理システム10の共有シナリオ記憶部17に、共有シナリオの一種として登録される。
この結果、外部シナリオ情報は、シナリオ加工部15が独自シナリオに基づいて生成した共有シナリオと同様、各ユーザの検索対象に供される。
【０１０７】
ただし、検索結果リスト45（図６(a)参照）中に列挙される際、外部シナリオ情報に基づく共有シナリオについては、「元記事参照」のアイコンが付記されており、独自シナリオに基づく共有シナリオとは区別されている（図示省略）。
この「元記事参照」のアイコンには、記事データ記憶部66内に格納された外損記事データとのリンクが設定されているため、ユーザがこれをクリックすると、記事データ配信部75によって外損記事データがWebサーバ12に送信され、Webサーバ12からクライアント端末23に対して外損記事データが記載された画面が送信される。
【０１０８】
この画面には、「他５件」のように、他の類似外損記事の存在を示すアンカーテキストが表示されており（図示省略）、ユーザがこれをクリックすると、同一グループに属する外損記事のリスト画面が表示される（図示省略）。
この結果ユーザは、共有シナリオ情報の素になった外損記事及びその類似記事を網羅的に確認することが可能となる。
【図面の簡単な説明】
【０１０９】
【図１】シナリオ管理システムの機能構成を示すブロック図である。
【図２】独自シナリオと共有シナリオのデータ構造を示す図である。
【図３】シナリオ管理システムにおける処理手順を示すフローチャートである。
【図４】シナリオ管理システムにおける処理手順を示すフローチャートである。
【図５】共有シナリオ検索画面を示す図である。
【図６】検索結果画面及びマッチング結果（該当なし）画面を示す図である。
【図７】独自シナリオ登録画面を示す図である。
【図８】マッチング結果（該当あり）画面を示す図である。
【図９】独自シナリオ修正画面を示す図である。
【図１０】外部シナリオ生成システムの機能構成を示すブロック図である。
【図１１】外部シナリオ生成システムにおける処理手順を示すフローチャートである。
【図１２】外損記事の具体例を示す説明図である。
【図１３】抽象化ルールの一例を示す説明図である。
【図１４】外部シナリオのデータ構造を示す図である。
【図１５】外部シナリオ情報抽出の処理手順を示すフローチャートである。
【図１６】グループ化処理の手順を示すフローチャートである。
【図１７】グループ化処理のイメージを示す説明図である。
【符号の説明】
【０１１０】
10 シナリオ管理システム
12 Webサーバ
13 独自シナリオ管理部
14 独自シナリオ記憶部
15 シナリオ加工部
16 辞書情報記憶部
17 共有シナリオ記憶部
18 シナリオ管理情報記憶部
19 シナリオ検索部
23 クライアント端末
30 外部シナリオ生成システム
40 共有シナリオ検索画面
42 検索ボタン
44 検索結果画面
45 検索結果リスト
46 詳細閲覧ボタン
47 マッチングボタン
50 マッチング結果（該当なし）画面
51 新規作成ボタン
54 独自シナリオ登録画面
55 登録ボタン
58 マッチング結果（該当あり）画面
59 詳細閲覧ボタン
60 修正ボタン
62 独自シナリオ修正画面
63 登録ボタン
65 記事データ収集部
66 記事データ記憶部
67 フィルタ処理部
68 辞書データ記憶部
69 抽象化処理部
70 ルール記憶部
71 外部シナリオ抽出部
72 グループ化処理部
73 外部シナリオ記憶部
74 共有シナリオ補充部
75 記事データ配信部
76 企業情報記憶部
77 ニュースサーバ
【技術分野】
【０００１】
この発明はシナリオ情報管理システム及びプログラムに係り、特に、銀行業務に付随するオペレーショナルリスクの計量化に利用するシナリオ情報を、複数の銀行間で共有可能とする技術に関する。
【背景技術】
【０００２】
バーゼル銀行監督委員会によって勧告された「新しい自己資本比率規制（所謂バーゼルII）」により、各銀行は従来の信用リスク、市場リスクに加えて、オペレーショナルリスク（以下「オペリスク」）の量に見合った自己資本を確保することが求められるようになった（非特許文献１及び２参照）。具体的には、銀行が国際業務を取り扱うためには、信用リスク、市場リスク、オペリスクの合計金額に対する資本金額の比率を８％以上に維持する必要性が生じた。
ここでオペリスクとは、事務ミス、不正、法令違反、システム障害などの内部管理上の問題や、災害、テロ、犯罪などの外部要因により損失が発生するリスクを意味しており、新しい規制に対応するためには、自行のオペリスク量を具体的数値として算出することが求められる。
【０００３】
オペリスク量を算出するための方法として、バーゼルIIでは「基礎的手法（BIA）」、「粗利益配分手法（TSA）」、及び「先進的計測手法（AMA）」の３つが認定されている。
まず、「基礎的手法（BIA）」は粗利益の15％を一律にオペリスク量と認定するものであり、「粗利益配分手法（TSA）」は業務区分毎に異なる比率を粗利益に乗じてオペリスク量を算出するものである。
これに対し「先進的計測手法（AMA）」については具体的な算出手法が明確に規定されているわけではなく、自行の業務特性に適合した手法を構築することが銀行側に課せられている。
【０００４】
リスク量算出の容易さという点からは、基礎的手法あるいは粗利益配分手法が有利であるといえるが、このような定率を粗利益に乗ずる簡易的手法では、業務改善によってオペリスク量を減らしたとしても所要自己資本の低減効果が生じないため、より難易度の高い先進的計測手法を志向する金融機関が増えてきている。
【０００５】
現在、先進的計測手法の有力候補として、「損失分布手法」が多くの金融機関において試行されている。
これは、自行で過去に発生した内部損失情報（頻度及び金額）や、経験則に基づいて導出した仮想損失事例であるシナリオ情報（頻度及び金額）を多数準備し、これらを使ってモンテカルロシミュレーションにより１年間の事故頻度の分布と事故１件当たりの損失額の分布とを求め、この分布図上で１０００年に１度発生すると考えられる金額をオペリスク量と推定するものである。
【非特許文献１】企業における事業リスク管理の高度化への挑戦〜金融機関のオペレーショナル・リスク管理の手法と課題に学ぶ〜 インターネットURL:http://www.nri.co.jp/publicity/mediaforum/2010/pdf/forum124.pdf 検索日：平成２２年３月１１日
【非特許文献２】地方銀行におけるオペレーショナルリスク管理の方向性 インターネットURL:http://www.nri.co.jp/opinion/kinyu_itf/2010/pdf/itf_201001_5.pdf 検索日：平成２２年３月１１日
【発明の開示】
【発明が解決しようとする課題】
【０００６】
先進的計測手法の場合、上記のように明確な算出手法が存在しないため、算出結果であるオペリスク量の正当性を立証するためには、投入するデータの妥当性及び網羅性を確保することが不可欠といえるが、個別金融機関における内部損失データの量には自ずと限りがあり、またデータの種類についても業務内容に応じた偏りが存在している。さらに、過去に遭遇していないタイプの損失については算出結果に織り込むことができないという問題もある。
このため、実際には起こっていないが起こる可能性のある潜在的なリスクを洗い出し、その頻度と損失金額を仮定的に設定したシナリオ情報の活用が重要となってくる。
【０００７】
しかしながら、自行の業務に関係するシナリオ情報を各行が一から創作するのは極めて骨の折れる作業であり、高度の専門性を備えた多くの人員を配置させる必要が生じるため、経営基盤の脆弱な中小金融機関にとっては高いハードルとなっている。
もちろん、他行の実例を参考にできれば、一からシナリオ情報を創作する場合に比べて各行の負担を大幅に軽減することが可能となるが、秘匿性の高い機微情報を含んでおり、自行の恥部ともなる内部損失情報を外部に流出させることには大きな抵抗があるため、現実的ではなかった。
【０００８】
この発明は、このような現状を打開するために案出されたものであり、各金融機関が自前のシナリオ情報を創作するに際し、外部の情報を容易に参照することを可能とする技術の提供を目的としている。
【課題を解決するための手段】
【０００９】
上記の目的を達成するため、請求項１に記載したシナリオ情報管理システムは、少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、金融機関の規模を表す抽象表現を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた共有シナリオ情報を、共有シナリオIDに関連付けて格納する共有シナリオ記憶手段と、少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた独自シナリオ情報を、金融機関固有の独自シナリオIDに関連付けて格納する独自シナリオ記憶手段と、加盟金融機関のクライアント端末に対し、共有シナリオ情報の検索画面を送信し、検索条件の入力を促す手段と、クライアント端末から検索条件が送信された場合に、この検索条件をキーに上記共有シナリオ記憶手段を検索し、該当する共有シナリオ情報を抽出する手段と、抽出された共有シナリオ情報が記載された検索結果画面を生成し、クライアント端末に送信する手段と、クライアント端末から、抽出された共有シナリオ情報と自社の独自シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報の特定のデータ項目の値と、各独自シナリオ情報の該当のデータ項目の値とを比較して、対応の独自シナリオ情報を抽出する手段と、マッチング結果が記載されたマッチング結果画面を生成し、クライアント端末に送信する手段と、クライアント端末から独自シナリオの登録リクエストが送信された場合に、少なくともイベントタイプ、業務区分、損失種別、損失金額、発生頻度の入力項目が設けられた独自シナリオ登録画面を生成し、クライアント端末に送信する手段と、クライアント端末から独自シナリオ情報を構成する入力データが送信された場合に、これを当該金融機関固有の独自シナリオIDに関連付けて上記独自シナリオ記憶手段に格納する手段と、金融機関毎にそれぞれの規模を表す抽象表現が登録された記憶手段を参照して、この独自シナリオ情報に対して当該金融機関の規模を表す抽象表現を付加した共有シナリオ情報を生成し、上記共有シナリオ記憶手段に格納する共有シナリオ生成手段を備えたことを特徴としている。
上記の「オペレーショナルリスクの内容を表す文字列」とは、例えば「業務上横領」、「着服」、「詐欺」、「システム障害」、「地震」、「テロ」、「銀行強盗」、「クーデター」等、銀行業務の障害となり得る事象を示す用語を意味している（以下同様）。
【００１０】
請求項２に記載したシナリオ情報管理システムは、請求項１のシステムであって、さらに上記共有シナリオ生成手段が、人名辞書及び企業名辞書を参照して、上記独自シナリオ情報中に個人名または具体的企業名が含まれているか否かを判定し、含まれている場合にはこれを抽象的な人名表現（「甲」等）または企業名表現（「Ａ社」等）に変換する処理を実行することを特徴としている。
【００１１】
請求項３に記載したシナリオ情報管理システムは、請求項１または２のシステムであって、さらに、具体的な表現文字列と、その種類を示す抽象化文字列との対応関係を登録した辞書を格納する記憶手段と、電子化された記事データを形態素に分解する手段と、上記辞書を参照し、各形態素の中で少なくとも金融機関名、金額、オペレーショナルリスクの内容を表す文字列に対して、対応の抽象化タグを付与する手段と、この抽象化タグが付与された記事データを格納しておく記事データ記憶手段と、記事データ中の各文に含まれる抽象化タグの組合せ、あるいは抽象化タグと特定の文字列との組合せ毎に、シナリオ情報の構成要素として抽出すべき文字列を規定した抽出ルールを、予め複数格納しておく抽出ルール記憶手段と、上記の記事データに上記抽出ルールを適用することにより、少なくとも金融機関名を表す文字列、金額を表す文字列、オペレーショナルリスクの内容を表す文字列をシナリオ情報の構成要素として抽出する手段と、抽象化タグが付与された文字列の構成に応じて、当該シナリオのイベントタイプを判定するためのイベントタイプ判定ルールを、予め複数格納しておく記憶手段と、上記記事データにおける抽象化タグの付与された文字列の構成を上記イベントタイプ判定ルールに適用し、当該シナリオのイベントタイプを判定する手段と、抽象化タグが付与された文字列の構成に応じて、当該シナリオの損失種別を判定するための損失種別判定ルールを、予め複数格納しておく記憶手段と、上記記事データにおける抽象化タグの付与された文字列の構成を上記損失種別判定ルールに適用し、当該シナリオの損失種別を判定する手段と、各金融機関の業務区分を格納しておく記憶手段と、この記憶手段を参照し、上記金融機関の業務区分を特定する手段と、上記のイベントタイプ、損失種別、業務区分、金融機関名、金額、オペレーショナルリスクの内容を表す文字列を含むシナリオ情報を生成する手段と、このシナリオ情報を上記共有シナリオ記憶手段に格納する手段とを備えたことを特徴としている。
【００１２】
請求項４に記載したシナリオ情報管理プログラムは、コンピュータを、少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、金融機関の規模を表す抽象表現を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた共有シナリオ情報を、共有シナリオIDに関連付けて格納する共有シナリオ記憶手段、少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた独自シナリオ情報を、金融機関固有の独自シナリオIDに関連付けて格納する独自シナリオ記憶手段、加盟金融機関のクライアント端末に対し、共有シナリオ情報の検索画面を送信し、検索条件の入力を促す手段、クライアント端末から検索条件が送信された場合に、この検索条件をキーに上記共有シナリオ記憶手段を検索し、該当する共有シナリオ情報を抽出する手段、抽出された共有シナリオ情報が記載された検索結果画面を生成し、クライアント端末に送信する手段、クライアント端末から、抽出された共有シナリオ情報と自社の独自シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報の特定のデータ項目の値と、各独自シナリオ情報の該当のデータ項目の値とを比較して、対応の独自シナリオ情報を抽出する手段、マッチング結果が記載されたマッチング結果画面を生成し、クライアント端末に送信する手段、クライアント端末から独自シナリオの登録リクエストが送信された場合に、少なくともイベントタイプ、業務区分、損失種別、損失金額、発生頻度の入力項目が設けられた独自シナリオ登録画面を生成し、クライアント端末に送信する手段、クライアント端末から独自シナリオ情報を構成する入力データが送信された場合に、これを当該金融機関固有の独自シナリオIDに関連付けて上記独自シナリオ記憶手段に格納する手段、金融機関毎にそれぞれの規模を表す抽象表現が登録された記憶手段を参照して、この独自シナリオ情報に対して当該金融機関の規模を表す抽象表現を付加した共有シナリオ情報を生成し、上記共有シナリオ記憶手段に格納する共有シナリオ生成手段として機能させることを特徴としている。
【発明の効果】
【００１３】
請求項１に記載のシナリオ情報管理システム及び請求項４に記載のシナリオ情報管理プログラムによれば、各金融機関が自行独自のシナリオ情報を作成する際に、他の金融機関の独自シナリオ情報に基づいて生成された共有シナリオ情報を参照することが可能となり、独自シナリオ作成の効率化が図れる。
また、特定の共有シナリオ情報に対応する独自シナリオが存在しているか否かがマッチング結果画面を通じて確認でき、対応の独自シナリオが存在しない場合には共有シナリオ情報に基づいて独自シナリオ情報を作成・登録できるため、金融機関は自行の独自シナリオ情報の網羅性を高めることが可能となる。
しかも、独自シナリオ情報が新規登録されると、これに基づいて新たな共有シナリオ情報が生成され、共有シナリオ情報記憶手段に追加されるため、共有シナリオ情報を常時アップデートすることができる。
【００１４】
請求項２に記載のシナリオ情報管理システムによれば、独自シナリオ情報中に個人名や具体的企業名が含まれていても、自動的に抽象的な表現に変換されるため、独自シナリオを提供した金融機関の機密保持が可能となる。
【００１５】
請求項３に記載のシナリオ情報管理システムによれば、電子化された新聞等の記事データから、自動的にイベントタイプ、業務区分、損失種別、金融機関名、オペレーショナルリスクの内容を表す文字列、金額が抽出され、これらの構成要素を備えたシナリオ情報が共有シナリオ情報の一種として共有シナリオ記憶手段に格納されるため、共有シナリオ情報の網羅性を高めることが可能となる。
【発明を実施するための最良の形態】
【００１６】
図１は、この発明に係るシナリオ管理システム10の機能構成を示すブロック図であり、Webサーバ12と、独自シナリオ管理部13と、独自シナリオ記憶部14と、シナリオ加工部15と、辞書情報記憶部16と、共有シナリオ記憶部17と、シナリオ管理情報記憶部18と、シナリオ検索部19とから構成されている。
【００１７】
上記の独自シナリオ管理部13、シナリオ加工部15、シナリオ検索部19は、コンピュータのCPUが、OS及びアプリケーションプログラムに従って必要な処理を実行することによって実現される。
また、上記の独自シナリオ記憶部14、辞書情報記憶部16、共有シナリオ記憶部17、シナリオ管理情報記憶部18は、同コンピュータのハードディスク内に設けられている。
【００１８】
独自シナリオ記憶部14内には、このシステム10に加盟している各金融機関固有のシナリオ情報が、金融機関単位で登録されている。
図２(a)は独自シナリオのデータ構造を示すものであり、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口…）、金額、発生頻度、業務改善策、日付のデータ項目を少なくとも備えている。
【００１９】
共有シナリオ記憶部17内には、このシステム10に加盟している各金融機関が共有しているシナリオ情報が登録されている。
図２(b)は共有シナリオのデータ構造を示すものであり、独自シナリオ情報と同様、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口…）、金額、発生頻度、業務改善策、日付のデータ項目を少なくとも備えている。
【００２０】
上記Webサーバ12は、インターネットを介して複数のクライアント端末23と接続されており、各クライアント端末23から送信されたリクエストに応じて独自シナリオ管理部13やシナリオ検索部19に処理を依頼し、その処理結果を記載した各種画面（Htmlファイル）をクライアント端末に送信する機能を備えている（詳細は後述）。
クライアント端末23は、Webブラウザプログラムを搭載したＰＣよりなり、各金融機関の担当者（以下「ユーザ」）が操作している。
【００２１】
上記共有シナリオ記憶部17には、外部シナリオ生成システム30が接続されており、この外部シナリオ生成システム30から送信された外部シナリオ情報が共有シナリオ記憶部17に格納される（詳細は後述）。
外部シナリオ生成システム30は上記Webサーバ12とも接続されており、クライアント端末23からのリクエストに応じて、外部シナリオ生成システム30からWebサーバ12に対して外損記事データが送信される（詳細は後述）。
【００２２】
つぎに、図３及び図４のフローチャートに従い、このシナリオ管理システム10における処理手順を説明する。
まず、クライアント端末23から共有シナリオ検索のリクエストをWebサーバ12が受信すると（Ｓ10）、共有シナリオ検索画面をクライアント端末23に送信する（Ｓ12）。
【００２３】
図５は、この共有シナリオ検索画面40を示すものであり、ユーザが「前回ログイン時から現在までの新規共有シナリオをチェック」の選択肢のラジオボタン41にチェックを入れて検索ボタン42をクリックすると、この検索条件がWebサーバ12に送信される。
【００２４】
これを受けたWebサーバ12は（Ｓ14）、内部に保持している当該ユーザのログイン履歴情報から前回ログイン日時を取り出してシナリオ検索部19に送信し、当該日時以降に登録された共有シナリオの検索を依頼する。
【００２５】
これに対しシナリオ検索部19は、共有シナリオ記憶部17から検索条件にマッチする共有シナリオ情報を抽出し（Ｓ16）、Webサーバ12に送信する。
Webサーバ12は、この検索結果が記載された検索結果画面を生成し、クライアント端末23に送信する（Ｓ18）。
【００２６】
図６(a)は、この検索結果画面44を示すものであり、ヒットした２件の共有シナリオが表示されている。
この検索結果リスト45には、各共有シナリオのイベントタイプ、業務区分、損失種別、金融機関（金融機関の規模に応じた類型）、金額が表示されているため、ユーザはこれらの情報に基づいて自行にとっての必要性を判断する。
例えば、ユーザの所属金融機関が地方銀行の類型に該当する場合、「メガバンクに係る共有シナリオは不要である」と判断したり、「自行が取り扱っていない業務区分の共有シナリオは不要である」と判断したりできる。
【００２７】
リスト中に表示された情報では不足の場合、ユーザは共有シナリオのチェックボックスにチェックを入れて詳細閲覧ボタン46をクリックし、当該共有シナリオの詳細画面の表示をリクエストする。
この結果、図示は省略したが、Webサーバ12から当該共有シナリオに含まれる全データが記述された詳細画面がクライアント23に送信され、Webブラウザ上に表示される。
【００２８】
詳細に内容を検討した結果、NO.２の共有シナリオが自行にとって必要であると判断したユーザは、そのチェックボックスにチェックを入れ、マッチングボタン47をクリックする。
この結果、自行の独自シナリオとのマッチングリクエストがWebサーバ12に送信される。
【００２９】
これを受けたWebサーバ12は（Ｓ19）、ユーザが選択した共有シナリオのIDと、ユーザの所属する金融機関の識別情報をシナリオ検索部19に送信し、マッチングを依頼する。
【００３０】
これに対しシナリオ検索部19は、指定された共有シナリオに対応する独自シナリオが、独自シナリオ記憶部14内に存在しているか否かを判定し、存在している場合にはこれを抽出するマッチング処理を実行する（Ｓ22）。
【００３１】
まずシナリオ検索部19は、独自シナリオ記憶部14から当該ユーザの属する金融機関に係る独自シナリオを取り出す。
つぎにシナリオ管理部19は、ユーザが選択した共有シナリオの所定の比較対象項目と、各独自シナリオの所定の比較対象項目同士を比較し、一定基準以上の一致率に達した独自シナリオを対応シナリオと認定する。また、一定基準以上の一致率に達した独自シナリオが存在しない場合、「該当シナリオなし」と判定する。
【００３２】
比較対象項目としては、例えばイベントタイプ、業務区分、損失種別が該当し、これらのすべてが一致した場合に、共有シナリオと独自シナリオとの一致が認定される。
比較対象項目として、キーワード中の幾つかの項目（例えば「手口」や「容疑」）、あるいは金額を加えることもできる。
【００３３】
また、すべての項目の値が完全一致した場合にのみ、共有シナリオと独自シナリオ間の一致と認定する代わりに、全比較対象項目中で所定数以上一致した場合に両シナリオ間の一致を認定するように運用することもできる。
【００３４】
あるいは、各比較対象項目に重要度に応じたポイントを付与しておき、一致した項目のポイントの合計値が所定の閾値を越えた独自シナリオを共有シナリオの対応シナリオ（類似シナリオ）として認定することもできる。このように、共有シナリオに対する各独自シナリオの一致度が数値化される場合には、一致度を示す数値の大きい順に所定数の独自シナリオをリスト表示させてもよい。
【００３５】
シナリオ検索部19から、「対応の独自シナリオなし」の判定結果を受けたWebサーバ12は（Ｓ24／Ｙ）、このマッチング結果が記載されたマッチング結果（該当なし）画面を生成し、クライアント端末23に送信する（Ｓ26）。
【００３６】
この結果、図６(b)に示すように、マッチング結果（該当なし）画面50がクライアント端末23のWebブラウザ上に表示される。
この画面50が表示されるということは、ユーザが所属する金融機関の独自シナリオ中に今回選択した新規共有シナリオに対応するものが欠落していることを意味しているため、ユーザは新規作成ボタン51をクリックし、独自シナリオの作成をリクエストする。
【００３７】
これを受けたWebサーバ12は（Ｓ28）、独自シナリオ登録画面を生成し、クライアント端末23に送信する（Ｓ30）。
図７は、この独自シナリオ登録画面54の一例を示しており、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口／…）、金額、発生頻度、業務改善策、日付の項目が設定されている。
【００３８】
これらの項目の中、シナリオIDの項目には、独自シナリオ管理部13によって採番されたシナリオIDが表示されている。また、金融機関の項目には、ユーザが所属する金融機関名が表示されている。日付の項目には、当日の日付が表示されている。
そこでユーザは、残りの項目に対して具体的な値を入力することになるが、Webサーバ12によってユーザが選択した共有シナリオの値がデフォルトで入力されているため、必要な箇所のみ修正すれば済む。
【００３９】
まず、イベントタイプの項目は、当該シナリオが対応するオペリスクの分類を選択入力する箇所であり、ユーザはプルダウンメニューを開いて以下の値の中から任意のものを選択することができる。
(1)外部の不正行為
(2)内部の不正行為
(3)顧客、商品及び取引慣行
(4)事業活動の中断及びシステム障害
(5)取引実行、デリバリー、プロセスの管理
(6)物的資産の損傷
(7)労務慣行及び職場の安全
【００４０】
業務区分の項目は、当該金融機関が扱っている業務の分類を選択入力する箇所であり、ユーザはプルダウンメニューを開いて以下の値の中から任意のものを選択することができる。
(1)コーポレート・ファイナンス
(2)リテール・バンキング
(3)コマーシャル・バンキング
(4)リテール・ブローカレッジ
(5)資産運用
(6)トレーディング及びセールス
【００４１】
損失種別の項目は、オペリスクにより発生する損失の分類を選択入力する箇所であり、ユーザはプルダウンメニューを開いて以下の値の中から任意のものを選択することができる。
(1)横領・盗難
(2)損害賠償
(3)追徴課税・罰則金
(4)情報漏洩・遺失
(5)機会損失
(6)風評被害
(7)物的資産の損傷
【００４２】
キーワード／人物の項目は、当該シナリオが対応する人物を選択入力する箇所であり、ユーザはプルダウンメニューを開いて任意の値（一般行員、銀行幹部等）を選択する。
キーワード／所属の項目は、上記人物の所属を選択入力する箇所であり、ユーザはプルダウンメニューを開いて任意の値（支店、本店営業部等）を選択する。
キーワード／処罰の項目は、上記人物に対する処罰の種類を選択入力する箇所であり、ユーザはプルダウンメニューを開いて任意の値（懲戒解雇、諭旨免職等）を選択する。
キーワード／容疑の項目は、上記人物の容疑を選択入力する箇所であり、ユーザはプルダウンメニューを開いて任意の値（業務上横領、詐欺等）を選択する。
キーワード／手口の項目は、不正行為の具体的な手口をフリーワードで入力する箇所であり、想定される手口を表す文章を簡潔に入力する。
【００４３】
金額の項目は、当該リスクによって生じる損失金額の予想値を入力する箇所であり、ユーザは具体的な数値を打鍵入力した後、プルダウンメニューを開いて任意の単位（千万円、億円等）を選択する。
発生頻度の項目は、当該リスクが自行において発生する頻度の推定値を入力する箇所であり、ユーザは具体的な数値を打鍵入力する。
業務改善策の項目は、当該リスクを回避するために策定した自行内の業務改善プランがある場合に、これをフリーワードで入力する箇所である。
【００４４】
必要な項目に対する設定を完了したユーザが登録ボタン55をクリックすると、独自シナリオの登録リクエストがWebサーバ12に送信される。
これを受けたWebサーバ12は（Ｓ32）、送信された入力データを独自シナリオ管理部13に転送し、その登録を依頼する。
これに対し独自シナリオ管理部13は、Webサーバ12から渡された入力データを、当該金融機関に関連付けて独自シナリオ記憶部14に格納する（Ｓ34）。
【００４５】
独自シナリオ記憶部14に独自シナリオが新規登録されると、シナリオ加工部15が起動し、この独自シナリオに基づく共有シナリオの生成処理を実行する（Ｓ36）。シナリオ加工部15は、具体的には以下の加工処理を実行する。
【００４６】
(1)金融機関名の抽象化：
シナリオ加工部15は、個別の金融機関名と当該金融機関の規模を表す抽象表現との対応関係が予め格納されている辞書情報記憶部16を参照し、独自シナリオの金融機関の項目に記載された「四菱銀行」という固有名称を、「メガバンク」や「地方中位行」のように、当該銀行の規模を表す抽象表現に変換する。
各行の具体的な銀行名をそのまま共有シナリオに引き継がせるのは機密保持の観点から望ましくないが、かといって金融機関名を削除したり伏せ字にしてしまうと企業規模が不明となり、他の金融機関が参考にし難くなるため、シナリオ加工部15は金融機関の規模を表す抽象表現に変換することとしている。
なお、独自シナリオ情報のデータ項目として「金融機関」を最初から除外しておき、共有シナリオ情報を生成する際にシナリオ加工部15が当該金融機関の規模を表す抽象表現を付加するようにすることもできる。
【００４７】
(2)人名や企業名、地名の抽象化：
独自シナリオの手口や業務改善策の項目に、人名や企業名、地名を表す固有名称が混入していた場合、シナリオ加工部15は具体的な人名や企業名、地名と抽象表現との対応関係が予め格納されている辞書情報記憶部16を参照し、これらの固有名称を抽象的な文字列に変換する（例えば、「山田太郎→甲」、「海南銀行→地銀Ａ行」、「静岡市→中部某市」）。
人名や企業名を抽象化するのは、個人情報や企業機密を保護するためである。また、地名を抽象化するのは、金融機関の規模と地名から特定の金融機関が推定される危険性を回避するためである。
【００４８】
シナリオ加工部15によって生成された共有シナリオは、共有シナリオ記憶部17に登録され（Ｓ38）、全加盟金融機関の閲覧に供される。
つぎにシナリオ加工部15は、新たに生成した共有シナリオのIDと、この共有シナリオ生成の基になった独自シナリオのIDとの対応関係を、シナリオ管理情報記憶部18に登録する（Ｓ40）。シナリオ検索部19は、共有シナリオと独自シナリオのマッチングを行う際にこのシナリオ管理情報記憶部18を参照し、ユーザの金融機関に係る共有シナリオを抽出対象から除外することが可能となる。
【００４９】
上記のシナリオマッチングにおいて、ユーザが選択した新規共有シナリオに対応する独自シナリオが抽出された場合には（Ｓ24／Ｎ）、Webサーバ12からクライアント端末23に対し、マッチング結果（該当あり）画面が送信される（Ｓ42）。
【００５０】
図８は、このマッチング結果（該当あり）画面58の一例を示しており、２件の独自シナリオが対応シナリオ候補としてリスト表示されている。
これに対しユーザは、独自シナリオのチェックボックスにチェックを入れて詳細閲覧ボタン59をクリックし、当該独自シナリオの詳細画面の表示をリクエストする。
この結果、図示は省略したが、Webサーバ12から当該独自シナリオに含まれる全データが記述された詳細画面がクライアント23に送信され、Webブラウザ上に表示される。
【００５１】
この詳細画面の内容を検討した結果、共有シナリオに比べて自行の独自シナリオの発生頻度や金額等の設定が不十分であると判断したユーザは、修正ボタン60をクリックし、修正のリクエストをWebサーバ12に送信する。
【００５２】
これを受けたWebサーバ12は（Ｓ44）、独自シナリオ修正画面を生成し、クライアント端末23に送信する（Ｓ46）。
図９は、この独自シナリオ修正画面62の一例を示しており、図７の独自シナリオ登録画面54と同様、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口…）、金額、発生頻度、業務改善策、日付の項目が設定されている。
【００５３】
ユーザは、これらの項目の中で修正が必要な箇所について、共有シナリオを参照して値を入力し直す。例えば、金額が独自シナリオでは「２千万円」と設定されていたところ、これを「５千万円」に増額させることが該当する。
また、独自シナリオの業務改善策の項目が空欄であった場合に、共有シナリオの業務改善策に記述された文章をコピー＆ペーストして充足させることもできる。
【００５４】
必要な項目に対する修正を完了したユーザが登録ボタン63をクリックすると、修正データによる独自シナリオの更新リクエストがWebサーバ12に送信される。
これを受けたWebサーバ12は（Ｓ48）、送信された修正データを独自シナリオ管理部13に転送し、その更新を依頼する。
これに対し独自シナリオ管理部13は、Webサーバ12から渡された修正データによって、独自シナリオ記憶部14内に格納された当該金融機関の独自シナリオを更新する（Ｓ50）。
【００５５】
上記においては、ユーザが図５の共有シナリオ検索画面40において「前回ログイン時から現在までの新規共有シナリオをチェック」のラジオボタン41にチェックを入れて検索をリクエストした場合について説明したが、同画面40中の「条件で絞り込む」のラジオボタン43にチェックを入れた上で、具体的な検索条件を設定し、検索ボタン42をクリックすることにより、共有シナリオ記憶部17に格納された全共有シナリオを様々な切り口で抽出することが可能となる。
【００５６】
図５の共有シナリオ検索画面40においては、検索条件の入力項目としてイベントタイプ、業務区分、損失種別、金融機関、キーワード、登録日の範囲が設けられている。キーワードの入力項目においてユーザは、フリーワードで任意のキーワードを設定することができる。
【００５７】
また、上記においては共有シナリオと独自シナリオとのマッチングの結果に基づいて独自シナリオの登録や修正をリクエストする例を示したが、ユーザは共有シナリオの存否とは無関係に、いつでも自由に独自シナリオの新規登録及び修正をWebサーバ12に対してリクエストすることができる。
【００５８】
さらに、上記においては新規に独自シナリオが登録された場合に限り、共有シナリオが生成される例を示したが、ユーザが自行の独自シナリオを修正した場合にも、シナリオ加工部15によって修正後の独自シナリオに基づく共有シナリオが生成されるようにシステムを運用してもよい。
【００５９】
つぎに、外部シナリオ生成システム30について説明する。
図１０は、この外部シナリオ生成システム30の機能構成を示すブロック図であり、記事データ収集部65と、記事データ記憶部66と、フィルタ処理部67と、辞書データ記憶部68と、抽象化処理部69と、ルール記憶部70と、外部シナリオ抽出部71と、グループ化処理部72と、外部シナリオ記憶部73と、共有シナリオ補充部74と、記事データ配信部75と、企業情報記憶部76から構成される。
【００６０】
上記の記事データ収集部65、フィルタ処理部67、抽象化処理部69、外部シナリオ抽出部71、グループ化処理部72、共有シナリオ補充部74及び記事データ配信部75は、コンピュータのCPUが、OS及びアプリケーションプログラムに従って必要な処理を実行することによって実現される。
【００６１】
また、上記の記事データ記憶部66、辞書データ記憶部68、ルール記憶部70、外部シナリオ記憶部73、企業情報記憶部76は、同コンピュータのハードディスク内に設けられている。
辞書データ記憶部68には、具体的な表現文字列と、その種類を示す抽象化文字列との対応関係を規定した各種の辞書データが多数登録されている（詳細は後述）。
また、ルール記憶部70には、抽象化ルール、シナリオ情報抽出ルール、照応解析ルール、イベントタイプ判定ルール、損失種別判定ルールが格納されている（詳細は後述）。
【００６２】
記事データ収集部65には、インターネットを介して複数のニュースサーバ77が接続されている。このニュースサーバ77は、テキスト化されたニュース記事データをオンラインで配信する機能を備えており、新聞社や通信社などが運営している。
【００６３】
つぎに、図１１のフローチャートに従い、この外部シナリオ生成システム30における処理手順を説明する。
まず記事データ収集部65は、定期的にニュースサーバ76にアクセスし、最新のニュース記事を取得した後、記事データ記憶部66に格納する（Ｓ60）。
このニュース記事はプレーンテキストによって構成されており、記事ID、発行者、報道年月日、取得年月日等の情報が関連付けられている。
【００６４】
つぎにフィルタ処理部67が起動し、記事データ記憶部66に格納されたニュース記事について検索処理を行い、外部損失記事（以下「外損記事」）とそれ以外の「一般記事」とのフィルタリングを行う（Ｓ62）。
すなわち、フィルタ処理部67は予め辞書データ記憶部68内に格納された外損キーワード辞書を参照し、対象となる記事データ中に外損キーワードが含まれているか否かを判定する。
【００６５】
外損キーワードとしては、例えば「銀行」、「信用金庫」、「金融機関」、「逮捕」、「横領」、「持ち逃げ」、「詐欺」、「銀行強盗」、「システムダウン」など、金融機関のオペレーショナルリスクに関する用語が広く選定されている。
これらのキーワードの所定の組合せが含まれるニュース記事に対しては、外損記事であることを示すフラグがフィルタ処理部67によって設定され、後続処理の対象と認定される。
これに対し、これらのキーワードの所定の組合せが含まれないニュース記事については、一般記事であることを示すフラグがフィルタ処理部67によって設定され、後続処理の対象から除外される。この結果、後続処理の効率化が図れる。
【００６６】
つぎに抽象化処理部69が起動し、リスク記事に含まれる所定の用語に対して抽象化タグ（メタタグ）を付与する。
このために抽象化処理部69は、まずリスク記事を形態素単位に分解し、それぞれの品詞を同定する（Ｓ64）。
【００６７】
つぎに抽象化処理部69は、辞書データ記憶部68に格納された金融機関名辞書、人物名辞書、地域名辞書、業務区分辞書、損失種別辞書、金融機関組織辞書、処罰名辞書、容疑名辞書、手口表現辞書、金額表現辞書などの辞書情報を参照し、各形態素の中で該当するものに対しては対応の抽象化タグを付与する（Ｓ66）。
【００６８】
例えば図１２に示すように、ある外損記事Ｘ（記事ID:2010...）の文No.0001中に「ＯＫ信用金庫」という文字列が存在しており、金融機関名辞書中に「ＯＫ信用金庫」の文字列が金融機関名として登録されている場合、抽象化処理部69は「ＯＫ商事」の文字列に対して＜社名＞の抽象化タグを関連付ける。
【００６９】
また、同文中に「支店」の文字列が存在しており、金融機関組織辞書中に「支店→＜所属＞」の登録例が存在している場合、抽象化処理部69は「支店」の文字列に対して＜所属＞の抽象化タグを関連付ける。
【００７０】
また、同文中に「元職員」の文字列が存在しており、金融機関組織辞書に「元職員→＜人物＞」の定義が存在している場合、抽象化処理部69は「元職員」の文字列に対して＜人物＞の抽象化タグを関連付ける。
同辞書中には他にも「支店長→＜人物＞」、「職員→＜人物＞」等の定義データが登録されており、金融機関の構成員を表す異なった用語に対して、等しく＜人物＞の抽象化タグが付与されることとなる。
【００７１】
また、同文中に「２５０万円」の文字列が存在しており、金額表現辞書中に「万円→＜金額＞」の定義が存在しているため、抽象化処理部69は「万円」の文字列及びこの直前に配置された数字である「２５０」に対して＜金額＞の抽象化タグを関連付ける。
【００７２】
さらに、同文中の「着服」の文字列が存在しており、手口表現辞書中に「着服→＜手口＞」の定義が存在しているため、抽象化処理部69は「着服」の文字列に対して＜手口＞の抽象化タグを関連付ける。
【００７３】
つぎの文No.0002には、「懲戒解雇」の文字列が存在しており、処罰名辞書中に「懲戒解雇→＜処罰＞」の定義が存在しているため、抽象化処理部69は「懲戒解雇」の文字列に＜処罰＞の抽象化タグを関連付ける。
【００７４】
また、同文中に「詐欺」及び「業務上横領」の文字列が存在し、容疑名辞書中に「詐欺」と「業務上横領」の登録例が存在しているため、抽象化処理部69はそれぞれの文字列に＜容疑＞の抽象化タグを関連付ける。
【００７５】
抽象化処理部69は上記のように、まず各種辞書の登録情報を参照することにより、該当の形態素に対して抽象化タグを付与する処理を実行するが、辞書の収録語数には自ずと限界があり、辞書ベースでの抽象化処理だけでは漏れが生じる可能性がある。
そこで抽象化処理部69は、ルール記憶部70に格納された抽象化ルールを適用することにより、辞書に収録されていない文字列について抽象化タグを関連付ける（Ｓ68）。
このため、ルール記憶部70には、予め多数の抽象化ルールが格納されている。
【００７６】
図１３の(a)は抽象化ルールの一例を示すものであり、「＜company_size＞の＜country＞(＜feature:名詞＞+)」は、「company_size（企業規模を表す文字列）」＋「の」＋「country（国を表す文字列）」の直後に続く名詞を企業名と認定することが定義されている。また、「company_size」のエイリアス表現（別名）として、「首位、大手、中堅」が定義されており、「company_size」のエイリアス表現として、「米、英、欧州」が定義されている。
【００７７】
ここに、図１３(b)に示すように、「金融大手の米AAAバンクは、人員削減計画を発表した。」という文が与えられた場合、抽象化処理部69はこれを図１３(c)に示すように名詞単位のOR表現に置き換え、ルールにマッチする「金融大手の米AAAバンク」を抽出した後、正規表現の「後方参照」を用いて「AAAバンク」を取り出し、金融機関名と認定する。
この結果、AAAバンクに対しては＜社名＞の抽象化タグが抽象化処理部69によって付与される。
【００７８】
つぎに抽象化処理部69は、記事中に所定の照応詞が含まれている場合に、これを対応の先行詞に置き換える照応処理を実行する（Ｓ70）。
例えば、図１２の外損記事Ｘの文No.0002には、「同信金」という文字列が存在し、この「同信金」はルール記憶部70に格納された照応解析ルールにおいて照応詞として規定されているため、抽象化処理部69はこの照応解析ルールに従い、直近の先行文中に含まれる＜社名＞の抽象化タグが付された文字列である「ＯＫ信用金庫」を先行詞と認定し、これと置き換える処理を実行する。この結果、「同信金」は「ＯＫ信用金庫＜社名＞」と置換される。
【００７９】
つぎに外部シナリオ抽出部71が起動し、抽象化処理部69による抽象化タグの付与が完了した外損記事データから外部シナリオ情報を抽出する（Ｓ72）。この際、外部シナリオ抽出部71は、ルール記憶部70内に格納されたシナリオ情報抽出ルールを参照する。
図１４は、この外部シナリオ情報のデータ構造を示すものであり、シナリオID、イベントタイプ、業務区分、損失種別、金融機関、キーワード（人物／所属／処罰／容疑／手口…）、金額、発生頻度、業務改善策、報道日、記事ID、記事グループIDのデータ項目を少なくとも備えている。
以下、図１５のフローチャートに従い、この外部シナリオ抽出処理の具体的手順を説明する。
【００８０】
まず外部シナリオ抽出部71は、外損記事から金融機関名抽出する（Ｓ72-01）。例えば、図１２に示した外損記事の場合、文No.0001に＜社名＞の抽象化タグが付与された文字列「ＯＫ信用金庫」が存在し、同文中にオペリスクの内容を表す「着服」の文字列が存在するため、外部シナリオ抽出部71はこの文から金融機関名として「ＯＫ信用金庫」を抽出する。
【００８１】
このために、ルール記憶部70内に予め以下のように、金融機関名を抽出するためのルールが設定されている。
■同一文中に＜社名＞の抽象化タグが付与された文字列と、オペリスクの内容を表す文字列が存在する場合→＜社名＞の抽象化タグに係る文字列を金融機関名として抽出
●「オペリスクの内容を表す文字列→着服、銀行強盗、業務上横領…etc.
なお、これらのルールは、実際には所定のプログラム言語によってコーディングされている（以下も同様）。
【００８２】
つぎに外部シナリオ抽出部71は企業情報記憶部76を参照し、当該金融機関に関連付けられた業務区分を特定する（Ｓ72-02）。「ＯＫ信用金庫」については辞書記憶部68において「リテール・バンキング」の業務区分が関連付けられているため、外部シナリオ抽出部71は業務区分として「リテール・バンキング」を特定する。
【００８３】
つぎに外部シナリオ抽出部71は、所定の抽出ルールに従い、外損記事中から予め設定されたキーワードを抽出する（Ｓ72-03）。
例えば、図１２に示した外損記事の場合、文No.0001に＜人物＞の抽象化タグが付与された文字列「元職員」が存在するため、外部シナリオ抽出部71はこの文から人物として「元職員」を抽出する。
【００８４】
また、文No.0001には＜所属＞の抽象化タグが付与された文字列「支店」が存在するため、外部シナリオ抽出部71はこの文から所属として「支店」を抽出する。
【００８５】
また、文No.0002には＜容疑＞の抽象化タグが付与された文字列「詐欺」及び「業務上横領」が存在するため、外部シナリオ抽出部71はこの文から容疑として「詐欺」及び「業務上横領」を抽出する。
【００８６】
また、文No.0002には＜処罰＞の抽象化タグが付与された文字列「懲戒解雇」が存在するため、外部シナリオ抽出部71はこの文から処罰として「懲戒解雇」を抽出する。
【００８７】
また、文No.0001には＜手口＞の抽象化タグが付与された文字列「着服」が存在するため、外部シナリオ抽出部71はこの文から手口として「着服」を抽出する。
【００８８】
つぎに外部シナリオ抽出部71は、外損記事から金額を抽出する（Ｓ72-04）。
図１２に示した外損記事の場合、文No.0001に＜金額＞の抽象化タグが付与された文字列「２５０万円」が存在するため、外部シナリオ抽出部71はこの文から金額として「２５０万円」を抽出する。
【００８９】
つぎに外部シナリオ抽出部71は、ルール記憶部70に格納されたイベントタイプ判定ルールを外損記事に適用することにより、当該外損記事のイベントタイプを判定する（Ｓ72-05）。
例えば、図１２に示した外損記事の場合、「職員／元職員」による「着服／詐欺／業務上横領」事件に関するものであるため、外部シナリオ抽出部71はイベントタイプとして「内部の不正行為」を認定する。
【００９０】
このために、ルール記憶部70内には以下のイベントタイプ判定ルールが設定されている。
■同一文中に「内部者」を示す文字列と、「不正行為」を示す文字列が存在している場合→「内部の不正行為」
●「内部者」を示す文字列→職員、元職員、幹部、支店長、副支店長、行員…etc.
●「不正行為」を示す文字列→詐欺、業務上横領、窃盗、情報漏洩、横流し…etc.
【００９１】
ルール記憶部70内には、この他にも「外部の不正行為」、「顧客、商品及び取引慣行」、「事業活動の中断及びシステム障害」、「取引実行、デリバリー、プロセスの管理」、「物的資産の損傷」、「労務慣行及び職場の安全」のイベントタイプを判定するためのルールがそれぞれ格納されている。
【００９２】
つぎに外部シナリオ抽出部71は、ルール記憶部70に格納された損失種別判定ルールを外損記事に適用することにより、当該外損記事の損失種別を判定する（Ｓ72-06）。
例えば、図１２に示した外損記事の場合、「業務上横領」事件に関するものであるため、外部シナリオ抽出部71は損失種別として「横領・盗難」を認定する。
【００９３】
このために、ルール記憶部70内には以下の損失種別判定ルールが設定されている。
■記事中に「横領・盗難」を示す文字列が存在している場合→「横領・盗難」
●「横領・盗難」を示す文字列→横領、業務上横領、盗難、窃盗…etc.
【００９４】
ルール記憶部70内には、この他にも「損害賠償」、「追徴課税・罰則金」、「情報漏洩・遺失」、「機会損失」、「風評被害」、「物的資産の損傷」の損失種別を判定するためのルールがそれぞれ格納されている。
【００９５】
つぎに外部シナリオ抽出部71は、外損記事から抽出した外部シナリオ情報を、外部シナリオ記憶部73に登録する（Ｓ72-07）。
外部シナリオ情報の場合、一般に公開された記事データに基づいて生成されているため、図１４に示したように、「金融機関」として実名の「ＯＫ信用金庫」がそのまま記録されている。また、「発生頻度」の項目についてはブランクとなされている。
【００９６】
なお、図１４の「グループID」の項目には具体的な値が記載されているが、この項目に対しては次段のグループ化処理によって値が充填されるものであり、この時点ではブランクとなされている。
【００９７】
外部シナリオ記憶部73に新たな外部シナリオ情報が格納されると、グループ化処理部72が起動し、外部シナリオ情報のグループ化処理を実行する（図１１のＳ74）。
以下、図１６のフローチャートに従い、このグループ化処理の具体的手順を説明する。
【００９８】
まずグループ化処理部72は、外部シナリオ記憶部73に外部シナリオ情報が格納されると（Ｓ74-01）、この新規の外部シナリオ情報の基になった外損記事（以下「新規外損記事」）と、直近の所定件数（例えば100件）以内の外部シナリオ情報の基になった外損記事（以下「既存外損記事」）との間で、抽象化タグに基づく相互間の類似度を算出する（Ｓ22-02）。
【００９９】
図１７(a)は、このグループ化処理のイメージを示すものであり、新規外損記事と、各グループに属する既存外損記事との間で、それぞれ類似度を算出する様子が描かれている。
ここで、例えばグループＡは「ＯＫ信用金庫における業務上横領事件に対する各新聞社の記事群」を意味しており、グループＢは「ＡＢＣ銀行のシステム障害に関する各新聞社の記事群」を意味しているというように、「グループ」とは、同一のイベント（事件）に対する個別記事の集合を意味している。
【０１００】
新規外損記事と比較の対象となるのは、各グループに含まれる全外損記事データではなく、時間的に「直近100件以内」に該当する外損記事データに限定される。
したがって、グループ内に「直近100件以内」に該当する外損記事データが１件も存在しない場合には、当該グループとの比較はなされないことになる。
【０１０１】
両リスク記事データ間の類似度は、図１７(b)の計算式に従って算出される。
ここで分子の「抽象化タグ一致数」とは、抽象化タグそのものの一致数ではなく、抽象化タグ及びこれが付与された文字列間の一致数を意味している。
例えば、既存記事中に「ＹＫ信用金庫＜社名＞」が存在し、新規記事中に「ＯＫ信用金庫＜社名＞」が存在した場合に、両者の抽象化タグは＜社名＞で一致しているが、抽象化タグが付与された文字列自体は異なっているため、「抽象化タグ一致数」としてカウントされることはない。
これに対し、既存記事中に「ＯＫ信用金庫＜社名＞」が存在し、新規記事中にも「ＯＫ信用金庫＜社名＞」が存在した場合には、両者の抽象化タグは＜社名＞で一致しており、かつ抽象化タグが付与された文字列も一致しているため、「抽象化タグ一致数」としてカウントされる。
【０１０２】
また、一致数は種類単位でカウントされるものであり、同種文字列が双方の記事中に多数存在したとしても、一致数は「１」となる。
例えば、既存記事中に「ＯＫ信用金庫＜社名＞」が５件存在し、新規記事中に「ＯＫ信用金庫＜社名＞」が３件存在した場合に、「一致数＝３」とカウントされるのではなく、「同種文字列間の一致数＝１」となされる。
【０１０３】
同様に、分母の「既存外損記事中の抽象化タグ数」及び「新規外損記事中の抽象化タグ数」も、抽象化タグが付与された文字列の種類の数を意味しており、単純に記事中に含まれる抽象化タグの総数を意味しているものではない。
先の例でいえば、「ＯＫ信用金庫＜社名＞」が５件存在しても抽象化タグ数としては「１」とカウントされ、「ＯＫ信用金庫＜社名＞」が５件、「東京証券＜社名＞」が３件存在した場合には、「抽象化タグ数＝２」とカウントされる。
【０１０４】
そして、直近100件の既存外損記事の中で、類似度が最も高い記事が所属するグループが新規外損記事の所属すべきグループと認定され、当該グループに組み入れられる。
具体的には、当該新規外損記事に係る外部シナリオ情報の「グループID」項目に、所属グループの識別コードがグループ化処理部72によって記録される（Ｓ74-03）。
【０１０５】
つぎにグループ化処理部72は、同一グループに属する外損記事間で、欠落しているデータ項目のマージ処理を実行する（Ｓ74-04）。
例えば、既存外損記事から抽出した外部シナリオ情報では「処罰」の項目の値が欠落していたところ、同グループに加えられた新規外損記事に係る外部シナリオ情報が「処罰」の項目に値を有していた場合、グループ化処理部72は新規外部シナリオ情報の「処罰」の値を既存外部シナリオ情報に追加する。
なお、既存外部シナリオ情報のデータと新規外部シナリオ情報のデータ間に矛盾（金額の不一致等）が存在する場合、グループ化処理部72は外部シナリオ情報間でデータの調整を行うことはせずに、そのまま放置する。
【０１０６】
外部シナリオ記憶部73に格納された外部シナリオ情報は、共有シナリオ補充部74により、シナリオ管理システム10の共有シナリオ記憶部17に、共有シナリオの一種として登録される。
この結果、外部シナリオ情報は、シナリオ加工部15が独自シナリオに基づいて生成した共有シナリオと同様、各ユーザの検索対象に供される。
【０１０７】
ただし、検索結果リスト45（図６(a)参照）中に列挙される際、外部シナリオ情報に基づく共有シナリオについては、「元記事参照」のアイコンが付記されており、独自シナリオに基づく共有シナリオとは区別されている（図示省略）。
この「元記事参照」のアイコンには、記事データ記憶部66内に格納された外損記事データとのリンクが設定されているため、ユーザがこれをクリックすると、記事データ配信部75によって外損記事データがWebサーバ12に送信され、Webサーバ12からクライアント端末23に対して外損記事データが記載された画面が送信される。
【０１０８】
この画面には、「他５件」のように、他の類似外損記事の存在を示すアンカーテキストが表示されており（図示省略）、ユーザがこれをクリックすると、同一グループに属する外損記事のリスト画面が表示される（図示省略）。
この結果ユーザは、共有シナリオ情報の素になった外損記事及びその類似記事を網羅的に確認することが可能となる。
【図面の簡単な説明】
【０１０９】
【図１】シナリオ管理システムの機能構成を示すブロック図である。
【図２】独自シナリオと共有シナリオのデータ構造を示す図である。
【図３】シナリオ管理システムにおける処理手順を示すフローチャートである。
【図４】シナリオ管理システムにおける処理手順を示すフローチャートである。
【図５】共有シナリオ検索画面を示す図である。
【図６】検索結果画面及びマッチング結果（該当なし）画面を示す図である。
【図７】独自シナリオ登録画面を示す図である。
【図８】マッチング結果（該当あり）画面を示す図である。
【図９】独自シナリオ修正画面を示す図である。
【図１０】外部シナリオ生成システムの機能構成を示すブロック図である。
【図１１】外部シナリオ生成システムにおける処理手順を示すフローチャートである。
【図１２】外損記事の具体例を示す説明図である。
【図１３】抽象化ルールの一例を示す説明図である。
【図１４】外部シナリオのデータ構造を示す図である。
【図１５】外部シナリオ情報抽出の処理手順を示すフローチャートである。
【図１６】グループ化処理の手順を示すフローチャートである。
【図１７】グループ化処理のイメージを示す説明図である。
【符号の説明】
【０１１０】
10 シナリオ管理システム
12 Webサーバ
13 独自シナリオ管理部
14 独自シナリオ記憶部
15 シナリオ加工部
16 辞書情報記憶部
17 共有シナリオ記憶部
18 シナリオ管理情報記憶部
19 シナリオ検索部
23 クライアント端末
30 外部シナリオ生成システム
40 共有シナリオ検索画面
42 検索ボタン
44 検索結果画面
45 検索結果リスト
46 詳細閲覧ボタン
47 マッチングボタン
50 マッチング結果（該当なし）画面
51 新規作成ボタン
54 独自シナリオ登録画面
55 登録ボタン
58 マッチング結果（該当あり）画面
59 詳細閲覧ボタン
60 修正ボタン
62 独自シナリオ修正画面
63 登録ボタン
65 記事データ収集部
66 記事データ記憶部
67 フィルタ処理部
68 辞書データ記憶部
69 抽象化処理部
70 ルール記憶部
71 外部シナリオ抽出部
72 グループ化処理部
73 外部シナリオ記憶部
74 共有シナリオ補充部
75 記事データ配信部
76 企業情報記憶部
77 ニュースサーバ
【特許請求の範囲】
【請求項１】
少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、金融機関の規模を表す抽象表現を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた共有シナリオ情報を、共有シナリオIDに関連付けて格納する共有シナリオ記憶手段と、
少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた独自シナリオ情報を、金融機関固有の独自シナリオIDに関連付けて格納する独自シナリオ記憶手段と、
加盟金融機関のクライアント端末に対し、共有シナリオ情報の検索画面を送信し、検索条件の入力を促す手段と、
クライアント端末から検索条件が送信された場合に、この検索条件をキーに上記共有シナリオ記憶手段を検索し、該当する共有シナリオ情報を抽出する手段と、
抽出された共有シナリオ情報が記載された検索結果画面を生成し、クライアント端末に送信する手段と、
クライアント端末から、抽出された共有シナリオ情報と自社の独自シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報の特定のデータ項目の値と、各独自シナリオ情報の該当のデータ項目の値とを比較して、対応の独自シナリオ情報を抽出する手段と、
マッチング結果が記載されたマッチング結果画面を生成し、クライアント端末に送信する手段と、
クライアント端末から独自シナリオの登録リクエストが送信された場合に、少なくともイベントタイプ、業務区分、損失種別、損失金額、発生頻度の入力項目が設けられた独自シナリオ登録画面を生成し、クライアント端末に送信する手段と、
クライアント端末から独自シナリオ情報を構成する入力データが送信された場合に、これを当該金融機関固有の独自シナリオIDに関連付けて上記独自シナリオ記憶手段に格納する手段と、
金融機関毎にそれぞれの規模を表す抽象表現が登録された記憶手段を参照して、この独自シナリオ情報に対して当該金融機関の規模を表す抽象表現を付加した共有シナリオ情報を生成し、上記共有シナリオ記憶手段に格納する共有シナリオ生成手段と、
を備えたことを特徴とするシナリオ情報管理システム。
【請求項２】
上記共有シナリオ生成手段が、人名辞書及び企業名辞書を参照して、上記独自シナリオ情報中に個人名または具体的企業名が含まれているか否かを判定し、含まれている場合にはこれを抽象的な人名表現または企業名表現に変換する処理を実行することを特徴とする請求項１に記載のシナリオ情報管理システム。
【請求項３】
具体的な表現文字列と、その種類を示す抽象化文字列との対応関係を登録した辞書を格納する記憶手段と、
電子化された記事データを形態素に分解する手段と、
上記辞書を参照し、各形態素の中で少なくとも金融機関名、金額、オペレーショナルリスクの内容を表す文字列に対して、対応の抽象化タグを付与する手段と、
この抽象化タグが付与された記事データを格納しておく記事データ記憶手段と、
記事データ中の各文に含まれる抽象化タグの組合せ、あるいは抽象化タグと特定の文字列との組合せ毎に、シナリオ情報の構成要素として抽出すべき文字列を規定した抽出ルールを、予め複数格納しておく抽出ルール記憶手段と、
上記の記事データに上記抽出ルールを適用することにより、少なくとも金融機関名を表す文字列、金額を表す文字列、オペレーショナルリスクの内容を表す文字列をシナリオ情報の構成要素として抽出する手段と、
抽象化タグが付与された文字列の構成に応じて、当該シナリオのイベントタイプを判定するためのイベントタイプ判定ルールを、予め複数格納しておく記憶手段と、
上記記事データにおける抽象化タグの付与された文字列の構成を上記イベントタイプ判定ルールに適用し、当該シナリオのイベントタイプを判定する手段と、
抽象化タグが付与された文字列の構成に応じて、当該シナリオの損失種別を判定するための損失種別判定ルールを、予め複数格納しておく記憶手段と、
上記記事データにおける抽象化タグの付与された文字列の構成を上記損失種別判定ルールに適用し、当該シナリオの損失種別を判定する手段と、
各金融機関の業務区分を格納しておく記憶手段と、
この記憶手段を参照し、上記金融機関の業務区分を特定する手段と、
上記のイベントタイプ、損失種別、業務区分、金融機関名、金額、オペレーショナルリスクの内容を表す文字列を含むシナリオ情報を生成する手段と、
このシナリオ情報を上記共有シナリオ記憶手段に格納する手段と、
を備えたことを特徴とする請求項１または２に記載のシナリオ情報管理システム。
【請求項４】
コンピュータを、
少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、金融機関の規模を表す抽象表現を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた共有シナリオ情報を、共有シナリオIDに関連付けて格納する共有シナリオ記憶手段、
少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた独自シナリオ情報を、金融機関固有の独自シナリオIDに関連付けて格納する独自シナリオ記憶手段、
加盟金融機関のクライアント端末に対し、共有シナリオ情報の検索画面を送信し、検索条件の入力を促す手段、
クライアント端末から検索条件が送信された場合に、この検索条件をキーに上記共有シナリオ記憶手段を検索し、該当する共有シナリオ情報を抽出する手段、
抽出された共有シナリオ情報が記載された検索結果画面を生成し、クライアント端末に送信する手段、
クライアント端末から、抽出された共有シナリオ情報と自社の独自シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報の特定のデータ項目の値と、各独自シナリオ情報の該当のデータ項目の値とを比較して、対応の独自シナリオ情報を抽出する手段、
マッチング結果が記載されたマッチング結果画面を生成し、クライアント端末に送信する手段、
クライアント端末から独自シナリオの登録リクエストが送信された場合に、少なくともイベントタイプ、業務区分、損失種別、損失金額、発生頻度の入力項目が設けられた独自シナリオ登録画面を生成し、クライアント端末に送信する手段、
クライアント端末から独自シナリオ情報を構成する入力データが送信された場合に、これを当該金融機関固有の独自シナリオIDに関連付けて上記独自シナリオ記憶手段に格納する手段、
金融機関毎にそれぞれの規模を表す抽象表現が登録された記憶手段を参照して、この独自シナリオ情報に対して当該金融機関の規模を表す抽象表現を付加した共有シナリオ情報を生成し、上記共有シナリオ記憶手段に格納する共有シナリオ生成手段、
として機能させることを特徴とするシナリオ情報管理プログラム。
【請求項１】
少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、金融機関の規模を表す抽象表現を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた共有シナリオ情報を、共有シナリオIDに関連付けて格納する共有シナリオ記憶手段と、
少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた独自シナリオ情報を、金融機関固有の独自シナリオIDに関連付けて格納する独自シナリオ記憶手段と、
加盟金融機関のクライアント端末に対し、共有シナリオ情報の検索画面を送信し、検索条件の入力を促す手段と、
クライアント端末から検索条件が送信された場合に、この検索条件をキーに上記共有シナリオ記憶手段を検索し、該当する共有シナリオ情報を抽出する手段と、
抽出された共有シナリオ情報が記載された検索結果画面を生成し、クライアント端末に送信する手段と、
クライアント端末から、抽出された共有シナリオ情報と自社の独自シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報の特定のデータ項目の値と、各独自シナリオ情報の該当のデータ項目の値とを比較して、対応の独自シナリオ情報を抽出する手段と、
マッチング結果が記載されたマッチング結果画面を生成し、クライアント端末に送信する手段と、
クライアント端末から独自シナリオの登録リクエストが送信された場合に、少なくともイベントタイプ、業務区分、損失種別、損失金額、発生頻度の入力項目が設けられた独自シナリオ登録画面を生成し、クライアント端末に送信する手段と、
クライアント端末から独自シナリオ情報を構成する入力データが送信された場合に、これを当該金融機関固有の独自シナリオIDに関連付けて上記独自シナリオ記憶手段に格納する手段と、
金融機関毎にそれぞれの規模を表す抽象表現が登録された記憶手段を参照して、この独自シナリオ情報に対して当該金融機関の規模を表す抽象表現を付加した共有シナリオ情報を生成し、上記共有シナリオ記憶手段に格納する共有シナリオ生成手段と、
を備えたことを特徴とするシナリオ情報管理システム。
【請求項２】
上記共有シナリオ生成手段が、人名辞書及び企業名辞書を参照して、上記独自シナリオ情報中に個人名または具体的企業名が含まれているか否かを判定し、含まれている場合にはこれを抽象的な人名表現または企業名表現に変換する処理を実行することを特徴とする請求項１に記載のシナリオ情報管理システム。
【請求項３】
具体的な表現文字列と、その種類を示す抽象化文字列との対応関係を登録した辞書を格納する記憶手段と、
電子化された記事データを形態素に分解する手段と、
上記辞書を参照し、各形態素の中で少なくとも金融機関名、金額、オペレーショナルリスクの内容を表す文字列に対して、対応の抽象化タグを付与する手段と、
この抽象化タグが付与された記事データを格納しておく記事データ記憶手段と、
記事データ中の各文に含まれる抽象化タグの組合せ、あるいは抽象化タグと特定の文字列との組合せ毎に、シナリオ情報の構成要素として抽出すべき文字列を規定した抽出ルールを、予め複数格納しておく抽出ルール記憶手段と、
上記の記事データに上記抽出ルールを適用することにより、少なくとも金融機関名を表す文字列、金額を表す文字列、オペレーショナルリスクの内容を表す文字列をシナリオ情報の構成要素として抽出する手段と、
抽象化タグが付与された文字列の構成に応じて、当該シナリオのイベントタイプを判定するためのイベントタイプ判定ルールを、予め複数格納しておく記憶手段と、
上記記事データにおける抽象化タグの付与された文字列の構成を上記イベントタイプ判定ルールに適用し、当該シナリオのイベントタイプを判定する手段と、
抽象化タグが付与された文字列の構成に応じて、当該シナリオの損失種別を判定するための損失種別判定ルールを、予め複数格納しておく記憶手段と、
上記記事データにおける抽象化タグの付与された文字列の構成を上記損失種別判定ルールに適用し、当該シナリオの損失種別を判定する手段と、
各金融機関の業務区分を格納しておく記憶手段と、
この記憶手段を参照し、上記金融機関の業務区分を特定する手段と、
上記のイベントタイプ、損失種別、業務区分、金融機関名、金額、オペレーショナルリスクの内容を表す文字列を含むシナリオ情報を生成する手段と、
このシナリオ情報を上記共有シナリオ記憶手段に格納する手段と、
を備えたことを特徴とする請求項１または２に記載のシナリオ情報管理システム。
【請求項４】
コンピュータを、
少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、金融機関の規模を表す抽象表現を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた共有シナリオ情報を、共有シナリオIDに関連付けて格納する共有シナリオ記憶手段、
少なくともオペレーショナルリスクのイベントタイプを格納するデータ項目と、金融機関の業務区分を格納するデータ項目と、当該オペレーショナルリスクの損失種別を格納するデータ項目と、当該オペレーショナルリスクによる損失金額を格納するデータ項目と、当該オペレーショナルリスクの発生頻度を格納するデータ項目と、オペレーショナルリスクの内容を表す文字列を格納するデータ項目とを備えた独自シナリオ情報を、金融機関固有の独自シナリオIDに関連付けて格納する独自シナリオ記憶手段、
加盟金融機関のクライアント端末に対し、共有シナリオ情報の検索画面を送信し、検索条件の入力を促す手段、
クライアント端末から検索条件が送信された場合に、この検索条件をキーに上記共有シナリオ記憶手段を検索し、該当する共有シナリオ情報を抽出する手段、
抽出された共有シナリオ情報が記載された検索結果画面を生成し、クライアント端末に送信する手段、
クライアント端末から、抽出された共有シナリオ情報と自社の独自シナリオ情報とのマッチングリクエストが送信された場合に、当該共有シナリオ情報の特定のデータ項目の値と、各独自シナリオ情報の該当のデータ項目の値とを比較して、対応の独自シナリオ情報を抽出する手段、
マッチング結果が記載されたマッチング結果画面を生成し、クライアント端末に送信する手段、
クライアント端末から独自シナリオの登録リクエストが送信された場合に、少なくともイベントタイプ、業務区分、損失種別、損失金額、発生頻度の入力項目が設けられた独自シナリオ登録画面を生成し、クライアント端末に送信する手段、
クライアント端末から独自シナリオ情報を構成する入力データが送信された場合に、これを当該金融機関固有の独自シナリオIDに関連付けて上記独自シナリオ記憶手段に格納する手段、
金融機関毎にそれぞれの規模を表す抽象表現が登録された記憶手段を参照して、この独自シナリオ情報に対して当該金融機関の規模を表す抽象表現を付加した共有シナリオ情報を生成し、上記共有シナリオ記憶手段に格納する共有シナリオ生成手段、
として機能させることを特徴とするシナリオ情報管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１１−２２１８３７（Ｐ２０１１−２２１８３７Ａ）
【公開日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願番号】特願２０１０−９１１３７（Ｐ２０１０−９１１３７）
【出願日】平成２２年４月１２日（２０１０．４．１２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【公開日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願日】平成２２年４月１２日（２０１０．４．１２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
[ Back to top ]