AWS re:Inventで発表されたAWS DevOps Agentって何だ？

はじめに

AWS re:Invent 2025で様々なアップデートが紹介されましたが、個人的にはAgentCore関連とAWS Security Agent、そして本記事の内容であるAWS DevOps Agentが推しです。実際に操作しながらどんな機能か検証したいと思います。

ちなみに後述するフロンティアエージェントとして、AWS DevOps Agent、AWS Security AgentとKiro Autonomous Agentの3つがre:Inventで発表されました。

AWS DevOps Agentとは

AWS DevOps Agentは過去に発生したインシデントや運用パターンを分析することで、運用中のインシデントに対応するフロンティアエージェントです。DevOpsという名前の通り、「開発・運用」に焦点を当てたAIエージェントと言えます。現時点ではプレビュー版となっており、バージニア北部リージョンでのみ利用が可能です。

【参考】フロンティアエージェント

フロンティアとは日本語で「最先端」「未開拓の領域」といった意味がありますが、AWSはフロンティアエージェントを「Autonomous, massively scalable AI agents that work for hours without requiring intervention（介入なしで何時間も動作する自律的で大規模にスケール可能なAIエージェント）」と記載しています。

試してみる

準備

まずはブログの通り、意図的にエラーを発生させるLambdaと、エラーが発生したらアラームが発生するCloudFormationでバージニア北部にデプロイします。

今回の検証はコード作成は本質ではないので、コードはKiroに作ってもらいました。

lambda-error-template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Lambda function that intentionally throws an error when invoked'

Resources:
  # Lambda実行ロール
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      RoleName: !Sub '${AWS::StackName}-lambda-role'

  # 意図的にエラーを発生させるLambda関数
  ErrorLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: !Sub '${AWS::StackName}-error-function'
      Runtime: python3.11
      Handler: index.lambda_handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Code:
        ZipFile: |
          def lambda_handler(event, context):
              """
              この関数は呼び出されると必ずエラーを発生させます
              """
              # 意図的にゼロ除算エラーを発生させる
              result = 1 / 0
              return {
                  'statusCode': 200,
                  'body': 'This will never be returned'
              }
      Description: 'Lambda function that intentionally throws a ZeroDivisionError'
      Timeout: 30
      MemorySize: 128

  # Lambda関数のエラーを検知するCloudWatchアラーム
  LambdaErrorAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: !Sub '${AWS::StackName}-lambda-error-alarm'
      AlarmDescription: 'Lambda関数でエラーが発生した際にアラームを発火'
      MetricName: Errors
      Namespace: AWS/Lambda
      Statistic: Sum
      Period: 60
      EvaluationPeriods: 1
      Threshold: 1
      ComparisonOperator: GreaterThanOrEqualToThreshold
      Dimensions:
        - Name: FunctionName
          Value: !Ref ErrorLambdaFunction
      TreatMissingData: notBreaching

Outputs:
  LambdaFunctionArn:
    Description: 'ARN of the error-throwing Lambda function'
    Value: !GetAtt ErrorLambdaFunction.Arn
    Export:
      Name: !Sub '${AWS::StackName}-function-arn'
  
  LambdaFunctionName:
    Description: 'Name of the Lambda function'
    Value: !Ref ErrorLambdaFunction
    Export:
      Name: !Sub '${AWS::StackName}-function-name'
  
  AlarmName:
    Description: 'Name of the CloudWatch Alarm'
    Value: !Ref LambdaErrorAlarm
    Export:
      Name: !Sub '${AWS::StackName}-alarm-name'

AWS CLIでデプロイしました。

aws cloudformation create-stack --stack-name lambda-error-stack --template-body file://lambda-error-template.yaml --capabilities CAPABILITY_NAMED_IAM --region us-east-1

一度実行してみると、想定通りExceptionが出ていることを確認できました。

エージェントスペースの作成

エージェントスペースはDevOps Agentがアクセスできるツールとインフラを定義する論理コンテナで、エージェントスペースごとに独立して動作します。

まずはマネコンから「Begin setup」します。

エージェントスペースの名前を入力します。

他の設定項目も見てみます。

Give this Agent Space AWS resource access

DevOpsエージェントに付与する権限の設定ができます。自動作成、既存ロールから作成、ポリシーテンプレートから新規作成の3つが選択可能です。ドキュメントを参照するとAuto-createが推奨になっていたので、「Auto-create a new DevOps Agent role」で作成します。

Include AWS tags - optional

この項目はオプションですが、エージェントに検知させたいAWSリソースをタグベースで設定することができます。

Enable web app

AWS DevOps Agentではマネコンとは異なるコンソールが提供されるようです。そのコンソールにアクセスするための権限を作成します。ここも自動作成が選択でき、推奨となっているのでAuto-createで進めます。

作成

スペース自体は10秒ほどで作成されました。

トポロジーはしばらく待っても表示されなかったので、試しにタグを設定してみたところトポロジーが表示されました。トポロジーグラフはCloudFormationのInfrastructure Composerと同じようなグラフィックでした。

ドキュメントには下記のような記載があったのですが、何か見逃してるのかもしれません。

By default, all CloudFormation stacks and their resources will be discovered. If your resources were not deployed with CloudFormation, you can have AWS DevOps Agent discover resources with specific AWS tags. See Application Resource Mapping[link] to learn more.

自動で作成されたIAMロールを眺めてみると、「AIOpsAssistantPolicy」というAWSマネージドポリシーと「AIDevOpsAllowAwsSupportActionsPolicy」というカスタマー管理のポリシーが作成されていました。中身をみると、support:CreateCaseの権限が付与されていたので、おそらくアラーム等をトリガーにしてサポートケースを自動で起票するといったことも想定されていそうです。

Web app

Web appタブからWeb app linkがありますので、そこからDevOpsエージェントのコンソールを開いてみます。

アラームを発生させた後、Incident Responseタブから「Latest alarm」というボタンを押すとテンプレートが作成されます。その後、「Start investigation」を押すとエージェントが調査開始します。

トータル10分ほどで調査が完了しました。

エージェントの動作を見ると、下記のような調査をしていました。

• CloudWatch Alarmの発生状況確認
  • 発生している場合は発生日時などの詳細の調査
• アラーム発生の根本原因調査
  • エラー発生前後の呼び出しパターンやリソースの使用状況の確認
    • エラー頻度など
  • Lambdaのデプロイが直近であったか
  • Lambda実行のトリガー（API呼び出し、手動呼び出し、スケジュールなど）

導き出されたアラーム根本原因を確認すると、「意図された例外スローによるLambda関数」となっており、100点回答が得られました。Lambda関数のDescriptionにも意図的に例外をスローする、と書いていたのでこれも判断材料になっていたと思いますが、おそらくLambdaのデプロイが複数回あったり、エラー率に違いがあれば異なる結果になっていたと思います。

「Go to root cause」を押すと、別ページで調査レポートのようなものが出来上がっています。

また、Root causeのページ上部からMitigation Planを生成するボタンもあり、こちらを押すと別タブで内容が生成されます。今回は意図したアラームであることから「やることはないよ！」となっていますが、これが偶発的に発生したものであれば何らかの回避策が提示されるのではないかと思われます。

さらにページ上部から「Ask for human support」を押せばサポートケースの作成もできそうです（Basicサポートプランなのでボタンは押せませんでしたが）。もしかしたらAIエージェントによる調査もサポートに共有されるんですかね。

まとめ

単に直接原因にとどまらず、様々な観点からアラームの原因を調査してくれそうです。また、今回は試していませんが、GitHubやSlackなどといった様々な外部ツールとの連携もできそうなので、より多面的に分析ができそうです。
より複雑なシステムではどうなるかは気になりますが、今後の運用の在り方が変わるようなAIエージェントになるかもしれないサービスになる予感です。

参考