当社でも、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公式サイトをご覧ください。

参考資料

本記事は、IETFとMCPの公開仕様をもとに、ID-JAGとEMAの関係を一般向けに整理したものです。図は公開仕様を参考に筆者が作成した概念図です。