はじめに
コーディングエージェントなどAI の進化で開発には AI の活用がなくてはならない時代になってきてると思いますが、
運用にも AI を活用できてますか？
SRE として、運用も AI を使ってもっと効率的にやっていきたい！と常々思っています。
そんな中、2025 年 12 月の AWS re:Invent 2025 で、運用の救世主となりそうなサービスが発表されました。
それが AWS DevOps Agent (Preview) です！！
AWS DevOps Agent は、AI を活用してインシデントの調査から根本原因の特定まで自動で行ってくれるというサービスです。
AWS が定義する新しいクラスの AI エージェント「Frontier Agent」の一つで、以下の特徴があります。
- 自律的な調査: CloudWatch アラートなどをトリガーに、人の介入なしで調査を開始
- 根本原因の特定: 複数の AWS サービスのデータを統合し、AI が原因を推論
- 対応策の提案: インシデントに対する修復プランを自動生成
- エージェント不要: コンテナ内にエージェントをインストール不要
詳細はAWS 公式ブログをご覧ください。
今回は「本当に AI だけでトラブルシューティングができるのか？」という疑問を持ちながら、標準的なwebサービス構成の ALB→ECS環境で検証してみました！
検証の目的
今回は以下の点を確認したいと思いました。
- 本当にエージェントなしで調査できるのか？
- どこまで詳細な根本原因を特定できるのか？
- 実際の運用で使えるレベルなのか？
検証環境の構築
アプリケーションの準備
検証のために AI でコーディングしたサンプルアプリ（個人情報をマスキングするwebアプリ、pii-masking-tool）を使います。
このアプリに以下の検証用エンドポイントを追加しました。
-
/error- 意図的にエラーを発生させる
@app.route('/error')
def trigger_error():
"""Intentionally trigger an error for DevOps Agent testing"""
error_type = request.args.get('type', 'exception')
if error_type == 'exception':
raise Exception("Intentional error triggered for AWS DevOps Agent testing")
elif error_type == 'division':
result = 1 / 0
# ...
ECS 環境のデプロイ
ECS 環境の構築には ECS Express Mode を使用しました。
こちらも11月に追加された新機能で、コンテナイメージを事前に用意しておけば、ECSクラスターやそれに紐づくALB、AutoScaling設定などを一括で自動作成してくれる機能です。
詳細はこちらを参照ください！
今回の構成
- ECS Fargate: 0.25 vCPU / 0.5 GB（最小構成）
- ALB: 自動作成
- オートスケーリング: CPU 使用率 60%でスケール、最大タスク数 2
AWS DevOps Agent の調査対象として識別させるため、ECS Express Mode で作られた下記リソースにタグを付与します。
- ECS クラスター
- ECS サービス
- ALB
- ターゲットグループ
※ タグは任意の値で問題ないです。(今回は Key：devops-agent, Value：true)
AWS DevOps Agent のセットアップ
1. Agent Space の作成
AWS DevOps Agent コンソールで「Begin Setup」をクリックし、以下を設定します。
-
エージェントスペース名: 例)
sample-app-ecs-agent
-
エージェントスペースの権限:
Auto-create a new DevOps Agent role(新しいロールを自動作成)
-
Include AWS tags： Key：
devops-agent, Value：true- 現状、DevOpsAgent は、CloudFormation で作成されたリソースか、ここで指定したタグを所持してるリソースしか調査対象としないため設定
- 現状、DevOpsAgent は、CloudFormation で作成されたリソースか、ここで指定したタグを所持してるリソースしか調査対象としないため設定
-
Web アプリの有効化:
Auto-create a new DevOps Agent role(新しいロールを自動作成)
1,2 分で作成が完了します。
2. Topology の確認
作成された Agent Space の「Topology」タブで、DevOps Agent が認識しているリソースを確認できます。
今回の環境では、以下のリソースが自動認識されました。
- ECS Cluster
- ALB / Target Group
- VPC / Subnet / Security Group
ECS Service や Task が Topology に表示されていませんが、
DevOps Agent は調査開始時に必要なリソースを動的に検出するため、実際の調査では正常に機能しました。
3. CloudWatch Alarm の作成
DevOps Agent がインシデントを検知できるよう、以下のアラームを作成しました。
5xx エラーアラーム
メトリクス: ALB - HTTPCode_Target_5XX_Count
条件: >= 3
期間: 1分
アラーム名: PII-Masking-ALB-5XX-Errors
検証実施：実際にインシデントを発生させる
テスト: 5xx エラーテスト
複数回エラーエンドポイントにアクセスして、5xx エラーを発生させます。
# HTTPSでアクセス
for i in {1..5}; do
curl "https://<アプリのドメイン>/error?type=exception"
sleep 1
done
実行結果
- 08:50（JST 17:50）に 5 回のエラーリクエスト
- 各リクエストで意図的に例外を発生
- ALB が 5 つの 500 エラーをカウント
- CloudWatch Alarm が ALARM 状態に遷移
DevOps Agent による自動調査
Web App の起動
Agent Spaces の「Web app」タブから「Operator access」で Web UI を起動します。
調査の実行
Web UI の「Start Investigation」から、自然言語で調査を依頼します。
調査クエリ例（英語のみ対応）
Investigate the 5xx errors on my application load balancer [エラー時刻]
調査依頼の詳細画面で、東京リージョンへ変更してます。
調査プロセスの観察
DevOps Agent が自動的に以下のステップを実行します。
1. インシデントの理解とコンテキスト収集
まず、ALB と ECS の構成情報を取得し、アーキテクチャ全体を把握します。
- Load Balancer の特定: describe_load_balancers API で ALB の詳細を取得
- CloudWatch Alarm の確認: describe_alarms API でアラームの状態とメトリクスを取得
- Topology の構築: リソース間の関係性を可視化
2. メトリクスデータの収集と分析
インシデント発生時刻前後のメトリクスを詳細に分析。
- HTTPCode_Target_5XX_Count: 08:50:00Z に 5 エラーを検出
- TargetResponseTime: 応答時間の変化を確認
- HealthyHostCount / UnhealthyHostCount: ターゲットの健全性を確認
検証結果：DevOps Agent の調査精度
5xx エラーインシデントの調査結果
DevOps Agent の最終結論
翻訳
/error エンドポイント経由で意図的に発生させたテストエラー
pii-masking-toolアプリケーションの/errorエンドポイントへのテストリクエストにより、意図的に5xxエラーが生成されました。
アプリケーションログには、08:50:38-43Zに5件の未処理例外が記録されており、各例外のメッセージは「AWS DevOps Agentテストのため意図的にエラーを発生させました」（app.pyの52行目から発生）となっています。
このエンドポイントは、テスト目的でサーバーエラーをシミュレートするよう設計されています。
各例外はALBにHTTP 500レスポンスを返却し、HTTPCode_Target_5XX_Countエラーとしてカウントされました。
発生時刻と件数（5秒間で5件）は、CloudWatchアラームデータが示す08:50:00Zの合計5リクエスト・エラー率100%と完全に一致しています。
これは本番環境のインシデントではなく、意図的なテスト活動によるものです。
調査精度の評価
DevOps Agent が特定した内容
| 項目 | 検出内容 | 精度 |
|---|---|---|
| エラー発生時刻 | 08:50:38-43Z（5 秒間） | 正確 |
| エラー件数 | 5 件 | 正確 |
| エラー率 | 100% | 正確 |
| 原因エンドポイント | /error |
正確 |
| ソースコード特定 | app.py 52 行目 | 正確 |
| エラーメッセージ | "Intentional error triggered for AWS DevOps Agent testing" | 完全一致 |
| インシデント性質 | テスト目的、本番障害ではない | 正確な判断 |
特に素晴らしかった点
- コードレベルまで特定: app.py の 52 行目という具体的な行番号まで特定
- 意図の理解: 単なるエラーではなく「テスト目的」と正しく判断
- データの整合性確認: CloudWatch Alarm の 5 エラーとログの 5 例外を照合
- 時系列の正確な把握: 5 秒間という短時間のイベントを正確に捉えた
所要時間: 約 9 分（自動）
対応策の提案
調査完了後、「Generate Mitigation Plan」をクリックすると、対応策の提案が表示されます。
今回はテストだったため「対応不要」という結果でした。
使ってわかったポイント
1. エージェントインストール不要
コンテナ内に何もインストールせずに、以下の情報だけで調査が完結しました。
- CloudWatch Logs（コンテナの標準出力が自動収集）
- CloudWatch Metrics（ECS/ALB のメトリクス）
- CloudTrail（API 操作履歴）
- AWS API（ECS DescribeTasks 等）
ECS Fargate の標準機能だけで、DevOps Agent に必要な情報がすべて揃います。
注意点・制約事項
実際に使ってみて気になった点です。
1. 日本語非対応（現時点）
調査クエリは英語のみ対応です。
2. プレビュー期間の制約
- リージョン: us-east-1 のみ
- 調査対象のサービスは ap-northeast-1(東京リージョン)でも大丈夫です。
コスト
DevOps Agent 本体
プレビュー期間中は無料です。
ただし、DevOps Agent が実行する CloudWatch Logs Insights クエリや API 呼び出しには通常料金が発生します。
使えそうなシーン
今回の検証を通して、以下のようなシーンで活用できそうと感じました。
- 障害時の初動対応 - 一次調査を実施
- トラブルシューティングの学習 - 調査プロセスを見て学べる
- ポストモーテム作成 - 調査ログをそのまま活用できる
まとめと今後の検証
今回は、シンプルな ECS 環境で AWS DevOps Agent の基本的な機能を検証してみました。
検証結果
- エージェントインストール不要で導入が簡単
- 根本原因の特定精度が想像以上に高い
- 調査プロセスが透明で理解しやすい
- プレビュー期間中は無料で試せる
今回はあくまで基本機能の動作確認でしたが、DevOps Agent がどんなことができるのか理解できました！
次の検証で試したいこと
今回の検証を踏まえて、今後は以下のような検証を進めていきたいと思います。
-
実際のプロダクション環境での検証
- 実際のwebサービスでの調査精度
- マイクロサービス間の連携エラーの追跡能力
-
複雑な障害シナリオでの検証
- データベース接続エラー
- 外部 API のタイムアウト
- メモリリークによるタスク再起動
-
運用フローへの組み込み
- Slack との通知連携
- アラート発火から調査開始までの自動化
- ポストモーテムレポートの自動生成
プレビュー期間中にさまざまなシーンで試してみて、実際の運用でどこまで活用できるか確かめていきたいと思います！
Discussion