何がサンプルとして固まったか

AWS Machine Learning Blogが公開したAgentWatchは、アンビエントエージェント（ユーザーからの個別要求を待たずに常時稼働するエージェント）をAWS運用監視に適用した参照実装である。中核はAmazon Bedrock AgentCore Runtime上にデプロイされHTTPエンドポイントとして呼び出せる構成で、デフォルト15分間隔（5/10/30/60分に変更可）で複数AWSアカウントを横断し、CloudWatchのメトリクス・ログ・アラームを要約する。出力先はSlackで、定期レポートに加えて自然言語による問い合わせにも応答する。実装一式は`aws-samples`配下のGitHubリポジトリで公開されており、読者は読んで終わりではなく自環境で動かして検証できる。

the solution performs infrastructure checks every 15 minutes, summarizing CloudWatch metrics, logs, and alarms across multiple AWS accounts. The agent delivers actionable reports directly to Slack and responds to natural language queries about your infrastructure state.

HITL3型という設計上の主張

本記事の独自性は技術スタックよりもHuman-in-the-loopの3パターンを明示したことにある。Notify（通知）は人間の承認を求めず事実を伝えるだけ、Question（質問）は判断に迷う場面で人間に問いかける、Review（レビュー）は破壊的アクション前に承認を取る。完全自律と完全手動の二択ではなく、行動の不可逆性に応じて段階的に統制を変える設計指針として読める。これは社内のリスク委員会や監査部門に「なぜAIに本番権限を渡すのか」を説明する際のフレームとしても流用しやすい。

着手時の落とし穴

サンプルをそのまま動かす際の注意点として、15分巡回で複数アカウントのCloudWatchを叩く構成はAPI呼び出し量とBedrock推論コストが監視対象の数とアカウント数で線形に増える。本家ブログには具体的な月額試算は掲載されておらず、PoCではまず単一アカウント・限定リソースで巡回頻度を実測してから拡張する手順が現実的だ。また既存の閾値アラート（CloudWatch Alarms単独やDatadog等）を置き換える発想ではなく、トリアージと要約のレイヤを上に乗せる位置付けで設計するほうが既存運用との衝突が少ない。