LangGraphで作ったアラート原因分析エージェントについて

LangChain Meetup Tokyo #7のLT資料です。
よろしくお願いします。

Transcript

1. アラート原因分析エージェントについて 2025/11/27 李俊起 LangChain Meetup Tokyo #7
2. 自己紹介 2025/11/27 2 名前 李 俊起（イ ジュンギ） / Joonki Lee 所属 KINTOテクノロジーズ株式会社 Platform Group / Platform Engineer 関心分野 Observability Kubernetes 生成AI
3. 話す内容 2025/11/27 3 • アラート原因分析AI Agent導入背景 • アーキテクチャ & 処理フロー • 分析結果例 • 現在直面している課題 • 今後について
4. 2025/11/27 4 アラート原因分析AI Agent導入背景
5. アラート対応のつらさ 2025/11/27 5 良く分からない アラートが出てる けど何をどこから 調べればいいの？ ナレッジが俗人化して いて対応できる人が 限られている 原因分析に時間がかかり、 対応/復旧までの時間 （MTTR）が長くなる
6. そこでAI Agentの出番 2025/11/27 6 複雑で状況に応じて柔軟な対応が必要な、 定型化が難しい作業にはAI Agentが適している
7. どういうAgentを作ったか 2025/11/27 7 • NewRelic、CloudWatch、Grafanaからのアラート発報をトリ ガーに、原因分析を行い、対処案の提案までできるもの • インフラレイヤーだけではなく、アプリレイヤーまで確認できるもの • 過去の履歴（ドメイン知識）を分析に活用できるもの • アラートの通知から原因分析結果の通知、コマンド実行まで、 すべてSlack上で行えるようにする（ChatOps）
8. 2025/11/27 8 アーキテクチャ & 処理フロー
9. 現在のアーキテクチャ（2025/11時点） 2025/11/27 9 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）
10. 処理の流れ 1/４ 2025/11/27 10 VPC NewRelic Lambda CMDB Health Dashboard リカバリー基盤 SQS Recovery Lambda Agent Lambda 該当システムの HealthCheck Endpoint API Gateway SlackBot Lambda SQS アラートが発報されると、Lambdaが Slackにアラート内容の通知と 原因分析処理開始のお知らせをする。 それと同時に原因分析処理を 非同期で行うため、SQSキューに メッセージを送信する WebHook CloudWatch Alarm
11. API Gateway SlackBot Lambda 処理の流れ ２/４ 2025/11/27 11 VPC NewRelic Lambda リカバリー基盤 SQS Recovery Lambda CMDB Health Dashboard 該当システムの HealthCheck Endpoint SQSからキューを取得し、AI Agentが処理を開始する。 Agentによる原因分析処理の前に、CMDBから取得した アラートが発生したシステムの情報(e.g. リソース一覧)や AWS Health Dashboardなどの情報をSystem Promptに入れる SQS Agent ECS EventBridge Pipes Step Functions
12. SQS EventBridge Pipes Step Functions CMDB Health Dashboard 該当システムの HealthCheck Endpoint API Gateway SlackBot Lambda 処理の流れ ３/４ 2025/11/27 12 VPC リカバリー基盤 SQS Recovery Lambda NewRelic Lambda CloudWatch Aurora ECS ELB その他 リソース アラートが発生した システムのリソース 『AWS CLI』と『NewRelicのクエリーを実行できるtool』を使って、 React Agentが、CMDBから取得したシステム情報を元に対象システム のアラートが発生したシステムのリソース(＋関連するリソース)の状態や NewRelic上のメトリクス・ログ・トレースを確認しながら、 原因分析と暫定対応コマンドの生成を行う Agent ECS Aurora （Vector Store） NLB EKS o11y Lambda
13. NewRelic Lambda CMDB Health Dashboard 該当システムの HealthCheck Endpoint SQS API Gateway SlackBot Lambda 処理の流れ ４/４ 2025/11/27 13 VPC リカバリー基盤 SQS Recovery Lambda 原因分析結果と暫定対応コマンドを Slackに通知 Agent ECS
14. 2025/11/27 14 分析結果例
15. ALBのResponse遅延アラートからDB Index最適化を提案 2025/11/27 15 インフラリソースは 正常であることを 確認 ログからトレースIDを特定し、 さらにトレースから アラートの原因となったSQL を特定 問題の原因を特定 対応方法を提案 （Index最適化）
16. 2025/11/27 16 ALBのUnHealthyHostアラートに対して、対応不要と案内 ALBのTarget Group のヘルスチェックに失敗 したTargetを検知 新しいバージョンのECS Taskへのローリングアップデートによ る一時的なアラートで、すでに解決済みであり、対処不要と案内
17. エラーログから、エラーの原因のコードを特定し、コード修正を提案 2025/11/27 17 エラーログと関連するコード の部分を特定し、原因と なっているロジックを分析 コードの修正方法について提案 エラーログを元に調査
18. 2025/11/27 18 現在直面している課題
19. Context Engineering 2025/11/27 19 • Context溢れ ➢ 1回の推論で複数のツールが呼び出されたりすると、Outputが膨大な 量になって、LLMモデルのInput Token Limitを超過してエラーになる ➢ 要約やFileSystemへの退避などを検討中
20. 評価について 2025/11/27 20 • 評価が人に依存 ➢ Good/Badボタンを設けているが、なかなか押してくれない • 正解データの不在 ➢ 同じアラートでも毎回原因が同じとは限らないため、正解データの作成 が難しい • 色々基準を設けてLLM as a Judgeでの評価を検討中 ➢ Toolの選択は適切か ➢ ToolのOutputと最終的な分析結果に相違はないか ➢ etc.
21. 2025/11/27 21 今後について
22. ロードマップ 2025/11/27 22 • 再分析機能追加 ➢ 1回の分析/提案で終わるのではなく、人が追加のコンテキスト情報を 与えて、再分析/提案を実施できるようにする • ToolをMCPサーバとして公開 ➢ アラート発生時だけではなく、通常時でも自然言語から テレメトリーデータの確認ができるようにする
23. 一緒に働く仲間を探しています 2025/11/27 23 クラウドプラットフォーム エンジニア カスタマーサクセス エンジニア AI x Platform
24. ご清聴ありがとうございました！