
Amazon Bedrock AgentCore上にホストしているリモートMCPサーバーに、AIコーディングツールからアクセスする
この記事は、クラスメソッド × AI駆動開発 Advent Calendar 2025 - Adventar 16日目の記事です。
こんにちは、かけい(@takaakikakei)です。
Amazon Bedrock AgentCore は、AWS が提供するマネージド型のエージェント基盤サービスです。AgentCore の Runtime と Gateway 機能を使用することで、リモート MCP サーバーを簡単にホスティングできます。本記事では、AgentCore 上にホストしたリモート MCP を企業内で共有し、AI コーディングツールから利用するユースケースの実装方法を探ります。
課題感
以下は、Runtime と Gateway のインバウンド認証方法です。
| 認証方式 | Runtime | Gateway |
|---|---|---|
| No Authorization | - | ✓ |
| JWT Authentication | ✓ | ✓ |
| IAM SigV4 Authentication | ✓ | ✓ |
企業内で MCP を共有する場合、どの認証方法を利用するのが適切でしょうか?
No Authorization
Gateway で利用可能な No Authorization は、認証なしでアクセスできる方式です。開発やテスト目的での使用は推奨されず、意図的にパブリックアクセスを許可する場合のみの利用が想定されています。企業内での共有には適していません。

JWT Authentication
JWT Authentication は、JSON Web Token (JWT) を使用した認証方式です。Cognito や Entra ID などの認証プロバイダーと連携して利用できます。企業で利用している認証プロバイダーと連携可能な場合は有力な選択肢となりますが、AI コーディングツール側での利用体験に課題があります。例えば、Runtime にホストしたリモート MCP サーバーに Claude Code からアクセスする場合、.mcp.json に以下のように記述します。
{
"mcpServers": {
"agentcore-runtime": {
"type": "http",
"url": "https://bedrock-agentcore.<region>.amazonaws.com/runtimes/<URLエンコードしたRuntime ARN>/invocations?qualifier=DEFAULT",
"headers": {
"Authorization": "Bearer ${ACCESS_TOKEN}"
}
}
}
}
ここで、${ACCESS_TOKEN} は認証プロバイダーから取得した JWT トークンです。JWT トークンは有効期限が短いため、定期的な更新が必要になります。現時点では、認証プロバイダーと MCP の仕様の組み合わせにより、AI コーディングツール側でトークンの自動更新に対応するのは困難です。そのため、ユーザーが手動でトークンを取得し、.mcp.json を更新する必要があり、利用体験が低下するのが課題です。
IAM SigV4 Authentication
IAM SigV4 Authentication は、AWS IAM の認証情報を使用してリクエストに署名する認証方式です。AI コーディングツールを使用するユーザーが AWS アカウントを持っている場合は有力な選択肢となります。対象ユーザーは AWS 利用者に限定されますが、企業内のエンジニアを対象とした MCP 共有には最も適していると考えられます。本記事では、IAM SigV4 Authentication を利用して AgentCore 上にホストしている MCP に AI コーディングツールからアクセスする方法を深掘りします。
前提
本記事では、以下の2つの AWS アカウントが存在する構成を前提とします。
- IAM ユーザーを管理する AWS アカウント(以降、基幹アカウント)
- AgentCore 上に MCP をホスティングする AWS アカウント(以降、MCP アカウント)
IAM SigV4 Authentication を使用した設計
IAM SigV4 Authentication を使用した設計には、以下の課題があります。
- クロスアカウントアクセスをどうするか
- ローカルでの認証情報の管理
- MFA コードの入力の手間をどうするか
- 認証情報を AI コーディングツールに渡す方法
各課題に対する設計方針を以下で説明します。
クロスアカウントアクセスの実現
MCP アカウント上に、基幹アカウントの特定 IAM ユーザーに対して AgentCore の実行権限を付与する IAM ロールを作成します。基幹アカウントの IAM ユーザーは、AWS STS の AssumeRole API を使用して MCP アカウントの IAM ロールを引き受けることで、MCP アカウントの AgentCore 上にホストしている MCP にアクセスできるようにします。
ローカルでの認証情報の管理
基幹アカウントの IAM ユーザーの認証情報は、ローカルマシンに保存します。IAM ユーザーのアクセスキーを ~/.aws/credentials に平文で保存する方法もありますが、一定のセキュリティリスクがあります。そこで、aws-vault を使用してローカルマシンでの認証情報管理を行います。aws-vault は、AWS の認証情報を OS のキーストアに安全に保存し、利用時には STS を使用して一時的な認証情報を取得した上で AI コーディングツールなどに渡すことができます。これにより、認証情報関連のセキュリティリスクを低減できます。
※ オリジナルの fork 元の最新リリースが2024年3月27日であり、現在メンテナンスされていないため、メンテナンスされている上記のfork版を推奨します。なお、Homebrew のインストール先も当該 fork 版に変更されています。
MFA コードの入力の手間の削減
セキュリティ上、基幹アカウントの IAM ユーザーには MFA の有効化を必須とすることを強く推奨します。aws-vault は MFA に対応していますが、MFA トークンの入力は手動で行う必要があります。これを自動化するために、1password-cli を使用して MFA トークンを取得します。1password-cli で MFA トークンを取得するコマンドをスクリプトに組み込むことで、aws-vault の MFA プロンプト時に自動でトークンを提供できるようにします。
認証情報を AI コーディングツールに渡す方法
AWS がオープンソースで公開している「MCP Proxy for AWS」を利用します。これはローカルで動作する MCP クライアント向けのプロキシで、ローカルの AWS 認証情報を使用して MCP 通信を SigV4 で署名し、AWS 上のリモート MCP サーバー(Amazon Bedrock AgentCore Gateway/Runtime 上にホストした MCP サーバーなど)へリクエストを中継します。これにより、AI コーディングツールはプロキシに対して MCP リクエストを送るだけで、SigV4 署名や AWS 認証の実装を意識せずにリモート MCP サーバーへアクセスできます。
やってみた
上記の設計を踏まえて、以下の前提条件で構築を行います。
- AWS IAM の認証情報管理: aws-vault を使用
- MFA トークンの取得: 1password-cli を使用
- AI コーディングツール: Claude Code を使用
- リモート MCP サーバー: Amazon Bedrock AgentCore の Gateway 機能を使用してホスティング
MCP アカウントに IAM ロールを作成する
MCP アカウントに、基幹アカウントの IAM ユーザーに対して AgentCore の実行権限を付与する IAM ロールを作成します。
-
MCP アカウント上で、IAM のサービス画面を開き、「ポリシーの作成」ボタンをクリックします。
-
ポリシーエディタで、JSON タブを選択し、以下のポリシーを入力して「次へ」ボタンをクリックします。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AgentCoreListGetInvokeAll",
"Effect": "Allow",
"Action": [
"bedrock-agentcore:ListAgentRuntimes",
"bedrock-agentcore:GetAgentRuntime",
"bedrock-agentcore:InvokeAgentRuntime",
"bedrock-agentcore:ListGateways",
"bedrock-agentcore:GetGateway",
"bedrock-agentcore:InvokeGateway"
],
"Resource": "*"
}
]
}
ポリシーの内容は、AgentCore 上にホストしている MCP サーバーに対して必要な権限を付与するように適宜調整してください。あまり強い権限を付与すると、AI コーディングツール経由で不要な操作ができてしまう可能性があるため、必要最小限の権限を付与することを推奨します。
-
任意のポリシー名(例:
AgentCoreInvokePolicy)を入力し、「ポリシーの作成」ボタンをクリックします。 -
続いて、MCP アカウント上で、IAM のサービス画面を開き、「ロールの作成」ボタンをクリックします。

- 「信頼されたエンティティの種類を選択」で「別の AWS アカウント」を選択し、基幹アカウントのアカウント ID を入力します。オプションの「MFAが必要」にもチェックを入れて、「次へ」ボタンをクリックします。

-
「許可を追加」で、先ほど作成した AgentCore の実行権限を持つ IAM ポリシーを選択し、「次へ」ボタンをクリックします。
-
任意のロール名(例:
agentcore-mcp)を入力し、「ロールの作成」ボタンをクリックします。

これで、基幹アカウントの IAM ユーザーが MCP アカウントの agentcore-mcp ロールを引き受けることで、MCP アカウント上の AgentCore にアクセスできるようになります。
1password-cli と aws-vault を設定する
Windows ユーザーは、以下のブログを参考に PowerShell 環境での aws-vault と 1password-cli の設定を行ってください。
以下では、macOS ユーザー向けの手順を説明します。
まず、1password-cli の設定を行います。以下の公式ドキュメントを参考に 1password-cli のインストールと初期設定を行ってください。op vault list コマンドで Vault の一覧が表示されたら設定完了です。
続いて、aws-vault のインストールと初期設定を行います。macOS ユーザーは、Homebrew を使用してインストールできます。aws-vault --version コマンドでバージョンが表示されたらインストール完了です。
brew install aws-vault
aws-vault に基幹アカウントの IAM ユーザー情報を登録します。以下のコマンドを実行し、プロンプトに従ってアクセスキー ID とシークレットアクセスキーを入力してください。
# aws-vault add <任意のプロファイル名>
aws-vault add default
~/.aws/config に以下の設定を追加します。
[default]
region = ap-northeast-1
mfa_serial = arn:aws:iam::123456789012:mfa/user-name
mfa_process = op item get 'AWS Account' --otp
[profile mcp]
region = ap-northeast-1
source_profile = default
role_arn = arn:aws:iam::123456789013:role/agentcore-mcp
各パラメータの説明:
mfa_serial: 基幹アカウントの IAM ユーザーに設定されている MFA デバイスの ARNmfa_process: 1password-cli を使用して MFA トークンを取得するコマンド(1Password アプリ上でAWS Accountという名前で MFA トークンを管理している場合)profile mcp: MCP アカウントのagentcore-mcpロールを引き受けるためのプロファイルrole_arn: 引き受けるロールの ARN(MCP アカウントのagentcore-mcpロールの ARN)
設定完了後、aws-vault exec mcp -- aws sts get-caller-identity コマンドを実行して、MCP アカウントの情報が表示されることを確認してください。また、~/.aws/credentials に認証情報を保存していた場合は、セキュリティのため適宜削除しましょう。
MCP アカウントにリモート MCP サーバーをホスティングする
MCP アカウント上で、Amazon Bedrock AgentCore の Gateway 機能を使用して、リモート MCP サーバーをホスティングします。Runtime 機能を使用しても問題ありませんが、今回はセットアップが簡単な Gateway 機能を使用します。
- MCP アカウント上で、Amazon Bedrock AgentCore のサービス画面を開き、「ゲートウェイ」を選択し、「ゲートウェイの作成」ボタンをクリックします。

-
「ゲートウェイの詳細」では、任意のゲートウェイ名を設定します。ゲートウェイのセマンティック検索機能を有効化したい場合は、
Enable semantic searchオプションをこのタイミングで有効化しておきましょう。 -
「インバウンド認証設定」では、「IAM 許可を使用」を選択します。

- 「ターゲット」に MCP サーバーを指定します。今回は、AWS が提供している AWS Knowledge MCP サーバーを指定します。これは、AWS の各種サービスに関するナレッジを提供する MCP サーバーです。以下の情報を入力します。
- ターゲット名:
aws-knowledge - ターゲットの説明:
AWS Knowledge MCP Server - ターゲットの種類:
MCP server - MCP endpoint: https://knowledge-mcp.global.api.aws
- アウトバウンド認証設定:
No Authorization
-
「ゲートウェイの作成」ボタンをクリックして、ゲートウェイを作成します。
-
ゲートウェイが作成されたら、対象ゲートウェイの「ゲートウェイ URL」(例:
https://gateway-xxxxx-gateway.bedrock-agentcore.ap-northeast-1.amazonaws.com/mcp)をメモしておきます。後で Claude Code の設定で使用します。

Claude Code に MCP を設定する
特定プロジェクトに対して MCP の設定を行います。プロジェクトフォルダに移動し、以下のコマンドを実行して .mcp.json ファイルを作成します。
touch .mcp.json
.mcp.json ファイルに、以下の内容を記述します。実際の JSON ファイルにはコメントを含められないため、コメント部分は削除して使用してください。
{
"mcpServers": {
"aws-mcp": {
"command": "aws-vault",
"args": [
"exec",
"mcp", // aws-vault のプロファイル名
"--",
"uvx",
"mcp-proxy-for-aws@1.1.5",
"https://gateway-xxxxx-gateway.bedrock-agentcore.ap-northeast-1.amazonaws.com/mcp", // AgentCore Gateway の URL
"--region",
"ap-northeast-1"
]
}
}
}
動作の流れ
aws-vaultが起動し、mcpという AWS プロファイルを使って認証情報を取得し、環境変数に一時的な認証情報を注入します- その認証情報が設定された状態で
uvxコマンドが実行されます(uvxは Python パッケージを一時的にダウンロードして実行するツール) - mcp-proxy-for-aws の安全性の確認が取れたバージョンを指定
- mcp-proxy-for-aws が、指定された AgentCore Gateway の URL に接続します(東京リージョン ap-northeast-1)
注意点
VS Code や Cursor で Claude Code の拡張機能を利用している場合、Native UI ではなく、Terminal で開くようにしてください。Native UI では、上記の MCP の設定が正しく反映されません。

動作確認
以下の流れで利用可能になることを確認します。
- Claude Code を起動する
- 期限が切れている場合、aws-vault のパスワードが求められる(手動で入力が必要)
- 期限が切れている場合、利用する AWS プロファイル関連の MFA トークンが求められる(1Password の指紋認証でシームレスに渡せる)
- MCP Proxy が起動し、AgentCore に接続される
- Claude Code で AgentCore 上にホストしている MCP サーバーが利用可能になる
aws-vault を利用する以上、aws-vault のパスワードの手動入力は避けられませんが、AWS プロファイル関連の MFA については、1password-cli を利用することで指紋認証でシームレスに渡せるのが嬉しいポイントです。これにより、比較的スムーズな利用体験が実現できます。
さいごに
最後までお読みいただき、ありがとうございました。
AgentCore 上にホストした、リモート MCP サーバーを企業内で共有する方法について長らく悩んでいましたが、現時点では今回紹介した方式が最も利用体験が良いと感じています。一方で、AWS アカウントを持たないユーザーの利用や、非エンジニアへの展開など、まだ課題も残されています。これらの課題については、MCP 仕様や各プロバイダーの対応状況を注視しながら、今後も検討を続けていきたいと思います。
本記事が、同様のユースケースを検討されている方の参考になれば幸いです。それではまた!








