2026.09.22 AI

AWS MCP Serverとは？GA版の接続手順と全ツール・権限設計【2026年版】

AWS MCP Serverとは？GA版の接続手順と全ツール・権限設計【2026年版】

AWS MCP Serverは、2026年5月6日に一般提供が始まったAWS公式のマネージドMCPサーバーです。エンドポイントは1つで、ドキュメント検索から実際のAPI呼び出しまで同じ接続でこなせます。ただし日本語の解説記事はプレビュー期の内容が多く、ツール名も認証方式も現行と噛み合いません。公式ドキュメントとリポジトリを突き合わせ、GA版の仕様、OAuthとSigV4の選び方、設定JSON、8ツールの役割、本番アカウントへ繋ぐときの権限設計を実装の順に整理します。

まとめ：AWS MCP Server導入の結論と認証方式の選び方

結論は3つ。第一に、これから触るなら旧来の aws-api-mcp-server と aws-knowledge-mcp-server ではなくAWS MCP Serverを選びます。両方を登録するとツール名が衝突し、エージェントの選択精度が落ちてしまう。第二に、認証はターミナル系のコーディングエージェントならSigV4、ブラウザ経由のWebクライアントならOAuthです。分岐の決め手は「読み取り専用モードが要るか」「複数アカウントを1セッションで切り替えるか」の2点で、どちらかが要るならSigV4しか選べません。

第三に、本番アカウントへ最初から書き込み権限で繋ぐ構成は採りません。--read-only で書き込み系ツールをエージェントの視界から消し、IAM条件キーで操作を絞り、CloudTrailで事後追跡できる状態を作ってから権限を開けていく。サーバー自体の利用料は無料で、課金はエージェントが触ったAWSリソース側に発生します（AWS公式のGA発表）。

AWS MCP ServerのGA版仕様と旧2サーバー統合による変更点

AWS MCP Serverは、MCP（Model Context Protocol）を通じてエージェントにAWSへのアクセス経路を渡すマネージドサーバーです。プロトコル自体の仕組みはMCPとは？AIと外部ツールをつなぐ標準規格とMCPサーバーの仕組みで整理しているため、ここではAWS側の実装に絞ります。

2026年5月6日のGAで変わった提供形態と対応2リージョン

GA発表は2026年5月6日付。提供形態は単独プロダクトではなく、Agent Toolkit for AWSのコアコンポーネントという位置づけへ変わりました。使えるリージョンは米国東部（バージニア北部）とヨーロッパ（フランクフルト）の2つだけで、エンドポイントは https://aws-mcp.us-east-1.api.aws/mcp と https://aws-mcp.eu-central-1.api.aws/mcp です。

機能面もGAで動いています。プレビュー期にあった「エージェントのSOP」は、より柔軟な形式であるエージェントスキルへ置き換えられました。1つのツールで任意のAWS APIを呼べるようになり、長時間実行を伴う操作も対象に入っています。AWSドキュメントの検索とサービス情報の取得は認証なしで通り、API呼び出し・サンドボックスでのPython実行・キュレーション済みスキルの参照には既存のIAM認証情報を使う設計です（AWS MCP Server – Agent Toolkit for AWS）。運用面ではCloudWatchメトリクスが出力され、API呼び出しはCloudTrailに記録されます。なおAgent Toolkit for AWSはMCP Server・Skills・Plugins・ルールファイルの4部品からなり、Skillsは旧Agent SOPの後継にあたります（Agent Toolkit for AWS components）。手順書でLLMの挙動を縛る設計思想は共通で、考え方はAgent SOPでLLMエージェントを標準作業手順で制御する仕組みがそのまま通用します。

旧APIサーバーとKnowledgeサーバーを外す必要とツール衝突

すでに aws-api-mcp-server か aws-knowledge-mcp-server をクライアントへ登録している環境には、移行手順が公式に示されています。MCP設定ファイル（Kiroなら ~/.kiro/settings/mcp.json）から該当エントリを削除し、保存してクライアントを再起動する、という3手順です。

削除が要る理由はツール名の衝突。公式ドキュメントは、古いサーバーを残すとAIエージェントが混乱して性能が落ちると明記しています。日本語の解説を見ながら設定を写すと旧サーバーの登録手順が残りがちで、ここが事故の入口になる。足すのではなく置き換える作業だと捉えてください。

OAuthとSigV4という認証2方式の違いと用途別の選択基準

設定でつまずく箇所はほぼ認証です。公式ドキュメントは判断表を用意しており、質問に1つでも当てはまればそちらを選ぶ形になっています（Setting up the AWS MCP Server）。

Webクライアント中心ならOAuthで足りる条件と更新の運用

OAuthが向くのは、uvxもAWS CLIもローカル認証情報の設定も避けて始めたい場合と、クライアントがリモートMCPサーバーしか扱えない場合。Claude.aiやChatGPT.comのようなWebクライアント、多くのIDE・ターミナル・デスクトップ製品が対象です。事前準備は AWSMCPSignInOAuthAccessPolicy をIAMロールへアタッチする1手だけ。

注意点はトークンの寿命にあります。初回のツール呼び出しでブラウザがAWSサインインへ飛び、同意後のアクセストークンは1時間有効。AWSサインインが最大12時間まで自動更新し、そこを越えるとサインインし直しです。複数AWSアカウントをまたぐプロファイル切り替えはOAuth非対応で、公式にSigV4を使えと書かれています。

SigV4だけが持つ読み取り専用モードと複数アカウント切り替え

SigV4は、AWS CLIで認証したうえでMCP Proxy for AWSにリクエストを署名させる方式です。Claude Code・Kiro・Codexのようなターミナル／IDE系のコーディングエージェント、AWSアカウントを頻繁に切り替える運用が対象になります。

この方式だけが持つ機能が2つ。1つは読み取り専用モードで、書き込み権限を要する可能性のあるツールをエージェントの視界から完全に隠せます。もう1つがセッション内での複数アカウント切り替え。組織側で signin:AuthorizeOAuth2Access と signin:CreateOAuth2Token を制限している環境も、ブラウザ経由のOAuthログインが通らないためSigV4へ寄せます。エージェントのセッション既定リージョンを指定したい場合も同じ判断です。

Kiro・Claude Code・Cursorの接続手順とMCP設定JSON

ここからは手を動かす部分です。SigV4を選んだ前提で、事前準備から設定ファイルまで順に置きます。

AWS CLI 2.32.0以降とuvを前提にした事前準備の手順

準備は4手です。

  1. AWS CLI 2.32.0以降をインストールする
  2. aws login でサインインし、認証情報を構成する
  3. aws sts get-caller-identity で認証情報が通ることを確かめる
  4. uvが未導入なら入れる（macOS・Linuxは curl -LsSf https://astral.sh/uv/install.sh | sh）

2番目の aws login は認証情報を15分ごとに自動ローテーションし、セッションは最大12時間まで維持します。SSOやクロスアカウントロールを使う場合は別手順が案内されています。MCP Proxy for AWS側の要件はPython 3.10以上、ライセンスはApache-2.0（aws/mcp-proxy-for-aws）。

uvx mcp-proxy-for-aws-cliを指定する設定JSONの記述例

Cursor IDE・Claude Desktop・Devin Desktopで使う設定はこの形です。

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws-cli@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-west-2"
      ]
    }
  }
}

読み方で外しやすい点が1つ。URLに含まれるリージョンは接続先のMCPサーバーを決め、--metadata の AWS_REGION はAWS操作の既定リージョンを決めます。別物です。AWS_REGION を省くと操作は us-east-1 に落ちるため、東京リージョンのリソースを触らせるなら明示してください。KiroのCLIやIDEでは上の記述へ "timeout": 100000 と "transport": "stdio" を加えた形が公式例、Claude Code CLIはJSONを書かずワンライナーで登録できます。

claude mcp add-json aws-mcp '{"type":"stdio","command":"uvx","args":["mcp-proxy-for-aws-cli@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"],"env":{}}'

oauth=initializeを付けるクライアントと判断の目安

OAuthを選ぶ場合、クライアントによってURLの書き方が2通りに分かれます。Claude Code CLI・Claude Code for Web・Kiro CLI（2.11以降）・Devinは既定のエンドポイントURLをそのまま渡す。対してClaude Desktop・Cursor・Kiro IDE・Gemini CLI・Codexは、URL末尾へ ?oauth=initialize を付けた形が公式の案内です。

claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http

一覧に無いクライアントは、まず既定URLで試します。クエリを付けない場合はMCPのOAuthディスカバリに任せる挙動になり、認証情報エラーでツール呼び出しが落ちたときに ?oauth=initialize を足してサーバー側から明示的にOAuthフローを起こす、という順番。接続後の確認はKiro CLIなら /tools と /mcp で、aws___search_documentation と aws___retrieve_skill が並べば通っています。

AWS MCP Serverの8ツールの役割とGA前後の名称変更

ここが日本語記事と現行仕様の食い違いが最も大きい箇所です。

Knowledge系5ツールとAPI系3ツールの分担と呼び出し順

GA版のツールはAWS Knowledge Toolsが5つ、AWS API Toolsが3つの計8つ（Understanding the MCP Server tools）。

  • aws___retrieve_skill：指定ドメインのスキル本文と参考資料を取得
  • aws___search_documentation：APIリファレンス・ガイド・スキルを横断検索
  • aws___read_documentation：ドキュメントをMarkdownへ変換して取得
  • aws___list_regions：全リージョンの識別子と名称を取得
  • aws___get_regional_availability：サービス・機能・API・CloudFormationリソースの地域別提供状況を確認
  • aws___run_script：サンドボックス内でPythonを実行しAWS APIを呼ぶ
  • aws___get_presigned_url：Amazon S3の署名付きURLを発行
  • aws___get_tasks：run_scriptが返した長時間タスクの状態をポーリング

3層の噛み合いが設計の要点になります。スキルが作業の型を与え、Knowledge系が現在の仕様とベストプラクティスを供給し、API系が認証・認可を通した実操作を担う。スキルの一覧は aws___search_documentation のトピックフィルタで引き当てます。複数プロファイルを構成した場合は、プロキシがAPI系3ツールのスキーマへ aws_profile を差し込み、呼び出し単位でアカウントを振り分ける仕組みです。

call_awsからrun_scriptへ変わった実行モデルの違い

プレビュー期の記事は aws___call_aws・aws___suggest_aws_commands・aws___recommend・aws___retrieve_agent_sop という名前でツールを説明しています。GA版の一覧にこれらはありません。名前が変わっただけではなく、実行モデルそのものが別物になっている。

旧構成はCLIコマンド1本を組み立てて叩く発想でした。GA版の aws___run_script はサンドボックス環境でPythonコードを走らせる前提で、公式が挙げる用途は並列API呼び出し、複数ステップのワークフロー、サービス横断のチェック、リトライ処理。1コマンド1操作から、スクリプト単位の処理へ粒度が上がっています。長時間タスクは aws___get_tasks でタスクIDをポーリングする非同期前提、S3のファイル授受は署名付きURLに寄りました。プレビュー期の記事を手本に権限設計をすると、この非同期実行とスクリプト実行を見落とします。

本番AWSアカウント接続時の権限設計と読み取り専用の使い分け

ここは言い切ります。本番アカウントの認証情報をそのままエージェントへ渡す構成は採用しません。aws___run_script は任意のPythonコードをAWS API付きで走らせるツールで、IAMで許された操作はすべて実行できてしまう。

–read-onlyで書き込み系ツールを隠す構成と適用範囲

MCP Proxy for AWSには --read-only フラグがあり、既定値は False、説明は「書き込み権限を要する可能性のあるツールを無効化する」です。ツール一覧そのものから消えるため、プロンプトで抑止する方式より確実に効きます。

{
  "mcpServers": {
    "aws-mcp-readonly": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws-cli@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--read-only",
        "--metadata", "AWS_REGION=ap-northeast-1"
      ]
    }
  }
}

運用の型としては、調査・棚卸し・障害の一次切り分けを読み取り専用の接続で回し、変更を伴う作業は別プロファイルへ切り替える。--profile prod-readonly dev staging のように複数指定でき、先頭が既定、以降が呼び出し単位の切り替え対象になります。IAM側でも読み取り専用の権限セットを当てて二重に締めてください。プロキシのフラグは設定の書き換えで外せるため、単独の防御線としては数えません。

IAM条件キーとCloudTrailで事後追跡する監査の設計

AWS MCP Serverはマネージドサーバーで、IAMベースのアクセス制御とIAM条件キーによる制限が効きます。エージェントの行動をIAM側で絞り込める点が、自前でMCPサーバーを立てる構成との実務的な差になる。API呼び出しはCloudTrailに残ります。

詰まりやすい失敗も公式に整理されています。ExpiredTokenException は既定1時間のセッショントークン切れで、aws login の再実行で解消。InvalidSignatureException はSigV4の署名不一致で、原因の1つがマシンの時刻ずれです。SigV4はAWSサーバーとの時刻差が5分以内であることを要求します。認証情報が切れるとサーバーの初期化に失敗し、エージェントがAWSツールを無言で使わなくなるので、ツールを呼ばない症状を見たら先に認証情報を疑ってください。ツール定義と認可をエージェント側でどう設計するかはAIエージェントにMCPで外部ツールを接続する実装手順で扱っています。

受託開発でAWS MCP Serverを見送るべき条件と代替構成

便利ですが、全案件に入れる部品ではありません。見送る条件を先に決めておくと、導入の議論が速く終わります。

見送りを決める3条件＝データ所在地・監査要件・多段のロール引き受け

次のいずれかに当たる案件では、AWS MCP Serverを本番系へ入れない判断をします。

  • データの所在地に制約がある案件。サーバーの提供はus-east-1とeu-central-1の2リージョンのみで、操作対象を東京へ向けてもMCPサーバー自体は国外にあります
  • エージェントの操作を事前承認フローに載せる必要がある案件。CloudTrailは事後の追跡であり、実行前の承認は担保しません
  • 多段のロール引き受けやカスタムの認証プロキシを挟んでいる環境。OAuthはマルチアカウント非対応、SigV4も認証情報プロバイダチェーンに乗る前提で、既存の踏み台構成と噛み合わないことがあります

逆に、開発・検証アカウントでの調査と一次切り分けに絞るなら、読み取り専用で入れて損はほぼありません。サーバー利用料が無料で、止めるときはMCP設定からエントリを消すだけ。判断の分かれ目は機能ではなく、対象アカウントの重みと監査要件の厳しさです。

OSSのawslabs製MCPサーバーへ寄せる代替構成と注意点

マネージド版を見送る場合の代替は、awslabs/mcpで公開されている30以上のOSSサーバーです。用途別に分かれており、IaC・EKS・ECS・DynamoDB・RDS・OpenSearch・Bedrock・SageMaker・EventBridgeといった単位で必要なものだけ入れられます。起動はサーバー単位で uvx awslabs.aws-documentation-mcp-server@latest のように指定し、AWS_PROFILE と AWS_REGION を環境変数で渡す形です。自前でMCPサーバーを書く場合の実装手順はFastMCPでPythonのMCPサーバーを構築する手順にまとめています。

注意点は2つ。第一に、管理の手間とセキュリティ制御が自分たちへ戻ってくる。公式ドキュメントはマネージド版の利点としてセットアップと保守の負担軽減、IAM条件キーによる制御強化を挙げています。第二に、サーバーを増やすほどツール定義が膨らみ、エージェントの選択精度が落ちます。必要な範囲だけ足すのが前提です。AWSアカウントの構成や権限境界の設計から相談したい場合はAWS・Google Cloud・Azureのインフラ構築で対応しています。エージェント前提のアカウント分割と権限設計は、後から直すほど高くつく部分です。

よくある質問

AWS MCP Serverの導入時に検索されている疑問へ、公式ドキュメントに沿って答えます。

AWS MCP Serverの料金はいくらかかりますか？

サーバー自体は追加料金なしで使えます。支払うのはエージェントが操作したAWSリソースの費用だけ。ただし aws___run_script を渡すと、リソース一覧や属性確認のAPI呼び出しが人間の操作より高頻度で走ります。EC2の起動やデータ転送を伴う操作を任せるなら、コスト異常検知を先に設定してください。

東京リージョン（ap-northeast-1）から使えますか？

MCPサーバーのエンドポイントはus-east-1とeu-central-1の2つだけで、ap-northeast-1のエンドポイントはありません。操作対象のリージョンは別に指定でき、SigV4方式なら --metadata AWS_REGION=ap-northeast-1 で東京のリソースを扱えます。省略した場合の既定は us-east-1。接続先と操作対象を別々に設定する、と覚えると混乱しません。

OAuthとSigV4はどちらを選べばよいですか？

読み取り専用モードが必要、または1セッションで複数AWSアカウントを切り替える必要があるなら、SigV4以外に選択肢はありません。どちらも不要でuvxやAWS CLIの導入を避けたい場合、クライアントがリモートMCPサーバーしか扱えない場合はOAuthが向きます。OAuthのアクセストークンは1時間有効、AWSサインインが最大12時間まで自動更新する仕様です。

以前から使っている aws-api-mcp-server は残してよいですか？

公式は削除を推奨しています。aws-api-mcp-server と aws-knowledge-mcp-server をAWS MCP Serverと併存させると、同種のツールが二重に見えてエージェントの判断が乱れ、性能が落ちると明記されている。MCP設定ファイルから旧エントリを消し、保存してクライアントを再起動してください。

ツール名が記事と違うのはなぜですか？

2026年5月6日のGAでツール構成が変わったためです。プレビュー期に紹介されていた aws___call_aws・aws___suggest_aws_commands・aws___retrieve_agent_sop は現行の一覧にありません。CLIコマンドを組み立てる実行モデルから、サンドボックスでPythonを走らせる aws___run_script を軸にした構成へ変わり、Agent SOPもエージェントスキルへ置き換わりました。設定やツール名は公式の一覧で確認してください。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る