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