AWS DevOps Agentで障害対応が3倍速くなる理由

AWS DevOps Agentで障害対応が3倍速くなる理由

最終更新日:2025年12月06日公開日:2025年12月06日
益子 竜与志
writer:益子 竜与志
XThreads

障害発生時、CloudWatchを開いてログを追い、GitHubの変更履歴を確認し、関連サービスのメトリクスをチェックする——この一連の作業、エンジニアなら誰もが経験していると思います。AWS DevOps Agentは、この「障害発生から原因特定までの初動」を自動化してくれる自律型AIエージェントです。今回はプレビュー版を触ってみた所感と、技術的なアーキテクチャについて深掘りしていきます。

そもそもDevOps Agentって何ができるの?

re:Invent 2025で発表されたAWS DevOps Agentは、従来のAmazon Q Developerのような「人間が質問してAIが答える」タイプとは根本的に異なります。CloudWatchアラームが発火したり、GitHubにIssueが作成されたりすると、人間が介入する前に自律的に調査を開始してくれるんです。

実際に使ってみると、障害が起きてSlackに通知が来た時点で、すでにAgentが調査を始めていて「このLambdaのエラーは3時間前のデプロイで追加されたコードが原因っぽいですよ」みたいなレポートが上がってくる。正直、最初は「え、もう調べてくれたの?」という驚きがありました。

アーキテクチャを理解する

DevOps Agentのアーキテクチャは、大きく3つの要素で構成されています。

DevOps Agentアーキテクチャ

まずAgent Spaceという論理的な境界があります。これは「このAgentがどのAWSアカウント、どのリージョン、どのツールにアクセスできるか」を定義するもの。チームごと、アプリケーションごとにSpaceを分けることで、最小権限の原則を守りながら運用できます。

次にDynamic Topology Graph。これがDevOps Agentの賢さの源泉といっても過言ではないです。CloudFormationのスタック情報やタグ、各種APIコールの結果から、Lambda→RDS→VPCといったリソース間の依存関係を自動でマッピングしてくれます。

障害調査で一番時間がかかるのって「この問題、どこから調べればいいんだ?」という部分だと思うんですが、Topology Graphがあることで「このLambdaに関連するRDSのCPU負荷」や「このECSサービスの直近のデプロイ履歴」をAgentが自動で紐付けて調査してくれます。

最後にModel Context Protocol (MCP)。Anthropicが提唱するオープン標準プロトコルで、AWSもこれに参画しています。MCPのおかげで、Datadogや New Relicといったサードパーティの監視ツールとも連携できる。つまり、CloudWatchだけでなく外部のメトリクスも含めて総合的に判断できるわけです。

Model Context Protocol統合

調査ワークフローの実際

実際の調査フローを見てみましょう。

調査ワークフロー
  1. トリガー検知: CloudWatchアラーム、Jiraチケット、Slackメンションなどでエージェントが起動
  2. 情報収集: トポロジーマップを参照し、関連リソースのログ、メトリクス、X-Rayトレースを取得。同時にGitHubの直近コミットやCI/CDのデプロイ履歴もチェック
  3. 相関分析: 「デプロイ時刻とエラー率上昇のタイミングが一致している」「このコミットで変更されたコードとスタックトレースの該当箇所が同じ」といった推論を実行
  4. 復旧案の提示: 具体的なAWS CLIコマンドや操作手順を提案

特に3番目の相関分析が優秀で、「最近何か変えた?」という定番の質問に対する答えを、人間より先に見つけて���れます。

TypeScriptでSlack通知を受け取る実装例

DevOps Agentの調査結果をSlackに通知する仕組みを作ってみました。

import { WebClient } from '@slack/web-api';

interface DevOpsAgentReport {
  incidentId: string;
  severity: 'critical' | 'high' | 'medium' | 'low';
  summary: string;
  rootCause: string;
  affectedResources: string[];
  suggestedActions: string[];
  investigationDuration: number;
}

const slackClient = new WebClient(process.env.SLACK_BOT_TOKEN);

export async function notifyIncidentReport(
  report: DevOpsAgentReport
): Promise<void> {
  const severityEmoji = {
    critical: '🔴',
    high: '🟠', 
    medium: '🟡',
    low: '🟢'
  };

  await slackClient.chat.postMessage({
    channel: '#incidents',
    text: report.summary,
  });
}

このコードでは、DevOps Agentの調査レポートを受け取って、Slackの#incidentsチャンネルに見やすい形式で通知しています。重要度に応じて絵文字を変えたり、推奨アクションを番号付きリストで表示したりと、実運用を意識した実装にしています。

プレビュー版の制限事項

現時点でいくつか制限があるので、導入を検討している方は押さえておいてください。

  • 利用料金: Agent自体は無料だが、CloudWatch LogsのクエリやLambda起動などのインフラコストは発生
  • クォータ: 1アカウントあたりAgent Spaces最大10個、インシデント対応は月間20時間まで
  • リージョン: 管理コンソールはus-east-1のみ。監視対象は全リージョン対応
  • 同時実行: 調査タスクは最大3並列まで

個人的に気になるのはリージョンの制限ですね。東京リージョンでコンソールが使えるようになるのはGA後かなと予想しています。

実際に使ってみて感じたこと

正直、最初は「本当に使えるの?」と半信半疑でした。でも実際に使ってみると、障害対応の「初動」部分での時間短縮効果は明らかです。

特に、複数のサービスが絡み合うマイクロサービス構成では、「どこから調べるか」を決めるのに時間がかかる。DevOps Agentはトポロジーマップを持っているから、この「どこから」の判断が速い。

もちろん、最終的な判断は人間がする必要がありますし、提案された復旧手順をそのまま実行するのは危険な場合もあります。でも「調査レポートの下書き」を作ってくれるだけでも、オンコール対応の精神的負担はかなり軽減されます。

今後、自動復旧(Human-in-the-loopなしでのコマンド実行)の権限委譲がどこまで細かく設定できるようになるかが注目ポイントです。

まとめ

  • DevOps Agentは障害発生時に自律的に調査を開始する新しいタイプのAIエージェント
  • Dynamic Topology Graphによるリソース依存関係の自動マッピングが調査精度の鍵
  • MCPプロトコルでDatadogなどサードパーティツールとも連携可能
  • 現時点ではプレビュー版のため制限あり(us-east-1のみ、月間利用時間制限など)
  • 障害対応の「初動」時間を大幅に短縮できる可能性を秘めている

参考リンク

Careerバナーconsultingバナー