🧠 AI プロダクト動向

MCPサーバーは2025年6月の仕様更新で「OAuth Authorization Serverではなく Resource Server」と明確化された。この結果、権限チェックの単位はサーバー全体ではなく個々のツールに移った。画像生成ツールが呼び出し時にimage_generationスコープをセッションに対して照会し、なければ拒否する、という実装がWorkOSの解説記事でリファレンスパターンとして示されている。

なぜサーバー単位では不十分になったのか。1つのMCPサーバーが提供するツール数はリリースのたびに増え、「検索はできるが送金はできない」のような粒度の権限を、サーバー単位のOAuthスコープだけでは表現できなくなったためだ。CloudflareのAgents SDKはWorkOS・Stytch・Auth0の3プロバイダそれぞれと統合し、同じサーバー内で「addツールは全ユーザーに公開、image_generationツールは権限を持つユーザーのみ」という条件付き公開を標準パターンとして提示している。

MCPエージェントは事前にどのツールを使うか人間が決めるのではなく、実行時にサーバーの提供するツール一覧を発見して呼び出す。この動的発見に対応するため、Dynamic Client Registration（DCR）でクライアント（エージェント）自身がサーバーへの登録とリダイレクトURIの申告を自律的に行う設計が広がった。StytchのConnected Appsはこの自己登録するクライアントを追跡し、権限ごとの同意画面でユーザーに「このエージェントが要求している権限」を提示する。

ただしDCRは登録済みクライアントのなりすましや、ユーザーが事前承認していない権限を実行時に要求されるリスクを伴う。Auth0はGA版のAuth for MCPでDCRの代わりにClient ID Metadata Document（CIMD）によるクライアント登録を採用し、あわせてdownstream API呼び出し用のOn-Behalf-Of（OBO）トークン交換を用意した。エージェントの自律的な発見と、なりすまし対策のバランスをどう取るかが実装ごとに割れている。

2026年6月18日、MCPの拡張仕様Enterprise-Managed Authorization（EMA）が安定版になった。ユーザーがIdP経由でログインすると、MCPクライアントがIdPに署名付きのアイデンティティ表明JWTを要求し、IdPが管理者設定のポリシーを適用してこのJWTを発行、MCPサーバーは既存のSSO信頼関係と同じ仕組みでこれを検証してスコープ済みアクセストークンを発行する。ユーザー操作も同意画面も一切発生しない。

これは前段の「ツールごとに同意を取る」設計とは逆方向で、権限判断をエンドユーザーの同意からIdP管理者の事前ポリシーへ完全に移す発想だ。ローンチ時点の対応IdPはOktaのみで、Asana・Atlassian・Canva・Figma・Granola・Linear・Supabaseがサーバー側で対応、クライアント側はAnthropic（Claude・Claude Code・Cowork）とMicrosoft（VS Code）が対応した。IdPが単一障害点かつ単一の信頼の起点になる設計であり、対応IdPを増やせるかが普及の鍵になる。