AWS MCP を触ってみた話

Last updated at 2025-12-22Posted at 2025-12-22

この記事は RnI アドベントカレンダー 2025 の 12 月 23 日の記事です。

はじめに

こんにちは！RnI の SRE チームの松本です。

2025 年 10 月に MCP Proxy for AWS が GA（一般提供）となり、AWS がホストするリモート MCP サーバーに接続できるようになりました。今回はこれを使って GitHub Copilot から AWS リソースの情報を取得してみたので、その使い方や感想をご紹介します。

MCP とは

MCP（Model Context Protocol）の概要

MCP（Model Context Protocol）は、2024 年 11 月に Anthropic 社がオープンソースとして公開したプロトコルです。

AI モデルが外部のデータソースやツールに、一貫性のある安全な方法でアクセスするための標準規格として設計されています。簡単に言うと、Claude、ChatGPT、GitHub Copilot など LLM を搭載したAIアプリケーションと、外部サービスをつなぐ共通のインターフェースです。

出典: Model Context Protocol - Introduction

MCP を使うことで、AI アプリケーションは以下のようなことができるようになります。

ファイルシステムやデータベースへのアクセス
外部 API との連携
クラウドサービスの操作

MCP の主要な概念

MCP では、サーバーがクライアント（AI アプリケーション）に提供する機能を以下の 3 つの概念で定義しています。

概念	説明	例
Tools	AI が外部システムと対話するための機能。データベースクエリ、API 呼び出し、計算処理などを実行できる	天気取得、AWS API 実行
Resources	サーバーがクライアントに公開するデータ。URI で一意に識別される	ローカルファイル、DB レコード
Prompts	構造化されたメッセージテンプレートと指示。スラッシュコマンドのような UI で公開されることが多い	コードレビュー依頼テンプレート

AWS MCP サーバーでは主に Tools を提供しており、aws___call_aws や aws___search_documentation などのツールを通じて AWS リソースの操作やドキュメント検索ができます。

AWS MCP サーバーで使えるツール

AWS MCP サーバーは、3 つのカテゴリのツールを提供しています。

AWS MCP サーバーで使えるツール一覧

カテゴリ	主なツール	機能
Agent SOP	`aws___retrieve_agent_sop`	ワークフローや手順書の取得
AWS ナレッジ	`aws___search_documentation`	AWS ドキュメントの横断検索
	`aws___read_documentation`	ドキュメントページの取得
	`aws___recommend`	関連トピックの推奨
	`aws___list_regions`	リージョン一覧の取得
	`aws___get_regional_availability`	サービスのリージョン別可用性確認
AWS API	`aws___call_aws`	AWS API の実行（15,000 以上の API に対応）
	`aws___suggest_aws_commands`	API の説明・構文ヘルプ

今回は、MCP Proxy for AWS を使って、GitHub Copilot から AWS リソースの情報を取得してみます。

環境構築

前提条件

今回は以下の環境で検証しました。

カテゴリ	項目
ハードウェア / OS	macOS Sequoia 15.6.1（Apple M3 Max / 64 GB）
ソフトウェア	AWS CLI v2.32.18
	Python 3.12.4（uvx を使用）
	VS Code + GitHub Copilot（Claude Sonnet 4.5）
AWS	検証用 AWS アカウント

1. IAM の設定

AWS MCP を利用するための IAM ユーザーを用意し、以下の権限を付与します。

必要な権限	用途
`SignInLocalDevelopmentAccess` マネージドポリシー	`aws login` でサインインする
確認したいリソースの読み取り権限（例: `ReadOnlyAccess`）	MCP 経由で AWS リソースにアクセスする

検証目的であれば ReadOnlyAccess ポリシーをアタッチするのが簡単です。

本番運用では、最小権限の原則に従い、必要な権限のみを付与してください。

2. AWS プロファイルのセットアップ

IAM の設定が完了したら、aws login コマンドでサインインします。

# AWS にサインイン（ブラウザが開きます）
aws login

# プロファイルを指定してサインインも可能
aws login --profile your_profile_name

aws login を使えば、アクセスキーを発行せずに一時的な認証情報でサインインできます。アクセスキーの漏洩リスクを減らせるので、セキュリティ面でもおすすめです。

ここで作成したプロファイルを、次の MCP 設定で指定します。MCP はこのプロファイルに紐づく IAM 権限で AWS API を実行するため、「1. IAM の設定」で付与した権限の範囲内で操作が可能になります。

3. VS Code / GitHub Copilot での設定

プロジェクトのルートに .vscode/mcp.json を作成し、以下のように設定します。

{
  "servers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--profile", "your_profile_name",
        "--metadata", "AWS_REGION=ap-northeast-1"
      ]
    }
  }
}

設定項目の説明：

項目	説明
`mcp-proxy-for-aws@latest`	ローカルで動く軽量な Proxy（中継役）
`https://aws-mcp.us-east-1.api.aws/mcp`	AWS がホストするリモート MCP サーバーのエンドポイント
`--profile`	使用する AWS プロファイル名
`--metadata AWS_REGION`	操作対象のリソースがあるリージョン

MCP サーバーのエンドポイント（us-east-1）と、操作対象のリージョン（ap-northeast-1）は別物です。エンドポイントは MCP サーバー自体のホスト先（現在は us-east-1 のみ）、AWS_REGION は実際に確認・操作したい AWS リソースのリージョンを指定します。

構成イメージ：

ローカルでは軽量な Proxy を動かすだけで、重い処理（AWS API の実行やドキュメント検索）は AWS 側のリモートサーバーが担当します。自前で MCP サーバーを管理しなくて済むのが利点です。

認証には AWS の標準的な方式である SigV4 署名を使用します。シークレットアクセスキーはローカルで署名計算に使われるだけで、ネットワークには送信されません。

VSCodeを用いたMCP サーバーの起動方法についてはこちらを参照してください。

実際に使ってみた

今回は、SRE の日常業務で使えそうなシナリオをいくつか試してみました。

検証用の AWS アカウントには、VPC、ECS Fargate、Aurora MySQL、Lambda、S3 などのリソースを事前に構築しています。

各ユースケースの結果は、以下の基準で（やや甘めに）評価しました。
出力結果については分量が多いため、概要のみ記載します。

評価	説明
◎	期待以上の結果で、そのまま活用できる
○	概ね期待通りだが、一部補足や確認が必要
△	参考にはなるが、追加の調査や検証が必要
×	誤りや不足が多く、そのままでは使えない

ユースケース 1: AWSインフラ構成の把握

まずはざっくりとした質問で、AWS MCP がどこまで情報を集めてくれるか確認します。

プロンプト：

現在のプロファイルで接続している AWS のインフラ構成を教えて

aws-mcp サーバーを通じて複数の AWS API を呼び出し、インフラ構成を取得している

出力された内容の概要：

カテゴリ	取得できた情報
ネットワーク	VPC、サブネット構成、NAT Gateway、VPC Endpoints 等
コンピューティング	ECS Fargate（タスク数、サービス数）、Lambda 関数一覧、ALB 等
データベース	Aurora MySQL の構成（ACU 設定、Multi-AZ、暗号化設定等）
ストレージ	S3 バケット一覧（用途別に分類）
セキュリティ・監視	WAF、CloudWatch Alarms、Datadog 連携、Security Hub 等

さらに Mermaid 形式のアーキテクチャ図や、優れている点・改善検討事項の評価まで出力してくれました。

評価： ○（情報取得したインフラの構成情報は正確だが、Mermaid の構成図は粒度が粗く見づらい。）

ユースケース 2: 可用性の確認

全体像を把握した上で、障害時の影響範囲や冗長構成について確認します。

プロンプト：

可用性の観点で気になるところはある？

出力された内容の概要：

区分	指摘内容
懸念事項	NAT Gateway が Single AZ 構成、ECS タスク数が少ない、VPC Endpoints の冗長構成の確認が必要
良好な点	Aurora Multi-AZ 構成、サブネットの 2AZ 分散、削除保護の有効化
追加確認	Route53 ヘルスチェック、ECS 最小タスク数とデプロイ設定、ALB クロスゾーン負荷分散、リストア手順

NAT Gateway の Single AZ が最優先の対応事項として挙げられ、AZ 障害時の影響範囲も具体的に説明されました。

評価： ◎（各指摘は技術的に正確で、改善検討の参考にできる）

ユースケース 3: コストの確認

コスト面で最適化できそうな箇所がないか確認します。

プロンプト：

コストの観点で気になるところはある？

出力された内容の概要：

優先度	指摘内容
高	リソース利用率が低い、検証環境の 24 時間稼働、S3 ライフサイクル未設定
中	Aurora Serverless v2 の ACU 設定見直し、Lambda メモリ最適化、不要な Lambda 削除
低	NAT Gateway → NAT Instance 検討、VPC Endpoint の見直し

想定削減額の試算や、対策の優先順位まで提示してくれました。

評価： ○（構成ベースの指摘は正確。ただし想定削減額などは別途確認が必要）

良かった点・気になった点

良かった点

自然言語で質問できる: 「インフラ構成を教えて」といった曖昧な質問でも、適切な AWS API を選んで情報を集めてくれる
情報の正確性が高い: VPC、サブネット構成、Aurora 設定など、主要な構成情報は実際の設定と一致していた
実用的な指摘: NAT Gateway の Single AZ 問題など、実際に改善を検討すべき項目を的確に指摘してくれた
構造化された出力: 表形式や Mermaid 図など、読みやすい形式で出力してくれる
セットアップが簡単: aws login と .vscode/mcp.json の設定だけで使い始められる

気になった点

レスポンス速度: 複数の AWS API を順次呼び出すため、1 回の質問に数十秒〜数分かかることがある
Mermaid 図の精度: アーキテクチャ図は概要把握には便利だが、細部に誤りや誤解を招く描き方があった
取得されないリソースがある: Route53、CloudFront、Secrets Manager、EventBridge など、今回の質問では取得されなかったリソースもあった。明示的に聞けば取れるかもしれないが、全体像の把握では漏れる可能性がある
瞬間的な値での判断に注意: CPU 使用率などは CloudWatch から取得した瞬間的な値のため、それだけで判断するのは難しい

まとめ

AWS MCP を使うことで、自然言語での質問から AWS リソースの構成情報を手軽に取得できました。特に可用性やコストの観点での分析は、SRE の日常業務で役立ちそうです。

ただし、出力された提案をそのまま鵜呑みにするのではなく、現在の構成に至る経緯を含めて確認することが重要です。例えば今回「NAT Gateway が Single AZ」と指摘されましたが、検証環境ではコスト優先で意図的にそうしているケースもあります。現状では、SRE 業務の補助役として「調査の起点」や「見落としのチェック」に活用するのが良さそうです。

今回はざっくりした質問で検証しましたが、用途ごとにプロンプトや事前の設定ファイル(copilot-instructions.mdやSKILL.mdなど)を工夫すれば、より精度の高い出力が期待できそうです。例えばセキュリティチェックリストを渡して各項目を確認させたり、コスト分析用の観点を事前に定義しておくなど、目的別の設定を用意しておくと業務への活用がさらに広がると思います。

今後は tfstate ファイルを読み込ませて全体像を把握したり、Terraform コードと実際のリソースの差分チェック（ドリフト検出）に使えるかなども試してみたいです。将来的には SRE エージェントとして活躍してくれることを期待しています。

参考リンク

採用情報

RnI では一緒に働く仲間を募集しています！

SRE チームでは、AWS をはじめとしたクラウドインフラの設計・運用や、今回ご紹介したような新しい技術の検証・導入にも積極的に取り組んでいます。

興味のある方はぜひお気軽にご連絡ください！

👉 エンジニア採用ページはこちら

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AWS MCP を触ってみた話

はじめに

目次

MCP とは

MCP（Model Context Protocol）の概要

MCP の主要な概念

AWS MCP サーバーで使えるツール

環境構築

前提条件

1. IAM の設定

2. AWS プロファイルのセットアップ

3. VS Code / GitHub Copilot での設定

実際に使ってみた

ユースケース 1: AWSインフラ構成の把握

ユースケース 2: 可用性の確認

ユースケース 3: コストの確認

良かった点・気になった点

良かった点

気になった点

まとめ

参考リンク

採用情報