「アラート対応をAIエージェントでどこまでできるか試してみた」というタイトルで DevelopersIO 2026 Nagoya に登壇しました #devio2026
こんにちは！製造ビジネステクノロジー部の石井です。
2026年10月9日（金）に開催された DevelopersIO 2026 Nagoya で、「アラート対応をAIエージェントでどこまでできるか試してみた」というタイトルで登壇しました。
イベントページには「AIエージェントで運用保守はどこまでラクになるのか試してみた」というタイトルで載っていたセッションです。準備を進めるうちに話す範囲をアラート対応に絞ったので、当日は今のタイトルに変えて話しました。
この記事ではスライドの流れはなぞらず、やったことと結論、それから実際に触ってみてどうだったかの要点をまとめます。登壇では時間が足りず話せなかったことと、登壇後に追加で試したことも入れました。
登壇資料
アラート対応をAIエージェントでどこまでできるか試してみた - Speaker Deck
やったこと
運用保守の作業の中から「アラートが鳴ったので原因を調べる」と「直して、リリースする」の2つに絞り、AI エージェントにどこまで任せられるかを検証用の環境で試しました。検知はとっくに自動化されているのに、鳴った後は人が調べている。今年 AI が入ってきたのは、まさにこの部分です。
構成はこんな感じ。
-
わざと壊した Lambda がエラーを出し、CloudWatch アラームが鳴る
-
転送用の Lambda が HMAC 署名を付けて、AWS DevOps Agent の Webhook に投げる
-
DevOps Agent が自律的に原因を調べる
-
調査完了のイベントを EventBridge で拾って CodeBuild を起動し、Claude Code（Amazon Bedrock 経由）がコードを直してプルリクエストを出す
紫が AWS のサービスで、設定するだけの部分。オレンジが自分で書いた部分。登壇時点で、アラームを DevOps Agent に転送する Lambda が210行ほど、修正役を動かす CodeBuild のスクリプトとプロンプトが150行ほど。インフラ定義は CDK で550行ほどです（壊した Lambda やアラームの定義も込み）。
壊し方は5種類用意しました。原因がログに書いてある例外、メモリを無限に確保し続けるもの、WARN ログだけ出して処理は成功するもの（つまり障害ではない）、S3 の読み取り権限がないもの、存在しない S3 オブジェクトを参照するもの。コード・インフラ・データ・そもそも障害ではないもの、と原因の場所をばらしてあります。各シナリオ1回ずつ、人は追加の指示を出さない条件で回しました。
結論
| どこまでできたか | 何が要るか | |
|---|---|---|
| 調べる | 原因と直し方が出る。人の介入ゼロ、十数分 | 設定するだけ（アラームから自動で始めるなら、転送用の Lambda を1本） |
| 直す | プルリクエストまで出る | 配線を足す（150行ほど） |
| 決める | マージ・デプロイ・お客様への説明 | 人 |
調べるところは任せられる。直すところは配線すれば届く。決めるところは人。今回の検証で引けた線はここです。
実際どうなのか
調べるところ
5つの障害すべてで根本原因を正しく特定しました。各1回ずつなので正答率とは言いません。見てほしいのは当たり方のほう。
たとえばメモリを使い切るシナリオ。ログには Runtime.OutOfMemory、メモリ上限128MBを使い切った、と出ます。素直に読めば「メモリを増やせば直る」。
ところが調査結果に書かれていたのは「メモリ引き上げのみでは解決不可。コード修正が必須。」。コードを読んで、while(true) の中でメモリを無制限に確保し続ける実装を見つけていました。ログの記述を鵜呑みにせず、実装まで確かめにいく。5本中4本で、こちらが用意した判定基準より深いところまで調べてきています。
調査にかかった時間は10〜26分。わざと壊した Lambda を動かしてからプルリクエストが出るまでは、15分前後。いちばん速い回で14分24秒でした。
直すところ
DevOps Agent を設定するだけでは、プルリクエストまでは届きません。
検証した時点（2026年10月上旬）では、DevOps Agent の GitHub 連携で書き込めるのは Issue の作成と、プルリクエストへのコメントの2つだけでした。
AWS 側も同じ構造です。IAM でほぼ全アクションを許可していても、エージェントが変更に使えるのはコンソールに並ぶ厳選されたアクションだけ。Lambda のコード差し替え（UpdateFunctionCode）は入っていて、メモリや環境変数をまとめて変える UpdateFunctionConfiguration は入っていません。
なので、調査完了のイベントを拾って Claude Code に渡す配線を自分で書きました。
DevOps Agent が「調べる側」、Claude Code が「直す側」という分担です。
プルリクエスト
やりたかったこと
直す必要のないアラートで、修正のプルリクエストを出さずに済むか。
やったこと
障害ではないアラートを2種類用意しました。WARN ログを出すだけで処理は成功するもの（シナリオ3）と、呼び出し元が不正な住所を送り、コードがそれを正しく弾いたもの（登壇後に追加）です。
登壇後に、修正プロンプトへ「直す必要がなければ何も変えない」という判断の手順を足して、元のプロンプトと比べました。足したのは、修正の手順の前に置いたこの部分です。
1. 変更が必要かの判断
.investigation-summary.md を読み、このリポジトリのコードや設定を変更する必要があるかを、まず判断する。
次のどちらかに当てはまる場合は、ファイルを一切変更せず、.pr-body.md も作らない。
- 調査結果から、障害（処理の失敗や、利用者・データへの影響）が起きているとは言えない
- 直すべき箇所と直し方を、調査結果から根拠をもって決められない
変更しない場合は、その理由を2〜3文で出力して終える。変更が必要な場合だけ、2と3に進む。
結果（結論）
| 調査の結論 | Claude Code の動き |
|---|---|
| 障害ではないと判定しつつ、修正仕様も出す（実際の調査3回） | どちらのプロンプトでも、修正仕様どおりに直す（9回中9回） |
| 対応不要と結論する（レポートを作って確認） | 元のプロンプトでは何かを直す。手順を足すと止まる（2回中2回） |
| 直すべき障害と結論する | 手順を足しても、ちゃんと直す（3回中3回） |
修正役は、調査の結論に従います。そして調査は、障害ではないと判定しても、ほぼ必ず修正仕様を付けてきます。重大度 low や medium、「誤検知」「ユーザー影響なし」と書いたうえで、恒久対策としてコードやアラームの変更を出す。これまでの17件の調査で、「対応不要」で終わったものは1件もありません。
なので、プロンプトでは止められませんでした。重大度で分ける手も、呼び出し元の入力ミスは medium だったので効きません。しかも出てくる修正は、仕様どおりでもそのまま入れられないものがありました。入力の形を推測で作る、全関数のアラームに効く部分を書き換える、ログを WARN に下げても WARN も数えるアラームは鳴り続ける、など。
修正のプルリクエストは出るもの、と考えておく。マージは人が判断する形にしておく必要があります。
DevOps Agent がリソースの変更に承認を求めるのも、誤った修正が勝手に入るのを防ぐためのはず。外のコーディングエージェントに渡すなら、その歯止めは自分の配線の側で用意することになります。
気になったところ: 料金
DevOps Agent の料金は、エージェントが実際に動いていた秒数 × 0.0083ドル。待っている時間は数えないので、調査にかかった時間より少なめになります。1回あたり5〜9ドルで、10月8日までの検証で64ドルでした。CodeBuild は1回2分ほどなので数円。
自分が担当している案件だと、アラートは月5〜10件ほど。全部を調査に回したとして、単純計算で月25〜90ドルです。
この額をどう見るか。得られるものは大きく2つあると思っています。
- 初動が速くなる。エンジニアが見に行く前に、一次調査が終わっている
- 修正が速くなる。障害が起きてからプルリクエストが出るまで、15分前後
調査結果を読んで判断できる運用担当の方がいれば、エンジニアの工数を割かずに初動を回せます。アラートのたびにエンジニアが調べ始めて、直すまでにかかっていた時間。それと比べて月25〜90ドルが見合うかどうかが、判断のポイントになりそうです。
登壇後に検証: 調査結果の出力
登壇後に検証したのが、調査結果の出力形式です。
やりたかったのは、調査結果を運用担当の方が読みやすい形で出すこと。エージェントへの指示で、「影響を受ける機能」から「緊急性」までの8項目で出すよう指定しました。試したのは次の3回です。
| 時点 | 指示の内容 | レポートの構成 |
|---|---|---|
| 登壇時点 | インシデント向けの指示に8項目を指定 | 変わらなかった |
| 10月21日 | 上に加えて、「組み込みの構成よりこの指示を優先する」と明記 | 変わらなかった |
| 10月22日 | 上に加えて、全体共通の指示にも優先順位を明記し、チャット向けの指示も追加 | 変わらなかった |
優先順位を明記するやり方は、AWS DevOps AgentのSlackの返答形式をAGENTS.mdで変えてみた を参考にしました。記事はチャットの返答の書式を変える内容で、10月22日は指示の置き方を記事と同じ条件にそろえています。
結果はどの回も、レポートは組み込みの構成（概要、原因、緩和策、コード修正仕様など）のまま。8項目の見出しは出てきませんでした。
試していないこと
- 本番環境
- 複数アカウントにまたがる調査
- Lambda 以外のワークロード
- リリース判定の機能（東京リージョンでは使えず、バージニア北部のみ）
最後に
実案件で使うならどうするか。ここは個人的な所感です。
原因を調べるところは、5つとも人の介入なしで当たりました（各1回）。ログを鵜呑みにせず、実装まで確かめにいく調べ方もしてくれます。一方で、料金は1回5〜9ドルとわりとかかりますし、レポートの構成は指示では変えられませんでした。
なので、いきなり導入するより、まずは試してみるのがいいと思っています。確かめたいのは次の2つ。
-
組み込みのレポートの形で、自分たちの欲しいアウトプットになっているか
-
料金に見合うだけ、調査の手間が減るか
この2つが合うかを見たうえで、導入するかを判断するのが良さそうです。
とはいえ、DevOps Agent は2026年3月に GA したばかりのサービス。レポートの構成を指定できるようになったり、リリース判定の機能が東京リージョンに来たりすれば、評価もまた変わってくるはずです。今後のアップデートに期待！
聞いてくださった方、ありがとうございました！
ちなみに、Claudeの導入・活用はクラスメソッドで総合支援しています。
おまけ
クラスメソッド名古屋オフィス（伏見駅徒歩5分）で月イチペースで開催している「なごやクラメソゆる勉強会」、第6回を2026年11月4日（水）に開催します！
今回のテーマは「Claude Codeで一歩踏み出す：手を動かしてつくってみよう」。前回の Claude Code の基本・活用事例の回の続編で、その場で Claude Code と対話しながらアプリを作る実践回です。テーマは自由、PC の持ち込みも任意。名前のとおりゆるめの雰囲気なので、気軽に参加できます！
詳細・申し込みはこちらから！
