はじめに
オンコールでアラートが鳴るたびに、CloudWatch のログを漁り、メトリクスを確認し、原因を特定する——この繰り返し、もう少し楽にならないかと思ったことはありませんか？
re:Invent 2025 で発表された AWS DevOps Agent (Preview) は、まさにその負担を軽減してくれるAIエージェントです。インシデントの自動トリアージ・根本原因分析・修復提案を行い、Amazon CloudWatch をはじめさまざまなツールと連携できます。
本記事では、AWS CDK を使って DevOps Agent の環境を構築し、実際に障害を発生させて調査（Investigation）を開始するところまでを紹介します。
ソースコードは以下のリポジトリで公開しています。
前提条件
- AWS CLI（設定済み）
- Node.js 22+
- pnpm 10+
- AWS CDK CLI
- リージョン: us-east-1 のみ（Preview期間中）
CDKで作成するリソース
DevOps Agent のセットアップに必要なリソースは以下の4つです。aws-cdk-lib に aws_devopsagent モジュールが含まれているため、追加の依存パッケージは不要です。
| リソース | 役割 |
|---|---|
| AgentSpaceRole (IAM Role) | DevOps Agent が CloudWatch、CodeDeploy 等のAWSリソースにアクセスするためのロール。AIOpsAssistantPolicy マネージドポリシー + Support/拡張権限 |
| OperatorAppRole (IAM Role) | DevOps Agent の Web コンソール（Operator App）から操作するためのロール |
| CfnAgentSpace | Agent Space — エージェントの論理的なコンテナ |
| CfnAssociation | AWS アカウントとの連携設定。accountType: "monitor" で監視対象として登録 |
両方の IAM ロールは aidevops.amazonaws.com サービスプリンシパルへの信頼ポリシーを持ち、SourceAccount / SourceArn 条件で自アカウントの Agent Space からのみ AssumeRole できるよう制限しています。
デプロイ
git clone https://github.com/kexi/devops-agent-sandbox.git
cd devops-agent-sandbox
pnpm install
# テンプレート生成で確認
pnpm synth
# デプロイ
pnpm run deploy -- --all --require-approval broadening
デプロイが成功すると、以下の出力が得られます。
✅ DevopsAgentSandboxAgentStack
Outputs:
DevopsAgentSandboxAgentStack.AgentSpaceId = 4b0042d7-xxxx-xxxx-xxxx-xxxxxxxxxxxx
DevopsAgentSandboxAgentStack.AgentSpaceRoleArn = arn:aws:iam::123456789012:role/DevOpsAgentRole-AgentSpace
DevopsAgentSandboxAgentStack.OperatorRoleArn = arn:aws:iam::123456789012:role/DevOpsAgentRole-WebappAdmin
Operator App の有効化
CDK では Operator App の有効化 API が提供されていないため、デプロイ後にスクリプトで実行します。
chmod +x packages/infra/scripts/enable-operator-app.sh
./packages/infra/scripts/enable-operator-app.sh
このスクリプトは以下を自動で行います:
- DevOps Agent CLI モデルの追加（
aws configure add-model） - CloudFormation 出力から AgentSpaceId と OperatorRoleArn を取得
-
aws devopsagent enable-operator-appを実行
Preview 中は --endpoint-url の指定が必要なため、スクリプト内にエンドポイントURLがハードコードされています。
障害を発生させる
デプロイされた Lambda は ?name=error でアクセスすると未処理の UserNotFoundError を throw し、502 を返します。大量のエラーリクエストを投げて CloudWatch にスパイクを作りましょう。
API_URL="https://xxxxxxxxxx.execute-api.us-east-1.amazonaws.com/prod/hello"
for i in $(seq 1 50); do
curl -s -o /dev/null "${API_URL}?name=error" &
curl -s -o /dev/null "${API_URL}?name=fail" &
curl -s -o /dev/null "${API_URL}?name=crash" &
done
wait
CloudWatch で Lambda Errors メトリクスが急増していることを確認できます。
aws cloudwatch get-metric-statistics \
--namespace AWS/Lambda \
--metric-name Errors \
--dimensions Name=FunctionName,Value=<YOUR_FUNCTION_NAME> \
--start-time "$(date -u -v-10M '+%Y-%m-%dT%H:%M:%S')" \
--end-time "$(date -u '+%Y-%m-%dT%H:%M:%S')" \
--period 60 --statistics Sum --region us-east-1
1分間で 84件のエラーが記録されました。
DevOps Agent で調査を開始
AWS コンソールで DevOps Agent を開き、「Start an investigation」をクリックします。
| フィールド | 入力例 |
|---|---|
| Investigation details | Investigate the sudden increase in application error rate. Lambda function is returning 502/500 errors. CloudWatch shows 84+ Lambda errors in a 1-minute window. |
| Investigation starting point | Lambda function: <YOUR_FUNCTION_NAME>, Error pattern: UserNotFoundError and 502 responses |
| Priority | Medium |
Investigation details / starting point フィールドは ASCII文字のみ 対応です。日本語を入力するとバリデーションエラーになります（^[\x09\x0A\x20-\x7E]*$）。
「Start investigating...」をクリックすると、DevOps Agent が自律的に CloudWatch ログの分析、エラーパターンの特定、根本原因の推定を行ってくれます。
しばらく待つと調査が完了し、根本原因が特定されました。handler.ts:24 の UserNotFoundError 例外と null レスポンスがエラーの原因であること、デプロイ後8分で障害が始まったことまで突き止めています。
クリーンアップ
npx cdk destroy --all --region us-east-1
おわりに
AWS DevOps Agent は CDK で手軽にセットアップできます。Operator App の有効化のみ CLI スクリプトか AWS コンソールでの操作が必要ですが、それ以外は cdk deploy 一発で完了します。
Preview 期間中は us-east-1 限定ですが無料で試せるので、まずは手を動かしてみるのがおすすめです。Investigation details が ASCII のみ（日本語不可）という罠には気をつけてください。
実際にインシデントが発生した際にどこまで自動調査してくれるのか、ぜひ試してみてください。