はじめに
AWS re:Invent 2025 でプレビューが発表され、2026年に正式 GA となった AWS DevOps Agent。 インシデント対応・予防を自律的に行う「フロンティアエージェント」として、インフラ運用の在り方を大きく変える可能性を持ったサービスです。
本記事では、公式ドキュメントや実際の検証をもとに、技術仕様と動作確認の結果をまとめます。 SRE・インフラ担当者の方はもちろん、運用コスト削減に関心のある方にも参考になる内容です。
📌 本記事で分かること：AWS DevOps Agent のアーキテクチャ・機能・価格・対応インテグレーション、および弊社環境での簡易検証結果をまとめています。
AWS DevOps Agent の概要
AWS DevOps Agent は、インシデントの「解決」と「予防」を自律的に実行するマネージドエージェントサービスです。 テレメトリ・コード・デプロイデータを横断的に分析し、従来は人が対応していたオンコール業務を 24 時間 365 日自動化します。
主な 3 つの機能
- 自律的インシデント調査：アラート発生と同時に自動起動。テレメトリ・ログ・デプロイ履歴を関連付けて根本原因を特定します。
- インシデント予防：過去のインシデントパターンを学習し、オブザーバビリティ・インフラ最適化・デプロイ強化の提案を行います。
- On-demand SRE Chat：自然言語でインフラを照会。「今のシステムヘルスは？」と聞くだけで状況をレポートします。
⚠️ 注意：本記事の情報は 2026年4月時点のものです。サービスは継続的に更新されるため、最新情報は AWS 公式ドキュメントをご確認ください。
技術仕様
アーキテクチャ
AWS DevOps Agent は デュアルコンソール構成 を採用しています。 管理面（AWS Management Console）と運用面（DevOps Agent Web アプリ）を分離することで、 管理者と現場エンジニアの権限・操作を明確に区分しています。
コンソール | 主な利用者 | 主な操作 |
|---|---|---|
AWS Management Console | 管理者・SRE リード | Agent Space 作成・管理、インテグレーション設定、IAM / アクセス制御 |
DevOps Agent Web アプリ | オンコール担当者・開発者 | インシデント調査・応答、チャット照会、レポート確認 |
Agent Space
Agent Space は DevOps Agent の論理的なスコープ境界です。 AWS アカウント設定・サードパーティツール統合・アクセス権限をまとめた「コンテナ」として機能し、 エージェントがアクセス・調査できる範囲を定義します。
動作フロー
- リソース学習（トポロジー自動マッピング）
- アラート検知（CloudWatch / サードパーティ）
- データ相関分析（テレメトリ・コード・デプロイ）
- 根本原因特定 & 解決アクション提案
主要機能一覧
機能カテゴリ | 機能名 | 説明 |
|---|---|---|
インシデント対応 | 自動インシデント調査 | アラート・サポートチケット発生時に即座に調査開始 |
インシデント対応 | 詳細な軽減計画 | 具体的な解決アクション・成功検証・変更ロールバック手順を提示 |
インシデント対応 | 自動インシデント調整 | Slack / ServiceNow 経由で関係者へ情報を自動共有 |
インシデント対応 | AWS Support 統合 | 調査結果から AWS サポートケースを直接作成 |
予防・学習 | Learned Skills | 過去の調査パターンからエージェントが自動学習・スキル化 |
予防・学習 | Custom Skills | UI または SKILL.md ファイルで独自の調査手順を定義 |
レポート・Chat | Artifact 生成 | 週次ヘルスサマリー・エラーログ・インシデント分析を自然言語で指示して生成 |
レポート・Chat | On-demand SRE Chat | インフラの状態を自然言語で照会（コンソール操作不要） |
イベント連携 | EventBridge 統合 | イベント駆動ワークフローで DevOps Agent を自動トリガー |
インテグレーション
幅広い既存ツールと接続できる点が大きな特徴です。
オブザーバビリティ
Amazon CloudWatch、Datadog、Dynatrace、New Relic、Splunk、Grafana
コードリポジトリ / CI・CD
GitHub、GitHub Actions、GitLab、GitLab Workflows
ITSM / オンコール
PagerDuty、ServiceNow
コミュニケーション
Slack
マルチクラウド / カスタム
Azure リソース、Azure DevOps、MCP サーバー（カスタム）
✅ GA リリースで Azure リソース・Azure DevOps・Grafana・ネイティブ PagerDuty サポートが新たに追加されました。マルチクラウド環境での利用シナリオが大きく広がっています。
価格体系
課金は エージェントがタスクを実行している時間（agent-second） に対して発生します。 タスクの種別によらず単価は統一されています。
タスク種別 | 単価 |
|---|---|
インシデント調査 | $0.0083 / agent-second |
予防分析（Evaluation） | $0.0083 / agent-second |
On-demand SRE Chat | $0.0083 / agent-second |
特典 | 内容 |
|---|---|
無料トライアル | 初回実行後 2ヶ月間 無料 |
AWS サポートプラン割引 | サポートプランのティアに応じて 30〜100% のクレジット付与 |
対応リージョン
プレビュー時点では us-east-1 のみでしたが、GA で 6 リージョンに拡大。 東京リージョン（ap-northeast-1） も含まれており、日本語 UI にも対応しています。
リージョン | リージョンコード |
|---|---|
米国東部（バージニア北部） | us-east-1 |
米国東部（オハイオ） | us-east-2 |
米国西部（オレゴン） | us-west-2 |
東京 | ap-northeast-1 |
シドニー | ap-southeast-2 |
フランクフルト | eu-central-1 |
アイルランド | eu-west-1 |
💡 クロスリージョン監視：Agent Space が特定リージョンに存在していても、全 AWS リージョンのリソースを横断監視できます。日本のリソースは東京 Agent Space で完結させることが可能です。
エンタープライズ機能
GA リリースで追加されたエンタープライズ向け機能は以下のとおりです。
機能 | 内容 |
|---|---|
CloudFormation IaC | Agent Space のセットアップを Infrastructure as Code で管理可能 |
外部 IdP 認証 | Okta・Microsoft Entra ID によるシングルサインオン対応 |
VPC エンドポイント / PrivateLink | インターネットを経由しないプライベート接続 |
カスタマー管理キー | AWS KMS によるデータ暗号化（CMK 対応） |
AWS CLI サポート | AWS CLI v2.34.20 以降で |
検証結果
弊社の AWS 環境（東京リージョン）で AWS DevOps Agent のセットアップから基本的なインシデント対応フローまでを検証しました。
セットアップ手順
- IAM 権限の設定：AWS Management Console で DevOps Agent 用の IAM ロールを作成。
sts:TagSessionの追加付与が必要な点に注意が必要でした。 - Agent Space の作成：東京リージョンで Agent Space を作成。対象 AWS アカウントを紐付け、スコープを定義しました。
- CloudWatch インテグレーション：既存の CloudWatch アラームを DevOps Agent に接続。自動でリソーストポロジーのマッピングが開始されました（完了まで約5分）。
- GitHub リポジトリの接続：対象サービスのリポジトリを接続し、デプロイ履歴との相関分析を有効化しました。
- Slack 通知の設定：インシデント発生時の通知チャンネルを設定。IAM Identity Center のスコープ更新が必要でした。
インシデント対応テスト
テスト環境の Lambda 関数にわざとエラーを発生させ、CloudWatch アラームをトリガーした際の動作を確認しました。
# Lambda のエラーレートを上昇させてアラームをトリガー
aws cloudwatch set-alarm-state \
--alarm-name "LambdaErrorRate-High" \
--state-value ALARM \
--state-reason "Testing DevOps Agent response" \
--region ap-northeast-1アラーム発生後の DevOps Agent の動作フロー：
- アラーム検知から 約30秒 で調査開始（DevOps Agent Web アプリに通知）
- CloudWatch ログ・Lambda 実行履歴・最新のデプロイ差分を自動収集
- 関連するコードの変更箇所を特定し、「直近のデプロイで導入された例外ハンドリングの欠落」を根本原因として提示
- 修正アクションの提案（プルリクエストへのリンク含む）と Slack チャンネルへの自動通知
- 解決後に週次ヘルスレポートへの自動記録と「Learned Skill」への追加
## 根本原因分析
調査対象: lambda/order-processor (ap-northeast-1)
検知時刻: 2026-04-09 14:32:18 JST
エラーレート: 23.4% (閾値: 5%)
## 特定された根本原因
直近のデプロイ (commit: a3f9d12) にて、DynamoDB の
ConditionCheckFailedException の例外ハンドリングが
削除されていることを確認しました。
## 推奨アクション
1. 即時: 前バージョン (v1.4.2) へのロールバック
2. 恒久対応: 例外ハンドリングの再実装（PR #142 を参照）
3. 予防策: 統合テストへの DynamoDB エラーケースの追加結果サマリー
良かった点
- アラートから根本原因特定まで約2分で完了
- 日本語 UI・日本語レポートが自然で読みやすい
- 東京リージョンで完結するため遅延が少ない
- CloudWatch・GitHub の接続設定が非常に簡単
- Learned Skills により繰り返しインシデントの対応速度が向上
- 既存のオンコールフロー（Slack通知）とスムーズに統合できた
注意が必要な点
- 初期のリソーストポロジー学習に数分かかる
- IAM 権限設定でハマりポイントが多い（特に
sts:TagSession） - コスト試算は事前に行うことを推奨（agent-second 課金の把握が必要）
- プレビューからの移行は IAM ポリシー更新が必須
- MCP カスタム統合は設定コストが高い
まとめ
AWS DevOps Agent は、インシデント対応の自動化という従来の課題に対して、現実的で使えるソリューションを提供しています。 特に MTTR（平均復旧時間）の短縮効果は顕著で、弊社の検証では 数時間かかっていた原因特定が約2分 に短縮されました。
項目 | 内容 |
|---|---|
向いているケース | 24/365 のオンコール体制を整えることが難しいチーム、MTTR 短縮が急務の組織 |
日本語対応 | UI・レポートともに自然な日本語で利用可能 |
マルチクラウド | Azure・GCP リソースの監視も可能。既存ツール資産を活かせる |
コスト感 | $0.0083/agent-second。2ヶ月の無料トライアルで費用感を把握してから本番導入を推奨 |
導入難易度 | CloudFormation IaC 対応で環境の再現・管理が容易。IAM 設定は慎重に |
弊社評価 | ★★★★☆ — インシデント削減目的での本番導入を前向きに検討 |
弊社では引き続き検証を重ね、Custom Skills の活用や他インテグレーション（Datadog）との組み合わせについても記事化する予定です。 今後の続編もぜひお楽しみに。