JP2017004452A - 情報処理装置及び情報処理プログラム - Google Patents

Abstract

【課題】Ｗｅｂページに関するエラーの発生があったならば、そのエラーに対処する担当者への通知を行う場合にあって、Ｗｅｂページに関するエラー後の利用者の操作によるそのＷｅｂページへのアクセスを監視し、利用者におけるエラーの深刻度に応じた通知を担当者に行うようにした情報処理装置を提供する。【解決手段】情報処理装置１００において、エラー検知モジュール１３０はＷｅｂページに関するエラーを検知し、ユーザーアクセス監視モジュール１４０はエラー後の利用者の操作によるＷｅｂページへのアクセスを監視し、エラー深刻度計算モジュール１５０は監視結果に応じて、ユーザーにおけるエラーの深刻度を算出する。エラー通知判定モジュール１６０は、監視結果及び深刻度に応じて、エラー通知モジュール１７０に通知を依頼する。エラー通知モジュール１７０は、渡されたエラー情報を、エラーに対処する運用担当者に通知する。【選択図】図１

Description

本発明は、情報処理装置及び情報処理プログラムに関する。

特許文献１には、過剰な障害情報の通知を受けずに済み、運用者の負担が軽減できる集約機能付障害情報通知システム及びマシンを集約機能付障害情報通知手段として機能させるためのプログラムを提供することを課題とし、障害情報通知装置は、サービス提供装置に設置されており、この装置は、サービス提供装置で発生した障害内容を、それぞれの運用マシン上に設置されている障害情報集約装置に通知する機能を持っており、障害情報集約装置は、受信した障害情報を取捨選択し、過剰な障害情報を通知しないように抑制して障害情報を出力し、障害情報集約装置の障害情報通知先は、運用者受信装置、又は障害情報集約装置が出力した障害情報をさらに集約する階層的な位置付けにある障害情報集約装置であることが開示されている。

特許文献２には、発生した異常状態の復旧難易度を算出し、復旧難易度に応じた宛て先に通知メールを送信するようにして、適切な宛て先にエラーを通知することができるようにすることを課題とし、異常状態を検出する状態検出部と、状態検出部によって検出された異常状態に応じた内容の通知メールを生成するメール生成部と、状態検出部によって検出された異常状態に応じた宛て先を抽出する宛て先抽出部と、宛て先抽出部によって抽出された宛て先との間の電子メールの通信及び再送を制御する通信制御部とを備え、状態検出部は、検出した異常状態の復旧難易度を算出し、宛て先抽出部は、算出された復旧難易度に基づいて通知メールを送信する宛て先を抽出し、メール生成部は、宛て先抽出部よって抽出された宛て先に対する通知メールを生成し、通信制御部は、メール生成部によって生成された通知メールを宛て先抽出部よって抽出された宛て先に送信することが開示されている。

特許文献３には、多種多様かつ難易度の異なる保守作業への対応を好適に支援することを課題とし、情報処理システムは、管理対象のシステムに含まれる置換可能な部位のうちの障害要因部位を特定するための情報と、該障害要因部位の障害の履歴情報とを格納した情報源にアクセスして、管理対象のシステムに含まれる置換可能な部位から発せられるエラーコードから、被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを生成する障害要因解析部と、前記障害要因部位と前記障害の履歴情報とに基づいて、保守作業の難易度を示す保守レベルを算出する保守レベル算出部と、を備え、前記保守レベルを含んだ保守作業の指示情報を出力することが開示されている。

特許文献４には、サイレント障害を監視する監視サーバーを備えた監視システムにおいて、複数種類の状態を並行して観測分析することで、精度よく障害を検知可能とする障害検知装置を得ることを課題とし、監視対象ホストのサイレント障害の発生を監視する障害検知装置において、前記監視対象ホストにおけるシステムログと、前記監視対象ホストにおける過去に存在したシステムログのログ遷移である正常状態モデルとを比較して異常を判定する異常判定部と、前記異常判定部で異常が判定された場合に、ＳＮＳ情報、キャリアにおけるコールセンター情報、ユーザー行動情報、サービスへのアクセス数のうちの少なくとも１つの観測データによるネガティブな事象を考慮するとともに、直前のシステムログの単語出現分布と、過去のシステムログの新規遷移出現時に紐付いた一定時間内の単語出現分布である結果予想モデルとを比較することでサイレント障害を推定する障害推定部とを備えることが開示されている。

特開２００３−３３０７５８号公報 特開２００７−０３０４４４号公報 特開２０１３−２０６１０５号公報 特開２０１５−０２８７００号公報

従来技術においては、Ｗｅｂページに関するエラーの発生があったならば、そのエラーに対処する担当者への通知を行う場合にあって、エラー自体の重要度によって、担当者に通知するか否かが判断されている。しかし、利用者におけるエラーの深刻度が異なることは考慮されておらず、不要なエラーの通知が行われてしまう場合、又は、利用者にとって深刻なエラーが担当者に通知されない場合がある。
本発明は、Ｗｅｂページに関するエラー後の利用者の操作によるそのＷｅｂページへのアクセスを監視し、利用者におけるエラーの深刻度に応じた通知を担当者に行うようにした情報処理装置及び情報処理プログラムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、Ｗｅｂページに関するエラーを検知する検知手段と、前記エラー後の利用者の操作による前記Ｗｅｂページへのアクセスを監視する監視手段と、前記監視手段による監視結果に応じて、前記エラーに対処する担当者への通知を行う通知手段を具備する情報処理装置である。

請求項２の発明は、前記監視手段による監視結果に応じて、前記利用者における前記エラーの深刻度を算出する算出手段をさらに具備し、前記通知手段は、前記算出手段によって算出された深刻度が予め定められた閾値より多い又は以上である場合は、前記エラーに対処する担当者への通知を行う請求項１に記載の情報処理装置である。

請求項３の発明は、前記算出手段は、前記Ｗｅｂページへのアクセスに関するエラーの回数に基づいて深刻度を算出する請求項２に記載の情報処理装置である。

請求項４の発明は、前記監視手段は、前記Ｗｅｂページへのアクセスが成功した場合は、監視を中止する請求項１又は２に記載の情報処理装置である。

請求項５の発明は、前記算出手段は、さらに予め定められたＷｅｂページへのアクセスがあったことに基づいて深刻度を算出する請求項２から４のいずれか一項に記載の情報処理装置である。

請求項６の発明は、前記算出手段は、さらに前記利用者のＷｅｂページへのアクセス履歴に基づいて、前記エラーが発生したＷｅｂページの重要度を算出し、該重要度に基づいて深刻度を算出する請求項２から５のいずれか一項に記載の情報処理装置である。

請求項７の発明は、前記算出手段は、予め定められた日にち、時間帯におけるアクセス履歴に基づいて、前記エラーが発生したＷｅｂページの重要度を算出する請求項６に記載の情報処理装置である。

請求項８の発明は、前記算出手段は、前記利用者と類似する他の利用者における重要度を用いる請求項６又は７に記載の情報処理装置である。

請求項９の発明は、前記通知手段は、前記担当者毎に予め定められた通知回数、現在までの通知回数、現在の時刻に応じて、通知を行うか否かを判断するための閾値を決定する請求項１から８のいずれか一項に記載の情報処理装置である。

請求項１０の発明は、コンピュータを、Ｗｅｂページに関するエラーを検知する検知手段と、前記エラー後の利用者の操作による前記Ｗｅｂページへのアクセスを監視する監視手段と、前記監視手段による監視結果に応じて、前記エラーに対処する担当者への通知を行う通知手段として機能させるための情報処理プログラムである。

請求項１の情報処理装置によれば、Ｗｅｂページに関するエラーの発生があったならば、そのエラーに対処する担当者への通知を行う場合にあって、Ｗｅｂページに関するエラー後の利用者の操作によるそのＷｅｂページへのアクセスを監視し、利用者におけるエラーの深刻度に応じた通知を担当者に行うことができる。

請求項２の情報処理装置によれば、監視結果に応じて、利用者におけるエラーの深刻度を算出することができる。

請求項３の情報処理装置によれば、Ｗｅｂページへのアクセスに関するエラーの回数に基づいて深刻度を算出することができる。

請求項４の情報処理装置によれば、Ｗｅｂページへのアクセスが成功した場合は、監視を中止することができる。

請求項５の情報処理装置によれば、予め定められたＷｅｂページへのアクセスがあったことに基づいて深刻度を算出することができる。

請求項６の情報処理装置によれば、利用者のＷｅｂページへのアクセス履歴に基づいて、エラーが発生したＷｅｂページの重要度を算出し、その重要度に基づいて深刻度を算出することができる。

請求項７の情報処理装置によれば、予め定められた日にち、時間帯におけるアクセス履歴に基づいて、エラーが発生したＷｅｂページの重要度を算出することができる。

請求項８の情報処理装置によれば、利用者と類似する他の利用者における重要度を用いることができる。

請求項９の情報処理装置によれば、担当者毎に予め定められた通知回数、現在までの通知回数、現在の時刻に応じて、通知を行うか否かを判断するための閾値を決定することができる。

請求項１０の情報処理プログラムによれば、Ｗｅｂページに関するエラーの発生があったならば、そのエラーに対処する担当者への通知を行う場合にあって、Ｗｅｂページに関するエラー後の利用者の操作によるそのＷｅｂページへのアクセスを監視し、利用者におけるエラーの深刻度に応じた通知を担当者に行うことができる。

第１の実施の形態の構成例についての概念的なモジュール構成図である。 本実施の形態を利用したシステム構成例を示す説明図である。 アクセス履歴テーブルのデータ構造例を示す説明図である。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示すフローチャートである。 アクセス履歴テーブルのデータ構造例を示す説明図である。 アクセス履歴テーブルのデータ構造例を示す説明図である。 アクセス履歴テーブルのデータ構造例を示す説明図である。 アクセス履歴テーブルのデータ構造例を示す説明図である。 第２の実施の形態の構成例についての概念的なモジュール構成図である。 ページ別エラー影響度テーブルのデータ構造例を示す説明図である。 第２の実施の形態による処理例を示すフローチャートである。 ページ別エラー影響度テーブルのデータ構造例を示す説明図である。 アクセス履歴テーブルのデータ構造例を示す説明図である。 アクセス履歴テーブルのデータ構造例を示す説明図である。 第３の実施の形態の構成例についての概念的なモジュール構成図である。 ユーザー別ページ重要度テーブルのデータ構造例を示す説明図である。 ユーザー別ページ重要度テーブルのデータ構造例を示す説明図である。 ユーザー情報テーブルのデータ構造例を示す説明図である。 第３の実施の形態による処理例を示すフローチャートである。 ユーザー別ページ利用確率テーブルのデータ構造例を示す説明図である。 ユーザー別ページ利用確率重要度テーブルのデータ構造例を示す説明図である。 アクセス履歴テーブルのデータ構造例を示す説明図である。 ユーザー別ページ利用確率テーブルのデータ構造例を示す説明図である。 ユーザー別ページ日にち利用確率テーブルのデータ構造例を示す説明図である。 ユーザー別ページ日にち利用確率重要度テーブルのデータ構造例を示す説明図である。 ユーザー情報テーブルのデータ構造例を示す説明図である。 第４の実施の形態の構成例についての概念的なモジュール構成図である。 エラー通知履歴テーブルのデータ構造例を示す説明図である。 第４の実施の形態による処理例を示すフローチャートである。 第５の実施の形態の構成例についての概念的なモジュール構成図である。 本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。

まず、実施の形態を説明する前に、その前提又は本実施の形態を利用する情報処理装置について説明する。なお、この説明は、本実施の形態の理解を容易にすることを目的とするものである。
Ｗｅｂ上に公開しているサービスでは、いつサービスの状態が不安定、又は利用不可能になるか分からない。そこで、対象のシステムが正常に動作しているか監視を行い、異常な状態になっている場合、運用担当者にエラー通知を行う監視システムを使用することが一般的に行われている。
監視システムによる監視は、システムが異常な状態とはどういった状態なのかを予め定義しておき、この状態になっていないかを定期的にチェックすることで実現する。この定義として、例えば、ＣＰＵ使用率が９０％を超えている、１分以内にエラーが１００個以上発生している等がある。
しかし、この異常状態の定義が実際のシステムの異常状態のマッチしていない場合、大量の通知が送信され運用者が対応できない、本当に重要なエラーが通知されないなどの問題がある。
前述した特許文献に記載されている技術では、発生したエラー自体の重要度については、精度よく計算できるようになっている。
しかし、同じエラーでも利用者のサービスの利用方法によっては、エラーの重要度が異なることが考慮されていない。例えば、ある機能はユーザーＡにとっては非常に重要な機能でありエラーが発生した場合、早期の復旧が必要なのに対して、ユーザーＢにとってはそこまで重要度が高い機能ではなく、後日の利用でも構わない場合が挙げられる。このような場合に、エラー自体の重要度のみで通知の判定を実施してしまうと、不要なエラー通知の発生や、重要なエラーの通知の見落としが発生する可能性がある。これらは、エラー発生時のエラーの重要度を、対象ユーザーに対してどれだけ問題があるかを考慮せずに決定していることに起因する。

以下、図面に基づき本発明を実現するにあたっての好適な各種の実施の形態の例を説明する。
図１は、第１の実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するという意味である。また、モジュールは機能に一対一に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態に応じて、又はそれまでの状況・状態に応じて定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、全ての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という意味を有する記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。

第１の実施の形態である情報処理装置１００は、Ｗｅｂページに関するエラーの発生があった場合に、そのエラーに対処する担当者への通知を行うものであって、図１の例に示すように、アクセス履歴記録モジュール１１０、アクセス履歴記憶モジュール１２０、エラー検知モジュール１３０、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、エラー通知判定モジュール１６０、エラー通知モジュール１７０を有している。情報処理装置１００は、Ｗｅｂ上でコンテンツやサービスを提供するシステムに利用される。例えば、Ｗｅｂページに関するエラーが発生した場合に、そのエラー発生後の対象利用者（以下、ユーザーともいう）の行動から、エラーが発生した機能が、そのユーザーにとってどれだけ重要であるかを算出し、その重要度に応じて、エラーに対処する担当者への通知の要否、緊急度を決定する。

アクセス履歴記録モジュール１１０は、アクセス履歴記憶モジュール１２０と接続されている。アクセス履歴記録モジュール１１０は、アクセス履歴記憶モジュール１２０に対して記録１１２の処理を行う。アクセス履歴記録モジュール１１０は、Ｗｅｂページに対するユーザーのアクセス履歴（アクセスした際の情報）をアクセス履歴記憶モジュール１２０に記録１１２する。例えば、アクセス履歴として、本実施の形態においてユーザーを一意に識別するための情報（ユーザーＩＤ：ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）、そのユーザーが利用したアクセス機能、その日時（年、月、日、時、分、秒、秒以下、又はこれらの組み合わせであってもよい）、そのアクセスの結果等がある。

アクセス履歴記憶モジュール１２０は、アクセス履歴記録モジュール１１０、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０と接続されている。アクセス履歴記憶モジュール１２０は、アクセス履歴記録モジュール１１０によって取得されたアクセス履歴を記憶する。また、そのアクセス履歴に対して、ユーザーアクセス監視モジュール１４０から監視１４５され、エラー深刻度計算モジュール１５０から参照１５２される。
例えば、アクセス履歴記憶モジュール１２０は、アクセス履歴テーブル３００を記憶する。図３は、アクセス履歴テーブル３００のデータ構造例を示す説明図である。アクセス履歴テーブル３００は、ユーザーＩＤ欄３１０、アクセス日時欄３２０、対象ページ欄３３０、結果欄３４０を有している。ユーザーＩＤ欄３１０は、ユーザーＩＤを記憶している。アクセス日時欄３２０は、そのユーザーによってアクセスが行われた日時を記憶している。対象ページ欄３３０は、そのユーザーによってアクセスが行われたＷｅｂページを記憶している。結果欄３４０は、そのアクセスの結果（例えば、成功（ＯＫ）、失敗（ＥＲＲＯＲ）等）を記憶している。

エラー検知モジュール１３０は、ユーザーアクセス監視モジュール１４０と接続されている。エラー検知モジュール１３０は、ユーザーアクセス監視モジュール１４０に対して起動１３２の処理を行う。エラー検知モジュール１３０は、Ｗｅｂページに関するエラーを検知する。「Ｗｅｂページに関するエラー」として、例えば、Ｗｅｂページへのアクセスエラー等がある。例えば、Ｗｅｂページを管理しているシステムを監視し、エラーを検知する。エラー検知後、発生したエラーの情報（ユーザーＩＤ、日時、Ｗｅｂページ等）をユーザーアクセス監視モジュール１４０に渡す。

ユーザーアクセス監視モジュール１４０は、アクセス履歴記憶モジュール１２０、エラー検知モジュール１３０、エラー深刻度計算モジュール１５０、エラー通知判定モジュール１６０と接続されている。ユーザーアクセス監視モジュール１４０は、アクセス履歴記憶モジュール１２０に対して監視１４５の処理を行い、エラー深刻度計算モジュール１５０に対して起動１４２の処理を行う。ユーザーアクセス監視モジュール１４０は、エラー検知モジュール１３０によってエラーが検知された場合、そのエラー後のユーザーの操作によるＷｅｂページへのアクセスを監視する。例えば、アクセス履歴記憶モジュール１２０内のエラー検知後の対象ユーザーにおけるアクセス履歴を取得すればよい。
また、ユーザーアクセス監視モジュール１４０は、Ｗｅｂページへのアクセスが成功した場合は、監視を中止するようにしてもよい。
また、ユーザーアクセス監視モジュール１４０による監視は、予め定められた期間としてもよい。
具体的には、ユーザーアクセス監視モジュール１４０は、指定されたユーザーのアクセスを予め定められた期間監視し、ユーザーのアクセスを検知した場合、エラー検知モジュール１３０から渡されたエラー情報とともに、エラー深刻度計算モジュール１５０を起動１４２して、それらの情報を渡す。ユーザーアクセス監視モジュール１４０は、予め定められた期間中に複数のアクセスがあった場合、その都度、エラー深刻度計算モジュール１５０を起動１４２する。

エラー深刻度計算モジュール１５０は、アクセス履歴記憶モジュール１２０、ユーザーアクセス監視モジュール１４０、エラー通知判定モジュール１６０と接続されている。エラー深刻度計算モジュール１５０は、アクセス履歴記憶モジュール１２０に対して参照１５２の処理を行い、エラー通知判定モジュール１６０に計算結果１５４を渡す。エラー深刻度計算モジュール１５０は、エラー検知モジュール１３０による監視結果に応じて、ユーザーにおけるエラーの深刻度を算出する。ここでの監視結果は、エラー発生後の対象ユーザーのアクセス履歴である。
また、エラー深刻度計算モジュール１５０は、Ｗｅｂページへのアクセスに関するエラーの回数に基づいて深刻度を算出するようにしてもよい。
具体的には、エラー深刻度計算モジュール１５０は、ユーザーアクセス監視モジュール１４０から渡されたエラー情報から、エラー発生日時から現在までの対象ユーザーのアクセス履歴を取得し、このアクセス履歴の情報を用いて対象ユーザーに対するエラーの深刻度を算出する。深刻度の計算は、対象Ｗｅｂページへのアクセスの成功／失敗の回数を使用して判定する。そして、算出したエラー深刻度をエラー情報とともに、エラー通知判定モジュール１６０へ渡す。

エラー通知判定モジュール１６０は、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、エラー通知モジュール１７０と接続されている。エラー通知判定モジュール１６０は、ユーザーアクセス監視モジュール１４０に対してクリア１６２の処理を行い、エラー深刻度計算モジュール１５０から計算結果１５４を受け取り、エラー通知モジュール１７０に対して起動１６４の処理を行う。エラー通知判定モジュール１６０は、ユーザーアクセス監視モジュール１４０による監視結果に応じて、エラーに対処する担当者への通知を行うようにエラー通知モジュール１７０を制御する。
また、エラー通知判定モジュール１６０は、エラー深刻度計算モジュール１５０によって算出された深刻度が予め定められた閾値より多い又は以上である場合は、エラーに対処する担当者への通知を行うようにエラー通知モジュール１７０を制御してもよい。ユーザーにとって深刻度の高いエラーを優先的に通知し、ユーザーにとって深刻でないエラーの通知を抑制している。
また、ユーザーアクセス監視モジュール１４０による監視は、予め定められた期間としてもよい。その場合、エラー通知判定モジュール１６０は、監視結果として、その監視期間内における最後のＷｅｂページへのアクセスが成功している場合は、通知は行わない又は緊急用の通知は行わないように制御してもよい。
具体的には、エラー通知判定モジュール１６０は、予め定められた閾値とエラー深刻度計算モジュール１５０で計算した深刻度を比較する。深刻度が閾値以上の場合、ユーザーアクセス監視モジュール１４０をクリア１６２し、エラー通知モジュール１７０にエラー情報を渡して通知を依頼する。

エラー通知モジュール１７０は、エラー通知判定モジュール１６０と接続されている。エラー通知モジュール１７０は、エラー通知判定モジュール１６０による制御によって、エラーに対処する担当者への通知を行う。「エラーに対処する担当者」は、主に、エラーの原因追及、その問題の解消等を行う運用担当者であって、一般的に管理者、設計者と呼ばれている者を含めてもよい。通知としては、電子メール、チャット、電子掲示板、ソーシャルメディアを用いた通知、プッシュ通知等であってもよい。
具体的には、エラー通知モジュール１７０は、エラー通知判定モジュール１６０から渡されたエラー情報を運用担当者に通知する。

図２は、本実施の形態を利用したシステム構成例を示す説明図である。
情報処理装置１００、ユーザー端末２１０Ａ、ユーザー端末２１０Ｂ、担当者端末２２０、サービス提供装置２５０は、通信回線２９０を介してそれぞれ接続されている。通信回線２９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット、イントラネット等であってもよい。
サービス提供装置２５０は、ユーザー端末２１０に対してＷｅｂページを介してサービスを提供する。サービス提供は、クラウドサービスとして実現してもよい。ユーザー端末２１０は、ユーザーの操作に応じて、サービス提供装置２５０にアクセスする。情報処理装置１００は、Ｗｅｂページに関するエラーが発生した場合は、担当者端末２２０の担当者に通知を行う。その担当者は、エラー原因の解明、復旧等を行う。なお、情報処理装置１００は、サービス提供装置２５０内に組み込んで構成してもよい。

図４は、第１の実施の形態による処理例を示すフローチャートである。
ステップＳ４０２では、エラー検知モジュール１３０がエラーを検知し、ユーザーアクセス監視モジュール１４０に対象ユーザーのアクセス監視を予め定められた期間依頼する。
ステップＳ４０４では、監視期間内であるか否かを判断し、監視期間内である場合はステップＳ４０６へ進み、それ以外の場合は処理を終了する（ステップＳ４９９）。ステップＳ４０４からステップＳ４１６までの処理を繰り返し行う。
ステップＳ４０６では、ユーザーアクセス監視モジュール１４０が、対象ユーザーのアクセスがないかを確認する。

ステップＳ４０８では、ユーザーアクセス監視モジュール１４０が、新しいアクセスがあったか否かを判断し、あった場合はステップＳ４１０へ進み、それ以外の場合はステップＳ４１６へ進む。
ステップＳ４１０では、エラー深刻度計算モジュール１５０にて、エラー深刻度を計算する。ステップＳ４１０における処理の詳細は、図５に例示するフローチャートを用いて後述する。
ステップＳ４１２では、エラー通知判定モジュール１６０にて、通知を行うかを判定する。ステップＳ４１２における処理の詳細は、図６に例示するフローチャートを用いて後述する。
ステップＳ４１４では、エラー通知判定モジュール１６０が、通知するか否かを判断し、通知する場合はステップＳ４１８へ進み、それ以外の場合はステップＳ４１６へ進む。
ステップＳ４１６では、予め定められた期間待機し、ステップＳ４０４に戻る。
ステップＳ４１８では、エラー通知モジュール１７０にて通知を実施する。

図５は、第１の実施の形態（エラー深刻度計算モジュール１５０）による処理例を示すフローチャートである。
ステップＳ５０２では、ユーザーアクセス監視モジュール１４０より、対象ユーザーＩＤ、エラー発生日時、エラー発生したＷｅｂページの情報を受け取る。
ステップＳ５０４では、エラー深刻度に「０」を代入する。
ステップＳ５０６では、『ユーザーＩＤ：「対象ユーザーＩＤ」、発生日時：「エラー発生日時」以降』の条件でアクセス履歴を取得する。
ステップＳ５０８では、取得した全てのアクセス履歴を確認したか否かを判断し、確認した場合は処理を終了し（ステップＳ５９９）、それ以外の場合はステップＳ５１０へ進む。ステップＳ５０８からステップＳ５１８までの処理を繰り返し行う。

ステップＳ５１０では、エラー発生したＷｅｂページの履歴であるか否かを判断し、エラー発生したＷｅｂページの履歴である場合はステップＳ５１２へ進み、それ以外の場合はステップＳ５１８へ進む。
ステップＳ５１２では、結果はＯＫであるか否かを判断し、ＯＫである場合はステップＳ５１４へ進み、それ以外の場合はステップＳ５１６へ進む。
ステップＳ５１４では、エラー深刻度に「０」を代入する。
ステップＳ５１６では、エラー深刻度に「エラー深刻度＋１」を代入する。
ステップＳ５１８では、ステップＳ５０８の処理に戻る。

図６は、第１の実施の形態（エラー通知判定モジュール１６０）による処理例を示すフローチャートである。
ステップＳ６０２では、エラー深刻度計算モジュール１５０より、対象ユーザーＩＤ、エラー発生日時、エラー発生したＷｅｂページ、エラー深刻度の情報を受け取る。
ステップＳ６０４では、判定閾値として、システムに予め設定された値を取得する。
ステップＳ６０６では、エラー深刻度＞＝判定閾値であるか否かを判断し、エラー深刻度＞＝判定閾値である場合はステップＳ６０８へ進み、それ以外の場合は処理を終了する（ステップＳ６９９）。
ステップＳ６０８では、エラー通知モジュール１７０に通知依頼を送信する。
ステップＳ６１０では、ユーザーアクセス監視モジュール１４０に対象ユーザーのアクセス監視の停止を依頼する。

以下、具体例を用いて説明する。
Ｗｅｂページ上でユーザーに対して、様々なサービスを提供するシステム（例えば、サービス提供装置２５０）に適用した例を示す。
ユーザーがＷｅｂページを操作中にエラーが発生したケースを考える。アクセス履歴となる対象ユーザー、エラー発生時刻、エラー発生したＷｅｂページは、以下の通りとする。
・対象ユーザー：Ｕｓｅｒ００１
・エラー発生時刻：２０１５／０１／０１ １２：００：００
・エラー発生Ｗｅｂページ：／ｍｙｐａｇｅ.ｈｔｍｌ
この状態では、図７に例示のアクセス履歴テーブル７００にアクセス履歴が保存されている。図７は、アクセス履歴テーブル７００のデータ構造例を示す説明図である。アクセス履歴テーブル７００は、図３に例示のアクセス履歴テーブル３００と同等の構成を有している。アクセス履歴テーブル７００には、前述のアクセス履歴が記憶されている。

エラー検知モジュール１３０はエラーを検知し、ユーザーアクセス監視モジュール１４０に以下の条件で監視を依頼する。
・対象ユーザー：Ｕｓｅｒ００１
・エラー発生時刻：２０１５／０１／０１ １２：００：００
・エラー発生Ｗｅｂページ：／ｍｙｐａｇｅ.ｈｔｍｌ
・監視期間：１０分間
・確認タイミング：１分毎

１分後、エラー発生ユーザーのアクセス履歴は、図８に例示のアクセス履歴テーブル８００のようになっていた。
図８は、アクセス履歴テーブル８００のデータ構造例を示す説明図である。アクセス履歴テーブル８００は、図３に例示のアクセス履歴テーブル３００と同等の構成を有している。つまり、図７に例示のアクセス履歴テーブル７００の状態から、１行追加されている。具体的には、
・ユーザーＩＤ：Ｕｓｅｒ００１
・アクセス日時：２０１５／０１／０１ １２：００：３０
・対象Ｗｅｂページ：／ｔｏｐ.ｈｔｍｌ
・結果：ＯＫ
この履歴から、１回目のエラー深刻度の計算を実施する。
エラー深刻度は、以下の方法で決定する。
１．エラー発生Ｗｅｂページで結果「ＯＫ」の履歴がある場合、深刻度は「０」とする。
２．上記以外の場合、エラー発生Ｗｅｂページで結果「ＥＲＲＯＲ」の履歴の個数をエラー深刻度とする。
今回のアクセス履歴では、エラー深刻度は「１」と計算される。

次に、このエラー深刻度でエラー通知をすべきかを判定する。
通知の判定は、システムに予め定められた閾値と比較して行う。今回の閾値は「３」とする。
エラー深刻度「１」＞＝閾値「３」は、条件を満たさないため、今回の確認では通知を実施せずとする。

その１分後（２０１５／０１／０１ １２：０２：００）、アクセス履歴が図９に例示のアクセス履歴テーブル９００のように変化していたとする。
図９は、アクセス履歴テーブル９００のデータ構造例を示す説明図である。アクセス履歴テーブル９００は、図３に例示のアクセス履歴テーブル３００と同等の構成を有している。つまり、図８に例示のアクセス履歴テーブル８００の状態から、３行追加されている。具体的には、
「３行目」
・ユーザーＩＤ：Ｕｓｅｒ００１
・アクセス日時：２０１５／０１／０１ １２：０１：１０
・対象Ｗｅｂページ：／ｍｙｐａｇｅ.ｈｔｍｌ
・結果：ＥＲＲＯＲ
「４行目」
・ユーザーＩＤ：Ｕｓｅｒ００１
・アクセス日時：２０１５／０１／０１ １２：０１：２０
・対象Ｗｅｂページ：／ｔｏｐ.ｈｔｍｌ
・結果：ＯＫ
「５行目」
・ユーザーＩＤ：Ｕｓｅｒ００１
・アクセス日時：２０１５／０１／０１ １２：０１：３０
・対象Ｗｅｂページ：／ｍｙｐａｇｅ.ｈｔｍｌ
・結果：ＥＲＲＯＲ

これらのアクセス履歴から対象ユーザーは、使用したい機能（「／ｍｙｐａｇｅ.ｈｔｍｌ」）に何回もアクセスを試みているが、結果が全て「ＥＲＲＯＲ」と返っていることが分かる。何度もアクセスしているということは、対象ユーザーにとって重要な機能であり、このＷｅｂページがエラーになるとユーザーにとってエラー深刻度が大きいと考えられる。エラー深刻度が大きいエラーは、早期に運用担当者に通知を行い、対応する必要がある。
これらのアクセス履歴でエラー深刻度を計算すると「３」という値となり、前回の「１」という値から増加している。
この値でエラー通知判定モジュール１６０で通知判定を実施すると、エラー深刻度「３」＞＝閾値「３」という条件を満たすため、通知が必要という判定になる。
エラーに関する情報（対象ユーザー、エラー発生日時、エラー発生Ｗｅｂページ）の情報をエラー通知モジュール１７０に渡し、通知を実施する。
また、通知を実施した以上、対象ユーザーのアクセス監視は不要とし、アクセス監視を停止する。

次に、「２０１５／０１／０１ １２：０２：００」のアクセス履歴が、図１０に例示のアクセス履歴テーブル１０００のケースを用いて説明する。
図１０は、アクセス履歴テーブル１０００のデータ構造例を示す説明図である。アクセス履歴テーブル１０００は、図３に例示のアクセス履歴テーブル３００と同等の構成を有している。つまり、図８に例示のアクセス履歴テーブル８００の状態から、５行追加されている。具体的には、３〜５行目は、図９に例示のアクセス履歴テーブル９００と同じである。
「６行目」
・ユーザーＩＤ：Ｕｓｅｒ００１
・アクセス日時：２０１５／０１／０１ １２：０１：４０
・対象Ｗｅｂページ：／ｔｏｐ.ｈｔｍｌ
・結果：ＯＫ
「７行目」
・ユーザーＩＤ：Ｕｓｅｒ００１
・アクセス日時：２０１５／０１／０１ １２：０１：５０
・対象Ｗｅｂページ：／ｍｙｐａｇｅ.ｈｔｍｌ
・結果：ＯＫ

図１０に例示のアクセス履歴の場合、対象Ｗｅｂページ「／ｍｙｐａｇｅ.ｈｔｍｌ」の結果「ＥＲＲＯＲ」の履歴が３件あるが、最後に結果「ＯＫ」の履歴１件がある。
この場合、対象ユーザーが実施したい操作が最終的には実行できたと考えられ、早急な対応は必要なしと考えられる。
エラーが発生したＷｅｂページと同じＷｅｂページでの「ＯＫ」の履歴がある場合、エラー深刻度は「０」とし、定期的な監視対象から除外する。

＜＜第２の実施の形態＞＞
図１１は、第２の実施の形態の構成例についての概念的なモジュール構成図である。
情報処理装置１１００は、アクセス履歴記録モジュール１１０、アクセス履歴記憶モジュール１２０、エラー検知モジュール１３０、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、エラー通知判定モジュール１６０、エラー通知モジュール１７０、ページ別エラー影響度記憶モジュール１１６０を有している。なお、前述の実施の形態と同種の部位には同一符号を付し重複した説明を省略する（以下、同様）。
エラー深刻度計算モジュール１５０は、アクセス履歴記憶モジュール１２０、ユーザーアクセス監視モジュール１４０、エラー通知判定モジュール１６０、ページ別エラー影響度記憶モジュール１１６０と接続されている。エラー深刻度計算モジュール１５０は、アクセス履歴記憶モジュール１２０に対して参照１５２の処理を行い、ページ別エラー影響度記憶モジュール１１６０に対して参照１１５２の処理を行い、エラー通知判定モジュール１６０に計算結果１５４を渡す。エラー深刻度計算モジュール１５０は、さらに予め定められたＷｅｂページへのアクセスがあったことに基づいて深刻度を算出する。
エラー深刻度計算モジュール１５０は、エラー深刻度の算出において、エラーが発生したＷｅｂページに関連する他のＷｅｂページへのアクセスを考慮して計算する。関連する他のＷｅｂページへのアクセスとしては、例えば、エラー後に、問い合わせＷｅｂページを開くこと、ＦＡＱＷｅｂページを開くこと等が該当する。問い合わせＷｅｂページを開いた場合は、ユーザーにとって重大な問題である可能性が高いので深刻度を上げることを行い、ＦＡＱＷｅｂページを開いた場合は、ユーザーによる自己解決が見込まれるため、深刻度を下げる等を行う。深刻度の精度を向上させるために行うものである。

ページ別エラー影響度記憶モジュール１１６０は、エラー深刻度計算モジュール１５０と接続されている。ページ別エラー影響度記憶モジュール１１６０は、例えば、ページ別エラー影響度テーブル１２００を記憶している。図１２は、ページ別エラー影響度テーブル１２００のデータ構造例を示す説明図である。ページ別エラー影響度テーブル１２００は、対象ページ欄１２１０、影響度欄１２２０を有している。対象ページ欄１２１０は、対象とするＷｅｂページを記憶している。影響度欄１２２０は、そのＷｅｂページにアクセスした場合の影響度を記憶している。つまり、Ｗｅｂページ別エラー影響度テーブル１２００は、システム（サービス提供装置２５０）内の各Ｗｅｂページのエラー時の影響度を保持した情報で、予め設定されている。エラー深刻度計算モジュール１５０で深刻度を計算する際に、アクセス履歴にこれらのＷｅｂページが含まれていた場合、影響度の値を深刻度に加算又は減算する。

図１３は、第２の実施の形態による処理例を示すフローチャートである。第１の実施の形態による図５に例示したフローチャートに対応するものであり、図５に例示したフローチャートにステップＳ１３１８、ステップＳ１３２０、ステップＳ１３２２の処理を付加したものである。
ステップＳ１３０２では、ユーザーアクセス監視モジュール１４０より、対象ユーザーＩＤ、エラー発生日時、エラー発生Ｗｅｂページの情報を受け取る。
ステップＳ１３０４では、エラー深刻度に「０」を代入する。
ステップＳ１３０６では、『ユーザーＩＤ：「対象ユーザーＩＤ」、発生日時：「エラー発生日時」以降』の条件でアクセス履歴を取得する。
ステップＳ１３０８では、取得した全てのアクセス履歴を確認したか否かを判断し、確認した場合は処理を終了し（ステップＳ１３９９）、それ以外の場合はステップＳ１３１０へ進む。ステップＳ１３０８からステップＳ１３２４までの処理を繰り返し行う。

ステップＳ１３１０では、エラー発生Ｗｅｂページの履歴であるか否かを判断し、エラー発生Ｗｅｂページの履歴である場合はステップＳ１３１２へ進み、それ以外の場合はステップＳ１３１８へ進む。
ステップＳ１３１２では、結果はＯＫであるか否かを判断し、ＯＫである場合はステップＳ１３１４へ進み、それ以外の場合はステップＳ１３１６へ進む。
ステップＳ１３１４では、エラー深刻度に「０」を代入する。
ステップＳ１３１６では、エラー深刻度に「エラー深刻度＋１」を代入する。
ステップＳ１３１８では、ページ別エラー影響度記憶モジュール１１６０に存在するページであるか否かを判断し、ページ別エラー影響度記憶モジュール１１６０に存在するページである場合はステップＳ１３２０へ進み、それ以外の場合はステップＳ１３２４へ進む。
ステップＳ１３２０では、対象Ｗｅｂページの「Ｗｅｂページ別エラー影響度」を取得する。
ステップＳ１３２２では、エラー深刻度に「エラー深刻度＋影響度」を代入する。
ステップＳ１３２４では、ステップＳ１３０８の処理に戻る。

以下、具体例を用いて説明する。
第２の実施の形態では、エラー発生後にお問い合わせＷｅｂページを開いている場合は、ユーザーにとって深刻度が高いと考え深刻度を上げる、ＦＡＱやヘルプのＷｅｂページを開いている場合、ユーザーの自己解決の可能性があるため深刻度を下げる、といった考慮を実施するために行う。
この考慮を行うにあたって、各Ｗｅｂページに対して上記のようなエラー深刻度への影響度を、ページ別エラー影響度テーブル１４００の例に示すように予め定めておく。図１４は、ページ別エラー影響度テーブル１４００のデータ構造例を示す説明図である。ページ別エラー影響度テーブル１４００は、図１２に例示のページ別エラー影響度テーブル１２００に対象ページ名欄１４２０を付加したものである。ページ別エラー影響度テーブル１４００は、対象ページ欄１４１０、対象ページ名欄１４２０、影響度欄１４３０を有している。対象ページ欄１４１０は、対象とするＷｅｂページを記憶している。対象ページ名欄１４２０は、その対象Ｗｅｂページの名称を記憶している。影響度欄１４３０は、そのＷｅｂページにアクセスした場合の影響度を記憶している。

ページ別エラー影響度テーブル１４００のように定義したうえで、「２０１５／０１／０１ １２：０２：００」の時点におけるアクセス履歴が、図１５に例示のアクセス履歴テーブル１５００のようになっていたとする。図１５は、アクセス履歴テーブル１５００のデータ構造例を示す説明図である。アクセス履歴テーブル１５００は、図３に例示のアクセス履歴テーブル３００と同等の構成を有している。
アクセス履歴テーブル１５００の状態である場合、前述の第１の実施の形態による深刻度の計算では、「ＥＲＲＯＲ」が２件しかないため深刻度「２」となり、通知は実施せずという判定になる。
しかし、第２の実施の形態では、エラー発生Ｗｅｂページで算出した深刻度に加え、Ｗｅｂページ別エラー影響度に登録されているＷｅｂページへのアクセスを確認し、アクセスがあった場合、「影響度」の値を深刻度の値に加算する。
この例の場合、エラー発生Ｗｅｂページから算出した深刻度「２」＋お問い合わせＷｅｂページへのアクセス１回「３」＝５となり、「５」が最終的な深刻度となる。
この値は閾値を超えているため、エラー通知が実施されるようになる。

また、逆に通知を抑制する例として、図１６に例示のアクセス履歴テーブル１６００のケースを用いて説明する。図１６は、アクセス履歴テーブル１６００のデータ構造例を示す説明図である。アクセス履歴テーブル１６００は、図３に例示のアクセス履歴テーブル３００と同等の構成を有している。
図１６に例示のアクセス履歴テーブル１６００の場合、前述の第１の実施の形態による深刻度の計算では、「ＥＲＲＯＲ」が３件あるため深刻度「３」となり、通知が実施される。
しかし、第２の実施の形態では、ＦＡＱＷｅｂページ（／ｆａｑ．ｈｔｍｌ）へのアクセスがある（アクセス履歴テーブル１６００の最終行）ため、最終的な深刻度が「２」となり、通知が抑制される。

＜＜第３の実施の形態＞＞
図１７は、第３の実施の形態の構成例についての概念的なモジュール構成図である。
情報処理装置１７００は、アクセス履歴記録モジュール１１０、アクセス履歴記憶モジュール１２０、エラー検知モジュール１３０、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、エラー通知判定モジュール１６０、エラー通知モジュール１７０、ユーザー別ページ重要度計算モジュール１７１０、ユーザー別ページ重要度記憶モジュール１７２０、ユーザー情報記憶モジュール１７３０を有している。
アクセス履歴記憶モジュール１２０は、アクセス履歴記録モジュール１１０、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、ユーザー別ページ重要度計算モジュール１７１０と接続されている。
エラー深刻度計算モジュール１５０は、アクセス履歴記憶モジュール１２０、ユーザーアクセス監視モジュール１４０、エラー通知判定モジュール１６０、ユーザー別ページ重要度記憶モジュール１７２０と接続されている。エラー深刻度計算モジュール１５０は、アクセス履歴記憶モジュール１２０及びユーザー別ページ重要度記憶モジュール１７２０に対して参照１５２の処理を行い、エラー通知判定モジュール１６０に計算結果１５４を渡す。

ユーザー別ページ重要度計算モジュール１７１０は、アクセス履歴記憶モジュール１２０、ユーザー別ページ重要度記憶モジュール１７２０、ユーザー情報記憶モジュール１７３０と接続されている。
ユーザー別ページ重要度記憶モジュール１７２０は、エラー深刻度計算モジュール１５０、ユーザー別ページ重要度計算モジュール１７１０と接続されている。
ユーザー情報記憶モジュール１７３０は、ユーザー別ページ重要度計算モジュール１７１０と接続されている。
ユーザー別ページ重要度計算モジュール１７１０は、ユーザー別ページ重要度記憶モジュール１７２０に対して記録１７１２の処理を行う。ユーザー別ページ重要度計算モジュール１７１０は、ユーザーのＷｅｂページへのアクセス履歴に基づいて、エラーが発生したＷｅｂページの重要度を算出する。
そして、その場合、エラー深刻度計算モジュール１５０は、その重要度に基づいて深刻度を算出する。
エラー深刻度の算出のために、対象ユーザーに対するエラー発生Ｗｅｂページの重要度を考慮するものである。ユーザーの使い方に応じた深刻度を算出することができ、深刻度の精度を向上させるものである。

また、ユーザー別ページ重要度計算モジュール１７１０は、予め定められた日にち、時間帯におけるアクセス履歴に基づいて、エラーが発生したＷｅｂページの重要度を算出するようにしてもよい。対象ユーザーにおけるエラー発生Ｗｅｂページの重要度を、そのＷｅｂページをユーザーが使用する日にち、時間帯による利用頻度を考慮して算出するものである。エラー深刻度の算出に、日時に関するユーザーの使い方を考慮することができ、深刻度の精度を向上させる。

また、ユーザー別ページ重要度計算モジュール１７１０は、ユーザーと類似する他のユーザーにおける重要度を用いるようにしてもよい。この処理は、対象としているユーザーのアクセス履歴が予め定められた値よりも少ない場合、又は、対象としているユーザーが登録された期間が予め定められた期間よりも短い場合を条件としてもよい。対象ユーザーにおけるエラー発生Ｗｅｂページの重要度を、ユーザーの属性情報の類似度の高いユーザーの値を参照して算出するものである。深刻度を算出するためには、アクセス履歴の量が十分ではないユーザーであっても、類似しているユーザーの使い方を考慮した深刻度を算出することができ、深刻度の精度を向上させる。

具体的に説明する。
ユーザー別ページ重要度計算モジュール１７１０は、アクセス履歴記憶モジュール１２０から各ユーザーのＷｅｂページ毎の重要度を算出する。ユーザー別ページ重要度計算モジュール１７１０は定期的に実行され、ユーザーのアクセス対象や嗜好が変化した際に重要度も変化できるようにする。
また、アクセス履歴が十分に記録されていないユーザー（初心者等）の場合は、ユーザー情報記憶モジュール１７３０から類似度の高いユーザーを抽出し、このユーザーの重要度を使用する機能も持つ。

ユーザー別ページ重要度記憶モジュール１７２０は、例えば、ユーザー別ページ重要度テーブル１８００を記憶している。図１８は、ユーザー別ページ重要度テーブル１８００のデータ構造例を示す説明図である。ユーザー別ページ重要度テーブル１８００は、ユーザーＩＤ欄１８１０、対象ページ欄１８２０、重要度欄１８３０を有している。ユーザーＩＤ欄１８１０は、ユーザーＩＤを記憶している。対象ページ欄１８２０は、そのユーザーに対応する対象Ｗｅｂページを記憶している。重要度欄１８３０は、そのユーザーにおけるその対象Ｗｅｂページの重要度を記憶している。つまり、ユーザー別Ｗｅｂページ重要度テーブル１８００は、システム（サービス提供装置２５０）上にある各Ｗｅｂページに対する、ユーザー毎の重要度を記録する領域である。「重要度」は１を基準とし、ユーザーにとって重要な機能は１より大きな値、ユーザーにとって重要度が低い機能は０以上で１未満の値を設定する。

また、日にち、時間帯を考慮した深刻度を考慮する場合、ユーザー別ページ重要度テーブル１８００に「対象期間・日時」の情報を追加し、図１９に例示のユーザー別ページ重要度テーブル１９００のように同一の「ユーザーＩＤ」「対象ページ」に対して複数の重要度が設定される。図１９は、ユーザー別ページ重要度テーブル１９００のデータ構造例を示す説明図である。ユーザー別ページ重要度テーブル１９００は、ユーザーＩＤ欄１９１０、対象ページ欄１９２０、重要度欄１９３０、対象期間・日時欄１９４０を有している。ユーザーＩＤ欄１９１０は、ユーザーＩＤを記憶している。対象ページ欄１９２０は、そのユーザーに対応する対象Ｗｅｂページを記憶している。重要度欄１９３０は、そのユーザーにおけるその対象Ｗｅｂページの重要度を記憶している。対象期間・日時欄１９４０は、日にち、時間帯を記憶している。つまり、重要度欄１９３０の重要度が適用されるのは、対象期間・日時欄１９４０での日にち、時間帯にアクセスがあった場合である。

ユーザー情報記憶モジュール１７３０は、例えば、ユーザー情報テーブル２０００を記憶している。ユーザー情報テーブル２０００は、各ユーザーの属性を示す情報を記憶する。年齢、性別、職業等のようにユーザーの分類を実施する際に使用可能な属性の一覧を保持する。図２０は、ユーザー情報テーブル２０００のデータ構造例を示す説明図である。ユーザー情報テーブル２０００は、ユーザーＩＤ欄２０１０、性別欄２０２０、生年月日欄２０３０、職業欄２０４０、職種欄２０５０、業種欄２０６０を有している。ユーザーＩＤ欄２０１０は、ユーザーＩＤを記憶している。性別欄２０２０は、そのユーザーの性別を記憶している。生年月日欄２０３０は、そのユーザーの生年月日を記憶している。職業欄２０４０は、そのユーザーの職業を記憶している。職種欄２０５０は、そのユーザーの職種を記憶している。業種欄２０６０は、そのユーザーの業種を記憶している。

図２１は、第３の実施の形態による処理例を示すフローチャートである。第１の実施の形態による図５に例示したフローチャートに対応するものであり、図５に例示したフローチャートにステップＳ２１１０、ステップＳ２１１２の処理を付加したものである。
ステップＳ２１０２では、ユーザーアクセス監視モジュール１４０より、対象ユーザーＩＤ、エラー発生日時、エラー発生Ｗｅｂページの情報を受け取る。
ステップＳ２１０４では、エラー深刻度に「０」を代入する。
ステップＳ２１０６では、『ユーザーＩＤ：「対象ユーザーＩＤ」、発生日時：「エラー発生日時」以降』の条件でアクセス履歴を取得する。
ステップＳ２１０８では、取得した全てのアクセス履歴を確認したか否かを判断し、確認した場合はステップＳ２１１０へ進み、それ以外の場合はステップＳ２１１４へ進む。ステップＳ２１０８からステップＳ２１２２までの処理を繰り返し行う。

ステップＳ２１１０では、ユーザー別ページ重要度記憶モジュール１７２０から「対象ユーザーＩＤ」「エラー発生ページ」の「重要度」を取得する。
ステップＳ２１１２では、エラー深刻度に「エラー深刻度＊重要度」を代入する。
ステップＳ２１１４では、エラー発生Ｗｅｂページの履歴であるか否かを判断し、エラー発生ページの履歴である場合はステップＳ２１１６へ進み、それ以外の場合はステップＳ２１２２へ進む。
ステップＳ２１１６では、結果はＯＫであるか否かを判断し、ＯＫである場合はステップＳ２１１８へ進み、それ以外の場合はステップＳ２１２０へ進む。
ステップＳ２１１８では、エラー深刻度に「０」を代入する。
ステップＳ２１２０では、エラー深刻度に「エラー深刻度＋１」を代入する。
ステップＳ２１２２では、ステップＳ２１０８の処理に戻る。

以下、具体例を用いて説明する。
（１）ユーザー別Ｗｅｂページ重要度を使用した深刻度の計算
システム（サービス提供装置２５０）内には様々なＷｅｂページがあり、ユーザーによって重要なＷｅｂページ、あまり重要でないＷｅｂページが存在するはずである。そして、ユーザーにとって重要なＷｅｂページでエラーが発生した場合、他のＷｅｂページでのエラーと比較して、深刻度は高いと考えられる。このような考慮をこの第３の実施の形態では実施する。
まず、ユーザー毎のシステム（サービス提供装置２５０）内の各Ｗｅｂページの重要度を決定する。重要度は１を中心とし、重要な場合１より大きい値、重要でない場合０以上１未満の値を設定する。

ユーザー毎の各Ｗｅｂページの重要度は過去アクセス履歴から算出する。
算出方法は様々にある、一例として、第３の実施の形態では「過去１カ月のアクセスしない日を除く１日のうちの利用確率」を使用する。例えば、過去１カ月でアクセスした日が５日とし、５日中４日使用している場合、利用確率は「０．８」となる。
例として、「Ｕｓｅｒ００１」の過去１カ月の各Ｗｅｂページの利用確率が、図２２に例示のユーザー別ページ利用確率テーブル２２００であったと仮定する。図２２は、ユーザー別ページ利用確率テーブル２２００のデータ構造例を示す説明図である。ユーザー別ページ利用確率テーブル２２００は、ユーザーＩＤ欄２２１０、対象ページ欄２２２０、利用確率欄２２３０を有している。ユーザーＩＤ欄２２１０は、ユーザーＩＤを記憶している。対象ページ欄２２２０は、対象としているＷｅｂページを記憶している。利用確率欄２２３０は、そのユーザーによるそのＷｅｂページの利用確率を記憶している。

利用確率から重要度への変換も様々な方法がある。例えば、予め定めた変換テーブルを利用する方法がある。一例として、第３の実施の形態では「０．７〜１．０」を「２．０」、「０．３〜０．７」を「１．０」、「０〜０．３」を「０．５」とする。すると、「Ｕｓｅｒ００１」の各Ｗｅｂページの重要度は図２３に例示のユーザー別ページ利用確率重要度テーブル２３００のように決定できる。図２３は、ユーザー別ページ利用確率重要度テーブル２３００のデータ構造例を示す説明図である。ユーザー別ページ利用確率重要度テーブル２３００は、ユーザーＩＤ欄２３１０、対象ページ欄２３２０、利用確率欄２３３０、重要度欄２３４０を有している。ユーザー別ページ利用確率重要度テーブル２３００は、ユーザー別ページ利用確率テーブル２２００に重要度欄２３４０を付加したものであり、図１８に例示のユーザー別ページ重要度テーブル１８００に対応するもの（ユーザー別ページ重要度テーブル１８００に利用確率欄２３３０を付加したもの）である。ユーザーＩＤ欄２３１０は、ユーザーＩＤを記憶している。対象ページ欄２３２０は、対象としているＷｅｂページを記憶している。利用確率欄２３３０は、そのユーザーによるそのＷｅｂページの利用確率を記憶している。重要度欄２３４０は、その利用確率のときの重要度を記憶している。

このような算出を実施したのち、「Ｕｓｅｒ００１」の操作でエラーが出た場合のエラー深刻度の算出について説明する。
例として「／ｉｍｐｏｒｔａｎｔ．ｈｔｍｌ」でエラーが発生した場合を説明する。エラー発生後のユーザーのアクセス履歴が図２４に例示のアクセス履歴テーブル２４００のようになっているとする。図２４は、アクセス履歴テーブル２４００のデータ構造例を示す説明図である。アクセス履歴テーブル２４００は、図３に例示のアクセス履歴テーブル３００と同等の構成を有している。
図２４に例示のアクセス履歴テーブル２４００の場合、第１の実施の形態による深刻度の算出方法では、「ＥＲＲＯＲ」が２件しかないため「２」となり、通知の閾値が「３」の場合、通知を実施しないという判断となる。

しかし、このＷｅｂページはユーザーにとって重要度の高いＷｅｂページであり、このＷｅｂページが利用できないことはユーザーにとって深刻なエラーであると考えられる。そこで、第３の実施の形態では、エラーの深刻度を、第１の実施の形態のように算出した深刻度に、対象ユーザーにとってのエラー発生Ｗｅｂページの重要度の積を計算することで算出する。上記例の場合、重要度は「２．０」であるため、深刻度は「４」となる。
深刻度が「４」の場合、通知が実施されるようになり、ユーザーにとって重要度が高いページのエラーは優先的に通知することとなる。
一方で、ユーザーにとって重要でない機能の場合、重要度が１未満でエラー深刻度が下がるため、通知は実施されないようになる。

（２）対象Ｗｅｂページの利用時期、時間帯を考慮してユーザー別Ｗｅｂページ重要度を決定する方法
（１）では、「過去１カ月のアクセスしない日を除く１日のうちの利用確率」としてユーザーにとっての各Ｗｅｂページの重要度を決定した。
しかし、この方法では、普段はアクセスしないが、特定の日にち、時間帯では重要なＷｅｂページがあった場合に、重要度を低く算出してしまう可能性がある。
そこで、重要度を特定の日にち、時間帯毎に算出し、エラーが発生した日時によって重要度を決定することで精度を高める。
（１）の例で用いた「／ｎｅｗｓ．ｈｔｍｌ」で説明する。このＷｅｂページは、（１）では図２５に例示のユーザー別ページ利用確率テーブル２５００のように、利用確率は「０．３」となっていた。図２５は、ユーザー別ページ利用確率テーブル２５００のデータ構造例を示す説明図である。ユーザー別ページ利用確率テーブル２５００は、図２２に例示のユーザー別ページ利用確率テーブル２２００と同等の構成を有している。

しかし、過去１年間で月内の各日にちで利用確率を算出すると、図２６に例示のユーザー別ページ日にち利用確率テーブル２６００になったとする。図２６は、ユーザー別ページ日にち利用確率テーブル２６００のデータ構造例を示す説明図である。ユーザー別ページ日にち利用確率テーブル２６００は、図２５に例示のユーザー別ページ利用確率テーブル２５００に日にち欄２６３０を付加したものである。ユーザー別ページ日にち利用確率テーブル２６００は、ユーザーＩＤ欄２６１０、対象ページ欄２６２０、日にち欄２６３０、利用確率欄２６４０を有している。
ユーザーＩＤ欄２６１０は、ユーザーＩＤを記憶している。対象ページ欄２６２０は、対象Ｗｅｂページを記憶している。日にち欄２６３０は、そのユーザーがそのＷｅｂページにアクセスした日にち（月内の日、１〜３１日）を記憶している。利用確率欄２６４０は、その日にちにおける利用確率を記憶している。
このＷｅｂページは対象ユーザーにとって月初めに重要なＷｅｂページで、結果として月内の１，２日の利用確率が非常に高いことが分かる。

このことから（１）と同じ方法で、日にち毎の重要度を図２７に例示のユーザー別ページ日にち利用確率重要度テーブル２７００のように算出できる。図２７は、ユーザー別ページ日にち利用確率重要度テーブル２７００のデータ構造例を示す説明図である。ユーザー別ページ日にち利用確率重要度テーブル２７００は、図２６に例示のユーザー別ページ日にち利用確率テーブル２６００に重要度欄２７５０を付加したものである。ユーザー別ページ日にち利用確率重要度テーブル２７００は、ユーザーＩＤ欄２７１０、対象ページ欄２７２０、日にち欄２７３０、利用確率欄２７４０、重要度欄２７５０を有している。ユーザーＩＤ欄２７１０は、ユーザーＩＤを記憶している。対象ページ欄２７２０は、対象Ｗｅｂページを記憶している。日にち欄２７３０は、そのユーザーがそのＷｅｂページにアクセスした日にちを記憶している。利用確率欄２７４０は、その日にちにおける利用確率を記憶している。重要度欄２７５０は、その利用確率における重要度を記憶している。
次に、対象ユーザー操作中に「／ｎｅｗ．ｈｔｍｌ」でエラーが発生した場合に、エラー発生日時に応じて重要度を使い分けることで、特定の日だけ利用が多いＷｅｂページがある場合に、その特定の日にエラーが起きた場合は早急に通知を送ることができる。
この例では、「１カ月内の各日にち」という観点で重要度を算出したが、「１週間内の日にち（日曜日〜土曜日）」、「１日内の時間帯」、「１年内の各月」という観点で重要度を算出してもよい。

（３）ユーザー別ページ重要度をユーザーの属性情報を使用して類似のユーザーから取得する方法
（１）、（２）の方法では、予め定められた期間のアクセス履歴からユーザーに対する各ページの重要度を決定していた。
しかし、ユーザー登録直後で過去のアクセス履歴がほとんどないユーザーの場合、どのページが重要なのか分からないため、結果として深刻なエラーの通知が遅れる、重要でないエラーが通知されてしまうなどの問題がある。
この問題を解決するため、この（３）では、アクセス履歴が十分にないユーザーの各ページに対する重要度を、ユーザー属性が類似しているユーザーは、各ページへのアクセスの傾向が類似していると仮定して、対象ユーザーと類似するユーザーを探し、類似ユーザーが持つ重要度を使用することで解決する。
まず、ユーザー登録から１週間しか経っていないユーザー「Ｕｓｅｒ９９９」の操作でエラーが発生したとする。
（１）では、過去１カ月のアクセス履歴が必要であるが、この場合、ユーザー登録から１週間しか経っていないので、必要な１カ月分の履歴を保持していない。
このように重要度の決定に必要な期間のアクセス履歴が存在していないことを情報処理装置１００で検知した場合、対象ユーザーと類似のユーザーから各ページの重要度を決定する。

各ユーザーのユーザー属性が図２８に例示のユーザー情報テーブル２８００のようになっていたとする。図２８は、ユーザー情報テーブル２８００のデータ構造例を示す説明図である。ユーザー情報テーブル２８００は、図２０に例示のユーザー情報テーブル２０００と同等の構成を有している。
図２８に例示のユーザー情報テーブル２８００の中で類似ユーザーの検索を行う。例えば、類似ユーザーの検索は、「性別」、「年齢（生年月日の年部分を比較対象とする）」、「職業」、「職種」、「業種」の５つの属性で他ユーザーとの一致度を計算する。結果として、「Ｕｓｅｒ００４」が全ての属性で一致していることが分かる。
「Ｕｓｅｒ００４」はアクセス履歴が十分にあり、各Ｗｅｂページの重要度も計算済みである。そのため「Ｕｓｅｒ９９９」の重要度として「Ｕｓｅｒ００４」の重要度を代わりに使用して、エラー深刻度を計算することで、アクセス履歴が十分にないユーザーに対しても、Ｗｅｂページの重要度を考慮した通知判定を実施することができる。
この例では、類似のユーザーを１名のみとしたが、複数名抽出して統計的値（平均値、中央値、最頻値等）を取るようにしてもよい。

＜＜第４の実施の形態＞＞
図２９は、第４の実施の形態の構成例についての概念的なモジュール構成図である。
情報処理装置２９００は、アクセス履歴記録モジュール１１０、アクセス履歴記憶モジュール１２０、エラー検知モジュール１３０、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、エラー通知判定モジュール１６０、エラー通知モジュール１７０、通知履歴記憶モジュール２９７０を有している。
エラー通知判定モジュール１６０は、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、エラー通知モジュール１７０、通知履歴記憶モジュール２９７０と接続されている。エラー通知判定モジュール１６０は、ユーザーアクセス監視モジュール１４０に対してクリア１６２の処理を行い、エラー深刻度計算モジュール１５０から計算結果１５４を受け取り、通知履歴記憶モジュール２９７０に対して参照２９６６の処理を行い、エラー通知モジュール１７０に対して起動１６４の処理を行う。エラー通知判定モジュール１６０は、担当者毎に予め定められた通知回数、現在までの通知回数、現在の時刻に応じて、通知を行うか否かを判断するための閾値を決定する。そして、その閾値を用いて、エラー通知モジュール１７０にエラー通知を行わせるか否かを制御する。具体的には、通知要否の判定を、現在の単位時間当たりの通知量を考慮して判定するものである。運用担当者にとって適切な量の通知を行うようにするためである。

通知履歴記憶モジュール２９７０は、エラー通知判定モジュール１６０と接続されている。通知履歴記憶モジュール２９７０は、例えば、エラー通知履歴テーブル３０００を記憶している。図３０は、エラー通知履歴テーブル３０００のデータ構造例を示す説明図である。エラー通知履歴テーブル３０００は、通知日時欄３０１０、対象ユーザーＩＤ欄３０２０、エラー発生ページ欄３０３０を有している。通知日時欄３０１０は、通知を行った日時を記憶している。対象ユーザーＩＤ欄３０２０は、通知先である対象ユーザーＩＤを記憶している。エラー発生ページ欄３０３０は、その通知において対象としたエラーが発生したＷｅｂページを記憶している。つまり、エラー通知履歴テーブル３０００は、エラー通知モジュール１７０が行ったエラー通知の履歴を記憶する領域である。

図３１は、第４の実施の形態による処理例を示すフローチャートである。
ステップＳ３１０２では、判定閾値をシステム設定から取得する。
ステップＳ３１０４では、現在時間として、現在日時の時間を０〜２３で取得する。
ステップＳ３１０６では、現在通知数を本日の通知履歴の件数とする。
ステップＳ３１０８では、通知可能数をシステム設定から取得する。
ステップＳ３１１０では、「新しい判定閾値」を計算する。
ステップＳ３１１２では、「新しい判定閾値」をシステムに反映する。

以下、具体例を用いて説明する。
通知要否の判定を、現在の単位時間当たりの通知量を考慮して判定する例について説明する。
通知を実施すべきかの判定に使用している閾値は、前述の実施の形態では予め設定した固定値を使用している。この場合、日によっては多くのアクセスがありエラーが発生している場合、運用担当者が対応できない量の通知が送信されてしまう可能性がある。また、逆に、深刻なエラーがほとんど発生していない場合、運用担当者の手が空いてしまう場合もある。
このような事態に対応するため、第４の実施の形態では、運用担当者の負荷を考慮して通知判定に使用する閾値を動的に変更することを実施する。
この説明では、午前中の通知数が少なく、午後に通知が増えるように閾値を変える場合を用いる。
上記を実現するために、まず運用担当者が１日当たりに対応可能な通知数を設定する。この例では「１０」と設定する。
１２：００時点で、本日中の通知履歴が「３件」であったと仮定する。
残り１２時間も同じペースで通知が実施されると仮定した場合、この日の通知は「６件」となり、１日に処理可能な通知数を大幅に下回ってしまう。
そこで通知判定に使用する閾値を減少させ、普段は通知しないエラーを運用担当者に通知するようにする。
第４の実施の形態では、閾値と単位時間当たりの通知数が反比例すると仮定して、新しい閾値を算出する。
具体的には、式（１）で算出する。

前述の例では、
３＊（２４−１２）＊３／（１２＊（１０−３））＝９／７＝１．２８６
結果は「１．２８６」となる
運用担当者に適切な量の通知を実施させるために、この閾値を次回の通知判定に使用する。
なお、この式では、２４時間態勢としているが、その他の勤務時間内での式としてもよい。つまり、担当者毎に予め定められた対応可能な通知数、実績としての現在までの通知回数、現在の時刻（経過時間、これは、残りの時間をも意味する）を用いて、通知を行うか否かを判断するための閾値を変更すればよい。

＜＜第５の実施の形態＞＞
図３２は、第５の実施の形態の構成例についての概念的なモジュール構成図である。
情報処理装置３２００は、アクセス履歴記録モジュール１１０、アクセス履歴記憶モジュール１２０、エラー検知モジュール１３０、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、エラー通知判定モジュール１６０、エラー通知モジュール１７０、ページ別エラー影響度記憶モジュール１１６０、ユーザー別ページ重要度計算モジュール１７１０、ユーザー別ページ重要度記憶モジュール１７２０、ユーザー情報記憶モジュール１７３０、通知履歴記憶モジュール２９７０を有している。前述の各種の実施の形態を組み合わせたものである。もちろんのことながら、第２の実施の形態と第３の実施の形態との組み合わせであってもよいし、第２の実施の形態と第４の実施の形態との組み合わせであってもよいし、第３の実施の形態と第４の実施の形態との組み合わせであってもよい。

なお、本実施の形態としてのプログラムが実行されるコンピュータのハードウェア構成は、図３３に例示するように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバーとなり得るコンピュータ等である。つまり、具体例として、処理部（演算部）としてＣＰＵ３３０１を用い、記憶装置としてＲＡＭ３３０２、ＲＯＭ３３０３、ＨＤ３３０４を用いている。ＨＤ３３０４として、例えばハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）を用いてもよい。アクセス履歴記録モジュール１１０、エラー検知モジュール１３０、ユーザーアクセス監視モジュール１４０、エラー深刻度計算モジュール１５０、エラー通知判定モジュール１６０、エラー通知モジュール１７０、ユーザー別ページ重要度計算モジュール１７１０等のプログラムを実行するＣＰＵ３３０１と、そのプログラムやデータを記憶するＲＡＭ３３０２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ３３０３と、アクセス履歴記憶モジュール１２０、ページ別エラー影響度記憶モジュール１１６０、ユーザー別ページ重要度記憶モジュール１７２０、ユーザー情報記憶モジュール１７３０、通知履歴記憶モジュール２９７０としての機能を有する補助記憶装置（フラッシュメモリ等であってもよい）であるＨＤ３３０４と、キーボード、マウス、タッチパネル、マイク等に対するユーザーの操作に基づいてデータを受け付ける受付装置３３０６と、ＣＲＴ、液晶ディスプレイ、スピーカー等の出力装置３３０５と、ネットワークインタフェースカード等の通信ネットワークと接続するための通信回線インタフェース３３０７、そして、それらをつないでデータのやりとりをするためのバス３３０８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。

前述の実施の形態のうち、コンピュータ・プログラムによるものについては、本ハードウェア構成のシステムにソフトウェアであるコンピュータ・プログラムを読み込ませ、ソフトウェアとハードウェア資源とが協働して、前述の実施の形態が実現される。
なお、図３３に示すハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図３３に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続しているような形態でもよく、さらに図３３に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、携帯情報通信機器（携帯電話、スマートフォン、モバイル機器、ウェアラブルコンピュータ等を含む）、情報家電、ロボット、複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）などに組み込まれていてもよい。

また、前述の実施の形態の説明において、予め定められた値との比較において、「以上」、「以下」、「より大きい」、「より小さい（未満）」としたものは、その組み合わせに矛盾が生じない限り、それぞれ「より大きい」、「より小さい（未満）」、「以上」、「以下」としてもよい。

なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通等のために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラム又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、又は無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分であってもよく、又は別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して記録されていてもよい。また、圧縮や暗号化等、復元可能であればどのような態様で記録されていてもよい。

１００…情報処理装置
１１０…アクセス履歴記録モジュール
１２０…アクセス履歴記憶モジュール
１３０…エラー検知モジュール
１４０…ユーザーアクセス監視モジュール
１５０…エラー深刻度計算モジュール
１６０…エラー通知判定モジュール
１７０…エラー通知モジュール
２１０…ユーザー端末
２２０…担当者端末
２５０…サービス提供装置
２９０…通信回線
１１００…情報処理装置
１１６０…ページ別エラー影響度記憶モジュール
１７００…情報処理装置
１７１０…ユーザー別ページ重要度計算モジュール
１７２０…ユーザー別ページ重要度記憶モジュール
１７３０…ユーザー情報記憶モジュール
２９００…情報処理装置
２９７０…通知履歴記憶モジュール
３２００…情報処理装置

Claims (10)

1. Ｗｅｂページに関するエラーを検知する検知手段と、
   前記エラー後の利用者の操作による前記Ｗｅｂページへのアクセスを監視する監視手段と、
   前記監視手段による監視結果に応じて、前記エラーに対処する担当者への通知を行う通知手段
   を具備する情報処理装置。
2. 前記監視手段による監視結果に応じて、前記利用者における前記エラーの深刻度を算出する算出手段
   をさらに具備し、
   前記通知手段は、前記算出手段によって算出された深刻度が予め定められた閾値より多い又は以上である場合は、前記エラーに対処する担当者への通知を行う
   請求項１に記載の情報処理装置。
3. 前記算出手段は、前記Ｗｅｂページへのアクセスに関するエラーの回数に基づいて深刻度を算出する
   請求項２に記載の情報処理装置。
4. 前記監視手段は、前記Ｗｅｂページへのアクセスが成功した場合は、監視を中止する
   請求項１又は２に記載の情報処理装置。
5. 前記算出手段は、さらに予め定められたＷｅｂページへのアクセスがあったことに基づいて深刻度を算出する
   請求項２から４のいずれか一項に記載の情報処理装置。
6. 前記算出手段は、さらに前記利用者のＷｅｂページへのアクセス履歴に基づいて、前記エラーが発生したＷｅｂページの重要度を算出し、該重要度に基づいて深刻度を算出する
   請求項２から５のいずれか一項に記載の情報処理装置。
7. 前記算出手段は、予め定められた日にち、時間帯におけるアクセス履歴に基づいて、前記エラーが発生したＷｅｂページの重要度を算出する
   請求項６に記載の情報処理装置。
8. 前記算出手段は、前記利用者と類似する他の利用者における重要度を用いる
   請求項６又は７に記載の情報処理装置。
9. 前記通知手段は、前記担当者毎に予め定められた通知回数、現在までの通知回数、現在の時刻に応じて、通知を行うか否かを判断するための閾値を決定する
   請求項１から８のいずれか一項に記載の情報処理装置。
10. コンピュータを、
    Ｗｅｂページに関するエラーを検知する検知手段と、
    前記エラー後の利用者の操作による前記Ｗｅｂページへのアクセスを監視する監視手段と、
    前記監視手段による監視結果に応じて、前記エラーに対処する担当者への通知を行う通知手段
    として機能させるための情報処理プログラム。

Images