こんにちは。Hataです。

今回は先日のre:Inventで発表されたDevOpsエージェントを筆頭に、最近選択肢が増えている障害・インシデント調査の分野で使えるサービスを机上比較してみたので、備忘として記事にします。
比較するサービスは以下の3つのサービスです。

対象サービス

CloudWatch Investigations

CloudWatch Investigationsは、CloudWatchに統合されたAI駆動のアシスタントで、システムインシデントへの対応を支援します。テレメトリーデータをスキャンし、関連するメトリクス、ログ、デプロイイベント、根本原因の仮説を視覚的に提示します。
CloudWatch Investigations(docs.aws.amazon.com)

Amazon Q Developer

Amazon Q Developerは、開発者向けのAI駆動アシスタントで、複雑なワークフローの実行を支援します。CLIとコンソール統合により、運用トラブルシューティング機能を提供します。
Amazon Q Developer(docs.aws.amazon.com)

AWS DevOps Agent

AWS DevOps Agentは、自律型AIエージェントで、インシデント対応の加速とシステム信頼性の向上を支援します。複数の運用ツール間でデータを自動的に相関付け、根本原因を特定し、対象を絞った緩和策を推奨します。
AWS DevOps Agent(docs.aws.amazon.com)

調査開始

今回は調査・比較にAWS Knowledge MCPを使用しました。
*今回初めてKnowledge MCPを使用したので、記念にスクショを添えておきます。

忙しい人向けのサマリ

各ツールの位置づけ

CloudWatch Investigations:
「AWS中心の迅速な調査ツール」

✅ 即座に使える
✅ AWS環境での標準的な調査
✅ 視覚的でわかりやすい

Q Developer:
「開発者のための対話型アシスタント」

✅ コードレベルの詳細調査
✅ 開発者ワークフローに統合
✅ 柔軟な対話型分析

DevOps Agent:
「自律型エンタープライズインシデント対応エージェント」

✅ 24/7自動対応
✅ マルチツール統合
✅ 継続的改善のサイクル

機能比較表

調査結果を表にまとめてくれました！
こうして見ると色々違いがありますね。

機能	CloudWatch Investigations	Q Developer	DevOps Agent
起動方法	CloudWatchコンソール、アラーム、Amazon Qチャット	CLI、コンソール、GitHub統合	手動またはアラート自動起動
設定の必要性	基本機能は不要、拡張機能は要設定	CLI設定のみ	Agent Space設定が必要
自律性	セミオートマティック	対話型	完全自律型
動作時間	セッションベース（24時間自動削除）	インタラクティブセッション	数時間〜数日の長期実行
対応環境	AWS のみ	AWS のみ	AWS、マルチクラウド、ハイブリッド
外部ツール連携	なし	なし	豊富（Datadog、Splunk等）
CI/CD統合	なし	GitHub連携あり	GitHub、GitLab
チケットシステム連携	なし	なし	ServiceNow、PagerDuty
Slack連携	あり（AWS Chatbot経由）	なし	あり（専用インシデントチャネル）
修復実行	Automation Runbook実行可能	ガイド付き修復提案	緩和プランの提供（実装ガイダンス）
クロスアカウント対応	あり	設定次第	あり
対応サービス	16のAWSサービス	AWS全般	AWS全般 + 外部ツール
料金	月150件まで無料	Q Developerサブスクリプション料金に含まれる	プレビュー期間は無料
長期改善提案	なし	なし	あり
インシデント後分析	レポート生成可能	なし	パターン分析と改善提案

ユースケースごとの使い分け

私が一番気になっていたサービスの使い分けについても整理してくれました。

CloudWatch Investigationsが最適なケース

シナリオ:

CloudWatchアラームがトリガーされた際の迅速な調査
AWS環境内で完結する障害調査
設定不要で即座に調査を開始したい場合
視覚的なリソース関係図を使った分析が必要な場合
チームで調査結果を共有し、レポート化したい場合

ユースケース例:

状況: Lambda関数のエラー率が急上昇
対応: CloudWatchアラームから「Investigate」をクリック
     → AIが関連メトリクス、ログ、最近のデプロイを分析
     → 根本原因の仮説を提示
     → Automation Runbookで自動修復

推奨される場面:

対応サービスリスト内のAWSサービスの問題
CloudWatch中心の運用体制
迅速な初期調査が必要な場合
チームメンバーが調査結果を引き継ぐ必要がある場合

Q Developerが最適なケース

シナリオ:

開発者がローカル環境から対話的に調査したい場合
コンテナワークロード（ECS/EKS）の問題
インフラストラクチャコードとアプリケーションコードを同時に確認したい場合
詳細なログ分析とコード修正を一連のフローで実施したい場合
GitHub統合が必要な場合

ユースケース例:

状況: NGINX プロキシで502 Gateway Timeoutエラーが発生
対応: Q Developer CLIで自然言語プロンプトを入力
     「502エラーを調査して原因を特定してください」
     → ECSクラスターを自動検出
     → CloudWatchログを分析
     → タイムアウト設定のミスマッチを発見
     → CDKコードの修正箇所を特定
     → 修正をデプロイして検証

推奨される場面:

開発者が主導する調査
ローカル開発環境からのトラブルシューティング
インフラストラクチャコード（CDK、CloudFormation）の問題
ECS/EKSタスク/ポッドの問題
コンソールではなくCLIベースのワークフローを好む場合

DevOps Agentが最適なケース

シナリオ:

24/7運用体制での自動インシデント対応
マルチクラウド/ハイブリッド環境の運用
複数の監視ツールを使用している環境
ServiceNowやPagerDutyとの統合が必要な場合
インシデント後の継続的改善が重要な場合
チーム協働が必要な大規模インシデント

ユースケース例:

状況: 本番環境でエラー率が急上昇し、PagerDutyアラートが発火
対応: DevOps Agentが自動的に調査を開始
     → Datadogメトリクス、CloudWatchログ、GitHub最新デプロイを相関分析
     → Slackの専用チャネルで関係者に通知
     → 根本原因を特定（最新デプロイに起因）
     → 即座の緩和プランを提示
     → 調査完了後、長期的な改善提案を生成
     → 過去のインシデントパターンから再発防止策を提案

推奨される場面:

エンタープライズレベルの運用
複数ツール（Datadog、Splunk等）を使用している環境
ServiceNow、PagerDutyとの統合が必要
Slackでのチーム協働が重要
AWS以外のクラウド環境も含む調査
インシデント後の継続的改善プロセスが確立されている組織
オンコールエンジニアの負荷軽減が課題

統合使用のベストプラクティス

これら3つのツールは相互排他的に使用するのではなく、組み合わせて使用することで最大の効果を発揮します。とのこと。

段階的アプローチ

レベル1: 初期調査（CloudWatch Investigations）

アラート発生時の第一次調査
迅速な問題の特定
既知の問題パターンの確認

レベル2: 詳細分析（Q Developer）

コードレベルの問題調査
インフラストラクチャコードの検証
修正の実装と検証

レベル3: 包括的対応（DevOps Agent）

大規模インシデントの自動対応
マルチツールデータの統合分析
チーム協働とステークホルダー管理
長期的改善策の策定

組織規模別の推奨構成

スタートアップ・小規模チーム

主要: CloudWatch Investigations（無料、設定不要）
補助: Q Developer CLI（開発者用）

中規模チーム

主要: CloudWatch Investigations（日常的な調査）
補助: Q Developer（開発者主導の調査）
検討: DevOps Agent（重要インシデント対応）

大規模エンタープライズ

主要: DevOps Agent（自動化された24/7対応）
補助: CloudWatch Investigations（特定サービスの迅速調査）
補助: Q Developer（開発者の日常的トラブルシューティング）

まとめ

今回はKnowledge MCPを使って比較を行ってみましたが、かなり充実した調査結果を出してくれるので驚きました。
こうして比較してみると、サービスごとにそれぞれ長所があるので導入先の状況に合わせて適切なサービスを選定する必要がありますね。
最終的な決断は人間の仕事だと思うので、適切な選択をしていきましょう。
本ブログがその選択の一助になれば幸いです。