AIエージェントが社内ツールに触れるたびに、同意画面が立ちはだかる——そんな運用の壁が、仕様レベルで崩れ始めました。

2026年6月18日、Model Context Protocol（MCP）のEnterprise-Managed Authorization（EMA）拡張が安定版（stable）になりました。IT管理者がアイデンティティプロバイダー（IdP）で接続先を一括設定し、社員は通常のSSOログインだけで承認済みのMCPサーバーへアクセスできます。同意画面を1つずつ踏む必要はありません。

この記事でわかること

  • EMAが解く「従来のMCP認可」の具体的な課題
  • ID-JAGという仕組みでゼロタッチ接続が成立する理由
  • Okta・Anthropic・VS Codeを含む対応状況と導入の前提

なぜ企業導入で認可がボトルネックだったか

MCPは、AIクライアントが外部ツールやデータに安全にアクセスするためのプロトコルです。標準の認可モデルはOAuth 2.1を前提にしており、ユーザーがブラウザでログインし、各MCPサーバーごとにアクセスを承認する流れが基本です。

個人利用では自然な設計です。一方、数百人規模の企業では次の問題が重なります。

  • 入社時に社員がサーバーごとに手動承認し、オンボーディングが遅れる
  • セキュリティチームが組織全体の接続状況を一元的に把握・監査できない
  • 対話型の口座選択があると、個人アカウントと業務アカウントが混在しやすい

MCP公式ブログでも、繰り返しの同意プロンプトが企業環境での最大の痛点の一つだと明言されています。NSAも2026年5月、MCPセキュリティに関する勧告で、ITの視界外で確立されたエージェント接続がリスクになる点を指摘しました（参考）。EMAは、この「中央管理できない接続」を仕様で塞ぐ狙いがあります。

EMA安定版で何が変わったか

EMA（拡張ID: io.modelcontextprotocol/enterprise-managed-authorization）は、組織のIdPをMCPアクセスの意思決定者に据えます。管理者がポリシーを一度設定すれば、社員は業務用SSOでMCPクライアントにログインするだけで、許可されたコネクタが自動的に使える状態になります。

MCP公式ドキュメントが示す主な変化は次の3点です。

  • Authorize once, inherit everywhere: 管理者がサーバーを組織向けに有効化すると、該当グループのユーザーは個別設定なしで利用できる
  • 中央ポリシーと監査: アクセス判断がIdP管理コンソールに集約され、コネクタ横断の監査証跡を残せる
  • 個人・業務アカウントの分離: 対話型の口座選択を排除し、業務用IDでの接続を構造的に強制しやすくなる

コアメンテナーのPaul Carleton氏が2026年6月18日の安定版化を発表し、2026年3月に優先課題として挙がっていたロードマップ項目が完了したと報じられています（参考）。MCP自体は2025年12月にAgentic AI Foundationへ寄贈され、Linux Foundation傘下のプロジェクトとして運営されています。

ID-JAGが同意画面を不要にする理由

EMAの技術的な芯は、Identity Assertion JWT Authorization Grant（ID-JAG）です。IETFドラフトとして策定中の仕様で、OAuth Token Exchangeを使ってIdPから署名付きJWTを受け取り、MCPサーバーの認可サーバーとトークンを交換します。

流れを簡潔に整理すると次のとおりです。

  1. ユーザーがMCPクライアント（Claude、VS Codeなど）でSSOログインする
  2. クライアントがIdPにID-JAGを要求し、管理者が設定したグループ・ロールに基づいてポリシーが評価される
  3. IdPが署名済みJWTを発行する（通常のSSO IDトークンと同じ鍵で署名）
  4. クライアントがそのJWTをMCP認可サーバーに提示し、スコープ付きアクセストークンを受け取る

ユーザーはMCPサーバー側の同意画面へリダイレクトされません。初回ログイン時にバックグラウンドで完結します。MCPサーバーがすでにIdPを信頼していれば、追加の信頼関係構築なしにJWTを検証できます。

OktaはこのID-JAG実装をCross App Access（XAA）という名称で提供しています。XAAはOkta固有のブランド名であり、EMA自体はOktaに限定されません。ID-JAGを実装したIdPであれば、どのベンダーでも対応可能な設計です。

ローンチ時点の対応状況

MCP公式ブログが示す、安定版リリース時の対応は次のとおりです。

IdP（アイデンティティプロバイダー）

https://www.okta.com/

Oktaが最初の対応IdPです。XAA経由で、対応クライアントから対応MCPサーバーへの接続をプロビジョニングできます。Okta Identity StandardsディレクターのAaron Parecki氏は、XAAをEMAに組み込むことで「アイデンティティを中央のガバナンス基盤にできる」と述べています。他IdPの対応時期は未発表です。

クライアント

Anthropicは共有MCPレイヤーにEMAを実装済みです。Claudeの管理設定がClaude CodeやCoworkにも自動適用されます。Team・Enterpriseプラン向けにベータ提供中です。

MicrosoftはVisual Studio CodeにEMA対応を追加しました。IDE内でゼロタッチのMCPコネクタ設定が可能です。企業ポリシー経由でmcp.enterpriseManagedAuth.idpを設定する想定で、IdPのissuerやclientIdを管理できます。

MCPサーバー

Asana、Atlassian、Canva、Figma、Granola、Linear、Supabaseがローンチ時に対応しています。Slackは順次対応中です。LinearのTom Moor氏は「一度ログインするだけで全コネクタが自動設定されるのは魔法のようだ」とコメントしています。HubSpot、Ramp、Webflowなどが早期導入企業として挙げられています。

IT・セキュリティ担当者が押さえるポイント

EMA導入後、MCP接続管理は他の業務アプリと同じワークフローに収まります。IdPとMCPクライアントを接続し、グループごとに有効化するサーバーを選ぶ——この一連の作業で運用が完結します。

トークン発行がIdP経由になるため、アクセストークンの寿命を短くしても、再認証の負荷はユーザーに見えません。サイレントに再発行されます。退職時のデプロビジョニングも、IdP側で権限を外せばトークン期限以内に接続が切れます。従来のように「忘れられた個人OAuth許可」が残り続けるリスクを抑えられます。

一方、利用者個人がツール単位で接続を選ぶ自由度は下がります。制御はIT・セキュリティチームへ移り、AI自体が勝手に権限を広げるわけではありません。組織ポリシーで許可された範囲だけが付与されます。

MCPサーバー開発者向けの実装入口

自社や顧客向けにMCPサーバーを運用する開発者は、EMA対応でエンタープライズ顧客へのリーチを広げられます。

実装の出発点は次のリソースです。

サーバー側では、認可メタデータにEMA拡張を宣言し、クライアントがエンタープライズ管理フローを使うよう要求します。任意でIdP管理APIと連携し、リソース記述子を公開すれば、管理者がIdPコンソールからポリシーを設定しやすくなります。EMA Interest Groupが互換性レポートや仕様フィードバックの窓口です。

従来OAuthとEMAの違い

観点 標準MCP OAuth EMA（Enterprise-Managed Authorization）
承認の主体 各ユーザーが個別に同意 IdPの管理者ポリシーが決定
ユーザー体験 サーバーごとにリダイレクトと同意画面 SSOログイン後はバックグラウンドで接続
監査 サーバーごとに分散 IdP管理コンソールに集約
オフボーディング 接続先ごとに個別失効が必要 IdPで一括失効
向いている環境 個人・小規模チーム 企業の集中管理が必要な組織

標準OAuthは柔軟性が高く、ユーザー主導の接続に向いています。EMAはその反面、組織のガバナンス要件を満たすための拡張です。どちらか一方に置き換わる話ではなく、デプロイ環境に応じて使い分ける設計です。

企業のAIエージェント連携は「接続の標準化」へ

MCPの企業向け認可が安定版になったことで、AIツールと業務システムの接続は「個人のOAuth操作」から「IdPが束ねるインフラ」へ移りつつあります。Okta・Anthropic・VS Codeが同時に対応したのは、クライアント・IdP・サーバーの三層が揃って初めて意味を持つ仕様だからです。

Team・EnterpriseプランのClaude利用者、Oktaを使う組織、VS Codeでエージェント開発を進めるチームは、まず自社のIdPとクライアントの対応状況を確認するのが近道です。サーバー側の対応はAsanaやLinearなど主要SaaSが先行しており、Slackの追加も見込まれます。認可の摩擦が下がれば、これまでオフにしていたコネクタを本番運用に載せやすくなる——EMA安定版の実務的な価値は、そこにあります。