AWS DevOps Agent にアラームの一次調査をやらせてみた

SREチームの平木です。普段はプロダクトのAWSのインフラ全般を担当しています。

ご存知の通り、本番インフラを運用していると業務のひとつにインシデント対応があります。メトリクスを見て、ログを追って、直近のデプロイを確認して……という切り分けは、経験に依存しがちで属人化しやすい作業です。

そこで、2026年3月に一般提供された AWS DevOps Agent（自律的にインシデント調査を行うエージェント）を検証しはじめました。最終的には「CloudWatchアラーム → 自動で調査 → 結果をSlackへ → ゆくゆくは復旧まで」を目指していますが、本記事はその第一歩として、セットアップと手動での調査を通じてエージェントの実力を確かめたところまでをまとめます。

AWS DevOps Agent とは

AWS DevOps Agent は、経験豊富な DevOps エンジニアの一人としてインシデントの解決と予防を自律的に行い、テレメトリーデータ等を横断的に分析し、インシデント対応を支援します。 2026年3月にGAし、東京リージョンでも利用できます。

管理者向けのコンソール（AWSマネジメントコンソール）でAgent Space（調査の土台）を作成
運用者向けのWebアプリ（Operator app）で、調査の実行・チャット・トポロジ閲覧を行う
調査の起動方法は「ServiceNowなどのビルトイン連携」「PagerDuty/GrafanaなどのWebhook」「手動」の3種類

AWS DevOps Agent

やってみた

1. Agent Space を作成

Agent Space の詳細 > 任意のエージェントスペース名を入力
エージェントの応答言語 - オプションはJapanese(Japan)を選択
この Agent Space AWS リソースへのアクセスを許可するにて、新しい DevOps エージェントロールを自動作成を選択 ※ 調査時に DevOps Agent がこのアカウントのリソースを発見・参照するためのIAMロールを設定
ウェブアプリを有効にするにて、運用者が調査の実行・チャット・トポロジ閲覧を行う Operator app を有効 ※ 後ほど運用者が利用するため

Agent Space 作成完了。作成直後にリソース関係が自動マッピングされています

※この「マッピングされた関係」とは、エージェントがアカウント内のAWSリソース同士のつながり（依存関係・関連）を分析し、トポロジ（構成のグラフ）として把握した数です。画面では「エンティティのマッピング：リソースとその関係の分析」として、発見済みの関係数がカウント表示されます。障害調査では「このリソースの異常が、どこに波及するのか」「上流に原因があるのか」を追うために、リソース間の関係＝構成の地図が土台になります。ふだん人間が頭の中や構成図で描いているものを、エージェントが作成直後から自動で持っている状態、とイメージするとわかりやすいです。また、この件数は固定ではなく、画面の説明にもある通り調査を実行したり機能を追加したりするにつれて増えていきます。使うほどインフラの理解が広がり、調査の精度が上がっていく前提の指標です。

2. 今回調査題材となる「必ず失敗する Lambda関数」を作成

エージェントに調べさせるための「症状」となるもっとも単純な、必ず例外を投げる Lambda関数を作成 ※ lambda関数の作成の仕方は割愛します。

(関数の内容: Python 3.14を利用)

def lambda_handler(event, context):
    raise Exception("blog demo error")

これをテスト実行で数回叩くと、CloudWatch Logs には次のエラーが並びます。

[ERROR] Exception: blog demo error
Traceback (most recent call last):
  File "/var/task/lambda_function.py", line 2, in lambda_handler
    raise Exception("blog demo error")

原因は自分で分かっている 状態にしておくのがミソです。こうしておくと、エージェントの結論が正しいかを後で評価できます。

3. 手動で調査を依頼

上記で作成したエージェントスペース内よりウェブアプリを起動を選択

下記Operator appの「インシデントレスポンス」から、自然言語で調査を依頼します。

(例)Lambda関数 blog-error-demo で 2026-06-28 07:00 (UTC) 頃からエラーが急増している。原因を調査して。

ここで、わざと間違った関数名を渡してみました（実際に作った関数は別名でした）。この“意地悪”が、後述の見どころにつながります。

調査の様子

エージェントの調査タイムラインを時系列で観察しました。

経過	エージェントの動き
開始	調査を開始。リージョン未指定のため主要リージョンでLambdaを探索
+1m3s	指定された関数名が見つからない → より詳細な検索へ
+1m33s	諦めず CloudWatch Logs でインシデント時刻付近に活動したLambdaを時刻相関で探索
+1m49s	実在する関数（該当時刻に更新・エラー発生）を発見し「これが調査対象の可能性が高い」と自己補正
+2m6s	症状を文書化：5/5呼び出しが全てエラー、エラー率100%
+2m44s	ベースライン（正常時）を確認 → 直前に呼び出しなし。「新規デプロイ/設定変更に関連の可能性」
+2m48s	3つのサブエージェントを並行実行（logs-analysis / deployment-check / function-config）
+5m5s	最終レポートを生成

※下記のように表示されます。

根本原因（最終結論）

エージェントが出した最終結論はこうでした。

バグを含むコードがデプロイされたことが原因 ユーザーが UpdateFunctionCode で関数コードを更新。意図的な例外 raise Exception('blog demo error') を含むコードがデプロイされ、以降の全呼び出しがエラーになった。デプロイ前は呼び出しがなく、関数は新規作成の直後に更新されている。

CloudTrail の UpdateFunctionCode イベントから、いつ・誰が・何をデプロイしたかまで特定していました。

評価：当たっていたか

結論は完全に正解でした。仕込んだ「無条件の raise Exception」を、デプロイ時刻・実行者まで含めて言い当てています。ただし今回は「必ず失敗するコードが1箇所にある」という単一・明確な原因であり、比較的診断しやすい条件だった点は添えておきます。ここで、この一度の調査で見えた強みと限界を分けて記録します。

強み

入力が不正確でも自己補正する：存在しない関数名を渡されても、ログの時刻相関で正しいリソースに辿り着いた
並行調査 × 変更履歴の相関：logs / deployment / config を同時に当て、CloudTrailと突き合わせて「バグ入りコードのデプロイ」という根本原因に、実行者・時刻つきで到達した
トポロジを事前に学習済み：Agent Space作成直後から関係をマッピングしており、調査の土台がある

限界（鵜呑みは禁物）

調査の中盤に、エージェントは 「存在しないランタイムが指定されているのが根本原因」という誤った仮説を出しました。

ただしエージェントは自身が並行検証でこの誤仮説を棄却し、最終結論には含めなかったことを説明できていました。これは複数サブエージェントによる検証ループが効いていたと思われます。

コストについて

今回の検証は 0円でした。理由は料金体系にあります（金額・無料枠はいずれも 2026年7月時点 の公式Pricingページの記載に基づきます）。

AWS DevOps Agent は、エージェントが実際に稼働した秒数（agent-second）に対する従量課金で、レートは調査・評価・chatのいずれも $0.0083 / agent-second。アイドル時や待機中は課金されず、前払いもありません。

さらに新規顧客には 2ヶ月の無料トライアルがあり、毎月 Agent Space 10個・調査(incident response) 20時間・評価 15時間・オンデマンドSREタスク(chat) 20時間 まで無料です（AWS無料利用枠にも含まれます）。今回の数分の調査はこの枠に余裕で収まったため0円でした。

秒課金なので、コストは「調査にどれだけ時間がかかったか」に素直に比例します。今回の調査は約5分だったので、単純計算でも数ドル相当。重い調査ほど agent-second が伸びてコストは上がりますが、実額として請求に乗るのは無料枠を超えてから。消費した稼働時間は Operator app の Settings（使用量）から確認できます。

※ 料金・無料トライアルの数値は変更され得ます。最新は公式Pricingページでご確認ください（本記事は2026年7月時点の記載に基づきます）。

これから

今回、あまり時間が取れず「人が画面から調査を依頼する」ところまでで留めておきます。目指しているのはこの先です。

CloudWatchアラームからの自動起動：アラーム → Webhook経由でDevOps Agentを起動し、調査を自動で走らせる
結果をSlackへ：DevOps Agentには調査結果をSlackチャンネルへ投稿するネイティブ連携があります（ただし、Slackアプリのインストールがワークスペースの管理者承認制になっているケースもあり、そこは運用調整が必要でした）
ゆくゆくは復旧まで：DevOps Agentは緩和策の提案・実行も守備範囲なので、どこまで人が介在すべきかを見極めながら広げていきたい

このあたりは順次まとめていきます。