クラウドがよく分かる！お役立ちコラム

AWS DevOps Agentとは？障害対応をAIにどこまで任せられるかを解説

この記事は約13分で読めます。

• #AWS DevOps Agent

AWS DevOps Agentとは

AWS DevOps Agentは、障害対応のうち調査の部分を肩代わりするAIエージェントです。まずは役割と連携先、料金と提供リージョンを押さえておきましょう。

障害の調査を担うAIエージェント

AWS DevOps Agent（日本語名：AWS DevOps エージェント）は、2026年3月31日に一般提供が始まったサービスです。主な役割として以下を持ちます。

• ● インシデントの調査
• ● 原因の特定
• ● 再発防止策の提案

調査では、監視データ（テレメトリ）とアプリケーションのコード、デプロイの履歴を突き合わせます。対象はAWSに限らず、Azureなど他のクラウドやオンプレミスの環境にも及ぶことがポイントです。担当者がチャットで質問し、調べものを頼むことも可能です。

【出典】AWS | AWS DevOps エージェントの一般提供を開始

利用するときは、「エージェントスペース」という単位を作成します。登録するのは、調査対象のAWSアカウントや連携するツールです。1つのエージェントスペースから、アカウント内の全リージョンのリソースを調べられます。

【出典】AWS | Supported Regions – AWS DevOps Agent

連携できる主なツール

AWS DevOps Agentは、すでに使っている監視ツールや開発ツールとつなげられます。一般提供の時点で連携できる主なツールは次のとおりです。

• ● 監視：Amazon CloudWatch、Datadog、Dynatrace、New Relic、Splunk、Grafana
• ● インシデント管理：PagerDuty、ServiceNow
• ● コード管理・CI/CD：GitHub、GitLab、Azure DevOps
• ● チャット：Slack

このほか、MCP（AIと外部ツールをつなぐ共通規格）に対応したサーバーも接続が可能です。チーム独自の調査手順は「スキル」として登録でき、調査に反映されます。

料金と東京リージョンへの対応

AWS DevOps Agentは、一般提供の時点から東京リージョン（ap-northeast-1）に対応しています。調査結果などのデータは、エージェントスペースを作成したリージョンに保存される仕組みです。データを国内に置きたい場合は、東京リージョンで作成するとよいでしょう。

料金は従量課金で、エージェントが実際に作業した秒数に対してかかります。単価は調査、評価、オンデマンドSREタスクのいずれも、1エージェント秒あたり0.0083USDです。待機している時間には料金が発生しません。

1時間に換算すると約29.9USDです。たとえば1件15分の調査を月30件行うと、合計7.5時間で約224USDになります。ログの検索など、ほかのAWSサービスの料金は別途かかる点に注意しましょう。

新規の利用者は、最初の運用タスクから2か月間の無料トライアルを使えます。各月の無料枠は次のとおりです。

• ● エージェントスペース：最大10個
• ● 調査：20時間
• ● 評価：15時間
• ● オンデマンドSREタスク：20時間

有料のAWSサポートプランを契約していれば、毎月クレジットが付与されます。付与額は前月のサポート料金に対し、Unified Operationsで100%、Enterprise Supportで75%、Business Support+で30%です。クレジットは月末で失効し、翌月には繰り越せません。

【出典】AWS | AWS DevOps Agent の料金

一般提供後に追加された主な機能

一般提供の後も、機能の追加が続いています。運用に関わる主なものは次の3つです。

• ● カスタムエージェント（2026年6月）：DBやログの点検など、定型の作業を定期的に実行できる
• ● Slackとの双方向連携（2026年9月）：Slackの非公開チャンネルから、調査の開始や指示ができる
• ● リリース管理（2026年6月、プレビュー）：本番へ出す前のコード変更を評価できる

リリース管理はプレビュー段階の機能です。提供リージョンは米国東部（バージニア北部）のみで、2026年11月時点では東京リージョンで使えません。

障害対応のどこまでをAIに任せられるか

障害対応は、検知・受付から調査、原因特定、対応、再発防止の順に進みます。AWS DevOps Agentが力を発揮する段階と、人の判断が欠かせない段階を順に見ていきましょう。

アラート受信後の初動調査はAIが得意な領域

AWS DevOps Agentは、アラートを受け取ると自動で調査を始められます。起点になるのは、監視ツールのアラートやサポートチケットなどです。夜間や休日でも、担当者が画面を開く前に一次調査が進みます。

調査では、関連するメトリクスやログ、直近のデプロイを横断して確認します。人が複数の画面を行き来して集めていた情報を、エージェントがまとめてくれるわけです。

重複したチケットの整理も、初動で役立つ機能です。同じ障害で複数のチケットが起票された場合、重複を見つけて主となる調査にひも付けます。アラートの数に振り回されず、見るべき事象に集中しやすくなるでしょう。

自動で調査を始めるには、通知元のツールとの連携が必要です。監視のアラートを起点にする場合、検知の質はこれまでどおり監視の設計に左右されます。

最終的には人が障害の原因を確認する

調査が進むと、AWS DevOps Agentは原因の候補を示します。どのデータを確認し、なぜその結論に至ったかは、調査の記録としてたどることが可能です。根拠が見えるため、担当者は一から調べ直さずに検証へ移れます。

例の場合、プレビュー期間の利用者から平均復旧時間（MTTR）が最大75%短縮したとの報告があったと発表しています。ただし、これは利用者の報告をAWSがまとめた数値です。自社の環境で同じ効果が出るとは限りません。

AIが示す原因は、手元のデータから導いた仮説です。データが足りなければ、もっともらしいが誤った結論になることもあります。原因を確定するのは、システムを知る担当者の役割です。検証では、示された根拠のデータを自分の目で確かめましょう。障害の発生時刻と変更の時刻が合っているか、ほかの原因を否定できるかの確認が重要です。

AWS DevOps Agentには、調査結果への評価や修正のフィードバックを受け取る仕組みがあります。受け取った内容は、次の調査に生かされる仕組みです。人が検証して結果を返すことで、短時間で高い精度を得やすくなります。

対応・再発防止はAIが提案し変更は人が承認する

原因の見当がつくと、AWS DevOps Agentは対応の手順を「緩和計画」として提案します。コードのリポジトリを連携していれば、コードの修正案も提示してくれるのです。過去のインシデントの傾向を踏まえて、再発防止の改善策も示されます。

提案した対応をエージェントが実行する機能として、「エージェントアクション」があります。英語ではDirected actionsと呼ばれ、AWSリソースの作成や変更を行える機能です。安全に使うため、次の仕組みが設けられています。

• ● 既定では無効で、エージェントスペースとアカウントごとに明示的な有効化が必要
• ● 承認はチャット内で、対象のツール・操作・リソースを指定して求められる
• ● 自律的な調査の途中で変更操作を呼び出しても、その操作は失敗する
• ● リソースの削除など一部の操作は、承認があっても実行しない

エージェントアクションとして行う変更には、人の承認が必要です。APIからの承認では、1回限りとするか、最大4時間の再利用期間を設けるかを選べます。

なお、自社で接続したMCPサーバーのツールを利用するときは注意すべきです。ツールごとの分類は利用者が設定し、省略すると読み取り専用として扱われます。そして、読み取り専用のツールは、承認なしで実行されてしまうのです。変更を伴うツールは「MUTATIVE」に分類し、承認の対象にしておきましょう。

なお、エージェントアクションがGAかプレビューかは、公式ドキュメントに明記されていません。利用前に最新の提供状況を確認しておきましょう。

再発防止策も同じ考え方です。設計の変更や手順の改訂は、提案を受けて人が採否を決めます。AIが選択肢を出し、人が決めるという役割分担が基本です。Slackと連携していれば、調査の経緯や推奨される対応が同じスレッドに残ります。チームで提案を確認し、誰が何を判断したかを共有しやすくなるでしょう。

AWSの障害管理で人が判断すべき部分

AIの調査や提案がどれほど速くても、人にしか担えない判断は残ります。特に次の2つは、AIに委ねられない領域です。

顧客やビジネスへの影響の判断

障害がどの顧客に、どの程度の影響を与えているかを判断するのは人です。売上への影響やSLA（サービス品質の合意）違反の有無は、システムのデータだけでは決まりません。決済が止まっている場合と管理画面が遅い場合では、同じ障害でも優先度が変わります。

復旧を急ぐか、影響を抑えてから慎重に進めるかも、事業上の判断を伴います。顧客や取引先へ、いつ何を知らせるかも同様です。こうした判断には、契約内容や顧客との関係といった、AIが持たない情報が必要とされます。

想定外の障害と責任の所在に注意

AIが得意な領域は、取得できているデータから異常の傾向を読み取ることです。監視の外で起きた事象や、過去に例のない障害は見落とす可能性があります。外部サービスの障害や、人の操作ミスが絡むケースも注意が必要です。

加えて、責任の所在は人に残ります。エージェントアクションは、エージェントが引き受けたIAMロールで実行される仕組みです。また、AWS CloudTrailの記録から、その操作を承認した担当者までたどれます。AIが提案した変更でも、実行を認めたのは人だという記録が残るわけです。承認者の権限と責任範囲は、組織の運用ルールとして決めておきましょう。

【出典】AWS | Working with directed actions – AWS DevOps Agent

AWS DevOps Agent導入前に押さえたい注意点

AWS DevOps Agentは、有効にすればすぐ成果が出るツールではありません。導入前に、次の4点を整理しておきましょう。

権限設計：エージェントに何を見せ、何を触らせるか

最初に決めるべきは、エージェントに与える権限です。AWSは、エージェントが調査に使うロールと、担当者が操作に使うロールを分けて設計するよう勧めています。組織のSCP（サービスコントロールポリシー）が、必要なAPIを止めていないかも確認しましょう。

エージェントスペースは、オンコールの担当範囲に合わせて分けるのが基本です。本番と本番以外の環境も分けておきます。エージェントアクションを使う場合は、まず読み取りのみで運用し、効果を確かめてから広げると安全です。

監視・runbook・コードリポジトリの整備

AIの調査の精度は、渡すデータの質で決まります。CloudWatchとCloudTrailを基本に、アプリの性能監視ツールやコード管理、CI/CDを連携するほど、原因を絞り込みやすいでしょう。

裏を返せば、監視の設計が甘い環境ではAIも十分な材料を得られません。しきい値が実態に合っていない、そもそも監視していない項目があるといった状態です。AIを活かす前提として、監視そのものの見直しが欠かせません。

チーム固有の手順やエスカレーション先は、runbookとして文書にしておきます。スキルとして登録すれば、エージェントの調査にも反映が可能です。

コストの見積もり

料金は、調査・評価・オンデマンドSREタスクでエージェントが稼働した累積時間で決まります。調査の件数だけでなく、定期実行するカスタムエージェントなどの利用量も見積もりましょう。アラートが多い環境ですべてのアラートを自動調査の対象にすると、費用が想定を超えるかもしれません。自動で調査を始める対象は、重要度の高いアラートに絞るとよいでしょう。

サポートプランのクレジットで、どこまで相殺できるかも確認します。たとえばBusiness Support+で前月のサポート料金が1,000USDなら、クレジットは300USDです。月末で失効するため、利用量の見込みと合わせて考えてください。

精度の検証と運用への組み込み

本番で頼る前に、テスト調査で精度を確かめましょう。AWSのベストプラクティスでは、次の観点で結果を確認するよう勧めています。

• ● 根本原因を正しく特定できたか
• ● 調査に必要なアカウントが漏れていないか
• ● テレメトリが不足していないか

結果に応じて、連携するツールを増やしたり、範囲を調整したりします。導入後も、調査結果を誰が確認し、どの時点で人が引き継ぐかを運用ルールとして決めておきましょう。