developersIO
AI が自動で障害調査！AWS DevOps Agent を最短 20 分でハンズオンしてみた

AI が自動で障害調査！AWS DevOps Agent を最短 20 分でハンズオンしてみた

話題の AWS DevOps Agent を忙しい方でもすぐ体験できるように、最短 20 分程度でできるハンズオンをご紹介します。
AWSAWS DevOps Agent
2026.04.08

はじめに

クラスメソッドオペレーションズの Shimizu です。

AI エージェントが自動で AWS 環境を調査してくれるサービス「AWS DevOps Agent」が、2026年3月31日についに GA（一般提供開始）となりました。
「なんとなく気になっているけど、忙しくてまだ触っていない」という方も多いのではないでしょうか。

この記事では、忙しい方でもすぐに AWS DevOps Agent を体験できるように、最短 20 分程度でできるハンズオンをやってみました。以下に、その内容をご紹介します！

img-006

やってみた

以下の前提で進めます。

  • AWS アカウントを保有していること
  • IAM で管理者またはそれに相当する権限があること

ハンズオンの手順と所要時間は、以下の通りです。

手順 所要時間
1. エージェントスペースの作成 約 3 分
2. 擬似的な障害を起こすリソースの用意 約 4 分
3. DevOps Agent による障害調査 約 10 分
4. リソースの後片付け 約 3 分

以下に、詳しい手順をご紹介します。

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

AWS DevOps Agent を使い始めるには、まず「エージェントスペース」というリソースを作成します。
プレビュー版ではバージニア北部リージョン（us-east-1）でのみ作成可能でしたが、現在は東京リージョン（ap-northeast-1）でも作成可能になっています。

img-000

DevOps Agent コンソール画面 にアクセスし、左側メニューの「エージェントスペース」を選択して「エージェントスペースを作成」をクリックします。

img-001

エージェントスペース名を入力します。適当で構いませんが、今回は「agent-space-test」とします。エージェントの応答言語は日本語にしたいので「Japanese」を選択します。

img-002

エージェントスペースが AWS 環境を操作するために必要な IAM ロールを設定します。
もし操作を制限したい場合は、事前に用意した IAM ロールの指定も可能ですが、今回は新規作成で進めます。

img-003

続いてエージェントを操作するウェブアプリ画面へのアクセスロールを設定します。
これも任意の IAM ロールを指定可能ですが、今回は新規作成を選択して「作成」をクリックします。

img-004

「created succesfully」のメッセージが表示されればエージェントスペースの作成は完了です。「オペレーターアクセス」をクリックします。

img-005

いつも見慣れた AI チャットのような、シンプルなウェブアプリ画面が立ち上がります。あとからこの画面を操作するので、URL をブックマークしておきます。

img-006

これでエージェントスペースの作成は完了です。

次はエージェントに調査させるための、擬似障害を起こすリソースを用意します。

2. 擬似的な障害を起こすリソースの用意

CloudFormation を利用するため、下記のテンプレート内容を丸ごとコピーしてPC上に拡張子 .yaml で保存します。
ファイル名は適当で構いませんが、今回は「devops-agent-lambda-test.yaml」としておきます。

テンプレートはこちら
AWSTemplateFormatVersion: '2010-09-09'
Description: 'AWS DevOps Agent Lambda Error Rate Test'
Resources:
  LambdaRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: AWS-DevOpsAgent-Lambda-Test-Role
      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

  TestLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: AWS-DevOpsAgent-Error-Test
      Runtime: python3.12
      Handler: index.handler
      Role: !GetAtt LambdaRole.Arn
      Code:
        ZipFile: |
          def handler(event, context):
              raise Exception("DevOps Agent test error - intentional failure")
      Tags:
        - Key: Purpose
          Value: AWS-DevOpsAgent-Testing

  ErrorAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: AWS-DevOpsAgent-Lambda-Error-Test
      AlarmDescription: DevOps Agent test - Lambda error rate alarm
      MetricName: Errors
      Namespace: AWS/Lambda
      Dimensions:
        - Name: FunctionName
          Value: !Ref TestLambda
      Statistic: Sum
      Period: 60
      EvaluationPeriods: 1
      Threshold: 3
      ComparisonOperator: GreaterThanOrEqualToThreshold
      TreatMissingData: notBreaching

.yaml ファイルを保存したら、CloudFormation のコンソール画面 にアクセスして「スタックの作成 > 新しいリソースを使用」をクリックします。

img-007

「テンプレートファイルのアップロード」を選択し、先ほどPC上に保存した .yaml ファイルをアップロードして次に進みます。

img-008

スタック名を入力します。適当で構いませんが、今回は「devops-agent-lambda-test」として次に進みます。

img-009

IAM ロールを作成することに承認のチェックを入れて、次に進みます。

img-010

確認画面では特に何も変更せず「送信」をクリックします。

img-011

2 〜 3 分待つと、3 つのリソースが作成されます。
擬似的にエラーを出す Lambda 関数、エラーを検知する CloudWatch アラーム、Lambda にアタッチする IAM ロールのみのシンプルな内容です。

img-012

これでリソースの作成は完了なので、次は擬似的に障害を起こして、実際に DevOps Agent で調査してみます。

3. DevOps Agent による障害調査

先の手順で作成した Lambda 関数のコンソール画面に移動し、「テスト」を 5 回ほど続けてクリックします。
実行が失敗してエラーとなりますが、意図した通りなので問題ありません。

img-013

次は作成した CloudWatch アラームのコンソール画面へ移動します。
1 〜 2 分待つと、先ほど Lambda 関数で発生させたエラーを検知してアラーム状態に遷移します。

img-014

アラーム状態を確認したら、調査開始です。
先ほどブックマークしておいた DevOps Agent ウェブアプリをブラウザで開き、左側の「インシデントレスポンス」をクリックします。

入力欄が表示されるので「最新のアラーム」を選択し「調査を開始」をクリックします。

img-015

詳細入力欄がポップアップで表示されます。
「調査の詳細」は入力されている文例をそのまま利用します。「調査の出発点」には、先ほどアラーム状態となっていた CloudWatch アラーム名を入力して「調査を開始中」をクリックします。

img-016

すると AI エージェントによる自動調査が開始されるので、あとは進捗状況を眺めるだけです。

入力した CloudWatch アラーム名から、監視先となる Lambda 関数や実行ユーザーを自律的に特定して調査が進み、タイムラインが更新されていきます。

img-017
img-018

5 分ほど待つと、調査が完了したようです。「根本原因に移動」をクリックします。

img-019

アラームが発生した直接の原因から、テスト目的で意図的にエラーを発生させたことまでを特定して、読みやすい自然な日本語でまとめられています。このまま報告書として提出できそうな内容です。

img-020

なお今回は実施しませんが「ヒューマンサポートを依頼」で AWS サポートへの問い合わせ、「緩和計画を生成」ボタンで今後の再発防止策の提案まで、そのまま行えるようになっています。

これで DevOps Agent による調査は完了です。
最後に、今回作成したハンズオン用リソースの後片付けをします。

4. リソースの後片付け

CloudFormation のコンソール画面 にアクセスして今回作成したスタックを選択し、「スタックを削除」で削除します。

img-021

次は DevOps Agent コンソール画面 にアクセスし、今回作成したエージェントスペースの「詳細を表示」をクリックします。

img-022

右上の「アクション > エージェントスペースを削除」で削除できます。

img-023

「deleted successully」のメッセージが表示されたら削除完了です。

img-024

以上でハンズオンは終了です。お疲れさまでした！

さいごに

いかがでしたでしょうか。

筆者は今回初めて AWS DevOps Agent に触れましたが、想像以上に簡単な設定ですぐ始められることに驚きました。

すでに Claude Code 等の AI エージェントで AWS 環境を操作した経験はありましたが、AWS DevOps Agent の場合は外部ツールが要らず AWS コンソール内だけで完結でき、IAM で権限制御できるなど、AWS 環境の障害調査に特化した場合は DevOps Agent を利用するメリットが大きいと感じました。

今回は最小限のハンズオンのみ行いましたが、もっと詳しく知りたい方は参考資料のドキュメントをご覧ください。

なお課金形態がプレビュー版の時と変わっているようなので、料金ドキュメントも事前に確認しましょう。現状ではエージェントスペースを作成するだけでは料金がかかりませんが、実際にエージェントを稼働させた時間や、調査したリソースに応じて課金されるようです。

この記事がどなたかのお役に立てば幸いです！

参考資料

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました

この記事をシェアする

関連記事

深夜2時のアラート対応、AWS DevOps Agent があればどう変わるのか比べてみた
kaz
2026.04.05
AWS DevOps Agent × MCP サーバーでインシデント調査ナレッジを蓄積してみた
kaz
2026.04.01
【レポート】 新サービスAWS DevOps Agent のワークショップ 「[NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agentに参加しました！#AWSreInvent #DVT337
おつまみ
2025.12.04
AWS DevOps Agent で CloudWatch アラームをトリガーに自動インシデント調査を行えるか試してみた #AWSreInvent
Shiina Yuichi
2025.12.10