AWSがMCPをGAに引き上げた日 — 標準は誰の手を離れたのか

Anthropicが作ったプロトコルをAWSがGAとして出すことは何を意味するのか。標準が作り手の手を離れる瞬間、その標準は強くなるのか、それとも形骸化するのか。そしてその間に、誰のIAMポリシーが最初に壊れるのか。

導入 — 102 LGTMが語っているもの

2026年5月6日、AWSは自社の Model Context Protocol(MCP)サーバーを一般提供(GA)に移行したと公式ブログで発表した。三日後の5月9日、日本のAWSコミュニティで活動するエンジニア Syoitu が Qiita に「AWS MCPサーバー超進化してGAしたらしい」というタイトルでまとめ記事を投稿し、この記事は公開24時間で 102 LGTM を獲得した。日本の Qiita で 100 LGTM は一年に数えるほどの数字である。同じ週にそれより多くの LGTM を集めた記事は、全カテゴリを合わせても五本に満たない。

この数字が示しているのは単なる人気ではなく、日本のエンジニアコミュニティがこの発表を「ずっと待っていた」という事実である。AWSはすでに 2025 年中頃から awslabs/mcp リポジトリを通じて 30 を超える個別の MCP サーバーをプレビューとして公開してきた。DynamoDB、EKS、Lambda、Bedrock Knowledge Bases、CloudFormation、Aurora シリーズ、Neptune、Redshift、Q Business — それぞれが独立したパッケージで、独立したインストール手順を持ち、独立した認証フローを持っていた。Syoitu の記事がまとめた新しい GA 版 aws-mcp は、この 30 余りを単一のマネージドエンドポイント(https://aws-mcp.us-east-1.api.aws/mcp)の背後に統合し、認証を IAM SigV4 に一本化する。すなわち GA が意味しているのは「使ってよい」ではなく、「これ以上ほかの方法で使う必要はない」という通告に近い。

この発表が一週間前の GitHub の6日間と異なるのは、崩れた既存秩序ではなく、新たに固まりつつある秩序であるという点だ。Anthropic が 2024 年 11 月 25 日に MCP を発表したとき、このプロトコルは一社の一クライアント(Claude Desktop)においてのみ意味を持つ仕様に見えた。1 年 6 ヶ月が経った今、OpenAI は ChatGPT に MCP ホストを統合し、Microsoft は Visual Studio Code と Copilot Studio で MCP を一級市民として扱い、Google は Gemini の関数呼び出しバックエンドを MCP 互換レイヤーの上に載せた。そして 5 月 6 日、この流れの最後の欠けであった AWS がマネージドエンドポイントとして合流した。これから 1 年以内に「MCP に対応していないクラウドコンソール」は事実上存在しなくなる可能性が高い。

そうすると問いは自然に一つに収束する。Anthropic がこの標準をもはや制御できなくなったとき、その標準は何になるのか。そしてその間に、誰の IAM ポリシーが最初に壊れるのか。

6日間の年表ではなく — AWS MCPサーバーが実際に何をするか

まず、GA された AWS MCP サーバーが具体的に何を露出しているのかを正確に押さえよう。抽象的なマーケティング文句では本質が見えない。

新しいマネージドサーバーは単一のエンドポイント(https://aws-mcp.us-east-1.api.aws/mcp)の背後に七つの中核ツールを露出する。これらは二つに分けられる。一方はリソース操作系、もう一方は知識系である。

リソース操作系の中核は call_aws だ。この単一ツールが約 1 万 5 千の AWS API オペレーションを呼び出し可能な関数として露出する。つまりエージェントは ec2:DescribeInstances も、s3:PutObject も、iam:CreateRole も、bedrock:InvokeModel も、すべて同じツールの引数として呼び出す。二つ目のツール run_script はネットワーク隔離されたサンドボックスで Python/boto3 スクリプトを実行し、呼び出し元の IAM 権限をそのまま継承する。すなわち単一 API 呼び出しでは終わらないマルチステップ自動化 — ページネーション、条件分岐、結果フィルタリング — をエージェントが一度に終わらせられる。三つ目の suggest_aws_commands は自然言語を AWS CLI コマンドへ変換する。

知識系は search_documentation(公式ドキュメントへのクロス参照)、retrieve_skill(AWS の各サービスチームが直接管理するベストプラクティス SOP の取得)、そしてリージョンメタデータを扱う list_regions と get_regional_availability から成る。興味深いのは retrieve_skill だ。このツールが取得する「スキル」は、AWS の各サービスチームが自ら作成・更新する推奨手順書であり、モデルが学習データに含まれていた一年前の情報の代わりにこの SOP を優先的に参照するように仕向ける。モデル応答の正確性を、モデル学習ではなく RAG 側の契約で保証する設計である。

認証フローは決定的な差を生む。従来の awslabs/mcp プレビューサーバー群はそれぞれローカルプロセスとして動作し、~/.aws/credentials や環境変数から認証情報を読み取っていた。新しい GA 版はマネージドのリモートエンドポイントだが、独自にトークンを発行することはない。代わりに mcp-proxy-for-aws というローカルプロキシがクライアント(Claude Code、Cursor、VS Code)とリモートエンドポイントの間に挟まり、IAM SigV4 署名を毎リクエストに直接付与する。すなわち OAuth も、別途の API キーも、トークンローテーションのスケジュールも存在しない。ユーザーは単に aws sso login --profile MyAdminProfile を一度実行して SSO セッションを更新するだけでよい。

Syoitu の記事に掲載された登録コマンドは次の通りである。

aws sso login --profile MyAdminProfile

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=ap-northeast-1"
  ],
  "env": {
    "AWS_PROFILE": "MyAdminProfile",
    "AWS_REGION": "ap-northeast-1"
  }
}'

この短い登録一行でクライアント側に起きることは次の通りだ。すべての MCP ツール呼び出しは stdio で mcp-proxy-for-aws に渡され、このプロキシは SigV4 で署名した HTTPS リクエストをマネージドエンドポイントへフォワードする。応答はそのままクライアントへ戻る。トークンがクライアントメモリに留まる時間は 0 秒であり、認証情報は SDK がすでに管理していた ~/.aws/sso/cache の中に留まる。これが AWS が掲げる「zero credential exposure」の実態である。

ここまでが事実関係である。しかし同じ記事のコメント欄に、ある日本人エンジニアが残した短いコメントの方がより本質的だ。「結局AWS CLIを自然言語でラップしただけでは?」 半分は当たっている。call_aws は本質的に boto3 呼び出しの薄いラッパーである。しかし半分は外している。本当の変化はツールの数ではなく、そのツールを呼び出す主体が変わったという点にある。

本論 2 — MCP標準の1年6ヶ月: 一社の仕様からインターネット標準へ

Anthropic が MCP を発表したのは 2024 年 11 月 25 日である。当日の発表資料を読み返してみると、MCP は最初から「AI アプリケーションのための USB-C ポート」を標榜していた。標準の作り手が初めから自社製品に閉じない意志を明示していたのである。しかしその意志が実際に実現するかは、標準の採用曲線ではなく、標準ガバナンスの変換曲線によって決まる。

採用曲線から押さえよう。発表後の最初の半年間、MCP は Claude Desktop のための仕様としてしか認識されなかった。変化のシグナルは 2025 年 5 月、OpenAI が ChatGPT のツール呼び出しインタフェースを MCP と互換になる形へ再設計すると告知した時点である。同年 9 月には Microsoft が Visual Studio Code 1.93 に MCP クライアントを一級市民として統合し、2025 年 12 月には Google が Gemini API の関数呼び出しバックエンドを MCP 互換レイヤーの上に載せると発表した。この時点でクラウドメジャー三社(AWS・Azure・GCP)のうち二社がクライアント側採用を宣言し、サーバー側ではすでに awslabs/mcp が 30 余りのプレビューサーバーを公開済みであった。そして 2026 年 5 月 6 日、AWS がマネージドの GA として合流したのである。

採用曲線だけを見れば、OpenAPI が RESTful API の事実上の標準になっていった 2016〜2018 年の流れと正確に重なる。一社(Swagger Inc.、後の SmartBear)が発表した仕様が Linux Foundation 傘下の OpenAPI Initiative に移管され、移管直後に AWS、Microsoft、Google、IBM が一斉に OpenAPI を自社 API Gateway の一級入力フォーマットとして採用したことで、OpenAPI は「一社が推す仕様」から「業界がデフォルトで前提にするフォーマット」へと遷移した。MCP の 5 月 6 日は、その遷移曲線の OpenAPI 3.0 GA に相当する地点である。

しかしガバナンス曲線を見ると絵が違う。MCP の仕様は依然として modelcontextprotocol/specification リポジトリで管理されており、このリポジトリのメンテナ名簿は Anthropic 社員が多数を占める。標準変更は RFC 形式の PR として提案されるが、マージ権限は Anthropic が握っている。AWS はクライアントとサーバーを作るだけで、仕様変更に直接影響を及ぼすことはない。ただし AWS の GA 発表資料に一行、「AWS は MCP の今後の進化に積極的に参加する(AWS will actively participate in the future evolution of MCP)」という文が紛れ込んでいる。この一行が意味するのは、今後の MCP 仕様変更に関するガバナンス圧力のバランスが動き始めたというシグナルだ。

ここで興味深いのは、MCP 標準がまだ IETF や ISO のような形式的な標準化機関に委ねられていないという点である。OpenAPI が Linux Foundation に移管されたのとは異なる。Anthropic は MCP を「オープンプロトコル」と呼ぶが、そのオープン性は仕様文書が公開されているという意味にすぎず、ガバナンスの分散を保証するものではない。AWS、Microsoft、Google が内部的に必要な拡張を仕様に反映できなければ、これらの企業は結局のところ独自の互換レイヤーを作って事実上のフォークを起こす可能性がある。2010 年代初頭、SAML が OAuth 2.0 の仕様定義をめぐって一部の IDP が独自拡張を作り相互運用性を破壊した事例がその端的な先例である。

Hacker News の議論で、あるコメントが正にこの点を突いていた。「AWS が MCP を GA で出すということは、6 ヶ月以内に『AWS MCP Extensions』が出るということだ。そしてその拡張が仕様にマージされなければ、MCP は事実上二つになる(AWS shipping MCP GA means ‘AWS MCP Extensions’ lands in 6 months. If they don’t get merged upstream, MCP de facto forks)」。この悲観には一理ある。マネージドエンドポイントはそれ自体、仕様外拡張の自然な経路となる。AWS が自社 IAM と結合したカスタムメタデータフィールドをマネージドエンドポイントに追加した時、そのフィールドが標準仕様に含まれていなくても、クライアントはすでにそのフィールドに依存して動作してしまう。

標準の作り手が制御力を失う方法は二つある。一つはガバナンスを能動的に譲り渡すこと(OpenAPI の道)、もう一つは事実上のユーザーが仕様外領域で自身の拡張を固めていくこと(SAML の道)である。MCP は今、二つの道の分岐点にある。AWS の GA は、その分岐点を OpenAPI 側へ押す圧力にもなり得るし、SAML 側へ引く圧力にもなり得る。次の半年間で Anthropic がどのようなガバナンス変更を発表するかが決定的だ。

もう一つ、見落とされやすい事実がある。MCP の採用曲線が速まった最大の理由は、標準そのものの優秀さではなく、コーディングエージェント生態系の構造的圧力である。一週間前の GitHub の 6 日間の亀裂で見たように、コーディングエージェントの急増は 30 倍負荷を生み、GitHub のインフラを揺さぶった。この急増の裏側には、エージェントが呼び出さねばならないツールの急増がある。AWS、GitHub、Slack、Linear、Notion、Datadog — エージェント一人が扱う外部システムの数は急速に二桁に達し、各システムごとに別々の SDK アダプタを書くことはもはや持続可能ではない。MCP はこの適応圧力に対する最もシンプルな答えであったために、急速に採用された。すなわち、MCP の勝利は仕様の優秀さではなく、エージェント生態系の統一性に対する市場の切迫感が作ったものである。

本論 3 — セキュリティとガバナンスの次なる請求書

GA 発表資料が最も長く扱った部分は認証と権限である。AWS は新たに二つの IAM コンテキストキーを導入した。aws:ViaAWSMCPService と aws:CalledViaAWSMCP。前者は呼び出しがマネージド MCP エンドポイントを通過したことを意味し、後者は呼び出しが本来 AWS MCP のツールから発したことを意味する。この二つのキーを IAM ポリシーの Condition に組み込めば、運用者は「MCP 経路では RDS バックアップの削除を禁止する」といったポリシーをわずか数行で書ける。少なくとも理論上はそうだ。

問題は、IAM モデル自体がコーディングエージェントの呼び出しパターンのために設計されたものではないという点である。従来の IAM は人・サービス・ロールという三種類の主体を前提とし、それぞれの主体が一つのセッション内で一貫した意図のもとに行動するという仮定を敷いていた。コーディングエージェントはこの三つのいずれにもきれいに収まらない。エージェントは人の委任を受けて動作するが、その委任の範囲は自然言語で与えられる。エージェントはサービスではあるが、その行動パターンは決まった RPC ではなくモデルの即興的判断である。エージェントはロールを持てるが、一つのセッション内で複数のロールを自由に行き来する可能性がある。

この不一致は具体的な失敗モードとして現れる。最も単純なシナリオは権限エスカレーションだ。ユーザーがエージェントに「ステージング環境の EC2 インスタンスを整理してくれ」と頼んだとしよう。マネージド MCP サーバーはユーザーの SSO セッショントークンで SigV4 署名を行う。ユーザーが持つ IAM 権限が仮に ec2:* を含んでいた場合、エージェントはステージングだけでなく本番インスタンスも終了させ得る。人間の運用者であればコンソールで間違った環境をクリックしたことに即座に気づくが、エージェントは自然言語要求に対する自身の解釈に従って実行する。AWS のドキュメントが推奨する緩和策は「管理者権限ではなく読み取り中心のカスタム IAM ロールを使え(use a read-focused custom IAM role)」というものだ。しかしこの推奨はすぐに矛盾にぶつかる。エージェントが有用になるためには結局のところ書き込み権限が必要になる。

二つ目のシナリオは secret の流れである。マネージドエンドポイントはユーザーの認証情報を直接受け取らないが、エージェントが呼び出す AWS API の応答の中には secret が含まれ得る。例えば secretsmanager:GetSecretValue 呼び出しの応答には平文 secret が入っている。この応答がマネージド MCP エンドポイントを経由してクライアントへ戻るということは、secret が一時的とはいえ AWS のマネージドインフラを通過することを意味する。AWS は「応答は保存されない」と明記しているが、応答が保存されないことと、応答がどこにもログ記録されないこととは別である。CloudTrail には呼び出しが記録され、マネージドサービスの運用ログにはメタデータが残る。このメタデータが将来どのような形の侵害の入口になるかは、まだ未知の領域である。

三つ目のシナリオは MCP 自体の audit log の不在である。現行の MCP 仕様には、ツール呼び出しの結果を誰が何のために受け取ったかを記録する標準化された audit log フォーマットが存在しない。AWS は CloudTrail で呼び出し側を記録するが、モデルがその応答をどう解釈し、どのような後続呼び出しに繋げたかという因果連鎖は、モデル側のクライアントにしか残らない。Claude Code のセッションログ、Cursor のセッションキャッシュ、VS Code の拡張ログ — クライアントごとに異なるフォーマット、異なる保存期間、異なるアクセス制御を持つ。事故が起きた際、運用チームが呼び出し側 CloudTrail と応答側クライアントログを結合して因果連鎖を復元することは、現実的にはほぼ不可能に近い。

GA 時点で AWS が約束したもの — IAM SigV4 統合、新しい Condition キー、CloudTrail 記録 — は、この三つのシナリオのうち一つ目を部分的に扱うにすぎず、二つ目と三つ目は依然として未解決のままである。これが MCP が OpenAPI の道を行くか SAML の道を行くかを決めるもう一つの変数だ。認証・権限・audit というセキュリティ三軸の標準化が仕様レベルで成されなければ、各クラウドベンダーは独自拡張でこの空白を埋めるしかなく、その瞬間に事実上のフォークが始まる。

最後に一つを指摘しておこう。コーディングエージェントがクラウド API を直接呼び出すパターンが固定されると、運用チームの仕事は「人間の行動を監査すること」から「エージェントの解釈を監査すること」へ移っていく。これは単なるツールの変化ではなく職務の変化である。SRE はすでに「SLO を定義する人」から「エージェントが提案した SLO 変更を承認する人」へ変わり始めており、セキュリティエンジニアは「ポリシーを書く人」から「エージェントがポリシー違反を試みた際、それが意図された違反か誤った解釈かを判別する人」へ変わる可能性が高い。AWS の MCP GA は、この職務変化のアクセルペダルである。

結論 — 標準が去った場所に残るもの

冒頭の問いに戻ろう。Anthropic が作ったプロトコルを AWS が GA として出すことは何を意味するのか。標準が作り手の手を離れる瞬間、その標準は強くなるのか、それとも形骸化するのか。

答えは両方である。AWS の GA は MCP を事実上のクラウド標準として固めた。クラウドメジャー三社のうち二社がマネージドチャネルとして合流した以上、残る一社(Google)が同じ道を辿るのは時間の問題である。この意味で MCP は一社の仕様から業界のデフォルトへの遷移を完了した。同時に、その遷移はガバナンスの分散を伴わないまま起きた。AWS はマネージドエンドポイントを通じて仕様外拡張を自然に追加でき、その拡張が標準へ逆流しなければ、事実上のフォークはその拡張の最初のユーザーがクライアントを更新した瞬間から始まる。

102 LGTM が語っているのは、この両面を日本のエンジニアコミュニティがすでに直感的に理解しているという事実だ。彼らは awslabs/mcp の 30 個のプレビューサーバーを一つずつインストールし、それぞれの認証フローを別々に管理してきた経験があり、その苦痛を単一のマネージドエンドポイントが解決してくれるという点で GA を歓迎した。同時に、同じコミュニティのもう一方は「結局AWS CLIを自然言語でラップしただけでは?」という懐疑的なコメントを残した。この二つの反応は矛盾ではなく、同じ事実の両面である。マネージドエンドポイントは運用負荷を減らすが、それは運用負荷の一部を AWS の制御下へ移すことでもある。

次の半年の観戦ポイントは三つだ。一つ目、Anthropic が MCP のガバナンスをどのような形で分散するか。Linux Foundation 傘下の業界コンソーシアムが形成されれば OpenAPI の道が固まり、その足取りが遅れれば SAML の道が近づく。二つ目、AWS がマネージドエンドポイントにどのような仕様外拡張を加えるか。その拡張が標準 RFC として逆流すればフォークは起きないが、そうでなければクライアント互換性の最初の亀裂が始まる。三つ目、セキュリティ事故がどのような形で最初に表面化するか。権限エスカレーション、secret 漏洩、audit 連鎖の断絶 — そのいずれかがヘッドラインに乗った瞬間、MCP のセキュリティモデルは仕様レベルでの再設計圧力を受ける。

標準が去った場所には二つのものが残る。一つはその標準に依存して作られたインフラであり、もう一つはそのインフラが生み出した新しい職務である。5 月 6 日以前の AWS 運用者は「AWS API を誰が呼び出したか」を監査していた。5 月 6 日以降の AWS 運用者は「AWS API を呼び出したエージェントが、その呼び出しをどの自然言語要求から導いたか」を監査し始める。この監査対象の変化は、標準の制御権が誰にあるかという問いよりも、はるかに深いところで我々の仕事を変える。

そうすると、最後の問いはこう言い換わる。あなたが運用している IAM ポリシーは、人のために設計されているか、それともエージェントのために再設計する準備ができているか。

出典: