(57)【要約】【課題】適切な確認事項を出力する。【解決手段】データ取得部は、サーバ名（例えば、Ｗ２）とサーバＷ２から出力された事象に関するメッセージを受信すると、サーバＷ２を含むシステム（多階層システム）の構成情報を格納する顧客情報ＤＢ２０からサーバＷ２の接続先のサーバ（例えば、Ａ２，Ａ３）の情報を取得する（Ｓ１２）。そして、データ処理部は、事象と、原因と、確認事項とを含む過去の事例を記憶する製品検索ＤＢを参照し、受信したメッセージの事象に基づいて、サーバＷ２やＡ２、Ａ３に関する過去の事例を抽出し（Ｓ１８）、抽出した過去の事例に含まれる確認事項を利用者端末７０に出力する（Ｓ２２、Ｓ２４）。【選択図】図７
2017068464.tif 000002
【特許請求の範囲】
【請求項１】
装置の識別情報と、該装置から出力された事象に関するメッセージの受信に応じて、前記装置を含むシステムの構成情報から前記装置の接続先の装置の情報を取得し、
事象と、該事象が発生した原因と、該事象に関し確認すべき確認事項とを含む過去の事例を記憶する記憶部を参照し、受信した前記メッセージの事象に基づいて、前記装置と、取得した前記接続先の装置とに関する過去の事例を抽出し、
抽出した前記過去の事例に含まれる確認事項を出力する、
処理をコンピュータに実行させることを特徴とする資料採取支援プログラム。
【請求項２】
前記記憶部は、参照すべき接続先の装置の情報と、該接続先の装置の事象を記憶することを特徴とする請求項１に記載の資料採取支援プログラム。
【請求項３】
前記出力する処理は、抽出した同一の装置の過去の事例が複数あり、該複数の過去の事例に含まれる確認事項の確認方法が共通し、確認内容が異なる場合には、抽出した複数の前記確認事項をまとめて出力する、ことを特徴とする請求項１又は２に記載の資料採取支援プログラム。
【請求項４】
前記確認事項に対する確認結果を受信すると、前記記憶部に記憶されている過去の事例を参照して、前記装置において事象が発生した原因を特定し、出力する、
処理を前記コンピュータに実行させることを特徴とする請求項１〜３のいずれか一項に記載の資料採取支援プログラム。
【請求項５】
装置の識別情報と、該装置から出力された事象に関するメッセージの受信に応じて、前記装置を含むシステムの構成情報から前記装置の接続先の装置の情報を取得し、
事象と、該事象が発生した原因と、該事象に関し確認すべき確認事項とを含む過去の事例を記憶する記憶部を参照し、受信した前記メッセージの事象に基づいて、前記装置と、取得した前記接続先の装置とに関する過去の事例を抽出し、
抽出した前記過去の事例に含まれる確認事項を出力する、
処理をコンピュータが実行することを特徴とする資料採取支援方法。
【請求項６】
装置の識別情報と、該装置から出力された事象に関するメッセージの受信に応じて、前記装置を含むシステムの構成情報から前記装置の接続先の装置の情報を取得する取得部と、
事象と、該事象が発生した原因と、該事象に関し確認すべき確認事項とを含む過去の事例を記憶する記憶部を参照し、受信した前記メッセージの事象に基づいて、前記装置と、取得した前記接続先の装置とに関する過去の事例を抽出する抽出部と、
抽出した前記過去の事例に含まれる確認事項を出力する出力部と、
を備える支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、資料採取支援プログラム、資料採取支援方法及び支援装置に関する。
【背景技術】
【０００２】
ＷＥＢサーバ（Web Server）、ＡＰサーバ（Application Server）、ＤＢサーバ（Database Server）などを含む多階層システムがある。各装置内でメッセージ（事象）が発生すると、オペレータはメッセージを管理者に通知し、管理者は過去の対処履歴を参照してメッセージに応じたエラーや原因等を特定する。
【０００３】
なお、特許文献１〜４等には、ネットワークシステムにおける障害推定等に関する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２６９２３８号公報
【特許文献２】特開２０１１−１００１９０号公報
【特許文献３】特開平１１−２５９３３１号公報
【特許文献４】特開２００１−８６１１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、管理者は、メッセージから一意にエラーや原因を確定できるわけではない。すなわち、管理者は、エラーや原因の確定までに、新たに取得した情報によりメッセージとは無関係な対処履歴を排除しながらエラーや原因の絞り込みを行う必要がある。このような方法では、エラーや原因の確定に必要な情報が一度にはわからないため、情報採取に長時間を要するおそれがある。また、多階層システムの場合、メッセージを発信した装置に異常がなくても他の階層でのエラーによりメッセージが発信されることがある。したがって、多階層システムの情報採取範囲は広いため、この点からも情報採取に長時間を要するおそれがある。
【０００６】
このように、情報採取に長時間を要する場合、装置がメッセージ通知後に処理を継続実行した結果、状況が改善されたりログが消去されるなどして、必要な情報を取得できなくなるおそれがある。
【０００７】
１つの側面では、本発明は、適切な確認事項の出力が可能な資料採取支援プログラム、資料採取支援方法及び支援装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一つの態様では、資料採取支援プログラムは、装置の識別情報と、該装置から出力された事象に関するメッセージの受信に応じて、前記装置を含むシステムの構成情報から前記装置の接続先の装置の情報を取得し、事象と、該事象が発生した原因と、該事象に関し確認すべき確認事項とを含む過去の事例を記憶する記憶部を参照し、受信した前記メッセージの事象に基づいて、前記装置と、取得した前記接続先の装置とに関する過去の事例を抽出し、抽出した前記過去の事例に含まれる確認事項を出力する、処理をコンピュータに実行させるプログラムである。
【発明の効果】
【０００９】
適切な確認事項を出力することができる。
【図面の簡単な説明】
【００１０】
【図１】第１の実施形態に係る情報処理システムの構成を概略的に示す図である。
【図２】図２（ａ）は、利用者端末のハードウェア構成を示す図であり、図２（ｂ）は、エラー原因特定装置のハードウェア構成を示す図である。
【図３】エラー原因特定装置の機能ブロック図である。
【図４】図４（ａ）は、顧客環境定義情報の一例を示す図であり、図４（ｂ）は、構成情報の一例を示す図である。
【図５】顧客情報ＤＢのデータ構造の一例を示す図である。
【図６】図６（ａ）、図６（ｂ）は、製品検索ＤＢに格納されている過去の事例を示す図である。
【図７】エラー原因特定装置の処理の一例を示すフローチャートである。
【図８】利用者端末に表示される入力画面の一例を示す図である。
【図９】図９（ａ）〜図９（ｃ）は、パターン１において利用される事例リスト、該当事例リストについて説明するための図である。
【図１０】図１０（ａ）は、パターン１において利用者端末に表示される確認事項の画面の例であり、図１０（ｂ）は、パターン１において利用者端末に表示されるエラーの原因を表示する画面の例である。
【図１１】図１１（ａ）は、パターン２において抽出される過去の事例（その１）を示す図であり、図１１（ｂ）、図１１（ｃ）は、パターン２において利用される事例リストの一例を示す図である。
【図１２】図１２（ａ）、図１２（ｂ）は、パターン２において抽出される過去の事例（その２）を示す図である。
【図１３】図１３（ａ）〜図１３（ｄ）は、パターン２において利用される事例リスト、確認事項の画面、該当事例リストの例を示す図である。
【図１４】図１４（ａ）はパターン２において利用される事例リストを示す図であり、図１４（ｂ）は、パターン２において抽出される過去の事例（その３）を示す図である。
【図１５】図１５（ａ）はパターン２において利用される事例リストを示す図であり、図１５（ｂ）は、パターン２において利用される該当事例リストを示す図である。
【図１６】図１６（ａ）は、パターン２において利用される該当事例リストを示す図であり、図１６（ｂ）は、パターン２において利用者端末に表示されるエラーの原因を表示する画面の例である。
【図１７】第２の実施形態に係る過去の事例を示す図である。
【図１８】図１８（ａ）、図１８（ｂ）は、第２の実施形態において、利用者端末に表示される確認事項の画面の例を示す図である。
【発明を実施するための形態】
【００１１】
《第１の実施形態》
以下、第１の実施形態について、図１〜図１６に基づいて詳細に説明する。図１には、第１の実施形態に係る情報処理システム１００の構成が概略的に示されている。
【００１２】
本第１の実施形態の情報処理システム１００は、利用者端末７０と、支援装置としてのエラー原因特定装置１０と、を備える。利用者端末７０と、エラー原因特定装置１０は、インターネットなどのネットワーク８０に接続されている。
【００１３】
利用者端末７０は、多階層システムを利用するオペレータが利用する端末である。多階層システムは、図４（ｂ）に示すようなＷＥＢサーバＷ１、Ｗ２…、ＡＰサーバＡ１、Ａ２…、ＤＢサーバＤ１、Ｄ２…が接続されたシステムである。
【００１４】
図２（ａ）には、利用者端末７０のハードウェア構成が概略的に示されている。図２（ａ）に示すように、利用者端末７０は、ＣＰＵ（Central Processing Unit）１９０、ＲＯＭ（Read Only Memory）１９２、ＲＡＭ（Random Access Memory）１９４、記憶部（ここではＨＤＤ（Hard Disk Drive））１９６、ネットワークインタフェース１９７、表示部１９３、入力部１９５、及び可搬型記憶媒体１９１に記憶されたデータやプログラムを読み取り可能な可搬型記憶媒体用ドライブ１９９等を備えている。これら利用者端末７０の構成各部は、バス１９８に接続されている。表示部１９３は、液晶ディスプレイ等を含み、入力部１９５は、キーボードやマウス、タッチパネルなどを含む。
【００１５】
図１に戻り、エラー原因特定装置１０は、利用者端末７０からエラー（事象）に関する情報（メッセージ）を受信した場合に、利用者端末７０を利用するオペレータに確認すべき確認事項を特定し、利用者端末７０に送信する。また、エラー原因特定装置１０は、利用者端末７０から確認項目の確認結果を受信した場合に、受信した確認結果に基づいて、新たな確認項目を特定したり、エラーの原因を特定したりする。
【００１６】
図２（ｂ）には、エラー原因特定装置１０のハードウェア構成が概略的に示されている。図２（ｂ）に示すように、エラー原因特定装置１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ＨＤＤ）９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらエラー原因特定装置１０の構成各部は、バス９８に接続されている。エラー原因特定装置１０は、ＣＰＵ９０がＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（資料採取支援プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（資料採取支援プログラムを含む）を実行することで、図３に示す各部として機能する。
【００１７】
図３には、エラー原因特定装置１０の機能ブロック図が示されている。エラー原因特定装置１０では、ＣＰＵ９０がプログラムを実行することで、送受信部１２、構成情報作成部１４、及びデータ処理部１６として機能する。なお、図３には、ＨＤＤ９６等に格納されている顧客情報ＤＢ２０、事例リスト２２、該当事例リスト２４、及び記憶部としての製品検索ＤＢ２６についても図示されている。
【００１８】
送受信部１２は、利用者端末７０との間で情報のやり取りを行う。構成情報作成部１４は、送受信部１２を介して、利用者端末７０等から取得した顧客環境定義情報を利用して、多階層システム内における各サーバの接続関係を構成情報として特定し、顧客情報ＤＢ２０に格納する。
【００１９】
ここで、図４（ａ）には、顧客環境定義情報の一例が示されている。顧客環境定義情報においては、各サーバに接続されているサーバ（接続先のサーバ）の情報が定義されている。構成情報作成部１４は、図４（ａ）の顧客環境定義情報を受信すると、該情報に基づいて、図４（ｂ）に示すような多階層システムの構成情報を生成する。そして、構成情報作成部１４は、図４（ｂ）の構成情報に基づいて、図５に示すような顧客情報ＤＢ２０を生成する。なお、図５の顧客情報ＤＢ２０は、顧客名と、接続元のサーバのサーバ名及び製品名と、接続先のサーバのサーバ名及び製品名と、が関連付けた状態で格納されている。
【００２０】
図３に戻り、データ処理部１６は、利用者端末７０から受信した事象（エラー）に関する情報や顧客情報ＤＢ２０に格納されているデータに基づいて、対応する過去の事例を製品検索ＤＢ２６から抽出する。また、データ処理部１６は、抽出した過去の事例に基づいて、利用者端末７０を利用するオペレータに確認させる必要がある確認事項を特定し、送受信部１２を介して利用者端末７０に送信する。そして、データ処理部１６は、確認事項に対するオペレータの回答結果を送受信部１２を介して受信すると、回答結果に基づいてエラー（事象）が発生した原因を特定する。
【００２１】
ここで、製品検索ＤＢ２６には、過去の事例が多数格納されている。過去の事例は、具体的には図６（ａ）や図６（ｂ）に示すようなデータ構造を有している。例えば、図６（ａ）の事例の場合、ＷＥＢサーバ（ＷＥＢＸＸ）において、事象「Applicationエラー」が発生した場合に、確認項目「XXlogにApplicationエラーが出力されている」ことがオペレータにより確認されれば、エラーの原因が「XXXXである」と特定できるという内容が格納されている。また、図６（ｂ）の事例の場合、原因についての記載はないが、ＡＰサーバ（ＡＰＸＸ）において、事象「タイムアウト」が発生した場合に、確認項目「YYY.logでタイムアウトが出力されている」ことがオペレータにより確認されれば、ＤＢサーバ（DBXX）に関する事例を事象「遅延」で再検索する必要があるという内容が格納されている。
【００２２】
なお、データ処理部１６が利用する事例リスト２２や該当事例リスト２４の詳細については、後述する。
【００２３】
次に、情報処理システム１００における処理について、図７のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。図７は、エラー原因特定装置１０の処理を示すフローチャートである。
【００２４】
図７の処理の前提として、構成情報作成部１４は、エラー原因特定装置１０にアクセス可能な利用者端末７０のオペレータが利用する多階層システムの構成情報（図４（ｂ）参照）を生成し、図５の顧客情報ＤＢ２０に格納しているものとする。
【００２５】
図７の処理では、まず、ステップＳ１０において、送受信部１２が、利用者端末７０から「顧客名」、「サーバ名」、「事象」を含むメッセージを受信するまで待機する。ここで、オペレータは、多階層システムにおいてエラーが発生した場合、利用者端末７０の表示部９３に図８に示すような入力画面を表示させ、入力部９５を介して各項目への入力を行った後「検索」ボタンを押す。これにより、利用者端末７０からエラー原因特定装置１０（送受信部１２）に対して発生した事象に関するメッセージが送信されることになる。なお、図８では、顧客名「ＡＡ社」のＷＥＢサーバ（Ｗ２）において、「Applicationエラー」が発生したという情報が送受信部１２で受信されることになる。なお、サーバ名「Ｗ２」は、事象が発生した装置の識別情報を意味する。
【００２６】
送受信部１２がメッセージを受信すると、送受信部１２からデータ処理部１６にメッセージが送信され、ステップＳ１２に移行する。ステップＳ１２に移行すると、データ処理部１６は、「顧客名」及び「サーバ名」をキーとして、顧客情報ＤＢ２０を検索する。この場合、データ処理部１６は、図５の顧客情報ＤＢ２０を参照して、キーとしたサーバに接続されているサーバを抽出する。例えば、キーとしたサーバが「Ｗ２」であれば、「Ｗ２」に接続されている「Ａ２」、「Ａ３」が抽出される。
【００２７】
次いで、ステップＳ１４では、データ処理部１６は、検索結果を接続元の製品名、接続先の製品名で集計する。上記の例では、集計により、「Ｗ２」の製品名「ＷＥＢＸＸ」と、「Ａ２」、「Ａ３」の製品名「ＡＰＸＸ」が特定される。
【００２８】
次いで、ステップＳ１６では、データ処理部１６が、集計結果に基づいて製品検索ＤＢ２６から過去の事例を検索し、事例リスト２２に追加する。例えば、上記の例では、サーバ「ＷＥＢＸＸ」と、事象「Applicationエラー」に基づいて、過去の事例を検索する。ここでは、例えば、図６（ａ）の事例１のみが検索されたとする。なお、図６（ａ）の事例１のみが検索された例をパターン１とし、以下パターン１の処理について説明する。
【００２９】
（パターン１）
パターン１の場合、事例リスト２２には、図９（ａ）に示すように、検索製品「ＷＥＢＸＸ」、検索事例「事例１」が格納される。なお、この段階では、事例リスト２２の「結果（確認項目）」、「完了フラグ」の欄は、空白となっている。
【００３０】
次いで、ステップＳ１８では、データ処理部１６は、事例リスト２２の中から、完了フラグが入っていない最新事例を抽出する。なお、最新事例とは、事例リスト２２の最下行に位置する事例を意味する。ここでは、図９（ａ）より、検索製品「ＷＥＢＸＸ」、検索事例「事例１」が抽出される。
【００３１】
次いで、ステップＳ２０では、データ処理部１６が、ステップＳ１８において事例を抽出できたか否かを判断する。ここでの判断が肯定されると、データ処理部１６は、ステップＳ２２に移行し、抽出した事例から確認項目を抽出する。パターン１においては、データ処理部１６は、図６（ａ）から確認項目「XXlogにApplicationエラーが出力されている」を抽出する。
【００３２】
次いで、ステップＳ２４では、データ処理部１６は、送受信部１２を介して、利用者端末７０に対し確認項目を表示した画面を送信する。利用者端末７０では、受信した確認項目を記載した図１０（ａ）に示すような画面（ただし、チェックボックスへのチェックは無い）を表示部１９３上に表示する。
【００３３】
次いで、ステップＳ２６では、データ処理部１６は、利用者端末７０から確認項目に対する確認結果（回答）を受信するまで待機する。オペレータが、図１０（ａ）の画面においてＹＥＳ又はＮＯのいずれかのチェックボックスにチェックを入れ、「返信」ボタンを押すと、利用者端末７０からエラー原因特定装置１０へ確認結果（回答）が送信される。したがって、データ処理部１６は、送受信部１２を介して確認結果（回答）を受信した段階で、ステップＳ２８に移行する。
【００３４】
ステップＳ２８に移行すると、データ処理部１６は、受信した確認結果を事例リスト２２の「結果（確認項目）」の欄に格納するとともに、「完了フラグ」の欄に○を格納する。なお、図１０（ａ）の画面のように、オペレータがＹＥＳにチェックを入れた場合、データ処理部１６は、事例リスト２２の「結果（確認項目）」の欄に「○」を格納する。一方、オペレータがＮＯにチェックを入れた場合、データ処理部１６は、事例リスト２２の「結果（確認項目）」の欄に「×」を格納する。
【００３５】
次いで、ステップＳ３０では、データ処理部１６は、ステップＳ２８において「結果（確認項目）」の欄に○が格納されたか否かを判断する。このステップＳ３０の判断が肯定された場合には、ステップＳ３２に移行し、データ処理部１６は、事例に「原因」の具体的内容が記載されているか否かを判断する。パターン１の場合、図６（ａ）の事例に原因「XXXXである」が記載されているので、ステップＳ３２の判断は肯定され、ステップＳ３４に移行する。なお、ステップＳ３０の判断が否定された場合には、ステップＳ１８に戻る。
【００３６】
ステップＳ３４に移行すると、データ処理部１６は、事例を該当事例リスト２４に追加し、事例の原因について正しいか否かを確認した後、確認結果を該当事例リスト２４に追加する。具体的には、データ処理部１６は、事例を図９（ｂ）に示すように該当事例リスト２４に追加し、事例の原因が正しいか否かを問う画面を利用者端末７０に送信する。なお、この段階では、該当事例リスト２４の「結果（原因）」の欄は空白となっている。そして、データ処理部１６は、利用者端末７０から正しい旨の返信があった場合には、図９（ｃ）に示すように「結果（原因）」の欄に「○」を追加する。なお、利用者端末７０から正しくない旨の返信があった場合には、データ処理部１６は、該当事例リスト２４の「結果（原因）」の欄に「×」を追加する。その後は、ステップＳ１８に戻る。
【００３７】
ステップＳ１８に戻ると、データ処理部１６は、再度、事例リスト２２の完了フラグが入っていない最新事例を抽出する。そして、次のステップＳ２０では、データ処理部１６は、抽出できたか否かを判断する。なお、パターン１では、事例リスト２２に格納された事例が１つであり、新たな事例を抽出できないので、ステップＳ２０の判断は否定される。
【００３８】
ステップＳ２０の判断が否定されると、ステップＳ４０に移行し、データ処理部１６は、該当事例リスト２４に基づいて画面表示を行う。この場合、データ処理部１６は、送受信部１２を介して、図６（ａ）の事例１の原因「XXXXである」が表示された画面（図１０（ｂ）参照）を利用者端末７０に送信する。利用者端末７０では、受信した画面（図１０（ｂ）)を表示部１９３上に表示するので、オペレータは、表示部１９３を見ることにより、エラーの原因を認識することが可能となる。
【００３９】
ステップＳ４０の処理が終了した後は、図７の全処理が終了する。
【００４０】
（パターン２）
次に、別のパターン（パターン２）について説明する。パターン２では、ステップＳ１４における集計処理により、「Ｗ２」の製品名「ＷＥＢＸＸ」と、「Ａ２」、「Ａ３」の製品名「ＡＰＸＸ」が特定されたとする。また、ステップＳ１６においては、図１１（ａ）に示すようなサーバ「ＷＥＢＸＸ」に関する複数の事例（事例１，２）が検索されたとする。なお、ステップＳ１６では、図１１（ｂ）に示すように、事例リスト２２に対して２つの事例が格納される。
【００４１】
次いで、ステップＳ１８では、データ処理部１６は、事例リスト２２から完了フラグが入っていない最新事例「事例２」を抽出する。その後、ステップＳ２０の判断が肯定されると、データ処理部１６は、ステップＳ２２に移行する。
【００４２】
ステップＳ２２に移行すると、データ処理部１６は、確認項目として、図１１（ａ）に示す「XXlogにApplicationエラーが出力されている」を抽出する。また、ステップＳ２４において、データ処理部１６は、抽出した確認項目（図１０（ａ）と同様の画面）を利用者端末７０に送信する。
【００４３】
そして、データ処理部１６は、利用者端末７０からの確認項目に対する確認結果を受信すると（Ｓ２６：肯定）、事例リスト２２の「結果（確認項目）」の欄への入力を行うとともに、「完了フラグ」の欄に「○」を格納する。なお、本例では、図１１（ｃ）に示すように、結果（確認項目）として「○」が格納されたものとする。
【００４４】
次いで、ステップＳ３０の判断が肯定されると、次のステップＳ３２では、データ処理部１６は、事例（図１１（ａ）の事例２）に原因が記載されているか否かを判断する。このステップＳ３２の判断が否定されると、データ処理部１６は、ステップＳ３６に移行する。
【００４５】
ステップＳ３６に移行した場合、データ処理部１６は、事例に記載されている接続先製品（図１１（ａ）のＡＰＸＸ）を接続元製品に変換し、接続先事象「タイムアウト」を接続元製品の事象に変換して、ステップＳ１２に戻る。
【００４６】
ステップＳ１２に戻ると、データ処理部１６は、「顧客名」及び「サーバ名」をキーとして、顧客情報ＤＢ２０を検索する。この場合、データ処理部１６は、図５の顧客情報ＤＢ２０を参照して、キーとしたサーバ名「Ａ２」、「Ａ３」を用い、Ａ２、Ａ３に接続されているサーバ名「Ｄ２」、「Ｄ３」を抽出する。次いで、ステップＳ１４では、データ処理部１６は、検索結果を製造元の製品名、接続先の製品名で集計する。ここでは、集計により、「Ｄ２」、「Ｄ３」の製品名「ＤＢＸＸ」が特定される。
【００４７】
次いで、ステップＳ１６では、データ処理部１６は、製品検索ＤＢ２６から、接続元製品「ＡＰＸＸ」、事象「タイムアウト」の事例を検索し、事例リストに追加する。なお、ここでは、図１２（ａ）、図１２（ｂ）に示すような２つの事例（事例１、２）が検索され、図１３（ａ）に示すように、事例リスト２２にＡＰＸＸの事例１、２が追加されたものとする。
【００４８】
次いで、データ処理部１６は、事例リスト２２の最下行に位置するＡＰＸＸの事例２（図１２（ｂ））を抽出すると（Ｓ１８、Ｓ２０：肯定）、確認項目「ZZ.logでタイムアウトが出力されている」を利用者端末７０に送信する（Ｓ２２，Ｓ２４）。この場合、オペレータが最初に入力したサーバ名「Ｗ２」に接続されているＡＰは、「Ａ２」、「Ａ３」の２つである。したがって、データ処理部１６は、図１３（ｂ）に示すように、確認項目として２つのＡＰサーバ「Ａ２」、「Ａ３」それぞれの確認項目を利用者端末７０に送信する。
【００４９】
その後、データ処理部１６は、利用者端末７０から結果（確認項目）を受信すると（Ｓ２６：肯定）、結果（確認項目）と完了フラグ「○」を事例リスト２２に格納する（Ｓ２８）。図１３（ｂ）の例のように、少なくとも一方の確認事項がＹＥＳである場合には、図１３（ｃ）に示すように、結果（確認項目）の欄には「○」が格納されるものとする。
【００５０】
次いで、データ処理部１６は、ステップＳ３０の判断が肯定されると、事例に原因が記載されているか判断する（Ｓ３２）。図１２（ｂ）の例では、事例に「原因」の具体的内容が記載されているので、ステップＳ３４に移行する。そして、ステップＳ３４では、データ処理部１６は、前述と同様、事例を該当事例リスト２４に追加するとともに、事例の原因について正しいか否かを確認した後、確認結果を該当事例リスト２４に追加する。なお、本例では、データ処理部１６は、ユーザが図１３（ｂ）の画面においてＹＥＳと回答したＡＰサーバ「Ａ２」における「ＧＣ発生」がエラー原因として正しいかどうかを確認する。ここでは、一例として、エラー原因「ＧＣ発生」の確認結果が「正しい」であったとし、図１３（ｄ）に示すように、該当事例リスト２４の結果（原因）の欄には「○」が格納されたとする。
【００５１】
その後は、ステップＳ１８に戻り、データ処理部１６は、次の事例（図１３（ｃ）の完了フラグが入っていない最新の事例である、図１２（ａ）に示すＡＰＸＸの事例１）についての処理を、上記と同様にして実行する。
【００５２】
この場合、ステップＳ２８が行われた段階で、図１４（ａ）に示すように、事例リスト２２のＡＰＸＸの事例１の結果（確認項目）の欄に「○」が格納されたとする（Ｓ３０：肯定）。そして、ステップＳ３２においては、図１２（ａ）の事例１には原因が記載されていないので、判断は否定され、ステップＳ３６に移行する。ステップＳ３６に移行すると、データ処理部１６は、事例に記載されている接続先製品（図１２（ａ）のＤＢＸＸ）を接続元製品に変換し、接続先事象「遅延」を接続元製品の事象に変換して、ステップＳ１６に戻る。
【００５３】
その後は、図１４（ｂ）に示すようなＤＢＸＸの事例１が抽出されると（Ｓ１８）、図１２（ｂ）のＡＰＸＸの事例２と同様に処理を実行し、事例リスト２２及び該当事例リスト２４を更新する（Ｓ２８，Ｓ３４）。例えば、事例リスト２２は、図１５（ａ）のように更新され、該当事例リスト２４は、図１５（ｂ）のように更新される。
【００５４】
更に、ステップＳ１８に戻り、事例リスト２２から残りの事例（ＷＥＢＸＸの事例１）が抽出されると、上記と同様の処理が実行され、例えば、該当事例リスト２４が図１６（ａ）のように更新される。
【００５５】
そして、ステップＳ２０の判断が否定されると、データ処理部１６は、ステップＳ４０に移行する。ステップＳ４０では、データ処理部１６は、該当事例リスト２４（図１６（ａ））に基づいて、図１６（ｂ）に示すような画面を生成し、生成した画面を送受信部１２を介して利用者端末７０に対して送信する。利用者端末７０では、受信した画面（図１６（ｂ））を表示部１９３上に表示するので、オペレータは、表示部１９３を見ることにより、エラーの原因を認識することが可能となる。
【００５６】
以上によりパターン２の処理が終了する。
【００５７】
なお、これまでの説明から分かるように、本実施形態では、データ処理部１６を含んで、多階層システムの顧客情報ＤＢ２０からサーバの接続先の情報を取得する取得部、及び製品検索ＤＢ２６を参照し、受信したメッセージの事象（エラー）に基づいて、サーバと、接続先のサーバとに関する過去の事例を抽出する抽出部として機能する。また、データ処理部１６と、送受信部１２とにより、出力部として機能する。
【００５８】
以上、詳細に説明したように、本第１の実施形態によると、データ処理部１６は、サーバ名（例えば、Ｗ２）とサーバＷ２から出力された事象に関するメッセージを受信すると、サーバＷ２を含むシステム（多階層システム）の構成情報を格納する顧客情報ＤＢ２０からサーバＷ２の接続先のサーバ（例えば、Ａ２，Ａ３）の情報を取得する（Ｓ１２）。そして、データ処理部１６は、事象と、原因と、確認事項とを含む過去の事例を記憶する製品検索ＤＢ２６を参照し、受信したメッセージの事象に基づいて、サーバＷ２やＡ２、Ａ３に関する過去の事例を抽出し（Ｓ１８）、抽出した過去の事例に含まれる確認事項を利用者端末７０に出力する（Ｓ２２，Ｓ２４）。これにより、本実施形態では、過去の事例の中から、オペレータが利用する多階層システムの構成情報に基づいて、適切な事例を抽出して、事例に含まれる適切な確認項目を利用者端末７０に対して出力することができる。したがって、本実施形態のように多階層システムの場合であっても、自動的にオペレータに確認すべき確認項目を最小限に絞ることができるため、無駄な質問がなくなり、確認に要する時間を削減することが可能となる。
【００５９】
また、製品検索ＤＢ２６に格納されている過去の事例には、参照すべき接続先の装置の情報（接続先製品）と、該接続先の装置の事象（接続先事象）とが記載されている。これにより、接続元製品と事象の情報から抽出される確認事項が正しいと確認された場合に、接続先製品と事象の情報から抽出される適切な確認事項を利用者端末７０に対して出力することが可能となる。
【００６０】
また、本第１の実施形態では、データ処理部１６は、確認項目を確認した結果を受信すると、確認済みの確認項目を含む過去の事例に記載されている原因を特定し、利用者端末７０に出力する（Ｓ３４）。これにより、オペレータは、最小限の確認項目を確認することで、事象が発生した原因を認識することが可能となる。
【００６１】
《第２の実施形態》
次に、第２の実施形態について説明する。本第２の実施形態の情報処理システムの構成は、上述した第１の実施形態の情報処理システムの構成と同様となっているが、処理の一部が異なる。以下、異なる点を中心に第２の実施形態について説明する。
【００６２】
図１７には、本第２の実施形態において製品検索ＤＢ２６に格納される過去の事例が示されている。図１７に示すように、本第２の実施形態の過去の事例においては、確認項目の記載方法が、第１の実施形態と異なっている。
【００６３】
具体的には、図１７に示すように確認項目の欄が「確認方法」と「内容」に分割されている。例えば、第１の実施形態において確認項目「XXlogにApplicationエラーが出力されている」が記載されていた場合、第２の実施形態では、確認項目の確認方法の欄に「XXlog」が記載され、内容の欄に「Applicationエラーが出力されている」が記載される。
【００６４】
本第２の実施形態では、図７のステップＳ２２において、データ処理部１６が確認項目を抽出する際、同一接続元製品（サーバ）で、かつ同一事象の過去の事例が複数存在する場合には、確認方法が共通する事例を纏めて（グルーピングして）抽出する。例えば、図１７の例では、データ処理部１６は、事例１と事例ｎを纏めて抽出する。この場合、ステップＳ２４においては、データ処理部１６は、図１８（ａ）に示すような確認事項を複数表示した画面を利用者端末７０に送信することになる。この場合、オペレータによる確認作業の際に、重複作業の発生を抑制することが可能となる。
【００６５】
一方、図１７の事例２のように、確認方法が共通する事例が他に存在しない場合には、データ処理部１６は、事例２の処理の際に、図１８（ｂ）に示すような画面を利用者端末７０に送信することになる。
【００６６】
以上説明したように、本第２の実施形態によると、データ処理部１６は、同一の接続元製品及び同一の事象の過去の事例が複数あり、該複数の過去の事例に含まれる確認事項の確認方法が共通する場合には、抽出した複数の確認事項をまとめて利用者端末７０に送信する。これにより、利用者は、確認方法が共通する確認事項を一度に認識することができるので、確認作業の効率化を図ることが可能となる。
【００６７】
なお、上記各実施形態では、オペレータが利用者端末７０を用いて直接エラー原因特定装置１０にアクセスする場合について説明したが、これに限られるものではない。例えば、オペレータは、システム管理者やサポート員に対して、問い合わせを行い、システム管理者やサポート員が、端末を介して、エラー原因特定装置１０にアクセスするようにしてもよい。この場合にも、オペレータとシステム管理者やサポート員との間のやり取りの時間を削減することができる。また、確認事項の選定においてシステム管理者やサポート員の技量（記憶や判断）が不要であるため、システム管理者やサポート員の負担軽減を図ることができる。
【００６８】
なお、上記各実施形態では、多階層システムの上位のサーバ（例えばＷＥＢサーバ）からエラー（事象）に関するメッセージが出力された場合を例にとり説明したが、これに限られるものではない。例えば、下位のサーバ（例えばＤＢサーバ）からエラー（事象）に関するメッセージが出力された場合にも、上記各実施形態と同様の処理を行うことができる。この場合、顧客情報ＤＢ２０に、図５とは逆向きの接続関係を定義しておけばよい。
【００６９】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。
【００７０】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００７１】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００７２】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【００７３】
なお、以上の第１、第２の実施形態の説明に関して、更に以下の付記を開示する。
（付記１）  装置の識別情報と、該装置から出力された事象に関するメッセージの受信に応じて、前記装置を含むシステムの構成情報から前記装置の接続先の装置の情報を取得し、
事象と、該事象が発生した原因と、該事象に関し確認すべき確認事項とを含む過去の事例を記憶する記憶部を参照し、受信した前記メッセージの事象に基づいて、前記装置と、取得した前記接続先の装置とに関する過去の事例を抽出し、
抽出した前記過去の事例に含まれる確認事項を出力する、
処理をコンピュータに実行させることを特徴とする資料採取支援プログラム。
（付記２）  前記記憶部は、参照すべき接続先の装置の情報と、該接続先の装置の事象を記憶することを特徴とする付記１に記載の資料採取支援プログラム。
（付記３）  前記出力する処理は、抽出した同一の装置の過去の事例が複数あり、該複数の過去の事例に含まれる確認事項の確認方法が共通し、確認内容が異なる場合には、抽出した複数の前記確認事項をまとめて出力する、ことを特徴とする付記１又は２に記載の資料採取支援プログラム。
（付記４）  前記確認事項に対する確認結果を受信すると、前記記憶部に記憶されている過去の事例を参照して、前記装置において事象が発生した原因を特定し、出力する、
処理を前記コンピュータに実行させることを特徴とする付記１〜３のいずれかに記載の資料採取支援プログラム。
（付記５）  装置の識別情報と、該装置から出力された事象に関するメッセージの受信に応じて、前記装置を含むシステムの構成情報から前記装置の接続先の装置の情報を取得し、
事象と、該事象が発生した原因と、該事象に関し確認すべき確認事項とを含む過去の事例を記憶する記憶部を参照し、受信した前記メッセージの事象に基づいて、前記装置と、取得した前記接続先の装置とに関する過去の事例を抽出し、
抽出した前記過去の事例に含まれる確認事項を出力する、
処理をコンピュータが実行することを特徴とする資料採取支援方法。
（付記６）  前記記憶部は、参照すべき接続先の装置の情報と、該接続先の装置の事象を記憶することを特徴とする付記５に記載の資料採取支援方法。
（付記７）  前記出力する処理は、抽出した同一の装置の過去の事例が複数あり、該複数の過去の事例に含まれる確認事項の確認方法が共通し、確認内容が異なる場合には、抽出した複数の前記確認事項をまとめて出力する、ことを特徴とする付記５又は６に記載の資料採取支援方法。
（付記８）  前記確認事項に対する確認結果を受信すると、前記記憶部に記憶されている過去の事例を参照して、前記装置において事象が発生した原因を特定し、出力する、
処理を前記コンピュータが実行することを特徴とする付記５〜７のいずれかに記載の資料採取支援方法。
（付記９）  装置の識別情報と、該装置から出力された事象に関するメッセージの受信に応じて、前記装置を含むシステムの構成情報から前記装置の接続先の装置の情報を取得する取得部と、
事象と、該事象が発生した原因と、該事象に関し確認すべき確認事項とを含む過去の事例を記憶する記憶部を参照し、受信した前記メッセージの事象に基づいて、前記装置と、取得した前記接続先の装置とに関する過去の事例を抽出する抽出部と、
抽出した前記過去の事例に含まれる確認事項を出力する出力部と、
を備える支援装置。
（付記１０）  前記記憶部は、参照すべき接続先の装置の情報と、該接続先の装置の事象を記憶することを特徴とする付記９に記載の支援装置。
（付記１１）  前記出力部は、抽出した同一の装置の過去の事例が複数あり、該複数の過去の事例に含まれる確認事項の確認方法が共通し、確認内容が異なる場合には、抽出した複数の前記確認事項をまとめて出力する、ことを特徴とする付記９又は１０に記載の支援装置。
（付記１２）  前記確認事項に対する確認結果を受信すると、前記記憶部に記憶されている過去の事例を参照して、前記装置において事象が発生した原因を特定し、出力する原因出力部を更に備える付記９〜１１のいずれかに記載の支援装置。
【符号の説明】
【００７４】
１０  エラー原因特定装置（支援装置）
１２  送受信部（出力部の一部）
１６  データ処理部（取得部、抽出部、出力部の一部）
２０  顧客情報ＤＢ（構成情報）
２６  製品検索ＤＢ（記憶部）
【図１】
2017068464.tif 000003
【図２】
2017068464.tif 000004
【図３】
2017068464.tif 000005
【図４】
2017068464.tif 000006
【図５】
2017068464.tif 000007
【図６】
2017068464.tif 000008
【図７】
2017068464.tif 000009
【図８】
2017068464.tif 000010
【図９】
2017068464.tif 000011
【図１０】
2017068464.tif 000012
【図１１】
2017068464.tif 000013
【図１２】
2017068464.tif 000014
【図１３】
2017068464.tif 000015
【図１４】
2017068464.tif 000016
【図１５】
2017068464.tif 000017
【図１６】
2017068464.tif 000018
【図１７】
2017068464.tif 000019
【図１８】
2017068464.tif 000020