はじめに

こんにちは。インフラエンジニアの鈴木です。

前回の記事「開発の手動構築を「AWS MCP Server」でサッとIaC管理へ移行しよう」では、手動構築した開発環境をAWS MCP Serverを使ってTerraform/CDKのコードに自動変換する方法を紹介しました。

今回はその第2弾として、「Terraform/CDKのリソース定義を起点に、監視アラートとCloudWatchダッシュボードを自動生成する」活用例を紹介します。

サービスを本番リリースする際、後回しになりがちなのが監視の整備とダッシュボードの作成です。機能開発やインフラ構築が優先され、「リリースしたけど監視もダッシュボードもまだない」という状況は、多くのプロジェクトで起こりがちです。

いざ着手しようとすると、以下のような作業が必要になります。

対象リソースの洗い出し（EC2、ALB、RDS、EFS...）
リソースごとの監視メトリクスの選定と閾値設計
ダッシュボード対象の選定
ダッシュボードの作成

本記事では、これらをClaude Code + AWS MCP Serverで一気に自動化する手順を紹介します。

なお、AWS MCP Serverの導入・設定方法は前回の記事で詳しく解説していますので、そちらをご参照ください。

今回やること

以下の3ステップで、Terraform/CDKのリソース定義から監視アラートとCloudWatchダッシュボードを生成するまでを自動化します。

flowchart LR
    A[Terraform/CDK<br>リソース定義] -->|Step1| B[本番リソース<br>読み取り]
    B -->|Step2| C[監視アラート<br>作成]
    B -->|Step3| D[ダッシュボード<br>作成]

ステップ	やること	使うもの
Step1	リソース定義から本番リソースを読み取る	Claude Code（コード読解）
Step2	監視アラートを設計しTerraformコードを生成する	Claude Code + AWS Docs MCP
Step3	ダッシュボードJSONを生成しデプロイする	Claude Code + AWS API MCP

この自動化によって期待できる効果｜半日〜1日→60分以内

監視への対応コストが圧倒的に減り、更新も容易な形を保てます。

Before: 手動で監視アラートとダッシュボードを作成する場合

対象リソースの洗い出し（EC2、ALB、RDS、EFS...）.. 1時間
リソースごとの監視メトリクスの選定と閾値設計.. 3~4時間
ダッシュボード対象の選定.. 1時間
ダッシュボードの作成.. 3~4時間

合計: 半日〜1日

After: Claude Code + AWS MCPを使う場合

プロンプトを投げる ... 5分
生成結果を確認しフィードバック ... 40分
最終確認 ... 10分

合計: 60分以内

その他のメリット

メトリクスの抜け漏れが減る: Claude CodeがAWSドキュメントを参照して推奨メトリクスを提案するため、「CloudFrontのCacheHitRate入れ忘れた」のような見落としが起きにくい
IaCとの連携: IaCの定義を起点にしているため、リソースの追加・削除に合わせて監視もダッシュボードも更新しやすい
横展開が容易: 一度作ったプロンプトのパターンを別のサービスに使い回せるため、2つ目以降の作成がさらに速くなる

では、ここから実際の手順を説明していきます。

手順

※ここではIaCがTerraformの想定で手順を記載していますが、CDKの場合も同様に、lib/配下のスタック定義から同様の手順を実施できます。

Step1: 本番リソースを読み取る

プロンプト例

Terraformのリソース定義（infra/prod/配下）を読んで、
Productionの監視対象リソースを一覧にしてください。

リソース種別、リソース名、用途をテーブル形式で整理してください。

出力例

Claude Codeはinfra/prod/配下の.tfファイルを順に読み、リソースを抽出してくれます。

Terraformの定義を確認しました。Productionの監視対象リソースは以下の通りです。

| リソース種別 | リソース名 | 用途 |
|------------|-----------|------|
| EC2 | myapp-prod-admin | アプリ管理用 |
| ALB | myapp-prod-user | ユーザー向け |
| ALB | myapp-prod-admin | 管理画面向け |
| Aurora MySQL | myapp-prod-cluster | Writer + Reader |
| EFS | myapp-prod | 共有ストレージ |
| CloudFront | myapp-prod-distribution | CDN配信 |
| WAF | myapp-prod-user | CloudFrontスコープ |
| WAF | myapp-prod-admin | ALBスコープ（REGIONAL） |

合計8リソースを検出しました。

Step2: 監視アラートを作成する

プロンプト例

上記のリソース一覧に対して、CloudWatchアラームを設計し
Terraformコードを生成してください。

条件:
- リソース種別ごとに推奨メトリクスと閾値を選定
- severityレベル（Critical/Warning/Notice）で分類
- 既存プロジェクトのmonitoring構成（infra/prod/monitoring/）を参考にする

出力例

Claude CodeはAWS MCPのドキュメント検索機能（aws-documentation-mcp-server）を使って各サービスの推奨メトリクスを調べた上で、Terraformコードを生成してくれます。

各リソースの監視アラームを設計しました。

| カテゴリ | メトリクス | 閾値 | Severity |
|---------|-----------|------|----------|
| ALB User | HTTPCode_Target_5XX_Count | 1分間で10件以上 | Critical |
| ALB User | TargetResponseTime | 平均3秒以上 | Warning |
| Aurora WRITER | CPUUtilization | 80%以上 | Warning |
| Aurora WRITER | DatabaseConnections | max_connectionsの80% | Warning |
| EC2 Admin | disk_used_percent | 95%以上 | Critical |
| EC2 Admin | disk_used_percent | 80%以上 | Warning |
| EFS | PercentIOLimit | 90%以上 | Warning |
| CloudFront | 5xxErrorRate | 1%以上 | Critical |
| WAF User | BlockedRequests | 1分間で100件以上 | Notice |

infra/prod/monitoring/alarms.tf を生成しました。

ここでAWS Docs MCPが活躍します。例えばAuroraのDatabaseConnectionsの上限値や、CloudFrontメトリクスがus-east-1でしか取得できないといった仕様を、ドキュメントから自動で拾ってくれます。手動だと見落としやすいポイントです。

また、「既存プロジェクトを参考に」と指示すれば、Claude Codeがそのコードを読んで既存アラートパターンやファイル構成を踏襲してくれるため、プロジェクト内の一貫性も保てます。

あとはTerraformを適用するだけで監視アラートの出来上がりです。

Step3: ダッシュボードを作成する

プロンプト例

Step1のリソース一覧に対して、CloudWatchダッシュボードを作成してください。

手順:
1. AWS MCP Serverを使って各リソースのIDを取得
2. ダッシュボードのJSONを生成
3. AWS CLIでデプロイ

条件:
- ダッシュボード名: myapp-prod
- プロファイル: myapp-prod-admin
- リソース種別ごとに推奨メトリクスを選定（Namespace、Period含む）
- ALBやAuroraはPeriod 1分、EC2やWAFはPeriod 5分
- CloudFrontとWAF(CLOUDFRONT scope)はus-east-1のメトリクスを使用

出力例

Claude Codeは3つのサブステップを順に実行します。

サブステップ1: リソースID取得

AWS API MCP（aws-api-mcp-server）を使って、各リソースのIDを自動取得します。

AWS MCP Serverを使ってリソースIDを取得します。

[MCP call_aws] aws elbv2 describe-load-balancers --names myapp-prod-user ...
[MCP call_aws] aws rds describe-db-clusters ...
[MCP call_aws] aws efs describe-file-systems ...
[MCP call_aws] aws cloudfront list-distributions ...

リソースIDの取得が完了しました:

| リソース | ID |
|---------|-----|
| EC2 Admin | i-0abc1234def56789 |
| ALB User | app/myapp-prod-user/1234567890abcdef |
| ALB Admin | app/myapp-prod-admin/abcdef1234567890 |
| Aurora Cluster | myapp-prod-cluster |
| EFS | fs-0abc1234 |
| CloudFront | E1ABC2DEF3GHIJ |
| WAF User | myapp-prod-user |

サブステップ2: ダッシュボードJSON生成

取得したリソースIDを埋め込んだダッシュボードJSONを生成します。ウィジェットの配置（x, y, width, height）やAnnotation（閾値ライン）も自動で設定されます。

{
  "widgets": [
    {
      "type": "text",
      "x": 0, "y": 0, "width": 24, "height": 1,
      "properties": {
        "markdown": "## ALB User (myapp-prod-user)"
      }
    },
    {
      "type": "metric",
      "x": 0, "y": 1, "width": 8, "height": 6,
      "properties": {
        "title": "RequestCount",
        "region": "ap-northeast-1",
        "metrics": [
          ["AWS/ApplicationELB", "RequestCount",
           "LoadBalancer", "app/myapp-prod-user/1234567890abcdef",
           {"stat": "Sum"}]
        ],
        "period": 60
      }
    }
  ]
}

（実際には全リソース分のウィジェットが生成されますが、ここでは抜粋しています）

サブステップ3: CLIでデプロイ

生成したJSONをファイルに保存し、AWS CLIでデプロイします。

[MCP call_aws] aws cloudwatch put-dashboard --dashboard-name "myapp-prod" --dashboard-body file:///tmp/dashboard.json
→ {"DashboardValidationMessages": []}

ダッシュボードの作成が完了しました。
<https://ap-northeast-1.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1#dashboards:name=><ダッシュボード名>

実際に生成されたダッシュボードのレイアウトイメージは以下の通りです。

(記事用のサンプルダッシュボード）

実践編: 一括依頼とフィードバックサイクル

ここまでのStep1〜3は整理されたプロンプト例を紹介しましたが、さらにシンプルに進めることもできます。
実際のプロジェクトでは、Step1〜3を個別に指示するのではなく、一つのプロンプトで一括依頼して進めました。

一括依頼プロンプト

対象サービスの監視とCloudWatchダッシュボードを検討してください

インプット:
- 構築手順書（infra/doc/build-guide.md）
- Terraformリソース定義

アウトプット:
- 監視とダッシュボード設計書
- productionフォルダにmonitoringフォルダを作って監視リソースを定義
- ダッシュボードをCLIで構築する手順書

チームリーダ、作業者、レビューアでチームを組んで実行してください。
不明点はチームリーダが判断して、必要あればこちらに確認してください。

ポイントはインプットとアウトプットを明示すること、Claude CodeのAgent Team機能(※)で役割分担を指示すること、「不明点はチームリーダが判断」と自律的に判断させることの3つです。

これだけで、リソースの洗い出しから設計、Terraformコード生成、ダッシュボードのCLIコマンド作成まで一気に進めてくれます。

※Agent Team機能を使うとAIに任せられる作業範囲が広がるため、私は利用していますが、使わずに1つずつ作業していくことももちろんOKです。

さらにフィードバックで段階的に完成度を上げる

とはいえ、一発で完璧な成果物が出てくることは稀です。

主に監視項目・ダッシュボード項目の過不足が発生します。

プロジェクトの監視要件や設計と一部合わないものが、全体の1〜2割程度発生することがあります。

そのため、数回フィードバックを重ねて完成度を上げていきます。

flowchart TD
    A[初回プロンプト<br>一括依頼] --> B[成果物v1]
    B --> C{レビュー}
    C -->|監視設定の改善| D[監視構成の見直し]
    C -->|ダッシュボード構成の改善| E[ダッシュボード見直し]
    C -->|設計書との突合| F[設計書との整合性確認]
    D --> G[成果物更新]
    E --> G
    F --> G
    G --> C
    C -->|完了| H[最終成果物]

重要なのは最初から完璧を目指さないことです。大枠を作り、フィードバックで詰めていく方が効率的です。

ちなみに監視とダッシュボードを一括で作成しているのは、この2つは類似の内容になることが多く、まとめて作った方が修正しやすいためです。

（先に紹介した手順のように監視とダッシュボードをStepで作成しても問題ありませんが、私はまとめて作るのがお薦めです。）

まとめ

Terraform/CDKのリソース定義をClaude Codeに読ませることで、監視対象リソースの洗い出しを自動化できる
AWS Docs MCPがサービスごとの推奨メトリクスやリージョン制約を自動で補完してくれる
監視アラートのIaCコードもダッシュボードJSONもまとめて自動生成できる
手動で半日〜1日かかっていた監視構築作業が60分以内で完了する
リソースの追加・削除に合わせて監視アラートもダッシュボードも更新しやすい

いかがでしたでしょうか。

前回のIaC移行に続き、AWS MCP Serverの活用例をお届けしました。リソース管理の自動化だけでなく、監視・可観測性の整備にもMCPが活躍するのはAWS MCPの万能性が窺えます。

AWS MCPの活用例は今後も紹介していきますので皆さんぜひ活用してみてください。

さいごに

「これ、自分ならこう作るのに」——そう思ったこと、ありませんか?

askenでは、【ひとびとの明日を今日より健康にする】ために、課題を見つけて自ら動けるエンジニアが裁量を持ってプロダクトを前に進めています。

そんな環境に興味があれば、ぜひ一緒にやりませんか?

↓↓まずはカジュアルにお話ししましょう。

https://hrmos.co/pages/asken/jobs/00_00

asken techのXアカウントで、askenのテックブログやイベント情報など、エンジニアリングに関する最新情報を発信していますので、ぜひフォローをお願いします！

Follow @asken_dev

asken テックブログ

AWS MCPで監視アラートとダッシュボードを自動生成しよう

はじめに

今回やること

この自動化によって期待できる効果｜半日〜1日→60分以内

Before: 手動で監視アラートとダッシュボードを作成する場合

After: Claude Code + AWS MCPを使う場合

その他のメリット

手順

Step1: 本番リソースを読み取る

プロンプト例

出力例

Step2: 監視アラートを作成する

プロンプト例

出力例

Step3: ダッシュボードを作成する

プロンプト例

出力例

実践編: 一括依頼とフィードバックサイクル

一括依頼プロンプト

さらにフィードバックで段階的に完成度を上げる

まとめ

さいごに

はじめに

今回やること

この自動化によって期待できる効果 ｜半日〜1日→60分以内

Before: 手動で監視アラートとダッシュボードを作成する場合

After: Claude Code + AWS MCPを使う場合

その他のメリット

手順

Step1: 本番リソースを読み取る

プロンプト例

出力例

Step2: 監視アラートを作成する

プロンプト例

出力例

Step3: ダッシュボードを作成する

プロンプト例

出力例

実践編: 一括依頼とフィードバックサイクル

一括依頼プロンプト

さらにフィードバックで段階的に完成度を上げる

まとめ

さいごに

この自動化によって期待できる効果｜半日〜1日→60分以内