Okta Cross App Access（XAA）とは？AIエージェントの認可を統制する新標準を2026年動向で解説

Okta Cross App Access（XAA）は、AIエージェントやアプリ同士の接続を、各アプリ任せにせず企業のIdP（アイデンティティプロバイダー）の管理下に移す新しいプロトコルです。本記事では、XAAの正体であるIETF草案ID-JAGの位置づけ、IdPが仲裁する2段階トークン交換の仕組み、MCPやゼロトラストとの関係、そして「今導入すべき企業／まだ見送るべき企業」の判断基準までを、2026年6月時点の最新ステータスに基づいて整理します。エンジニアと情報システム部門の双方が、自社で何を準備すべきかを判断できる状態をゴールにします。

Cross App Access（XAA）の要点と、日本企業が2026年に取るべき初動

XAAの本質は一言で言えます。AIエージェントの認可判断を、アプリ層から企業のIdPへ引き上げる仕組みです。これにより「どのエージェントが、どのアプリに、どの権限で触れたか」をOktaが一元的に記録・制御し、繰り返される同意画面も不要になります。土台はOAuthとOpenID Connectの拡張であり、まったく新しい認証基盤への置き換えではありません。

2026年6月時点で、XAAはまだEarly Access（早期提供）段階です。同月にClaude・Cursor・Slack・Datadogなど25社以上の連携が発表され、Okta Workforce向けはOkta Integration Network経由で2026年8月、Auth0向けは7月末にEAが始まる予定です。つまり仕様と賛同企業は固まりつつある一方、本番投入できる対応SaaSはまだ拡大途上にあります。

日本企業が取るべき初動は、本格導入の前段にあります。自社で稼働中のAIエージェントと、各エージェントが握る静的APIキー・サービスアカウントを棚卸しし、同一IdPでのSSOを整える。この準備が、対応SaaSが出そろった瞬間にXAAへ移行できるかどうかを分けます。具体的な判断基準と準備作業は後半で詳述します。

Cross App Access（XAA）の定義と、AIエージェントが従来の認可を破綻させる理由

XAAが何を指すのかは、製品名と標準仕様を切り分けると理解しやすくなります。ここを混同すると「Okta独自の囲い込み機能」と誤解しがちですが、実態はオープン標準の実装です。

XAAの正体——OktaがIETF草案ID-JAGを製品化したOAuth拡張

XAA（Cross App Access）は、Oktaが付けた製品名です。その中身は、IETFのOAuthワーキンググループで標準化が進むIdentity Assertion JWT Authorization Grant（ID-JAG）という拡張仕様です。ID-JAGは2025年9月にWG草案として採択され、トークン種別をurn:ietf:params:oauth:token-type:id-jag、JWTの型をtyp=oauth-id-jag+jwtとして定義します。さらにその下敷きには、RFC 8693（Token Exchange）とRFC 7523（JWT Bearer Grant）という既存の標準があります。XAAはこれらを組み合わせた仕組みであり、OAuth 2.0の認可の仕組みを土台に拡張したものだと捉えると正確です。Oktaが標準化を主導していますが、ID-JAG自体は他のIdPでも実装できるオープン仕様である点が重要です。

同意画面前提のOAuthがAIエージェントで機能しない構造的な理由

従来のOAuthは、人間が画面の同意ボタンを押すことを前提に設計されています。AIエージェントはここでつまずきます。エージェントは処理を止めて同意画面を待てませんし、接続先ごとに長期間有効なAPIキーを抱え込むのも危険だからです。加えて同意画面そのものが攻撃面になります。偽の同意画面でユーザーに「許可」を押させ、IdPから不正にトークンを発行させる同意フィッシングです。同意操作に慣れたユーザーほど、文面を読まずに広い権限を渡してしまいます。XAAは、この同意操作自体をIdP側のポリシー審査に置き換えることで、構造的にこのリスクを断ちます。

非人間IDの急増でIT管理者が失う「誰が何にアクセスしたか」の可視性

AIエージェントは、人間とは別の「非人間ID」です。その数は急増しています。Oktaが引用するGartnerの予測では、2026年までにエンタープライズアプリの40%がタスク特化型のAIエージェントを搭載するとされます。問題は可視性です。ユーザーがAIツールにアプリ接続を許可するとき、IdPはユーザー認証までは把握できても、エージェントが実際に「1ファイルだけ」読むのか「データベース全体」を読むのかまでは見えません。アプリAからアプリBへの個別接続は各アプリ内で完結し、中央から一覧化・停止することが難しい。XAAは、この接続の裁定と監査ログをIdPに集約することで、管理者が失っていた可視性を取り戻します。

IdPが仲裁するXAAの仕組みと、2段階トークン交換の処理フロー

XAAの動作は、登場人物と手順に分けると具体的に追えます。鍵は、IdPが2通の「紹介状」を介在させる点です。

Requesting App・IdP・Resource Appという3者の役割分担

XAAには3つの役割が登場します。Requesting App（呼び出し元）は、データ取得を起こすAIエージェントや開発ツールです。2026年6月の発表では、Claude、Cursor、Docker、Visual Studio Code、ZoomのAIアシスタントなどがこれにあたります。Resource App（リソース側）は、要求されたデータを保持する下流のシステムで、Asana、Atlassian、Datadog、Figma、Slack、Supabaseなどが名を連ねます。そして中央に立つのがIdP（Okta）です。IdPが両者の信頼関係を仲裁し、接続可否をポリシーで裁きます。XAAがOpenID Connect（OIDC）のID情報を起点にする以上、この3者が同じIdPで連携していることが前提になります。

ID-JAG発行からアクセストークン取得までの4ステップ

処理は大きく4段階で進みます。ユーザーのクリックを挟まずに、IdPのポリシーで自動審査される点が従来との最大の違いです。

1. ユーザー認証（SSO）：ユーザーがOIDCで一度ログインし、IdPがID情報を確立する。
2. Token Exchange：Requesting AppがIdPへ、ログイン済みのIDトークンを材料に「Resource App宛ての紹介状（ID-JAG）」を要求する。IdPはポリシーを評価し、許可なら短命のID-JAGを発行する。
3. アクセストークン要求：Requesting Appが、受け取ったID-JAGをResource Appの認可サーバーへ提示する（JWT Bearer Grant）。認可サーバーは署名や発行者を検証する。
4. リソースアクセス：検証に成功すると、Resource App用のアクセストークンが返り、エージェントが目的のAPIを呼び出せる。

第2段階のリクエストは、grant_type=urn:ietf:params:oauth:grant-type:token-exchangeにrequested_token_typeとしてID-JAGを指定する形になります。宛先のResource Appはresourceパラメータで特定します。標準のトークン交換を素直に拡張した構造です。

refresh_token非推奨と短命トークンが即時遮断を成立させる設計

XAAの草案は、refresh_tokenの発行を推奨していません（SHOULD NOT）。理由は接続停止を即座に効かせるためです。長生きするrefresh_tokenをRequesting Appが握ると、管理者がAdmin Consoleで接続を停止しても、しばらくアクセスが残り得ます。そこでXAAは「必要になるたびにToken ExchangeでID-JAGを再発行する」設計を採ります。トークンを短命にしておけば、停止操作はそのまま新規交換のブロックとして働き、権限剥奪が即時に伝播します。エージェントの暴走時に「緊急停止」を効かせられるかどうかは、まさにこの設計に依存します。

従来のOAuth 2.0とXAAで異なる「裁定者・可視化・UX」の比較

同じOAuthの系譜でも、誰が接続を裁定し、どこまで可視化できるかが根本的に異なります。下表で要点を対比します。

表の通り、XAAはUX（同意疲れの解消）とガバナンス（中央統制）を同時に前進させます。ただし「IdPが裁定する」という性質上、IdPのポリシー設計が甘ければ統制も甘くなります。仕組みが守ってくれるのは経路であって、ポリシーの中身は運用側の責任です。

MCP・ゼロトラストとXAAが噛み合うエンタープライズAIセキュリティの構図

XAAは単独の機能ではなく、MCPやゼロトラストと組み合わさって初めて効果を発揮します。ここを押さえると、なぜ業界標準として広がりつつあるのかが見えてきます。

MCPの「Enterprise-Managed Authorization」にXAAが採用された意味

MCP（Model Context Protocol）は、AIエージェントがデータソースやAPIと通信する方法を定めます。ただしMCP自体は「どう通信するか」を扱い、「誰がアクセスを許可するか」までは管理しません。この空白を埋めたのが2025年11月のMCP仕様更新です。XAAが「Enterprise-Managed Authorization」という認可拡張として正式に組み込まれました。公式MCP SDKもXAA対応を進めており、2026年6月時点でTypeScriptとJavaが対応済み、Pythonが進行中です。結果として、これらのSDKで作られたエージェントは、独自のセキュリティ実装なしにエンタープライズ級の認可を利用できます。MCPサーバー側をリソースとして扱う設計は、FastMCPによるMCPサーバー構築を経験していると具体的にイメージしやすいはずです。

静的APIキーと長期シークレットを排除する最小権限・JITの実装

従来のエージェント連携の実態は、しばしば危うい構成でした。コードに静的APIキーが埋め込まれ、複数のエージェントが同一クレデンシャルを使い回し、長期間有効なシークレットが放置される。これらは常時有効な権限（standing privilege）を生み、攻撃面を広げます。XAAは、接続のたびに発行する短命トークンでこれを置き換えます。エージェントには必要なスコープだけを、必要なときにだけ渡す。最小権限とジャストインタイム（JIT）のアクセス制御を、運用の力技ではなくプロトコルの設計として実現する点が要諦です。

同意画面フィッシングとConfused Deputyに対する防御効果と限界

XAAが効くリスクは具体的です。第一に同意フィッシング。XAA環境では同意画面が原則出ないため、同意画面が表示されること自体が「要注意」のシグナルになります。第二にConfused Deputy（混乱した代理）問題。過剰な権限を持つエージェントが、別の主体に成り代わって意図しない操作を起こす類型で、AIエージェントの事故事例として語られてきました。XAAはIDと権限の文脈をトークンに正しく載せ、IdPで裁定することで、この種の権限取り違えを抑えます。ただし限界もはっきりしています。XAAはアプリ間の認可経路を守りますが、エージェント内部のプロンプトインジェクションや、ハルシネーションそのものを防ぐ仕組みではありません。守備範囲を「接続の認可」に限定して理解することが、過信を避ける鍵です。

XAAを今導入すべき企業と、まだ見送るべき企業を分ける判断基準

ここからは立場を明確にします。2026年6月時点のXAAは、すべての企業が今すぐ本番導入すべき技術ではありません。一方で、検証と準備を始める価値がある企業は確実に存在します。線引きを具体的な条件で示します。

既存方式（APIキー・個別OAuth同意・SAML SSO・MCP単体）との使い分け

XAAは万能の置き換えではなく、適材適所です。今ある方式とどう棲み分けるかを整理します。

判断の軸はシンプルです。守りたいのが「人間のログイン」ならSSOのまま、「エージェントの接続認可」ならXAAの検討に入る。SSOとMCPは敵ではなく、XAAが噛み合う土台です。

XAA採用が過剰になり、見送りを推奨する具体的な条件

次の条件に当てはまるなら、現時点での本番導入は過剰です。第一に、社内でAIエージェントをまだ本番運用しておらず、人間のSSOだけで足りている企業。XAAが解く「エージェントの認可」という課題自体が顕在化していないため、投資が先行しすぎます。第二に、連携したいSaaSがまだXAAに対応していないケース。XAAは接続の両側（Requesting AppとResource App）が対応して初めて機能するため、片側だけでは動きません。第三に、IdPをOktaやAuth0などXAA対応基盤に寄せておらず、複数IdPが分立している企業。現行のID-JAG草案は、同一エンタープライズIdPでSSO済みであることを信頼境界の前提に置きます。これらに該当するなら、急ぐべきは導入ではなく前提整備です。

導入前に満たすべき前提——同一IdPでのSSOとEA有効化

逆に、検証を始める価値がある企業の条件も明確です。すでにOktaを全社IdPとして運用し、主要SaaSのSSOを集約できている。社内でAIエージェントの本番利用が始まり、エージェントが握るクレデンシャルの可視化に課題を感じている。この2点が揃うなら、Okta Admin Consoleの設定からCross App AccessをEarly Access機能として有効化し、サンプルアプリで挙動を確認する段階に進めます。Oktaが公開するサンプルでは、Requesting App役のAgent0とResource App役のTodo0を使い、接続の同意付与とトークン交換の流れを実機で追えます。本番SaaSの対応を待つ間に、この検証で社内の理解と運用設計を固めておくことが、移行の速さに直結します。

2026年のXAA提供ロードマップと、日本企業が着手できる準備作業

XAAは段階的に提供が広がっています。時期と対応状況を正確に押さえておくと、自社の動き出しのタイミングを誤りません。

Early Access・OIN（8月）・Auth0（7月末）の提供時期と対応アプリの現状

2026年6月時点のステータスを時系列で整理します。XAAは2025年6月にOktaが発表し、2026年1月からEarly Accessとして提供が始まりました。2026年6月には、Requesting App・Resource App・接続基盤（Cloudflare、Keycloak、WorkOS、Stytchなど）を含む25社以上の連携が公表されています。提供時期は、Okta Workforce顧客向けがOkta Integration Network経由で2026年8月開始予定、Auth0のB2B SaaS開発者向けが2026年7月末にEA予定です。Anthropicのベータプログラムでは、OktaをIdPとしてRamp・Webflow・HubSpotがClaudeのMCPプロバイダー接続を統制する実運用も始まっています。一方で、XAA対応を本番提供するSaaSはまだ限られ、仕様もドラフト段階で今後変わり得ます。「もう全社展開できる」段階ではない、という現実は押さえておくべきです。

対応SaaS拡大を待つ間に進める棚卸しとアクセスポリシー設計

対応SaaSの拡大は他社任せですが、自社で前倒しできる作業は多くあります。まず、稼働中のAIエージェントを全数リスト化し、各エージェントが使うサービスアカウントや静的APIキーを洗い出す。使い回しや埋め込みシークレットが見つかれば、それが最初に塞ぐべき穴です。次に、IdPに寄せるべきSSO連携を点検し、XAAが前提とする同一IdP環境を整える。さらに、エージェントごとに「どのアプリへ、どのスコープで、どの条件下なら許可するか」というアクセスポリシーの草案を、ビジネス部門と作っておく。XAAが本番化したとき、技術的な有効化よりもポリシー合意のほうが時間を要するからです。準備が済んだ企業から、対応SaaSが出そろった瞬間に移行できます。

Cross App Access（XAA）に関するよくある質問

導入検討の現場でよく挙がる疑問を、仕様と最新ステータスに基づいて簡潔に整理します。

XAAとID-JAGは何が違うのですか？

ID-JAGは、IETFのOAuthワーキンググループで標準化が進む拡張仕様（Identity Assertion JWT Authorization Grant）の名称です。XAA（Cross App Access）は、そのID-JAGをOktaが実装した製品ブランド名です。標準とその実装の関係にあたり、本記事では実務上ほぼ同義として扱っています。ID-JAGはオープン標準のため、Okta以外のIdPでも実装可能です。

Cross App Accessを使うと既存のSSOやIdPは置き換えが必要ですか？

必要ありません。XAAは既存のSSOやIdPを置き換えるのではなく、OAuthとOIDCを拡張してその上に乗る仕組みです。組織は現在のIdPを使い続けたまま、プロトコルに対応したアプリに対してXAAを有効化します。むしろ既存のSSOが整っていることが、XAAを機能させる前提になります。

2026年時点でCross App Accessに対応しているアプリはありますか？

2026年6月に25社以上の連携が公表され、Requesting App側にClaude・Cursor・Docker・VS Code・Zoom、Resource App側にAsana・Atlassian・Datadog・Figma・Slack・Supabaseなどが含まれます。ただし提供は段階的で、Okta Workforce向けはOIN経由で2026年8月、Auth0向けは7月末にEAが始まる予定です。本番で使える対応アプリは拡大途上だと理解してください。

XAAとMCPはどのような関係にありますか？

補完関係です。MCPはエージェントとデータ源の通信方法を定めますが、アクセス許可の管理までは扱いません。2025年11月のMCP仕様更新で、XAAが「Enterprise-Managed Authorization」という認可拡張として正式に追加され、この空白を埋めました。MCPが通信の規約、XAAがその認可層という分担です。

Cross App Accessはどこで有効化し、無料で試せますか？

Okta Admin Consoleの設定画面から、Cross App AccessをEarly Access機能として有効化できます。Oktaは無料のIntegrator向けプランやサンプルアプリ（Agent0・Todo0）、ブラウザ上で挙動を試せるプレイグラウンドを公開しており、自社環境を用意せずにトークン交換の流れを確認できます。本番導入の前に、まずこれらで仕組みを把握するのが現実的です。

関連記事

• Okta（オクタ）とは？クラウドID管理サービスの概要と最新動向：XAAの前提となるOktaのIDaaS・SSOとしての基本機能を理解できます。
• GitHub SSOの概要とその導入によるメリットとは：XAAが土台とするSSOの具体的な設定例として参考になります。