AWS DevOps Agent とは？ ―― 障害対応のデモで見る「調査・是正・レポート化」の実際

システム運用の現場では、障害を「検知する」仕組みはすでに広く整備されています。一方で、そのアラートが「なぜ上がっているのか」を突き止め、影響範囲を見極め、関係者に報告し、再発防止までつなげる一連の作業は、いまも担当者の経験と手作業に大きく依存しているのが実情です。

本記事では、2026年に提供開始されたAWS DevOps Agent を取り上げ、実際のデモ画面を交えながら、障害の発生から調査・是正・復旧確認・レポート化までをどのように支援してくれるのかを解説します。「名前は聞いたことがあるが、実際に何をしてくれるのかイメージが湧かない」という方の参考になれば幸いです。

AWS DevOps Agent は、DevOps 業務を支援する対話型・自律支援型のサービスです。開発・運用の現場で発生する障害について、状況判断や対応案の作成をチャット形式で支援してくれます。役割は大きく次の3つに整理できます。

＜AWS DevOps Agentの役割＞

1. 情報を整理する
   障害の内容、作業履歴、変更内容などを読み取り、要点を分かりやすくまとめます。
   　
2. 判断を支援する
   影響範囲、優先度、確認すべきポイントを整理し、次に取るべき行動を提示します。
   　
3. 対応を標準化する
   属人化しやすい確認手順や報告内容を、再利用しやすい形に整えます。
   　

ここで重要なのは、DevOps Agent が「人の判断を置き換えるもの」ではなく、「判断に必要な情報を素早くそろえる支援役」だという位置づけです。作業者は Agent の提案を確認し、必要に応じて修正・承認したうえで利用します。日々の対応履歴が自然に整理されていくため、チーム全体のナレッジ化を後押しする効果も期待できます。

従来の障害対応には、いくつかの共通した課題がありました。

＜従来の障害対応における課題＞

• 原因調査に必要な 情報が複数の場所に散らばり、確認に時間がかかる
• 経験のある担当者でないと着手点が分からず、初動が属人化 しやすい
• 関係者向けの状況説明や対応履歴、再発防止策の整理が後回しになり、報告作成に時間がかかる
• 連絡・記録・チケット管理など 外部サービスとの連携が個別作業 になりがち
• 確認・要約・報告・振り返りといった 定型作業に工数を取られる

DevOps Agent は、状況の要約、対応手順の提案、報告文の作成、Slack などの外部サービス連携、ナレッジ化までを一貫して支援します。これにより、上記の課題をまとめて軽減できる点が大きな特徴です。

ここからは、デモを用いて実際にAWS DevOps Agentでどんなことができるのかをご紹介したいと思います。

今回のデモでは、利用者がデータを登録するシンプルなアプリケーションを題材にしています。構成は、Amazon API Gateway からのリクエストを AWS Lambda が処理し、Amazon DynamoDB にデータを保存する、というものです。Amazon CloudWatch が API Gateway を監視し、エラーが発生するとアラームを発報します。このアラームを起点に、DevOps Agent が調査から是正対応までを実施する流れになっています。

図1　検証環境の全体構成。API Gateway → Lambda → DynamoDB の処理を CloudWatch が監視し、アラームを起点に DevOps Agent が調査・是正対応を行う。

障害シナリオは、「利用者からデータが登録できないという問い合わせが来た」という、運用の現場でよくある状況からスタートします。あらかじめ Lambda の環境変数に設定誤りを仕込み、意図的に 5xx エラーを発生させたうえで、どのリソースに問題があるかのヒントを与えずに Agent へ調査を依頼しています。

まず「18時40分頃、利用者からデータが登録できないと問い合わせがありました。どのリソースか調査し、解決に向け原因を特定してください」とチャットで依頼します。どのリソースが原因かは伝えていません。Agent は「まず現在時刻を確認してから、その時間帯に何が起きていたかを調査します」と応答し、自律的に調査を開始しました。

図2　リソースのヒントを与えずに調査を依頼すると、Agent が自律的に調査を開始する。

調査の結果、Agent は影響を受けているリソースが Lambda 関数であることを特定しました。根本原因は「Lambda 関数の環境変数の設定ミスにより、すべてのデータ登録処理が AccessDeniedException で失敗している」というものです。さらに、現在の TABLE_NAME の値が誤った名称（末尾が -wrong）であること、本来アクセスすべき正しい DynamoDB テーブル名がどれであるかまで、具体的に指摘してくれました。単に「エラーが出ている」ではなく、設定値のどこが間違っているかまで踏み込んで提示してくれる点が特徴です。

図3　根本原因の特定。環境変数（TABLE_NAME）の設定ミスと、誤り・正しい値を具体的に指摘する。

続けて Agent は、環境変数を誤った値から正しい値へ変更するという解決策を提示します。ここで DevOps Agent には調査内容をもとに根本原因の是正を行うべく、「修正するので、その手順を教えてください」と依頼します。 

図4　解決策の提示。誤った値から正しい値への変更を提案し、修正するか調査を続けるかを尋ねてくる。

すると Agent は、AWS マネジメントコンソールから修正する方法と、AWS CLI から修正する方法の両方を、具体的なコマンド付きで提案してくれました。提案どおりに環境変数を正しい値へ修正します。原因の特定から修正までを、対話しながら短時間で進められることが分かります。

図5　修正手順の提案。マネジメントコンソールと AWS CLI の両方の手順を、コマンド付きで提示する。

修正後、「システム管理者からデータ登録を確認できたと連絡が来た」というシナリオで、実際にリソース側で正常に登録できているかの確認を依頼します。Agent は再度調査を行い、修正前はエラー率が約89%だったのに対し、修正後は実行12回に対してエラー0件・エラー率0%であることを提示しました。数値の裏付けをもって、復旧を確認できています。

図6　修正前後の比較。エラー率が約89%から0%へ改善し、復旧を数値で確認できる。　

対応が完了したら、その一連の流れをレポートに起こし、ナレッジとして蓄積する必要があります。「今回の事象発生から恒久対策案までをまとめてレポート化してください」と依頼すると、Agent はエグゼクティブサマリーを含むレポートをマークダウン形式で自動生成しました。エラー率の推移グラフやインシデントのタイムラインもあわせて整理されます。そのまま最終版として使うわけにはいかないものの、たたき台としては十分な内容で、ローカルにダウンロードして編集することもできます。

図7　インシデントレポートの自動生成。エグゼクティブサマリーを含む報告書をマークダウン形式で出力する。

レポートには、障害の発生から復旧までのエラー率の推移がグラフとして添えられます。エラー率が約89%で推移していた状態から、修正後に一気に0%へ収束していく様子が視覚的に確認できます。

図8　エラー率の推移グラフ。障害発生から復旧までの推移が自動でグラフ化される。

さらに、影響範囲を示すアーキテクチャのトポロジ図を自動で作図してもらうこともできます。API Gateway から Lambda を経由して DynamoDB に至る処理経路や、関連する IAM ロール・CloudWatch アラーム・ログといったリソースの関係が一枚の図に整理され、調査結果を図として素早く共有できます。

図9　影響範囲のトポロジ図。関連リソースの依存関係を Agent が自動で作図する。

一連のデモを通して、DevOps Agent が「障害の発生 → 調査 → 是正 → 復旧確認 → レポート化」までを一貫して支援できることが確認できました。改めて利用メリットを整理すると、以下のようになります。

＜AWS DevOps Agentを導入するメリット＞

1. 初動対応のスピード向上
   必要な情報を素早くそろえて確認漏れを減らす
   　
2. 属人化の低減
   経験に依存しがちな調査観点や報告内容を標準化する
   　
3. 対応品質の向上
   原因候補・是正案・再発防止策を一貫して整理できる
   　
4. ナレッジ化の促進
   そして障害対応の履歴を次回以降に活かせる形で残す

加えて、他の AI サービスを併用することなく AWS 内で完結できる点も、運用面での大きな利点です。

一方で、いきなり Agent に修正まで任せるのではなく、まずは 調査・分析・提案を中心に利用 し、本番環境では人の確認・承認を挟んで安全に運用していくのが現実的です。対応履歴を蓄積して手順やチェックリストに落とし込み、チーム全体で再利用できるナレッジとして育てていく――そうした段階的な導入が、DevOps Agent を無理なく現場に取り入れる近道になりそうです。