Claude CodeにCloudWatch MCPサーバーをつないで、アラームやログを日本語で確認してみた

こんにちは！染田です

Amazon CloudWatch（以下、CloudWatch）のアラームやログを確認するとき、普段は次のような手順を踏んでいると思います。

AWSマネジメントコンソールにログインします
リージョンを切り替えます
CloudWatchを開き、アラームやロググループを探します
CloudWatch Logs Insights（以下、Logs Insights）のクエリを書いて実行します

確認したいことは「さっき鳴ったアラームの原因は何か」だけなのに、意外と手間がかかります。

そこで今回は、AWSが公開している CloudWatch MCPサーバー をClaude Codeにつないでみました。つないでしまえば、コンソールにログインしなくても、日本語で聞くだけでClaude Codeが自動でAWSにアクセスし、アラームやログを確認してくれます。

本記事でわかること

Claude CodeからCloudWatchを確認できる仕組み
読み取り専用で安全につなぐための準備と、登録の手順
アラーム・ログの確認で、実際にどんな聞き方ができるか
使うときの注意点

仕組み

Claude Code ── CloudWatch MCPサーバー ── AWS（CloudWatchのAPI）
                       ↑
          AWS CLIのプロファイル（読み取り専用のアクセスキー）

MCP（Model Context Protocol）は、Claude CodeなどのAIツールに、外部のサービスを操作する「道具」を追加するための仕組みです。CloudWatch MCPサーバーを登録すると、Claude Codeは、AWS CLIのプロファイルに登録したアクセスキーを使ってCloudWatchのAPIを呼び出せるようになります。

こちらは日本語で質問するだけで、どのツールを、どのリージョン・期間で使うかはClaude Codeが判断してくれます。

できること

CloudWatch MCPサーバーには、主に次のツールがあります。

分類	ツール	できること
アラーム	`get_active_alarms`	いまALARM状態のアラームの一覧
アラーム	`get_alarm_history`	指定したアラームの状態変化の履歴
アラーム	`get_recommended_metric_alarms`	メトリクスに対するおすすめのアラーム設定
ログ	`describe_log_groups`	ロググループの一覧と、保持期間・容量などの情報
ログ	`execute_log_insights_query`	Logs Insightsのクエリを実行して結果を取得
ログ	`analyze_log_group`	ロググループの異常やメッセージのパターンを分析
メトリクス	`get_metric_data`	CPU使用率やエラー数などのメトリクスの値を取得

どれも参照系のツールで、アラームの設定変更やログの削除はできません。

準備

① 読み取り専用のAWS IAMユーザーを用意する

AIにAWSを触らせるので、壊せない状態でつなぐことを最優先にします。

MCP用に、ReadOnlyAccess だけを付けたIAMユーザーを作り、アクセスキーを発行します
管理者権限のアクセスキーは使いません

CloudWatch MCPサーバーが使う権限（cloudwatch:DescribeAlarms、logs:StartQuery など）は、すべて ReadOnlyAccess に含まれています。

② AWS CLIのプロファイルに登録する

aws configure --profile myapp-prd-readonly

本番と検証でプロファイル名を分けておくと、環境の取り違えを防げます。登録できたら、どのアカウントにつながるかを確認しておきます。

aws sts get-caller-identity --profile myapp-prd-readonly

③ Claude Codeに登録する

uv（Pythonのツール）をインストールしておき、次のコマンドでCloudWatch MCPサーバーを登録します。プロファイル名とリージョンは環境に合わせて変えてください。

claude mcp add --scope user aws-cloudwatch \
  -e AWS_PROFILE=myapp-prd-readonly \
  -e AWS_REGION=ap-northeast-1 \
  -e FASTMCP_LOG_LEVEL=ERROR \
  -- uvx awslabs.cloudwatch-mcp-server@latest

登録できたら、claude mcp list で Connected になっていることを確認します。

aws-cloudwatch: uvx awslabs.cloudwatch-mcp-server@latest - √ Connected

MCPサーバーのツールは、会話を始めるときに読み込まれます。登録したあとは、Claude Codeを開き直してから使います。

使ってみた

ここからは、実際に聞いてみた内容と、Claude Codeの回答を紹介します。

画面は、社内の検証用アカウントに作ったデモで撮影しています。デモの中身は、受注処理のAWS Lambda関数 blog-demo-order-function と、そのエラー数を監視するアラーム blog-demo-order-function-Errors です。Lambda関数を7回実行し、そのうち4回はわざとエラーにしています。

① いま鳴っているアラームを確認する

東京リージョンで、いまアラーム状態になっているものはある？

Claude Codeは aws-cloudwatch のツールを呼び出し、「アラーム状態のものが1件あります」と答えてくれました。回答では、次の内容が表にまとまっています。

アラーム名と説明
監視対象（Lambda関数 blog-demo-order-function の Errors メトリクス）
条件（エラー数が0を超えたら発報）
発報の理由（19:47の1分間にエラーが4件出た）
ALARMになった時刻（日本時間に変換済み）

さらに、「原因を調べるなら、この関数のロググループで19:45〜19:50ごろのエラーログを検索します。実行しましょうか？」と、次にやるべきことまで提案してくれました。

② エラーが出ていないかログを調べる

直近1時間に、blog-demo-order-function のLambdaでERRORが出ていないか調べて

画面では「Called aws-cloudwatch」と1行にまとめて表示されますが、裏ではClaude CodeがLogs Insightsのクエリを自分で組み立てて実行しています。

回答では、「直近1時間（日本時間 18:51〜19:51）でERRORが4件出ていて、どれも19:47台の約11秒間に集中している。件数はアラームの4件と一致する」と、①のアラームとの関係まで確認してくれました。

ERRORの一覧は、時刻・注文ID（order_id）・アプリのメッセージ・例外の表にまとまっています。そのうえで、原因を次の2種類に分けて説明してくれました。

入力データの不正（A004、A005）：int(event["quantity"]) の行で、項目がない・数値でないデータを受けて例外になっている。関数側に入力チェックがない
在庫APIのタイムアウト（A006、A007）：TimeoutError("stock api timeout") が発生している

エラーが起きたコードの行番号まで、ログのスタックトレースから読み取って示してくれます。

③ アラームが鳴った原因を調べる

このアラームが鳴った原因を、ログから調べて

①と同じ会話の続きなので、「このアラーム」だけで、どのアラームのことかを理解してくれます。

回答では、まず「19:47の1分間に、Lambda関数が4回続けて例外で終了したため。このアラームはエラーが1件でもあれば発報する設定なので、1件目のエラーで条件を満たしている」と、アラームの条件と結び付けて説明してくれました。

続いて、この1時間の実行7回分を、時刻・注文ID・結果・処理時間の表に並べてくれています。エラーの4回だけでなく、正常に終わった3回もあわせて並べているので、どこから失敗し始めたかがひと目で分かります。

驚いたのは、在庫APIのタイムアウトについての見立てです。

処理時間が1.87ミリ秒・1.90ミリ秒しかなく、外部APIの応答を待った形跡がない
例外が出ているのは、入力を読み取る行より前の raise TimeoutError(...) の行で、コードがこの例外を直接投げている

という2つの理由から、「実際に通信がタイムアウトしたのではない」と判断していました。さらに、注文IDが連番で、約3.5秒おきに「正常3件 → データ不正2件 → タイムアウト2件」ときれいに並んでいることから、「動作確認用のテストデータで、わざとエラーを起こした実行と考えるのが自然」と、デモであることまで言い当てていました。

最後に、「テストだったなら対応は不要。心当たりがない場合は、呼び出し元を確認してください」と、このあとの対応もまとめてくれています。

使うときの注意点

アラームの名前の一覧は取れない

get_active_alarms で一覧にできるのは、ALARM状態のアラームだけです。OK状態のものも含めて集計したいときは、コンソールの「すべてのアラーム」からアラーム名をコピーして渡すと確実です。

時刻はUTCで扱われる

ツールに渡す時刻と、返ってくる時刻はUTCです。今回のデモでは、Claude Codeが自分で日本時間に直して答えてくれましたが、期間を指定するときは「日本時間の〜」と明示してお願いすると、取り違えを防げます。

AIの見立ては、最後に人が確認する

③の回答では、「この時刻以降エラーは出ていないので、次の評価期間でアラームはOKに戻るはず」とも説明していました。しかし、デモのアラームは、データがない間は状態を変えない設定（欠落データを無視）にしていたため、実際にはOKには戻りません。

ログやアラームの読み取りはとても正確ですが、アラームの細かい設定まで踏まえた判断は外れることもあります。対応を決める前には、人が設定や画面を確認するようにしましょう。

Logs Insightsはスキャン量で課金される

Logs Insightsは、スキャンしたデータ量に応じて課金されます。ログが多いロググループで期間を広げすぎるとスキャン量が一気に増えるので、「この時間帯だけ」と範囲を絞ってお願いするのがおすすめです。

ログの保持期間を過ぎたログは見られない

保持期間を過ぎたログは削除されているため、確認できません。保持期間が短いロググループもあるので、describe_log_groups の結果で確認しておくとよいです。

ログに含まれる情報に気をつける

ログには、ユーザーの入力内容などが出力されていることがあります。AIにログを読ませるときは、どんなデータが含まれているかにも注意が必要です。

認証情報の扱い

アクセスキーは ~/.aws/credentials にだけ保存し、MCPの設定にはプロファイル名だけを書きます。なお、Claude CodeがAWS CLIの設定ファイルを読みに行こうとした際、Claude Codeの自動判定で「認証情報の探索」としてブロックされたことがありました。読み取り専用のIAMユーザーとあわせて、安心して使えるポイントです。