特許 7514405 異常判定システム、異常判定方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-07-02

(45)【発行日】2024-07-10

(54)【発明の名称】異常判定システム、異常判定方法、及びプログラム

(51)【国際特許分類】

   G06Q 10/06 20230101AFI20240703BHJP

【ＦＩ】

G06Q10/06

【請求項の数】 18

(21)【出願番号】P 2023577279

(86)(22)【出願日】2023-01-24

(86)【国際出願番号】 JP2023002139

【審査請求日】2023-12-13

【早期審査対象出願】

(73)【特許権者】

【識別番号】399037405

【氏名又は名称】楽天グループ株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】弁理士法人はるか国際特許事務所

(72)【発明者】

【氏名】長谷川 大地

(72)【発明者】

【氏名】西村 亮

(72)【発明者】

【氏名】藤井 大助

(72)【発明者】

【氏名】藤岡 健吾

【審査官】永野 一郎

(56)【参考文献】

【文献】特開２０１７－０３３２７５（ＪＰ，Ａ）

【文献】国際公開第２０１０／００１９６６（ＷＯ，Ａ１）

【文献】特開２０２２－１４４２０４（ＪＰ，Ａ）

【文献】特開２０２１－１３５５４１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得部と、
前記サービスの予定に関する予定データを取得する予定データ取得部と、
前記予定データに関する条件と、当該条件が満たされた場合の前記異常判定に関する異常判定基準と、の関係に基づいて、前記異常判定基準を決定し、当該決定された異常判定基準と、前記指標と、に基づいて、前記異常判定を実行する異常判定部と、
を含む異常判定システム。

【請求項2】

所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得部と、
前記サービスの予定に関する予定データを取得する予定データ取得部と、
前記予定データと、訓練用の前記予定データと前記異常判定に関する異常判定基準との関係が学習された学習モデルと、に基づいて、前記異常判定基準を決定し、当該決定された異常判定基準と、前記指標と、に基づいて、前記異常判定を実行する異常判定部と、
を含む異常判定システム。

【請求項3】

所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得部と、
前記サービスの予定に関する予定データを取得する予定データ取得部と、
前記指標と、訓練用の前記指標と前記異常の発生に関する異常判定結果との関係が学習された学習モデルと、に基づいて、前記異常判定を実行する異常判定部であって、前記予定データに基づいて、前記異常判定を実行するか否かを決定する異常判定部と、
を含む異常判定システム。

【請求項4】

複数のサービスを提供するためのサービス提供システムにおける前記複数のサービスの各々の異常の発生に関する異常判定で利用可能な指標を取得する指標取得部と、
前記複数のサービスの各々の予定に関する予定データを取得する予定データ取得部と、
前記複数のサービスの各々の前記予定データに基づいて、前記複数のサービスのうちの少なくとも１つの前記異常判定に関する異常判定基準を決定し、当該決定された異常判定基準と、前記複数のサービスの各々の前記指標と、に基づいて、前記異常判定を実行する異常判定部と、
を含む異常判定システム。

【請求項5】

前記予定データは、前記サービスに関するキャンペーンが開催されるキャンペーン時期を示し、
前記異常判定部は、前記指標と、前記予定データが示す前記キャンペーン時期と、に基づいて、前記異常判定を実行する、
請求項１～４の何れかに記載の異常判定システム。

【請求項6】

前記予定データは、前記サービスに関するメンテナンスが行われるメンテナンス時期を示し、
前記異常判定部は、前記指標と、前記予定データが示す前記メンテナンス時期と、に基づいて、前記異常判定を実行する、
請求項１～４の何れかに記載の異常判定システム。

【請求項7】

前記異常判定部は、過去の実績に基づく前記関係が学習された前記学習モデルに基づいて、前記異常判定基準を決定する、
請求項２に記載の異常判定システム。

【請求項8】

前記異常判定部は、過去の実績に基づく前記関係が学習された前記学習モデルに基づいて、前記異常判定を実行する、
請求項３に記載の異常判定システム。

【請求項9】

前記異常判定部は、前記異常判定の対象となる前記サービスごとに、当該サービスの前記指標及び前記予定と、前記複数のサービス全体の前記指標及び前記予定と、の関係に基づいて、前記異常判定を実行する、
請求項４に記載の異常判定システム。

【請求項10】

前記異常判定部は、前記異常判定の対象となる前記サービスごとに、当該サービスの前記指標及び前記予定と、他の前記サービスの前記指標及び前記予定と、の関係に基づいて、前記異常判定を実行する、
請求項４に記載の異常判定システム。

【請求項11】

コンピュータが、
所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得ステップと、
前記サービスの予定に関する予定データを取得する予定データ取得ステップと、
前記予定データに関する条件と、当該条件が満たされた場合の前記異常判定に関する異常判定基準と、の関係に基づいて、前記異常判定基準を決定し、当該決定された異常判定基準と、前記指標と、に基づいて、前記異常判定を実行する異常判定ステップと、
を実行する異常判定方法。

【請求項12】

コンピュータが、
所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得ステップと、
前記サービスの予定に関する予定データを取得する予定データ取得ステップと、
前記予定データと、訓練用の前記予定データと前記異常判定に関する異常判定基準との関係が学習された学習モデルと、に基づいて、前記異常判定基準を決定し、当該決定された異常判定基準と、前記指標と、に基づいて、前記異常判定を実行する異常判定ステップと、
を実行する異常判定方法。

【請求項13】

コンピュータが、
所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得ステップと、
前記サービスの予定に関する予定データを取得する予定データ取得ステップと、
前記指標と、訓練用の前記指標と前記異常の発生に関する異常判定結果との関係が学習された学習モデルと、に基づいて、前記異常判定を実行する異常判定ステップであって、前記予定データに基づいて、前記異常判定を実行するか否かを決定する異常判定ステップと、
を実行する異常判定方法。

【請求項14】

コンピュータが、
複数のサービスを提供するためのサービス提供システムにおける前記複数のサービスの各々の異常の発生に関する異常判定で利用可能な指標を取得する指標取得ステップと、
前記複数のサービスの各々の予定に関する予定データを取得する予定データ取得ステップと、
前記複数のサービスの各々の前記予定データに基づいて、前記複数のサービスのうちの少なくとも１つの前記異常判定に関する異常判定基準を決定し、当該決定された異常判定基準と、前記複数のサービスの各々の前記指標と、に基づいて、前記異常判定を実行する異常判定ステップと、
を実行する異常判定方法。

【請求項15】

所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得部、
前記サービスの予定に関する予定データを取得する予定データ取得部、
前記予定データに関する条件と、当該条件が満たされた場合の前記異常判定に関する異常判定基準と、の関係に基づいて、前記異常判定基準を決定し、当該決定された異常判定基準と、前記指標と、に基づいて、前記異常判定を実行する異常判定部、
としてコンピュータを機能させるためのプログラム。

【請求項16】

所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得部と、
前記サービスの予定に関する予定データを取得する予定データ取得部と、
前記予定データと、訓練用の前記予定データと前記異常判定に関する異常判定基準との関係が学習された学習モデルと、に基づいて、前記異常判定基準を決定し、当該決定された異常判定基準と、前記指標と、に基づいて、前記異常判定を実行する異常判定部と、
としてコンピュータを機能させるためのプログラム。

【請求項17】

所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得部、
前記サービスの予定に関する予定データを取得する予定データ取得部、
前記指標と、訓練用の前記指標と前記異常の発生に関する異常判定結果との関係が学習された学習モデルと、に基づいて、前記異常判定を実行する異常判定部であって、前記予定データに基づいて、前記異常判定を実行するか否かを決定する異常判定部、
としてコンピュータを機能させるためのプログラム。

【請求項18】

複数のサービスを提供するためのサービス提供システムにおける前記複数のサービスの各々の異常の発生に関する異常判定で利用可能な指標を取得する指標取得部と、
前記複数のサービスの各々の予定に関する予定データを取得する予定データ取得部と、
前記複数のサービスの各々の前記予定データに基づいて、前記複数のサービスのうちの少なくとも１つの前記異常判定に関する異常判定基準を決定し、当該決定された異常判定基準と、前記複数のサービスの各々の前記指標と、に基づいて、前記異常判定を実行する異常判定部、
としてコンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、異常判定システム、異常判定方法、及びプログラムに関する。

【背景技術】

【0002】

従来、システムにおける異常の発生に関する異常判定を実行する技術が知られている。例えば、特許文献１には、所定のサービスを提供するサービス提供システムにおけるコンピュータに関する負荷に基づいて、コンピュータが異常な動作をしているか否かを判定する技術が記載されている。特許文献１の技術では、コンピュータが異常な動作をしていると判定された場合に、コンピュータが所定の命令に応答するまでに要した時間である応答時間に基づいて、管理者に対し、異常が通知される。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１１－１５４４８３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１には、コンピュータの負荷の傾向に基づいて、異常判定基準を決定することも記載されている。しかしながら、コンピュータを利用したサービスにおいて、何らかの予定がある場合には、最適な異常判定基準が予定に応じて変わることがある。特許文献１の技術では、リアルタイムな傾向に応じて異常判定基準が決定されるので、予定に応じた柔軟な異常判定基準にすることはできない。この点は、特許文献１の技術以外の他の技術も同様である。このため、従来の技術では、異常判定の柔軟性を十分に高めることができなかった。

【0005】

本開示の目的の１つは、異常判定の柔軟性を高めることである。

【課題を解決するための手段】

【0006】

本開示に係る異常判定システムは、所定のサービスを提供するためのサービス提供システムにおける異常の発生に関する異常判定で利用可能な指標を取得する指標取得部と、前記サービスの予定に関する予定データを取得する予定データ取得部と、前記指標と、前記予定データと、に基づいて、前記異常判定を実行する異常判定部と、を含む。

【発明の効果】

【0007】

本開示によれば、異常判定の柔軟性を高まる。

【図面の簡単な説明】

【0008】

【図1】異常判定システムの全体構成の一例を示す図である。

【図2】異常判定システム及びサービス提供システムの概念の一例を示す図である。

【図3】異常判定で利用される業績指標の一例を示す図である。

【図4】第１実施形態の異常判定システムで実現される機能の一例を示す図である。

【図5】業績指標データベースの一例を示す図である。

【図6】第１実施形態の異常判定システムで実行される処理の一例を示す図である。

【図7】キャンペーンの開催時期と、通常の時期と、の各々における業績指標の一例を示す図である。

【図8】第２実施形態の異常判定システムで実現される機能の一例を示す図である。

【図9】予定データベースの一例を示す図である。

【図10】異常判定基準データベースの一例を示す図である。

【図11】第２実施形態の異常判定システムで実行される処理の一例を示す図である。

【図12】複数のサービス全体の業績指標に基づく異常判定の一例を示す図である。

【図13】あるサービスの業績指標と、他のサービスの業績指標と、の関係に基づく異常判定の一例を示す図である。

【図14】変形例１－４で実現される機能の一例を示す図である。

【発明を実施するための形態】

【0009】

［１．第１実施形態］
本開示に係る異常判定システムの実施形態の一例である第１実施形態を説明する。

【0010】

［１－１．異常判定システムの全体構成］
図１は、異常判定システムの全体構成の一例を示す図である。例えば、異常判定システム１は、インターネット又はＬＡＮ等のネットワークＮに接続可能である。ネットワークＮには、サービス提供システム２も接続可能である。ネットワークＮには、他のシステム又は端末が接続可能であってもよい。図１は、異常判定システム１及びサービス提供システム２がネットワークＮを介して接続される例について説明しているが、異常判定システム１がサービス提供システム２に含まれてもよい。このとき、異常判定システム１の管理者権限は、サービス提供システム２の管理者権限に含まれる。

【0011】

例えば、異常判定システム１は、異常判定サーバ１０及び管理者端末２０を含む。異常判定サーバ１０は、サーバコンピュータである。例えば、異常判定サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

【0012】

管理者端末２０は、異常判定システム１を管理する管理者のコンピュータである。例えば、管理者端末２０は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。例えば、管理者端末２０は、制御部２１、記憶部２２、通信部２３、操作部２４、及び表示部２５を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様である。操作部２４は、タッチパネル又はマウス等の入力デバイスである。表示部２５は、液晶又は有機ＥＬ等のディスプレイである。

【0013】

例えば、サービス提供システム２は、第１サーバ３０、第２サーバ４０、第３サーバ５０、及び共通サーバ６０を含む。第１サーバ３０、第２サーバ４０、第３サーバ５０、及び共通サーバ６０の各々のハードウェア構成は、異常判定サーバ１０と同様である。例えば、制御部３１，４１，５１，６１、記憶部３２，４２，５２，６２、及び通信部３３，４３，５３，６３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様である。サービス提供システム２は、クラウドインフラストラクチャ又はクラウドプラットフォームにおけるテナントと読み換えられ、異常判定システム１等のソフトウェア構成又はハードウェア構成を含むオファリングサービス群から選択される複数のオファリングサービスによって構成される。

【0014】

なお、記憶部１２，２２，３２，４２，５２，６２に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。また、各コンピュータには、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、メモリカードスロット）と、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）と、の少なくとも一方が含まれてもよい。例えば、情報記憶媒体に記憶されたプログラムが、読取部及び入出力部の少なくとも一方を介して供給されてもよい。

【0015】

また、異常判定システム１は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。例えば、異常判定システム１は、管理者端末２０を含まずに、異常判定サーバ１０だけを含んでもよい。異常判定システム１は、異常判定サーバ１０を含まずに、管理者端末２０だけを含んでもよい。異常判定システム１は、異常判定サーバ１０及び管理者端末２０以外の他のコンピュータを含んでもよい。

【0016】

［１－２．第１実施形態の概要］
例えば、サービス提供システム２は、少なくとも１つのサービスをユーザに提供する。第１実施形態では、第１サービス、第２サービス、及び第３サービスといった３つのサービスを例に挙げるが、サービス提供システム２は、１つのサービス、２つのサービス、又は４つ以上のサービスをユーザに提供してもよい。第１サーバ３０は、第１サービスのサーバコンピュータである。第２サーバ４０は、第２サービスのサーバコンピュータである。第３サーバ５０は、第３サービスのサーバコンピュータである。

【0017】

第１実施形態では、第１サービスが電子商取引サービスであり、第２サービスが決済サービスであり、第３サービスが金融サービスである場合を例に挙げるが、サービス提供システム２は、任意のサービスをユーザに提供可能である。サービス提供システム２がユーザに提供するサービスは、第１実施形態の例に限られない。例えば、サービス提供システム２は、通信サービス、旅行予約サービス、動画配信サービス、保険サービス、チケット予約サービス、又はその他のサービスをユーザに提供してもよい。

【0018】

例えば、サービス提供システム２が提供する複数のサービスで共通のポイントが利用可能であってもよい。あるサービスを利用して獲得したポイントが、このサービスだけではなく、他のサービスで利用可能であってもよい。サービス提供システム２は、ユーザが獲得したポイントを循環して利用できるような複数のサービスを提供してもよい。同じ事業者によって複数のサービスが提供されるようにしてもよいし、互いに異なる事業者によって複数のサービスが提供されるようにしてもよい。

【0019】

例えば、１つのサービス提供システム２によって複数のサービスが提供されるのではなく、複数のサービス提供システム２によって複数のサービスが提供されてもよい。１つのサービスを提供するために複数のサービス提供システム２が連携してもよい。サービス提供システム２と、サービスと、の関係は、１対１、１対多、多対１、又は多対多の何れであってもよい。サービス提供システム２は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。サービス提供システム２は、複数のコンピュータを含んでもよい。サービス提供システム２の数も、任意の数であってよい。

【0020】

異常判定システム１は、サービス提供システム２における異常判定を実行する。異常判定は、サービス提供システム２における異常の発生に関する判定である。例えば、異常が発生したか否かを判定すること、又は、異常の度合を示す異常スコアを計算することは、異常判定に相当する。異常スコアは、数値、文字、又はその他の記号で表現可能である。例えば、異常スコアが数値である場合、異常スコアが高いほど、異常の度合が高くなってもよい。逆に、異常スコアが低いほど、異常の度合が高くなってもよい。

【0021】

サービス提供システム２における異常とは、サービス提供システム２に含まれるハードウェア及びソフトウェアの少なくとも一方の異常を意味する。サービス提供システム２における異常は、ハードウェア及びソフトウェアの両方の異常を意味してもよいし、ハードウェアだけの異常又はソフトウェアだけの異常を意味してもよい。異常は、正常ではない状態ということもできる。例えば、障害が発生すること、又は、障害とまではいかないが注意すべき状態になることは、異常に相当する。

【0022】

例えば、異常判定システム１は、サービス提供システム２に含まれるハードウェアを異常判定の対象にする。異常判定の対象となるハードウェアは、任意の種類であってよい。例えば、異常判定の対象となるハードウェアは、サーバコンピュータ、パーソナルコンピュータ、タブレット、スマートフォン、ネットワーク機器、ネットワークケーブル、情報記憶媒体、バッテリー、電源コード、センサ、カメラ、カードリーダ、リーダライタ、ディスプレイ、プリンタ、その他の周辺機器、又はこれらの組み合わせであってもよい。例えば、ハードウェアの負荷が高まること、ハードウェアが故障すること、ハードウェアが意図しない動作をすること、ハードウェアが動作しないこと、ハードウェアが外部の機器と通信できないこと、又はハードウェアの電源が意図しない時に切れることは、異常に相当する。

【0023】

例えば、異常判定システム１は、サービス提供システム２に含まれるソフトウェアを異常判定の対象にする。異常判定の対象となるソフトウェアは、任意の種類であってよい。例えば、異常判定の対象となるソフトウェアは、オペレーティングシステム、決済を実行するためのプログラム、商品の注文を受け付けるためのプログラム、施設の予約を受け付けるためのプログラム、チケットの予約を受け付けるためのプログラム、サービスへの会員登録を受け付けるためのプログラム、サービスを提供するために実行されるその他のプログラム、データベースを参照するプログラム、ＡＰＩ、又はこれらの組み合わせであってもよい。例えば、正常時よりもソフトウェアの動作に時間がかかること、ソフトウェアの動作が停止すること、ソフトウェアが終了しないこと、ソフトウェアがその他のエラーになること、ソフトウェアが起動しないこと、又はデータベースを更新できないことは、異常に相当する。

【0024】

図２は、異常判定システム１及びサービス提供システム２の概念の一例を示す図である。実際には、異常判定システム１及びサービス提供システム２に含まれる種々のハードウェア（仮想的なものも含む）及びソフトウェアによって、複数のサービスの各々がユーザに提供されるが、概念としては、クラウド化された１つのシステムによって、種々のサービスがユーザに提供されるものとする。このため、概念としては、異常判定システム１及びサービス提供システム２を包含する１つのクラウドシステムによって、種々のサービスがユーザに提供される。

【0025】

例えば、サービス提供システム２は、第１サーバ３０により実現される第１サービスのＡＰＩ、第２サーバ４０により実現される第２サービスのＡＰＩ、及び第３サーバ５０により実現される第３サービスのＡＰＩを含む。第１実施形態では、決済サービスである第２サービスと、金融サービスである第３サービスと、がフィンテックサービスという意味では互いに同じなので、共通のプラットフォームが利用される。プラットフォームは、共通サーバ６０に含まれるハードウェア及びソフトウェアの少なくとも一方である。

【0026】

例えば、第１サービス、第２サービス、及び第３サービスは、互いに共通の共通ＡＰＩを利用する。例えば、共通ＡＰＩは、第１サービス、第２サービス、及び第３サービスの各々で共通のポイントを利用するためのＡＰＩであってもよい。このＡＰＩは、共通サーバ６０により実現される。例えば、共通ＡＰＩによって提供される共通サービスは、第１サービス、第２サービス、及び第３サービスの各々で共通のポイントを利用するためのサービスであってもよい。共通サービスは、共通サーバ６０により提供される。サービス提供システム２は、その他のサービスを提供する構成を含んでもよいし、サービス提供システム２の通信を制御するための物理層等の種々の層を含んでもよい。

【0027】

例えば、サービス提供システム２は、第１サーバ３０、第２サーバ４０、第３サーバ５０、及び共通サーバ６０といったハードウェアを含む。ハードウェアは、サービスを提供するために利用されるものであればよく、サーバコンピュータに限られない。例えば、ハードウェアは、先述したネットワーク機器等の他のハードウェアを含んでもよい。ハードウェアは、物理的なものに限られず、仮想的な構成を意味してもよい。例えば、ハードウェアは、コンテナ又はバーチャルマシンも含む意味である。これらの仮想的な構成は、ハードウェアではなく、ソフトウェアに分類されてもよい。

【0028】

従来の技術として、サービス提供システム２の異常判定で利用される指標として、レイテンシ、エラー、トラフィック、及びサチュレーションの少なくとも１つを利用する技術が知られている。レイテンシは、サービスに対するリクエストの処理時間（レスポンスタイム）である。エラーは、リクエストに対して返されたエラーの数である。トラフィックは、単位時間あたりのサービスの使用量（例えば、リクエスト数）である。サチュレーションは、サービス提供システム２におけるリソースの消費度合である。これら４つの指標は、ゴールデンシグナルメトリクスと呼ばれることもある。

【0029】

第１実施形態では、異常判定システム１は、サービス提供システム２における異常の発生に関する異常判定を実行するために、サービスの業績に関する業績指標を取得する。業績指標は、ビジネス的な観点で業績を評価するための指標である。業績指標は、業績評価指標又は重要業績評価指標と呼ばれることもある。例えば、業績指標は、決済数、決済額、注文数、利用数、新規ユーザ数、アクティブユーザ数、アクセス数、ログイン数、又はこれらの組み合わせである。図２のように、異常判定システム１は、サービスにおけるログを取得したり、管理者にアラートを通知したりすることもできる。

【0030】

図３は、異常判定で利用される業績指標の一例を示す図である。図３の縦軸は、業績指標を示す軸である。図３の横軸は、時間を示す軸である。図３では、単位時間あたりのサービス全体の決済額が業績指標に相当する場合を例に挙げる。第１実施形態では、単位時間を１分とするが、単位時間は、予め定められた長さであればよく、第１実施形態の例に限られない。例えば、１分未満、数分～１時間、数時間～１日、又は他の長さであってもよい。単位時間は、管理者によって指定されてもよいし、サービスによって異なってもよい。

【0031】

図３の例では、横軸における現時点は、直近の１分間を意味する。第１サービスの業績指標の時系列的な変化を実線で示す。第２サービスの業績指標の時系列的な変化を点線で示す。第３サービスの業績指標の時系列的な変化を破線で示す。例えば、異常判定サーバ１０は、単位時間ごとに、第１サーバ３０、第２サーバ４０、及び第３サーバ５０の各々と通信することによって、第１サービス、第２サービス、及び第３サービスの各々の業績指標を取得する。

【0032】

図３の上側の例では、現時点の少し前から、第１サービスの業績指標が急激に低下し、低い業績指標のまま推移している。一方で、第２サービスの業績指標と、第３サービスの業績指標と、は安定した値のまま変化がない。この場合、第１サービスの業績指標だけが急激に低下しているので、第１サービスだけで決済を受け付けにくい可能性がある。例えば、第２サーバ４０及び第３サーバ５０には異常が発生しておらず、第１サーバ３０にだけ異常が発生している可能性がある。

【0033】

この場合、図３の下側のように、管理者端末２０の表示部２５には、第１サービスで異常が発生している可能性を示す管理者画面ＳＣが表示される。管理者画面ＳＣには、第１サービス、第２サービス、及び第３サービスの各々の現時点の業績指標及び通常の業績指標が表示される。通常の業績指標とは、異常判定の基準となる業績指標である。例えば、通常の業績指標は、過去の一定期間における業績指標の平均値、過去の同じ時期における業績指標、又は管理者が手動で定めた値であってもよい。

【0034】

例えば、現時点の業績指標と、通常の業績指標と、の差が閾値以上になった場合に、異常が発生したと判定されるものとする。通常の業績指標は、過去の実績から計算されてもよいし、管理者が指定してもよい。図３の例では、第１サービスの現時点の業績指標だけが急激に低下しているので、管理者画面ＳＣでは、第１サービスで異常が発生している可能性を示すメッセージが表示される。

【0035】

第１実施形態では、ゴールデンシグナルメトリクス等の公知の指標では異常が検出されていなくても、業績指標で異常が発生していれば、管理者に対し、何らかの通知が行われる。例えば、管理者がボタンＢ１を選択すると、第１サーバ３０の状態をチェックするための画面に遷移する。この画面では、第１サーバ３０のハードウェア及びソフトウェアの少なくとも一方の動作を確認できる。この画面自体は、公知のメンテナンスツールであってよい。管理者は、この画面から、第１サービスの現時点の業績指標だけが急激に低下した原因を解析する。管理者は、第１サーバ３０の状態をチェックし、必要に応じて、第１サーバ３０のメンテナンスを行う。

【0036】

例えば、第２サービスの業績指標、第３サービスの業績指標、又は全てのサービスに共通する業績指標と、通常の業績指標と、の差が閾値以上になった場合も、異常が発生したことを示す管理者画面ＳＣが表示部２５に表示される。管理者は、ボタンＢ２～Ｂ４の何れかを選択し、第２サーバ４０、第３サーバ５０、又は共通サーバ６０の状態をチェックする。例えば、ゴールデンシグナルメトリクス等の公知の指標では、ある程度の異常が発生していたとしても、業績指標に異常が発生していなければ、メッセージが表示されなかったり、業績指標に異常が発生していないため、対応を後回しにしてもよい旨のメッセージが表示されたりしてもよい。

【0037】

以上のように、第１実施形態では、第１サービス、第２サービス、及び第３サービスの各々の業績指標に基づいて、サービス提供システム２における異常判定が実行される。これにより、従来の技術では特定できないような異常を判定可能になるので、異常判定の精度が高まる。例えば、ゴールデンシグナルメトリクスでは検出できないような異常を、ビジネス的な観点で判定できるので、異常判定の精度が高まる。以降、第１実施形態の詳細を説明する。

【0038】

［１－３．第１実施形態の異常判定システムで実現される機能］
図４は、第１実施形態の異常判定システム１で実現される機能の一例を示す図である。

【0039】

［１－３－１．異常判定サーバで実現される機能］
異常判定サーバ１０は、データ記憶部１００、指標取得部１０１、及び異常判定部１０２を含む。データ記憶部１００は、記憶部１２により実現される。指標取得部１０１及び異常判定部１０２は、制御部１１により実現される。

【0040】

［データ記憶部］
データ記憶部１００は、異常判定に必要なデータを記憶する。例えば、データ記憶部１００は、業績指標データベースＤＢ１を記憶する。

【0041】

図５は、業績指標データベースＤＢ１の一例を示す図である。業績指標データベースＤＢ１は、サービスの業績指標が格納されたデータベースである。例えば、業績指標データベースＤＢ１は、サービスＩＤ、異常判定の実行日時、当該実行日時に取得された業績指標、及び異常判定の実行結果が格納される。業績指標データベースＤＢ１には、任意の情報が格納されてよい。業績指標データベースＤＢ１に格納される情報は、図５の例に限られない。

【0042】

サービスＩＤは、サービスを識別可能なサービス識別情報の一例である。サービス識別情報は、任意の情報であってよく、サービスＩＤに限られない。例えば、サービス識別情報は、サービスの名前、又は、サービスを提供する会社の名前であってもよい。期間は、異常判定の対象となる期間である。第１実施形態では、期間の長さが１日である場合を説明するが、期間は、任意の長さであってよい。例えば、期間の長さは、１０秒～３０分程度、１時間～半日程度、数日～１週間程度、又は他の長さであってもよい。

【0043】

業績指標は、後述の業績指標取得部１０１Ａによって取得される。業績指標の具体例は、先述した通りである。第１実施形態では、１分ごとに異常判定が実行されるので、１分ごとに、業績指標が取得されて業績指標データベースＤＢ１に格納される。異常判定の実行結果は、後述の異常判定部１０２による異常判定の実行結果である。図５の例では、異常判定結果は、正常であることを意味する第１の値、又は、異常であることを意味する第２の値の何れかを示す。異常判定結果は、これらの２値ではなく、中間値が存在してもよい。例えば、異常判定結果は、先述した異常スコアであってもよい。

【0044】

なお、データ記憶部１００に記憶されるデータは、業績指標データベースＤＢ１に限られない。データ記憶部１００は、異常判定に必要なデータを記憶すればよく、任意のデータを記憶可能である。例えば、データ記憶部１００は、異常判定基準を記憶してもよい。第１実施形態では、サービスごとに、業績指標との比較対象となる基準である異常判定基準が定められているものとする。例えば、データ記憶部１００は、第１サービスの異常判定基準、第２サービスの異常判定基準、及び第３サービスの異常判定基準を記憶してもよい。例えば、異常判定基準は、異常判定で利用される閾値を含む。

【0045】

［指標取得部］
指標取得部１０１は、所定のサービスを提供するためのサービス提供システム１における異常の発生に関する異常判定で利用可能な指標を取得する。この指標は、異常判定の際に参照される情報である。例えば、異常判定基準と比較される情報が指標に相当する。第１実施形態では、指標の一例として業績指標を説明する。指標取得部１０１は、業績指標取得部１０１Ａを含む。業績指標以外の他の指標が利用されない場合には、業績指標取得部１０１Ａを上位概念化した指標取得部１０１が存在しなくてもよい。

【0046】

業績指標取得部１０１Ａは、所定のサービスを提供するためのサービス提供システム２に関する利用状況に基づいて、サービスの業績に関する業績指標を取得する。利用状況とは、サービスが利用されている度合である。例えば、決済の実行結果（例えば、決済額、支払先、決済日時、及びエラー数）、注文の受付結果（例えば、商品の価格、注文を受け付けた店舗、及び注文日時）、予約の受付結果（例えば、予約された施設、利用量、及び予約日時）、新規ユーザによる会員登録の結果、サービスに対するアクセス履歴、サービスに対するログイン履歴は、利用状況に相当する。

【0047】

例えば、動画配信サービスであれば、ストリーミング配信の視聴者数は、利用状況に相当する。何らかのイベントを開催するサービスであれば、イベントへのエントリー数は、利用状況に相当する。クーポンを配信するサービスであれば、クーポンの取得率は、利用状況に相当する。ポイントを利用可能にするサービスであれば、ポイントが付与された量、又は、ポイントが利用された量は、利用状況に相当する。コールセンターサービスであれば、オペレータに対する電話の量は、利用状況に相当する。ユーザが何らかの利用をした場合に実行される不正検知サービスであれば、不正が検知された量は、利用状況に相当する。ＳＮＳであれば、投稿数は、利用状況に相当する。他のサービスも同様に、サービスに応じた利用状況が取得されてよい。

【0048】

第１実施形態のサービス提供システム１は、複数のサービスを提供するためのシステムである。このため、業績指標取得部１０１Ａは、複数のサービスの各々の業績指標を取得する。例えば、業績指標取得部１０１Ａは、第１サービス、第２サービス、及び第３サービスの各々の業績指標を取得する。例えば、業績指標取得部１０１Ａは、第１サーバ３０から、第１サービスの利用状況を取得する。業績指標取得部１０１Ａは、第１サービスの利用状況に基づいて、第１サービスの業績指標を取得する。

【0049】

例えば、業績指標取得部１０１Ａは、第２サーバ４０から、第２サービスの利用状況を取得する。業績指標取得部１０１Ａは、第２サービスの利用状況に基づいて、第２サービスの業績指標を取得する。例えば、業績指標取得部１０１Ａは、第３サーバ５０から、第３サービスの利用状況を取得する。業績指標取得部１０１Ａは、第３サービスの利用状況に基づいて、第３サービスの業績指標を取得する。第１実施形態では、業績指標取得部１０１Ａが共通サーバ６０からは利用状況を受信しないものとするが、業績指標取得部１０１Ａは、共通サーバ６０から、第１サービス、第２サービス、及び第３サービスの各々の利用状況を取得してもよい。

【0050】

第１実施形態では、業績指標取得部１０１Ａが、稼働中のサービスの業績指標をリアルタイムで取得する場合を説明する。稼働中とは、サービスの提供中である。例えば、第１サーバ３０、第２サーバ４０、及び第３サーバ５０の各々が、ユーザが操作するユーザ端末と何らかの通信をしたり、ユーザ端末から受信したユーザの要求に応じた処理を実行したりすることは、稼働中であることに相当する。即ち、第１サービス、第２サービス、及び第３サービスの各々の利用状況が更新中であることは、稼働中であることに相当する。

【0051】

リアルタイムとは、現時点又は直近の期間を意味する。直近の期間は、現時点の所定時間前の時点から現時点までの期間である。直近の期間は、業績指標データベースＤＢ１に業績指標が格納される期間のうち、最も新しい期間ということもできる。第１実施形態では、異常判定の単位時間が１分なので、業績指標取得部１０１Ａは、１分ごとに、現時点の１分前から現時点までの業績指標を取得する。例えば、業績指標取得部１０１Ａは、１分ごとに、第１サーバ３０、第２サーバ４０、及び第３サーバ５０の各々から最新の利用状況を取得し、第１サービス、第２サービス、及び第３サービスの各々の業績指標を取得する。

【0052】

なお、業績指標取得部１０１Ａは、リアルタイムではなく、ある程度過去の業績指標を取得してもよい。例えば、業績指標取得部１０１Ａは、直近の期間よりも過去の期間における業績指標を取得してもよい。業績指標取得部１０１Ａは、予め作成されたシミュレータによって将来の業績指標を予測し、将来の業績指標を取得してもよい。例えば、シミュレータは、現時点が属する時期と、その時期の過去の実績値に基づく将来の業績指標と、の関係が定義されている。この関係は、数式、テーブル、プログラムコードの一部、又は機械学習の手法を利用したモデルに定義されているものとする。

【0053】

第１実施形態では、業績指標取得部１０１Ａは、業績指標として、サービスにおける決済に関する決済指標を取得する場合を例に挙げる。決済指標は、決済の実行状況を示す指標である。例えば、決済指標は、決済額、決済額の合計値、決済額の平均値、決済回数、支払先、決済日時、又はこれらの組み合わせである。図３の例では、第１サービス、第２サービス、及び第３サービスにおける１分あたりの決済額の合計値が決済指標に相当する。

【0054】

例えば、業績指標取得部１０１Ａは、第１サーバ３０から、第１サービスにおける決済の実行状況を取得する。業績指標取得部１０１Ａは、第１サービスにおける決済の実行状況に基づいて、第１サービスの決済指標を取得する。図３の例であれば、業績指標取得部１０１Ａは、１分ごとに、その１分間に実行された第１サービスの決済における決済額の合計値である決済指標を取得する。業績指標取得部１０１Ａは、第２サービス及び第３サービスも同様にして、１分ごとに、その１分間における決済指標を取得する。

【0055】

なお、業績指標は、上記のような合計値ではなく、平均値、中央値、又は最頻値といった他の値であってもよい。これらの計算は、第１サーバ３０、第２サーバ４０、及び第３サーバ５０側で実行されてもよい。この場合、利用状況と業績指標は同じものであってもよい。業績指標取得部１０１Ａは、第１サーバ３０、第２サーバ４０、及び第３サーバ５０から受信した利用状況を、業績指標として取得してもよい。決済額以外の他の業績指標についても同様に、業績指標取得部１０１Ａは、利用状況の合計値等を計算することによって、業績指標を取得してもよいし、受信した利用状況をそのまま業績指標として取得してもよい。

【0056】

また、第１サーバ３０，第２サーバ４０、及び第３サーバ５０の各々は、自身が提供するサービスの利用状況に関する利用状況データベースを記憶しているものとする。第１サーバ３０，第２サーバ４０、及び第３サーバ５０の各々は、あるユーザがサービスを利用した場合（例えば、決済が実行された場合）に、このユーザがサービスを利用したことを示す利用状況を利用状況データベースに格納する。第１サーバ３０，第２サーバ４０、及び第３サーバ５０の各々は、異常判定サーバ１０からの要求に応じて、利用状況データベースに格納された利用状況のうち、任意の期間（第１実施形態では、直近１分間）の利用状況を異常判定サーバ１０に送信する。業績指標取得部１０１Ａは、この利用状況に基づいて、業績指標を取得すればよい。

【0057】

［異常判定部］
異常判定部１０２は、指標取得部１０１により取得された指標に基づいて、サービス提供システム１における異常判定を実行する。第１実施形態では、この指標として業績指標が利用されるので、異常判定部１０２は、業績指標取得部１０１Ａにより取得された業績指標に基づいて、サービス提供システム１における異常判定を実行する。第１実施形態では、異常判定基準を利用した異常判定を例に挙げるが、異常判定の実行方法は、第１実施形態の例に限られない。後述の変形例のように、異常判定基準ではなく、機械学習の手法が利用されてもよい。

【0058】

例えば、異常判定部１０２は、業績指標が所定の異常判定基準を満たすか否かを判定することによって、異常判定を実行する。異常判定基準は、異常判定のために定められた基準である。異常判定基準は、当該異常判定基準が満たされた場合に異常となるように定められるものとする。例えば、異常判定基準は、少なくとも１つの閾値を含む。第１実施形態では、業績指標が閾値未満になることが、異常が発生することに相当する場合を例に挙げるが、業績指標が閾値以上になることが、異常が発生することに相当してもよい。他にも例えば、業績指標と閾値を比較するのではなく、業績指標の変化量が閾値以上であるか否かを判定することによって、異常判定が実行されてもよい。

【0059】

第１実施形態では、異常判定部１０２は、複数のサービスの各々の業績指標に基づいて、複数のサービスのうちの少なくとも１つの異常判定を実行する。例えば、異常判定部１０２は、第１サービスの業績指標に基づいて、第１サービスの異常判定を実行する。異常判定部１０２は、第２サービスの業績指標に基づいて、第２サービスの異常判定を実行する。異常判定部１０２は、第３サービスの業績指標に基づいて、第３サービスの異常判定を実行する。

【0060】

第１実施形態では、業績指標を取得元になったサービスと、異常判定の対象となるサービスと、が同じである場合を説明するが、これらは異なってもよい。例えば、異常判定部１０２は、第１サービスの業績指標に基づいて、第２サービス又は第３サービスの異常判定を実行してもよい。異常判定部１０２は、第２サービスの業績指標に基づいて、第１サービス又は第３サービスの異常判定を実行する。異常判定部１０２は、第３サービスの業績指標に基づいて、第１サービス又は第２サービスの異常判定を実行する。

【0061】

他にも例えば、異常判定部１０２は、第１サービスの業績指標と、第２サービス及び第３サービスの少なくとも一方の業績指標と、に基づいて、第１サービスの異常判定を実行してもよい。異常判定部１０２は、第２サービスの業績指標と、第１サービス及び第３サービスの少なくとも一方の業績指標と、に基づいて、第２サービスの異常判定を実行してもよい。異常判定部１０２は、第３サービスの業績指標と、第１サービス及び第２サービスの少なくとも一方の業績指標と、に基づいて、第１サービスの異常判定を実行してもよい。

【0062】

第１実施形態では、異常判定部１０２は、リアルタイムで取得された業績指標に基づいて、異常判定をリアルタイムで実行する。リアルタイムの意味は、先述した通りである。異常判定部１０２は、リアルタイムではなく、ある程度過去における異常判定を実行してもよい。例えば、異常判定部１０２は、直近の期間よりも過去の期間における異常判定を実行してもよい。逆に、異常判定部１０２は、シミュレータによって取得された将来の業績指標に基づいて、将来の異常判定を実行してもよい。

【0063】

第１実施形態では、決済指標が業績指標に相当するので、異常判定部１０２は、決済指標に基づいて、異常判定を実行する。例えば、異常判定部１０２は、決済指標が異常判定基準を満たすか否かを判定することによって、異常判定を実行する。異常判定部１０２は、決済指標に基づいて、予め定められた異常判定基準が満たされるか否かを判定することによって、異常判定を実行する。例えば、異常判定部１０２は、異常判定基準が満たされると判定された場合に、異常が発生したことを示す判定結果を出力する。逆に、異常判定部１０２は、異常判定基準が満たされないと判定された場合に、異常が発生したことを示す判定結果を出力してもよい。何れの処理が実行されるかは、どのように異常判定基準を定めておくかによる。

【0064】

図３の例であれば、異常判定部１０２は、１分ごとに、当該１分間における第１サービスの決済指標が、第１サービスに定められた異常判定基準を満たすか否かを判定する。例えば、異常判定部１０２は、当該決済指標が、当該異常判定基準が示す閾値以上である場合には、異常が発生していないことを示す判定結果を出力する。異常判定部１０２は、当該決済指標が、当該異常判定基準が示す閾値未満である場合には、異常が発生したことを示す判定結果を出力する。異常判定部１０２は、第２サービス及び第３サービスについても同様にして、異常判定を実行する。

【0065】

なお、異常判定部１０２は、異常判定部１０２は、１分ごとに、当該１分間における第１サービスの決済指標が、第１サービスに定められた異常判定基準が示す閾値未満である場合には、異常が発生していないことを示す判定結果を出力してもよい。異常判定部１０２は、当該決済指標が、当該異常判定基準が示す閾値以上である場合には、異常が発生したことを示す判定結果を出力してもよい。異常判定部１０２は、第２サービス及び第３サービスについても同様にして、異常判定を実行してもよい。

【0066】

［１－３－２．管理者端末で実現される機能］
例えば、管理者端末２０は、データ記憶部２００、操作受付部２０１、及び表示制御部２０２を含む。データ記憶部２００は、記憶部２２を主として実現される。操作受付部２０１及び表示制御部２０２は、制御部２１を主として実現される。

【0067】

［データ記憶部］
データ記憶部２００は、管理者の業務に必要なデータを記憶する。例えば、データ記憶部２００は、管理者画面ＳＣを表示するために必要なデータを記憶する。データ記憶部２００は、管理者の業務に必要なメンテナンスツールを記憶してもよい。メンテナンスツール自体は、公知のツールであってよく、例えば、ハードウェア及びソフトウェアの少なくとも一方の状態を監視可能なツールであればよい。

【0068】

［操作受付部］
操作受付部２０１は、管理者による各種操作を受け付ける。例えば、操作受付部２０１は、管理者画面ＳＣに対する操作を受け付ける。

【0069】

［表示制御部］
表示制御部２０２は、各種画面を表示部２５に表示させる。例えば、表示制御部２０２は、管理者画面ＳＣを表示部２５に表示させる。表示制御部２０２は、管理者がボタンＢ１～Ｂ４の何れかを選択した場合に、第１サーバ３０、第２サーバ４０、第３サーバ５０、及び共通サーバ６０のうちの何れかの状態を表示部２５に表示させる。

【0070】

［１－４．第１実施形態の異常判定システムで実行される処理］
図６は、第１実施形態の異常判定システム１で実行される処理の一例を示す図である。制御部１１，２１が、それぞれ記憶部１２，２２に記憶されたプログラムを実行することによって、図６の処理が実行される。図６のように、異常判定サーバ１０は、単位時間である１分が経過したか否かを判定する（Ｓ１００）。Ｓ１００では、異常判定サーバ１０は、前回の異常判定から１分が経過したか否かを判定する。１分が経過したと判定されない場合（Ｓ１００：Ｎ）、再びＳ１００の処理に戻る。

【0071】

Ｓ１００において、１分が経過したと判定された場合（Ｓ１００：Ｙ）、異常判定サーバ１０は、第１サーバ３０、第２サーバ４０、及び第３サーバ５０の各々から、第１サービス、第２サービス、及び第３サービスの各々の利用状況を取得する（Ｓ１０１）。Ｓ１０１で取得される利用状況には、直近の１分間で実行された全ての決済の決済額が含まれる。第１サーバ３０、第２サーバ４０、及び第３サーバ５０の各々は、決済額の合計値を計算したうえで、異常判定サーバ１０に対し、利用状況として送信してもよい。

【0072】

異常判定サーバ１０は、第１サービス、第２サービス、及び第３サービスの各々の利用状況に基づいて、第１サービス、第２サービス、及び第３サービスの各々の業績指標を取得する（Ｓ１０２）。Ｓ１０２では、異常判定サーバ１０は、サービスごとに、直近の１分間で実行された決済の決済額の合計値を計算し、当該サービスの業績指標として取得する。

【0073】

異常判定サーバ１０は、第１サービス、第２サービス、及び第３サービスの各々の業績指標に基づいて、第１サービス、第２サービス、及び第３サービスの各々の異常判定を実行する（Ｓ１０３）。Ｓ１０３では、異常判定サーバ１０は、第１サービスの業績指標に基づいて、第１サービスに関連付けられた異常判定基準が満たされるか否かを判定する。異常判定サーバ１０は、第２サービスの業績指標に基づいて、第２サービスに関連付けられた異常判定基準が満たされるか否かを判定する。異常判定サーバ１０は、第３サービスの業績指標に基づいて、第３サービスに関連付けられた異常判定基準が満たされるか否かを判定する。

【0074】

異常判定サーバ１０は、第１サービス、第２サービス、及び第３サービスのうちの少なくとも１つが異常と判定されたか否かを判定する（Ｓ１０４）。Ｓ１０４では、異常判定サーバ１０は、第１サービス、第２サービス、及び第３サービスのうちの少なくとも１つで、異常判定基準が満たされたか否かを判定する。異常判定サーバ１０は、あるサービスで異常判定基準が満たされた場合に、そのサービスで異常が発生したと判定する。Ｓ１０４において、第１サービス、第２サービス、及び第３サービスのうちの少なくとも１つが異常と判定されない場合（Ｓ１０４：Ｎ）、本処理は終了する。

【0075】

Ｓ１０４において、第１サービス、第２サービス、及び第３サービスのうちの少なくとも１つが異常と判定された場合（Ｓ１０４：Ｙ）、異常判定サーバ１０は、管理者端末２０に対し、当該少なくとも１つのサービスで異常が発生したことを示す異常発生通知を送信する（Ｓ１０５）。通知は、任意の媒体を利用可能であり、例えば、電子メール、ＳＭＳ、ＳＮＳ、メッセージアプリ、又はメンテナンスツール上の通知であってもよい。管理者端末２０は、異常判定サーバ１０から異常発生通知を受信すると（Ｓ１０６）、当該異常発生通知に基づいて、管理者画面ＳＣを表示部２５に表示させ（Ｓ１０７）、本処理は終了する。

【0076】

第１実施形態の異常判定システム１は、サービス提供システム２に関する利用状況に基づいて、サービスの業績に関する業績指標を取得する。異常判定システム１は、業績指標に基づいて、サービス提供システム２における異常の発生に関する異常判定を実行する。これにより、例えばゴールデンシグナルメトリクスでは判定できないような異常をビジネス的な観点で判定できるようになるので、異常判定の精度が高まる。図３の例であれば、第１サーバ３０のゴールデンシグナルメトリクスでは異常とは判定されなかったとしても、ゴールデンシグナルメトリクスだけでは判定できない部分に異常が発生している可能性がある。この場合に、業績指標によって、第１サーバ３０に何らかの異常が発生していると判定できるので、異常判定の精度が高まる。例えば、ゴールデンシグナルメトリクスで何らかの異常が発生していたとしても、業績指標に大きな影響が出ていないのであれば、すぐに対応する必要がないといった判断を管理者が行うこともできる。

【0077】

また、異常判定システム１は、複数のサービスの各々の業績指標に基づいて、複数のサービスのうちの少なくとも１つの異常判定を実行する。これにより、サービス提供システム１が複数のサービスを提供する場合だったとしても、少なくとも１つのサービスの異常判定を実行できるようになる。例えば、第１サービスの業績指標と、第２サービス及び第３サービスの少なくとも一方の業績指標と、に基づいて、第１サービスの異常判定を実行する場合には、第１サービスの業績指標だけではなく、他のサービスの業績指標も総合的に考慮して異常判定を実行できるので、異常判定の精度が高まる。

【0078】

また、異常判定システム１は、リアルタイムで取得された業績指標に基づいて、異常判定をリアルタイムで実行する。これにより、サービス提供システム１に発生した異常を迅速に検出できる。

【0079】

また、異常判定システム１は、決済指標に基づいて、異常判定を実行する。これにより、サービス提供システム１における決済に何らかの異常が発生した場合に、この異常を迅速に検出できる。例えば、ビジネスに直結する決済指標を利用することによって、ビジネス的な影響の大きい異常を検出できる。

【0080】

［２．第２実施形態］
次に、異常判定システム１の別実施形態である第２実施形態を説明する。例えば、サービス提供システム２では、特定の時期にキャンペーンが開催されることがある。キャンペーンの開催中は、サービスの利用が増加し、キャンペーンが開催されていない他の時期である通常の時期とは異なる利用状況になることがある。そこで、キャンペーンの開催時期と、通常の時期と、で異常判定基準を異ならせることによって、異常判定の柔軟性を高めるようにしてもよい。

【0081】

図７は、キャンペーンの開催時期と、通常の時期と、の各々における業績指標の一例を示す図である。図７の上側の例は、第１サービスがキャンペーン中であり、第２サービス及び第３サービスが通常の時期である場合の業績指標の時系列的な変化である。図７の下側の例は、第１サービス、第２サービス、及び第３サービスが３つとも通常の時期である場合の業績指標の時系列的な変化である。図７の上側の例のように、キャンペーンの開催時期における第１サービスの業績指標は、通常の時期の業績指標に比べて高くなる。

【0082】

例えば、キャンペーンの開催時期に異常が発生すると、より多くの機会損失が発生するので、ビジネス的な影響が大きくなる。このため、キャンペーンの開催時期には、異常判定基準が高くなる。図７の例では、第１サービスの異常判定基準を太い実線で示す。図７のように、キャンペーンの開催時期の異常判定基準は、通常の時期の異常判定基準よりも高くなる。第２サービス及び第３サービスでは、キャンペーンは開催されていないので、異常判定基準は変わらない。以降、第２実施形態の詳細を説明する。なお、第２実施形態では、第１実施形態と同様の構成については説明を省略する。

【0083】

［２－１．第２実施形態の異常判定システムで実現される機能］
図８は、第２実施形態の異常判定システム１で実現される機能の一例を示す図である。例えば、異常判定サーバ１０は、データ記憶部１００、指標取得部１０１、異常判定部１０２、及び予定データ取得部１０３を含む。データ記憶部１００，指標取得部１０１、及び異常判定部１０２については、第１実施形態と異なる点について説明する。予定データ取得部１０３は、制御部１１により実現される。なお、管理者端末２０で実現される機能は、第１実施形態と同様であってよい。

【0084】

［データ記憶部］
第２実施形態のデータ記憶部１００は、第１実施形態で説明した業績指標データベースＤＢ１に加えて、予定データベースＤＢ２と、異常判定基準データベースＤＢ３と、を記憶する。

【0085】

図９は、予定データベースＤＢ２の一例を示す図である。予定データベースＤＢ２は、サービス提供システム２における予定に関する情報が格納されたデータベースである。第２実施形態では、キャンペーンが予定に相当する場合を説明するが、予定自体は、任意の種類であってよく、キャンペーンに限られない。例えば、予定は、キャンペーン以外の何らかのイベント、オフラインでのイベント、新サービスのリリース、メンテナンス、又は他のサービスに関する予定であってもよい。

【0086】

例えば、予定データベースＤＢ２には、予定の日時、予定の名前、及び予定の内容が格納されている。第２実施形態では、予定データベースＤＢ２に含まれる個々のレコードが予定データに相当する。管理者又はその他の者によって、これらの情報が予定データベースＤＢ２に登録される。例えば、予定の内容は、予定が関係するサービスのサービスＩＤ、予定の種類、予定の日時に予想される利用状況、又はこれらの組み合わせである。なお、予定データベースＤＢ２には、予定に関する任意の情報が格納されてよい。予定データベースＤＢ２に格納される情報は、図９の例に限られない。

【0087】

図１０は、異常判定基準データベースＤＢ３の一例を示す図である。異常判定基準データベースＤＢ３は、異常判定で利用される異常判定基準が格納されたデータベースである。例えば、異常判定基準データベースＤＢ３は、予定ごとに、異常判定基準が格納される。例えば、管理者は、サービス提供システム２における予定ごとに、異常判定基準を異常判定基準データベースＤＢ３に登録する。管理者は、あるキャンペーンが開催される場合に、過去の同様のキャンペーンにおける業績指標を考慮して、異常判定基準を指定する。異常判定基準データベースＤＢ３には、キャンペーン時期における異常判定基準と、通常の時期における異常判定基準と、が格納されている。

【0088】

なお、異常判定基準は、管理者が指定する方法以外の他の方法によって決定されてもよい。例えば、異常判定基準は、機械学習の手法を利用して、過去の傾向が学習された学習モデルに基づいて決定されてもよい。この場合、異常判定サーバ１０は、これから開催される予定の内容を、学習済みの学習モデルに入力する。異常判定サーバ１０は、この予定に関連付けて、学習モデルから出力された異常判定基準を異常判定基準データベースＤＢ３に格納する。他にも例えば、異常判定基準は、ルールベースの手法等の他の方法で決定されてもよい。

【0089】

［指標取得部］
第２実施形態では、指標取得部１０１が、第１実施形態で説明した業績指標を取得する場合を説明するが、指標取得部１０１は、業績指標以外の他の指標を取得してもよい。第２実施形態で業績指標と記載した箇所は、他の指標に読み替えることができる。例えば、指標取得部１０１は、ハードウェアに関する指標であるハードウェア指標と、ソフトウェアに関するソフトウェア指標と、の少なくとも一方を取得してもよい。第１実施形態で説明したゴールデンシグナルメトリクスは、ハードウェア指標及びソフトウェア指標の一例である。ハードウェア指標及びソフトウェア指標は、ベンチマークテスト又はメンテナンスツールで利用されているプログラムに基づいて取得されてもよい。

【0090】

ハードウェア指標は、ハードウェアの負荷に関する指標である。ソフトウェア指標は、ソフトウェアの動作に関する指標である。ハードウェア指標及びソフトウェア指標自体は、公知の指標であってよい。例えば、ハードウェア指標は、ＣＰＵ使用率、メモリ使用率、ネットワーク使用率、電力使用率、及びこれらの組み合わせであってもよい。ハードウェア指標以外の他の指標が利用されてもよい。例えば、ハードウェア又はその周辺の温度が異常判定基準以上になることが、ハードウェアの異常に相当してもよい。例えば、ソフトウェア指標は、テスト用のプログラムの実行に要した処理時間、又は、所定のデータの読み込みに要した処理時間である。

【0091】

［予定データ取得部］
予定データ取得部１０３は、サービスの予定に関する予定データを取得する。例えば、予定データ取得部１０３は、予定データベースＤＢ２を参照し、予定データを取得する。予定データが予定データベースＤＢ２以外の他のデータベースに格納されている場合には、予定データ取得部１０３は、当該他のデータベースを参照し、予定データを取得すればよい。異常判定サーバ１０以外の他のコンピュータ又は情報記憶媒体に予定データが記憶されている場合には、予定データ取得部１０３は、当該他のコンピュータ又は情報記憶媒体から、予定データを取得すればよい。

【0092】

第２実施形態では、予定データは、サービスに関するキャンペーンが開催されるキャンペーン時期を示す。キャンペーン時期は、キャンペーンが開催される期間である。キャンペーン時期は、任意の長さであってよい。例えば、キャンペーン時期の長さは、１分～１時間、数時間～数日、１週間～１ヶ月、又は他の長さであってもよい。図１０の例では、キャンペーン時期が日時で示される場合を説明するが、キャンペーン時期は、時間を含まずに日付だけを含んでもよい。

【0093】

［異常判定部］
第２実施形態の異常判定部１０２は、業績指標と、予定データと、に基づいて、異常判定を実行する。第２実施形態では、予定データがキャンペーン時期を示すので、異常判定部１０２は、業績指標と、予定データが示すキャンペーン時期と、に基づいて、異常判定を実行する。例えば、異常判定部１０２は、キャンペーン時期に基づいて、異常判定基準を決定する。異常判定部１０２は、キャンペーン時期が訪れたか否かを判定する。

【0094】

例えば、異常判定部１０２は、キャンペーン時期が訪れたと判定されない場合には、通常の時期の異常判定基準に基づいて、異常判定を実行する。異常判定部１０２は、キャンペーン時期が訪れたと判定された場合に、異常判定基準データベースＤＢ３を参照し、キャンペーンに関連付けられた異常判定基準を取得する。異常判定部１０２は、業績評価と、当該取得された異常判定基準と、に基づいて、異常判定を実行する。異常判定基準の取得方法が第１実施形態とは異なるが、異常判定基準が取得された後における異常判定の処理自体は、第１実施形態と同様である。

【0095】

なお、異常判定部１０２が予定データを異常判定に利用する方法は、上記の例に限られない。例えば、異常判定部１０２は、予定データに基づいて異常判定基準を決定するのではなく、予定データに基づいて、異常判定を実行するか否かを決定してもよい。異常判定部１０２は、予定データが示すキャンペーン時期になったか否かを判定し、キャンペーン時期になっていないと判定した場合には、異常判定を実行せず、キャンペーン時期になったと判定された場合に、業績指標に基づいて、異常判定を実行してもよい。逆に、異常判定部１０２は、キャンペーン時期になったと判定した場合には、異常判定を実行せず、キャンペーン時期になっていないと判定した場合に、業績指標に基づいて、異常判定を実行してもよい。

【0096】

［２－２．第２実施形態の異常判定システムで実行される処理］
図１１は、第２実施形態の異常判定システム１で実行される処理の一例を示す図である。制御部１１，２１が、それぞれ記憶部１２，２２に記憶されたプログラムを実行することによって、図１１の処理が実行される。図１１のように、Ｓ２００～Ｓ２０２の処理は、それぞれＳ１００～Ｓ１０２の処理と同様である。

【0097】

異常判定サーバ１０は、予定データベースＤＢ２を参照し、現時点が属する予定が存在するか否かを判定する（Ｓ２０３）。Ｓ２０３において、現時点が属する予定が存在しないと判定された場合（Ｓ２０３）、異常判定サーバ１０は、異常判定基準データベースＤＢ３を参照し、通常の期間における異常判定基準を取得する（Ｓ２０４）。

【0098】

Ｓ２０３において、現時点が属する予定が存在しないと判定された場合（Ｓ２０３）、異常判定サーバ１０は、異常判定基準データベースＤＢ３を参照し、キャンペーン時期における異常判定基準を取得する（Ｓ２０５）。Ｓ２０６～Ｓ２１１の処理は、Ｓ２０４又はＳ２０５で取得された異常判定基準が利用される点で、Ｓ１０２～１０７の処理とは異なるが、他の点については、Ｓ１０２～１０７の処理と同様である。

【0099】

第２実施形態の異常判定システム１は、業績指標と、予定データと、に基づいて、異常判定を実行する。これにより、予定データが示す予定に応じた異常判定が可能になるので、異常判定の柔軟性が高まる。例えば、ある時期に業績指標が上がることが予想される場合には、異常判定基準を上げることによって、キャンペーン時期のような重要な時期の機会損失を防ぎやすくなる。通常の時期には、予定がある時期とは異なる異常判定基準にすることによって、不要な通知が管理者端末２０に送信されることを防止できる。キャンペーン時期にだけ異常判定を実行することによって、必要な時期にだけ異常判定を実行できる。

【0100】

また、異常判定システム１は、業績指標と、予定データが示すキャンペーン時期と、に基づいて、異常判定を実行する。これにより、キャンペーン時期のような重要な時期に応じた異常判定が可能になるので、異常判定の柔軟性が高まる。

【0101】

［３．変形例］
本開示は、以上に説明した第１実施形態及び第２実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

【0102】

［３－１．第１実施形態に関する変形例］
まず、第１実施形態に関する変形例を説明する。

【0103】

［変形例１－１］
例えば、図２のように、サービス提供システム１は、個々のサービスに特有の構成と、複数のサービスにまたがる構成と、を含むことがある。この場合、ある特定のサービスの業績指標だけが減っていれば、このサービスに特有の構成に異常が発生している可能性がある。一方で、複数のサービス全体の業績指標が減っていれば、複数のサービスにまたがる構成に異常が発生している可能性がある。そこで、個々のサービスの業績指標だけではなく、複数のサービスの全体の業績指標を考慮して、異常判定が実行されてもよい。

【0104】

変形例１の異常判定部１０２は、異常判定の対象となるサービスごとに、当該サービスの業績指標と、複数のサービス全体の業績指標と、の関係に基づいて、異常判定を実行する。複数のサービス全体の業績指標とは、複数のサービスの各々の業績指標の合計である。例えば、異常判定部１０２は、第１サービスの業績指標、第２サービスの業績指標、及び第３サービスの業績指標の合計を計算する。

【0105】

例えば、異常判定部１０２は、第１サービスの業績指標と、当該計算された合計と、の関係に基づいて、第１サービスの異常判定を実行する。異常判定部１０２は、第１サービスの業績指標が第１サービスの異常判定基準を満たし、かつ、合計が全体の異常判定基準を満たさなかった場合には、第１サービスに異常が発生したと判定する。異常判定部１０２は、合計が全体の異常判定基準を満たした場合には、サービス全体に異常が発生したと判定する。この場合、第１サービスの業績指標が第１サービスの異常判定基準を満たしたか否かに関係なく、サービス全体に異常が発生したと判定されてもよい。異常判定部１０２は、第２サービス及び第３サービスについても同様にして異常判定を実行する。

【0106】

図１２は、複数のサービス全体の業績指標に基づく異常判定の一例を示す図である。図１２の例では、第１サービス、第２サービス、及び第３サービスの全てのサービスの業績指標が急激に低下している。この場合、第１サーバ３０、第２サーバ４０、及び第３サーバ５０の全てに異常が発生している可能性もあるが、第１サービス、第２サービス、及び第３サービスに共通する共通サーバ６０の異常のために、全てのサービスで決済を受け付けにくい状態にある可能性がある。

【0107】

例えば、異常判定部１０２は、第１サーバ３０、第２サーバ４０、及び第３サーバ５０ではなく、共通サーバ６０に異常が発生したと判定する。この場合、異常判定部１０２は、管理者端末２０に対し、共通サーバ６０に異常が発生したことを示す異常発生通知を送信する。図１２の下側の管理者画面ＳＣのように、共通サーバ６０で異常が発生している可能性を示すメッセージが表示される。

【0108】

変形例１－１の異常判定システム１は、異常判定の対象となるサービスごとに、当該サービスの業績指標と、複数のサービス全体の業績指標と、の関係に基づいて、異常判定を実行する。これにより、複数のサービス全体の業績指標を考慮して異常判定を実行できるので、異常判定の精度が高まる。例えば、個々のサービスに特有の構成ではなく、複数のサービスにまたがる構成に異常が発生していることを特定しやすくなる。

【0109】

［変形例１－２］
例えば、異常判定部１０２は、異常判定の対象となるサービスごとに、当該サービスの業績指標と、他のサービスの業績指標と、の関係に基づいて、異常判定を実行してもよい。即ち、個々のサービスの業績指標と、複数のサービス全体の業績指標と、の関係（変形例１－１で説明した関係）ではなく、個々のサービスの業績指標同士の関係を考慮して、異常判定を実行してもよい。

【0110】

図１３は、あるサービスの業績指標と、他のサービスの業績指標と、の関係に基づく異常判定の一例を示す図である。図１３の例では、第２サービスの業績指標と、第３サービスの業績指標と、の各々が急激に低下している。第１サービスの業績指標は、通常時とあまり変わらない。この場合、第２サーバ４０及び第３サーバ５０の各々に異常が発生している可能性もあるが、第２サービス及び第３サービスで共通する共通プラットフォーム（例えば、共通サーバ６０の構成の一部）の異常のために、第２サービス及び第３サービスで決済を受け付けにくい状態にある可能性がある。

【0111】

例えば、異常判定部１０２は、異常判定部１０２は、第２サービスの業績指標が異常判定基準を満たし、かつ、第３サービスの業績指標も異常判定基準を満たす場合には、第２サービス及び第３サービスで共通の構成に異常が発生したと判定する。異常判定部１０２は、第２サーバ４０及び第３サーバ５０ではなく、共通サーバ６０により実現される共通プラットフォームに異常が発生したと判定する。この場合、異常判定部１０２は、管理者端末２０に対し、共通サーバ６０の共通プラットフォームに異常が発生したことを示す異常発生通知を送信する。図１３の下側の管理者画面ＳＣのように、共通サーバ６０の共通プラットフォームで異常が発生している可能性を示すメッセージが表示される。

【0112】

例えば、異常判定部１０２は、第２サービスの業績指標が異常判定基準を満たし、かつ、第３サービスの業績指標が異常判定基準を満たさなかった場合には、第２サービスに特有の構成に異常が発生したと判定する。異常判定部１０２は、第２サービスの業績指標が異常判定基準を満たさず、かつ、第３サービスの業績指標が異常判定基準を満たす場合には、第３サービスに特有の構成に異常が発生したと判定する。個々のサービスに特有の構成に異常が発生したと判定された場合の処理は、第１実施形態と同様である。なお、各サービスの関係と、サービス提供システム２のうち異常が発生した部分と、の関係は、データ記憶部１００に予め記憶されているものとする。

【0113】

変形例１－２の異常判定システム１は、異常判定の対象となるサービスごとに、当該サービスの業績指標と、他のサービスの業績指標と、の関係に基づいて、異常判定を実行する。これにより、個々のサービスの業績指標同士の関係を考慮して異常判定を実行できるので、異常判定の精度が高まる。例えば、個々のサービスに特有の構成ではなく、複数のサービスにまたがる構成に異常が発生していることを特定しやすくなる。

【0114】

［変形例１－３］
例えば、第１実施形態で説明したように、サービス提供システム２が複数のサービスの各々をユーザに提供する場合には、異常判定部１０２は、複数のサービスの各々の業績指標が、異常判定基準を満たすか否かを判定してもよい。この場合、複数のサービスのうち、異常が発生したサービスを特定するために、業績指標の種類が役立つことがある。

【0115】

例えば、業績指標取得部１０１Ａが、決済に関する決済指標と、ログイン数に関するログイン指標と、の２つの業績指標を取得したとする。決済指標が異常判定基準を満たさない場合、サービス提供システム２のうち、フィンテック系のサービスに異常が発生している可能性がある。ログイン指標が異常判定基準を満たさない場合、サービス提供システム２のうち、会員管理のサービスに異常が発生している可能性がある。このように、異常判定基準を満たした業績指標の種類は、異常が発生したサービスの特定に役立つ。

【0116】

そこで、変形例１－３の異常判定部１０２は、異常判定基準を満たした業績指標の種類に基づいて、異常判定を実行する。変形例１－３では、業績指標の種類と、異常が発生した可能性のあるサービスと、が関連付けられた種類データがデータ記憶部１００に記憶されているものとする。種類データは、任意の形式であってよく、例えば、テーブル、プログラムコードの一部、又は機械学習の手法を利用した学習モデルであってもよい。例えば、種類データには、決済指標と、フィンテック系のサービスと、が関連付けられている。種類データには、ログイン指標と、会員管理のサービスと、が関連付けられている。

【0117】

例えば、異常判定部１０２は、種類データに基づいて、複数のサービスのうち、異常判定基準を満たした業績指標の種類に関連付けられたサービスに異常が発生したと判定する。異常判定部１０２は、決済指標が異常判定基準を満たしたと判定された場合に、決済指標に関連付けられたフィンテック系のサービスに異常が発生したと判定する。異常判定部は、ログイン指標が異常判定基準を満たしたと判定された場合に、決済指標に関連付けられたフィンテック系のサービスに異常が発生したと判定する。

【0118】

なお、異常判定基準を満たした業績指標の種類に基づく異常判定は、上記の例に限られない。種類データには、業績指標の種類と、異常が発生した可能性のあるハードウェア又はソフトウェアと、の関係が関連付けられていてもよい。この場合、異常判定部１０２は、異常判定基準を満たす業績指標の種類に関連付けられたハードウェア又はソフトウェアに異常が発生したと判定してもよい。異常判定部１０２は、管理者端末２０に対し、当該ハードウェア又は当該ソフトウェアを示す異常発生通知を送信する。管理者画面ＳＣには、当該ハードウェア又は当該ソフトウェアの情報が表示される。

【0119】

変形例１－３の異常判定システム１は、異常判定基準を満たした業績指標の種類に基づいて、異常判定を実行する。これにより、業績指標の種類に応じた異常判定を実行できるので、異常判定の精度が高まる。例えば、業績指標の種類に基づいて、異常が発生した可能性があるサービスが特定される場合には、異常が発生したサービスを管理者が特定しやすくなる。業績指標の種類に基づいて、異常が発生した可能性のあるハードウェア又はソフトウェアが特定される場合には、異常が発生したハードウェア又はソフトウェアを管理者が特定しやすくなる。

【0120】

［変形例１－４］
例えば、第１実施形態では、業績指標に基づいて、異常判定が実行される場合を説明した。異常判定では、業績指標以外の他の指標も考慮されてもよい。変形例１－４では、他の指標の一例として、ハードウェア指標を説明する。他の指標は、ハードウェア指標に限られず、第１実施形態で説明したソフトウェア指標であてもよい。

【0121】

図１４は、変形例１－４で実現される機能の一例を示す図である。図１４では、第１実施形態及び第２実施形態を組み合わせた場合の機能が示されているが、第２実施形態で説明した機能は、異常判定システム１に含まれなくてもよい。変形例１－４の異常判定システム１は、ハードウェア指標取得部１０１Ｂを含む。ハードウェア指標取得部１０１Ｂは、サービス提供システム２に含まれるハードウェアに関するハードウェア指標を取得する。ハードウェア指標の詳細は、第１実施形態で説明した通りである。更に、ハードウェア指標の取得方法自体は、公知の方法を利用可能な点についても、第１実施形態で説明した通りである。

【0122】

異常判定部１０２は、業績指標と、ハードウェア指標と、に基づいて、異常判定を実行する。例えば、異常判定部１０２は、業績指標だけではなく、ハードウェア指標についても、異常判定基準を満たすか否かを判定する。以降、変形例１－４では、業績指標に関する異常判定基準を、業績指標基準という。ハードウェア指標に関する異常判定基準を、ハードウェア指標基準という。業績指標基準が満たされるか否かを判定する処理は、第１実施形態で説明した通りである。

【0123】

例えば、ハードウェア指標基準は、ハードウェア指標に関する閾値を含む。異常判定部１０２は、ハードウェア指標が閾値以上であるか否かを判定することによって、異常判定を実行する。異常判定部は、ハードウェア指標が示すＣＰＵ使用率、メモリ使用率、及びネットワーク使用率の少なくとも１つが閾値以上である場合に、異常が発生したと判定する。なお、ハードウェア指標基準は、閾値を特に含まなくてもよい。例えば、ハードウェア指標基準は、ハードウェア指標の傾向が学習された学習モデルから出力された値が所定の値であるか否かといった基準であってもよい。

【0124】

例えば、異常判定部１０２は、業績指標に基づく異常判定と、ハードウェア指標に基づく異常判定と、の少なくとも一方で、異常が発生したとの判定結果が得られた場合に、管理者端末２０に対し、異常発生通知を送信する。ハードウェア指標に基づく異常判定で異常が発生した場合には、異常発生通知は、異常が発生したハードウェアに関する情報が含まれる。表示制御部２０２は、異常発生通知に基づいて、異常が発生したハードウェアに関する情報を管理者画面ＳＣに表示させる。

【0125】

変形例１－４の異常判定システム１は、業績指標と、ハードウェア指標と、に基づいて、異常判定を実行する。これにより、業績指標だけではなく、ハードウェア指標も考慮して異常判定を実行できるので、異常判定の精度が高まる。

【0126】

［変形例１－５］
例えば、変形例１－４で説明したように、異常判定部１０２は、業績指標が所定の業績指標基準を満たすか否かを判定してもよい。異常判定部１０２は、ハードウェア指標が所定のハードウェア指標基準を満たすか否かを判定してもよい。この場合に、異常判定部１０２は、ハードウェア指標基準が満たされて、かつ、業績指標基準が満たされないと判定された場合には、ハードウェア指標基準及び業績指標基準の両方が満たされた場合よりも、異常に関する度合が低くなるように、異常判定を実行してもよい。

【0127】

異常に関する度合は、異常の疑いの高さを示す情報である。別の言い方をすれば、異常に関する度合は、異常の深刻さを示す情報である。異常に関する度合は、２値ではなく、中間値を有する情報によって表現される。即ち、異常に関する度合は、３段階以上の値を取りうる。第１実施形態で説明した異常スコアは、異常に関する度合に相当する。このため、異常に関する度合と記載した箇所は、異常スコアと読み替えることができる。異常に関する度合は、異常スコア以外の他の名前で呼ばれてもよい。

【0128】

例えば、異常判定部１０２は、ハードウェア指標基準が満たされて、かつ、業績指標基準が満たされないと判定された場合には、ハードウェア指標基準及び業績指標基準の両方が満たされたと判定された場合よりも、異常スコアを低くする。異常判定部１０２は、ハードウェア指標基準が満たされて、かつ、業績指標基準が満たされないと判定された場合には、ハードウェア指標基準が満たされず、かつ、業績指標基準が満たされた場合よりも、異常スコアを低くしてもよい。

【0129】

別の言い方をすれば、異常判定部１０２は、ハードウェア指標だけを考慮すれば、異常が発生したと判定されたとしても、業績指標基準を考慮すると異常が発生したと判定されない場合には、業績指標基準を考慮すると異常が発生したと判定される場合よりも、異常の度合を低くする。即ち、業績指標に基づいて異常判定が、ハードウェア指標に基づく異常判定よりも優先的に利用されるようにしてもよい。ハードウェア的には異常が発生していても、ビジネス的な影響が小さい場合には、異常の度合が相対的に小さくなる。

【0130】

変形例１－５の異常判定システム１は、ハードウェア指標が所定のハードウェア指標基準を満たすか否かを判定し、ハードウェア指標基準が満たされて、かつ、業績指標基準が満たされないと判定された場合には、ハードウェア指標基準及び業績指標基準の両方が満たされた場合よりも、異常に関する度合が低くなるように、異常判定を実行する。これにより、異常判定の精度が高まる。例えば、ハードウェア的には異常になりそうだったとしても、ビジネス的な影響が小さい場合には、管理者による対応を後回しにしたり、そもそも対応しなかったりすることができる。

【0131】

［変形例１－６］
例えば、業績指標は、現時点における異常判定だけではなく、将来における異常判定に利用できることがある。変形例１－６では、第１実施形態で説明した第１サービス（電子商取引サービス）を例に挙げる。第１サービスにおけるキャンペーンの開催中は、より多くのユーザが第１サービスを利用するので、業績指標が高くなることがある。業績指標が高くなると、サービス提供システム２の負荷が高まることがある。ただし、業績指標が高くなった後に、サービス提供システム２の負荷が直ちに高くなるとは限らない。

【0132】

例えば、買い物かごに入れられた商品の数が業績指標に相当したとする。この場合、業績指標が閾値以上になってから、ある程度の時間が経過した後に、商品を購入するための決済が集中的に実行されると考えられる。この場合、業績指標が閾値以上になってから、ある程度の時間が経過した後に、サービス提供システム２に障害が発生する可能性がある。そこで、異常判定部１０２は、業績指標に基づいて、将来における異常の発生に関する異常判定を実行してもよい。

【0133】

例えば、異常判定部１０２は、業績指標が異常判定基準を満たす場合に、業績指標が示す時点（例えば、現時点）ではなく将来に異常が発生すると判定する。ここでの将来は、業績指標が示す時点よりも後の時点である。これらの時点の時間間隔は、任意の長さであってよい。この時間間隔は、管理者が指定してもよいし、過去の傾向から動的に決定されてもよい。この時間間隔は、サービスごとに定められていてもよい。時間間隔を示すデータは、予めデータ記憶部１００に記憶されているものとする。

【0134】

例えば、買い物かごに商品が入れられてから決済が実行されるまでの間の平均的な時間間隔が５分だったとすると、異常判定部１０２は、業績指標が示す時点から５分後に第１サーバ３０に異常が発生する可能性があると判定する。異常判定部１０２は、管理者端末２０に対し、５分後に第１サーバ３０に異常が発生する可能性があることを示す異常判定通知を送信する。表示制御部２０２は、異常判定通知を受信すると、５分後に第１サーバ３０に異常が発生する可能性を示す管理者画面ＳＣを表示部２５に表示させる。

【0135】

変形例１－６の異常判定システム１は、業績指標に基づいて、将来における異常の発生に関する異常判定を実行する。これにより、業績指標が異常判定基準を満たしてから、実際に異常が発生しうる時点までの間に、ある程度のタイムラグがあったとしても、将来に異常が発生する可能性を判定できる。その結果、管理者がマニュアルで対策をしたり、自動的に負荷分散をするロードバランサを利用したりすることによって、異常の発生を未然に防ぐことができる。

【0136】

［変形例１－７］
例えば、第１実施形態では、業績指標と比較する閾値を含む異常判定基準が異常判定で利用される場合を例に挙げたが、異常判定は、第１実施形態の例に限られない。異常判定部１０２は、業績指標と、訓練用の業績指標と異常の発生との関係が学習された学習モデルと、に基づいて、異常判定を実行してもよい。学習モデルは、機械学習の手法を利用して学生されたモデルである。

【0137】

機械学習の手法自体は、公知の種々の手法を利用可能である。例えば、機械学習の手法は、教師有り学習、半教師有り学習、又は教師無し学習の何れの手法であってもよい。変形例１－７では、ニューラルネットワークを利用した学習モデルを例に挙げる。例えば、管理者は、訓練用の業績指標を示す入力部分と、異常が発生しているか否かを示す出力部分と、のペアである訓練データを用意する。訓練データは、管理者が手動で作成してもよいし、公知のツールを利用して作成されてもよい。

【0138】

訓練データの学習方法自体も、機械学習で利用されている公知の手法を利用すればよい。例えば、管理者端末２０は、訓練データの入力部分が入力された場合に、訓練データの出力部分が出力されるように、学習モデルのパラメータを調整することによって、学習モデルの学習を実行する。管理者端末２０は、異常判定サーバ１０に対し、学習済みの学習モデルを送信する。異常判定サーバ１０は、管理者端末２０から受信した学習済みの学習モデルを、データ記憶部１００に記録する。

【0139】

例えば、異常判定部１０２は、学習モデルに対し、あるサービスの業績指標を入力する。学習モデルは、業績指標の特徴量を計算し、特徴量に基づいて、異常が発生した否かを示す判定結果を出力する。学習モデルが行う処理は、推定と呼ばれることもあるので、学習モデルから出力される判定結果は、学習モデルによる推定結果ということもできる。判定結果は、第１実施形態で説明したような２値に限られず、異常スコアのように中間値を有する情報であってもよい。異常判定部１０２は、学習モデルから出力された判定結果を取得することによって、異常判定を実行する。

【0140】

変形例１－７の異常判定システム１は、業績指標と、訓練用の業績指標と異常の発生との関係が学習された学習モデルと、に基づいて、異常判定を実行する。これにより、機械学習の手法を利用して異常判定を実行できるので、異常判定の精度が高まる。

【0141】

［変形例１－８］
例えば、変形例１－７で説明した学習モデルは、個々のサービスごとに用意されていてもよいが、複数のサービスの各々の業績指標が総合的に学習されていてもよい。変形例１－８の学習モデルには、複数のサービスの各々の訓練用の業績指標と、異常の発生と、の関係が学習されている。訓練データのデータ構造自体は、変形例１－７と同様であるが、訓練データの入力部分は、ある１つのサービスの訓練用の業績指標ではなく、複数のサービスの各々の訓練用の業績指標である。

【0142】

変形例１－８の異常判定部１０２は、複数のサービスの各々の業績指標と、学習モデルと、に基づいて、複数のサービスのうちの少なくとも１つの異常判定を実行する。例えば、異常判定部１０２は、サービスごとに、当該サービス及び他のサービスの各々の業績指標と、学習モデルと、に基づいて、当該サービスの異常判定を実行する。学習モデルに入力される業績指標が、１つのサービスではなく、複数のサービスという点で変形例１－７とは異なるが、他の点については、変形例１－７と同様である。

【0143】

変形例１－８の異常判定システム１は、複数のサービスの各々の業績指標と、学習モデルと、に基づいて、複数のサービスのうちの少なくとも１つの異常判定を実行する。これにより、複数のサービスの各々の業績指標を総合的に考慮して異常判定を実行できるので、異常判定の精度が高まる。

【0144】

［変形例１－９］
例えば、サービス提供システム２が段階的にリニューアルすることがある。この場合、相対的に古いサービス提供システム２である旧システムと、相対的に新しいサービス提供システム２である新システムと、が共存することがある。旧システム及び新システムは、サービスを提供するために利用されるハードウェア及びソフトウェアの少なくとも一方が互いに異なる。この場合、新システムの異常判定が、旧システムの業績指標に基づいて実行されてもよい。

【0145】

例えば、ユーザがブラウザでサービスを利用する場合、ユーザは、旧システムのＵＲＬと、新システムのＵＲＬと、のうちの任意の方にアクセスできる。ユーザがブラウザ以外のアプリケーションを利用する場合、ユーザは、旧システム用のアプリケーションと、新システム用のアプリケーションと、のうちの任意の方にアクセスできる。変形例１－９では、旧システム及び新システムといった２つのサービス提供システム２が存在する。

【0146】

変形例１－９の業績指標取得部１０１Ａは、旧システムに基づく業績指標である旧システム指標と、新システムに基づく業績指標である新システム指標と、を取得する。例えば、業績指標取得部１０１Ａは、旧システムから、旧システム指標を取得する。旧システム指標は、旧システムに基づく業績指標という点で、第１実施形態で説明した業績指標とは異なるが、他の点については同様である。このため、旧システム指標は、第１実施形態で説明した種々の業績指標であってよい。

【0147】

例えば、業績指標取得部１０１Ａは、新システムから、新システム指標を取得する。新システム指標は、新システムに基づく業績指標という点で、第１実施形態で説明した業績指標とは異なるが、他の点については同様である。このため、新システム指標は、第１実施形態で説明した種々の業績指標であってよい。

【0148】

変形例１－９の異常判定部１０２は、旧システムに基づく業績指標である旧システム指標に基づいて、新システムの異常判定を実行する。例えば、異常判定部１０２は、旧システム指標が異常判定基準を満たす場合に、新システムに異常が発生していると判定する。ここでの異常判定基準は、旧システム指標が閾値以上になることであってもよい。旧システム指標が閾値以上であることは、ユーザが新システムではなく旧システムばかりを利用しているので、何らかの異常が新システムに発生している可能性がある。このため、異常判定部１０２は、旧システム指標が閾値以上である場合に、新システムに異常が発生していると判定する。

【0149】

変形例１－９の異常判定システム１は、旧システムに基づく業績指標である旧システム指標に基づいて、新システムの異常判定を実行する。これにより、新システムの異常判定の精度が高まる。新システムに基づく業績指標だけでは特定できないような異常を特定できる。

【0150】

［変形例１－１０］
例えば、第１実施形態では、業績指標の一例として、決済指標を説明した。業績指標は、サービスの何らかの業績を表す情報であればよく、決済指標に限られない。例えば、業績指標取得部１０１Ａは、業績指標として、電子商取引サービスにおける取引に関する取引指標を取得する。取引は、電子商取引サービスの利用である。例えば、商品又はコンテンツの購入である。取引指標は、購入数、購入額、購入額の合計、買い物かごに追加された商品、買い物かごからのドロップ数、ブックマークに追加された商品、又はこれらの組み合わせである。

【0151】

変形例１－１０の異常判定部１０２は、取引指標に基づいて、異常判定を実行する。取引指標が異常判定で利用される点で第１実施形態とは異なるが、他の点は、第１実施形態で説明した通りである。

【0152】

変形例１－１０の異常判定システム１は、取引指標に基づいて、異常判定を実行する。これにより、電子商取引サービスにおける異常判定の精度が高まる。

【0153】

［変形例１－１１］
例えば、業績指標取得部１０１Ａは、業績指標として、サービスのメンバーシップに関するメンバーシップ指標を取得してもよい。メンバーシップ指標は、サービスの会員に関する指標である。例えば、メンバーシップ指標は、会員数、会員数の変化量、退会数、退会数の変化量、又はこれらの組み合わせである。

【0154】

異常判定部１０２は、メンバーシップ指標に基づいて、異常判定を実行する。メンバーシップ指標が異常判定で利用される点で第１実施形態とは異なるが、他の点は、第１実施形態で説明した通りである。

【0155】

変形例１－１１の異常判定システム１は、メンバーシップ指標に基づいて、異常判定を実行する。これにより、会員登録が必要なサービスにおける異常判定の精度が高まる。

【0156】

［３－２．第２実施形態に関する変形例］
次に、第２実施形態に関する変形例を説明する。

【0157】

［変形例２－１］
例えば、第２実施形態では、予定データがキャンペーン時期を示す場合を説明したが、予定データは、サービス提供システム１における何らかの予定を示せばよく、キャンペーン時期に限られない。変形例２－１では、予定データが、サービスに関するメンテナンスが行われるメンテナンス時期を示す場合を例に挙げる。

【0158】

メンテナンスは、サービス提供システム２に含まれるハードウェア及びソフトウェアを対象にして行われる。例えば、ハードウェアの点検、交換、撤去、増設、又はこれらの組み合わせは、メンテナンスに相当する。ソフトウェアの点検、インストール、アンインストール、又はこれらの組み合わせは、メンテナンスに相当する。メンテナンス時期は、メンテナンスが行われる期間である。メンテナンス時期は、キャンペーン時期と同様、日時で示されてもよいし、日付だけで示されてもよい。

【0159】

変形例２－１の異常判定部１０２は、業績指標と、予定データが示すメンテナンス時期と、に基づいて、異常判定を実行する。例えば、異常判定部１０２は、現時点がメンテナンス時期に含まれるか否かを判定する。異常判定部１０２は、現時点がメンテナンス時期に含まれる場合には、業績指標に基づく異常判定を実行せず、現時点がメンテナンス時期に含まれない場合に、業績指標に基づいて、異常判定を実行する。

【0160】

変形例２－１の異常判定システム１は、業績指標と、予定データが示すメンテナンス時期と、に基づいて、異常判定を実行する。これにより、メンテナンス時期に応じた異常判定が可能になるので、異常判定の柔軟性が高まる。例えば、メンテナンスのために業績指標が下がった場合に異常と判定しないようにすることによって、不要な異常判定通知が管理者に通知されることを防止できる。

【0161】

［変形例２－２］
例えば、変形例２－１では、メンテナンス時期に基づいて、異常判定を実行するか否かが決定される場合を説明したが、メンテナンス時期を利用した異常判定は、変形例２－１の例に限られない。変形例２－２の異常判定部１０２は、予定データに基づいて、異常判定に関する異常判定基準を決定する。異常判定部１０２は、当該決定された異常判定基準と、指標と、に基づいて、異常判定を実行する。

【0162】

例えば、異常判定部１０２は、予定データが示すメンテナンス時期に基づいて、異常判定基準を決定し、業績指標と、当該決定された異常判定基準と、に基づいて、異常判定を実行してもよい。異常判定部１０２は、現時点がメンテナンス時期に含まれる場合には、現時点がメンテナンス時期に含まれない場合よりも、異常判定基準が示す閾値を低くする。異常判定部１０２は、業績指標と、当該低くした閾値と、に基づいて、異常判定を実行する。

【0163】

なお、変形例２－２では、予定データがメンテナンス時期を示す場合を例に挙げたが、予定データがキャンペーン時期を示す場合も同様に、異常判定部１０２は、キャンペーン時期に基づいて、異常判定基準を決定してもよい。この処理は、第２実施形態で説明した方法と同様であってよい。

【0164】

変形例２－２の異常判定システム１は、予定データに基づいて、異常判定に関する異常判定基準を決定し、当該決定された異常判定基準と、指標と、に基づいて、異常判定を実行する。これにより、予定に応じた異常判定基準とすることができるので、異常判定の精度が高まる。

【0165】

［変形例２－３］
例えば、変形例２－２のように異常判定基準が動的に決定される場合に、異常判定部１０２は、予定データに関する条件と、当該条件が満たされた場合の異常判定基準と、の関係に基づいて、異常判定基準を決定してもよい。この関係は、異常判定基準データベースＤＢ３に定められているものとする。予定データに関する条件とは、予定データに含まれる情報に基づいて判定される条件である。

【0166】

例えば、キャンペーン時期、キャンペーンの長さ、キャンペーンの金額、キャンペーンで対象とするユーザ層、キャンペーンで見込まれるユーザ数、キャンペーンで見込まれる業績指標、又はこれらの組み合わせに関する条件は、予定データに関する条件に相当する。例えば、メンテナンス時期、メンテナンスの長さ、メンテナンスの対象となるサービス、メンテナンスの対象となるハードウェア、メンテナンスの対象となるソフトウェア、又はこれらの組み合わせは、予定データに関する条件に相当する。

【0167】

例えば、変形例２－３の異常判定基準データベースＤＢ３には、予定データに関する条件ごとに、当該条件が満たされた場合に適用される異常判定基準が定義されている。条件の一例として、キャンペーンの金額が定義されているようにしてもよい。例えば、キャンペーンの金額が高いほど、異常判定基準が高くなるように、異常判定基準データベースＤＢ３が作成されている。例えば、異常判定部１０２は、予定データに基づいて、個々の条件が満たされるか否かを判定する。異常判定部１０２は、満たされると判定された条件に関連付けられた異常判定基準を特定する。異常判定部１０２は、業績指標と、当該特定された異常判定基準と、に基づいて、異常判定を実行する。

【0168】

変形例２－３の異常判定システム１は、予定データに関する条件と、当該条件が満たされた場合の異常判定基準と、の関係に基づいて、異常判定基準を決定する。これにより、予定データに応じた最適な異常判定基準とすることができるので、異常判定の精度が高まる。

【0169】

［変形例２－４］
例えば、変形例２－３では、異常判定基準データベースＤＢ３を利用して異常判定基準を決定する場合を説明したが、異常判定基準の決定方法は、変形例２－３で説明した例に限られない。異常判定部１０２は、予定データと、訓練用の予定データと異常判定基準との関係が学習された学習モデルと、に基づいて、異常判定基準を決定してもよい。この学習モデルは、変形例１－７で説明した学習モデルとは異なる。

【0170】

機械学習の手法自体は、公知の種々の手法を利用可能である。例えば、機械学習の手法は、教師有り学習、半教師有り学習、又は教師無し学習の何れの手法であってもよい。変形例２－４では、ニューラルネットワークを利用した学習モデルを例に挙げる。例えば、管理者は、訓練用の予定を示す入力部分と、最適と思われる異常判定基準を示す出力部分と、のペアである訓練データを用意する。訓練データは、管理者が手動で作成してもよいし、公知のツールを利用して作成されてもよい。

【0171】

訓練データの学習方法自体も、機械学習で利用されている公知の手法を利用すればよい。例えば、管理者端末２０は、訓練データの入力部分が入力された場合に、訓練データの出力部分が出力されるように、学習モデルのパラメータを調整することによって、学習モデルの学習を実行する。管理者端末２０は、異常判定サーバ１０に対し、学習済みの学習モデルを送信する。異常判定サーバ１０は、管理者端末２０から受信した学習済みの学習モデルを、データ記憶部に記録する。

【0172】

例えば、異常判定部１０２は、学習モデルに対し、予定データを入力する。学習モデルは、予定データが示す予定の特徴量を計算し、特徴量に応じた異常判定基準を出力する。異常判定部１０２は、業績指標と、学習モデルから出力された異常判定基準と、に基づいて、異常判定を実行する。異常判定基準の取得方法が第２実施形態とは異なるが、異常判定基準を利用した異常判定については、第２実施形態と同様であってよい。例えば、学習モデルは、予定データが示す予定におけるキャンペーンの影響（例えば、決済額の増加量）が大きいほど、異常判定基準に含まれる閾値が大きくなるように、異常判定基準を出力する。学習モデルは、予定データに含まれる他の要素についても、異常判定基準と相関関係があるものについては、当該他の要素に応じた異常判定基準を出力する。

【0173】

変形例２－４の異常判定システム１は、予定データと、訓練用の予定データと異常判定基準との関係が学習された学習モデルと、に基づいて、異常判定基準を決定する。これにより、機械学習の手法を利用して最適な異常判定基準とすることができるので、異常判定の精度が高まる。

【0174】

［変形例２－５］
例えば、変形例２－５の学習モデルには、過去の実績に基づく関係が学習されていてもよい。過去の実績に基づく関係とは、過去における実際の業績指標と、その時に最適と思われる異常判定基準と、の関係である。例えば、変形例２－５の訓練データは、過去の実績に基づいて、管理者により手動で作成される。変形例２－５の訓練データも、公知のツールを利用して自動的に作成されてもよい。

【0175】

変形例２－５の異常判定部１０２は、過去の実績に基づく関係が学習された学習モデルに基づいて、異常判定基準を決定する。過去の実績に基づく関係が学習モデルに学習されている点で変形例２－４とは異なるが、他の点は、変形例２－４と同様である。例えば、変形例２－５の学習モデルには、過去の予定の予定データに含まれる要素と、その時の実際の業績指標を考慮して最適だと思われる異常判定基準と、の関係が学習されている。学習モデルは、今後の予定の予定データが入力されると、当該予定データに応じた異常判定基準を出力する。

【0176】

変形例２－５の異常判定システム１は、過去の実績に基づく関係が学習された学習モデルに基づいて、異常判定基準を決定する。これにより、機械学習の手法を利用して最適な異常判定基準とすることができるので、異常判定の精度が高まる。

【0177】

［変形例２－６］
例えば、第１実施形態の変形例１－７と、第２実施形態と、を組み合わせて、異常判定部１０２は、業績指標と、訓練用の指標と異常の発生に関する異常判定結果との関係が学習された学習モデルと、に基づいて、異常判定を実行してもよい。この処理は、変形例１－７で説明した通りである。

【0178】

変形例２－６の異常判定システム１は、業績指標と、訓練用の指標と異常の発生に関する異常判定結果との関係が学習された学習モデルと、に基づいて、異常判定を実行する。これにより、機械学習の手法を利用して異常判定を実行できるので、異常判定の精度が高まる。

【0179】

［変形例２－７］
例えば、変形例２－６の学習モデルには、変形例２－５の学習モデルと同様、過去の実績に基づく関係が学習されていてもよい。過去の実績に基づく関係とは、過去における実際の業績指標と、その時に異常が発生していたか否かと、の関係である。例えば、変形例２－６の訓練データは、過去の実績に基づいて、管理者により手動で作成される。変形例２－６の訓練データも、公知のツールを利用して自動的に作成されてもよい。

【0180】

異常判定部１０２は、過去の実績に基づく関係が学習された学習モデルに基づいて、異常判定を実行する。過去の実績に基づく関係が学習モデルに学習されている点で変形例２－６とは異なるが、他の点は、変形例２－６と同様である。

【0181】

変形例２－７の異常判定システム１は、異常判定部１０２は、過去の実績に基づく関係が学習された学習モデルに基づいて、異常判定を実行する。これにより、機械学習の手法を利用して異常判定を実行できるので、異常判定の精度が高まる。

【0182】

［変形例２－８］
例えば、第２実施形態では、第１サービスのキャンペーンを例に挙げたが、予定データ取得部１０３は、複数のサービスの各々の予定を取得してもよい。変形例２－８では、予定データベースＤＢ２に、複数のサービスの各々の予定を示す予定データが格納されているものとする。個々の予定データについては、第２実施形態で説明した通りである。

【0183】

変形例２－８の異常判定部１０２は、複数のサービスの各々の業績指標と、複数のサービスの各々の予定と、に基づいて、複数のサービスのうちの少なくとも１つの異常判定を実行する。例えば、異常判定部１０２は、サービスごとに、当該サービスの業績指標と、当該サービスの予定と、に基づいて、当該サービスの異常判定を実行する。例えば、異常判定部１０２は、サービスごとに、当該サービス及び他のサービスの各々の業績指標と、当該サービス及び他のサービスの各々の予定と、に基づいて、当該サービスの異常判定を実行する。

【0184】

変形例２－８の異常判定システム１は、複数のサービスの各々の指標と、複数のサービスの各々の予定と、に基づいて、複数のサービスのうちの少なくとも１つの異常判定を実行する。これにより、サービス提供システム１が複数のサービスを提供する場合だったとしても、少なくとも１つのサービスの異常判定を実行できるようになる。例えば、第１サービスの業績指標と、第１サービスの予定と、に基づいて、第１サービスの異常判定を実行する場合には、第１サービスの予定も考慮して異常判定を実行できるので、異常判定の精度が高まる。第１サービス及び第２サービスの各々の業績指標と、第１サービス及び第２サービスの各々の予定と、に基づいて、第１サービスの異常判定を実行する場合には、第１サービスだけではなく、第２サービスの予定も考慮して異常判定を実行できるので、異常判定の精度が高まる。

【0185】

［変形例２－９］
例えば、第１実施形態の変形例１－１と、第２実施形態と、を組み合わせて、異常判定部１０２は、異常判定の対象となるサービスごとに、当該サービスの業績指標及び予定と、複数のサービス全体の業績指標及び予定と、の関係に基づいて、異常判定を実行してもよい。複数のサービス全体の業績指標については、変形例１－１で説明した通りである。複数のサービス全体の予定とは、複数のサービスにまたがる予定である。

【0186】

例えば、共通サーバ６０のメンテナンスは、全てのサービスに関係するので、複数のサービス全体の予定に相当する。異常判定部１０２は、複数のサービス全体のメンテナンスが発生する場合には、異常判定を実行しない。複数のサービスの全てで利用可能なポイントのキャンペーンは、全てのサービスに関係するので、複数のサービス全体の予定に相当する。異常判定部１０２は、複数のサービス全体のキャンペーンが開催される場合には、異常判定基準を全体的に高くする。

【0187】

変形例２－９の異常判定システム１は、異常判定の対象となるサービスごとに、当該サービスの業績指標及び予定と、複数のサービス全体の業績指標及び予定と、の関係に基づいて、異常判定を実行する。これにより、複数のサービス全体の予定を考慮して異常判定を実行できるので、異常判定の精度が高まる。例えば、個々のサービスに特有の予定ではなく、複数のサービスにまたがる予定を考慮して異常判定を実行できるようになる。

【0188】

［変形例２－１０］
例えば、第１実施形態の変形例１－２と、第２実施形態と、を組み合わせて、異常判定部１０２は、異常判定の対象となるサービスごとに、当該サービスの業績指標及び予定と、他のサービスの業績指標及び予定と、の関係に基づいて、異常判定を実行してもよい。他のサービスの業績指標については、変形例１－２で説明した通りである。例えば、実施形態の例であれば、第２サービスと第３サービスがともにフィンテック系のサービスなので、異常判定部１０２は、第２サービスの予定と、第３サービスの予定と、に基づいて、第２サービスの異常判定基準を決定する。異常判定部１０２は、第２サービスの業績指標と、第３サービスの業績指標と、が当該決定された第２サービスの異常判定基準を満たすか否かを判定することによって、第２サービスの異常判定を実行してもよい。

【0189】

変形例２－１０の異常判定システム１は、異常判定部１０２は、異常判定の対象となるサービスごとに、当該サービスの指標及び予定と、他のサービスの指標及び予定と、の関係に基づいて、異常判定を実行する。

【0190】

［３－３．第１実施形態及び第２実施形態に共通するその他の変形例］
例えば、上記変形例を組み合わせてもよい。

【0191】

例えば、第１実施形態及び第２実施形態では、異常判定サーバ１０で主な処理が実行される場合を説明したが、異常判定サーバ１０で実行されるものとして説明した処理は、管理者端末２０又は他のコンピュータで実行されてもよいし、複数のコンピュータで分担されてもよい。

【要約】

異常判定システム（１）の指標取得部（１０１）は、所定のサービスを提供するためのサービス提供システム（２）における異常の発生に関する異常判定で利用可能な指標を取得する。予定データ取得部（１０３）は、サービスの予定に関する予定データを取得する。異常判定部（１０２）は、指標と、予定データと、に基づいて、異常判定を実行する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】