【AWS MCP Server GA】AIエージェントが300以上のAWSサービスに安全接続できるようになった

AI × Infrastructure

この記事の概要

2026年5月9日、AWS が管理型リモート MCP サーバー「AWS MCP Server」の一般提供(GA)を発表しました。
Claude Code・Kiro・Cursor などの AI コーディングツールに数行の設定を追加するだけで、AIエージェントが最新の AWS ドキュメントを参照しながら、15,000 以上の AWS API を IAM 認証付きで安全に呼び出せるようになります。
追加料金はなく、今日からすぐ使えます。


AIコーディングツールが「古い AWS」しか知らない問題から解放される

Claude Code や Cursor などの AI コーディングツールを使っていると、こんな場面に遭遇したことはないでしょうか。

「S3 にベクトルデータを保存したい」と聞いたら、pgvector や Pinecone の話が返ってきた——でも 2025年末に GA になった Amazon S3 Vectors という専用サービスがあるのに、AI はそれを知らなかった。

これはバグではなく、構造的な問題です。大規模言語モデルには「学習カットオフ」があり、それ以降のサービスや API 変更を知ることができません。
インフラ分野では新機能のリリースサイクルが早いため、数ヶ月前の知識では「動くが本番向きではない」コードや「存在しないサービス名」が生成されてしまいます。

AWS MCP Server はこの問題を解決するために設計された、クラウドインフラエンジニア待望のツールです。


AIモデルの学習カットオフと「IAMキーを渡す」リスクという2つの壁

AWS MCP Server GA 以前、AI エージェントに AWS を操作させようとすると、主に2つの課題がありました。

① ドキュメント・知識の陳腐化

モデルの学習データは常に数ヶ月〜1年以上古い状態です。
Amazon Aurora DSQL、Amazon Bedrock AgentCore、S3 Vectors といった 2025 年以降の新サービスは、ほとんどのモデルが知りません。
エージェントが古い知識で生成したコードは「一見動くが非推奨 API を使っている」「より適切なマネージドサービスが存在するのに自前実装している」という状態になりがちです。

② IAMキーの過剰付与とセキュリティリスク

エージェントに AWS を操作させる場合、これまでは環境変数にアクセスキーを渡す方法が一般的でした。
しかしエージェントは必要以上に広い権限で動作しがちで、操作ログの追跡も困難でした。
「エージェントが何をしたか」を CloudTrail で追うのは簡単ではなく、コンプライアンス要件を満たすのが難しい状況でした。

AWS MCP Server は、この2つの課題を同時に解決します。


実際に Claude Code + AWS MCP Server を設定してみる

セットアップ手順

前提として uv(Python パッケージマネージャ)が必要です。

# uv のインストール
curl -LsSf https://astral.sh/uv/install.sh | sh

# AWS MCP Server を Claude Code に登録
claude mcp add-json aws-mcp --scope user \
  '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=ap-northeast-1"]}'

--scope user でこのマシン全体に適用。AWS_REGION は東京の場合 ap-northeast-1

# Claude Code 内で実行
/mcp
# → aws-mcp が connected 状態になっていれば OK

既存の AWS CLI 認証情報が自動使用されるため、追加のキー発行は不要です。

AWS MCP Server が提供する主要ツール

ツール名 役割
call_aws 15,000+ API オペレーションを実行(IAM 認証済み)
search_documentation 最新の AWS ドキュメントを検索
read_documentation 特定ドキュメントページを取得
run_script Python スクリプトをサーバーサイドのサンドボックスで実行

実務での活用シナリオ

シナリオ①: IaC コード生成の精度向上

「ECS Fargate タスク定義を Terraform で書いて」に対し、最新 Terraform AWS プロバイダーのドキュメントを参照し正確なコードを生成します。

シナリオ②: 複数 API を連携した調査タスク

「CPU 使用率が高い ECS サービスとデプロイ履歴をレポートして」という依頼を run_script で一発処理。CloudWatch → ECS 履歴の取得・集計を1回のサーバーサイド実行で完了します。

# run_script で実行されるコード例(エージェントが自動生成)
import boto3
from datetime import datetime, timedelta

ecs = boto3.client('ecs', region_name='ap-northeast-1')
cw = boto3.client('cloudwatch', region_name='ap-northeast-1')

# CPU 使用率の高いサービスを特定
services = ecs.list_services(cluster='production')['serviceArns']
# ... (以下、エージェントが状況に応じて生成)

シナリオ③: IAM ポリシーの最小権限化

Lambda のコードを解析し、AWS ドキュメントを参照しながら必要な Action のみの最小権限ポリシーを自動生成します。


今すぐ設定できる。追加コストゼロ。監査証跡も完備

AWS MCP Server の採用を後押しする重要なポイントをまとめます。

コスト面:
MCP サーバー自体の利用料金は無料です。
エージェントが実際に呼び出した AWS API で発生するリソースコストのみ課金されます。

セキュリティ面:
IAM コンテキストキーを使って、MCP サーバー経由のアクセスにのみ適用されるポリシーを記述できます。
例えば「MCP 経由では読み取り専用」「MCP 経由では特定バケットのみアクセス可」といった制御が標準 IAM ポリシーで表現できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["s3:DeleteObject", "ec2:TerminateInstances"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:CalledVia": ["aws-mcp.amazonaws.com"]
        }
      }
    }
  ]
}

監査面:
すべての API 呼び出しは CloudTrail に記録されます。
CloudWatch には AWS-MCP 名前空間でメトリクスが発行されるため、「エージェントが何をいつ呼び出したか」を人間の操作と分離して追跡できます。

対応クライアント:
Claude Code、Kiro、Cursor、Codex など、MCP をサポートするすべてのツールで使用可能です。


まとめ

AWS MCP Server の登場は、インフラエンジニアが AI コーディングツールを使う上での「知識の陳腐化」と「権限管理の複雑さ」という2つの根本的な課題を解決します。

設定は10分以内で完了し、既存の IAM 認証情報をそのまま使えます。
call_aws ツールによる 15,000 以上の API への認証済みアクセスと、最新ドキュメントの動的参照が組み合わさることで、エージェントが生成するインフラコードの品質が大きく向上します。

日々 AWS を触るインフラエンジニアにとって、今最も費用対効果の高い「AI 活用の一手」です。
まずはローカル環境に設定して、普段の調査・IaC 生成タスクで試してみてください。


参考リンク

コメント