AI

MCPの認証をIdP経由にして「個別OAuth野良化」を止める｜Enterprise-Managed Authorization（EMA / Okta Cross App Access）で作るAIエージェント認可の一元統制 2026/06

Shinji Saito
Shinji Saito

代表取締役社長 / 文部科学省 最高情報セキュリティアドバイザー

シンジです。AIを使うときにMCPを接続することで更に賢く便利になる反面、MCPは個人がそれぞれの認証で接続をしなければならないし、危険なMCPを組織で排除することが難しい状況です。それを解決するEMAが6/18に安定版になりました。これでMCPに世界平和が来たかと思いたいのですが、実際はAI提供ベンダーやIDaaSベンダーなどによる対応が必要で、現時点では限られたユーザーのみが「お試し」できる程度の状況です。ただし、シンジの予想では、これらが幅広く対応し、標準的に使われる未来はそう遠くないと予想しています。

この記事では、EMAについての概要、今試す方法、情シスの仕事増えるぞっていう話をします。

エグゼクティブサマリー

  • MCPの認可拡張「Enterprise-Managed Authorization（EMA）」の仕様が2026年6月18日に安定版（stable）になりました。 AIエージェントが使うMCPサーバー（＝コネクタ）へのアクセスを、各従業員の個別OAuth同意ではなく、組織のIdP（IDプロバイダ）で一元的に認可・失効できるようにするMCPの公式拡張です。
  • 技術基盤はIETF OAuthワーキンググループで標準化が進むドラフト「Identity Assertion JWT Authorization Grant（ID-JAG）」。Oktaの実装ブランド名が「Cross App Access（XAA）」です。ID-JAGはベンダー中立の仕様で、原理的にはOkta以外のIdPも実装できます。
  • 段階差に注意：「EMAという拡張仕様」はstable、各社の「実装」はベータです。AnthropicのClaude向けEMAは、Claude Team／Enterpriseプラン向けのベータとして提供開始されました。
  • Claude EMAで現在使える対応IdPはOktaのみ。Microsoft Entra ID・Google Workspaceなど主要IdPの対応は、本稿時点で公式な提供時期がアナウンスされていません。一方、ID-JAG標準自体はOkta以外にもAthenz（ベータ）・Keycloak（実装中）などが実装を進めています。
  • 即時の全社導入は難しい段階です。EMA/XAAの対応クライアントはClaude系・VS Code等に限られ（OpenAI／ChatGPTは現状対象外）、Claude側はベータ申込制、Okta側のXAAもEarly Accessで対応SaaSが限定的。
  • EMAのメリットは、入退社ライフサイクルに連動した一元的な付与・剥奪、監査証跡の集約、同意画面フィッシングの低減、個人アカウント混入の構造的防止。一方で「IdPが攻撃された場合の影響範囲（ブラストラディウス）拡大」「接続後の実行時リスク（プロンプトインジェクション等）はEMAでは解決しない」という限界も明確です。
  • 情シスの現実解は「今すぐ全面移行」ではなく、自社IdP・対象コネクタ・スコープ・監査ログ・既存OAuth連携との共存を棚卸しし、AI×主要SaaSのハイリスク連携から段階適用することです。

1. 何が起きているのか

MCP（Model Context Protocol）とは、AIエージェントが外部のツールやデータ（チケット管理、CRM、ドキュメント、データベース等）に接続するための標準プロトコルです。AIクライアント（Claudeなど）が「MCPクライアント」、接続先のSaaS側が「MCPサーバー（コネクタ）」にあたります。ClaudeやChatGPTに様々なSaaSのMCPを接続して連携利用する、みたいな使い方が主流です。

2026年6月18日、MCPの認可拡張「Enterprise-Managed Authorization（EMA）」の仕様が安定版（stable）になったと、MCPのコアメンテナであるPaul Carleton氏名義で公式ブログが発表しました。同日、Anthropicは自社のClaude向けにEMAを実装し、Oktaを最初の対応IdPとするベータ提供を開始しました（Claude Team／Enterpriseプラン向け）。導入企業としてHubSpot・Ramp・Webflowが挙がっており、Anthropicの公式ブログには「（コネクタ一式に）初日からログインだけで接続済み。2,000名の従業員にOkta経由でプロビジョニング、追加操作ゼロ」という顧客の声も掲載されています。いつもの公告です。

技術的な裏側は、IETF OAuthワーキンググループで標準化が進むドラフト「Identity Assertion JWT Authorization Grant（ID-JAG）」です。XAA/ID-JAGは2025年9月にOAuthワーキンググループに採択され、2025年11月のMCP仕様（2025-11-25版、提案番号SEP-990）に「Enterprise-Managed Authorization」として組み込まれました。Oktaはこの仕組みの実装を「Cross App Access（XAA）」という独自のブランド名で提供しています。重要なのは、XAAはあくまで一実装名で、ID-JAGはベンダー中立の標準仕様（IETFで標準化中）であるという点です。

MCP接続時の同意画面が消える仕組み（フロー）は次の通りです。

  1. ユーザーがMCPクライアント（Claude、Claude Code、Cowork、VS Code等）に、いつものSSOでログインする（IdPからID Token／SAMLアサーションを取得）
  2. MCPクライアントが、OAuth Token Exchangeを使ってIdPにID-JAG（署名付きで短命な「許可証」JWT）を要求する
  3. IdPが管理者の設定済みポリシー（どのグループがどのサーバーに到達してよいか）を評価し、通ればaudience（宛先）を限定した署名付きアサーションを発行する
  4. MCPクライアントがそのアサーションをMCPサーバーの認可サーバーに提示し、SSOのID Tokenと同じ信頼関係（同じ署名鍵）で検証され、スコープ限定のアクセストークンが発行される
  5. ユーザーにはリダイレクトも同意画面も表示されない

ローンチ時の対応状況は、IdP＝Okta、クライアント＝Claude／Claude Code／Cowork（Anthropic）とVisual Studio Code（Microsoft）、サーバー＝Asana・Atlassian・Canva・Figma・Granola・Linear・Supabase（Slackは対応進行中）です。oauth.netの実装一覧ではクライアントにWorkOS・Archestraも挙がります。一方、OpenAI（ChatGPT）はEMA/XAAの対応クライアントに含まれていません。IdPはOkta（Early Access）が先行し、Athenz（ベータ）・Keycloak（実装中）が続きます。

2. なぜ情シス・セキュリティ担当に関係するのか（何のためにやるのか）

従来のMCP認可は、消費者向けの発想で「ユーザー個人が、自分のデータに何を触れさせるかを対話的な同意で決める」モデルでした。これは企業展開ではスケールしません。公式ブログが挙げる3つの構造的課題は、そのまま情シスの痛点です。

  • 全員が、全サーバーを個別に認可しなければならない：オンボーディングのたびに、各従業員が手作業でコネクタを1つずつ承認する
  • セキュリティチームが一貫したポリシーを強制できない：アクセスは「各ユーザーが承認した範囲」になり、中央の統制も監査証跡もない
  • 業務アカウントと個人アカウントが混ざる：法人IDの利用を強制できず、業務ツールに個人アカウントを繋いでしまえる

これは新しい問題ではなく、「サービスアカウント・APIキー・OAuthアプリの野良化（NHI＝非人間IDのガバナンス）」と同じ構図がAIエージェントで再来したものです。Oktaの整理では、AIエージェントについて①どこにいるか、②何に接続できるか、③何ができるか、の3点を把握・制御できなければなりません。EMAが直接担うのは②「何に接続できるか」です。

何のためにやるのか

それは、AIエージェントのコネクタ接続を、SSO・条件付きアクセス・入退社ライフサイクルといった「既存のID統制レイヤー」に折り込み、シャドーAI／野良連携が生まれない構造にするためです。

3. 何が変わるのか：意味と効果

EMA/XAAを入れると、「誰が・どのAIで・どこに・どの権限で」触れているかが一元的に見え、止められるようになります。実務上の効果は次の通りです。

  • 一元可視化：「クライアントXがユーザーZとしてサーバーYにスコープA/B/Cで接続」をIdPがログ化・可視化。従来は各SaaSに分散・不可視だった連携を一望できる。
  • 即時失効（ワンストップ）：AIのアクセスを止めたいとき、各SaaSを個別に無効化せず、IdP一箇所で失効すれば全体に波及する。
  • 監査証跡の集約：SOC 2・HIPAA・GDPR等の監査で「どのAIがどのデータにいつアクセスしたか」を一本の証跡で示せる。
  • 同意画面フィッシング耐性：XAA環境では原則同意画面が出ないため、同意画面が出ること自体を「異常のサイン」にできる。同意操作に慣れたユーザーを狙うフィッシングへの耐性が上がる。
  • 個人／法人の分離：「このコネクタはIdP経由でしか接続させない」を強制でき、個人アカウント混入を構造的に防げる。
  • トークン短寿命化の実用化：IdPでのアクセス確認が摩擦なく行えるため、アクセストークンの寿命を短くしても利用体験を損ねず、古いトークンが残り続けるリスクを下げられる。

4. よくある誤解

  • 「EMA＝Okta専用の機能」ではない。 ID-JAGはベンダー中立の標準で、原理的にはどのIdPも実装できます（実際にOkta以外にAthenz・Keycloak等が実装中）。ただしClaude EMAで現在使える対応IdPはOktaのみで、Entra ID・Google Workspaceは公式な対応時期が未公表です。
  • 「OpenAI／ChatGPTでも同じIdP一元認可が使える」ではない。 現時点でChatGPTはEMA/XAAの対応クライアントに含まれず、そのMCP/コネクタは従来型のOAuthで個別認証します。
  • 「導入すればAIのアクセスが全部安全になる」ではない。 EMAが解決するのは「誰がどのコネクタに接続してよいか（接続時の認可）」であり、接続後にエージェントが何をするか（プロンプトインジェクションや悪性MCPサーバーによる実行時リスク）は対象外です。
  • 「EMAを入れれば社員が危険なMCPを勝手に繋ぐのを防げる」ではない。 EMAは「承認済みコネクタの認可」を統制しますが、ユーザーが別の個人コネクタ／MCPを追加すること自体はEMA単体では止まりません。その強制は別レイヤー（後述の配布統制）で行います。
  • 「同意画面が出ないと不安」は逆。 XAA環境では本来同意画面が出ないため、同意画面が表示されること自体を「要注意」のサインにできる＝同意画面フィッシングへの耐性が上がる、という設計です。

5. 【Okta管理者向け】導入のHow-to（ライセンス・提供状況と手順の勘所）

ClaudeのEMA連携は現在ベータです。実際の有効化は、Anthropicへの利用申請（後述の参加フォーム）と、Oktaの「Claude × Cross App Access（XAA）参加ガイド」（Oktaサポート、要ログイン）に沿って進めます。

ライセンス・提供状況（重要）

  • XAAはOktaのEarly Access（EA）機能です（Okta公式ドキュメントの表記）。Admin Consoleの「Settings ＞ Features ＞ Early Access」でセルフ有効化します。
  • 基盤はOkta Platform（Workforce Identity）です。
  • 利用条件は、要求側アプリと対象アプリがOIN（Okta Integration Network）にOIDCで登録され、XAAが有効化されていること、両アプリ間にOAuth関係があること、そして両アプリがOktaをIdPとしてSSOしていることです。
  • XAA固有のライセンスSKU・正式GA時期・価格は公式に公表されていません。 自社のどの契約区分でいつ使えるかは、Okta担当や代理店に要確認。
  • さらにClaudeのEMA連携を使うには、Okta側のXAAに加えてClaude Team／Enterpriseプラン＋AnthropicのEMAベータ登録が別途必要です（claude.com/form/ema-waitlist から申請）。

Okta管理コンソールでの基本ステップ（XAAの一般的な流れ）

  1. Cross App Access機能を有効化：Admin Console →「Settings ＞ Features」→「Early Access」で「Cross App Access」をオン。
  2. コネクタと要求側アプリを登録・承認：App CatalogからXAA対応の連携を追加し、クライアント（Claude）と各コネクタのManaged Connection（信頼関係）を作成する。Claude本番では、この部分がOktaの参加ガイドの手順に対応します。
  3. グループ／ロールで割り当て：どのグループ／ロールのユーザーに、どのコネクタを与えるかをOktaのアサインで定義する（コネクタを一度承認すれば、対象グループのユーザーは初回ログインで自動的に繋がる＝ゼロタッチ）。
  4. 条件付きアクセスの適用：デバイス状態・ネットワーク・MFA／ステップアップ認証など、既存の条件付きアクセスポリシーをMCP接続にも効かせる。
  5. トークン寿命・失効の設計：アクセストークン寿命を短く保ち、入退社・ロール変更時にIdPのデプロビジョニングでコネクタアクセスも同時に失効するよう連動させる（トークン寿命・ライフサイクルは接続先の認可サーバーとIdPが管理します）。
  6. 監査ログ運用：「誰が・どのAIで・どのリソースに」アクセスしたかをOktaログから追跡・モニタリングする体制を用意する。

スコープと権限の勘所

  • IdPはトークン発行前にポリシー評価を行い、(a) このクライアントはこのサーバーに接続してよいか（app-to-appのallowlist/denylist）、(b) 要求スコープは許可範囲か（最小権限）、(c) ステップアップ認証が必要か、(d) ユーザーは許可グループか、を判定します。
  • ロールベース権限（RBAC）とのきめ細かい連携はAnthropic側で「coming soon」とされており、当面はグループ／チーム単位のスコープが中心になります。
  • ID-JAG仕様はOIDCのID TokenとSAMLアサーションの双方を許容しますが、Okta実装でのSAML対応状況はバージョン依存のため、自社要件がSAML前提なら個別に確認してください。

6. 【自社製MCP】オリジナルMCPサーバーをEMA対応にしてIdP統合する

自社開発のMCPサーバー（Resource App）をEMAの統制下に置くには、認可の受け口をID-JAGに対応させ、IdP（Okta）に連携します。要点は次の3層です。

(A) MCPサーバー／認可サーバー側（仕様要件）

  • サーバーの認可サーバーでID-JAGを検証する：IdPのJWKSで署名検証し、aud（自サーバー宛先）・iss・有効期限を確認、sub／email等のclaimでアカウント連携（account linking）、scope／resource claimを自サーバーの権限にマッピングする。
  • サーバーの認可メタデータでEMA拡張を宣言し、enterprise-managedフローを要求する。
  • 任意でIdPの管理APIと統合してリソースディスクリプタを公開し、管理者がIdP側でアクセスポリシーを設定できるようにする。
  • 自前で1から実装する負担が重ければ、ID-JAG対応（または対応予定）の認可サーバーにオフロードできます（Stytch・Scalekit・Auth0〔ベータ〕・Keycloak〔実装中〕・WorkOS等）。これらは署名検証・aud／claim検証・スコープ付きトークン発行を肩代わりします。

(B) Okta側（XAA Resource Appとして登録）

  • 自サーバーをOINにOIDCで登録し、XAAを有効化（XAA Resource App）。要求側アプリ（Claude等）とのManaged Connectionを確立し、両アプリをOkta SSO配下に置く。
  • OIN掲載・統合相談はOktaのXAA窓口（xaa@okta.com）に申請します。

(C) 検証

  • xaa.dev（デモ／テストユーティリティ）や、任意のID-JAGを受け付けるサンプルMCPサーバーmotd.xaa.rocksで、発行〜検証フローを試せます。
  • これにより、自社製MCPも「他の全社アプリと同じIdP統制」に載り、付与・剥奪・監査をIdPで一元化できます。

7. 【情シス実務】すでに使っているMCP/OAuth連携をどうするか

「もう各SaaSと個別にOAuth連携している」「社員が各自でMCPを入れている」状態から、どう統制下に移すか、実務の要点です。

  1. 棚卸し（最優先）：いま社内で使われているAIクライアントと、それらが各SaaSと結んでいるOAuth連携・APIキー・サービスアカウントを洗い出す（NHIの棚卸しと同じ作業）。
  2. XAA対応コネクタはEMAへ寄せる：対象SaaSとクライアントの双方がEMA/XAA対応なら、個別OAuth同意をやめ、IdP一元認可（EMA）へ移行する計画とする。
  3. XAA非対応の既存OAuthアプリは「Brokered Consent」でブローカする：標準対応を待つ間の現実解として、Oktaは、通常クライアント⇄アプリ間で行われるOAuthフローをOkta自身が代行する方式（Brokered Consent）を提供しています。OAuthの性質上、途中の同意ステップ自体は残りますが、認可ポリシーの管理と可視性をIdP側に寄せられます。将来アプリがXAA対応した時点でスムーズに移行できる設計です。
  4. 個人利用（personal connector）は併存させる：EMAは組織が配布するコネクタを統制し、個人が自分用に追加するコネクタは併存可能です。「会社が配るもの」と「個人が足すもの」を分けて整理すると運用しやすくなります。
  5. 段階移行：全連携を一斉に切り替えず、非クリティカルなもの、あるいは「AI×機微データを扱う主要SaaS」のハイリスク連携から小さく適用し、効果と運用を確かめながら広げる。

8. 危険なMCPを勝手に繋がせない：配布統制と強制力

EMAは「承認済みコネクタを誰がどう使えるか」の認可を統制しますが、ユーザーが自分で別のMCP／コネクタを追加すること自体は、EMA単体では止まりません（Claude公式も「個人コネクタは併存可能」と明記）。しかも既定値は緩く、Claude公式ドキュメントは「既定では誰でも任意のMCPサーバーに接続できる」としています。危険なMCPの野放図な接続を防ぐ強制力は、Claude側の配布統制で別途かける必要があります。

Claude Code（開発者向け）

  • managed-mcp.jsonをMDMで配布し、固定の承認済みサーバーだけを配備（ユーザーは追加不可）、またはMCPを全面無効化できる。
  • allowedMcpServers／deniedMcpServers／allowManagedMcpServersOnly: trueで、承認カタログ（許可リスト）方式や既知の危険サーバーのブロック（拒否リスト）を強制できる。
  • プラグイン経由のみ許可（strictPluginOnlyCustomization）など、統制レベルを段階選択できる。

Claudeアプリ（claude.ai／Team・Enterprise）

  • 管理コンソールの「Organization settings ＞ Connectors」でコネクタを許可／ブロック、verified-domainコネクタを自社エンタープライズに限定（社外アカウント接続の遮断）、読取のみ／書込許可など操作範囲を制御できる。

多層防御（任意）

  • ネットワーク出口やMCPゲートウェイで、未承認のリモートMCP・stdio型MCPの利用を遮断する構成も有効です。

つまり、「EMA＝認可の一元化」＋「managed-mcp／コネクタ統制＝接続できるMCPの限定」を組み合わせて初めて、「個人が危険なMCPを自由に繋ぐ」を実務的に防げます。なお、Anthropicは掲載前にコネクタを基準で審査しますが、各MCPサーバーのセキュリティ監査・運用まで保証するものではない点にも注意が必要です。

9. どう統制するか：ガバナンス設計の型

配布＝ばらまきではなく「統制された配布」にするための設計要素です。

  • 接続ポリシー：クライアント×サーバーのallowlist/denylistで「許可した組み合わせだけ」接続させる。
  • 最小権限スコープ：読取専用／書込／管理などの粒度で、必要最小限のスコープだけ付与する（SaaS側のスコープ実装に依存）。
  • 条件付きアクセス：MFA・デバイス状態・ネットワーク・ステップアップ認証をMCP接続にも適用する。
  • グループ／ロール設計：部門・職務単位でコネクタ集合を割り当て、入退社・異動で自動的に増減する形にする。
  • トークン寿命と失効：短命トークン＋オフボーディング連動失効で、退職者のAIアクセスが古いトークンで生き残らないようにする。
  • IdP経由限定の強制：重要コネクタは「IdP経由でしか接続できない」を強制し、個人アカウント・野良連携を締め出す。
  • 監査・モニタリング：IdPログを定常監視し、想定外のクライアント×サーバー接続やスコープ逸脱を検知する。
  • 責任分界の理解：アクセス判断・スコープ・各コネクタが到達できるデータ範囲は、IdPと接続先サービスのポリシーが支配します（Anthropicはあくまで認可の中継）。この分界を踏まえて設計し、契約条件を確認します。

10. 対応方針の比較表

観点従来型（個別OAuth同意）EMA / ID-JAG（IdP一元認可）中間策（Brokered Consent・ゲートウェイ）
認可の主体ユーザー個人の同意組織のIdPポリシーIdP（Okta）がOAuthを代行・仲介
監査証跡分散・不可視IdPコンソールに集約仲介点に集約
退職時の剥奪古いトークンが残りやすいIdPのオフボーディングで失効仲介側で制御
同意画面都度表示（疲れ・フィッシング）原則なし＝耐性向上同意ステップは残るが可視化
前提クライアントとSaaSのみIdP・クライアント・SaaSの三者対応既存OAuthアプリに広く適用可
現状の対応IdP不問Claude EMAはOktaのみ（標準実装はAthenz/Keycloak等も進行）Okta（XAA非対応アプリ向け）
解決しない範囲—実行時リスク（プロンプトインジェクション等）／危険MCPの接続自体は別統制同左

11. 今から準備できること（即導入できなくても価値がある）

EMAはClaude側がベータ申込制、Okta側のXAAもEarly Accessで対応SaaS・対応IdPが限定的で、「今すぐ全社導入」できる段階ではありません。しかし“待ち”の間にやれることは多く、そのほとんどはEMAの有無に関係なく価値があります。

  1. AI連携・OAuth・APIキー（NHI）の棚卸し：最優先かつ最大の価値。EMAが来た時の移行対象がそのまま可視化され、待つ間のリスクの所在も分かる。
  2. Claude側のMCP配布統制を“今”かける：managed-mcp.jsonの許可／拒否リストや管理コンソールのコネクタ統制はEMAを待たずに即適用でき、危険なMCP接続を現時点で抑止できる（最も即効性が高い守り）。
  3. IdP（Okta）側のreadiness：XAA（EA）を検証環境で有効化し、グループ／ロール設計・条件付きアクセス・オフボーディング連動失効を先に整える。
  4. 小さくパイロット：Claude Team/Enterprise＋EMAベータを申請し、対応SaaSのうち1〜2連携でPoC。フロー・運用・監査ログの見え方を確認する。
  5. ポリシーの言語化：「誰が・どのAIで・どこに・どの権限で繋いでよいか」を文書化し、承認・例外フローを決める。
  6. 自社製MCPのID-JAG対応方針：内製MCPがあるなら、前章の方式で対応計画を持つ。

価値：EMAが正式に使えるようになった瞬間に“スイッチ”できる状態を作れること。そして待っている間も、棚卸しとClaude側の配布統制によって現に危険を減らせること——「準備＝守りの前倒し」になります。

12. 導入・見直しチェックリスト

  • 自社IdP（Okta／Entra ID／Google Workspace等）のID-JAG/XAA対応状況と時期を確認した（Claude EMAは現状Okta）
  • 利用中・展開予定のAIクライアントがEMA対応かを確認した（OpenAI／ChatGPTは現状非対応である点を踏まえた）
  • 優先して繋ぐSaaSがEMA対応か、OktaのXAA（EA）を自社契約で使えるかをOktaに確認した
  • いま使っているAI連携・OAuth・APIキー（NHI）を棚卸しした
  • Claude側のMCP配布統制（managed-mcp.jsonの許可／拒否リスト、管理コンソールのコネクタ許可／ブロック）を設定した
  • 「AI×機微データ」のハイリスク連携を先行対象として特定した（全連携を一気に移行しない）
  • グループ／ロール単位のアクセスポリシーと、最小権限スコープを設計した
  • 条件付きアクセス・MFA・デバイス状態をMCP接続にも適用できるか確認した
  • アクセストークン寿命の短縮と、オフボーディング連動の失効フローを整えた
  • 「重要コネクタはIdP経由限定」を強制できるか確認した
  • XAA非対応の既存OAuthアプリの当面策（Brokered Consent等）と将来移行計画を作った
  • 自社製MCPがある場合、ID-JAG対応（認可サーバー実装またはOIN登録・オフロード）の計画を立てた
  • IdPログでのAIアクセス監査・モニタリング体制を決めた
  • IdP侵害時の影響範囲（ブラストラディウス）と検知・失効策（ID脅威対策／Universal Logout等）を併せて設計した
  • 実行時リスク（プロンプトインジェクション・悪性MCPサーバー）への別建て対策方針を持った
  • ベータ・ライセンス条件（対象プラン・SLA・サポート）を契約面で確認した

13. 限界とリスク

  • IdPが単一障害点・攻撃集中点になる。 すべてのMCPアクセスを1つのIdPに集約すると運用はきれいになりますが、そのIdPが侵害された場合の影響範囲は確実に広がります。ID脅威検知・セッション失効（Identity Threat Protection／Universal Logout等）とセットで考える必要があります。
  • 接続後の実行時リスクは対象外。 プロンプトインジェクションや悪性MCPサーバーによる被害は、EMAでは防げません。ここは従来通り、検知・隔離・レビューなど別建ての対策が必要です。余談ですが、安全なMCPはこれですとお墨付きを出す動きは各所で進んでいるので、近い将来MCPの安全性は一定レベルで担保されるはずです。
  • 三者対応が前提で、現在は対応範囲が限定的。 IdP・クライアント・サーバーの3者が同じ拡張に対応して初めて成立します。現状クライアントはClaude系・VS Code等に限られ、OpenAI／ChatGPTは未対応、対応SaaSも限定的です。
  • きめ細かいRBAC連携・SAML対応などは発展途上。 ロールベース権限連携は「coming soon」、SAML対応状況は実装・バージョン依存です。

14. 経営層・監査部門への説明ポイント

  • これはAIの「機能追加」ではなく、AIエージェントのアクセスを既存のID統制（SSO・条件付きアクセス・入退社ライフサイクル）に統合する標準化であり、シャドーIT／野良連携の抑制策である、と位置づける。
  • 監査対応の改善：「誰が・どのAIで・どのデータに触れたか」がIdPの一元的な監査証跡として残る（SOC 2・HIPAA・GDPR等への適合を支援）。
  • リスクの正直な開示：①Claude EMAの対応IdPが現状Oktaのみ・対応クライアント／SaaSも限定的で自社が即適用できるとは限らない、②IdP集中による影響範囲の拡大、③接続後の実行時リスクは別対策が必要、の3点を「未解決リスク」として明示する。
  • 業界の標準化動向：XAA/ID-JAGはOAuthワーキンググループ採択済みで、MCPの公式拡張に組み込まれ、賛同企業も広がっています（Automation Anywhere・AWS・Boomi・Box・Glean・Google Cloud・Grammarly・Miro・Salesforce・WRITER等）。特定ベンダー依存ではなく標準への投資である、と説明できます。

15. まとめ

EMA／Cross App Access（ID-JAG）は、「AIエージェントが社内SaaSに触れるときの認可」を、各ユーザーの同意任せから組織のIdP統制へと引き戻す、AI時代のゼロトラスト認可の現実解です。ただし2026年6月時点ではClaude EMAの対応IdPがOktaに限られ、対応クライアント（OpenAIは未対応）やSaaSも限定的で、接続後の実行時リスクは別問題として残ります。情シスがいまやるべきは、AI連携・OAuth・APIキーの棚卸し、Claude側のMCP配布統制の即時適用、ハイリスク連携からの段階適用、そしてIdP集中リスクと実行時リスクへの併走対策です。「モデルを選ぶ」より前に、「AIがどこに、誰の権限で触れるか」を一元統制できる状態を作ることが、AIの全社展開を現実にします。

FAQ

Q. Enterprise-Managed Authorization（EMA）とは何ですか？

A. AIエージェントが使うMCPコネクタへのアクセスを、各ユーザーの個別OAuth同意ではなく、組織のIdPで一元的に認可・取り消しできるようにするMCPの公式拡張です。拡張仕様は2026年6月18日に安定版になりました（各社の実装はベータ段階です）。

Q. ID-JAGとXAAとEMAの関係は？

A. ID-JAG（Identity Assertion JWT Authorization Grant）がIETFで標準化中のOAuth拡張ドラフト、XAA（Cross App Access）がそのOktaブランドの実装名、EMAがそれをMCPに組み込んだ公式拡張名です。

Q. Okta以外のIdPでも使えますか？

A. ID-JAGはベンダー中立で、Okta以外にAthenz（ベータ）・Keycloak（実装中）などが実装を進めています。ただしClaudeのEMAベータで現在使える対応IdPはOktaのみで、Entra ID・Google Workspace等の対応時期は公式に未公表です。

Q. OpenAI（ChatGPT）でもEMA／Cross App Accessは使えますか？

A. 現時点で対応クライアントに含まれていません。ChatGPTのMCP／コネクタは従来型のOAuth 2.1（MCP認可仕様）で個別に認証する設計で、IdP一元認可（EMA）の対象外です。将来の対応は公式に未公表です。

Q. OktaのどのライセンスでいつからXAAを使えますか？

A. XAAはOktaのEarly Access機能で、Admin Consoleでセルフ有効化します（2025年6月発表・同年Q3にselect顧客向けEAの計画）。ただしXAA固有のライセンスSKU・正式GA時期・価格は公式に公表されておらず、自社契約での利用可否はOkta担当や代理店に要確認です。Claude連携にはClaude Team/Enterprise＋ベータ登録も別途必要です。

Q. 個人が危険なMCPを勝手に繋ぐのを防げますか？

A. EMA単体では防げません（個人コネクタは併存可・既定では任意接続可）。Claude Codeのmanaged-mcp.json（許可／拒否リスト・全面無効化）やClaudeアプリのコネクタ許可／ブロックで別途強制します。

Q. 自社で作ったMCPサーバーをEMA対応にできますか？

A. できます。認可サーバーでID-JAGを検証し、EMA拡張を宣言、OktaのOINにOIDC登録してXAAを有効化します。自前実装が重ければStytch／Auth0／Scalekit／Keycloak／WorkOS等のID-JAG対応認可サーバーにオフロードできます。

Q. どのAIクライアント・SaaSが対応していますか？

A. クライアントはClaude／Claude Code／Cowork（Anthropic）とVS Code（Microsoft）等。サーバーはAsana・Atlassian・Canva・Figma・Granola・Linear・Supabaseで、Slackは対応進行中です。

Q. EMAを入れればAI利用は安全になりますか？

A. いいえ。EMAは「誰がどのコネクタに接続してよいか」を統制しますが、接続後にエージェントが何をするか（プロンプトインジェクションや悪性MCPサーバー）は対象外で、別の対策が必要です。

Q. 退職者のAIアクセスはどう止まりますか？

A. アクセスがIdPに集約されるため、退職・ロール変更時に他の業務アプリと同じオフボーディングで失効します。トークン寿命を短くすれば残存リスクも下げられます。

CTA

AIの全社展開で最初に問われるのは、モデルの優劣ではなく「AIがどこに、誰の権限で、どこまで触れるか」を情シスが説明・統制できるかです。クラウドネイティブは、ゼロトラストとSaaSセキュリティの専門企業として、AI連携・OAuthアプリ・APIキー（NHI）の棚卸し、IdP（Okta／Entra ID等）を軸にしたアクセス統制設計、Claude側のMCP配布統制（許可／拒否リスト）、自社製MCPのID-JAG対応、条件付きアクセス・監査ログ・失効運用までを一体で支援しています。「Claudeを全社解禁したいが認可が不安」「EMA/Cross App Accessを自社IdPでどう評価すべきか」「内製MCPをIdP統制下に置きたい」といった段階からでも、エンジニアが直接ご相談に応じます。まずは自社状況の整理からお気軽にどうぞ。

お問い合わせ | 株式会社クラウドネイティブ 株式会社クラウドネイティブへのお問い合わせはこちらから。製品・サービスに関するご相談、お見積り、資料請求など、お気軽にお問い合わせください。 https://cloudnative.co.jp/contact/

参考情報

一次情報

二次情報（技術解説・補足）

タグ

この記事をシェア

Shinji Saito
Shinji Saito

代表取締役社長 / 文部科学省 最高情報セキュリティアドバイザー

株式会社クラウドネイティブ代表取締役社長であり文部科学省 最高情報セキュリティアドバイザー。日本のゼロトラスト領域の第一人者として、SaaS導入・セキュリティ対策のコンサルティングを行う。Okta、Netskope、CrowdStrikeなど30以上の製品を扱い、企業のゼロトラスト実装を支援。

関連記事

AI

【2026年5〜6月】AzureのAI（Foundry）の開発者向けアップデートを、まとめてみた

SaaS

Google Workspace 2026年下期セキュリティ設定見直しガイド｜DBSC・AI control center・監査ログ拡張を「管理コンソールの棚卸し」に落とす

その他

SaaS管理が大変になってきた会社が見直すべき5つのサイン

セキュリティ

ランサムウェアの「本当のコスト」は9か月後の決算で確定する｜アサヒ700億円規模の下方修正に学ぶ、情シスが経営に説明すべき事業インパクトと適時開示対応2026

AI

Claude Codeを企業利用するときのベストプラクティス

AI

AI時代の競争力は「モデル選び」ではない、サティアナデラ氏の「学習ループ所有」論を読み解く