re:Invent 2025 のキーノートで「AWS DevOps Agent」が発表されたとき、正直「また新しいAIサービス出てきた…」ってなりました。でも調べるほど「これ、夜中の障害対応がかなり変わるんじゃ？」と思い始めたので、ちゃんとまとめておこうと思います。
自分はインフラ寄りの学習が多いので、インシデント対応の文脈でどう使えるかを中心に調べてみました。まだプレビュー中のサービスなので、変わっている部分もあるかもしれませんが、現時点（2026年2月）でわかっていることをまとめています。
この記事でわかること
- AWS DevOps Agent が何をするサービスなのか
- 「フロンティアエージェント」という概念の意味
- Agent Space（エージェントスペース）の考え方
- 基本的なセットアップと使い方の流れ
- CloudWatch や GitHub などとの連携イメージ
- プレビュー中の制限・料金まわりのポイント
AWS DevOps Agent とは？
AWS DevOps Agent は、インシデントへの対応（調査・トリアージ・根本原因の推定）と、過去のインシデント傾向からの予防的な改善提案を支援するAIエージェントです。AWSの発表では「frontier agent（フロンティアエージェント）」と呼ばれていて、経験豊富なDevOpsエンジニアのように、観測データ・コード/デプロイ情報・運用手順などを関連付けて状況を理解する、という位置づけらしいです。
リリース時期については、AWS公式の”What’s New”に 2025年12月2日付でプレビュー公開の告知が出ています（re:Invent 2025のタイミングですね）。現在はパブリックプレビューとして提供されています。
名前に「DevOps」とついているので開発全般を自動化するのかと思いきや、メインはインシデント対応の自動化と障害予防に焦点を当てたサービスです。ざっくり言うと「AIがあなたの代わりに障害調査をやってくれる」というイメージ。
フロンティアエージェントとは何か
公式発表や記事で「frontier agents（フロンティアエージェント）」という言葉が出てきます。これはAWSが”自律的に長時間動ける（hours or days）”タイプのAIエージェント、という文脈で使っている用語っぽいです。
要するに、チャットで「これ調べて」と一言投げたら後は勝手にやってくれる、という感じのエージェントです。これまでのAIアシスタントより自律性を強めた方向性、という理解でよさそうです（とはいえ「勝手に何でもする」ではなく、権限と接続先次第でできることが決まるので、そのへんは現実的です）。
具体的に何をやってくれるのか
AWS DevOps Agentは、アラートが入ってきた瞬間から調査を開始します。午前2時であっても、ピーク時間帯であっても関係なく、アプリケーションを最適なパフォーマンスに素早く復元するために動き続けます。インシデントを24時間365日自律的にトリアージし、根本原因の分析と解決のためのアクションを提供します。
また、過去のインシデントのパターンを分析し、オブザーバビリティ（モニタリング・アラート・ロギング）、インフラ最適化、デプロイメントパイプラインの強化、アプリケーション回復性という4つの重要領域を強化する実用的なレコメンデーションを提供します。後ろ2つは「再発防止のための提案」という感じですね。
余談ですが、「午前2時でも動いてくれる」系の表現、AWS公式の告知にも出てきます。エンジニアの夜中オンコール対応を意識してますよね絶対。刺さる文句だなと思いました（自分はオンコール未経験ですが、想像するだけで胃が痛い）。
Agent Space（エージェントスペース）の考え方
AWS DevOps Agentの使い方を理解するうえで、まず押さえておきたいのがAgent Spaceという概念です。
Agent Spaceは、AWS DevOps Agentがタスクを実行する際の”運用上の単位”というか、どの範囲を対象に調査するかを整理するための枠、と捉えるとわかりやすいです。実際には、Agent Spaceごとに「どのAWSアカウントを接続するか」「どのデータソース/連携機能を有効にするか」などを設定していく形になります。
エージェントスペースは運用モデルに基づいて整理できます。1つのアプリケーションに合わせてAgent Spaceを作るチームもあれば、複数サービスを管理するオンコールチームごとに1つ作るチームもあります。また、中央集権的なアプローチを取る組織もあります。
自分の理解では、「プロジェクトや責任範囲ごとにエージェントの調査スコープを切り分ける仕組み」と捉えるとわかりやすいです。本番環境と開発環境で別々のAgent Spaceを作れば、誤って開発環境を調査対象にしてしまう、なんてことも防げます。
トポロジーグラフ
Agent Space を作成すると、アプリケーション内のリソースとその依存関係を検出し、可視化するためのトポロジー（Topology）が作られていきます。Webアプリ上ではトポロジーグラフとして表示され、全体像を把握しやすくなります。
このトポロジーグラフは、AWS DevOps Agentがアプリケーション内部のリソースを検出し、それらがどのように接続され、依存し合っているかをグラフとして表現したものです。このトポロジーは、インシデント調査や原因分析、再発防止のための推奨事項を生成する際の重要な基盤になります。
なお、リソースの検出には少し注意が必要です。CloudFormationスタック由来のリソースは検出しやすい一方で、CloudFormation外のリソースも含めたい場合は、タグ（キーと値のペア）で「どれを含めるか」を指定する形になります。さらに、タグ経由で検出する場合は対象アカウント側で Resource Explorer を有効化しておく必要がある点もハマりポイントになりそうです。
AWS DevOps Agent の使い方：基本的なセットアップの流れ
それでは実際にどうやって始めるのかを見ていきます。公式ドキュメントやいくつかの検証記事を参考にまとめました。
① Agent Space を作成する
AWSマネジメントコンソールのAWS DevOps Agentセクションで Agent Space を作成します（コンソール操作が基本になりそうです）。
このとき、どのアカウント/リソースにアクセスさせるか（クロスアカウント含む）や、Webアプリの認証方式（Identity Center連携か、管理者向けの短時間アクセスか）も合わせて設定していく流れになります。
② Web アプリにアクセスする
Agent Space が作成されると、AWSマネジメントコンソールの外部サイトとして「Agent Space web app（オペレーター向けWebアプリ）」が利用できるようになります。アクセス方法は2種類あり、基本はIdentity Centerを利用します。
記事内の「オペレーターアクセスは30分限定のセッション」という記述は概ね合っているのですが、正確には “Admin access（IAM認証）” が30分セッションで、これは初期セットアップ向けです。Identity Center経由のセッションはデフォルト8時間（設定で1〜12時間）なので、「普段使いはIdentity Centerで」が安全そうです。
WebアプリのUIについては、少なくとも「DevOps Center」画面でトポロジーを見ながら状況を追える、という構成になっています（タブ名などはプレビュー中に変わる可能性があるので、ここは”画面構成の概念”として押さえるのがよさそうです）。
③ リソースタグの設定（CloudFormation非使用の場合）
CloudFormationを使っていないリソースを調査対象に含めたい場合は、対象リソースにタグを付与して「このアプリの範囲はこれ」と定義します。
ここは元記事だと devops-agent: true の固定タグを付ける書き方になっていましたが、公式ドキュメント上は「どのタグのキー/値ペアを対象にするか」を（リストとして）指定する形です。つまり、タグキーは固定ではなく、運用に合わせて決めてOKです。
# リソースに設定するタグ（例）
Key: app
Value: nyanchu-prod
上記のようにタグを付けたうえで、AWS DevOps Agent側で「Key: app / Value: nyanchu-prod をトポロジーに含める」と設定して、初めて検出対象として効いてきます。タグ管理をちゃんとやっていないと「なんか表示されない…」になりがちなので、ここは地味に大事そうです。
対応している連携ツール一覧
AWS DevOps Agent の強みのひとつが、既存のツール群と連携して、観測データやデプロイ情報などを横断して調査できる点です。
AWSの公式告知では、例として Amazon CloudWatch、Datadog、Dynatrace、New Relic、Splunk などのオブザーバビリティ、さらに runbooks / code repositories / CI/CD pipelines といった運用・開発の情報も関連付ける、という説明になっています。
また、Bring Your Own 的な拡張としては、MCP（Model Context Protocol）サーバーを接続して調査能力を拡張する機能が用意されています。ここは元記事の方向性は合ってます。ただし注意点があって、公式ドキュメント上は MCPサーバーはHTTPSでパブリックに到達可能なエンドポイントが必要で、VPC内に閉じたMCPサーバーには接続できないとされています。セキュリティ設計は先に考えた方がよさそうです。
整理するとこんな感じです：
- オブザーバビリティ系（例）： Amazon CloudWatch / Datadog / Dynatrace / New Relic / Splunk
- CI/CD・運用情報： runbooks / code repositories / CI/CD pipelines（具体的な対応製品はプレビュー中で増減しそう）
- カスタム連携： MCPサーバー経由（外部オブザーバビリティ/社内ツール等）
実際のインシデント調査の流れ（イメージ）
いくつかの検証記事を読んでわかったことをもとに、インシデント対応の大まかな流れを整理しました。
トリガー：アラートが発火
例えば、Lambda関数でエラーが多発してアラートが上がった、というケースを想定します。
# Lambda関数（検証用）でエラーを発生させる例
def lambda_handler(event, context):
raise Exception("意図的なエラーです")
上記のようにエラーを発生させてアラートをトリガーとし、AWS DevOps Agentが自動的に調査を開始する、というのが基本の流れです（どのアラート経路でどう起動するかは、連携設定に依存します）。
エージェントが自律的に調査を開始
アラートが入ってきた瞬間から、エージェントはトポロジーグラフなどの情報をもとに依存関係を確認しながら調査を進めます。調査の進捗はWebアプリ上で確認できます。
詳細な緩和計画（Mitigation Plan）も生成されます。これはインシデントに対する具体的なアクション、成功の検証方法、必要に応じた変更のロールバック方法を提示します。
根本原因の特定と提案
エージェントはただ「エラーが出ています」と報告するだけでなく、なぜそのエラーが発生したのかの推論まで行います。また、緩和策の提案を明示的にリクエストすることも可能です。
ただし、意図的なエラーと判断された場合は、具体的な修正プランが生成されないこともあります。実務に近い構成で試した方が、より実践的な提案が出てくるようです。
料金・制限・注意点まとめ
現在の利用可能リージョン
AWS公式の告知では、プレビュー期間中の提供リージョンは US East (N. Virginia)（us-east-1）となっています。
「us-east-1で実行されるが、任意のリージョンにデプロイされたアプリをモニタリングできる」という言い方をたまに見かけますが、断定しすぎかもしれません。実際には、どのリージョン/どのアカウントのどのデータソースにアクセスできるかは、接続したアカウント設定や権限、連携したツール次第です（”何でも任意にOK”というより、設計と設定が必要、という温度感）。
プレビュー期間中の料金・利用制限
プレビュー期間中はAWS DevOps Agent自体の利用料金はかかりません。ただし、調査中に他のAWSサービスや外部サービスへクエリ/APIコールを投げることで、それらのサービス側の課金が発生しうる点は注意です。
また、プレビュー中の制限は公式ドキュメントに明記されています。（アカウント単位で）以下の制限があります：
- Agent Space：最大10個
- インシデント解決（incident resolution）時間：月間20時間
- インシデント予防（incident prevention）時間：月間10時間
- チャットメッセージ数：月間1,000件
- インシデント解決調査タスク：同時に3つまで
- インシデント予防評価タスク：同時に1つまで
「無料だけど無限ではない」タイプなので、検証するときはタスク時間の消費ペースを見ながらやった方がよさそうです（自分は調子に乗ってログクエリ投げまくって上限到達しがちなので気をつけます…）。
マルチアカウント対応
企業や組織では本番・開発・検証や複数ビジネスユニットなど、AWSアカウントが分かれていることが一般的です。AWS DevOps Agentも、セカンダリアカウントを接続して、アカウントをまたいだトポロジー/調査に対応する前提の作りになっています（ただし、最終的にどこまで見えるかは権限設計次第です）。
まとめ
AWS DevOps Agent の使い方・入門として調べたことをまとめると、こんな感じです：
- 2025年12月2日付でプレビュー公開（re:Invent 2025のタイミング）、現在パブリックプレビュー中
- 「フロンティアエージェント」として自律的にインシデントを調査・対応する
- Agent Space という単位で運用対象や連携を整理する
- トポロジーグラフでリソース間の依存関係を可視化し、調査の土台にする
- CloudWatch / Datadog / Dynatrace / New Relic / Splunk など（例）と連携しうる
- プレビュー中はDevOps Agent自体は無料（ただし連携先のクエリ課金等は別）
- プレビュー制限は「解決20時間/月」「予防10時間/月」「メッセージ1000/月」など（アカウント単位）
- CloudFormation外のリソースは「固定タグ」ではなく、指定したタグ（キー/値ペア）でトポロジーに含める。タグ検出にはResource Explorer有効化も必要
「AIが勝手に障害調査してくれる」という話を聞くと少し不思議な感じがしますが、AWSの説明を見る限り、トポロジー＋観測データ＋デプロイ/コード情報をちゃんと”紐づける”のが強みっぽいです。逆にいうと、権限・連携・タグ設計が雑だと、たぶん期待したほど賢く動けない気もします。
GAになったら東京リージョンでも試せると嬉しいなとは思いますが、さすがに断言はできないので…（自分の願望はある）。参考になれば！
関連記事
参考になったらクリックしてもらえると嬉しいです!
