AIOpsとは？AI監視で自動化できることと導入の進め方・限界

「AIOps」という言葉は聞くものの、具体的に何が自動になるのか、自社の規模で導入する意味があるのかは分かりにくいものです。この記事では、AIOps が運用のどの作業を肩代わりするのかを作業ごとに分けて説明し、従来の閾値による監視との違い、小さく始める手順、そして AI に任せきれない部分を整理します。

AIOps とは

AIOps は「AI for IT Operations」の略で、IT システムの運用に機械学習や AI を使う考え方と、そのための製品群を指します。調査会社の Gartner が製品の分類として定義した言葉で、大量の運用データ (メトリクス、ログ、イベント、変更履歴) を集めて機械学習で分析する製品を指していました。

ここ数年で、AIOps の中身は二つの系統に分かれてきました。

一つは、統計や機械学習で「いつもと違う値」を見つける系統です。過去のデータから正常な範囲を学び、そこを外れた値を知らせます。クラウドの監視サービスに組み込まれている異常検知の機能の多くはこちらです。

もう一つは、大規模言語モデル (LLM) を使う系統です。アラートの内容、関連するログやデータ、過去の対応記録を LLM に読ませ、原因の候補や対処案を文章で出させます。数値の判定だけでなく、「この値の動きは、月末の締め処理によるものなので問題ない」といった文脈を踏まえた判断を担わせようとするものです。

どちらも目的は同じで、人が見なければならないアラートを減らし、障害に気づいてから原因にたどり着くまでの時間を短くすることです。

AIOps が自動化する作業

運用の作業を順に並べると、AIOps が手を出す場所が分かりやすくなります。障害対応はおおむね「データを集める → 異常に気づく → 通知を絞る → 原因を切り分ける → 対処する」の順に進みます。

1. データを集めて揃える

異常検知も原因の切り分けも、材料となるデータがなければ始まりません。AIOps の製品はサーバーのメトリクス、アプリケーションのログ、デプロイや設定変更の履歴などを一か所に集め、時刻やホスト名、サービス名の表記を揃えます。

地味な工程ですが、ここが崩れていると後ろの工程がすべて狂います。たとえばログの時刻が UTC、メトリクスが日本時間のままだと、「デプロイの直後にエラーが増えた」という相関を見落とします。

2. 異常を検知する

従来の監視は「CPU 使用率が 90% を超えたら通知」のような固定の閾値で判定します。AIOps では過去の推移から「この曜日のこの時間なら、この範囲に収まるはず」という予測の幅を作り、そこを外れたときに知らせます。

具体例として、AWS の CloudWatch の異常検知は、最大 2 週間分のメトリクスから傾向と時間・日・週の周期を学び、予想される値の帯を作ります。帯の太さは閾値のパラメータで調整でき、デプロイのような普段と違う期間を学習から除くこともできます。

この方式が向いているのは、時間帯や曜日で値が大きく変わる指標です。夜間は少なく昼に多いアクセス数に固定の閾値を置くと、昼に合わせれば夜の落ち込みを見逃し、夜に合わせれば昼に鳴りっぱなしになります。手法の詳細は「異常検知とは」で説明しています。

3. アラートのノイズを減らす

一つの障害はたいてい複数のアラートを同時に鳴らします。DB が止まれば、DB の死活監視、アプリのエラー率、API の応答時間、外形監視が一斉に赤くなります。担当者のスマートフォンに数十件の通知が届くこともありますが、原因は一つです。

ノイズを減らす方法は昔からある規則による方法と、AIOps らしい学習による方法に分かれます。

規則による方法の代表が Prometheus の Alertmanager にある三つの機能です。似たアラートを一つの通知にまとめる「グルーピング」、上位の障害が起きているあいだ下位のアラートを黙らせる「抑制 (inhibition)」、メンテナンス中などに期間を決めて通知を止める「サイレンス」です。

AIOps の製品はこれに加えて、同時に発生しやすいアラートの組み合わせや、構成情報 (どのサービスがどの DB に依存しているか) から、関連するアラートを自動でまとめます。過去に「鳴ったが何もしなかった」アラートを学び、優先度を下げる仕組みもあります。

アラートが多すぎて大事な通知を見落とす状態は「アラート疲れ」と呼ばれます。対策の全体は「アラート疲れの原因と対策」にまとめています。

4. 原因を切り分ける

異常に気づいたあと、最も時間がかかるのが原因の切り分けです。人は通常、次のような順に調べます。

• 直前にデプロイや設定変更がなかったか
• 同じ時刻にほかの指標も動いていないか
• 影響は一部の顧客・機能・サーバーに偏っていないか
• 過去に似た障害がなかったか

AIOps はこの手順を機械的に回します。変更履歴と異常の時刻を突き合わせる、同時に動いた指標を並べる、影響の偏りを集計する、といった作業です。LLM を使う製品ではさらにログやデータベースの中身を調べ、「何が起きて、どこに影響し、何が根拠か」を文章にまとめます。

ただし、ここで出てくるのはあくまで「原因の候補」です。同時に動いた二つの指標のどちらが原因かは、データの相関だけでは決まりません。根拠として何を見たのかが人に見える形で残る仕組みかどうかが、実務では大きな差になります。

5. 対処を自動化する

最後の段階が再起動やスケールアウト、キャッシュの削除といった対処の自動実行です。手順が決まっていて、失敗しても影響が小さい操作から自動化するのが一般的です。

データの削除や設定変更のように取り返しのつかない操作は、AI が提案し、人が承認してから実行する形にとどめる例が多く見られます。自動で直すことよりも、判断の根拠と実行の記録が残ることを優先したほうが、事故が起きたときに説明がつきます。

従来の監視との違い

閾値による監視、統計・機械学習による異常検知、LLM による判断を比べると、次のようになります。

これらは置き換えの関係ではありません。ディスクの残量のように限界がはっきりしたものは固定の閾値のほうが確実です。AIOps を導入しても、固定の閾値は残るのが普通です。

インフラの指標だけでなく、事業の数字を見る

AIOps の説明は、CPU やメモリ、ログといったインフラの話に偏りがちです。しかし、利用者にとっての障害はインフラの異常として現れないことがあります。

たとえば決済代行サービスの仕様変更で、特定のカード会社の決済だけが失敗し続けているとします。サーバーは元気で、エラー率もわずかしか上がりません。気づけるのは、データベースの「決済の成功件数」や「1 時間あたりの注文数」を見ている場合だけです。同じように、夜間バッチが止まって未処理のジョブが溜まっている、会員登録の確認メールが送られていない、といった問題も、業務データを見て初めて分かります。

Google の SRE 本は、監視は「何が壊れているか (症状)」と「なぜか (原因)」の二つに答えるべきで、呼び出しは症状に基づいて行うべきだとしています。利用者にとっての症状にいちばん近いのは、多くの場合、事業の数字です。AIOps の対象を決めるときは、インフラの指標と並べて、注文数や決済の成否、ジョブの滞留件数のような数字を入れるかどうかを検討してください。

導入の進め方

AIOps の製品は、全部入れると大がかりになります。小さく始め、効果を測りながら広げるのが現実的です。

ステップ 1: 今のアラートを棚卸しする

最初に、直近 1〜3 か月のアラートを数えます。次のような表 (数字は例です) を作るだけで十分です。

「対応が必要だった件数」が件数に比べて極端に少ないアラートはノイズの候補です。逆に、最後の行のように「アラートが鳴らずに利用者からの問い合わせで気づいた障害」は、監視の穴です。AIOps で解きたいのがノイズなのか、穴なのかで、選ぶ機能が変わります。

ステップ 2: 対象をひとつに絞る

棚卸しの結果から、損失の大きい課題をひとつ選びます。夜間の誤報で担当者が疲弊しているならノイズの削減、障害に気づくのが遅れているなら異常検知、原因の調査に毎回時間がかかっているなら原因の切り分けです。

ステップ 3: 既存の監視と並べて動かす

AIOps の判定をすぐに本番の通知に使わず、一定期間は既存の監視と並べて動かします。その間に、「AIOps だけが気づいた異常」「既存の監視だけが気づいた異常」「AIOps の誤報」を記録します。期間には、月末や週末のように値の動きが変わる日を含めてください。

ステップ 4: 誤判断を返して学ばせる

誤報だった、見逃した、という結果を AIOps 側に戻す仕組みがあるかを確認します。誤報を閉じたときの理由が残り、次の判断に反映される製品であれば、運用するほど精度が上がります。

ステップ 5: 自動化は承認付きから

対処の自動化は、影響が小さく手順の決まった操作から、人の承認を挟む形で始めます。どの操作をいつ誰が承認したかが残るようにしておきます。

AIOps の限界と注意点

AIOps は運用の判断をすべて肩代わりするものではありません。導入前に知っておきたい限界を挙げます。

学習期間にない出来事に弱い。 統計や機械学習のモデルは、過去に見た変動しか「正常」と分かりません。前述の CloudWatch の例でも学習に使うのは最大 2 週間分なので、年末年始、年度末、大型セール、テレビで紹介された日のような出来事は異常に見えます。予定された出来事は事前に除外期間として登録するか、通知を受けてから人が判断します。

ゆっくりした劣化を正常として覚えてしまう。 少しずつ遅くなるクエリや、徐々に増えるディスク使用量は、モデルが新しい推移に合わせて学び直すため、異常として扱われないことがあります。限界がはっきりしている指標には、固定の閾値を残してください。

相関は因果ではない。 同じ時刻に動いた指標を並べることはできても、どちらが原因かはデータだけでは決まりません。原因の候補を鵜呑みにせず、根拠のデータを人が確かめられることが前提です。

LLM は誤ったことをもっともらしく書く。 LLM による原因の説明は読みやすい反面、根拠のない推論が混ざることがあります。どのデータを見てその結論に至ったのか、実行したクエリや参照したログが残るかを確認してください。

運用データを外部に送ることになる。 クラウドの AIOps 製品や LLM の API を使うと、ログやデータベースの値が外部に送られます。ログには顧客のメールアドレスなどが含まれていることもあります。送る範囲と、提供元での扱い (学習に使われるか、どれだけ保存されるか) を確認しましょう。詳しくは「生成 AI に個人情報を渡すときの注意」を参照してください。

権限を絞る。 原因を調べるために AIOps に DB やサーバーへのアクセスを与える場合は、読み取り専用の権限にとどめます。調査のための権限と、対処のための権限は分けて考えます。

なお、Google の SRE 本は、閾値を学習したり因果関係を自動で検出したりする「魔法のような」システムは避ける、という立場を取っています。単純で予測しやすい規則のほうが、なぜ鳴ったのかを誰でも理解でき、保守しやすいからです。AIOps を入れる場合も、判定の理由が人に読める形で残るかどうかを選定の基準にすると、この懸念をかなり和らげられます。

AIOps と関連する言葉の違い

AIOps と混同されやすい言葉を整理しておきます。

オブザーバビリティについては「オブザーバビリティとは」、SRE については「SRE とは」で説明しています。

AI による監視を試すには

ここまでの内容を手作業で始めるなら、まずアラートの棚卸しをして、ノイズになっているアラートを止め、注文数や決済の成否のような事業の数字を定期的に集計するクエリを cron や監視ツールに登録するところからです。そのうえで、曜日や時間帯で動きが変わる指標には、監視ツールの異常検知の機能を試すとよいでしょう。

データベースの監視であれば、AI に任せる方法もあります。Scandock は、接続文字列を登録すると AI がテーブルの構成と実データを読み、注文数やジョブの滞留のような事業の数字も含めて、何を監視するかを決めます。固定の閾値ではなく、値の推移や過去の発火とその結末を踏まえて異常かどうかを判断し、異常と判断すると読み取り専用のクエリで関連データを調べ、原因・影響・根拠・対処案をつけて通知します。対処は事前に登録した SQL や通知に限られ、人が承認してから実行します。

参考

• Using CloudWatch anomaly detection - Amazon CloudWatch
• Alertmanager - Prometheus
• Monitoring Distributed Systems - Google SRE Book