この記事の狙い Windows 11への移行や第12世代以降のハイブリッドCPU採用が進む中、企業端末の運用・セキュリティ対応の現場では、「CPU使用率は高くないのに操作が重く見える」「更新・同期・セキュリティ関連のバックグラウンド処理が前面操作に影響しているように見えるが、原因を説明しにくい」といった事象を、従来より丁寧に整理・説明する必要性が高まっています。 特に、セキュリティ対策ソフト、ログ収集、更新適用、同期処理など、業務上必要なバックグラウンド処理がユーザー体感や業務アプリの応答性に影響している可能性がある場合、単にCPU使用率や優先度だけを見ても十分に説明できないことがあ

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 4/14（火）にオンラインセミナー「 これから始める AWS のコンテナサービス活用 」を開催します。Amazon ECS や Amazon EKS をはじめとする AWS のコンテナ関連サービスの全体像をご紹介します。初めてコンテナを利用される方はもちろん、既にご利用中で最新機能をキャッチアップしたい方にもおすすめの内容です。ぜひ事前登録のうえご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年3月30日週の主要なアップデート 3/30(月) AWS Direct Connect が BGP 監視用の CloudWatch メトリクスを追加 AWS Direct Connect で BGP セッションを監視できる CloudWatch メトリクスが 3 つ追加されました。これまでカスタム Lambda 関数やオンプレミスのネットワーク管理ツールが必要だった BGP 監視が、CloudWatch で実現できるようになります。セッション状態やプレフィックス数を追跡し、障害検知や設定変更の検証が可能です。全ての商用リージョンで利用でき、CloudWatch アラームやダッシュボードと統合して Direct Connect の正常性を確認するためのモニタリング環境を構築できます。 Amazon SageMaker Data Agent が Amazon SageMaker Unified Studio Query Editor で利用可能になりました Amazon SageMaker Unified Studio の Query Editor で Data Agent が利用できるようになりました。これまではノートブックでのみ使えていた AI による会話型データ分析機能が SQL 分析ワークフローでも利用が出来るアップデートです。「2025年の製品カテゴリ別四半期売上成長率を計算して」のような自然言語の質問 (英語) から SQL クエリを自動生成し、エラーが発生した際は AI が修正案を提示してくれます。複雑な結合や集計処理を手動で書く必要がなくなり、データ分析の効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Athena が追加リージョンで Capacity Reservations を開始 Amazon Athena で Capacity Reservations が新たに、大阪を含めた 19 のリージョンで利用可能になりました。この機能は Athena の裏側のリソースを一定容量を確保でき、他のクエリの影響を受けずに安定したパフォーマンスを実現しやすくなります。同時実行クエリ数も制御できるため、予測可能な処理時間でデータ分析を行えます。詳細は こちらのドキュメントをご参照ください。 3/31(火) Amazon CloudFront が VPC IPAM 統合を通じて IPv6 の BYOIP をサポート開始 Amazon CloudFront で IPv6 の BYOIP (Bring Your Own IP) がサポートされました。これまでは IPv4 のみでしたが、VPC IPAM を利用して、IPv6 (/48) も BYOIP が利用できるようになりました。これにより、既存の IP アドレス空間を維持したまま CloudFront に移行でき、パートナーや顧客への IP アドレス提供がしやすくなります。セキュリティ強化とネットワーク管理の効率化が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS Outposts での Amazon RDS for Oracle の発表 Amazon RDS for Oracle が AWS Outposts で利用可能になりました。これまでデータ所在地やコンプライアンス要件でクラウド移行が困難だった企業も、Outposts 上で管理された Oracle データベースを利用できます。自動バックアップやパッチ適用、CloudWatch 監視などクラウド同等の機能を提供し、マルチ AZ 配置で高可用性も実現します。詳細は こちらのドキュメントをご参照ください。 AWS Transform custom が自動化されたコードベース分析の一般提供開始 AWS Transform custom で自動コードベース分析機能が一般提供開始しました。Python や Java などの言語で書かれたコードを深く解析し、アーキテクチャや技術的負債を自動でドキュメント化します。これまで手作業で行っていたコードの現状把握や移行計画に役立ち、大規模なモダナイゼーションのための時間を短縮できます。100 万行を超える大規模アプリケーションにも対応し、古いコンポーネントを特定して優先度をつけた改善提案も行います。バージニア北部リージョンとフランクフルトリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon CloudWatch Logs がルックアップクエリコマンドをサポート Amazon CloudWatch Logs Insights で新しい lookup コマンドが利用可能になりました。このコマンドにより、ログに含まれる ID や IP アドレスなどの機械的な文字列を、CSV ファイルから参照した意味のある情報 (顧客名やチーム名など) に変換して、クエリ結果をみやすくできます。これまでは前処理が必要でしたが、クエリ実行時に直接データを結合できるため、ログ分析がやりやすくなります。全商用リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS Backup が Amazon Redshift Serverless のサポートを 7 つのリージョンに拡大 AWS Backup が Amazon Redshift Serverless のサポートを大阪、ハイデラバード、台北、クアラルンプール、オークランド、ミラノ、ケープタウンの 7 つのリージョンに拡張しました。これまでこれらのリージョンでは利用できなかったポリシーベースの自動バックアップ機能が使えるようになり、データウェアハウスの保護と復旧が簡単になります。詳細は こちらの製品ページをご参照ください。 AWS Security Agent オンデマンドペネトレーションテストが一般提供開始 AWS Security Agent のオンデマンドペネトレーションテストが一般提供開始されました。従来は手動で定期的に実施していたセキュリティテストを、AI エージェントが 24 時間 365 日自動実行できるようになり、コストも大幅削減されます。脆弱性の発見から修復提案まで包括的にサポートし、マルチクラウド環境にも対応しています。東京リージョンなど 6 リージョンで利用可能で、2 ヶ月の無料トライアルも提供されます。 AWS Direct Connect が AWS CloudFormation をサポート開始 AWS Direct Connect が AWS CloudFormation に対応しました。これまで手動で構築していた Direct Connect のネットワーク環境を、コードで管理できるようになります。CloudFormation テンプレートで接続設定や仮想インターフェース、Direct Connect ゲートウェイなどを定義し、他の AWS リソースと一緒に自動デプロイが可能です。全リージョンで利用可能で、ネットワーク運用の効率化が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS DevOps Agent が一般提供開始 AWS DevOps Agent が一般提供開始となりました。このサービスは AI を活用して障害の調査や解決を自動化する仕組みです。従来は手動で行っていた障害対応を自動化することで、平均復旧時間 (MTTR) を数時間から数分に短縮できる場合があります。AWS だけでなく Azure やオンプレミス環境にも対応し、カスタムレポート機能やスキル拡張も可能になりました。AWS Support を利用しているお客様には月次クレジットが提供され、多くの場合コストを大幅に削減できます。詳細は こちらの Blog 記事をご参照ください。 Amazon ECS Managed Instances が Amazon EC2 インスタンスストアをサポート Amazon ECS Managed Instances が EC2 instance store ボリュームに対応しました。これまでは Amazon EBS データボリュームを使う必要がありましたが、今回のアップデートで instance store ボリュームを選択できるようになりました。これによりストレージコストの削減と I/O パフォーマンスの向上を実現でき、特にレイテンシに敏感なワークロードでメリットがあります。詳細は こちらのドキュメントをご参照ください。 AWS が End User Messaging Notify を発表 AWS が新サービス AWS End User Messaging Notify を発表しました。従来、ワンタイムパスコード (OTP) の送信には電話番号取得が必要で、時間がかかる場合がありました。新しいサービスの AWS End User Messaging Notify では、AWS が所有する電話番号を利用できるため、素早く実現できるうれしさがあります。 200 以上の国に SMS や音声で OTP を送信でき、詐欺防止機能も標準搭載されています。ブランド名やコード形式のカスタマイズも可能で、利用制限設定により予想外のコスト発生も防げます。詳細は こちらのユーザーガイドをご参照ください。 Amazon S3 Vectors が 17 の追加 AWS リージョンに拡張 Amazon S3 Vectors が新たに 17 リージョンで利用可能になり、合計 31 リージョンで提供開始となりました。S3 Vectors は AI アプリケーション向けのベクトルデータを効率的に格納・検索できるサービスで、従来のベクトルデータベースと異なり S3 の高い可用性と耐久性を活用できます。RAG (検索拡張生成) やセマンティック検索などの AI 用途で、最大 20 億ベクトルを 100 ミリ秒の低レイテンシで処理可能です。詳細は こちらのドキュメントをご参照ください。 Amazon OpenSearch Service がログ分析のためのエージェント AI を導入 Amazon OpenSearch Service で agentic AI 機能が利用開始となりました。従来はログ分析にクエリ言語の習得が必要でしたが、今回のアップデートで自然言語での質問やインシデント調査の自動化が可能になります。チャット機能では PPL クエリを自動生成し、調査エージェントが根本原因分析を自律的に実行して仮説を提示します。会話履歴も保持されるため、継続的な分析作業が効率化されます。追加料金なしで東京リージョンを含む 9 リージョンで提供中です。詳細は こちらのドキュメントをご参照ください。 4/1(水) Oracle Database@AWS が高性能アプリケーション向けにサブミリ秒のネットワークレイテンシを提供開始 Oracle Database@AWS でサブミリ秒のネットワークレイテンシを提供開始しました。支払い処理や証券取引など、低遅延が求められるアプリケーションで特にメリットがあります。EC2 インスタンスの配置を最適化することによってこの仕組みを実現しました。追加料金は不要です。オハイオ、カナダ中部、フランクフルト、ダブリン、東京、シドニーリージョンで利用可能で、今後拡大予定です。詳細は こちらのドキュメントをご参照ください。 Amazon SES Mail Manager がセキュリティ強化とメール処理のための新機能を追加 Amazon SES Mail Manager でセキュリティに関する機能にアップデートがあります。これまで、SES Mail Magaer を利用する際に TLS (STARTTLS) の利用が必要でしたが、TLS の利用がオプションになり、これまで難しかったレガシーシステムから利用しやすくなります。また、クライアント証明書を利用した相互認証の mTLSが利用できるようになりました。中東 (UAE・バーレーン) を除く全リージョンで利用可能です。詳細は こちらをご参照ください。 4/2(木) Amazon WorkSpaces Applications がマルチセッションフリート管理を改善 Amazon WorkSpaces Applications で multi-session fleet のドレインモード機能が追加されました。この機能により、既存のユーザーセッションを中断することなく、新しいセッション受付を停止できるようになります。従来はメンテナンスやアップデート時に、既存のセッションを強制終了する必要がありましたが、今回のアップデートでユーザーの作業を妨げずにシステム管理をしやすくなりました。管理者は計画的にインスタンスを空にでき、新しい接続は他のインスタンスに自動転送されます。詳細は こちらのドキュメントをご参照ください。 Amazon ElastiCache Serverless が IPv6 およびデュアルスタック接続をサポート Amazon ElastiCache Serverless が IPv6 とデュアルスタック接続に対応しました。従来は IPv4 のみでしたが、今回のアップデートで IPv4、IPv6、デュアルスタックの 3 つのネットワークタイプから選択できるようになりました。デュアルスタック接続では IPv4 と IPv6 の両方を同時に利用でき、IPv6 移行時も既存アプリケーションとの互換性を保ちながら段階的な移行が可能です。IPv6 専用サブネットも使用でき、コンプライアンス要件にも対応できます。全 AWS リージョンで追加料金なしで利用可能です。詳細は こちらのドキュメントをご参照ください。 4/3(金) Amazon CloudWatch が Query Studio プレビューで PromQL クエリを導入 Amazon CloudWatch で Query Studio がパブリックプレビューとして提供開始されました。これまで CloudWatch では PromQL クエリが利用できませんでしたが、今回のアップデートで利用できるようになり、PromQL と CloudWatch Metric Insights を統一インターフェースで使用できるようになりました。例えば EC2 上で動作するアプリケーションの OpenTelemetry メトリクスと AWS 標準メトリクスを横並びで分析し、スタック全体の問題を素早く特定できます。バージニア北部、オレゴン、シドニー、シンガポール、アイルランドリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

はじめに 分散ワークロードを運用するチームは、根深い運用上の課題に直面しています。障害が発生した際、解決に必要な情報はログ、デプロイパイプライン、設定変更履歴、サードパーティの監視ツールなど、あちこちに散在しています。深夜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 サポートプランが有効な AWS アカウント (サポート対象のティアについては AWS アカウントチームにお問い合わせください) クロスアカウントオブザーバビリティを設定するための適切な IAM 権限 サポート対象リージョン にデプロイされた AWS サービス Amazon CloudWatch と AWS CloudTrail (デフォルトで有効) 機能強化のための追加 インテグレーション : チケット管理用の ServiceNow 、チーム通知用の Slack 、オンコール管理用の PagerDuty アプリケーション概要 あなたは、AWS 上にデプロイされた URL 短縮サービスを提供する SaaS 企業の SRE です。このアプリケーションは完全な サーバーレスアーキテクチャ を採用しており、ショートコードの作成、元の URL へのリダイレクト、アナリティクスの追跡を行います。 Amazon CloudFront が Amazon S3 バケットから静的アセットを配信 Amazon API Gateway が API リクエストを AWS Lambda 関数にルーティング Amazon DynamoDB が Lambda 関数からアクセスされる 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  の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。