AWS

AWS DevOps Agentの使い方：CLIでの構築とCloudWatchアラームから調査を自動起動する手順

AWS DevOps Agentの使い方：CLIでの構築とCloudWatchアラームから調査を自動起動する手順

AWS DevOps Agentは、障害の原因調査をAIエージェントに任せるAWSのサービスで、2026年3月31日に一般提供へ移りました。この記事では、IAMロールとAgent SpaceをAWS CLIで作り、CloudWatchアラームが鳴った瞬間にHMAC署名付きのWebhookで調査を起動するところまでを、コピーして動かせる形で説明します。料金は1エージェント秒あたり0.0083ドルで、使った分だけの従量課金です。サービスの全体像やAgent Spaceという概念そのものは、プレビュー期に書いたAWS DevOps Agentの概要と特徴の解説に譲り、ここでは手を動かす部分に絞ります。

まとめ：東京リージョンにCLIで構築しアラームからWebhookで調査を起動

構築の順番は、IAMロール2本、Agent Space、AWSアカウントの関連付け、オペレーターアプリの有効化です。ここまではAWS CLIだけで進められます。東京リージョン（ap-northeast-1）でも使えるので、データの保存先を国内に置けます。

調査の自動起動は、CloudWatchアラームからLambdaを直接呼び、そのLambdaがWebhookへ署名付きのリクエストを送る形が素直です。Webhookの発行だけはコンソール操作になります。費用は調査1件あたりの稼働秒数で決まるため、導入初月は get-account-usage で使用時間を毎日確かめてください。

AWS DevOps Agentの一般提供後の仕様と料金を2026年9月時点で整理

プレビュー期の解説記事は、対応リージョンが米国東部だけだった頃の前提で書かれているものが多く残っています。構築の前に、一般提供後に変わった点を公式の記載で押さえておきます。

2026年3月の一般提供で変わった対応リージョンと東京でのデータの保存先

一般提供の告知（2026年3月31日）では、Azureやオンプレミスのアプリケーションの調査、独自スキルの追加、調査結果のレポート作成が新たに加わりました。対応リージョンの一覧には2026年9月時点で11リージョンが並び、東京も含まれます。

押さえておきたいのは保存先の扱いです。Agent Spaceとその調査結果・トポロジー・推奨事項は、Agent Spaceを作ったリージョンに保存されます。一方で監視対象のリソースは、関連付けたアカウントの全リージョンが対象です。大阪で動くシステムでも東京のAgent Space1つで調べられるため、リージョンごとにAgent Spaceを作る必要はありません。

なお、CLIのオンボーディングガイド本文には「6リージョン」という記述が残っており、リージョン一覧と食い違っています。構築前に確かめるならリージョン一覧のページを見てください。

1エージェント秒0.0083ドルの従量課金と無料トライアルの範囲

公式の料金ページでは、調査・評価・オンデマンドのタスクのいずれも同じ秒単価です。

項目 2026年9月時点の公式の記載
単価 0.0083ドル／エージェント秒
1時間あたり 29.88ドル（待機中は課金なし）
無料トライアル 新規利用者に2か月
AWS Supportのクレジット 前月のSupport料金の30〜100%
公式の試算例 月10件・平均8分で39.84ドル
別料金 Logs Insightsなど他サービス

無料トライアルの枠は、各月Agent Space10個・調査20時間・評価15時間・オンデマンドのタスク20時間までです。Supportのクレジットは契約の種類で率が変わり、Unified Operationsが100%、Enterprise Supportが75%、Business Support+が30%で、毎月10日までに付与されてその月末に失効します。

見落としやすいのは表の最後の行です。エージェントがログを横断検索すると、スキャン量に応じたLogs Insightsの料金が別に積み上がります。ロググループが大きい環境では、エージェントの秒課金より先にこちらが膨らむことがあります。

検証環境の前提とIAMロール2本をAWS CLIで作成する手順

AWS CLI v2と、IAMロールを作成できる権限を持つ認証情報を用意します。CLIオンボーディングガイドの所要時間の目安は約20分です。以下では監視アカウントIDを111122223333、リージョンを東京として書きます。

Agent Space用ロールの信頼ポリシーとマネージドポリシーの付与

1本目はエージェント本体が引き受けるロールです。信頼ポリシーのプリンシパルは aidevops.amazonaws.com で、aws:SourceAccount と aws:SourceArn の条件で自アカウントのAgent Spaceだけに絞ります。この条件を外すと、別アカウントのサービスに権限を悪用される「混乱した代理」の余地が残ります。

REGION=ap-northeast-1
ACCOUNT_ID=111122223333

cat > devops-agentspace-trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "aidevops.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "aws:SourceAccount": "${ACCOUNT_ID}" },
      "ArnLike": { "aws:SourceArn": "arn:aws:aidevops:${REGION}:${ACCOUNT_ID}:agentspace/*" }
    }
  }]
}
EOF

aws iam create-role \
  --role-name DevOpsAgentRole-AgentSpace \
  --assume-role-policy-document file://devops-agentspace-trust-policy.json

aws iam attach-role-policy \
  --role-name DevOpsAgentRole-AgentSpace \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy

ガイドでは、このロールにResource Explorerのサービスリンクロールを作る権限（iam:CreateServiceLinkedRole）もインラインポリシーで足しています。トポロジーの自動検出に使うので省略しないでください。

オペレーターアプリ用ロールとsts:TagSessionを足す理由

2本目は、運用担当者が調査結果を見るWebアプリ（オペレーターアプリ）用のロールです。信頼ポリシーの形は1本目と同じで、Actionに sts:TagSession を加えます。付与するマネージドポリシーは AIDevOpsOperatorAppAccessPolicy です。

TagSessionが要るのは、このポリシーが aws:PrincipalTag/AgentSpaceId の条件で操作できるAgent Spaceを絞っているためです。セッションにタグが付かないと、権限はあっても対象のAgent Spaceが見えません。同じアカウントで2つ目のAgent Spaceを作るときは、このロールを使い回せます。

Agent Spaceの作成からAWSアカウントの関連付けまでをCLIで進める

ロールがそろったら、aws devops-agent コマンドでAgent Spaceを作ります。サブコマンドの一覧はAWS CLIリファレンスのdevops-agentの項で確かめられます。

Agent Spaceを作成し監視アカウントをmonitorとして関連付ける

作成時のレスポンスにある agentSpace.agentSpaceId を控え、続けて監視アカウントを accountType が monitor の関連付けとして登録します。回答の言語を指定する --locale や、顧客管理のKMSキーを使う --kms-key-arn も作成時に渡せます。

SPACE_ID=$(aws devops-agent create-agent-space \
  --name "prod-payments" \
  --description "決済系サービスの本番環境" \
  --region ${REGION} \
  --query 'agentSpace.agentSpaceId' --output text)

aws devops-agent associate-service \
  --agent-space-id ${SPACE_ID} \
  --service-id aws \
  --configuration "{
    \"aws\": {
      \"assumableRoleArn\": \"arn:aws:iam::${ACCOUNT_ID}:role/DevOpsAgentRole-AgentSpace\",
      \"accountId\": \"${ACCOUNT_ID}\",
      \"accountType\": \"monitor\"
    }
  }" \
  --region ${REGION}

aws devops-agent enable-operator-app \
  --agent-space-id ${SPACE_ID} \
  --auth-flow iam \
  --operator-app-role-arn "arn:aws:iam::${ACCOUNT_ID}:role/DevOpsAgentRole-WebappAdmin" \
  --region ${REGION}

本番・検証など別アカウントも調べさせる場合は、相手側のアカウントにクロスアカウントロールを作り、accountType を source にして関連付けを追加します。

関連付けの確認手順とオペレーターアプリのSSO認証への切り替え

登録できたかは get-agent-space と list-associations で確かめます。関連付けが1件も返らない場合は、associate-service の実行結果を見直し、ロールARNのアカウントIDと、信頼ポリシーの aws:SourceArn に書いたリージョンの誤りを確かめます。

オペレーターアプリの認証は、ここではIAMで有効にしました。チームで使うなら --auth-flow idc でIAM Identity Centerに、社内のIdPを使うなら --auth-flow idp に切り替えられます。

CloudWatchアラームからWebhookで調査を起動するLambdaの実装

調査の起動口はWebhookです。ServiceNowやDatadogなど連携先ごとに専用のWebhookがあり、それ以外の送信元には汎用Webhookを使います。CloudWatchアラームは汎用Webhookで受けるのが早道です。

汎用WebhookのHMACとAPIキーの選び方と作成時の制約

Webhookの公式ドキュメントによると、汎用Webhookの認証方式はHMACとAPIキー（Bearerトークン）の2種類で、Agent Spaceごとに各1本までです。

観点 HMAC APIキー
送るヘッダ x-amzn-event-signature等 Authorization: Bearer
本文の改ざん検知 できる できない
再送攻撃への備え タイムスタンプで古い要求を拒否 トークンを回転するまで再利用される
実装の手間 要求ごとに署名を計算 固定トークンを付けるだけ

自前のLambdaから送るなら、署名の計算は数行で済むのでHMACを選びます。発行はコンソールのAgent Space→Capabilities→Webhookで行い、シークレットが表示されるのは作成時の1回だけです。控え損ねたら、URLを変えずにシークレットだけ作り直す「Rotate webhook」を使います。

Secrets ManagerからURLとシークレットを読み署名するPythonコード

URLとシークレットは環境変数に書かず、AWS Secrets Managerの料金とローテーション設定で扱っている形でシークレットに保存します。AWS公式のサンプルリポジトリも同じ構成です。

import base64
import hashlib
import hmac
import json
import os
import urllib.request
from datetime import datetime, timezone

import boto3

secrets = boto3.client("secretsmanager")


def load_webhook():
    # {"webhookUrl": "...", "webhookSecret": "..."} の形で保存しておく
    raw = secrets.get_secret_value(SecretId=os.environ["WEBHOOK_SECRET_ARN"])["SecretString"]
    value = json.loads(raw)
    return value["webhookUrl"], value["webhookSecret"]


def build_incident(event):
    alarm = event["alarmData"]
    state = alarm["state"]
    return {
        "eventType": "incident",
        # 同じ状態遷移の再送は同じIDになり、DevOps Agent側で重複排除される
        "incidentId": f'{alarm["alarmName"]}-{state["timestamp"]}',
        "action": "created",
        "priority": os.environ.get("PRIORITY", "HIGH"),
        "title": f'{alarm["alarmName"]} が {state["value"]} に遷移',
        # エージェントに届くのは title・description・priority だけなので、手掛かりはここに書く
        "description": f'{state["reason"]} account={event["accountId"]} region={event["region"]}',
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "service": os.environ.get("SERVICE_NAME", "unknown"),
    }


def sign(secret, timestamp, body):
    # 署名対象は「タイムスタンプ:本文」。SHA-256のHMACをBase64にする
    mac = hmac.new(secret.encode("utf-8"), f"{timestamp}:{body}".encode("utf-8"), hashlib.sha256)
    return base64.b64encode(mac.digest()).decode("ascii")


def handler(event, context):
    state = event["alarmData"]["state"]["value"]
    if state != "ALARM":
        # OK や INSUFFICIENT_DATA への遷移では調査を起動しない
        return {"skipped": state}
    url, secret = load_webhook()
    body = json.dumps(build_incident(event), ensure_ascii=False)
    timestamp = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.000Z")
    request = urllib.request.Request(
        url,
        data=body.encode("utf-8"),
        method="POST",
        headers={
            "Content-Type": "application/json",
            "x-amzn-event-timestamp": timestamp,
            "x-amzn-event-signature": sign(secret, timestamp, body),
        },
    )
    with urllib.request.urlopen(request, timeout=10) as response:
        return {"status": response.status}

ペイロードの data 欄は受け付けられるものの、公式ドキュメントには調査の文脈には入らないと明記されています。アカウントIDやリージョンを description に書いているのはそのためです。

Lambdaにリソースポリシーを付けアラームのアクションに登録する

CloudWatchアラームは2023年12月からLambdaを直接呼べるようになり、SNSを挟む必要がなくなりました。CloudWatchのLambdaアクションの説明にあるとおり、関数側にリソースポリシーを付けてからアラームのアクションに関数のARNを指定します。

FUNCTION_ARN=arn:aws:lambda:${REGION}:${ACCOUNT_ID}:function:devops-agent-webhook

aws lambda add-permission \
  --function-name devops-agent-webhook \
  --statement-id AlarmAction \
  --action 'lambda:InvokeFunction' \
  --principal lambda.alarms.cloudwatch.amazonaws.com \
  --source-account ${ACCOUNT_ID} \
  --source-arn arn:aws:cloudwatch:${REGION}:${ACCOUNT_ID}:alarm:payments-api-5xx

aws cloudwatch put-metric-alarm \
  --alarm-name payments-api-5xx \
  --namespace AWS/ApiGateway \
  --metric-name 5XXError \
  --dimensions Name=ApiName,Value=payments-api \
  --statistic Sum --period 60 --evaluation-periods 3 --threshold 5 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions ${FUNCTION_ARN} \
  --region ${REGION}

Lambdaの実行ロールには、対象シークレットへの secretsmanager:GetSecretValue だけを許可します。アラームそのものの閾値の決め方はLambdaをCloudWatchで監視する方法の記事が参考になります。

Webhookの応答が200でも調査が始まらないときに確かめる3つの点

Webhookが200を返すのは「認証が通り、キューに入った」という意味までです。調査が始まらない原因は、公式のトラブルシューティングで次の順に挙げられています。

  1. incidentIdとタイムスタンプが毎回変わっているか（同じ内容は重複として捨てられる）
  2. 本文が正しいJSONか、eventTypeやpriorityの値が仕様どおりか
  3. 200のあと即座にキャンセルされるなら、月間の上限に達していないか

4xxが返る場合はほぼ署名かヘッダの誤りです。Lambdaが例外で終わると非同期呼び出しの再試行が走りますが、上のコードはincidentIdが同じになるため、再試行で調査が二重に起動することはありません。

CLIから調査を起票し月間の使用時間と費用を見張るコマンドの使い方

Webhookを使わず、CLIやSDKから直接調査を起票する方法もあります。デプロイ後の確認をCIに組み込むときや、手動で気になる事象を調べさせるときに使えます。

create-backlog-taskのINVESTIGATIONで手動調査を起票する

create-backlog-taskのリファレンスでは、--task-type にINVESTIGATION・EVALUATION・RELEASE_READINESS_REVIEW・RELEASE_TESTINGの4種を指定できます。後ろの2つは2026年6月17日にプレビュー公開されたリリース管理機能で、2026年9月時点では米国東部（us-east-1）だけで動きます。

aws devops-agent create-backlog-task \
  --agent-space-id ${SPACE_ID} \
  --task-type INVESTIGATION \
  --priority HIGH \
  --title "決済APIのp99レイテンシが14:05から倍増" \
  --description "14:00のデプロイ後から悪化。RDSの接続数も増えている" \
  --client-token deploy-20260930-1405 \
  --region ${REGION}

aws devops-agent get-account-usage --region ${REGION}

--client-token を付けると、同じトークンでの再実行が新しい調査を作りません。CIのリトライで調査が重複しないよう、デプロイIDなどから決まる値を入れておきます。

get-account-usageで月間の調査時間と上限を毎日確かめる

get-account-usageのリファレンスによると、応答には調査・評価・システム学習・オンデマンドの4種類について、月間の使用時間（usage）と上限（limit）が入ります。上限が-1なら制限なしという意味です。

導入初月は、この値を日次で取得してSlackなどに流すところまで作っておくと安心です。調査時間20時間は、トライアル後なら約597ドルに当たります。アラームの閾値が甘く調査が1日に何十件も起動すると、この水準へ短期間で届きます。

AWS DevOps Agentを導入すべき条件と見送るべき運用体制の見極め

ここまでの構築は1日あれば終わります。難しいのは「任せてよい環境か」の判断のほうです。

導入を勧める条件は夜間の呼び出しと初動調査の属人化が重なる環境

導入を勧めるのは、夜間や休日の呼び出しが月に数回以上あり、初動の切り分けを特定の担当者に頼っている環境です。調査の平均が30分かかっている障害を、エージェントが8分で当たりを付けるなら、1件あたりの費用は約4ドルで済みます。MTTRの計算式と短縮策のうち「検知から原因特定まで」の区間を縮める手段として見るのが実態に合います。

インシデントの記録や振り返りの流れが無いまま入れても、エージェントの調査結果は読まれずに流れます。先にインシデント管理のプロセスとオンコール体制を整えるのが順番です。

見送る場面は監視が未整備の環境とデータ所在の規定が厳しい案件

次の2つに当たるなら、この段階では見送ります。1つ目は、CloudWatchのメトリクスやログ、トレースがそろっていない環境です。エージェントは既存のテレメトリを読んで推論するので、材料が無ければ当て推量の報告しか返りません。ADOTとCloudWatchでの計装を先に済ませるべきです。

2つ目は、調査データを特定の場所から出せない案件です。Agent Spaceの保存先は選べても、推論の処理経路は公式の料金・リージョンのページからは読み取れません。規定の厳しい案件では、AWSの担当窓口に処理経路を書面で確かめてから決めてください。

監視の整備から障害対応の運用設計までを外部に任せたい場合は、一創の保守運用・内製化支援でご相談を受けています。

よくある質問

AWS DevOps Agentの構築と運用で、検索されることの多い疑問に答えます。

AWS DevOps Agentは東京リージョンで使えますか？

使えます。2026年9月時点の対応リージョン一覧には東京（ap-northeast-1）を含む11リージョンが並びます。Agent Spaceと調査データは作成したリージョンに保存され、監視対象のリソースは関連付けたアカウントの全リージョンが対象です。ただしリリース管理のプレビュー機能は米国東部だけで、東京では調査・評価・オンデマンドのタスクとカスタムエージェントを使う形になります。

AWS DevOps Agentの料金はどう計算されますか？

調査・評価・オンデマンドのタスクとも、エージェントが動いた秒数に0.0083ドルを掛けた額です。待機時間は課金されません。公式の試算では月10件・平均8分の調査で39.84ドルです。新規利用者には2か月の無料トライアルがあり、AWS Supportの契約に応じたクレジットも付きます。調査中に呼ばれるLogs Insightsなどの料金は別に請求されます。

Webhookのシークレットを控え忘れたらどうすればよいですか？

コンソールのCapabilitiesタブから該当のWebhookを開き、「Rotate webhook」でシークレットを作り直します。URLは変わらず、古いシークレットは無効になります。シークレットは作成時にしか表示されず、APIからも取り出せません。CloudFormationやTerraformで作った場合も出力には含まれないので、デプロイ後に同じ手順で作り直し、Secrets Managerへ保存してください。

SNS経由とLambda直接呼び出しのどちらでつなぐべきですか？

DevOps Agentへ送るだけならLambdaの直接呼び出しで足ります。CloudWatchは状態が変わるたびに非同期でLambdaを呼び、届かない場合も再試行する仕組みです。同じアラームをメールやチャットにも流したい場合は、SNSトピックを挟んで配信先を分けるほうが構成を追いやすくなります。

DatadogのBits AI SREとはどう使い分ければよいですか？

監視の中心がDatadogにあるなら、テレメトリの近くで動くDatadogのBits AI SREが先に候補になります。AWSのリソース構成やCloudWatchが中心で、GitHubの変更履歴と突き合わせて調べさせたいならDevOps Agentが合います。DevOps AgentはDatadogとも連携できるため、両方を持つ環境では、どちらの調査結果を一次の窓口にするかを先に決めてください。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.09.28　テックブログ タイムズカーの不正アクセスと約660万件の流出｜免許証画像を退会者まで残さない保管設計
  2. 2025.11.28　コラム ポリコレとは？意味と具体例、「行き過ぎ」「逆差別」と言われる理由を法律と調査で整理
  3. 2026.05.22　テックブログ Irodori-TTSとは？v4.1の使い方・絵文字一覧・商用利用とv3からの変更点
  4. 2026.09.25　コラム 最低賃金引き上げ【令和8年度】47都道府県の改定額・発効日と企業の対応手順
  5. 2026.09.27　コラム 法定調書合計表とは？令和8年分の書き方と提出義務、給与・支払データからの集計自動化

RELATED POSTS 関連記事

一覧へ戻る

目次