---
title: "Auth0 for AI Agentsとは？Token Vault・CIBAの設定手順とSDK対応状況・料金【2026年11月】"
url: "https://www.issoh.co.jp/tech/details/9411/"
published: 2025-10-21
updated: 2026-11-08
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# Auth0 for AI Agentsとは？Token Vault・CIBAの設定手順とSDK対応状況・料金【2026年11月】

Auth0 for AI Agentsは、AIエージェントがユーザーの代わりに外部APIを呼んだり、社内文書を検索したり、決済のような操作を実行したりする場面の認証・認可を、Auth0の上で扱うための機能群です。この記事では、何ができるかに加えて、Token Vaultと非同期認可（CIBA）を動かすまでの設定、2026年11月時点のSDKの対応範囲、詰まりやすいエラー、料金の条件を一次情報で確認していきます。

## まとめ：Auth0 for AI Agentsの要点

- **提供状況**：2025年4月のDeveloper Previewを経て、**2025年11月19日に一般提供（GA）**。MCPサーバー向けのAuth for MCPも2026年5月6日にGAしました。Agents as PrincipalやCross App Access（XAA）など、2026年夏以降に追加された機能はEarly Accessです。
- **中核の4機能**：ユーザー認証、Token Vault（外部APIのトークン保管と交換）、非同期認可（CIBAによる人間の承認）、FGA for RAG（文書単位の閲覧制御）。
- **設定で詰まる箇所**：Token Vaultはリフレッシュトークンのローテーションを有効にしたままでは使えません。CIBAの通知はプッシュかメールかが `requested_expiry` の秒数で決まり、SDKの既定300秒ではプッシュ側になります。
- **SDKの現状**：JavaScript版の最新は2026年4月22日公開のまま更新がなく、Vercel AI SDK 7とLangChain 1.xは依存範囲の外です。新規プロジェクトでは `ai@6` や LangChain 0.3系に揃える必要があります。
- **料金**：無料プランではCIBAが使えません。Token Vaultの接続数は無料で2つ、Essentials・Professionalで3つ、Enterpriseで4つが基本枠で、それ以上はアドオンです。

## Auth0 for AI Agentsとは｜4つの機能と提供段階

### 「Auth for GenAI」「Auth0 Gen for AI」との関係

正式な製品名は**Auth0 for AI Agents**です。2025年4月の最初の発表では「Auth for GenAI」と呼ばれており、発表記事のURL（`introducing-auth-for-genai`）やデモ用リポジトリ `auth0/auth-for-genai` にその名前が残っています。検索で「auth0 genai」「auth0 for genai」と調べても、指しているのは同じ製品です。

一方「Auth0 Gen for AI」という表記は、Auth0の発表記事・製品ページ・ドキュメントのいずれにも出てきません。この名前で書かれた解説を読むときは、出典を確かめてください。

### 機能ごとの提供段階（2026年11月時点）

GAは製品全体の区切りで、その後に追加された機能はそれぞれ別の段階にあります。[Auth0のchangelog](https://auth0.com/changelog)から、AIエージェントに関わる項目を拾うと次のとおりです。

| 機能                              | 提供段階              | 日付                  |
| ------------------------------- | ----------------- | ------------------- |
| Auth0 for AI Agents（4機能）        | GA                | 2025年11月19日         |
| CIBA（非同期認可の基盤）                  | GA                | 2025年5月21日（v202520） |
| Auth for MCP                    | GA                | 2026年5月6日           |
| Token Vaultの組織（Organizations）対応 | GA                | 2026年5月28日          |
| XAA（リソースアプリ側）                   | Open Early Access | 2026年7月27日          |
| Agents as Principal             | Early Access      | 2026年7月30日          |
| Token Vault Privileged Worker   | Early Access      | 2026年7月30日          |
| CIMDの動的登録                       | Early Access      | 2026年10月22日         |

Auth0の[提供段階の定義](https://auth0.com/docs/troubleshoot/product-lifecycle/product-release-stages)では、Early Accessも本番環境で使えますが、GAまでに小さな変更が入りうるとされています。設計の土台にはGAの機能を置き、Early Accessの機能は変更に追随できる範囲で使うのが無難です。Agents as PrincipalやOBOトークン交換など2026年に追加された機能の中身は[Auth0 for AI Agentsの新機能5つ：Agent as Principal・OBO・FGA索引の提供状況【2026年10月】](/tech/details/12263/)で、MCPクライアントを事前登録なしで受け入れるCIMDは[CIMD（Client ID Metadata Documents）とは？MCPでDCRに代わるOAuthクライアント登録の仕組みと実装【2026年10月】](/tech/details/10011/)で扱っています。

### 4機能と解く課題の対応

| 機能          | 解く課題                            | 使う仕組み            |
| ----------- | ------------------------------- | ---------------- |
| ユーザー認証      | エージェントを操作しているのが誰かを確定する          | Universal Login  |
| Token Vault | Google・Slack・GitHubなどをユーザー代理で呼ぶ | トークン交換と保管        |
| 非同期認可       | 決済などの直前に人間の承認を挟む                | CIBA（任意でRAR）     |
| FGA for RAG | 閲覧権のある文書だけをLLMへ渡す               | Auth0 FGA（ReBAC） |

Token Vaultが要るのは、他社が持つAPIを呼ぶときだけです。自社のAPIを呼ぶだけなら、通常のOAuth 2.0の委任とスコープ設計で足ります。委任の基本は[OAuthとは？OAuth 2.0の仕組み・認証と認可の違いとOAuth 2.1の現状をわかりやすく解説](/tech/details/8369/)を参照してください。

## Token Vaultの設定手順｜外部APIのユーザー代理呼び出し

Token Vaultは、ユーザーが外部サービスとの接続を許可したときに、そのサービスのアクセストークンとリフレッシュトークンをAuth0側に保管します。エージェントは必要になったときにAuth0のトークンと交換して外部のアクセストークンを受け取るので、外部サービスの鍵をエージェントのコードや環境変数に置かずに済みます。

### 使えるアプリケーションの条件とグラントタイプ

[Token Vaultの設定ドキュメント](https://auth0.com/docs/secure/call-apis-on-users-behalf/token-vault/configure-token-vault)は、このグラントタイプを使えるクライアントを3条件に絞っています。ファーストパーティであること（`is_first_party: true`）、認証手段を持つコンフィデンシャルクライアントであること（`token_endpoint_auth_method` が `none` でない）、OIDC準拠であること（`oidc_conformant: true`）です。ブラウザだけで完結するSPAは2つ目を満たさないため、後述のアクセストークン交換を使います。

Webアプリでリフレッシュトークン交換を使う場合は、ダッシュボードのアプリケーション設定で **Advanced Settings > Grant Types** を開き、Refresh Token・Authorization Code・Token Vaultの3つを有効にします。

### Connected AccountsとMy Account APIの準備

外部サービスのトークンをToken Vaultへ入れる経路は、ログインとは別の「Connected Accounts」フローです。My Account APIの `/me/v1/connected-accounts/connect` を呼んでユーザーを外部サービスの同意画面へ送り、戻ってきた `connect_code` を `/complete` に渡すと保管が完了します。[Connected Accountsのドキュメント](https://auth0.com/docs/secure/call-apis-on-users-behalf/token-vault/connected-accounts-for-token-vault)では、事前にMy Account APIを有効化してアプリケーションにConnected Accountsのスコープを許可し、My Account API用のアクセストークンを得るためにMulti-Resource Refresh Token（MRRT）を設定するよう求めています。

外部接続ごとに「Authentication」と「Connected Accounts」の用途を切り替えられます。ログインには使わずトークン保管だけに使う接続は、Authenticationをオフ、Connected Accountsをオンにします。

### リフレッシュトークン交換のリクエスト

エージェントが外部APIを呼ぶ直前に、Auth0のリフレッシュトークンを `/oauth/token` へ渡して外部サービスのアクセストークンを受け取ります。リクエストの形は次のとおりです。

```
curl -X POST https://{YOUR_DOMAIN}/oauth/token \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token",
    "client_id": "{CLIENT_ID}",
    "client_secret": "{CLIENT_SECRET}",
    "subject_token": "{AUTH0_REFRESH_TOKEN}",
    "subject_token_type": "urn:ietf:params:oauth:token-type:refresh_token",
    "requested_token_type": "http://auth0.com/oauth/token-type/federated-connection-access-token",
    "connection": "google-oauth2"
  }'
```

保管中の外部アクセストークンが期限切れなら、Auth0が保管済みの外部リフレッシュトークンで新しいものを取り直して返します。同じ接続に仕事用と個人用など複数のアカウントがあるユーザーでは、`login_hint` でどちらのアカウントかを指定します。

### SPA構成ではバックエンドAPIによるアクセストークン交換

SPAが自社のバックエンドAPIを呼ぶとき、渡るのは `Authorization` ヘッダーのAuth0アクセストークンだけです。[アクセストークン交換のドキュメント](https://auth0.com/docs/secure/call-apis-on-users-behalf/token-vault/access-token-exchange-with-token-vault)のとおり、バックエンドはSPAのリフレッシュトークンを受け取らないため、受け取ったアクセストークンを検証したうえで、それを外部サービスのアクセストークンと交換します。AI向けドキュメントは、リフレッシュトークンを扱えないヘッドレスなエージェントやCLIもこの方式の対象に挙げています。交換に使うのは、バックエンドAPIと同じ識別子で作る「Custom API Client」で、Token Vaultのグラントタイプが最初から有効になっています。フロントエンドに外部サービスのトークンを一切渡さない構成になるので、エージェントをブラウザ上で動かす場合はこちらを選んでください。

## 非同期認可（CIBA）の実装｜人間による承認フロー

非同期認可は、エージェントが送金・発注・本番環境の変更といった取り消しにくい操作をする直前に、ユーザーの別の端末へ承認依頼を送る仕組みです。Auth0はOpenID FoundationのCIBA（Client-Initiated Backchannel Authentication）で実装しており、承認内容を構造化して見せたいときはRAR（Rich Authorization Requests）を組み合わせます。

### CIBAの有効化とbc-authorizeからトークン発行までの流れ

最初にダッシュボードの Applications > Applications で対象アプリを開き、Grant Types で Client Initiated Backchannel Authentication (CIBA) を有効にします。使えるのは、Token Vaultと同じくファーストパーティ・コンフィデンシャル・OIDC準拠のクライアントだけです。続いて通知チャネルを有効にします。プッシュにはGuardianの有効化と承認するユーザーのプッシュMFA登録が、メールには確認済みのメールアドレス、Asynchronous Approvalのメールテンプレート、本番用のメールプロバイダーが必要です。そのうえで、処理は次の順に進みます。

1. エージェントのバックエンドが `/bc-authorize` へ、ユーザー識別子（`login_hint`）・`binding_message`・スコープを送ります。
2. Auth0が `auth_req_id` と `expires_in`・`interval` を返します。
3. バックエンドは `auth_req_id` を使って `/token` をポーリングします。承認前は `authorization_pending` が返ります。
4. ユーザーが端末で承認すると次のポーリングでアクセストークンが発行され、拒否すると `access_denied` になります。

[CIBAのフロー解説](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authorization-with-ciba)によると、ポーリング間隔はおよそ5秒です。短い間隔で叩くと `slow_down` が返り、指定された秒数まで待つよう求められます。

### 通知チャネルの選択条件とrequested\_expiry

使える通知チャネルは、Auth0 Guardian（またはGuardian SDKを組み込んだ自社アプリ）へのプッシュ通知と、メールの2つです。製品の概要文にはSMSも挙がっていますが、ドキュメントで「現在利用できるオプション」として並ぶのはこの2つだけです。

両方のチャネルを有効にしたとき、どちらを使うかは承認の有効期間 `requested_expiry` で選ばれます。[CIBAの設定ドキュメント](https://auth0.com/docs/get-started/applications/configure-client-initiated-backchannel-authentication)の規定は次のとおりです。

| requested\_expiry  | 使われるチャネル | 条件                            |
| ------------------ | -------- | ----------------------------- |
| 300秒以下             | モバイルプッシュ | ユーザーがGuardianのプッシュをMFA登録済み    |
| 301〜259,200秒（72時間） | メール      | 有料プラン＋Auth0 for AI Agentsアドオン |

JavaScript SDK（`@auth0/ai` 6.0.2）の非同期認可は、`requestedExpiry` を指定しないと300秒を送ります（配布物の `AsyncAuthorizerBase.js` で確認）。つまり何も指定しなければプッシュが選ばれます。「上長が翌朝メールで承認する」ような運用で最初からメールを選ばせたいなら、`requestedExpiry` を301〜259,200秒の範囲で指定します。これとは別に、プッシュのMFAを登録していないユーザーには、メールが有効になっていればメールで通知が送られます（依頼は拒否されません）。

### binding\_messageの文字数と文字種の制約

承認画面に表示される `binding_message` は必須で、仕様上は**最大64文字、使える文字は英数字と `+-_.,:#`** と定められています。日本語で「◯◯社へ5万円を送金しますか」と出す設計はこの規定から外れるため、文言は英数字で組み、金額や宛先など判断に必要な値を必ず入れてください。「Approve this action」のような汎用文では、承認する側が何に同意したのか分かりません。

### Vercel AI SDKのツールへの承認の組み込み

Vercel AI SDK向けの `@auth0/ai-vercel` では、ツールを `withAsyncAuthorization` で包むと、実行前に承認を求めるようになります。SDKはAuth0の接続情報をサーバー側の環境変数 `AUTH0_DOMAIN`・`AUTH0_CLIENT_ID`・`AUTH0_CLIENT_SECRET` から読みます（`@auth0/ai` 6.0.2の配布物で確認）。下の例では、確認文を規定の文字種と64文字に収めるため、商品はASCIIの商品IDで受け取り、組み立てた文を送る前に検証しています。

```
import { Auth0AI } from "@auth0/ai-vercel";
import { AccessDeniedInterrupt } from "@auth0/ai/interrupts";
import { getUser } from "./auth0";

const auth0AI = new Auth0AI();

// 公式の許可文字（英数字と +-_.,:#）と64文字以内に収める
const BINDING_MESSAGE = /^[A-Za-z0-9+\-_.,:#]{1,64}$/;

export const withAsyncAuthorization = auth0AI.withAsyncAuthorization({
  userID: async () => {
    const user = await getUser();
    if (!user?.sub) throw new Error("User is not signed in");
    return user.sub;
  },
  bindingMessage: async ({ productId, qty }) => {
    const message = `Buy:${qty}:${productId}`;
    if (!Number.isInteger(qty) || !BINDING_MESSAGE.test(message)) {
      throw new Error("Invalid binding message");
    }
    return message;
  },
  scopes: ["openid", "product:buy"],
  audience: process.env["SHOP_API_AUDIENCE"]!,
  requestedExpiry: 300,
  onUnauthorized: async (e: Error) => {
    if (e instanceof AccessDeniedInterrupt) {
      return "The user has denied the request";
    }
    return e.message;
  },
});
```

承認待ちの扱いは、ユーザーの応答まで処理を止める `block` と、いったん実行を中断して後で再開する `interrupt`（既定）から選べます。公式ドキュメントは `block` を、待っている間にプロセスのクラッシュやタイムアウトが起こりうるため開発中にだけ使うものとしています。本番では `interrupt` を使い、承認後にエージェントを再開する経路を用意してください。

## FGA for RAG｜閲覧権限による検索結果の絞り込み

社内文書を検索させるRAGでは、ベクトル検索が類似度だけで文書を拾うため、閲覧権のない人事資料や財務資料が回答の材料に混ざります。FGA for RAGは、検索で取った候補をAuth0 FGAに照会し、許可されたものだけをLLMへ渡す後段のフィルタです。

Auth0 FGAはReBAC（関係ベースのアクセス制御）で、権限を (user, relation, object) の3つ組「タプル」で持ちます。`user:anne` は `document:2024-financials` の `viewer`、という形です。LangChain（JavaScript）では、既存のリトリーバーを `FGARetriever` で包みます。

```
import { FGARetriever } from "@auth0/ai-langchain/RAG";

const retriever = FGARetriever.create({
  retriever: vectorStore.asRetriever(),
  buildQuery: (doc) => ({
    user: `user:${user?.email}`,
    object: `doc:${doc.metadata.documentId}`,
    relation: "can_view",
  }),
});
```

Vercel AI SDKでは `@auth0/ai` の `FGAFilter` で取得済みの配列を絞ります。どちらも「取ってから絞る」順序なので、閲覧できる文書が少ないユーザーほど、検索件数を多めに取らないと回答に使える文書が残りません。社内文書検索の設計全体は[ナレッジベースとRAGの違い｜社内文書をAmazon Bedrockで検索させる設計と権限制御【2026年11月】](/tech/details/4317/)で整理しています。

## SDKの対応状況｜AI SDK 7とLangChain 1.xは対象外

実装で最初につまずくのは、Auth0のSDKが周辺フレームワークの最新版に追いついていない点です。2026年11月8日にnpm registryとPyPIで確認した結果をまとめます。

### パッケージと現行版

| パッケージ                       | 最新版（公開日）          | 対応するフレームワークの範囲                    |
| --------------------------- | ----------------- | --------------------------------- |
| `@auth0/ai`                 | 6.0.2（2026-04-22） | 共通部分                              |
| `@auth0/ai-vercel`          | 5.1.1（2026-04-22） | `ai` ^5.0.0 または ^6.0.0            |
| `@auth0/ai-langchain`       | 5.0.2（2026-04-22） | `@langchain/core` ^0.3.72         |
| `@auth0/ai-llamaindex`      | 5.0.2（2026-04-22） | `llamaindex` ^0.11.28             |
| `@auth0/ai-genkit`          | 6.0.2（2026-04-22） | `genkit` ^1.5                     |
| `@auth0/ai-cloudflare`      | 2.1.1（2026-04-22） | Cloudflare Agents SDK             |
| `auth0-ai-langchain`（PyPI）  | 1.0.1（2026-01-20） | `langchain-core` \>=0.3.69,<0.4.0 |
| `auth0-ai-llamaindex`（PyPI） | 1.0.2（2026-04-22） | `llama-index-core` \>=0.14,<0.15  |

一方、同じ日の最新版は `ai` が7.0.165、`@langchain/core` が1.3.5、Pythonの `langchain-core` が1.7.6です。JavaScript版のリリースは2026年4月22日を最後に止まっており（GitHubの [auth0/auth0-ai-js](https://github.com/auth0/auth0-ai-js) ではMCP向けの新パッケージのプルリクエストが進行中ですが、npmには未公開）、LangChain 1.0への対応を求める[Issue #413](https://github.com/auth0/auth0-ai-js/issues/413)（2026年9月13日起票）も、2026年11月8日時点でOpenのままです。

### 最新版と組み合わせたときのnpm installの結果

空のディレクトリ（Node.js v26.5.0／npm 11.17.0）で最新版同士を入れると、どちらも依存解決の段階で止まります。

```
$ npm i ai@7.0.165 @auth0/ai-vercel@5.1.1
npm error code ERESOLVE
npm error Found: ai@7.0.165
npm error Could not resolve dependency:
npm error peer ai@"^5.0.0 || ^6.0.0" from @auth0/ai-vercel@5.1.1

$ npm i @langchain/core@1.3.5 @langchain/langgraph@1.7.2 @auth0/ai-langchain@5.0.2
npm error code ERESOLVE
npm error Found: @langchain/core@1.3.5
npm error peer @langchain/core@"^0.3.72" from @auth0/ai-langchain@5.0.2
```

`ai@6` に下げると61パッケージが7秒で入り、`ai` 6.0.325と `@auth0/ai-vercel` 5.1.1の組み合わせになりました。エラーメッセージが勧める `--legacy-peer-deps` で押し込むこともできますが、SDK側がテストしていない組み合わせになるため、認可の処理で使うのは避けたほうが安全です。新規に作るなら、Vercel AI SDKは6系、LangChainは0.3系に揃えるのが2026年11月時点の現実的な選択です。すでにAI SDK 7やLangChain 1.xで組んでいるプロジェクトでは、SDKを使わずに前述の `/oauth/token` と `/bc-authorize` を直接呼ぶ実装も選択肢になります。

### 旧名withTokenForConnectionはwithTokenVaultへ

Token Vaultのラッパー関数は、`@auth0/ai-vercel` 3.x系まで `withTokenForConnection` という名前で、2025年10月15日公開の4.0.0で `withTokenVault` に変わりました。現行の5.1.1が公開している関数は `withTokenVault`・`withAsyncAuthorization`・`getAccessTokenFromTokenVault`・`getAsyncAuthorizationCredentials` などで、旧名はありません。2025年秋までに書かれた日本語の解説を写すとインポートエラーになるので、関数名と参照している版を最初に確かめてください。

## 詰まりやすいエラーと対処｜トークン期限切れ・権限取得の失敗

「エージェントがユーザーの権限を取得できない」「トークンが切れる」ときに見るべき箇所を、原因ごとにまとめます。SDKが返す割り込み（interrupt）のコード名は `@auth0/ai` 6.0.2の配布物で確認したものです。

| 症状・コード                                                      | 主な原因                           | 対処                          |
| ----------------------------------------------------------- | ------------------------------ | --------------------------- |
| Token Vaultの交換が失敗する                                         | リフレッシュトークンのローテーションが有効          | アプリ設定でRotationをオフにする        |
| 交換で401                                                      | ユーザーにその接続のConnected Accountがない | Connected Accountsフローをやり直す  |
| Auth0のリフレッシュトークンが返らない                                       | 認可要求に `offline_access` が無い     | スコープに `offline_access` を含める |
| `TOKEN_VAULT_ERROR`                                         | 外部の同意が無い・スコープ不足・外部RT失効         | 割り込みを受けてユーザーに再接続させる         |
| `ASYNC_AUTHORIZATION_USER_DOES_NOT_HAVE_PUSH_NOTIFICATIONS` | GuardianのプッシュMFAが未登録           | MFA登録させるかメールを有効化            |
| `ASYNC_AUTHORIZATION_AUTHORIZATION_REQUEST_EXPIRED`         | 有効期間内に承認されなかった                 | requestedExpiryを見直し再依頼      |
| `slow_down`                                                 | ポーリング間隔が短すぎる                   | 返された `interval` 秒まで待つ       |

表の1行目がもっとも気づきにくい原因です。[リフレッシュトークン交換のドキュメント](https://auth0.com/docs/secure/call-apis-on-users-behalf/token-vault/refresh-token-exchange-with-token-vault)は、Token Vaultがリフレッシュトークンのローテーションに対応していないと明記し、交換を成功させるにはダッシュボードで「Allow Refresh Token Rotation」を無効にするよう求めています。ローテーションの代わりにトークンをクライアントに結び付けたい場合は、DPoPを使います。

しばらく動いていたエージェントが突然外部APIを呼べなくなる場合は、外部サービス側のリフレッシュトークンの失効を疑ってください。同じドキュメントによると、Auth0は外部プロバイダーが定めた有効期限を過ぎたリフレッシュトークンを削除し、**1年以上トークン交換に使われなかったものも削除**します。年に数回しか動かないバッチ型のエージェントでは、ユーザーに再接続を求める導線が必要です。

もう1点、2026年10月1日のchangelogで、Auth0が発行するリフレッシュトークンの文字列が従来の約45文字より長くなると告知されました。エージェント側でAuth0のリフレッシュトークンを `VARCHAR(45)` のような固定長の列に保存していたり、長さを検証していたりすると、交換の前段で壊れます。

## 監査とログ｜エージェント操作の記録と保持期間

Token Vaultの交換やCIBAの承認は、通常のログインと同じくAuth0のテナントログに残ります。ダッシュボードの Monitoring > Logs でイベントタイプを指定して絞り込めます。[ログのイベントタイプ一覧](https://auth0.com/docs/deploy-monitor/logs/log-event-type-codes)で、エージェントの監査に使うコードは次のとおりです。

| イベントタイプ                                            | 記録される操作                     |
| -------------------------------------------------- | --------------------------- |
| `seta` ／ `feta`                                    | Token Vaultのトークン交換の成功／失敗    |
| `ciba_start_succeeded` ／ `ciba_start_failed`       | 承認依頼（bc-authorize）の開始の成功／失敗 |
| `ciba_exchange_succeeded` ／ `ciba_exchange_failed` | 承認後のトークン発行の成功／失敗            |

「どのエージェントが、いつ、どの外部サービスのトークンを取り出したか」は `seta` で追えます。`feta` が続いていれば、前章の設定不備や接続の失効を疑ってください。ただし保持期間はプランで大きく違い、[料金比較表](https://auth0.com/pricing)ではFreeが1日、Essentialsが5日、Professionalが10日、Enterpriseが30日です。外部のSIEMへ送るログストリーミングはFreeに無く、Essentialsで1本、Professional・Enterpriseで2本まで使えます。

無料プランの1日では、エージェントが前日に何をしたかを翌々日に追えません。監査証跡を残す前提なら、Essentials以上でログストリームを外部へ流してください。エージェントごとに固有のIDを持たせて `agent_id` でログを検索する方法は、Early AccessのAgents as Principalの機能で、[新機能5つの記事](/tech/details/12263/)で手順を解説しています。

## 料金と導入判断｜CIBAの有料条件と無料枠の範囲

[Auth0の料金ページ](https://auth0.com/pricing)の比較表（2026年11月8日取得）で、AIエージェントに関わる行は次のとおりです。

| 項目               | Free | Essentials | Professional | Enterprise |
| ---------------- | ---- | ---------- | ------------ | ---------- |
| CIBA（非同期認可）      | 提供なし | アドオン       | アドオン         | 標準＋アドオン    |
| Token Vault（接続数） | 2    | 3＋アドオン     | 3＋アドオン       | 4＋アドオン     |
| Auth for MCP     | 標準   | 標準＋アドオン    | 標準＋アドオン      | 標準＋アドオン    |
| ログ保持             | 1日   | 5日         | 10日          | 30日        |
| ログストリーミング        | なし   | 1本         | 2本           | 2本         |

導入判断に効くのは1行目です。CIBAの設定ドキュメントにも「EnterpriseプランかCIBAのアドオンが必要」とあり、Auth0の無料プランだけではCIBAによるHuman-in-the-Loopを検証できません。進める順序は、Auth0の無料プランでユーザー認証とToken Vault（接続2つまで）を、Auth0 FGAの[無料トライアル](https://docs.fga.dev/subscription-plans)（Auth0本体のプランとは別枠）でFGA for RAGの疎通を確かめ、承認フローが本当に必要な操作を洗い出してから、有料プランとアドオンを見積もるのが無駄の少ない進め方です。MCPサーバーを保護するAuth for MCPは無料プランでも標準で含まれるので、MCPから試す場合は[MCPサーバーの作り方とAIエージェントへの接続手順｜Python SDK 2.3でツール定義・認可を実装](/tech/details/15365/)と組み合わせて検証できます。

Auth0を使わずに自前で組む場合、外部サービスのトークン保管と更新、承認の通知と有効期限、文書単位の権限照会をすべて自社で持つことになります。社員向けのエージェントで、既存のIdPがOktaやEntra IDに統一されている企業なら、Okta側のXAAで統制する選択肢もあります（[Okta Cross App Access（XAA）とは？ID-JAGの仕組みとAgent SSO GA後の導入判断【2026年10月】](/tech/details/12774/)）。どちらの構成でも、IdPとの連携や権限設計を社内で組み切れない場合は、[認証基盤・ID管理システム開発](/service/system/identity/)の支援を受ける方法もあります。

## よくある質問

### Auth0 for AI Agentsはまだ開発者プレビューですか？

いいえ。2025年11月19日にGAしており、MCPサーバー向けのAuth for MCPも2026年5月6日にGAしました。Agents as Principal、Token VaultのPrivileged Worker、XAA、CIMDの動的登録は2026年11月時点でEarly Accessです。

### 無料プランだけでCIBAによるHuman-in-the-Loopを試せますか？

試せません。料金比較表のCIBA行はFreeが提供なしで、Essentials・Professionalはアドオン、Enterpriseは標準で含まれます。メール通知を使う場合は、有料プランにAuth0 for AI Agentsのアドオンが必要です。

### 非同期認可の承認依頼はSMSで送れますか？

ドキュメントで現在利用できるとされているのは、Guardianのプッシュ通知とメールの2つです。両方を有効にしている場合、`requested_expiry` が300秒以下ならプッシュ、301秒〜72時間ならメールが選ばれます。プッシュのMFAを登録していないユーザーには、メールが有効ならメールで送られます。

### LangChain 1.xやVercel AI SDK 7でAuth0のSDKは使えますか？

2026年11月8日時点では使えません。`@auth0/ai-langchain` 5.0.2は `@langchain/core` ^0.3.72、`@auth0/ai-vercel` 5.1.1は `ai` ^5または^6を要求し、最新版と同時に入れるとnpmがERESOLVEで止まります。フレームワークを下げるか、SDKを使わずにAPIを直接呼びます。

### エージェントの操作の監査証跡は残せますか？

Token Vaultの交換は `seta`（成功）・`feta`（失敗）、CIBAは `ciba_start_*` と `ciba_exchange_*` のイベントとしてテナントログに残ります。ただし保持期間はFreeで1日、Enterpriseで30日です。長期の保管はEssentials以上のログストリーミングで外部へ送ります。

### 古いサンプルのwithTokenForConnectionが見つからないのはなぜですか？

`@auth0/ai-vercel` の4.0.0（2025年10月15日）で `withTokenVault` に改称されています。3.x系のサンプルは関数名を差し替えてください。

## 関連記事

- [Auth0 for AI Agentsの新機能5つ：Agent as Principal・OBO・FGA索引の提供状況【2026年10月】](/tech/details/12263/)
- [Okta Cross App Access（XAA）とは？ID-JAGの仕組みとAgent SSO GA後の導入判断【2026年10月】](/tech/details/12774/)
- [CIMD（Client ID Metadata Documents）とは？MCPでDCRに代わるOAuthクライアント登録の仕組みと実装【2026年10月】](/tech/details/10011/)
- [OAuthとは？OAuth 2.0の仕組み・認証と認可の違いとOAuth 2.1の現状をわかりやすく解説](/tech/details/8369/)
- [Keycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断【2026年10月】](/tech/details/7663/)

---

出典: [Auth0 for AI Agentsとは？Token Vault・CIBAの設定手順とSDK対応状況・料金【2026年11月】](<https://www.issoh.co.jp/tech/details/9411/>)（株式会社一創）