「さらばアラートノイズ！」 AIエージェントでインシデント対応を自動化する

Transcript

1. 「さらばアラートノイズ！」 AIエージェントでインシデント対応を自動化する
2. 話すこと • なぜAIエージェントが必要だったのか • ADKを使ったインシデント対応エージェントの開発 • AIエージェントのオブザーバビリティ
3. スピーカー 1 髙橋 和真 (Takahashi Kazuma) クラウドエース株式会社 DevSecOps事業部 Engineer Work Google Cloudを中心としたシステムの開発、運用を担当 Tech SRE O11y Serverless Award Google Cloud Partner Top Engineer 2025 SNS X：@kazzuvi Github：@kazuvi
4. なぜAIエージェントが必要だったのか
5. アラートノイズとの戦い • アラートノイズ システムに影響がなく優先度の低い、対応不要 なアラートにより対応の時 間だけが奪われていく現象。 弊社の運用保守チームでは、特に高頻度で Cloud IDSによる攻撃検知アラートが 鳴ることに悩まされていた。 このアラートを確認し調査することはセキュリティ上重要だが、 そのほとんどはシステムに実害のない 攻撃の"試み"だった。 実態として対応が不要であっても、攻撃の調査時間は必要になり、 その分睡眠や開発にさける時間が減ってしまっていた。
6. アラートをミュートすれば良いのでは？ 実際に攻撃されている以上無視はできない。閾値を上げすぎて、 本当に危険なアラート を見逃すことだけは避けないといけない。 結果として、「復旧作業は不要だが、ログを確認して影響の有無を判断す る」という人間による調査作業が残ってしまった。
7. 問題の焦点をシフトさせる ノイズを減らすべく閾値を調整するのは、本当に対処すべきアラートを考慮 すると非常に難しい。 ノイズが多いことを問題とするのではなく、睡眠や開発にさける時間が減っ ているという部分に焦点を当て、 人間が対処する必要のない作業をさせられている 、ことに原因があるとし た。 AIエージェントに インシデント対応させて、 空いた時間で開発とかしよう
8. 一次対応エージェントの構築 AIエージェントをここでは 目標達成のため、繰り返し推論し、ツールを使って行動する ソフトウェアと定義する。 インシデントの一次対応として AIエージェントが入り、 システムに影響がある、もしくは調査が必要なインシデントだけを人間に通知する。 結果的に人間がアラートノイズに対処することない 運用保守が可能に！
9. 負担の改善 Primary, Secondaryの2人のエンジニアで対応していた運用保守チームに、 AIエージェント が加わることで、実質的に 3人体制に。 人間にエスカレーションされる =システムに問題がある、なので電話が鳴る 恐怖は倍増...？
10. ADKを使った インシデント対応エージェントの開発
11. エージェント構築のために AIエージェントは大きく分けて、ワークフロー型と自律型に分けられる。 • ワークフロー型 事前に定義されたフロー、ツールの指定にしたがってタスクを実行する • 自律型 目標だけを与え、ワークフローやツールの選定は全てエージェントに任せ る それぞれの中間をとったハイブリッド型もある。
12. エージェント構築のために AIエージェントを構築のためのフレームワークがたくさん出てきた 何を使うかによって、実装方式や思想も異なってくる。 • LangGraph（ハイブリッド） • LangManus（自律） • Mastra（ハイブリッド） • ADK（ハイブリッド） など
13. ADKとは Agent Development Kit（ADK） Google Cloudから提供されているAIエージェント を構築するためのフレームワーク 外部ツールを使ったり、複数のエージェント を使ったシステムを構築できる。 自律ベースでありながら、挙動を制御する ための仕組みも提供してくれている。
14. スピーカー 2 三原 知樹 (Mihara Tomoki) クラウドエース株式会社 DevSecOps事業部 Engineer Work Google Cloudを中心としたシステムの開発、運用を担当 SNS Github：@TomokiMihara
15. エージェントのライフサイクル 責務ごとにエージェントを分離するマルチエージェントアーキテクチャ SequentialAgentでワークフローのように 順番にエージェントを実行
16. エージェントとツール エージェントごとにツールを定義
17. エージェントのライフサイクル エスカレーションが必要なしと判断された場合 エスカレーションが必要ありと判断された場合
18. ・ツールが適切に利用されない 　→ツールの関数名やdoc stringが実際にツールの 呼び出しの性能に関わってくる 　→クリーンコードがメンテナビリティのみならず、性能 に影響を及ぼす →ツールの呼び出しが確実に実行される保証は無 いため、ツールの呼び出しが無かったらリトライ処理 なども別途必要 ハマった事
19. AIエージェントのオブザーバビリティ
20. エージェントの抱える課題 AIエージェントの挙動はそのままではブラックボックス化 して しまう。動作に問題が起きても、なぜそうなったか分からない。 プロンプトのチューニング、モデルの更新、実行時間やお金など、様々 な考慮すべきことがあるため、 AIエージェントのオブザーバビリティ が重要となってくる。
21. Langfuseの導入 Langfuse LLMアプリケーション向けに設計 された観測・分析プラットフォーム できること • トレースの可視化 • プロンプトの評価と管理 • フィードバック収集 などなど
22. 一次対応 AIエージェン トもLangfuseにトレー スを送り、チューニング の参考にしていたりし ます。各エージェントの レイテンシも計測できる ので、マルチエージェン トアーキテクチャはオブ ザーバビリティ 観点で も重要だと言えます。
23. 作って・自動化させて終わりではない エージェント自身の運用管理 が増えてしまう 挙動を見て、分析し、改善するというサイクルは AIエージェント にも必要。銀の弾丸ではない。 Langfuseをはじめとした LLMオブザーバビリティ ツールを活用しましょう。