AWS DevOps Agent (プレビュー) が発表されました！
2025年12月2日現在、米国東部（バージニア北部）リージョンでのみ使用可能です。

Frontier Agents という新しいエージェント概念

re:Invent2025 にて新しいエージェントの概念「Frontier Agents」が発表されました。
これはソフトウェア開発チームの一員として機能するように設計されており、数時間から数日間にわたり、複雑なプロジェクトを自律的に遂行できる能力を持っています。

re:Inventでは3つの Frontier Agents が発表されました。
– Kiro autonomous agent
– AWS Security Agent
– AWS DevOps Agent

この記事では、この中から AWS DevOps Agent に焦点を当てて紹介します！

AWS DevOps Agent とは

アプリケーションを運用する中で、障害発生時のダウンタイム短縮は常に重要な課題です。
障害が発生したことを検知した後の調査にかかる時間を短くしたい、また今後さらに障害になりそうな部分があるのであれば事前に検知しておきたい。
そんなユースケースでAWS DevOps Agentが活用できます。
※AWS DevOps Agentでは障害検知をする機能はありません。CloudWatch AlarmやDatadogなどの外部ツールで検知の仕組みを作成し、それをエージェントに接続する必要があります。

AWS DevOps Agent の主要な機能は以下の通りです。

DevOps Agent Web App

AWS DevOps Agent 専用の Web アプリケーションインターフェースです。
この画面を通じて、発生した障害の調査状況や結果を確認し、対話的に分析を進めることができます

DevOps Agent Spaces

AWS DevOps Agent がどアクセス可能なリソース範囲や権限を定義したものです。
特定のアプリケーションや環境に対して、エージェントがどこまで調査を行えるかという範囲をここで管理します。

DevOps Agent topology

アプリケーション内のリソースとその依存関係を自動的に検出し、可視化する機能です。Agent Space 作成後、リソース構成グラフが表示され、全体像を把握しやすくなります。

やってみた

AWS DevOps Agent を利用することで、障害発生から原因調査、分析、対処までどのような流れになるのか検証します。
今回は意図的に障害を発生させ、エージェントの挙動を確認します。

まず、AWS Lambda を使用して、エラーを返すだけの検証用関数を作成します。

def lambda_handler(event, context):
    raise Exception("意図的なエラーです")

次に Amazon CloudWatch Alarm を設定し、作成した Lambda 関数のエラー回数が「1以上」になった場合にアラーム状態となるよう構成します。
今回は検証のため、通知アクション設定は削除しておきます。


作成した Lambda 関数を実行してエラーを発生させ、CloudWatch Alarm を「アラーム状態」にします。

ここから AWS DevOps Agent をセットアップし、調査を開始します。
AWS マネジメントコンソールから「AWS DevOps Agent」を開き、「Begin setup」をクリックして Agent Space を作成します。

Agent Space の作成プロセスでは、Space 自体と Web アプリケーションへのアクセス権限を定義します。
デフォルト設定のままでも進められますが、必要に応じてカスタムしたサービスポリシーをアタッチすることも可能です。


作成後、画面右上の「Operator access」を選択すると、専用の Web アプリケーション URL（https://{id}.aidevops.global.app.aws/）へ遷移します。

初期状態では何も表示されていません。「Start an investigation」の入力欄から、調査対象として最新のアラーム（Latest Alarm）を選択します。
「最新の CloudWatch Alarm が発報された理由を調査する」旨のプロンプトが自動入力されるため、そのまま「Start investigation」をクリックして調査を開始します。

エージェントによる自律的な調査が開始されます。私の環境では、完了するまでに8分ほどかかりました。CloudWatchアラームの内容をかなり細かく調査しています。

調査の最後では、何が原因で発生したか要約してくれます。
今回は「100%エラーが発生するコードが埋め込まれているので、意図的に実装されている」と結論づけてくれました。すごい！

Root Cause（根本原因）のタブを開くと、より詳細な調査プロセスと結果を確認できます。

また、「Generating mitigation plan」ボタンから緩和策の提案を求めることも可能です。
Mitigation Plan とは、リスクや被害を最小限に抑えるための対応計画のことですが、今回は「意図的なエラー」と判断されたため、具体的な修正プランは生成されませんでした。
実際の障害であれば、ここで具体的な修正コードや設定変更案が提示されるはずです。

ちなみに画面上部にある「Ask for human support」ボタンを使用すると、DevOps Agent が収集した CloudWatch Logs や調査結果を添付した状態で、AWS サポートへケースを起票できるようです。障害があった際のサポート起票がよりスムーズになるかもしれません。

まとめ

re:Invent2025で発表されたばかりの AWS DevOps Agent を試してみました！
障害発生時の一次切り分けを DevOps Agent に任せることで、より早い判断が可能になり、恒久対応に集中できるようになりそうです。
まだプレビュー版となるため、今後の機能追加に期待です！

参考