はじめに
皆さま、お久しぶりです。入社5年目の堀内です。普段はJavaやPHPで開発・運用保守を担当しています。
2025年12月、AWS re:Invent 2025に参加してきました。本イベントは、“Frontier Agents” (常時稼働の自律型 AI エージェント)と呼ばれる新しいエージェント群の発表により大きく盛り上がりました。
その中でも、開発・運用領域を支える新サービス AWS DevOps Agent が特に注目を集めていました。
普段から運用でインシデント対応に関わる身として、実際に現地ラスベガスでKeynoteを聴講し、その後のセッションやハンズオンに参加した内容を二部構成で記していこうと思います。
現地ラスベガスの Keynoteで得た情報
AWS DevOps Agent の狙い
「運用の卓越性のための最前線のエージェント。アラートを減らし、チームにより多くの睡眠を。」というスローガンが前面に打ち出されていました。 また、
- 24時間稼働のインシデント対応優先順位付けとガイド付きの解決を提供
- “火消し”型の対応から、能動的で優れた運用へとシフト
- 主要な観測ツール（Datadog / New Relic / CloudWatch など）からインサイトを取得
- リソースを賢くマッピングし、MTTR（平均復旧時間）の短縮とアプリケーションの信頼性向上を実現
という特徴も紹介されていました。
AWS DevOps Agentの紹介に割かれた時間はその他新サービスに比べると短く、説明も端的だった印象を受けました。 しかし、DevOpsエンジニアのあり方を変えるサービスとして、力強い言葉で紹介されていました。
サービス概要（AWS DevOps Agent とは）
AWS DevOps Agent は、運用のための Frontier Agentsであり、以下を特徴としています。
- ①発生した問題を迅速に解決
- アラートを受け取った瞬間に調査を開始し、アプリケーションをすばやく復元
- インシデントを 24 時間 365 日自律的に優先順位付けし、根本原因候補と緩和策を提案
- アプリケーションのリソースと関係を理解し、依存関係と相互作用を把握
- ② 将来のインシデントを予防
- 過去インシデントの傾向を分析し改善すべき領域を特定
- 強化すべき項目に対し、実用的なレコメンデーションを提供
- ③運用とワークロードの新たなインサイトを活用
- CloudWatch、Dynatrace(SaaS型監視サービス)、Datadog、New Relic、Splunk、GitHub、GitLab などとの統合機能が標準で備わっている
- 統合したサービスから、運用データから新たなインサイトを得ることが可能
- 独自の MCP サーバーと接続することで、組織固有のツールやプラットフォーム、チケットシステムとの連携を追加し、機能を拡張可能
その後のセッションで得た情報
re:Invent では AWS DevOps Agent の詳細紹介セッションやハンズオンも開催されており、実際に参加することでより詳細な説明やAWS側の展望を聞くことができました。※サービス概要と重複する情報は割愛しています。
インシデント対応プロセスの変化
AWS DevOps Agentを導入することで、インシデントが発生してからのライフサイクルに下記の様な変化が生まれます。
| フェーズ | 通常のインシデントライフサイクル | With AWS DevOps Agent |
|---|---|---|
| Alarm | オペレーターが通知を受け、夜中であってもしばしば起こされる | 常にインシデント対応可能で、即時反応 |
| Investigation | 原因調査にはアプリケーション知識が必要 | AWS の専門知識とトポロジを使用し自動的に原因解析 |
| Mitigation | 修正策の特定とリスク評価が必要 | 検証ステップ・ロールバック付きの緩和計画を生成 |
| Prevention | 可観測性・テスト・インフラのギャップ特定には専門性が必要 | 再発防止改善点を自動で特定し、対応時間を短縮 |
「アラームが鳴っても起きなくてよい」という世界までは行かないにしても、人間が準備する間に調査が完了している点は、対応時間短縮に大きく貢献すると感じました。
チームメンバーのように機能する存在
AWS DevOps Agent は、既存の運用ツールや他のAIエージェントと連携し、チームの一員として働いてくれます。
既存ツールのチケットやアラームに対応して、分析を開始。取得した分析結果を、Slack などのコミュニケーションツールに投稿するところまで実施可能です。Dynatrace Davis のような他の AI エージェントとも連携して動作することも可能の様です。
もはやチームに一人コール用のメンバーが増えるも同然です。頼もしい、、、、
今後の展望
現時点ではプレビュー版で機能も限定されていますが、今後の展望として以下のような進化が期待できるのではないかと私は考えました。
デプロイパイプライン連携の強化
現状、GitHub/GitLab は対応していますが、AWS CodePipeline とは非対応となっています。 今後はAWS CodePipelineと深く統合され、本番デプロイとインシデントを AWS 内で結びつけられるようになると考えられます。CodePipeline の各ステージ（Build/Deploy/Test）と CloudWatch等 のアラートを紐付け、"どのステージでデプロイされた artifact が本番障害を起こしたか"を自動で特定できるようになり、本番環境をどの状態にロールバックすればよいのかまで提案可能になると考えられます。
原因分析のその先、自動修復へ
現在は「原因分析」と「緩和策の提示」までを主な機能としていますが、 将来的には Runbook の内容を自動実行する “自動復旧エージェント” へ発展する可能性もあるのではないかと感じました。 インシデントへの対応パターンがある程度決まっている場合、解決までの処理をテンプレート化しておけば、自動修復可能になると考えます。
今後はさらに運用自動化が進むことでMTTR が短縮し、再発防止の仕組みが強化され運用の質の上昇が期待されます。
不安要素
Keynote～セッションを聴講して、私が不安要素として感じたのは導入コストです。
Frontier Agentsは常時稼働するエージェントということもあり、導入した場合の月額がかなり高額になることが予想されます。
※参考に同種のFrontier AgentsであるKiroでは、法人向けプランの「Kiro Power」を利用した場合、料金は $200/月となっています。
実際に運用負荷軽減を目的にDevOps Agentを導入する際には、法人用の高額かつ容量制限が緩いプランでの契約が必要になると思われます。コスト面を理由に導入を見送るケースも出てくるかもしれません。
まとめ
AWS DevOps Agent は、 “インシデント対応の自動化” と “再発防止の体系化” を同時に行う新しい AI エージェント です。
- 障害検知後の初動を大幅に削減
- 運用者が深掘りすべきポイントが明確になる
- チームでの調査プロセスが標準化される
など、運用現場での効果が高いと実感できました。
サービス展開後も実際に各システムへ導入するまでには、申請等準備に時間はかかりそうですが、非常に楽しみな存在です。日頃インシデント対応に携わっている身としては、本番端末に接続した時点で調査が完了している——そんな未来を想像すると、非常に心強く感じました。
続いて②の記事では、ワークショップにて実際にAWS DevOps Agentを稼働させてみた内容を記載します。
WEB系システムエンジニア
筋肉の開発、保守運用も行っています💪
