- はじめに——アラートの”入口”ではなく”出口”を設計する
- 本稿の位置づけ
- なぜ”100件鳴って、原因は1つ”が起きるのか
- イベント処理の全体像——6つの段階
- 規律1：イベントを正規化する——共通スキーマと重大度の統一
- 規律2：重複排除と抑制——”同じこと”と”知っていること”を鳴らさない
- 規律3：CMDBの依存関係で相関する——親子関係から根本イベントを特定する
- 規律4：提供元のステータスページと突き合わせる
- 規律5：ノイズ率とアラート適合率で”鳴りすぎ”と”鳴らなすぎ”を測る
- 運用サイクル——いつ、何を見るか
- よくある落とし穴
- イベント管理（EventOps）チェックリスト
- よくある質問（Q&A）
- まとめ——”100件”を”1件と、その影響範囲”に変える運用へ
- 参考リンク
- 関連記事
はじめに——アラートの”入口”ではなく”出口”を設計する
ある朝、オンコール担当のスマートフォンが鳴り止まなくなります。社内問い合わせエージェントの応答遅延、RAG検索のタイムアウト、要約エージェントのリトライ超過、ワークフローの失敗、SLOバーンレートの警告——15分のあいだに100件近いアラートが届きました。ところが調べてみると、原因は外部のLLM APIのレイテンシ悪化、ただ1つでした。
AIエージェントの運用では、こうした場面が珍しくありません。エージェント、モデル、ツール、外部APIが何層にも重なり、それぞれが自分の視点でアラートを上げるからです。結果として、オンコール担当は「どれが本当の原因か」を探すことに時間を使い、肝心の対応が遅れます。そして鳴りすぎに慣れたチームは、やがて本当に重要な1件を見逃すようになります。
筆者はネットワーク機器ベンダーのNOC（ネットワーク運用センター）で長く働いてきました。NOCでは「上位の回線が1本落ちると、その配下にある数十台の機器のアラートが一斉に鳴る」という場面が日常です。そこで行っていたのが、イベントの重複排除・抑制・相関でした。上位の障害を「親」、配下のアラートを「子」として束ね、親のイベントだけを人に渡す。本稿は、この考え方をAIエージェントの運用に持ち込みます。
本稿は、AIエージェントを業務で運用している企業の運用担当者、SRE、情報システム部門、そしてAgentOpsの仕組みづくりを任された方を対象としています。
本稿の位置づけ
AgentOpsシリーズでは、これまでアラートや障害対応に関わるテーマをいくつか扱ってきました。本稿の役割は、次の表のとおりです。
| 記事 | 扱う範囲 | キーワード |
|---|---|---|
| オブザーバビリティ編（8/18） | 何を計測し、いつアラートを鳴らすか（アラートの入口） | メトリクス、トレース、SLO、バーンレート |
| インシデント運用編（9/5） | インシデントを起票した後の対応 | 重大度判定、エスカレーション、事後レビュー |
| 構成管理（CMDB）編（10/20） | 依存関係の地図を作る | 構成アイテム、サービスマッピング、影響範囲分析 |
| 本稿：イベント管理（EventOps）編 | 鳴ったアラートをどう束ね、どう絞り込むか（アラートの出口）。起票する前のイベント処理 | 重複排除、抑制、相関、重大度の正規化、ノイズ率 |
特にCMDB編とは2本で1組の構成です。CMDB編で作った依存関係の地図を、本稿では監視の現場でリアルタイムに使います。地図があっても使わなければ相関は取れず、相関を取ろうにも地図がなければ親子関係はわかりません。
なぜ”100件鳴って、原因は1つ”が起きるのか
発生源が多層化している
AIエージェントのシステムでは、イベントの発生源が少なくとも4つの層に分かれます。
- エージェント層：タスク失敗、リトライ超過、ループ検知、ガードレール発動、人間への差し戻し増加
- モデル層：推論レイテンシ悪化、レート制限（429）、出力品質スコアの低下、トークン消費の急増
- ツール層：社内API・データベース・RAG検索・MCPサーバーの呼び出し失敗やタイムアウト
- 外部API層：LLM提供元、SaaS、認証基盤などの障害や性能劣化
下の層で起きた1つの問題は、上の層すべてで”症状”として観測されます。監視ツールが層ごとに分かれていれば、同じ問題が層の数だけアラートになります。
同じ事象が”別の名前”で鳴る
同じレイテンシ悪化でも、APM（アプリケーション性能監視）は「応答時間の閾値超過」、LLMゲートウェイは「タイムアウト率の上昇」、SLO監視は「バーンレート警告」として通知します。名前も重大度の表現も違うため、人が見ても同じ事象だと気づきにくいのです。
依存先の障害が”自分の障害”に見える
エージェントは自分が何に依存しているかを知りません。外部APIが遅くなれば、エージェントは「自分のタスクが失敗した」とだけ報告します。依存関係の情報がイベントに含まれていないため、「親」が別にいることがわからないのです。
イベント処理の全体像——6つの段階
イベント管理（EventOps）とは、監視ツールから上がるイベントを受け取り、人が対応すべきものだけを、対応に必要な情報を付けて渡すための運用規律です。処理は次の6段階で考えると整理しやすくなります。
| 段階 | やること | 本稿での規律 |
|---|---|---|
| 1. 収集・正規化 | 発生源ごとに異なる形式を共通スキーマにそろえ、重大度を統一する | 規律1 |
| 2. 重複排除 | 同じ事象の繰り返し通知を1件にまとめる | 規律2 |
| 3. 抑制 | 計画作業中や既知の事象など、通知不要なものを止める | 規律2 |
| 4. 相関 | 依存関係と時間をもとに、根本イベント（親）と派生イベント（子）を束ねる | 規律3・4 |
| 5. エンリッチ | 影響を受ける業務サービス、担当者、手順書、直近の変更を付け加える | 規律3 |
| 6. 起票判定 | インシデントとして起票するか、記録だけにするかを決める | インシデント運用編へ |
この流れを継続的に改善するための物差しが、規律5のノイズ率とアラート適合率です。
規律1：イベントを正規化する——共通スキーマと重大度の統一
まず”同じ形”にそろえる
相関の前提は、すべてのイベントが同じ項目を持っていることです。最低限、次の項目をそろえます。
| 項目 | 内容 | 例 |
|---|---|---|
| 発生元（source） | どの監視ツール・層から来たか | LLMゲートウェイ、APM、エージェント実行基盤 |
| 対象CI | CMDBの構成アイテムID | agent-faq-01、tool-rag-search、ext-llm-api-a |
| 事象の種類 | 統一した分類コード | latency_high、error_rate_high、quota_exceeded |
| 重大度 | 正規化後の共通レベル | Critical / Major / Minor / Info |
| 発生時刻・状態 | 発生・継続・回復のどれか | firing / resolved |
| 重複排除キー | 同一事象を判定するためのキー | 対象CI＋事象の種類 |
ポイントは対象CIをCMDBのIDで持つことです。監視ツールごとのホスト名やサービス名のままでは、依存関係の地図と結び付けられません。
重大度を正規化する
監視ツールによって、重大度は「P1〜P5」「critical/warning」「1〜10」などばらばらです。発生元の表現をそのまま使うと、ツールAの「critical」とツールBの「warning」のどちらが深刻かが比較できません。重大度は技術的な数値ではなく、業務への影響で定義し直します。
| 正規化後の重大度 | 定義（業務影響） | 通知方法 |
|---|---|---|
| Critical | 重要度ティア1の業務サービスが停止、または誤った出力が利用者に届いている | 即時呼び出し（電話・プッシュ） |
| Major | 業務サービスが劣化している、またはSLOを短期間で使い切るペース | チャット通知＋営業時間内に対応 |
| Minor | 単一コンポーネントの異常だが、業務影響は冗長化などで吸収できている | チケットのみ |
| Info | 記録・分析用。回復通知や計画作業の開始・終了など | 通知なし（ログに保存） |
CMDB編で付けた重要度ティアがここで効いてきます。同じ「エラー率上昇」でも、ティア1の業務につながるCIならMajor、検証環境ならMinor、というように、CIの属性から重大度を補正できます。
AIエージェントならではのイベントも取り込む
従来のインフラ監視にはなかったイベントも、同じスキーマに載せます。ガードレールの発動件数、人間への差し戻し率、ツール呼び出しのループ検知、1タスクあたりのトークン消費の急増、出力品質評価スコアの低下などです。これらは単独では原因になりにくい一方、他のイベントと相関させると原因の手がかりになります。
規律2：重複排除と抑制——”同じこと”と”知っていること”を鳴らさない
重複排除：1つの事象は1件に
同じ事象が5分おきに再通知されると、30分で6件になります。重複排除キー（対象CI＋事象の種類）が同じイベントは、状態が「回復」になるまで1件として扱い、件数と最終発生時刻だけを更新します。
あわせて、フラッピング（発生と回復を短時間で繰り返す状態）への対策も必要です。たとえば「10分以内に3回以上、発生と回復を繰り返したら、安定するまで1件にまとめる」といったルールを設けます。LLM APIのレート制限は、まさにフラッピングを起こしやすい事象です。
抑制：鳴らす必要のないものを止める
抑制には、主に3つの種類があります。
- 計画作業による抑制：変更管理（ChangeOps）で承認された作業時間中、対象CIとその配下のアラートを止める。モデルの切り替えやプロンプトの更新時に、評価スコアの一時的な変動で呼び出されることを防げます。
- 既知の事象による抑制：問題管理（ProblemOps）の既知エラーデータベース（KEDB）に登録され、回避策が決まっている事象は、通知ではなく記録だけにする。
- 依存関係による抑制：親のイベントが発生している間、子のイベントを止める（次の規律3で詳しく扱います）。
抑制には必ず”期限”を付ける
抑制の最大のリスクは、止めたまま忘れることです。作業が終わったのに抑制が残り、その間に起きた本当の障害を見逃す——NOCでも何度も見てきた事故です。すべての抑制ルールに、作成者・理由・終了期限を必須項目として持たせ、期限切れの抑制は自動で解除するか、少なくとも一覧で警告します。
規律3：CMDBの依存関係で相関する——親子関係から根本イベントを特定する
トポロジー相関の考え方
相関の中心となるのが、トポロジー相関です。CMDBの依存関係をたどり、一定の時間内に発生したイベントのうち、依存関係の最も下流（依存される側）にあるものを根本イベント（親）とみなし、それに依存する上流のイベントを派生イベント（子）としてまとめます。
冒頭の例で考えてみます。
| CI（依存の向き：上→下） | 発生したイベント | 相関の判定 |
|---|---|---|
| 業務サービス：社内問い合わせ対応 | SLOバーンレート警告 | 子（業務影響として表示） |
| エージェント：問い合わせ回答エージェント | タスク失敗率上昇、リトライ超過 | 子 |
| ツール：RAG検索 | タイムアウト率上昇 | 子 |
| モデル：埋め込みモデル（外部API経由） | レイテンシ悪化 | 子 |
| 外部API：LLM提供元A | レイテンシ悪化、429エラー増加 | 親（根本イベント） |
100件のアラートは、「外部API：LLM提供元Aの劣化」という1件のインシデントにまとまり、そこに「影響を受けている業務サービス」と「派生イベントの件数」が付いた形で、オンコール担当に届きます。
“共通の親”を探す
CMDB編で紹介した「共通の親を探す」という使い方を、ここでは自動化します。複数のエージェントで同時に異常が出たら、それらが共通して依存しているCIを地図から引き、そのCIにイベントが出ていないかを確認します。共通の親にイベントがなくても、「共通の親が怪しい」という仮説として提示するだけで、調査時間は大きく縮まります。
時間相関で補う
依存関係の地図は完全ではありません。地図に載っていない依存（ハードコードされたAPI呼び出しなど）もあります。そこで、同じ時間帯に集中して発生したイベントを候補としてまとめる時間相関を補助的に使います。ただし時間相関は”たまたま同時”も拾うため、トポロジー相関より確度が低いことを表示上も区別しておきます。
相関ルールの設計上の注意
- 相関の時間窓は、発生源ごとの検知遅延を考慮して設定します。外部APIのステータスは数分遅れて変わることがあり、窓が短すぎると親子を結び付けられません。
- 子を消さないこと。子のイベントは人への通知を止めるだけで、記録は残します。親が回復した後も子が回復しなければ、それは別の原因があるサインです。
- 相関の結果に理由を付けること。「どの依存関係によって、この親にまとめたのか」を表示すると、相関が誤っていたときに人がすぐ気づけます。
相関がうまくいかなかったケースは、多くの場合地図が古いことが原因です。相関ミスはCMDBの更新漏れを見つける最良のシグナルでもあるため、CMDB編の「地図と実態のずれの検知」に必ずフィードバックします。
規律4：提供元のステータスページと突き合わせる
外部APIの”親”は自社の外にある
AIエージェントの障害で特に多いのが、LLM提供元やSaaSなど、自社の管理外にある依存先の障害です。この場合、根本原因は自社では直せません。だからこそ、早く「外部要因である」と判定し、無駄な調査を止めることが重要です。
主要な提供元の多くは、ステータスページを公開し、RSSやAPIで状態を取得できるようにしています。これを1つのイベント発生源として取り込み、CMDB上の外部API CIに紐づけます。
突き合わせの4パターン
| 自社の観測 | 提供元のステータス | 判断と対応 |
|---|---|---|
| 異常あり | 障害・劣化を表示 | 外部要因と判定。親イベントに提供元の情報を付け、フォールバック（代替モデルへの切り替えなど）の要否を判断 |
| 異常あり | 正常を表示 | 最も注意が必要。提供元の公表遅れ、特定リージョンだけの問題、または自社側（認証情報、ネットワーク、レート制限の設定）の問題の可能性。両方を並行して調べる |
| 異常なし | 障害・劣化を表示 | 自社が使っていない機能・リージョンの障害の可能性。Infoとして記録し、影響が広がらないか監視を強める |
| 異常なし | 正常を表示 | 平常 |
経験上、ステータスページの更新は自社の観測より遅れることが少なくありません。ステータスページは「外部要因であることの確認」に使い、「自社の検知の代わり」にはしないことが原則です。そのためにも、外部APIへの呼び出しは自社側でも合成監視（定期的なテストリクエスト）で観測しておくと、判定が速くなります。
規律5：ノイズ率とアラート適合率で”鳴りすぎ”と”鳴らなすぎ”を測る
2つの失敗は同時に起きる
アラート設計の失敗には、鳴りすぎ（ノイズでオンコールが疲弊する）と鳴らなすぎ（本当の障害を見逃す）の2種類があります。厄介なのは、鳴りすぎを減らそうと抑制を強めると鳴らなすぎが増え、見逃しを恐れて閾値を下げると鳴りすぎが増えることです。どちらか片方だけを見ていると、もう片方が悪化しても気づけません。そこで、両方を数字で測ります。
測る指標
| 指標 | 計算方法 | 何がわかるか |
|---|---|---|
| ノイズ率 | 人に通知したアラートのうち、「対応不要」と判定されたものの割合 | 鳴りすぎの度合い |
| アラート適合率 | 人に通知したアラートのうち、実際に対応が必要だったものの割合（＝1−ノイズ率） | 通知の”当たり”の割合。チーム内の目標として前向きに示しやすい |
| 見逃し率 | 発生したインシデントのうち、アラートより先に利用者からの問い合わせや他部署からの連絡で発覚したものの割合 | 鳴らなすぎの度合い |
| 圧縮率 | 受け取ったイベント数 ÷ 起票したインシデント数 | 重複排除・抑制・相関がどれだけ効いているか |
| 相関の正答率 | 自動で特定した根本イベントが、事後レビューで正しかった割合 | 相関ルールとCMDBの品質 |
ノイズ率とアラート適合率は「鳴りすぎ」を、見逃し率は「鳴らなすぎ」を測ります。この組み合わせを必ずセットで追うことがポイントです。
測るための仕掛け
ノイズ率を測るには、アラートを閉じるときに「対応が必要だったか」を記録する必要があります。選択肢は「対応した／対応不要（誤検知）／対応不要（既知・重複）」程度の3択にとどめ、記録の手間を最小限にします。見逃し率は、インシデント運用編で扱った事後レビューの中で「最初にどう気づいたか」を必ず記録することで集計できます。
アラートごとに”棚卸し”する
全体の数字に加えて、アラートルールごとのノイズ率を見ます。ノイズの大半は、ごく一部のルールから出ていることが多いからです。ノイズ率の高いルールは、閾値の見直し、重大度の引き下げ、相関ルールへの組み込み、あるいは廃止を検討します。逆に、見逃しが起きたインシデントについては「どのイベントがあれば気づけたか」を確認し、ルールを追加します。
運用サイクル——いつ、何を見るか
| 頻度 | やること | 担当 |
|---|---|---|
| リアルタイム | 重複排除・抑制・相関を自動で実行し、親イベントだけを通知 | イベント管理基盤 |
| シフト交代時 | 未回復の子イベント、期限が近い抑制ルールを引き継ぐ | オンコール担当 |
| 毎週 | ノイズ率の高いアラートルール上位を確認し、改善対象を決める | 運用チーム |
| 毎月 | ノイズ率・適合率・見逃し率・圧縮率・相関の正答率の推移を確認。相関ミスをCMDBの更新に反映 | 運用責任者＋構成管理担当 |
| 四半期 | 重大度の定義、抑制ルール全体、ステータスページ連携先の棚卸し | 運用責任者 |
よくある落とし穴
- 相関ツールを入れれば解決すると考える：相関の精度はCMDBの精度で決まります。地図が古ければ、ツールは誤った親を自信満々に提示します。
- 子のイベントを捨ててしまう：通知を止めることと、記録を消すことは別です。子の記録がないと、親が回復した後の”残り火”に気づけません。
- 期限のない抑制：計画作業のために入れた抑制が残り続け、本当の障害を隠します。
- ノイズ率だけを目標にする：ノイズ率を下げることだけを評価すると、通知を減らす方向にばかり動き、見逃し率が悪化します。
- 提供元のステータスページを”検知”に使う：公表を待っていると、対応開始が遅れます。ステータスページは確認に使うものです。
- AI特有のイベントを別系統で管理する：ガードレール発動やトークン急増をインフラ監視と別の画面で見ていると、相関が取れません。
イベント管理（EventOps）チェックリスト
| 領域 | 確認項目 |
|---|---|
| 正規化 | すべてのイベントが共通スキーマに変換され、対象CIがCMDBのIDで記録されている |
| 正規化 | 重大度が業務影響で定義され、CIの重要度ティアで補正されている |
| 正規化 | エージェント層のイベント（ガードレール発動、ループ検知、トークン急増など）も同じ基盤に集約されている |
| 重複排除 | 重複排除キーとフラッピング対策のルールが定義されている |
| 抑制 | 計画作業による抑制が、ChangeOpsの承認済み作業と連動している |
| 抑制 | すべての抑制ルールに作成者・理由・終了期限がある |
| 相関 | CMDBの依存関係を使ったトポロジー相関が動いている |
| 相関 | 子のイベントは通知を止めても記録は残している |
| 相関 | 相関ミスがCMDBの更新にフィードバックされている |
| 外部連携 | 主要な外部APIの提供元ステータスを取り込み、外部API CIに紐づけている |
| 外部連携 | 外部APIへの合成監視を自社側でも行っている |
| 測定 | アラートを閉じる際に「対応の要否」を記録している |
| 測定 | ノイズ率・アラート適合率・見逃し率をセットで追跡している |
| 測定 | アラートルールごとのノイズ率を定期的に棚卸ししている |
よくある質問（Q&A）
Q1. 専用のイベント管理ツール（AIOpsツール）がないと始められませんか？
いいえ。多くの監視ツールやアラート通知サービスには、グループ化、抑制、依存関係による通知停止といった機能が備わっています。まずは既存ツールの機能で重複排除と計画作業の抑制から始め、CMDBの整備が進んだ段階でトポロジー相関に進むのが現実的です。
Q2. CMDBがまだ整っていません。相関は諦めるべきですか？
諦める必要はありません。まずは外部API、LLMゲートウェイ、共通のRAG基盤など、多くのエージェントが共通して依存しているCIだけでも地図に載せてください。親になりやすいCIが押さえられていれば、相関の効果の大部分は得られます。
Q3. 相関で親子をまとめた結果、間違った親に束ねてしまったら？
そのために、子のイベントの記録を残し、相関の理由を表示しておきます。オンコール担当が「この子は別原因」と判断したら手動で切り離せるようにし、その事例を相関ルールとCMDBの見直しに使います。相関の正答率を指標として追うのもこのためです。
Q4. ノイズ率の目標値はどのくらいにすべきですか？
一律の正解はありません。まずは現状を測り、ノイズ率の高いルールから改善して推移を下げていくことを目標にしてください。同時に見逃し率が上がっていないことを必ず確認します。夜間の呼び出しにつながるCriticalについては、特に厳しく適合率を見ることをおすすめします。
Q5. LLMが出すアラートの要約や原因推定を使ってもよいですか？
補助としては有効です。正規化済みのイベントと依存関係を渡して、要約や原因の仮説を作らせることで、初動の判断を助けられます。ただし、抑制や相関の判定そのものは、説明可能なルールで行うことをおすすめします。LLMの判断で通知を止めると、見逃したときに理由を検証できないからです。
まとめ——”100件”を”1件と、その影響範囲”に変える運用へ
AIエージェントの運用では、エージェント・モデル・ツール・外部APIの各層がそれぞれアラートを上げるため、1つの原因が大量のアラートに化けます。イベント管理（EventOps）は、そのアラートを束ね、絞り込み、人が判断すべき1件にして渡すための規律です。
- まず正規化する：共通スキーマと業務影響で定義した重大度にそろえ、対象をCMDBのCIで特定できるようにする。
- 依存関係で相関する：重複排除と期限付きの抑制で量を減らし、CMDBの親子関係から根本イベントを特定する。外部APIは提供元のステータスと突き合わせる。
- “鳴りすぎ”と”鳴らなすぎ”を同時に測る：ノイズ率・アラート適合率と見逃し率をセットで追い、ルールを継続的に棚卸しする。
CMDB編で作った依存関係の地図は、本稿のイベント相関で使われて初めて、日々の運用の価値になります。そして相関の失敗は、地図を更新するきっかけになります。地図を作り、使い、直す——この循環が回り始めたとき、オンコールの疲弊と見逃しは同時に減っていきます。
参考リンク
- Google SRE Book：Monitoring Distributed Systems
- Prometheus：Alertmanager（グループ化・抑制・サイレンス）
- OpenTelemetry：Semantic Conventions for Generative AI
- CloudEvents（イベント記述の共通仕様）
関連記事
- 【AgentOps・構成管理（CMDB）編】”このエージェントが止まると、何が止まるか”を即答できるようにする
- 【AgentOps・問題管理（ProblemOps）編】”同じ障害を、毎回はじめて対応する”をやめる
- 【AgentOps・変更管理（ChangeOps）編】
- 【AgentOps・HumanOps編】
- 【AgentOps・オブザーバビリティ編】
- 【AgentOps・インシデント運用編】
免責事項：本記事は、AIエージェントのイベント管理に関する一般的な考え方を整理したものであり、特定の製品・サービスの動作や効果を保証するものではありません。実際の設計・導入にあたっては、自社のシステム構成、利用する監視ツールや外部サービスの仕様、社内規程を確認したうえでご判断ください。
コメント