はじめに
GitHub Copilot や Claude Code といった AI コーディングエージェントから AWS を操作したいとき、これまでは個別の MCP サーバを立てたり、awslabs 配下のツール群を組み合わせたりして利用していました。とはいえ「どの権限で動いているのか」「人が触ったのかエージェントが触ったのか」など区別しづらいなど、運用面で気になる部分もあったかと思います。
2026年5月6日、AWS が Agent Toolkit for AWS を GA としてリリースしました。マネージドな AWS MCP Server と、エージェント向けの Skill / Plugin がひとまとまりになっており、認証は既存の IAM、MCP 経由のアクションは新しい IAM 条件キーで切り分け、という形で IAM の枠組みに統合されているのが特徴的です。
本記事では Agent Toolkit for AWS の全体像を整理しつつ、VS Code 上の GitHub Copilot に MCP Server として組み込んで動かすところまでを記録します。Claude Code での体験は他の方が記事にされていると思うので、今回は GitHub Copilot での利用にフォーカスしてみました。
忙しい人のための要約
- AWS が AI コーディングエージェント向けに マネージド MCP Server + Skill + Plugin をパッケージ化した「Agent Toolkit for AWS」を GA でリリース
- AWS の幅広いサービス・15,000以上の API アクションをカバーし、Python のサンドボックス実行や CloudWatch / CloudTrail での監査にも対応
- IAM 条件キー
aws:CalledViaAWSMCPで「MCP 経由のときは Read-only に絞る」といったポリシーが書けるため、制限付きで安全にエージェントに AWS を触らせる運用がしやすくなりそう - 提供リージョンは US East (N. Virginia) と Europe (Frankfurt) の2つだが、操作対象のリージョンは引数で指定できるため、東京リージョンのリソースも触れる
- ツール自体に追加料金はなし（実際に呼び出した AWS リソース分のみ課金）
Agent Toolkit for AWS とは
ざっくり言うと、AI コーディングエージェントが AWS を「正しく・安全に」操作するために必要な部品をまとめたツールキットです。主に3つのコンポーネントから構成されています。
3つの構成要素
| コンポーネント | 役割 |
|---|---|
| AWS MCP Server | マネージドなリモート MCP サーバ。AWS API の呼び出し、Python のサンドボックス実行、最新ドキュメントの取得などを担当 |
| Agent Skills | サービス選定ガイドや手順書、トラブルシュート手順などをパッケージ化したもの。エージェントが文脈に応じて自動で読み込む |
| Agent Plugins | MCP Server 設定と Skill 群を一括導入するためのバンドル。aws-core / aws-agents / aws-data-analytics の3種類 |
全体像
ローカルから直接 AWS API を叩くわけではなく、mcp-proxy-for-aws 経由で AWS マネージドな MCP Server に接続し、そこから IAM 認証付きでサービスを呼び出す構造になっています。エージェントの Python 実行はローカルではなくサーバ側のサンドボックス内で動くため、ファイルシステムやネットワークから隔離されているとのこと。
提供される Plugin
| Plugin | 用途 |
|---|---|
aws-core |
サービス選定、CDK/CloudFormation、サーバレス、コンテナ、ストレージ、監視、課金、SDK 利用、デプロイなど横断的な基本一式 |
aws-agents |
Amazon Bedrock や AgentCore で AI エージェントを構築する用途 |
aws-data-analytics |
データレイク、アナリティクス、ETL ワークフロー向け |
GA 時点で Plugin としてワンコマンドで導入できるのは Claude Code と Codex のみで、GitHub Copilot や Kiro 等のエージェントは MCP Server を直接登録する形になりそうです。とはいえ Plugin の中身は「MCP Server 設定 + Skill ファイル一式」で、Skill 自体は MCP Server 側に登録されており aws___retrieve_skill ツールで都度引いてくる仕組みのため、MCP 直接登録経路でもどの Plugin 相当の Skill にも問題なくアクセスできます。
IAM でエージェント経由のアクションを区別
特徴的なのが、IAM 条件キー aws:CalledViaAWSMCP と aws:ViaAWSMCPService です。MCP Server 経由で発行された API 呼び出しには自動的にこれらのコンテキストキーが付くため、IAM ポリシーで「人間が直接呼ぶときは書き込みも許可するが、MCP 経由のときは Read-only に限定する」といった切り分けが書けるようです。
CloudTrail でも MCP 経由のアクションが識別できる形で記録されるので、「うっかりエージェントが本番に変更を加えていた」といった事故を後追いしやすくなりそうです。本番アカウントにエージェントを接続するときは、まずこのポリシーを噛ませてから動かすのが安全な順序かと思います。
何がうれしいのか
- 「都度 MCP サーバを集めてくる」運用から解放される
- これまで AWS 関連の MCP サーバは
awslabs/*配下に小さい単位で散在していて、用途に応じて.mcp.jsonに並べる必要がありました。Agent Toolkit ではマネージドな単一エンドポイントに集約され、Skill も自動で読み込まれるため、設定ファイルの肥大化を抑えられそうです。
- これまで AWS 関連の MCP サーバは
- ドキュメントが常に最新
- ローカルにキャッシュされた古い知識ではなく、サーバ側で最新の AWS ドキュメントを参照してくれる、というのもありがたいかと思います。
試してみる
ここでは VS Code 上の GitHub Copilot に Agent Toolkit の MCP Server を組み込んで、実際に AWS 関連の質問を投げて Skill が引かれる様子を確認します。
必要なもの
- uv がローカルにインストール済みであること
- AWS 認証情報（
aws loginまたはaws configure sso推奨）
ドキュメント検索や Skill 探索だけなら認証情報なしでも動きますが、実 API を叩くなら必須です。
MCP Server を登録
VS Code の MCP 設定はワークスペース単位なら .vscode/mcp.json、または、.mcp.json に次のブロックを追加します。
.mcp.json は先日 Visual Studio Code 1.118 で追加されていますので、VS Code のバージョンが古い場合はアップデートしておく必要があります。
.vscode/mcp.json に記載する場合:
{
"servers": {
"aws-mcp": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-proxy-for-aws@latest",
"https://aws-mcp.us-east-1.api.aws/mcp",
"--metadata", "AWS_REGION=ap-northeast-1"
]
}
}
}
.mcp.json に記載する場合:
{
"mcpServers": {
"aws-mcp": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-proxy-for-aws@latest",
"https://aws-mcp.us-east-1.api.aws/mcp",
"--metadata", "AWS_REGION=ap-northeast-1"
]
}
}
}
AWS_REGION 引数で AWS 操作のデフォルトリージョンを指定しています。MCP Server の接続先エンドポイント自体はバージニア北部で、実操作対象のリージョンとは別に指定する形になります。
接続確認
Chat ビューの Tools ピッカーで aws-mcp のツールを確認してみましょう。
GA 時点での各ツールの説明は以下の通りです。
| ツール名 | できること |
|---|---|
call_aws |
AWS CLI コマンドを実行する（メインの実行ツール） |
run_script |
Python コードをサンドボックスで実行し boto3 経由で AWS API を呼ぶ（複数 API 呼び出し・並列処理向け） |
suggest_aws_commands |
自然言語からやりたいことを説明すると、対応する AWS CLI コマンド候補を最大 10 件提案する（call_aws が使えないときのフォールバック） |
search_documentation |
AWS 公式ドキュメントを全文検索する（リファレンス・トラブルシューティング・CDK・Amplify 等トピック指定可） |
read_documentation |
指定 URL の AWS ドキュメントページを Markdown 形式で取得する（複数 URL を並列取得可） |
recommend |
指定した AWS ドキュメント URL に関連するページを推薦する（新機能ページの発見にも利用可） |
retrieve_skill |
search_documentation で見つけたスキル名を指定してドメイン特化ワークフロー（SKILL.md）を取得する |
list_regions |
全 AWS リージョンの一覧（リージョン ID・名称）を取得する |
get_regional_availability |
サービス・API・CloudFormation リソースのリージョン別提供状況を確認する |
get_presigned_url |
S3 へのファイルアップロード／ダウンロード用の署名付き URL を発行する |
get_tasks |
call_aws や run_script が返した長時間タスクの進捗をポーリングする |
Chat を Agent モードに切り替えてから、たとえば次のように聞いてみます。
利用可能な AWS リージョンを教えて
これは単純に aws___list_regions が呼び出されてリージョン一覧が返ってくる体験です。
次に aws-agents 領域（Bedrock AgentCore）と aws-core 領域（API Gateway）にまたがる質問を1つ投げてみます。
Bedrock AgentCore Runtime に簡単なエージェントを1つ作って、API Gateway 経由で呼び出せるようにしたい
Copilot 側のツール呼び出しを覗いてみると、aws___retrieve_skill が以下のパラメータで呼ばれています。
{
"skill_name": "amazon-bedrock",
"file": "references/agentcore-runtime.md"
}
amazon-bedrock skill 全体ではなく、その中の references/agentcore-runtime.md という AgentCore Runtime 専用のサブドキュメントだけがピンポイントで引かれ、トークンの節約にも貢献していそうですね。
質問内容は AgentCore（aws-agents 領域）と API Gateway（aws-core 領域）の両方に踏み込んでいますが、Plugin を別途インストールしていなくても1つの retrieve_skill 呼び出しで一通り動作していそうです。
まとめ
VS Code GitHub Copilot 経由なら .vscode/mcp.json への1ブロック追加だけで導入でき、Plugin を分けて入れなくても aws___retrieve_skill から各領域の Skill が透過的に引ける形でした。
ただし、skill が使われるかどうかは Copilot 側のジャッジに依存しており、抽象的・探索的な質問（「サーバレス API ってどう構成すればいい？」のような問い方）では retrieve_skill がスキップされ、自前知識だけで回答が組み立てられてしまうケースもありました。skill の説明欄には "Always use this skill when ..." のような明示的なトリガー文言が書かれていることが多いので、質問の語彙をそちらに寄せて、具体的・動詞ベースで聞くほど引かれやすい印象です。「aws___retrieve_skill を使って」と明示してしまうのも、確実に通したいときの手としてありかと思います。