こんにちは。

高橋健斗です。今回はフロンティアエージェントの一つであるDevOpsエージェントを少し触ってみたので、紹介していきます。

フロンティアエージェントとは?

re:Invent 2024で提唱:

自律的でスケーラブルな新しいタイプのAIエージェントで、人間の介入なしに数時間から数日間稼働

まずは、3つのフロンティアエージェントとしてSecurity Agent、DevOps Agent、Kiro autonomous agentがプレビューしました。

参考:https://aws.amazon.com/jp/ai/frontier-agents/

セキュリティエージェントについては、こちらで濱口さんが紹介してくれていますね。

提唱された3つのフロンティアエージェントのうち、最後に残されたKiroエージェントはほとんど触ったことがないので、書くことが出来ないです…。

(私はClaude Codeを使用しています)

Kiroエンタープライズを導入された事例があれば、是非拝見したいです!!

機能

機能は結構盛り沢山です。

1. 自動インシデント調査

  • アラートやサポートチケットが届いた瞬間に自動的に調査を開始
  • 24時間365日、深夜2時でもピーク時でも自律的にトリアージを実施
  • 根本原因分析と解決策の推奨を提供

2. アプリケーショントポロジーマッピング

  • アプリケーションリソースとその関係性のトポロジーグラフを自動構築
  • クロスアカウント、マルチクラウド、ハイブリッド環境にも対応
  • リソース間の依存関係と影響範囲を可視化

3. 統合機能

  • 観測ツール連携

　・Amazon CloudWatch、Dynatrace、Datadog、New Relic、Splunkと連携

  • CI/CDパイプライン連携

　・GitHub Actions、GitHub リポジトリ、GitLab workflows、GitLab リポジトリと統合

  • カスタム統合

　・独自のMCP(Model Context Protocol)サーバーに接続して機能拡張可能

4. インシデント対応の自動化

  • 詳細な緩和計画(解決アクション、成功検証、変更のロールバック)を提供
  • Slack、ServiceNowなどのコミュニケーションチャネルを通じて、観測結果、発見事項、緩和手順を自動的にルーティング
  • 調査から直接AWS Supportケースを作成し、即座にコンテキストを提供

5. 予防的改善の推奨

  • 過去のインシデントパターンを分析し、4つの主要領域で具体的な改善を提案
  • 監視・アラート・ログ(可観測性)、インフラ最適化(オートスケーリング、キャパシティチューニング)、デプロイメントパイプライン強化(テスト、検証)
  • チームのフィードバックに基づいて継続的に学習

6. 対話型調査チャット

  • DevOps Agent Space Webアプリで自然言語を使用して調査を開始・ガイド可能
  • エンジニアがリアルタイムで質問し、調査を誘導可能

メリット

1. 平均解決時間(MTTR)の削減

  • 自律調査が即座に開始され、数時間から数分へ短縮

2. 再発防止と運用効率の向上

3. 既存ワークフローを変更せずに統合可能

4. パブリックプレビュー期間中は無料(US East (N. Virginia) リージョン)

参考:https://aws.amazon.com/jp/blogs/aws/new-aws-security-agent-secures-applications-proactively-from-design-to-deployment-preview/

軽く触ってみた

全ての機能を試してみたいところですが、機能も多いので「DevOps Agent Space Webアプリで自然言語を使用して調査を開始・ガイド」を試しました。
DevOps Agentで使うMCPに関しては、後日別のブログにて検証してみたいと思います。

なお、DevOps Agentと自前のMCPサーバーを接続するには指定のCallback URLを認証アプリ側に追加しないといけないようです。
私の試したい自前MCPはEntraを使うため、色々な関係で設定に時間がかかりそうです…ドキュメントを見ても、MCPの部分は個人的にピンと来なかったので確かめたいです。
(ドキュメントも時間が経てば充実するかな??)

まずは、コンソールからDevOps Agentを検索し、Agent Spaceを作成します。

Agent Spaceを作成したら、Webアプリに入ることができます。
この画面からDevOps Agentの操作ができるようですね。現時点ではセキュリティエージェントと似たような仕様(Agent Space作成→Webアプリ操作)ですが、ユーザの紐づけや、UIもかなり異なりますね。
(チーム/POが違ったような気がするので、そのためかな…??)

Start Investigationから自然言語でクエリを投げてみます。
日本語には対応していないようなので、英語で「アカウントにあるECSのコスト最適化」と指示を入力します。
*CloudWatchを基にエラー分析など幅広い分析が可能

画面上の方にはトポロジーマップが自動作成されています。画面右のChatから追加でクエリを投げることができるようです。

レポートを作成するまで、画面で行っている処理を書き出してくれますね。ありがたい。
CLIでまずは、環境のECSを特定しているようです。

続いてCPU等のメトリクスを出してくれました。
最終結果として、以下のような提案がされました。

Assistant Response
Analysis Complete: ECS Task Resource Optimization for [SERVICE-NAME]

Based on my comprehensive analysis of CloudWatch metrics over the past 7 days, here are my findings and recommendations:

Current Configuration

  • CPU: 1024 units (1 vCPU)
  • Memory: 2048 MB (2 GB)
  • Service: [SERVICE-NAME] (Fargate)
  • Current tasks: 2 running tasks

Actual Resource Utilization

CPU Usage:

  • Average: ~0.29% (extremely low)
  • Peak: 38.03% (occurred on Dec 17, 2025)
  • Typical pattern: Consistent baseline of <1% with occasional spikes to 35-38%
  • Actual CPU consumed: ~3-4 CPU units average, with peaks up to ~390 CPU units

Memory Usage:

  • Average: 7.6-7.9% (very consistent)
  • Peak: 8.06%
  • Actual memory consumed: ~155-165 MB
  • Pattern: Extremely stable with no growth trends

Recommendations

Option 1: Balanced Optimization (RECOMMENDED)

  • CPU: 512 units (0.5 vCPU)
  • Memory: 1024 MB (1 GB)
  • Cost savings: ~50% reduction

Rationale:

  • Provides 131% headroom above peak CPU usage (512 vs 390 peak)
  • Offers 6x memory headroom (1024 MB vs ~165 MB peak)
  • Maintains performance buffer for unexpected traffic
  • Safe middle-ground approach

Option 2: Aggressive Optimization

  • CPU: 512 units (0.5 vCPU)
  • Memory: 512 MB
  • Cost savings: ~62.5% reduction

Rationale:

  • Still provides 31% CPU headroom above peak
  • Offers 3x memory headroom
  • Maximum cost optimization
  • Risk: Tighter margins during unexpected load

Option 3: Conservative Optimization

  • CPU: 512 units (0.5 vCPU)
  • Memory: 2048 MB (2 GB – keep current)
  • Cost savings: ~25% reduction

Rationale:

  • Only optimize CPU (clear over-provisioning)
  • Keep memory allocation unchanged for maximum safety
  • Minimal risk approach

Cost Impact Analysis

With 2 tasks running 24/7 in us-east-1:

Configuration Monthly Cost Savings
Current (1024/2048) ~$59.50 –
Option 1 (512/1024) ~$29.75 ~$29.75 (50%)
Option 2 (512/512) ~$22.32 ~$37.18 (62.5%)
Option 3 (512/2048) ~$44.63 ~$14.87 (25%)

Implementation Recommendations

  1. Start with Option 1 (512/1024) – Best balance of cost savings and safety margin
  2. Monitor closely for 1-2 weeks after change:
    • Watch for CPU throttling (if CPU hits 100%)
    • Monitor memory pressure and OOM events
    • Check application response times
  3. Consider Option 2 if metrics remain stable with significant headroom
  4. Rollback plan: Keep current task definition revision for quick revert if needed

Key Observations

  • ✓ Safe to optimize: Usage patterns are stable and predictable
  • ✓ No scaling concerns: Even peak usage is well below proposed limits
  • ✓ Consistent workload: No concerning growth trends or anomalies
  • ⚠ Monitor after change: Peak CPU spikes to 38% suggest some load variability

Next Steps

  1. Update task definition to 512 CPU / 1024 MB
  2. Deploy during low-traffic period
  3. Monitor CloudWatch metrics for:
    • CPU utilization should stay <80%
    • Memory utilization should stay <80%
    • No container restarts due to OOM
  4. Consider further optimization to 512/512 after 2 weeks if metrics remain healthy

Would you like me to help you create the updated task definition or provide the AWS CLI commands to implement these changes?

分析内容

過去7日間のCloudWatchメトリクスを自動分析し、以下の現状が明らかになりました。

1. 現在の設定

  • CPU: 1024ユニット(1 vCPU)
  • メモリ: 2048 MB

2. 実際の使用状況

  • CPU平均使用率: 0.29%(ピーク時でも38%)
  • メモリ平均使用率: 7.6%(約160MB)

3. 驚くべき発見

  • リソースの大部分が未使用のまま放置されていました。

提案内容

DevOps Agentは3つの最適化オプションを提示してくれました。

1. 推奨案(バランス型)

  • CPU 512ユニット / メモリ 1024 MB
  • コスト削減: 50%
  • 十分な余裕を確保しつつコスト最適化

2. 積極的最適化

  • CPU 512 / メモリ 512 MB
  • コスト削減: 62.5%
  • 最大限のコスト削減だがリスクやや高め

3. 保守的最適化

  • CPU 512 / メモリ 2048 MB(現状維持)
  • コスト削減: 25%
  • リスク最小限

エージェントの優れている点

1. 具体的な数値根拠

  • 「ピークCPU使用率に対して131%の余裕」など、単なる推測ではなく実測データに基づいた提案

2. リスク評価の明確さ

  • 各オプションのメリット・デメリット、リスクレベルを明示。意思決定がしやすい

3. 実装計画まで提示

  • デプロイタイミングの推奨
  • 監視すべきメトリクス
  • ロールバック計画

4. コスト影響の可視化

  • 月額$59.50が$29.75に削減(50%減)という具体的な数値で効果を提示

具体的で信頼性のある分析が返ってきましたね!!!

まとめ

「他のツールでもできるんじゃ?」という疑問について

正直、CLI系のコーディングエージェントやCloudWatch MCPでも似たようなことはできます。

ただ、DevOps Agentの良さは「組織で使うための作り込み」だと思います。メトリクスが見やすく表示されて、チームで共有しやすい。追加の分析も自然言語で簡単。Webアプリで一元管理できる。

個人の便利ツールじゃなくて、チーム全体の運用基盤として使えるのが大きな違いですね。

他の機能もかなり充実してて、既存の運用・監視SaaSを補完するだけでなく「DevOps Agent単体でほぼ完結する世界」への可能性も期待しています。

GAとアップデート、楽しみに待ってます!