株式会社スプリックス IT戦略部・SPRIX Enginieering LabPublicationへの投稿
🤖

AWSのマネージドなエージェンティックAIOpsサービスを整理する（2026年4月時点）

いけ
に公開
AWS
SRE
CloudWatch
Bedrock
AIOps
tech

はじめに

「障害対応をほぼ人手介入なしで回したい」——エージェンティックAIOpsの文脈でこのゴールを掲げる組織が増えています。

一方で、自前でLLMエージェント基盤を組むのは現実的ではありません。LLM呼び出しループ・ツール接続・観測・ガードレール・評価までを一から作ると、本業の運用改善に辿り着く前に基盤開発で疲弊します。

そこで本記事では、AWSをメインで使っている組織が、今すぐ検証に入れるマネージド・エージェンティックAIOpsサービスの選択肢を整理します。2026年3月末にAWS DevOps Agentが一般提供開始されたことで、AWS純正でこの領域を始められる状況が一気に整ったタイミングです。

結論：AWSには既に3層でマネージドサービスが揃っている

先に結論から示します。AWSにおけるマネージドなエージェンティックAIOpsの選択肢は、次の3層で整理できます。

層 サービス 位置づけ 2026/4時点のステータス
①使う AWS DevOps Agent 自律的なインシデント対応エージェント本体 GA（2026/3/31）
②使う Amazon CloudWatch Investigations CloudWatchネイティブの生成AI調査アシスタント GA
③作る Amazon Bedrock AgentCore 自作エージェントのランタイム基盤 GA

①は「既製品としてエージェントを使う」アプローチ、③は「自前エージェントをマネージド基盤の上に載せる」アプローチです。②はCloudWatchの中で軽量に始められる調査補助機能で、①の導入前ステップにもなります。

以降、順番に中身を見ていきます。

① AWS DevOps Agent：本命の自律的インシデント対応エージェント

これは何か

AWS DevOps Agentは、AWSが2025年re:Invent時にプレビュー発表し、2026年3月31日に一般提供を開始した、インシデント対応・根本原因分析・再発防止までを目的としたマネージドAIエージェントです。

AWSはこれを frontier agent と呼んでいます。これは「数時間〜数日、常時の人間の介入なしに自律的に動き続けられる、大規模にスケール可能な新世代のAIエージェント」という位置づけです。従来の「アラート→人がトリアージ→人が対応」という流れに対し、DevOps Agentは検知以降の調査と原因推定までをエージェント側で完結させることを狙っています。

アーキテクチャ上の立ち位置

DevOps AgentはAmazon Bedrock AgentCoreをランタイム基盤とする「frontier agent」の一つとして位置づけられています。AgentCoreは2025年10月にGAとなったエージェント向けマネージド基盤で、Runtime（サーバーレス実行環境）・Gateway（既存APIをMCPツール化する層）・Memory（長期/短期メモリ）・Observability（実行トレース） を提供します。DevOps Agentはその上で「インシデント対応ドメイン」に特化したエージェントとして動く、という構造です。

この構成の重要なポイントは、DevOps AgentがマルチベンダーのオブザーバビリティSaaSに最初から対応している点です。CloudWatchだけでなく、Datadog・Dynatrace・New Relic・Splunk と連携できるため、「監視はDatadogだがAWS基盤なので AWS純正エージェントを使いたい」というよくある構成でも導入障壁が低くなっています。

具体的に何をしてくれるのか

インシデント発生時に DevOps Agent が行う動作は次のようなものです。

  1. 運用ツールチェーン全体の自動相関：メトリクス、ログ、直近のデプロイ（GitHub/GitLab）、設定変更、AWS Healthイベントなどを横断的に参照
  2. 根本原因候補の特定：複数の信号から確度の高い原因仮説を生成
  3. 緩和策の推奨：具体的な対処アクションを提案
  4. 過去インシデントとの突き合わせ：再発パターンを検出して再発防止策に繋げる

「検知」の部分は依然としてCloudWatchアラームや外部監視ツールが担い、DevOps Agentは検知直後〜対処提案までの"調査フェーズ"を自律化するのが役割、という整理になります。

連携ポイント

領域 対応サービス
Observability Amazon CloudWatch / Datadog / Dynatrace / New Relic / Splunk
CI/CD（デプロイ履歴の取得） GitHub Actions / GitLab CI/CD
インシデント管理 ServiceNow（組み込み） / PagerDuty等（webhook）

プレビュー期のユーザー実績

AWSのGAアナウンスで言及されている事例は次のような定量効果が報告されています。

  • MTTR 最大 75% 削減
  • 調査時間 80% 短縮
  • 根本原因特定精度 94%
  • Western Governors University：解決時間が「数時間→数分」
  • United Airlines、T-Mobile などが採用

もちろんこれらはAWSの公式発信なので鵜呑みにせず自社環境での検証は必要ですが、一桁パーセントの改善ではなく「桁が変わる」レベルの効果が謳われている点は押さえておく価値があります。

対応リージョン

GA時点で 6リージョンでの提供となっており、そこに Asia Pacific (Tokyo) ap-northeast-1 と Sydney が含まれています。東京リージョンで運用している組織でも、そのまま始められる状況です。

さらに重要な設計ポイントとして、DevOps Agentは**「Agent Space」と呼ばれる単位を対応リージョンに作成すれば、そこから任意のリージョンのAWSリソースを調査・分析できる**構成になっています。全リージョンに Agent Space を立てる必要はなく、マルチリージョン構成でも単一の Agent Space から扱えます。

料金モデル

AWS DevOps Agentは agent-second 課金のモデルです。

  • $0.0083 / agent-second（エージェントが実タスクに費やした秒数に対して課金）
  • 待機・アイドル時間には課金されない
  • Investigations（インシデント対応）、Evaluations（障害予防）、On-Demand SRE タスク（Chat）のすべての用途で同一単価
  • 新規顧客には 2ヶ月の無料トライアル（GA後の初回操作開始から起算）
  • AWS Free Tierにも含まれる
  • AWS Supportプラン加入者は、前月のサポート費用に応じたクレジットが付与される（Unified Operations 100% / Enterprise 75% / Business+ 30%）。クレジットは翌月に繰り越されず、月末で失効する点に注意

注意点として、接続先サービス側の料金は別途発生します。具体的には、CloudWatch Logs Insights クエリや X-Ray トレース取得などは、それぞれのサービスの標準料金で課金されます。PoCのコスト試算時は「DevOps Agent本体の秒数課金」と「接続先の通常課金」の二段構えで考えておく必要があります。

権限設計の注意点（インフラエンジニア視点）

見落とされがちですが、実運用で最初に検討すべきはエージェントに付与するIAMロールの最小権限設計です。

DevOps Agentは CloudWatch、CloudTrail、GitHub/GitLab、ServiceNow など複数のシステムへアクセスしながら調査を行います。これらに対して読み取り権限を渡すのは比較的安全ですが、対処アクションまで任せるフェーズに進む際には、書き込み権限・変更権限の範囲をリソースタグやアカウント境界で明示的に絞り込む設計が必須です。

特に以下の観点は、PoC設計の初期段階で決めておくと後戻りを防げます。

  • 読み取りのみで始めるか、書き込みまで任せるかのフェーズ分け
  • 書き込みを許可する場合のリソース範囲（タグベース or アカウントベース）
  • ロールの信頼ポリシーで DevOps Agent のサービスプリンシパル以外を排除
  • CloudTrailでのエージェントアクションの全量記録と監査

Agentic AIの失敗が「単なる誤判断」で終わらず「不可逆な変更を引き起こす」事故に発展するのを防ぐための、最も基礎的な防御線です。

② Amazon CloudWatch Investigations：CloudWatchネイティブの調査アシスタント

これは何か

Amazon CloudWatch Investigationsは、CloudWatchの画面から直接起動できる生成AI駆動のインシデント調査アシスタントです。旧称「Amazon Q Developer operational investigations」で、現在はCloudWatch側の機能として統合されています。

DevOps Agentとの関係

立ち位置を整理すると、次のようになります。

観点 CloudWatch Investigations AWS DevOps Agent
スコープ CloudWatch中心、AWS環境内 マルチベンダー対応、運用チェーン全体
起動方法 CloudWatchの画面上で明示起動 or アラームで自動起動 より広い範囲で常駐的に動作
得意領域 単発インシデントの初動調査 複雑・長時間の自律調査
始めやすさ セットアップ不要で即試せる PoC前提でセットアップが必要
料金 機能自体は追加料金なし（裏側API課金あり、上限あり） $0.0083/agent-second（新規は2ヶ月無料）

CloudWatch Investigationsは、DevOps Agentに踏み込む前の"入り口"として非常に有効です。CloudWatchを使っている組織なら、新規契約や追加サブスクリプションなしで生成AIによる調査補助を体験できます。

具体的に何ができるか

  • 任意のCloudWatchデータウィジェットで「Investigate」アクションから調査開始
  • CloudWatchアラームを起点に自動で調査を開始する設定も可能
  • 分析対象は広範：CloudWatchテレメトリ、CloudTrailログ、デプロイ情報、リソース構成変更、AWS Healthイベント、X-Rayトレース、CloudWatch Logs Insightsクエリ
  • 自然言語による観察・仮説・根本原因の説明
  • 複数リソースにまたがる仮説の可視化
  • Amazon Nova Sonic（AWSの音声対話用マルチモーダルモデル）と連携した音声インターフェースも提供開始。音声での調査依頼・応答読み上げが可能になります

始めるときの指針

「まずはCloudWatch Investigationsでアラーム自動起動をオンにし、DevOps Agentは並行してPoCを回す」という進め方が現実的です。前者で運用チームがエージェント的な調査フローに慣れつつ、後者でマルチベンダー統合や自律性の高い運用にシフトする、という二段階の導入計画が立てられます。

③ Amazon Bedrock AgentCore：自作する場合のマネージドランタイム

これは何か

Amazon Bedrock AgentCoreは、AIエージェントを本番運用するために必要な共通機能をマネージドで提供するランタイム基盤です。DevOps Agent自身もこの上に構築されています。

AgentCoreが担うのは次のような要素です。

  • メモリ：長期・短期のエージェントメモリ管理
  • ポリシー：エージェントが取れるアクションの制御
  • 評価（Evaluations）：エージェント挙動のリグレッションテスト
  • Observability：エージェントの実行トレース・失敗解析
  • Runtime：長時間実行・状態保持

DevOps Agentで足りない場合の選択肢

「DevOps Agentは便利だが、弊社固有の運用Runbookに沿った独自判断をさせたい」というケースでは、AgentCoreで自作エージェントを組む選択肢が現実的です。

AWSは Multi-agent SRE assistant のリファレンス実装を公開しており、スーパーバイザー＋4つの専門エージェント（Kubernetes担当、ログ担当、メトリクス担当、Runbook担当）という構成例が示されています。ここから派生させて自社環境向けにカスタマイズする、という現実的な出発点があります。

AgentCore Gateway：既存APIをMCPツール化する

AgentCoreの構成要素で特に注目すべきなのが AgentCore Gateway です。これは既存のバックエンドAPI（Kubernetes API、アプリログAPI、メトリクスAPI、運用Runbook API など）を Model Context Protocol（MCP）ツールとしてエージェントに公開するコンポーネントです。

さらにAWSは Amazon CloudWatch MCP server と Application Signals MCP server も提供しており、エージェントからCloudWatchのアラーム操作・メトリクス分析・ログパターン検出などを自然言語経由で呼び出せるようになっています。

図のポイントは、AWS純正のMCPサーバー（CloudWatch / Application Signals）はエージェントから直接呼ぶ一方、自社の既存APIをツール化する場合は AgentCore Gateway を経由する、という役割分担です。

「既製品のDevOps Agent」と「AgentCoreで自作」の使い分けは、標準的なインシデント対応ならDevOps Agent、独自の運用ワークフローが深く絡むならAgentCore自作、というのが現時点のガイドラインになりそうです。

補足：AWS Security Agent も同時期にGA

本記事のスコープ外ですが、2026年4月6日のAWS Weekly Roundupによると、DevOps Agentと並んで AWS Security Agent も一般提供開始しています。セキュリティインシデント対応の自律化についても同じAgentCoreベースのアプローチが広がっており、運用と同様に「セキュリティアラート対応を人手介入なしに」の方向性が見えます。

「障害対応の無人化」と「セキュリティ対応の無人化」は隣接する課題なので、DevOps Agent評価と同時にSecurity Agentも視野に入れておくと、組織全体の自律運用計画が立てやすくなります。

どれをどう選ぶか

ここまでを踏まえた選定ガイドです。

現状スタックで分岐する

現状 推奨ファーストステップ
CloudWatchを監視の中心に使っている CloudWatch Investigations をアラーム自動起動で有効化
DatadogやNew Relic等を使っている AWS DevOps Agent を無料トライアルでPoC
既に独自の運用Runbookが定着している AgentCore で自作エージェントの検証＋DevOps Agentとの比較
まだ何も始めていない まずCloudWatch Investigations（機能自体は追加料金なし）でエージェント的調査に慣れ、次にDevOps Agentの2ヶ月無料トライアルへ進む2段階

評価軸

エージェンティックAIOpsのPoCを評価する際は、次の軸を設計しておくと議論が噛み合いやすくなります。

  • 自動解決率：人手介入を介さず解決まで至ったインシデントの割合
  • 誤った対処の発生率：カスケード障害や誤った復旧を引き起こした件数
  • 調査時間の短縮：アラートから原因特定までのリードタイム
  • 対応可能インシデントの種類：L1（既知障害）／L2（Runbook合成）／L3（未知・複合障害）のどこまでカバーできたか
  • 承認ゲートの運用性：運用フェーズで「可逆な操作は自動・不可逆な操作は承認必須」という切り分けが破綻せず回り続けるか（権限設計そのものは前述の権限設計の注意点を参照）

おわりに

AWSにおけるマネージドなエージェンティックAIOpsの選択肢は、2026年3月末のDevOps Agent GAによって「既製品として使える」「自作基盤として使える」の両面で揃いました。特に DevOps Agent は、マルチベンダー監視ツールとの統合・東京リージョン対応・2ヶ月無料トライアル・秒課金という条件が揃っており、AWS中心の組織にとって最初の検証候補として位置づけやすいサービスです。

一方で、「ほぼ人手介入しない運用」というゴールに到達するには、ツール選定だけではなく、承認ゲートの設計・L1〜L3の自動化階層設計・評価指標の整備といった運用側の設計が不可欠です。マネージドサービスが成熟したことで、これらの運用設計に集中できる環境は整ったとも言えます。

次回は、実際にAWS DevOps Agentを無料トライアルで接続し、単純な障害シナリオを自律対応させる検証ログをお届けする予定です。

参考リンク

AWS DevOps Agent

Amazon CloudWatch Investigations

Amazon Bedrock AgentCore

セキュリティ・運用設計

参考：第三者まとめ

株式会社スプリックス IT戦略部・SPRIX Enginieering Lab
株式会社スプリックス IT戦略部・SPRIX Enginieering LabPublication

教育で世界No.1へ。 スプリックスIT戦略部の公式テックブログです🌸 渋谷本部・長岡ラボの2拠点がワンチームとなり、世界展開する教育サービスを支えています！ 生成AI活用・モダンな技術スタックへの刷新・地方での組織づくりなど、私たちが日々の開発で得た知見と挑戦の記録をオープンに発信します

Discussion