MCP（Model Context Protocol）をエンタープライズで本格運用しようとすると、必ずぶつかる地味な壁があります。「社員一人ひとりが、繋ぎたいMCPサーバーの数だけOAuthの同意画面を踏まないと使い始められない」 という問題です。10個のサーバーがあれば10回、部署をまたげば数十回。オンボーディングは詰まり、情シスは「誰がどのサーバーに繋いだか」を把握できず、個人アカウントと会社アカウントが混ざる——スケールするほど統制が効かなくなります。
この入口の設計を、根本から変える仕様が2026年6月に安定版（stable）になりました。Enterprise-Managed Authorization（EMA） です。本稿は、homula がエンタープライズ向けのAIエージェント・インテグレーターとして日々ぶつかっている「MCPの認可」を、EMAという新しい標準に沿って整理し直すものです。EMAが何を解決し、どう動き、そして何を解決しないのか——ここを分けて理解することが、日本企業のMCP統制設計の出発点になります。
EMAとは何か——「認可の決定権」をIdPへ寄せる
EMAは、MCPの認可（Authorization）拡張を 企業のアイデンティティプロバイダ（IdP）が一元管理できるようにする 仕様です。MCPのコアメンテナである Paul Carleton 氏が2026年6月18日に安定版化を告知しました（Model Context Protocol Blog, 2026年6月18日）。experimental（実験的）段階を越え、本番運用に耐える確定仕様 になった、という位置づけです。
発想はシンプルです。従来は「MCPサーバーごとにユーザーが同意する」構造だったものを、「管理者がIdP上でポリシーを一度定義すれば、ユーザーはSSOでログインするだけで、許可されたサーバーが自動的に接続される」 構造へ反転させます。公式ブログの表現を借りれば「一度認可すれば、あらゆる場所で継承される（Authorize once, inherit everywhere）」——管理者が組織にサーバーを有効化すれば、ユーザーは自分がすでに属するグループとロールのスコープで、それを自動的に受け取ります。
論点を分けて考えると混乱しません。認証＝そのユーザーは誰か（SSOでIdPが確認）／接続時の認可＝どのMCPサーバーに繋いでよいか（EMAがIdPに寄せる部分）／実行時の認可＝繋いだ先で、どのツールをどのパラメータで叩いてよいか（EMAの範囲外）。EMAが刷新するのは、このうち 前半2つ、すなわち「入口」です。
仕組み——ID-JAGという「引換券」で同意画面を消す
技術的な核は、ID-JAG（Identity Assertion JWT Authorization Grant） と呼ばれるトークン交換です。フローは大きく3ステップです（EMA 安定版仕様, modelcontextprotocol/ext-auth）。
- SSO認証：MCPクライアントは、ユーザーをOpenID ConnectまたはSAMLでIdPにリダイレクトし、シングルサインオンさせる。
- ID-JAGの取得：クライアントはIdPから、対象サーバー向けの引換券である ID-JAG（署名付きJWT）を受け取る。ここでIdPが「管理者の定めたポリシー（グループ・ロール・条件付きアクセス）」に照らし、そのユーザー／クライアント／サーバーの組み合わせを許可するか判断する。
- アクセストークンへの交換：クライアントはID-JAGを、MCPサーバーの認可サーバーに提示し、そのMCPサーバー宛てに用途を限定（audience-restricted）したアクセストークン を得る。
このフローの結果、ユーザーはサーバーごとの同意画面を一切踏みません。認可の判断は、その場のポップアップではなく、IdP上の管理者ポリシーへ移ります。最初のIdPとして Okta が対応し、同社の Cross App Access（XAA） を通じて接続を配布します。「一度ログインすれば、MCPコネクタが全部自動でセットアップされるのは、ちょっと魔法みたいだ」——Linear のエンジニアリング責任者 Tom Moor 氏はそうコメントしています（Model Context Protocol Blog）。
もう「実験」ではない——対応が広がりはじめている
安定版化が重要なのは、主要プレイヤーが実装に踏み切れる基準線 になるからです。現時点で、クライアント側では Anthropic（Claude）や Visual Studio Code、Microsoft が、サーバー側では Asana・Atlassian・Canva・Figma・Granola・Linear・Supabase などがEMAに対応し、Slack も対応を進めていると告知されています（InfoQ, 2026年7月）。ID基盤に Okta を使う組織であれば、対応クライアントから対応サーバーへ ゼロタッチのSSO でMCP接続をプロビジョニングできる状態が、現実になりつつあります。ツール接続が数個の実験だったうちは同意画面の連打も許容できましたが、部門横断で数十のサーバーに繋ぐ段では、認可をIdPに寄せて自動化しないと運用が回りません。EMAは、その現実にプロトコル側が追いついた仕様です。
最重要ポイント——EMAが「解かない」こと
ここが本稿でいちばん伝えたい点です。EMAは強力ですが、解決する範囲を明確に区切っています。安定版仕様は、スコープ外（Out of Scope）を次のように定めています。
- IdPの可視性は「トークン発行の判断」までに限られる。つまりIdPは「誰にどのサーバーへの入場券を出したか」は分かるが、実際にMCPで流れるトラフィック（どのツールをどう呼んだか）は監視しない。
- トークン発行以降のランタイム制御はスコープ外。入場を許した後、その中で何をするかの実行時ポリシー適用は、EMAの守備範囲ではない。
言い換えれば、EMAは 「建物の入口で、正しい社員証をかざせば入れる」ところまで を標準化します。しかし、入った先の各部屋で「この書類を持ち出してよいか」「この本番テーブルを書き換えてよいか」を判断・記録・承認する仕組みは、依然として企業側の責任 です。認証と「接続時の粗い認可」は解けても、実行時のツール単位の認可・DLP・行動監査・高リスク操作の人手承認は、EMAの外側に残る のです。
EMA導入を「MCPのセキュリティが完了した」と誤読しないこと。EMAが担うのは**入口（誰がどのサーバーに繋がるか）**であり、接続の先で何をするかの統制はゼロのまま残ります。むしろEMAで接続が滑らかに増えるぶん、「繋いだ先の制御層」の重要性は相対的に上がります。
この整理は、2026年に進んだ 「統制点はアクション（ツール呼び出し）単位へ降りる」 という潮流とセットで理解すると腑に落ちます（関連：AIエージェントの統制は『ツール単位』へ）。EMAが入口の認可を、ツール単位の承認ゲートが出口（実行時）の認可を担う——役割が違う二層 なのです。
二層で捉える、MCP統制の全体像
EMAを起点に、エンタープライズがMCPに必要とする統制を層で並べると、責任の切れ目がはっきりします。
| 層 | 問い | 担い手 | EMAの範囲 |
|---|---|---|---|
| 認証 | このユーザー／エージェントは誰か | IdPのSSO | ✅ 対象 |
| 接続時の認可 | どのMCPサーバーに繋いでよいか | IdPの管理者ポリシー（グループ・ロール） | ✅ 対象 |
| 実行時の認可 | 繋いだ先で、どのツールを・どんな値で叩いてよいか | 企業側の制御層 | ❌ 範囲外 |
| 人手承認 | この高リスクな一手を、今やってよいか | 企業側の制御層（HITL） | ❌ 範囲外 |
| 行動監査 | 実際に誰が何をしたか、後から辿れるか | 企業側の制御層（証跡） | ❌ 範囲外 |
上2層はEMAで標準化・自動化できます。しかし下3層——実行時の認可・承認・監査 は、依然として企業が自前で設計・運用しなければならない領域です。ここを空白のままEMAだけ入れると、「入口はきれいに整ったが、入った先は野放し」という、かえって危うい状態になりかねません。
homulaの観点——「入口はEMA、その先はAgens Control」
homula は、MCPを「便利なツール接続を足す」話ではなく、入口と実行時を別の層として設計する 立場でエンタープライズ導入を支援しています。EMAが標準化した入口の外側——下3層——は、まさに homula が提供する統制の領域と重なります。
- 繋ぐ先は絞って、速く用意する：Agens は MCP を活用し、200以上のツールと構築ゼロで接続 します。EMAでサーバー接続の配布が自動化されるほど、「どのツールに実行時ゲートを噛ませるか」の設計に時間を割けるようになります。接続の作り込みではなく、統制の設計 に投資できるのが要点です。
- 実行時の認可・承認・監査を一枚岩で持つ：Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供します。EMAが対象外とした「実行時の認可」「高リスク操作の人手承認」「実際の行動の証跡」を、サーバーごとにバラバラに作るのではなく、組織横断の一つの制御層 として持てます。EMAの『Authorize once』が入口の一元化なら、Agens Control は出口の一元化 です。
- 適所適ツールで実装する：n8n / Dify / LangGraph を組み合わせ、ツール単位の人手承認（HITL）や最小権限を、業務の重要度に応じて作り分けます。低リスクの参照系は止めずに走らせ、本番書き込みや外部送信にだけゲートを噛ませる——強弱のある統制を実装します。
- 入口と出口の要件を最初に定義する：AIエージェント・ブートキャンプ では、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日 で完結します。このとき「どのサーバーを誰に開放するか（入口＝EMA相当）」と「繋いだ先の何を承認・監査対象にするか（出口）」を、最初の要件 として並べて置くことが、後戻りを防ぎます。
順序が肝心です。EMAで接続を先に滑らかにしてから実行時統制を後付けすると、承認も監査も現場の回避で形骸化します。入口の自動化と、その先の制御層を、同じ設計の中で並走させる——これが、処理時間の大幅削減のような成果を全社規模で安全に取りにいく現実的な道筋です。
まとめ——EMAは「入口の標準化」、統制は入口で終わらない
EMAの安定版化は、MCPが企業インフラとして成熟した節目です。個々のサーバーへのOAuth同意の連打は過去のものになり、「どのサーバーに誰が繋がるか」の決定はIdPへ一元化 されます。オンボーディングは速く、接続の可視性は上がり、個人・法人アカウントの混在も抑えられる——歓迎すべき前進です。
しかし仕様自身が明言するとおり、EMAは 入口までを担い、接続の先で何をするかは監視しません。認証と接続時の認可は解けても、実行時の認可・人手承認・行動監査は企業の責任として残る。むしろEMAで接続が増えるほど、この「繋いだ先の制御層」を先に設計しておくことの価値が上がります。
日本企業がいま準備すべきは、EMA対応の有無だけでなく、入口（IdP管理の接続）と出口（実行時の統制）を二層で設計すること です。入口を標準に任せ、出口を自社の制御層で締める——この二層が揃って初めて、MCPは「実験」から「全社で安心して使えるインフラ」へと変わります。
MCPの入口はEMAへ、その先の承認・監査・権限は自社の制御層へ。homula は、MCP接続の統制設計を、業務棚卸しからROI試算まで一気通貫で支援します。