特開 2024-36800 トラフィック分析装置、トラフィック分析プログラム及びトラフィック分析方法

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

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

(11)【公開番号】P2024036800

(43)【公開日】2024-03-18

(54)【発明の名称】トラフィック分析装置、トラフィック分析プログラム及びトラフィック分析方法

(51)【国際特許分類】

   H04L 43/0876 20220101AFI20240311BHJP

【ＦＩ】

H04L43/0876

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2022141279

(22)【出願日】2022-09-06

(71)【出願人】

【識別番号】000000295

【氏名又は名称】沖電気工業株式会社

(74)【代理人】

【識別番号】100180275

【弁理士】

【氏名又は名称】吉田 倫太郎

(74)【代理人】

【識別番号】100161861

【弁理士】

【氏名又は名称】若林 裕介

(72)【発明者】

【氏名】土江 康太

(57)【要約】

【課題】 単体装置でリアルタイム且つ効率的に通信トラフィックを析し異常通信を検出する。
【解決手段】 本発明は、トラフィック分析装置に関する。そして、本発明のトラフィック分析装置は、分析対象のネットワーク上を流れる通信トラフィックデータに基づく分析対象データについて、それぞれ異なる項目で分析して異常通信の有無の検知を行う検知処理部を１以上備える第１の分析手段と、１以上の検知処理部で異常通信有りと検知された分析対象データについて学習モデルを用いたＡＩ分析処理を行うＡＩ分析処理部により異常通信の有無を判定する第２の分析手段とを有することを特徴とするトラフィック分析装置。
【選択図】 図１

【特許請求の範囲】

【請求項1】

分析対象のネットワーク上を流れる通信トラフィックデータに基づく分析対象データについて、それぞれ異なる項目で分析して異常通信の有無の検知を行う検知処理部を１以上備える第１の分析手段と、
１以上の前記検知処理部で異常通信有りと検知された前記分析対象データについて学習モデルを用いたＡＩ分析処理を行うＡＩ分析処理部により異常通信の有無を判定する第２の分析手段と
を有することを特徴とするトラフィック分析装置。

【請求項2】

前記第２の分析手段に前記ＡＩ分析処理をさせる前記分析対象データの優先順位を決定する優先順位決定処理を行い、前記優先順位決定処理の結果に従った順序で、前記分析対象データについて前記第２の分析手段に前記ＡＩ分析処理を実行させる分析制御手段をさらに有することを特徴とする請求項１に記載のトラフィック分析装置。

【請求項3】

前記分析制御手段は、前記第１の分析手段で異常通信有りと検知された前記検知処理部に応じて前記分析対象データの優先順位を決定することを特徴とする請求項２に記載のトラフィック分析装置。

【請求項4】

前記分析制御手段は、前記優先順位決定処理で異常通信有りと検知した前記検知処理部の数に基づく第１の判断基準を考慮して優先順位を決定することを特徴とする請求項３に記載のトラフィック分析装置。

【請求項5】

前記分析制御手段は、前記通信トラフィックデータの送信元の属性ごとに優先すべき前記検知処理部を記述した機器種別毎優先情報を保持し、前記優先順位決定処理で異常通信有りと検知した前記検知処理部と前記機器種別毎優先情報との照合結果に基づく第２の判断基準も考慮して優先順位を決定することを特徴とする請求項４に記載のトラフィック分析装置。

【請求項6】

前記分析制御手段は、前記通信トラフィックデータの送信元に関わらず共通で優先すべき前記検知処理部を記述した機器共通優先情報を保持し、前記優先順位決定処理で異常通信有りと検知した前記検知処理部と前記機器共通優先情報との照合結果に基づく第３の判断基準も考慮して優先順位を決定することを特徴とする請求項５に記載のトラフィック分析装置。

【請求項7】

前記第２の分析手段は、前記分析対象データに係る前記通信トラフィックデータの送信元に応じた学習モデルを前記ＡＩ分析処理部に設定し、
前記分析制御手段は、前記ＡＩ分析処理部に設定する学習モデルの切替回数がより少なるような順序で前記分析対象データの優先順位を決定する
ことを特徴とする請求項２に記載のトラフィック分析装置。

【請求項8】

前記第１の分析手段で異常通信有りと検知した前記検知処理部と、前記第２の分析手段の判定結果の組合せに応じて異常通信の理由について推定する異常判定理由推定処理を行う異常判定理由推定処理手段をさらに備えることを特徴とする請求項１に記載のトラフィック分析装置。

【請求項9】

前記通信トラフィックデータの送信元ごとに、定常状態における前記通信トラフィックデータを取得し、取得した前記通信トラフィックデータに基づいて機械学習処理を行って学習モデルを取得する学習手段をさらに備えることを特徴とする請求項１に記載のトラフィック分析装置。

【請求項10】

コンピュータを、
分析対象のネットワーク上を流れる通信トラフィックデータに基づく分析対象データについて、それぞれ異なる項目で分析して異常通信の有無の検知を行う検知処理部を１以上備える第１の分析手段と、
１以上の前記検知処理部で異常通信有りと検知された前記分析対象データについて学習モデルを用いたＡＩ分析処理を行うＡＩ分析処理部により異常通信の有無を判定する第２の分析手段と
して機能させることを特徴とするトラフィック分析プログラム。

【請求項11】

トラフィック分析装置が行うトラフィック分析方法において、
前記トラフィック分析装置は、第１の分析手段と第２の分析手段とを有し、
前記第１の分析手段は、分析対象のネットワーク上を流れる通信トラフィックデータに基づく分析対象データについて、それぞれ異なる項目で分析して異常通信の有無の検知を行う検知処理部を１以上備え、
前記第２の分析手段は、１以上の前記検知処理部で異常通信有りと検知された前記分析対象データについて学習モデルを用いたＡＩ分析処理を行うＡＩ分析処理部により異常通信の有無を判定する
ことを特徴とするトラフィック分析方法。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、トラフィック分析装置、トラフィック分析プログラム及びトラフィック分析方法に関し、例えば、ネットワークを流れる通信トラフィックを収集・分析し、サイバー攻撃等の異常通信を検知するシステムに適用し得る。

【背景技術】

【0002】

現在、ＩｏＴ（Ｉｎｔｅｒｎｅｔ Ｏｆ Ｔｈｉｎｇｓ）機器は、オフィスや工場など組織の様々な環境で活用されている。企業等の組織では、組織内のネットワークに管理外の機器が接続されていないか、マルウェア感染等により不正な通信を発生させていないか等、ネットワークに接続される機器の管理を行う。従来、コアネットワークのインターネットとの接続口（コアスイッチ等）を流れる通信トラフィックをキャプチャし分析することで、接続されている機器をリストアップするとともに機器が不正な通信を行っていないかを監視（場合によっては通信遮断まで）する通信トラフィック分析装置を設置することでネットワーク機器の管理を行う方法がある。しかしながらＩｏＴ機器は、普段はインターネット接続せず、末端の生産現場やオフィス内等の閉じたネットワーク環境（エッジネットワークと呼ぶ）で使われる場合も多く、コアネットワークの監視だけではネットワーク全体を網羅できない場合がある。そのため、ＩｏＴ機器が設置されるエッジネットワークにも監視ポイントを設置しそこを流れるトラフィックをキャプチャし分析する通信トラフィック分析装置が必要となっている。

【0003】

通信トラフィック分析装置によりＩｏＴ機器による不正通信を検出するために、機械学習を用いる方法がある。機械学習により不正通信を検出する具体的な方法の一つに、ネットワークの定常通信パターンを機械学習し定常通信パターンから大きく逸脱する通信パターンを異常通信として検出する教師無し学習による方法がある。教師無し学習では、未知のマルウェア感染による通信や内部不正による情報漏洩の通信等、エッジネットワークで起こり得る異常通信を幅広く検出することができる。上記の従来における教師無し学習による不正通信検出方法では、さらに機器単位に定常通信パターンを学習した機械学習モデルを構築（つまり機器の数だけ機械学習モデルを構築）することで、機器が持つ特有の定常通信パターンを学習に反映できるため、不正通信の検出精度を高めることができる。

【0004】

ここで、エッジネットワークに設置する通信トラフィック分析装置は、監視ポイント数だけ装置が必要になるため、安価に導入できることが望ましい。そのため、エッジネットワーク向けのトラフィック分析装置が持てる計算資源は限られたものにならざるを得ない。従来、計算資源の限られたエッジ装置では、計算負荷の高い、例えば深層学習によって構築された機械学習モデルを分析するのが困難であった。しかし近年、エッジ装置でも深層学習による機械学習モデルの推論処理を実行可能にするＶＰＵ（Ｖｉｓｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が開発され実用化されている。ＶＰＵでは、ハードウェア上に機械学習モデルをロードして実行可能なものであり、ＣＰＵやメモリが潤沢でない場合にも、深層学習により構築された機械学習モデルの推論処理を高速に実行することができる。

【0005】

以上より、エッジネットワークにおける通信トラフィック分析装置は、ＶＰＵを搭載し、機器毎に定常通信パターンを学習した機械学習モデルをＶＰＵ上で動作させ、通信トラフィックをリアルタイムに分析して異常通信を検出するものが望ましい。しかし、ＶＰＵは機械学習モデルをハードウェア上にロードするため、モデルのロードに時間がかかる。そのため、機器毎に機械学習モデルを用意し、受信したトラフィックに合わせてモデルを切り替えながら分析を行う場合、モデルの切り替え時間がボトルネックとなり、リアルタイムに分析を行うことができない課題がある。よって、モデル切り替えが発生する構成においてもリアルタイムに異常通信を検出できる方法が求められている。

【0006】

上記のような背景に鑑みて、特許文献１の技術が提案されている。特許文献１の記載技術は、ＩｏＴ機器を対象に通信を収集し、機器毎に定常通信範囲を定義して、そこから逸脱する通信を異常通信として検出し通信遮断等の制御を行う通信制御装置に関するものである。特許文献１では、ＩｏＴ機器の通信量が多く単体の通信制御装置では処理しきれない場合に、他の通信制御装置との共有情報を使って解析する方法について言及されている。

【先行技術文献】

【特許文献】

【0007】

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

【発明の概要】

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

【0008】

しかしながら、特許文献１の技術は複数の通信制御装置が連携することが前提となっており、単体装置で動作させる場合には適用することができない。

【0009】

以上より、単体装置で、リアルタイム且つ効率的に通信トラフィックを分析し、異常通信を検出することができるトラフィック分析装置、トラフィック分析プログラム及びトラフィック分析方法が望まれている。

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

【0010】

第１の本発明のトラフィック分析装置は、分析対象のネットワーク上を流れる通信トラフィックデータに基づく分析対象データについて、それぞれ異なる項目で分析して異常通信の有無の検知を行う検知処理部を１以上備える第１の分析手段と、１以上の前記検知処理部で異常通信有りと検知された前記分析対象データについて学習モデルを用いたＡＩ分析処理を行うＡＩ分析処理部により異常通信の有無を判定する第２の分析手段とを有することを特徴とする。

【0011】

第２の本発明のトラフィック分析プログラムは、コンピュータを、分析対象のネットワーク上を流れる通信トラフィックデータに基づく分析対象データについて、それぞれ異なる項目で分析して異常通信の有無の検知を行う検知処理部を１以上備える第１の分析手段と、１以上の前記検知処理部で異常通信有りと検知された前記分析対象データについて学習モデルを用いたＡＩ分析処理を行うＡＩ分析処理部により異常通信の有無を判定する第２の分析手段として機能させることを特徴とする。

【0012】

第３の本発明は、トラフィック分析装置が行うトラフィック分析方法において、前記トラフィック分析装置は、第１の分析手段と第２の分析手段とを有し、前記第１の分析手段は、分析対象のネットワーク上を流れる通信トラフィックデータに基づく分析対象データについて、それぞれ異なる項目で分析して異常通信の有無の検知を行う検知処理部を１以上備え、前記第２の分析手段は、１以上の前記検知処理部で異常通信有りと検知された前記分析対象データについて学習モデルを用いたＡＩ分析処理を行うＡＩ分析処理部により異常通信の有無を判定することを特徴とする。

【発明の効果】

【0013】

本発明によれば、単体装置で、リアルタイム且つ効率的に通信トラフィックを析し、異常通信を検出することができる。

【図面の簡単な説明】

【0014】

【図1】第１の実施形態に係るトラフィック分析装置の機能的構成について示したブロック図である。

【図2】第１の実施形態に関係する各装置の接続関係について示したブロック図である。

【図3】第１の実施形態に係るトラフィック分析装置のハードウェア構成の例について示したブロック図である。

【図4】第１の実施形態に係るＡＩ分析キッカー部で用いられる優先度情報の構成例について示した図である。

【図5】第１の実施形態に係るＡＩ分析部で適用されるＡＩの構成例について示した図である。

【図6】第１の実施形態に係るトラフィック分析装置における分析処理の概要について示した図である。

【図7】第１の実施形態に係るトラフィック分析装置の動作について示したフローチャート（その１）である。

【図8】第１の実施形態に係るトラフィック分析装置の動作について示したフローチャート（その２）である。

【図9】第１の実施形態に係るトラフィック分析装置の動作について示したフローチャート（その３）である。

【図10】第１の実施形態に係るトラフィック分析装置の動作について示したフローチャート（その４）である。

【図11】第１の実施形態に係るＡＩ分析キッカー部によるＡＩ分析対象フローの優先付けの処理の具体例について示した図である。

【図12】第２の実施形態に係るトラフィック分析装置の機能的構成について示したブロック図である。

【図13】第３の実施形態に係るトラフィック分析装置の機能的構成について示したブロック図である。

【図14】第４の実施形態に係るトラフィック分析装置の機能的構成について示したブロック図である。

【図15】第５の実施形態に係るトラフィック分析装置の機能的構成について示したブロック図である。

【図16】第５の実施形態に係る異常判定事由推定部で用いられる異常理由条件リストの構成例について示した図である。

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

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

図１６に示す異常理由条件リストでは、左列から順に、非ＡＩ分析部１４で異常判定された検知エンジン名を示す「非AI分析における異常判定項目名」、ＡＩ分析部１７による判定結果を示す「ＡＩ分析判定結果」、及び「異常理由」の項目が示されている。

【0141】

つまり、図１６に示す異常理由条件リストでは、非ＡＩ分析部１４で異常判定された検知エンジン名とＡＩ分析部１７による判定結果の組合せごとの「異常理由」が定義されていることになる。異常判定事由推定部１９は、ＡＩ分析部１７でＡＩ分析処理されたフローごとに、ＡＩ分析処理の判定結果と非ＡＩ分析部１４において異常判定された検知エンジン名の情報を取得して異常理由条件リストにあてはめ、当該フローに対応する異常理由を取得することができる。

【0142】

図１６では、監視対象機器３０の通信量が普段より統計的に多いことを検出する「通信量異常」の検知エンジンを対象に、ＡＩ分析部１７での判定結果も踏まえて異常事由を出力するための条件リストを表している。異常理由条件リストにおける異常理由の項目については、例えば、予め記述されたデータを異常判定事由推定部１９に保持させるようにしてもよいし、オペレータ等により編集可能な構成としてもよい。

【0143】

図１６に示す異常理由条件リストの１行目では、非ＡＩ分析部１４の通信量異常で異常判定されＡＩ分析部１７でも異常判定された場合の異常理由として「外部からの攻撃の疑い」というテキストが記述されている。この場合、当該フローの送信元機器（監視対象機器３０）で、普段発生させない通信パターンで異常な通信量の通信が発生したことになるため、外部からの攻撃の疑いと理由付けできるため、上記のようなテキストが記述されている。

【0144】

図１６に示す異常理由条件リストの２行目では、非ＡＩ分析部１４の通信量異常で異常判定されＡＩ分析部１７で異常判定されなかった場合（正常と判定された場合）の異常理由として「内部不正によるデータ持ち出しの疑い」というテキストが記述されている。この場合、当該フローの送信元機器（監視対象機器３０）で、普段の通信パターンであるが通信量が普段より異常に多いため、内部不正によるデータ持ち出しの疑いと理由付けできるためである。

【0145】

異常判定事由推定部１９により取得されたフロー毎（送信元機器ごと）の異常理由（異常理由のテキスト）については、通知／可視化部１８に供給され所定の手段及び形式で出力されオペレータ等に提示（通知）されることになる。

【0146】

以上のように、第５の実施形態のトラフィック分析装置１０Ｄでは、ＡＩ分析部１７の結果と非ＡＩ分析部１４の結果とを組み合わせて異常理由を推定することで、異常検知後の対処方法までも明確化した情報を出力（通知／可視化部１８により出力）することができる。

【0147】

なお、第１～第３の実施形態のいずれかのトラフィック分析装置１０、１０Ａ、１０Ｂにおいて、異常判定事由推定部１９を追加する構成としてもよい。

【0148】

（Ｆ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

【0149】

（Ｆ－１）第１の実施形態では、学習部１３において、学習期間経過後に非ＡＩ分析の検知エンジン群の閾値やパターンの算出を行っていたが、学習期間でも受信した通信トラフィックデータを逐次学習するようにしても良い。例えば、普段通信しない通信先やサービス等のレア通信を検出する検知エンジンでは、実現方法として、学習期間に受信した通信トラフィックデータから通信先やサービス情報を取得しリストとして保持して、異常判定ではリストに存在しない通信先やサービスを異常とみなす方法が考えられる。このような検知エンジンでは受信した通信トラフィックデータを逐次分析してリストに追加することができるため、学習期間が終了するまで待つ必要が無い。これにより、トラフィック分析装置１０では、非ＡＩ分析の閾値計算等を逐次処理することで、学習処理負荷が分散され、学習期間完了後の学習処理負荷を軽減することができる。

【0150】

（Ｆ－２）第１の実施形態のトラフィック分析装置１０では、ＡＩ分析キッカー部１５における優先度情報１６１として、異常と判定される可能性が高いフローの優先度が高くなるようなものを用いたが、これに限定されず、機械学習モデルの切換えが少なくなるような観点を設けるようにしてもよい。例えば、ＡＩ分析キッカー部１５が、図４の優先度情報１６１を用いて最も優先度の高いフローを決定した後に、当該フローの送信元機器の他のフローに限定して次に優先度の高いフローを選択し、これを注目機器のフローが無くなるまで行うようにしてもよい。次に、ＡＩ分析キッカー部１５が、他の監視対象機器３０のフローから最も優先度の高いフローを選択し、同様に選択したフローの送信元機器のフローに限定して優先度付けしていく（ＶＰＵ２０４において機械学習モデルの切替が少なくなるような順序で優先度付けしていく）ようにしてもよい。このような優先順位付けの方法により、ＡＩ分析部１７では、同一機器のフローを連続してＡＩ分析することになるため、機械学習モデルの切換え回数が削減され、ＡＩ分析のスループットを向上させることができる。

【0151】

（Ｆ－３）上記の各実施形態の非ＡＩ分析部１４において、検知エンジンには軽量な機械学習アルゴリズム（ＶＰＵ２０４を用いる必要のないアルゴリズム）を用いるものがあっても良い。軽量な機械学習アルゴリズムとしては、例えば、ロジスティック回帰モデルや単純な決定木モデル等が挙げられる。

【0152】

（Ｆ－４）上記の各実施形態のＡＩ分析キッカー部１５では、図４のような優先度情報１６１を用いて、優先度の高い判断基準（項目名）から順に判断することで各フローの優先付けを行っているが、図４のような優先度の高い判断基準（項目名）について重視して考慮される手順であれば、他の優先付け手順を適用するようにしてもよい。例えば、ＡＩ分析キッカー部１５が、複数の判断基準（項目名）に基づく評価値を算出してその評価値に応じてフローの優先付けを行うようにしてもよい。この場合、判断基準（項目名）ごとに優先度（重要度）に応じた評価値の重みを変更するようにしてもよい。例えば、「検知項目数」の評価値の重みを「３」、「機器種別毎の優先検知エンジンの有無」の評価値の重みを「２」、「機器共通の優先検知エンジンの有無」の評価値の重みを「１」と設定するようにしてもよい。例えば、検知項目数が複数であるだけのフローの評価値は「３」、検知項目数が複数で且つ「機器種別毎の優先検知エンジンの有無」が有りとなるフローについての評価値は「５」となり、後者のフローの方が評価値が大きいため優先度が高くなる。

【符号の説明】

【0153】

１０、１０Ａ、１０Ｂ、１０Ｃ、１０Ｄ…トラフィック分析装置、１１…トラフィックキャプチャ部、１２…制御部、１３…学習部、１４…非ＡＩ分析部、１５…ＡＩ分析キッカー部、１６…記憶部、１７…ＡＩ分析部、１８…可視化部、１９…異常判定事由推定部、２０…ネットワークスイッチ、３０…監視対象機器、４０…ゲートウェイ、１６１…優先度情報、１７１…オートエンコーダ、２００…コンピュータ、２０１…ＣＰＵ、２０２…一次記憶部、２０３…二次記憶部、２０４…ＶＰＵ、Ｎ１…監視対象ネットワーク、Ｎ２…インターネット

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】