AWS DevOps AgentとBedrockを連携させ、障害一次対応を自動化する

2026.05.28
 Introductionいままで私が関わったWEBシステムでは、よく以下のような運用をしていました。
システムでアラート（CPU・メモリ使用率の超過、ログのエラー等）が上がる
Slack やメールに通知される
通知内容を担当者が見て、ログを確認して原因を調べ、報告・対応する
この「担当者(人)がログを確認する一次調査」部分を、AWS DevOps Agent で自動化してみました。

DevOps Agent は、アラートを起点に CloudWatch やデプロイ履歴を横断調査し、

根本原因と対処案まで出してくれる自律エージェントです（修正の実行よりも、調査と対処案の提示がメイン）。
本記事では、適当なデモシステムを構築し、エラーを発生させてDevOps Agentがどのように動くか確認してみます。

なお、本記事のうち「調査完了 → 対応エージェントへの自動連携」部分のコードは GitHub にあります（Try② の Webhook dispatcher / CloudWatch Alarm / SNS は本文中の抜粋で、リポジトリには含めていません）。
 AWS DevOps Agent?AWS DevOps Agentとは、DevOps/SREエンジニアと同じように

インシデント調査や改善をする自律型エージェントです。

2025年の re:Invent でプレビュー発表され、2026年3月にGAされました。
主な特徴を簡単に紹介します（公式）。
3種のタスク: 自律調査（Investigation）/ 予防（Evaluation）/ オンデマンド（チャット）
調査・提案が中心: 多くのケースで DevOps Agent 自身は修正せず、対処を「緩和計画」や「agent-ready spec」として出力する（※公式の概要には remediation procedure を実行する旨の記述もあり、設定や状況で挙動が異なる）
トポロジ自動構築: CloudFormation/CDK・タグからアプリの構成グラフを自動生成し、調査の土台にする
幅広い統合: CloudWatch  / Slack / カスタム MCP など、いろいろ統合可能
2つのコンソール: 管理コンソールとOperator Web Appが使用可能
料金: agent-second 単位（稼働している秒数のみ課金）
類似機能に CloudWatch investigations もあり、こちらもアラームから自動起動できます。DevOps Agent の違いは、Datadog などのサードパーティツールを横断して調査でき、

外部イベント（Webhook）も起点にできる点です。
GAの概要や全体像は DevelopersIOの解説記事 を参照。
 About Agent Demo わざと発生させるエラー今回は「Amazon Aurora DSQL の1トランザクションあたり3000行以内の更新制限」に引っかかるような処理を行い、

「バッチ件数が増えたタイミングでエラーになった」という、障害を再現して試してみます。
Aurora DSQL のクォータには「1 トランザクションで変更できる行数は最大 3,000 行」という制限があります。

超えると transaction row limit exceeded（code 54000）。
 As-Is / To-BeAs-Is（現状）
  Lambda(エラー) → CloudWatch Alarm → SNS → slack/メール通知 → 【人がログをみて原因究明】

To-Be（DevOps Agent）
  Lambda(エラー) → CloudWatch Alarm → SNS → Webhook → 【Agent が自律調査】→ 根本原因 + 対処案
                                                              │ EventBridge(調査完了)
                                                              ▼
                                                  【対応 Agent】→ トリアージ / Issueドラフト生成 / 通知
 EnvironmentOS: macOS 26.4 (Apple Silicon)
デモアプリ: Node.js
IaC: AWS CDK
DB: Amazon Aurora DSQL
対応エージェント: Strands Agents（Bedrock）を Lambda で実行し、EventBridge で自動起動
DevOps Agent等、リージョンはap-northeast-1を使用。
 Setup 1. DSQL クラスターデモ用アプリのセットアップをします。

AWS CLIでDSQLの作成。
% aws dsql create-cluster --region ap-northeast-1 --no-deletion-protection-enabled
# → identifier と endpoint (<CLUSTER_ID>.dsql.ap-northeast-1.on.aws) を取得
% aws dsql wait cluster-active --identifier "<CLUSTER_ID>" --region ap-northeast-1
 2. デモ用Lambda（1 tx で N 行 INSERT）実行ロールから @aws-sdk/dsql-signer で IAM トークンを生成して pg で接続。

rowCount 行を 1 トランザクションでまとめて INSERT します。
// 実行ロール → DsqlSigner で IAM 認証トークン → pg で TLS 接続（DSQL は TLS 必須）
const token = await new DsqlSigner({ hostname: ENDPOINT, region: REGION })
  .getDbConnectAdminAuthToken();
const client = new Client({ host: ENDPOINT, user: "admin", password: token /* ...ssl 等... */ });
await client.connect();

// rowCount 行を 1 トランザクションでまとめて INSERT
await client.query("BEGIN");
await client.query(`INSERT INTO demo_orders (...) VALUES ${placeholders}`, params);
await client.query("COMMIT"); // rowCount > 3000 でここが transaction row limit exceeded
CDK で Lambda などをまとめてデプロイします（Try② で使う CloudWatch Alarm / SNS は別途追加）。
% cdk deploy
 3. DevOps Agent のオンボーディング公式の CLI onboarding guide どおり、コンソールを使わず CLI で構築できます。
# IAM ロール2種（AgentSpace 用 / Operator App 用）を作成し、
#   AIDevOpsAgentAccessPolicy / AIDevOpsOperatorAppAccessPolicy をアタッチ（手順は公式参照）

# Agent Space 作成
% aws devops-agent create-agent-space --name devops-agent-demo --region ap-northeast-1

# AWS アカウント連携（monitor）。これでトポロジ探索が有効になる
% aws devops-agent associate-service --agent-space-id <ASID> --service-id aws \
    --configuration '{"aws":{"assumableRoleArn":"arn:aws:iam::111122223333:role/DevOpsAgentRole-AgentSpace","accountId":"111122223333","accountType":"monitor"}}' \
    --region ap-northeast-1

# Operator Web App 有効化（IAM 認証）
% aws devops-agent enable-operator-app --agent-space-id <ASID> --auth-flow iam \
    --operator-app-role-arn arn:aws:iam::111122223333:role/DevOpsAgentRole-WebappAdmin --region ap-northeast-1
!補足:

trust policy の aws:SourceArnを zsh の heredoc に書くと $ACCT:agentspace が

修飾子展開で壊れることがあります。${ACCT} と波括弧で囲んで回避しましょう。
 Try : Basic UsageまずはDevOps Agentの動作確認。手動で調査させましょう。
 障害を起こすrowCount=3001 で Lambda を実行するとエラーになります。
% aws lambda invoke --function-name devops-agent-demo-insert \
    --payload '{"rowCount":3001}' --cli-binary-format raw-in-base64-out out.json
% cat out.json
{"errorType":"error","errorMessage":"transaction row limit exceeded","code":"54000", ...}
するとCloudWatch Logs にエラーが記録されます（Try② で CloudWatch Alarm を追加すれば、ここから ALARM 状態に遷移する）。
 調査を起動して結果を取得（CLI）調査の起動は create-backlog-task（taskType: INVESTIGATION）。

※create-chat はチャットセッション作成のみ
% aws devops-agent create-backlog-task --agent-space-id <ASID> --region ap-northeast-1 \
    --task-type INVESTIGATION --priority HIGH \
    --title "Lambda devops-agent-demo-insert is failing" \
    --description "Lambda 'devops-agent-demo-insert' is returning errors. CloudWatch Logs show 'transaction row limit exceeded'. Investigate the root cause and propose a mitigation."
# → taskId と executionId が返る

# 調査ログ・結論を取得
% aws devops-agent list-journal-records --agent-space-id <ASID> --execution-id <EID> --region ap-northeast-1
しばらく待つと調査が完了します。list-journal-records には

調査の進行ログ（仮説・参照した情報・結論）が記録されています。
Operator Web App で見ると次のとおりです。
以下のように、
調査タイムライン — アクセス検証
CloudWatch Logs 取得
transaction row limit exceeded (54000) 発見
100行成功/3001行失敗の比較
と人間の調査手順をそのままなぞっています。
そして、根本原因として

「3,001 行を 1 tx で INSERT → DSQL の 3,000 行/tx 制限超過。原因は 7 分前に CloudFormation/CDK でデプロイされた新コードがバッチ分割を実装していないこと」

と、CloudTrailも確認してデプロイイベントを特定しています。
さらに、緩和計画として「No mitigation action can be identified」。

ロールバック等の運用緩和は無い（リグレッションではなく初回からのコード欠陥）と判断し、

代わりに agent-ready spec（EARS 形式）を生成しています。
THE SYSTEM SHALL implement batch processing ... split large INSERT into multiple transactions of at most 3000 rows ...
THE SYSTEM SHALL add input validation to reject INSERT requests when rowCount exceeds a reasonable maximum ...
今回の構成では「自分で直さず、修正は spec にして人や Kiro に渡す」挙動でした。
もしこれを人がやる場合、

「ログファイル取得→エラーを探す→デプロイ履歴を確認して…」と実施する一次調査が、

アラートから数分で根本原因＋対処案になりました。
 Try: use Webhookさきほどは手動起動（運用者が Agent に調査を依頼）でした。

次はアラートで自動起動します。
 Webhook 作成（コンソール使用）現在CLIに webhook 作成コマンドが無いため、コンソールを使います。
DevOps Agent コンソール→ Agent Space → Capabilities → Webhooks → Add
Webhook作成のステップでURL とシークレットキーを生成します。

発行されたWebhook URLとSecretはその場で保存します。（ファイルダウンロード可能）
 dispatcher LambdaSNS（アラーム）をsubscribeし、CloudWatch Alarm を DevOps Agent の payload に変換、

HMAC-SHA256署名してWebhookにPOSTします。
// SNS → DevOps Agent の payload に変換（incidentId はアラーム単位）
const payload = { eventType: "incident", incidentId: msg.AlarmArn, action: "created", /* ... */ };

//署名してWebhookにPOST
const signature = createHmac("sha256", secret)
  .update(`${timestamp}:${JSON.stringify(payload)}`, "utf8").digest("base64");
await fetch(url, {
  method: "POST",
  headers: { "x-amzn-event-timestamp": timestamp, "x-amzn-event-signature": signature /* ... */ },
  body: JSON.stringify(payload),
});
再度エラーを発生させ、 アラーム → dispatcher が Webhook に POSTさせてみました。

結果、調査が自動作成されました。

ダッシュボードのトリガー列が、手動分は「ユーザー」、自動分は「Event Channel」と分かれているのがわかります。
 Try: Automatic routing to the assigned agentさきほどまでは「調査を起動するまで」の自動化でした。

今度は、調査が出した結論（根本原因＋agent-ready spec）に続く処理

(トリアージや Issue ドラフト生成など)を自動化します。
DevOps Agent は調査のライフサイクルを EventBridge の default bus に流します（source: aws.aidevops）。

Investigation Completed を拾えば、調査完了をトリガーにして任意の処理を実行できます。
//EventBridge イベント。結論の本文は入らず、取得用の ID が入る
{
  "source": "aws.aidevops",
  "detail-type": "Investigation Completed",
  "detail": {
    "metadata": { "agent_space_id": "...", "execution_id": "..." },
    "data": { "status": "COMPLETED", "summary_record_id": "..." }
  }
}
イベントに結論本文は含まれないので、execution_id を使い list-journal-records（recordType=investigation_summary_md）で本文を取得します。
 対応用のエージェント（Strands Agents + Bedrock）今回は EventBridge → Lambda で自動起動にしたいので、

軽量な Strands Agents SDK を使います（Bedrock モデルを利用）。
!補足：

Claude Agent SDK でも可能ですが、Claude Code ランタイムを内包するため

Lambda よりコンテナ（Fargate）向きです。今回は手軽に動作確認したかったのでStrandsを使いました。
EventBridge ルール（CDK）は以下のようにします。
// 調査完了で triage Lambda を起動
const rule = new events.Rule(this, "InvestigationCompletedRule", {
  eventPattern: {
    source: ["aws.aidevops"],
    detailType: ["Investigation Completed"],
    // 自分の Agent Space の調査だけ拾う（同アカウントの他調査では発火させない）
    detail: { metadata: { agent_space_id: [props.agentSpaceId] } },
  },
});
rule.addTarget(new targets.LambdaFunction(triageFn));
Strands Lambda では、 list_journal_records を tool 化し、

エージェントに結果を取得してトリアージさせます。
@tool
def get_investigation_summary(agent_space_id, execution_id) -> str:
    # list_journal_records(recordType="investigation_summary_md") で調査本文を取得
    ...

def handler(event, context):
    meta = event["detail"]["metadata"]  # agent_space_id / execution_id が入る
    agent = Agent(
        model=BedrockModel(model_id="jp.anthropic.claude-haiku-4-5-20251001-v1:0"),
        system_prompt="調査結果を取得し、重大度/担当/次アクション/Issue を日本語で出力せよ",
        tools=[get_investigation_summary])
    print(str(agent(f"execution_id={meta['execution_id']} の調査結果をトリアージして")))
model_id は ap-northeast-1（東京）の推論プロファイル IDです（リージョンにより apac. / us. などの接頭辞が変わります）。
アプリ固有の権限は aidevops:ListJournalRecords と Bedrock 推論（bedrock:InvokeModel 等）が中心です。
ここの作り方次第で自由に処理が可能です。

例えば、githubにPR出したりNotionやGoogleドライブに障害表を起票したりなど、

運用に応じて外部サービスも含めていろいろできます。
 動作確認さきほどと同じ手順で調査を起動し、COMPLETED になった瞬間、

こちらでは何もせずtriage Lambda が自動起動したのを確認しました。

ログの先頭に EventBridge 由来であることが出力されています。
[triage] detail-type=Investigation Completed status=COMPLETED agent_space=<ASID> exec=<EID>
Tool #1: get_investigation_summary
Strands エージェントが tool で調査結果（investigation_summary_md）を取得し、

Bedrockで以下を生成しました。
//CloudWatch Logs 出力・抜粋

## トリアージ結果
### 1. 重大度: CRITICAL（本番の挿入機能が継続失敗）
### 2. 想定担当チーム: バックエンド/Lambda（主）＋ DBアーキ（副）
### 3. 次に取るべきアクション
  1. INSERT を 3,000 行単位のバッチ処理に修正
  2. 暫定: 送信元で 1 回 3,000 行以下に制限
  3. 3,001 行以上で再発しないか検証
### 4. GitHub Issue ドラフト（タイトル＋本文 … 省略）
調査結果（根本原因＋agent-ready spec）を入力に、重大度や対応に関連する情報を自動生成できました。

このAgentでは実装次第でいろいろさせることが可能なので、

実際にAgent SDKをつかってオンデマンドで修正PRを出したり

Twilio で担当者に緊急電話をかけたりなど、要件に応じて柔軟に対応できます。
 Summary「アラートを起点に人がログを確認して一次調査」という運用が、AWS DevOps Agent を使うことで

「アラート → 僅かな時間で根本原因＋対処案」にできました。

手動起動と Webhook 経由の自動起動どちらも動作し、オンボーディングから調査・結果取得まで

ほぼ CLI で完結します（Webhook 作成はコンソール）。
調査では CloudWatch Logs と CloudTrail を横断し、

直近のデプロイとの相関まで特定できました。
今回のデモでは調査完了イベントを EventBridge で受け、

対応エージェント（Strands + Bedrock）でトリアージや Issue ドラフト生成まで自動化できることも確認しています。
DevOps Agent の良いところは、深夜や休日のアラートでも、人が作業する前に

根本原因と対処案が揃っている状態を作れる点です。

一次調査が属人的なスキルに依存しないため情報のフォーマットも揃い、

対応の入り口で迷う時間を減らせます。
さらに対応エージェントを連携させると、例えば調査結果を「重大度・担当・次アクション」というように、

運用に直結する形まで変換できます。

それだけでなく、Claude Agent SDK や Codex CLI（OpenAI API を使った独自エージェント）などを組み合わせれば、

調査結果を元にコード修正や PR 起票まで自動化することも可能です。
DevOps Agent 側を調査、プロジェクト固有の判断や処理は独自に用意したエージェント側で吸収する、

という役割分担が組めるので、いろいろと便利に使えそうです。
 Referencesデモコード（GitHub）
AWS DevOps Agent（公式）
CLI onboarding guide
Invoking DevOps Agent through Webhook
Integrating AWS DevOps Agent with Amazon EventBridge
Strands Agents SDK
Aurora DSQL クォータと制限
aws-samples/sample-aws-devops-agent-cloudwatch
AWS DevOps Agent が GA になりました（DevelopersIO）