はじめに

こんにちは。クロスイノベーション本部クラウドイノベーションセンター3年目の宮崎です。
AWS re:Invent 2025 で発表された AWS DevOps Agent を触ってみたので、概要を記載したいと思います。
AWS re:Invent 2025については、同じくクロスイノベーション本部エンジニアリングテクノロジーセンターの宮原さんが、速報記事を書いているので、是非下記の記事もご覧ください！
AWS re:Invent2025 Keynote現地速報
また、AWS re:Inventがそもそもどのようなものか把握したい方は、過去の私の記事もご覧いただけると幸いです。
AWS re:Invent 2024とAWS GameDayについて

本記事は電通総研 Advent Calendar 2025 9日目の記事です！

記事の目的

新しいエージェントについての紹介
AWS DevOps Agentの機能やセットアップの流れの紹介

AWS DevOps Agentの位置づけ

まず前提として、AWSは re:Invent 2025で「Frontier Agents」という新しいコンセプトを掲げ、次の3つの新しいエージェントサービスを発表しました。

Kiro autonomous agent
AWS Security Agent
AWS DevOps Agent

Frontier Agentsは、AWS公式のページでは「介入を必要とせずに何時間も動作する、自律的で大規模にスケーラブルなAIエージェント」という、新しいクラスのエージェントと定義しています。
従来の「人間をサポートする AI アシスタント」から一歩進み、「チームのメンバーとして成果を出すことを期待されるデジタルワーカー」的な位置づけのサービス群だと捉えています。

引用：自律的で大規模に拡張可能なAIエージェント - Frontier agents – AWS
フロンティアエージェントは、目標達成のために独立して動作し、同時実行タスクに対応するために大規模にスケールし、介入なしに数時間または数日間持続的に動作する自律システムです。個々のタスクを支援する従来のAIアシスタントとは異なり、フロンティアエージェントはチームの延長として機能し、多様なユースケースにわたって包括的な成果をもたらします。
この中で、AWS DevOps AgentFrontier agent – AWS DevOps Agent – AWSはシステムの障害対応（インシデントレスポンス）を加速し、将来の問題を未然に防ぐための運用エージェントで、具体的には、チケットなどをトリガーに自動でエージェントが起動し、メトリクス、ログ、最近のデプロイ履歴（GitHub）、トレース情報などを自動で分析し根本原因を特定・ユーザーに通知を行います。
また、システムの構成要素とその相互関係、デプロイ履歴を含むマップを自動構築し、影響範囲を正確に把握することが可能になります。

AWS DevOps Agent は、その中でも運用・インシデント対応を担う役割を持つ Frontier Agent です。

監視ツールやログを横断して自動で調査・分析し、インシデントの原因特定と復旧案、さらに再発防止策まで提案してくれるAWSの生成AIエージェントサービスとなっています。
インシデントの対応において、様々な情報を人間が行き来して疲弊するのではなく、人間は判断に注力できる未来はすぐそこに来ていると感じています。
インシデント対応における、以下のような課題を人間の介入無しに解決できることを狙っていると思われます。

課題

インシデント調査に時間がかかる

CloudWatch / Datadog / New Relic / その他監視ツール / デプロイ履歴 / Runbook などを人がいちいち行き来して調べるのは大変。
⇒ AWS DevOps Agentがこれらをまとめて見て、根本原因候補を自動で絞り込む。

夜間・休日オンコール負荷が高い問題

24/7 で人を張り付けるのはしんどいしコストも高い。
⇒AWS DevOps Agentが常時起動のオンコール要員として自動で調査開始し、対応案まで出してくれるので、MTTR（復旧時間）を短縮しつつ負荷も軽減。

再発防止・改善の振り返りが十分にできていない

インシデント後に振り返りや今後に向けた改善等をきちんとやる時間がない。
⇒AWS DevOps Agentが過去インシデントを横串で分析し、監視や構成・デプロイの改善案を提案してくれる。

AWS DevOps Agentの機能

参考：https://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/what-is.html
上記の公式ドキュメントベースでご説明します：
1. 常時稼働の自動インシデント対応

アラートやチケットをトリガーに、自動で調査開始し、メトリクス、ログ、トレース、デプロイ履歴、コード、Runbook などを突き合わせ、原因候補と影響範囲を特定することができます。具体的な緩和策や復旧手順、ロールバック案までプランとして提示することが可能です。

2. チャットベースのインタラクティブ調査

専用の DevOps Agent Web アプリ（Agent Space）から、視覚的に調査の状況や、人間が追加チャットでどこまで調査したか、他に影響はないか等も確認ができます。また、別チャットにて追加の調査や指摘もすることが可能です。

3. トポロジ学習とマルチツール連携

AWS リソースや各サービスのトポロジ（関係性）を自動で学習します。
CloudWatch、Datadog、New Relic、Dynatrace、Splunk などのオブザーバビリティツール、監視設定と連携し横断的に相関をとることも可能なようです。

4. 予防・再発防止のための改善提案

調査後に改善の提案を確認できます。また、過去インシデントのパターンを分析し、改善案を自動で提示することが可能です。

AWS DevOps Agentの管理・認証

今回、実際の検証を実施した際はIAM認証（既存のマネジメントコンソールのセッション）にて初期設定を実施しました。一方で、少し経つとAWS DevOps Agent Spaceウェブアプリのセッションが切れてしまいました。そこで、AWSの公式ドキュメントを確認すると、IAM認証でのアクセスは30分までに制限されていました。
そのため、本番環境等において複数人に展開する場合はIAM Identity Centerが推奨されているようです。外部プロバイダーとの連携により集中管理することが可能になり、最大12時間のセッションが提供されます。
Setting Up IAM Identity Center Authentication

AWS DevOps Agentのセットアップ手順

※現状パブリックプレビュー期間中のため、AWS DevOps Agent自体の使用料は発生しませんが、他のサービスへのクエリや API 呼び出し時に当該サービスから料金が掛かる場合は使用料金が発生します。
引用：Public preview pricing and limits

マネジメントコンソールの検索欄に、AWS DevOpsを入力すると出てきました。
現在はプレビュー版になっておりリージョンが制限されているので、バージニア北部に遷移します。
サービスページから「Begin setup」を押下し、エージェントスペースを作成します。
Agent Spaceの名前を設定し、画面に従って設定をします。
問題なく作成後、Agent Spaceの画面に遷移すれば完了です。

機能検証前の実施内容

AWS DevOps Agentを試す前に、調査対象となる環境、および仮トラブルをAWS DevOps Agentの公式ドキュメントの内容に基づき準備しました。
環境準備の詳細手順は以下のリンクからご覧ください。
Creating a test environment

内容は、準備されているIaCコードを用いてCloud FormationでEC2やLambdaの環境をデプロイ後、用意されたトラブルに対してAWS DevOps Agentを利用し、代表機能を見ていけるというものになっています。
AWS DevOps Agentを試したいが、対象のシステム環境がない方が試す場合に打って付けです。
※実際のアプリケーション等の検証環境がある方はそちらで検証した方が、実際の業務で何がどこまでできそうか把握しやすいと思います。

実際の調査の流れ

作成したAgent Spacesから画面右上の「Operator access」を押下します。
すると別タブでAWS DevOps Agentの画面に遷移します。erator accessから作成したエージェントに質問をします。

質問内容

以下を項目ごとに入力します。
（実際のプロンプトは対象の環境やエラーの状況によって変えてください。
今回はAWS DevOps Agentの公式ドキュメントの内容に基づき準備した場合のプロンプトになっています。）
※今後、日本語対応されるまでは調査したい内容を日本語から英語へ翻訳する1アクションが必要になりそうです。

Investigation details：
Investigate high CPU utilization on test EC2 instance and Lambda error rate spikes generated by test stacks.
Investigation starting point：
Start from CloudWatch alarms AWS-AIDevOps-EC2-CPU-Test and AWS-AIDevOps-Lambda-Error-Test which are currently in ALARM.
内容を確認後「Start Investigation」を押下し、調査を開始します。
タイムライン形式で何の情報をインプットに、どのようなステップで調査をしているか、最終的に何を根本原因と判断したかまで等が把握できます。
視覚的で内容も把握しやすいものとなっています。
調査結果が約5分~10分ほどで出ます。
詳細を確認すると根本原因について記載しています。
実際のインシデントが起こった流れについても、詳細に記載されていました。
また、調査は並行で走らせることができました。

※現状、同時に実行できるインシデント解決調査タスクの数は 3 までとなっています。

実際の本番利用においては、エラーに関連するリソースの指定や環境の指定により調査対象をプロンプトによって指定する等で、異なる視点からの調査を並行して実施することもできそうです。

まとめ

AWS DevOps Agentは設定が簡単で、実際のエラーの調査内容/理由を時系列に沿ってUIで分かりやすく、詳細に解説してくれました。調査は並行で走らせることができ、根本原因が約5分～10分で直ぐに把握が可能です。
AWS DevOps Agentはインシデントの調査・根本原因の特定はもちろん、ポストモーテム（システムにトラブルや障害が発生したあとに行う事後分析）に非常に有効だと思いました。
そして何より、「チームのメンバーとして成果を出すことを期待されるデジタルワーカー」的な位置づけのサービスとしてAWS DevOps Agentで一次調査を任せることができるレベルだと言うことが分かりました。
現状、二次対応で実際のリソースの設定変更などについてはKiro CLI(旧Amazon Q Developer CLI)でAWS CLIの認証情報との組み合わせにより設定変更や環境参照なども可能になっています。
日本語対応やリージョンの拡大を期待しつつ、AWS DevOps Agentがインシデント対応のプロセスにおいてどの部分まで担っていけるのか、AWSの他サービス（Kiro CLI,Amazon Q Develper等）やAI機能が備わってきているオブザーバビリティ・インシデント対応周りのSaaSサービスとの棲み分け等について、引き続きWatchして確認して行ければと思っています。