Claude Code × AWS MCP Serverによるマルチアカウント操作

はじめに

本記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」の2日目の記事となります！

昨日の記事はこちらです！

さて、AWS MCP Serverがクロスアカウントアクセスに対応したことで、Claude Codeなどのコーディングエージェントから、複数のAWSアカウントを横断して操作しやすくなりました。
本記事では、マルチアカウント環境でAWS MCP Serverを利用するためのセットアップ手順と、実際にClaude Codeから複数アカウントを操作して検証した内容を紹介します。

AWS MCP Serverとは

AWS MCP Serverは、Claude CodeのようなAIコーディングエージェントからAWSを操作できるようにする、AWSがホストするマネージドなMCPサーバーです。2026年5月にGAされました。

AWSドキュメントの検索や、IAM認証情報を使用してAWS APIを実行でき、コーディングエージェントからAWSリソースの調査や操作を自然言語で行うことが可能です。

クロスアカウントアクセスに対応できるように！

これまでAWS MCP Serverを利用する際は、1つのセッションで使用するAWS CLIプロファイルが固定されていました。そのため、別のAWSアカウントを使用するには、ローカルの認証情報を変更してMCPサーバーを再起動するなど、一手間必要でした。

ですが、2026年6月の下記アップデートにより、複数のAWS CLIプロファイルをあらかじめ登録できるようになり、同一セッションのまま複数のAWSアカウントを切り替えて操作することが可能になりました。

マルチアカウント環境利用時のAWS MCP Serverのセットアップ

今回は次の環境で実施しています。

項目	内容
AWSアカウント	2つ（Organizationsで管理）
リージョン	ap-northeast-1
AWS CLI	2.33.13（2.32.0 以降が必要）
uv	0.7.19
OS	Windows 11

AWSアカウントはOrganizations配下に作成し、IAM Identity Centerで各アカウントに AdministratorAccess の許可セットを割り当てたユーザーでログインできるようにしています。

今回は検証を進めやすくするために AdministratorAccess を使っていますが、実際に利用する場合は権限を絞ることをおすすめします。

AWS CLIプロファイルを用意する

C:\Users\<ユーザー名>\.aws\config に、利用したいアカウントのプロファイル設定を書いておく必要があります。

なお、今回の検証で使わないアカウントのプロファイルがすでに書かれていても、消す必要はありません。あとでAWS MCP Serverに渡すプロファイルを明示的に指定するので、そこで宣言したものだけが操作対象になります。

~/.aws/config

[sso-session my-sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access

[profile account-a]
sso_session = my-sso
sso_account_id = <アカウントAのID>
sso_role_name = AdministratorAccess
region = ap-northeast-1
output = json

[profile account-b]
sso_session = my-sso
sso_account_id = <アカウントBのID>
sso_role_name = AdministratorAccess
region = ap-northeast-1
output = json

両方のアカウントに入れるか確認してみましょう。

aws sso login --sso-session my-sso

aws sts get-caller-identity --profile account-a
aws sts get-caller-identity --profile account-b

Claude Codeに登録する

AWS MCP Serverの認証方式にはOAuthとSigV4の2つがありますが、マルチアカウントで使う場合はSigV4を選びます。OAuthでは複数アカウントの切り替えができません。

Multi-profile switching for cross-account workflows is not supported with OAuth. If you need to work with multiple AWS accounts in a single session, use the SigV4 authentication option instead.

（OAuthでは、アカウントをまたがるワークフローにおけるマルチプロファイル切り替えはサポートされていません。単一のセッションで複数のAWSアカウントを操作する必要がある場合は、代わりにSigV4認証オプションを使用してください。）

プロジェクトのフォルダに次の .mcp.json を置くと、そのフォルダでClaude Codeを起動したときに自動で読み込まれます。

.mcp.json

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.4",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=ap-northeast-1",
        "--profile",
        "account-a",
        "account-b"
      ]
    }
  }
}

URLに含まれる us-east-1 は、接続先であるAWS MCP Server自体が置かれている場所です。エンドポイントは us-east-1 と eu-central-1 の2つのみ用意されています。

操作対象のリージョンは --metadata AWS_REGION=ap-northeast-1 で指定します。これを書かないと、AWS MCP Serverのある us-east-1 のリソースを見にいってしまいます。

また、--profile account-a account-b には、使わせたいプロファイルを起動時に並べて宣言します。先頭に書いた account-a が、プロファイル未指定のときのデフォルトになります。
ここで宣言していないプロファイルは、~/.aws/config に書いてあってもエージェントからは見えません。

設定後、Claude Codeを起動すると、新しいMCPサーバーを承認するかどうか聞かれます。

動作確認

次のプロンプトを実行してみたところ、

AWS MCP Server のツールを使って、account-a と account-b の両方のアカウントIDを取得して

ちゃんとアカウント情報が取得できていました。

ハンズオン

Claude Code上で同一セッションで2つのAWSアカウントを操作できるか試してみます。
今回は、開発環境のアカウントAで作成したS3バケットと全く同じ設定のリソースを、AWS MCP Serverを利用して本番環境のアカウントBに複製してもらいます。

複製元のS3バケットをアカウントAに作る

アカウントAに、TerraformでS3バケット「dev-awsmcp-demo-bucket」を作りました。設定は次の通りです。

設定項目	内容
バージョニング	有効
デフォルト暗号化	SSE-S3（AES256）、バケットキー有効
パブリックアクセスブロック	4項目すべて有効
ライフサイクル	30日でSTANDARD_IAに移行、90日で削除
タグ	Environment=dev
バケットポリシー	HTTPS以外とアカウント外からのアクセスを拒否

これらは1つのAPIでまとめて取れるものではなく、別々のAPIを呼ばないとS3バケットの全体像が掴めません。全ての設定を忘れずに取ってこれるのでしょうか。。。

バケットポリシーの中身は次の通りです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::dev-awsmcp-demo-bucket",
        "arn:aws:s3:::dev-awsmcp-demo-bucket/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "DenyAccessFromOtherAccounts",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::dev-awsmcp-demo-bucket/*",
      "Condition": {
        "StringNotEquals": { "aws:PrincipalAccount": "<アカウントAのID>" }
      }
    }
  ]
}

HTTPS以外の通信を拒否するのと、自分のアカウント以外のプリンシパルからのオブジェクト操作を拒否する、という2つの禁止事項だけを書いています。

実際に複製させてみる

Claude Codeで次のような指示をしたところ、、

AWS MCP Serverを利用して、アカウントAにあるS3バケット「dev-awsmcp-demo-bucket」の設定を確認し、同様のものをアカウントBにも作成してほしい。バケット名は「prod-awsmcp-demo-bucket」にして

ちゃんとS3バケットが作成されていました！

ただ、Environment タグは dev のままでした。バケット名を prod にしたのだから、ここも prod にしてほしかったですが、「同様のものを作成して」と指示したのは自分なので、忠実にコピーしたのが正しいとも言えますね。

バケットポリシーのほうは、自分のアカウント以外からのオブジェクト操作を拒否する条件が、アカウントBのIDに書き換わっていました。
ポリシーが何を意味しているかを踏まえて直してくれたのがよかったです。

おわりに

複数アカウントにまたがる操作を簡単に行えるのは、とても快適ですね。
環境を複製しやすいのはIaC管理のメリットですが、IaCを使っていない環境でも、コーディングエージェントに既存環境の構成を確認させ、その内容をもとに別環境へ作らせれば、手作業で一つずつ設定を確認して作り直すよりは効率よく進められそうです。
複数アカウントを行き来する作業が多い方は、ぜひ試してみてください！

最後までお読みいただきありがとうございました！
明日以降のJr.Championsによる記事投稿もお楽しみに！