--- title: "AWS MCP Serverとは？GA版の接続手順と全ツール・権限設計【2026年版】" url: "https://www.issoh.co.jp/tech/details/17726/" published: 2026-09-22 updated: 2026-10-31 categories: ["AI"] publisher: "株式会社一創" --- # 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発表](https://aws.amazon.com/jp/about-aws/whats-new/2026/05/aws-mcp-server/)）。 ## AWS MCP ServerのGA版仕様と旧2サーバー統合による変更点 AWS MCP Serverは、MCP（Model Context Protocol）を通じてエージェントにAWSへのアクセス経路を渡すマネージドサーバーです。プロトコル自体の仕組みは[MCPとは？AIと外部ツールをつなぐ標準規格とMCPサーバーの仕組み](/tech/details/5736/)で整理しているため、ここでは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](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/mcp-server.html)）。運用面ではCloudWatchメトリクスが出力され、API呼び出しはCloudTrailに記録されます。なおAgent Toolkit for AWSはMCP Server・Skills・Plugins・ルールファイルの4部品からなり、Skillsは旧Agent SOPの後継にあたります（[Agent Toolkit for AWS components](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/components.html)）。手順書でLLMの挙動を縛る設計思想は共通で、考え方は[Agent SOPでLLMエージェントを標準作業手順で制御する仕組み](https://www.issoh.co.jp/tech/details/13287/)がそのまま通用します。 ### 旧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](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/getting-started-aws-mcp-server.html)）。 ### 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](https://github.com/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` が並べば通っています。Amazon Q Developer CLIから移行した環境では、MCP設定がインストール時に `~/.aws/amazonq/mcp.json` から `~/.kiro/settings/mcp.json` へコピーされているので、追加先はこちらです（移行時の設定パスの対応は「[Amazon Q CLIはKiro CLIへ：q chatからの移行手順と設定・3.0の変更点【2026年10月】](https://www.issoh.co.jp/tech/details/5753/)」にまとめています）。 ## AWS MCP Serverの8ツールの役割とGA前後の名称変更 ここが日本語記事と現行仕様の食い違いが最も大きい箇所です。 ### Knowledge系5ツールとAPI系3ツールの分担と呼び出し順 GA版のツールはAWS Knowledge Toolsが5つ、AWS API Toolsが3つの計8つ（[Understanding the MCP Server tools](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/understanding-mcp-server-tools.html)）。 - `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で外部ツールを接続する実装手順](https://www.issoh.co.jp/tech/details/15365/)で扱っています。 ## 受託開発でAWS MCP Serverを見送るべき条件と代替構成 便利ですが、全案件に入れる部品ではありません。見送る条件を先に決めておくと、導入の議論が速く終わります。 ### 見送りを決める3条件＝データ所在地・監査要件・多段のロール引き受け 次のいずれかに当たる案件では、AWS MCP Serverを本番系へ入れない判断をします。 - データの所在地に制約がある案件。サーバーの提供はus-east-1とeu-central-1の2リージョンのみで、操作対象を東京へ向けてもMCPサーバー自体は国外にあります - エージェントの操作を事前承認フローに載せる必要がある案件。CloudTrailは事後の追跡であり、実行前の承認は担保しません - 多段のロール引き受けやカスタムの認証プロキシを挟んでいる環境。OAuthはマルチアカウント非対応、SigV4も認証情報プロバイダチェーンに乗る前提で、既存の踏み台構成と噛み合わないことがあります 逆に、開発・検証アカウントでの調査と一次切り分けに絞るなら、読み取り専用で入れて損はほぼありません。サーバー利用料が無料で、止めるときはMCP設定からエントリを消すだけ。判断の分かれ目は機能ではなく、対象アカウントの重みと監査要件の厳しさです。 ### OSSのawslabs製MCPサーバーへ寄せる代替構成と注意点 マネージド版を見送る場合の代替は、[awslabs/mcp](https://github.com/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サーバーを構築する手順](https://www.issoh.co.jp/tech/details/6507/)にまとめています。 注意点は2つ。第一に、管理の手間とセキュリティ制御が自分たちへ戻ってくる。公式ドキュメントはマネージド版の利点としてセットアップと保守の負担軽減、IAM条件キーによる制御強化を挙げています。第二に、サーバーを増やすほどツール定義が膨らみ、エージェントの選択精度が落ちます。必要な範囲だけ足すのが前提です。AWSアカウントの構成や権限境界の設計から相談したい場合は[AWS・Google Cloud・Azureのインフラ構築](https://www.issoh.co.jp/service/system/aws/)で対応しています。エージェント前提のアカウント分割と権限設計は、後から直すほど高くつく部分です。 ## よくある質問 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もエージェントスキルへ置き換わりました。設定やツール名は公式の一覧で確認してください。 ## 関連記事 - [MCPとは？AIと外部ツールをつなぐ標準規格とMCPサーバーの仕組み・作り方を解説](/tech/details/5736/)：プロトコルとしてのMCPの構造と、サーバー・クライアントの役割分担から確認したい場合はこちら - [AIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】](https://www.issoh.co.jp/tech/details/15365/)：AWS以外のツールも含め、エージェント側の接続・認可設計を扱っています - [FastMCPとは｜PythonでMCPサーバーを最速構築するフレームワークの使い方【2026年版】](https://www.issoh.co.jp/tech/details/6507/)：マネージド版ではなく自前でMCPサーバーを書く場合の実装手順 - [Agent SOPとは？LLMエージェントを標準作業手順で制御する仕組みと実装判断](https://www.issoh.co.jp/tech/details/13287/)：GA版のSkillsの前身にあたる、手順書でエージェントを制御する考え方 - [MCPとRAGの違いとは？役割の違いと使い分け・併用アーキテクチャを実装者向けに解説【2026年版】](https://www.issoh.co.jp/tech/details/15347/)：外部ツール接続と知識検索のどちらを使うかを整理しています --- 出典: [AWS MCP Serverとは？GA版の接続手順と全ツール・権限設計【2026年版】]()（株式会社一創）