アラートだけでここまで分析できるの！？AI Agentで切り開くアラート対応の新時代

by nutslove

Embed

Start on current slide

Slide 1

Slide 1 text

アラートだけでここまで分析できるの？ AI Agentで切り開くアラート対応の新時代 2025/11/18 李俊起

Slide 2

Slide 2 text

自己紹介 2025/11/18 2 名前李俊起（イジュンギ） / Joonki Lee 所属 KINTOテクノロジーズ株式会社 Platform Group / Platform Engineer 関心分野 Observability Kubernetes 生成AI

Slide 3

Slide 3 text

話す内容 2025/11/18 3 • アラート原因分析AI Agent導入背景 • アーキテクチャ & 処理フロー • Agentの機能追加/改善 • 実際の分析結果例 • 今後について • まとめ

Slide 4

Slide 4 text

2025/11/18 4 アラート原因分析AI Agent導入背景

Slide 5

Slide 5 text

アラート対応のつらさ 2025/11/18 5 良く分からないアラートが出てるけど何をどこから調べればいいの？ナレッジが俗人化していて対応できる人が限られている原因分析に時間がかかり、対応/復旧までの時間（MTTR）が長くなる

Slide 6

Slide 6 text

そこでAI Agentの出番 2025/11/18 6 複雑で状況に応じて柔軟な対応が必要な、定型化が難しい作業にはAI Agentが適している

Slide 7

Slide 7 text

どういうAgentを作るか（最初の目標） 2025/11/18 7 • NewRelicからのアラート発報をトリガーに、原因分析を行い、暫定対応のためのAWS CLIコマンドの提案から実行までできるもの ➢ コマンドの実行は human-in-the-loop で人が介入 • アラートの通知から原因分析結果の通知、コマンド実行まで、すべてSlack上で行えるようにする（ChatOps）

Slide 8

Slide 8 text

AI Agentフレームワークの選定 2025/11/18 8 • 今はADKやOpenAI Agents SDKなど、様々なフレームワークがあるが、当時(2025年1月)はあまり選択肢がなく、 Bedrock AgentsとLangGraphを比較検討し、以下の理由でLangGraphを採用 ➢ 簡単にReact Agentが作れる ➢ 細かなフローの制御が可能 ➢ LangSmithやLangfuseへのトレースの連携が可能

Slide 9

Slide 9 text

2025/11/18 9 アーキテクチャ & 処理フロー

Slide 10

Slide 10 text

全体アーキテクチャ（Phase1 リリース時） 2025/11/18 10 • サーバーレス/イベント駆動型アーキテクチャで、コストを抑止 VPC API Gateway SlackBot Lambda SQS NewRelic Lambda CMDB Health Dashboard リカバリー基盤 SQS Recovery Lambda Agent Lambda 該当システムの HealthCheck Endpoint

Slide 11

Slide 11 text

処理の流れ 1/6 2025/11/18 11 VPC NewRelic Lambda CMDB Health Dashboard リカバリー基盤 SQS Recovery Lambda Agent Lambda 該当システムの HealthCheck Endpoint API Gateway SlackBot Lambda SQS アラートが発報されると、Lambdaが Slackにアラート内容の通知と原因分析処理開始のお知らせをする。それと同時に原因分析処理を非同期で行うため、SQSキューにメッセージを送信する WebHook

Slide 12

Slide 12 text

※補足：なぜo11yツールのSlack通知を使わないのか 2025/11/18 12 • o11yツールからSlack Integrationで、直接Slackに通知し、 Slack投稿をトリガーに、処理を開始する方法もある • しかし、通知内容が１つのブロックに非構造化（plain text）データに入っているため、データ抽出が困難 • Webhookの方がデータ整形とSlackへの通知の手間は増えるが、構造化（json）データで連携されるため、必要なデータの抽出が容易なので、Webhook方式を選択

Slide 13

Slide 13 text

API Gateway SlackBot Lambda 処理の流れ２/6 2025/11/18 13 VPC NewRelic Lambda リカバリー基盤 SQS Recovery Lambda CMDB Health Dashboard Agent Lambda 該当システムの HealthCheck Endpoint SQSからキューを取得し、AI Agentが処理を開始する。 Agentによる原因分析処理の前に、CMDBから取得したアラートが発生したシステムの情報(e.g. リソース一覧)や AWS Health Dashboardなどの情報をSystem Promptに入れる SQS

Slide 14

Slide 14 text

CMDB Health Dashboard 該当システムの HealthCheck Endpoint SQS API Gateway SlackBot Lambda 処理の流れ３/6 2025/11/18 14 VPC リカバリー基盤 SQS Recovery Lambda Agent Lambda NewRelic Lambda CloudWatch Aurora ECS ELB その他リソースアラートが発生したシステムのリソース『AWS CLI』と『NewRelicのクエリーを実行できるtool』を使って、 React Agentが、CMDBから取得したシステム情報を元に対象システムのアラートが発生したシステムのリソース(＋関連するリソース)の状態や NewRelic上のメトリクス・ログ・トレースを確認しながら、原因分析と暫定対応コマンドの生成を行う

Slide 15

Slide 15 text

NewRelic Lambda CMDB Health Dashboard 該当システムの HealthCheck Endpoint SQS API Gateway SlackBot Lambda 処理の流れ４/6 2025/11/18 15 VPC リカバリー基盤 SQS Recovery Lambda Agent Lambda 原因分析結果と暫定対応コマンドを Slackに通知

Slide 16

Slide 16 text

Agent Lambda NewRelic Lambda CMDB Health Dashboard 該当システムの HealthCheck Endpoint SQS 処理の流れ５/6 2025/11/18 16 VPC API Gateway SlackBot Lambda リカバリー基盤 SQS Recovery Lambda 人がコマンドの実行を許可処理開始の通知コマンドはリカバリー基盤上で実行される

Slide 17

Slide 17 text

API Gateway SlackBot Lambda リカバリー基盤 SQS Agent Lambda NewRelic Lambda CMDB Health Dashboard 該当システムの HealthCheck Endpoint SQS 処理の流れ６/6 2025/11/18 17 VPC Recovery Lambda コマンド実行結果を Slackに通知

Slide 18

Slide 18 text

Phase1 リリース後のフィードバック • インフラレイヤーだけではなく、アプリレイヤーまで調べてほしい • NewRelicだけではなく、CloudWatchアラームとGrafanaからのアラートにも対応してほしい • コマンドを実行して良いか判断ができず、逆に勝手に実行されないか不安 • Agentが何を実行して、何を根拠にその結論に至ったのか確認したい • 過去対応履歴など、ドメイン知識を踏まえて調査できるようにしてほしい 2025/11/18 18

Slide 19

Slide 19 text

2025/11/18 19 Codebase Analysis

Slide 20

Slide 20 text

実現したいこと 2025/11/18 20 • Githubリポジトリ上のコードとアラート（障害）の関連性を調べて、コード側に原因がある場合は、問題箇所と修正案を提案する • SlackからGithub issueの起票ができて、さらにGithub issueの起票をトリガーに、AIによるPRの作成までできるようにする

Slide 21

Slide 21 text

Codebase AnalysisとしてClaude Codeを使用 2025/11/18 21 • Claude CodeをAPIとしてラッピングし、 AgentにToolとして追加 • 実行有無/実行タイミング/関連性を調査するためのメッセージ（e.g. アプリーログ）はLLMが判断 • 調査対象のGithubリポジトリはCMDBから取得 • 初回リクエスト時にEFSにCloneしておき、２回目以降は更新があった場合のみPullして更新

Slide 22

Slide 22 text

Github issue起票＆ Claude Code Actionsとの連携 2025/11/18 22 • SlackからGithub issue起票、さらにissue起票をトリガーに Claude Code Actionsの起動まで可能 Claude起動ありでGithub issueを起票すると Claudeメンション付きでissueが作成され、 Claude Code Actionsが起動される。設定次第で自動PR作成まで可能。

Slide 23

Slide 23 text

これで万事解決？ 2025/11/18 23 これでアプリレイヤーの対応までできるようになった。めでたし～めでたし～ ...と言いたいところだが...

Slide 24

Slide 24 text

Codebase Analysis導入で別の課題が浮き彫りに 2025/11/18 24 • Lambdaの最大実行時間15分という制約で、処理が途中で終わってしまうケースが出てきた • SQS → EventBridge Pipes → Step Fuctions → ECS Task の構成に変更し、サーバーレス/イベント駆動型アーキテクチャはそのまま維持しつつ、最大実行時間の制約を解消

Slide 25

Slide 25 text

CodeBase Analysis導入後の構成 2025/11/18 25 VPC API Gateway SlackBot Lambda SQS NewRelic Lambda CMDB Health Dashboard リカバリー基盤 SQS Recovery Lambda Agent ECS EventBridge Pipes Step Functions NLB EKS 該当システムの HealthCheck Endpoint EFS Github issue起票 Clone & Pull

Slide 26

Slide 26 text

2025/11/18 26 複数のo11yツールへの対応

Slide 27

Slide 27 text

アラート発報元の判別 / 分岐処理 2025/11/18 27 • o11yツールによって連携されるアラートデータのフォーマットが異なるため、ツールに応じた分岐処理が必要 • アラートを受信する最初のLambdaで「user-agent」ヘッダーの値から発報元を判定し、対応するツールに合わせてデータを抽出したうえで、Slackには同じフォーマットで通知

Slide 28

Slide 28 text

アラート発報元ごとにTool、System Promptを使い分け 2025/11/18 28 • o11yツールごとにAgentの処理を最適化 1. LLMが誤ったToolを選択しないように、アラート発報元ごとに使用できるToolを制限 2. 使うToolが異なると、ToolのFew Shotなど、System Promptも変わるので、アラート発報元ごとに専用のSystem Promptを使用

Slide 29

Slide 29 text

o11yツールの違いによる差分 2025/11/18 29 • 連携されるデータが異なる ➢ Grafanaからはアラートに設定されているクエリーが連携されず、直接該当アラートに設定されているクエリーをGrafanaから取得 • AgentのToolの数 ➢ NewRelicではAgentのToolとして２つだけだったが、Grafanaを始めとするOSS製のモニタリング基盤では、メトリクスはThanos、ログはLoki、トレースはTempoみたいに多数のToolが必要

Slide 30

Slide 30 text

2025/11/18 30 復旧コマンドの実行について

Slide 31

Slide 31 text

コマンドを実行していいかの判断は誰が？ 2025/11/18 31 • 色々セーフティネット(※) は設けているが、本当に提案されたコマンドが正しいか、実行して良いかの判断が難しい • 実行ボタンを非表示にできるよう、機能追加 ※LLM as a judgeでコマンドの正当性を検証

Slide 32

Slide 32 text

定型化された作業に対象を絞り込む 2025/11/18 32 • 運用手順が定まっていて、実行パターンが明確に定義されている作業に限定 ➢ e.g. 障害発生時にCloudFrontの向き先をSorryページに切り替える • RunBook実行基盤を作成し、原因分析Agentと連携して実行する方法を模索中（構想段階）

Slide 33

Slide 33 text

2025/11/18 33 Incident Manager ＆ RAG

Slide 34

Slide 34 text

Incident Manager 2025/11/18 34 • Incidentの対応履歴を記録し、過去の類似障害の検索やポストモーテムなどに活用できるIncident管理システムを内製開発 • アラートごとにIncidentチケットが作成され、アラート内容だけではなく、Agentの分析結果が連携される

Slide 35

Slide 35 text

Incident Managerを内製開発した理由 2025/11/18 35 • Incidentのデータを自社環境で保持・管理したい • 対応履歴をRAGとして活用できるようにするうえで、 VectorStoreに入れるタイミングや内容などを完全に制御したい • 原因分析Agentとのネイティブな連携

Slide 36

Slide 36 text

Incident Managerのその他の機能（Agentの処理内容確認） 2025/11/18 36 • Agentがどういう処理を行なったか確認できるよう、Agentの処理ログを別タグにて表示

Slide 37

Slide 37 text

Incident Managerのその他の機能（トポロジー図表示） 2025/11/18 37 • アラート(障害)で影響を受けているリソースを表示 • 影響を受けているリソースは、LLMに(1)システムのリソース一覧 (全量)、(2)分析結果をinputとして与えて、洗い出してもらった結果をIncident Managerに連携

Slide 38

Slide 38 text

Incident Managerのその他の機能（RAG連携） 2025/11/18 38 • Incidentのアラート内容と人のコメントをVectorStoreに取り込み、 AgentでRAGとして次の分析に活かす ➢ Agentの分析結果はGoodボタンが押されたものだけを取り込む • 未完結のIncidentを含めるとノイズになってしまうため、 VectorStoreにはクローズ済みのIncidentのみを取り込む Agent ECS Incident Manager Aurora （Vector Store） ①アラート内容、分析結果を連携（Incident登録） ②アラート内容、人のコメントを取り込む ③次のアラート発生時に参照

Slide 39

Slide 39 text

Vector Storeの選定 1/2 2025/11/18 39 • 最初はOpenSearchをバックエンドとした、Bedrock KnowledgeBaseで実装 • その後、コストの観点からAurora Serverless（PostgreSQL）をバックエンドとした、 Bedrock KnowledgeBaseに変更 • PostgreSQLのBedrock KnowledgeBaseでは、一応ハイブリット検索は使えるものの、日本語Tokenizerが存在せず、日本語のキーワード検索ができないことから、 Bedrock KnowledgeBase を使わず、素のpgvectorを利用する方法に変更

Slide 40

Slide 40 text

Vector Storeの選定 2/2 2025/11/18 40 • pgvectorのセマンティック検索と、BM25によるキーワード検索を組み合わせたハイブリッド検索＋ Rerankを試すも期待通りの結果が得られず ➢ クエリーとログの内容的に類似度が高いものより、タイムスタンプが近いものが上位に来たり • 結局、現在はpgvectorのセマンティック検索だけにしている ➢ 検索（取得）件数は10件など、多めにしている

Slide 41

Slide 41 text

Chunking戦略（一般的なChunking） 2025/11/18 41 • Chunkを分割すると、不完全なデータがAgentに連携される可能性がある Aurora （Vector Store）アラート情報 ECS CPU使用率アラート原因・・・対応履歴・・・ Incident情報 chunk1 chunk2 chunk3 Agent 「原因」と「対応履歴」、両方必要だけど、片方だけ取得される可能性がある

Slide 42

Slide 42 text

Chunking戦略（Parent-Child Chunking） 2025/11/18 42 • Parent-Child Chunkingは、関連性の低いドキュメントが取得される可能性がある Aurora （Vector Store）アラート情報 ECS CPU使用率アラート原因・対応履歴 <今回の事象と最も関連性の高い情報> アラート情報 ECS CPU使用率アラート原因・対応履歴 <今回の事象と関連性の低い情報> Incident情報（１） chunk1 chunk2 Agent アラート情報で検索される場合、どちらもECS CPUアラートなので、（１）の方を取りたいのに、（２）が取得される可能性がある Incident情報（2） chunk1 chunk2 クエリーに使われる単位 Promptに含まれる単位

Slide 43

Slide 43 text

Chunking戦略（Chunkingしない） 2025/11/18 43 • そのため、Chunkingをせず（Chunkを分割せず）、１つのIncident情報を１つのChunkとして保存 Aurora （Vector Store）アラート情報 ECS CPU使用率アラート原因・・・対応履歴・・・ Incident情報 chunk1 Agent 検索もPromptに含めるのも全て、まとまった１つのChunkに対して行うので、不完全なデータが含まれることなく、関連性の低いものが検索される可能性も低い

Slide 44

Slide 44 text

データ検索のタイミング & クエリー（処理の最初に実施） 2025/11/18 44 • Agent処理の最初のステップで、アラート内容だけで検索をすると、同じアラートの数あるIncidentから、現在のアラートと関連性の高い履歴の検索ができない可能性がある Aurora （Vector Store）アラート情報 ECS CPU使用率アラート原因・対応履歴 <今回の事象と最も関連性の高い情報> アラート情報 ECS CPU使用率アラート原因・対応履歴 <今回の事象と関連性の低い情報> Incident情報（１） Agent まだ、アラートに関する情報が出揃ってない処理の最初のタイミングで、アラート内容だけ検索しても、数多くの類似事象から関連性の高い情報の検索が困難 Incident情報（2） “ECS CPU使用率”で検索

Slide 45

Slide 45 text

データ検索のタイミング & クエリー（処理の最後に実施） 2025/11/18 45 • 最後のステップで行うと検索結果を踏まえた追加分析ができない Aurora （Vector Store）アラート情報・ALB Target Unhealthyアラート・ALB Target Group ： ECS Service ・Target ECS Service： hoge 原因・対応履歴 OpenSearch側で障害が発生し、 Logエージェントがログを送れず、 OOMが発生し、ECS Taskが落ちていた Incident情報 Agent 関連性が高そうな情報が取得できたところで、さらにその情報を元に調査を進めてほしいのに、回答を生成してしまう・・ “ALB Target Unhealthy、 Target ECS Service ： hoge” で検索前のステップでToolで確認した情報＋検索で取得した原因・対応履歴を元に回答を生成

Slide 46

Slide 46 text

データ検索のタイミング & クエリー（処理の途中で実施） 2025/11/18 46 • そこで、検索（Retriever）をToolとしてAgentに追加し、「検索タイミング」と「検索クエリー」はLLMに判断させる（Like “Agentic RAG”） ➢ ただ、検索クエリーにアラート内容は固定で入れる。つまり、「クエリー＝アラート内容(固定) ＋ Context(変動)」 Aurora （Vector Store）アラート情報・・・原因・対応履歴・・・ Incident情報 Agent 過去類似情報検索前のステップでToolで確認した情報＋検索で取得した原因・対応履歴を元に、さらに調査を進める

Slide 47

Slide 47 text

※補足： Rerankや検索件数の絞り込みはしなくて大丈夫？ 2025/11/18 47 • Naive RAGでは、検索結果をそのままSystem Promptに埋め込んで、LLMに回答をさせるので、関連性の低い内容を除外する必要がある • 原因分析Agentでは、検索結果をそのまま使うのではなく、Agent にその中から今回の事象と関連するものだけを利用するよう、指示しているので、関連性の低い履歴が混ざっていても影響が小さい ➢ 少しノイズとなるデータが混ざっていても、関連性の高いデータが漏れるより分析の質が高くなる可能性が高いため、取得件数を多めにしている • 追加で、システムIDをメタデータとして付与して、フィルタリングをすることで対象システムの過去履歴だけを取得している

Slide 48

Slide 48 text

現在のアーキテクチャ（2025/11時点） 2025/11/18 48 VPC API Gateway SlackBot Lambda SQS NewRelic Lambda CMDB Health Dashboard リカバリー基盤 SQS Recovery Lambda Agent ECS EventBridge Pipes Step Functions NLB EKS 該当システムの HealthCheck Endpoint EFS CloudWatch Alarm o11y Lambda Incident Manager Aurora （Vector Store）

Slide 49

Slide 49 text

2025/11/18 49 分析結果例

Slide 50

Slide 50 text

ALBのResponse遅延アラートからDB Index最適化を提案 2025/11/18 50 インフラリソースは正常であることを確認ログからトレースIDを特定し、さらにトレースからアラートの原因となったSQL を特定問題の原因を特定対応方法を提案（Index最適化）

Slide 51

Slide 51 text

2025/11/18 51 ALBのUnHealthyHostアラートに対して、対応不要と案内 ALBのTarget Group のヘルスチェックに失敗したTargetを検知新しいバージョンのECS Taskへのローリングアップデートによる一時的なアラートで、すでに解決済みであり、対処不要と案内

Slide 52

Slide 52 text

エラーログから、エラーの原因のコードを特定し、コード修正を提案 2025/11/18 52 エラーログと関連するコードの部分を特定し、原因となっているロジックを分析コードの修正方法について提案エラーログを元に調査

Slide 53

Slide 53 text

2025/11/18 53 今後について

Slide 54

Slide 54 text

ロードマップ 2025/11/18 54 • 再分析機能追加 ➢ 1回の分析/提案で終わるのではなく、人が追加のコンテキスト情報を与えて、再分析/提案を実施できるようにする • ToolをMCPサーバとして公開 ➢ アラート発生時だけではなく、通常時でも自然言語からテレメトリーデータの確認ができるようにする

Slide 55

Slide 55 text

2025/11/18 55 まとめ

Slide 56

Slide 56 text

1. System Prompt ➢ 指示を具体的に、かつ順序を立てて書く ➢ Toolの使い方についてFew Shotを記載する 2. Context ➢ ToolやRAGから取得する動的なContextだけではなく、静的なContextも重要 ➢ 固定的に必要な情報は、事前に取得してSystem Promptに埋め込む方が効果的 3. Tool ➢ AgentがTool選択に迷わないよう、機能を明確に分ける ➢ Descriptionは、引数の説明も含めて詳細かつ明確に記載する（私が思う）AI Agent開発で最も重要な3要素 2025/11/18 56 １つでも欠けると期待した出力や行動を安定して得ることは難しくなる。

Slide 57

Slide 57 text

一緒に働く仲間を探しています 2025/11/18 57 クラウドプラットフォームエンジニアカスタマーサクセスエンジニア AI x Platform

Slide 58

Slide 58 text

ご清聴ありがとうございました！