はじめに
分散ワークロードを運用するチームは、根深い運用上の課題に直面しています。障害が発生した際、解決に必要な情報はログ、デプロイパイプライン、設定変更履歴、サードパーティの監視ツールなど、あちこちに散在しています。深夜2時にアラートで呼び出された Site Reliability Engineer (SRE) は、複数のソースからテレメトリを手動で突き合わせ、サービス間の依存関係をトレースし、仮説を立てなければなりません。この作業には通常、数時間を要します。システムの複雑さが増すにつれ、AI を活用した運用チームメンバー、すなわち SRE 支援エージェントの必要性がますます明確になっています。
自前で構築する (DIY) アプローチとその限界
この領域を模索するチームは、まず普段使いの AI コーディングツールを調査中に活用することから始めることが多いでしょう。大規模言語モデル (LLM) に薄くインターフェースを被せただけのツールです。オンコールエンジニアは起床後、インシデントの詳細やチケットを確認し、コーディングツールにログや監視ツールへのアクセスを与えて調査を開始させます。このアプローチは単純なシナリオでは価値を発揮しますが、実際の大規模アプリケーションアーキテクチャでは、複数アカウント、監視システム、アプリケーショントポロジーにまたがるコンテキストの把握、ガバナンスとアクセス制御の適用、過去のインシデントからの学習の蓄積が必要であり、本格的なインシデント管理には力不足です。環境が拡大するにつれ、限られたコンテキストしか持たないシンプルなコーディングツールと、本番環境レベルの運用エージェントとの差は広がる一方です。
フルマネージド型の代替ソリューション
AWS DevOps Agent は、常に利用可能な運用チームメンバーです。インシデントの解決とプロアクティブな予防を行い、アプリケーションの信頼性とパフォーマンスを最適化し、AWS、マルチクラウド、オンプレミス環境にわたるオンデマンド SRE タスクを処理します。DevOps Agent は包括的なエージェント型 SRE パラダイムを提供し、チームをリアクティブな消火活動からAI を活用したプロアクティブな運用改善へと導きます。
では、AWS DevOps Agent はSRE が個人でコーディングエージェントを使う場合と何が違うのでしょうか？この記事では、AWS 上のサーバーレス URL 短縮サービスアプリケーションを例に、DevOps Agent がトポロジーインテリジェンス、3 階層のスキル体系、クロスアカウント調査、継続的学習を基盤として、単純な LLM ラッパーでは再現できない能力を発揮し、平均復旧時間 (MTTR) を数時間から数分に短縮する真の運用チームメンバーとして機能する様子をご紹介します。
前提条件
DevOps Agent を使い始める前に、以下を確認してください。
アプリケーション概要
あなたは、AWS 上にデプロイされた URL 短縮サービスを提供する SaaS 企業の SRE です。このアプリケーションは完全なサーバーレスアーキテクチャを採用しており、ショートコードの作成、元の URL へのリダイレクト、アナリティクスの追跡を行います。
図 1. URL 短縮サービスアプリケーション
このアーキテクチャの構築は簡単ですが、トラブルシューティングは複雑です。リダイレクト関数のレイテンシスパイクは、DynamoDB のスロットリング、Lambda のコールドスタートの劣化、API Gateway の設定変更、CloudFront のキャッシュ無効化など、さまざまな原因が考えられます。しかも、それぞれのシグナルは異なるロググループ、メトリクス名前空間、トレーススパンに存在します。このような状況こそ、DevOps Agent が自律的な運用チームメンバーとしての価値を発揮するポイントです。
調査の実際の流れ
このワークフローでは、DevOps Agent が人間の介入なしにわずか 4分で本番インシデントを自律的に検出・診断する様子を示しています。CloudWatch アラームが 5xx エラーの増加により発報されると、順を追って仮説を検証し、最近のコードデプロイに起因する DynamoDB の書き込みスロットリングを特定します。その後、DevOps Agent は問題のあるコミットを含む完全な根本原因分析と具体的な緩和策の推奨事項 (オンデマンドキャパシティへの切り替えまたはロールバックの提案) を自律的に Slack に投稿します。初回アラームから実行可能な解決策の提示まで、すべてが 5分以内に完了します。
図 2. 論理的な調査ワークフロー
図 3. AWS DevOps Agent の調査ワークフロー: 初期インシデント検出から根本原因分析、実行可能な緩和策の推奨までの自動化フロー
DevOps Agent が異なる理由
DevOps Agent は大規模言語モデルの上にチャットインターフェースを被せたものではありません。Amazon Bedrock AgentCore 上に構築されており、メモリ、ポリシー、評価、オブザーバビリティのための専用インフラストラクチャを備えています。以下では、DevOps Agent を次世代の完全な運用チームメンバーたらしめる 6 つの主要な能力「6 つの C」を解説します。
1. Context (コンテキスト)
運用コンテキストを持たない LLM は、一般的な提案しかできません。DevOps Agent は Agent Spaces によってこの課題を解決します。Agent Spaces は、クラウドリソース、テレメトリソース、コードリポジトリ、CI/CD パイプライン、チケットシステムへのクロスアカウントアクセスを提供する、分離された論理コンテナです。各 Agent Space 内で、DevOps Agent はリソース (コンテナ、ネットワークコンポーネント、ロググループ、アラーム、デプロイメント) を自動検出し、AWS、Azure、オンプレミス環境にまたがる相互接続をマッピングすることで、アプリケーションリソーストポロジーを構築します。バックグラウンドでは学習エージェントが稼働し、インフラストラクチャ、テレメトリ、コードを分析して、推定されたアプリケーションとサービス間のトポロジーを生成します。DevOps Agent は Amazon Elastic Kubernetes Service (EKS) などのサービスとの深い AWS ネイティブインテグレーションを維持しており、パブリックおよびプライベート環境の Kubernetes クラスター、Pod ログ、クラスターイベントへのイントロスペクションを提供します。これは外部ツールにはない特権アクセスを必要とする機能です。DevOps Agent はリソーストポロジーだけでなく、テレメトリ、デプロイタイムライン、インフラストラクチャおよびアプリケーションコードも把握しています。リソース、アラーム、メトリクス、ロググループ間の関係を検出・把握します。レイテンシスパイクを検出すると、GitHub、GitLab、Azure DevOps の最近のマージを自動的にチェックし、デプロイのタイムスタンプとメトリクスの異常を相関させ、コード変更が原因である可能性を判断します。URL 短縮サービスの例では、エージェントは DynamoDB のバッチ書き込みを追加するコミットがスロットリング開始の 47 分前にデプロイされたことを特定します。これは人間の SRE なら発見に 30 分かかってもおかしくない相関です。
URL 短縮サービスの場合、DevOps Agent は CloudFront から API Gateway を経由して各 Lambda 関数、さらに DynamoDB テーブルまでの依存関係チェーンをマッピングします。URL リダイレクト関数でレイテンシスパイクが発生すると、エージェントは関係グラフをトレースして、根本原因が DynamoDB の読み取りスロットリングなのか、Lambda の同時実行数制限なのか、API Gateway のタイムアウト設定なのかを判断します。CloudWatch メトリクス、Lambda トレース、DynamoDB の消費キャパシティを単一の調査で相関させます。
2. Control (制御)
コンテキストだけではガバナンスなしにリスクが生じます。Agent Spaces は、エージェントがアクセスできる範囲と動作方法を一元的に制御します。管理者は、各 Agent Space 内で利用可能な AWS および Azure アカウント、テレメトリおよびコードインテグレーション、MCP サーバーを、きめ細かい IAM 権限を使用して定義します。これにより、個々の開発者が独自のツールチェーンを設定する際の不整合 (徹底的に設定する人、部分的にしか設定しない人、まったく設定しない人) が解消され、新しいチームメンバーのためのアドホックなオンボーディングプロセスも不要になります。すべての推論ステップとアクションは、エージェントが記録後に変更できない不変の監査ジャーナルに記録され、意思決定の完全な透明性を提供します。AWS DevOps Agent は初日からセキュリティが確保されており、すべての推論ステップとツール呼び出しを記録する不変の監査証跡、AWS CloudTrail との統合、きめ細かい権限を持つ IAM Identity Center 認証、調査データを分離し組織のセキュリティ設定を尊重する Agent Space レベルのデータガバナンスを備えています。
URL 短縮サービスの場合、管理者は本番アカウントの CloudWatch ログ、DynamoDB テーブルメトリクス、GitHub リポジトリ、インシデント調整用の Slack チャンネルへの読み取りアクセスを持つ単一の Agent Space を設定します。チームのすべての SRE がこの一貫した制御された設定を継承し、個別のセットアップは不要です。
3. Convenience (利便性)
Agent Space が設定されると、チームのすべての開発者と SRE は、トポロジー、テレメトリ、コードリポジトリ、チケットインテグレーションといったエージェントの完全な運用コンテキストに、追加のセットアップなくすぐにアクセスできます。これは、各エンジニアが個別にコーディングエージェントを CloudWatch、オブザーバビリティツール、ソースリポジトリ、チケットシステムの Model Context Protocol (MCP) サーバーに接続する従来のアプローチとは大きく異なります。実際には、セットアップを完了するエンジニアもいれば、部分的にしか設定しないエンジニアもおり、まったく設定しないエンジニアもいます。結果として、チーム全体でツールの不整合が生じ、新入社員のたびにオンボーディングの負担が発生します。DevOps Agent では、管理者が Agent Space を一度設定すれば、エンジニアはオペレーター Web アプリにログインするか、Slack を通じてやり取りするだけです。エージェントはコンテキストを考慮した応答を提供し、会話履歴を維持し、ユーザーごとのセットアップなしでアプリケーショントポロジーに対する自然言語クエリをサポートします。
URL 短縮サービスチームの場合、オンコールローテーションに新しく参加する SRE は、3 つの Lambda 関数のロググループ、DynamoDB メトリクスダッシュボード、GitHub リポジトリへのアクセスを設定するのに丸一日費やす必要はありません。Agent Space にログインして「この DynamoDB テーブルに接続されているすべての Lambda 関数を表示して」と聞くだけで、トポロジー、テレメトリアクセス、コードコンテキストがすでに揃っています。
図 4. AWS DevOps Agent の MCP サーバーおよびコミュニケーションインテグレーション
図 5. AWS DevOps Agent のテレメトリインテグレーション
図 6. AWS DevOps Agent のマルチクラウドおよびパイプラインインテグレーション
4. Collaboration (コラボレーション)
DevOps Agent は受動的な Q&A ツールではなく、自律的なチームメンバーです。CloudWatch アラーム、PagerDuty アラート、Dynatrace Problem、ServiceNow チケット、または Webhook で設定したその他のイベントソースを通じてインシデントがトリガーされると、エージェントは人間のプロンプトなしに即座に調査を開始します。仮説を生成し、テレメトリおよびコードデータソースにクエリを実行して検証し、コラボレーションチャネル全体で調整を行います。Slack に調査タイムラインを投稿し、ServiceNow チケットを更新し、関係者に調査結果をルーティングします。MCP による拡張性と、CloudWatch、Datadog、Dynatrace、New Relic、Splunk、Grafana、GitHub、GitLab、Azure DevOps との組み込みインテグレーションにより、チームの運用データがどこにあっても、エージェントはシグナルを取得できます。エージェントはまた、週次で予防的な改善提案も行い、最近のインシデントを分析して、コード最適化、オブザーバビリティカバレッジ、インフラストラクチャのレジリエンス、ガバナンスプラクティスにわたる具体的な改善を提案します。さらに、DevOps Agent はより広範なフロンティアエージェントエコシステム内で動作し、調査結果には Kiro が修正を実装するためのエージェント対応の指示を含めることができます。
URL 短縮サービスで深夜3時に DynamoDB スロットリングイベントが発生した場合、DevOps Agent はアラームを検出し、自律的に調査を行い、トラフィックスパイクがテーブルのプロビジョンドキャパシティを超えたことを特定し、緩和策を Slack に投稿します。これらすべてが、オンコールエンジニアがページの内容を読み終える前に完了します。週次の予防評価では、オンデマンドキャパシティモードへの切り替えと、将来のスパイクを早期に検出するための ConsumedWriteCapacityUnits に対する CloudWatch アラームの追加を推奨します。
図 7. AWS DevOps Agent の Slack 調査通知
図 8. AWS DevOps Agent の Ops Backlog における予防推奨
5. Continuous Learning (継続的学習)
ここが AWS DevOps Agent がLLM を薄くラップしただけのツール (LLM ラッパー) と最も明確に差別化されるポイントです。エージェントは洗練された 3 階層のスキル体系を実装しています。
AWS 提供スキル – AWS のエンジニアとサイエンティストが開発した組み込み機能で、実証済みの運用アプローチを反映し、内部で継続的にメンテナンスされています。
ユーザー定義スキル – 組織固有のコンテキストやワークフローに合わせてエージェントをより効果的に動作させるために定義するカスタムスキルです。
学習済みスキル – バックグラウンドで継続的に動作する AWS DevOps Agent の学習サブエージェントは、2 つの重要な機能を実行します。第一に、クラウドインフラストラクチャ、テレメトリデータ、コードリポジトリをスキャンして、アプリケーショントポロジーを継続的に学習・更新します。リソースとその関係を理解し、特定のアラームに関連する重要なログを絞り込むのに役立ちます。第二に、過去の調査を分析してパターンを特定し、将来のトラブルシューティングワークフローを最適化することで、時間とともにより効果的になります。
URL 短縮サービスの場合、DevOps Agent が 1 か月間に 3 件の DynamoDB スロットリングインシデントを解決した後、学習エージェントは繰り返しパターンを特定し、同じクラスの将来の調査を加速する学習済みスキルを生成します。次にスロットリングが発生した際、エージェントは探索的な仮説をスキップし、プロビジョンドキャパシティと消費キャパシティを即座にチェックすることで、調査時間をさらに短縮します。SRE チームはカナリアデプロイプロセスを記述したランブックもアップロードでき、エージェントは最近のデプロイがインシデントと相関するかどうかを評価する際にこれを参照します。
図 9. AWS DevOps Agent のユーザー定義スキルと学習済みスキル
6. Cost Effective (コスト効率)
独自のエージェントを構築することもできますが、消費するモデルトークンの費用はかかります。さらに重要なのは、エージェントとそのインテグレーションの開発、保守、運用を行うチームを配置する必要があることです。基盤モデルの変更に伴い、モデルの品質、レイテンシ、コストを定期的に評価する必要もあります。AWS DevOps Agent では、これらすべてを AWS のエンジニアとサイエンティストのチームが代行します。
DevOps Agent は使用量ベースの料金体系を採用しており、エージェントがタスクに積極的に取り組んでいる時間に対してのみ課金されます。シートごとのライセンス料やアイドルインフラストラクチャのコストはありません。エージェントはマシンスピードで動作し、人間のエンジニアが数時間かかる調査を数分で完了し、実際のアクティブな計算の秒数に対してのみ課金されます。
内部的には、DevOps Agent はコストを削減しながら精度を向上させる大幅なデータ取得最適化を採用しています。ツール全体にわたるクエリ最適化技術により、AWS 固有のアクセスパターンとデータ特性を活用して、大規模データセット全体で最大 15 倍高速なクエリを実現します。これらの最適化により、エージェントは調査ごとの計算消費を抑えながら、より正確な結果を提供します。これは、汎用的な LLM ラッパーでは再現できない、深い AWS インテグレーションの直接的なメリットです。
URL 短縮サービスの場合、SRE が 3 つの Lambda 関数のロググループにわたって CloudWatch Logs Insights を手動でクエリし、DynamoDB メトリクスと相関させるのに 2 時間費やす代わりに、DevOps Agent は最適化されたクエリを使用して同じ調査を数分で完了します。エンジニアリング時間のコストのほんの一部で済みます。
実証済みの実績
プレビューで AWS DevOps Agent を使用しているお客様やパートナーは、MTTR の最大 75% 削減、調査の 80% 高速化、根本原因の特定精度 94%を報告しており、3〜5 倍のインシデント解決速度を実現しています。
Western Governors University(WGU) は、191,000 人以上の学生にサービスを提供する大手オンライン大学であり、Amazon DevOps Agent を本番環境にデプロイした最初の組織の一つです。re:Invent でのプレビュー開始よりも前にデプロイを行いました。大規模な Dynatrace ユーザーである WGU は、DevOps Agent のネイティブ Dynatrace インテグレーションを活用し、Dynatrace Intelligence が問題レコードを自動的にエージェントにルーティングして調査を行い、充実した調査結果を Dynatrace に直接返すことを可能にしています。
最近の本番調査では、WGU の SRE チームが AWS DevOps Agent を使用してサービス中断シナリオを分析し、推定 2 時間の解決時間をわずか 28 分に短縮しました。MTTR が 77% 改善されたことになります。AWS DevOps Agent は AWS Lambda 関数の設定内の根本原因を迅速に特定し、それまで発見されていなかった社内ドキュメントにのみ存在していた重要な運用知識を表面化させました。
Zenchef は、レストランが予約、テーブル運営、デジタルメニュー、決済、ゲストマーケティングを手数料無料の単一システムから管理できるレストランテクノロジープラットフォームです。少数精鋭の DevOps チームが複数のビジネスユニットにわたる複数の本番環境を管理する中、社内ハッカソン中にダウンストリームパートナーに影響する API インテグレーションの問題が浮上しました。エンジニアはイベントに参加しており、監視では問題の方向性を示す重要な兆候は見られませんでした。
ハッカソンからエンジニアを引き抜く代わりに、チームは問題を AWS DevOps Agent に持ち込みました。エージェントは体系的に問題に取り組み、認証を原因から除外し、調査の焦点を Amazon Elastic Container Service (Amazon ECS) のデプロイメントに移し、最終的にデータベース内の認識されない enum 値を新バージョンが処理できなかったコードリグレッションに根本原因をトレースしました。調査全体は 20〜30 分で完了し、手動で行った場合の 1〜2 時間と比較して約 75% の削減となりました。調査結果は担当エンジニアに直接共有されました。
まとめ
AWS DevOps Agent は、アーキテクチャ的に LLM ラッパーとは異なります。そのトポロジーインテリジェンスサービスは AWS サービスの関係をマッピングし、アプリケーションの依存関係を理解します。検証ベースの学習エージェントを備えた 3 階層のスキル体系は、各顧客環境に固有の複合的な運用知識を生み出します。クロスアカウント調査機能、ガバナンス付き自律モデル、不変の監査証跡は、外部ラッパーでは満たせないエンタープライズ要件に対応します。
6 つの C「Context (コンテキスト)、Control (制御)、Convenience (利便性)、Collaboration (コラボレーション)、Continuous Learning (継続的学習)、Cost Effective (コスト効率) 」 はマーケティング上のカテゴリではありません。これらは具体的なエンジニアリング投資を表しています。分離のための Agent Spaces、トポロジー、パフォーマンスのための最適化されたログクエリ、クロスアカウントアクセスのためのフェデレーテッド認証情報管理、そして調査のたびに学習し改善するスキルアーキテクチャです。AWS 上で分散型の複雑なアーキテクチャアプリケーションを運用するすべてのチームにとって、DevOps Agent はインシデント対応の運用負荷を軽減しながら、将来のすべての調査をより迅速かつ正確にする組織的知識を構築します。
始める準備はできましたか？ AWS DevOps Agent ドキュメントでセットアッププロセスを確認し、AWS DevOps Agent ワークショップでハンズオン体験を行い、AWS アカウントチームに連絡して最初の Agent Space を設定してください。
著者について
Tipu Qureshi
Tipu Qureshi は AWS Agentic AI の Senior Principal Technologist で、運用エクセレンスとインシデント対応の自動化に注力しています。AWS のお客様と協力して、レジリエントでオブザーバブルなクラウドアプリケーションと自律的な運用システムを設計しています。
Bill Fine
Bill Fine は AWS の Agentic AI Product Management Leader で、AWS DevOps Agent の製品戦略と顧客エンゲージメントを統括しています。
Joe Alioto
Joe Alioto は、オブザーバビリティと AWS 上の一元化された運用管理に焦点を当てたクラウドオペレーションの World Wide Senior Specialist Solutions Architect です。20 年以上のハンズオン運用エンジニアリングとアーキテクチャの経験を持っています。仕事以外では、家族との時間を楽しみ、新しいテクノロジーの学習や PC ゲームを趣味としています。
Janardhan Molumuri
Janardhan Molumuri は AWS の Principal Technical Leader で、20 年以上のエンジニアリングリーダーシップ経験を持ち、クラウドと AI の導入戦略や生成 AI を含む新興技術についてお客様にアドバイスしています。ソートリーダーシップ、講演、執筆に情熱を持ち、大規模な課題解決のためのテクノロジートレンドの探求を楽しんでいます。
本ブログは 2026 年 3 月 31 日に公開された Leverage Agentic AI for Autonomous Incident Response with AWS DevOps Agent の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。