これからのAWS運用に必須？DevOps Agentを使ってみよう！

2025-12-16

エヌデーデーの池ノ上です。

re:Invent 2025のMatt Garmanの基調講演にて「AWS DevOps Agent」がプレビュー公開されました。

本記事では、DevOps Agentを使ってみてわかったことや所感について綴りたいと思います。

Contents

1. DevOps Agentとは？
2. 料金
3. とにかく使ってみよう！
4. 構成イメージ
5. 様々なツールとの統合
6. モデルトレーニングへの入力内容の利用有無
7. 利用されるモデル
8. プレビュー期間中の制約
9. 所感
10. 参考ドキュメント

DevOps Agentとは？

AWS運用においてインシデント調査や改善活動をAI Agentが行ってくれるサービスです。

常時稼働のインシデントトリアージとガイド付き解決
事後対応型の消火活動から先手を打つ運用エクセレンスへ
既存の監視ツール（Dynatrace、New Relic、Datadog、Splunk、CloudWatch）を通じて洞察にアクセス
リソースをインテリジェントにマッピングし、MTTRとアプリケーションの信頼性を向上

料金

プレビュー期間は無料（なんとなくまあまあ高そうな予感・・・）
Agentがアクセスしたサービス側で課金される可能性あり（メトリクスやログクエリを実行する等）
無料期間中にぜひ使ってみましょう！

とにかく使ってみよう！

スペース作成

AWSマネジメントコンソールのDevOps Agentトップ画面はこのような感じで、リージョンはバージニアのみです。FAQ によると、GA前に他のリージョンもサポートされる予定だそうです。

スペース名を入力します。

Agent SpaceがAWSアカウントにアクセスするためのロールを作成します。（プライマリアカウントロール）

Agent SpaceごとにWebアプリが作成されますが、そのWebアプリが利用するためのロールを作成します。（Webアプリロール）

スペース作成自体はすぐに完了します。

トポロジー

スペース作成完了と同時にトポロジーの作成が開始します。先ほど作成したプライマリアカウントロールを利用してAWSアカウントのリソースを読み取ります。

正確には測っていないですが10分以上経過したころに見てみるとリソースが表示されました。その後しばらくの間は画面リロードするとリソース数が増えており、いつ完了したのか、どういったタイミングで変更を検出しに行くのかは不明です。

トポロジーグラフは表示方法がいくつかあります。

・All Resources

・Components

・Container

・System

リソース検出

リソースの検出方法は下記の2つです。

CloudFormationスタック
リソースタグ（Resource Explorer が有効になっている必要あり）

Webアプリ接続手段

Webアプリへの接続手段は2つです。

Identity Centerと連携する
30分限定のセッションで、最初に作成したWebアプリ用のロールを利用する（オペレーターアクセス）

基本はIdentity Centerを利用し、オペレーターアクセスは、DevOps Agent自体の検証や、Identity Center経由でログイン不可となった場合の代替手段として利用するようです。

まずはオペレーターアクセスを利用してみます。

AWSマネジメントコンソールの外部サイトとして「DevOps Agent Webアプリ」の画面が表示されます。

Webアプリのドメインは下記のとおりです。

https://<識別子>.aidevops.global.app.aws/

インシデントレスポンス

インシデントを調査し、根本原因を特定する機能です。

調査開始のトリガーとしては下記の3パターンがあります。

組み込みの統合機能：ServiceNow等のチケットシステムからインシデント調査をトリガーし、結果をチケットシステム側に提供
WebSocket：PagerDutyやGrafanaアラームからインシデント調査をトリガー
手動：DevOps Agent Webアプリからオンデマンド実行

手動で試していきます。

日本語入力はどうでしょうか？

ダメだそうです。（※ドキュメントに現在は英語に対応との記載がありました）

何か問題がおきているかどうかを聞いてみました。

このように、左側に調査のタイムライン、右側にチャットが表示されます。

ブラウザ翻訳するとタイムラインは次のようになります。

漠然とした質問であったため、詳細をヒアリングされました。

思わず日本語で返事をしたら、下記のようなレスポンスになりました。

改めて英語で聞いてみました。（※以降はすべてブラウザ翻訳です）

また質問が返ってきました。

仕方ないので、S3バケットをリストアップするLambda関数を作成し、Lambda用ロールにS3へのアクセス権限が無い状態にして、関数実行しました。
こんなイメージです。

その後、下記のように聞いてみました。

これで調査が動き始めました。

いろんなツール？を使いながら調査を進めています。ツール実行結果の詳細も確認できます。

該当のLambda関数を見つけたそうです。

メトリクスの集計を始めました。

いくつかのメトリクスを確認したのち・・・

あらためて体系的な調査計画を作成するそうです。

いくつかデータを取得したのち、計画を立て始めました。

調査を実行していくそうです。

ログやCloudTrailを調査しています。

Lambdaのロールを確認し、観察を重ね、AccessDeniedのエラーにたどり着きました。

今度はロールの詳細を確認しに行くそうです。

ポリシーの中身をチェックしています。

ついに全体像がわかったとのこと！

根本原因を突き止めました。

予防

インシデント調査全体のパターンを分析し、将来のインシデントを予防するための推奨事項を提供してくれる機能です。この機能はDevOps AgentのWebアプリから手動で実行できます。

下記4つのカテゴリーで推奨事項を提供してくれます。

コードの最適化：アプリケーションコードの品質、パフォーマンス、およびエラー処理を改善するための推奨事項
可観測性：監視、アラート、ログ記録、システムの可視性を強化するための推奨事項
インフラストラクチャ：リソース構成、容量調整、アーキテクチャの回復力を最適化するための推奨事項
ガバナンス：展開プロセス、テスト方法、運用管理を強化するための推奨事項

わたしの環境でとりあえず実行してみたかぎりでは何も検出されませんでした。

Identity Center連携

Identity Centerと連携してみます。

新規ロールを作成します。

Identity Centerで認証を行う場合のWebアプリのURLが発行されました。なお、オペレーターアクセスも引き続き利用可能です（画面左上にあります）。Identity Centerのユーザーまたはグループに対してアクセス権限を付与していきます。

ここでは既存のユーザーまたはグループを選択します。

adminグループに権限を付与してみます。

登録されました。

登録完了すると、下記のようにIdentity Centerのアクセスポータルに表示されるようになります。

ログインは、上記のアクセスポータルか、もしくはIdentity Center接続時に発行された下記のようなURLで直接ログインすることができます。

https://<識別子>.aidevops.global.app.aws/authorizer/login

構成イメージ

AWSアカウントやロール、DevOps Webアプリなどの関係性を図にしてみました。
※設定等から想像して作ったので間違っている可能性があります

Webアプリ用のロールは、オペレーターアクセス用とIdentity Center用の2種類があります。DevOps Agent画面から新規作成した場合のロールの権限は、許可ポリシーは同じで、信頼ポリシーに少し違いがあります。具体的には、Identity Center用の信頼ポリシーにのみ下記のSid「TrustedIdentityPropagation」のステートメントが追加されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "aidevops.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111111111111"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:aidevops:us-east-1:111111111111:agentspace/*"
                }
            }
        },
        {
            "Sid": "TrustedIdentityPropagation",
            "Effect": "Allow",
            "Principal": {
                "Service": "aidevops.amazonaws.com"
            },
            "Action": "sts:SetContext",
            "Condition": {
                "Null": {
                    "sts:RequestContextProviders": "false"
                },
                "ForAllValues:ArnEquals": {
                    "sts:RequestContextProviders": "arn:aws:iam::aws:contextProvider/IdentityCenter"
                }
            }
        }
    ]
}

様々なツールとの統合

運用で使っていくにあたり、下記のようなツールとマネージドに連携できることのメリットは大きいと思いました。

AWS EKS アクセス設定：パブリックとプライベートの両方の EKS 環境の Kubernetes クラスター、ポッドログ、クラスターイベントのイントロスペクションを有効にします。
CI/CD パイプライン統合：GitHub と GitLab パイプラインを接続して、デプロイメントとインシデントを相関させ、調査中にコードの変更を追跡します。
MCP サーバー接続：モデルコンテキストプロトコルを介して外部の観測ツールとカスタム監視システムを接続することで、調査機能を拡張します。
マルチアカウント AWS アクセス：インシデント対応中に組織全体のリソースを調査するためにセカンダリ AWS アカウントを設定します。
テレメトリソースの統合：Datadog、New Relic、Splunk などの監視プラットフォームを接続して、包括的な観測データにアクセスします。
チケットとチャットの統合：ServiceNow、PagerDuty、Slack を接続してインシデント対応ワークフローを自動化し、チームのコラボレーションを可能にします。
Webhook 構成：外部システムが HTTP リクエストを通じて DevOps エージェントの調査を自動的にトリガーできるようにする。

モデルトレーニングへの入力内容の利用有無

入力内容はモデルのトレーニングに利用されません。

利用されるモデル

Bedrockが使われる
具体的なモデルは非公開
パフォーマンス・可用性の最適化のため、米国内の最適なリージョンが自動的に選択される
データはバージニアリージョンで保持
入力、リクエスト、出力は他の米国リージョンで処理される場合がある

プレビュー期間中の制約

スペース：10個
エージェントのインシデント対応時間：20時間
エージェントのインシデント防止時間：10時間
月あたりのチャットメッセージ：1,000 件
インシデント解決調査タスクの同時実行数：3
インシデント予防評価タスクの同時実行数：1

所感

今回使ってみて、AWSにおけるトラブルシューティングのスタンダードになるのでは？と感じました。

多くの人がこのような調査をこれまで何度も行ってきて、今現在も行っているものと思います。障害調査・原因究明は、論理的に・網羅的に調査を進めようと努めても、人力ではなかなか原因にたどり着けないものです。私自身、何時間もしくは数日かけて原因を突き止めたのち、「そんなことか・・・」と思ったことが何度もあります。

FAQ に以下の記述がありますが、少し使ってみただけでこの利点を体感することができました。

DevOps Agent は、運用とワークロードに関するこの深い理解を活用して、MTTR を短縮し、運用の卓越性を高めます。

参考ドキュメント

AWS,技術者向け,機能紹介Agent,AWS,DevOps

Posted by 池ノ上寿志