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

1. って本当に不要？ AWS MCP Serverで確かめる 新しい役割 MCP
2. 今日話すこと 不要論について 1 MCP 2 検証1 操作の追跡 3 検証2 権限の制御 4 検証3 知識の鮮度 5 まとめ
3. 従来MCPが担っていた役割 能力の提供 知識の提供 外部サービスを操作するツールを エージェントに渡す 最新ドキュメントや手順書を エージェントに渡す ▼ 不要論の主張 ▼ 不要論の主張 を直接使えば同じことができる CLI として手元に置けば足りる Skills 不要論 = どちらもCLIとSkillsで代替できるという主張
4. の実行環境 MCP サーバーは大きく分けて二つの実行環境で分類できる MCP ローカル起動型 自分のマシンで起動する – ツールの実体は手元のプロセス – 不要論が前提にしているのはこちら – リモート型 提供元のサービスとして動く – 呼び出しは提供元のインフラを経由 – 新しいMCPサーバーの形 –
5. AWS MCP Server 年 月にGAされた、AWSが運用するリモート型MCPサーバー 手元でサーバーを立てず、接続先URLを登録するだけで使用できる 2026 6 での接続設定（これだけ） # Claude Code claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http サーバー本体はAWS上で動き、呼び出しはIAMで認 証される もリモート型MCPサーバーを強化している AWS
6. リモート型MCPサーバーが担う新しい役割 リモート型MCPサーバーは、CLIとSkillで代替できない新たな役割を担っている 1 操作の追跡 2 権限の制御 3 知識の鮮度 エージェントの操作だと、あとから記録で識別できるか 経由で実行される特定の操作を止められるか MCP モデルが学習していない知識を継続的に補えるか この新しい役割を、AWS MCP Serverで検証してみます！
7. 今日話すこと 1 2 不要論について MCP 検証1 操作の追跡 3 検証2 権限の制御 4 検証3 知識の鮮度 5 まとめ
8. 検証1の方法 操作で、MCP経由のリクエストが追跡できるかを検証 API 揃えたもの ロール ・リージョン S3バケットを1つ作成する操作 IAM lt-mcp-verify ap-northeast-1 変えたもの 経路A ローカルの AWS CLI 経路B AWS MCP Server の 観測したもの CloudTrail run_script に残った両者の記録を全フィールドで比較
9. 検証1の結果 CloudTrailの差分 経路A（CLI） 経路B（MCP） assumed-role/lt-mcp-verify/… assumed-role/lt-mcp-verify/… フィールド自体が無い aws-mcp.amazonaws.com sourceIPAddress クライアントのIP aws-mcp.amazonaws.com userAgent aws-cli/2.33.5 … aws-mcp.amazonaws.com （使用された userIdentity.arn role ） userIdentity.invokedBy 経由のリクエストかどうかを判別することができた MCP
10. 今日話すこと 不要論について 1 MCP 2 検証1 操作の追跡 3 検証2 権限の制御 4 検証3 知識の鮮度 5 まとめ
11. 検証2の方法 検証1と同一ロールに、このDenyポリシーだけを追加して両経路から削除を実行 { "Effect": "Deny", "Action": "s3:DeleteBucket", "Condition": { "Bool": { "aws:ViaAWSMCPService": "true" } } } AWS MCP Server 付く条件キー 経由のリクエストにだけ自動で
12. 検証2の結果 経路A（CLI）→ 成功 $ aws s3api delete-bucket --bucket lt-verify1-cli-20260827-011404 ( exit=0 ) 出力なし・ バケットは削除された 経路B（MCP）→ AccessDenied / HTTP 403 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 同じロール・同じ操作のまま、MCP経由の削除だけが拒否された
13. 今日話すこと 不要論について 1 MCP 2 検証1 操作の追跡 3 検証2 権限の制御 4 5 検証3 知識の鮮度 まとめ
14. 検証3の方法 モデルが学習していない機能に対し、CLIとどの程度差がでるか検証 書かせたもの モデルが学習していない新機能の実装手順をレポートさせる 新規セッションで、3回ずつ試して比較する 比較した条件 条件A AWS CLI のみ 条件B AWS MCP Server（ドキュメント検索） 数えたもの 全コマンドをAPI定義（service-2.json）と機械照合し、実在しないAPIを数える
15. 生成レポートイメージ プロンプト（抜粋） 経由で社内ツールを呼び出す構成を ゼロから構築します。以下の要件をすべて満たす構築手順を書いてください。 - ユーザー単位で、リクエスト数とトークン消費量の両方にレート制限をかける 実在しないコマンド名・パラメータ名を書かないでください。 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コマンド入り手順書が返ってくる
16. 検証3の結果 実在しないAPIの数 条件A（CLIのみ） 条件B（MCP Server） 0件 0件 回とも0 ／ 計132コマンド照合 3 回とも0 ／ 計66コマンド照合 3 だけでも、存在しないAPIを叩くことはない CLI
17. では根拠を示せる MCP 題材に含めた「ユーザー単位のトークン制限」について、生成結果に差が生じた 条件A（CLIのみ） 条件B（MCP Server） ターゲットでのトークン計上 の有無は不明です。検証で必ず実測し てください （TPM）は推論ターゲットにし か適用されません。Lambda ツールタ ーゲットには、設定はできても実際に は評価されません Lambda 本とも同旨（A/1 §9-5 ほか） 3 tokens 本とも同旨（B/3 §8-3 ほか） 3 としては成功する設定が実際には効かない、と言えたのは条件Bだけ API
18. 今日話すこと 不要論について 1 MCP 2 検証1 操作の追跡 3 検証2 権限の制御 4 検証3 知識の鮮度 5 まとめ
19. は本当に不要か？ MCP 開発者個人には で十分 – 自分の操作を監査する必要がない – 権限をAIと分離する必要がない – CLI を利用する組織には AI 経路を識別できる – 経路ごとに権限を分けられる – AIが継続的に正しい情報を取得できる –
20. ご清聴ありがとうございました！