特開 2025-17535 情報処理装置および情報処理方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025017535

(43)【公開日】2025-02-06

(54)【発明の名称】情報処理装置および情報処理方法

(51)【国際特許分類】

   G06F 11/34 20060101AFI20250130BHJP

   G06F 11/07 20060101ALI20250130BHJP

【ＦＩ】

G06F11/34 147

G06F11/07 190

G06F11/07 140A

G06F11/07 151

【審査請求】未請求

【請求項の数】18

【出願形態】ＯＬ

(21)【出願番号】P 2023120626

(22)【出願日】2023-07-25

(71)【出願人】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(71)【出願人】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】110002860

【氏名又は名称】弁理士法人秀和特許事務所

(72)【発明者】

【氏名】大野 允裕

(72)【発明者】

【氏名】伊藤 雅典

(72)【発明者】

【氏名】吉田 琢也

(72)【発明者】

【氏名】蒔田 篤志

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042GB08

5B042KK13

5B042KK15

5B042MA08

5B042MA09

5B042MA11

5B042MA14

5B042MC08

(57)【要約】

【課題】障害検知の精度を向上させる。
【解決手段】情報処理装置が、異常検知モデルを利用して、第一のシステムにおいて異常が発生しているか否かを判定し、前記第一のシステムに異常が発生したと判定された場合に、前記異常が、前記第一のシステムに接続されている外部システムの障害の影響を受けたものであるか否かを推定し、前記判定された異常が、前記外部システムの障害の影響を受けたものであると推定される場合に、前記外部システムの障害の影響が小さくなるように、前記異常検知モデルを更新する。
【選択図】図１

【特許請求の範囲】

【請求項1】

異常検知モデルを利用して、第一のシステムにおいて異常が発生しているか否かを判定することと、
前記第一のシステムに異常が発生したと判定された場合に、前記異常が、前記第一のシステムに接続されている外部システムの障害の影響を受けたものであるか否かを推定することと、
前記判定された異常が、前記外部システムの障害の影響を受けたものであると推定される場合に、前記外部システムの障害の影響が小さくなるように、前記異常検知モデルを更新することと、
を実行する制御部を含む、情報処理装置。

【請求項2】

前記制御部は、前記外部システムに含まれる通信網またはサーバ装置の障害を通知する障害情報を取得する、
請求項１に記載の情報処理装置。

【請求項3】

前記制御部は、前記障害情報を取得した場合に、前記異常が、前記外部システムの影響を受けたものであると推定する、
請求項２に記載の情報処理装置。

【請求項4】

前記外部システムは、前記情報処理装置の管理者が管理していないシステムである、
請求項２または３に記載の情報処理装置。

【請求項5】

前記異常検知モデルは、前記第一のシステムに含まれる一つ以上の装置において計測された複数種類の計測値を入力とし、前記第一のシステムに対する異常スコアを出力する機械学習モデルであり、
前記制御部は、前記異常スコアが所定の閾値を超えている場合に、前記第一のシステムにおいて異常が発生していると判定する、
請求項２に記載の情報処理装置。

【請求項6】

前記制御部は、前記障害情報に基づいて、前記外部システムにおいて障害が発生している時間帯を判定する、
請求項５に記載の情報処理装置。

【請求項7】

前記制御部は、前記時間帯における、前記異常検知モデルの入力と出力を解析することで、前記外部システムの障害に起因した前記異常スコアの変化に対して所定値以上の貢献度を持つ前記計測値を特定する、
請求項６に記載の情報処理装置。

【請求項8】

前記制御部は、前記異常検知モデルについて、前記特定した計測値に対応する重みを補正する、
請求項７に記載の情報処理装置。

【請求項9】

前記制御部は、前記貢献度が所定値を上回る計測値について、重みを小さくする補正を行う、
請求項８に記載の情報処理装置。

【請求項10】

情報処理装置が実行する方法であって、
異常検知モデルを利用して、第一のシステムにおいて異常が発生しているか否かを判定することと、
前記第一のシステムに異常が発生したと判定された場合に、前記異常が、前記第一のシステムに接続されている外部システムの障害の影響を受けたものであるか否かを推定することと、
前記判定された異常が、前記外部システムの障害の影響を受けたものであると推定される場合に、前記外部システムの障害の影響が小さくなるように、前記異常検知モデルを更新することと、
を含む、情報処理方法。

【請求項11】

前記外部システムに含まれる通信網またはサーバ装置の障害を通知する障害情報を取得することをさらに含む、
請求項１０に記載の情報処理方法。

【請求項12】

前記障害情報を取得した場合に、前記異常が、前記外部システムの影響を受けたものであると推定する、
請求項１１に記載の情報処理方法。

【請求項13】

前記外部システムは、前記情報処理装置の管理者が管理していないシステムである、
請求項１１または１２に記載の情報処理方法。

【請求項14】

前記異常検知モデルは、前記第一のシステムに含まれる一つ以上の装置において計測された複数種類の計測値を入力とし、前記第一のシステムに対する異常スコアを出力する機械学習モデルであり、
前記異常スコアが所定の閾値を超えている場合に、前記第一のシステムにおいて異常が発生していると判定する、
請求項１１に記載の情報処理方法。

【請求項15】

前記障害情報に基づいて、前記外部システムにおいて障害が発生している時間帯を判定する、
請求項１４に記載の情報処理方法。

【請求項16】

前記時間帯における、前記異常検知モデルの入力と出力を解析することで、前記外部システムの障害に起因した前記異常スコアの変化に対して所定値以上の貢献度を持つ前記計測値を特定する、
請求項１５に記載の情報処理方法。

【請求項17】

前記異常検知モデルについて、前記特定した計測値に対応する重みを補正する、
請求項１６に記載の情報処理方法。

【請求項18】

前記貢献度が所定値を上回る計測値について、重みを小さくする補正を行う、
請求項１７に記載の情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、障害検知技術に関する。

【背景技術】

【0002】

通信網やサーバ装置を含む情報処理システムに発生した異常を検知するための技術がある。これに関して、例えば、特許文献１には、高精度なアノマリ検知を可能にする機械学習モデルを生成する方法が開示されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第７００４４７９号公報

【発明の概要】

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

【0004】

機械学習の発展に伴い、障害検知の分野において機械学習モデルを活用するケースが増えることが予想される。

【0005】

本開示は、障害検知の精度を向上させることを目的とする。

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

【0006】

本開示の実施形態の一態様は、
異常検知モデルを利用して、第一のシステムにおいて異常が発生しているか否かを判定することと、前記第一のシステムに異常が発生したと判定された場合に、前記異常が、前記第一のシステムに接続されている外部システムの障害の影響を受けたものであるか否かを推定することと、前記判定された異常が、前記外部システムの障害の影響を受けたものであると推定される場合に、前記外部システムの障害の影響が小さくなるように、前記異常検知モデルを更新することと、を実行する制御部を含む、情報処理装置である。

【0007】

本開示の実施形態の一態様は、
情報処理装置が実行する方法であって、異常検知モデルを利用して、第一のシステムにおいて異常が発生しているか否かを判定することと、前記第一のシステムに異常が発生したと判定された場合に、前記異常が、前記第一のシステムに接続されている外部システムの障害の影響を受けたものであるか否かを推定することと、前記判定された異常が、前記外部システムの障害の影響を受けたものであると推定される場合に、前記外部システムの障害の影響が小さくなるように、前記異常検知モデルを更新することと、を含む、情報処理方法である。

【0008】

また、他の態様として、上記の方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

【発明の効果】

【0009】

本開示によれば、障害検知の精度を向上させることができる。

【図面の簡単な説明】

【0010】

【図1】第一の実施形態に係るデータ収集システムの概要図。

【図2】車両および車載装置が有するハードウェアの構成の一例。

【図3】サーバ装置のハードウェア構成の一例。

【図4】異常検知装置のハードウェア構成の一例。

【図5】車載装置のソフトウェア構成を模式的に示した図。

【図6】サーバ装置のソフトウェア構成を模式的に示した図。

【図7】異常検知装置が取得する計測データの一例。

【図8】異常検知装置のソフトウェア構成を模式的に示した図。

【図9】モデル生成部の動作を説明する図。

【図10】判定部の動作を説明する図。

【図11】モデル更新部の動作を説明する図。

【図12】車載装置、サーバ装置、異常検知装置が行う処理のシーケンス図。

【図13】異常検知モデルを生成する処理のフローチャート。

【図14】異常検知モデルを利用した異常検知処理のフローチャート。

【図15】異常検知モデルを更新する処理のフローチャート。

【図16】障害が発生した時間帯を説明する図。

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

【0011】

複数の車両（プローブカー）によって取得されたセンサデータを、サーバ装置によって収集するシステムがある。複数の車両からデータを収集することで、例えば、最新の渋滞情報といった様々な情報を生成し、車両に提供することが可能になる。

【0012】

また、このようなデータ収集システムにおいて、異常が発生したことを判定するための技術がある。例えば、システムに含まれる通信網やサーバ装置から様々な計測値を収集し、これを、異常判定を行うための機械学習モデルに入力することで、システムに発生している異常の度合いを示すスコアを得ることができる。また、当該スコアに基づいて自動的にアラートを発することができる。

【0013】

しかし、既存の技術では、システムの一部のみに障害が発生した場合であっても、全体として異常判定がされてしまうという問題がある。例えば、通信網の一部に障害が発生しているが、全体として機能を維持しているような場合、障害が続いている限り、異常判定が続いてしまい、新規に発生しうるその他の異常（例えば、ハードウェア障害）を検知できなくなってしまう。
本開示に係る情報処理装置は、斯様な問題を解決する。

【0014】

本開示の一態様に係る情報処理装置は、異常検知モデルを利用して、第一のシステムにおいて異常が発生しているか否かを判定することと、前記第一のシステムに異常が発生したと判定された場合に、前記異常が、前記第一のシステムに接続されている外部システムの障害の影響を受けたものであるか否かを推定することと、前記判定された異常が、前記外部システムの障害の影響を受けたものであると推定される場合に、前記外部システムの障害の影響が小さくなるように、前記異常検知モデルを更新することと、を実行する制御部を含む。

【0015】

第一のシステムとは、典型的には、複数のノードからデータを収集して処理するシステムである。第一のシステムは、複数のノード、ノードから送信されたデータを収集するサーバ装置、および、これらを接続する通信網を含んでいてもよい。第一のシステムに含まれるノード、サーバ装置、および通信網はそれぞれ複数であってもよい。

【0016】

異常検知モデルは、第一のシステムにおいて異常が発生しているか否かを判定するためのモデルである。異常検知モデルは、例えば、第一のシステムに含まれる一つ以上の装置において計測された複数の計測値を入力とし、第一のシステムの異常度（異常スコア）を出力する機械学習モデルであってもよい。異常検知モデルは、正常時に得られた計測値、または異常発生時に得られた計測値に基づいて事前に学習されたものであってもよい。制
御部は、異常スコアに基づいて、第一のシステムに何らかの異常が発生していることを判定することができる。

【0017】

また、制御部は、異常検知モデルによって判定された異常が、第一のシステムに接続されている外部システムの障害の影響を受けたものであるか否かを推定する。例えば、第一のシステムに、セルラ通信網や、計算リソースを提供するクラウドサーバなどが接続されている場合、これらの外部システムの障害に起因して、異常検知モデルが異常判定を下す可能性がある。

【0018】

制御部は、外部システムに含まれる通信網またはサーバ装置の障害を通知する障害情報を取得してもよい。当該障害情報は、情報処理装置の管理者の管理責任が及ばない通信網またはサーバ装置の障害を通知する情報を含むものであってもよい。
制御部は、当該障害情報を取得した場合に、判定された異常が、外部システムの影響を受けたものであると推定してもよい。

【0019】

制御部は、取得した障害情報に基づいて、異常検知モデルを更新してもよい。
制御部は、例えば、既知である外部システムの障害が異常判定の対象から除外されるように、異常検知モデルを更新してもよい。例えば、制御部は、外部システムの障害に起因して、異常検知モデルが閾値を超えた異常スコアを出力しなくなるように、異常検知モデルを更新してもよい。

【0020】

かかる構成によると、第一のシステムに含まれない通信網やサーバ装置の障害を、異常判定の対象から除外することができる。これにより、外部システムにおいて障害が発生したとしても、第一のシステムのみを対象として監視を継続することが可能になる。

【0021】

制御部は、障害情報に基づいて、外部システムに障害が発生している時間帯を判定してもよい。また、当該時間帯における、異常検知モデルの入力と出力を解析することで、外部システムの障害に起因した異常スコアの変化に対して所定値以上の貢献度を持つ計測値を特定してもよい。
例えば、機械学習モデルに対する入力データと出力データを解析することで、出力データに対する入力データの貢献度を算出する技術がある。これを、外部システムに障害が発生している時間帯を対象として実行することで、「外部システムの障害と相関がある計測値」を特定することができる。

【0022】

例えば、外部システムの障害に起因する異常判定を抑制したい場合、特定された計測値に対する重みを小さくするという方法がある。このため、制御部は、貢献度が所定値を上回る計測値について、重みを小さくする補正を行ってもよい。
これにより、外部システムの障害に起因して、異常検知モデルが閾値を超えた異常スコアを出力してしまうことを抑制することができる。すなわち、現在発生している既知の障害に起因して継続して異常判定がなされることを抑制することができ、それ以外の障害発生に備えることができる。

【0023】

以下、本開示の具体的な実施形態について図面に基づいて説明する。各実施形態に記載されているハードウェア構成、モジュール構成、機能構成等は、特に記載がない限りは開示の技術的範囲をそれらのみに限定する趣旨のものではない。

【0024】

（第一の実施形態）
第一の実施形態に係るデータ収集システムの概要について、図１を参照しながら説明する。本実施形態に係るデータ収集システムは、車載装置１０が搭載された車両１と、サーバ装置２と、異常検知装置３と、を含んで構成される。データ収集システムに含まれる車
両１（および車載装置１０）、サーバ装置２は、複数台であってもよい。

【0025】

車両１は、データを取得するためのプローブ車両である。車両１は、走行中においてデータを取得可能に構成され、取得したデータを、車載装置１０を介して、サーバ装置２に送信することができる。
車両１が取得するデータとして、例えば、車両の速度、進行方向、位置情報、運転操作に関する情報、車両の挙動に関する情報、または車載カメラが撮影した画像データ等が例示できる。
以降の説明において、車両１が取得するデータをセンサデータと称する。なお、車両１が取得するデータは、必ずしもセンシングによって得られたものである必要はない。

【0026】

サーバ装置２は、車両１から収集したセンサデータに基づいて、所定のサービスを提供する装置である。例えば、複数の車両１から位置情報や速度情報を収集することで、渋滞情報や交通情報を生成し、他の車両に対して提供することができる。また、車載カメラが捉えた画像を収集することで、道路地図データを生成することが可能になる。
サーバ装置２は、複数の車両１に対して所定のセンサデータの送信を要求し、車両１（車載装置１０）が、これに応答してセンサデータの送信を行う。

【0027】

サーバ装置２は、自装置単独によってサービスの提供を行ってもよいし、追加の計算リソースを提供する外部サービス（クラウドサービス等）を利用してサービスの提供を行ってもよい。

【0028】

サーバ装置２は、車両１から収集したセンサデータに基づいて、車両１（または他の車両）に対してサービスを提供する装置であってもよいし、車両１から収集したセンサデータを、さらなる外部装置に提供する装置であってもよい。例えば、車両１から収集されるセンサデータの種類が複数ある場合、サーバ装置２は、センサデータの種類ごとに、異なる事業者の管理下にある、異なる外部装置にセンサデータをそれぞれ提供してもよい。

【0029】

サーバ装置２は、データの収集および処理の状況に関するデータ（以下、計測データ）を取得可能に構成される。計測データとは、センサデータの収集および処理に関与する装置またはネットワークの状況を示す一つ以上の計測値を含む。計測値は、ネットワークのステータスに関する値（例えば、レイテンシ等）であってもよいし、ハードウェアのステータスに関する値（例えば、プロセッサの使用率等）であってもよい。
なお、本実施形態では、サーバ装置２を単一の装置としたが、サーバ装置２は複数の装置（仮想マシンを含む）を含んで構成されてもよい。この場合、計測データは、複数の装置においてそれぞれ計測された値を含んでもよい。
計測データは、異常検知装置３に送信される。

【0030】

異常検知装置３は、サーバ装置２から送信された計測データに基づいて、データ収集システムに何らかの異常が発生していることを検知する装置である。異常検知装置３は、例えば、複数の計測値を入力データとし、異常の度合いを表すスコア（Anomaly Score，以
下、異常スコア）を出力する機械学習モデルによって、データ収集システムに異常が発生していることを検知することができる。

【0031】

斯様な構成によると、データ収集システムのいずれかに障害が発生した場合に、これを検知することが可能になる。しかし、単純に計測データに基づいて異常判定を行うだけでは、異常を適切に検知できないケースが生じうる。

【0032】

例えば、データ収集システムに、複数のシステムが含まれており、当該複数のシステムのいずれかに障害が発生したケースを考える。複数のシステムのうちの一部に障害が発生
した場合であって、全体として機能を維持しているような場合、障害が続いている限り、異常判定が続いてしまい、新規に発生しうるその他の異常を判定できなくなってしまう。
さらに、図１に示したネットワークやクラウドサービスなど、データ収集システムの管理者の管理責任が及ばない部分において障害が発生した場合、異常判定が続くことで、自己が管理する装置の異常が検知できなくなってしまうという問題が生じる。

【0033】

そこで、本実施形態では、異常検知装置３が、外部から提供される既知の障害情報を取得し、既知の障害が検知されなくなるよう（あるいは、検知されにくくなるよう）、機械学習モデルを適宜更新する。障害情報は、障害情報サーバ４から提供される。障害情報サーバ４は、通信インフラ（例えば、セルラ通信網）等、データ収集システムの管理者の管理責任が及ばない部分において発生した障害に関する情報（障害情報）を提供するサーバ装置である。具体的な方法については後述する。

【0034】

［ハードウェア構成］
次に、システムを構成する各装置のハードウェア構成について説明する。図２は、本実施形態に係る車両１および車載装置１０が有するハードウェアの構成の一例を模式的に示した図である。
車両１は、車載装置１０、無線通信モジュール１１、およびセンサ群１２を有して構成される。

【0035】

車載装置１０は、プロセッサ（ＣＰＵ、ＧＰＵ等）、主記憶装置（ＲＡＭ、ＲＯＭ等）、補助記憶装置（ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等）を有するコンピュータとして構成することができる。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に合致した各機能（ソフトウェアモジュール）を実現することができる。ただし、一部または全部の機能は、例えば、ＡＳＩＣ、ＦＰＧＡ等のハードウェア回路によってハードウェアモジュールとして実現されてもよい。
車載装置１０は、車両１が有するネットワークバスに接続される。

【0036】

無線通信モジュール１１は、ネットワーク経由で他の装置（または外部ネットワーク）と無線通信を行う通信装置である。無線通信モジュール１１は、車両１が有するコンポーネントを、車両外部のネットワークに接続するためのゲートウェイとして機能する。例えば、無線通信モジュール１１は、車載装置１０に対して、外部ネットワークへのアクセスを提供する。これにより、車載装置１０は、無線通信モジュール１１を介して、外部装置と通信を行うことができる。
無線通信モジュール１１が利用する通信方式は、セルラ通信網を利用したものであってもよいし、ＤＳＲＣや車々間通信を利用したものであってもよい。また、無線通信モジュール１１が利用する通信方式は、Ｗｉ－Ｆｉ（商標登録）やＢｌｕｅｔｏｏｔｈ（商標登録）を利用した、比較的近距離で通信を行う方式であってもよい。

【0037】

センサ群１２は、車両１が有する複数のセンサの集合である。複数のセンサは、例えば、速度センサ、加速度センサ、および、ＧＰＳモジュールなど、車両の走行に関するデータを取得するものであってもよい。また、複数のセンサは、画像センサ、照度センサ、および、雨量センサなど、車両１の走行環境に関するデータを取得するものであってもよい。また、センサ群１２は、車両周辺を撮像するカメラ（画像センサ）を含んでいてもよい。

【0038】

車載装置１０について詳しく説明する。車載装置１０は、制御部１０１、記憶部１０２、通信モジュール１０３、および入出力装置１０４を有して構成される。車載装置１０は
、車両の乗員に情報を提供する装置（例えば、カーナビゲーション装置）であってもよい。

【0039】

制御部１０１は、所定のプログラムを実行することで、車載装置１０の各種機能を実現する演算ユニットである。制御部１０１は、例えば、ＣＰＵ等のハードウェアプロセッサによって実現することができる。また、制御部１０１は、ＲＡＭ、ＲＯＭ（Read Only Memory）、キャッシュメモリ等を含んで構成されてもよい。

【0040】

記憶部１０２は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。記憶部１０２には、制御部１０１にて実行されるプログラム、当該プログラムが利用するデータ等が記憶される。

【0041】

通信モジュール１０３は、車載装置１０を車内ネットワークに接続するための通信インタフェースである。通信モジュール１０３は、例えば、ＣＡＮ（Controller Area Network）プロトコルによって通信を行うネットワークインタフェースボードを含むように構成
されてよい。車載装置１０は、通信モジュール１０３を介して、車両１が有する他の構成要素との間でデータ通信を行うことができる。

【0042】

入出力装置１０４は、車両の乗員が行った入力操作を受け付け、乗員に対して情報を提示する手段である。具体的には、入出力装置１０４は、マウス、キーボード等の入力を行うための装置、及びディスプレイ、スピーカ等の出力を行うための装置を含む。入出力装置は、例えば、タッチパネルディスプレイ等により一体的に構成されてもよい。

【0043】

図３は、本実施形態に係るサーバ装置２のハードウェア構成の一例を模式的に示した図である。サーバ装置２は、制御部２１、記憶部２２、および通信モジュール２３を有するコンピュータとして構成される。

【0044】

サーバ装置２は、車載装置１０と同様に、プロセッサ（ＣＰＵ、ＧＰＵ等）、主記憶装置（ＲＡＭ、ＲＯＭ等）、補助記憶装置（ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等）を有するコンピュータとして構成することができる。ただし、一部または全部の機能（ソフトウェアモジュール）は、例えば、ＡＳＩＣ、ＦＰＧＡ等のハードウェア回路によってハードウェアモジュールとして実現されてもよい。

【0045】

制御部２１は、所定のプログラムを実行することで、サーバ装置２の各種機能（ソフトウェアモジュール）を実現する演算ユニットである。制御部２１は、例えば、ＣＰＵ等のハードウェアプロセッサによって実現することができる。また、制御部２１は、ＲＡＭ、ＲＯＭ（Read Only Memory）、キャッシュメモリ等を含んで構成されてもよい。

【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】

具体的には、モデル更新部３１４は、障害に起因した異常スコアの変化に対する貢献度を、複数の計測値のそれぞれについて算出する。
例えば、機械学習モデルにおいて、出力に影響を与える入力の貢献度を算出する技術がある。斯様な技術として、例えば、ＳＨＡＰ（Shapley Additive exPlanations）といっ
たものがある。これにより、閾値を超える異常スコアが出力された際に、当該異常スコアに影響を及ぼした要因（計測値）を特定することができる。

【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】

１・・・車両
２・・・サーバ装置
３・・・異常検知装置
４・・・障害情報サーバ
１０・・車載装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】