「つなぐ」の最後の難所、認可が動いた
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。MCP（Model Context Protocol）の導入支援で繰り返しぶつかってきた壁が、**「つなぐところまでは進むが、認証・認可・監査の運用設計で止まる」**という現実でした。
その最後の難所のひとつが、2026年6月18日に大きく動きました。MCPの**「企業が管理する認可」＝Enterprise-Managed Authorization（EMA）が、拡張仕様として安定（stable）ステータス**に到達したのです（Model Context Protocol Blog、The New Stack）。ひとことで言えば、社員一人ひとりがMCPサーバーごとにOAuthの同意画面を踏む運用をやめ、組織のIdP（IDプロバイダ）から接続を一括で配る仕組みです。
以前の記事「MCPの2026年進化——ステートレス化とエンタープライズ対応」で、私たちはロードマップが掲げた「静的シークレットから離れ、SSO統合フローへ向かう“舗装された道”」を紹介しました。今回はその舗装が、実際に踏める道として実装・安定化したという続報です。本記事では、何が変わったのか・どう動くのか・企業が今すぐ整えるべきことを整理します。
前提整理：MCPはAIエージェントと外部ツール／データを標準化された方法でつなぐオープンプロトコルです。EMAは「認証（誰か）」と「接続の配布・ポリシー適用」を企業のIDレイヤーに寄せる拡張で、コア仕様の置き換えではなくオプトインの拡張として提供されます。
何が変わったのか：個別OAuthから「IdPが配る」へ
これまでの標準的なMCP認可では、社員が使うMCPサーバーごとに個別にOAuthで認証し、同意画面を承認する必要がありました。サーバーが10個あれば10回。新入社員のオンボーディングでは、本人が一つずつ繋ぎ込むしかなく、しかもセキュリティ部門には「全社で一貫したアクセスポリシーを強制する手段」も「横断的な監査証跡」もありませんでした（The New Stack）。
EMAはこの構図を反転させます。組織のIdPが、MCPサーバーへのアクセス可否を決める権威者になり、管理者が一度ポリシーを定義すれば、ユーザーは普段どおりSSOでログインするだけで必要なMCPサーバーが初回ログイン時に接続済みになる（ゼロタッチ）——個別のOAuth同意は不要、という設計です（Model Context Protocol Blog、Claude）。
| 従来（個別OAuth） | EMA（企業管理の認可） | |
|---|---|---|
| 接続の付与 | 社員がサーバーごとに同意画面を承認 | IdPから初回ログイン時に自動配布（ゼロタッチ） |
| ポリシー | クライアントごとにバラバラ | IdPでグループ・ロール・条件付きアクセスにより一元適用 |
| 退職・異動 | 各サービスで個別に剥がす | IdPの権限変更で一括反映 |
| 監査 | サーバーごとに分散・標準なし | IdP管理コンソールに横断の証跡が残る |
要点は、「誰が・どのMCPサーバーに繋いでよいか」の判断を、ツール側の同意画面から、企業がすでに運用しているIDレイヤーへ移したことです。SaaSのアクセス管理で当たり前にやってきたことを、エージェントのツール接続にも適用できるようになった、と捉えると分かりやすいでしょう。
仕組み：ID-JAG で同意画面が消える
技術的な核は、ID-JAG（Identity Assertion JWT Authorization Grant）と呼ばれる仕組みです。ユーザーがMCPクライアント（Claude、VS Code、その他EMA対応アプリ）にSSOでログインすると、クライアントはOAuth Token Exchangeを使ってIdPに「本人性を証明する署名付きアサーション（ID-JAG）」を要求します。IdPは管理者が設定したポリシーを適用したうえでアサーションを発行し、MCPサーバーは通常のSSOと同じ信頼関係でそれを検証し、スコープを絞ったアクセストークンを発行します（Model Context Protocol Blog）。
従来: ユーザー → MCPサーバーごとにOAuth同意画面 → 個別トークン
EMA : ユーザー → 企業SSO(IdP) → ID-JAG(署名付きアサーション)
→ MCPサーバーが検証 → スコープ付きトークン
└ ポリシー判定・付与・失効・監査はIdP側で一元化
ユーザー操作は不要、同意画面も出ません。IdPはグループ所属・ロール・条件付きアクセスルールに基づいてアクセスを許可／拒否でき、すべての判断がIdPの管理コンソールに記録されるため、他の全社アクセスと同じガバナンス・コンプライアンス報告の対象になります（Model Context Protocol Blog）。この仕様は標準化プロセス上は**SEP-646（Enterprise-Managed Authorization Profile for MCP）**として議論されてきたものです。
実務的な含意：オンボーディングは「初回ログインで必要なツールが揃う」状態に、オフボーディングは「IdPで権限を外せば全MCP接続が一括で切れる」状態になります。退職者のトークンがツール側に残り続ける——という、エージェント時代に膨らみがちなリスクを構造的に減らせます。
なぜエンタープライズに効くのか：3つの実務インパクト
EMAが効くのは、エージェントが「個人の便利ツール」から「全社で動く業務基盤」へ広がる局面です。
- プロビジョニングの一元化：誰がどのツールに繋ぐかを情シスがIdPで配れる。社員の自己流接続（シャドー化）を抑えつつ、立ち上げは速くなる。
- ポリシーの強制：「経理グループは会計系MCPのみ」「未承認デバイスからは不可」といった条件付きアクセスを、エージェント接続にも適用できる。
- 監査の横断化：「誰が・いつ・どのMCPサーバーに・どの権限で」接続したかが、IdPの一本の証跡に集約される。SIEMやコンプライアンス報告に素直に乗る。
これは、私たちが現場で「MCPは認証・監査・スケールで止まる」と言い続けてきた壁のうち、認証・接続配布・監査の三つに直接効く変化です。標準が「企業のIDレイヤーに乗る」方向へ着実に進んでいることの、具体的な証拠と言えます。
対応状況と、まだ埋まっていない穴
過度な期待は禁物です。対応状況と限界も正確に押さえておきましょう。
対応の広がり：拡張の採用はAnthropic・Microsoft・Oktaが牽引し、最初の対応IdPはOktaです。クライアント側ではClaude（Claude／Claude Code／Cowork）とVS Codeが対応し、MCPサーバー側ではAsana・Atlassian・Canva・Figma・Granola・Linear・Supabaseなどが立ち上げ時点で対応、Slackも続くとされています（The New Stack、Claude）。AnthropicのClaude向け実装は、現時点ではTeam／Enterpriseプラン向けのベータ段階です。
注意点：（1）対応IdP・対応サーバーはまだ限定的で、自社の主要ツールが揃うかは個別確認が必要。（2）EMAが扱うのは主に「誰が接続してよいか（認証・接続配布）」であり、「そのツールでエージェントが何をしてよいか（操作レベルの認可・承認）」は別レイヤーの設計が要ります。たとえば「読み取りは自動、書き込み・送金・外部送信は人間承認」といった統制は、EMAだけでは完結しません。
この「接続の認可」と「操作の認可」の切り分けこそ、本番設計の肝です。EMAは前者を標準化してくれますが、後者——承認フロー・DLP・操作の監査——は企業側で設計し続ける必要があります。
homulaの観点：接続はEMA、操作はAgens Controlで締める
ここまでの変化は、homulaの支援領域そのものです。整理すると、2026年のMCPは**「つなぐ」を企業のIDレイヤーに寄せて簡単にしつつ、「安全に動かす」責任を企業側のガバナンス基盤に集約していく**方向にあります。
homulaのAgensは、MCPを活用したエンタープライズ向け統合プラットフォームとして、200以上のツールと構築ゼロで接続します。EMAのように「接続の付与・剥奪をIdPで一元管理する」世界では、エージェント側から見た接続点を共通化しておく価値がさらに上がります。クライアントごとに連携を積み増す保守負債を避け、IdP起点の統制と素直にかみ合わせられるからです。
そして、EMAが埋めない**「操作レベルの認可」に直接効くのがAgens Controlです。承認フロー・DLP・5年分の監査ログ・RBACをセットで提供し、「誰が・何に・どの権限で・何をしたか」を横断的に追える状態をつくります。EMAで接続の入口をIdPに集約し、Agens Controlで操作の出口**を承認・監査で締める——この二段構えが、エージェントを全社展開する際の現実解です。
導入の順序としては、(1) 1業務でMCP接続をPoC → (2) 接続をIdP（EMA対応が進めばEMA）で配り、操作の承認・監査の境界をAgens Controlで設計 → (3) 横展開、が無理のない道筋です。homulaのAIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で行い、この最初の一歩を素早く形にします。
まとめ
2026年6月18日、MCPに企業が管理する認可（EMA）が安定化し、エージェントのツール接続が「社員が個別に同意画面を踏む」世界から、「IdPがポリシーに従ってゼロタッチで配る」世界へと動き始めました。中核にあるのはID-JAGによる静かなトークン交換で、これにより接続の付与・剥奪・ポリシー・監査をIDレイヤーに一元化できます。
ただし、対応IdP・サーバーはまだ限定的で、しかもEMAが標準化するのは主に「接続の認可」です。エージェントがそのツールで何をしてよいかという操作レベルの統制は、引き続き企業側で設計しなければなりません。標準が前進したいま問われるのは、接続の入口（EMA）と操作の出口（承認・監査）を、どこで・誰が引くかという設計です。
エージェント接続のガバナンスは、「繋げるか」より「全社で安全に配り、操作を統制し、監査できるか」へと焦点が移りました。自社のどの業務からMCPを本番に乗せ、接続と操作の境界をどこで引くか——標準の前進を活かす設計を、早めに整理することが導入の成否を分けます。