aws/mcp-proxy-for-aws解説｜SigV4を肩代わりしAWS上MCPサーバに繋ぐ公式プロキシ

この記事ではMCPに特化して解説します。MCP（Model Context Protocol）全般は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル をご覧ください。

aws/mcp-proxy-for-awsは、AWSが2026年に公開した公式のMCPプロキシ兼Pythonライブラリだ。Bedrock AgentCoreや独自にホストされたAWS上のMCPサーバはほぼ例外なくIAM認証（SigV4署名）で守られているが、Claude DesktopやKiro CLIなど主要なMCPクライアントはOAuth／APIキー前提で、AWSの署名認証に直接対応していない。このギャップを埋めるためだけに作られた、極めて目的の絞られたツールだ。

ローカルでstdio MCPサーバとして起動するとAWS署名を肩代わりするプロキシとして振る舞い、Pythonライブラリとして使うとStrands・LangChain・LlamaIndexから直接AWS MCPエンドポイントを叩けるクライアントになる。本記事ではAWS MCP Proxyの位置付け、SigV4プロキシの内部動作、Claude Desktop・Kiro CLI・Strands Agentsからの導入手順、AWS Labsの他MCP関連OSSとの違いまでを実装目線で整理する。

AWS MCP Proxyとは — IAM認証MCPサーバ専用の翻訳機

Model Context Protocol（MCP）はAnthropicが2024年に策定したオープン標準で、AIアシスタントと外部ツールを繋ぐための共通プロトコルだ。プロトコル仕様自体は認証方式を強制せず、stdio・HTTP・Streamable HTTPといったトランスポート層と、OAuth・APIキー・mTLSといった認証手段は実装側に委ねられている。

AWSがMCPサーバをBedrock AgentCoreやAPI Gateway経由で公開する場合、AWSの世界では当然のようにIAMポリシー＋SigV4署名で保護される。これは妥当な設計だが、現時点（2026年5月）のClaude Desktop・Kiro CLI・Cline・Continueなどの主要MCPクライアントは、AWSのSigV4署名をネイティブにサポートしていない。OAuth 2.1のフローを実装したクライアントは増えてきたが、リクエストごとにAWS署名を計算してAuthorizationヘッダに乗せる、という処理はMCPクライアントの責務外と見做されている。

mcp-proxy-for-awsはこのギャップを埋めるためだけに存在する。MCPクライアントから見ると普通のローカルstdio MCPサーバに見え、AWS側エンドポイントから見ると正しくSigV4署名されたStreamable HTTPリクエストを送ってくる。両者の中間で「クレデンシャル取得→リクエスト署名→AWSへ転送→レスポンス返却」を自動化する、いわば翻訳機だ。

このシーケンス図が示す通り、ユーザーから見えるのは普通のClaude DesktopとMCPサーバのやり取りだけ。SigV4署名・クレデンシャル取得・リクエスト転送はすべてプロキシ内で完結する。

なぜ単独のプロキシが必要なのか — 既存ツールではダメな理由

AWS上のMCPサーバへの接続経路として、表面的には他にも候補がある。それらでは不足する理由を整理しておく。

要するに「IAM認証で守られたAWS上のMCPサーバを、OAuth非対応のMCPクライアントから叩く」という条件下では、SigV4を肩代わりする中間レイヤが必須になる。mcp-proxy-for-awsはこの一点に特化している。

主要機能 — プロキシとライブラリの2形態

READMEに明記されている通り、本ツールは2つの利用形態を持つ。

1. プロキシモード — stdio MCPサーバとして振る舞う

uvxまたはDockerで起動し、Claude DesktopやKiro CLIから普通のローカルMCPサーバとして登録する。クライアント側はAWSの存在を意識しない。

主要オプション（README抜粋を整理）：

--read-onlyは地味に重要なオプションだ。MCPサーバ側がツール定義に書き込み属性をマークしている場合、プロキシ層で物理的に無効化できる。LLMが暴走しても破壊的操作が走らない安全弁になる。

2. ライブラリモード — Pythonコードから直接呼び出す

pip install mcp-proxy-for-awsでインストールし、aws_iam_streamablehttp_clientを取得して各種AIフレームワークのMCPClientに渡す。プロキシプロセスを介さないため、エージェントを動かす単一プロセス内で完結する。

from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client

mcp_client = aws_iam_streamablehttp_client(
    endpoint="https://your-mcp-endpoint.bedrock-agentcore.us-east-1.amazonaws.com/...",
    aws_region="us-east-1",
    aws_service="bedrock-agentcore",
)

クレデンシャルを明示的に渡すこともできる。CIや一時ロール想定のケースで使う。

from botocore.credentials import Credentials
from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client

creds = Credentials(
    access_key="AKIA...",
    secret_key="...",
    token="...",
)

mcp_client = aws_iam_streamablehttp_client(
    endpoint="https://...",
    aws_region="us-east-1",
    aws_service="bedrock-agentcore",
    credentials=creds,
)

前提条件と動作環境

READMEから整理すると以下の通り。

• Python 3.10以上
• uv パッケージマネージャ（uvx経由でゼロインストール起動するため推奨）
• AWSクレデンシャル（AWS CLI設定 / 環境変数 / IAMロール / SSO のいずれか）
• Docker Desktop（オプション、コンテナで動かす場合のみ）

クレデンシャルはboto3標準のチェーンで解決される。順序は環境変数 → AWS CLI設定 → コンテナロール → EC2インスタンスメタデータ、というboto3の通常仕様に従う。AWS SSO（IAM Identity Center）使用時は期限切れトークンを自動的に検出し、aws sso loginで更新するだけでプロキシ再起動なしで継続動作する点が運用上ありがたい。

導入手順 — uvx・ローカル・Docker

uvx（最も簡単）

uvx mcp-proxy-for-aws@latest <SigV4 MCPエンドポイントURL>

これだけでPyPIから取得して即実行される。MCPクライアントから繰り返し呼ばれる前提なので、最新版固定で問題ない。

ローカルリポジトリから

git clone https://github.com/aws/mcp-proxy-for-aws.git
cd mcp-proxy-for-aws
uv run mcp_proxy_for_aws/server.py <SigV4 MCPエンドポイントURL>

開発・デバッグ・カスタムパッチ適用時はこちら。uv runが依存解決と実行を一括で行う。

Docker（公式イメージ）

docker pull public.ecr.aws/mcp-proxy-for-aws/mcp-proxy-for-aws:latest

ローカル環境にPythonを入れたくない場合や、サンドボックス的に動かしたい場合の選択肢。AWSクレデンシャルは~/.awsをボリュームマウントで渡す。

クライアント設定例

Kiro CLI（uvでローカルリポジトリを参照）

公式README記載の設定例をそのまま引用する。

{
  "mcpServers": {
    "<server_name>": {
      "disabled": false,
      "type": "stdio",
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/mcp_proxy_for_aws",
        "run",
        "server.py",
        "<SigV4 MCP endpoint URL>",
        "--service",
        "<service_code>",
        "--profile",
        "default",
        "--region",
        "us-east-1",
        "--read-only",
        "--log-level",
        "INFO"
      ]
    }
  }
}

--read-onlyをデフォルトで入れている点に注目。Kiro CLIのようにIDE組み込みで自動実行される環境では、書き込み系ツールを最初から封じておくのが安全側のデフォルトだ。

Claude Desktop（Docker版）

{
  "mcpServers": {
    "<server_name>": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--volume",
        "/full/path/to/.aws:/app/.aws:ro",
        "public.ecr.aws/mcp-proxy-for-aws/mcp-proxy-for-aws:latest",
        "<SigV4 MCP endpoint URL>"
      ],
      "env": {}
    }
  }
}

.awsディレクトリを読み取り専用（:ro）でマウントするのがポイント。コンテナ側からクレデンシャルを書き換えられないように防御している。

環境変数によるクレデンシャル指定

設定ファイルに直書きしたくない場合は、起動シェルで以下を渡す。

export AWS_PROFILE=my-profile
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
export AWS_REGION=us-east-1

CI/CDからエージェントを動かすときはこの形が現実的になる。

AIエージェントフレームワークからの統合

ライブラリモードでは4種類のフレームワーク向けサンプルがexamples/mcp-client/配下に同梱されている。代表的な統合パターンを2つ紹介する。MCPサーバ単体での自然言語ワークフロー構築事例としては n8n MCP｜Claude Codeから自然言語でn8nワークフローを構築するMCPサーバー もあわせて参照すると、AIエージェントとMCPの組み合わせ例が掴みやすい。

パターン1：Strands Agents — クライアントファクトリ統合

Strands Agents SDKはMCPClientにクライアントファクトリを渡す設計。aws_iam_streamablehttp_clientをそのままラムダで返す。

from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client
from strands_agents import Agent, MCPClient

mcp_client_factory = lambda: aws_iam_streamablehttp_client(
    endpoint="<MCP URL>",
    aws_region="us-east-1",
    aws_service="bedrock-agentcore",
)

with MCPClient(mcp_client_factory) as mcp_client:
    mcp_tools = mcp_client.list_tools_sync()
    agent = Agent(tools=mcp_tools, model="...")
    agent.run("AWSのリソース一覧を取得して")

ファクトリ方式なので、クレデンシャルが期限切れになったときも次回呼び出しで自動的に新しいセッションが張られる。

パターン2：LangChain — 直接MCPセッション統合

LangChainのlangchain-mcp-adaptersではClientSessionを非同期で扱うのが標準。

from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client
from mcp import ClientSession
from langchain_mcp_adapters.tools import load_mcp_tools

mcp_client = aws_iam_streamablehttp_client(
    endpoint="<MCP URL>",
    aws_region="us-east-1",
    aws_service="bedrock-agentcore",
)

async with mcp_client as (read, write, session_id_callback):
    async with ClientSession(read, write) as session:
        mcp_tools = await load_mcp_tools(session)
        agent = create_langchain_agent(tools=mcp_tools, ...)

非同期コンテキストの入れ子になる点だけ注意。aws_iam_streamablehttp_clientは(read, write, session_id_callback)の3タプルを返すため、Streamable HTTPのセッション管理が透過的に動く。

パターン3：LlamaIndex

LlamaIndexはMcpToolSpec経由でツールリストを構築する。

from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client
from llama_index.tools.mcp import McpToolSpec
from llama_index.core.agent import ReActAgent

mcp_client = aws_iam_streamablehttp_client(
    endpoint="<MCP URL>",
    aws_region="us-east-1",
    aws_service="bedrock-agentcore",
)

async with mcp_client as (read, write, session_id_callback):
    async with ClientSession(read, write) as session:
        mcp_tools = await McpToolSpec(client=session).to_tool_list_async()
        agent = ReActAgent(tools=mcp_tools, ...)

3フレームワークとも、aws_iam_streamablehttp_clientを取得した後の流れは通常のMCP統合と完全に同一になっている。SigV4周りが差し替えられただけで、フレームワーク側のコードは変わらない、というのが本ライブラリの設計上の最重要ポイントだ。

サンプル実行

cd examples/mcp-client/strands  # langchain / llamaindex / microsoft-agent-framework
uv run main.py

内部動作 — boto3クレデンシャルチェーンとSigV4署名

ライブラリ実装の中身は意外と素直で、要は次の3ステップを毎リクエストごとに繰り返している。

1. クレデンシャル解決：boto3のSessionからクレデンシャルプロバイダチェーンを取り出し、最新のAccessKey/SecretKey/SessionTokenを得る
2. SigV4署名計算：botocoreのSigV4Authを使い、リクエストメソッド・URL・ヘッダ・ボディ・サービス名・リージョンからAuthorizationヘッダを生成
3. Streamable HTTP転送：MCPの公式SDKのStreamable HTTPクライアントに署名済みヘッダを差し込んで送出

SigV4署名はリクエスト単位で計算されるため、SSO等で短命なトークンが切れても次のリクエストで自動的に更新される。プロキシモードでも同じロジックが回るので、長時間Claude Desktopを起動しっぱなしでも署名失敗で詰まる場面は少ない。

トラブルシューティング — 認証失敗とハング対策

READMEに記載のある2大トラブルパターンを整理しておく。

認証エラーが返る場合

• --serviceを明示する：URLからのサービス名推論が外れているケース。Bedrock AgentCoreなら--service bedrock-agentcore、API Gatewayなら--service execute-apiなど
• aws sts get-caller-identityで現在のクレデンシャルが有効か確認
• AWS SSO使用時はaws sso login --profile <profile>を実行
• 期限切れは自動検出・更新されるので、プロキシ再起動は基本不要

ツール呼び出しがハングする

--tool-timeout 60

のように明示的にタイムアウトを設定する。デフォルト300秒は長すぎるケースが多く、エージェントループが固まる原因になる。MCPサーバ側のリトライ・サーキットブレーカと組み合わせて短めに切る運用が現実的。

権限統制 — プロキシ自身でできること／IAM側に任せること

エンタープライズ導入で最初に問われるのが「このOSSで権限統制できるのか」という点だ。結論から言うと、統制の主体はAWS IAM側にあり、プロキシ自身がやれることは --read-only と --profile 切替程度に限定される。プロキシは透過的な署名屋として設計されており、ポリシー判断ロジックは持たない。

レイヤ別の責務分担

つまりプロキシは「IAMが許可した範囲を、さらに --read-only で安全側に絞る」程度しかできない。細かいツール単位の許可・拒否を入れたい場合は、IAMポリシーで対応するAWSアクション（例：s3:DeleteBucket）を明示的に拒否する設計が必要になる。

実運用で効くパターン

1. MCPエンドポイントごとにIAMロールを分ける — --profile をMCPサーバ単位で切り替え、各ロールに必要最小権限のみ付与する。事実上の本命統制
2. AssumeRoleでセッション短命化 — AWS SSO（IAM Identity Center）やaws sts assume-roleで短命クレデンシャルにし、長期アクセスキーをプロキシに渡さない
3. --read-onlyをデフォルトに — エージェント用途では破壊的操作を物理封じ。書き込みが必要なときだけ別プロファイルで起動
4. CloudTrail で監査 — プロキシ側ログではなく、AWS API側の呼び出し記録を一次証跡にする。プロキシ起因かユーザー直接操作かはuserIdentityで判別
5. 条件キーでIAMを縛る — aws:SourceIp（オフィスIP固定）、aws:MultiFactorAuthPresent（MFA必須）、タグベース制御をIAMポリシーで強制
6. AgentCore側のリソースポリシー併用 — Bedrock AgentCoreでホストする場合、AgentCore側のリソースポリシーでも呼び出し元プリンシパルを絞る

例：読み取り専用ロールのIAMポリシー骨子

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:InvokeAgentRuntime"
      ],
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:agent-runtime/<runtime-id>",
      "Condition": {
        "Bool": {"aws:MultiFactorAuthPresent": "true"},
        "IpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "bedrock-agentcore:Update*",
        "bedrock-agentcore:Delete*"
      ],
      "Resource": "*"
    }
  ]
}

--read-onlyをプロキシ側で立てつつ、IAM側でもUpdate*/Delete*を明示Denyしておく二重防御が安全側のデフォルトになる。

プロキシ側に「ない」もの — 補完が要る機能

• ツール単位のallowlist/denylist：「このMCPサーバのlist_bucketsは許可、delete_bucketは拒否」という粒度は持たない。IAM側で対応AWSアクションをDenyする
• 動的承認フロー（human-in-the-loop）：ツール呼び出し前にユーザー確認を挟む仕組みは未実装。Claude Desktop側のツール承認UI、または独自MCPサーバ実装側で対応
• 構造化監査ログ：DEBUGレベルでリクエスト内容は出るが、SIEM連携前提の構造化JSON出力は標準ではない。CloudTrail＋CloudWatch Logs Insightsで補う前提
• レート制限：呼び出し頻度の制限はプロキシ側にはない。API Gatewayや AgentCore側のスロットリング設定で対応
• テナント分離：マルチテナント運用は--profile切替で対応するが、テナントID自動付与のような機能はない

READMEの免責事項に「IAM設定の責任は利用者側にある」と明記されているのは、プロキシが意図的に「素直な署名屋」として設計されているためだ。統制ロジックを持たないからこそ汎用性があるが、IAM設計が雑だと一発で抜ける。エンタープライズ導入時は、プロキシ導入と同じくらいの工数をIAMポリシー設計とCloudTrail監査基盤に割く前提で計画したい。

セキュリティ運用 — 最小権限と書き込み封じ

mcp-proxy-for-awsはAWS資格情報を直接扱う以上、運用面では一定の注意が要る。エンタープライズ向けMCPサーバの権限制御例としては Microsoft Power BI Modeling MCP：Power BIモデルをAIで自動構築するMCPサーバー も参考になる。

実運用時のチェックポイントは以下の通り。

• IAMポリシーは最小権限：プロキシが叩くMCPエンドポイントごとに専用IAMロール／ユーザを切る
• --read-onlyをデフォルトに：エージェントが破壊的操作を行わない用途では物理的に書き込み封じ
• --tool-timeout短め：エージェントがハングしないよう60〜120秒程度に
• --disable-telemetry：プロキシ側の匿名テレメトリ送信を無効化
• .awsは読み取り専用マウント：Docker使用時は/app/.aws:ro
• AWS SSO推奨：長期クレデンシャルではなくSSO短命セッションで運用
• ログレベルは本番INFO：DEBUGはリクエスト内容を出すため機微情報の流出に注意

公式READMEの免責事項にも「IAMポリシー設定の責任は利用者側にある」「LLMは非決定的なので本番投入前に十分テストせよ」と明記されている。エージェント＋IAM＋本番AWSアカウントの組み合わせは事故ったときの被害が大きいので、開発アカウントで一通り通してから本番に上げる手順が原則になる。

既存AWS MCPエコシステムとの違い — 4系統の役割分担

「AWS関連MCP」と一括りにされがちだが、AWSが公開／関与しているMCP関連プロジェクトは大きく4系統あり、サーバとクライアント、ローカル動作とAWS上ホスティングで真逆の役割を持つ。mcp-proxy-for-awsの位置を理解するには全体マップを押さえるのが早い。

4系統マトリクス

サーバとクライアントの真逆構造

• awslabs/mcp = ローカルで動くMCPサーバの実装集（自分がAWS APIを叩く）
• mcp-proxy-for-aws = AWS上に置かれたMCPサーバへ繋ぐためのクライアント（自分はAWS APIを直接叩かない）

同じ「AWS MCP」という名前でも目的が完全に異なる。awslabs/mcp配下のサーバはローカルプロセスとして動き、自身がboto3経由でAWS APIを叩く。一方、mcp-proxy-for-awsはサーバを持たず、リモートのMCPエンドポイント（AgentCoreでホストされたMCPサーバやAPI Gateway+Lambda構成のMCPサーバ）への接続層として動く。

使い分けフロー

具体的な棲み分け例

ケース1：個人開発者がClaude DesktopからS3を触りたい → awslabs/mcp の aws-s3-mcp-server をローカル登録して終わり。mcp-proxy-for-aws不要。

ケース2：社内20人にClaude Desktopから自社CRMデータを触らせたい → 自作MCPサーバを AgentCore Runtime でホスト → 各人が mcp-proxy-for-aws で繋ぐ → IAM Identity Centerで権限統制。これが本ツールの本命ユースケース。

ケース3：CI/CDからAWSリソースをエージェントに操作させたい → awslabs/mcpをCIランナーで動かす（プロキシ不要）か、AgentCoreにホストしてmcp-proxy-for-awsライブラリモードで叩く。

ケース4：既存社内REST APIをMCP化して配布したい → AgentCore Gateway でAPIをMCPツール化 → 利用者は mcp-proxy-for-aws で接続。MCPサーバ自体を書かずに済む。

なぜAWSは2系統（サーバ群＋プロキシ）作ったのか

時系列で見ると意図がはっきりする。

• awslabs/mcp：MCPエコシステム初期（2024-2025）の「とりあえずAWSサービスを叩けるサーバ群」。各サービス専用のローカルMCPサーバを乱立させて、まずは触れる状態を作った
• mcp-proxy-for-aws：Bedrock AgentCoreのMCPホスティング正式化（2026）に合わせた「AWSにMCPサーバを置く時代の標準クライアント」。MCPサーバを社内集約・IAM統制可能にする中央集権化フェーズに対応

つまりMCPの中央集権化（ローカル乱立 → AWS上にホスト）という潮流に対応するために、後発で接続クライアント側の標準として出てきた。awslabs/mcpを置き換えるのではなく、住み分けて補完する関係だ。

「AIエージェントが自社サービスのデータにアクセスする」というエンタープライズ向けユースケースでは、社内側でMCPサーバをAgentCoreに乗せてIAMで保護し、利用者側はmcp-proxy-for-awsで接続する、という分担が自然な形になる。MCPサーバ自体の設計手順は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル を参照。

ユースケース — 現実的な使い所

実際にどういう場面で本ツールが効くかを整理する。

1. Bedrock AgentCoreでホストしたMCPサーバの社内配布

AgentCoreでMCPサーバを動かすと、エンドポイントは自動的にIAM認証で保護される。社内利用者がClaude DesktopやKiro CLIから繋ぐとき、各人のAWS SSOプロファイルを使ってプロキシ経由で接続させれば、ユーザー単位の権限制御がIAMポリシーだけで完結する。

2. 既存MCPサーバをAPI Gateway + Lambdaで公開

オンプレで動かしているMCPサーバをLambda化し、API Gateway（IAM認証）で外向けに出す構成でも、利用者側はmcp-proxy-for-awsで普通に繋がる。OAuthインフラを別途用意せずに済む。

3. CI/CDからのエージェント実行

GitHub Actions等のCI/CDから一時IAMロール（OIDC連携）でAWS MCPサーバを叩きたい場合、ライブラリモードでCredentialsを明示注入するパターンがハマる。エージェントがCI環境内で完結する。

4. マルチアカウント運用

--profile切り替えで本番／ステージング／開発のクレデンシャルを使い分けられる。MCPクライアントの設定ファイルを環境別に分けるだけで運用可能。

ライセンス・統計・コミュニティ

リリース頻度は月1〜2回ペースで、SigV4周りやサンプルコードの追加が中心。Apache 2.0なのでフォーク・社内カスタム配布も問題ない。

限界と向かない用途

万能ツールではないので、向かないケースも明確にしておく。

• OAuth認証のMCPサーバには使えない：Anthropic公式のリモートMCP（OAuth 2.1）やGitHub MCPなどは対象外
• APIキー認証のMCPサーバには使えない：シンプルなAPIキー認証MCPには無関係
• MCPプロトコル自体の機能拡張ではない：ツール発見・スキーマ管理はMCPサーバ側の責任
• AWS SDK代替ではない：MCPクライアント経由でツール呼び出しする層なので、生のAWS API直叩きより遅いケースもある

LLMがそもそもAWS APIを叩く必要があるか、MCP化するメリットが本当にあるか、という設計レベルの判断は別途必要だ。

参照ソース

• aws/mcp-proxy-for-aws GitHub: https://github.com/aws/mcp-proxy-for-aws
• README（プロキシ・ライブラリ・サンプル一式の一次情報）
• examples/mcp-client/ — Strands・LangChain・LlamaIndex・Microsoft Agent Framework向けの公式サンプル
• public.ecr.aws/mcp-proxy-for-aws/mcp-proxy-for-aws — 公式コンテナイメージ
• Apache License 2.0 — ライセンス本文