JP5439775B2 - 障害対応プログラム、障害対応装置、及び障害対応システム - Google Patents

Description

情報システムにおいては、様々な障害が発生する。このため、障害復旧の支援が不可欠である。一般に、情報システムの障害復旧に対する対処は、過去の障害事例を蓄積した知識ベースから障害の症状に応じた対処方法を取得し、その方法を実際に試みることにより行われている（例えば、特許文献１参照）。

図２０は、従来の障害対処方法を示す模式図である。
図２０に示すシステムにおいては、過去のトラブル事例１００１を知識化して、それを知識ベース２０００に登録しておく。知識ベース２０００には、「症状」とそれに対応する「対処方法」とから成るレコードが格納されている。システム管理者などのユーザ３０００が、端末３００１などから「症状」３００３を入力すると、その症状３０００３をキーとして、知識ベース２０００が検索される。そして、その検索結果２００３として、「原因」と「対処方法」などがユーザ３０００の端末３００１に返され、それが端末３００１に画面表示される。

このように、従来の障害対処システムは、過去に発生したトラブルの対処事例を知識化して知識ベースなどに蓄積しておき、トラブル発生時に、症状などを基に、該知識ベースなどを検索して、対処方法などを推薦するものであった。

しかしながら、実際の現場では、「複数のトラブルに対する対処を効率的に行えるようにしてほしい」という要望があった。例えば、「同じ原因でも、複数の症状が発生する場合があり、それらの症状にまとめて対処したい」という要求があった。しかしながら、複数の症状の内、どれとどれが同じ原因に起因したものであるかは、簡単には究明できない。そうであるならば、「せめて、トラブルに効率的に対処したい」というのがユーザの願望である。

ここで、従来のトラブル対処方法を整理すると、以下のような課題が見つかる。
［同じ原因でも、複数の症状が発生する場合があり、それら症状にまとめて対処する方法］
（１）原因が自明に分かる場合
・複数の症状を一つにまとめる
しかしながら、現実には、自明に分からない場合が多い。
（２）原因が自明に分からない場合
・発生時間や過去事例などを使い、『同じ原因だろう』と推測される症状を絞込み、それらを一つの症状にまとめる
しかしながら、『同じ原因だろう』と推測することは容易ではないし、非常に手間がかかる。
特開平８−２２１２９５号公開公報

本発明の目的は、情報システムにおける複数の症状を有する障害の原因に対して効率的に対処できるようにすることである。

本発明の障害対応プログラムは、一実施の形態として、コンピュータに、受け付けた障害による症状の情報に基づき過去に発生した障害による症状の対処事例を蓄積した障害対処知識を検索して対処候補を取得し、過去に実施した、または、実施中の対処を症状に関連付けて蓄積した対処履歴情報を参照して前記対処候補の評価を行い、前記対処候補を前記評価と関連づけて出力する、処理を実行させ、前記対処候補の評価は、前記受け付けた障害に対する対処中の他の症状にも関連付けられた対処候補の評価を高くする、ことを特徴とする。

本発明の障害対応プログラムは、一実施の形態として、前記対処候補の評価は、前記対処候補に優先度を付けることにより行われる、ことを特徴とする。
本発明の障害対応プログラムは、一実施の形態として、前記対処履歴情報内に多く含まれている対処候補ほど、優先度を高くする、ことを特徴とする。

上記障害対応プログラムによれば、対処履歴情報を参照することにより、対処中の他の症状にも有効な対処方法を優先的に推薦できる。
本発明の障害対応プログラムは、一実施の形態として、蓄積した前記対処履歴情報のうち、共通部分が多い対処履歴情報を一つに統合する処理を実行させることを特徴とする。

上記障害対応プログラムによれば、同一原因によって発生している症状を、一つの対処履歴情報に統合することができる。

開示のプログラム及び方法は、対処の過程で、自動的に、同じ原因に起因する症状を統合する。この結果、該統合に必要な人的手間を削減することが可能となる。また、同時進行している他の症状も考慮して、他の症状にも有効な対処方法を優先的に推薦する。この結果、複数の症状が発生するトラブルに対する総合対処時間を短縮することが可能となる。したがって、開示のプログラム及び方法によれば、情報システムにおける複数の症状が発生するトラブルに対して、効率的に対処できるようになる。

以下、図面を参照しながら、本発明の実施形態について説明する。
［原理］
まず、本発明の実施形態の原理を説明する。
（１）各症状に対してバラバラに対処を始め、行った対処方法の共通部分が多い多い症状を、一つの症状にまとめる。

この場合、後述するように、各症状の対処履歴を木構造のイメージに整理し、通ったパスの共通部分が多い症状を「同じ症状」にまとめる。こうすることで、対処の過程で、自然に、同じ原因の症状が一つにまとめられていく。これにより、「対処に必要な人手削減」、「作業の重複回避」、「症状を一つにまとめるための手間削減」などの効果が得られる。
（２）対処方法を推薦する際に、他の対処でも必要となっている作業も考慮する。

これは、同時進行している他の症状も考慮して、全体最適化を行うことである。こうすることで、本当は同じ原因に起因する症状でありながら「同じ症状」にまとめることができなかったものに対しても、互いに考慮し合いながら、対処方法が推薦される。この結果、総対処時間の短縮及び手間削減という効果が得られる。

［原理（１）、（２）の詳細］
次に、上記原理（１）、（２）について、図面を参照しながら、その具体的イメージを
説明する。

｛原理１｝
図１は、上記原理（１）の解決イメージを示す図である。図１（ａ）は症状１の対処履歴を示す木構造であり、図１（ｂ）は症状２の対処履歴を示す木構造である。ここで、症状１は「サーバＡの反応が遅い」であり、症状２は「サーバＢへの通信が途切れる」である。

図１（ａ）、（ｂ）において、共通の対処方法は太線の矩形枠で囲まれた部分である。すなわち、症状１の対処履歴１０と症状２の対処履歴２０において、対処履歴１０中の対処方法１１、１２、１３と、対処履歴２０中の対処方法２１、２２、２３が共通している。したがって、この場合には、対処方法１１（２１）、１２（２２）、１３（２３）を、「サーバＣが原因となって発生している症状」としてまとめる。

｛原理２｝
図２は、上記原理（２）の解決イメージを示す図である。図２（ａ）は症状１の対処方法候補を示し、図２（ｂ）は症状２の対処方法候補を示している。

図２（ａ）に示す対処方法候補群３０内の各対処方法候補（対処方法）は図１（ａ）に示す対処履歴１０から抽出したものであり、図２（ｂ）に示す対処方法候補群４０内の各対処方法候補（対処方法）は図１（ｂ）に示す対処履歴２０から抽出したものである。図２（ａ）、（ｂ）において、対処方法候補群３０と対処方法候補群４０において共通な対処方法は太い矩形枠で囲まれた部分である。すなわち、両対処方法候補群３０、４０において、対処方法候補群３０中の対処方法３１、３２と対処方法候補群４０中の対処方法４１、４２が共通している。したがって、この場合は、症状１と症状２の対処において、対処方法３１（４１）と対処方法３２（４２）が有効であると判断して、これら２つの対処方法（「回線を調べる」、「サーバＣを調べる」）の優先度を上げるようにする。

［実施形態］
｛システム概要｝
まず、本実施形態のシステムの概要を図３と図４を参照しながら説明する。

図３に示すように、ユーザ１００は、サーバＡの反応が遅くなった場合、自身の端末１０１から「サーバＡの反応が遅い」という初期症状１１１（１１１−１）と、行った対処１１２を含む症状１１０（１１０−１を本実施形態のトラブル対処システム２００に送る。この時点では、対処ＩＤ１２０（１２０−１）は“なし”（未設定）である。また、ユーザ１００は症状に対する対処をまだ行なっていないので、行なった対処１１２−１も“なし”に設定される。

トラブル対処システム２００は、該対処依頼１１０−１を受け取ると、優先度の高低が付与された複数の対処方法（この例では、３つの対処方法）をユーザ１００の端末１０１に返す。この例では、対処方法３１０−１（「サーバＡのプロセス数を調べる」）、対処方法３１０−２（「サーバＡの回線を調べる」）及び対処方法３１０−３（「サーバＢにｐｉｎｇを送ってみる」）をユーザ１００の端末１０１に返す。ここで、優先度の順位は、対処方法３１０−１、３１０−２、３１０−３の順である。また、対処方法３１０−３で用いられる“ｐｉｎｇ”は、サーバＢがＴＣＰ／ＩＰネットワークで正常に稼動しているかを調べるためのコマンドである。

また、トラブル対処システム２００は、今回、これらの対処方法３０１−１〜３１０−３に対して、識別子が“ＩＤ１１１”である対処ＩＤ１２０（１２０−２）を割り当て、
これをユーザ１００の端末１０１に返す。以後、ユーザ１００とトラブル対処システム２００は、今回のトラブルに関するやり取りを、この識別ＩＤ１２０−２を用いて行う。

ユーザ１００は、トラブル対処システム２００から上記対処方法３１０−１〜３１０−３を受け取ると、それらを試みる。そして、図４に示すように、前記初期症状１１１−１に加え、今回の対処によって判明した症状１１１（１１１−２）（「サーバＡのプロセス数が多い」）などと、今回行った対処１１２（「サーバＡのプロセス数を調べる」）を含む症状１１０（１１０−２）をトラブル対処システム２００に送る。これに対し、トラブル対処システム２００は、対処ＩＤ１２０−２（“ＩＤ１１１”）と共に、対処方法３１０−４（「サーバＡのＩ／Ｏを調べる」）、上記対処方法３１０−３及び対処方法３１０−５（「サーバＣにｐｉｎｇを送ってみる」）を、ユーザ１００の端末１０１に返す。この場合、優先度は、対処方法３１０−４、３１０−３、３１０−５の順である。

このようにしながら、ユーザ１００は、対処ＩＤ１２０を識別子として使用しながら、トラブルが解決するまで、「初期症状」、「対処によって判明した症状」及び「行った対処」を含む対処依頼を、トラブル対処システム２００に送り続ける。トラブル対処システム２００は、ユーザ１００から該対処依頼を受け取る毎に、対処ＩＤ１２０と共に、優先度が付けられた対処方法をユーザ１００に返す。

［システム構成］
図５は、図３と図４に示すトラブル対処システム２００の構成を示すブロック図である。

トラブル対処システム２００は、対処依頼処理部２１０、対処方法更新部２２０、対処方法推薦部２３０、症状統合部２４０、対処履歴管理情報２５０、対処方法検索部２６０及びトラブル対処知識２７０を備えている。

対処依頼処理部２１０は、上述した図３及び図４に示す方法で、ユーザ１００の端末１０１との間で、対処依頼と対処方法のやり取りを行う。該対処依頼は対処ＩＤ１２０と症状１１０を含み、該対処方法は対処ＩＤ１２０と対処方法３１０を含む。対処依頼処理部２１０は、ユーザ１００の端末１０１から対処依頼を受信すると、対処方法検索部２６０に対して、受け取った症状に対応する対処方法候補の検索を依頼する。また、対処方法更新部２２０に対して、ユーザ１００が実際に行った対処方法の更新を依頼する。また、対処方法更新部２２０に対して、対処方法検索部２６０から返された検索結果の優先度付けを依頼する。また、症状統合部２４０に対して、今回、ユーザ１００に端末１０１から受け取った症状と、対処中の症状（今までに対処した症状）との統合を依頼する。そして、症状統合部２４０の統合結果に応じた対処ＩＤと対処方法を、ユーザ１００の端末１０１に返す。

対処履歴管理情報２５０は、各症状に関する対処履歴情報（過去に行った対処方法に関する履歴情報）を、対処ＩＤと対応付けて管理しているテーブルである。
トラブル対処知識２７０は、症状に対応する対処方法を格納しているデータベースである。

対処方法検索部２６０は、対処依頼処理部２１０から検索依頼を受信すると、トラブル対処知識２７０を検索し、対処依頼処理部２１０から受け取った症状に対応する対処方法候補を取得する。そして、それを、対処依頼処理部２１０に返す。

対処方法更新部２２０は、対処依頼処理部２１０更新依頼を受信すると、対処履歴管理情報２５０中の該対処ＩＤに対応する対処履歴情報を更新する。
対処方法推薦部２３０は、対処依頼処理部２１０から推薦依頼を受信すると、対処履歴管理情報２５０を参照して、対処方法検索部２６０が検索した対処方法候補について優先度付けを行う。そして、各対処方法候補の優先度を対処依頼処理部２１０に返す。

症状統合部２４０は、対処依頼処理部２１０から統合依頼を受信すると、対処履歴管理情報２５０を参照して、現在処理中の対処ＩＤに関する対処履歴管理情報と対処方法に共通部分が多い対処履歴情報を有する対処履歴管理情報２５０内のその他の対処ＩＤが存在するか調べ、存在する場合には、それらの対処ＩＤの対処履歴情報を統合する。そして、その統合した対処履歴情報を対処依頼処理部２１０に返す。

＜本実施形態が実装されるコンピュータのハードウェア構成＞
図６は、図５に示す本実施形態のトラブル対処システム２００をプログラムの実行により実現するコンピュータのハードウェア構成を示す図である。

図６に示すコンピュータ５００は、ＣＰＵ５０１、メモリ５０２、入力装置５０３、表示装置５０４、外部記憶装置５０５、可搬型記憶媒体駆動装置５０６、ネットワーク接続装置５０７、及び、ＣＰＵ５０１と各構成要素５０２〜５０７を接続するバス５１０を備える。

ＣＰＵ５０１は、コンピュータ５００のシステム全体の動作を制御する中央演算処理装置である。メモリ５０２は、ＣＰＵ５０１が実行するプログラムがロードされる領域や該プログラムが実行する際に中間データを格納する作業領域などを備える主記憶装置である。入力装置５０３は、キーボードやマウスなどのポインティングデバイスを備える。表示装置５０４は、ＣＲＴディスプレイや液晶ディスプレイなどである。外部記憶装置５０５は、ＨＤＤ(Hard Disk Drive)やＳSＤ(Solid State Drive)などである。可搬型記憶媒体駆動装置５０６は、ＣＤ(Compact Disc)やＤＶＤ(Digital Video Disc)またはＵＳＢ(Universal Serial Bus)メモリなどの可搬型記憶媒体のデータのリード／ライトを行う装置である。ネットワーク接続装置５０７は、データゼンターや企業内システムに構築されたＬＡＮ(Local Area Network)などに接続するためのネットワークカードなどである。上記ＬＡＮは、ルータなどのネットワーク機器を介してインターネットやＶＰＮ(Virtual Private Network)などのＷＡＮ(Wide Area Network)に接続される。本実施形態においては、コンピュータ５００は、ネットワーク接続装置５０７を介して、ユーザ１００の端末１０１とＴＣＰ／IPなどの各種通信プロトコルにより通信を行う。

コンピュータ５００を本実施形態のトラブル対処システム２００として機能させるプログラム（障害対処プログラム）は、例えば、可搬型記憶媒体に格納されて、可搬型記憶媒体によって配布される。また、インターネットなどのネットワークを介して外部記憶装置５０５や可搬型記憶媒体駆動装置５０６に装着された可搬型記憶媒体にダウンロードしてインストールすることも可能である。

外部記憶装置５０５などにインストールされた前記障害対処プログラムは、例えば、表示装置５０４に表示されるユーザインターフェース画面を介して、システム管理者などによる入力装置５０３からの入力操作により、ＣＰＵ５０１により実行される。このＣＰＵ５０１の実行により、コンピュータ５００は、図５に示すトラブル対処システム２００が備える対処依頼処理部２１０、対処方法更新部２２０、対処方法推薦部２３０、症状統合部２４０及び対処方法検索部２６０の各機能を実現する。対処履歴管理情報２５０とトラブル対処知識２７０は、例えば、外部記憶装置５０５内、または可搬型記憶媒体駆動装置５０６に装着される可搬型記憶媒体内に作成される。

[動作]
上記構成のトラブル対処システム２００の処理を説明する。以下に述べる、
｛全体フロー｝
図７は、トラブル対処システム２００の全体フローである。

トラブル対処システム２００は、ユーザ１００の端末１０１から「トラブル対処依頼」を受けると（ステップＳ１）、推薦するトラブル対処方法を、ユーザ１００の端末１０１に返す（ステップＳ２）。

｛対処依頼処理部２１０の処理｝
図８は、図５の対処依頼処理部２１０の処理を示すフローチャートである。対処依頼処理部２１０は、図８のフローチャートに示す処理を、ユーザ１００の端末１０１から対処依頼を受信するごとに実行する。

対処依頼処理部２１０は、ユーザ１００の端末１０１から対処依頼を受け取ると、図８に示すフローチャートの処理を開始する。上記対処依頼は、パラメータｉとパラメータｉｄを含んでいる。ｉは「症状」を示すパラメータであり、ｉｄは「対処ＩＤ」を示すパラメータである。対処ＩＤは、ユーザ１００が現在対処中のトラブルに付与される識別子であり、システムにおいて一意的なものである。このため、ユーザ１００の端末１０１とトラブル対処システム２００は、対処ＩＤをやり取りする事で、対処中のトラブルを識別可能となっている。症状は、「症状（初期症状及び対処によって判明した症状）」と「ユーザ１００が行った対処」を含んでいる。

図８のフローチャートの説明を行う。
対処依頼処理部２１０は、まず、ｉｄが空であるか判断し（ステップＳ１１）、ｉｄが空であれば（ステップＳ１１、Ｙｅｓ）ステップＳ１２に進み、ｉｄが空でなければ（ステップＳ１１、Ｎｏ）ステップＳ１１３に進む。

対処ＩＤは、トラブル対処システム２００によって付与されるので、ユーザ１００の端末１０１から最初に受け取る対処ＩＤ（＝ｉｄ）は“空”となっている。したがって、ステップＳ１１の判断は、ユーザ１００が最初に症状を送ってきたかを判断する処理でもある。

対処依頼処理部２１０は、ステップＳ１２において、新しい対処ＩＤを（＝ｉｄ´）を生成し、ステップＳ１５に進む。一方、対処依頼処理部２１０は、ステップＳ１３において、パラメータｉｄ´にｉｄを代入する（ステップＳ１３）。この処理は、対処ＩＤ（＝ｉｄ）を保存する処理である。ステップＳ１３の処理に続いて、対処方法更新部２２０に、実際に行なった対処方法の更新を依頼し（ステップＳ１４）、ステップＳ１５に進む。ステップＳ１４の処理の詳細は後述する。尚、ステップＳ１４における「実際に行なった対処方法」は、ユーザ１００の端末１０１から受け取る「症状」に含まれている情報である。

対処依頼処理部２１０は、ステップＳ１５において、対処方法検索部２６０に、症状ｉに対する対処方法の検索を依頼する。対処方法検索部２６０は、該検索依頼を受け取ると、症状ｉをキーとしてトラブル対処知識２７０を検索し、症状ｉに対応する対処方法をトラブル対処知識２７０から取得する。そして、その取得した検索結果を対処依頼処理部２１０に返す。

対処依頼処理部２１０は、対処方法検索部２６０から検索結果を受け取ると、該検索結果が“空”であるか判断する（ステップＳ１６）。そして、検索結果が空でなければ（ステップＳ１６、Ｎｏ）ステップＳ１７に進み、検索結果が空であれば（ステップＳ１６、
Ｙｅｓ）ステップＳ２３に進む。

対処依頼処理部２１０は、ステップＳ１７において、対処方法推薦部２３０に、上記検索結果の優先度付けを依頼する。このステップＳ１７の処理の詳細は後述する。一方、対処依頼処理部２１０は、ステップＳ２３において、ユーザ１００の端末１０１に「対処方法なし」を返す。そして、本フローチャートの処理を終了する。

対処依頼処理部２１０は、ステップＳ１７に続いて、ｉｄが“空”であるか判断し（ステップＳ１８）、ｉｄが空でなければ（ステップＳ１８、Ｎｏ）ステップＳ１９に進み、ｉｄが空であれば（ステップＳ１１８、Ｙｅｓ）ステップＳ２２に進む。

このステップＳ１８の処理は、ステップＳ１１と同様に、現在の処理が、最初のトラブル対処処理であるかを判断する処理である。本実施形態のトラブル対処システム２００は、ユーザ１００の個々のトラブルに対して、そのトラブルに対する対処方法の履歴を対処履歴管理情報２５０に記録する。ステップＳ１９の処理は、ユーザ１００の端末１０１からの２回目以降の対処依頼においてのみ処理可能である。このため、対処依頼処理部２１０は、ステップＳ１８の処理により、ステップＳ１９に分岐するか否かを判断している。

対処依頼処理部２１０は、ステップＳ１９において、症状統合部２４０に、症状ｉと（今までに）対処中の症状との統合を依頼する。このステップＳ１９の処理の詳細は後述する。症状統合部２４０は、ステップＳ１９の処理を終了すると、対処依頼処理部２１０に統合結果を返す。対処依頼処理部２１０は、その統合結果を基に、ステップＳ１９において、症状ｉが統合されたか判断する（ステップＳ２０）。そして、統合されていれば（ステップＳ２０、Ｙｅｓ）ステップＳ２１に進み、統合されていなければ（ステップＳ２０、Ｎｏ）ステップＳ２２に進む。

対処依頼処理部２１０は、ステップＳ２１において、症状統合部２４０によって、症状ｉと統合された「対処中の症状」の対処ＩＤと、該対処ＩＤに対応する対処履歴情報において最後にリンクされている対処履歴の対処方法を、ユーザ１００の端末１０１に返す。そして、本フローチャートの処理を終了する。

一方、対処依頼処理部２１０は、ステップＳ２２において、ｉｄ´（対処ＩＤ）と、対処方法推薦部２３０から取得した「優先付けされた対処方法」を、ユーザ１００の端末１０１に返す。そして、本フローチャートの処理を終了する。

このように、対処依頼処理部２１０は、ユーザ１００の端末１０１から「対処依頼」を受信すると、対処方法検索部２６０、対処方法更新部２２０、対処方法推薦部２３０及び症状統合部２４０に依頼を出しながら、ユーザ１００の端末１０１から受け取った症状ｉに対処するための対処方法を、優先度を付けて、端末１０１に返す。また、対処履歴管理情報２５０に、各対処ＩＤに対応する対処方法の履歴情報を記録していく。

｛対処方法更新部２２０の処理｝
図９は、対処方法更新部２２０の処理（図５のステップＳ１４に該当）を示すフローチャートである。このフローチャートの処理は、図８のフローチャートのステップＳ１４の処理に該当する。

対処方法更新部２２０は、対処依頼処理部２１０から引数として、前記パラメータｉ（症状）と前記パラメータｉｄ（対処ＩＤ）を受け取り、図８のフローチャートの処理を開始する。

対処方法更新部２２０は、まず、ｉの中に、“行なった対処”の情報ｅが含まれているか判断する（ステップＳ３１）。この情報ｅは、上述した図４においては、症状１１０−２中の“サーバＡのプロセス数を調べる”に該当する。

対処方法更新部２２０は、ステップＳ３１において、情報ｅが含まれていると判断すると（ステップＳ３１、Ｙｅｓ）ステップＳ３２に進み、情報ｅが含まれていないと判断すると（ステップＳ３１、Ｎｏ）本フローチャートの処理を終了する。

対処方法更新部２２０は、ステップＳ３２において、対処履歴管理情報２５０に記録されている、対処ＩＤがｉｄである対処履歴情報について、その最後の対処履歴の「対処方法」を情報ｅで更新する（ステップＳ３２）。そして、本フローチャートの処理を終了する。

このように、対処方法更新部２２０は、対処履歴管理情報２５０中の対処ＩＤがｉｄである対処履歴情報について、その最後の対処履歴の「対処方法」を登録する。
図１０は、図９のフローチャートに示す処理の一例を示す図である。

図１０において、（ａ）は更新前の対処履歴管理情報２５０、（ｃ）は更新後の対処履歴管理情報２５０を示す。また、（ｂ）は、対処方法更新部２２０が対処依頼処理部２１０から受け取る引数ｉｄ（対処ＩＤ）、ｉ（症状）を示す。

図１０（ａ）、（ｃ）に示すように、対処履歴管理情報２５０は、各エントリに、「対処ＩＤ２５１」とそれに対応する「対処履歴情報１５２」とで構成されるレコードを格納しているテーブルである。

対処履歴管理情報２５０は、対処依頼処理部２１０が生成する対処ＩＤ２５１とそれに対応する対処履歴情報２５２の組から成るレコードを、対処ＩＤ２５１の生成順に格納している。対処履歴情報２５２は、ユーザ１００が実際に実施した対処方法を時系列順に記憶している。対処履歴情報２５２に格納されている対処履歴は、「対処方法ａ、［対処候補（対処方法候補）ａ１、対処候補ａ２、・・・］というデータ形式となっている。ここで、対処方法ａは、ユーザ１００が実際に行なった対処（前記情報ｅに該当）である。該対処方法ａは、［ ］内の対処候補の中の一つである。また、対処履歴において、［ ］内には、対処候補が優先度順に配置されている。尚、以後の明細書においては、「対処候補」を「対処方法候補」記載することにする。

図１０には、対処ＩＤ２５１がｉｄ３である対処履歴情報２５２の更新例を示している。図１０（ａ）に示すように、対処ＩＤ２５１がｉｄ３である更新前の対処履歴管理情報２５０−１のその最後の対処履歴の対処方法は、ユーザ１００の端末１０１から、ユーザ１００が行なった対処を、まだ受け取っていないので、“なし”に設定されている。この例では、対処依頼処理部２１０は、推薦すべき対処方法として、「回線調査」及び「サーバＣ調査」をユーザ１００の端末１０１に返す。このとき、優先度は「回線調査」の方が高くなっている。これに対し、図１０（ｂ）に示すように、対処依頼処理部２１０が、ユーザ１００の端末１０１から、対処ｉｄ（対処ＩＤ＝ｉｄ３）と共に症状ｉを受け取る。そして、対処方法更新部２２０に対し、上記のようにして対処方法の更新を依頼する。

対処方法更新部２２０は、対処方法更新部２２０から、対処ｉｄ（対処ＩＤ＝ｉｄ３）とその症状ｉ内に含まれる「行なった対処１１２」（＝回線調査）を受け取ると、対処履歴管理情報２５０内の、対処ＩＤ２５１がｉｄ３であるレコードの対処履歴情報２５２の最後の対処履歴の対処方法を「なし」から「回線調査」に更新する（図１０（ｃ）参照）。

｛対処方法推薦部２３０の処理｝
図１１は、図５の対処方法推薦部２３０の処理（図５のステップＳ１７に該当）を示すフローチャートである。

この処理において、対処方法推薦部２３０は、対処依頼処理部２１０から、引数として、ｉｄ´（対処ＩＤ）とＣ（対処方法候補群）を受け取る。そして、まず、レジスタＲを“空”に設定する（ステップＳ４１）。ここで、レジスタＲは、対処履歴を格納するレジスタである。次に、引数Ｃが“空”であるか判断し（ステップＳ４２）、空でなければ（ステップＳ４２、Ｎｏ）ステップＳ４３に進み、空であれば（ステップＳ４２、Ｙｅｓ）ステップＳ５２に進む。

ステップＳ４３において、Ｃから一つの対処方法候補ｃを取り出す。取り出し順序は、例えば、優先度順である。次に、変数ｐを“０”に初期設定する（ステップＳ４４）。ここで、変数ｐは優先度の数値を格納する変数である。続いて、対処履歴管理情報２５０から、対処ＩＤがｉｄ´に等しくない対処ＩＤに対応する対処履歴情報の全ての集合である情報Ｈを取出す（ステップＳ４５）。そして、情報Ｈが“空”か判断し（ステップＳ４６）、空でなければ（ステップＳ４６、Ｎｏ）ステップＳ４７に進み、空であればステップＳ５１に進む。

ステップＳ４７において、Ｈから一つの対処履歴情報ｈ（＝対処履歴情報２５２）を取出す。ステップＳ４７においては、Ｈの先頭行から順に一つの対処履歴情報ｈを取出す。そして、対処履歴情報ｈの中に対処方法候補ｃに等しい対処方法候補が存在するか判断し（ステップＳ４８）、存在しなければ（ステップＳ４８、Ｎｏ）ステップＳ４６に戻り、存在すれば（ステップＳ４８、Ｙｅｓ）ステップＳ４９に進む。
対処方法推薦部２３０は、２度目以降のステップＳ４６において、Ｈから次の対処履歴情報ｈを取出す。そして、再び、ステップＳ４７、Ｓ４８の処理を行う。

このようにして、対処方法推薦部２３０は、現在処理中の当該対処履歴情報ｈ中に対処方法候補ｃが存在するか調べ、対処方法候補ｃが存在すれば（ステップＳ４８、Ｙｅｓ）ステップＳ４９に進む。

対処方法推薦部２３０は、ステップＳ４９において、値ｐ´を計算する。この値ｐ´は、優先度ｐの重み付け計算に使用される値であり、優先度が高い程、大きな値に設定される。値ｐ´の計算の詳細は後述する。

次に、ｐ＋ｐ´を計算し、その計算結果をｐに代入する（ステップＳ５０）。そして、ステップＳ４６に戻る。
このようにして、対処方法推薦部２３０は、ステップＳ４６においてＨが空であると判断するまで（ステップＳ４６、Ｙｅｓ）ステップＳ４６〜Ｓ５０の処理を繰り返す。これにより、対処方法候補群Ｃ中の各対処方法候補ｃについて、その優先度ｐが算出される。

対処方法推薦部２３０は、ステップＳ４６において、Ｈが空であると判断すると（ステップＳ４６、Ｙｅｓ）ステップＳ５１に進む。
ステップＳ５１において、対処方法候補ｃをＲに追加する。この追加処理は、Ｒ内において、対処方法候補ｃが、そのｐの値が大きい順から並ぶようにするソート処理である。

対処方法推薦部２３０は、ステップＳ５１の処理が終了すると、ステップＳ４２に戻り、Ｃが空であるか判断する。そして、Ｃが空でなければ（ステップＳ４２、Ｎｏ）、再び、ステップＳ４７以降の処理を行う。

このようにして、対処方法推薦部２３０は、ステップＳ４２〜Ｓ５１の処理を繰り返す
ことによって、対処方法候補群Ｃ中の全ての対処方法候補について、その優先度ｐを計算する。そして、それら各対処方法候補を、優先度ｐが大きい方から順に、Ｒ内に並べる。

対処方法推薦部２３０は、ステップＳ４２において、Ｃが空である、つまり、Ｃ中から全ての対処方法候補ｃを取出したと判断すると（ステップＳ４２、Ｙｅｓ）ステップＳ５２に進む。

対処方法推薦部２３０は、ステップＳ５２において、対処履歴管理情報２５０に、対処ＩＤがｉｄ´である対処履歴情報として、Ｒを追加する。この追加は、例えば、上記Ｒを、対処履歴管理情報２５０中の最後尾に登録することによって行う。そして、Ｒを、対処依頼処理部２１０に返し（ステップＳ５３）、本フローチャートの処理を終了する。

上述したように、Ｒ内には、対処方法候補が優先度順に配置されている。したがって、対処方法推薦部２３０から対処依頼処理部２１０には、優先度順に配列された対処方法候補が送られる。図１１に示す処理フローにおいて、ｉｄが空の場合には、Ｈは空となっているので、ステップＳ４２〜Ｓ４６→Ｓ５１→Ｓ４２のループ処理がｃの個数に等しいだけ実行される。したがって、ユーザ１００の端末１０１から最初の対処依頼を受け取った場合、症状ｉの初期症状１１１−１に対応する全ての対処方法候補ｃの優先度ｐは“０”に設定される。したがって、初期症状１１１−１に対応する対処方法候補（対処依頼）の優先度ｐは全て等しくなるの。このため、Ｒには、対処方法検索部２６０の検索結果がそのまま設定される。

｛対処方法推薦部２３０の処理の説明｝
（１）対処全体を考慮して、優先度ｐを計算する方法
図１２は、対処方法推薦部２３０の処理の一例を示す図である。図１２に示す手法では、対処中の他の症状にも有効な対処方法を優先して推薦する。これは、対処履歴管理情報２５０の対処中の他の症状に対応する対処履歴情報２５２に多く含まれている対処候補（対処方法候補）ほど、その優先度ｐを高く設定することによって得られる。

図１２（ａ）は、対処依頼処理部２１０が対処方法推薦部２３０を起動する前の対処履歴管理情報２５０（２５０−５）の内容を示す図である。すなわち、対処履歴管理情報２５０−５は、対処方法推薦部２３０が更新する前の対処履歴管理情報の内容を示している。対処履歴管理情報２５０−５には、現在、対処中の３つの対処履歴情報２５２（対処ＩＤ２５１がｉｄ１〜ｉｄ３の対処履歴情報）が記録されている。

ここで、図１２（ｂ）に示すように、対処方法推薦部２３０は、対処依頼処理部２１０から、ｉｄ´（対処ＩＤ＝ｉｄ３）、対処方法候補群Ｃ（サーバＡ調査、サーバＢ調査、サーバＣ調査）を引数として受け取るものとする。この場合、上述した図１１のフローチャートのステップＳ４５において対処履歴情報２５２−５から取出される情報Ｈは、対処ＩＤが「ｉｄ１」の対処履歴情報２５２と「ｉｄ２」の対処履歴情報２５２の集合となる。この例では、対処方法候補群Ｃ内の各対処方法候補（この場合、サーバＡ調査、サーバＢ調査、サーバＣ調査）について、Ｈ内での出現頻度ｐを計算する。すなわち、図１６のステップＳ４９の処理は、対処方法候補ｃが対処履歴情報ｈ内に含まれていた場合、ｐ´を“１”に設定する処理となる。この結果、図１２（ｂ）に示すように、「サーバＡ調査」のｐは“１”、「サーバＢ調査」のｐは“０”、「サーバＣ調査」のｐは“２”となる。したがって、サーバＡ調査、サーバＢ調査、サーバＣ調査を優先度ｐの高い順から配列すると、サーバＣ、サーバＢ、サーバＡとなる。対処方法推薦部２３０は、この配列情報Ｒを、対処ＩＤ（＝ｉｄ３）と対応付けて、対処履歴管理情報２５０に追加・記録する（図１１のステップＳ５２の処理に該当）。この結果、図１２（ｃ）に示すように、対処履歴情報２５２内の対処ＩＤ２５１が「ｉｄ３」である対処履歴情報２５２において、（なし、「サーバＣ調査、サーバＡ調査、サーバＢ調査」）という対処履歴が追加される。また、対処方法推薦部２３０は、上記Ｒを対処依頼処理部２１０に返す（図１１のステップＳ５３の処理に該当）。

（２）１つの対処を考慮して、優先度ｐを計算する方法
２．１）同一対処ＩＤ２５１の対処履歴情報２５２中に多く含まれる対処候補（対処方法候補）ほど、その優先度ｐを高くする（但し、多くの対処の対処候補に含まれている方を優先する、すなわち、上記（１）の方を優先する）手法
図１３は、この方法を示す図である。

図１３に示す方法では、同一の対処候補が複数の対処方法に含まれている場合には、後で実施した対処方法に含まれている対処候補のｐ´を“０．２”刻みで段階的に減らしていく。

ここでは、図１３（ａ）に示す対処履歴情報２５２−１１内の対処ＩＤ２５１が「ｉｄ１」である対処履歴情報２５２を取り上げて説明する。この対処履歴情報２５２には、「サーバＡ調査」、「サーバＢ調査」、「サーバＣ調査」の順に対処したことが記録されている。

また、各対処について、サーバＡ調査の対処候補は、「サーバＡ調査」、「サーバＢ調査」、「サーバＣ調査」であることが記録されている。また、サーバＢ調査の対処候補は、「サーバＢ調査」、「サーバＣ調査」であることが記録されている。さらに、サーバＣ調査の対処候補は、「サーバＣ調査」であることが記録されている。また、この例では、図１３（ｂ）に示すように、対処方法候補群Ｃは、「サーバＡ調査」、「サーバＢ調査」、「サーバＣ調査」を含んでいる。

したがって、この例では、対処ＩＤ２５１がｉｄ１である対処履歴情報２５２において、サーバＡ調査、サーバＢ調査、サーバＣ調査の各対処方法について、優先度ｐを計算する。上記重み付け方法に基づき、対処ＩＤ２５１がｉｄ１である対処履歴情報２５２中の「サーバＡ調査」、「サーバＢ調査」、「サーバＣ調査」の各対処方法における「サーバＡ調査」、「サーバＢ調査」、「サーバＣ調査」のｐ´は、図１３（ａ）に示す値に設定される。この結果、対処方法候補群Ｃの３つの対処方法候補の優先度ｐの値は、最終的に下記のように計算される。

サーバＡ調査のｐ＝１
サーバＢ調査のｐ＝１．８
サーバＣ調査のｐ＝２．４
したがって、上記３つの対処方法候補の優先度は、優先度の高い順から、サーバＣ調査、サーバＢ調査、サーバＡ調査となる。このようにして、優先度付けされた、サーバＣ調査、サーバＢ調査、サーバＢ調査は図１１の変数Ｒに格納され、その変数Ｒが、対処方法推薦部２３０から対処依頼処理部２１０に返される。

２．２）新しい対処候補に含まれている対処候補ほど、ｐ´を高く設定する手法
図１４は、対処履歴情報２５２中の新しい対処候補に含まれている対処候補ほど、ｐ´を高く設定して、対処方法候補群Ｃ中の各対処方法候補の優先度ｐを計算する方法を示す図である。

図１４（ａ）は、図１４（ｂ）に示す対処方法候補群Ｃの各対処方法候補の優先度ｐを計算するための対象となる対処履歴情報２５２を記録している対処履歴管理情報２５０（２５０−１３）を示す図である。この例では、ｐ´の基準値を“１”とし、最初の該当対処候補には、該基準値に“1/3”の重みを加算する。２回目の対処の該当対処候補には、上記基準値に“2/3”の重みを加算する。３回目の対処の該当対処候補には、上記基準値に“3/3”の重みを加算する。この結果、図１４（ａ）に示すように、最初の対処の該当対処候補である「サーバＡ調査」のｐ´は“１＋1/3”となる。また、２回目の対処の該当対処候補である「サーバＢ調査」のｐ´は“１＋2/３”となる。また、３回目の対処の該当対処候補である該当対処候補である「サーバＣ調査」のｐ´は“１＋3/3”となる。

したがって、図１４（ｃ）に示すように、対処方法候補群ＣのサーバＡ調査の優先度ｐは１．３、サーバＢ調査の優先度ｐは１．７、サーバＣ調査の優先度ｐは２となる。尚、この場合、優先度ｐの計算において、小数点２桁以下は四捨五入するようにしている。

２．３）元が高い優先度の高い対処候補ほどｐ´を高く設定する手法
図１４は、対処履歴管理情報２５０内で、優先度が高い対処候補ほどｐ´を高く設定して、対処方法候補の優先度を計算する手法を説明する図である。

図１５（ａ）に示すように、対処履歴管理情報２５０（２５０−１５）の対処が「ｉｄ１」に対応する対処履歴情報２５２に、（サーバＡ調査、［サーバＡ調査、サーバＢ調査、サーバＣ調査］）という情報が記録されていたとする。そして、図１５（ｂ）に示すように、対処方法候補群Ｃが、「サーバＡ調査」、「サーバＢ調査」、「サーバＣ調査」を含んでいるとする。

この場合、対処履歴管理情報２５０の対処ＩＤが「ｉｄ１」の対処履歴情報２５２中の対処候補について、サーバＡ調査のｐ´を“１”に、サーバＢ調査のｐ´を“０．８（１−０．２）”に、サーバＣ調査のｐ´を“０．６（１−０．４）”に設定する（図１５（ａ）参照）。すなわち、この場合は、優先度が１段階下がるごとに、対処方法候補のｐ´を“0.2”刻みで下げる。

したがって、この例においては、図１５（ｃ）に示すように、対処方法候補群Ｃの各対処方法候補の優先度ｐの計算結果は、サーバＡ調査＝１、サーバＢ調査＝０．８、サーバＣ調査＝０．６となる。

２・４） まとめるほどではないが、当該対処と共通部分が多い対処に含まれている対処候補ほどｐ´を高くする手法
図１６は、対処履歴管理情報２５０中の対処候補について、当該対処と共通部分が多い対処に含まれている対処候補ほどｐ´を高く設定する手法を説明する図である。

図１６（ｂ）に示すように、対処依頼処理部２１０から対処方法推薦部２３０
に渡される引数において、ｉｄ´が「対処ＩＤ：３」、対処方法候補群Ｃが｛サーバＡ調査、サーバＢ調査、サーバＣ調査｝であるとする。

このとき、対処履歴管理情報２５０−１７の記録内容が図１６（ａ）に示すようになっていたとする。図１６（ａ）に示すように、対処履歴管理情報２５０の対処ＩＤ２５１が「ｉｄ３」の対処履歴情報２５２には、対処方法として、「サーバ１調査」と「サーバ２調査」が記録されている。上記２つの対処方法（「サーバ１調査」と「サーバ２調査」について、対処履歴管理情報２５０−１７の対処ＩＤ２５１が「ｉｄ１」と「ｉｄ２」の対処履歴情報２５２を調べてみると、対処ＩＤ２５１が「ｉｄ１」の対処履歴情報２５２には、対処方法として、「サーバ１調査」と「サーバ２調査」の両方が記録されている。また、対処ＩＤ２５１が「ｉｄ２」の対処履歴情報２５２には「サーバ２調査」のみが記録されている。

したがって、この場合、ｐ´の重み付けを、対処ＩＤ２５１が「ｉｄ１」の対処履歴情報２５２中の対処候補の方が「ｉｄ２」の対処履歴情報２５２中の対処候補よりも高くなるように設定する。図１６（ａ）に示す例では、対処ＩＤ２５１が「ｉｄ１」の対処候補の重み付けを“2/5”、対処ＩＤ２５１が「ｉｄ２」の重み付けを“1/5”に設定するようにしている。具体的には、対処ＩＤ２５１が「ｉｄ１」の「サーバＡ調査」と「サーバＢ調査」のｐ´は“１＋2/5”、対処ＩＤ２５１が「ｉｄ２」の「サーバＡ調査」と「サーバＣ調査」のｐ´は“１＋1/5”に設定される。

上記設定をふまえて、対処方法候補群Ｃの各対処方法候補の優先度ｐを計算すると、その結果は、図１６（ｃ）に示すように、サーバＡ調査のｐ＝２．６、サーバＢ調査のｐ＝１．４、サーバＣ調査のｐ＝１．２となる。

尚、上記各手法を組み合わせて、ｐ´を設定するようにすることも可能である。
｛症状統合部２４０の処理｝
図１７は、症状統合部２４０の処理を示すフローチャートである。この処理は、図８のステップＳ１９の処理に該当する。

症状統合部２４０は、対処依頼処理部２１０から引数ｉｄ（対処ＩＤ）を受け取り、図１７のフローチャートに示す処理を開始する。
症状統合部２４０は、まず、ｉｄが“空”であるか判断し（ステップＳ６１）、ｉｄが空でなければ（ステップＳ６１、Ｎｏ）ステップＳ６２に進み、ｉｄが空であれば（ステップＳ６１、Ｙｅｓ）ステップＳ６８に進む。ステップＳ６１の判断は、上述した図８のフローチャートのステップＳ１１と同様の処理である。

症状統合部２４０は、ステップＳ６２おいて、対処履歴管理情報２５０から対処ＩＤ２５１が「ｉｄ」の情報ｈを取り出す。この情報ｈは、対処ＩＤ２５１（＝ｉｄ）と、それに対応する対処履歴情報２５２の組から成る情報である。次に、対処履歴管理情報２５から該ｈ以外の情報Ｈを取得し（ステップＳ６３）、該Ｈが“空”であるか判断する（ステップＳ６４）。そして、Ｈが空でなければ（ステップＳ６４、Ｎｏ）ステップＳ６５に進み、Ｈが空であれば（ステップＳ６４、Ｙｅｓ）ステップＳ６８に進む。

症状統合部２４０は、ステップＳ６５において、Ｈから先頭のｈ´を取り出す。このｈ´は、前記ｈと同様に、対処ＩＤ２５１と、それに対応する対処履歴情報２５２との組から成る情報である。続いて、ｈの対処履歴情報２５２とｈ´の対処履歴情報２５２を比較し、それらに共通部分が多いか判断する（ステップＳ６６）。そして、該共通部分が多いと判断すれば（ステップＳ６６、Ｙｅｓ）ステップＳ６７に進み、該共通部分が少ないと判断すれば（ステップＳ６６、Ｎｏ）ステップＳ６４に戻る。ステップＳ６６の処理の詳細は、後述する。

このようにして、症状統合部２４０は、ステップＳ６４において、Ｈが空、すなわち、Ｈから取り出すｈ´が無いと判断するか（ステップＳ６４、Ｙｅｓ）、または、ステップＳ６６において、ｈの対処履歴情報２５２とｈ´の対処履歴情報２５２に共通部分が多いと判断するまで（ステップＳ６６、Ｙｅｓ）、ステップＳ６４〜Ｓ６６の処理を繰り返す。

症状統合部２４０は、ステップＳ６７において、ｈをｈ´に統合し、「統合すべき症状あり」のステイタスとｈ´を対処依頼処理部２１０に返す。そして、本フローチャートの処理を終了する。

症状統合部２４０は、ステップＳ６８において、「統合すべき症状なし」のステイタス
を対処依頼処理部２１０に返す。そして、本フローチャートの処理を終了する。
図１８は、上述した図１７のフローチャートの処理の具体例を示す図である。

図１８（ａ）は症状統合部２４０が統合する前の対処履歴管理情報２５０（２５０−１９）を示す図、図１８（ｂ）は症状統合部２４０が対処依頼処理部２１０から受け取る引数ｉｄを示す図、図１８（ｃ）は症状統合部２４０が統合した後の対処履歴管理情報２５０（２５０−２１）を示す図である。

この例では、図１８（ｂ）に示すように、症状統合部２４０は、対処依頼処理部２１０から、引数ｉｄとして「ｉｄ３」の対処ＩＤを受け取る。したがって、図１８（ａ）に示す対処履歴管理情報２５０（２５０−１９）の対処ＩＤ２５１が「ｉｄ３」である情報ｈが統合の対象となる。この例では、対処履歴管理情報２５０−１９において、ｈ以外の情報Ｈは、対処ＩＤ２５１が「ｉｄ１」の情報と「ｉｄ２」の情報から構成される。したがって、情報Ｈから、「ｉｄ１」の情報ｈ´と「ｉｄ２」の情報ｈ´を順次取り出し、それぞれの対処履歴情報２５２の内容を情報ｈの対処履歴情報２５２の内容と比較し、情報ｈの対処履歴情報２５２と共通部分が多い対処履歴情報２５２を有する情報ｈ´を見つけ出し、その情報ｈ´が見つかったならば、情報ｈをその情報ｈ´に統合させる処理を行う。

この例では、図１８（ａ）に示すように、情報ｈの対処履歴情報２５２と共通部分が多い対処履歴情報２５２を有するのは、対処ＩＤ２５１が「ｉｄ２」の情報ｈ´の対処履歴情報２５２である。具体的には、それぞれの対処履歴情報２５２中の対処方法において、「サーバDの調査」、「サーバDのプロセス調査」、「サーバDのI／O調査」、「なし」が共通している。したがって、この例では、図１８（ｃ）に示すように、対処ＩＤ２５１が「ｉｄ３」の情報ｈを、対処ＩＤ２５１が「ｉｄ２」の情報ｈ´に統合する。

｛情報ｈと情報ｈ´の対処履歴情報２５２の共通部分が多いと判定する方法｝
図１９は、図１７のフローチャートのステップＳ６６の判断方法の例を示す図である。図１９おいて、「履歴１」、「履歴２」は、それぞれ、情報ｈの対処履歴情報２５２、情報ｈ´の対処履歴情報２５２を示す。また、「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」、「Ｅ」は、対処履歴情報２５２内の対処方法を示す。また、Ａ→Ｂ→Ｃ→Ｄ→Ｅは、Ａ、Ｂ、Ｃ、Ｄ、Ｅの順序で対処方法が実施されたことを示している。

図１９（ａ）は、対処履歴情報２５２全体に占める共通部分の割合が一定値以上である場合、共通部分が多いと判断する例を示している。この例では、一定値を５０％と定めている。この例の場合、履歴１と履歴２で、対処方法Ｃ、Ｄ、Ｅが共通するので、共通部分の割合が６０％となり、一定値（＝５０％）を超える。したがって、履歴１と履歴２の共通部分が多いと判断される。

図１９（ｂ）は、一方の対処履歴情報２５２の対処履歴（対処方法の履歴）が他方の対処履歴情報２５２の対処履歴に対して前方一致する場合、共通部分が多いと判断する例を示す。この例では、履歴１の対処履歴（「Ａ→Ｂ→Ｃ→Ｄ→Ｅ」）に対し、履歴２の対処履歴（「Ａ→Ｂ→Ｃ」）が前方一致している。したがって、この場合、前方一致率は６０％となる。この例では、前方一致の基準値（一定値）を５０％としているので、履歴１と履歴２の対処履歴は共通部分が多いと判断される。

図１９（ｃ）は、一方の対処履歴情報２５２の対処履歴（対処方法の履歴）が他方の対処履歴情報２５２に包含される場合、共通部分が多いと判断する例を示す。この例では、履歴１の対処履歴は「Ａ→Ｂ→Ｃ→Ｄ→Ｅ」となっている。また、履歴２の対処履歴は「Ｂ→Ｃ→Ｄ」となっている。この場合、履歴２の対処履歴は、履歴１に包含されており、履歴１の対処履歴全体における履歴２の対処履歴の割合は６０％を占めている。この例では、包含割合の基準値（一定値）を５０％に設定しているので、共通部分が多いと判断される。

図１９（ｄ）は、一方の対処履歴情報２５２の対処履歴が他方の対処履歴情報２５２の対処履歴に対して後方一致する場合に、共通部分が多いと判断する例を示す。この例では、履歴１の対処履歴は「Ａ→Ｂ→Ｃ→Ｄ→Ｅ」となっている。また、履歴２の対処履歴は「Ｃ→Ｄ→Ｅ」となっている。この場合、履歴２の対処履歴は、履歴１に後方一致しており、履歴１の対処履歴全体における履歴２の後方一致部分の割合は６０％である。この例では、後方一致部分の対処履歴全体の割合の基準値（一定値）を５０％に設定しているので、共通部分が多いと判断される。

尚、上述した図１９（ａ）〜（ｄ）の例は、いずれも、「連続する対処方法」を共通部分の対象としているが、本発明は、これに限定されるものではない。例えば、「Ａ→Ｅ→Ｂ→Ｃ」のように、対処方法ＡとＢの間に対処方法Ｅを実施するような場合でも、これを、「Ａ→Ｂ→Ｃ」に順ずる共通部分とみなすようにしてもよい。

本発明は、上述した実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内で種々に変形して実施することができる。例えば、優先度ｐの計算方法は上述した実施形態に限定されるものではない。また、共通部分が多いと判断する方式も上述した実施形態の手法に限定されるものではない。

上述した実施形態に関し、更に、以下の付記を開示する。
（付記１）
情報システムにおいて過去に発生した障害の対処事例を知識化し、該知識化によって得られた障害対処知識と、障害発生時の障害の症状を基に、対処方法を推薦する処理を、コンピュータに実行させる障害対処プログラムであって、
前記障害対処知識を検索して、対処を依頼された障害に対する対処方法の候補を取得する検索ステップと、
各症状に対して実施した対処方法の履歴を、対処履歴情報として、記憶手段に記録する記録ステップと、
該対処履歴情報を参照して、前記検索ステップで得られた対処方法の候補（対処方法候補）を優先度付けする優先度付けステップと、
該優先度付けステップによって得られた優先度付け情報を基に、前記対処依頼された障害に対する対処方法を、優先度を付けて、対処依頼先に返すステップと、
を備える処理を、
コンピュータに実行させる障害対処プログラム。
（付記２）
前記優先度付けステップにおいて、対処中の他の症状の対処履歴情報を参照して、対処中の他の症状にも有効な対処方法候補の優先度が高くなるように設定する処理を、
前記コンピュータに実行させることを特徴とする付記１記載の障害対処プログラム。
（付記３）
前記優先度付けステップにおいて、当該対処履歴情報内に多く含まれている対処方法候補ほど、優先度が高くなるように設定する処理を、
前記コンピュータに実行させることを特徴とする付記１記載の障害対処プログラム。
（付記４）
前記優先度付けステップにおいて、当該対処履歴情報を参照し、新しく実施された対処方法候補ほど、優先度が高くなるように設定する処理を、
前記コンピュータに実行させることを特徴とする付記１記載の障害対処プログラム。
（付記５）
前記優先度付けステップにおいて、当該対処履歴情報を参照して、元の優先度が高い対処方法候補ほど、優先度が高くなるように設定する処理を、
前記コンピュータに実行させることを特徴とする付記１記載の障害対処プログラム。
（付記６）
前記優先度付けステップにおいて、前記対処履歴管理情報を参照し、前記検索ステップで得られた対処方法候補の群（対処方法候補群）に含まれる対処候補と共通する対処候補を含む対処の対処候補に含まれている対処方法候補ほど重みを大きくして、各対処方法候補の優先度を計算する処理を、
前記コンピュータに実行させることを特徴とする付記１記載の障害対処プログラム。
（付記７）
さらに、
前記対処履歴管理情報に記録されている対処履歴情報について、共通部分が多い対処履歴情報を一つに統合する統合ステップの処理を、
前記コンピュータに実行させる請求項１記載の障害対処プログラム。
（付記８）
前記統合ステップにおいて、前記対処履歴管理情報内の各対処履歴情報を参照し、対処方法の履歴（対処履歴）全体に占める共通部分の割合が一定値以上であれば、共通部分が多いと判断する処理を、
前記コンピュータに実行させることを特徴とする付記７記載の障害対処プログラム。
（付記９）
前記統合ステップにおいて、一方の対処履歴が他方の対処履歴に対して前方一致していれば、それらの対処履歴は共通部分が多いと判断する処理を、
前記コンピュータに実行させることを特徴とする付記７記載の障害対処プログラム。
（付記１０）
前記統合ステップにおいて、一方の対処履歴が他方の対処履歴に包含されていれば、それらの対処履歴は共通部分が多いと判断する処理を、
前記コンピュータに実行させること特徴とする付記７記載の障害対処プログラム。
（付記１１）
前記統合ステップにおいて、一方に対処履歴が他方の対処履歴に後方一致していれば、それらの対処履歴は共通部分が多いと判断する処理を、
前記コンピュータに実行させることを特徴とする付記７記載の障害対処プログラム。
（付記１２）
前記共通部分は、一方が他方の対処方法を全て包含している場合も含むことを特徴とする付記８乃至付記１１のいずれか１項に記載の障害対処プログラム。
（付記１３）
情報システムにおいて過去に発生した障害の対処事例を知識化し、該知識化によって得られた障害対処知識と、障害発生時の障害の症状を基に、対処方法を推薦する障害対処装置であって、
前記障害対処知識を検索して、対処を依頼された障害に対する対処方法の候補を取得する検索手段と、
各症状に対して実施した対処方法の履歴を、対処履歴情報として、記憶手段に記録する記録手段と、
該記憶手段に格納されている対処履歴情報を参照して、前記検索手段により取得された対処方法の候補（対処方法候補）を優先度付けする優先度手段と、
該優先度付けステップによって得られた優先度付け情報を基に、前記対処依頼された障害に対する対処方法を、優先度を付けて、対処依頼先に返す推薦手段と、
を備える障害対処装置。
（付記１４）
前記優先度手段は、対処中の他の症状の対処履歴情報を参照して、対処中の他の症状にも有効な対処方法候補の優先度が高くなるように設定することを特徴とする付記１３記載
の障害対処装置。
（付記１５）
前記優先度手段は、当該対処履歴情報内に多く含まれている対処方法候補ほど、優先度が高くなるように設定することを特徴とする付記１３記載の障害対処装置。
（付記１６）
前記優先度手段は、当該対処履歴情報を参照し、新しく実施された対処方法候補ほど、優先度が高くなるように設定することを特徴とする付記１３記載の障害対処装置。
（付記１７）
前記優先度手段は、当該対処履歴情報を参照して、元の優先度が高い対処方法候補ほど、優先度が高くなるように設定することを特徴とする付記１３記載の障害対処装置。
（付記１８）
前記優先度手段は、前記対処履歴管理情報を参照し、前記検索ステップで得られた対処方法候補の群（対処方法候補群）に含まれる対処候補と共通する対処候補を含む対処の対処候補に含まれている対処方法候補ほど重みを大きくして、各対処方法候補の優先度を計算することを特徴とする付記１３記載の障害対処装置。
（付記１９）
さらに、
前記対処履歴管理情報に記録されている対処履歴情報について、共通部分が多い対処履歴情報を一つに統合する統合手段を、
備える請求項１３記載の障害対処装置。
（付記２０）
前記統合手段は、前記対処履歴管理情報内の各対処履歴情報を参照し、対処方法の履歴（対処履歴）全体に占める共通部分の割合が一定値以上であれば、共通部分が多いと判断することを特徴とする付記１９記載の障害対処装置。
（付記２１）
前記統合手段は、一方の対処履歴が他方の対処履歴に対して前方一致していれば、それらの対処履歴は共通部分が多いと判断することを特徴とする付記１９記載の障害対処装置。
（付記２２）
前記統合手段は、一方の対処履歴が他方の対処履歴に包含されていれば、それらの対処履歴は共通部分が多いと判断すること特徴とする付記１９記載の障害対処装置。
（付記２３）
前記統合手段は、一方に対処履歴が他方の対処履歴に後方一致していれば、それらの対処履歴は共通部分が多いと判断することを特徴とする付記１９記載の障害対処装置。
（付記２４）
前記共通部分は、一方が他方の対処方法を全て包含している場合も含むことを特徴とする付記１９乃至付記２３のいずれか１項に記載の障害対処装置。
（付記２５）
情報システムにおいて過去に発生した障害の対処事例を知識化し、該知識化によって得られた障害対処知識と、障害発生時の障害の症状を基に、対処方法を推薦する障害対処装置であって、
各対処ＩＤと、各対処ＩＤに対応する対処履歴情報の組を含む対処履歴管理情報を記憶する対処履歴管理情報記憶部と、
ユーザの端末から、対処ＩＤと障害の症状を含む対処依頼を受信し、該対処依頼に対して、対処ＩＤと対処方法を返す対処依頼処理部と、
前記障害対処知識を検索して、前記対処依頼に含まれる障害の症状に対応する対処方法の候補（対処方法候補）を取得する対処方法検索部と、
前記対処履歴管理情報記憶部に記録されている対処履歴管理情報記憶部を参照して、該対処方法検索部により取得された対処方法候補に対して優先度を付け、前記対処ＩＤと該優先度付けされた対処方法（対処方法候補）の組を対処履歴情報として、前記対処履歴管
理情報記憶部内の対処履歴管理情報に追加すると共に、前記優先度付けされた対処方法を前記対処依頼処理部に渡す対処方法推薦部と、
前記対処履歴管理情報記憶部に記録されている対処履歴管理情報内の該対処依頼に含まれる対処ＩＤに対応する対処履歴情報の当該対処履歴内の対処方法を、前記対処依頼処理部が受信した対処依頼に含まれるユーザが実施した対処方法に更新する対処方法更新部と、
を備える障害対処装置。

原理（１）の解決イメージを示す図である。 原理（２）の解決イメージを示す図であり、（ａ）は症状１の対処方法候補を、（ｂ）は症状２の対処方法候補を示している。 本実施形態のシステムの概要を示す図（その１）である。 本実施形態のシステムに概要を示す図（その２）である。 トラブル対処システムの構成を示すブロック図である。 図５に示す本実施形態のトラブル対処システムをプログラムの実行により実現するコンピュータのハードウェア構成を示す図である。 トラブル対処システムの全体フローである。 図５の対処依頼処理部の処理を示すフローチャートである。 図５の対処方法更新部の処理を示すフローチャートである。 （ａ）は対処方法更新部により更新される前の対処履歴管理情報、（ｂ）は対処依頼処理部から受け取る引数、（ｃ）は対処方法更新部により更新された後の対処履歴管理情報を示す図である。 図５の対処方法推薦部の処理（図５のステップＳ１７に該当）を示すフローチャートである。 対処中の他の症状にも有効な対処方法を優先して推薦する方法を説明する図である。 １つの対処を考慮して、優先度を計算する方法（その１）を説明する図である。 １つの対処を考慮して、優先度を計算する方法（その２）を説明する図である。 １つの対処を考慮して、優先度を計算する方法（その３）を説明する図である。 １つの対処を考慮して、優先度を計算する方法（その４）を説明する図である。 症状統合部の処理を示すフローチャートである。 図１７のフローチャートの処理の具体例を示す図である。 図１７のフローチャートのステップＳ６６の判断方法の例を示す図である。 従来の障害対処方法を示す模式図である。

符号の説明

１０ 症状１の対処履歴
１１、１２、１３ 対処方法
２０ 症状２の対処履歴
２１、２２、２３ 対処方法
３０ 対処方法候補群
３１、３２ 対処方法候補（対処方法）
４０ 対処方法候補群
４１、４２ 対処方法候補（対処方法）
１１０（１１０−１、１１０−２） 症状
１１１−１ 初期症状
１１２ 対処
１２０（１２０−１、１２０−２） 対処ＩＤ
２００ トラブル対処システム
２１０ 対処依頼処理部
２２０ 対処方法更新部
２３０ 対処方法推薦部
２４０ 症状統合部
２５０（２５０−１、２５０−２、２５０−５、２５０−６、２５０−１１、２５０−１３、２５０−１５、２５０−１７，２５０−１９、２５０−２１） 対処履歴管理情報
２５１ 対処ＩＤ
２５２ 対処履歴情報
２６０ 対処方法検索部
２７０ トラブル対処知識
３１０（３１０−１〜３１０−５） 対処方法
５００ コンピュータ
５０１ ＣＰＵ
５０２ メモリ（主記憶装置）
５０３ 入力装置
５０４ 表示装置
５０５ 外部記憶装置
５０６ 可搬型記憶媒体駆動装置
５１０ バス
ｉ 症状
ｉｄ、ｉｄ´ 対処ＩＤ
Ｃ 対処方法候補群
ｃ 対処方法候補
ｐ 優先度
ｐ´ 優先度ｐの計算式で使用される変数

Claims (7)

1. コンピュータに、
   受け付けた障害による症状の情報に基づき過去に発生した障害による症状の対処事例を蓄積した障害対処知識を検索して対処候補を取得し、
   過去に実施した、または、実施中の対処を症状に関連付けて蓄積した対処履歴情報を参照して前記対処候補の評価を行い、
   前記対処候補を前記評価と関連づけて出力する、
   処理を実行させ、
   前記対処候補の評価は、前記受け付けた障害に対する対処中の他の症状にも関連付けられた対処候補の評価を高くする、
   ことを特徴とする障害対応プログラム。
2. 請求項１記載の障害対応プログラムであって、前記対処候補の評価は、前記対処候補に優先度を付けることにより行われる、ことを特徴とする障害対応プログラム。
3. 請求項２記載の障害対応プログラムであって、前記対処履歴情報内に多く含まれている対処候補ほど、優先度を高くする、ことを特徴とする障害対応プログラム。
4. 請求項１記載の障害対応プログラムであって、コンピュータに、さらに、
   蓄積した前記対処履歴情報のうち、共通部分が多い対処履歴情報を一つに統合する
   処理を実行させることを特徴とする障害対応プログラム。
5. 受け付けた障害による症状の情報に基づき過去に発生した障害による症状の対処事例を蓄積した障害対処知識を検索して対処候補を取得する検索手段と、
   過去に実施した、または、実施中の対処を症状に関連付けて蓄積した対処履歴情報を記録する記録手段と、
   前記記憶手段に格納されている対処履歴情報を参照して前記対処候補を評価する評価手段と、
   前記対処候補を前記評価と関連付けて出力する出力手段と、
   を備え、
   前記評価手段は、前記受け付けた障害に対する対処中の他の症状にも関連付けられた対処候補の評価を高くする
   ことを特徴とする障害対応装置。
6. 請求項５に記載の障害対応装置は、さらに、
   前記記憶手段に記録されている対処履歴情報のうち、共通部分が多い対処履歴情報を一つに統合する統合手段、
   を備えることを特徴とする障害対応装置。
7. ユーザの端末から、対処中のトラブルに付与される識別子である対処識別子と障害の症状とを含む対処依頼を受信し、該対処依頼に対して、対処識別子と対処方法を返す依頼処理部と、
   受け付けた障害による症状の情報に基づき前記過去に発生した障害による症状の対処事例を蓄積した障害対処知識を検索して対処候補を取得する検索部と、
   過去に実施した、または、実施中の対処を症状に関連付けて蓄積した対処履歴情報を記憶する記憶部と、
   前記記憶部に記憶された前記対処履歴情報を参照して前記対処候補の評価を行い、前記対処識別子と該対処候補と該評価とを関連付けて対処履歴情報として、前記記憶部に追加すると共に、前記評価された対処候補を前記依頼処理部に渡す評価部と、
   前記記憶部に記録されている対処識別子に対応する対処履歴情報における対処候補を、前記依頼処理部が受信した対処依頼に含まれるユーザが実施した対処方法に更新する更新部と、
   を備え、
   前記評価部は、前記受け付けた障害に対する対処中の他の症状にも関連付けられた対処候補の評価を高くする、
   ことを特徴とする障害対応システム。