Model Context Protocol（MCP）の世界で、かなり実務的で、しかも地味に効くアップデートが正式版になりました。
その名も Enterprise-Managed Authorization（EMA）。ざっくり言うと、「社内のID管理基盤でMCPサーバーへのアクセスをまとめて管理できる仕組み」です。
MCPは、AIアシスタントや開発ツールが外部サービスとつながるための共通規格として広がってきました。ただ、企業で使うとなると、思った以上に面倒が多い。サーバーごとにOAuthの許可画面が出て、社員が一人ずつポチポチ承認していく。これ、個人利用ならまだしも、組織運用だとかなりしんどいです。今回のEMAは、その“しんどさ”をかなり正面から潰しにいっています。
元記事が最初に強調しているのは、従来のMCP認証は per-user auth、つまり「ユーザーごと・サーバーごとの認可」を前提にしていた、という点です。
これは発想としては自然です。OAuthは基本的に「このアプリにこのデータを使わせていいですか？」を、利用者本人の意思で確認する仕組みだからです。
でも企業では話が変わります。
たとえば、新人が入社してAIアシスタントを使い始める場面を想像するといいです。
本来なら、必要な社内ツールやデータソースに自動でつながっていてほしい。ところが現実には、Asana、Figma、Slack、社内ナレッジベース……みたいに、接続先ごとに認可作業が発生する。しかもツールが増えるほど、承認画面も増える。
これ、体験としてかなり雑です。
「AIを入れて生産性を上げよう」と言っているのに、最初の関門がひたすら認証の連打というのは、正直かなりもったいないと思います。
元記事は、この問題を次の3点に分けて説明しています。
社員はサーバーごとに手動承認が必要になるし、セキュリティチームは統一ポリシーを効かせにくい。さらに、個人アカウントと仕事用アカウントが混ざるリスクもある。ここは本当に重要です。便利さの話に見えて、実は情報漏えいの入口にもなり得るからです。
EMAの面白いところは、認可の主導権をユーザーから 組織のIdP に移す点です。
IdPは、企業が社員のログインや権限を管理する“本丸”の仕組みです。たとえば Okta のようなサービスがこれに当たります。
EMAでは、MCPホストにログインする際に、ユーザーは自分の既存の企業アカウントで認証します。その裏で、IdPが「この人はこのグループにいるから、このMCPサーバーを使ってよい」と判断し、必要なら許可、ダメなら拒否します。
しかも、記事によるとこの流れでは ID-JAG（Identity Assertion JWT Authorization Grant） という仕組みを使い、SSO中にIdPから取得した情報をもとに、MCPサーバー側の認可サーバーからアクセス・トークンを受け取る形になっています。
ここは少し専門的ですが、言いたいことはシンプルです。
「毎回、各アプリに向かって個別に『いいよ』と言わなくていい」。
これだけで運用の手間がかなり減ります。
個人的には、この設計はかなり筋がいいと思います。
なぜなら、企業システムで本当に欲しいのは“自由に許可を積み上げること”ではなく、“会社のルールに沿って勝手に適切なものがつながること”だからです。MCPがそこに寄ってきたのは、普及のうえでかなり大きい。
EMAの説明の中で、元記事は3つの効果を挙げています。
まず、authorize once, inherit everywhere。
管理者が一度サーバーを組織に対して有効化すれば、ユーザーは自分の所属グループや役割に応じて自動的に使えるようになります。これはつまり、社員側の作業をほぼ消せるということです。初日からAIツールが“ちゃんとつながっている”状態を作れるのは、体験としてかなり大きい。
次に、centralized policy and audit。
権限の判断がIdPの管理画面に集約されるので、監査ログも追いやすくなります。
企業にとってこれは地味ですが、非常に価値があります。便利なシステムほど、「誰が、いつ、何にアクセスしたのか」が見えないと怖い。EMAはその不安にちゃんと答えています。
最後が、personal/enterprise mixups の回避。
これは見落とされがちですが、かなり現実的な問題です。
仕事用ツールにうっかり個人アカウントをつないでしまう。あるいは逆に、個人の情報が業務フローに混ざる。こういう事故は、別に悪意がなくても起きます。
EMAは、対話的なアカウント選択を減らすことで、この混線を起こしにくくするわけです。セキュリティは「禁止」だけでなく、「間違えにくいUI」を作ることでも強くなる、という好例だと思います。
今回の発表は、単なる“仕様ができました”で終わっていません。
すでに実装や対応が進んでいます。
Identity provider 側では、まず Okta が対応。Okta の Cross App Access（XAA） を使って、MCPアクセスをプロビジョニングできるようになっています。
Client 側では、Anthropic が Claude 向けの共有MCPレイヤーに実装し、Claude、Claude Code、Cowork で使えるようにしています。さらに Visual Studio Code もIDE内でEMA対応を追加したとされています。
Server 側では、Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase が対応済み。
Slack なども追随中とのことです。
この「IdP・Client・Server」が同時に揃ってきているのが、かなり重要です。
規格って、1社だけが頑張っても広がりません。認証みたいな基盤機能は特にそうで、送る側、受ける側、そして管理する側が一緒に動かないと意味がない。今回の発表は、その三者が同時に前へ進んでいるのが見えるのが面白いところです。
元記事の最後は、実装者やベンダーに向けて仕様を読んでほしい、対応してほしい、という呼びかけで締められています。
つまりEMAは、単なる便利機能ではなく、MCPを企業で本格採用するための“土台”として位置づけられているわけです。
ここは、かなり本質的だと思います。
AIエージェントやAIアシスタントが社内ツールを横断して使う未来は、もう絵空事ではありません。でも、そのときに毎回OAuthの許可地獄が待っていたら、現場はすぐ疲れます。
EMAは、その疲れを減らして、しかもセキュリティと監査性を上げる。派手さはないけれど、実装されると効き目が大きいタイプの進化です。
個人的には、MCPの本当の普及はこういう「地味だけど運用を変える仕組み」がどれだけ揃うかで決まると思っています。
モデル性能が上がることももちろん大事ですが、企業で使われるかどうかは、結局こういう認証・権限・監査の話で決まることが多いです。EMAのstable化は、その現実にかなり正面から応えた一歩に見えます。
参考: Enterprise-Managed Authorization: Zero-touch OAuth for MCP
