Anthropic、ClaudeがMCPプラグイン向けにIDアサーションを発行可能に
Claudeは現在、第三者サービスに対して従業員のIDを保証できるようになり、Oktaなどの互換性のあるエンタープライズIDプロバイダーの必要性を回避できます。
英語の原文から自動翻訳されました。
Anthropicは、Claudeが職場用プラグイン向けのID発行元として機能できるようにする新しい認可機能を導入しました。2026年11月4日からTeamおよびEnterprise顧客向けにベータ版で利用可能となったこのアップデートにより、個別のサインインや特定のIDプロバイダーのサポートなしに、対応サービスへの自動接続が可能になります。
何が起きたのか
以前は、Notion、Figma、Supabaseなどの職場ツールにClaudeを接続する場合、従業員が各サービスごとに個別に認証を行う必要がありました。この煩雑さは、6月に登場したModel Context Protocol(MCP)用のEnterprise-Managed Authorization(EMA)拡張機能への依存によってさらに悪化していました。EMAによりIDプロバイダーを通じた中央管理が可能になりましたが、リリース時点で対応していたのはOktaのみであり、多くの組織ではこれらの接続を自動化できませんでした。
このギャップを解消するため、AnthropicはClaude自体が署名付きIDアサーションを発行できることを発表しました。これらのアサーションにより、参加しているMCPサービスは、従業員をその組織のメンバーとして直接認識できるようになります。Anthropicでアプリケーション部門を率いるBoris Cherny氏は、ユーザー体験の向上を強調し、会社用プラグインに一つずつサインインするのは面倒であること、そして自動接続がこのペインポイント(課題)を解決することを指摘しました。
管理者は、有効にするサービスを設定し、従業員の役割に基づいてアクセスを定義できます。例えば、一般的な生産性ツールは全スタッフに開放される一方、機密性の高いデータベースは特定のチームに限定されます。対象者がプラグインにアクセスすると、Claudeは署名付きアサーションをサービスに送信し、サービスはそれを受けてアクセストークンを発行します。このプロセスではトークンの更新も自動的に処理されるため、繰り返しの認可プロンプトが削減されます。
仕組み
このメカニズムは、Claudeが完全なIDプロバイダーではなく、信頼できる発行元として機能することに依存しています。ユーザーが対応サービスへの接続を試みると、Claudeはユーザーの組織メンバーシップを確認する署名付きアサーションを生成します。第三者サービスは、Anthropicから提供された登録済み発行元URLに対してこのアサーションを検証します。検証が成功すれば、サービスは独自の内部権限ルールに基づいてアクセスを許可します。
このアプローチにより、プラグイン接続と基盤となるエンタープライズIDインフラストラクチャが分離されます。Supabaseのようなサービスはこの機能を統合しており、主要なIDプロバイダーがEMA拡張機能に対応していない場合でも、顧客がClaudeを認証に使用できるようにしています。ただし、サービス側でも独自のアクセス制御が適用されるため、従業員はターゲットアプリケーション内で対応するアカウントと権限を持っている必要があります。
セキュリティ責任は共有されます。Claudeが組織メンバーシップを検証する一方で、接続されたサービスが実際のデータアクセスを管理します。管理者は、退職した従業員をClaudeと個々のサービスの両方から削除する必要があります。企業IDプロバイダーだけでアクセスを取り消しても、Claudeが発行したアサーションは無効化されないためです。
主要な詳細
- この機能は現在、Anthropic TeamおよびEnterprise顧客向けにベータ版として提供されています。
- リリース時点で14のサービスが自動接続に対応しており、Amplitude、Apollo.io、Atlassian、Datadog、Dropbox、Figma、Granola、HubSpot、Linear、Mixpanel、Notion、PagerDuty、Semrush、Supabaseが含まれます。
- Claudeは署名付きIDアサーションを発行し、参加しているMCPサービスが従業員のステータスを検証するために使用します。
- 管理者は、有効にするサービスを制御し、アクセスを特定の従業員ロールにマッピングします。
- システムはトークンリフレッシュを自動的に処理するため、繰り返しの手動再認可が必要なくなります。
- アクセス取り消しには、企業IDプロバイダーだけでなく、Claudeとターゲットサービスの両方からユーザーを削除する必要があります。
なぜ重要なのか
ソフトウェアエンジニアや技術リードにとって、この変化はエージェント型ワークフローの管理に伴う運用オーバーヘッドを軽減します。Oktaのような特定のIDプロバイダーへの依存を排除することで、組織は既存のITインフラストラクチャに関係なく、MCPベースのプラグインをより迅速に採用できます。これは、あまり一般的でないカスタムIDソリューションを使用している企業にとっても、高度なAI統合へのアクセスを民主化するものです。
この変更は、開発者がMCPサーバーを構築・保護する方法にも影響を与えます。Claude発行のアサーションをサポートするには、これらの特定の署名付きトークンの検証ロジックを実装する必要があります。しかし、ユーザーオンボーディングフローを大幅に簡素化するため、社内ツールの採用率向上につながる可能性があります。開発者は権限モデリングについて警戒を怠らず、自動接続の利便性がアプリケーション内の必要なロールベースアクセス制御を迂回しないようにする必要があります。
実施できること
- サポートされている14のサービスのリストを確認し、チームにとって即時の統合機会を特定してください。
- MCPサーバーを構築している場合は、Claude発行の署名付きIDアサーションの検証サポートを実装してください。
- Claudeでロールベースのアクセスポリシーを設定し、機密性の高いプラグイン接続を承認された人員のみに制限してください。
- 現在のオフボーディング手順を監査し、ユーザーがClaudeと個々のサービスの両方から削除されることを確認してください。
- NotionやLinearなどの非クリティカルなツールで自動接続機能をテストし、ユーザー体験を評価してください。
- より多くのサービスが自動接続エコシステムに参加するにつれ、Anthropicのドキュメントの更新を監視してください。



