【CNDW2025】アラート起点の原因分析をAIで標準化するKINTOテクノロジーズのエージェントアーキテクチャ

アラート対応の属人化を解消するAI導入の必然性

CloudNative Days Winter 2025で登壇したKINTOテクノロジーズの李 俊起（イ・ジュンギ）氏は「アラートだけでここまで分析できるの？ AI Agentで切り開くアラート対応の新時代」と題して、アラート調査を自動化するAIエージェントの開発事例を紹介した。アラート対応は現場で属人化し、特定の有識者への依存が強くなりがちである。とりわけ、原因がインフラ側かアプリケーション側かを切り分ける作業は高度な知識を要し、経験の浅いメンバーにとっては大きな負担となっていた。

李氏は当時の状況をこう振り返る。「知らないシステムのアラートが飛んできたとき、まず誰に訊けばよいのか探すところから始まっていました」。100を超えるシステムを監視する中で、有識者への依存により調査時間が延びる問題が顕在化していた。こうした「都度判断が必要で、かつ定型化が難しいタスク」こそ、AIエージェントが適していると考えたことが、プロジェクトの出発点である。

KINTOテクノロジーズが構築したAIエージェントは、監視ツールから受信したアラートをトリガーに、原因調査と解決策提示を自動で行う仕組みである。「状況に応じて次に調べるべき箇所を推論でき、細かなフロー制御も簡単に実装できる」として、李氏はLangGraphを採用した。アーキテクチャはサーバーレスかつイベント駆動で構成され、WebhookからAPI Gateway、SlackBotを経由してアラート内容を整形し、Slackへ通知する。同時にSQSを介してエージェントが起動し、CMDBに保存された構成情報を参照しながらAWS CLIや各種クエリツールで状況を分析する。分析結果と対応案はSlack上に提示され、担当者は迅速に状況を把握できる。

全体アーキテクチャ（Phase1 リリース時）

アプリとインフラを跨ぐ調査を支える基盤の進化

フェーズ1のリリース後、開発・インフラの両チームから改善要望が相次いだ。開発側からは「アプリケーションレイヤーまで調査してほしい」、インフラ側からは「CloudWatchアラームにも対応したい」といった声が寄せられた。さらに復旧コマンドの安全性に関する懸念、エージェントの処理内容の可視化、過去インシデントの活用といった課題も明らかになった。

李氏は、アプリ側の調査に対応するためコードベース分析機能を実装した。「コードに起因する障害でも、AIが根拠を示して問題箇所を特定できるようにしたかったのです」と李氏は説明する。Claude CodeをToolとして組み込むことで、アラートとコードの関連性を調査し、修正案まで提示する仕組みが実現した。またSlackからGitHub Issueを起票し、そのIssueをトリガーにAIがPRを自動生成するフローも追加した。

これらの機能拡張によりLambdaの「15分実行制限」が課題となったため、エージェントの実行基盤はLambdaからECSへ移行され、Step Functionsを中間層に挟む構成へ刷新された。これによりサーバーレス構成を維持しつつ、複雑な解析にも対応できる柔軟性が確保された。

CodeBase Analysis導入後の構成

社内ではNew RelicとGrafana系OSS、CloudWatchなどが混在しているため、ツールごとにアラート形式が異なる問題があった。エージェントはユーザーエージェントヘッダーから発報元を判別し、ツールごとに異なるデータ抽出処理や利用可能なToolを制御する設計が施されている。「エージェントが使えるツールは発報元に応じて制御し、System Promptも切り替えています」と李氏は語る。

復旧コマンドの安全性確保においては、LLMによる検証とリカバリ基盤でのバリデーションチェックという二重のセーフティネットを導入した。しかし李氏は「本番環境で実行する判断が難しく、実際に実行されたことはありませんでした」と語る。利用者からの「分析だけ使いたい」というニーズに応え、コマンド実行ボタンを非表示にできる設定を追加したのも運用上の工夫である。

統合管理とRAG活用が支える実践的なAI運用基盤

李氏はAIエージェントと連携するIncident Managerについても詳細に説明した。このシステムはアラート単位でインシデントチケットを自動生成し、エージェントの分析結果を紐づけて管理できる仕組みである。内製にこだわった理由として、データを自社環境で保持したいこと、RAGに用いるVector Storeへのデータ連携を自分たちで制御したいこと、そしてエージェントとのネイティブな連携を実現したいことの三点を挙げている。Incident Managerには処理ログの確認機能、システム構成の俯瞰表示、RAG検索機能などが備わり、アラートの前後を統合的に把握できる環境が整えられた。

RAG実装では、当初Bedrock Knowledge Baseを利用していたが、Aurora PostgreSQLが低コストであったことから切り替えた経緯がある。日本語のハイブリッド検索のための形態素解析がサポートされていなかったこと、検索結果のランキング戦略の難しさなどの課題もあったという。チャンク戦略としては、一つのインシデントチケットを一つのチャンクとして保存する方式を採用し、検索タイミングやクエリを最適化することで推論精度を高めている。

李氏は、ALBレスポンス遅延アラート、ALBアンヘルシーホストアラート、コードベース分析が発動したケースの三例を紹介し、アラート起点で調査範囲を広げ、属人化しがちな判断プロセスを標準化できた効果を示した。

現在のアーキテクチャ（2025/11時点）

今後の展望として李氏は「再分析機能の追加と、エージェントのツールをMCPサーバーとして公開する取り組みを進めています」と語り、社内にとどまらず外部との連携を視野に入れた発展を示した。

最後に李氏は、AIエージェントから期待した結果を得るために欠かせない三つの要素として、システムプロンプト、コンテキスト、ツールの重要性を強調した。「プロンプトの設計、文脈の与え方、使わせるツールの制御。この三つが揃って初めて、エージェントが人間の代わりに調査を進められるようになります」と締めくくり、AIエージェントによる新しいアラート対応の姿を提示した。