AWS MCPサーバー超進化してGAしたらしい

Posted at 2026-05-07

前書き

AWS MCP サーバー、結構前からGA するらしいという噂は流れていたんですが、何回か見送られて、昨日（2026/05/06）でようやく GA したので、さっそく使ってみます

これまで、 AWS には aws-api-mcp-server や aws-knowledge-mcp-server があったんですが、情報が古かったり、最新の AWS サービスを使うときは自力でドキュメントを探してこないといけなかったり、というモヤモヤがありました。

今回の AWS MCP サーバーなら、そのあたりが最新の情報のまま取ってこれます。

結論

AWS MCP を繋いだ Claude Code に、今プレビュー公開中の AgentCore harness について聞いてみます。

完璧です。検索速度も以前の MCP サーバーより速くなった気がします。

AWS MCP サーバーとは

AWS MCP Server は、AI コーディングエージェントから AWS の API・公式ドキュメント・ベストプラクティスを叩けるようにする、AWS マネージドのMCPサーバーです。

Agent Toolkit for AWS（MCP Server + Skills + plugins）というスイートの目玉です。

旧 MCP（`aws-api-mcp-server` / `aws-knowledge-mcp-server`）から何が変わった？

これまで AWS で MCP を使うときは aws-api-mcp-serverやaws-knowledge-mcp-serverの 2 つのMCPサーバーを別々にローカルへ立てる構成が一般的でした。

新しい AWS MCP サーバーはここがガラッと変わっていて、ざっくり並べるとこんな感じです。

観点	旧	新（AWS MCP Server）
提供形態	2 つを別々にローカル起動	1 つのマネージドリモートに統合
認証	API 側はクレデンシャル、Knowledge 側は無認証	IAM SigV4 ネイティブ + ドキュメントは認証不要
API 呼び出し	CLI 経由でローカル実行	`call_aws` で 15,000+ API をサーバ側実行
複数 API のチェーン	できない（1 個ずつ往復）	`run_script` で boto3 を 1 往復に圧縮
ベストプラクティス参照	自力でドキュメント検索	`retrieve_skill` で AWS サービスチーム監修の Skill を取得
IAM 制御	リソースレベルのみ	`aws:ViaAWSMCPService` / `aws:CalledViaAWSMCP` の context key 対応
監査	クライアント側ログのみ	CloudTrail + CloudWatch（`AWS-MCP` namespace）
サンドボックス実行	なし	サーバ側のネットワーク隔離 sandbox（IAM 継承）

特に効きそうなのは run_script とSkills の追加で、

run_script は全リージョンの Lambda を集計してみたいな、複数 API を組み合わせる作業を 1 往復で済ませてくれる
Skills は AWS サービスチームが直接メンテしている検証済みベストプラクティスで、AIエージェントのハルシネーションを抑える効果がある

エンタープライズ視点だと、aws:CalledViaAWSMCP の IAM コンテキストキーでMCP 経由のときだけ destructive アクションを denyみたいな統制がかけられるようになったのもありがたいポイントです。

IAM ネイティブだからプロキシ経由になった

AWS MCP の特徴的なところは、認証が IAM SigV4 ネイティブな点です。
普段の AWS 認証情報（aws login / SSO / assume-role）がそのまま使えるので、別途トークン発行みたいな手間が発生しません。

ただし、ここで MCP の仕様との整合性問題が出てきます。
MCP の標準仕様の認証は OAuth 2.1 のみで、IAM SigV4 をそのままはサポートしていません。

そこを埋めるのが mcp-proxy-for-aws というローカルプロキシで、こいつがローカルの AWS クレデンシャルで SigV4 署名してリモートのマネージドエンドポイント（https://aws-mcp.us-east-1.api.aws/mcp など）に中継してくれる、という流れになります。

[Claude Code] ── MCP (stdio) ──▶ [uvx mcp-proxy-for-aws]
                                        │
                                        │  ローカルの AWS クレデンシャルで SigV4 署名
                                        ▼
                              [https://aws-mcp.<region>.api.aws/mcp]
                                        │
                                        ▼
                              [AWS API / docs / sandbox]

提供リージョンと料金

エンドポイントは us-east-1 と eu-central-1 の 2 拠点
操作対象の API は任意のリージョンに飛ばせます（--metadata AWS_REGION=... で切り替え）
AWS MCP サーバー自体には追加課金なし。発生するのは実際に動かした AWS 操作分の料金だけです

提供されるツール

実際に使えるツールは結構たくさんあるので、リソース操作系・ドキュメント参照系・リージョン情報系の順に見ていきます。

まずはリソース操作系。

ツール	用途
`call_aws`	15,000+ の AWS API オペレーションを呼び出す。リソース操作の主力
`suggest_aws_commands`	やりたいことを自然言語で投げると AWS CLI コマンド候補を返してくれる。`call_aws` のフォールバック
`run_script`	Python サンドボックスで boto3 を実行。複数 API を組み合わせた集計や横断分析向け（IAM 権限を継承、外部ネットワークなし）
`get_presigned_url`	S3 のアップロード/ダウンロード用 presigned URL を発行。ローカルファイルを `call_aws` の引数に渡したいときに使う
`get_tasks`	`call_aws` / `run_script` がタイムアウトを超えたときに発行されるタスク ID を polling して結果を回収

次にドキュメント参照系。最新仕様をブラウザで探さなくて済むのは、このグループのおかげです。

ツール	用途
`search_documentation`	AWS 公式ドキュメントを横断検索。関連する Skill 候補もあわせて返してくれる
`read_documentation`	検索でヒットしたページ本文を Markdown 化して取得
`recommend`	開いているドキュメントページに関連する人気/新着/類似ページを提案
`retrieve_skill`	AWS サービスチームが提供する検証済みベストプラクティス（Skill）を取得

最後にリージョン情報系。マルチリージョン構成を考えるときに地味に便利です。

ツール	用途
`list_regions`	AWS の全リージョン一覧を取得
`get_regional_availability`	サービスや CloudFormation リソースが特定リージョンで使えるかを一括確認

call_aws で AWS を直接動かすのもいいんですが、個人的に効くなと思ったのは search_documentation と retrieve_skill の組み合わせです。Claude Code が記憶していない最新サービスや仕様変更でも、ドキュメント側に正解があれば取りに行ってくれるので、「これって最新の仕様どうなってたっけ？」のたびにブラウザを開かなくていいのがありがたい。

複数の API を組み合わせる集計（「全リージョンの Lambda を舐めて Invocation 多い順に並べて」みたいなやつ）は run_script が活躍します。逆にコマンドを一つだけ叩きたいときは call_aws の方が軽くて速いので、用途で使い分ける感じです。

セットアップ手順

AWS アカウント（SSO で運用していると話が早いです）
AWS CLI v2

uv / uvx

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Claude Code（CLI 版）
ローカルで uvx mcp-proxy-for-aws がプロキシとして動き、SigV4 で中継してくれるので、Claude Code から call_aws などのツールが使えるようになる

あとはAWS SSO ログイン → Claude Code に MCP サーバーを登録の 2 ステップだけです。

AWS SSO ログイン

プロファイル名はご自身の環境に合わせて読み替えてください（以降の例では MyAdminProfile という名前で進めます）。

aws sso login --profile MyAdminProfile

ブラウザでデバイス承認を済ませたら、まずは AWS CLI 単体で疎通確認しておきます。

aws sts get-caller-identity --profile MyAdminProfile

UserId / Account / Arn が返ってくれば OK です。ここが通らないまま MCP 側に進んでもどうせ動かないので、まずは CLI で叩ける状態を作っておくのが結局いちばん早いです。

Claude Code に MCP サーバーを登録

公式ドキュメントには Claude Desktop / Cursor / Claude Code それぞれの登録方法が載っていますが、Claude Code なら claude mcp add-json 一発で済みます。

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"
  ],
  "env": {
    "AWS_PROFILE": "MyAdminProfile",
    "AWS_REGION": "ap-northeast-1"
  }
}'

ポイントは 2 つあります。

--metadata AWS_REGION=... は、MCP サーバー側に「デフォルトでこのリージョンの API を叩いて」と伝えるパラメータ
env.AWS_PROFILE は、プロキシがローカルクレデンシャルを取得するときに参照するプロファイル名。ここを入れないと default プロファイルを見に行ってしまう

--scope user にしておくと、どのプロジェクトから Claude Code を起動しても同じ MCP が使えるようになります。プロジェクトごとに登録し直すのが面倒なので、最初から user スコープで入れておくのがおすすめ。

動作確認

Claude Code起動した状態で、下記のコマンドを実行する

/mcp

aws-mcp のステータスが connected になっていれば登録 OK です。

セキュリティ・コストの注意

便利な反面、会話一発で AWS が動いてしまう以上、ガバナンスは普段以上に意識しておきたいところです。ここは正直、最初に決めておかないと後から制御が効きにくくなります。

権限

AdministratorAccess で繋ぐと、原理上は Claude が読み取り以外の任意操作を実行できてしまいます
普段使いの MCP プロファイルは、read 寄りのカスタムロールにしておくのがおすすめです
AWS MCP 経由のリクエストには aws:ViaAWSMCPService / aws:CalledViaAWSMCP の IAM コンテキストキーが自動で付くので、SCP や IAM ポリシーで「MCP 経由なら destructive なアクションは拒否」みたいな制御がかけられます

このコンテキストキーが入っているおかげで、「MCP 経由のとき限定で禁止」がポリシーで書けるのは結構ありがたいです。SCP に組み込んでおくと、間違って強い権限のプロファイルで叩いてしまっても安全側に倒れます。

コスト

s3 list-buckets などの List 系は基本タダ
describe-* / get-* を多用するサービス（CloudWatch Logs Insights、Athena、Bedrock など）はリクエスト課金や処理時間課金が乗ります
会話の流れで「全リージョン全リソースを舐めて」と頼むと、想像以上に API コール数が膨らむことがあります

最初は 1 リージョン / 1 サービスに絞って試して、どのくらいの API コール数になるかの感覚を掴むのが安全です。AWS の請求アラートも一応セットしておくと、想定外のコール量に気づきやすくなります。

`run_script` の挙動

run_script のサンドボックスはネットワーク隔離されていて、AWS API 以外には出ていけない作りになっています。

ネットワーク隔離されているとはいえ、IAM 権限はそのまま継承されます。「サンドボックスだから安全」ではないので、強い権限のプロファイルで run_script を許可するときは特に注意してください。

最後

ここまで触ってみての所感です。

セットアップは想像より楽で、uvx と claude mcp add-json で完結する
call_aws だけでなく search_documentation / run_script まで使い倒すと、コンソールを開く回数が露骨に減る
権限とコストは普段以上に意識する。MCP 用に絞った IAM ロールを作っておくと、心理的にも安心して触れる

Agent Toolkit for AWSのリリースもでかい、AWS基盤としたAI駆動開発がよりやりやすくなった気がする、特定のスキルだけ使いたい時、このリポジトリから入手できます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up