結論（おすすめ1つ）
Clerk に乗り換えるべき。
理由は3点：フロントエンドとの統合が最も薄い実装コストで済む、UI コンポーネントがそのまま使えるためデザインの手が入らない、そして Auth0 の「ルール/アクション」に相当するカスタマイズが JavaScript で書けるため既存チームのスキルセットで対応できる。ただし、エンタープライズ SSO や SCIM プロビジョニングが最優先なら WorkOS を選ぶこと。
比較表（料金/無料枠/移行コスト/対応言語）
| 項目 | Auth0 | Clerk | Supabase Auth | WorkOS |
|---|---|---|---|---|
| 無料枠 | MAU 上限あり（公式の料金ページで要確認） | MAU 上限あり（公式の料金ページで要確認） | プロジェクト数・MAU に上限あり（公式の料金ページで要確認） | ユーザー数上限あり（公式の料金ページで要確認） |
| 有料開始価格 | 公式の料金ページで要確認 | 公式の料金ページで要確認 | 公式の料金ページで要確認 | 公式の料金ページで要確認 |
| 移行コスト | ― | 低〜中（SDK 差し替え＋JWT 検証変更） | 中（Supabase クライアント導入が前提） | 中〜高（エンプラ向け設定が多い） |
| 対応フレームワーク | Next.js/React/Vue/他多数 | Next.js/React/Vue/他多数 | Next.js/React/Flutter/他多数 | Next.js/React/他多数 |
| SSO（SAML/OIDC） | あり（有料プランから） | あり（有料プランから） | 部分的（OIDC のみ） | 最優先機能として全面対応 |
| SCIM プロビジョニング | あり | 対応（プランによる） | なし | あり |
| セルフホスト | 不可 | 不可 | 可（OSS） | 不可 |
移行手順
Auth0 から Clerk への移行を例に示す。
1. Clerk アカウントとアプリケーションを作成
# Clerk SDK をインストール（Next.js App Router の場合）
npm install @clerk/nextjs
2. 環境変数を設定
# .env.local
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_xxxxxxxxxx
CLERK_SECRET_KEY=sk_test_xxxxxxxxxx
# Auth0 側の変数は削除または無効化しておく
# AUTH0_SECRET=... # 削除
# AUTH0_BASE_URL=... # 削除
3. middleware.ts を差し替える
// Auth0 の withMiddlewareAuthRequired を削除し Clerk の clerkMiddleware に変更
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server';
const isProtectedRoute = createRouteMatcher(['/dashboard(.*)']);
export default clerkMiddleware((auth, req) => {
if (isProtectedRoute(req)) auth().protect();
});
export const config = {
matcher: ['/((?!_next|.*\\..*).*)'],
};
4. レイアウトに ClerkProvider を追加
// app/layout.tsx
import { ClerkProvider } from '@clerk/nextjs';
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<ClerkProvider>
<html lang="ja">
<body>{children}</body>
</html>
</ClerkProvider>
);
}
5. 認証状態の取得を差し替える
// Auth0: const { user } = useUser();
// Clerk: 同名だが import 元が変わる
import { useUser } from '@clerk/nextjs';
const { user, isLoaded } = useUser();
6. Auth0 のユーザーデータをエクスポートして Clerk へインポート
# Auth0 Management API でユーザーをエクスポート
curl -X POST https://YOUR_DOMAIN.auth0.com/api/v2/jobs/users-exports \
-H "Authorization: Bearer MGMT_TOKEN" \
-H "Content-Type: application/json" \
-d '{"connection_id":"con_xxx","format":"json"}'
# Clerk の Backend API でユーザーを一括作成（スクリプト例）
# 公式ドキュメントの createUser エンドポイントを参照してバッチ処理を実装する
# パスワードハッシュの移行には Clerk の password_hasher オプションを使う
向き不向き
Clerk が向くチーム・規模
- フロントエンド中心のスタートアップ（Next.js / React）
- 認証 UI を自前で作りたくない小〜中規模チーム
- Auth0 の料金が MAU 増加で急上昇し始めたタイミングで乗り換えを検討しているプロジェクト
- ソーシャルログイン・マジックリンク・パスキーを素早く組み込みたいケース
Supabase Auth が向くチーム・規模
- すでに Supabase をデータベースとして使っているプロジェクト（認証を追加コストゼロで統合できる）
- セルフホストが必要な規制業種・データ主権要件のあるチーム
- バックエンドが PostgreSQL Row Level Security で設計されているアーキテクチャ
WorkOS が向くチーム・規模
- B2B SaaS で企業顧客への SAML SSO / SCIM プロビジョニング提供が必須のプロダクト
- エンタープライズ営業を本格化する段階のチーム
- Admin Portal を自前実装したくない場合
避けるべきケース
- Clerk を避けるべき：セルフホストが必須、または SCIM が即日必要でプランの確認が間に合わない場合
- Supabase Auth を避けるべき：Supabase 以外のデータベースを使っており、認証だけ切り出して使いたい場合（RLS と密結合しているため恩恵が薄い）
- WorkOS を避けるべき：BtoC や個人向けプロダクトで SSO 不要のケース（オーバースペックになりやすい）
Top comments (0)