アラート対応をAIエージェントでどこまでできるか試してみた

DevelopersIO 2026 Nagoya（2026年10月9日）の登壇資料です。

アラートが鳴ってから「原因を調べる」「直してプルリクエストを出す」までを、AWS DevOps Agent と Claude Code にどこまで任せられるか、検証環境で試した結果をまとめました。

登壇レポート: （ブログの URL）
#devio2026

Transcript

1. アラート対応をAIエージェントでどこま でできるか試してみた クラスメソッド株式会社 製造ビジネステクノロジー部 ⽯井 悠汰
2. 普段の業務で、AIエージェントを使っていますか 社内導⼊に向けて動いている最中という⽅もいらっしゃるかと思います。 またAIの話かよ、と思われるかもしれません それでも今⽇はAIエージェントの話をします。 2
3. 今⽇の流れ 1. 運⽤保守って、何をしている仕事か 2. そのどこにAIが効いて、どこに効かないのか 3. 実際に作って試した結果 4. どこまで任せられるのか 3
4. ⾃⼰紹介 ⽯井 悠汰（Ishii Yuta） • • • 経歴 ◦ 福岡出⾝ ◦ 前職：⿅児島で⽣産管理システム開発 ▪ Spring Boot（API）× React（UI）× Docker ◦ 2025年11⽉：クラスメソッドにジョイン ▪ TypeScript / HonoでAPI開発 趣味： ◦ 飲み会、美味しいもの探し ◦ ドライブ、旅⾏ 現在の⽬標： ◦ AWS全冠（残り1つ — ANS） 4
5. 運⽤保守って、何をしている仕事か 5
6. ⾃分が思いつく限りで、このぐらい • • • • • • • ⽉次の運⽤報告書をまとめる 問い合わせに答える アカウントを発⾏する、権限を⾜す 証明書の期限を⾒て更新する ログをローテートする、保管期間を決める バックアップが取れているか確かめる OSにパッチを当てる • • • • • • • ライブラリのバージョンを上げる EOLの告知が来たので影響を調べる コストが跳ねた理由を調べる 脆弱性スキャンの結果を仕分ける 性能が落ちた原因を探す アラートが鳴ったので原因を調べる 直して、リリースする 6
7. 今⽇話すのは、この2つ • • • • • • • ⽉次の運⽤報告書をまとめる 問い合わせに答える アカウントを発⾏する、権限を⾜す 証明書の期限を⾒て更新する ログをローテートする、保管期間を決める バックアップが取れているか確かめる OSにパッチを当てる • • • • • • • ライブラリのバージョンを上げる EOLの告知が来たので影響を調べる コストが跳ねた理由を調べる 脆弱性スキャンの結果を仕分ける 性能が落ちた原因を探す アラートが鳴ったので原因を調べる 直して、リリースする 7
8. ⾃動化の現在地 8
9. ⾃動化の進み⽅ ① すでに⾃動化できている作業 ② ⼈が残っていた作業 ③ まだ⼈がやっている作業 今回検証 ログのローテート アラートの原因調査 サーバーの再起動 証明書の更新 コスト異常の原因究明 デプロイ OSのパッチ 脅威検知のトリアージ お客様への報告 バックアップ ログの読み取り 判断が要らず、ルールで書ける 検知は⾃動化済み 鳴った後が、⼈だった 実⾏と判断 今⽇話すグループ 9
10. ① すでに⾃動化できている作業 • ログのローテート、証明書の更新 • OSのパッチ、バックアップ • 判断が要らず、ルールで書ける定型作業 とっくに⾃動化できる作業になっている。ここにAIを持ち込む理由はない。 10
11. ② 判断が要るので、⼈が残っていた作業 • アラートが鳴った。で、何が起きているのか ← 今回検証したのはここ • コストが跳ねた。で、なぜ上がったのか • セキュリティの検出結果が100件出た。で、どれを優先すべきか 11
12. 同じ形で、今年 AI が⼊ったもの ⼈が残っていた作業 2026年に AWS から出たもの 今回の扱い アラートの原因調査 AWS DevOps Agent（GA 2026-03） 今回検証 コスト異常の原因究明 AWS FinOps Agent（プレビュー 2026-06） 調べた範囲 脅威検出のトリアージ GuardDuty 調査エージェント 調べた範囲 ログの読み取り CloudWatch ⾃然⾔語クエリ‧Log Analytics（2026-06） 調べた範囲 どれも「検知の後」に⼊っている。 今⽇はアラート対応だけを深掘りする。 12
13. ③ まだ⼈がやっている作業 • サーバーを再起動する • デプロイする • お客様に報告する 13
14. 今回試したこと 14
15. 題材にしたアプリと、5つの障害 架空の受注処理アプリの裏側。画⾯は無く、受注の取り込み‧レポート集計‧レコード取り込み‧レ ポート読み出し‧請求書取得の Lambda 5本が共有の S3 バケットを読みに⾏く。関数名は答えが分 からないよう中⽴にしてある。 関数 仕込んだ障害 原因の所在 order-intake 原因がログに明記された例外を投げる コード（ベースライン） report-aggregator メモリを無限に確保し続けて使い切る コード record-importer WARN ログだけ出して処理は成功する 障害ではない（ノイズ判定） report-reader S3 の読み取り権限が無く AccessDenied インフラ（IAM） invoice-fetcher 存在しない S3 オブジェクトを参照する データ∕コードの不整合 15
16. 何を⾒たか ⾒た項⽬ • • • • 原因を正しく当てられるか どこまで⼈の⼿が要るか 時間がどれくらいかかるか 料⾦がいくらかかるか 条件 • 各シナリオ 1回ずつ • ⼈は追加で指⽰しない • 検証⽤のサンドボックス 16
17. 今回やっていないこと • 本番環境では試していない（料⾦が読めなかったため、今回は検証の み） • カスタマイズの範囲はこれから。良さそうならお客様にも提案したい • 複数アカウントにまたがる調査はしていない • 先に並べた他の運⽤業務も試していない 17
18. どう作ったか 18
19. 設定するだけの部分と、⾃分で書いた部分 壊れた Lambda エラー ×5 CloudWatch アラーム発⽕ アラーム 転送 Lambda HMAC 署名 Webhook AWS DevOps Agent ⾃律調査 完了通知 EventBridge 調査完了イベント 起動 CodeBuild + Claude Code push / PR GitHub プルリクエスト 紫：CloudWatch アラーム、AWS DevOps Agent。設定するだけ オレンジ：アラーム転送 Lambda、CodeBuild 上のスクリプト。⾃分で書いた（配線 300⾏ほ ど、CDK で 500⾏弱） なぜ⾃分で書く必要があったのか。後半で話します。 • • 19
20. 結果 20
21. ⼈が何も指⽰しない状態で、ここまで出る 21
22. 5つとも、原因を当てた • 5つの障害すべてで根本原因を正しく特定 • ただし、各1回ずつしか試していない 22
23. 実際の調査結果をひとつ紹介 ログは「メモリ上限128MBを使い切った」。 エージェントはコードを読んで無限確保ループを⾒つけ、メモリ増量では直らないと報告し た。 23
24. 料⾦と、費⽤対効果 • 調査1回あたり 5〜9ドル。検証全体で 64ドル • ⽉20件なら 100〜180ドル。 エンジニアが⾒る前に、⼀次調査が終わっている。 調査結果を読んで判断できる運⽤担当がいれば、エンジニアの⼯数を割かずに回る。 24
25. 出てきたプルリクエスト 25
26. 確認できていないこと • リリース判定の機能は東京リージョンで使えない（バージニア北部の み） • 本番環境では試していない • 複数アカウントにまたがる調査も未検証 26
27. まとめ 27
28. 何で、どこまでできたか 原因を調べる • • ⼈の介⼊ゼロで到達 ⽤意した正解より深いところまで 直して PR を出す • • 到達したが、⾃分で配線を書く必要 があった サービスを設定するだけでは届かな い 28
29. ⼈間の作業として残ったもの • プルリクエストをレビューして、マージを決める • 本番にデプロイする • お客様に報告する 29
30. AIは、どこまで⽀援してくれるのか どこまで 何が要るか 調べる 原因と直し⽅が出る。⼈の介⼊ゼロ、⼗数分 設定するだけ 直す プルリクエストまで出る 配線を⾜す（300⾏ほど） 決める マージ‧デプロイ‧お客様への説明 ⼈ これから：リリース判定が東京に来れば PR → リリース判定まで繋がる。 コスト‧脅威検知にも同じ形のエージェントが出てきている。 30
31. なごやクラメソゆる勉強会 #6 • • • • • 2026年11⽉4⽇（⽔）19:00〜21:00 クラスメソッド名古屋オフィス（伏⾒駅徒歩5分） 「Claude Codeで⼀歩踏み出す：⼿を動かしてつくっ てみよう」 その場で Claude Code と対話しながらアプリを作る 実践回 定員15名‧先着 https://classmethod.connpass.com/event/408161/ 31
32. ありがとうございました