AIを活用したシステム監視とは？異常検知におけるAIの活用領域と人が確かめる領域

企業のITシステムは、クラウドやコンテナ、分散データベースなどの利用拡大に伴い複雑化しています。監視対象や取得するデータが増える一方、すべてのアラートを人が確認し、原因を一つずつ調査する方法では、運用担当者の負担が増加しやすくなります。

こうした背景から、システム監視を効率化する方法として、AI（人工知能）や機械学習の活用が進んでいます。正常時の傾向から外れた動きを自動で検知したり、大量のアラートを整理したりすることで、担当者が確認する範囲を絞り込める可能性があります。ただし、AIが示した異常や原因候補を、そのまま本番環境への対応につなげられるとは限りません。

本記事では、システム監視にAIが求められる理由やAIを活用できる領域、人による確認が必要な場面、異常検知の精度を高めるための考え方について解説します。

なお、データベースを安定的に運用していくためのポイントを知りたい方は、こちらの資料も併せてご覧ください。

なぜシステム監視にAIが求められるのか

従来のシステム監視では、CPU使用率やメモリ使用量、レスポンスタイムなどに一定の閾値を設定し、基準を超えた場合にアラートを通知する方法が広く利用されています。

こうした監視方法は現在も有効ですが、システム構成や監視対象が複雑になるなか、固定的な条件だけで状況を判断することが難しい場面も増えています。

閾値監視・人力監視だけでは判断しにくいケースがある

閾値監視では、「CPU使用率が80％を超えたら通知する」といった条件をあらかじめ設定します。異常を一定の基準で検知できる反面、その数値が本当に異常を示しているのかまでは判断できません。

例えば、毎日決まった時間にバッチ処理が実行され、CPU使用率が一時的に高くなるシステムでは、正常な処理であってもアラートが発生する可能性があります。一方、普段は20％程度で推移している処理が50％まで上昇した場合、設定した閾値には達していなくても、通常とは異なる変化が起きているケースがあります。アラートが増えすぎると、本当に確認が必要な通知が埋もれたり、オンコール担当者が確認作業に追われたりする要因にもなります。

そこで考えられるのが、過去のデータから通常時の傾向を把握し、「いつもと異なる動き」を機械学習などによって検出する方法です。

クラウド・分散システムでは監視対象も増えている

クラウドやマイクロサービス、コンテナなどを組み合わせた環境では、一つのサービスを構成するサーバーやアプリケーション、データベース、ネットワークなどが複数に分かれています。

そのため、異常が発生した際に一つのメトリクスを見るだけでは、どこで問題が起きているのか判断しにくいケースがあります。

データベースでも、CPUやメモリなどのリソース情報だけでなく、SQLの実行状況、セッション、待機イベントなどをあわせて確認しなければ、性能低下の背景を把握できない場合があります。

監視対象が増えるほど、人がすべてのデータを常時比較することは難しくなります。こうした大量の観測データから変化や関連性を見つける場面で、AIや機械学習の活用が期待されています。

AIを活用したシステム監視でできること

AIを活用したシステム監視は、「監視業務をすべてAIに置き換える仕組み」ではありません。現在のAIOps（Artificial Intelligence for IT Operations）では、異常検知のほか、アラートの集約・相関分析、原因候補の提示、定型的な対応の自動化など、インシデント対応の各工程を支援するために活用が進んでいます。

なかでも、通常時とは異なる動きの検知、大量に発生するアラートの整理、原因調査の候補提示などは、AIを活用しやすい領域です。人がすべてのデータを常時確認するのではなく、AIによって確認対象を絞り込み、担当者の判断や調査を支援することが、現在のシステム監視における主な活用方法といえます。

異常検知・障害予兆の把握

機械学習を活用した異常検知では、過去のメトリクスなどから通常時の傾向を把握し、そこから外れる動きを検出します。

例えば、曜日や時間帯によって負荷が変化するシステムであれば、一定の数値だけを見るのではなく、過去の同じ曜日・時間帯との違いなどを分析できます。これにより、固定閾値には達していなくても、通常とは異なる変化を捉えられる可能性があります。大量の観測データを継続的に分析できるため、人が見つけにくい変化の抽出にも役立ちます。

また、複数のデータを継続的に分析することで、性能劣化につながり得る傾向を早い段階で把握することも、AI・機械学習の活用領域に含まれます。ただし、「異常として検知されたこと」と「障害が発生すること」は同じではありません。検知結果は、担当者が詳しく確認する対象を絞るための情報として扱う必要があります。

なお、障害の予兆に関する考え方については、以下の記事で解説しています。

アラートノイズの削減や原因調査の叩き台をつくる

AIは、異常そのものを見つけるだけでなく、アラートの整理や分析にも活用できます。同じ障害から発生した複数のアラートをまとめたり、関連性の低い通知を除外したり、過去のインシデントと照合したりする処理にも活用が進んでいます。

例えば、一つの障害によってサーバーやアプリケーション、データベースなどから複数のアラートが発生した場合、それぞれを個別に確認するだけでは、同じ原因から生じたものか判断しにくいことがあります。AIを活用してアラート同士の時間的な近さや関連性を分析することで、一連の事象としてまとめられる可能性があります。

さらに、メトリクスやログなどの情報を関連付け、「このサービスの変化が起点になっている可能性がある」「過去のこの障害と似ている」といった原因調査の候補を提示する活用方法もあります。

大量のデータから関連性の高い情報を抽出し、調査の優先順位を付ける処理にはAIを活用しやすい一方、提示された候補が実際の原因かどうかを判断するには、人による確認が必要です。AIに原因そのものを決定してもらうというより、担当者がどこから調査すればよいかを判断するための叩き台を得るイメージです。

なお、アラート後の対応や運用自動化については、以下の記事で解説しています。

AIの判断をそのまま使わず、人が検証する

ここまで紹介した異常検知やアラートの整理、原因候補の提示などは、AIを活用できる領域です。一方、提示された結果が実際の状況と合っているか、本番環境で対応を実行して問題がないかを判断する工程は、人が確かめる領域です。

AIを使って異常を検知したり、原因候補を絞り込んだりできても、提示された結果をそのまま本番環境への操作につなげる際には注意が必要です。AIによる分析結果は、あくまで入力されたデータや学習したパターンを基に導き出されます。システムの業務上の位置づけや、当日の特殊な運用状況まで常に把握しているとは限りません。

検証せずに適用すると想定外の影響が生じる可能性がある

例えば、AIが「データベースへの負荷が高いため、特定の処理を停止する」と提案したとしても、その処理が決算や受注などの重要な業務に関係していれば、停止による影響のほうが大きくなる可能性があります。

また、異常検知では誤検知や見逃しが発生する可能性もあります。システム構成の変更や新しいサービスの追加によって、これまでの「通常」が変化すれば、過去の傾向との比較だけでは適切に判断しにくくなるためです。

AIが提示する分析結果は「確認すべき候補」として利用し、本番環境に影響する対応については、別途検証する考え方が適しています。

人が確認したい3つの観点

AIから異常や原因候補が提示された場合、システムへの想定外の影響を防ぐため、担当者は以下の3つの観点から確認します。

特に原因調査では、AIが提示した結論だけを見るのではなく、その結論につながったデータまでたどれる状態にしておくことがポイントです。根拠を確認できれば、担当者はAIの分析が現在の状況と整合しているかを判断しやすくなります。

完全自動復旧は対象を限定して考える

AIや自動化技術の発展に伴い、異常を検知し、原因を分析したうえで復旧処理まで自動で実行する仕組みも広がっています。AIOpsの分野でも、自動復旧は一つの方向性として位置づけられています。

ただし、すべての復旧操作を同じように自動化する必要はありません。例えば、手順が明確で元の状態へ戻しやすい処理であれば、事前に定義した条件に沿って自動化しやすくなります。一方、データベースの設定変更やSQLチューニング、サービス停止など、業務への影響範囲が広い操作では、人による確認を挟む運用が考えられます。

今後はAIが判断から実行まで担う範囲が広がる可能性がありますが、「AIか人か」で分けるのではなく、処理の影響度や可逆性に応じて自動化の範囲を設定することが現実的です。

AIOpsの定義やメリットについては、以下の記事で解説しています。

なお、テレメトリーデータの概念や活用事例については、以下の記事で解説しています。

AI監視の精度は観測データの質に左右される

AIによる異常検知や原因分析を高度化するうえで考えたいのが、分析対象となるデータです。高度なAIモデルを利用していても、入力される情報が限られていれば、システム内部で何が起きているのかを判断するための材料が不足します。AIOpsと可観測性を組み合わせる考え方でも、ログ・メトリクス・トレースなどの観測データが分析の基盤になります。

粗い数値だけでは原因までたどりにくい

例えば、「CPU使用率が90％になった」という情報だけがあっても、なぜ上昇したのかまでは判断できません。データベースであれば、その時間にどのSQLが動いていたのか、どのセッションで待機が発生していたのか、I/Oやロックの状況に変化がなかったかなど、複数の情報を組み合わせる必要があります。

観測データを考える際は、次のように複数の軸から整理できます。

• 縦方向：インフラ、OS、アプリケーション、データベースなどの各レイヤー

• 横方向：複数のサーバー、サービス、DBインスタンス、セッションなど

• 期間：異常発生時だけでなく、発生前後や通常時の履歴

• 項目：メトリクス、ログ、トレース、SQL、待機イベントなど

一つの数値だけを見るよりも、異なる粒度・レイヤーのデータを関連付けられる状態のほうが、AIと人の双方が原因を検証するための材料を得やすくなります。

定量データに「普段との違い」を組み合わせる

同じCPU使用率80％でも、それが正常か異常かはシステムによって異なります。毎日80％前後まで上昇する時間帯であれば、正常な挙動かもしれません。一方、通常は20％程度で推移するシステムが突然80％になった場合は、調査が必要な変化である可能性があります。そのため、異常時のデータだけでなく、正常時の状態を継続して記録しておくことがポイントになります。

曜日や時間帯、月末処理、バッチ実行、リリース直後といった運用上の文脈もあわせて把握できれば、「数値が高いか低いか」だけではなく、「いつもと比べてどう違うか」という観点から分析できます。

AI活用の前提として可観測性を整える

こうした考え方につながるのが、可観測性（Observability）です。可観測性とは、システムから取得したさまざまなデータを通じて、内部でどのような状態や振る舞いが起きているのかを把握できるようにする考え方です。

日本エクセムの「exemONE」は、サーバーやアプリケーション、クラウドリソースなどの情報を一元的に収集・可視化する、フルスタックのオブザーバビリティプラットフォームです。データベース領域では、SQLやセッション、リソース状況などの情報を取得・可視化し、時系列で分析できる環境を提供しています。

こうした詳細な観測データを平時から蓄積しておけば、現在のトラブル調査に利用できるだけでなく、将来的にAIによる異常検知や原因分析を高度化する場合にも、その判断材料として活用できます。

つまり、AIを導入してからデータを集め始めるのではなく、AIによる分析に必要な情報をあらかじめ取得できる状態にしておくことが、監視高度化の土台になります。

AI監視を始めるための進め方

AI監視を検討する場合も、最初からすべてのシステムへAIを適用する必要はありません。まずは監視対象と観測データを整理し、異常をどのように検知するのか、人がどの段階で確認するのかを決めながら、対象を広げていく方法があります。

重要なシステム・データベースから始める

最初に、障害が発生した場合の影響が大きく、現在の監視や原因調査に課題があるシステムを整理します。例えば、障害が発生するたびにログ収集から始めているデータベースや、アラートは発生するものの原因調査に時間がかかっているシステムなどが候補になります。

まずは、一部のシステムで平常時と異常時のデータを蓄積し、どの情報が原因調査に役立ったのかを確認することで、自社に必要な監視項目も整理しやすくなります。

まず可観測性を整える

次に取り組みたいのが、AIによる分析に用いる観測データを整えることです。異常発生時だけログを収集するのではなく、通常時から継続してメトリクスやログ、SQL、セッションなどを取得します。

あわせて、「どのシステムとどのDBがつながっているのか」「どの処理がどのリソースを利用しているのか」といった関係性を追える状態にしておけば、異常検知後の原因調査にも利用できます。

AI監視を高度化するうえでは、AIそのものを導入する前に、判断材料となるデータを揃えられる監視環境になっているかを確認することが一つの出発点です。

exemONEでシステムの観測データを収集・可視化する

日本エクセムが提供する「exemONE」では、データベースをはじめ、サーバーやアプリケーションなど、複数レイヤーの情報を一元的に可視化できます。特にデータベースでは、表面的なリソース情報だけでなく、SQLやセッションなど、性能低下の背景を確認するための詳細な情報まで掘り下げられます。

現時点でAIに運用判断のすべてを任せることを前提とするのではなく、まず「何が起きているか」「なぜ起きているか」を人が確認できるデータ基盤を整えることが重要です。そのうえで、異常検知や分析、自動化の対象を段階的に広げていくことが、AI時代のシステム監視を考える一つの方法です。

exemONEの詳細については、製品ページをご確認ください。

まとめ

AIや機械学習をシステム監視に活用することで、通常とは異なる挙動の検知やアラートの整理、原因調査の候補提示など、運用担当者の判断を支援できる領域は広がっています。一方、AIの分析結果だけで本番環境への対応を決めるのではなく、根拠となるデータや過去の状態、業務への影響を人が確認する工程も必要です。

また、AIによる異常検知や分析を高度化するには、通常時から詳細な観測データを蓄積し、システム内部の状態を追える環境が土台になります。

システム監視におけるAIの活用範囲を検討する際は、まず自社のシステムをどこまで観測できているかを確認し、可観測性の整備から始めることも選択肢となります。exemONEは、データベースを含むシステムの詳細な状態を収集・可視化し、こうした監視高度化のためのデータ基盤づくりを支援します。