developersIO
[アップデート] AWS MCP Server が AI エージェントからの接続に業界標準の OAuth 2.1（AWS Sign-In 経由）をサポートしたので試してみました

[アップデート] AWS MCP Server が AI エージェントからの接続に業界標準の OAuth 2.1（AWS Sign-In 経由）をサポートしたので試してみました

AWS MCP Server が OAuth 2.1（AWS Sign-In 経由）をサポートしました。従来の認証情報事前配布やローカルプロキシが不要になり、ブラウザサインインだけで AI エージェントを AWS に直接接続できるようになったこのアップデートについて紹介します。
AWSModel Context Protocol (MCP)ClaudeClaude Code生成AI
2026.07.11

クラウド事業統括本部の石川です。AWS MCP Server が、AI エージェントからの接続に業界標準の OAuth 2.1（AWS Sign-In 経由）をサポートしました。追加の認証プロキシソフトウェアを用意することなく、既存の AWS アイデンティティ・IAM 権限・ガバナンスをそのまま使って、AI エージェントを AWS に接続できるようになります。

https://aws.amazon.com/jp/about-aws/whats-new/2026/07/oauth-aws-mcp-server/

https://aws.amazon.com/jp/blogs/security/introducing-oauth-support-for-aws-mcp-server/

AWS MCP Server とは

AWS MCP Server は、Model Context Protocol（MCP）に対応した AWS 公式の MCP サーバーで、Agent Toolkit for AWS の一部として提供されています。Claude Code や Kiro のような AI エージェント（MCP クライアント）が AWS にアクセスするための窓口となるサーバーです。

https://dev.classmethod.jp/articles/20260507-aws-mcp-server-ga/

これまでは、エージェントを AWS MCP Server に接続する際にローカルプロキシなどの追加の認証の仕組みが必要になるケースがありました。今回のアップデートにより、OAuth 対応の MCP クライアントであれば追加ソフトウェアなしで直接接続できるようになりました。

今回のアップデートの「嬉しさ」を理解するには、まず従来どうだったかを押さえておくと分かりやすいです。

従来の接続方式

AWS MCP Server のエンドポイント（https://aws-mcp.us-east-1.api.aws/mcp）は SigV4 署名で保護 されています。そのため従来は、エージェント側の環境に SigV4 署名が可能な AWS 認証情報を事前にセットアップ しておく必要がありました。具体的には aws configure・SSO ログイン・環境変数などで認証情報を用意し、mcp-proxy-for-aws（uvx 経由のローカルプロキシ）を挟んで、MCP のリクエストを 1 つずつ SigV4 署名してエンドポイントへ中継する、という構成です。

// 従来（SigV4 プロキシ方式）の MCP 設定例
{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws==1.6.2",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-west-2"
      ]
    }
  }
}

この方式には、次のような制約がありました。

  • 認証情報の事前配布・セットアップが前提: エージェントを動かす各環境に、あらかじめ SigV4 署名可能な AWS 認証情報を用意しておく必要がある
  • ローカルプロキシ（uvx / mcp-proxy-for-aws）が必須: MCP クライアントから直接ではなく、必ずプロキシを経由する
  • MCP 標準の OAuth フローで直結できない: Claude Code のようなリモート MCP（HTTP transport）クライアントが備える「標準的な OAuth フローで繋ぐ」導線を、そのまま使うことができなかった

https://dev.classmethod.jp/articles/20260506-agent-toolkit-for-aws/

https://dev.classmethod.jp/articles/aws-mcp-server-claude-code-20260507/

アップデート内容

AWS MCP Server が AWS Sign-In を通じた OAuth 2.1 認可をサポートしました。AWS Sign-In が OAuth の認可サーバーとして機能し、スコープを絞ったアクセストークン（ベアラートークン）を発行します。エージェントはこのトークンを使って AWS MCP Server に接続します。

新旧の比較

従来（SigV4 プロキシ方式）と今回の OAuth 方式を並べると、変化は次のとおりです。

観点 従来（SigV4 プロキシ方式） 今回（OAuth 2.1 方式）
接続方式 ローカルプロキシ（mcp-proxy-for-aws / uvx）を経由 エンドポイントに直結
認証情報の準備 SigV4 署名可能な AWS 認証情報を各環境に事前セットアップ ブラウザサインインのみ（既存セッションは再利用可）
追加ソフトウェア uvx / mcp-proxy-for-aws が必要 不要
クライアント登録 ―（OAuth 非対応） DCR で自動登録（クライアント ID/シークレットの手動発行が不要）
トークン 都度 SigV4 署名（トークンなし） 短命のアクセストークン（1 時間）＋リフレッシュトークン（最大 12 時間）
非対話（ヘッドレス） SigV4 で直接署名 client_credentials グラントで OAuth トークンを取得する公式パス
ガバナンス IAM ポリシーのみ IAM に加え OAuth 条件キー・トークン失効・CloudTrail 監査

新しくできるようになったこと

今回のアップデートで具体的に嬉しいのは、以下の 4 点です。

  1. ブラウザサインインだけで直接接続できる
    claude mcp add --transport http aws-mcp https://aws-mcp.us-east-1.api.aws/mcp を実行し、初回アクセス時にブラウザで開く AWS Sign-In ページで、コンソールや CLI と同じ方法でサインイン・承認するだけで接続が完了します。認証情報を各環境へ事前配布する必要がなくなり、既存の AWS アイデンティティ・サインイン方法・IAM 権限・ガバナンスがそのまま適用されます。IAM フェデレーション・IAM Identity Center・ルート/IAM ユーザーのいずれにも対応し、Okta や Ping Identity 経由のフェデレーションも利用できます。すでにコンソールへのアクティブなサインインセッションがあれば、再サインインなしでそのセッションを再利用できます。

  2. DCR（動的クライアント登録）による自動セットアップ
    エージェントは初回接続時に、保護リソースメタデータ（RFC 9728）と OAuth サーバーメタデータ（RFC 8414）を取得し、RFC 7591 の DCR で自動的にクライアント登録して認可コードフローを開始します。開発者が OAuth クライアント ID やシークレットを手動でプロビジョニングする必要はありません。これは MCP 仕様の標準的な認可フローそのものなので、Claude Code に限らず Kiro・Codex・Gemini・GitHub Copilot など MCP 対応エージェント全般で同じ手順が使えます。

  3. ヘッドレス（非対話）認可
    ブラウザや人間の介在なしに動くエージェント向けに、aws signin create-oauth2-token-with-iam で既存の AWS 認証情報（SigV4）から OAuth アクセストークンを取得する client_credentials グラントが用意されました。CI/CD やサーバー上の自律エージェントから AWS MCP Server を叩くパスが、公式に用意された形です。

  4. 管理者向けのガバナンス機能（新規）
    OAuth 条件キー、トークン検査（Introspection）・失効（Revocation）API、aws:SignInSessionArn によるセッション単位の制御、CloudTrail 監査イベントが追加され、エンタープライズが「誰が・どのエージェントで・どのセッションから」接続したかを統制・監査できるようになりました（詳細は後述）。

なお、エージェントを認可しても、そのエージェントに追加の AWS 権限が付与されるわけではありません。すべてのリクエストは既存の IAM ポリシー・SCP・RCP・Permission Boundary・データ境界で評価されます。

2 つの認可モデル

用途に応じて、対話型と非対話型の 2 つの認可モデルが用意されています。

  • 対話型（インタラクティブ）: ブラウザと人間が介在するケース向けです。OAuth の認可コードフローとリフレッシュトークンフローを利用し、動的クライアント登録（DCR）によってクライアントが自動登録されます。ローカルワークステーションで開発者がエージェントを実行する場合などが該当します。
  • 非対話型（ヘッドレス）: ブラウザや人間の介在なしに動作するエージェント・アプリケーション向けです。すでに AWS 認証情報を持っている場合に、その認証情報から OAuth アクセストークンを取得します。AWS Sign-In が静的なクライアントシークレットの代わりに SigV4 認証（AWS の署名）を使い、短命のアクセストークンを返します。

管理者向けのガバナンス機能

管理者は、使い慣れた IAM ポリシーに加えて、今回追加された OAuth 向けの機能でアクセスを統制できます。OAuth の認可グラントは arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com という IAM リソースとして表現され、signin:AuthorizeOAuth2Access / signin:CreateOAuth2Token の各アクションを条件キーで制御できます。

  • 条件キー: signin:OAuthClientId（クライアントの ARN）、signin:OAuthRedirectUri（リダイレクト先の制限）、signin:OAuthGrantType（許可するフローの制限）、signin:OAuthClientAuthentication（クライアント認証方式の制限）など。アクセストークンにはグローバル条件キー aws:SignInSessionArn が付与され、疑わしい特定の OAuth セッションだけを他へ影響なくピンポイントで拒否できます。
  • トークン検査・失効 API: 発行済みトークンの状態確認（Introspection）や失効（Revocation）が可能です。特定のリフレッシュトークンだけを個別に無効化できます。
  • CloudTrail 監査: 認可リクエスト・トークン発行・失効などの操作を CloudTrail のイベントとして記録します。OAuth トークン経由の AWS API 呼び出しには SignInSessionArn コンテキストが付与されるため、元のサインインセッションと実際の API アクティビティを相関して追跡できます。

たとえば、リダイレクト先を localhost に限定して、意図しないリダイレクト先へのトークン受け渡しを防ぐには、次のような IAM ポリシー（あるいは SCP）を使います。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "signin:AuthorizeOAuth2Access",
      "Resource": "arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com",
      "Condition": {
        "StringLike": {
          "signin:OAuthRedirectUri": [
            "http://localhost:*/*",
            "http://127.0.0.1:*/*"
          ]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "signin:CreateOAuth2Token",
      "Resource": "arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com"
    }
  ]
}

認可フロー

対話型（認可コードフロー）の大まかな流れは以下のとおりです。

従来との最大の違いは、エージェントが AWS 認証情報を一切持たずに、ブラウザ経由のサインインとメタデータ探索・DCR だけで接続を確立できる 点です。認証情報の事前セットアップやローカルプロキシの起動が不要になり、MCP 標準の OAuth フローがそのまま流れます。

やってみた

以降では、Claude Code を例に、接続手順を紹介します。

前提条件

  • AWS MCP Server エンドポイント: https://aws-mcp.us-east-1.api.aws/mcp （us-east-1）
  • 認可コードを受け取るためのローカルリスナー（127.0.0.1:3118）
  • AWS CLI コマンド（aws-cli/2.35.21）

エージェントが利用する IAM ロールに権限を付与

エージェントが利用する IAM ロールに、AWS マネージドポリシー AWSMCPSignInOAuthAccessPolicy をアタッチします。

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

<MyRole>は、あなたが AWS にサインインしている IDです。この場合は新規ロールを作る必要はなく、この既存ロールにポリシーを付けるだけです。

`AWSMCPSignInOAuthAccessPolicy` の中身はこちら
% aws iam get-policy-version \
  --policy-arn arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy \
  --version-id v1
{
    "PolicyVersion": {
        "Document": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Sid": "AllowOAuthForAWSMCP",
                    "Effect": "Allow",
                    "Action": [
                        "signin:AuthorizeOAuth2Access",
                        "signin:CreateOAuth2Token"
                    ],
                    "Resource": "arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com"
                }
            ]
        },
        "VersionId": "v1",
        "IsDefaultVersion": true,
        "CreateDate": "2026-07-09T06:57:15+00:00"
    }
}

Claude CodeにMCPサーバーの追加

次に、AWS MCP Server のエンドポイントを MCP クライアントに追加します。

% claude mcp add --transport http aws-mcp-oauth https://aws-mcp.us-east-1.api.aws/mcp
Added HTTP MCP server aws-mcp with URL: https://aws-mcp.us-east-1.api.aws/mcp to local config
File modified: /Users/ishikawa.satoru/.claude.json [project: /Users/ishikawa.satoru/workspaces/cc/blog/20260711-aws-mcp-server-oauth]

補足: 上記の claude mcp add で aws-mcp という名前が local config にすでに登録済みの場合は、MCP server aws-mcp already exists in local configというエラーが表示されました。私は既存のaws-mcpを削除しましたが、aws-mcp-oauthという名前で登録しています。

ブラウザで AWS Sign-In ページから接続を許可する

1. /mcp を実行 を実行して、次に aws-mcp-oauth を選択します。

20260710-aws-mcp-server-oauth-1

2. aws-mcp-oauth を選択して、Authenticate を選択します。

20260710-aws-mcp-server-oauth-2

3. 下記のURLをブラウザで AWS Sign-In が開きます。

20260710-aws-mcp-server-oauth-3

4. AWS Sign-In ページでアクティブセッションで使う認証します。

追加後、ブラウザで AWS Sign-In ページにリダイレクトされるので、既存の AWS 認証情報でサインインし、接続を許可します。上の部分を押します。

20260710-aws-mcp-server-oauth-4

すると、Authentication successfulが表示されます。

20260710-aws-mcp-server-oauth-5

**5. プロンプト（クエリの実行）で、MCPサーバー（aws-mcp-oauth）を呼び出します。 **

20260710-aws-mcp-server-oauth-6

非対話型（ヘッドレス）のアクセストークン取得

非対話型（ヘッドレス）の場合は、以下のように AWS CLI でアクセストークンを取得します。

$ aws signin create-oauth2-token-with-iam \
  --grant-type client_credentials \
  --resource aws-mcp.amazonaws.com \
  --region us-east-1

20260710-aws-mcp-server-oauth-7

なお、SDK や AWS CLI のバージョンによっては更新が必要な場合があります。詳細は公式ドキュメントを参照してください。

トークンのライフサイクル

  • 対話型（認可コードフロー）: アクセストークンの有効期限は 1 時間です。リフレッシュトークン（最大 12 時間有効）で自動更新されるため、セッション中に再サインインする必要はありません。
  • 非対話型（client_credentials フロー）: アクセストークンの有効期限は「呼び出し元セッションの有効期限」と「1 時間」の短い方（JWT 形式）です。こちらは リフレッシュトークンが発行されない ため、期限が切れたら再度 create-oauth2-token-with-iam でトークンを取得します。

事前準備と注意点

  • 追加権限は付与されない: 認可はあくまで「エージェントがあなたに代わって AWS MCP Server にアクセスする」ことを許可するだけで、追加の AWS 権限は付与されません。実際に実行できる操作は、既存の IAM ポリシー・SCP・RCP・Permission Boundary・データ境界の範囲に限られます。
  • マネージドポリシーのアタッチが必須: 事前準備として、IAM プリンシパルに AWSMCPSignInOAuthAccessPolicy（signin:AuthorizeOAuth2Access と signin:CreateOAuth2Token を許可）をアタッチしておく必要があります。
  • マルチアカウント（プロファイル切替）は OAuth 未対応: 1 セッション内で複数の AWS アカウントを横断的に扱いたい場合、OAuth 認証ではプロファイル切替がサポートされません。その用途では、従来どおり mcp-proxy-for-aws を使った SigV4 認証を利用します。OAuth と SigV4 は排他ではなく、用途に応じて使い分けられます。

最後に

従来は、SigV4 署名可能な AWS 認証情報を各環境に事前セットアップし、mcp-proxy-for-aws などのローカルプロキシを挟まないと AWS MCP Server に接続できませんでした。今回のアップデートで、AWS MCP Server が OAuth 2.1（AWS Sign-In 経由）をサポートし、認証情報の事前配布やローカルプロキシなしに、MCP 標準の OAuth フローでブラウザサインインだけで直接接続できる ようになりました。一言でまとめると「認証情報の事前配布なしに MCP 標準の OAuth フローで繋げるようになり、同時にエンタープライズがそれを IAM/SCP/CloudTrail で統制・監査できるようになった」アップデートです。

対話型・非対話型の 2 つの認可モデルに対応し、認証・権限・ガバナンスは既存の IAM の仕組みをそのまま活用できます。管理者は条件キーやトークン失効 API、CloudTrail による監査でアクセスを統制でき、signin:OAuthRedirectUri を localhost に限定するといったガバナンスパターンも組めます。

AI エージェントから AWS を安全に操作したい方は、まずは開発用アカウントで Claude Code などの OAuth 対応クライアントから接続を試してみてはいかがでしょうか。

Claudeならクラスメソッドにお任せください

クラスメソッドは、Anthropic社とリセラー契約を締結しています。各種製品ガイドから、業種別の活用法、フェーズごとのお悩み解決などサービス支援ページにまとめております。まずはご覧いただき、お気軽にご相談ください。

サービス詳細を見る

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

Authorization Code flowを使ってMCPサーバーをAmazon Bedrock AgentCore Gatewayに接続してみた
せーの
2026.04.07
AWS MCP Server の新機能「OAuth認証」を Kiro CLI で試してみた
suzuki.ryo
2026.07.10
AWS DevOps Agent × MCP｜そのまま使えるMCPサーバの雛形を作ってみました
SIN
2026.04.04
[アップデート]Amazon Bedrock AgentCore GatewayのMCP ServerターゲットでIAM認証が利用可能になりました
神野 雄大
2026.04.12