AWS MCP Server (Preview) にCloudWatch監視とセマンティック検索が追加 — AIアシスタントのAWS操作をどう変えるか
aws.amazon.com 
docs.aws.amazon.com 
AWS MCP Server（Preview）に、CloudWatchメトリクスの自動発行とセマンティック検索によるAgent SOPs発見が追加されました（2026年3月19日 AWS What’s New）。
「AIアシスタントにAWSを操作させる」というユースケースが現実的になってきた中で、運用監視とワークフロー発見という2つの実用的な機能が加わった形です。実際にClaude Codeから接続して検証してみたので、何ができるのか、そしてAWS CLIとの使い分けについて考えてみます。
AWS MCP Serverとは
AWS MCP Server（Preview）は、AWSがホストするマネージドのリモートMCPサーバーです。AIアシスタント（Claude Code、Amazon Q Developer、Cursor等）に対して、AWSサービスへのセキュアなアクセスを提供します。
- エンドポイント:
https://aws-mcp.us-east-1.api.aws/mcp（us-east-1のみ、Preview） - 料金: MCPサーバー自体は無料。AWSリソースの使用料のみ
- 認証: SigV4署名によるIAM認証
提供されるツールは以下の3種類です。
| ツール | 機能 |
|---|---|
call_aws | 15,000以上のAWS APIをSigV4認証で実行 |
search_documentation | AWSドキュメント＋Agent SOPsのセマンティック検索 |
retrieve_agent_sop | 事前構築ワークフロー（Agent SOP）の取得 |
加えて、suggest_aws_commands（CLIコマンドの提案）、read_documentation（ドキュメント読み込み）、recommend（関連ドキュメント推薦）、get_regional_availability（リージョン対応状況）、list_regions（リージョン一覧）も利用できます。
今回のアップデート
CloudWatchメトリクスの自動発行
AWS MCP Serverの利用状況がAWS-MCP名前空間でCloudWatchに自動記録されるようになりました。追加コストはありません。
| メトリクス | 内容 |
|---|---|
| Invocations | ツールの呼び出し回数 |
| SuccessCount | 成功した呼び出し数 |
| ClientErrors | クライアントエラー数 |
| ServerErrors | サーバーエラー数 |
| ThrottleCount | スロットリング発生数 |
ツールごと（call_aws、retrieve_agent_sopなど）にメトリクスが記録されるため、「どのツールがどれだけ使われているか」「エラー率が閾値を超えたらアラーム」といった運用が可能になります。
これまではAIアシスタント経由のAWS操作を監視する手段がなかったので、本番環境でMCPを使うための重要な一歩だと思います。
セマンティック検索によるAgent SOPs発見
search_documentationツールが、ドキュメント検索に加えてセマンティック類似度でAgent SOPsも返すようになりました。
以前は利用可能なSOPを知るためにはSOPの名前を正確に知っている必要がありましたが、今回のアップデートで自然言語クエリから関連するSOPを発見できるようになっています。
Claude Codeから実際に試してみた
セットアップ
プロジェクトの.mcp.jsonに以下を設定します。
{
"mcpServers": {
"aws-mcp": {
"command": "uvx",
"timeout": 100000,
"transport": "stdio",
"args": [
"mcp-proxy-for-aws@latest",
"https://aws-mcp.us-east-1.api.aws/mcp",
"--metadata", "AWS_REGION=ap-northeast-1"
],
"env": {
"AWS_PROFILE": "your-profile"
}
}
}
}uvx（uvのツール実行機能）とmcp-proxy-for-awsを使ってローカルからリモートMCPサーバーに接続します。--metadata AWS_REGIONで操作対象リージョンを指定できます。
Claude Codeを再起動すると、ツールが自動的に読み込まれます。
call_aws — AWS APIの実行
call_awsはAWS CLIコマンドをMCPサーバー経由で実行するツールです。
> call_aws: aws sts get-caller-identity{
"UserId": "AROA...:user@example.com",
"Account": "123456789012",
"Arn": "arn:aws:sts::123456789012:assumed-role/..."
}> call_aws: aws ec2 describe-vpcs --query "Vpcs[].{VpcId:VpcId,CidrBlock:CidrBlock}"[
{
"VpcId": "vpc-00d05578c115a2227",
"CidrBlock": "10.1.128.0/18"
}
]AWS CLIと同じ構文でコマンドを渡すとSigV4認証で実行してくれます。シェルパイプやリダイレクトは使えませんが、--queryによるフィルタリングは利用可能です。
search_documentation — セマンティック検索
ドキュメント検索とAgent SOPsの発見を同時に行えます。
> search_documentation: "deploy Lambda function with API Gateway"
topics: ["agent_sops"]結果として、以下のSOPが返ってきました。
| 順位 | SOP名 | 概要 |
|---|---|---|
| 1 | lambda-gateway-api | REST/HTTP APIの作成とLambda関数への接続 |
| 2 | create_api_gateway_stage | API Gatewayステージの作成 |
| 3 | deploy-supabase-app | SupabaseアプリのAWSデプロイ |
| 4 | deploy-webapp | Webアプリのデプロイ（静的サイト含む） |
| 5 | lambda-vpc-internet-access | VPC内Lambda関数のインターネットアクセス |
「Lambda API Gateway」という自然言語の検索クエリから、関連するSOPが正確にランク付けされて返ってきています。これがセマンティック検索の効果です。
retrieve_agent_sop — ワークフロー取得
検索で見つかったSOPの中身を取得してみます。
> retrieve_agent_sop: "lambda-gateway-api"返ってきたのは、14ステップからなる詳細な手順書でした。
- 依存関係の検証 — 必要なツールの確認
- Lambda関数の存在確認 —
aws lambda get-function - REST API Gatewayの作成 —
aws apigateway create-rest-api - APIリソースの作成 —
aws apigateway create-resource - HTTPメソッドの作成 — 認可タイプの設定
- Lambda統合の設定 —
AWS_PROXY統合 - メソッドレスポンスの設定
- 統合レスポンスの設定
- セキュリティ設定 — スロットリング、WAF、ログ
- CORS設定（条件付き）
- Lambda実行権限の付与
- APIのデプロイ
- エンドポイントURLの取得
- 統合テスト
各ステップにはConstraints（制約条件）が付いており、「authorization_typeがNONEの場合は警告を出す」「bodyフィールドはJSON文字列化が必要」といったベストプラクティスが組み込まれています。
これはただの手順書ではなく、AIアシスタントが実行するためのプロンプトです。Claude CodeがこのSOPに従ってステップバイステップでAWS APIを呼び出すことで、Lambda + API Gatewayの構築を自動化できます。
MCP vs AWS CLI — どう使い分けるか
ここで避けて通れないのが、「MCP vs CLI」の議論です。
2026年2月に公開されたベンチマークでは、CLIの方がMCPより35倍トークン効率が良いという結果が出ています。
| MCP | CLI | |
|---|---|---|
| トークン消費 | ~145,000トークン | ~4,150トークン |
| Token Efficiency Score | 152 | 202（33%優位） |
| コンテキスト圧迫 | ツールスキーマで~55,000トークン消費 | LLMの学習データに含まれるため追加不要 |
CLIが効率的な理由はシンプルです。LLMはすでにAWS CLIの使い方を学習しているため、スキーマ定義を追加で読み込む必要がありません。一方MCPは、利用可能なツールのスキーマをコンテキストに載せる必要があるため、その分トークンを消費します。
ではMCPは不要なのか？
単純な1コマンドの実行であればCLIの方が効率的です。しかし、以下のケースではMCPに優位性があります。
Agent SOPsによる複雑なワークフロー: 上で見たlambda-gateway-apiのように、14ステップの手順を正しい順序・正しいパラメータで実行するのは、CLIだけでは「LLMの知識頼み」になります。SOPという形で手順が構造化されていることで、再現性と信頼性が上がります。
セマンティック検索: 「何をしたいか」を自然言語で伝えるだけで、関連するドキュメントとSOPが見つかります。CLIではまず正しいサービス名とサブコマンドを知っている必要があります。
認証の統一: MCPサーバーがSigV4署名を処理するため、AIアシスタント側でAWSクレデンシャルの取り扱いを意識する必要がありません。
運用監視: 今回追加されたCloudWatchメトリクスにより、AIアシスタント経由のAWS操作を可視化・アラートできます。CLIをシェルから直接実行する場合、この粒度の監視は別途構築が必要です。
現実的な使い分け
| ユースケース | 推奨 |
|---|---|
| 単発のAWS API呼び出し（describe、list等） | CLIが効率的 |
| 複数ステップの構築作業 | MCP（Agent SOPs）が信頼性高い |
| ドキュメント調査・手順の発見 | MCP（セマンティック検索）が便利 |
| ローカルファイルを扱う操作（S3アップロード等） | CLIのみ対応 |
| 本番環境でのAI操作の監視 | MCP（CloudWatchメトリクス） |
自分の検証では、Claude Codeの場合はCLI実行もMCPツール呼び出しも両方使えるため、実際には併用が最も実用的だと感じました。単純な確認はCLI、複雑な構築作業はMCPという使い分けです。
OSS版との違い
AWS MCP Serverには、今回取り上げたマネージド版（Preview）の他に、OSS版もあります。
| マネージド版（Preview） | OSS版 | |
|---|---|---|
| 実行場所 | AWSホスト（リモート） | ローカル実行 |
| 接続方式 | mcp-proxy-for-aws経由 | 直接起動 |
| ツール | 統一された7ツール | サービスごとに個別サーバー |
| Agent SOPs | あり | なし |
| CloudWatch監視 | あり（今回追加） | なし |
| リージョン | us-east-1のみ | 任意 |
OSS版はサービスごとに個別のMCPサーバー（ECS、EKS、Lambda等）を起動する形式で、きめ細かい制御が可能です。一方マネージド版は単一エンドポイントで全サービスにアクセスでき、Agent SOPsと監視機能が付いています。
注意点
- Preview: まだプレビュー段階のため、本番利用は慎重に。エンドポイントや仕様が変更される可能性があります
- リージョン: エンドポイントはus-east-1のみ。
--metadata AWS_REGIONで操作対象リージョンは指定できますが、MCPサーバー自体はus-east-1で動作します - ローカルファイル非対応:
call_awsはリモート実行のため、aws s3 cpのようなローカルファイルを扱うコマンドは使えません。その場合はシェルからCLIを直接実行する必要があります - CloudWatchメトリクスの反映: メトリクスの反映にはラグがあります。検証時、ツール実行直後にはデータポイントが確認できませんでした
まとめ
AWS MCP Serverの今回のアップデートは、「AIにAWSを操作させる」ことを本番環境で使うための基盤が整い始めたという印象です。
- CloudWatchメトリクスで操作の可視化・アラートが可能に
- セマンティック検索でAgent SOPsの発見が自然言語で可能に
- Agent SOPs自体がAIアシスタント向けの構造化されたワークフローとして機能
一方で、単純なAPI呼び出しにはCLIの方がトークン効率が良いという現実もあります。CLIとMCPは対立するものではなく、補完し合うものとして併用するのが現時点では最も実用的なアプローチだと思います。