Claude Media
ClaudeとAWS MCPサーバーを連携する方法 — OAuthとSigV4の使い分け

ClaudeとAWS MCPサーバーを連携する方法 — OAuthとSigV4の使い分け

ClaudeからAWS MCP Serverにつなぐ手順を、OAuthとSigV4の選び方、リージョン別エンドポイント、IAM条件キーによる制限、データの扱いまでまとめます。

AWS MCP Serverは、AWSが管理するリモートのMCPサーバーです。ClaudeからAWSのドキュメント検索、APIの実行、Pythonスクリプトの実行までを1つのエンドポイントで任せられます。ドキュメント検索だけなら認証は要りません。APIを実行させるときだけ、手元のIAM認証情報で認証します。

接続方式は2つあり、選び方で手順も権限の絞り方も変わります。ブラウザで済ませるOAuthか、AWS CLIとプロキシを使うSigV4か。この記事では、その分かれ目から順に説明します。

AWS MCP ServerはClaudeに何を渡すか

AWS MCP Serverは「Agent Toolkit for AWS」の中核コンポーネントです。ツールは3系統に分かれます。

系統ツール認証
知識ツールaws___search_documentation / aws___read_documentation / aws___retrieve_skill / aws___list_regions / aws___get_regional_availability認証不要
API実行ツールaws___run_script / aws___get_presigned_url / aws___get_tasks認証必要
コネクタ紹介ページのみツールaws___call_aws認証ツール解説ページに記載なし

aws___run_scriptは、サンドボックスでPythonを動かしてAWS APIを呼びます。リソースの列挙、並列のAPI呼び出し、複数サービスをまたぐ確認に向いたツールです。時間のかかる処理はaws___get_tasksで状況を取ります。aws___get_presigned_urlはS3の署名付きURLを作り、ファイルの受け渡しに使います。

aws___call_awsはClaudeのコネクタ紹介ページにはありますが、Agent Toolkitのツール解説ページには載っていないツールです。挙動はどちらのページにも書かれていないため、導入後にClaudeへ使えるツールを一覧させ、説明文で確かめてください。

aws___retrieve_skillが返す「スキル」は、AWSの各分野の手順や判断基準をまとめた資料です。検索ツールのtopicフィルタでスキルだけを探せます。

知識系の3ツールとリージョン系の2ツールは認証なしで動きます。ただし認証なしのリクエストは送信元IPごとの低いレート制限に入ります(後述のクォータ参照)。

運用の調査に使える「serverless capability」

ツールとは別に、AWS MCP Serverには「capability」という単位があります。現在の説明があるのはserverlessで、Lambda関数の不調を調べるために読み取り専用で動きます。

  • diagnose: 健全性と7日間のベースライン比較、接続先リソースを含めた原因推定
  • search_logs: CloudWatch Logsから例外の種類ごとに要約
  • get_live_config: 実際にデプロイされている設定(タイムアウトやSQSの可視性タイムアウトなど)
  • get_recent_changes: CloudTrailなどから「誰がいつ何を変えたか」の時系列
  • get_trace_summary: X-Rayのトレースから遅延の出どころを抽出(関数側でX-Rayを有効にしておく必要あり)

スコープは呼び出したアカウント自身に限られます。「このLambdaがなぜ失敗するか」のように結果を伝えれば、Claudeが必要なhelperを選びます。

OAuthとSigV4はどちらで接続するか

最初の分岐は、どのClaudeから使うかです。AWSの判断表をClaudeの使い方に引き直すと、次のとおりです。Claude Desktopはローカルでプロキシも起動できるため、OAuthとSigV4のどちらも選べます。

くらべる

Claudeの使い方で決まる接続方式

ブラウザで認可する

OAuth

claude.aiのように、ローカルでプロセスを動かせないクライアント向けです。Claude Desktopを含め、OAuthに対応したクライアントならuvxもAWS CLIも不要で、AWS Sign-inの画面で承認するだけで済みます。単一アカウントで使う場合の既定の選択肢です。

AWS CLIとプロキシで署名する

SigV4

Claude CodeやClaude Desktopのように、ローカルでプロキシを起動できるクライアント向けです。複数アカウントの切り替え、読み取り専用モード、既定リージョンの指定はこちらでしか使えません。

SigV4が向く条件は、AWSの判断表に次の形で並んでいます。1つでも当てはまるならSigV4です。

  • 同じセッションで複数のAWSアカウントにアクセスさせたい
  • 書き込み可能なツールをエージェントから隠す読み取り専用モードが必要
  • 組織がsignin:AuthorizeOAuth2Accessとsignin:CreateOAuth2Tokenを制限している
  • 毎回リージョンを指定せず、既定リージョンを設定したい
  • クライアントがOAuthに未対応だが、ローカルのMCPプロキシは動かせる

Claude Codeは、OAuthにもSigV4にも対応しています。迷ったらまずOAuthで試し、アカウント切り替えが要る段階でSigV4に移る順序もあります。

OAuthでClaudeにつなぐ

前提のIAM権限

OAuthでは、サインインするIAMユーザーまたはロールに、OAuth用の2アクションが必要です。管理ポリシーAWSMCPSignInOAuthAccessPolicyを付けるのが最短です。

aws iam attach-role-policy \
  --role-name MyRole \
  --policy-arn arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy

管理ポリシーを使わず自前で書く場合は、signin:AuthorizeOAuth2Accessとsignin:CreateOAuth2Tokenを許可し、リソースをarn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.comに絞ります。

Claude Codeの場合

OAuthの登録はHTTPトランスポートを指定する1行です。

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

最初にツールを呼んだとき、ブラウザでAWS Sign-inが開きます。サインインして同意すると、アクセストークンは1時間有効になります。リフレッシュトークンによる自動更新は最大12時間続くため、1日の作業中に何度も認可し直す必要はありません。

claude.aiとClaude Desktopの場合

claude.ai上では、Claudeのコネクタ紹介ページにある「Add to Claude」から追加できます。紹介ページではAnthropic verifiedとされ、作成元はAmazon Web Servicesです。サインインは「Not required」と表示されます。これはドキュメント検索が認証なしで使えることと整合します。API実行を使うときは、前述のIAM権限でOAuth認可を通します。

Claude DesktopはSigV4(uvxでプロキシを起動する設定)でも接続できます。OAuthで使うなら、リモートサーバーとして手で追加し、URLの末尾に?oauth=initializeを付けます。

https://aws-mcp.us-east-1.api.aws/mcp?oauth=initialize

このパラメーターは、OAuthの自動検出に対応しきれないクライアントに、サーバー側から認可フローを明示的に始めさせるためのものです。Claude Codeでは不要です。認証エラーが出たクライアントで試す価値があります。

OAuthでできないこと

OAuthのセッションは1つのIAMロールに紐づきます。アカウントを切り替えるには再認可が必要です。同じセッションでの複数アカウント切り替えは、OAuthでは使えません。

SigV4でClaude Codeにつなぐ

認証情報の準備

AWS CLIは2.32.0以降を使います。aws loginは認証情報を15分ごとに自動更新し、最大12時間のセッションを張れます。

aws login
aws sts get-caller-identity

SSOや長期のアクセスキーを使う場合は、それぞれの方式でサインインしても構いません。いずれもaws sts get-caller-identityでプロキシに渡る認証情報が有効か先に確かめておくと、後の切り分けが楽になります。トークン切れの直し方はClaude CodeでAWS認証が切れたときの対処に書いています。

MCPの登録

SigV4ではMCP Proxy for AWSがリクエストに署名します。uvxでプロキシを起動する形で登録します。

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": {}
}'

URLのリージョンは「どのMCPサーバーに接続するか」を決めます。AWS_REGIONは「AWSの操作を既定でどのリージョンに向けるか」を決めます。上の例はus-east-1のサーバーに接続し、操作はus-west-2に向けます。AWS_REGIONを省くと、操作はus-east-1が既定になります。

複数アカウントを切り替える

SigV4でだけ使える機能が、プロファイルの切り替えです。プロキシに複数のプロファイルを渡すと、run_script、get_presigned_url、get_tasksにaws_profileというパラメーターが加わります。

mcp-proxy-for-aws-cli \
  https://aws-mcp.us-east-1.api.aws/mcp \
  --profile prod-readonly dev staging

先頭のプロファイルが既定で、aws_profileを省くとそれで署名されます。宣言していないプロファイルを指定するとプロキシがエラーにします。~/.aws/configの他のプロファイルをエージェントが探して使うことはありません。必要なプロキシはmcp-proxy-for-awsの1.6.0以降です。

既定を読み取り専用のプロファイルにしておけば、書き込みの権限があるプロファイルは明示的に指定されたときだけ使われます。本番プロファイルの前にClaude Code側で承認を挟む手は、後の権限設計で扱います。

リージョン別エンドポイントを選ぶ

AWS MCP Serverは8リージョンにエンドポイントがあります。URLのus-east-1の部分を差し替えるだけで、接続先が変わります。

リージョンコード
米国東部(バージニア北部)コードus-east-1
米国西部(オレゴン)コードus-west-2
アジアパシフィック(東京)コードap-northeast-1
アジアパシフィック(シンガポール)コードap-southeast-1
アジアパシフィック(シドニー)コードap-southeast-2
欧州(フランクフルト)コードeu-central-1
欧州(アイルランド)コードeu-west-1
欧州(ロンドン)コードeu-west-2

URLの形はhttps://aws-mcp.<リージョン>.api.aws/mcpです。Claudeのコネクタ紹介ページに載っているのは、us-east-1とeu-central-1の2本です。東京(ap-northeast-1)を含む残りは、Claude Codeやリモートサーバーの手動登録で使います。

クォータは、特に記載がなければリージョンごとの値です。データ保護のページは、一時的な処理がどのリージョンで行われるかを明示していません。データの置き場所を要件にする組織は、AWSに確認が必要です。

接続を確かめる

登録できたら、Claudeに次のように頼みます。

利用できるAWSリージョンを教えて。

aws___list_regionsが呼ばれてリージョンの一覧が返れば、接続は通っています。ツールの一覧はaws___search_documentationとaws___retrieve_skillなどが並んでいるはずです。初回の接続は初期化に数分かかることがあります。

認証エラーでツールが読み込まれないと、エージェントはAWS MCPのツールを呼べません。「エージェントがAWSのツールを使ってくれない」ときの第一の疑いは、認証情報の期限切れです。

権限の絞り方はAWSのIAMとClaudeのpermissionsの2か所で決める

エージェントに何をさせるかは、AWS側のIAMとClaude側のpermissionsの2か所で絞ります。

AWS側: MCP経由だけを拒否する

AWS MCP Serverは独自のIAMアクションを持ちません。リクエストにMCP用の条件キーを足して、各サービスに転送します。認可は、あなたの既存のIAMポリシーでそのサービス側が判断します。

  • aws:ViaAWSMCPService: AWSが管理するMCPサーバーを経由するとtrue(Boolean)
  • aws:CalledViaAWSMCP: 経由したMCPサーバーのサービスプリンシパル。AWS MCP Serverはaws-mcp.amazonaws.com

この条件キーは、MCP経由のときだけ破壊的な操作を禁じる使い方に向きます。次の例では、S3の読み取りは許可し、MCP経由でのバケット削除とオブジェクト削除だけを拒否します。

[
  {
    "Sid": "AllowS3ReadOperations",
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": "*"
  },
  {
    "Sid": "DenyDeleteWhenAccessedViaMCP",
    "Effect": "Deny",
    "Action": ["s3:DeleteObject", "s3:DeleteBucket"],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com"
      }
    }
  }
]

これはAWSが示している例の形です。組織全体で使えるSCPにも、同じ条件を書けます。aws:ViaAWSMCPServiceをtrueで拒否すれば、AWS管理のMCPサーバー経由の操作を全面的に止められます。

プレビュー期間に使われていたaws-mcp:InvokeMcp、aws-mcp:CallReadOnlyTool、aws-mcp:CallReadWriteToolは、いまは不要で効果もありません。これらをDenyに使っていた古いポリシーは、MCP経由の遮断として機能していないため、条件キーへ書き換えが必要です。

OAuthで接続する組織では、signin:OAuthClientId(承認済みクライアントだけを許可)やsignin:OAuthGrantType(client_credentialsのブロックなど)、signin:OAuthRedirectUri(localhostや社内ドメインに限定)を使えます。

Claude側: 呼ぶたびに確認する

AWS側のDenyは最終防衛です。その手前で、Claude Codeのpermissionsを使って操作ごとの確認を入れられます。permissionsの規則名は、Claude Codeに登録したサーバー名が基準です。aws-mcpという名前で登録したなら、mcp__aws-mcp__で始まります。

{
  "permissions": {
    "allow": [
      "mcp__aws-mcp__aws___search_documentation",
      "mcp__aws-mcp__aws___read_documentation",
      "mcp__aws-mcp__aws___retrieve_skill",
      "mcp__aws-mcp__aws___list_regions",
      "mcp__aws-mcp__aws___get_regional_availability"
    ],
    "ask": [
      "mcp__aws-mcp__aws___run_script",
      "mcp__aws-mcp__aws___get_presigned_url"
    ]
  }
}

知識系は自動で通し、スクリプト実行と署名付きURLの発行は毎回確認します。これは設定の一例です。あなたの環境の既定の許可モードと合わせて調整してください。Claude Codeはパラメーターを条件にしたMCPのルール(括弧付き)を読み込み時にスキップするので、「このスクリプトだけ許可」といった中身での判定はできません。ツール単位で絞ることになります。

CLAUDE.mdには、手順の方針を短く書いておくと実行が安定します。

## AWS操作の方針
- AWSの調査には aws-mcp を使い、まず aws___search_documentation で確認する
- aws___run_script は読み取り系のAPIから始める。書き込みを含むときは実行前に内容を説明する
- 本番用プロファイルは明示的に頼まれたときだけ使う

プラグイン以外のMCP追加を管理設定で止めている組織では、claude mcp add自体が拒否されます。その場合はclaude mcp addが失敗する原因を先に確認してください。

データはどこを通り、何が残るか

AWS MCP Serverはステートレスなプロキシとして、あなたに代わってAWS APIを呼びます。顧客のコンテンツを保存するS3、DynamoDB、EBS、SQSなどの永続ストレージは使いません。処理中に一時的に置かれるファイルは、LambdaのTmp領域とAgentCore Runtimeの一時ストレージだけです。

  • 一時ストレージはAWS管理キーで暗号化され、顧客ごとに隔離される
  • 保持の上限は8時間で、ほとんどの処理は数秒で終わる
  • 一時ストレージにカスタマー管理のKMSキーは使えない
  • 通信はクライアントからサーバーも、サーバーから下流のAWS APIも、TLSで暗号化される。TLS 1.2が必須で1.3を推奨する
  • FIPSエンドポイントには対応していない

FIPS 140-3の検証済み暗号モジュールが要件の組織では、最後の点が導入の可否に直結します。

ローカルのファイルはサーバーから読めません。デプロイパッケージのアップロードのような処理では、あなた自身のS3バケットへの署名付きURLを経由します。流れは3段階です。

手順

ファイルがサーバーに渡るまで

  1. 1

    署名付きURLを発行する

    サーバーが、あなたのS3バケットを指す署名付きURLを作ります。URLの有効期限は最長15分です。

  2. 2

    自分のバケットへアップロードする

    ファイルをその署名付きURLでバケットに置きます。この時点でS3のリクエスト料金と保管料金があなたのアカウントにかかります。

  3. 3

    サービスがS3の参照を渡す

    対象サービスがS3の場所を直接受け取れるなら、ファイルはサーバーにダウンロードされません。内容そのものが必要なときだけ、一時ストレージに落として処理し、すぐに削除します。

上限は、サーバーが処理のためにダウンロードする単一ファイルが125MB、ディレクトリアップロード用のzipが1GB、実行環境の全ステージング合計が4GBです。S3のオブジェクトがカスタマー管理キーで暗号化されている場合は、あなたの認証情報にkms:Decryptが必要で、これを外せばサービスはその中身にアクセスできなくなります。

クォータと監査ログ

リクエストの上限は、認証の有無で大きく違います。

項目既定値引き上げ
認証済みリクエスト(アカウント・リージョンごと)既定値毎秒10(継続)引き上げ不可
認証なしリクエスト(送信元IP・リージョンごと)既定値毎秒5(継続)引き上げ不可
同時接続数(アカウント・リージョンごと)既定値100引き上げ不可
同時アクティブセッション(アカウントごと)既定値180引き上げ可
同時アクティブセッション(ユーザーごと)既定値90引き上げ可

超過分は429で返されます。チームで同じアカウントを共有してClaudeからつなぐ場合は、1アカウントあたり毎秒10と、同時接続100が先に効きます。使用量はCloudWatchのAWS/Usage名前空間で見られ、Service Quotasで警告を設定できます。

監査はCloudTrailに残ります。認証が必要なツールの呼び出しは、すべてCloudTrailのイベントになります。OAuthでは、AWS Sign-inのAuthorizeOAuth2AccessとCreateOAuth2Tokenも記録され、どのOAuthクライアントがいつ認可されたかを追えます。API呼び出しにはaws:SignInSessionArnが付くので、OAuthセッションと実際の操作を突き合わせられます。

CloudTrailのツール名には注意が必要です。MCPクライアントではaws___retrieve_skillと見えるツールが、CloudTrailには名前空間の接頭辞なしのretrieve_skillで記録されます。ログをツール名で検索するときは、接頭辞を外して探します。

つまずきやすいエラーの切り分け

症状原因対処
ExpiredTokenException原因一時認証情報の期限切れ。最も多い対処aws loginをやり直し、MCPクライアントを再起動
UnrecognizedClientException原因認証情報が無効、または別のパーティション対処aws sts get-caller-identityで確認。awsとaws-cnの取り違えも疑う
InvalidSignatureException原因署名の不一致。時計のずれが典型対処端末の時計をAWSの時刻から5分以内に合わせる
OAuth後に400のエラーページ原因OAuth用の2アクションがない対処AWSMCPSignInOAuthAccessPolicyを付ける
No AWS credentials found.原因認証情報が見つからない対処aws loginで設定する

認証エラーの出ているまま放置すると、MCPサーバーの初期化に失敗して、AWSのツールそのものが読み込まれません。ツールが一覧に出ないときは、まず認証を疑います。

まとめ

ブラウザだけで試すならOAuth、AWSの作業を端末でClaude Codeに任せるならSigV4が基本線です。複数アカウントの切り替えが要る時点で、OAuthでは足りなくなります。

導入前にやることは2つあります。1つはIAMのDenyを条件キーで書き直すこと。もう1つは、FIPSエンドポイントが必須の環境ではそもそも使えないと知っておくことです。API実行まで広げる前に、Claude側のpermissionsでスクリプト実行に確認を挟んでおくと、意図しない書き込みを承認の段階で止められます。

旧来のローカル実行型であるaws-api-mcp-serverからの移行はaws-api-mcp-serverの権限設計に、請求データを読ませる使い方はAWS Billing MCPサーバーの手順に、Azure側の同種の構成はAzure MCPサーバーにまとめています。

この記事を共有:XはてブLinkedIn