アラート対応エージェント NOAの裏側 [DeNA インフラ SRE]

はじめに

こんにちは、IT基盤部の三浦忠善です。前回のブログ記事に続き、今回もアラート対応をテーマにお届けします。

本記事は、IT基盤部NOCの岡崎さんが執筆した記事「ワークフロー言語化×LLMで実現するアラート対応革命介」の続編として、LLMを活用したアラート対応支援エージェント NOA (NOC Alert Agent) の裏側、その技術的な仕組みを深掘りします。

NOAは、私たち IT基盤部ネットワークグループが開発・運用するアラート対応支援エージェントです。複数のコンポーネントが連携し、継続的な改善を重ねながら進化しています。

本記事では、NOAの実用例と、頭脳にあたるコアコンポーネント「alert-agent」について解説します。

AIアラート分析エージェントのSlack連携による迅速な情報提供

alert-agent は、現在2つのシステムで活用されています。本稿ではその一つであるSlack Bot連携を紹介します。

DeNA NOCでは、アラート通知の集約と対応時のコミュニケーションを主にSlackで行っています。alert-agent をSlackに統合することで、アラート通知の受信から分析結果の確認までを、普段利用しているツール上でシームレスに行えるようになりました。

特筆すべきは、その速度です。Slackへのアラート通知を検知してから、alert-agent が分析を完了し、結果を投稿するまでの総所要時間は平均120〜180秒程度です。これにより、担当者がアラートに気づいて初動を開始する頃には、すでに関連スレッドに詳細な分析レポートが投稿されている、という理想的な状態を実現しています。

運用に最適化した情報提供

アラート発生時という緊急かつ高ストレスな状況下で、状況認識の負荷を最小限に抑えるため、Slack Botは alert-agent のレポートをさらに整形して投稿します。最も重要な情報が最初に目に入るよう、表示順序を工夫しています。

アラート概要: 種別と対象機器
影響範囲: 「特定AP周辺」「特定フロア」など、運用上の影響範囲
推奨対応: 直ちに実施すべきアクション
原因分析: 仮説と検証結果をまとめた総合的な説明
収集データ要約: クリックで詳細データを段階的に展開できる折りたたみ形式
アラート判定: 運用上の深刻度と対応の推奨温度感
分析の確実性: 確実性が低い場合はレポート冒頭に警告フラグを表示
フィードバック: 分析が役立ったかをワンクリックで評価できるボタン

alert-agent における LLM の使い分け

前回の記事では、Gemini 2.5 Proの幅広い専門知識と高度な推論能力について触れましたが、応答に時間がかかるというトレードオフもあります。そのため、「アラートの自動分析による対応支援」という時間制約があるタスクにおいて、全ての処理にGemini 2.5 Proのような高負荷なモデルを使用することは適切ではありません。

一方で、Gemini 2.5 FlashやGemini 2.5 Flash Liteのような下位モデルは、Gemini 2.5 Proよりも応答速度に優れていますが、情報の精度や推論能力には顕著な違いがあります。

そこで、開発フェーズにおいて同一のプロンプトとアラートデータを用いて各ステップで異なるモデルを使用し、多角的に性能評価を行うことで、速度と品質の最適なバランスが取れるモデルを選定しています。

2025年8月時点では、以下のような構成で各モデルの長所を活かしています。

簡易な処理: Gemini 2.5 Flash Lite （既に情報が揃っている状況でのレポート作成処理など、高度な推論が不要な定型タスク。推論は無効化）
中程度の処理: Gemini 2.5 Flash （ステップごとに推論の有効/無効を動的に切り替え）
高度・複雑な処理: Gemini 2.5 Pro （常時推論を有効化し、深い分析を実行）

また、推論の思考量を制御する thinkingBudget パラメータは下限を1024に設定し、各ステップやモデルの特性に応じて微調整しています。

alert-agent の柔軟な入出力

alert-agent は、特定のシステムに縛られない高い汎用性を持つよう、プレーンテキストを入力とし、JSON形式で結果を出力するシンプルなHTTP APIとして設計されています。これにより、特定のアラート通知フォーマットに依存することなく、様々な外部システムと柔軟に連携できます。

現在の主な利用ケースでは、Prometheus/LokiからAlertmanager経由でSlackに送られるアラート通知をBotが転送していますが、将来的には他の経路からの分析依頼にも対応可能です。

構造化出力による精度の向上

alert-agent 内の各ステップの出力には、LangChainのStructured Outputを活用しています。これは、プロンプト内に定義されたJSON Schemaに従って、LLMの出力を厳密にJSON形式で生成させる技術です。

このアプローチは、LLMに対する指示を、いわば「真っ白な紙を渡してレポートを書いてもらう」状態から、「記入項目が定められた専用の報告書類を渡す」状態へと変えることに似ています。出力形式を規定することで、ステップ間の情報伝達が自然言語よりも明確かつブレの少ないものになります。

Gemini 2.5 ファミリーは、その豊富な知識と強力な推論能力から、時に良かれと思って過度に詳細な情報を生成する「お節介」な側面も持ち合わせます。構造化出力は、この強力な能力を最大限に活かしつつ、出力を我々の意図通りに制御し、実用的な結果を安定して得るための重要な鍵となっています。

マルチエージェントシステムとしての alert-agent

alert-agent が実行する一連の分析処理は、複数の独立したステップに分割されています。各ステップでは、そのステップの専門家として特化したLLMエージェントが動作します。

ステップ間の制御は基本的にLangChainとその拡張であるLangGraphの機能を用いて静的に行われており、LLMによる自律的なワークフローの制御は仮説生成〜情報十分性判定の部分のみとしています。そのため、純粋なマルチエージェントシステムではなく、手続き型システムとマルチエージェントシステムのハイブリッドである、といえます。

この設計思想により、単一の巨大なプロンプトで全ての処理を行おうとした場合に生じる、以下のような問題を効果的に回避しています。

コンテキストウィンドウの逼迫
処理時間の増大
分析精度の低下

また、開発・改善のサイクルにおいても利点があります。例えば、特定のステップの入力として、LLMの出力の代わりに人間が手動で作成した情報を与えることで、そのステップが理想的な入力を受け取った際の出力を正確に評価できます。これにより、各エージェントの継続的な改善が容易になります。

実務の知見を埋め込むコンテキストエンジニアリング

alert-agent のプロンプトに記述されている手順や判断基準は、私や他のNOCメンバーが実際のアラート対応で行っている思考プロセスそのものを反映したものです。

私たちは、単にプロンプトを書くだけでなく、そのプロンプトを人間が読み解き、それに従って手動で作業をシミュレーションします。その過程で明らかになった、プロンプトに記述されていない暗黙知（経験や勘に基づく判断）がLLMの動作を妨げていると判明した場合、その知見を明文化してプロンプトに追加する、という地道な作業を繰り返しています。

この「コンテキストエンジニアリング」を通じて、熟練担当者の経験を確実にコンテキストへと落とし込み、暗黙知を段階的に形式知へと変換しているのです。最終的には、「このプロンプト群自体が、人間がアラートを分析するための優れた手順書になる」レベルを目指し、日々の分析結果をレビューしながら改善を続けています。

特に重要なプロンプトエンジニアリングにおいては、GoogleがGemini向けに公開しているプロンプト設計戦略を参考にしています。

以下の観点には特に注意を払っています:

各ステップで実施すべきタスクの明確で具体的な指示
回答形式の指定（JSON Schemaによる構造化出力など）
Few-shot プロンプト（入出力やツール呼び出しに関する例の提示）

中でも Few-shot プロンプトは、複雑なメトリクス構造を持つPrometheusから必要な情報を的確に取得するために、多くの工数を費やしてチューニングしています。後述する関連情報の注入（RAG）と組み合わせることで、その効果はさらに高まります。

NOAによるアラート分析フロー

ここからは、alert-agent が実行する分析フローをステップごとに解説します。

各ステップへの入力情報は、1つ前のステップの出力とあわせて、他のステップの情報や外部からの情報を必要に応じて付帯させています。この戦略により、全ての会話履歴を利用することによる処理量増大のリスクと、伝言ゲームのような情報の流れによる精度低下のリスクを効果的に抑制しています。

Step 1.1: アラートの認識

受信したアラートテキストから基本的な情報を抽出し、JSON形式のデータで仮説検証に必要な情報を出力します。

種別: どのような種類のアラートか
発生時刻: いつから発生し、どのくらい継続しているか
対象: どの機器やシステムで発生しているか
状態: 具体的な値は何か（閾値を超えているかなど）

これにより、アラートの事象（What, When, Where, Who）を特定し、後続のステップでその原因（Why）と経緯（How）を深掘りする準備を整えます。

Step 1.2: 関連情報の取得と注入 (RAG)

後続の分析精度と効率を飛躍的に高めるため、一部の情報はLLMに推測させるのではなく、外部ソースから機械的に取得し、各ステップのプロンプトに注入します。これは RAG (Retrieval-Augmented Generation) の一形態として機能します。

alert-agentは現在、以下の3種類の情報をJSON形式のキャッシュデータから自動で取得・注入しています。

1. ネットワークトポロジ情報

ネットワーク運用監視ツールおよび NW機器config管理ツールの情報を基に、アラート対象機器からAWS上の監視ツールまでの経路上に存在する全機器の情報を注入します（インターフェース、接続関係、機器種別など）。
これにより、影響範囲の判断精度が格段に向上します。

2. メトリクス情報

アラート対象機器および関連機器について、Prometheus/Lokiで取得可能なメトリクス名やラベルを事前に取得して注入します。
メトリクス名をLLMに推測させたり、考えられる名前を網羅的に試したりする方法では、クエリの精度や実行速度に課題がありましたが、この最適化によりメトリクス取得の初回成功率は9割以上に達しました（従来は2〜3回の再試行が必要でした）。

3. アラートルール定義

通知内容に具体的なメトリクス情報が含まれない場合に備え、該当アラートのルール定義そのものを注入します。
発生条件、閾値、時系列の条件などを正確に把握することで、「なぜこのアラートが発生したのか」という分析の精度を高めます。

Step 2: 仮説の生成

受け取ったアラート情報と注入された関連情報（トポロジ、メトリクス等）を基に、LLMが持つネットワーク知識を総動員して、原因に関する仮説を体系的に生成します。

仮説の質と網羅性を高めるため、プロンプトでは以下のルールを定めています。

優先順位付け: 各仮説に「高」「中」「低」の確信度を付与する。
具体性の担保: 機器名やインターフェース名などの固有名詞を必ず含める。
多様性の確保: 最大4件まで、それぞれ異なる観点から仮説を生成し、そのうち1件は必ずログを起点とした仮説を含める。

ログ起点の仮説を必須とすることで、メトリクス（Prometheus）とログ（Loki）の両面から一貫した検証が可能になります。

さらに、DeNAのネットワーク環境に特化した知識（拠点間のVPN構成、ファイアウォールの特性、無線APとスイッチの親子関係など）もプロンプトに埋め込むことで、Gemini 2.5が持つ広範な知識を我々の環境に合わせて最大限に引き出し、より妥当性の高い仮説を生成させています。

Step 3: 情報の収集と仮説の検証

生成された仮説を検証するため、MCP Serverを経由して、PrometheusやLokiから実際にデータを取得します。検証結果は、実行したクエリと共に以下の4つに分類して出力します。

取得成功・仮説を証明: 仮説を裏付けるデータが得られた
取得成功・仮説を反証: 仮説を否定するデータが得られた
取得成功・証明不可: データは得られたが、仮説の証明にも反証にも至らなかった
取得失敗: データの取得自体ができなかった

誤報アラートの可能性も考慮し、特に「取得失敗」時のハンドリングは慎重に設計されています。

Step 4: 情報十分性の判定

全ての仮説の検証が一通り完了した時点で、原因を特定するのに十分な情報が集まったかを判定します。情報が不十分だと判断した場合は、不足している情報と、それまでに収集した情報を基に、再びStep 2の仮説生成からプロセスを再実行します。

RAGによる背景情報の強化（特にトポロジ情報）を行った結果、この再試行ループが2回以上発生することは稀になりました。

Step 5: 根本原因の分析

十分な証拠が揃った段階で、収集した全ての情報を統合し、真の原因を特定します。このステップは高度で複雑な推論を要するため、Gemini 2.5 Pro が担当します。

分析は、以下のような多角的なアプローチで行われます。

証拠の重み付け: 「証明」「反証」「証明不可」「取得失敗」といった検証結果に基づき、各情報の信頼度を評価します
時系列と因果関係の整理: 「何が最初に異常となり、それがどのように他の事象へ波及したか」を解明します
影響範囲の特定: 障害が局所的なものか、広範囲に及んでいるかを判断します
専門知識による深掘り: プロトコル階層（L1〜L7）を意識した系統的な検証や、冗長構成・フェイルオーバーが正常に機能したかといった観点からも分析を加えます

最終的な分析結果は、以下の構造で明確に出力されます。

根本原因: 最も確からしい原因
関連事象: 原因に伴って発生した二次的な事象
否定された仮説: 原因ではなかったと結論付けられた仮説（消去法的な証拠）
分析の確信度: 総合的な確信度を5段階で評価

この構造化により、「何を最優先で対処すべきか」「有効な予防策は何か」といった次のアクションに繋がりやすくなります。

Step 6: 推奨アクションの検討

分析された根本原因に基づき、具体的な対処策と再発防止策を、確信度と影響範囲を踏まえて提示します。アクションは、緊急度に応じて3つのカテゴリに分類されます。

即時対応 (Immediate): サービスの迅速な復旧、問題の封じ込め、影響の緩和策
短期対応 (Short-term): 恒久的な再発防止策のうち、1週間〜1ヶ月程度で実施可能なもの
長期対応 (Long-term): 冗長化の強化や監視体制の見直しなど、より構造的な改善策

さらに、アクションの実行可能性を高めるため、機器固有の手順や作業時の注意点、実施後に確認すべきメトリクスやログなども具体的に提示します。

Step 7: 最終レポートの生成

最後に、ここまでの全ステップで蓄積した情報を一つのレポートに統合します。このレポートは、対応担当者が状況を即座に把握し、迷わず初動対応に着手できることを目指して設計されています。

レポートは主に以下の要素で構成されます。

アラート概要: 根本原因と推奨される即時対応を1〜2段落で要約し、深夜の呼び出し時やエスカレーション時にも、これだけ読めば状況が把握できることを意図しています
根本原因の詳細: 仮説の検証プロセスを含め、どのような証拠に基づいて結論に至ったかを時系列で説明
推奨アクション: 「即時」「短期」「長期」に分類された、優先度付きの具体的なアクションリスト

NOAの現在地

alert-agentの開発とSlackとの統合により、これまで属人的な経験と能力に大きく依存していたアラートの一次分析が、24時間365日、一定の品質で実行される自動化されたプロセスへと進化しました。

これにより、アラート発生時のストレス下でも担当者が必要な情報を的確に把握し、適切な対応判断を下すことを強力に支援し、ネットワーク障害対応の迅速化と品質向上に貢献しています。

NOAのこれから: “受動的"から"能動的"へ

ここまで紹介してきたシステムは、NOAプロジェクトが発足当初に構想していた「Slackに投稿されたアラートに反応して分析を行う」という受動的 (Reactive) なエージェントであり、私たちはこれを R-NOA (Reactive NOA) と呼んでいます。

現在、alert-agent 自体の継続的な性能改善と並行して、より発展的な利活用に向けた研究開発も進めています。その一つが、「アラートが担当者に通知される前に分析を行い、その重要度や緊急度に応じて通知自体を制御する」という、より能動的 (Proactive) なアラート分析エージェントシステムです。私たちはこれを P-NOA (Proactive NOA) と名付け、研究開発を進めています。

次回の記事では、alert-agent のさらなる進化や裏側、実際のアラートに対する分析事例に加え、このP-NOAの構想についてもご紹介できればと考えています。ご期待ください。