こんにちは、ネクストモードのゆきなわです。
Okta 社の年次イベント Oktane 2026 も最終日となりました。
9月24日のセッション「Unblocking the agentic enterprise: How Cross App Access secures AI connections」では、Cross App Access（XAA）の共同策定者と、XAA の導入・運用に携わった登壇者がパネルディスカッションを行いました。
本記事では、AI エージェント接続の現場で何が問題になっているのか、XAA が接続をどう管理するのか、そして導入後に利用者の行動がどう変わったのかをレポートします。
Cross App Access の共同策定者と、導入・運用に携わった登壇者によるパネルディスカッション
30分間のディスカッションでは、仕様の説明だけでなく、社内で AI エージェントを展開したときに起きた問題、XAA の実装作業、導入後の利用状況まで、4人それぞれの立場から具体的な話が続きました。
登壇者の組織では、ChatGPT、Claude、Cursor、社内エージェント基盤などの利用が急速に広がっています。規模が大きくなるにつれ、次の課題が表面化しました。
求められているのは、利用者へ注意を促し続けることではなく、安全な接続方法を最も簡単な選択肢にすることです。
Cross App Access（XAA） は、AI エージェントやアプリ間の接続を企業の Identity Provider（IdP）で管理するための OAuth 拡張です。MCP が AI エージェントとデータやツールをつなぐ標準的なインターフェースを提供するのに対し、XAA は利用者のアイデンティティに基づく認可を接続へ与えます。
Enterprise IdP を介して AI エージェントと業務アプリを接続する XAA の全体像
従来は、利用者が AI ツールから Google、Slack などへ接続するたびにログインし、同意画面を進める必要がありました。XAA では、接続を要求するアプリ（Requesting app）が企業の IdP へ認可を求め、IdP が利用者の状態と管理者の接続ポリシーを確認します。許可されると、IdP は利用者と要求元アプリの関係を示す署名付きの Identity Assertion を発行します。これは ID-JAG（Identity Assertion JWT Authorization Grant）で使われる情報です。データや機能を提供するアプリ（Resource app）側の認可サーバーが Identity Assertion を検証し、アクセストークンを発行します。
Requesting app、IdP、Resource app の間で XAA がアクセスを制御する流れ
セッションでは、通常の MCP 接続で 8〜30日間有効なアクセストークンが使われ、macOS のキーチェーンやテキストファイルに保存される場合があると紹介されました。XAA では IdP を接続の制御点とし、有効期間の短いトークン（short-lived token）を更新する設計を取りやすくなります。
| 観点 | 従来の個別接続 | XAA を使う接続 |
|---|---|---|
| 利用者の操作 | 接続先ごとにログイン・同意 | IdP のポリシーに基づいて認可 |
| 権限 | 接続ごとに広いスコープを許可しがち | 必要なスコープに絞る |
| アクセストークン | 実装によっては8〜30日間有効で端末に保存 | 有効期間を短くし、IdP を介して更新 |
| 失効 | 接続先ごとに確認 | IdP で新規発行を止め、既存トークンは接続先で失効または期限切れ |
| 監査 | 接続先ごとに分散 | 接続ポリシーを IdP で一元的に把握 |
Aaron Parecki 氏は XAA を「API アクセスのための SSO」と表現しました。利用者に認証操作を繰り返させず、企業側は IdP を中心に接続を管理するという価値を端的に表した言葉です。
HubSpot の Andrew Meinert 氏は、数千人の利用者と数十から数百のアプリがある環境では、接続ごとの同意が掛け算で増えていくと説明しました。LLM は参照できるコンテキストがあってこそ価値を発揮しますが、利用者が一つずつ接続しなければならない構成では、使い始めた初日から十分な価値を得られません。
Cameron Leavenworth 氏は、Ramp で XAA の早期導入を担当し、現在は Legora に所属しています。Ramp では、段階的な立ち上げを一つずつ進めなくても、利用者が使い始めた初日から社内情報へアクセスできる状態を目指したと説明しました。社内サポート向けの Serval では、利用者が行き詰まったときに Serval MCP 経由でサポートチームへ助けを求められ、XAA の存在を意識しないまま安全な接続を使えていたそうです。
Okta 社内の導入担当者からは、社内エージェント「Dex」と社内 AI ゲートウェイで XAA を実装した経験が共有されました。XAA 対応を3つのアプリへ実装し、別のチームでも作業を再現できるよう社内手順を用意したとのことです。また、XAA 対応後、Slack MCP は社内で最も利用されている MCP 接続になったとのことです。安全な経路を簡単に使えるようにしたことで、利用者の行動が実際に変わった例です。
Okta の公開情報では、Anthropic（Claude）、Zoom、Slack を含む 25以上の早期採用サービスが案内されています。掲載したセッションスライドで判読できる範囲では、Notion、Linear、Slack、Zoom など、AI ツール、業務アプリ、開発基盤をまたぐ多数のサービスが並んでいます。
拡大する Cross App Access エコシステム。AI ツール、業務アプリ、開発基盤まで幅広いサービスが並ぶ
終盤の短答コーナー（ライトニングラウンド）では、導入の始め方について次の助言が出ました。
IT 部門が一度 XAA 対応を実装すれば、その効果は全社に及びます。利用者が認証画面を進める時間も、うまく接続できないという問い合わせへの対応も、そのぶん減っていきます。
一方で、業務で広く使われていてもまだ XAA に対応していないサービスもあります。よく使われている接続先を振り返る場面では、エコシステムの一覧に Google Workspace の名前がないことに触れ、「この会場に Google の方がいるなら、ぜひ XAA を実装してほしい」と呼びかける登壇者もいました。他の登壇者からも、AI エージェントが承認のないままメールを送ってしまうような操作こそ、アイデンティティの層で制御したいという声が上がりました。
Slack チャンネルのように複数人が参加する場所で動くエージェントは、エージェント自身のアイデンティティを持ちながら、操作した利用者ごとの権限も尊重する必要があります。高い権限を持つサービスアカウントをそのまま使えば、ある利用者だけが見られる情報が別の利用者への応答に含まれる恐れがあります。
ディスカッション終盤では、Agentic Discovery が次の課題として挙げられました。利用可能な MCP サーバーをエージェントが動的に発見できれば、利用者が接続先を事前にすべて登録する必要はありません。同時に、あらゆる MCP を常にコンテキストへ追加するのではなく、必要な接続だけを選び、コンテキストの消費量（LLM のトークン）を抑えられます。
ネクストモードブログでは XAA の発表背景、技術仕様、実サービスとの接続を継続して紹介しています。本記事で XAA に興味を持たれた方は、あわせて是非お読みください。
今回のパネルディスカッションから見えてきたのは、XAA がセキュリティのために利用者へ手間を求める仕組みではなく、アプリ間接続の判断を個人の同意から企業の IdP へ移す仕組みだということです。
プロトコルの共同策定者と導入・運用担当者の具体的な話から、安全な経路を簡単に使える状態にすることが、AI エージェントの活用を広げる前提になると感じました。
引き続き現地からのレポートをお楽しみに！
ネクストモードでは Okta の導入から運用までを支援しています。Okta や AI エージェントのアイデンティティ管理に関するご相談は、ネクストモードまでお気軽にお問い合わせください。