[アップデート] AWS MCP Server がcross-account と cross-role accessをサポートしたので、Claude Code で試してみた

AWS MCP Server がクロスアカウント・クロスロールアクセスをサポートしました。セッション再起動なしに複数の AWS アカウント・IAM ロールを切り替えながら操作できるようになった今回のアップデートについて、仕組みから AI コーディングエージェントである Claude Code による実装例まで詳しく紹介します。
石川覚
2026.06.08
クラウド事業本部の石川です。AWS MCP Server（AWS Model Context Protocol Server）がクロスアカウント・クロスロールアクセスをサポートしました。AI コーディングエージェントが、セッションを再起動することなく、単一セッション内で複数の AWS アカウント・IAM ロールを横断して操作できるようになります。
今回のアップデートについて、仕組みから AI コーディング エージェントである Claude Code による実装例 まで詳しく紹介します。
https://aws.amazon.com/jp/about-aws/whats-new/2026/06/aws-mcp-server/
 AWS MCP Server とはAWS MCP Server は、Agent Toolkit for AWS の一部として提供されるマネージド型のリモート MCP（Model Context Protocol）サーバーです。AI エージェントやコーディングアシスタントに対し、AWS Identity and Access Management（IAM）と SigV4 認証による安全な AWS サービスへのアクセスを提供します。
call_aws ツールによる 15,000 以上の AWS API の実行、最新 AWS ドキュメントの検索・参照、サンドボックス環境での Python スクリプト実行などの機能を備えており、2026 年 5 月に一般提供が開始されました。Claude Code、Kiro、Cursor など MCP 互換のクライアントから利用できます。
https://dev.classmethod.jp/articles/20260507-aws-mcp-server-ga/
https://dev.classmethod.jp/articles/20260506-agent-toolkit-for-aws/
https://dev.classmethod.jp/articles/aws-mcp-server-claude-code-20260507/
 アップデート内容これまで AI コーディングエージェントの作業中に AWS アカウントや IAM ロールを切り替えるには、AI コーディングセッションを停止し、ローカルの AWS 認証情報を更新して、MCP サーバーを再起動する必要がありました。
今回のアップデートにより、AI エージェントはコマンドごとにプロファイルを指定できるようになり、セッションを中断することなくアカウント・ロール間をシームレスに切り替えられるようになりました。
主な変更点は以下のとおりです。
セッションの再起動なしで AWS アカウント・IAM ロールを切り替え可能に
リクエストごとにプロファイルを明示するため、誤ったアカウントへコマンドが実行されるリスクを排除
プロファイル変更時のローカル AWS 認証情報の更新や MCP サーバーの再起動が不要に
Kiro、Claude Code、Codex などの AI コーディングエージェントとの統合をサポート
たとえば、DevOps エンジニアが本番アカウントとステージングアカウントを横断して CloudWatch ログを照会しパフォーマンス問題を診断する、アプリケーション開発者があるアカウントの Lambda 設定を更新しつつ別のアカウントの S3 バケットポリシーを調整する、といった作業を 1 つの会話の中で完結できます。
 対応リージョンAWS MCP Server は以下のリージョンで利用可能です。
米国東部（バージニア北部）
欧州（フランクフルト）
なお、AWS API の呼び出し自体は任意のリージョンに対して実行できます。
 仕組みクロスアカウント・クロスロールアクセスは、オープンソースの MCP Proxy for AWS と AWS MCP Server の組み合わせで実現されます。
動作の流れは以下のとおりです。
プロキシ起動時に複数のプロファイルを設定します（--profile フラグまたは AWS_MCP_PROXY_PROFILES 環境変数）
プロキシが、認証を必要とするツール（call_aws、run_script、get_presigned_url、get_tasks、suggest_aws_commands）のスキーマに aws_profile パラメータを追加します
エージェントがツールを呼び出すと、プロキシは指定されたプロファイルの認証情報で署名してリクエストをルーティングします
aws_profile 未指定: デフォルト（先頭）のプロファイルで署名
aws_profile="dev" を指定: dev プロファイルの認証情報で署名された専用接続を使用
無効なプロファイルを指定: 利用可能なプロファイル一覧とともにエラーで拒否

aws_profile パラメータはバックエンドへの転送前に除去されるため、AWS MCP Server 自体がこのパラメータを受け取ることはありません
 利用方法 前提条件利用する各プロファイルが ~/.aws/config および ~/.aws/credentials に設定済みであること
mcp-proxy-for-aws バージョン 1.6.0 以降
各プロファイルに、エージェントが実行する操作に必要な最小限の IAM 権限が付与されていること
 設定方法CLI フラグで設定する場合、最初のプロファイルがデフォルトになります。
mcp-proxy-for-aws https://aws-mcp.us-east-1.api.aws/mcp --profile prod-readonly dev staging
環境変数で設定する場合は以下のとおりです。CLI 引数を変更できないプラグイン統合などで有用です。
AWS_MCP_PROXY_PROFILES="prod-readonly dev staging"
AWS_MCP_PROXY_PROFILES が設定されている場合、--profile や AWS_PROFILE より優先されます。
MCP クライアントの設定例は以下のとおりです。
{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": ["mcp-proxy-for-aws@latest", "https://aws-mcp.us-east-1.api.aws/mcp"],
      "env": {
        "AWS_MCP_PROXY_PROFILES": "prod-readonly dev staging"
      }
    }
  }
}
設定後は、AI エージェントに「dev アカウントと prod アカウントの Lambda 呼び出しコストを比較して」のように依頼するだけで、エージェントがプロファイルを切り替えながら調査を実行してくれます。公式ドキュメントでは、クロスアカウントのコスト比較、複数アカウントの S3 バケットの一括セキュリティ監査、ステージングと本番の設定比較によるトラブルシューティング、全アカウントの EC2 インスタンス棚卸しといったユースケースが紹介されています。
https://docs.aws.amazon.com/agent-toolkit/latest/userguide/multi-account-access.html
 やってみた実際のAIエージェントからの利用例として、Claude Codeに接続して試しました。**任意のプロファイルを指定するので、プロジェクトルートに.mcp.json**というファイル名で作成して、claude起動時に自動で読み込ませる方法を採用しました。下記の例では、ishikawa と cloud-cons の２つのプロファイルを指定しています。
{
  "mcpServers": {
    "aws-multi": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.0",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--profile", "ishikawa", "cloud-cons"
      ]
    }
  }
}
Claude Code の初回起動時に承認プロンプトが表示されます。「1. Use this MCP server」を選択します。
おなじみの Claude Code に下記のプロンプトを入力します。今回は2つのプロファイルのAWS ACCOUNT IDを取得するプロンプトで動作を確認します。
ishikawaとcloud-consの両プロファイルで aws sts get-caller-identity を実行して、AWS ACCOUNT IDを表で比較してください。
スキーマのenumとdescriptionから利用可能なプロファイルを認識し、人間がプロファイル名を細かく教えなくても使い分けてくれました。「ishikawaとcloud-consの両プロファイルで aws sts get-caller-identity を実行して、AWS ACCOUNT IDを表で比較してください。」のようなクロスアカウント調査が1回の指示で完結するのは、従来の起動時固定方式にはなかった体験です。
 利用上の注意公式ドキュメントでは、以下のセキュリティ上の考慮事項が示されています。
明示的な許可リスト: 起動時に宣言したプロファイルのみが利用可能です。エージェントが ~/.aws/config 内の他のプロファイルを発見・使用することはできません
ステートレスルーティング: 各呼び出しが独自の認証情報を持つため、並列リクエストが互いに干渉しません
最小権限: 読み取り専用プロファイルをデフォルトにし、書き込み可能なプロファイルは明示的な選択を必須にする構成が推奨されています
クライアントサイドの制御: 本番プロファイル使用前の手動承認といった追加の制御は、MCP クライアント側のフックや権限ルールで構成します
なお、このプロファイル切り替え機能は AWS MCP Server 専用であり、MCP Proxy for AWS で他の MCP サーバーへプロキシする場合には利用できない点にご注意ください。
 最後にこれまでは環境変数や設定ファイルなどを用いて、無理やりクロスアカウント・クロスロールアクセスをやってたりしてました。今後は、AWS MCP Server のクロスアカウント・クロスロールアクセス対応により、マルチアカウント環境での AI エージェント活用が一段と実用的になりました。リクエスト単位でプロファイルを明示する設計のため、誤操作のリスクを抑えながら、複数アカウントにまたがる調査・運用作業を 1 つのセッションで完結できます。
マルチアカウント構成で AWS を運用されている方は、読み取り専用プロファイルをデフォルトにした構成から検討してみてはいかがでしょうか。