AWS MCPサーバー入門2026｜使い方・料金・設定を解説

2026年5月6日、AWSがMCPサーバーのGA（一般提供）を発表した。対応API数は15,000超。S3もLambdaもCloudFormationも、たった1つのエンドポイントから操作できる。OSS版で25個以上に分かれていたサーバーを統合し、IAMポリシーでアクセス制御まで組み込んだ構成だ。

従来の構成を振り返ると面倒さが際立つ。S3用のMCPサーバー、Lambda用、CloudFormation用…それぞれ個別にインストールし、認証を通していた。GA版はこの手間を一掃する。ローカルに置くのは軽量プロキシだけ。処理はAWS側のリモートサーバーが引き受ける。

料金はゼロ。正確には、MCPサーバー自体の課金がない。発生するのはエージェントが実際に消費したAWSリソースの料金だけだ。セットアップからIAM設計、ユースケースまで検証した結果をまとめた。

AWS MCPサーバーとは — OSSからマネージドへの転換

MCPの基礎をおさらい

MCP（Model Context Protocol）は、AIモデルが外部ツールやデータソースに接続するためのオープンプロトコルだ。Anthropicが2024年に提唱し、2026年5月時点でレジストリ登録は12,000サーバーを超えた。SDK月間ダウンロードは9,700万件に達している。

MCPの仕組みを一言で表すなら「AIエージェントが閉じ込められたターミナルの壁にドアを開ける」こと。エージェントはMCPサーバーを通じてファイル操作、API呼び出し、データベース接続など外部リソースに手を伸ばせる。詳しくはMCPとは？Model Context Protocol完全解説で解説している。

OSS版からGA版で何が変わったか

AWSは2025年末のre:Invent以降、GitHub上のawslabs/mcpリポジトリでOSS版MCPサーバーを25種類以上公開していた。S3、Lambda、CloudFormation、Bedrock、DynamoDB…サービスごとに別々のサーバーをインストールし、それぞれに認証を通す構成だった。

GA版は設計思想が違う。

主要機能 — 4つのコアツール

提供するツールは4つ。これだけでAWSインフラの操作・分析・ドキュメント参照を網羅する。

call_aws — 15,000超のAPIを1ツールで

GA版の中核。エージェントが「S3バケットを作って」「Lambdaのログを見せて」と頼むと、call_awsが該当するAWS APIを自動で選んで実行する。OSS版では@aws-mcp/s3と@aws-mcp/lambdaを別々にインストールしていた操作が、1ツールで完結する。

ファイルアップロード込みの操作（S3 PutObject等）もそのまま通る。長時間実行のAPIもタイムアウトしない。IAM認証情報はAWS CLIの設定を引き継ぐので、SSOログイン済みならすぐ使える。実際にLambda関数のコードをS3経由でデプロイしてみたが、OSS版2サーバーの連携で5分かかっていた手順が、GA版では1コマンドで30秒だった。

sandboxed_python — 安全なスクリプト実行

バッチ処理が必要な場面で活きる。エージェントがPythonスクリプトを生成し、サンドボックス内で実行する。ローカルのファイルシステムには触れない。シェルにもアクセスしない。意図しない破壊が構造的に起きない設計だ。

たとえば「全リージョンのEC2インスタンスをリストアップして、停止中のものだけフィルタして返す」といったマルチステップの処理に向く。boto3がプリインストールされており、追加のpip installは不要。

search_documentation / read_documentation

エージェントがAWSの設定方法やベストプラクティスを調べる際に使うツール群だ。search_documentationでキーワード検索し、見つかったページの全文をread_documentationで取得する。

MCPサーバーの中にドキュメント検索が組み込まれている設計は、Context7 MCPと発想が近い。Context7がOSSライブラリの最新ドキュメントをLLMに注入するのに対し、AWS MCPサーバーはAWS公式ドキュメントに特化している。

料金 — 追加費用ゼロの仕組みと実コスト

結論から書く。AWS MCPサーバー自体の利用料は無料だ。課金が発生するのは、エージェントがcall_awsを通じて作成・利用したAWSリソースの分だけ。EC2を起動すればEC2の料金、S3にファイルを置けばS3のストレージ料金がかかる。MCP経由かコンソール操作かで料金は変わらない。

実際にかかるコストの感覚

開発目的でエージェントにインフラを触らせる場合、ほとんどの操作はAPI呼び出し回数ベースの課金で、1回あたり数セント以下に収まる。注意が要るのはエージェントが「よかれと思って」大きなリソースを作るケースだ。

クラウドMCPサーバーの料金比較

AWS・Azureともにサーバー利用料を取らず、クラウドリソースの消費で課金する「入口無料・利用量課金」モデルを採用している。MCPサーバーをきっかけにクラウド利用を拡大させる戦略だろう。Azure MCPサーバーの詳細はこちらで解説している。

セットアップ手順（Claude Code / Cursor）

前提条件

AWS MCPサーバーを使うには以下が必要だ。

• AWSアカウント（無料利用枠のアカウントでも可）
• AWS CLI v2がインストール済み
• IAMユーザーまたはSSO（IAM Identity Center）の認証設定
• Node.js 18以上（mcp-proxy-for-awsの実行に必要）

Claude Codeでの設定手順

Claude Codeを使っている場合、3ステップで完了する。

Step 1: AWS SSOログイン

aws sso login --profile your-profile-name

Step 2: MCPサーバーを登録

claude mcp add-json aws-mcp '{
  "type": "stdio",
  "command": "npx",
  "args": ["-y", "@anthropic-ai/mcp-proxy-for-aws"],
  "env": {
    "AWS_PROFILE": "your-profile-name",
    "AWS_REGION": "us-east-1"
  }
}'

Step 3: 動作確認

Claude Codeを起動して「S3バケットの一覧を表示して」と入力する。バケットリストが返ってくれば設定完了だ。

# Claude Code内で実行される裏側のイメージ
# call_aws → s3:ListBuckets → JSON結果を返す
{
  "Buckets": [
    {"Name": "my-project-assets", "CreationDate": "2026-01-15"},
    {"Name": "data-pipeline-staging", "CreationDate": "2026-03-20"}
  ]
}

VS Code / Cursorでの設定手順

CursorやVS CodeでMCPサーバーを使うには、プロジェクトのルートに.cursor/mcp.json（Cursorの場合）または.vscode/mcp.jsonを作る。

{
  "mcpServers": {
    "aws-mcp": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-proxy-for-aws"],
      "env": {
        "AWS_PROFILE": "your-profile-name",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

設定ファイルを保存したらエディタを再起動する。MCPサーバー一覧に「aws-mcp」が緑色で表示されれば接続成功だ。MCPサーバーのワンクリック導入方法も参考にしてほしい。

IAMガードレールとセキュリティ設計

AIエージェントに15,000のAWS APIを全開放するのは危険だ。GA版のAWS MCPサーバーはIAMポリシーでアクセス制御する設計になっている。ここが従来のOSS版との最大の違いでもある。

最小権限のIAMポリシー例

開発環境でエージェントに与えるポリシーの例を示す。読み取り専用＋特定バケットへの書き込みだけを許可する構成。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyAccess",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject",
        "ec2:Describe*",
        "lambda:List*",
        "lambda:GetFunction",
        "cloudwatch:GetMetricData",
        "logs:GetLogEvents"
      ],
      "Resource": "*"
    },
    {
      "Sid": "LimitedWriteAccess",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-dev-bucket/*"
    },
    {
      "Sid": "DenyDangerousActions",
      "Effect": "Deny",
      "Action": [
        "ec2:TerminateInstances",
        "rds:DeleteDBInstance",
        "iam:*",
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

CloudTrailで全操作を監査する

GA版はCloudTrailにMCP経由の全API呼び出しを自動記録する。「エージェントが勝手にリソースを作っていないか？」を後から追跡できる仕組みだ。

CloudWatchメトリクスはAWS-MCP名前空間に発行される。呼び出し回数、成功率、エラー率をダッシュボードで確認した。テスト中に1日あたり120回ほどcall_awsが呼ばれており、想定以上に頻繁だった。月あたりの呼び出し回数が急増したらアラートを飛ばす設定をおすすめする。

ガードレールが動くことを確認してから、実際のユースケースに入る。

実践ユースケース3選

インフラ自動構築でコンソール操作を置き換えた。ログ分析とIaC化も含めて3パターンの結果を書く。

ユースケース1: インフラ構築の自動化

時間削減のインパクトが最も大きい。VPC作成からサブネット分割、ALB設定まで、コンソールなら10画面以上をクリックして回る工程を自然言語1文で片付けられる。

落とし穴はある。エージェント任せだとセキュリティグループのインバウンドルールが甘くなりがちで、サブネットのCIDR設計も粗い。「search_documentationでAWS Security Hubのベストプラクティスを確認してから構築して」と指示に1行足すだけで、セキュリティグループが0.0.0.0/0で返ってくる頻度が激減した。

ユースケース2: ログ分析

深夜のアラート対応。CloudWatch Logsを手動で漁る時間がもったいない。エージェントに「過去1時間のERRORログを抽出して、発生パターンと仮説を3つ出して」と振ると、抽出→フィルタ→分類→仮説提示を数分で完走する。

sandboxed_python内でpandasが動くため、「24時間分のエラー件数を1時間刻みで集計して」といった定量分析も1回の指示で返ってくる。障害の原因切り分けが格段に速くなった。

ユースケース3: 手動構築からIaCへの移行

「コンソールでポチポチ作ったあのVPC、いつかCloudFormation化しなきゃ…」と先延ばしにしていた作業。AWS MCPサーバーならエージェントがDescribe APIで既存リソースの構成情報を吸い上げ、CloudFormationテンプレートに変換する。

VPC + EC2 + RDSのシンプルな構成で試したところ、70-80%の精度でIaC化できた。依存関係の順序ミスが2-3割あり手動修正は必要だったが、手動でゼロからYAMLを書くと丸1日かかる構成が、修正込みで2-3時間に収まった。

OSS版からの移行ガイド

すでにawslabs/mcpのOSS版サーバーを使っている場合、GA版への移行は「設定の差し替え」で済む。データの移行は不要だ。

移行手順（Claude Codeの場合）

Step 1: 既存のOSS版サーバーを削除

# 個別のOSS版サーバーを削除
claude mcp remove aws-s3
claude mcp remove aws-lambda
claude mcp remove aws-cloudformation

Step 2: GA版のマネージドサーバーを登録（前述のadd-jsonコマンド）

Step 3: 動作確認。これまでOSS版で実行していた操作がGA版でも同じ結果を返すことを確認する。

OSS版を残したほうがいいケース

GA版ではカバーしきれないユースケースもある。たとえばOSS版の@aws-mcp/bedrock-knowledge-baseのようにBedrock固有の高レベルAPIを提供するサーバーは、GA版のcall_awsでは同等の機能を再現しにくい。両方を並行運用する選択肢も現実的だ。

MCPサーバーの選び方や併用のコツはMCPサーバーおすすめ2026で詳しくまとめている。

Azure MCPサーバーとの比較

AWSのGA発表から約1か月前、MicrosoftもAzure MCP Server 2.0をリリースしている。両者のアプローチは似ているが、設計思想に違いがある。

自分ならAWSを使っているプロジェクトにはAWS MCPサーバー、Azureを使っているプロジェクトにはAzure MCPサーバーを選ぶ。マルチクラウド環境では両方をClaude CodeのMCPサーバーとして登録し、プロジェクトごとに切り替える運用が現実的だ。

AWS MCPサーバーが一歩リードしているのはsandboxed_pythonとドキュメント検索の内蔵。Azure側はこれらを別のMCPサーバーで補わなければならない。AWSメインのチームなら迷う理由がない。Azureを選ぶのは業務要件でAzureリソースを触るときだけだ。

よくある質問（FAQ）

まとめ

GA版が変えたのは「AIエージェントとAWSの距離」だ。15,000のAPIを叩けるcall_aws、安全なsandboxed_python、公式ドキュメント検索――この3本柱を1エンドポイントに詰め込み、IAMとCloudTrailで企業レベルのガバナンスまで載せた。

料金はゼロ。セットアップは3行。OSS版からの移行も設定ファイルの差し替えで済む。

AWSを日常的に触るエンジニアにとって、コンソールとCLIに次ぐ第3のインターフェースになる存在だ。自分なら、まず読み取り専用のIAMポリシーで1週間試す。安全を確かめてから書き込み権限を追加する。MCPサーバーを自作したい場合はこちら。