![[アップデート] CloudWatch Application Signals MCP サーバーが公開されました](https://images.ctfassets.net/ct0aopd36mqt/4AJd3M26yescaNaY21CYmQ/9730e95c53a7b3049c6da6d4c0b1dec9/mcp.png)
[アップデート] CloudWatch Application Signals MCP サーバーが公開されました
2025.07.12こんにちは。クラウド事業本部の枡川です。
先日 CloudWatch MCP サーバーと CloudWatch Application Signals MCP サーバーが利用できるようになりました。
生成 AI を使って運用時のトラブルシューティングが楽になると嬉しいですよね！
本記事では CloudWatch Application Signals MCP サーバーにフォーカスして試してみます。
CloudWatch Application Signals MCP サーバー
CloudWatch Application Signals とは？
OpenTelemetry 互換のアプリケーションパフォーマンスモニタリングを実現するための CloudWatch の 1 機能です。
Observability を簡単に整備できることが大きなメリットで、ドキュメント通り設定するだけでアプリケーションへの自動計装も完了します。
もちろん組み込みダッシュボードも存在しており、SLO（サービスレベル目標）や SLI（サービスレベル指標）を扱えることも大きな特徴です。
Application Signals MCP サーバーでできること
できることをざっくりまとめると下記のようになります。
| Available Tools | 概要 |
|---|---|
| list_monitored_services | Application Signals で監視されている全サービスの一覧を取得 |
| get_service_detail | 特定サービスの詳細情報を取得 |
| list_slis | 全サービスの SLO/SLI ステータスを一覧取得 |
| get_slo | 特定 SLO の詳細情報を取得 |
| search_transaction_spans | Transaction Search を使った OTel Spans データのクエリ |
| query_sampled_traces | AWS X-Ray トレースをクエリしてインサイトを取得 |
| query_service_metrics | Application Signals メトリクスをクエリ |
AWS 上でトレースをクエリしてインサイトを得ようとすると専用のクエリ方式を扱う必要があります。
例えば応答時間が 5 秒を超えたリクエストを取得しようとした場合、下記のように書けます。
responsetime > 5
これだけだと簡単ですが、サービスや URL、ステータスコードなども含めて条件が複雑になってくると、どんどん複雑なクエリになっていきます。
昨年 Transaction Search が登場してトレースの分析が簡単になりましたが、AI に指示したら情報まとめてくれた方が嬉しい場面もあると思います。
とはいえ、Transaction Search のビジュアルエディタはフィルタ式を書かなくても簡単に分析できてとても良いです。
トレースの分析という観点だけだとまだまだ Transaction Search を見たいなとも思います。
なので、ローカル環境にある各種ソースコードと Application Signals で得られる情報の両方を AI に読み込ませて動作させることができるというのが一つの肝に思いました。
こんな感じで各種メトリクス情報と各種ソースコードを理解した AI がコードの問題点まで調査してくれたら最高ですよね。
※ 上記画像の際は AWS CLI を実行させて AWS の情報を取得させてます。
使ってみる
今回は AWS が公開している application-signals-demo を利用してデモ環境を作成しました。
その状態で Application Signals MCP サーバーリポジトリの README.md 記載の通り、 Cursor に MCP サーバーの設定を行います。
Add to Cursor と記載してあるので、そこをクリックして追加しました。
ただ、普通に追加すると MCP 名と Tool 名の組み合わせが長いと怒られました。
(わかる、CloudWatch Application Signals MCP サーバーって長いよね、良い略し方を提案して欲しい)
CloudWatch は自明なので省いてあげて、最終的な設定は下記の通りになりました。
{
"awslabs.appsignals-mcp-server": {
"autoApprove": [],
"disabled": false,
"timeout": 60,
"command": "uvx awslabs.cloudwatch-appsignals-mcp-server@latest",
"env": {
"AWS_PROFILE": "<利用するプロファイル名>",
"AWS_REGION": "ap-northeast-1",
"FASTMCP_LOG_LEVEL": "ERROR"
},
"transportType": "stdio"
}
}
では聞いてみます。
まずは監視されているサービス一覧を確認します。
list_monitored_services を利用して正確に回答してくれました。
次の SLO の状態を聞いてみると、list_slis を利用して確認してくれました。
Transaction Search が有効であるので、100% のトレース可視性があることも伝えてくれています。
どうやら Transaction Search が有効な時に使える search_transaction_spans を利用しないと、全てのトレースを見て回答することはできないようです。
Transaction Search は X-Ray トレース設定で明示的に有効化しないと利用できないので、こちらは注意が必要です。
個別のサービス (payment-service-dotnet) について聞くと、get_service_detail や query_service_metrics を利用して、状態をまとめてくれました！
Application Signals の Error メトリクスや Latency メトリクスから情報を持ってきているようです。
最後に
CloudWatch Application Signals MCP サーバーを試してみました。
生成 AI による運用負荷低減は、多くの人が望んでいる所ではないでしょうか。
今回は触ってみるだけに留まりましたが、より実践的なシナリオを作ってトラブルシューティングさせるといったことも試していこうと思います！
