こんにちは。野村総合研究所の早川です。
本記事は、AWS re:Invent 2025で発表されたAWS DevOps Agentについて、実際に使ってみた体験をまとめたものです。「どんなサービスなのか」「インシデント管理が今後どう変わりそうか」について、分かったことをシェアします。
AWS DevOps Agentとは
AWS DevOps Agentは、AWS re:Invent 2025で発表された Frontier Agent の一つです。Frontier Agentとは、自律的に計画を立て、複数のツールを組み合わせて複雑な問題を解決し、数時間から数日間にわたって人間の介入なしに動作し続けることができるAIエージェントを指します。
Frontier Agentとしては「Kiro Autonomous Agent」「AWS Security Agent」「AWS DevOps Agent」の3つが発表されています。AWS DevOps Agentはその名の通り、DevOps領域に特化して設計されており、AWSはこのエージェントを「常時稼働するオンコールエンジニア」と表現しており、アラートが発生した瞬間から自律的に調査を開始します。現在はパブリックプレビュー段階にあり、バージニアリージョンで無料で試すことができます。
主な機能
インシデント調査
AWS DevOps Agentの中核が、インシデントの自律調査機能です。Amazon CloudWatchだけでなく、Dynatrace、Datadog、New Relic、Splunkといったサードパーティのモニタリングサービスをまたいで、メトリクスやログを横断的に相関分析してくれます。
特に印象的だったのは、「調査の段取りを自動でやってくれる」という点です。アラートが上がると、エージェントはまず何を確認するべきかの計画を立て、ログやメトリクスを順に見ていきます。人間が深夜に複数の画面を行き来しながらやっていた作業を、エージェントが先にやっておいてくれるんです。
調査が終わると、根本原因の仮説と緩和策の候補をまとめたレポートが出てきます。担当者が電話を受けてPCを開いた時点で、すでに調査のベースラインが整っている、この状態になれば深夜対応の精神的な負荷はかなり軽くなるでしょう。下記の画面は、公式ドキュメントのテスト環境構築の記載された「Test option B: Lambda error rate test」を分析した際の結果です。
再発防止
過去のインシデントのパターンを分析し、構造的な改善提案を自動生成する機能もあります。週次で自動実行されるほか、Ops BacklogメニューのPreventionページから「Run Now」ボタンで手動実行することもできます。
提案はCode・Observability・Infrastructure・Governanceの4カテゴリに分かれて出てきます。コード品質やパフォーマンス改善から、監視・アラートの強化、インフラ構成の見直し、デプロイや運用管理の改善まで幅広くカバーしています。
自動出力される「改善提案の起点」は、ポストモーテムのたたき台として活用できるほか、第三者的な視点での分析が加わることで、視野が狭くなりがちな当事者の判断に客観性を持たせることもできます。
Agent Spaceによるスコープ管理
Agent Spaceは、アプリケーション単位またはオンコールチーム単位で調査スコープを分離する仕組みです。権限制御にはIAMロールを使うので、既存のAWSアクセス管理の考え方をそのまま持ち込めます。Agent Spaceの設計方針や本番運用のベストプラクティスについては、AWSの公式ブログ「AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス」で詳しく解説されています。
アーキテクチャ
AWS DevOps Agent はマルチエージェント構成になっています。リードエージェントがインシデントコマンダーの役割を担い、まず調査計画を立案します。その計画にもとづいて、ログ解析・メトリクス分析といった専門サブエージェントに調査を委譲する仕組みです。
人間のインシデント対応に例えると、指揮を執る担当者が各メンバーに調査タスクを割り振るモデルに近いです。サブエージェントはそれぞれ独立したコンテキストで動くため、長時間の調査でも精度が落ちにくい設計になっています。
セットアップからインシデント調査までの流れ
Step 1：Agent Space を作る
AWSコンソールのAWS DevOps Agent 画面から「Create Agent Space」を選び、まずAgent Spaceを作成します。Agent Space はAWSアカウント・リージョンに紐づく作業単位で、「どのアプリケーションやチームを対象とするか」を定義する場所です。
- 名前と説明："web-app-prod" など管理しやすい名前をつける
- IAMロール：CloudWatchや連携ツールへのアクセス権限を持つロールを割り当てる
- モニタリングソースの接続：CloudWatch Logs／Metricsは同一アカウントであれば自動で参照可能。DatadogやNew Relicはコンソール上でAPIキーを登録して連携する
Step 2：インシデント調査を開始する
アラートが発生したとき、2つの方法でエージェントを起動できます。
（A）手動でインシデントを起動する
コンソールの「Start Investigation」から、調査内容を自然言語で入力します。エージェントへの指示は英語での入力が基本ですが、UIの表示は日本語にも対応しています。エージェントはこの入力をもとに調査計画を立て、CloudWatchのログやメトリクスを自律的に分析し始めます。
（B）CloudWatchアラームから自動トリガーする
CloudWatchアラームのアクションにCloudWatch InvestigationsのARNを設定しておくと、アラーム発火と同時に調査が自動で始まります。担当者が気づく前にエージェントがすでに動いている、という状態を作れます。
Step 3：調査レポートを読む
調査が完了すると、Root Cause タブにレポートが生成されます。
| セクション | 内容 |
|---|---|
| Root Cause | エージェントが最も可能性が高いと判断した根本原因 |
| Key Observations | 根本原因の分析を支持する主要な観察事項（ログの該当行やメトリクスの値など） |
その後「Generate mitigation plan」ボタンで、Mitigation Plan を作成できます。
Step 4：再発防止レポートを活用する
Operator Web AppのOps BacklogメニューのPreventionページでは、過去のインシデント履歴を分析した改善提案が週次で自動生成されます。「Run Now」ボタンからいつでも手動で実行することが可能です。
改善提案は4つのカテゴリに整理されて出てきます。
- Code：アプリケーションコードの品質・パフォーマンス・エラーハンドリングの改善
- Observability：監視・アラート・ログの強化とシステム可視化の向上
- Infrastructure：リソース構成やキャパシティのチューニング、アーキテクチャの復元力向上
- Governance：デプロイメントプロセス・テスト・運用管理の強化
この出力をそのままポストモーテムのたたき台として使えば、インシデント後の改善サイクルが回しやすくなります。
課題と評価
従来のAIナレッジベースとの違い
これまでAIをインシデント対応に活用するといえば、過去の障害事例をナレッジベースに蓄積して検索するという使い方でした。「似た症状の障害が過去にあったか」を参考にすることで属人化を緩和できますが、前提として「過去に経験したことがある障害」しか対応できないことが難点でした。
AWS DevOps Agentの場合、過去の情報ではなく「今」の環境を対象に調査を行います。CloudWatchに流れている直近のメトリクス、直前に発生した設定変更、現在のリソース状態——これらを実際に参照しながら仮説を立てます。「過去の事例と照合する」のではなく「今起きていることを調べる」。これが、従来のナレッジベースの活用とは異なる部分です。
また、AWSが持つ膨大な障害パターンのナレッジを検索できるのも強みです。従来のナレッジベースは自社が経験した障害の範囲でしかデータを蓄積できませんが、AWSは無数のユーザーの障害対応を通じて積み上げたパターンを持っています。その厚みは、自社のナレッジベースではなかなか補いにくいところです。
もう一つ、使ってみて良いと感じたのが「根拠を一緒に出してくれる」という点です。従来のナレッジベース型では「この障害は過去のXXXと同じパターンです」という結論だけが返ってくることが多く、それを信じるかどうかを判断するために、過去の障害パターンと現在の環境の状態を自分で比較調査する必要がありました。AWS DevOps Agentは根本原因の仮説とセットで、参照したログの該当行やメトリクスの値を Evidence として提示します。担当者はエージェントの結論を受け入れるかどうかを、自分の目で根拠を確認してから判断できます。深夜の障害対応でAIの出力を鵜呑みにして対処を誤るリスクを下げられる、という意味で、この設計は現場での使い方として重要だと思いました。
監視ツールと連絡手段の連携
逆に、導入の障壁になりそうな課題は監視ツールの連携です。AWS DevOps Agent がビルトインでサポートしているのはCloudWatch、Datadog、New Relic、SplunkなどSaaSが中心で、昔から使われているような独自の監視ツールは対象にできません。アラートの起点もPagerDutyやCloudWatchアラームが前提の設計で、電話やメールで連絡がある場合、どのようにDevOps Agentに自動連携するかが課題となります。
社内の連絡手段も同様で、SlackやTeamsなら通知連携の選択肢がありますが、セキュリティを重視していて、クローズドな社内環境にあるチャットツールへ通知するには、何かしら中継するための仕組みを作り込む必要があります。
独自ツール用のMCPサーバーを持ち込める仕組み（Bring Your Own MCP）を使えば、既存環境を取り込める可能性はありますが、小さく導入しながらその効果を示すことを求められそうです。
コストとキャップの問題
現在はパブリックプレビューで無料ですが、正式リリース後は利用量に応じた課金となることが想定されます。そのとき、月次の利用上限がどうなるかも確認が必要です。
インシデント対応のツールである以上、「月末に上限を超えたので障害調査できない」という状態は避ける必要があります。コスト上限が設定できるか、上限到達時の挙動がどうなるのか（エージェントが止まるのか、追加料金を支払えば使えるのか、等）は、本番導入前に確認すべきでしょう。
まとめ
活用に向けたアクションとして、まずCloudWatchへのログ転送を整備することが挙げられる。既存の監視ツールを入れ替えなくても、CloudWatchにログを流す構成を並走させることでエージェントの調査範囲に含められます。
次にポストモーテムの起点として使うという使い方です。アラートの自動連携がなくても、インシデント後に手動で調査を起動して、生成されたレポートをたたき台に担当者が肉付けしていく形であれば、本番運用に影響を与えず、今すぐ始められます。
DevOps Agent を使ってみて、「自分たちの環境をどう整備すれば使えるようになるか」を考えるきっかけをもらいました。CloudWatchへのログ集約や、MCPサーバーによる既存ツールの接続など、段階を踏みながら本番運用への適用を進めていきたいと思います。複数ツールをまたいだ事象の分析はAIの得意な領域です。そこから導き出された復旧アクションの最終判断は人間が担う——それぞれの強みを組み合わせることで、より迅速なインシデント対応が可能になると考えています。