--- title: 【Okta for AI Agents】AI エージェントの認証・認可を ID 基盤に集約する 第2回：散らばった同意を IdP に集約する XAA / ID-JAG / MCP EMA｜Nextmode Blog description: ユーザーごとに分散した OAuth 接続認可を、ID-JAG / XAA / MCP EMA によって組織管理の IdP へ集約する仕組みを整理します。いずれも Okta for AI Agents の接続認可を支える技術です。静的・共有資格情報との違いと、接続後もリソース側に残る操作統制も確認します。 image: https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/%E7%94%9F%E6%88%90AI%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3_Okta.png --- [![nextmode blog](https://info.nextmode.co.jp/hubfs/raw_assets/public/NextMode_Theme/nextmode%20blog.png)](https://info.nextmode.co.jp/blog) [ホワイトペーパー](https://info.nextmode.co.jp/white-paper/) [資料請求](https://info.nextmode.co.jp/request/) [お問い合わせ](https://nextmode.co.jp/contact/) - [会社TOP](https://nextmode.co.jp/) - [生成AIセキュリティ](https://nextmode.co.jp/services/ai/security/) - [SaaSライセンス＆サポート](https://nextmode.co.jp/services/saas/) - [Oktaライセンス＆サポート](https://nextmode.co.jp/services/saas/okta/) - [Netskopeライセンス＆サポート](https://nextmode.co.jp/services/saas/netskope/) - [Notionライセンス＆サポート](https://nextmode.co.jp/services/saas/notion/) - [Asanaライセンス＆サポート](https://nextmode.co.jp/services/saas/asana/) - [SysCloudライセンス＆サポート](https://nextmode.co.jp/services/saas/syscloud/) - [CrowdStrikeライセンス＆サポート](https://nextmode.co.jp/services/saas/crowdstrike/) - [AWS総合支援](https://nextmode.co.jp/services/aws/) - [AWS導入コンサル・構築](https://nextmode.co.jp/services/aws_consulting/) - [AWS運用・保守代行](https://nextmode.co.jp/services/aws_operation/) - [導入事例](https://nextmode.co.jp/casestudy/) - [会社情報](https://nextmode.co.jp/company/) - [セミナー](https://info.nextmode.co.jp/seminar/) - [ブログ](https://info.nextmode.co.jp/blog) [![YouTube](https://nextmode.co.jp/assets/images/common/icon_youtube.svg)](https://www.youtube.com/@nextmode) 目次 2026/07/14 08:52 # 【Okta for AI Agents】AI エージェントの認証・認可を ID 基盤に集約する 第2回：散らばった同意を IdP に集約する XAA / ID-JAG / MCP EMA [» Okta](https://info.nextmode.co.jp/blog/tag/okta) [» 技術](https://info.nextmode.co.jp/blog/tag/技術) [» Notion AI](https://info.nextmode.co.jp/blog/tag/notion-ai) [» 生成AIセキュリティ対策シリーズ](https://info.nextmode.co.jp/blog/tag/生成aiセキュリティ対策シリーズ) [» AI](https://info.nextmode.co.jp/blog/tag/ai) [![yuki](https://info.nextmode.co.jp/hs-fs/hubfs/avator_yukinawa.jpg?width=40&name=avator_yukinawa.jpg) yuki](https://info.nextmode.co.jp/blog/author/yuki) 共有： [facebook-f icon](http://www.facebook.com/share.php?u=https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-xaa-idjag-mcp-ema) [linkedin-in icon](http://www.linkedin.com/shareArticle?mini=true&url=https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-xaa-idjag-mcp-ema) [Twitter icon](https://twitter.com/intent/tweet?url=https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-xaa-idjag-mcp-ema) [pinterest-p icon](http://pinterest.com/pin/create/link/?url=https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-xaa-idjag-mcp-ema) [envelope icon](mailto:?body=https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-xaa-idjag-mcp-ema) ## はじめに --- [第1回](https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-permission-models)では、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回で詳述）。あわせて、**集約した後もリソース側に残る統制**を整理します。 本記事の扱う範囲は次のとおりです。 - **対象**：モデル A（ユーザー代理型）の OAuth 接続の接続認可 - **対象外**：静的 API キー・共有資格情報（app-only を含む）、接続後の操作単位の認可 対象外の静的・共有資格情報は、OAuth／ワークロード ID ベースへ移行するか、ボールト（vault：認証情報を保管・管理するシークレットストア）と特権管理で扱います（第3回）。 > **本記事のポイント** > > - 従来の個別同意では、OAuth 同意や資格情報がユーザーごと・SaaS ごとに分散し、IdP から横断的に把握・停止できません。 > - ID-JAG / XAA / EMA を使うと、ユーザー代理型（モデル A）の接続認可を組織管理の IdP へ集約できます。 > - 集約できるのは接続認可までです。アクセストークンの発行・失効やリソース側の操作認可は、Resource AS（リソース側の認可サーバー）や SaaS 側に残ります。 本シリーズの構成は次のとおりです。 - [第1回](https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-permission-models)：エージェントは誰の権限で動くのか。権限主体を A / B / C の3モデルで整理しました。 - 第2回（本記事）：外部 SaaS への接続認可を ID 基盤へ集約する仕組み（ID-JAG / XAA / EMA）を扱います。 - [第3回](https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-vendor-landscape)：Okta・Microsoft・Google・AWS のエージェント ID 管理を比較し、残る課題を整理します。 ## 従来の接続方法と3つの問題 --- 従来、AI ツールやエージェントが外部 SaaS に繋がる方法は、①ユーザーが SaaS ごとに OAuth 同意する、②静的な API キーや Bearer トークンを保存する、③共有のサービスアカウントを使う、の3つが中心でした。いずれの方法にも、統制の面で次の問題があります。 | 問題 | 確認すべき問い | | --- | --- | | 1. 接続の管理基盤が分散する | 管理者は接続先と失効経路を把握できるか | | 2. 経路で権限主体が変わる | 外部 SaaS では誰の権限で動くか | | 3. 保存接続が共有される | 接続を設定した本人以外が、その権限を使えるか | 1つめの問題から見ていきます。接続の把握・停止自体は、SaaS 管理画面・OAuth アプリ管理・CASB / SSPM・ネットワークログでも部分的には可能です。しかし管理基盤とログが SaaS や接続方式ごとに分かれるため、エージェントを起点に**接続先・権限・失効経路を組織横断で追うのは容易ではありません**。Okta の解説も、IdP はユーザーの認証はできても、その AI エージェントが何の権限を要求しているかまでは見えにくいと指摘しています（[Okta の解説記事](https://www.okta.com/identity-101/cross-app-access-securing-ai-agent-and-app-to-app-connections/)）。 こうした個別同意と分散管理は、現場では2つの形で表面化します。ひとつはユーザー側の**同意疲れ**です。中身を読まずに許可ボタンを押し、広範なアクセスを与えてしまいます。もうひとつは管理者側の**可視性の分散**です。ユーザーの ID は確認できても、エージェントがどこにどの権限で繋がり、どの主体として動くかを一元的には追えません。 問題1への答えが、本記事の主題である IdP への集約です。問題2と問題3は、次節で Notion と Google Workspace を例に具体化します。 ## 経路で変わる権限主体 --- ID-JAG / XAA / EMA で IdP へ集約できるのは、**モデル A（ユーザー代理型）の経路だけ**です。モデル C の保存資格情報も ID 基盤製品で統制できますが、その手段は接続認可の集約ではなく、ボールトでの保管・取得制御という補完策です（第3回）。つまり、どの経路がどのモデルにあたるかの見極めが、そのまま集約対象の特定になります。第1回の最後に触れた**同じ SaaS でもアクセス経路によって権限主体が変わる**という論点を、Notion から Google Workspace へのアクセスを例に確認します。 ### 経路1：AI コネクタ（モデル A） AI コネクタは、Notion AI や Enterprise Search からユーザーが Drive・Gmail・Calendar を検索する経路です。**利用者ごとの権限が適用されます**（モデル A：ユーザー代理型）。 Notion の各コネクタのヘルプもこの動作を明記しています。Drive は、Notion と Google Workspace 間の権限マッピングに従って、許可されたコンテンツだけを取り込みます（[Google ドライブ AI コネクター](https://www.notion.com/ja/help/notion-ai-connectors-for-google-drive)）。Gmail・Calendar は、メールアドレスの完全一致で本人を照合し、各ユーザーの AI が自分自身の受信箱・カレンダーだけを参照します（[Gmail](https://www.notion.com/ja/help/notion-ai-connector-for-gmail) / [Google Calendar](https://www.notion.com/ja/help/google-calendar-ai-connector)）。いずれも検索（読み取り）の経路です。 ### 経路2：カスタムエージェントの保存接続（モデル B＋C） カスタムエージェントでは、**Notion 内部の権限と、外部サービスへ接続するときの資格情報が別**になります。 - Notion 内部のページ・データベースに対しては、エージェント自身へ付与した独立権限で動きます（モデル B：エージェント独立権限型）。 - 外部の Mail / Calendar / MCP には、接続を設定したユーザーの保存資格情報を使います。この資格情報は**実際の利用者の権限で再評価されない**ため、モデル C（保存接続依存型）にあたります。 Notion の公式ヘルプもこの動作を説明しています。MCP 接続は、接続を認証した人の資格情報を使います。そのため共有されたエージェントの利用者は、外部サービスに直接アクセスできなくても、接続済みツールを利用できます。Calendar・Mail も同様で、接続を設定したユーザーが見られる予定や受信箱に、共有された利用者もアクセスできます。つまり1つのカスタムエージェントに、**モデル B と C が併存します**。 | 経路 | 外部 SaaS で使う権限 | | --- | --- | | AI コネクタ | 各利用者の権限（A） | | カスタムエージェントの保存接続（Mail / Calendar / MCP） | 接続を設定した人の権限（C） | ![fig-gws-access-paths](https://info.nextmode.co.jp/hs-fs/hubfs/Blog_yuki/o4aa-ai-agent-authn-authz/fig-gws-access-paths.png?width=2384&height=2352&name=fig-gws-access-paths.png) なお判定の基準は、[第1回](https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-permission-models)で整理したとおり**下流アクセスの認可主体が誰か**であり、有人か無人（定時・イベント実行）かではありません。特定ユーザーの委任が下流で継続適用されるなら、無人実行でもモデル A です。 ### 経路を分けても残る統制の境界 Notion 側にも、接続できるツールの選択・読み取りと書き込みの権限・書き込み時の確認・共有時の警告といった制御があります。一方、接続先 SaaS の最終認可・アクセストークンのライフサイクル・接続先に残る操作ログは、Notion 単独では完結しません。この統制の境界は、**IdP へ集約した後も同じ形で現れます**（後述）。 これらの経路のうち、ID-JAG / XAA / EMA が対象にするのは、AI コネクタのような**ユーザー代理型の OAuth 接続（モデル A）の経路**です。次節から、その集約の仕組みを見ていきます。 ## 個別同意から IdP 集約へ --- 従来のユーザー代理型の 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 集約後に残る統制」で扱います）。 ## ID-JAG / XAA / EMA の関係 --- ここまで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 の技術的な背景や検証内容は、弊社記事（[検証](https://info.nextmode.co.jp/blog/okta-cross-app-access-ai-agent)・[技術詳細](https://info.nextmode.co.jp/blog/okta-id-jag-cross-app-access-tech)）でも解説しています。 ## XAA：ID-JAG とアクセストークンの発行元 --- アプリ間（SaaS 間）の接続に ID-JAG を使うパターンが XAA です。集約した後も、**IdP が発行するのは ID-JAG まで**です。アクセストークンの発行はリソース側に残ります。 ### 発行から実行までの3段階 1. **IdP** が接続を認可し、ID-JAG を発行する。 2. **Resource AS（リソース側認可サーバー）**が ID-JAG を検証し、アクセストークンを発行する。 3. **要求側アプリ**がそのアクセストークンで、Resource Server / SaaS / MCP Server の API を呼び出す。 第1回の4者モデルと対応させると、要求側アプリが AI エージェント、リソースアプリが SaaS、企業 IdP が ID 基盤にあたります。ただし、これはあくまで説明上の対応です。Okta はパートナーエコシステムを Requesting apps・Resource apps・Identity infrastructure, gateways & frameworks の3つに分類しています（ユーザーは含まれません）が、これは製品エコシステムの分類であり、Resource AS を含む OAuth / ID-JAG のプロトコル上のロールとは別のものです。 ![fig-xaa-ecosystem](https://info.nextmode.co.jp/hs-fs/hubfs/Blog_yuki/o4aa-ai-agent-authn-authz/fig-xaa-ecosystem.png?width=2384&height=1426&name=fig-xaa-ecosystem.png) ### IdP と Resource AS の役割分担 IdP が評価するのは、「この要求側アプリが、特定のユーザーのために、特定のリソースへ接続してよいか」です。一方、ID-JAG の検証とアクセストークンの発行は Resource AS の責務です。両者は別の役割であるため、**監査ログも IdP 側と Resource AS 側に分かれます**。 Okta の実装では、エージェントの接続先として登録したカスタム認可サーバー（API Access Management）がこの Resource AS を担い、接続プロトコルには XAA が使われます（[Okta 公式ドキュメント](https://help.okta.com/oie/ja-jp/content/topics/ai-agents/ai-agent-resource-comparison.htm)）。 ### 可視性の単位 ID-JAG の必須クレームのうち主体を表すのは、ユーザーの `sub` と OAuth クライアントの `client_id` です。行為者を表す `act` クレームも任意クレームとして定義されていますが、`actor_token` の検証やポリシー評価・発行への反映は現行ドラフトでは規定されておらず、将来のプロファイルに委ねられています。 そのため、この段階で得られる可視性はエージェント単位ではなく、まず**ユーザー・要求側クライアント・Resource AS・resource・scope の組み合わせ**です。エージェント単位の識別・所有者・ライフサイクルは、第3回のワークロード ID 管理として分けて扱います。 ## EMA：MCP の企業向け認可拡張 --- MCP には、ユーザー単位の OAuth ベースの標準認可がすでにあります。**Enterprise-Managed Authentication (EMA)** は、その上に載る企業向けプロファイルです。ID-JAG を MCP に適用することで、**ユーザー個別の同意を管理者ポリシーへ置き換えます**。 ### 認可フローの3段階 前節の3段階を MCP に当てはめると、次のようになります。前節の**要求側アプリ**にあたるのが MCP クライアントです。 1. ユーザーが MCP クライアントに企業 IdP で SSO ログインし、Identity Assertion を取得する。 2. MCP クライアントが IdP にトークン交換を要求し、ID-JAG を取得する。 3. MCP クライアントが Resource AS に ID-JAG を提示してアクセストークンを取得し、MCP サーバーを呼び出す。 ![fig-ema-flow](https://info.nextmode.co.jp/hs-fs/hubfs/Blog_yuki/o4aa-ai-agent-authn-authz/fig-ema-flow.png?width=2384&height=2182&name=fig-ema-flow.png) ### 消える操作と残る判断 大きな違いは、対応済みの管理対象接続では、企業 IdP へのログイン後に **Resource AS ごとの同意画面へリダイレクトされない**点です。ただし、次の処理は残ります。 - MCP クライアントへの企業 IdP SSO と、条件付きアクセスやステップアップ認証 - IdP によるユーザー・グループ・ロール・クライアント・接続先・スコープの評価 - Resource AS 側のローカルポリシーとユーザーアカウントの対応付け また前提として、MCP クライアントとサーバーの双方が EMA に対応している必要があります。 消えるのは同意の**操作**であって、認可の**判断**ではありません。判断は管理者ポリシーとして事前に行われます。 ### 補足：ID-JAG の主なクレーム ID-JAG の主なクレームは、現行ドラフト（draft-04）で次のように定められています。 - `aud`：提示先の Resource AS の issuer - `resource`：対象の保護リソース（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月予定 | | いずれも変化の速い情報のため、導入判断の際は各一次情報（末尾の参考ドキュメント）で最新のステータスを確認してください。 ## 製品例：Claude Enterprise-managed auth --- 前節の表に挙げた実装は、いずれも利用が始まっています。XAA は Okta のカスタム認可サーバーを Resource AS として既に利用でき、弊社の検証記事でも動作を確認しています。ここでは **EMA がエンドユーザー向け製品にどう現れるか**の例として、Claude の Enterprise-managed auth を見ていきます。EMA の3段階のフローが、利用者には同意画面なしの自動接続として、管理者には IdP でのポリシー管理として現れます。Claude チャット・Claude Code・Cowork を横断して機能します。ローンチ時点で対応する IdP は Okta です。 ### 一括認可の仕組み 管理者が Okta 経由で MCP コネクタを認可すると、**ユーザーは自動接続されます**。適用範囲は、有効化されたクライアント・MCP サーバー・ユーザー / グループ・スコープの組み合わせで決まります。Okta 側の統制は次の3点にまとめられています（[Okta のプレスリリース](https://www.okta.com/ja-jp/newsroom/press-releases/okta-becomes-a-featured-identity-provider-powering-secure-ai-agent-connections-for-claude-enterprise/)）。 - **集中管理された認可**：組織の MCP コネクタをまとめてプロビジョニング・認可する - **アクセス制御**：既存の Okta グループ・ロールにもとづき、利用者とそのエージェントがアクセスを継承する - **自動オフボーディング**：アカウントの無効化やロール変更により、他の業務アプリの権限と同時にコネクタへのアクセス権も失効する 加えて Claude 側の管理機能でも、有効にするコネクタと、グループ・チーム・ロール単位のアクセス範囲を制御できます。ただし Anthropic は、Claude はあくまで IdP が発行した認可を中継する立場だと説明しています。アクセス可否と、アクセスできるデータの範囲は、IdP のポリシーと接続先サービス側の権限に従います。 ### 適用条件と失効 EMA を有効にしただけで、**組織内のすべての接続が管理対象になるわけではありません**。Claude では、組織管理コネクタに加えて個人コネクタも併存できます。個人コネクタは引き続き個別同意の経路で動くため、統制対象の棚卸しでは両者を区別して把握する必要があります。 失効操作のうち、IdP 側で完結するのは**新規 ID-JAG の発行停止**です。既存セッションは、接続先のアクセストークンが失効または期限切れになったときに終了します。 ## IdP 集約後に残る統制 --- ここまで見てきたとおり、ユーザー代理型の OAuth 接続では、接続認可を IdP へ集約できます。ただし、集約してもカバーしきれない統制が3つ残ります。**操作単位の統制・監査ログの突き合わせ・トークンの失効**です。Notion の例で見た**経路を分けても残る統制の境界**は、IdP へ集約した後も同じ形で現れます。ただし、いずれについても対策はあります。以下では、IdP の外側の制御ポイントとどう組み合わせるかを順に見ていきます。 ### 操作単位の統制：4段階の制御ポイント 個々の操作の判断は1つの層では完結せず、次の4段階を組み合わせます。 - **IdP**：接続可否の判断と ID-JAG の発行 - **Resource AS**：アクセストークンの発行と、`resource` / `scope` / `authorization_details` によるスコープの絞り込み - **Resource Server / SaaS / MCP Server**：アクセストークンの検証と、サービス内権限・業務ルールによる個々の操作の最終認可 - **MCP Host / ゲートウェイ**：ツールの許可、書き込み制限、人による確認、リスク条件、DLP 4つめの層にある DLP は既存の SSE / CASB でも一部を担えます。ただし、カバーできるのは観測可能なネットワーク経路と対応 SaaS までです。**クラウド間で直接流れる MCP トラフィックや、SaaS 内で完結する操作には届きません**。 この MCP Host / ゲートウェイの層は、製品化が進みつつある領域でもあります。Okta は Okta for AI Agents の今後の拡張として、エージェントとツール間のトラフィックを仲介する Okta ホスト型のコントロールプレーン **Agent Gateway** を発表しています（[Okta の GA 発表](https://www.okta.com/blog/ai/okta-for-ai-agents-general-availability/)。2026年7月時点では提供前）。 DLP を補完する SSE / CASB 側の具体策は、Netskope を使った生成 AI 利用の制御として[弊社記事](https://info.nextmode.co.jp/blog/netskope-secure-genai-usage)で解説しています。 ### 監査ログの突き合わせ **単一の監査証跡**は、プロトコルだけでは完成しません。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 の実装・設定として確認します。 ## 自社への当てはめ：3段階の確認手順 --- 冒頭の表では、**管理者は接続先と失効経路を把握できるか**、**外部 SaaS では誰の権限で動くか**、**接続を設定した本人以外がその権限を使えるか**という3つの問いを挙げました。自社の環境でこれらに答えるための確認手順を、3段階に整理します。 **棚卸し**（第1回の3モデルを使います） 1. エージェントごとに、接続先 SaaS とアクセス経路を棚卸しする。 2. 各経路がモデル A / B / C のどれに当たり、どの資格情報を使うかを確認する。 **移行判断**（本記事の主題です） 1. ユーザー代理型（モデル A）の OAuth 接続を、XAA / EMA へ移行できるか確認する。 2. IdP・MCP クライアント・Resource AS / MCP サーバーの対応状況と提供段階（ドラフト／stable／ベータ／Preview）を確認する。 **失効・監査・補完**（前節「IdP 集約後に残る統制」に対応します） 1. 異動・退職・接続停止のとき、新規 ID-JAG・既存アクセストークン・保存資格情報をそれぞれどう止めるかを確認する。 2. IdP・Resource AS・SaaS・ゲートウェイのログをどう突き合わせるかを確認する。 3. 操作単位の認可・人による確認・DLP を、どこで補うかを確認する。 この7つのステップは、冒頭の3つの問いに答えるための材料になります。 ## おわりに --- 本記事では、従来のユーザー代理型の OAuth 接続（SaaS ごとの個別同意）が、委任の仕組みを変えないまま、ID-JAG / XAA / EMA によって組織管理の IdP へ集約できることを確認しました。ただし、IdP へ移るのは**接続認可の判断まで**です。アクセストークンの発行は Resource AS が担い、操作単位の統制・監査ログの突き合わせ・トークンの失効は IdP の外側の層に残ります。この**集約できる範囲と残る範囲の切り分けが、本記事の要点です**。 集約の仕組みは、製品への組み込みも進んでいます。Okta for AI Agents では、**リソース接続**の一部として実装されています（[Okta 公式ドキュメント](https://help.okta.com/oie/ja-jp/content/topics/ai-agents/ai-agent-secure.htm)）。 [第3回](https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-vendor-landscape)では、この 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。データの外部送出や横展開を制御する仕組み | ## 参考ドキュメント --- - [Okta - Cross App Access: Securing AI Agent and App-to-App Connections](https://www.okta.com/identity-101/cross-app-access-securing-ai-agent-and-app-to-app-connections/) - [Okta Blog - Okta for AI Agents is now generally available](https://www.okta.com/blog/ai/okta-for-ai-agents-general-availability/) - [Okta 公式ドキュメント - AIエージェントのリソース接続](https://help.okta.com/oie/ja-jp/content/topics/ai-agents/ai-agent-secure.htm) - [Okta 公式ドキュメント - AIエージェントリソースタイプを比較する](https://help.okta.com/oie/ja-jp/content/topics/ai-agents/ai-agent-resource-comparison.htm) - [IETF - Identity Assertion JWT Authorization Grant (ID-JAG) draft-04](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) - [IETF - RFC 8693 OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693.html) - [IETF - RFC 7523 JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://www.rfc-editor.org/rfc/rfc7523.html) - [MCP Blog - Enterprise-Managed Authorization: Zero-touch OAuth for MCP](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/) - [MCP Specification - Enterprise Managed Authorization](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization.mdx) - [MCP - SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990) - [Claude - Authorize MCP connectors for your entire organization](https://support.claude.com/en/articles/15537633-authorize-mcp-connectors-for-your-entire-organization) - [Claude - Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claudes-capabilities) - [Visual Studio Code 1.123 - Enterprise-managed MCP authentication（Preview）](https://code.visualstudio.com/updates/v1_123) - [Okta Newsroom - Okta、Anthropic の Claude 向けに主要 IdP に選定](https://www.okta.com/ja-jp/newsroom/press-releases/okta-becomes-a-featured-identity-provider-powering-secure-ai-agent-connections-for-claude-enterprise/) - [Okta Newsroom - Cross App Access パートナーエコシステム拡大](https://www.okta.com/newsroom/press-releases/okta-announces-cross-app-access-partners/) - [Notion ヘルプセンター - GoogleドライブAIコネクター](https://www.notion.com/ja/help/notion-ai-connectors-for-google-drive) - [Notion ヘルプセンター - Gmail AI Connector](https://www.notion.com/ja/help/notion-ai-connector-for-gmail) - [Notion ヘルプセンター - Google Calendar AI Connector](https://www.notion.com/ja/help/google-calendar-ai-connector) - [Notion - MCP connections for Custom Agents](https://www.notion.com/en-gb/help/mcp-connections-for-custom-agents) - [Notion - Connect Calendar to Custom Agents](https://www.notion.com/help/connect-calendar-to-custom-agents) - [Notion - Connect Mail to Custom Agents](https://www.notion.com/help/connect-mail-to-custom-agents) - [Nextmode Blog - Okta Cross App Access で AI エージェントの接続認可を検証する](https://info.nextmode.co.jp/blog/okta-cross-app-access-ai-agent) - [Nextmode Blog - ID-JAG / Cross App Access の技術詳細](https://info.nextmode.co.jp/blog/okta-id-jag-cross-app-access-tech) - [Nextmode Blog - 生成AI時代のネットワーク制御 ― Netskopeで「使わせない」から「安全に使わせる」へ](https://info.nextmode.co.jp/blog/netskope-secure-genai-usage) --- *本記事はシリーズ **AI エージェントの認証・認可を ID 基盤に集約する** の第2回です。記載の各製品の仕様・挙動については2026年7月時点の情報を元にしています。急速に変化する領域のため、導入検討時は一次情報での再確認を推奨します。* ### AI セキュリティ対策に関するお問い合わせ Okta や AI エージェントのセキュリティ統制に関するご相談は、ネクストモードまでお気軽にお問い合わせください。 [![SaaSバナー\_Okta](https://hubspot-no-cache-na2-prod.s3.amazonaws.com/cta/default/20481958/interactive-256988631778.png)](https://info.nextmode.co.jp/hs/cta/wi/redirect?encryptedPayload=AVxigLKUC7qFvCQgHJ1XtSVb5AvcorR%2B5Y15Xv0Is03lIML9EetnKIB8POgSVQqmQLA%2B%2FjUhAWHlVug%2FlpTFAJmLtTnsyMYn1dIWgmd0LSaH36oliUddZM0JPJHMMcuj0aeV%2FrcSr6X%2F%2BNATe8h%2BGYBO0qTpW8ggn5%2BRcrGrlnNKii4F3ZPSfZOwpnxh8nS8SA%3D%3D&webInteractiveContentId=256988631778&portalId=20481958) ### 関連記事 [![【Oktane26】セッション：Okta Workflows 顧客事例と今後のロードマップ](https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/oktane26.png) 【Oktane26】セッション：Okta Workflows 顧客事例と今後のロードマップ ![](https://info.nextmode.co.jp/hubfs/kusumi.png) kusumin 2026/09/24](https://info.nextmode.co.jp/blog/oktane26-workflows-flowcase) [![【Oktane26】セッション：AI エージェント接続の安全と使いやすさを両立する Cross App Access](https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/oktane26.png) 【Oktane26】セッション：AI エージェント接続の安全と使いやすさを両立する Cross App Access ![](https://info.nextmode.co.jp/hubfs/avator_yukinawa.jpg) yuki 2026/09/24](https://info.nextmode.co.jp/blog/oktane26-cross-app-access-ai-agents) [![【Oktane26】Day3 基調講演：How Did I Get Here?: The Ascent of an Unlikely CEO](https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/oktane26.png) 【Oktane26】Day3 基調講演：How Did I Get Here?: The Ascent of an Unlikely CEO ![](https://info.nextmode.co.jp/hubfs/oharafu.png) おはらふ 2026/09/24](https://info.nextmode.co.jp/blog/oktane26-day3-keynote) ### Category [» 技術](https://info.nextmode.co.jp/blog/tag/技術) [» Okta](https://info.nextmode.co.jp/blog/tag/okta) [» Notion](https://info.nextmode.co.jp/blog/tag/notion) [» イベントレポート](https://info.nextmode.co.jp/blog/tag/イベントレポート) [» Netskope](https://info.nextmode.co.jp/blog/tag/netskope) [» CrowdStrike](https://info.nextmode.co.jp/blog/tag/crowdstrike) [» Notion AI](https://info.nextmode.co.jp/blog/tag/notion-ai) [» AWS](https://info.nextmode.co.jp/blog/tag/aws) [» Asana](https://info.nextmode.co.jp/blog/tag/asana) [» カルチャー](https://info.nextmode.co.jp/blog/tag/カルチャー) [» ワーケーション](https://info.nextmode.co.jp/blog/tag/ワーケーション) [» 生成AIセキュリティ対策シリーズ](https://info.nextmode.co.jp/blog/tag/生成aiセキュリティ対策シリーズ) [» Oktane25](https://info.nextmode.co.jp/blog/tag/oktane25) [» SaaS](https://info.nextmode.co.jp/blog/tag/saas) [» re:Invent](https://info.nextmode.co.jp/blog/tag/reinvent) [» AI](https://info.nextmode.co.jp/blog/tag/ai) [» リモートワーク](https://info.nextmode.co.jp/blog/tag/リモートワーク) [» Keeper](https://info.nextmode.co.jp/blog/tag/keeper) [» ネクストモードアドベントカレンダー2024](https://info.nextmode.co.jp/blog/tag/ネクストモードアドベントカレンダー2024) [» Oktane24](https://info.nextmode.co.jp/blog/tag/oktane24) [» Oktane23](https://info.nextmode.co.jp/blog/tag/oktane23) [» Asana AI](https://info.nextmode.co.jp/blog/tag/asana-ai) [» Slack](https://info.nextmode.co.jp/blog/tag/slack) [» Oktane26](https://info.nextmode.co.jp/blog/tag/oktane26) [» OIGシリーズ](https://info.nextmode.co.jp/blog/tag/oigシリーズ) [» その他](https://info.nextmode.co.jp/blog/tag/その他) [» 脱Excelシリーズ](https://info.nextmode.co.jp/blog/tag/脱excelシリーズ) [» Oktane22](https://info.nextmode.co.jp/blog/tag/oktane22) [» SysCloud](https://info.nextmode.co.jp/blog/tag/syscloud) [» Google](https://info.nextmode.co.jp/blog/tag/google) [» HubSpot](https://info.nextmode.co.jp/blog/tag/hubspot) [» Zapier](https://info.nextmode.co.jp/blog/tag/zapier) [» Azure AD](https://info.nextmode.co.jp/blog/tag/azure-ad) [» Entra ID](https://info.nextmode.co.jp/blog/tag/entra-id) [» Googleドライブ](https://info.nextmode.co.jp/blog/tag/googleドライブ) [» SentinelOne](https://info.nextmode.co.jp/blog/tag/sentinelone) [» ゼロトラスト](https://info.nextmode.co.jp/blog/tag/ゼロトラスト) [» DocuSign](https://info.nextmode.co.jp/blog/tag/docusign) [» Jamf](https://info.nextmode.co.jp/blog/tag/jamf) [» セキュリティ対策](https://info.nextmode.co.jp/blog/tag/セキュリティ対策) [» トラブルシューティング](https://info.nextmode.co.jp/blog/tag/トラブルシューティング) [» 利用者目線](https://info.nextmode.co.jp/blog/tag/利用者目線) [» 運用](https://info.nextmode.co.jp/blog/tag/運用) [» GitHub](https://info.nextmode.co.jp/blog/tag/github) [» GitHub Gist](https://info.nextmode.co.jp/blog/tag/github-gist) [» JOUG](https://info.nextmode.co.jp/blog/tag/joug) [» Notion Calendar](https://info.nextmode.co.jp/blog/tag/notion-calendar) [» Proflly](https://info.nextmode.co.jp/blog/tag/proflly) [» kintone](https://info.nextmode.co.jp/blog/tag/kintone) [![ネクストモード株式会社](https://nextmode.co.jp/assets/images/common/logo_white.svg)](https://nextmode.co.jp/) Service - [生成AIセキュリティ](https://nextmode.co.jp/services/ai/security/) - [SaaSライセンス＆サポート](https://nextmode.co.jp/services/saas/) - [Oktaライセンス＆サポート](https://nextmode.co.jp/services/saas/okta/) - [Netskopeライセンス＆サポート](https://nextmode.co.jp/services/saas/netskope/) - [Notionライセンス＆サポート](https://nextmode.co.jp/services/saas/notion/) - [Asanaライセンス＆サポート](https://nextmode.co.jp/services/saas/asana/) - [SysCloudライセンス＆サポート](https://nextmode.co.jp/services/saas/syscloud/) - [CrowdStrikeライセンス＆サポート](https://nextmode.co.jp/services/saas/crowdstrike/) - [Keeperライセンス＆サポート](https://nextmode.co.jp/services/saas/keeper/) - [AWS総合支援](https://nextmode.co.jp/services/aws/) - [AWS導入コンサル・構築](https://nextmode.co.jp/services/aws_consulting/) - [AWS運用・保守代行](https://nextmode.co.jp/services/aws_operation/) Company - [会社情報](https://nextmode.co.jp/company/) - [サービス一覧](https://nextmode.co.jp/services/) - [導入事例](https://nextmode.co.jp/casestudy/) - [お知らせ](https://nextmode.co.jp/news/) - [サステナビリティ](https://nextmode.co.jp/sustainability/) - [採用](https://nextmode.co.jp/recruit/) - [私たちの働き方](https://nextmode.co.jp/workstyle/) - [カルチャー](https://nextmode.co.jp/culture/) Contact - [お問い合わせ](https://nextmode.co.jp/contact/) - [資料請求](https://info.nextmode.co.jp/request/) Media - [セミナー](https://info.nextmode.co.jp/seminar) - [ブログ](https://info.nextmode.co.jp/blog) - [ホワイトペーパー](https://info.nextmode.co.jp/white-paper/) - [![ネクストモード公式YouTubeチャンネル](https://nextmode.co.jp/assets/images/common/icon_youtube.svg)](https://www.youtube.com/channel/UCeW8ocoe9C3E0GOINh167MA) - [![ネクストモード公式Xアカウント](https://nextmode.co.jp/assets/images/common/icon_x.svg)](https://twitter.com/Nextmode_Inc) [English](https://nextmode.co.jp/en/) - [NTTグループカスタマーハラスメント基本方針](https://group.ntt/jp/group/customer_harassment/) - [就活ハラスメント防止方針](https://docs.nextmode.co.jp/nextmode_recruit_harassment.pdf) - 運用アシスタント利用規約([AWS](https://docs.nextmode.co.jp/nextmode-unyo-assistant-aws-terms-of-use.pdf)/[Azure](https://docs.nextmode.co.jp/nextmode-unyo-assistant-azure-terms-of-use.pdf)) - [日中運用支援定型約款](https://docs.nextmode.co.jp/nextmode-nittyu-unyo-shien-terms-of-use.pdf) - [定型約款](https://docs.nextmode.co.jp/nextmode-standard-contracts.pdf) [プライバシーポリシー](https://nextmode.co.jp/company/privacy.html) Copyright(c) Nextmode, Inc. ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "yuki", "url" : "https://info.nextmode.co.jp/blog/author/yuki" }, "dateModified" : "2026-07-13T23:52:52.180Z", "datePublished" : "2026-07-13T23:52:52.000Z", "headline" : "【Okta for AI Agents】AI エージェントの認証・認可を ID 基盤に集約する 第2回：散らばった同意を IdP に集約する XAA / ID-JAG / MCP EMA｜Nextmode Blog", "image" : [ "https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/%E7%94%9F%E6%88%90AI%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3_Okta.png" ], "mainEntityOfPage" : { "@id" : "https://info.nextmode.co.jp/blog/o4aa-ai-agent-authn-authz-xaa-idjag-mcp-ema", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://info.nextmode.co.jp/hubfs/nm_l_color.png" }, "name" : "ネクストモード株式会社" } } ``` ```json { "@context" : "https://schema.org", "@id" : "https://nextmode.co.jp/#organization", "@type" : "Organization", "alternateName" : "Nextmode, Inc.", "logo" : "https://nextmode.co.jp/assets/images/common/logo_white.svg", "name" : "ネクストモード株式会社", "sameAs" : [ "https://www.youtube.com/channel/UCeW8ocoe9C3E0GOINh167MA", "https://twitter.com/Nextmode_Inc", "https://info.nextmode.co.jp/" ], "url" : "https://nextmode.co.jp/" } ```