MCP × CloudWatch で障害調査を会話で完結させる｜AIOpsの設定から実践まで

AWS

Lambda の実行エラーが増えてるな…と思ってマネコンを開いたとき、ログを探してメトリクスを確認して、またログに戻って…という往復作業、正直しんどいんですよね。そこに MCP と CloudWatch の組み合わせが刺さりました。

2025年7月に AWS から、AWS Labs のオープンソースとして CloudWatch MCP サーバーが公開され、AIエージェントが自然言語でメトリクス・ログ・アラームを横断的に調査できるようになっています。使ってみたら想像以上に便利だったので、設定方法から実際のユースケースまでまとめておきます。

この記事でわかること

  • CloudWatch MCP サーバーの基本と役割
  • Claude Desktop への設定手順
  • 必要な IAM 権限の設定
  • 利用可能なツール群と機能
  • 障害調査・監視設計での実践的なユースケース
  • ハマりやすい注意点

CloudWatch MCP サーバーとは

MCP（Model Context Protocol）は Anthropic が策定したオープンプロトコルで、アプリケーションが LLM にコンテキストを提供する方法を標準化するものです。CloudWatch MCP サーバーは、このプロトコルを使って AI エージェントが CloudWatch のデータに直接アクセスできるようにする仕組みです。

AI エージェントは自然言語インタラクションを通じて、アラームパターンの分析・メトリクスの異常検知・サービスヘルスの調査・ログやトレースの照会といった複雑なトラブルシューティングワークフローを実行できます。つまり、「さっきから Lambda のエラーが増えてるんだけど何が原因？」みたいな問いかけだけで、メトリクスの取得・ログの検索・アラームの確認を AI が自律的にこなしてくれるわけです。

最初は「どうせ大企業向けの話でしょ」と思ってたんですが、個人の AWS 環境でも普通に使えます。

セットアップ方法

前提条件

  • Claude Desktop（または Cursor、Amazon Q CLI など MCP 対応クライアント）
  • Python 3.10 以上 ＋ uv / uvx
  • AWS 認証情報（aws configure 済み、または環境変数）
  • CloudWatch へのアクセス権限を持つ IAM ロール or ユーザー

uv が入っていない場合はまずこれを実行します。

curl -LsSf https://astral.sh/uv/install.sh | sh

claude_desktop_config.json に追記する

Mac の場合、設定ファイルは ~/Library/Application Support/Claude/claude_desktop_config.json にあります。以下の内容を追記するだけです。

{
  "mcpServers": {
    "cloudwatch": {
      "command": "uvx",
      "args": [
        "awslabs.cloudwatch-mcp-server@latest"
      ],
      "env": {
        "AWS_REGION": "ap-northeast-1",
        "AWS_PROFILE": "your-profile-name",
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

AWS プロファイルを使わずに環境変数で認証する場合は、AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY を env ブロックに書けば動きます。ただ、セッショントークンが必要な場合（SSO や一時クレデンシャル）は AWS_SESSION_TOKEN も忘れずに入れてください。ここでハマりがちです。

設定ファイルを保存したら Claude Desktop を完全に終了して再起動します。入力ボックスの左下にツールアイコンが増えていれば成功です。

必要な IAM 権限

最小権限の原則に従って、MCP サーバーが CloudWatch メトリクス・ログ・アラームを照会するのに必要なアクセス権限のみを付与するのが推奨です。以下は最小限に近いですが、実運用では AWS Labs の公式ドキュメントと合わせて調整するのが無難です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricData",
        "cloudwatch:ListMetrics",
        "cloudwatch:DescribeAlarms",
        "cloudwatch:DescribeAlarmHistory",
        "logs:DescribeLogGroups",
        "logs:DescribeQueryDefinitions",
        "logs:ListLogAnomalyDetectors",
        "logs:ListAnomalies",
        "logs:StartQuery",
        "logs:GetQueryResults",
        "logs:StopQuery"
      ],
      "Resource": "*"
    }
  ]
}

書き込み系の操作は含まれていないので、誤操作でリソースが壊れる心配はありません。MCP サーバーは読み取り専用に徹するのが無難です。

CloudWatch MCP サーバーで使えるツール群

AWS Labs の公式ドキュメントに基づくと、提供されているツールは大きく以下のカテゴリに分かれています。

メトリクス系

  • get_metric_data – 任意のメトリクスの時系列データを取得。メトリクスのネームスペース・ディメンション・統計量などを柔軟に指定できます。
  • get_metric_metadata – メトリクスに関する包括的なメタデータ（単位・ディメンション名など）を取得します。
  • analyze_metric – メトリクスの傾向や季節性などを分析します。
  • get_recommended_metric_alarms – メトリクスに対する推奨アラーム設定（しきい値・評価期間・その他アラーム設定を含む）を提案してくれます。

アラーム系

  • get_active_alarms – アカウント内のアクティブなアラームを取得
  • get_alarm_history – アラームの状態遷移履歴を取得

ログ系

  • describe_log_groups – ロググループの一覧と関連メタデータを取得
  • execute_log_insights_query / get_logs_insight_query_results – CloudWatch Logs Insights のクエリを実行して結果を取得（必要に応じて cancel_logs_insight_query で中断もできます）

get_recommended_metric_alarms ツールは予想外の機能で、「このメトリクスにアラームを設定したい」と伝えるだけで適切な設定値を提案してくれます。監視設計のたたき台として使えそうです。

実際のユースケース

① Lambda のエラー急増を調査する

たとえば Claude に以下のように話しかけます。

「過去1時間で Lambda 関数 my-function のエラーが増えています。
メトリクスとログを確認して原因を教えてください。」

Claude は自動的に get_metric_data で Lambda の Errors メトリクスを取得し、続いて Logs Insights でエラーログを検索、スタックトレースを見て根本原因の候補を提示してくれます。開発者が複数の AWS コンソール画面を手動で操作する必要がなくなり、かなり時間が短縮できます。

② アラームの一括確認とサマリー

「現在 ALARM 状態になっているアラームをすべてリストアップして、
重要度順にサマリーしてください。」

get_active_alarms を使いつつ、各アラームの直近の履歴も引いてきてまとめてくれます。朝イチの状況確認みたいな用途には結構使えます。

③ 監視設計の壁打ち

「DynamoDB の ConsumedReadCapacityUnits と ConsumedWriteCapacityUnits に
アラームを設定したい。適切なしきい値の設定を提案してください。」

実際のメトリクスデータを参照しながら現実的なしきい値を提案してくれるので、「とりあえず 80% にしとくか」みたいな雑な設定から卒業できます。

Application Signals MCP サーバーとの違い

AWS Labs には CloudWatch MCP サーバーと並んで Application Signals MCP サーバーも公開されています。混同しやすいので整理しておきます。

CloudWatch MCP サーバーは汎用的な CloudWatch データ（メトリクス・ログ・アラーム）へのアクセスに特化しています。Application Signals MCP サーバーは、AI アシスタントがサービスの監視と分析を行うための包括的なツールを提供しており、X-Ray トレースを組み合わせたマイクロサービス観点のトラブルシューティングに向いています。

シンプルな Lambda + DynamoDB 構成くらいなら CloudWatch MCP サーバー単体で十分です。ECS や複数サービスが絡み合うようなアーキテクチャなら両方を組み合わせる方が威力が出ると思います。

ハマりポイントと注意事項

使ってみて気になった点をいくつか紹介します。

ローカル実行限定 – 現状の CloudWatch MCP サーバーはローカル環境（LLM クライアントと同一ホスト）での実行が前提です。CI/CD パイプラインに組み込んだり、リモートで動かしたりする想定ではないようです。

ログのデータ量に注意 – Logs Insights で大量のデータを引っ張ってくると、Claude のコンテキストウィンドウが埋まりがちです。クエリに時間範囲やフィルター条件を入れておくことを AI に伝えると多少マシになります。

認証のリフレッシュ – SSO を使っている場合、トークンの有効期限が切れると MCP サーバーがエラーを返します。長時間の作業中は aws sso login を定期的に実行する習慣をつけておく方がよいです。

事前に CloudWatch アラームを整備しておく – MCP サーバーを効果的に使うには、アクティブな CloudWatch アラームを事前に設定しておくことが重要です。アラームが AI のクエリに対する理解と応答に有効なコンテキストを提供するからです。監視が疎かな環境だとそもそも調査の手がかりが少なくなります。

※この記事にはプロモーションが含まれます

ちなみに、お名前.com レンタルサーバー（WordPressに特化した高速レンタルサーバー。月額990円〜、独自ドメイン実質0円）も気になっています。お名前.com レンタルサーバー

まとめ

CloudWatch MCP サーバーを使うと、インシデント調査の流れが「コンソールをポチポチする作業」から「AI と会話しながら仮説を検証する作業」に変わります。まだ「これで完全に自動化できる」というレベルではありませんが、調査の起点として使うだけでもかなり時間が節約できます。

設定自体は JSON に数行書くだけなので、CloudWatch を使っている環境があれば一度試してみる価値はあると思います。実際の業務でどのくらい使い物になるか、もう少し検証を続けてみるつもりです。

参考になったらクリックしてもらえると嬉しいです!

Blogmura CloudAWS Ranking
タイトルとURLをコピーしました