【Oktane26】セッション：AI エージェント接続の安全と使いやすさを両立する Cross App Access

» Okta » イベントレポート » AI » Oktane26
yuki yuki

はじめに

こんにちは、ネクストモードのゆきなわです。

Okta 社の年次イベント Oktane 2026 も最終日となりました。

9月24日のセッション「Unblocking the agentic enterprise: How Cross App Access secures AI connections」では、Cross App Access（XAA）の共同策定者と、XAA の導入・運用に携わった登壇者がパネルディスカッションを行いました。

本記事では、AI エージェント接続の現場で何が問題になっているのか、XAA が接続をどう管理するのか、そして導入後に利用者の行動がどう変わったのかをレポートします。

セッション概要

  • 日時：2026年9月24日（現地時間）
  • タイトル：Unblocking the agentic enterprise: How Cross App Access secures AI connections
  • 登壇者：
    • Aaron Parecki 氏：Director of Identity Standards、Okta。XAA 仕様の共同策定者
    • Cameron Leavenworth 氏：Member of Technical Staff、Legora。Ramp で XAA の早期導入を担当
    • Andrew Meinert 氏：Director, System Operations & AI、HubSpot, Inc.
    • Dennis Henry 氏：Enterprise Architect、Okta
  • セッションタイプ：Breakouts

oktane26-cross-app-access-ai-agents-01-panel-discussion

Cross App Access の共同策定者と、導入・運用に携わった登壇者によるパネルディスカッション

30分間のディスカッションでは、仕様の説明だけでなく、社内で AI エージェントを展開したときに起きた問題、XAA の実装作業、導入後の利用状況まで、4人それぞれの立場から具体的な話が続きました。

AI エージェントの普及で表面化した課題

登壇者の組織では、ChatGPT、Claude、Cursor、社内エージェント基盤などの利用が急速に広がっています。規模が大きくなるにつれ、次の課題が表面化しました。

  1. 広い権限のサービスアカウントが増える
    • 利用者や開発チームが、必要なサービスや権限を十分に整理しないまま、広い権限を持つサービスアカウントを大量に申請するケースがあります。
  2. 利用者の権限とエージェントの実行権限が混ざる
    • 共有エージェントで利用者ごとのセッションや権限を分離できなければ、ある利用者だけが見られる情報が、別の利用者への応答に含まれる可能性があります。
  3. 安全な方法が面倒だと非公式な経路が選ばれる
    • 安全な接続方法が面倒だと、利用者は手早く動く非公式な方法を選びます。ディスカッションでは、利用者が危険な使い方を望んでいるのではなく、最も簡単な方法を選んでいるという指摘が繰り返されました。
  4. どの MCP サーバーを使うべきか分からなくなる
    • 接続先が増えるほど、利用者やエージェントが必要な MCP サーバーを見つけること自体が課題になります。

求められているのは、利用者へ注意を促し続けることではなく、安全な接続方法を最も簡単な選択肢にすることです。

Cross App Access の仕組み：IdP がアプリ間の接続を仲介する

Cross App Access（XAA） は、AI エージェントやアプリ間の接続を企業の Identity Provider（IdP）で管理するための OAuth 拡張です。MCP が AI エージェントとデータやツールをつなぐ標準的なインターフェースを提供するのに対し、XAA は利用者のアイデンティティに基づく認可を接続へ与えます。

oktane26-cross-app-access-ai-agents-02-enterprise-access-model

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 を検証し、アクセストークンを発行します。

oktane26-cross-app-access-ai-agents-03-xaa-flow

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：同意操作が掛け算で増える

HubSpot の Andrew Meinert 氏は、数千人の利用者と数十から数百のアプリがある環境では、接続ごとの同意が掛け算で増えていくと説明しました。LLM は参照できるコンテキストがあってこそ価値を発揮しますが、利用者が一つずつ接続しなければならない構成では、使い始めた初日から十分な価値を得られません。

Ramp：初日から使える安全な接続

Cameron Leavenworth 氏は、Ramp で XAA の早期導入を担当し、現在は Legora に所属しています。Ramp では、段階的な立ち上げを一つずつ進めなくても、利用者が使い始めた初日から社内情報へアクセスできる状態を目指したと説明しました。社内サポート向けの Serval では、利用者が行き詰まったときに Serval MCP 経由でサポートチームへ助けを求められ、XAA の存在を意識しないまま安全な接続を使えていたそうです。

Okta 社内：実装手順の標準化と Slack MCP の利用拡大

Okta 社内の導入担当者からは、社内エージェント「Dex」と社内 AI ゲートウェイで XAA を実装した経験が共有されました。XAA 対応を3つのアプリへ実装し、別のチームでも作業を再現できるよう社内手順を用意したとのことです。また、XAA 対応後、Slack MCP は社内で最も利用されている MCP 接続になったとのことです。安全な経路を簡単に使えるようにしたことで、利用者の行動が実際に変わった例です。

対応サービスの広がりと導入の進め方

Okta の公開情報では、Anthropic（Claude）、Zoom、Slack を含む 25以上の早期採用サービスが案内されています。掲載したセッションスライドで判読できる範囲では、Notion、Linear、Slack、Zoom など、AI ツール、業務アプリ、開発基盤をまたぐ多数のサービスが並んでいます。

oktane26-cross-app-access-ai-agents-04-ecosystem

拡大する Cross App Access エコシステム。AI ツール、業務アプリ、開発基盤まで幅広いサービスが並ぶ

終盤の短答コーナー（ライトニングラウンド）では、導入の始め方について次の助言が出ました。

  • 組織で最も利用されている対応アプリを一つ選ぶ
  • 小さく始める場合も、IT 部門が提供する安全な経路を最初から使える状態にする
  • 公式ドキュメントを読むところから始める。構えるような分量ではなく、設定手順も3つほどにまとまっている
  • 利用者が個別に資格情報やアプリを作る時間まで含めて投資対効果を見る

IT 部門が一度 XAA 対応を実装すれば、その効果は全社に及びます。利用者が認証画面を進める時間も、うまく接続できないという問い合わせへの対応も、そのぶん減っていきます。

一方で、業務で広く使われていてもまだ XAA に対応していないサービスもあります。よく使われている接続先を振り返る場面では、エコシステムの一覧に Google Workspace  の名前がないことに触れ、「この会場に Google の方がいるなら、ぜひ XAA を実装してほしい」と呼びかける登壇者もいました。他の登壇者からも、AI エージェントが承認のないままメールを送ってしまうような操作こそ、アイデンティティの層で制御したいという声が上がりました。

次の課題：マルチプレイヤーエージェントと Agentic Discovery

共有の場で動くマルチプレイヤーエージェント

Slack チャンネルのように複数人が参加する場所で動くエージェントは、エージェント自身のアイデンティティを持ちながら、操作した利用者ごとの権限も尊重する必要があります。高い権限を持つサービスアカウントをそのまま使えば、ある利用者だけが見られる情報が別の利用者への応答に含まれる恐れがあります。

必要な MCP だけを見つける Agentic Discovery

ディスカッション終盤では、Agentic Discovery が次の課題として挙げられました。利用可能な MCP サーバーをエージェントが動的に発見できれば、利用者が接続先を事前にすべて登録する必要はありません。同時に、あらゆる MCP を常にコンテキストへ追加するのではなく、必要な接続だけを選び、コンテキストの消費量（LLM のトークン）を抑えられます。

関連記事：ネクストモードのブログで XAA の背景と実装をさらに知る

ネクストモードブログでは XAA の発表背景、技術仕様、実サービスとの接続を継続して紹介しています。本記事で XAA に興味を持たれた方は、あわせて是非お読みください。

おわりに

今回のパネルディスカッションから見えてきたのは、XAA がセキュリティのために利用者へ手間を求める仕組みではなく、アプリ間接続の判断を個人の同意から企業の IdP へ移す仕組みだということです。

プロトコルの共同策定者と導入・運用担当者の具体的な話から、安全な経路を簡単に使える状態にすることが、AI エージェントの活用を広げる前提になると感じました。

引き続き現地からのレポートをお楽しみに！

Okta に関するお問い合わせ

ネクストモードでは Okta の導入から運用までを支援しています。Okta や AI エージェントのアイデンティティ管理に関するご相談は、ネクストモードまでお気軽にお問い合わせください。

SaaSバナー_Okta