当社でも、SSOに対応したMCP、OAuth認証が必要なMCP、APIキーで接続するMCPを用途に応じて使い分けています。
特に負担になったのがOAuth認証です。新しいMCPを追加するたびに、利用者が接続先ごとに認証しなければなりませんでした。
少人数で試している間は、それでも大きな問題にはなりません。しかし社内で利用者とMCPが増えると、誰がどのMCPを認証したのか把握しにくくなります。異動や退職時には、各サービスの連携を確認する必要もあります。
MCPを増やすほどOAuth認証も増える。便利なはずのMCPを社内展開した結果、私たちは「OAuth認証地獄」に直面しました。
この接続認可を社員任せにせず、企業のIdentity Provider（IdP）で一元管理するMCP拡張が、Enterprise-Managed Authorization（EMA）です。
EMAの認可フローで中核となる技術がID-JAGです。
この記事では、EMAが必要になった背景、ID-JAGとの関係、EMAだけでは解決しない権限管理について説明します。
この記事は2026年7月時点の公開仕様をもとにしています。EMA拡張はMCP公式からstableと案内されていますが、ID-JAGはIETFで標準化作業中のInternet-Draftです。今後、仕様が変更される可能性があります。
そもそも従来のOAuthは何をしているのか
一般的なOAuthの認可フローでは、ユーザーがアプリとサービスの間を移動し、同意画面でアクセスを承認します。
たとえば、あるAIクライアントからJiraへ接続する場合、ユーザーはJira側の認可画面で「このアプリへチケットの閲覧権限を与える」といった判断をします。
個人向けサービスでは、この設計は自然です。自分のデータへ誰を接続するかを、本人が決められるからです。
しかし企業利用では、次の事情が加わります。
- 利用を許可するMCPクライアントを会社として決めたい
- 部署や役割に応じて接続先を制限したい
- 個人アカウントではなく企業アカウントを必須にしたい
- 入社、異動、退職に合わせてアクセスを一元管理したい
- 監査時に接続関係を確認したい
「各ユーザーが、その都度同意する」だけでは、企業の管理ポリシーを一貫して適用しにくくなります。
ID-JAGは「この接続を企業IdPが認めた」という署名付き証明書
ID-JAG（Identity Assertion JWT Authorization Grant）は、異なる信頼ドメイン間で委任アクセスを行うための、署名付きJWTを使ったOAuthのgrantです。
難しく見えますが、役割は次の一文にまとめられます。
企業IdPが「このユーザー、このクライアント、この接続先に対するアクセスを認める」と署名付きJWTで表明する。
ID-JAGは、それ自体がMCPサーバーを操作するアクセストークンではありません。MCPサーバー側のAuthorization Serverへ提示し、そのサーバー用のアクセストークンと交換するために使います。
概念的な流れは次のとおりです。
- ユーザーが企業SSOでMCPクライアントへログインする
- MCPクライアントが企業IdPへIdentity Assertionを提示する
- 企業IdPがユーザー、クライアント、接続先、ポリシーを確認する
- 条件を満たす場合、企業IdPがID-JAGを発行する
- MCPクライアントがID-JAGを接続先のAuthorization Serverへ提示する
- Authorization Serverが署名、issuer、audience、有効期限などを検証し、アクセストークンを発行する
ユーザーを接続先の同意画面へ毎回リダイレクトする代わりに、企業IdPのポリシー判断を使えることがポイントです。
ただし、「同意画面がない＝確認なしで自由に接続できる」ではありません。判断主体がユーザー個別の同意から、管理者が設定した企業ポリシーへ移ります。
EMAはID-JAGをMCP接続へ適用する仕組み
Enterprise-Managed Authorization（EMA）は、企業IdPをMCP接続の認可判断に組み込むMCP拡張です。
MCP公式は2026年6月18日、EMA拡張をstableとして案内しました。拡張はopt-inであり、すべてのMCPクライアントやサーバーで自動的に有効になるわけではありません。クライアント、MCPサーバー側のAuthorization Server、企業IdPが、それぞれEMAのフローへ対応する必要があります。
従来方式とEMAの違いを整理すると、次のようになります。
| 観点 | ユーザーごとのOAuth認可 | EMAを使った企業管理 |
|---|---|---|
| 認可判断 | ユーザーが接続先ごとに同意 | 企業IdPがポリシーを評価 |
| 初期設定 | MCPサーバーごとに操作 | SSOと組織設定をもとに接続 |
| 管理場所 | 各サービスへ分散 | IdPを中心に管理 |
| ポリシー | ユーザー判断に依存しやすい | グループ、役割、条件付きアクセスを適用 |
| オフボーディング | 各連携の確認が必要 | IdP側のユーザー・ポリシー管理へ集約 |
EMAによって、管理者はたとえば次のようなポリシーを設計できます。
- EngineeringグループはGitHub MCPとJira MCPへ接続できる
- Financeグループだけが会計システムのMCPへ接続できる
- 管理対象端末からのアクセスだけを許可する
- 退職者や無効化されたアカウントには新しいトークンを発行しない
なお、ポリシー変更後に既発行のアクセストークンがいつ無効になるかは、トークンの有効期限、失効、イントロスペクションなど接続先Authorization Serverの実装にも依存します。「IdPでユーザーを無効化すれば、あらゆる既発行トークンが必ず瞬時に消える」とまでは考えない方が安全です。
ID-JAG、XAA、EMAは何が違うのか
この領域では、似た用語が複数登場します。
大まかには、次のように整理できます。
- ID-JAG：IETFで標準化中のOAuth grant。署名付きJWTを使った技術的な中核
- XAA（Cross App Access）：アプリ間アクセスを企業IdPで管理する考え方や実装で使われる名称
- EMA：ID-JAGを利用して、企業管理の認可をMCPへ適用する拡張
ID-JAGはMCP専用ではありません。EMAが、ID-JAGによる認可の仕組みをMCPのクライアントとサーバーの接続へ持ち込んでいます。
EMAで管理できるのは「MCPサーバーへ接続してよいか」まで
ここは特に重要です。
EMAが扱う中心は、MCPクライアントからMCPサーバーへ接続するための認可です。接続後に実行できる個別操作を、すべてEMAだけで安全に制御できるわけではありません。
たとえば、Jira MCPへ接続できるユーザーについても、次の権限は別途考える必要があります。
- チケットの閲覧はできるが、更新はできない
- 特定プロジェクトのチケットだけを操作できる
- 削除や外部送信には人間の承認を必要とする
- 個人情報を含むフィールドはAIへ返さない
これらはMCPサーバー、接続先アプリ、ゲートウェイなどで実装する認可・制御の仕事です。
また、EMAはPrompt Injection、悪意あるツール応答、過剰な権限設定、機密情報の出力といった問題を自動的に解決しません。企業でAIエージェントを運用する場合は、接続認可に加えて次の層が必要です。
- 最小権限
- ツール呼び出し単位の認可
- 重要操作前の承認
- 入出力の検証とPIIマスキング
- 操作ログと監査
- トークンの短寿命化と適切な失効設計
導入前に確認したいチェックリスト
EMAを検討するときは、仕様名だけでなく、実際の対応範囲を確認します。
- 利用するMCPクライアントはEMA拡張へ対応しているか
- MCPサーバー側のAuthorization ServerはID-JAGを検証できるか
- 企業IdPは対象クライアントと接続先をポリシー管理できるか
- issuer、audience、client ID、有効期限を厳密に検証しているか
- ユーザーのグループや役割を、接続先の権限へどう対応付けるか
- 既発行アクセストークンの有効期限と失効方法はどうなっているか
- EMAより細かいツール・データ単位の権限をどこで制御するか
- 接続と操作の監査ログをどこへ残すか
EMAはopt-inの拡張です。「MCP対応」と書かれているだけでEMAにも対応しているとは限らないため、クライアントとサーバー双方の実装状況を確認する必要があります。
まとめ
接続先のMCPサーバーが増えると、ユーザーごとのOAuth同意だけでは、企業全体の接続関係を管理しにくくなります。
- ID-JAGは、企業IdPが認めたユーザー・クライアント・接続先の関係を署名付きJWTで表すOAuth grant
- EMAは、ID-JAGを使った企業管理の認可をMCP接続へ適用する拡張
- 認可判断を企業IdPへ集約することで、SSO、グループ、役割など既存のID管理を活用できる
- EMAは接続認可の仕組みであり、ツールやデータ単位の細かな権限、Prompt Injection対策、操作承認は別途必要
ID-JAGとEMAの本質は、OAuthをなくすことではありません。
AIエージェントの接続認可をユーザー任せにせず、企業のID管理とポリシーへ戻す。
これが、MCPを個人利用から企業利用へ広げるうえで重要な変化です。
MCP接続を簡単・安全に管理する「Tumiki」
私たちRAYVENが開発するTumikiは、AIクライアントとMCPの接続を一元管理するサービスです。MCPの追加、権限管理、PIIマスキング、接続ログなどを通じて、AIエージェントの安全な業務利用を支援します。
MCP接続の管理にお困りの方は、Tumiki公式サイトをご覧ください。
参考資料
- Enterprise-Managed Authorization — Model Context Protocol
- Enterprise-Managed Authorization: Zero-touch OAuth for MCP — MCP公式ブログ
- Identity Assertion JWT Authorization Grant — IETF Datatracker
- Configure Cross App Access — Okta
- How We Brought Enterprise-Managed Authorization to Rovo MCP with XAA and ID-JAG — Atlassian
本記事は、IETFとMCPの公開仕様をもとに、ID-JAGとEMAの関係を一般向けに整理したものです。図は公開仕様を参考に筆者が作成した概念図です。