Claude Code × AWS CLIでログ調査革命｜CloudWatchエラー原因をAIに特定させる実用テク

May 9, 2026

「CloudWatchのログ画面、いつまで開いてる？」問題

本番Lambdaがエラー吐いてる。CloudWatchを開いてロググループを探し、ログストリームの中から該当時刻のログを目で追って、関連するスタックトレースを拾い上げて、API Gatewayのログとも照合して…。

気づけば1時間が経過。それでも原因はまだ完全には掴めていない。これ、AWS運用に関わるエンジニアなら、誰もが何度も経験している地獄ですよね。

でも2026年現在、ログ調査のやり方は根本的に変わりつつあります。Claude Code のようなAIコーディングエージェントに aws logs filter-log-events を実行させ、結果を解析してエラーの根本原因まで特定させる。これが今、現場で起きている革命です。

本記事では、Claude Code × AWS CLIの組み合わせで、CloudWatchのエラー調査を圧倒的に効率化する具体的な方法を解説します。実際に投げるプロンプト例、設定ファイル、本番運用で気をつけるべきセキュリティポイントまで、今日から試せる実用テクをまとめました。

※AWS CLIの基本セットアップがまだの方は、事前に基礎編をご確認ください：AWS CLIで開発が爆速になる！セットアップからCloudWatch・Lambda活用まで実用コマンド付き

なぜClaude Code × AWS CLIが最強なのか

「AIにログを読ませる」というアイデア自体は新しくありません。コンソールでログをコピーして、ChatGPTに貼り付けて、エラー解析させる。これも有効な方法ですが、決定的な弱点があります。毎回コピペするのが面倒すぎるのと、AIが追加情報を取りに行けないこと。

Claude Codeは違います。AIが直接ターミナル上でコマンドを実行できるため、「必要なログを自分で取得して、不足があれば追加で取りに行く」という人間の運用エンジニアと同じ動きが可能になります。

理由1：ターミナル完結でコンテキスト切り替えゼロ

VSCodeでコードを書いて、ブラウザでCloudWatchを開いて、別タブでX-Rayを開いて…という作業は、認知負荷が高すぎます。Claude Codeならターミナル1枚で完結。AIが結果を要約してくれるので、自分でログを目で追う必要がありません。

理由2：構造化JSONとAIの相性が抜群

AWS CLIは全てのレスポンスがJSON。これはAIにとって最高の入力フォーマットです。AIは構造化データから必要な情報をピンポイントで抽出でき、無駄なトークンを使いません。生のログテキストをコピペするよりも、はるかに精度の高い解析が可能になります。

理由3：エージェント的な「探索」ができる

これが最大のポイント。たとえば「Lambdaがエラーを吐いている」という相談に対して、Claude Codeはこう動きます。

まずは関数名一覧を取得
該当しそうな関数のロググループを特定
直近のエラーログを抽出
エラー内容を見て、関連サービス（DynamoDB、SQSなど）の状態も確認
最後に「原因はこれです」と結論をまとめる

これは運用ベテランエンジニアの調査プロセスそのものです。AIに任せれば、最初の探索段階を全部自動化できます。

セットアップ：Claude Code から AWS CLI を呼べるようにする

「AIにAWS CLIを叩かせる」と聞くと、何か特別な統合が必要に思えますが、実はClaude Codeが標準でターミナルコマンドを実行できるため、AWS CLIさえ動けばすぐに使えます。

前提条件の確認

以下が動く状態になっていればOKです。

# 1. AWS CLIが動く
aws sts get-caller-identity

# 2. Claude Codeがインストール済み
claude --version

Claude Codeのインストール手順はClaude Codeとは？AI搭載のコーディングアシスタントを徹底解説に詳しく解説しているので、未導入の方はまずこちらから。

プロジェクトの初期化とCLAUDE.md

AWS運用作業用のディレクトリを作って、Claude Codeを起動します。

# 作業ディレクトリ作成
mkdir aws-ops && cd aws-ops

# Claude Codeを起動
claude

ここで重要なのが CLAUDE.md ファイル。これはClaude Codeに対する常時参照される指示書で、ここにAWS環境の前提を書いておくと、毎回の指示がシンプルになります。

# CLAUDE.md の例

## このプロジェクトのコンテキスト
このディレクトリはAWS本番環境の運用作業用です。
すべての作業は以下の前提で行ってください。

## AWS環境
- リージョン: ap-northeast-1
- プロファイル: production-readonly（読み取り専用）
- 主要サービス: Lambda, API Gateway, DynamoDB, S3

## Lambdaのロググループ命名規則
- Lambda関数のログは /aws/lambda/{関数名} に保存
- 関数名は kebab-case（例: my-api-handler）

## 調査の基本フロー
1. エラー報告を受けたら、まず該当関数のロググループを確認
2. 直近のエラーログを filter-log-events で抽出
3. エラー内容を要約して報告
4. 必要に応じて関連サービス（DynamoDB、API Gateway）も調査

## 禁止事項
- 書き込み系コマンド（put/delete/update）は実行しない
- 本番環境のリソース作成・削除は禁止

これだけで、Claude Codeが「このディレクトリで作業しているときはAWSの読み取り専用調査担当」として振る舞ってくれるようになります。

権限設定（settings.json）

Claude Codeは初期設定ではコマンド実行ごとに承認を求める動作になっています。AWS CLIを頻繁に叩く場面ではこれが煩わしいので、aws logs 系のコマンドだけは事前承認しておくと快適です。

{
  "permissions": {
    "allow": [
      "Bash(aws sts get-caller-identity)",
      "Bash(aws logs describe-log-groups:*)",
      "Bash(aws logs tail:*)",
      "Bash(aws logs filter-log-events:*)",
      "Bash(aws lambda list-functions:*)",
      "Bash(aws lambda get-function-configuration:*)"
    ]
  }
}

このファイルを .claude/settings.json に置いておくだけ。読み取り系のコマンドは即実行、変更系は必ず承認を求める、という安全な運用ができます。

【実践1】Lambdaエラーの原因をAIに特定させる

セットアップが終わったら、いよいよ実際にAIにログ調査をさせてみましょう。

シナリオ：「昨夜Lambdaが落ちたらしい」

本番運用でよくある相談はこれ。「夜中の2時頃、APIが502を返してた。Lambdaのどれかでエラーが出てたっぽい」という雑な情報からスタートします。

投げるプロンプト

Claude Codeにこう投げます。

昨日の深夜帯（25:00-27:00 JST）にLambdaでエラーが出たらしい。
全Lambda関数を対象に、その時間帯のエラーログを調査して、
原因として最も可能性が高いものを教えて。

調査手順：
1. すべてのLambda関数を一覧化
2. 各関数のロググループから、該当時間帯のERRORレベルログを抽出
3. エラーメッセージをグループ化して、頻度の高いものを特定
4. 根本原因の仮説を提示

Claude Codeが裏で実行するコマンド

このプロンプトを受けて、Claude Codeは以下のような順序でコマンドを実行していきます。

# Step 1: Lambda関数一覧を取得
aws lambda list-functions --query "Functions[*].FunctionName" --output text

# Step 2: 各関数について、指定時間帯のエラーログを抽出
# （JSTの25:00-27:00 = UTCの16:00-18:00、エポックミリ秒に変換）
aws logs filter-log-events \
  --log-group-name /aws/lambda/my-api-handler \
  --start-time 1746896400000 \
  --end-time 1746903600000 \
  --filter-pattern "ERROR"

# Step 3: 他の関数も同様に調査
aws logs filter-log-events \
  --log-group-name /aws/lambda/order-processor \
  --start-time 1746896400000 \
  --end-time 1746903600000 \
  --filter-pattern "?ERROR ?Exception ?Timeout"

# Step 4: 怪しい関数の詳細設定も確認
aws lambda get-function-configuration --function-name order-processor

Claude Codeが自動でコマンドを組み立て、結果を解析していきます。

Claude Codeの出力例

調査結果：

該当時間帯（25:00-27:00 JST）にエラーが集中していたのは
「order-processor」関数です。

主なエラー：
- DynamoDBアクセス時のタイムアウトエラー: 47件
- "ProvisionedThroughputExceededException": 23件
- メモリ不足によるOOM: 3件

最も可能性の高い原因：
DynamoDBテーブル「orders」のキャパシティ不足です。
深夜2時頃にバッチ処理が走った可能性があり、
該当時間帯にProvisionedThroughputExceededExceptionが
集中しています。

推奨対応：
1. DynamoDBの該当テーブルをオンデマンドキャパシティに変更
2. または、プロビジョンドキャパシティを引き上げ
3. リトライロジックの追加（指数バックオフ）

詳細ログを確認しますか？

これがClaude Code × AWS CLIの威力です。「Lambdaが落ちた」という曖昧な情報から、根本原因の仮説まで5分以内。コンソールでポチポチやっていたら30分以上かかる作業が、ターミナル1画面で完結します。

【実践2】複数サービスを横断したエラー調査

もう少し複雑なケースもやってみましょう。サーバーレスアーキテクチャでは、API Gateway → Lambda → DynamoDB のように複数サービスを経由するのが普通。エラーがどこで発生しているか、横断的に調べる必要があります。

シナリオ：「特定のAPIが間欠的に500を返す」

POST /api/orders のエンドポイントが、たまに500を返すと
ユーザー報告がある。

リクエストID「abc-123-xyz」が500だったケースを起点に、
以下を横断的に調査して：

1. API Gatewayのアクセスログでこのリクエストを特定
2. 紐づくLambda関数の同時刻の実行ログ
3. その時点でのDynamoDB側のメトリクス異常
4. X-Rayトレースがあれば併せて確認

タイムラインで整理した上で、500の根本原因を教えて。

AIが横断調査する流れ

このプロンプトに対して、Claude CodeはAWS CLIの様々なコマンドを組み合わせていきます。

# API Gatewayのアクセスログ検索
aws logs filter-log-events \
  --log-group-name API-Gateway-Execution-Logs_xxxx/prod \
  --filter-pattern "abc-123-xyz"

# 該当時刻のLambdaログ
aws logs filter-log-events \
  --log-group-name /aws/lambda/order-handler \
  --start-time {上記から取得した時刻 - 5秒} \
  --end-time {上記から取得した時刻 + 30秒}

# DynamoDBのCloudWatchメトリクス
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ThrottledRequests \
  --dimensions Name=TableName,Value=orders \
  --start-time 2026-05-09T17:00:00Z \
  --end-time 2026-05-09T17:05:00Z \
  --period 60 \
  --statistics Sum

# X-Rayトレース取得
aws xray get-trace-summaries \
  --start-time 1746896700 \
  --end-time 1746896800 \
  --filter-expression "annotation.requestId = \"abc-123-xyz\""

結果を統合して、AIが「リクエストabc-123-xyzはAPI Gatewayで14:23:45に受信、Lambda呼び出しで14:23:46にタイムアウト、その時点でDynamoDBのスロットリングが発生していた」というタイムラインを構築してくれます。

これを人間が手動でやろうとすると、ブラウザでタブを5つ以上開いて、時刻を秒単位で照合する地獄。AIに任せれば30秒で終わります。

【実践3】定型レポートを自動生成

Claude Code × AWS CLIの組み合わせは、単発のトラブル調査だけでなく、定期的な運用レポートの自動化にも威力を発揮します。

朝会用：直近24時間のエラーサマリー

毎朝の朝会で「昨日の本番環境はどうだった？」という確認をしているチームは多いはず。これをAIに自動生成させます。

過去24時間の全Lambda関数のエラー状況をまとめて、
朝会で共有できる形式のレポートをMarkdownで作って。

含めてほしい内容：
- エラー総数（前日比）
- エラー種別TOP3とその件数
- 影響を受けた関数名
- 特に注意すべき新規発生エラーがあれば指摘
- 本日の対応推奨事項

Claude Codeは必要な情報を取得して、こんなアウトプットを返してくれます。

# 朝会レポート 2026-05-10

## サマリー
- エラー総数: 142件（前日比 +23件）
- 影響を受けた関数: 4関数
- 新規発生エラー: 1件（要注意）

## エラー種別TOP3
1. DynamoDB ProvisionedThroughputExceededException: 89件
2. Lambda Timeout (30秒超過): 41件
3. ValidationException (入力バリデーション): 12件

## 新規発生エラー
- order-processor関数で「PaymentGateway connection refused」が
  深夜に5件発生。前日まで0件だったため要調査。

## 推奨対応
1. order-processorの調査優先度: 高
2. DynamoDBのキャパシティプラン見直し検討
3. 入力バリデーションエラーはクライアント側のリリース起因か確認

毎週の傾向分析レポート

定期実行するなら、Claude Codeの非対話モード（-p オプション）を使って、cronで回すこともできます。

#!/bin/bash
# weekly-report.sh
# 毎週月曜の朝にcronで実行

claude -p "過去7日間のCloudWatchエラーログを分析し、
傾向レポートをMarkdownで出力して。
出力先は ./reports/weekly-$(date +%Y%m%d).md" \
  > /dev/null

# Slackに投稿
curl -X POST -H 'Content-type: application/json' \
  --data "{\"text\":\"$(cat ./reports/weekly-$(date +%Y%m%d).md)\"}" \
  $SLACK_WEBHOOK_URL

これで毎週月曜にAIが書いた運用レポートがSlackに届く仕組みが完成。SREチームのレポート作成工数がほぼゼロになります。

【補足】Codex CLIでも同じことができる？

「Claude Codeじゃなくて、OpenAIのCodex CLIでも同じこといけるよね？」と思った方も多いはず。結論から言うと、できます。ただし、いくつか違いがあるので、軽く比較しておきます。

項目	Claude Code	Codex CLI
提供元	Anthropic	OpenAI
使用モデル	Claude Opus / Sonnet	GPT-5系
コマンド実行	標準対応	標準対応
設定ファイル	CLAUDE.md / settings.json	AGENTS.md / config.toml
強み	長文コンテキスト処理、複雑な推論	コード生成精度、応答速度
AWS Bedrockルーティング	対応	非対応

使い分けの判断基準

個人的な印象としては、ログ調査のような「大量の文脈を読んで原因を推論する」タスクではClaude Codeに分がある感覚です。長いログ全体を渡しても文脈を保ち、複雑な因果関係を整理してくれる強さがあります。

一方、Codex CLIは応答が速く、シンプルなコマンド生成に強いため、「特定のCLIコマンドを組み立ててほしい」「軽い疑問を即座に解消したい」みたいな用途では快適です。

両方使い分けるか、まずは1つ試して馴染んだ方を主軸にする、というのが現実的なアプローチです。本記事ではClaude Codeを主軸に解説していますが、設定ファイル名や細かい仕様を読み替えれば、Codex CLIでも同じワークフローが組めます。

AI運用で押さえるべきセキュリティと注意点

「AIにAWS CLIを叩かせる」というのは強力ですが、本番環境で使うなら絶対に守るべきセキュリティ原則があります。

原則1：読み取り専用IAMロールを使う

本番環境を調査する用途なら、AdministratorAccess は絶対に使わないこと。専用の読み取り専用IAMロール／ユーザーを作成して、それをClaude Code用のプロファイルに紐づけます。

# Claude Code専用プロファイルの設定
aws configure --profile production-readonly

# CLAUDE.mdで明示
# AWS_PROFILE=production-readonly が常に使われるよう指定

付与するIAMポリシーは、AWS管理ポリシーの ReadOnlyAccess をベースに、必要最小限まで絞るのがベストです。

原則2：–dangerously-skip-permissions は本番で使わない

Claude Codeには --dangerously-skip-permissions（通称YOLOモード）というオプションがあり、すべてのコマンド実行を承認なしで通します。名前の通り危険なので、開発用サンドボックス以外で使うのは厳禁。

本番調査では、必ず settings.json で読み取り系コマンドだけ事前承認する形を徹底しましょう。

原則3：機密情報のログ出力に注意

CloudWatchログに、誤ってAPIキーやパスワード、個人情報が出力されていることは現場で意外と多いです。AIに渡すと、それらが外部のLLMサーバーに送信されることになります。

対策として、エンタープライズ環境では Amazon Bedrock経由でClaude Codeを使うのが推奨です。これによりリクエストがAWSアカウント内で完結し、CloudTrailで監査ログが残ります。

# Bedrock経由で使う設定
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-west-2  # Bedrockが使えるリージョン

さらに加速させるTips

基本ができたら、より使い込むための応用テクも押さえておきましょう。

Tip 1：カスタムスラッシュコマンド化

頻出する調査パターンは、Claude Codeのカスタムスラッシュコマンドとして登録できます。.claude/commands/ 配下にMarkdownファイルを置くだけ。

# .claude/commands/aws-error.md

直近のLambdaエラーを調査してレポートしてください。

引数: $ARGUMENTS （関数名、未指定なら全関数）

手順:
1. 指定された関数（または全関数）のロググループを特定
2. 過去1時間のERRORログを抽出
3. エラータイプ別に集計
4. 最も頻度の高いエラーの根本原因を仮説提示

これを保存しておくと、Claude Code内で /aws-error と打つだけで定型調査が走ります。/aws-error order-processor のように引数も渡せます。

Tip 2：MCPサーバーで深い統合

AWS CLIだけでなく、専用のMCP（Model Context Protocol）サーバーを使うとさらに強力です。AWS公式が公開しているawslabs/Log-Analyzer-with-MCPは、CloudWatchログ専用のAI統合ツールで、横断検索・サービス間相関分析がより自然にできます。

Tip 3：複数AWSアカウントの切り替え

開発・ステージング・本番を行き来する運用なら、AWS_PROFILE の切り替え自体もAIに任せられます。

ステージング環境で同様のエラーが発生しているか確認して。
AWS_PROFILE=staging に切り替えて、本番と同じ調査を実施。

Claude Codeは export AWS_PROFILE=staging を実行してから調査コマンドを叩いてくれます。環境横断の比較調査が一瞬です。

まとめ：AI×CLIで運用エンジニアの時間を取り戻そう

Claude Code × AWS CLIで何が変わるのかを、最後にまとめます。

セットアップは超簡単：AWS CLIが動く環境にClaude Codeを入れて、CLAUDE.mdを書くだけ
ログ調査が劇的に高速化：曖昧な相談から根本原因の仮説まで5分以内
横断調査が現実的に：API Gateway → Lambda → DynamoDB を秒単位で照合
定型レポート自動化：朝会用エラーサマリー、週次分析がAIに任せられる
セキュリティ必須：読み取り専用IAM、settings.jsonで権限制御、Bedrock経由で監査

「AIにログを読ませる」のは、もう未来の話じゃありません。2026年現在、現場で動いている運用効率化の標準パターンです。CloudWatchを目で追う作業に時間を奪われているなら、今日この記事のセットアップを試してみてください。1度体験すれば、もう後戻りできなくなります。

運用エンジニアの本当の仕事は、ログを目で追うことではなく、システムの改善方針を考えること。AIにルーチン作業を任せて、人間にしかできない判断に時間を使っていきましょう。

Claude Code × AWS運用をさらに加速させる関連記事

本記事のテクニックを実践したら、Claude Codeの活用範囲をさらに広げて、運用業務全体を効率化していきましょう。AI×AWS運用の関連トピックを厳選しました。

Claude Code活用を深める

Claude Codeとは？AI搭載のコーディングアシスタントを徹底解説 – Claude Codeの基本機能と料金プラン、初期セットアップを詳しく解説。本記事の前提となる知識を押さえられます
HeyAgent – Claude Codeの実行通知を自動化するAIコーディングアシスタント支援ツール – Claude Codeの長時間タスクをスマホに通知できるツール。AWS調査を裏で走らせる運用と相性抜群です
GitHub IssuesにClaude Codeを導入する方法｜AIでバグ修正・コードレビューができる仕組みとは？ – エラー調査で見つけたバグ修正をGitHub上で完結させる連携テクニックです

AWS運用・サーバーレス開発を強化

AWS Lambda + API Gatewayで始めるサーバーレスAPI開発｜実装手順から運用まで – 本記事の調査対象となるサーバーレスAPI構成を体系的に学べます。実装サイドの理解が深まると調査精度も上がります
Updog by Datadog – サービス障害を早期検知するリアルタイムモニタリングツール – CloudWatchの先にある本格的な監視ツール。AI調査と組み合わせると検知から対応までの時間を最短化できます
コマンドラインの基本と活用方法【初心者エンジニア向け】 – AI×CLIワークフローの土台となるシェル操作の基礎。パイプ・リダイレクトを使いこなすと連携の幅が広がります

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！