本文へ移動
Amazon Watch Japan Amazon.com, Inc.（AMZN）の製品、サービス、...
製品・サービス・ソリューション 更新: 2026.06.12

AWS MCP Serverのクロスアカウント対応とは：AIコーディングエージェントに複数AWSアカウントを触らせる前に確認すべき権限設計

AWS MCP Serverのクロスアカウント対応でprofile、IAM、監査ログを整理した図

3行まとめ

このテーマをもう少し広げて見るなら、AWS FinOps Agentプレビューとは：異常コスト調査をAIエージェント化する前に確認すべきこと と 次世代AWS Resilience Hub一般提供とは：AI障害モード評価とサービス単位課金で導入前に確認すべきこと も合わせて確認してください。MCP経由で複数アカウントを扱う前に、AIエージェントがコスト調査を行うときの権限と監査の見方も確認できます。

VisualAWS MCP Server更新の要点クロスアカウント対応を、便利になった点と先に決めるべき安全策に分けて確認します。
単一セッション

AIコーディングエージェントが、複数のAWSアカウントやIAMロールを扱いやすくなります。

multi-profile support

各ツール呼び出しで`aws_profile`を指定できますが、許可profileやdefault profileの設計が必要です。

初期検証

read-only default、devまたはsandboxの書き込みprofile、CloudTrail/CloudWatch/MCPクライアントログの突合から始めます。

便利さだけでなく、IAM、SCP、クライアント側承認、監査ログを合わせて見る更新です。

  • AWSは2026年6月5日、AWS MCP Serverでクロスアカウント/クロスロールアクセスをサポートしたと発表しました。AIコーディングエージェントは、単一セッションの中で複数のAWSアカウントやIAMロールを扱いやすくなります。
  • 便利になった中心は、各ツール呼び出しでaws_profileを指定できるmulti-profile supportです。ただし、安全性はAWS MCP Serverだけで決まらず、許可するprofile、既定profile、IAM、SCP、クライアント側承認で設計する必要があります。
  • まずはread-onlyのdefault profile、devまたはsandboxの書き込みprofile、CloudTrail/CloudWatch/MCPクライアントログの突合から始めるのが現実的です。本番書き込みprofileを常時見せる構成は、最後まで慎重に扱うべきです。

AWS MCP Serverのクロスアカウント対応は、AIコーディングエージェントをAWS運用に入れたいチームにとって、かなり実務的な更新です。これまではアカウントやロールを切り替えるたびに、ローカルのAWS credentialsを変えたり、MCP serverを再起動したりする運用になりがちでした。今回の発表では、Kiro、Claude Code、CodexなどのMCP対応エージェントが、1つの作業セッションの中でprofileを指定しながらAWS API操作や調査を進められるようになったと説明されています。

一方で、これは「AIエージェントに本番アカウントを広く任せてよい」という話ではありません。むしろ、複数アカウントを同じ会話に載せられるようになったからこそ、どのprofileを見せるのか、aws_profileなしの呼び出しをどこへ流すのか、書き込み系APIをどこで止めるのか、事後にどのログで追うのかを先に決める必要があります。

この記事では、AWS公式発表、AWS News Blog、Agent Toolkit for AWSのUser Guideと製品ページをもとに、AWS MCP Serverのクロスアカウント対応を「導入前の権限設計」として読みます。2026年6月のAWS関連更新を追う場合は、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月重要トピックまとめ</a>にも並べて確認しておくと、AgentCoreやBedrock系の更新との関係を追いやすくなります。

AWS MCP Serverのクロスアカウント対応で何が変わったのか

Visualprofile切り替えの考え方が変わる同じセッションの中で、AWS API、ドキュメント、skills、監査の見方を用途別profileに結び付けて整理します。
  1. 1AWS API操作

    `call_aws`は広いAPI operationsを扱えるため、APIカバレッジより先に許可するIAM actionを絞ります。

  2. 2ドキュメント参照

    documentation toolsは、現行AWSドキュメントやベストプラクティスを確認する補助線になります。

  3. 3script実行

    `run_script`はサンドボックス環境でのPython script実行として、filesystemやnetwork accessと分けて理解します。

  4. 4監査

    CloudWatch/CloudTrailでは、人間の直接操作とエージェント経由の操作を分けて追います。

AWS環境へ触らせるなら、人間の作業用roleをそのまま渡すのではなく、エージェント用profileを用途別に作るのが起点です。

今回の公式発表で押さえるべき変化は、AIエージェントがAWSアカウントをまたいで作業するときの「切り替え負荷」が下がったことです。AWSは2026年6月5日、AWS MCP Serverでcross-account and cross-role accessを発表しました。AWS MCP ServerはAgent Toolkit for AWSの一部で、MCP対応のAIコーディングエージェントからAWSのAPI、ドキュメント、スキルなどへアクセスするための入口です。

従来の運用では、開発アカウントを見たあとに本番アカウントのCloudWatch Logsを確認したい場合、ローカルのAWS profileやcredentialsを切り替え、AI coding sessionやMCP serverを再起動する必要がありました。今回の更新では、エージェントが各コマンドでprofileを指定できるため、1つの会話の流れの中でdev、staging、productionなどを行き来しやすくなります。

単一セッションで複数AWSアカウント/IAMロールを扱える

根拠

AWSの発表では、DevOps担当者がproductionとstagingのCloudWatch logsをまたいで調査する例や、アプリケーション開発者が一方のアカウントでLambda設定を更新し、別アカウントでS3 bucket policyを調整する例が挙げられています。つまり、AIエージェントに「この障害をdevとprodで比較して」と頼むとき、会話そのものを分けずにprofileを切り替えながら調査を進める余地が広がります。

これは、AWS Organizationsでアカウントを分けているチームほど効きます。dev、stg、prod、shared services、security、billingなどを分離している場合、ひとつの障害調査で複数アカウントを見る場面は珍しくありません。人間がコンソールを切り替えるだけならまだしも、AIエージェントにAWS調査を補助させる場合、途中でMCP serverを再起動すると会話の文脈が壊れやすくなります。

注意点

ただし、便利さの裏側にあるリスクも同じくらい大きくなります。複数アカウントを一つの会話に載せるということは、自然言語の曖昧な指示が、より広いAWS環境へ届く可能性を持つということです。AWS発表では各リクエストがprofileを指定するため誤ったアカウントへ届くリスクを抑えられると説明されていますが、実運用ではprofile名、default profile、承認、IAM境界の設計を別途見なければなりません。

AWS MCP ServerはAgent Toolkit for AWSの中核機能

AWS MCP Serverは、単体の便利ツールというより、Agent Toolkit for AWSの中核に置かれているmanaged remote MCP serverです。AWS News BlogのGA記事では、AI agentsやcoding assistantsにAWSへの認証済みアクセスを与えるための仕組みとして説明されています。

確認項目

公式情報から確認できる主な機能は次の通りです。

項目公式情報で確認できる位置づけ導入時の見方
call_aws15,000超のAWS API operationsを実行できるtoolAPIカバレッジではなく、許可するIAM actionを先に見る
documentation tools現行AWSドキュメントやベストプラクティスを取得する古いモデル知識に頼らないための補助線になる
run_scriptサンドボックス環境でPython scriptを実行できるローカルfilesystemやnetwork accessとは分けて理解する
SkillsAWSサービスチームが管理する手順やガイダンスを読み込むエージェントの作業手順を整えるが、権限境界の代替ではない
CloudWatch/CloudTrailMCP server callsやAWS API callsの監視・監査に関係する人間の直接操作とエージェント経由の操作を分けて追う

この表で大事なのは、AWS MCP Serverが広いAPI操作を扱えるほど、最初に絞るべき権限も明確になるということです。AIエージェントがAWS CLIの代わりにAWS環境へ触るなら、人間の作業用roleをそのまま渡すのではなく、エージェント用に用途別profileを作るところから始めたほうが安全です。

料金とリージョンも過度に広く読まない

AWS News Blogでは、AWS MCP Server自体に追加料金はなく、作成・利用するAWSリソースやデータ転送など通常の費用がかかると説明されています。これは「無料で何でも試せる」という意味ではありません。エージェントがCloudWatch Logsを読み、大量のAPIを呼び、リソースを作成し、データを移動すれば、それぞれのサービス料金や転送費用は通常通り発生します。

また、2026年6月8日に確認した公式情報では、AWS MCP ServerはUS East (N. Virginia)とEurope (Frankfurt)で利用可能とされています。AWS News Blogでは、それらのエンドポイントから任意のAWS RegionへAPI callできる旨も説明されています。ここは「自分のAWSワークロードが東京リージョンにあるから使えない」と早合点しない一方で、組織のデータ所在地、監査要件、接続先エンドポイントの扱いは別途確認すべきところです。

multi-profile supportの仕組みを権限設計の目線で読む

Visual`aws_profile`が通る4段階MCPクライアントからAWS APIまで、profile指定がどこで効くのかを役割ごとに分けます。
  1. 1MCPクライアント

    Codex、Claude Code、Kiro、Cursorなどがtool callを出し、profile指定をユーザーが確認できるかを見ます。

  2. 2MCP Proxy for AWS

    許可profileを受け取り、署名済み接続へ振り分けます。起動時に許可したprofileを確認します。

  3. 3AWS MCP Server

    AWS API、docs、skillsなどの入口になり、IAMとCloudWatch/CloudTrailの扱いを確認します。

  4. 4AWS API/各サービス

    実際のAWS操作が行われ、CloudTrailに残るprincipalとAPI eventを確認します。

`aws_profile`なしの呼び出しはdefault profileへ流れるため、defaultを強くしすぎない設計が重要です。

今回の肝は、Agent Toolkit for AWSのUser Guideにあるmulti-profile supportです。公式ドキュメントでは、MCP Proxy for AWSとAWS MCP Serverを使うと、複数のAWS CLI profilesを設定し、accountやroleをtool callごとに切り替えられると説明されています。

流れは大きく4段階です。

段階役割確認したいこと
MCPクライアントCodex、Claude Code、Kiro、Cursorなどがtool callを出すprofile指定をユーザーが確認できるか
MCP Proxy for AWS許可profileを受け取り、署名済み接続へ振り分ける起動時にどのprofileを許可したか
AWS MCP ServerAWS API、docs、skillsなどの入口になるIAMとCloudWatch/CloudTrailの扱い
AWS API/各サービス実際のAWS操作が行われるCloudTrailに残るprincipalとAPI event

aws_profileはどのツール呼び出しに付くのか

Agent Toolkitのmulti-profile supportでは、proxyがAWS MCP Serverの認証が必要なtool schemaにaws_profile parameterを追加します。公式ドキュメントで例示されている対象には、call_aws、run_script、get_presigned_url、get_tasks、suggest_aws_commandsがあります。

この仕組みによって、エージェントは「このCloudWatch Logs調査はprod-readonlyで」「このstagingの設定確認はstg-app-readonlyで」のように、tool callごとにprofileを選べます。裏側ではproxyが該当profileのcredentialsで接続を署名し、AWS MCP Serverへ渡します。ドキュメントでは、aws_profile parameterはbackendへ転送される前に取り除かれ、AWS MCP Server自体はそのparameterを直接見るわけではないと説明されています。

条件

導入前に確認する条件は、少なくとも3つあります。

  1. 使いたいprofileが~/.aws/configと~/.aws/credentialsに設定されていること。
  2. mcp-proxy-for-awsが1.6.0以上であること。
  3. 各profileに、エージェントに許可したい最小限のIAM権限だけが付いていること。

注意点

3つ目がいちばん重い確認です。multi-profile supportは、複数profileを便利に切り替えるための機能であり、強すぎる権限を弱める機能ではありません。prod-adminのようなprofileをallowedに入れれば、エージェントはそのprofileで実行できる範囲を持ちます。ここをプロンプトで「慎重にやって」と頼むだけでは足りません。

aws_profileなしの呼び出しはdefault profileへ流れる

公式ドキュメントでは、aws_profileを指定しないtool callはdefault、つまり最初のprofileで署名されると説明されています。これは設計上かなり重要です。エージェントがprofile指定を忘れた場合、またはユーザーが自然言語でprofileを明示しなかった場合、どのAWSアカウントへ向かうのかがdefault profileで決まるからです。

推奨初期値

おすすめの初期値は、defaultをread-onlyにすることです。たとえばprod-readonly、org-audit-readonly、dev-readonlyのように、調査・一覧・ログ確認に寄せたprofileを最初に置きます。stagingの変更やsandboxの作成操作は、明示的にprofileを指定したときだけ使えるようにします。

避けたいのは、最初のprofileに強い書き込み権限を置く構成です。aws_profileを指定しない呼び出しが本番書き込みroleへ流れる状態は、AIエージェント運用ではかなり攻めた設定です。人間が「prodではなくstgを見て」と言ったつもりでも、エージェントがprofile指定を落としたらdefaultへ行きます。ここはIAMやSCPで止める前に、profileの並び順と命名で事故を減らすべきです。

allowed profilesは「見せるアカウント」を制限する入口

multi-profile supportでは、proxy起動時に複数profileを指定します。CLI flagの--profile、またはAWS_MCP_PROXY_PROFILES environment variableで設定でき、公式ドキュメントではenvironment variableが--profileやAWS_PROFILEより優先されると説明されています。

このallowlistは、AIエージェントに見せるAWSアカウントの入口です。ドキュメントのsecurity considerationsでは、起動時に宣言したprofileだけが使え、エージェントが~/.aws/configの他profileを勝手に発見して使うわけではないとされています。つまり、手元に強い管理者profileが存在していても、MCP Proxy for AWSのallowed profilesに入れなければ、少なくともこの経路では使わせない設計にできます。

評価基準

初期設計では、次のような分類にしておくと判断しやすくなります。

profile例対象用途allowed初期値
org-audit-readonly複数アカウントCloudTrail、Config、CloudWatchの調査入れてよい
dev-sandbox-writedevまたはsandbox検証用リソース作成、削除条件付きで入れる
stg-app-writestagingアプリ設定変更、検証デプロイ承認付きで入れる
prod-readonlyproduction障害調査、ログ確認必要なら入れる
prod-app-writeproduction本番変更原則として初期allowlistに入れない
security-adminsecurity accountIAM、SCP、監査基盤変更別経路に分ける

この表は、AWS公式がそのまま推奨しているprofile名ではありません。導入時の棚卸し例です。大事なのは、profile名を見ただけで環境、権限の強さ、用途が分かることです。

AIエージェントに複数AWSアカウントを触らせる前のIAM設計

Visualprofile別の初期権限マトリクスread-only defaultから始め、書き込み可能profileは用途ごとに分けて考えます。
項目内容見方
CloudWatch Logslog group/list、filter、query系から始め、retention変更やsubscription変更は注意します。
CloudTrailevent lookupやtrail確認を許可し、trail停止や証跡保存先変更は慎重に扱います。
AWS Configresource config参照やcompliance確認を中心にし、recorder/channel変更は止める対象にします。
dev-sandbox-writedev内の検証用リソース作成、削除に限定し、本番参照や組織共通IAMは外します。
prod-change-approved事前承認済みの限定変更だけを想定し、IAM、SCP、Secrets、delete系は原則止めます。

権限はprofile名だけでなく、IAM context keysやSCPとも合わせて確認します。

AWS MCP Serverのmulti-profile supportを使う前に、IAM設計を「人間用roleの流用」から「エージェント用profileの分離」へ切り替えて考える必要があります。AIエージェントは、自然言語の指示をtool callに変換します。だからこそ、意図の曖昧さをIAM側で吸収できるようにしておきたいところです。

read-only defaultから始める

最初の検証では、default profileをread-onlyにするのが扱いやすいです。対象は、CloudWatch Logsの検索、CloudTrailイベントの確認、AWS Configのリソース状態確認、IAMのGet/List、LambdaやS3などの設定確認に寄せます。

ただし、AWS managed policyのReadOnlyAccessをそのまま使えば常に十分、という話でもありません。ReadOnlyAccessは広いサービスにまたがるため、組織のポリシーによっては広すぎる可能性があります。逆に、サービスごとに絞りすぎると、エージェントが調査のたびに権限不足で止まり、結局人間が横から追加権限を渡す運用になってしまいます。

確認項目

初期の落としどころは、次のような考え方です。

調査対象最初に許可したい操作注意したい操作
CloudWatch Logslog group/list、filter、query系retention変更、subscription変更
CloudTrailevent lookup、trail確認trail停止、証跡保存先変更
AWS Configresource config参照、compliance確認recorder/channel変更
IAMGet/List系Put/Attach/Create/Delete系
Lambdaconfiguration参照、version/alias確認update-function-code、環境変数更新
S3bucket設定参照、public access確認bucket policy変更、object削除

この分け方を先に決めると、AIエージェントに「調査して」と言うだけで、意図せず変更操作まで届く状況を避けやすくなります。

書き込み可能profileは用途ごとに分ける

書き込み可能profileを1つにまとめると、運用は楽になりますが、事故時の範囲が広がります。たとえば、Lambda設定変更、S3 bucket policy変更、Secrets Manager更新、IAM policy変更、CloudFormation stack updateを同じprofileで許可すると、エージェントの一回の誤判断が複数の重要領域に届く可能性があります。

分離する理由

書き込みprofileは、用途ごとに分けるほうが現実的です。

profile例許可する変更原則止める変更
dev-sandbox-writedev内の検証用リソース作成、削除本番参照、組織共通IAM
stg-lambda-config-writestaging Lambdaの設定変更IAM role変更、production alias変更
stg-s3-policy-reviewstaging bucket policyの検証更新本番bucket policy、public化
prod-breakglass-readonly本番障害時の緊急調査write系全般
prod-change-approved事前承認済みの限定変更IAM、SCP、Secrets、delete系

本番で書き込みを許すなら、profile名だけでなく、使えるAPI action、対象resource ARN、時間帯、承認者、ログ確認方法まで決めます。AIエージェントに任せるからこそ、人間の変更管理より緩くするのではなく、むしろ狭く始めるべきです。

IAM context keysとSCPも合わせて見る

AWS News BlogのGA記事では、AWS MCP ServerがIAM context keysに対応し、MCP server経由の操作を人間の直接操作と分けて制御できることが説明されています。Agent Toolkit製品ページでも、CloudWatch metrics、IAM-based access controls、CloudTrail audit loggingがenterprise controlsとして紹介されています。

ここで重要なのは、profileの権限だけを見ないことです。AWS Organizationsを使っているなら、SCPで本番アカウントの削除系、IAM変更、KMS key変更、CloudTrail停止などを止める設計も候補になります。IAM policyでMCP経由の操作をread-onlyに寄せ、人間のbreak-glass roleだけが特定変更をできるようにすれば、エージェントの誤操作を一段外側で抑えられます。

AWS MCP ServerのAPIカバレッジが広いことは、設計次第で強みにもリスクにもなります。広く触れる入口を持つなら、入口の手前とAWSアカウント側の両方で境界を置く。これがmulti-account導入の基本線です。

誤操作を減らすprofile命名・承認・クライアント側ガード

Visual許可前に見る6つのガードAIエージェントが毎回正しく判断する前提にせず、profile名、承認、停止条件を先に置きます。
profile名

`prod`や`admin`のような曖昧な名前を避け、環境、用途、権限の強さが分かる名前にします。

default

どこへ向かうか分からないdefaultではなく、`org-audit-readonly`のような読み取り用途に寄せます。

prod操作

`prod-*write` profileの利用は、本番変更に直結するため承認なしでは許しにくい操作です。

IAM/Secrets

IAM policy/role/userやSecrets Manager/SSM Parameterの変更は、権限昇格や接続先変更につながります。

監査系変更

CloudTrail、Config、GuardDutyなどの変更は、事後追跡能力を落とす可能性があります。

delete系API

取り返しがつかない場合があるため、無効profileの拒否と合わせて検証します。

profile命名、client-side gating、承認ルールを組み合わせると、IAMだけでは残る誤操作リスクを下げられます。

IAMでできることを制限しても、AIエージェント特有の誤操作は残ります。人間が「本番とステージングを比較して」と言ったとき、どのprofileでどのAPIを使うべきか、エージェントが毎回完璧に判断するとは限りません。そこで、profile命名、client-side gating、承認ルールの設計が効いてきます。

profile名はエージェントにも人間にも誤解されにくくする

profile名は、短さよりも意味の明確さを優先します。prod、admin、mainのような名前は、人間にもエージェントにも曖昧です。prod-readonly、stg-app-write、dev-sandbox-write、security-audit-readonlyのように、環境、用途、権限の強さが入っている名前にします。

避けたい例と、比較的扱いやすい例を分けるとこうなります。

避けたいprofile名問題置き換え例
prodread/writeの区別がないprod-readonly
admin環境も用途も分からないsecurity-admin-human-only
defaultどこへ向かうか分からないorg-audit-readonly
appdev/stg/prodの区別がないstg-app-config-write
ops調査か変更か不明prod-ops-readonly

AIエージェントはprofile名を手がかりにtool callを組み立てます。profile名が曖昧だと、自然言語指示と実行profileの対応も曖昧になります。これは監査時にも困ります。あとからMCPクライアントログやCloudTrailを見返したとき、「なぜそのprofileを選んだのか」を説明しやすい名前にしておくべきです。

client-side gatingでprod操作を止める

Agent Toolkitのmulti-profile supportドキュメントでは、additional controlの例としてclient-side hooksやpermission rulesに触れています。これは、MCPクライアント側で本番profileの使用や危険なtool callに承認を挟む考え方です。

ここで避けたいのは、プロンプトだけで安全性を担保することです。「本番は変更しないで」「削除はしないで」とsystem promptや運用ルールに書くのは有用ですが、それだけでは技術的なガードではありません。エージェントが誤ってtool callを作る、ユーザーが曖昧な指示を出す、途中の会話で前提が崩れる。そうした場面を考えると、profile allowlist、IAM、SCP、client-side approvalを重ねる必要があります。

承認対象

承認を挟みたい操作の例は次の通りです。

操作カテゴリ承認なしで許しにくい理由
prod-*write profileの利用本番変更に直結する
IAM policy/role/userの変更権限昇格や横展開につながる
S3 bucket policy/public access変更データ露出リスクがある
Secrets Manager/SSM Parameterの更新認証情報や接続先を変える可能性がある
CloudTrail/Config/GuardDutyなど監査系の変更事後追跡能力を落とす可能性がある
delete系API取り返しがつかない場合がある

クライアント別の承認機能は変化しやすいため、この記事では個別の設定手順までは断定しません。Codex、Claude Code、Kiro、Cursorなど、実際に使うクライアントのpermission modelやhooksを確認してください。AWS MCP Server側のmulti-profile supportがあっても、最後に止める場所はクライアントとIAMの両方にあります。

無効profileの拒否も検証項目にする

公式ドキュメントでは、無効なprofileを指定した場合、proxyがallowed profilesの一覧を含むerrorで拒否すると説明されています。これは小さく見えますが、導入検証では必ず試したい項目です。

たとえば、allowed profilesにdev-readonly stg-app-writeだけを入れた状態で、エージェントにprod-adminを使わせようとしたらどう見えるのか。クライアント画面で拒否理由が分かるのか。ログに残るのか。エージェントが別profileで勝手に代替しようとしないか。こうした失敗時の挙動を確認しておくと、本番導入前の安心感がかなり変わります。

監査ではCloudTrail・CloudWatch・MCPクライアントログを分けて見る

Visualログごとの役割分担AWS側のAPI実行事実、MCP経由の呼び出し傾向、クライアント側の承認文脈を分けて見ます。
項目内容見方
CloudTrail対象アカウント、principal、API名、対象リソース、時刻、error、sourceを確認します。
CloudWatch metricsMCP経由の呼び出し傾向や、異常な呼び出し増を確認する補助線になります。
MCPクライアントログuser prompt、作業チケット番号、提案されたtool call、選択された`aws_profile`を残します。
承認履歴承認者、承認時刻、実行結果の要約、対応するCloudTrail eventへのリンクまたは検索条件を残します。

CloudTrailだけでは自然言語指示の意図や承認の文脈までは読めないため、ログを突合して見ます。

AWS MCP Serverを使うとき、監査は1種類のログだけでは足りません。AWS側で実行されたAPIの事実、MCP server経由の呼び出しの傾向、クライアント側の承認や会話の文脈を分けて見ます。

CloudTrailはAWS API操作の事実を追う場所

CloudTrailは、AWS側で実際に起きたAPI操作を追う場所です。AssumeRole、Get/List、Update、Put、Deleteなど、対象アカウントで実行されたAPI eventを確認できます。AIエージェントがMCP経由で操作した場合でも、最終的にAWS APIが呼ばれれば、そのAPI eventの監査が重要になります。

確認項目

CloudTrailで見たい観点は次の通りです。

観点確認内容
対象アカウント期待したaccount IDか
principalどのrole/profileのcredentialsで実行されたか
API名読取か変更か、削除か
対象リソースどのARN、bucket、function、trail、policyか
時刻MCPクライアント側の承認時刻と合うか
errorAccessDeniedで止まったのか、成功したのか
sourceMCP経由と人間の直接操作を識別できるか

CloudTrailだけでは、ユーザーが自然言語で何を依頼したのか、エージェントがどの推論でprofileを選んだのかまでは分かりません。だから、CloudTrailは「AWS側で起きた事実」を見るログとして扱い、意図や承認は別ログと突き合わせます。

CloudWatch metricsは活動量を見る補助線

AWS News Blogでは、AWS MCP ServerがAWS-MCP namespaceのCloudWatch metricsを公開し、MCP server callsを人間の直接操作と分けて観測できると説明されています。これは、エージェント経由の利用状況を把握するうえで役立ちます。

ただし、metricsだけで操作内容を判断してはいけません。呼び出し回数、エラー傾向、レイテンシなどは見えても、どの自然言語指示からどのAWS APIが選ばれたのか、変更が承認済みだったのかまでは、別の情報が必要です。CloudWatch metricsは、MCP経由の活動量や異常傾向を見つける入口として使い、詳細はCloudTrailとクライアントログへ進むのが自然です。

MCPクライアントログと承認履歴を残す

AIエージェント運用では、MCPクライアント側のログも重要です。どのpromptで、どのtool callが提案され、誰が承認し、どのprofileが選ばれたのか。この流れは、AWS側ログだけでは再現しにくい部分です。

特に本番profileを許す場合は、次の情報を残せるかを確認してください。

  • user promptまたは作業チケット番号
  • エージェントが提案したtool call
  • 選択されたaws_profile
  • 承認者と承認時刻
  • 実行結果の要約
  • 対応するCloudTrail eventへのリンクまたは検索条件

ここまで残せると、障害後や監査時に「AIエージェントが勝手にやった」ではなく、「誰の依頼で、どのprofileで、どのAPIが実行されたか」を説明できます。AIエージェント導入の社内合意では、この説明可能性がかなり大きな材料になります。

導入前チェックリスト：まず小さく試すならどこからか

Visual最初の検証スコープ本番運用へ入れる前に、失敗時の止まり方、ログの残り方、profile選択の見え方を確認します。
項目内容見方
allowed profiles`org-audit-readonly dev-sandbox-write`から始め、エージェントに見せる範囲を狭くします。
default profileread-onlyを初期値にし、profile指定漏れの被害を抑えます。
invalid profile必ず拒否されることを確認し、allowlistの効き方を見ます。
write操作devまたはsandbox限定にして、本番影響を避けます。
`run_script`読取集計から始め、IAM権限継承を安全に確認します。
CloudTrailAPI eventを突合し、実際のAWS操作を追います。
CloudWatch metricsMCP経由の呼び出し傾向を見て、異常な呼び出し増を検知します。
クライアント承認prod相当操作は止まる設計にし、人間の明示確認を挟みます。

multi-profile supportそのものより先に、拒否、既定値、監査、承認の挙動を小さく確認します。

AWS MCP Serverのクロスアカウント対応は、いきなり本番運用へ入れるより、小さな検証スコープで始めるほうが向いています。multi-profile supportそのものより、失敗時の止まり方、ログの残り方、profile選択の見え方を先に確認するためです。

最初の検証スコープ

最初の検証は、devまたはsandboxアカウントを中心にします。profileはread-only defaultと、限定的なdev書き込みprofileの2つで十分です。production profileは最初から入れず、どうしても必要な場合もprod-readonlyまでに留めます。

失敗時の挙動

検証項目は次のように並べると漏れが減ります。

確認項目推奨初期値見る理由
allowed profilesorg-audit-readonly dev-sandbox-writeエージェントに見せる範囲を狭くする
default profileread-onlyprofile指定漏れの被害を抑える
invalid profile必ず拒否されることallowlistの効き方を見る
write操作devまたはsandbox限定本番影響を避ける
run_script読取集計から始めるIAM権限継承を安全に確認する
CloudTrailAPI eventを突合する実際のAWS操作を追う
CloudWatch metricsMCP経由の呼び出し傾向を見る異常な呼び出し増を検知する
クライアント承認prod相当操作は止まる設計にする人間の明示確認を挟む

この検証で大切なのは、成功ケースより失敗ケースです。profileを指定しない、無効profileを指定する、権限のないAPIを呼ぶ、delete系操作を提案させる。こうした場面で、エージェント、proxy、IAM、クライアント承認がどう振る舞うかを先に見ます。

本番導入の判断基準

本番導入の判断基準は、「便利に動いた」では足りません。少なくとも次の条件が揃ってから、production profileをallowedに入れるべきです。

評価基準

  1. productionで許可する操作が文書化されている。
  2. productionで拒否する操作がIAMまたはSCPで技術的に止まる。
  3. prod-readonlyとprod-writeが分かれている。
  4. prod-writeの利用にはクライアント側承認または外部の変更管理がある。
  5. CloudTrailとMCPクライアントログを突合できる。
  6. 緊急停止手順、profile削除手順、credential rotation手順がある。
  7. 監査担当者または運用責任者がログの見方を理解している。

このうち、1つでも曖昧なら、production writeはまだ早いと考えるほうが安全です。AIエージェントのAWS操作は、うまくいくと調査や変更が速くなります。その速度は、事故の速度にもなります。だからこそ、速く動かす前に、止める線を作る必要があります。

AWS MCP Serverを使うべきケース、まだ待つケース

使う価値が高いのは、複数アカウントをまたぐ読取調査、CloudWatch/CloudTrail/Configの横断確認、staging環境での反復的な設定検証です。これらはAIエージェントが得意な「情報を集めて整理する」作業と相性がよく、read-only中心でも効果が出ます。

一方、まだ待ったほうがよいのは、IAMやSCPの変更、Secrets Managerの値更新、production bucket policy変更、削除系API、監査基盤の停止や変更です。これらは、エージェントに任せる前に、人間の承認、変更管理、rollback、ログ保全を整える必要があります。

AWS MCP Serverのクロスアカウント対応は、AIエージェントにAWS操作を近づける更新です。だからこそ、最初の問いは「何ができるようになったか」だけでなく、「何をまだできないようにしておくか」であるべきです。

関連記事と読み分ける

Visual近い論点との読み分け今回のテーマを、AWS MCP Server、Agent Toolkit for AWS、AIエージェント運用の周辺論点に分けて整理します。
AWS MCP Server

今回の中心は、AWS MCP ServerとAgent Toolkit for AWSのクロスアカウント/クロスロール対応です。

Bedrock AgentCore

Bedrock AgentCoreそのものではありませんが、AIエージェントにAWS環境を触らせる論点は近くなります。

監査設計

CloudTrail/CloudWatchの監査設計と並べると、エージェント経由のAWS操作を整理しやすくなります。

製品・サービス更新

AWSの製品・サービス更新をカテゴリ単位で追う場合は、製品・サービス・ソリューションの一覧も確認できます。

関連テーマは似ていますが、この記事ではprofile、権限、承認、監査の初期設計に焦点を置きます。

今回のテーマは、AWS MCP ServerとAgent Toolkit for AWSの話です。Bedrock AgentCoreそのものではありませんが、AIエージェントにAWS環境を触らせるという意味では、既存記事とかなり近い論点があります。

AIエージェントの認証情報管理を先に押さえたい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-21-agentcore-identity-secrets-manager/" rel="noopener">Amazon Bedrock AgentCore Identityが既存Secrets Manager参照に対応</a>を読むと、secretやresource providerをどう扱うかの視点が補えます。

設定監査やリソース追跡の観点では、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-28-aws-config-bedrock-agentcore-sagemaker-resource-types/" rel="noopener">AWS ConfigがBedrock AgentCore/SageMaker系9リソースに対応</a>が近いです。AI基盤で「何が設定されているか」を追う話と、MCP経由で「誰が何をしたか」を追う話は、運用設計では並べて考えるべきです。

また、エージェントのセッションへ端末で入る運用リスクを見たい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-33-agentcore-runtime-interactive-shells/" rel="noopener">AgentCore RuntimeのInteractive Shells記事</a>も参考になります。今回のAWS MCP Server記事は、端末操作ではなく、MCP tool callでAWS APIへ触るときのprofile設計に焦点を当てています。

AWSの製品・サービス更新をカテゴリ単位で追う場合は、<a href="https://amzn-watch.blog.mo-gmo.com/category/products-services-solutions/" rel="noopener">製品・サービス・ソリューション</a>の一覧も確認できます。

まとめ：AWS MCP Serverを安全に試す初期線

Visual安全に試すための初期線profile切り替えの便利さを、権限、料金、提供地域、監査条件の確認とセットで扱います。
調査しやすさ

profile切り替えのためにセッションを止める必要が減り、dev、stg、prodをまたいだ調査がしやすくなります。

権限の初期値

read-only defaultと、devまたはsandboxの限定的な書き込みprofileから始めます。

監査条件

CloudTrail、CloudWatch、MCPクライアントログ、承認履歴を突合できる状態にします。

確認範囲

発表直後の便利さだけでなく、権限、料金、提供地域、監査条件まで確認します。

この記事はAWS公式情報をもとにした製品・サービス理解のための解説であり、投資助言や法務判断ではありません。

AWS MCP Serverのクロスアカウント/クロスロール対応は、AIコーディングエージェントをAWS調査や運用補助へ近づける更新です。profile切り替えのためにセッションを止める必要が減り、dev、stg、prodをまたいだ調査がしやすくなります。

ただし、導入の主役は「便利さ」ではなく「境界」です。aws_profileを指定できること、allowed profilesを絞れること、default profileが最初のprofileになること、無効profileを拒否できること。これらを使って、AIエージェントに見せるAWSアカウントと見せないAWSアカウントを分けます。

最初の一歩としては、read-only default、dev/sandboxの限定write、CloudTrail/CloudWatch/MCPクライアントログの突合から始めるのがよいでしょう。本番書き込みprofileは、承認、IAM/SCP、監査、停止手順まで揃ってからです。AWS MCP Serverは強力な入口です。入口が強力になるほど、扉の鍵と監視カメラを先に整える必要があります。

Amazon Watch Japanは、Amazon.com, Inc.およびその関係会社とは非提携の独立した情報整理サイトです。この記事はAWS公式情報をもとにした製品・サービス理解のための解説であり、投資助言やAWS利用契約上の法務判断ではありません。

今後のAWS、Amazon Bedrock、Agent Toolkit for AWS、AIエージェント運用の更新は、ニュースレターでも控えめに追跡します。発表直後の便利さだけでなく、権限、料金、提供地域、監査条件まで確認したい方は、更新通知の導線として使ってください。

次に読むなら

参照した主な情報源

  • AWS What's New: The AWS MCP Server now supports cross-account and cross-role access

https://aws.amazon.com/about-aws/whats-new/2026/06/aws-mcp-server/

  • AWS News Blog: The AWS MCP Server is now generally available

https://aws.amazon.com/blogs/aws/the-aws-mcp-server-is-now-generally-available/

  • Agent Toolkit for AWS User Guide: Multi-profile support

https://docs.aws.amazon.com/agent-toolkit/latest/userguide/multi-account-access.html

  • AWS Product Page: Agent Toolkit for AWS

https://aws.amazon.com/products/developer-tools/agent-toolkit-for-aws/