AIOps とは：アラートの相関分析とその限界

AIOps とは、IT運用のための人工知能を意味し、アラート、ログ、メトリクスなどの運用シグナルを解釈するために分析手法やAIを活用することです。アラートの相関分析では、関連する可能性のあるイベントをまとめ、調査担当者がグループとして確認できるようにします。相関のあるグループは調査の手掛かりであり、実証された根本原因ではありません。

確認すべきなのは、提供された証拠が特定のインシデントの仮説を裏付けるかどうかです。AIが書いた要約は証拠の整理に役立ちますが、不足する測定値を補ったり、サービス間の依存関係を実証したり、復旧措置を許可したりすることはできません。

執筆：Ai Flowi · 公開日 2026-10-11

AIOpsの意味：シグナルから調査へ

監視は観測結果を収集し、アラートを発生させる可能性のある条件を評価します。相関分析は、共通のサービス、デプロイ参照、時刻、検証済みの依存関係など、観測結果の間の関係を調べます。診断は、観測された挙動を何が説明するかを問います。対応は、運用上の状況を変更します。ツールが1つの画面に表示していても、これらは別々の責任です。

モデルは、2つのサービスを併せて調べるべきだと提案できます。その提案には、サービス間を結ぶ依存関係図やその他の証拠が引き続き必要です。似たアラート文面は、共通の障害ではなく共通のメッセージテンプレートを反映している可能性があります。同様に、時刻が近いことは比較する理由になっても、どちらがもう一方を引き起こしたかを示しません。

注釈付きの架空のアラートデータ一式

以下は学習用に作成した架空の入力記録であり、本番環境のテレメトリではありません。すべての時刻は同じ架空の日に属し、UTCオフセットも同じです。CSVの列名は正確にtimestampです。各値にUTCオフセットが含まれるため、別のタイムゾーン列はありません。提供されたデータ一式には、検証済みのサービス依存関係図がありません。observed_statusは、サービス全体の正常性ではなく、指定されたシグナルを示します。

小さな画面ではアラート表を横にスクロールしてください。キーボードを使う場合は、領域にフォーカスを移して矢印キーで操作できます。

2件のevt_aは、このデータ一式のすべてのフィールドで一致します。同一のイベントIDを持つ同一内容の繰り返しは同じ観測の再配信とする演習ルールに従い、配信回数2回の1つの証拠項目にまとめます。元の両方の行への参照は保持してください。重複表示を抑えても、配信履歴を消してはいけません。

これにより、提供された4行から、異なる証拠項目が3つ残ります。別のevt_aが異なる状態や時刻で届いた場合は、不一致として保持して確認します。この演習では、IDが一致するというだけで採用する記録を選びません。モデルにインシデントの要約を依頼する前に、同一性のルールを適用する必要があります。

AIOpsで相関グループは何を裏付けられますか？

evt_aとevt_bは同じサービスとデプロイ参照を示すため、同じ候補グループに含められます。ただし、観測内容は遅延アラートと成功したプローブで異なります。両方を保持してください。プローブが別のエンドポイントや別の瞬間を対象にしている可能性があり、遅延の観測を打ち消すものではありません。

evt_cは時刻が近いものの、デプロイ参照が不明です。不足する依存関係の証拠を明示し、別途識別した関連候補として含めます。受け入れ可能な仮説案は、その時点でcheckoutのリクエストがinventoryに依存していたかを問うものです。inventoryの障害がcheckoutのアラートを引き起こしたと断定するものではありません。

したがって、調査資料一式には、証拠ID、提案する関係、反証、不足するテレメトリ、次に検証する問いを含める必要があります。この例で有用な問いは、影響を受けたエンドポイント、2つのサービスをまたぐ呼び出しの有無、症状に先行するデプロイの有無などです。架空の表には、これらの問いへの答えはありません。

範囲を限定したAI Flowi Workflowの例

パーサーの入出力仕様については、Load CSVのリファレンスを、JSONからTableへの境界にはData → DataFrameを参照してください。Table OperationsとStructured Outputはコンポーネントカタログに記載されています。以下で使う機能の状態は文書化済みです。カタログに文書化されていますが、Ai Flowiによる本番環境でのテストは行われていません。

設定例であり、記録されたテストではありません

使用が許可された架空のCSVエクスポートと、Workflowエディターへのアクセスを準備してください。モデルを使う段階では、ご自身のプロバイダーアカウントとAPIキーが必要で、そのプロバイダーに別途料金を支払います。この演習は提供された記録から始め、監視データの取り込みや復旧措置への接続はありません。

1. Load CSVのcsv_stringに、正確なヘッダーevent_id,service,timestamp,signal,deployment_ref,observed_statusと、それに続く上記の4件の記録を設定します。各timestamp値のオフセットを保持し、evt_aの2回目の配信も残してください。
2. 読み込んだ記録をData → DataFrameのdata_listからTable Operationsのdfへ渡します。間の接続は変換リファレンスに従ってください。並べ替えを設定する前に、列名が引き続きtimestampであることを確認します。
3. 同じ日、同じオフセットのこのデータ一式では、Table Operationsのoperation = "Sort"、column_name = timestamp、ascending = trueという設定を提案します。すべての状態を保持してください。日付やオフセットが混在する場合は、時系列比較の前に正規化が必要です。
4. 上記の明示的な同一性ルールを使い、重複グループをレビューします。カタログには"Drop Duplicates"がありますが、比較対象の列や保持方針は実証されていません。提案したSortステップは、イベントIDによるグループ化を実装するものではありません。
5. Structured Outputのinput_valueにレビュー済みの証拠一式を渡します。モデルと結果形式案の設定には、構造化出力の説明を参照してください。system_promptでは、各仮説に裏付けとなるイベントIDを明記し、成功したプローブを保持し、不足する依存関係の証拠を特定するよう求めます。

グループ化のレビュー後、手作業で準備したインシデント要約をモデルに渡します。その要約には収集期間も含めてください。データ一式は09:00:08で終わるため、その後に遅延が解消したかは実証できません。後の成功したリクエストは証拠の期間を延ばしますが、それ以前のしきい値超過の観測を遡って誤りにするものではありません。対象の区間を測定でカバーするまで、継続時間の問いは未回答にしておきます。

レビューの境界とよくある誤り

提案された仮説がevt_bを保持し、inventoryとの依存関係を不明と示し、evt_aの2回目の配信も考慮しているか確認します。inventoryのデプロイを捏造する、正常なプローブを黙って省く、追加の証拠なしに因果関係を示す下書きは却下してください。

アラートの件数をインシデントの件数と同一視しないでください。テレメトリがないことを正常な測定値として扱ってはいけません。配信の遅延を調べる際は、観測時刻と受信時刻を分けます。情報源ごとの時計にずれがある場合は、グループを解釈する前に、見かけの順序の補正が必要なことがあります。

既知のルールで次の確認事項が決まる場合は、既存の運用手順を使ってください。この例は、無人でのインシデント終了処理、自動ロールバック、利用できないテレメトリを必要とする判断には適しません。障害検出率、診断精度、対応の成功は一切主張していません。

関連用語と次の参照先

LLMの可観測性は、サービスをまたぐインシデントの相関ではなく、モデルリクエストから得られる証拠を扱います。AIのプロダクションシステムは行動を選ぶ明示的なルールを説明します。エージェントのプランニングは調査ステップ間の依存関係を扱います。

定期的な資料エクスポートのレポートでは、インシデントの仮説を集計処理として扱わず、レポート作成の自動化を参照してください。ビルダーの問題にはWorkflowのトラブルシューティングを使います。