ワンログインで全アプリを支配：MCP の跨アプリアクセスを実現、WorkOS の Garrett Galow氏

ワンログインで全アプリを支配：MCP の「承認疲れ」とセキュリティリスクを解決する新規格 XAA

AI エージェントの企業導入において、最大の障壁となっているのが「ユーザーが毎回表示される承認画面への疲弊」と「IT 部門によるアクセス管理の不可視化」です。WorkOS の Garrett Galow 氏は、この課題を解決する新たなアプローチとして「Cross-App Access（XAA）」を提案し、MCP（Model Context Protocol）エコシステムの成熟を加速させる基盤技術としての重要性を説きました。

MCP が招く「承認疲れ」とセキュリティの隙間

現在、MCP サーバーを利用する際、開発者は Cursor や Claude などの AI クライアントから Figma、Notion、GitHub といった各ツールへの接続を試みるたびに、個別の OAuth 承認画面が表示されます。 Garrett 氏はこの状況を「承認画面の上に承認画面が重なった状態」と表現し、ユーザー体験を著しく損なう問題として指摘しました。

「MCP サーバーを使いたいたびに、小さな同意画面が表示され、『了解』をクリックしてリダイレクトされる。これを各ツールで実行する必要があり、正直かなり面倒です」

この非効率性は単なる手間話ではありません。MCP が OAuth プロトコルを採用している背景には、「システム同士が互いを信頼していない」という前提があります。そのため、AI クライアント（例：Cursor）がリソース（例：Figma）にアクセスするたびに、ユーザー本人が「Cursor に Figma へのアクセスを許可します」と宣言する必要があります。

しかし、企業環境ではすでに「シングルサインオン（SSO）」が標準化されています。Okta や Microsoft Entra ID を通じて一度ログインすれば、社内アプリはすべて利用可能になるはずです。MCP の現状の仕組みはこの SSO モデルを無視しており、「同じ人物」として認識する手段がないため、毎回手動での承認フローを繰り返させます。

さらに深刻なのはセキュリティリスクです。IT 部門にとって、MCP を介した接続先は「可視化」されていません。理論上、ユーザーが任意の MCP クライアント（例：DeepSeek や非公式ツール）を使用して、機密システムへのアクセス権限を付与できてしまいます。

「IT チームが使用を望まないツールでも利用でき、これらの機密システムへのアクセス権限が付与されてしまうことになります」

実際、npm パッケージのセキュリティインシデント（Axios 関連）のような事例で、ローカル環境のコンポーネントが乗っ取られた際、IT 部門はネットワークを切断して Okta のセッションを無効化しました。しかし、MCP を介した接続では、IDP（Identity Provider）に依存しない API キーやトークンが残存しており、アクセス権限の剥奪が即座に行われない可能性があります。

「会社を去った際やセッションが失効しても、アクセストークンやリフレッシュトークンが残っており、数日〜数ヶ月間、サービスへの継続的なアクセスが可能になるリスクがあります」

XAA（Cross-App Access）による自動連携の実現

この課題に対する WorkOS が提案する解決策が「XAA（Cross-App Access）」です。これは IDP（Okta など）を仲介役として機能させ、ユーザーの SSO 認証後にバックグラウンドで自動的にトークンを発行する仕組みです。

従来のフローでは、AI クライアントとリソースアプリが直接信頼関係を築く必要がありましたが、XAA では「IDP がアプリケーション間の信頼プロバイダー」となります。例えば、Cursor と Figma の両方がすでに Okta と信頼関係を持っている場合、Okta は「Garrett 氏が両方のアプリのメンバーであること」を確認できます。

この仕組みにより、ユーザーは手動で承認画面をクリックする必要がなくなります。 Garrett 氏のデモでは、Claude を起動し MCP サーバーを確認すると、Figma が自動的に接続されている様子が示されました。

「何もクリックしませんでした。同意画面を見る必要もありませんでした。Figma は自動的に接続されました」

裏側で動く「ID JAG」フローとセキュリティ強化の仕組み

この自動連携が実現する背景には、ID JAG（Identity JWT Authorization Grant） という仕様が利用されています。これは IDP が発行するトークンを用いて、サービス間でアクセスを管理するためのプロトコルです。

具体的な動作フローは以下の通りです。

1. ユーザーログイン: ユーザーが SSO を経由して IDP（Okta）にログインし、ID トークンとリフレッシュトークンを取得します。これは初回設定時や一定期間ごと（例：1 日 1 回など）のみで十分です。
2. ID JAG リクエスト: AI クライアント（Claude/Cloud Code）が IDP に「Figma で使える ID JAG トークンをください」と要求します。これには、どのリソースにアクセスしたいかという情報も含まれます。
3. ポリシー検証とトークン発行: IDP は「Cursor が Figma へのアクセス権限を持つか」「Garrett 氏が両方のアプリのメンバーか」を検証し、許可されれば ID JAG トークンを返します。このプロセスはユーザーには不可視です。
4. リソース認証: AI クライアントが取得した ID JAG トークンを Figma の認証サーバーに送信し、検証を完了させます。その後、通常の MCP フローとしてアクセストークンが発行され、通信が可能になります。

この仕組みの最大の利点は、セキュリティ体制の強化にあります。発行されるアクセストークンは非常に短命（例：5 分）に設定されており、SSO セッションが有効な限り自動的に更新されます。もしユーザーの権限が削除された場合や、Okta のセッションがロックされた場合は、ID JAG トークンの発行が拒否され、即座に MCP サーバーへのアクセスも停止します。

「トークンが期限切れになれば、再度ログインできず、その MCP サーバーへの再接続も不可能になります」

実装の課題と標準化への道

XAA の導入には、IT 部門と開発者の双方でいくつかの準備が必要です。IT 管理者は、Okta や Microsoft Entra ID などの IDP 上で「どのアプリが他のアプリへのアクセス権限を持つか」というポリシーを設定するだけで済みます。

「すでに Cloud Code や Cursor の Okta アプリケーションが作成されており、Figma の SSO も設定済みのはずです。新しい管理ポータルで『Cursor が Figma へのアクセスを要求できる』と指定するだけです」

開発者側では、XAA に互換性のある SSO 接続（ID JAG フローのサポート）が必要です。現時点では Okta が対応済みですが、Microsoft Entra ID など他のプロバイダーや、MCP クライアント側の実装状況にはばらつきがあります。

「XA サポートは比較的新しい機能です。Okta はサポートしていますが、Microsoft のような業界パートナーとも協力し、同様のサポートを進めています」

まとめ

XAA（Cross-App Access）は、AI エージェントの企業導入における「ユーザー体験の悪化」と「セキュリティ管理の難しさ」という二大課題を同時に解決する鍵となります。承認画面への依存から解放され、IT 部門がアクセス権限を一元的かつ即時に管理できる環境は、MCP エコシステムの成熟と、大規模組織における AI ツールの安全なガバナンスにとって不可欠な基盤技術です。