📚 業界ナレッジ

Claude × Okta、MCP の Enterprise-Managed Auth ベータ公開 — エージェント時代の『ゼロタッチ認可』と『退場の即時化』が同時に標準化された日（XAA／IPSIE／Asana・Atlassian・Canva・Figma・Granola・Linear・Supabase 対応）

トピック分析AI・イノベ2026-06-20

【国際・海外企業】連載・AI・イノベ米国【科学・AI】【経済・SaaS】

#AI・イノベ#エンタープライズAI#エージェント認可#MCP#Okta#Anthropic#Claude#アイデンティティガバナンス

目次
  1. 概要
  2. 詳細
  3. Enterprise-Managed Auth は『何を変えるか』
  4. XAA から EMA へ — オープン仕様化の1年
  5. 対応 MCP サーバーとクライアント — どこまで実用に乗るか
  6. Okta 側の同時打ち — ISPM × Claude Compliance API
  7. Brad Brooks（Anthropic）と Ely Kahn（Okta）が語ったこと
  8. もし深堀するなら
  9. まとめ
  10. 理解度チェック
  11. 関連リンク

Claude × Okta、MCP の Enterprise-Managed Auth ベータ公開 — エージェント時代の『ゼロタッチ認可』と『退場の即時化』が同時に標準化された日（XAA／IPSIE／Asana・Atlassian・Canva・Figma・Granola・Linear・Supabase 対応）

Claude × Okta MCP Enterprise-Managed Auth の全体構造図

出典（一次／二次／三次の切り分け） — C1契約
  • primary_source: Anthropic公式「Centrally manage authorization for MCP connectors」（2026-06-18公開）
  • primary_source_url: https://claude.com/blog/enterprise-managed-auth
  • primary_source_checked_at: 2026-06-20
  • secondary_source: Okta公式プレスリリース「Okta becomes a featured identity provider powering secure AI agent connections for Claude Enterprise」（2026-06-18）
  • secondary_source_url: https://www.okta.com/newsroom/press-releases/okta-becomes-a-featured-identity-provider-powering-secure-ai-agent-connections-for-claude-enterprise/
  • tertiary_source: Model Context Protocol公式ブログ「Enterprise-Managed Authorization: Zero-touch OAuth for MCP」
  • tertiary_source_url: https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
  • source_date: 2026-06-18
  • source_confidence: High
  • verification_note: 三層一次でXAA→EMAの経緯（2025-06提案／2025-09 OAuth WG採択／2025-11 MCP正式組込）、対応IdP（Oktaリード、他IdPは順次）、対応MCPサーバー7社（Asana/Atlassian/Canva/Figma/Granola/Linear/Supabase、Slack順次）、対応クライアント（Claude chat／Claude Code／Cowork）、Team/Enterpriseプラン、ベータ取り込み顧客（Ramp／Webflow／HubSpot）、Okta CPO Ely Kahn発言、Identity Security Posture ManagementとClaude Compliance APIの統合まで一致確認。

概要

エージェントを社内に入れる議論が、いま静かに『機能の話』から『身分証の話』へ移っています——。
2026年6月18日（米国時間）、Anthropic がClaude の MCP コネクタを Okta などのアイデンティティプロバイダ（IdP）から中央集権的に管理できる「Enterprise-Managed Authorization（EMA）」のベータ提供を開始し、同時に Okta も「Anthropic の featured identity provider に選定された」と公式発表しました。
打ち出された機能はシンプルです。「ユーザー個別に OAuth 承認をぽちぽち押させる時代を終わりにする」。
それだけのことなのですが、これはエージェント運用の前提条件＝『誰がどの会社のデータに触れていいか』を、実行時に IdP の権限グループから取り直すという大きな思想転換でもあります。

要点を3行で整理します。

具体的には、Claude（Team／Enterprise プラン）の Web チャット・Claude Code・Cowork という3クライアント全面で、MCP コネクタの認可が組織の IdP の認証文脈に紐付くようになります。
ベータ初期の対応 MCP サーバーは Asana・Atlassian・Canva・Figma・Granola・Linear・Supabase の7つ、Slack は順次対応が予告されました。
先行導入企業として Ramp・Webflow・HubSpot など共同顧客の名前が挙がっています。
技術仕様の根っこは Identity Assertion JWT Authorization Grant（ID-JAG）で、ユーザーが組織の IdP に1回だけ認証すれば、その結果が許可された MCP サーバー全てへ自動で配られるという設計です。MCP の認可拡張は OAuth の上位互換ではなく、OAuth を補完する『組織の境界に沿った認可の標準』という位置づけになります。
Okta は同時に、Identity Security Posture Management（ISPM）と Claude のCompliance APIの統合も発表し、誰がどのエージェントに何を許したかをアイデンティティ側からも監査できる経路を整えました。
なお Okta が主導した XAA は2025年6月に提案／同9月に OAuth ワーキンググループで採択／同11月に MCP に Enterprise Managed Auth として組み込みという1年がかりの仕込みの上に立っています。

補足 — そもそも MCP／Okta／XAA／IPSIE／ID-JAG とは

MCP（Model Context Protocol） は Anthropic が2024年末に提案し、業界の事実上の標準になりつつある「AI エージェントが外部のデータ・ツールに繋ぐための共通プロトコル」です。各 SaaS ごとに専用コネクタを書く負担をなくし、1つの規格でデータソース／ツールを横断できるようにする発想です。Okta は世界最大級のアイデンティティ／アクセス管理（IAM）プラットフォームで、社員の認証（誰なのか）と認可（何ができるか）を中央で管理します。XAA（Cross App Access） は Okta が主導したOAuth の拡張仕様で、エージェント-アプリ間／アプリ-アプリ間でユーザーの代理として権限を委譲する流れを標準化します。IPSIE（Interoperability Profile for Secure Identity in the Enterprise） は OpenID Foundation が策定中のエンタープライズ向けアイデンティティ相互運用プロファイルで、SaaS 横断の認証・認可・監査の共通土台を目指しています。ID-JAG（Identity Assertion JWT Authorization Grant） はユーザーが IdP に1回だけ認証すれば、その結果（IDアサーション）を JWT として複数のリソースに配布できるOAuth の認可付与方式の1つで、XAA の技術的な裏側に位置します。ここまで全て「特定ベンダーの独自仕様」ではなく、業界標準化の流れに乗っている点が、今回の発表の土台の堅さを支えています。

詳細

Enterprise-Managed Auth は『何を変えるか』

Anthropic 公式が掲げた中心メッセージは1つです。「コネクタの認可を、ユーザーから組織に引き上げる」。
これまで、Claude で MCP コネクタを使うにはユーザー本人が SaaS ごとに OAuth 同意画面を踏む必要がありました。
10個 SaaS に繋ぐなら10回。2,000人の従業員に展開する組織では単純計算で 20,000 回の同意操作が必要で、現実問題として導入が止まる。
これがエンタープライズ導入の最大の詰まりでした。

Enterprise-Managed Auth（EMA）では、管理者が IdP 側でコネクタを1回許可すれば、ユーザー側の操作は0回で済むようになります。

Anthropic は事例として、「Before: 1コネクタごとの OAuth 承認列。After: 2,000人を Okta 経由で即日プロビジョン、追加操作ゼロ」という導入ケースを開示しています。運用工数の話だけでなく、ガバナンスとセキュリティの本筋が同時に進む設計です。

XAA から EMA へ — オープン仕様化の1年

今回の発表は単発のベンダー連携ではなく、1年がかりの標準化プロセスの到達点でもあります。経緯を時系列で並べると次の通りです。

時期 できごと 意味
2025年6月 Okta がXAA（Cross App Access）を提案 エージェント-アプリ間／アプリ-アプリ間の権限委譲標準の発端
2025年9月 OAuth ワーキンググループで採択 中立な国際標準化の場に乗った
2025年11月 MCP の公式拡張として「Enterprise Managed Auth」に組み込み AI エージェント業界の標準仕様に組み込まれた
2026年6月18日 Claude（Team／Enterprise）でベータ提供開始、Okta が featured IdP に 実装が世に出た日。ベータながら実顧客が動いている

1年の地慣らしの上で公開された機能であるため、仕様の安定性と他ベンダー追従の余地がはじめから設計に組み込まれている格好です。Okta が IdP のリードですが、他 IdP（Microsoft Entra ID／Google Workspace／Ping／OneLogin 等）の対応は順次拡大予定と明示されています。

対応 MCP サーバーとクライアント — どこまで実用に乗るか

ベータ初期に対応するMCP サーバーは7社です。

Slack は順次対応が予告されています。
クライアント側は Claude チャット／Claude Code／Cowork の3面で同じ仕組みが効きます。非エンジニアが普段使う Web チャットも、開発者が使う Claude Codeも、チーム協業で使う Coworkも、同じ IdP の権限境界で動きます。プラットフォーム内のチャネル分断が認可レイヤーで解消される点が運用上の肝です。

Enterprise-Managed Auth のゼロタッチ認可フロー（Before／After 比較）

Okta 側の同時打ち — ISPM × Claude Compliance API

Okta は同日、Identity Security Posture Management（ISPM）の Claude 連携も発表しました。ISPM はアイデンティティ周りのリスク（過剰権限・休眠アカウント・誤設定）を継続的に検出する Okta の機能で、これが Claude のCompliance API（エージェントの監査ログ・ポリシー違反を構造化して引き出すAPI）と連携します。

意味するところは、「エージェントの行動」と「人間のアイデンティティ」を1つの監査文脈で扱えるようになる、ということです。誰のロールでエージェントが何をしたかがアイデンティティ側のリスクボードに自動で集約される設計で、SOX 内部統制・ISO 27001・SOC 2 等の監査で問われる粒度に事前に応える形になっています。検出だけでなく『監査での説明のしやすさ』まで踏み込んだのが、Okta 側の今回の打ち手の中身です。

Brad Brooks（Anthropic）と Ely Kahn（Okta）が語ったこと

両社の責任者が同じ趣旨を繰り返しました。
Okta CPO Ely Kahn の整理は「技術エコシステムが急速に拡大する時には、オープン標準が安全な拡張の鍵になる」。機能カタログの競争ではなく、仕様の上で誰が信頼レイヤーを取るかの競争に論点が移ったという認識です。

単一ベンダーの独自連携では特定 IdP と特定 SaaS のロックインを増やすだけで、組織のマルチベンダー現実に合わない。MCP × EMA × XAA の積み上げは、どの IdP からでも・どの MCP サーバーへでも・どのクライアントからでも、同じ言葉で認可を語れる土台を作ろうとしています。「エージェントの実装競争」から「エージェントの信頼レイヤー競争」へのフェーズ移行が、業界トップの共通認識になった日、と整理できます。

もし深堀するなら

🔎 FP&A実務的なアプローチの考察（クリックで展開／全員必読ではありません）

ここから先は、自社にエージェントを導入する立場と、予算・統制・監査を設計する立場で本件を「自社の中期予算と組織設計」にどう転用するか、の実務的な読み筋です。要点を5つに絞ります。

1. AI 予算の科目に『境界コスト』を独立計上する — 単一プラットフォーム内のエージェント運用費（モデル利用料・API・ストレージ）と、プラットフォーム間の境界（IdP 連携・認可・監査・棚卸）にかかる実装＋運用コストは、似て非なる科目です。実装プロジェクト費に紛れ込ませると、恒常運用に入った瞬間に予算化されず運用品質が落ちる典型パターンになります。
来期予算編成では、「AI 境界コスト」を独立科目化し、IdP ライセンス増分・コネクタ実装・監査整備・棚卸ツールを項目別に置く設計が、中期の予実差異分析を回しやすくします。

2. SaaS 選定 RFP の必須要件に『MCP × EMA 対応』を追加する — 来年以降の SaaS 更改 RFP のチェック欄に、「MCP サーバー対応／EMA 対応／対応 IdP 種別」を必須項目として置く設計は、中期のロックイン回避と運用工数の双方に効きます。機能でなく境界仕様の対応を選定軸に格上げするのは、情シス独自判断ではなく経営会議の合意事項として決め切る価値があります。経営から見ると、これは「個別 SaaS の話」ではなく「組織の AI 統制の土台」です。

3. オンボーディング／オフボーディングの『真の所要時間』を KPI 化する — 今回の最大の便益はオンボーディングと退場の所要時間の劇的短縮です。従来の SaaS 個別 OAuthでは入社時の SaaS 接続完了までに 1〜2 週間、退職時の権限剥奪完遂までに 1〜4 週間かかる組織が一般的です。EMA が効くと両方とも『当日』に近づきます。オンボーディング DTC（Day-To-Connect）とオフボーディング DTR（Day-To-Revoke）をFP&A モニタの KPIに置くと、運用品質と人事リスク管理の両方を1指標で可視化できます。退職時の権限剥奪漏れはSOX・GDPR・個人情報保護法の論点に直結するので、CFO 室の数値ボードに月次の DTR 中央値を置く設計は、2026年下期からの定型化に値します。

4. 監査法人との対話を『今のうちに』予習しておく — EMA／XAA／ID-JAGは監査人にとってまだ新しい概念です。監査論点に組み込まれる前に、自社の監査法人・内部監査部門と「これは SOX のアクセス管理セクションでどう扱うか」「監査証跡として何を取れば足りるか」の事前すり合わせをしておくと、翌年の監査で慌てない運用になります。経理／内部監査／情シス／経営企画の4部門合同の論点として年1で常設化する価値があります。監査人視点での説明素材がClaude の Compliance API＋Okta の ISPMで構造化されるため、CFO 室として『説明しやすい監査ボード』を事前に組んでおく設計が大きな差になります。

5. 投資テーマの再分類 — 『AI＝モデル』から『AI＝アイデンティティ』へ — 投資妙味の視点では、モデル本体の競争が飽和に近づき、認可・監査・棚卸のレイヤーに資金が集中しています。
Gartner はAI ガバナンス・プラットフォーム市場を2026年4.92億ドル／2030年10億ドル超と予測しています。MCP/EMA 系の認可・監査、ISPM 系のアイデンティティ姿勢監視、MuleSoft／Unity AI Gateway／Entra AI Governance 系のエージェント棚卸——この3層は、特化型スタートアップの参入余地が残る領域です。自社の投資ポートフォリオでも、AI＝モデルではなく AI＝アイデンティティ／統制で再分類する視点は、中期テーマの解像度を一段上げます。

試算例（一般化した思考実験） — 仮に従業員 2,000 人規模の組織で、1人あたり 10 SaaS を Claude のコネクタ経由で利用するケースを考えます。従来方式では、1人あたり 10 回の OAuth 承認が必要で、同意ダイアログ・ログイン・許可確認に平均 5 分かかったとすると、1人あたり 50 分、2,000 人で 1,667 時間が単純な認可セットアップに消費されます。EMA を導入すると、この時間が実質ゼロに近づきます。
さらにオフボーディングでは、旧来は 1人あたり 10 SaaS の権限剥奪を IT に依頼し平均 3〜10 日かかる運用が一般的でした。2,000 人組織で年間 200 人の退職があれば、2,000 SaaS-ユーザー連携の剥奪作業が発生します。EMA で『退職処理＝同日剥奪』になると、情シスの工数だけでなく、退職者の権限滞留期間が短くなるリスク削減効果も同時に得られます。SOX／GDPR／個人情報保護法上の権限滞留リスクは1件あたりの監査対応コスト＋万一の漏えい時の損害で試算されるので、運用工数と監査リスクの両面で便益が立つ構造です。
数値はあくまで一般化した思考実験で、特定組織の実数はもちろん部門・業種・統制要件で大きく変わりますが、EMA の便益は『機能の便益』ではなく『運用工数の便益＋監査リスクの便益』で語るべきという発想は、CFO・FP&A 視点で投資の正当化に有効です。

EMA 導入の便益試算（オンボーディング工数＋オフボーディング権限滞留リスクの一般化）

まとめ

理解度チェック

記事内容を確認するための簡易チェックです。

Q1. Anthropic の Enterprise-Managed Auth（EMA）の最も大きな運用上の便益はどれでしょうか？

解答

正解: B EMA の核は「ゼロタッチ認可」と「退場の即時化」の同時設計です。
管理者が IdP 側でコネクタを許可すれば社員側の操作はゼロ、IdP 側で Deactivate された瞬間に MCP コネクタへのアクセスも剥奪される——この2点が運用上の最大の便益です。
A／C は本件の論点ではなく、D は MCP 標準仕様への組み込みなので逆方向です。

Q2. EMA の技術的な裏側にある仕様の組み合わせとして正しいものはどれでしょうか？

解答

正解: C XAA は Okta が主導した OAuth の拡張仕様で、2025年9月に OAuth WG で採択され、2025年11月に MCP の公式拡張「Enterprise Managed Auth」として組み込まれました。
技術的な裏側は ID-JAG（Identity Assertion JWT Authorization Grant）で、IdP に1回認証すればその結果が許可された MCP サーバー全てへ自動で配布されます。特定ベンダーの独自仕様ではなく、業界標準の上に立っている点が今回の発表の堅さの土台です。

Q3. FP&A 視点で、EMA 導入時に「独立科目として予算化すべき」と本記事が提案しているのは何でしょうか？

解答

正解: B モデル利用料は実装プロジェクト費に紛れ込みやすい一方、IdP 連携・認可・監査・棚卸といった「境界コスト」は恒常運用に入った時点で予算化されないと品質が落ちる典型パターンです。「AI 境界コスト」を独立科目化することで、来期の予算編成から監査整備・棚卸ツール・IdP ライセンス増分を項目別に管理できるようになります。

関連リンク

↑ 今日の新着・3入口へ戻る