AWS DevOps Agent 検証 — 最小構成でのセットアップ・インシデント調査・Chat の実力
目次
はじめに
2026年3月31日、AWS は AWS DevOps Agent の一般提供(GA)を発表した。インシデント対応の自律的な調査・解決、予防的な改善提案、オンデマンド SRE タスクの3つの柱を持つ「フロンティアエージェント」である。GA では Azure / オンプレミス環境の調査対応、カスタムスキルによる拡張、Triage Agent(重複チケット自動検出)、PagerDuty / Grafana 連携などが追加された。対応リージョンは us-east-1、us-west-2、ap-southeast-2、ap-northeast-1、eu-central-1、eu-west-1 の6つ。
プレビューでは「MTTR を数時間から数分に短縮」「最大75% の MTTR 改善」と報告されている。ただし、ローンチブログの顧客事例を見ると、WGU は Dynatrace 連携、Zenchef は ECS デプロイメントと EC2 上の GitHub の IAM 設定を横断的に調査するなど、いずれも複数ツールを接続した環境での成果である。最小構成(単一アカウント + CloudWatch のみ)でも実用的な結果が得られるのか。本記事では東京リージョンでゼロからセットアップし、インシデント調査と Chat 機能を検証する。公式ドキュメントは AWS DevOps Agent User Guide。
前提条件:
- AWS CLI v2(2.34.21 で動作確認済み。2.34.16 では
devops-agentサブコマンド未対応) - IAM ロール作成権限、EC2 / CloudWatch の操作権限
- AWS Organizations を使用している場合、SCP で
aidevops:*アクションがブロックされていないことを確認する(よくあるトラブルとして報告されている) - 検証リージョン: ap-northeast-1(東京)
料金は秒単位課金で、AWS Support 顧客は月額クレジットが付与される(Unified Operations: 100%、Enterprise: 75%、Business+: 30%)。詳細は料金ページを参照。
結果だけ見たい場合はまとめに進んでほしい。
検証 1: エージェントスペース セットアップとトポロジー構築
エージェントスペース は DevOps Agent の論理的なコンテナで、AWS アカウント・外部ツール連携・ユーザー権限を定義する。ベストプラクティスガイドでは、エージェントスペースの境界をオンコールの責任範囲に合わせ、本番環境と非本番環境を分離することを推奨している。本記事では検証目的のため単一アカウント・最小構成で進める。DevOps Agent はデュアルコンソール構成を採用しており、管理者は AWS マネジメントコンソールで エージェントスペース の作成や連携設定を行い、オペレーターはオペレーターアクセスで日常のインシデント調査や Chat を利用する。CLI オンボーディングガイドに従い、IAM ロール作成から オペレーターアクセス有効化までを実行した。本番環境では CDK や Terraform のテンプレートを使った IaC デプロイが推奨されている。
IAM ロール・エージェントスペース 作成手順
2つの IAM ロールが必要である。エージェントスペース 用ロール(リソース検出・調査用)と オペレーターアクセス用ロールだ。
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=ap-northeast-1
# 信頼ポリシー
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 SLR 作成用インラインポリシー
cat > devops-agentspace-additional-policy.json << EOF
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowCreateServiceLinkedRoles",
"Effect": "Allow",
"Action": ["iam:CreateServiceLinkedRole"],
"Resource": [
"arn:aws:iam::${ACCOUNT_ID}:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"
]
}]
}
EOF
aws iam put-role-policy \
--role-name DevOpsAgentRole-AgentSpace \
--policy-name AllowCreateServiceLinkedRoles \
--policy-document file://devops-agentspace-additional-policy.jsoncat > devops-operator-trust-policy.json << EOF
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "Service": "aidevops.amazonaws.com" },
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Condition": {
"StringEquals": { "aws:SourceAccount": "${ACCOUNT_ID}" },
"ArnLike": { "aws:SourceArn": "arn:aws:aidevops:${REGION}:${ACCOUNT_ID}:agentspace/*" }
}
}]
}
EOF
aws iam create-role \
--role-name DevOpsAgentRole-WebappAdmin \
--assume-role-policy-document file://devops-operator-trust-policy.json
aws iam attach-role-policy \
--role-name DevOpsAgentRole-WebappAdmin \
--policy-arn arn:aws:iam::aws:policy/AIDevOpsOperatorAppAccessPolicyAGENT_SPACE_ID=$(aws devops-agent create-agent-space \
--name "verification-space" \
--description "Agent Space for verification" \
--locale "ja-JP" \
--region $REGION \
--query "agentSpace.agentSpaceId" --output text)
aws devops-agent associate-service \
--agent-space-id $AGENT_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 $AGENT_SPACE_ID \
--auth-flow iam \
--operator-app-role-arn "arn:aws:iam::${ACCOUNT_ID}:role/DevOpsAgentRole-WebappAdmin" \
--region $REGION結果
| ステップ | 所要時間 |
|---|---|
| IAM ロール 2つ作成 + ポリシーアタッチ | 約26秒 |
| エージェントスペース 作成 | 約8秒 |
| AWS アカウント関連付け | 約10秒 |
| オペレーターアクセス有効化 | 約6秒 |
| 合計 | 約50秒 |
aws sts get-caller-identity によるアカウント ID 取得を含めると約66秒で全工程が完了した。
エージェントスペース 作成直後に SYSTEM_LEARNING タスクが自動起動し、アカウント内のリソースを学習し始めた。トポロジー構築は約20分で完了した。コンソール操作なしで CLI のみで完結する点は、IaC との親和性が高い。
注目すべきは --locale "ja-JP" オプションである。これを指定すると、エージェントの応答がすべて日本語になる。調査レポートやチャット応答が日本語で返ってくるのは、日本のチームにとって大きなメリットだ。
検証 2: インシデント調査 — Chat で根本原因を特定できるか
EC2 インスタンス(t3.micro)を起動し、stress-ng で CPU 負荷をかけて CloudWatch アラームを発火させた。その後、Web App の Chat 経由で調査を依頼した。
なお、今回の検証では CloudWatch アラームが発火しても DevOps Agent が自動的に調査を開始しなかった。ドキュメントによると、PagerDuty との連携では PagerDuty アラートをトリガーとした自動調査が可能である。今回は最小構成のため、手動で Chat から調査を依頼する方式で検証した。
また、検証 1 のトポロジー構築(約20分)が完了してから検証 2 に進むことを推奨する。ドキュメントではトポロジーが調査時のリソース関係の理解に使われると説明されており、未構築の状態では調査精度に影響する可能性がある(今回はトポロジー構築完了後に検証を実施したため、未構築時との比較は行っていない)。
EC2 インスタンス起動・stress テスト・アラーム設定
検証 1 で設定した $REGION、$ACCOUNT_ID をそのまま使用する。デフォルト VPC が存在する環境を前提としている。
AMI_ID=$(aws ssm get-parameters \
--names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
--query "Parameters[0].Value" --output text --region $REGION)
SG_ID=$(aws ec2 create-security-group \
--group-name devops-agent-verification \
--description "SG for DevOps Agent verification" \
--region $REGION --query "GroupId" --output text)
INSTANCE_ID=$(aws ec2 run-instances \
--image-id $AMI_ID --instance-type t3.micro \
--security-group-ids $SG_ID \
--tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=devops-agent-stress-test}]" \
--region $REGION --query "Instances[0].InstanceId" --output text)
aws ec2 wait instance-running --instance-ids $INSTANCE_ID --region $REGION
aws cloudwatch put-metric-alarm \
--alarm-name "devops-agent-verification-high-cpu" \
--metric-name CPUUtilization --namespace AWS/EC2 \
--statistic Average --period 60 --threshold 80 \
--comparison-operator GreaterThanThreshold --evaluation-periods 1 \
--dimensions "Name=InstanceId,Value=${INSTANCE_ID}" \
--region $REGION# SSM Agent がオンラインになるまで待機(15〜30秒程度)
while true; do
STATUS=$(aws ssm describe-instance-information \
--filters "Key=InstanceIds,Values=${INSTANCE_ID}" \
--query "InstanceInformationList[0].PingStatus" \
--output text --region $REGION 2>/dev/null)
[ "$STATUS" = "Online" ] && break
echo "Waiting for SSM Agent..." && sleep 10
done
# stress-ng で CPU 負荷をかける(10分間)
aws ssm send-command \
--instance-ids $INSTANCE_ID \
--document-name "AWS-RunShellScript" \
--parameters '{"commands":["sudo dnf install -y stress-ng","nohup stress-ng --cpu 2 --timeout 600 &"]}' \
--region $REGION# CloudWatch メトリクスの反映に2〜5分かかる
while true; do
STATE=$(aws cloudwatch describe-alarms \
--alarm-names "devops-agent-verification-high-cpu" \
--query "MetricAlarms[0].StateValue" --output text \
--region $REGION)
echo "Alarm state: $STATE"
[ "$STATE" = "ALARM" ] && break
sleep 60
done調査の依頼
アラームが ALARM 状態になったら、AWS マネジメントコンソールの DevOps Agent ページから エージェントスペース を選択し、「オペレーターアクセス」ボタンで Web App を開く。Chat 画面で自然言語で質問を入力すればよい。
「高 CPU 使用率アラームについて、原因を調査して根本原因を特定してください」と依頼すると、DevOps Agent は即座に 調査タスクを作成し、以下の4つのサブタスクを並列実行した。
| サブタスク | 内容 |
|---|---|
| analyze-cpu-metrics | CPUUtilization / CreditUsage / CreditBalance の推移分析 |
| analyze-network-metrics | NetworkIn / NetworkOut の相関分析 |
| investigate-infrastructure-changes | CloudTrail イベントの調査 |
| check-instance-logs | コンソール出力・SSM コマンド履歴の確認 |
調査結果
調査開始から完了まで約4分25秒。エージェントが特定した根本原因:
インスタンス i-0123456789abcdef0 で 2026-04-01 00:42:09 UTC に Systems Manager 経由で
stress-ng --cpu 2 --timeout 600コマンドが実行された。t3.micro の2 vCPU を stress-ng が完全に使用していることが、100% の CPU 使用率の直接的な原因である。
CloudTrail から SSM SendCommand イベントを検出し、コマンド ID まで特定している。さらに付加的な分析として、CPU クレジット枯渇(サープラスクレジット24.45累積)の検出、ネットワークトラフィックとの時間的相関の分析、インスタンス起動からアラーム発火までのタイムライン構築が行われた。
意図的に仕込んだ原因を正確に特定できた点は評価できる。ただし、これは比較的シンプルなシナリオである。実際の本番環境では複数の要因が絡むため、調査精度は環境の複雑さに依存するだろう。
検証 3: Chat の汎用的な質問対応力
検証 2 でインシデント調査の能力は確認できた。次に、日常的なオペレーション業務で使えるかを4つの質問で検証した。
Q1: 「ap-northeast-1 で現在 ALARM 状態の CloudWatch アラームを教えて」
正確 ✅ — アラーム名、対象インスタンス ID、CPU 使用率(99.997%)、閾値、発火時刻まで正確に報告した。
ただし注意点がある。最初の質問ではリージョンを指定しなかったため、エージェントが13リージョンを順番にスキャンした。たまたまアラームが OK に戻った後のタイミングで ap-northeast-1 をチェックしたため「アラームなし」と誤報告した。リージョンを明示的に指定した2回目で正確に検出できた。Chat への質問はリージョンを明示的に指定すべきである。
Q2: 「EC2 インスタンスの一覧と状態を教えて」
正確 ✅ — 4つのインスタンスすべてを列挙し、インスタンスタイプ、起動日時、AZ、IP アドレス、VPC まで報告した。EKS ノードには「EKS クラスター名」「ノードプール名」まで付記されており、タグ情報を適切に解釈していた。応答時間は19秒。単純なリソース一覧でも、タグやメタデータを解釈して文脈を付加してくれる点は、AWS CLI の生出力より読みやすい。
Q3: 「セキュリティ上の懸念点はあるか」
実用的 ✅ — アカウント全体をスキャンし、RDS の公開アクセス設定(4つの Aurora MySQL)、MFA 未設定、暗号化されていない EBS ボリューム、EC2 のパブリック IP、Security Hub 未有効化、VPC フローログの不足を検出した。優先度付きのアクションリスト(「今すぐ」「今週」「今月」)まで提示された。GuardDuty の有効化や S3 暗号化など良好な点も併記されていた。応答時間は2分45秒。Security Hub の代替ではないが、「まず何から手をつけるべきか」の初期トリアージとしては十分実用的だ。
Q4: 「CPU 使用率が高いインスタンスのスケーリング戦略を提案して」
実用的 ✅ — t3.micro の CPU クレジットモデルを理解した上で、垂直スケーリング(c7a.large、月額コスト比較テーブル付き)、Spot インスタンス(70% コスト削減)、水平スケーリング(Auto Scaling Group、構成図付き)の3つの戦略を提案した。応答時間は3分7秒。各戦略に「どのようなワークロードに向いているか」の判断基準が付いており、読者がそのまま意思決定に使える形式だった。
Chat 応答時間まとめ
| 質問タイプ | 応答時間 |
|---|---|
| リソース状態の確認(Q1, Q2) | 19〜36秒 |
| セキュリティ分析(Q3) | 2分45秒 |
| アーキテクチャ提案(Q4) | 3分7秒 |
| インシデント調査(検証 2) | 約4分25秒 |
事実確認系は30秒前後、分析・提案系は3分前後だった。サンプル数が少ないため一般化はできないが、質問の複雑さに応じて応答時間が変わる傾向は見て取れる。
まとめ — どのようなチームに向いているか
| 観点 | 計測結果 | 評価 |
|---|---|---|
| セットアップ(CLI) | 66秒(IAM ロール〜オペレーターアクセス有効化) | ◎ |
| トポロジー構築 | 約20分(自動・バックグラウンド) | ○ |
| インシデント調査 | 4分25秒で根本原因を正確に特定 | ◎ |
| Chat(事実確認) | 正確、19〜36秒 | ◎ |
| Chat(分析・提案) | 実用的、2〜3分 | ○ |
| 日本語対応 | locale 設定で全応答が日本語 | ◎ |
- 最小構成でも実用的 — 単一アカウント + CloudWatch のみの構成でも、インシデント調査は根本原因まで正確に特定できた。外部監視ツールを追加した場合の精度向上は今回未検証だが、まずは CloudWatch だけで始められる
- CLI 完結のセットアップが強み — 66秒で エージェントスペース が稼働する。IaC(CDK / CloudFormation / Terraform)テンプレートも公式提供されており、組織展開のハードルは低い
- Chat の調査能力は「経験豊富な SRE の初動対応」レベル — CloudTrail・CloudWatch メトリクス・SSM コマンド履歴を横断的に分析し、タイムラインを構築する能力は高い。アプリケーションレベルのログ分析は今回の検証範囲外だが、ドキュメントによると Datadog / Splunk 等との連携でカバーできる
- セキュリティ分析は副次的だが有用 — Security Hub の代替ではないが、「今すぐ対応すべき項目」の優先度付けは実用的だった
クリーンアップ
検証用の EC2 インスタンスとアラームを削除する。エージェントスペース と IAM ロールは続きの検証記事で再利用するため残しておく。
リソース削除手順
# EC2 インスタンス終了
aws ec2 terminate-instances --instance-ids $INSTANCE_ID --region $REGION
aws ec2 wait instance-terminated --instance-ids $INSTANCE_ID --region $REGION
aws ec2 delete-security-group --group-id $SG_ID --region $REGION
# CloudWatch アラーム削除
aws cloudwatch delete-alarms \
--alarm-names "devops-agent-verification-high-cpu" --region $REGIONシリーズの検証がすべて完了した後に エージェントスペース と IAM ロールを削除する場合:
# エージェントスペース 削除
ASSOCIATION_ID=$(aws devops-agent list-associations \
--agent-space-id $AGENT_SPACE_ID \
--region $REGION \
--query "associations[0].associationId" --output text)
aws devops-agent disable-operator-app \
--agent-space-id $AGENT_SPACE_ID --region $REGION
aws devops-agent disassociate-service \
--agent-space-id $AGENT_SPACE_ID \
--association-id $ASSOCIATION_ID --region $REGION
aws devops-agent delete-agent-space \
--agent-space-id $AGENT_SPACE_ID --region $REGION
# IAM ロール削除
aws iam detach-role-policy --role-name DevOpsAgentRole-AgentSpace \
--policy-arn arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy
aws iam delete-role-policy --role-name DevOpsAgentRole-AgentSpace \
--policy-name AllowCreateServiceLinkedRoles
aws iam delete-role --role-name DevOpsAgentRole-AgentSpace
aws iam detach-role-policy --role-name DevOpsAgentRole-WebappAdmin \
--policy-arn arn:aws:iam::aws:policy/AIDevOpsOperatorAppAccessPolicy
aws iam delete-role --role-name DevOpsAgentRole-WebappAdmin