MCPって本当に不要？ AWS MCP Serverで確かめる新しい役割

Transcript

1. って本当に不要？ AWS MCP Serverで確かめる 新しい役割 MCP
2. 今日話すこと 不要論とリモート型 1 MCP 2 AWS MCP Servers 3 4 5 6 7 の概要 検証1 操作の追跡 検証2 権限の制御 検証3 知識の鮮度 検証4 集約による効率化 限界とまとめ
3. 従来MCPが担っていた役割 能力の提供 知識の提供 外部サービスを操作するツールを エージェントに渡す 最新ドキュメントや手順書を エージェントに渡す ▼ 不要論の主張 ▼ 不要論の主張 を直接使えば同じことができる CLI として手元に置けば足りる Skills 不要論 = どちらもCLIとSkillsで代替できるという主張
4. の実行環境 MCP サーバーは大きく分けて二つの実行環境で分類できる MCP ローカル起動型 自分のマシンで起動する – ツールの実体は手元のプロセス – 不要論が前提にしているのはこちら – リモート型 提供元のサービスとして動く – 呼び出しは提供元のインフラを経由 – 新しいMCPサーバーの形 –
5. 今日話すこと 不要論とリモート型 1 MCP 2 AWS MCP Servers 3 4 5 6 7 検証1 操作の追跡 検証2 権限の制御 検証3 知識の鮮度 検証4 集約による効率化 限界とまとめ の概要
6. AWS MCP Servers awslabs/mcp と聞いて思い浮かぶもの で公開されている、サービスごとの約60種類のサーバー AWS API MCP Server AWS IaC MCP Server CLI AWS Documentation MCP Server Amazon EKS / ECS MCP Server Amazon DynamoDB MCP Server AWS Knowledge MCP Server コマンドでAPIを実行 コンテナの運用とデプロイ Knowledge 以外は 公式ドキュメントを検索 テーブル設計の支援 uvx awslabs. 〇〇@latest と のガイドと検証 CFn CDK ドキュメント検索（リモート） で手元で起動するローカル起動型
7. ローカル起動型から、リモート型へ 主にローカル起動型だったところに、AWSが運用するリモート型が加わった 2025 AWS Labs サービスごと 主にローカル起動型 2025-11-30 2026-05-06 プレビュー APIとKnowledgeを 統合したリモート型 GA Agent Toolkit 出典 AWS What's New（2025-11-30 / 2026-05-06）、GitHub awslabs/mcp の 一部として提供
8. からAgent Toolkit for AWSへ AWS MCP Servers コーディングエージェントがAWSで作業するための、AWS公式の配布セット AWS Labs サーバーやSkillsを個別に公開 – 引き続き利用できる – MCP AWS Labs Agent Toolkit for AWS つの部品をまとめて提供 – IAM条件キーと CloudTrail の記録 – 精度を評価した Skills – 4 の中で有用なものを、順に Agent Toolkit へ移していく 出典 AWS What's New 2026-05-06（the best of AWS Labs will be transitioned to the Agent Toolkit for AWS）
9. は つの部品でできている Agent Toolkit 4 サーバーだけでなくSkillsや設定ファイルまで、追加料金なしで提供される MCP 1 2 3 4 AWS MCP Server を操作するリモートMCPサーバー AWS Skills 作業手順と参考資料をまとめたパッケージ Plugins の接続設定とSkillsを1回で入れるパッケージ MCP Rules files プロジェクト単位でエージェントに渡す指示ファイル 出典 Agent Toolkit for AWS User Guide「Agent Toolkit for AWS components」、AWS What's New 2026-05-06
10. AWS MCP Server AWS Labs は、その中のMCPを担う部品 の2つのサーバーの役割を、1つのリモートMCPサーバーにまとめた AWS Labs （リモート型） AWS MCP Server AWS API MCP Server ローカル起動型、 call_aws でCLIコマンドを 実行 AWS Knowledge MCP Server リモート型、ドキュメント検索 → 系ツール API run_script でPythonを実行 系ツール Knowledge ドキュメント検索とSkills取得 中身の系統は同じだが、API実行もAWS側に移った 出典 AWS What's New「AWS MCP Server（Preview）」2025-11-30
11. は と AWS MCP Skills をセットで配っている を つ入れると、MCP Serverの接続設定とSkillsが同時に入る Plugin 1 に プラグインを入れる # Claude Code aws-core /plugin install aws-core@claude-plugins-official Core AWS skills and MCP Server configuration （aws-core の説明文） MCP vs Skills という二項対立は、配り方の実態とずれている 出典 GitHub aws/agent-toolkit-for-aws README
12. AWS MCP Server につなぐ2つの方法 年 月にGAされた、AWSが運用するリモート型MCPサーバー 2026 5 接続 URLを登録するだけ（IAMでOAuth用ポリシーの付与が必要） OAuth claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http 接続 手元でプロキシを起動（プロファイルの切り替えはこちらだけ） SigV4 uvx mcp-proxy-for-aws-cli@latest https://aws-mcp.us-east-1.api.aws/mcp どちらの方法でも、サーバー本体はAWS上で動く 出典 Agent Toolkit for AWS User Guide「Setting up the AWS MCP Server」
13. 接続でプロキシがしていること 認証情報は手元に置いたまま、署名したリクエストだけが へ渡る SigV4 AWS 自分のPC AWS エージェント 1 ツールを呼ぶ ↓ MCP Proxy 2 ~/.aws 3 → 署名付きで送る の認証情報で署名 AWS MCP Server 4 署名で本人確認、条件キーを付ける 5 同じIAM権限で呼ぶ ↓ S3 など 接続なら、この署名の代わりにAWS Sign-in のトークンを使う OAuth 出典 Agent Toolkit for AWS User Guide「How AWS MCP Server works with IAM」
14. つのツールを提供している 8 「ツール定義がコンテキストを食う」批判に、ツールを増やさない設計で応える 系（認証なし） 系（IAM認証） Knowledge – search_documentation – – – – read_documentation API – run_script serverless capability – – retrieve_skill list_regions もこの中で使う get_presigned_url get_tasks get_regional_availability 以上のAPIを8個のツールで扱う 15,000 2026-09-29 に tools/list を実測（接頭辞 aws___ は省略）
15. call_aws はもう無い 同じ「バケットを1つ作る」を比べる（2026-09-29 の tools/list に call_aws は無い） （ローカル版に残る） 1回の呼び出し = CLIコマンド1つ call_aws aws s3api create-bucket --bucket lt-verify1-local-… --region ap-northeast-1 \ --create-bucket-configuration LocationConstraint=ap-northeast-1 run_script （現行） 1回の呼び出し = 複数のAPIを呼べるPython r = await call_boto3(service_name="s3", operation_name="CreateBucket", region_name="ap-northeast-1", params={"Bucket": "lt-verify1-mcp-…", …}) ツールを増やさず、スクリプト1本に寄せた
16. リモート型MCPサーバーが担う新しい役割 リモート型MCPサーバーは、CLIとSkillで代替できない新たな役割を担っている 1 2 3 4 操作の追跡 エージェントの操作だと、あとから記録で識別できるか 権限の制御 経由で実行される特定の操作を止められるか 知識の鮮度 モデルが学習していない知識を継続的に補えるか 集約による効率化 MCP 複数の調査を1回の呼び出しにまとめ、少ないトークンで答えに届くか この新しい役割を、AWS MCP Serverで検証してみます！
17. 今日話すこと 1 2 3 4 5 6 7 不要論とリモート型 AWS MCP Serversの概要 MCP 検証1 操作の追跡 検証2 権限の制御 検証3 知識の鮮度 検証4 集約による効率化 限界とまとめ
18. 検証1の方法 操作で、MCP経由のリクエストが追跡できるかを検証 API 揃えたもの ロール IAM lt-mcp-verify ・リージョン ap-northeast-1 で、S3バケットを1つ作成する 変えたもの 経路A ローカルの AWS CLI 経路B AWS MCP Server の 経路C ローカル起動の AWS API MCP Server の run_script 観測したもの CloudTrail call_aws に残った3経路の記録を全フィールドで比較
19. 検証1の結果 CloudTrailの差分 経路A（CLI）と経路C（ローカル MCP） 経路B（AWS MCP Server） userIdentity.arn role assumed-role/lt-mcp-verify/… assumed-role/lt-mcp-verify/… userIdentity.invokedBy A C ・ ともフィールド自体が無い aws-mcp.amazonaws.com ・ とも手元のIP aws-mcp.amazonaws.com ） （使用された sourceIPAddress userAgent invokedBy A C A aws-cli/… C …aws-api-mcp-server… aws-mcp.amazonaws.com と sourceIPAddress が変わるのはAWS MCP Server経由だけ
20. 経路Cは userAgent にサーバー名が入る 「ローカルMCPはCLIと見分けがつかない」という仮説は外れた "userAgent": "[Boto3/1.43.104 md/Botocore#1.43.104 … Botocore/1.43.104 md/awslabs#mcp#aws-api-mcp-server#1.5.5 md/via/AWS-API-MCP MCPClient/claude-code#2.1.284 cfg/ro#0 cfg/consent#0 cfg/scripts#0 …]" のサーバーが、APIリクエストの Userに自分の名前と設定を書き込んでいる awslabs Agent ただし書き換えられる文字列で、IAMの条件にも使えない
21. 見えるのは「経路」まで AWS MCP Server 自身の呼び出し記録（CallReadWriteTool）の中身 "params": { "name": "aws___run_script", "arguments": "[HIDDEN_DUE_TO_SECURITY_REASONS]" } どのツールを呼んだかは残るが、渡したコードの中身は残らない
22. 今日話すこと 1 2 3 4 5 6 7 不要論とリモート型 AWS MCP Serversの概要 検証1 操作の追跡 MCP 検証2 権限の制御 検証3 知識の鮮度 検証4 集約による効率化 限界とまとめ
23. 検証2の方法 検証1と同一ロールに、このDenyポリシーだけを追加して3経路から削除を実行 { "Effect": "Deny", "Action": "s3:DeleteBucket", "Condition": { "Bool": { "aws:ViaAWSMCPService": "true" } } } AWS MCP Server 付く条件キー 経由のリクエストにだけ自動で
24. 検証2の結果 経路A（CLI）→ 成功（exit=0） 経路B（AWS MCP Server）→ AccessDenied An error occurred (AccessDenied) when calling the DeleteBucket operation: User: arn:aws:sts::…:assumed-role/lt-mcp-verify/lt-mcp-verify-session is not authorized to perform: s3:DeleteBucket on resource: … with an explicit deny in an identity-based policy 経路C（ローカルMCP）→ 成功 "cli_command": "aws s3api delete-bucket --bucket lt-verify1-local-20260929-230813 …" "response": {"error": null, "status_code": 204, …} 同じMCPでも、ローカル起動型の削除は止まらない
25. 今日話すこと 1 2 3 4 5 6 7 不要論とリモート型 AWS MCP Serversの概要 検証1 操作の追跡 検証2 権限の制御 MCP 検証3 知識の鮮度 検証4 集約による効率化 限界とまとめ
26. 検証3の方法 モデルが学習していない機能に対し、CLIとどの程度差がでるか検証 書かせたもの モデルが学習していない新機能の実装手順をレポートさせる 新規セッションで、3回ずつ試して比較する 比較した条件 条件A AWS CLI のみ 条件B AWS MCP Server（ドキュメント検索） 数えたもの 全コマンドをAPI定義（service-2.json）と機械照合し、実在しないAPIを数える
27. 生成レポートイメージ プロンプト（抜粋） 経由で社内ツールを呼び出す構成を ゼロから構築します。以下の要件をすべて満たす構築手順を書いてください。 - ユーザー単位で、リクエスト数とトークン消費量の両方にレート制限をかける 実在しないコマンド名・パラメータ名を書かないでください。 Amazon Bedrock AgentCore Gateway 生成されたレポート（抜粋） を作成 ## Step 1 Policy Engine aws bedrock-agentcore-control create-policy-engine \ --region "$AWS_REGION" --name "$ENGINE_NAME" ### get-policy-engine status ACTIVE 待機条件 の が になるまで待つ 実行できる形のCLIコマンド入り手順書が返ってくる
28. 検証3の結果 実在しないAPIの数 条件A（CLIのみ） 条件B（MCP Server） 0件 0件 回とも0 ／ 計132コマンド照合 3 回とも0 ／ 計66コマンド照合 3 だけでも、存在しないAPIを叩くことはない CLI
29. では根拠を示せる MCP 題材に含めた「ユーザー単位のトークン制限」について、生成結果に差が生じた 条件A（CLIのみ） 条件B（MCP Server） ターゲットでのトークン計上 の有無は不明です。検証で必ず実測し てください （TPM）は推論ターゲットにし か適用されません。Lambda ツールタ ーゲットには、設定はできても実際に は評価されません Lambda 本とも同旨（A/1 §9-5 ほか） 3 tokens 本とも同旨（B/3 §8-3 ほか） 3 としては成功する設定が実際には効かない、と言えたのは条件Bだけ API
30. 今日話すこと 1 2 3 4 5 6 7 不要論とリモート型 AWS MCP Serversの概要 検証1 操作の追跡 検証2 権限の制御 検証3 知識の鮮度 MCP 検証4 集約による効率化 限界とまとめ
31. serverless capability Lambda とは が失敗したときに、原因の手がかりを集めて要約して返す関数 エージェント diagnose() を呼ぶ 短いPython 4 1 run_script 読むのは 要約された結果だけ → ← 3 AWS aws_serverless で送る 要約を返す 側（run_script の中） 2 ここでAPIを何十回も呼んで集計 CloudWatch Logs CloudTrail X-Ray 何十回ものAPI呼び出しと集計を、関数1回にまとめる 出典 Agent Toolkit for AWS User Guide「Capabilities」、2026-09-29 に help(aws_mcp) で実測
32. 側のサンドボックスで動く意味 AWS 手元のシェルなし（AWS側のサンドボックス）で、安全に実行できる 手元で絞る（Bash と jq など） 手元のシェルが必要 – 条件キーが付かない（検証2） – Bash を塞ぐと使えない – 側で絞る（run_script） AWS シェルは不要 – 条件キーが付き、CloudTrail に残る – Bash を塞いでも使える（検証5） – 安全を保ったまま、トークンに載せる前に絞れる
33. serverless capability の5つの関数 どれも読み取り専用で、自分のアカウントのリソースだけが対象 1 2 3 4 5 diagnose メトリクスを7日間の平常時と比べ、どこが悪いかを返す search_logs ログのエラーを種類ごとにまとめ、代表例だけ返す get_live_config Lambda と接続先の、今の設定を返す get_recent_changes 最近のデプロイと設定変更を時系列で返す get_trace_summary X-Ray のトレースから、遅い箇所とエラーの箇所を返す
34. 検証4の方法 serverless capability で、障害の原因調査が少ないトークンで終わるかを検証 仕込んだ障害 → Lambda → DynamoDB の構成で、Lambdaのタイムアウトを3秒から1秒に変更 「500の根本原因を調べて」と頼む（読み取り専用ロール、新規セッションで3回ずつ） API Gateway 比較した条件 条件A AWS CLI のみ 条件B AWS MCP Server（依頼文に「serverless capability を使って」と1文追加） 数えたもの 入力・出力トークン、ツール呼び出し回数、所要時間、原因を正しく特定できた回数
35. 検証4の結果 原因の特定にかかったコスト 条件A（CLIのみ） 条件B（capability を使用） 10.7 万 15.8 万 正答 3/3 ／ 呼び出し 9.3回 ／ $0.21 正答 3/3 ／ 呼び出し 10.7回 ／ $0.28 どちらも3回とも正解、トークンは1.5倍に増えた 入力トークンはキャッシュ読み込みを含む累計の3回平均（モデル opus）。費用は1回あたりの平均
36. なぜ増えたのか 固定費と変動費 条件A（CLIのみ） 取り方 --query 固定費 毎ターン送る定義 や tail で絞って読む 5,379 トークン 条件B（capability を使用） つの関数をすべて順に呼ぶ 5 約 8,830 トークン 万 7.9 万 7.9 固定費の累計（× 呼び出し回数） 4.7 変動費 調査で積み上がった分 6.1 万 万 増えた分の約65%は、capability ではなくMCPを登録した固定費 AWS MCP Server の8ツールの定義と指示文は約5,000トークン（2026-09-30 実測）。呼ばなくても毎ターン送られる
37. 要約で落ちた情報もあった 変更前のタイムアウト値（3秒）を示せたのは、条件A 2/3、条件B 0/3 条件A 生のCloudTrail 作成時（23:07:17 JST、 ） は でした。23:46:11 JST の で に変わっています 条件B capability の要約 変更前の値は CloudTrail に新しい値 しか残っていないため確認できていま せん CreateFunction "timeout": 3 UpdateFunctionConfiguration A/3 の報告より（A/2 も同旨） "timeout": 1 B/3 の報告より（3本とも同旨） 要約は読む量を減らすが、捨てた情報にはたどり着けない
38. 応答だけを比べると、読む量は28分の1 同じ情報のトークン数 ▪ 生のAPI（CLIの出力） ▪ aws_serverless の関数 filter‑log‑events 53,539 search_logs lookup‑events 3,147 ほか 69,333 get_recent_changes 4,179 get‑trace‑summaries 129,489 get_trace_summary 314 関数の合計で 256,362 → 9,210 トークン 5
39. を直接呼ぶと diagnose 同じ障害中の関数を、 aws_serverless.diagnose に1回だけ診断させた "root_cause": {"resource": "lt-v4-order-fn", "type": "Lambda Function", "issue": "high error rate"}, "impact_chain": ["Error rate 100.0% exceeds 5% threshold"], "recommendations": ["Check Lambda logs for error details", "Review recent code deployments"] 診断が示すのは次に見るべき場所まで、タイムアウトとは言っていない 2026-09-29 15:10Z 実行、応答は2,360文字（7日間のベースラインなし）
40. 課題と、効果が出るはずの場面 応答には上限がある（ログは代表5件、トレースは20件）。右側は未検証 今回見えた課題 登録の固定費が毎ターンかかる – 関数を順に全部呼び、ターンが増える – 要約で変更前の値が落ちた – 履歴がないと diagnose は大まか – MCP 効果が出るはずの場面 ログやトレースが大量にある – 断続的に失敗している – 原因が接続先にしか出ない – 7日分の平常時データがある – 読む量が固定費を上回る調査ほど、差は開くはず
41. 今日話すこと 1 2 3 4 5 6 7 不要論とリモート型 AWS MCP Serversの概要 検証1 操作の追跡 検証2 権限の制御 検証3 知識の鮮度 検証4 集約による効率化 MCP 限界とまとめ
42. を通らない操作には条件キーが付かない MCP が効くのは、AWS MCP Serverを通ったリクエストだけ Deny 条件キーが付く の – 検証2で削除を止められた – AWS MCP Server run_script 条件キーが付かない エージェントが bash で叩く AWS CLI – ローカル起動型のMCPサーバー – 検証2で削除が素通りした – エージェントがbashを持っている限り、IAMの制御は迂回できる 出典 AWS Security Blog「Secure AI agent access patterns to AWS resources using Model Context Protocol」
43. を塞いで、MCPだけを許可する bash Bash だけでなく、コマンドを実行できるツールをすべて deny する { "permissions": { "deny": ["Bash", "PowerShell", "Monitor"], "allow": ["mcp__aws-mcp__*"] } } 塞ぐほど安全だが、エージェントにできることも減る は「MCPサーバー経由でだけAWSを触るエージェント」に限って汎用の実行手段を外す、としている。2026-09-29 実測 Bash(aws *) だけの deny は sh -c ですり抜けた AWS Security Blog
44. は本当に不要か？ MCP 開発者個人には で十分 – 自分の操作を監査する必要がない – 権限をAIと分離する必要がない – CLI を利用する「組織」には AI 経由なら、経路を識 別して権限を分けられる – AIが継続的に正しい情報を取得できる – 調査で読む量を減らせる（重い障害ほ ど効くはず） – ただし bashを塞がないと素通りする – AWS MCP Server
45. ご清聴ありがとうございました！