Claude Code × AWS CloudWatch 完全ガイド|ログ分析・アラーム設定・ダッシュボード自動構築

「本番でエラーが出た！でもログが多すぎてどこを見ればいいかわからない」——インシデント対応でよくある焦りです。

CloudWatch は AWS の標準的なモニタリングサービスですが、ログが膨大すぎて肝心な情報が埋もれ、アラームの設定も後回しになりがちです。私は業務でECS+Lambdaのシステムを監視していますが、Claude Code にログを読ませて原因を特定させることで、インシデント対応時間が平均40%短縮されました。

この記事では、CloudWatch のログ分析・アラーム設計・ダッシュボード構築を Claude Code で自動化する実践手順を解説します。

---

CloudWatch の主要コンポーネント

CloudWatch Logs      : アプリ・AWSサービスのログ保存・検索
CloudWatch Metrics   : CPU使用率・リクエスト数などの数値データ
CloudWatch Alarms    : メトリクスの閾値超過を検知してSNS等に通知
CloudWatch Dashboards: メトリクス・ログを可視化するカスタム画面
Log Insights         : ログをSQLライクに分析するクエリエンジン

---

Step 1: ログパターン分析を Claude Code に任せる

インシデント発生時、まず「エラーログのパターン」を把握することが重要です。

# 直近1時間のエラーログを取得
aws logs filter-log-events \
  --log-group-name "/ecs/myapp" \
  --start-time $(date -d "1 hour ago" +%s000) \
  --filter-pattern "ERROR" \
  --output json > error-logs.json

claude -p "
以下の CloudWatch エラーログを分析して:

1. エラーの種類別に分類 (5xx, 4xx, DB接続エラー, タイムアウト等)
2. 最も頻度が高いエラーを特定
3. エラーが急増した時刻を特定
4. 根本原因の仮説を提示
5. 調査すべき次のアクションを提案

$(cat error-logs.json | head -500)
"

Log Insights クエリを自動生成

claude -p "
以下の目的のための CloudWatch Log Insights クエリを生成して:

1. 過去1時間のエンドポイント別エラー率 (上位10件)
2. レイテンシが500ms以上のリクエストの詳細
3. 特定ユーザー (user_id: 12345) のすべての操作ログ
4. デプロイ後30分以内に発生した初回エラー

ログフォーマット: JSON (timestamp, level, message, user_id, endpoint, duration_ms, status_code)
"

生成されるLog Insightsクエリ例:

-- エンドポイント別エラー率
fields @timestamp, endpoint, status_code
| filter status_code >= 400
| stats count() as error_count by endpoint
| sort error_count desc
| limit 10

-- レイテンシ500ms超のリクエスト
fields @timestamp, endpoint, duration_ms, user_id
| filter duration_ms > 500
| sort duration_ms desc
| limit 50

-- 特定ユーザーの操作ログ
fields @timestamp, level, message, endpoint
| filter user_id = "12345"
| sort @timestamp desc
| limit 100

---

Step 2: アラーム設定を自動生成

claude -p "
以下のシステムに必要な CloudWatch アラームを全て設計して。
CDK TypeScript で実装すること。

【システム構成】
- ECS Fargate (APIサーバー、2〜10台)
- RDS PostgreSQL
- ALB (Application Load Balancer)
- Lambda (バッチ処理)

【アラーム要件】
- 本番環境: 5分以内に気づけるアラーム設定
- 通知先: SNS → Slack と PagerDuty
- 段階的アラーム (Warning/Critical の2段階)
- ビジネスアワー外は Critical のみ通知
"

// lib/monitoring-stack.ts
import * as cdk from "aws-cdk-lib";
import * as cloudwatch from "aws-cdk-lib/aws-cloudwatch";
import * as actions from "aws-cdk-lib/aws-cloudwatch-actions";
import * as sns from "aws-cdk-lib/aws-sns";

export class MonitoringStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const alertTopic = sns.Topic.fromTopicArn(
      this, "AlertTopic",
      `arn:aws:sns:${this.region}:${this.account}:prod-alerts`
    );
    const warnTopic = sns.Topic.fromTopicArn(
      this, "WarnTopic",
      `arn:aws:sns:${this.region}:${this.account}:prod-warnings`
    );

    // ALB 5xx エラー率アラーム
    const alb5xxAlarm = new cloudwatch.Alarm(this, "Alb5xxAlarm", {
      alarmName: "prod-alb-5xx-critical",
      alarmDescription: "ALB 5xxエラー率が5%超過",
      metric: new cloudwatch.Metric({
        namespace: "AWS/ApplicationELB",
        metricName: "HTTPCode_Target_5XX_Count",
        dimensionsMap: { LoadBalancer: "app/myapp/xxx" },
        statistic: "Sum",
        period: cdk.Duration.minutes(5),
      }),
      threshold: 10,
      evaluationPeriods: 2,
      comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_THRESHOLD,
      treatMissingData: cloudwatch.TreatMissingData.NOT_BREACHING,
    });
    alb5xxAlarm.addAlarmAction(new actions.SnsAction(alertTopic));

    // ECS CPU使用率アラーム (Warning/Critical)
    const ecsCpuWarning = new cloudwatch.Alarm(this, "EcsCpuWarning", {
      alarmName: "prod-ecs-cpu-warning",
      metric: new cloudwatch.Metric({
        namespace: "AWS/ECS",
        metricName: "CPUUtilization",
        dimensionsMap: { ClusterName: "myapp-cluster", ServiceName: "myapp-service" },
        statistic: "Average",
        period: cdk.Duration.minutes(5),
      }),
      threshold: 70,
      evaluationPeriods: 3,
    });
    ecsCpuWarning.addAlarmAction(new actions.SnsAction(warnTopic));

    const ecsCpuCritical = new cloudwatch.Alarm(this, "EcsCpuCritical", {
      alarmName: "prod-ecs-cpu-critical",
      metric: new cloudwatch.Metric({
        namespace: "AWS/ECS",
        metricName: "CPUUtilization",
        dimensionsMap: { ClusterName: "myapp-cluster", ServiceName: "myapp-service" },
        statistic: "Average",
        period: cdk.Duration.minutes(5),
      }),
      threshold: 90,
      evaluationPeriods: 2,
    });
    ecsCpuCritical.addAlarmAction(new actions.SnsAction(alertTopic));

    // RDS 接続数アラーム
    const rdsConnectionAlarm = new cloudwatch.Alarm(this, "RdsConnectionAlarm", {
      alarmName: "prod-rds-connections-critical",
      metric: new cloudwatch.Metric({
        namespace: "AWS/RDS",
        metricName: "DatabaseConnections",
        dimensionsMap: { DBInstanceIdentifier: "myapp-db" },
        statistic: "Maximum",
        period: cdk.Duration.minutes(5),
      }),
      threshold: 80,  // db.t3.micro の最大接続数の80%
      evaluationPeriods: 2,
    });
    rdsConnectionAlarm.addAlarmAction(new actions.SnsAction(alertTopic));

    // Lambda エラー率アラーム
    const lambdaErrorAlarm = new cloudwatch.Alarm(this, "LambdaErrorAlarm", {
      alarmName: "prod-lambda-errors-critical",
      metric: new cloudwatch.Metric({
        namespace: "AWS/Lambda",
        metricName: "Errors",
        dimensionsMap: { FunctionName: "myapp-batch" },
        statistic: "Sum",
        period: cdk.Duration.minutes(15),
      }),
      threshold: 5,
      evaluationPeriods: 1,
    });
    lambdaErrorAlarm.addAlarmAction(new actions.SnsAction(alertTopic));
  }
}

---

Step 3: カスタムダッシュボードを自動生成

claude -p "
以下の情報を表示する CloudWatch ダッシュボードを CDK で生成して。

【ダッシュボード構成】
Row 1: システム全体ヘルス (ALBリクエスト数・5xx率・レイテンシ P50/P95/P99)
Row 2: ECSサービス (CPU・メモリ・実行タスク数)
Row 3: RDS (接続数・レイテンシ・CPU使用率)
Row 4: Lambda (実行回数・エラー数・実行時間)
Row 5: ビジネスメトリクス (新規登録数・決済成功率) ← カスタムメトリクス
"

// ダッシュボード定義 (抜粋)
const dashboard = new cloudwatch.Dashboard(this, "AppDashboard", {
  dashboardName: "myapp-production",
});

dashboard.addWidgets(
  new cloudwatch.Row(
    new cloudwatch.GraphWidget({
      title: "ALB リクエスト数",
      left: [new cloudwatch.Metric({
        namespace: "AWS/ApplicationELB",
        metricName: "RequestCount",
        statistic: "Sum",
        period: cdk.Duration.minutes(1),
      })],
      width: 8,
    }),
    new cloudwatch.GraphWidget({
      title: "ALB 5xx エラー率 (%)",
      left: [new cloudwatch.MathExpression({
        expression: "5xx / (2xx + 3xx + 4xx + 5xx) * 100",
        usingMetrics: {
          "5xx": new cloudwatch.Metric({ metricName: "HTTPCode_Target_5XX_Count", namespace: "AWS/ApplicationELB", statistic: "Sum" }),
          "2xx": new cloudwatch.Metric({ metricName: "HTTPCode_Target_2XX_Count", namespace: "AWS/ApplicationELB", statistic: "Sum" }),
          "3xx": new cloudwatch.Metric({ metricName: "HTTPCode_Target_3XX_Count", namespace: "AWS/ApplicationELB", statistic: "Sum" }),
          "4xx": new cloudwatch.Metric({ metricName: "HTTPCode_Target_4XX_Count", namespace: "AWS/ApplicationELB", statistic: "Sum" }),
        },
        period: cdk.Duration.minutes(1),
      })],
      width: 8,
    }),
  )
);

---

Step 4: インシデント調査を Claude Code に任せる

claude -p "
本番インシデントを調査したい。以下のコマンドを実行して結果を分析して:

1. aws logs filter-log-events --log-group-name '/ecs/myapp' \
   --start-time \$(date -d '2 hours ago' +%s000) \
   --filter-pattern 'ERROR' --limit 100

2. aws cloudwatch get-metric-statistics \
   --namespace AWS/ApplicationELB \
   --metric-name HTTPCode_Target_5XX_Count \
   --start-time \$(date -d '2 hours ago' -u +%Y-%m-%dT%H:%M:%SZ) \
   --end-time \$(date -u +%Y-%m-%dT%H:%M:%SZ) \
   --period 300 --statistics Sum

上記の結果を踏まえて:
- インシデントの開始時刻
- 影響を受けているユーザー数 (推定)
- 根本原因の仮説 (TOP3)
- 即時対応アクション
をまとめて
"

---

Step 5: カスタムメトリクスの自動設計

claude -p "
ECサイトのビジネスKPIを CloudWatch カスタムメトリクスとして
Node.js (AWS SDK v3) で計測するコードを生成して。

計測するメトリクス:
- 決済成功数・失敗数 (1分ごと)
- カート放棄率 (5分ごと)
- 新規会員登録数 (1時間ごと)

名前空間: MyApp/Business
各メトリクスに環境タグ (Production/Staging) を付与
"

// src/monitoring/business-metrics.ts
import { CloudWatchClient, PutMetricDataCommand } from "@aws-sdk/client-cloudwatch";

const cw = new CloudWatchClient({ region: process.env.AWS_REGION });
const NAMESPACE = "MyApp/Business";
const ENV = process.env.NODE_ENV ?? "development";

export async function recordPaymentSuccess() {
  await cw.send(new PutMetricDataCommand({
    Namespace: NAMESPACE,
    MetricData: [{
      MetricName: "PaymentSuccess",
      Value: 1,
      Unit: "Count",
      Dimensions: [{ Name: "Environment", Value: ENV }],
    }],
  }));
}

export async function recordPaymentFailure(reason: string) {
  await cw.send(new PutMetricDataCommand({
    Namespace: NAMESPACE,
    MetricData: [{
      MetricName: "PaymentFailure",
      Value: 1,
      Unit: "Count",
      Dimensions: [
        { Name: "Environment", Value: ENV },
        { Name: "Reason", Value: reason },
      ],
    }],
  }));
}

---

落とし穴4選

1. アラームの evaluationPeriods が短すぎる

// ❌ 瞬間的なスパイクでも即アラーム
evaluationPeriods: 1,
threshold: 10,

// ✅ 3期間連続で超えた時だけアラーム (誤検知防止)
evaluationPeriods: 3,
threshold: 10,
datapointsToAlarm: 2,  // 3期間中2回超過でアラーム

2. Log Insights のコストを考慮しない

Log Insights はスキャンしたデータ量に応じて課金されます。時間範囲を絞らずに実行すると想定外の料金に。--start-time --end-time を必ず指定しましょう。

3. カスタムメトリクスの高解像度は高コスト

標準メトリクス (60秒) は無料だが高解像度メトリクス (1秒) はコストが約10倍。ビジネスメトリクスは1分集計で十分なケースが多いです。

4. Lambda のログ保持期間を設定しない

デフォルトは「無期限」でストレージコストが増え続けます。ロググループの保持期間を必ず設定しましょう。

new logs.LogGroup(this, "AppLogGroup", {
  logGroupName: "/ecs/myapp",
  retention: logs.RetentionDays.ONE_MONTH,  // 30日で自動削除
});

---

まとめ

タスク	Claude Code の貢献
ログ分析	エラーログを読んで原因仮説と対応策を提示
Log Insights クエリ	分析目的を伝えるだけでクエリを生成
アラーム設定	システム構成を伝えるとCDKコードを一括生成
ダッシュボード	表示したい情報を伝えてウィジェット定義を生成
インシデント調査	AWS CLIコマンドを実行させて結果を分析

「モニタリングは後で設定しよう」と後回しにした結果、インシデント発生時に何もわからない——という状況は避けたい。Claude Code を使えば、30分で本番レベルのアラームとダッシュボードが揃います。

関連記事

• Claude Code × AWS ECS/Fargate 完全ガイド
• Claude Code × AWS CodePipeline/CodeBuild 完全ガイド
• Claude Code × AWS IAM 完全ガイド

参考資料

• Amazon CloudWatch 公式ドキュメント
• CloudWatch Log Insights クエリ構文
• CDK CloudWatch モジュール