第1回では、AI エージェントが誰の権限で動くかを、モデル A（ユーザー代理型）・B（エージェント独立権限型）・C（保存接続依存型）の3つに整理しました。あわせて、権限主体が導入形態で変わるため、個々の SaaS や個々のユーザーの同意だけでは全体像を把握しにくいことも確認しました。
今回はその続きとして、このうちモデル A（ユーザー代理型の OAuth 接続）の接続認可を組織管理の IdP へ集約する仕組みを扱います。具体的には、ID-JAG（Identity Assertion JWT Authorization Grant）・Cross App Access（XAA）・MCP の Enterprise-Managed Authorization（EMA）の3つです。いずれも Okta が中心になって推進している仕組みで、Okta for AI Agents の接続認可にも組み込まれています（第3回で詳述）。あわせて、集約した後もリソース側に残る統制を整理します。
本記事の扱う範囲は次のとおりです。
対象外の静的・共有資格情報は、OAuth／ワークロード ID ベースへ移行するか、ボールト（vault：認証情報を保管・管理するシークレットストア）と特権管理で扱います（第3回）。
本記事のポイント
- 従来の個別同意では、OAuth 同意や資格情報がユーザーごと・SaaS ごとに分散し、IdP から横断的に把握・停止できません。
- ID-JAG / XAA / EMA を使うと、ユーザー代理型（モデル A）の接続認可を組織管理の IdP へ集約できます。
- 集約できるのは接続認可までです。アクセストークンの発行・失効やリソース側の操作認可は、Resource AS（リソース側の認可サーバー）や SaaS 側に残ります。
本シリーズの構成は次のとおりです。
従来、AI ツールやエージェントが外部 SaaS に繋がる方法は、①ユーザーが SaaS ごとに OAuth 同意する、②静的な API キーや Bearer トークンを保存する、③共有のサービスアカウントを使う、の3つが中心でした。いずれの方法にも、統制の面で次の問題があります。
| 問題 | 確認すべき問い |
|---|---|
| 1. 接続の管理基盤が分散する | 管理者は接続先と失効経路を把握できるか |
| 2. 経路で権限主体が変わる | 外部 SaaS では誰の権限で動くか |
| 3. 保存接続が共有される | 接続を設定した本人以外が、その権限を使えるか |
1つめの問題から見ていきます。接続の把握・停止自体は、SaaS 管理画面・OAuth アプリ管理・CASB / SSPM・ネットワークログでも部分的には可能です。しかし管理基盤とログが SaaS や接続方式ごとに分かれるため、エージェントを起点に接続先・権限・失効経路を組織横断で追うのは容易ではありません。Okta の解説も、IdP はユーザーの認証はできても、その AI エージェントが何の権限を要求しているかまでは見えにくいと指摘しています（Okta の解説記事）。
こうした個別同意と分散管理は、現場では2つの形で表面化します。ひとつはユーザー側の同意疲れです。中身を読まずに許可ボタンを押し、広範なアクセスを与えてしまいます。もうひとつは管理者側の可視性の分散です。ユーザーの ID は確認できても、エージェントがどこにどの権限で繋がり、どの主体として動くかを一元的には追えません。
問題1への答えが、本記事の主題である IdP への集約です。問題2と問題3は、次節で Notion と Google Workspace を例に具体化します。
ID-JAG / XAA / EMA で IdP へ集約できるのは、モデル A（ユーザー代理型）の経路だけです。モデル C の保存資格情報も ID 基盤製品で統制できますが、その手段は接続認可の集約ではなく、ボールトでの保管・取得制御という補完策です（第3回）。つまり、どの経路がどのモデルにあたるかの見極めが、そのまま集約対象の特定になります。第1回の最後に触れた同じ SaaS でもアクセス経路によって権限主体が変わるという論点を、Notion から Google Workspace へのアクセスを例に確認します。
AI コネクタは、Notion AI や Enterprise Search からユーザーが Drive・Gmail・Calendar を検索する経路です。利用者ごとの権限が適用されます（モデル A：ユーザー代理型）。
Notion の各コネクタのヘルプもこの動作を明記しています。Drive は、Notion と Google Workspace 間の権限マッピングに従って、許可されたコンテンツだけを取り込みます（Google ドライブ AI コネクター）。Gmail・Calendar は、メールアドレスの完全一致で本人を照合し、各ユーザーの AI が自分自身の受信箱・カレンダーだけを参照します（Gmail / Google Calendar）。いずれも検索（読み取り）の経路です。
カスタムエージェントでは、Notion 内部の権限と、外部サービスへ接続するときの資格情報が別になります。
Notion の公式ヘルプもこの動作を説明しています。MCP 接続は、接続を認証した人の資格情報を使います。そのため共有されたエージェントの利用者は、外部サービスに直接アクセスできなくても、接続済みツールを利用できます。Calendar・Mail も同様で、接続を設定したユーザーが見られる予定や受信箱に、共有された利用者もアクセスできます。つまり1つのカスタムエージェントに、モデル B と C が併存します。
| 経路 | 外部 SaaS で使う権限 |
|---|---|
| AI コネクタ | 各利用者の権限（A） |
| カスタムエージェントの保存接続（Mail / Calendar / MCP） | 接続を設定した人の権限（C） |
なお判定の基準は、第1回で整理したとおり下流アクセスの認可主体が誰かであり、有人か無人（定時・イベント実行）かではありません。特定ユーザーの委任が下流で継続適用されるなら、無人実行でもモデル A です。
Notion 側にも、接続できるツールの選択・読み取りと書き込みの権限・書き込み時の確認・共有時の警告といった制御があります。一方、接続先 SaaS の最終認可・アクセストークンのライフサイクル・接続先に残る操作ログは、Notion 単独では完結しません。この統制の境界は、IdP へ集約した後も同じ形で現れます（後述）。
これらの経路のうち、ID-JAG / XAA / EMA が対象にするのは、AI コネクタのようなユーザー代理型の OAuth 接続（モデル A）の経路です。次節から、その集約の仕組みを見ていきます。
従来のユーザー代理型の OAuth 接続（SaaS ごとの個別同意）は、委任の仕組みを変えずに、接続認可だけを組織管理の IdP へ集約できます。IdP へ移るのは、どのエージェントが、どの SaaS に、どの権限で接続してよいかという判断です。誰の権限で動くか（モデル A であること）は変わりません。
この集約の中核となる ID-JAG は、企業 IdP が発行する接続の許可証です（XAA / EMA との関係は次節で整理します）。個別同意のままとの違いは次のとおりです。
| 観点 | 従来（ユーザーごとの個別同意） | IdP 集約（ID-JAG / XAA / EMA） |
|---|---|---|
| 接続を承認する人 | 各ユーザー | 管理者（IdP のポリシー） |
| ユーザーの操作 | SaaS ごとに同意画面 | 企業 IdP へのログインのみ（Resource AS ごとの同意画面なし） |
| 可視性 | 接続が SaaS 側に分散 | 接続認可と ID-JAG 発行を IdP 側に記録できる |
| 失効 | SaaS ごとに手作業 | IdP が新規 ID-JAG 発行を停止（既存トークンは Resource AS 側の実装に依存） |
これで、接続可否の判断・ID-JAG 発行・ポリシー適用の起点が IdP にそろいます。一方、アクセストークンの発行・既存トークンの失効・下流 SaaS 内の操作ログは、Resource AS や SaaS / ゲートウェイ側と組み合わせて管理します（詳細は「IdP 集約後に残る統制」で扱います）。
ここまで3つの名前を並べてきましたが、中心にあるのは ID-JAG という1つの OAuth 拡張仕様です。XAA はこの仕様を使うアプリ間接続パターンの名称で、EMA は同じ仕様を MCP 接続へ適用した認可拡張です。つまり、仕様（ID-JAG）→ 適用パターン（XAA / EMA）→ 製品実装（Claude の Enterprise-managed auth など）という階層で捉えると、用語の関係を整理できます。以降の節では、XAA、EMA の順に仕組みを見ていきます。
| 用語 | 位置づけ |
|---|---|
| ID-JAG | 企業 IdP が発行し、Resource AS へ提示するユーザー委任の許可証。あわせて、その形式と交換手順を定めた OAuth ドラフト仕様の名称（Identity Assertion JWT Authorization Grant） |
| XAA | ID-JAG を使うアプリ間接続パターンと、その実装エコシステムの名称（Cross App Access） |
| EMA | ID-JAG を MCP 接続へ適用する公式 MCP 認可拡張（Enterprise-Managed Authorization） |
| Claude Enterprise-managed auth | EMA のベータ実装例の1つ |
XAA の技術的な背景や検証内容は、弊社記事（検証・技術詳細）でも解説しています。
アプリ間（SaaS 間）の接続に ID-JAG を使うパターンが XAA です。集約した後も、IdP が発行するのは ID-JAG までです。アクセストークンの発行はリソース側に残ります。
第1回の4者モデルと対応させると、要求側アプリが AI エージェント、リソースアプリが SaaS、企業 IdP が ID 基盤にあたります。ただし、これはあくまで説明上の対応です。Okta はパートナーエコシステムを Requesting apps・Resource apps・Identity infrastructure, gateways & frameworks の3つに分類しています（ユーザーは含まれません）が、これは製品エコシステムの分類であり、Resource AS を含む OAuth / ID-JAG のプロトコル上のロールとは別のものです。
IdP が評価するのは、「この要求側アプリが、特定のユーザーのために、特定のリソースへ接続してよいか」です。一方、ID-JAG の検証とアクセストークンの発行は Resource AS の責務です。両者は別の役割であるため、監査ログも IdP 側と Resource AS 側に分かれます。
Okta の実装では、エージェントの接続先として登録したカスタム認可サーバー（API Access Management）がこの Resource AS を担い、接続プロトコルには XAA が使われます（Okta 公式ドキュメント）。
ID-JAG の必須クレームのうち主体を表すのは、ユーザーの sub と OAuth クライアントの client_id です。行為者を表す act クレームも任意クレームとして定義されていますが、actor_token の検証やポリシー評価・発行への反映は現行ドラフトでは規定されておらず、将来のプロファイルに委ねられています。
そのため、この段階で得られる可視性はエージェント単位ではなく、まずユーザー・要求側クライアント・Resource AS・resource・scope の組み合わせです。エージェント単位の識別・所有者・ライフサイクルは、第3回のワークロード ID 管理として分けて扱います。
MCP には、ユーザー単位の OAuth ベースの標準認可がすでにあります。Enterprise-Managed Authentication (EMA) は、その上に載る企業向けプロファイルです。ID-JAG を MCP に適用することで、ユーザー個別の同意を管理者ポリシーへ置き換えます。
前節の3段階を MCP に当てはめると、次のようになります。前節の要求側アプリにあたるのが MCP クライアントです。
大きな違いは、対応済みの管理対象接続では、企業 IdP へのログイン後に Resource AS ごとの同意画面へリダイレクトされない点です。ただし、次の処理は残ります。
また前提として、MCP クライアントとサーバーの双方が EMA に対応している必要があります。
消えるのは同意の操作であって、認可の判断ではありません。判断は管理者ポリシーとして事前に行われます。
ID-JAG の主なクレームは、現行ドラフト（draft-04）で次のように定められています。
aud：提示先の Resource AS の issuerresource：対象の保護リソース（EMA では MCP Server の Resource Identifier）client_id：Resource AS に登録された OAuth クライアント。認証済みクライアントと一致する必要があるjti：JWT の一意な識別子。識別やログの突き合わせに使える注意したいのは、jti があっても一回限りの利用にはならない点です。現行ドラフトは ID-JAG の一回限り利用を要求しておらず、有効期限内の同じ ID-JAG の再提示を受け入れるかは、Resource AS の実装・ポリシーに依存します。一方で、別の Resource AS への同じ ID-JAG の使い回しは明示的に禁止されています。送信者以外による再利用を抑えるには、任意の DPoP / cnf による鍵バインディングを用います。
なお、ID-JAG を取得するまでの流れは、OIDC では ID Token または Refresh Token を用い、SAML では一度 Refresh Token に交換してから取得する、と仕様で説明されています。
この領域では、仕様の成熟度と製品の提供状況が一致していません。ID-JAG は Internet-Draft のまま製品提供が先行し、逆に EMA は仕様が stable になった後も実装はベータ／プレビュー段階です（2026年7月時点）。標準の完成を待たずに各社が製品化へ踏み出すほど動きの速い領域となっています。仕様が stable だから製品も使えるとは限らず、製品があるから仕様が確定しているわけでもありません。そのため、仕様のステータスと製品のステータスは分けて確認します。
| 区分 | 対象 | ステータス |
|---|---|---|
| 仕様・名称 | ID-JAG | IETF OAuth WG の Internet-Draft（草案）。現行版は draft-04 で、確定標準の RFC ではありません |
| XAA | ID-JAG を使うパターン・エコシステムの通称。Okta が初期の策定・実装を主導。独立した IETF 仕様名ではありません | |
| EMA | SEP-990 を基にした公式 MCP 認可拡張。2026年6月18日に stable。コア MCP 本体とは別の opt-in 拡張です | |
| 製品・実装 | Claude Enterprise-managed auth | Claude Team / Enterprise 向けに顧客提供中のベータ |
| VS Code の Enterprise-managed MCP authentication | Preview として提供中 | |
| Okta XAA エコシステム | 発表済みパートナーと実際に利用可能な統合は別物。Okta Workforce の OIN 提供開始は2026年8月予定 |
いずれも変化の速い情報のため、導入判断の際は各一次情報（末尾の参考ドキュメント）で最新のステータスを確認してください。
前節の表に挙げた実装は、いずれも利用が始まっています。XAA は Okta のカスタム認可サーバーを Resource AS として既に利用でき、弊社の検証記事でも動作を確認しています。ここでは EMA がエンドユーザー向け製品にどう現れるかの例として、Claude の Enterprise-managed auth を見ていきます。EMA の3段階のフローが、利用者には同意画面なしの自動接続として、管理者には IdP でのポリシー管理として現れます。Claude チャット・Claude Code・Cowork を横断して機能します。ローンチ時点で対応する IdP は Okta です。
管理者が Okta 経由で MCP コネクタを認可すると、ユーザーは自動接続されます。適用範囲は、有効化されたクライアント・MCP サーバー・ユーザー / グループ・スコープの組み合わせで決まります。Okta 側の統制は次の3点にまとめられています（Okta のプレスリリース）。
加えて Claude 側の管理機能でも、有効にするコネクタと、グループ・チーム・ロール単位のアクセス範囲を制御できます。ただし Anthropic は、Claude はあくまで IdP が発行した認可を中継する立場だと説明しています。アクセス可否と、アクセスできるデータの範囲は、IdP のポリシーと接続先サービス側の権限に従います。
EMA を有効にしただけで、組織内のすべての接続が管理対象になるわけではありません。Claude では、組織管理コネクタに加えて個人コネクタも併存できます。個人コネクタは引き続き個別同意の経路で動くため、統制対象の棚卸しでは両者を区別して把握する必要があります。
失効操作のうち、IdP 側で完結するのは新規 ID-JAG の発行停止です。既存セッションは、接続先のアクセストークンが失効または期限切れになったときに終了します。
ここまで見てきたとおり、ユーザー代理型の OAuth 接続では、接続認可を IdP へ集約できます。ただし、集約してもカバーしきれない統制が3つ残ります。操作単位の統制・監査ログの突き合わせ・トークンの失効です。Notion の例で見た経路を分けても残る統制の境界は、IdP へ集約した後も同じ形で現れます。ただし、いずれについても対策はあります。以下では、IdP の外側の制御ポイントとどう組み合わせるかを順に見ていきます。
個々の操作の判断は1つの層では完結せず、次の4段階を組み合わせます。
resource / scope / authorization_details によるスコープの絞り込み4つめの層にある DLP は既存の SSE / CASB でも一部を担えます。ただし、カバーできるのは観測可能なネットワーク経路と対応 SaaS までです。クラウド間で直接流れる MCP トラフィックや、SaaS 内で完結する操作には届きません。
この MCP Host / ゲートウェイの層は、製品化が進みつつある領域でもあります。Okta は Okta for AI Agents の今後の拡張として、エージェントとツール間のトラフィックを仲介する Okta ホスト型のコントロールプレーン Agent Gateway を発表しています（Okta の GA 発表。2026年7月時点では提供前）。
DLP を補完する SSE / CASB 側の具体策は、Netskope を使った生成 AI 利用の制御として弊社記事で解説しています。
単一の監査証跡は、プロトコルだけでは完成しません。ID-JAG / EMA が定めるのは認可の流れであり、ログの保存までは保証しないためです。製品実装では、接続要求・ポリシー判断・ID-JAG 発行を IdP 側に記録できます。一方、アクセストークンの発行・MCP ツール呼び出し・SaaS 内の操作は、Resource AS・MCP Server・SaaS・ゲートウェイのそれぞれに残ります。全体の証跡は、これらのログを突き合わせる相関分析によって再構成します。前述のとおり、ID-JAG の jti はこの突き合わせのキーとして使えます。
IdP で止められるのは、新しい ID-JAG の発行と、将来の接続認可です。既発行 ID-JAG の再利用や、既存のアクセストークン・セッションの扱いは、Resource AS の実装に依存します。ID-JAG / EMA は、Resource AS が発行するアクセストークンに短い有効期限を義務付けていません。そのため、トークンの寿命と失効機構は、Resource AS の実装・設定として確認します。
冒頭の表では、管理者は接続先と失効経路を把握できるか、外部 SaaS では誰の権限で動くか、接続を設定した本人以外がその権限を使えるかという3つの問いを挙げました。自社の環境でこれらに答えるための確認手順を、3段階に整理します。
棚卸し（第1回の3モデルを使います）
移行判断（本記事の主題です）
失効・監査・補完（前節「IdP 集約後に残る統制」に対応します）
この7つのステップは、冒頭の3つの問いに答えるための材料になります。
本記事では、従来のユーザー代理型の OAuth 接続（SaaS ごとの個別同意）が、委任の仕組みを変えないまま、ID-JAG / XAA / EMA によって組織管理の IdP へ集約できることを確認しました。ただし、IdP へ移るのは接続認可の判断までです。アクセストークンの発行は Resource AS が担い、操作単位の統制・監査ログの突き合わせ・トークンの失効は IdP の外側の層に残ります。この集約できる範囲と残る範囲の切り分けが、本記事の要点です。
集約の仕組みは、製品への組み込みも進んでいます。Okta for AI Agents では、リソース接続の一部として実装されています（Okta 公式ドキュメント）。
第3回では、この Okta for AI Agents を軸に、エージェントの発見から、登録・所有者管理・最小権限・失効に至るライフサイクル管理の最新状況を解説します。
| 用語 | 説明 |
|---|---|
| IdP | Identity Provider。ユーザーやワークロードの認証を担う。本シリーズでは認可サーバー機能を兼ねる企業 ID 基盤を便宜上 IdP と表記 |
| ID-JAG | Identity Assertion JWT Authorization Grant。企業 IdP が発行する署名済み JWT で、ユーザー委任にもとづく下流のアクセストークン取得を認可する許可証。仕様は IETF の OAuth 拡張ドラフト |
| Internet-Draft | IETF の標準化過程で公開される草案文書。末尾の数字は改訂版数を表し（ID-JAG の draft-04 は4回改訂された現行版）、改訂により内容が変わり得る。標準化が完了すると RFC として発行される |
| XAA | Cross App Access。ID-JAG を核とするアプリ間接続パターンと実装エコシステムの名称。Okta が策定・実装を主導 |
| EMA | Enterprise-Managed Authorization。ID-JAG を MCP 接続へ適用する公式 MCP 認可拡張 |
| MCP | Model Context Protocol。AI エージェントが外部ツール・データソースに接続するためのプロトコル |
| Identity Assertion | 企業 IdP がユーザーの認証結果として発行するアサーション（OIDC の ID Token や SAML Assertion 等）。ID-JAG 取得の入力になる |
| Resource AS | リソース側の認可サーバー（Resource Authorization Server）。ID-JAG を検証し、アクセストークンを発行する |
| Resource Server | アクセストークンを検証し、サービス内権限で個々の API 操作を最終認可するサーバー（SaaS / MCP Server 等） |
| client authentication | クライアントが認可サーバーに自身を証明する方式（private_key_jwt・mTLS など） |
| aud | audience。ID-JAG では提示先である Resource AS の issuer を指定するクレーム |
| jti | JWT ID。JWT の一意な識別子。識別やログの突き合わせに使えるが、それだけで一回限りの利用は保証されない |
| DLP | Data Loss Prevention。データの外部送出や横展開を制御する仕組み |
本記事はシリーズ AI エージェントの認証・認可を ID 基盤に集約する の第2回です。記載の各製品の仕様・挙動については2026年7月時点の情報を元にしています。急速に変化する領域のため、導入検討時は一次情報での再確認を推奨します。
Okta や AI エージェントのセキュリティ統制に関するご相談は、ネクストモードまでお気軽にお問い合わせください。