[登壇]opsmethod #1 に 「AWS DevOps Agent “裏で何している？” 〜証跡から可視化してみた〜」というタイトルで登壇しました！

クラウド事業本部運用イノベーション部の いそま です。

2026年2月13日(金)に開催されましたopsmethod #1 「そのシステム運用、AIに任せよう」にて、「AWS DevOps Agent “裏で何している？” 〜証跡から可視化してみた〜」というタイトルで登壇しました！

登壇内容

今回の登壇では、AWS DevOps Agentがどのように「調査」を裏で進めてくれているかについて、お話しをさせていただきました。
本テーマに決めた背景としては、AWS DevOps Agentが一生懸命調査してくれているのにも関わらず、その調査内容についてあまり深く言及されていないなぁと感じたからです。

AWS DevOps Agentとは

AWS DevOps Agent関連のブログは多数紹介されていますが、その中でもオススメのブログはこちらです。
キーノート内では語られなかった部分についても、盛り込まれた内容となっています。https://dev.classmethod.jp/articles/reinvent2025-report-cop362/

AWS DevOps Agent裏で何している？

AWS DevOps Agentはアラームを受信後、「調査」 → 「根本原因特定」 → 「改善策を提示」・・（以下省略）というような動きをしてくれています。

今回の登壇は、その「調査」の部分にフォーカスした内容となっています。

デモ
調査デモ用に以下の環境を作成しました。

① Lambda実行ロールからDynamoDBへの書き込み権限を剥奪
② ①の状態でAPI Gatewayからpostリクエスト
③ Lambda実行が失敗し、CloudWatch Alarmが発火
④ AWS DevOps Agentにてアラーム調査を実行する

結果
AWS DevOps Agentの「調査」は、大きく以下の５フェーズに分かれていました。
※DevOps Agentコンソール画面に表示されるログ／チャット機能、CloudTrailイベントログを元に推測した結果です

1. 初期情報収集
2. トポロジー発見
3. 並列調査
4. 根本原因特定
5. レポート生成

その中でも、今回私が注目したフェーズは「1.初期情報収集」「2.トポロジー発見」「3.並列調査」の３つです。

1. 初期情報収集
   実際の調査画面です。
   
   (翻訳)

2026年2月8日 01:23 UTC に ap-northeast-1 でアラーム状態になった CloudWatch アラーム「DEMO-DevOpsAgent-demo-devops-agent-LambdaErrors」を調査します。まずはアラームに関する情報収集と現状把握から始めましょう。

「> View details」を開くと下記の情報が出力されていました。

Describe alarms

{
  "service_name": "cloudwatch",
  "operation_name": "describe_alarms",
  "parameters": {
    "AlarmNames": [
      "DEMO-DevOpsAgent-demo-devops-agent-LambdaErrors"
    ]
  },
  "aws_region": "ap-northeast-1"
}

Describe alarm history

{
  "service_name": "cloudwatch",
  "operation_name": "describe_alarm_history",
  "parameters": {
    "AlarmName": "DEMO-DevOpsAgent-demo-devops-agent-LambdaErrors",
    "HistoryItemType": "StateUpdate",
    "MaxRecords": 10,
    "ScanBy": "TimestampDescending"
  },
  "aws_region": "ap-northeast-1"
}

JSONの内容から推測するに、以下のAPIが呼び出されていると考えられます。

2. トポロジー発見
   「トポロジー」とはアーキテクチャ図のようなものを想像してもらえればOKです。
   https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-what-is-a-devops-agent-topology.html

前述の「1.初期情報収集」にて、調査対象のアラームを確定した後、アラームに関係するリソース（今回で言えば、API GW・Lambda・DynamoDB・IAM(Lambda実行ロール)など）を把握しています。
ログには明記されていなかったのですが、AWS DevOps Agentはアプリケーション内のリソースの関係を自動的に検出して視覚化させることができる（＝トポロジー）ため、その機能を使用しているのではと考えられます。

少し話題はそれますが、調査対象のアラーム時間のズレも勝手に修正してくれているので助かります。

(翻訳)

アラームの詳細を確認できます。タイミングのずれに注意が必要です。

重要:ユーザーはアラームが「01:23 UT」に発生したと述べていますが、アラーム履歴には次のように表示されます。

アラームは2026年2月8日 05:07:36 UTCにのみ作成されました
最新のALARM状態: 2026-02-08 06:09:04 UTC (06:08:00 UTCに4つのエラーを検出)
OKに戻りました: 2026-02-08 06:15:04 UTC
アラームはLambda関数demo-devops-agent-demo-functionのエラーを監視します（しきい値：エラー1件）。UTCの6:08～6:09に発生した最新のアラームイベントを調査し、トポロジを確認してみましょう。

完璧です！トポロジーはできました。特定された症状に基づいて調査計画を作成しましょう。

3. 並列調査
   1,2で調査に必要な前提情報を集めることができたので、ここからはアラームが発火した原因を本格的に調査します。
   

まずは、必要な情報（メトリクスやエラーログ、設定変更ログなど）を取得します。
コンソール画面の調査経過ログだけでは、どのようにそれらの情報を取得しているのか分からなかったため、AWS DevOps Agentにデフォルトで搭載されているチャットに聞いてみました。

Q：私の操作が DynamoDB エラーの原因となっていることを調べるために、どの API を使用しましたか?

回答：
CloudFormation 操作と DynamoDB エラーを関連付けるために、3 つの主要な AWS API を使用しました。

1. CloudTrail API (LookupEvents)

検出内容: 06:07:33Z の CloudFormation スタックの更新

取得された主な詳細:

アクター: xxxxxxxx (ユーザー)

イベント: スタック demo-devops-agent の UpdateStack

変更されたパラメーター: EnableDdbWritePermission

ソース: AWS コンソール (ユーザーエージェントはブラウザを表示)

2. CloudWatch Logs API (FilterLogEvents)

検出内容: 06:08:31～06:08:37Z の Lambda 関数のエラーログ

エラーメッセージ: AccessDeniedException: ユーザーに dynamodb:PutItem を実行する権限がありません

これにより、Lambda が DynamoDB への書き込み権限を失ったことが証明されました。

3. CloudWatch Metrics API (GetMetricStatistics)

検出内容: 5 件の Lambda 呼び出し (以下の条件を満たすもの) 06:08:00Z にエラー率が 100% でした。

これは、すべての呼び出しが即座に失敗したことを示しています (88.6 ミリ秒、通常は 300.7 ミリ秒)。

DevOps Agentチャットの情報から、以下のAPIが呼び出されていることが分かりました。

そして、次がいよいよい最終フェーズです。APIで取得した情報を元に推論を繰り返します。調査画面のログを元にAWS DevOps Agentの推論フローを要約したのがこちらです。
（実際の調査画面を添付するのは長すぎるため断念しました）

推論のフロー及び結果とデモ内容（DyanamoDB実行権限エラー発生）までのフローが一致していたため、推論精度もかなり高いのではと思いました。

まとめ

今回の調査デモでは、はっきりわかるだけでも５種類のAPIが裏で呼び出されていましたが、必要な情報を得るためのAPIを瞬時に判断できるのは生成AIならではの素晴らしさだと思います。

ただ、今回私が伝えたかったことはAWS DevOps Agentの有能さということではありません。

今回の登壇資料を作成するにあたり、AWS DevOps Agentの凄さを改めて痛感し、それと同時に「人間の調査能力は必要なのか？」「自分が今まで経験したことは無意味だったのではないか」など、正直超絶ネガティブになってしまいました…。

その上で今回私がお伝えしたかったのは、AWS DevOps Agentの能力を人間側に取り込もうということです！
AWS DevOps Agentはある意味、インシデント調査の「正解」を導き出してくれています。すなわち、調査ログを元にインシデント時の調査フロー・ポイントを人間側のナレッジとして貯めることで、運用チーム全体の技術の底上げが可能なのではと考えています。

余裕がある時で構いませんので、AWS DevOps Agentの調査経過ログを一度振り返ってみてください！

感想と感謝

この度はopsmethodの記念すべき第一回にご来場いただきありがとうございました。初開催のイベントではありますが23名の方にご来場いただき、とても嬉しく思っています！
また、懇親会にてお話しをしたくださった方…本当にありがとうございます！貴重なご意見や新たな学びを得ることができました。

また、懇親会中に「もっと複雑な構成になった時にどのようなAPIが叩かれるんだろう」という会話をさせていただきました。<次回以降のブログにて、複数パターンを試した場合の調査結果をご紹介したいと思いますので、少々お待ちください🙇‍♀️

最後に、「まとめ」にも記載しました今回一番お伝えしたかった部分について、「共感しました！」とお声がけくださった方いらっしゃいました！とても嬉しかったですし、今後の励みになります。この場をかりて感謝を申し上げます！！