AWS MCP Server を Claude Code から主要ツールをひと通り叩いてみた
クラウド事業本部の石川です。AWS MCP Server が一般提供開始されましたので、Claude Code に組み込んで主要ツールをひと通り叩いてみました。
AWS MCP Server は、AI コーディングエージェントから AWS サービスへ Model Context Protocol（MCP）経由でアクセスするためのマネージドサービスです。preview から GA になり、IAM ベースのガードレール・CloudWatch メトリクス・CloudTrail ロギングといった可視化と制御機能が標準で備わりました。
「3 つのコアツール」（call_aws 、 search_documentation 、 run_script）は、実際にエンドポイントへ tools/list を投げてみると 11 個のツールが返ってきます。今回はその全体像と、Claude Code から接続して読み取り系の動作を確認した結果をまとめます。
AWS MCP Server とは
AWS MCP Server は、AWS が公式に提供するマネージド MCP サーバーで、Anthropic 主導で策定された Model Context Protocol（MCP）の上に、AWS 認証・監査・ガードレールを乗せたものです。AI エージェント（Claude Code、Kiro、Cursor、その他 MCP 互換クライアント）から、ふだん使っている IAM 認証情報のまま、AWS の API・ドキュメント・運用ノウハウ（Skills）にアクセスできるよう設計されています。preview から GA に至るまでの過程で、preview 期に存在した OSS の awslabs/mcp（AWS API MCP Server）とは別系統の、マネージドサービスとして組み直されています。
3 つの構成要素
AWS MCP Server を使うときに登場するコンポーネントは 3 つです。
| 層 | 名称 | 役割 |
|---|---|---|
| クライアント | Claude Code / Kiro / Cursor 等 | エージェント本体。MCP プロトコルでツールを呼ぶ |
| ローカルプロキシ | MCP Proxy for AWS | ローカルで動く SigV4 署名プロキシ（uvx で起動） |
| エンドポイント | AWS MCP Server | AWS 側のリージョナルなマネージドサーバー |
クライアントとプロキシの間は MCP の stdio トランスポート（標準入出力で JSON-RPC をやり取りする方式）、プロキシとエンドポイントの間は HTTPS + SigV4 です。MCP Proxy for AWS は OSS として公開されており、内部実装も追えます。
リクエストの流れ
エージェントが「東京リージョンで Bedrock が使えるか教えて」のような依頼を受けてから、結果がユーザーに返るまでの流れは次のとおりです。
各ステップの中身は次のとおりです。
- ユーザーがエージェント（Claude Code 等）に自然言語で指示します。
- エージェントが MCP プロトコルで tools/call を発行し、ローカルプロセスとして起動している MCP Proxy for AWS に stdio 経由で送ります。
- MCP Proxy はローカル環境の AWS 認証チェーン（環境変数 /
~/.aws/credentials/ IAM ロール / IAM Identity Center）から認証情報を取得します。 - 取得した認証情報でリクエストに SigV4 署名を付与し、AWS MCP Server のエンドポイント（例: https://aws-mcp.us-east-1.api.aws/mcp）へ HTTPS で転送します。
- エンドポイントは SigV4 を検証し、呼び出し元 IAM プリンシパルが要求された操作を実行できるかを IAM ポリシーで判定します。
- 権限が通れば、エンドポイントが該当する AWS API（STS / EC2 / S3 / Lambda 等）を呼び出します。
- 実行結果は CloudTrail に
userIdentity.invokedBy = aws-mcp.amazonaws.com付きで記録され、CloudWatch のAWS/AWS-MCP名前空間にInvocation/Successメトリクスが ToolName 別に発行されます。 - レスポンスは MCP Proxy 経由でエージェントに戻り、最終的にユーザーに提示されます。
このフローで重要なポイントは、AWS の長期クレデンシャルがローカルマシンの外（エージェント本体や LLM 推論基盤）に出ないことです。SigV4 署名はあくまでローカルの MCP Proxy 内で完結し、エンドポイントには署名済みリクエストだけが届きます。エージェント側に渡るのは tools/list のスキーマと tools/call のレスポンス（つまり実行結果の JSON）だけです。
提供される機能
エンドポイントから tools/list で返ってくる 11 ツールは、ざっくり 3 つのグループに整理できます（個別の挙動は後述の「やってみた」で実機検証します）。
- AWS API 直接実行系:
call_aws/run_script/get_presigned_url/get_tasks - ドキュメント・ナレッジ系:
search_documentation/read_documentation/recommend/retrieve_skill - メタ情報・補助系:
list_regions/get_regional_availability/suggest_aws_commands
なかでも run_script はサンドボックス Python に call_boto3 を備えていて、複数 API の組み合わせ操作（List → Describe など）を 1 リクエストで完結させられます。また retrieve_skill で取得できる「Skills」は、AWS のサービスチームがレビュー済みのワークフロー文書（手順 + リファレンス + 判断フレームワーク）で、エージェントが特定ドメインに「化ける」ための知識パッケージとして配信されます。
セキュリティ・監査
- 認証は IAM SigV4。既存の AWS 認証チェーンをそのまま流用し、新しい認証経路を増やさない
- CloudTrail には
userIdentity.invokedBy = aws-mcp.amazonaws.com、sourceIPAddress/userAgentも同じ値が記録され、人間操作との区別が一目で付く - CloudWatch は
AWS/AWS-MCP名前空間にInvocation/Successを ToolName 次元で発行する - IAM ポリシーや SCP で
aws:CalledVia系コンテキストキーを使い、「エージェントには Read 系のみ許可」「人間ロールには Write 系を許可」といった分離が現実的に書ける
料金と利用可能リージョン
- AWS MCP Server 本体は追加料金なし
- 課金対象は
call_awsやrun_scriptから呼ばれた AWS API のリソース料金と通常のデータ転送料のみ - エンドポイントは執筆時点で 2 リージョン: US East (N. Virginia) の
https://aws-mcp.us-east-1.api.aws/mcpと Europe (Frankfurt) のhttps://aws-mcp.eu-central-1.api.aws/mcp - どのリージョンエンドポイントを使うかは MCP Proxy 起動時の引数（つまり MCP クライアントの登録設定）で決める。
--metadata AWS_REGION=...で「呼び先 AWS API のリージョン」を上書きできる
やってみた
今回の検証では、AWS MCP Server をClaude Code から実際に動かしました。GA となった AWS MCP Server はマネージドサービスの「3 つのコアツール」は、実際にエンドポイントへ MCP プロトコルで問い合わせると何が返ってくるのか、提供されているツールはどんな粒度で IAM 権限を継承するのか、エージェント経由のリクエストは CloudTrail でどう識別できるのか、といった運用観点の挙動を、ドキュメント記述だけではなく実機で確認することを確認しました。
検証の流れ
検証は次の流れで進めます。最初に MCP Proxy for AWS のセットアップと Claude Code への登録で疎通を確立し、続いて initialize と tools/list を直接叩いて提供ツールの全体像を把握します。そのうえで主要ツール（call_aws、run_script、search_documentation、retrieve_skill、get_regional_availability、suggest_aws_commands）を 1 つずつ呼び出し、入出力と制約を確認していきます。最後に、AWS MCP Server 経由のリクエストが CloudTrail にどのように記録されるかと、CloudWatch にどんな運用メトリクスが発行されるかを確認することで、エンタープライズで導入する際のガードレール設計の手触りを掴みに行きます。
破壊的な書き込みは行いません。すべて読み取り系（Get / Describe / List）と無認証のドキュメント検索系のみで進めます。
前提条件
- AWSアカウント（IAM ユーザー / IAM ロールで AWS CLI が利用可能）
- AWS CLI: 2.34.42
- MCP エンドポイント: https://aws-mcp.us-east-1.api.aws/mcp（us-east-1）
Claude Code への AWS MCP Server 登録
公式ブログのコマンドに --metadata AWS_REGION=us-east-1 を加えて登録しました。--scope user を指定するとユーザー全体（~/.claude.json）に保存されます。
% claude mcp add-json aws-mcp --scope user \
'{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-east-1"]}'
Added stdio MCP server aws-mcp to user config
Claude Code を起動して、/mcp で接続状態を確認します。
Connected 表示が出れば、ローカルの AWS 認証情報での SigV4 署名が成功し、リモート MCP エンドポイントとの疎通が取れています。
tools/list で利用可能なツールを確認
接続が確認できたら、Claude Code 上で /mcp を実行し、aws-mcp サーバーに登録されたツール一覧を確認します。Claude Code は MCP サーバー登録時に内部的に initialize → tools/list を発行しており、その結果を /mcp のメニューから閲覧できます。
aws-mcp サーバーを選んで詳細を開くと、以下の 11 個のツールが提供されていることが分かります。
- aws___call_aws: AWS CLI コマンドの実行（15,000+ API 操作）
- aws___run_script: Python サンドボックス実行（call_boto3 経由）
- aws___search_documentation: AWS 公式ドキュメント検索
- aws___read_documentation: AWS ドキュメントを Markdown で取得
- aws___suggest_aws_commands: 自然言語から CLI コマンドを提案（readOnlyHint=True）
- aws___list_regions: AWS リージョン一覧取得
- aws___get_regional_availability: サービス・API・CFnリソースのリージョン可用性確認
- aws___retrieve_skill: AWS サービスチーム提供の Skill を取得
- aws___recommend: 関連ドキュメントの推奨
- aws___get_presigned_url: S3 署名付き URL の生成
- aws___get_tasks: 長時間タスクのステータス取得
3 つのコアツール以外にも、リージョン可用性確認・Skill 取得・presigned URL 生成・長時間タスクのポーリングなど、エージェントの使い勝手を意識した補助ツールが揃っています。Claude Code からは mcp__aws-mcp__call_aws のような名前空間付きで利用できます（呼び出し側の自然言語プロンプトでは特に意識しなくても、Claude が必要なツールを選んでくれます）。
call_aws ツールで AWS API を呼ぶ
最も基本的なツールである call_aws を試します。Claude Code に AWS CLI のコマンドを文章で頼むと、aws___call_aws ツールが選ばれて実行されます。
❯ aws-mcp 経由で aws sts get-caller-identity を実行して結果を見せて
Called aws-mcp
aws-mcp 経由で aws sts get-caller-identity を実行しました。
┌────────┬────────────────────────────────────────────────────────────────┐
│ 項目 │ 値 │
├────────┼────────────────────────────────────────────────────────────────┤
│ UserId │ AROAIQYDPIIE4D75QUZEM:ishikawa │
├────────┼────────────────────────────────────────────────────────────────┤
│ Accoun │ <aws_account_id> │
│ t │ │
├────────┼────────────────────────────────────────────────────────────────┤
│ Arn │ arn:aws:sts::<aws_account_id>:assumed-role/cm-ishikawa.satoru/ishi │
│ │ kawa │
└────────┴────────────────────────────────────────────────────────────────┘
cm-ishikawa.satoru ロールを assume した状態で、ishikawa セッションとして認証されています。
ローカル環境で aws sts get-caller-identity を実行した結果と完全に一致しました。--query パラメータも問題なく解釈されます。
❯ aws-mcp で aws ec2 describe-availability-zones --region us-east-1 を実行して、ZoneName だけ抜き出して
Called aws-mcp
us-east-1 の AvailabilityZones の ZoneName 一覧です。
- us-east-1a
- us-east-1b
- us-east-1c
- us-east-1d
- us-east-1e
- us-east-1f
run_script ツールで Python サンドボックスを実行
複数の API を並列に呼んだり、結果を加工してから返したいときは run_script の出番です。Claude Code に「並列で叩いて」「集計して」のように頼むと、run_script を選んでくれます。
❯ aws-mcp で sts:GetCallerIdentity と ec2:DescribeRegions(us-east-1)
を並列で実行して、有効リージョン数と最初の 5 件をまとめて返して
Called aws-mcp 2 times
⏺ 2 つのコマンドを並列実行しました。
結果サマリ
Caller Identity
- Account: <aws_account_id>
- Arn: arn:aws:sts::<aws_account_id>:assumed-role/cm-ishikawa.satoru/ishikawa
有効リージョン
- 総数: 17（すべて opt-in-not-required の標準有効リージョン）
- 最初の 5 件:
a. ap-south-1 (India)
b. eu-north-1 (Sweden)
c. eu-west-3 (France)
d. eu-west-2 (United Kingdom)
e. eu-west-1 (Ireland)
search_documentation で AWS ドキュメントを検索する
AWS の最新動向や API 仕様を検索するツールです。Claude Code に検索したいキーワードと領域（current_awareness / reference_documentation / troubleshooting / agent_skills）を伝えると、aws___search_documentation が呼ばれます。
❯ aws-mcp の search_documentation で「AWS MCP Server IAM context keys」を current_awareness から検索して、上位 3 件の URL を教えて
Called aws-mcp
current_awareness トピックでの検索結果上位 3 件です。
1. AWS API MCP Server now available - AWS (2025/07)
https://aws.amazon.com/about-aws/whats-new/2025/07/aws-api-mcp-server-available/
2. The AWS MCP Server is now generally available - AWS (2026/05)
https://aws.amazon.com/about-aws/whats-new/2026/05/aws-mcp-server/
3. setting-up-ec2-instance-profiles（Agent Skill のサジェスト。URL は無し）
なお 3 件目はドキュメントではなく Agent Skill の提案として返ってきました。URL を持つドキュメント結果は上位 2 件のみです。
注目すべきは、agent_skills トピックも検索結果に混ざってくる点です。3 番目のヒットには通常のドキュメント URL ではなく skill_name が返ってきており、これを次の retrieve_skill ツールに渡すことで Skill を読み込めます。
retrieve_skill で AWS サービスチーム提供の Skill を取得する
Skill は AWS のサービスチームが運用ノウハウや手順をパッケージ化したものです。先ほどの search_documentation で見つけた setting-up-ec2-instance-profiles を、そのまま Claude Code に渡して取得します。
❯ aws-mcp で skill_name=setting-up-ec2-instance-profiles の Skill を取得して、Overview と Troubleshooting を要約して
Called aws-mcp
Skill setting-up-ec2-instance-profiles を取得しました。要約は以下の通りです。
Overview 要約
EC2 インスタンスに IAM ロール／インスタンスプロファイル経由で AWS サービスへの安全なアクセスを付与するためのドメインナレッジ。ハードコードされた認証情報を排除し、必要な権限の特定 → 最小権限ポリシーでの IAM ロール作成（or 流用）→ インスタンスプロファイル作成 → EC2 へのアタッチ → 認証情報の利用可否確認、というライフサイクル全体をカバーします。具体的なセットアップ手順は references/ec2-instance-profile-setup.md に分離されています。
Troubleshooting 要約
┌────────────────────────┬────────────────────────────────────────────────┐
│ 症状 │ 対処 │
├────────────────────────┼────────────────────────────────────────────────┤
│ │ インスタンス ID とリージョンを確認。aws ec2 │
│ Instance not found │ describe-instances --region <region> │
│ │ で一覧を取得 │
├────────────────────────┼────────────────────────────────────────────────┤
│ Instance already has a │ 手順が置換に対応。既存プロファイル解除前にプロ │
│ profile │ ンプトで確認される │
├────────────────────────┼────────────────────────────────────────────────┤
│ アタッチ後も認証情報が │ インスタンスプロファイルの伝播に 30〜60 │
│ 使えない │ 秒。アプリ再起動で新しい認証情報を読み込ませる │
├────────────────────────┼────────────────────────────────────────────────┤
│ │ ロールのポリシーに必要なアクション・リソース │
│ Access denied │ ARN が含まれているか確認。CloudTrail │
│ │ で拒否されたアクションを特定 │
├────────────────────────┼────────────────────────────────────────────────┤
│ │ 設定ファイル、環境変数（AWS_ACCESS_KEY_ID / │
│ ハードコード認証情報を │ AWS_SECRET_ACCESS_KEY）、~/.aws/credentials │
│ 使い続けている │ から削除。SDK のデフォルト認証情報チェーンがイ │
│ │ ンスタンスプロファイルを利用するようになる │
└────────────────────────┴────────────────────────────────────────────────┘
EC2 インスタンスプロファイル設定の詳細手順、トラブルシューティング、命名規則などがすべて Markdown で返ってきます。（~/.claude/plugins/marketplaces/agent-toolkit-for-aws/skills/compute-skills/setting-up-ec2-instance-profiles/SKILL.md）
retrieve_skill のツール説明には「事前に search_documentation で skill_name を取得しろ、skill_name を推測するな」と強く書かれており、エージェントがハルシネーションを起こさないよう設計されている点が興味深いところです。Claude Code から呼ばせる場合も、search_documentation の結果に出てきた skill_name をそのまま渡すフローが推奨されます。
get_regional_availability でリージョン可用性を確認する
複数サービスの複数リージョン可用性を一度に確認できるツールです。Claude Code に「aws-mcp の get_regional_availability で、Amazon Bedrock と AWS Lambda が us-east-1 / ap-northeast-1 / eu-central-1 で使えるか確認して」と頼みます。
❯ aws-mcp の get_regional_availability で、Amazon Bedrock と AWS Lambda が
us-east-1 / ap-northeast-1 / eu-central-1 で使えるか確認して
Called aws-mcp
⏺ 両サービスとも 3 リージョンすべてで利用可能です。
┌────────────────┬──────────────────┬──────────────────┬──────────────────┐
│ サービス │ us-east-1 │ ap-northeast-1 │ eu-central-1 │
├────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ Amazon Bedrock │ ✅ isAvailableIn │ ✅ isAvailableIn │ ✅ isAvailableIn │
├────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ AWS Lambda │ ✅ isAvailableIn │ ✅ isAvailableIn │ ✅ isAvailableIn │
└────────────────┴──────────────────┴──────────────────┴──────────────────┘
resource_type は product（サービス・機能）/ api（SDK API オペレーション）/ cfn（CloudFormation リソース）の 3 種類が指定できます。
--read-only オプションの挙動を確認する
mcp-proxy-for-aws には --read-only オプションがあり、書き込み権限を持つ可能性のあるツールを除外できます。安全側に倒したいときに便利そうですが、実際に試してみると挙動が想像と違いました。
一度 aws-mcp を削除して、--read-only 付きで再登録してみます。
% claude mcp remove aws-mcp --scope user
Removed MCP server aws-mcp from user config
File modified: /Users/ishikawa.satoru/.claude.json
% claude mcp add-json aws-mcp-readonly --scope user \
'{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-east-1","--read-only"]}'
Added stdio MCP server aws-mcp-readonly to user config
新しい Claude Code セッションを開いて /mcp を見ると、aws-mcp-readonly に紐づくツールは 1 つだけです。
--read-only オプションのヘルプ説明には「Disable tools which may require write permissions (readOnlyHint True or unknown)」とあり、ヒント未設定のツールは安全のために除外される設計です。結果として、--read-only で残るのは readOnlyHint=True が明示された 1 ツールだけになります。
つまり、書き込み API を実際に防ぎたい場合は --read-only フラグに頼るのではなく、IAM ポリシー側で許可アクションを ReadOnly 系に絞り込む運用が現実的です。
CloudTrail でエージェント呼び出しを識別する
ここからが本題です。先ほど call_aws / run_script で実行した API が CloudTrail にどう記録されるかを、Claude Code から確認してみます。
> aws-mcp で過去 30 分の CloudTrail から GetCallerIdentity イベントを 1 件取得して、userIdentity・sourceIPAddress・userAgent を見せて
返ってきたイベントの主要部分を抜粋します。
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAIQYDPIIE4D75QUZEM:ishikawa",
"arn": "arn:aws:sts::<aws_account_id>:assumed-role/cm-ishikawa.satoru/ishikawa",
"accountId": "<aws_account_id>",
"sessionContext": {
"attributes": {"creationDate": "2026-05-07T05:08:18Z", "mfaAuthenticated": "true"}
},
"invokedBy": "aws-mcp.amazonaws.com"
},
"eventTime": "2026-05-07T05:40:28Z",
"eventSource": "sts.amazonaws.com",
"eventName": "GetCallerIdentity",
"awsRegion": "us-east-1",
"sourceIPAddress": "aws-mcp.amazonaws.com",
"userAgent": "aws-mcp.amazonaws.com",
"readOnly": true
}
注目は userIdentity.invokedBy: "aws-mcp.amazonaws.com" の行です。sourceIPAddress と userAgent も同じ値になっており、AWS MCP Server を経由した呼び出しであることがログだけで一目瞭然です。
参考として、同じ操作（DescribeAvailabilityZones）をマネジメントコンソールから実行したときのイベントと並べてみます。
| 項目 | MCP Server 経由 | マネジメントコンソール |
|---|---|---|
| userIdentity.invokedBy | aws-mcp.amazonaws.com |
（未設定） |
| sourceIPAddress | aws-mcp.amazonaws.com |
90.149.240.4 |
| userAgent | aws-mcp.amazonaws.com |
Mozilla/5.0 ... Chrome/147.0.0.0 ... |
ログ上で人間操作とエージェント操作が完全に区別できるため、IAM ポリシーの aws:CalledVia 系コンテキストキーや SCP で「人間のロールには許可するが MCP 経由では拒否する」「またはその逆」といった制御が現実的に書けます。
CloudWatch メトリクスで利用状況を確認する
公式ブログには「CloudWatch の AWS-MCP 名前空間にメトリクスを発行する」と書かれていますが、実際は AWS/AWS-MCP 名前空間でした。Claude Code に頼んで list-metrics を流させます。
> aws-mcp で CloudWatch list-metrics を実行して、AWS/AWS-MCP 名前空間にあるメトリクスをすべて教えて
AWS/AWS-MCP 名前空間のメトリクス一覧
us-east-1 のみに存在（他 3 リージョンは 0 件）。6 件＝ MetricName × ToolName の組み合わせ：
┌────────────┬────────────────────────────┐
│ MetricName │ ToolName (Dimension) │
├────────────┼────────────────────────────┤
│ Invocation │ aws___suggest_aws_commands │
├────────────┼────────────────────────────┤
│ Success │ aws___suggest_aws_commands │
├────────────┼────────────────────────────┤
│ Invocation │ aws___call_aws │
├────────────┼────────────────────────────┤
│ Success │ aws___call_aws │
├────────────┼────────────────────────────┤
│ Invocation │ aws___run_script │
├────────────┼────────────────────────────┤
│ Success │ aws___run_script │
└────────────┴────────────────────────────┘
Invocation（実行回数）と Success（成功回数）の 2 メトリクスが、ToolName ディメンションで切り出されています。ただし、検証中に呼び出した list_regions / search_documentation / retrieve_skill / get_regional_availability の分は今回の list-metrics 結果には含まれていません。ドキュメント検索やリージョン可用性確認のような無認証リクエスト系はメトリクス対象外、もしくは別のディメンションで集約されている可能性があります。
実数値を get-metric-statistics で取得します。
> aws-mcp で AWS/AWS-MCP 名前空間の Invocation / Success を ToolName 別に過去 1 時間分集計して
┌────────────────────────────┬────────────┬─────────┬─────────────┐
│ ToolName │ Invocation │ Success │ SuccessRate │
├────────────────────────────┼────────────┼─────────┼─────────────┤
│ aws___suggest_aws_commands │ 1 │ 1 │ 100.0% │
├────────────────────────────┼────────────┼─────────┼─────────────┤
│ aws___call_aws │ 2 │ 2 │ 100.0% │
├────────────────────────────┼────────────┼─────────┼─────────────┤
│ aws___run_script │ 2 │ 2 │ 100.0% │
└────────────────────────────┴────────────┴─────────┴─────────────┘
実行回数が正しくカウントされています。run_script の最初のリクエストは Python コードのなかで TypeError を起こしましたが、Success は 2 となっています。これは「サーバーがコードを受け付けて実行を試みた」段階で成功とカウントされる仕様で、ユーザーコードの例外有無は別レイヤで管理されているようです。
考察
エージェント識別が CloudTrail だけで完結する
CloudTrail の userIdentity.invokedBy: aws-mcp.amazonaws.com です。MCP Server を介した呼び出しだけがこのフィールドに値を持ち、人間がコンソール / CLI で叩いたときには空のままです。これにより、
- 監査要件で「エージェントが実行した API 操作だけを抽出したい」
- ガードレール要件で「特定のロールでは MCP 経由のリクエストを拒否したい」（あるいはその逆）
といったシナリオを、追加のタグやカスタムログを仕込むことなく標準機能だけで実装できます。事前に IAM コンテキストキー（aws:CalledVia）でポリシー側からエージェント識別ができることは公式ブログでも触れられていましたが、CloudTrail にも同じ識別子が落ちる点は、運用者目線では非常にありがたい設計です。
--read-only オプションは「フラグ 1 つで読み取り専用」にはならない
--read-only を付けると、readOnlyHint=True が明示されたツール（今回は suggest_aws_commands のみ）以外がすべて除外されます。call_aws も run_script も「書き込み API を実行する可能性がある」ためにフィルタされます。
つまり、この機能は**「どの AWS API を実行可能にするか」を制限するものではなく、「サーバー側の readOnlyHint メタデータが明示的に True のツールだけを残す」フィルタ**です。実際に MCP 経由での書き込みを禁止したい場合は、
- IAM ポリシーで
Actionを*:Get**:List**:Describe*等に絞る - もしくは Permission Boundary や SCP で書き込み API を Deny する
といった IAM 側のガードレールを併用する必要があります。
run_script は規約が強く、エージェント設計の意図が透けて見える
run_script のツール説明には「ONE SCRIPT PER TASK」「LIST→DESCRIBE IS MANDATORY」「NEVER TRUNCATE」「DISTRUST EMPTY RESULTS」「NO COMMENTS」など、行動規範レベルの指示が大量に詰め込まれています。これは LLM エージェントが run_script を呼ぶときに陥りがちな失敗（ページネーション忘れ、勝手に上位 10 件で打ち切る、空応答を「0 件」と誤判定する等）を、ツール定義の段階で潰しに行っている設計です。
サンドボックス側もネットワーク隔離・標準ライブラリ限定・call_boto3 のみが外部通信窓口、と縛りがきつく、エージェントが「ふつうの Python 開発」気分で書くと TypeError や ImportError で素直に弾かれます。逆に言えば、規約に沿って書けば多段の AWS API 呼び出しを 1 リクエストでまとめて実行でき、コンテキスト消費も round-trip も最小化できます。
Skills は「ハルシネーション抑止のための公式ノウハウ供給」
retrieve_skill は、search_documentation で取得した skill_name をそのまま渡さないと使えません。これは**「LLM が skill 名を勝手に推測すると壊れる」ことを前提にした設計**で、エージェントの暴走をプロトコル設計レベルで抑え込んでいます。
Skill そのものは AWS サービスチームがレビュー済みのワークフロー文書（手順書 + リファレンス + 判断フレームワーク）で、ベストプラクティスを「拾いに行ける」状態で配信できる仕組みになっています。preview 時の awslabs/mcp（OSS の AWS API MCP Server）と比べて、GA 版で大きく変わったのはこの Skills の取り回し部分だと感じました。
最後に
実際に Claude Code から AWS MCP Server を叩いてみた結論としては、**3 つのコアツール（call_aws / run_script / search_documentation）**に加えて、retrieve_skill と get_regional_availability、recommend、get_presigned_url、get_tasks までセットで提供されている「Agent Toolkit としての完成度」が素晴らしいです。
- セットアップは uv が入っていれば
claude mcp add-jsonの 1 コマンドで完了する - 接続は
--metadata AWS_REGION=...を渡すだけで SigV4 署名が回る - CloudTrail / CloudWatch との統合が標準で動く（人間操作との識別が標準フィールドで可能）
--read-onlyは IAM の代わりにはならない。ガードレールは IAM ポリシー側で書く前提- run_script のサンドボックスは制約が強い分、「LLM に任せて壊れにくい」設計になっている
エージェントから AWS を操作させたい場面（IaC のドラフト生成、運用調査、コンプライアンスチェックなど）は今後ますます増えそうですが、AWS MCP Server は「個別の OSS MCP サーバーを並べる」運用と比べて、認証・監査・メトリクスを 1 サービスで揃えられる点で運用コストが圧倒的に低いです。Bedrock AgentCore や Strands Agents と組み合わせた運用検証は別記事でやっていきたいと思います。この記事がどなたかのお役に立てば幸いです。
