まとめ:Auth0 for AI Agentsの要点
先に結論を示します。Auth0 for AI Agentsは、AIエージェントがユーザーに代わって外部APIを呼んだり社内文書を検索したりする場面の認証・認可を、Auth0の既存基盤の上で扱えるようにした機能群です。
- 提供状況:2025年4月8日にDeveloper Preview、2025年11月19日に一般提供(GA)を開始済みです。プレビュー参加申込みという段階はすでに終わっています。
- 機能は4本柱:ユーザー認証、Token Vault(第三者API連携)、非同期認可(CIBA)、FGA for RAG(文書単位の認可)。
- 実装はSDK経由が前提で、JavaScriptは
@auth0/ai系、Pythonはauth0-ai系。LangChain・LlamaIndex・Vercel AI SDK・Genkit・Cloudflare Agents向けのアダプタが揃っています。 - 料金の分かれ目は非同期認可です。無料プランではCIBAが提供対象外で、EssentialsとProfessionalは有料アドオン、Enterpriseで標準搭載という区分になっています。
- SDKは名称変更を経ています。旧
withTokenForConnectionはwithTokenVaultへ改称済みで、2025年前半の日本語記事のコードはそのままでは動きません。
以下、それぞれを一次情報にあたって整理します。
Auth0 for AI Agentsとは|名称の整理と提供状況
この製品はまず名前が紛らわしく、検索時に別々の呼び方が混在しています。最初にそこを片付けます。
「Auth for GenAI」と「Auth0 for AI Agents」の関係
正式な製品名はAuth0 for AI Agentsです。一方で「Auth for GenAI」という表記も公式資産に残っています。最初の発表記事のURLは introducing-auth-for-genai であり、デモ用リポジトリも auth0/auth-for-genai、ドキュメントの配置も auth0.com/ai/docs 配下です。つまりAuth for GenAIは取り組み全体の初期の呼び名で、製品名としてはAuth0 for AI Agentsに一本化されたと理解するのが実態に合います。
なお日本語圏では「Auth0 Gen for AI」という表記も見かけますが、この語はAuth0の発表記事・製品ページ・ドキュメントのいずれにも登場しません。検索でこの名前に当たった場合は、出典を確認したほうがよい記述と考えてください。
Developer PreviewからGAまでの経緯
2025年4月8日の発表時点では「Developer Preview」として公開され、ユーザー認証・Token Vault・非同期認可・FGA for RAGの4機能が示されました。その後2025年11月19日にGAが告知され、同じ日に @auth0/ai の6.0.0、@auth0/ai-vercel と @auth0/ai-langchain の5.0.0といったメジャー版が公開されています。SDKのリリース履歴とGA告知日が一致しており、GAは告知だけでなくパッケージの版更新を伴った区切りだったことが確認できます。
GA後も機能ごとに提供段階は分かれています。MCPサーバー向けの「Auth for MCP」は2025年11月のGA時点ではEarly Accessでしたが、2026年5月6日に一般提供へ移行しました。Cross App Access(XAA)は2026年9月時点でもEarly Accessで、Enterprise・B2B Pro・B2B Essentialの各プランが対象、利用にあたってOktaのMaster Subscription Agreementの無償トライアル条項への同意が必要です。製品ページではこのほかにAgent as PrincipalやAgent Gatewayが今後の提供予定として並んでいます。
4つの機能が担う範囲|どの課題をどれで解くか
機能名だけを並べても選べないため、解きたい課題との対応で整理します。
機能と用途の対応表
| 機能 | 解く課題 | 使う技術 |
|---|---|---|
| ユーザー認証 | チャットボットに誰がログインしているかを確定させる | Universal Login(ソーシャル・エンタープライズ・独自IdP) |
| 第一者API呼び出し | 自社APIを本人の権限の範囲で呼ばせる | OAuth 2.0(ユーザーが同意したスコープに限定) |
| Token Vault | Google・Slack・GitHubなど外部APIをユーザー代理で呼ばせる | トークン交換とトークンの保管・更新 |
| 非同期認可 | 重要操作の直前に人間の承認を挟む | CIBA、必要に応じてRAR |
| FGA for RAG | 検索した文書のうち本人に閲覧権のあるものだけをLLMへ渡す | Auth0 FGA(ReBAC) |
第一者APIと第三者APIで設計が変わる
混同しやすいのがこの2つの区別です。自社が所有するAPIを呼ぶ場合は通常のOAuth 2.0の委任で足り、アクセストークンのスコープ設計が主な論点になります。これに対しGoogleやSlackのように他社が所有するAPIを呼ぶ場合は、そのプロバイダー側のトークンを誰がどこに保持するかという別の問題が生じます。そこを引き受けるのがToken Vaultです。設計の入口として、呼びたいAPIが自社所有かどうかを先に切り分けてください。OAuth 2.0の委任そのものの前提はOAuth 2.0とは?仕組み・認可フローと認証・認可の違いをわかりやすく解説で整理しています。
Token Vault|第三者APIをユーザー代理で呼ぶ
Token Vaultは、ユーザーが外部プロバイダーへの接続を許可した時点でそのプロバイダーのアクセストークンとリフレッシュトークンをAuth0側に保管し、エージェントからの要求に応じて交換で払い出す仕組みです。エージェントのコードに外部サービスのトークンを直接持たせずに済む点が要点になります。
リフレッシュトークン交換とアクセストークン交換
交換のパターンはアプリケーション種別によって2つに分かれます。
1つ目はリフレッシュトークン交換です。Webアプリ・モバイルアプリ・ネイティブアプリのようにAuth0のリフレッシュトークンを保持できる構成で使い、リフレッシュトークンを /oauth/token エンドポイントへ渡して外部プロバイダーのアクセストークンを取得します。ユーザーがアプリを開いていない間でも外部APIを呼べるのがこの方式の利点です。
2つ目はアクセストークン交換です。SPA(シングルページアプリケーション)やヘッドレスなエージェント、CLIのようにリフレッシュトークンを扱えない構成で使います。SPAは Authorization ヘッダーでAuth0のアクセストークンをバックエンドAPIへ渡し、バックエンドが署名・発行者・オーディエンス・有効期限・スコープを検証したうえで、自身と同じ識別子を設定したCustom API Clientを使って交換を行います。SPA向けのこの経路は2025年8月25日の更新で追加されたもので、比較的新しい選択肢です。
なおOrganizations機能を併用している場合は、Connected Accountsで外部プロバイダーを認可する前に対象組織でユーザーを認証しておく必要があります。組織はセッションの文脈を決めますが、トークン交換自体はサインイン中の個人単位で行われます。
接続できる外部プロバイダー
ドキュメントのConnections一覧には、Google・Microsoft・GitHub・Slack・Salesforce・Box・Dropbox・Stripe Connect・PayPal・Figma・Discord・Spotifyなど25前後の名前付きプロバイダーに加えて、汎用のOAuth 2.0接続とOIDC接続、Google WorkspaceとMicrosoft Azureのページが並んでいます。2025年9月にはAmazon・Bitbucket・Hugging Face・Basecamp・DigitalOcean・Tumblr・Twitch・X(Twitter)などが追加されており、対応先は継続的に増えています。目的のサービスがあるかどうかは、実装前にConnections一覧で確認するのが確実です。
非同期認可(CIBA)|Human-in-the-Loopの実装
エージェントが決済や本番デプロイのような取り返しのつかない操作を行う直前に、人間の承認を挟む仕組みです。ここが4機能のなかで最も実装上の制約が多い部分になります。
Auth0はCIBA(Client-Initiated Backchannel Authentication)を使い、必要に応じてRAR(Rich Authorization Requests)を組み合わせます。RARの併用は任意です。処理は次の順で進みます。
- エージェントのバックエンドが
/bc-authorizeエンドポイントへCIBA要求を送ります。要求にはユーザー識別子と、任意でauthorization_detailsパラメータのRARペイロードを含めます。 - Auth0が即座に
auth_req_idを返します。 - バックエンドはその
auth_req_idを使い、/tokenエンドポイントへのポーリングを開始します。 - 並行してAuth0がユーザーの端末へ通知を送り、ユーザーが承認または拒否します。
- 承認された時点で次のポーリングが成功し、アクセストークンとIDトークンが払い出されます。
RARを使う意味は同意画面の具体性にあります。汎用的なスコープ名の代わりに「ExampleCorpへ50.00ドルの支払いを承認しますか」といった構造化された内容を提示できるため、承認する側が何に同意したのかを判断できます。
通知チャネルはGuardianプッシュとメール
ここは記述に注意が必要な箇所です。Auth0の概要文はプッシュ通知・SMS・メールの3つを挙げていますが、同じドキュメントの「現在利用可能な選択肢」の一覧に載っているのは、優先順にAuth0 Guardianのモバイルプッシュ通知とメールの2つです。既定かつ推奨はGuardianプッシュで、メールはフィッシングに対して脆弱なため明示的に有効化する必要があるとされています。
さらに、非同期認可のメール通知は有料アドオン扱いで、Essentials・Professional・Enterpriseの各プランで利用可能という条件が付きます。Guardianアプリを配布できない利用者向けにメールで代替する設計を考えている場合、この条件を先に確認してください。
blockとinterruptの使い分け
SDK側では承認待ちの扱い方を選べます。block はユーザーが承認または拒否するまでツールの実行を待ち続け、interrupt はいったん実行を中断します。既定は interrupt です。公式ドキュメントは block について、承認を待っているプロセスがクラッシュしたりタイムアウトしたりする可能性があるため開発中にのみ有用だと明記しています。本番のワークフローで安易に block を選ばないでください。
Vercel AI SDKを使う場合の設定は次のような形になります。
import { Auth0AI } from "@auth0/ai-vercel";
import { AccessDeniedInterrupt } from "@auth0/ai/interrupts";
import { getUser } from "./auth0";
const auth0AI = new Auth0AI();
export const withAsyncAuthorization = auth0AI.withAsyncAuthorization({
userID: async () => {
const user = await getUser();
return user?.sub as string;
},
bindingMessage: async ({ product, qty }) =>
`Do you want to buy ${qty} ${product}`,
scopes: ["openid", "product:buy"],
audience: process.env["SHOP_API_AUDIENCE"]!,
onUnauthorized: async (e: Error) => {
if (e instanceof AccessDeniedInterrupt) {
return "The user has denied the request";
}
return e.message;
},
});
bindingMessage がユーザーの端末に表示される確認文言になります。ここを「操作を承認しますか」のような汎用文にしてしまうと、RARを使う意味が失われる点に注意してください。
FGA for RAG|ドキュメント単位のアクセス制御
社内文書を検索させるRAGでは、ベクトル検索が類似度だけで文書を拾うため、本来閲覧権のない人事資料や財務資料が回答の材料になり得ます。Auth0 FGAはこれを検索後のフィルタとして塞ぎます。
ReBACとタプルの考え方
Auth0 FGAが採るのはReBAC(関係ベースアクセス制御)です。まず document のようなオブジェクト型と owner・editor・viewer といった関係を認可モデルとして定義し、実際の権限は「タプル」として保存します。タプルは (user, relation, object) の3つ組で、たとえば user:anne が document:2024-financials の viewer である、という形です。ロールだけで表現しにくい共有関係を扱える点がRAGと相性の良い理由になります。
リトリーバーに差し込む実装
実行時の流れは、ベクトルデータベースから候補文書を取得し、その一覧に対してFGAへ権限チェックを投げ、許可されたものだけをLLMへ渡すという順序です。SDKはこれをリトリーバーの差し替えとして提供します。LangChain(JavaScript)の場合は次の形です。
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",
}),
});
Pythonでは auth0_ai_langchain パッケージが FGARetriever を公開しており、build_query に openfga_sdk の ClientBatchCheckItem を返す形で同じ設計を組みます。Vercel AI SDK側では @auth0/ai の FGAFilter を使い、取得済みの候補配列をフィルタする書き方になります。いずれも「取得してから絞る」という順序は共通です。社内文書検索そのものの設計はナレッジベースとRAGの違い|社内文書をAmazon Bedrockで検索させる設計と権限制御【2026年版】も参考になります。
SDKと実装|パッケージ名・現行版・改称に注意
ここは古い記事のコードをそのまま写すと動かない領域です。
JavaScriptとPythonのパッケージ
2026年9月時点の現行版は次のとおりです。
| パッケージ | 用途 | 現行版(公開日) |
|---|---|---|
@auth0/ai |
共通の抽象と中断処理 | 6.0.2(2026年4月22日) |
@auth0/ai-langchain |
LangChain・LangGraph向け | 5.0.2(同) |
@auth0/ai-llamaindex |
LlamaIndex向け | 5.0.2(同) |
@auth0/ai-vercel |
Vercel AI SDK向け | 5.1.1(同) |
@auth0/ai-genkit |
Genkit向け | 6.0.2(同) |
@auth0/ai-cloudflare |
Cloudflare Agents SDK向け | 2.1.1(同) |
auth0-ai(PyPI) |
Python共通 | 1.0.2(2026年1月20日) |
auth0-ai-langchain(PyPI) |
Python版LangChain向け | 1.0.1(同) |
Python版の auth0_ai_langchain は、トップレベルで FGARetriever を公開し、token_vault・fga・async_authorization の3つのサブモジュールを持つ構成です。非同期認可では AsyncAuthorizer と、LangGraphの再開を担う GraphResumer が用意されています。
withTokenForConnectionはwithTokenVaultへ改称済み
Token Vaultを扱うラッパー関数は、以前は withTokenForConnection という名前でした。パッケージの配布物を版ごとに確認すると、@auth0/ai-vercel では3.x系までがこの名前を持ち、2025年10月15日公開の4.0.0で withTokenVault へ置き換わっています。現行の5.1.1に withTokenForConnection は含まれません。
この改称はGA(2025年11月19日)の約1か月前に入ったため、2025年前半から秋にかけて書かれた日本語の解説記事は旧名のままであることが多く、コードを写すと解決できないインポートエラーになります。サンプルを見つけたら、まず参照しているパッケージの版を確認してください。
料金と導入判断|無料プランではCIBAが使えない
検証を始める前に、どこから課金が発生するかを把握しておく必要があります。基本プランの実額とMAUの数え方はAuth0の料金はいくら?MAU課金の実額と無料枠を超えた後の増え方にまとめました。
プラン別の提供範囲
公式の料金比較表では、Auth0 for AI Agentsはエンタープライズ向けアドオンとして位置づけられ、AI関連の行は次の区分になっています。
| 項目 | Free | Essentials | Professional | Enterprise |
|---|---|---|---|---|
| CIBA(非同期認可) | 提供なし | アドオン | アドオン | 標準搭載+アドオン |
| Token Vault(接続数) | 2 | 3+アドオン | 3+アドオン | 4+アドオン |
| Auth for MCP | 標準搭載 | 標準搭載+アドオン | 標準搭載+アドオン | 標準搭載+アドオン |
| 外部アクティブユーザー | 25,000まで | カスタム階層 | ||
実務上いちばん効くのは1行目です。無料プランではCIBAの欄が空欄になっており、非同期認可を無料枠だけで試すことはできません。Human-in-the-Loopの検証を計画に入れるなら、有料プランとアドオンの手当てを最初の見積もりに含めてください。GA告知にある「無料プランはToken Vaultの接続アプリ2つを含む」という記述は、表のToken Vault行の数値と一致しています。
検証環境をどう組むか
この制約を踏まえると、無料枠で確かめられるのはユーザー認証とToken Vault(接続2つまで)、それにFGAの組み合わせまでです。FGA for RAGは FGA_STORE_ID・FGA_CLIENT_ID・FGA_CLIENT_SECRET・FGA_API_URL・FGA_API_AUDIENCE を設定して動かす構成で、Auth0本体のプランとは別にFGAのストアを用意します。したがって、まず認証とToken Vaultで疎通を確認し、FGAでRAGの絞り込みを組んだうえで、承認フローが本当に必要かを見極めてから有料プランへ進む順序が無駄になりにくい進め方です。
MCPサーバーを認可の対象に含める場合は、Auth for MCPが2026年5月6日に一般提供へ移行したうえで無料プランでも標準搭載になっている点が使えます。MCP側の権限設計そのものはAIエージェントにMCPで外部ツールを接続する実装手順とは?tool定義・権限・認可の設計を解説【2026年版】で扱っています。
よくある質問(FAQ)
Auth0 for AI Agentsはまだ開発者プレビューですか?
いいえ。2025年11月19日に一般提供(GA)が告知されており、プレビュー段階は終了しています。MCPサーバー向けのAuth for MCPも2026年5月6日に一般提供へ移行しました。一方でCross App Access(XAA)は2026年9月時点でEarly Accessのままで、機能ごとに提供段階が異なります。
「Auth0 Gen for AI」という名前は正しいですか?
Auth0の発表記事・製品ページ・ドキュメントのいずれにもこの表記は登場しません。公式に使われているのはAuth0 for AI Agentsと、初期の呼び名であるAuth for GenAIの2つです。
非同期認可の通知はSMSでも送れますか?
概要説明ではプッシュ通知・SMS・メールが挙げられていますが、ドキュメントが「現在利用可能な選択肢」として列挙しているのはAuth0 Guardianのモバイルプッシュ通知とメールの2つです。SMSを前提に設計する場合は、実装前に最新のドキュメントで提供状況を確認してください。
無料プランだけでHuman-in-the-Loopを試せますか?
試せません。料金比較表のCIBA行はFreeプランが提供対象外で、EssentialsとProfessionalは有料アドオン、Enterpriseが標準搭載という区分です。加えて、メール通知はEssentials以上での有料アドオンになります。
古いサンプルのwithTokenForConnectionが見つかりません。
@auth0/ai-vercel の4.0.0(2025年10月15日)で withTokenVault へ改称されており、現行版に旧名は含まれません。3.x系までのサンプルを参照している場合は、関数名を差し替えてください。
自社APIを呼ぶだけでもToken Vaultは必要ですか?
必要ありません。自社が所有する第一者APIはOAuth 2.0の委任で呼べます。Token Vaultが要るのは、GoogleやSlackのように他社が所有する第三者APIをユーザーの代理で呼ぶ場合です。