AWS DevOps Agentが一般公開開始! — 料金・機能・インテグレーションをまとめました

記事タイトルとURLをコピーする

2026年3月31日、AWS re:Invent 2025で発表されたAWS DevOps Agentが一般公開(GA)されました。
この記事では、GA によるアップデートを踏まえたDevOps Agentの最新情報をカテゴリ別に紹介します。
各機能を掘り下げた記事へのリンクも付けていますので、DevOps Agent全般のまとめ記事として読んでいただけると幸いです。

AWS DevOps Agent とは

AWS DevOps Agent は、インシデントの検知・調査・復旧・予防を自動で行うサービスです。
例えば、予期せぬ負荷上昇が起きてアラートが発生した場合、そのアラートの原因と暫定対応策などを調査してもらうことができます。

GAで明らかになった主なポイントは以下の通りです。

  • 動いた分だけの秒単位の従量課金($0.0083/agent-second
  • 2ヶ月の無料トライアルあり
  • 東京リージョン対応、Azure/オンプレミス対応、PagerDuty/Grafana 連携など幅広くカバー
  • Preview 環境からの移行には IAM ポリシー名・信頼ポリシー・IDC スコープの変更対応が必要(後述)

料金体系

DevOps Agentの料金体系は以下の通りです。
DevOps Agentは設置するだけでは料金はかからず、AIによるインシデント調査の時間に対して料金が発生します。

項目 内容
課金単位 agent-second(秒単位)
単価 $0.0083 / agent-second
前払い なし
対象 Investigations, Evaluations, On-demand SRE タスク(すべて同一料金)

簡単に見積もると、1 回のインシデント調査(5〜10 分)で 約 $2.50〜$5.00($0.0083 × 300〜600 秒)という計算になります。
エージェントが待機しているだけの時間には課金されません。

月間の目安として、月 20 件のインシデント調査(各平均 10 分)なら月額約 $100。
オンデマンド SRE タスクの日常利用(1 日 15 分 × 20 営業日)を加えると月額約 $250 程度です。

接続先の AWS サービス(CloudWatch Logs Insights クエリ等)の利用料は別途かかる点に注意してください。

無料トライアル

2ヶ月間の無料トライアルが提供されています。

リソース 無料枠
Agent Space 最大 10
Investigations 20 時間
Evaluations 15 時間
On-demand SRE タスク 20 時間

AWS Support クレジット

AWS Support の契約レベルに応じた月額クレジットもあります。

サポートプラン クレジット割合
Unified Operations 100%
Enterprise 75%
Business+ 30%

月次付与で失効ありなので、使わなければ消えます。
詳細は 料金ページ を確認してください。

対応リージョン

現在、以下の 6 リージョンに対応しています。
GAにより東京リージョンにも対応しました。

リージョン コード
US East (N. Virginia) us-east-1
US West (Oregon) us-west-2
Europe (Frankfurt) eu-central-1
Europe (Ireland) eu-west-1
Asia Pacific (Sydney) ap-southeast-2
Asia Pacific (Tokyo) ap-northeast-1

エンドポイント形式は aidevops.<region-code>.amazonaws.com です。

クロスリージョンモニタリング

Agent Space がどのリージョンにあっても、任意のリージョンの AWS リソースを監視・調査できます。
たとえば東京リージョンに Agent Space を作成して、us-east-1 のリソースを調査対象にすることも可能です。

機能・インテグレーション(他のサービスとの連携)

主な機能とインテグレーションをカテゴリ別に紹介します。
インテグレーションとは、他のサービスとの連携を指す用語です。

対応ユースケース

  • Azure サポート: Azure ワークロードのインシデント調査にも対応。 AWS 以外のクラウドも調査対象に
  • オンプレミスサポート: MCP 経由でオンプレミスアプリケーションにも対応
  • オンデマンド SRE タスク: 会話型 AI アシスタント。 自然言語でクエリ・分析・カスタムチャート/レポート作成が可能
  • Triage Agent: アラートを受信するとまず重大度を自動評価し、過去のインシデントとの重複を検出する。 重複と判定された場合はメインの調査に「LINKED」ステータスでリンクされ、自動起動されないためノイズが減る。 Investigation(根本原因調査)の前段として機能

インテリジェンス機能

  • 学習済みスキル: 組織の調査パターン・ツール使用・トポロジから自動学習
  • カスタムスキル: 組織固有の調査手順・ベストプラクティス・ナレッジを追加可能。エージェントタイプ別に設定
  • コードインデックス: コードリポジトリをインデックス化し、バグ特定・コードレベルの修正提案が可能に

学習済みスキル・カスタムスキルについては、こちらの記事で検証しています。

blog.serverworks.co.jp

インテグレーション(他のサービスとの連携)

サービス 概要
PagerDuty ネイティブインテグレーション
Grafana 組み込み MCP サーバー。 セルフマネージド / Grafana Cloud / Amazon Managed Grafana 対応。 Prometheus, Loki, OpenSearch 等のデータソースにアクセス
Azure DevOps Azure Pipelines 連携
Amazon EventBridge 調査イベントをカスタム自動化ワークフローに利用可能

PagerDuty や Grafana とネイティブ連携できるのは、既にインシデント管理・監視に使っているチームにとって嬉しいポイントですよね。

エンタープライズ対応

エンタープライズ向けの機能も備えています。

機能 概要
プライベート接続 VPC / 内部ネットワークのサービスにパブリックインターネット経由なしで接続。 MCP サーバー、セルフホスト Grafana / Splunk 等
IdP 統合 Okta, Microsoft Entra ID との直接統合
カスタマーマネージドキー KMS 対応
ローカライゼーション ブラウザのロケール設定に応じた応答翻訳

プライベート接続があるので、セキュリティ要件の厳しいエンタープライズ環境でも導入しやすくなっています。

Preview 参加企業による実績

GA にあたって 公式ブログ では、Preview 参加企業の実績として以下の数値が公開されています。

指標 効果
MTTR 削減 最大 75%
調査時間短縮 80%
根本原因特定精度 94%
インシデント解決速度 3〜5 倍

Preview からの移行で必要な対応

Preview から使っていた環境向けの内容です。
GA でもっとも注意が必要なのが IAM まわりの変更です。 Preview から使っている環境では、IAM の名前やポリシーが変わっているため、そのままだと動かなくなります。

変更点 Preview GA
IAM マネージドポリシー名 AIOpsAssistantPolicy AIDevOpsAgentAccessPolicy
Monitor ロール信頼ポリシー sts:AssumeRole + ArnLike 変更なし
Operator ロール信頼ポリシー sts:AssumeRole のみ sts:AssumeRole + sts:TagSession + ArnEquals
Operator ロール信頼ポリシーの条件 ArnLike + ワイルドカード ArnEquals + 具体的な agentspace-id
IAM IDC スコープ awsaidevops:read_write aidevops:read_write
Operator ロールポリシー インラインポリシー AIDevOpsOperatorAppAccessPolicy(マネージド)
IDC Operator ロール なし sts:SetContext(TrustedIdentityPropagation)の追加など複数の変更が必要。 移行ガイド参照
オンデマンドチャット履歴 保持 2026/3/30 以前のチャットは削除(調査ジャーナル・ファインディングは保持)

特に注意してほしいのが、Monitor ロールと Operator ロールで対応内容が異なる点です。 Monitor ロールの信頼ポリシーは Preview から変更なし(ArnLike のまま)ですが、Operator ロールは ArnLikeArnEquals + 具体的な agentspace-id への変更と、sts:TagSession の追加が必要です。

IDC 経由の Operator ロールでは、さらに sts:SetContext(TrustedIdentityPropagation)用のステートメントも追加が必要です。

Monitor ロール(AgentSpace 用)の信頼ポリシー(変更なし):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:us-east-1:123456789012:agentspace/*"
        }
      }
    }
  ]
}

Operator ロール(Web アプリ用)の信頼ポリシー(要変更):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        },
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:aidevops:us-east-1:123456789012:agentspace/your-agentspace-id"
        }
      }
    }
  ]
}

Preview からの移行では、Operator ロールのみ ArnLikeArnEquals + 具体的 ARN への書き換えと sts:TagSession の追加が必要です。
Monitor ロールの信頼ポリシーは変更不要です。

IAM Identity Center(IDC)経由の Operator ロールでは、上記に加えて TrustedIdentityPropagation 用のステートメントが必要です:

{
  "Sid": "TrustedIdentityPropagation",
  "Effect": "Allow",
  "Principal": {
    "Service": "aidevops.amazonaws.com"
  },
  "Action": "sts:SetContext",
  "Condition": {
    "ForAllValues:ArnEquals": {
      "sts:RequestContextProviders": "arn:aws:iam::aws:contextProvider/IdentityCenter"
    }
  }
}

IAM Identity Center のマネージドアプリについても注意が必要です。
IDC スコープが awsaidevops:read_write から aidevops:read_write に変わっていますが、IDC マネージドアプリは直接更新できません。
一度切断して再接続する必要があります。

移行手順の詳細は 公式移行ガイド を参照してください。

IaCとAWS SDKの対応状況

IaCとAWS SDKの対応状況はこちらの記事をご覧ください。

blog.serverworks.co.jp

インシデント調査などが動作するトリガー

インシデント調査などが動作するトリガーは以下の3種類があります。

トリガー 説明
手動 オペレーターアプリのチャットから直接依頼
ビルトイントリガー 連携させたServiceNow、PagerDutyなどで起票
Webhook 外部システムからの HTTP POST

Amazon CloudWatchでアラートが発生しても、DevOps Agentは即時反応してインシデント調査が発生するわけではありません。
上記3種類のいずれかの操作をする必要があります。
アラートに対して自動でDevOps Agentを動かすにはWebhookを使用して実行を促す必要があります。
Webhookを使用したDevOps Agentの起動については、以下の記事で検証しているのでこちらをご覧ください。

blog.serverworks.co.jp

参考リンク

越後 元貴 (記事一覧)

アプリケーションサービス本部ディベロップメントサービス4課

2023年新卒入社