MCP接続の認可が『組織のIdP』に移った——一人ずつOAuthを卒業する企業の設計

エンタープライズでAIエージェントを本気で使い始めると、必ずぶつかる地味な壁がある。**「誰が、どのツールに、どうやって繋ぐのか」**の認可だ。MCP（Model Context Protocol）が社内外のツール接続の事実上の標準になった一方で、その入り口は長らく「従業員が一人ずつ、サーバーごとにOAuthで同意する」個人任せの運用だった。管理者から見れば、誰がどの接続を持っているか把握できず、退職者の権限が残り、監査証跡もバラバラ——統制の観点では穴だらけである。

2026年8月24日、Anthropic はこの構造を作り替える機能を一般提供（GA）にした。**MCPコネクタの「エンタープライズ管理認可（Enterprise-Managed Authorization、EMA）」**である（Claude公式ブログ）。認可の主導権を「個人」から「組織のIDプロバイダ（IdP）」へ反転させる仕組みで、Claude の Team / Enterprise プランで使える。本稿は、何がどう変わったのかを一次情報で正確に押さえ、日本企業がMCP接続層に敷くべき統制を整理する。

何が変わったのか——「一人ずつ許可」から「組織が一度で統べる」へ

これまでの標準的なMCP認可には、エンタープライズ運用と相性の悪い前提があった。MCP公式ブログはその摩擦を3点に整理している（Enterprise-Managed Authorization解説）。

• 個人任せの認可: 「従業員が、すべてのサーバーを一つずつ承認しなければならない」
• 中央ポリシーの不在: セキュリティチームが一貫したアクセス制御を強制できない
• アカウントの混線: 個人IDと会社IDが不適切に混ざりうる

EMA はこの主導権を反転させる。要点は公式の一言に凝縮されている——「一度許可すれば、どこでも継承される（Authorize once, inherit everywhere）」。管理者が組織に対してサーバーを有効化すると、ユーザーは自分が既に属しているグループやロールに紐づく形で、自動的にそのコネクタを受け取る。個々の同意画面は不要になる。

対応コネクタは、Asana・Atlassian・Canva・Figma・Granola・Linear・Supabase を皮切りに、GA時点で Datadog・Notion・Slack が加わり、Exa・Miro・Zoom が続く予定だ。IdP は Okta が最初の対応先で、Okta の Cross App Access（XAA） プロトコルを用いる。

仕組み——鍵は「ID-JAG」というトークン交換

EMA の技術的な核は、SSO のついでに発行される特殊なトークンにある。クライアント（Claude）は、シングルサインオンの過程で IdP から ID アサーション JWT 認可グラント（Identity Assertion JWT Authorization Grant、ID-JAG） を取得し、それを MCP サーバーの認可サーバーでアクセストークンに交換する。ユーザーはサーバーごとの同意画面を完全に迂回する（MCP公式ブログ）。

この設計の副作用として、動的クライアント登録（Dynamic Client Registration、DCR）は EMA では使えない。IdP が発行するアサーションには固定の client_id が刻まれるため、認可サーバーは最初のアサーションが届く前に、そのクライアントを既に認識していなければならない。したがって自社でMCPサーバーを運用する側は、Claude を Anthropic 保有のクライアント認証情報か、**Client ID Metadata Document（CIMD）**で事前登録しておく必要がある（WorkOS: サーバービルダー向け解説）。DCR は2026-07-28仕様で正式に非推奨化され、CIMD が推奨経路になった。

従来の個人OAuthとEMAを、企業統制の視点で並べると差が明確になる。

なぜ企業にとって重要か——統制の「三点セット」が揃う

EMA が効くのは、単に「ログインが楽になる」からではない。エンタープライズのAI統制で長年埋まらなかった穴を、標準的なIDの仕組みで塞げるからだ。

第一に、プロビジョニングの一元化。 IT部門はコネクタを組織で一度承認し、既存の Okta グループ/ロールに沿ってアクセスを割り当てられる。ユーザー（およびそのAIエージェント）は、所属に応じて必要な接続を初回ログイン時に受け取る。「誰がどのツールに繋げるか」が、既存のID基盤の延長線上で決まる。

第二に、オフボーディングの自動化。 ユーザーやエージェントが退職・停止されれば、IdP側の失効に連動してMCP接続の権限も自動で消える。手作業で「あの人のあの接続を消し忘れた」という典型的な事故を、構造的に防げる。

第三に、監査の一本化。 アクセス判断は IdP の管理コンソールに集約され、全コネクタを横断する単一の監査証跡になる。誰が・いつ・どの権限で繋いだかを、一箇所で追える。

落とし穴——「GAになった」を過信しない

一方で、導入前に直視すべき制約もある。

• IdPとコネクタのカバレッジ。 初期対応IdPは Okta が中心で、対応コネクタも順次拡大中だ。自社が使う主要SaaSやIdPが対象に入っているかを、まず現況で確認する必要がある。「MCPだから何でも繋がる」ではない。
• 自社構築サーバーへの影響。 DCR非推奨・CIMD推奨・ID-JAG対応は、内製のMCPサーバーに実装作業を要求する。認可サーバーで固定client_idを認識し、テナントごとの issuer 許可リストを持ち、認可判断をクレームのマッピングに寄せる——といった対応が前提になる（WorkOS）。
• 認可の粒度は「接続の有無」が中心。 EMA が統べるのは「誰がどのサーバーに繋げるか」。その先の「エージェントがそのツールで何をしてよいか（書き込み・削除・送信などの操作単位の承認）」までは別レイヤーの設計だ。接続の認可と、実行の承認は分けて考える必要がある。

MCP のロードマップ（2026年8月更新）も、EMA の安定化に続けて DPoP やワークロードID連携によるエージェントID を次の重点に挙げている（MCPロードマップ）。接続の認可は入り口であって、統制の全体像はまだ拡張の途上にある。

homula の観点——「接続の認可」と「実行の統制」を分けて設計する

homula はエンタープライズ向けの AIエージェント・インテグレーターとして、まさにこの「接続層をどう統べるか」を実装の中心に据えてきた。

• 接続の入り口は、標準のIDに寄せる。 homula の統合プラットフォーム Agens は、MCPを活用して200以上のツールと構築ゼロで接続する。EMA のように「正規の接続経路を管理者が一度で敷き、あとはIDから継承させる」設計は、ツールが増えるほど効いてくる。個人が場当たりで承認する接続を、組織のID基盤に集約するのが第一歩だ。
• 接続の先には、実行の統制を必ず重ねる。 前述のとおり、EMA が守るのは「繋げるか」まで。Agens Control は、その先の承認フロー・DLP・RBAC・5年分の監査ログを担う。「誰がどのツールに繋げるか（EMA/IdP）」と「エージェントがそのツールで何を実行してよいか（Agens Control）」を二層で設計することで、接続の認可と操作の承認・監査が初めて噛み合う。
• 立ち上げは棚卸しから。 どのコネクタを、どの部門・ロールに、どこまで開くか。AIエージェント・ブートキャンプで業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で回し、IdPのグループ設計と接続方針を最初から統制込みで固める。

技術は n8n / Dify / LangGraph を組み合わせ、戦略策定からPoC・実装・運用・内製化までを一気通貫で伴走する。認可の標準が整った今こそ、「自社のID基盤に接続をどう乗せ、その先の実行をどう統べるか」を設計に落とす好機だ。

まとめ

• 2026年8月24日、AnthropicがMCPコネクタのエンタープライズ管理認可（EMA）をGAにした（Team / Enterprise）。認可の主導権が「個人」から「組織のIdP」に反転した。
• 仕組みは ID-JAG によるトークン交換。「一度許可すれば、どこでも継承」。DCRは非推奨となり、固定client_id＋CIMDが前提になる。
• 企業にとっての本質は、プロビジョニングの一元化・オフボーディングの自動化・監査の一本化という統制の三点セットが、既存のID基盤で揃うこと。
• ただし EMA が統べるのは「接続の有無」まで。「繋げるか」と「何を実行してよいか」は別レイヤーとして二層で設計する必要がある。

MCP接続の認可がIdPに移った今、次の一歩は「自社のID基盤に、どのコネクタを・どのロールまで開き、その先の実行をどう承認・監査するか」を言語化することだ。homula はその設計から本番運用・内製化までを伴走する。

---

接続の認可はIdPで一元化できる時代になりました。次に効くのは、その先の“実行の統制”です。homula が接続方針の設計から実装・監査まで伴走します。

無料相談を予約する

Agens Controlで承認・監査・RBACの統制を設計する

MCP活用支援で接続層を標準化する