AWS DevOps Agentで運用の定型をどこまで任せるか — カスタムSREエージェントは何を肩代わりし、何を人間に残すか

AWS運用の現場では、データベースのヘルスチェックやログの異常検知といった定型作業が、毎日のように手を取ります。こうしたSRE（Site Reliability Engineering＝サイト信頼性の維持を担う運用）的な定型を、AIエージェントに任せる選択肢が東京リージョンで今すぐ使えるようになりました。受託でAWS運用を見ることの多い私の感覚では、ここで問われるのは「すべて自動化できるか」ではなく「何を任せ、何を人間に残すか」の線引きです。本記事では AWS DevOps Agent のカスタムSREエージェントとMCP/A2A対応を、運用者が採用を判断できる視点で整理します。

なぜ「エージェントに任せる」話が出てきたか

AWS DevOps Agentは、2026年6月15日に登場した新サービスではありません。元になるサービスは 2026年3月31日にGA（一般提供開始） しており、インシデントを解決・予防し、オンデマンドのSREタスクを AWS・マルチクラウド・オンプレミス横断で処理する「常駐の運用担当」として提供されています。

従来の運用自動化（Runbook、Lambda、しきい値アラートなど）との違いは、判断を含む作業を委譲できる点にあります。DevOps Agentはアプリと依存関係を学習し、可観測性ツール・Runbook・コードリポジトリ・CI/CDパイプラインと連携して、テレメトリ（計測データ）＋コード＋デプロイ情報を相関させます。そのうえで自律的にトリアージ（優先度の切り分け）を行い、迅速な解決へ導きます。公式は、この相関による調査で MTTR（平均復旧時間）を「時間」から「分」へ短縮 すると説明しています。

そして 2026年6月15日の発表は、このGA済みサービスの機能拡張 にあたります。新サービスの登場ではなく、既存サービスに「カスタムSREエージェントの定期実行」と「MCP/A2Aによるヘッドレスアクセス」が加わった、という位置づけで読むのが正確です。

カスタムSREエージェントとは — 何ができるか

今回の拡張の中心は、Agent Spaces 内で独自のエージェントを作り、cadence（定期スケジュール）で実行できる ようになったことです。公式が挙げる例は、運用現場の定型そのものです。

• 毎日のDBヘルスレポート：スロークエリや、チューニングが必要なパラメータを検出する。
• 直近24時間のログレビュー：ログを通読し、異常をフラグ立てするエージェントを常時動かす。

定期実行以外にも、運用品質を高める機能が加わっています。

• incident-skip rules：顧客が定義したルールで、特定のインシデントを除外できる（既知の無害なアラートを抑制するなど）。
• memories＋Git管理の skills：エージェントに記憶を持たせ、知識（skills）をGitで管理して継続的に強化する。
• human labeling＋カスタムダッシュボード：人手でのラベリングと、顧客が作成するダッシュボードで、エージェントが処理したタスクの品質を追跡する。

提供範囲は 東京（ap-northeast-1）を含む11リージョン です。さらに運用上重要なのが、クロスリージョン監視 に対応する点です。DevOps Agentは、Agent Spaceを作成したリージョンに関係なく、どのリージョンのAWSアカウントのリソースも監視・調査できます。アカウントをAgent Spaceに紐づければ、全リージョンのリソースを自動的にディスカバー（発見）します。つまり監視したいすべてのリージョンにAgent Spaceを作る必要はありません。リージョンの選定は、データレジデンシー（データの所在地要件）や運用チームとの近接性、組織のポリシーで決めればよい、という設計です。

MCPとA2A — 「呼ぶ」と「繋ぐ」の役割分担

今回の拡張では、DevOps Agentを MCP（Model Context Protocol）と A2A（Agent-to-Agent）の2つのプロトコルでヘッドレスに利用 できるようになりました。ヘッドレスとは、専用画面を介さず、別のツールやエージェントから機能を呼び出せる形を指します。この2つは似て見えますが、役割が分かれています。

• MCP：開発者が既に使っているツールやIDEから DevOps Agent を呼ぶための窓口です。公式の例では「Kiro power for AWS DevOps Agent」として、IDE（統合開発環境）を離れずに本番ヘルスチェックや問題調査を実行できます。
• A2A：Amazon Bedrock製やサードパーティ製フレームワークで作った自前のサブエージェントを繋ぐための連携です。自作エージェントをA2Aで接続して、DevOps Agentの守備範囲を広げます。

「呼ぶのがMCP、繋ぐのがA2A」と整理すると分かりやすくなります。

観点	MCP	A2A
役割	外部ツール/IDEから DevOps Agent を呼ぶ	自前サブエージェントを繋ぐ
主体	呼び出し元（Kiro・Claude などのツール）	自作エージェント（Bedrock製/3rd-party）
典型ユースケース	IDEを離れず本番ヘルスチェック・問題調査	自前エージェントを接続してDevOps Agentを拡張

サービスエンドポイントは aidevops.<region>.amazonaws.com（HTTPS）です。なお、A2A接続時の認証ハンドシェイクなど実装作法の細部は、公式のWhat’s Newやドキュメントに明記がありません。本記事では「呼ぶ／繋ぐ」の役割までを整理し、具体的な接続手順は公式ドキュメントで確認することをおすすめします。

使いどころと判断 — 何を任せ、何を人間に残すか

ここが採用判断の核心です。DevOps Agentは強力ですが、運用そのものが消えるわけではありません。任せられる領域と、人間に残る領域を分けて考えます。

任せられる（定型・一次対応）

• 毎日のDBヘルスチェックや、24時間のログ異常検知といった定型監視。
• インシデント発生時の一次トリアージと相関調査（テレメトリ・コード・デプロイの突き合わせ）。
• 過去パターンに基づく予防的な改善提案。

人間に残る（判断・責任）

• 誤検知の最終確認：エージェントがフラグ立てした異常が本当に対応すべきものか。
• 権限と変更の承認：本番環境への変更や、強い権限を伴う操作の可否判断。
• 監査と説明責任：なぜその対応を取ったのかを組織・顧客に説明する責務。

定型監視と一次調査を任せて運用者の手を空け、判断と責任は人間が握る——これが現実的な線引きです。自動化を「運用の置き換え」ではなく「運用者の時間の再配分」として捉えると、導入の効果を見積もりやすくなります。

料金 — 秒課金で「働いた分だけ」

料金体系は、運用エージェントとして合理的な設計になっています（以下は公式の参考値。利用前に公式の料金ページで最新値を確認してください）。

• 秒単位課金（per second）：エージェントが運用タスクに実働した累積時間に対して課金されます。前払いコミットなし・アイドル（待機）中は無課金です。
• PAYG（従量）レート：Investigations（インシデント対応）／Evaluations（予防のための信頼性評価）／On-demand SRE tasks（チャット＋カスタムSREエージェント）の3種すべて $0.0083／agent-second です。
• 2ヶ月の無料トライアル：新規顧客は初回の運用タスクから2ヶ月間、各月「10 agent spaces／investigations 20時間／evaluations 15時間／on-demand SREタスク 20時間」まで無料です。超過分とトライアル終了後は標準のPAYGになります。
• AWS Support契約者の月次クレジット：前月のAWS Support請求額に基づき、Unified Operations 100%／Enterprise Support 75%／Business Support+ 30% のクレジットが付きます（クレジットは月末で失効）。

注意したいのは 接続先サービスの料金が別建て になる点です。DevOps Agentに接続して使う他のAWSサービス——たとえば CloudWatch Logs Insights のクエリやトレース取得——は、各サービスの標準料金で課金され、DevOps Agentの料金には含まれません。実コストは「調査回数 × 平均秒数 × 単価 ＋ 接続先サービス料金」で変動するため、規模を仮置きして試算するのが安全です。公式には小規模（月10調査・1 space）で月39.84ドル、アクティブ利用（月80調査＋100チャット）で月343.62ドルという試算例も示されていますが、これらはあくまで規模依存の参考値です。可観測性側のコスト感は CloudWatchのOpenTelemetryメトリクス も、コスト異常の検知は AWS FinOps Agent も併せて押さえておくと、運用全体の費用設計がしやすくなります。

将来像：Release Management（Preview）

DevOps Agentには、配信（delivery）側をカバーする Release Management という別機能も用意されています。リリース準備のコードレビュー（社内標準からの逸脱・依存影響・アクセス制御のチェック、破壊的変更のコミット前の表面化）と、自律的なリリーステストを担うものです。ただし現時点ではPreview・US East（バージニア）のみで、本番運用機能（GA）とは提供段階が異なります。東京で今すぐ使えるのはGA済みの運用機能であり、Release Managementは将来像として頭の片隅に置いておく、という整理が無難です。

まとめ — 定型は任せ、判断は残す

AWS DevOps Agentは、SRE的な定型監視と一次調査を任せられる運用エージェントです。カスタムSREエージェントの定期実行とMCP/A2A対応により、毎日のDBヘルスチェックやログ異常検知をエージェントに委ね、IDEや自前エージェントから呼び出せるようになりました。東京を含む11リージョンでGA済み、料金は秒課金・前払いなしで、働いた分だけのコスト感です。

採用の判断軸はシンプルです。定型監視・一次調査は任せ、誤検知の最終確認・権限・監査・判断は人間に残す。この線引きを前提に、まず無料トライアルで自分の運用に合うかを試すのが現実的な第一歩になります。

SREエージェントを安全に動かす設計では、各ステップの安全策に Bedrock Guardrailsの新API を、A2Aで繋ぐ自前サブエージェントの基盤モデル選びには Bedrock上のGrok を検討できます。AgentCoreで作ったエージェントをA2Aで繋ぐ設計も描けますが、これは公式統合として発表されたものではなく、あくまで設計上の選択肢です（Amazon Bedrock AgentCore は本番化の基盤として参照してください）。生成AIを使う運用基盤を体系的に組む順番は Bedrockで生成AIアプリを本番化する実装地図 にまとめています。料金・提供リージョン・機能の提供段階は流動的なため、導入時は必ず公式の最新情報をご確認ください。