Anthropicは2026年8月24日、ClaudeのModel Context Protocol（MCP）コネクター向けEnterprise-Managed Authorization（EMA）を一般提供したと発表しました。これにより、コネクターの認可を従業員一人ひとりのOAuth同意に任せるのではなく、企業が既に利用しているID・アクセス管理基盤から一元的に設定できるようになります。3943

MCPは、AIアシスタントを外部ツール、業務アプリケーション、データリポジトリ、開発環境などに接続するオープン標準です。12 EMAは、こうした接続を企業の中央アクセスポリシーに沿って展開・管理しやすくするための仕組みです。

何が変わるのか

従来の導入手順は、概ね次の2段階でした。

1. 管理者が組織向けにコネクターを有効化、または承認する。
2. 各従業員が接続先サービスに個別にサインインし、そのサービスのOAuth同意フローを完了する。

EMAでは、管理者が企業のIDプロバイダー上でコネクターとアクセス方針を設定します。組織のグループや既存ポリシーによって利用権限を持つ従業員は、既存のシングルサインオン（SSO）セッションを通じて承認済みコネクターを利用できます。コネクターごとのブラウザーリダイレクトや、個別の同意画面を繰り返す必要はありません。4962

ただし、アクセス管理が無制限になるわけではありません。認可の判断を担うのは引き続き企業のIDプロバイダーです。管理者はユーザーやグループ単位で利用範囲を設定でき、同じ集中管理されたポリシーからアクセスを取り消せます。4142

IDプロバイダーを使った認可の流れ

技術的には、MCPのEnterprise-Managed Authorization拡張と、Identity Assertion JWT Authorization Grant（ID-JAG）プロファイルを利用します。簡略化すると、処理は次のように進みます。

1. 従業員が企業の既存SSOシステムにサインインする。
2. IDプロバイダーが、署名付きのJSON Web Token（JWT）形式のIdentity Assertionを発行する。
3. Claudeが、そのアサーションをMCPコネクターの認可サーバーに提示する。
4. 認可サーバーがアサーションを検証し、企業ポリシー上の利用権限を確認できれば、通常のアクセストークンを発行する。
5. Claudeがそのトークンを使って、承認済みのMCPサーバーにアクセスする。

コネクター側は、ユーザーの企業上の身元と認可コンテキストを検証できるため、従業員が接続先サービスのOAuth同意手続きをもう一度行う必要がありません。4963

Oktaは、この方式をCross App Access（XAA）として実装しています。XAAはOktaによる実装名であり、EMA自体は特定のベンダー専用のコネクター方式ではなく、IDプロバイダーを介した認可を実現するオープンなプロトコル層を目指しています。3538

Claude、Claude Code、Coworkを横断して適用

MCPプロジェクトの発表によると、Anthropicは共有MCPレイヤーにこの拡張を実装し、Claude、Claude Code、CoworkでMCPサーバーを認可できるようにしました。62チャットでのClaude利用、開発者向けワークフロー、デスクトップやエージェント指向の作業環境で、同じ認可モデルを使える構成です。

Claude Codeには、MCPの設定を管理するための別の企業向け制御もあります。Anthropicによれば、管理ポリシー設定によって、ツールの権限、ファイルアクセス、MCPサーバーの構成を強制できます。組織が管理するサーバーリストを設定することも可能です。13

つまりEMAは、IDプロバイダーとMCPコネクター間の「身元・認可の引き渡し」を担う仕組みです。一方、管理対象のClaude Code設定は、そもそもユーザーが設定できるMCPサーバーを制限する追加の統制レイヤーになります。

Anthropicのプラットフォーム文書には、長期間有効な固定APIキーの代わりに、企業のIDプロバイダーから短期間有効なOIDC認証情報を取得してワークロードを認証する方法も記載されています。これは企業IDを重視する方向性としては関連しますが、コネクター固有のEMAフローとは別の仕組みです。18

対応が確認されているコネクター

提供された資料から、Oktaのプログラムに関連して初期対応が確認できるMCPプロバイダーは次の7社です。3856

• Asana
• Atlassian
• Canva
• Figma
• Granola
• Linear
• Supabase

ただし、2026年8月24日の一般提供開始時点で、すべての対応コネクターを網羅した確定リストや、対応済みと今後追加予定のコネクターを厳密に区別した一覧は、提供資料からは確認できません。Okta以外のIDプロバイダーについても、完全な対応一覧は示されていません。導入企業は、コネクターごとの提供状況と自社IDプロバイダーとの互換性を個別に確認する必要があります。

EMAの採用余地はOktaだけに限定されません。IDプロバイダー側は必要なアサーションを発行できる必要があり、MCPコネクターの開発者側は、それを受け取り検証できる認可サーバーを実装する必要があります。Anthropicの開発者向け文書では、個別のユーザー同意なしで企業のIdentity Assertionを受け入れ、アクセストークンを返すための要件が説明されています。49

Rampについて分かっていること

Oktaは、Ramp、Webflow、HubSpotなどの共同顧客が、参加MCPプロバイダーのアプリケーションに対するClaudeのアクセス管理を目的とした初期プログラムに参加していると説明しています。38

一方、提供資料には、Rampの具体的な導入方法、展開規模、利用したコネクターの組み合わせ、測定された成果について十分な情報はありません。そのため、同社の導入状況を発表内容から推測することはできません。

なぜ企業導入で重要なのか

EMAが解消するのは、AIと業務ツールを大規模に接続する際の実務上のボトルネックです。従業員ごとにOAuthの確認画面を表示する方式では、オンボーディングの作業が増え、アクセス設定を標準化しにくくなります。従業員が手続きを完了するまで、管理者が導入状況を把握しにくいケースもあります。

IDプロバイダーを中心に据えれば、アクセス判断を組織の既存の役割やグループポリシーに合わせられます。セキュリティ上の境界も明確です。IDプロバイダーがユーザーの利用資格を判断し、MCPコネクターの認可サーバーがアサーションを検証したうえで、自身のアクセストークンを発行します。

もっとも、各MCPサーバーの安全性を評価し、最小権限のポリシーを設定する必要は残ります。AnthropicのClaude Code文書も、信頼できるMCPサーバーを利用し、管理対象またはソース管理された設定によってユーザーが追加できるサーバーを制限することを推奨しています。13

今回の変更を単純に「OAuthがなくなった」と捉えるのは正確ではありません。従業員向けの個別同意ループが、既存のSSOポリシーとMCPコネクターへのアクセスを結び付ける、企業管理の認可交換に置き換わったということです。Claude、Claude Code、Coworkにまたがって接続を展開したい企業にとって、導入と権限管理をより一貫させるための基盤になりそうです。4962

Anthropicは2026年8月24日、ClaudeのModel Context Protocol（MCP）コネクター向けEnterprise-Managed Authorization（EMA）を一般提供したと発表しました。これにより、コネクターの認可を従業員一人ひとりのOAuth同意に任せるのではなく、企業が既に利用しているID・アクセス管理基盤から一元的に設定できるようになります。3943

MCPは、AIアシスタントを外部ツール、業務アプリケーション、データリポジトリ、開発環境などに接続するオープン標準です。12 EMAは、こうした接続を企業の中央アクセスポリシーに沿って展開・管理しやすくするための仕組みです。

何が変わるのか

従来の導入手順は、概ね次の2段階でした。

1. 管理者が組織向けにコネクターを有効化、または承認する。
2. 各従業員が接続先サービスに個別にサインインし、そのサービスのOAuth同意フローを完了する。

EMAでは、管理者が企業のIDプロバイダー上でコネクターとアクセス方針を設定します。組織のグループや既存ポリシーによって利用権限を持つ従業員は、既存のシングルサインオン（SSO）セッションを通じて承認済みコネクターを利用できます。コネクターごとのブラウザーリダイレクトや、個別の同意画面を繰り返す必要はありません。4962

ただし、アクセス管理が無制限になるわけではありません。認可の判断を担うのは引き続き企業のIDプロバイダーです。管理者はユーザーやグループ単位で利用範囲を設定でき、同じ集中管理されたポリシーからアクセスを取り消せます。4142

IDプロバイダーを使った認可の流れ

技術的には、MCPのEnterprise-Managed Authorization拡張と、Identity Assertion JWT Authorization Grant（ID-JAG）プロファイルを利用します。簡略化すると、処理は次のように進みます。

1. 従業員が企業の既存SSOシステムにサインインする。
2. IDプロバイダーが、署名付きのJSON Web Token（JWT）形式のIdentity Assertionを発行する。
3. Claudeが、そのアサーションをMCPコネクターの認可サーバーに提示する。
4. 認可サーバーがアサーションを検証し、企業ポリシー上の利用権限を確認できれば、通常のアクセストークンを発行する。
5. Claudeがそのトークンを使って、承認済みのMCPサーバーにアクセスする。

コネクター側は、ユーザーの企業上の身元と認可コンテキストを検証できるため、従業員が接続先サービスのOAuth同意手続きをもう一度行う必要がありません。4963

Oktaは、この方式をCross App Access（XAA）として実装しています。XAAはOktaによる実装名であり、EMA自体は特定のベンダー専用のコネクター方式ではなく、IDプロバイダーを介した認可を実現するオープンなプロトコル層を目指しています。3538

Claude、Claude Code、Coworkを横断して適用

MCPプロジェクトの発表によると、Anthropicは共有MCPレイヤーにこの拡張を実装し、Claude、Claude Code、CoworkでMCPサーバーを認可できるようにしました。62チャットでのClaude利用、開発者向けワークフロー、デスクトップやエージェント指向の作業環境で、同じ認可モデルを使える構成です。

Claude Codeには、MCPの設定を管理するための別の企業向け制御もあります。Anthropicによれば、管理ポリシー設定によって、ツールの権限、ファイルアクセス、MCPサーバーの構成を強制できます。組織が管理するサーバーリストを設定することも可能です。13

つまりEMAは、IDプロバイダーとMCPコネクター間の「身元・認可の引き渡し」を担う仕組みです。一方、管理対象のClaude Code設定は、そもそもユーザーが設定できるMCPサーバーを制限する追加の統制レイヤーになります。

Anthropicのプラットフォーム文書には、長期間有効な固定APIキーの代わりに、企業のIDプロバイダーから短期間有効なOIDC認証情報を取得してワークロードを認証する方法も記載されています。これは企業IDを重視する方向性としては関連しますが、コネクター固有のEMAフローとは別の仕組みです。18

対応が確認されているコネクター

提供された資料から、Oktaのプログラムに関連して初期対応が確認できるMCPプロバイダーは次の7社です。3856

• Asana
• Atlassian
• Canva
• Figma
• Granola
• Linear
• Supabase

ただし、2026年8月24日の一般提供開始時点で、すべての対応コネクターを網羅した確定リストや、対応済みと今後追加予定のコネクターを厳密に区別した一覧は、提供資料からは確認できません。Okta以外のIDプロバイダーについても、完全な対応一覧は示されていません。導入企業は、コネクターごとの提供状況と自社IDプロバイダーとの互換性を個別に確認する必要があります。

EMAの採用余地はOktaだけに限定されません。IDプロバイダー側は必要なアサーションを発行できる必要があり、MCPコネクターの開発者側は、それを受け取り検証できる認可サーバーを実装する必要があります。Anthropicの開発者向け文書では、個別のユーザー同意なしで企業のIdentity Assertionを受け入れ、アクセストークンを返すための要件が説明されています。49

Rampについて分かっていること

Oktaは、Ramp、Webflow、HubSpotなどの共同顧客が、参加MCPプロバイダーのアプリケーションに対するClaudeのアクセス管理を目的とした初期プログラムに参加していると説明しています。38

一方、提供資料には、Rampの具体的な導入方法、展開規模、利用したコネクターの組み合わせ、測定された成果について十分な情報はありません。そのため、同社の導入状況を発表内容から推測することはできません。

なぜ企業導入で重要なのか

EMAが解消するのは、AIと業務ツールを大規模に接続する際の実務上のボトルネックです。従業員ごとにOAuthの確認画面を表示する方式では、オンボーディングの作業が増え、アクセス設定を標準化しにくくなります。従業員が手続きを完了するまで、管理者が導入状況を把握しにくいケースもあります。

IDプロバイダーを中心に据えれば、アクセス判断を組織の既存の役割やグループポリシーに合わせられます。セキュリティ上の境界も明確です。IDプロバイダーがユーザーの利用資格を判断し、MCPコネクターの認可サーバーがアサーションを検証したうえで、自身のアクセストークンを発行します。

もっとも、各MCPサーバーの安全性を評価し、最小権限のポリシーを設定する必要は残ります。AnthropicのClaude Code文書も、信頼できるMCPサーバーを利用し、管理対象またはソース管理された設定によってユーザーが追加できるサーバーを制限することを推奨しています。13

今回の変更を単純に「OAuthがなくなった」と捉えるのは正確ではありません。従業員向けの個別同意ループが、既存のSSOポリシーとMCPコネクターへのアクセスを結び付ける、企業管理の認可交換に置き換わったということです。Claude、Claude Code、Coworkにまたがって接続を展開したい企業にとって、導入と権限管理をより一貫させるための基盤になりそうです。4962