Enterprise-Managed Authorization は「各自で OAuth 接続」から「会社の権限設計でつなぐ」へ進める
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- この発表の本質は、MCP 接続を社員一人ひとりの手作業に任せるのをやめ、会社の権限ルールでまとめて配れるようにした点だ。
- 社員ごとに一つずつ接続させる方式は、最初は楽でも、入社・異動・退職や監査の場面で『誰が何につながっているか』を追いにくくする。
- Enterprise-Managed Authorization は、その問題を個別の同意画面ではなく会社の認証基盤側で解く拡張として stable になった。
- 便利さより重要なのは、MCP 接続管理を個人作業から組織統制へ移せることだ。
何が変わったのか
原典が示している変化は、MCP authorization を個人ごとの接続成功ではなく、組織の権限配布として扱うことです。`OAuth` は外部サービスに『このアプリへここまで触ってよい』と渡す接続認可、`IdP` は会社のログインと権限をまとめる認証基盤です。EMA ではその IdP を権限判断の中心に置き、`zero-touch OAuth` によって社員ごとの consent 画面を減らしながら server access を配れます。実装上は `ID-JAG` を token 交換に使いますが、本質は略語ではなく、認可地点が per-server consent から enterprise identity policy に移ることです。
なぜ重要か
日本企業では、PoC では各自が個人 OAuth でつなぎ、本番移行時に権限回収や監査の方法がなくなるケースが多いです。MCP は接続先が増えるほど、その粗さが露出します。server access を IdP に寄せれば、退職、異動、条件付きアクセス、企業アカウント強制といった既存統制へ乗せやすくなります。remote MCP を社内標準にしたいなら、この論点を避けられません。
技術的ポイント
- standard MCP authorization は user-scoped で、server ごとの個別認可が前提になるため、enterprise では onboarding と audit の負担が重くなりやすい。
- EMA は `IdP` を権限判断の中心に置き、groups、roles、conditional access rules に基づいて server access を配る。
- `zero-touch OAuth` は認可を消す意味ではなく、認可地点を per-app consent screen から enterprise identity policy へ移すことを指す。
- フロー上は `ID-JAG` を使って SSO 中の assertion を server 側 token へ交換するが、運用上の主題は token 交換より access governance である。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| Enterprise-Managed Authorization | 企業管理型認可 | MCP 接続を個人の都度認可ではなく、会社の認証基盤と権限ルールで配る拡張。 |
| zero-touch OAuth | 手作業不要の OAuth 接続 | 社員ごとの同意画面を毎回通す代わりに、会社の policy に沿って最初から接続可否を配る考え方。 |
| identity provider | 認証基盤 / IdP | 会社のログインと権限をまとめる中心。MCP 接続を個人作業から組織統制へ寄せる要になる。 |
| conditional access | 条件付きアクセス | 端末条件や所属条件などで接続可否を変える制御。MCP 接続を既存の企業統制へ乗せる時に効く。 |
試すなら
- 今の MCP 接続を列挙し、『各自 OAuth か』『会社の IdP で回収できるか』を分ける。
- server ごとではなく、部署や職種ごとに必要な MCP access を定義し、group や role に落とし込めるか確認する。
- 個人アカウントと企業アカウントの混線が起きやすい接続先から enterprise-managed 化の対象にする。
注意点
- EMA が stable でも、全ての client、IdP、server がすぐ同じ水準で使えるわけではない。対応状況は導入前に個別確認が必要だ。
- 自動接続は便利だが、権限配布のミスがそのまま広がる危険もある。group 設計と監査手順が雑だと被害も拡大する。