✍️ 필사 모드: 認証プロバイダ徹底比較 2026 — Clerk・WorkOS・Auth0・Stytch・Better Auth・Kinde・SuperTokens、そして NextAuth と Lucia 終焉レビュー

• プロローグ — 認証を「買う」時代
• 第 1 章 · 8 つの軸 — 何を見て選ぶか
• 第 2 章 · 10 個のオプション — 一行アイデンティティと一行リスク
• 第 3 章 · 機能マトリクス — 1 表で整理
• 第 4 章 · 価格マトリクス — 実際の請求書シミュレーション
  • シナリオ A · B2C 消費者向けアプリ（50,000 MAU、MFA・passkey・ソーシャルのみ）
  • シナリオ B · B2B SaaS（顧客 200 社、平均 50 シート、SAML 30 パーセント・SCIM 10 パーセント）
  • シナリオ C · グローバル消費者アプリ（500,000 MAU）
• 第 5 章 · 意思決定ツリー — どれを選ぶか
• 第 6 章 · セルフホスト TCO — 本当に安いのか
• 第 7 章 · Clerk vs WorkOS — 最頻出の比較
• 第 8 章 · パスワードレス・passkey・magic link — 2026 年のデフォルト
• 第 9 章 · Lucia 移行 — どこへ何を
• 第 10 章 · NextAuth（Auth.js）vs Better Auth — Next.js ライブラリの選択
• 第 11 章 · アンチパターン — よくある誤り 10 個
• エピローグ — 決定チェックリストと次回予告
  • 決定チェックリスト
  • アンチパターン総括
  • 次回予告
• 参考 / References

プロローグ — 認証を「買う」時代

2026 年 5 月の認証市場は 5 年前とまったく違う。2021 年は「Auth0 を使うか、Cognito を使うか、自作するか」が全てだった。今は同じ問いに少なくとも 10 個の答えがあり、それぞれが異なる価格・運用負担・機能セットを持つ。

市場は二方向に裂けた。

• B2C・開発体験陣営。 Clerk が旗を立てた。UI コンポーネント、ホスト型認証、洗練された React/Next.js 統合、そして「10 分でログインが動く」という約束。Stytch がパスワードレス・passkey・Fraud SDK で並び、Kinde が「よりシンプルな代替」として続いた。
• B2B・エンタープライズ readiness 陣営。 WorkOS が作ったカテゴリ。SAML・SCIM・ディレクトリ同期・監査ログ — エンタープライズ顧客が叫ぶ全ての機能を API 1 行で売る会社。Auth0 はここにいたが、Okta 買収後の価格引き上げと停滞でシェアを失った。

セルフホスト・OSS 陣営でも 2025 年に二つの大事件が起きた。Lucia が死んだ。 メンテナの pilcrowOnPaper が 2025 年 3 月に deprecation を公式発表し、ライブラリは 2025 年末に学習用リソースへ移行した。そしてその席を Better Auth が奪った。TypeScript ネイティブ・フレームワーク非依存・プラグインアーキテクチャ・セルフホスト可能 — 2025 年のインディーハッカーが一斉に乗り換えた。

本稿はこれら全てのオプションを同じ軸で比較する。理論（OIDC・SAML プロトコルそのもの）は別記事に、Keycloak セルフホスト ハンズオンも別記事にある。本稿は 「何を買うか」 の意思決定ガイドだ。

価格は速く変わる。本稿の数字は全て 2026 年 5 月時点の参考値であり、正確な値より 構造 に注目してほしい。半年後に価格が動いてもフレームワークは生き残る必要がある。

流れは: 比較軸 → 10 プロバイダの一行紹介 → 機能マトリクス → 価格マトリクス → シナリオ別決定ツリー → セルフホスト TCO → Lucia 移行 → エピローグ。

第 1 章 · 8 つの軸 — 何を見て選ぶか

共通フレームワークなしには「Clerk のほうが良い vs WorkOS のほうが良い」のような無意味な議論になる。次の 8 軸を全プロバイダに当てはめる。

軸 1 · ターゲット市場（B2C と B2B） ユーザは誰か。個人がサインアップするアプリ（B2C）か、企業がシートを購入する SaaS（B2B）か。答えで必要機能が変わる。B2C はソーシャルログイン・パスワードレス・passkey が中心。B2B は SSO（SAML/OIDC）・SCIM（自動プロビジョニング）・組織・ロール・監査ログが中心。両方を上手にこなすと宣伝するプロバイダは多いが、実際にはどちらかに寄っている。

軸 2 · ホスティングモデル 完全 SaaS か、セルフホスト可能か、両方か。SaaS は運用負担がない代わりに依存性・価格・データ主権を譲る。セルフホストはその逆。「両方」はマーケ文言であることが多く、セルフホストを本気で一級サポートしている OSS 会社は少数だ。

軸 3 · 価格モデル MAU（月次アクティブユーザ）課金か、シート課金か、機能ゲート課金か。MAU 課金は B2C に厳しい — ユーザが増えると線形にコストが伸びる。シート（組織メンバー）課金は B2B に合理的。そして「エンタープライズ機能」（SAML・SCIM・SSO）を別 SKU にまとめて 5 倍の請求書にするパターンは、ほぼ全 SaaS プロバイダの標準だ。

軸 4 · 機能の幅（passkey・MFA・組織・SAML・SCIM・パスワードレス・magic link） 必須: メール・パスワード、ソーシャル、セッション。ボーナス: passkey/WebAuthn・TOTP・SMS OTP・magic link・パスワードレス・SAML SSO・SCIM プロビジョニング・B2B 組織・ロール権限・監査ログ・デバイス管理。同じ価格帯で何が含まれて何が課金されるか。

軸 5 · DX（開発体験） SDK 品質・ドキュメント・例・UI コンポーネント・フレームワーク統合。Clerk の独壇場。<SignIn /> コンポーネントが 30 秒で動くか、それとも OIDC ハンドシェイクを自前でコードを書くか。

軸 6 · 統合の深さ（フレームワーク・BaaS・メール・課金） Next.js・Remix・SvelteKit のようなメタフレームワークでファーストクラスか。Stripe・Resend・Supabase・Vercel との連携はどうか。統合が良ければボイラープレートが減り、なければアダプタ層を自分で書くことになる。

軸 7 · データ主権・コンプライアンス ユーザデータはどこに格納されるか。EU/日本/韓国リージョンのオプションはあるか。SOC2・ISO 27001・HIPAA・GDPR DPA・日本 APPI 対応。セルフホストならば自明だが、SaaS では本社所在地とリージョン選択肢が決める。

軸 8 · 切替コスト（lock-in） ユーザデータをどう export できるか。パスワードハッシュは持ち出せるか（SCRAM・bcrypt・argon2 形式が互換か）。MAU 課金が痛みの閾値を超えたとき、実際の移行コストはいくらか。ここが最も無視される軸だ。 小規模では魅力的に見えるプロバイダが、50 万 MAU で年間 30 万ドルを請求してくる時、「移ればいい」が本当に成立するか確認すべきだ。

第 2 章 · 10 個のオプション — 一行アイデンティティと一行リスク

本格比較前に各プロバイダを短くまとめる。

Clerk — 開発体験 1 位の B2C 認証。UI コンポーネント（<SignIn />・<UserButton />）・B2B Organizations・Backend API。料金は Pro 25 ドル/月から、10,000 MAU 無料。SAML・SCIM は高価な Enhanced Authentication アドオン（100 ドル/月から）。一行リスク: B2C から始まり B2B 機能を追加している段階で、B2B の深さは WorkOS に及ばない。

WorkOS — 「Enterprise OAuth」カテゴリを作った会社。SSO・SAML・SCIM・ディレクトリ同期・監査ログを API 1 行で。価格は SSO・DSync 各 connection あたり 125 ドル/月（月 1,000,000 unit までの無料枠あり）。2026 年に AuthKit が 1M MAU 無料となり、全ての認証ビルディングブロックをまとめている。一行リスク: B2C 認証（ソーシャル・パスワード）も可能だが、真の価値は普通の認証ではなくエンタープライズ readiness にある。

Auth0（Okta） — 認証 SaaS の元祖にして巨人。2021 年に Okta が 65 億ドルで買収。全ての機能と統合があり、全てに課金される。2026 年価格: B2C Essentials 35 ドル/月から（1,000 MAU 込み）、Pro 240 ドル/月（1,000 MAU）、5,000 MAU で約 1,500 ドル/月。B2B 価格は別 — Auth0 Organizations・Enterprise Connections は高い。一行リスク: M&A 後の停滞。新機能の出荷が遅くなり、価格引き上げは年中行事。新規プロジェクトが Auth0 を選ぶ比率は 2023 年から下落傾向。

Stytch — パスワードレス・passkey・magic link を最もうまく作る会社。2024 年から「Fraud Prevention」SDK を追加し、bot・アカウント乗っ取り・合成 ID を ML で検出。料金は B2C 0 ドル（10,000 MAU まで）・249 ドル/月（Pro）、B2B は別。一行リスク: カテゴリが狭い。Stytch だけで全認証を処理することも可能だが、一般 SaaS 認証市場では Clerk・WorkOS と比べて認知度が低い。

Better Auth — 2025 年にインディー市場を奪った OSS TypeScript 認証ライブラリ。フレームワーク非依存（Next.js・Nuxt・SvelteKit・Solid・Astro・Hono・Express…）、DB アダプタ（Drizzle・Prisma・Kysely・MongoDB）、プラグインアーキテクチャ（passkey・magic link・organization・admin・OIDC provider）。MIT ライセンス・セルフホスト。一行リスク: サービスではなくライブラリだ。DB・メール・セッションストア・運用を全部自分でやる。Clerk が与える 30 秒オンボーディングはここには無い。

Kinde — 「Auth0 よりシンプルで安い」を掲げる。オーストラリア発、2024-25 年に急成長。UI・B2B 組織・MFA・ソーシャルが揃い、価格は Auth0 の半分以下。Pro 25 ドル/月（10,500 MAU）、Plus 89 ドル/月（10,500 MAU + 機能拡張）。一行リスク: Auth0・Clerk・WorkOS ほどのエコシステム・統合・ドキュメント深さはまだ不足。

SuperTokens — OSS セルフホストを真剣にサポートする会社。Apache 2.0、Docker で起動、React SDK・Node SDK もよくできている。マネージド SaaS オプションもあるが、コアアイデンティティはセルフホスト。一行リスク: エコシステムが狭い。日本・韓国コミュニティはほぼ無く、B2B Organizations・SAML・SCIM のようなエンタープライズ機能は有料 SaaS ティアに閉じている。

Supabase Auth — Supabase BaaS と統合された認証。Postgres にユーザテーブルが存在し、RLS（Row Level Security）と直結する。既に Supabase を使っているチームには事実上無料。価格は Supabase 料金に含まれる — Pro 25 ドル/月から。一行リスク: Supabase 内でのみ価値。別バックエンドがあり Supabase 以外の DB を使うと不自然になる。

Firebase Auth（Google Identity Platform） — モバイルアプリのデフォルト。Firebase を使う全チームが自動的に使う。価格は 50,000 MAU まで無料、それ以上は MAU あたり 0.0055-0.0025 ドル。一行リスク: ベンダーロックインが強い。Google Cloud 内でのみ本当に滑らかで、他バックエンドからは Admin SDK で薄く繋ぐ。

Auth.js（NextAuth） — Next.js の事実上標準認証ライブラリ。v5 で改名されフレームワーク中立化。OSS・セルフホスト・DB は自分で用意。一行リスク: サービスではなくライブラリ（Better Auth と同カテゴリ）。深さはあるが学習曲線が急で、セッション・DB アダプタ・コールバックを自分で理解する必要。2025-26 年に Better Auth への移動が顕在化。

Logto — OSS セルフホスト型アイデンティティプラットフォーム。MIT ライセンス、OIDC・OAuth2・SAML をサポート、Console UI を提供。Cloud オプションもある。一行リスク: 後発でエコシステム・統合の深さは Keycloak・SuperTokens に及ばない。

Lucia（deprecated） — TypeScript ネイティブのセッションライブラリとして愛されたが、メンテナが 2025 年 3 月に公式に deprecation を発表。新規プロジェクトでは使用禁止。既存プロジェクトは Better Auth・Auth.js・Arctic（同メンテナの後継 OAuth クライアントライブラリ）への移行が必要。

第 3 章 · 機能マトリクス — 1 表で整理

各プロバイダが無料/デフォルトティアで提供するもの。「あり・なし・有料アドオン」の三つだけ。

読み方: マトリクスだけで決めるな。「機能あり」は「プロダクション品質」を保証しない。Clerk の SAML と WorkOS の SAML は同じ単語だが深さが違う。WorkOS はカテゴリを定義した会社、Clerk はアドオンとして付けた会社だ。

第 4 章 · 価格マトリクス — 実際の請求書シミュレーション

抽象的な価格表は無意味だ。3 つの実シナリオで月額請求書をシミュレーションする。

シナリオ A · B2C 消費者向けアプリ（50,000 MAU、MFA・passkey・ソーシャルのみ）

解釈: B2C 50K MAU だけ見ると WorkOS AuthKit・Firebase・Supabase が圧倒的に安い。ライブラリ（Better Auth・Auth.js）はライセンス費 0 だが運用費を忘れてはいけない（次章）。

シナリオ B · B2B SaaS（顧客 200 社、平均 50 シート、SAML 30 パーセント・SCIM 10 パーセント）

解釈: B2B SAML が増えると WorkOS の connection 価格が急に膨らむ。それでも「1 つの SAML 接続を自前で実装する人件費」よりは安い（IdP ごとの互換デバッグで通常 1-2 週間）。Clerk の Enhanced Authentication は絶対価格では最安に見えるが、深さ・ディレクトリ同期品質で WorkOS と差がある。

シナリオ C · グローバル消費者アプリ（500,000 MAU）

解釈: 50 万 MAU の帯はほぼ全ての MAU 課金 SaaS の閾値。Clerk・Auth0・Stytch の請求書が怖くなる。この帯ではセルフホスト（Better Auth + Postgres）あるいは WorkOS AuthKit（現ポリシーの枠内）あるいは Firebase が合理的。

価格は 2026 年 5 月の公式価格ページとリリース情報を基にした推定で、実際の請求書はアドオン・サポート・超過で ±50 パーセント変動しうる。正確な見積もりは自分のワークロードで直接取るべき。

第 5 章 · 意思決定ツリー — どれを選ぶか

8 軸・10 オプション・3 つの価格シナリオを見ても決められないなら、正直なツリーはこれだ。

[Q1] B2C か B2B か両方か?
   |-- 純粋 B2C -> Q2
   |-- 純粋 B2B -> Q4
   '-- 両方 -> Q3

[Q2] B2C: 1 年後の予想 MAU は?
   |-- 1 万未満 -> Clerk Pro または Better Auth / Auth.js（好み）
   |-- 1 万-10 万 -> Clerk / Stytch / Kinde を DX 好みで、または Better Auth セルフホスト
   '-- 10 万超 -> WorkOS AuthKit、Firebase、または Better Auth セルフホスト（Clerk・Auth0 は高くなる）

[Q3] ハイブリッド: 本気で B2B を気にするか?
   |-- B2B は「あれば良い」 -> Clerk + Enhanced Auth または Kinde
   '-- B2B が売上の 50% 超 -> WorkOS（B2C は AuthKit で同時にカバー）

[Q4] B2B: エンタープライズ顧客の割合は?
   |-- SMB・ミッドマーケット中心 -> Clerk・Kinde・Auth0 Pro
   '-- エンタープライズ・SAML・SCIM 必須 -> WorkOS（圧倒的）または Auth0 B2B（予算あり）

[Q5] セルフホスト要件はあるか?
   |-- データ主権・オンプレ義務 -> Keycloak（別記事）または SuperTokens・Logto
   |-- フルスタック TS チームで小さく始める -> Better Auth
   '-- Next.js + DB 自由に扱う -> Better Auth（Auth.js v5 より優勢）

意思決定ヒューリスティック 6 つ:

1. B2B エンタープライズが売上の 50 パーセント超 -> WorkOS が第一候補。 ほぼ他の答えはない。SAML・SCIM・ディレクトリ同期の深さが別カテゴリ。
2. 個人開発・インディー・小規模チーム + Next.js -> Clerk または Better Auth。 二つに絞り、Clerk は「管理したくない」、Better Auth は「OSS・セルフホスト・DB 自由」。
3. 既に Supabase・Firebase を使っているなら -> 同じ BaaS の Auth を使う。 別認証を挟むと RLS・セッションが不自然になる。
4. 新規プロジェクトを Auth0 で始める理由はほぼない。 同じ価格帯で Clerk・Stytch・WorkOS がほぼ全ての面で上。
5. MAU が 50 万を超える可能性が高いなら -> Clerk・Auth0・Stytch の請求書を事前にシミュレーションする。 請求書が怖くなってから移すコストはもっと怖い。
6. Lucia を使っているなら -> 今すぐ移行計画を立てる。 第 9 章参照。

第 6 章 · セルフホスト TCO — 本当に安いのか

「自前で認証を作ろう」あるいは「Keycloak・SuperTokens・Better Auth をセルフホストしよう」という決定は、ほぼ常に初年度の請求書を見てから出る。SaaS Auth0 が月 5,000 ドルを送ってきたが、Keycloak は EC2 インスタンス 1 台 100 ドルで済む。本当にそうか。

5 年 TCO を分解する。

SaaS 側コスト（Clerk・Auth0 B2C など）:

• ライセンス: MAU 単位請求書。10 万 MAU で年間 2 万-10 万ドル。
• 人件費: ほぼ 0。統合初週に 1 人 1 週間。
• 運用負担: 0。ダウンタイムは向こうの SLA。
• 移行コスト: lock-in。出ようとするとパスワードハッシュ・ソーシャル連携・セッションをどう export するか確認が必要。

セルフホスト側コスト（Keycloak・SuperTokens・Better Auth）:

• ライセンス: 0。
• インフラ: インスタンス・DB・ロードバランサ・バックアップ。本気で HA・マルチリージョンなら月 500-2,000 ドル。
• 人件費: 初期セットアップ + 運用。ここが巨大だ。 SRE 1 人の時間 0.1-0.3 FTE。パッチ・アップグレード・インシデント対応・SAML デバッグ。年間で人件費 2-6 万ドル。
• セキュリティ負担: 自分で背負う。CVE 対応・パッチ・脆弱性検査。0-day が出たらその夜が消える。
• コンプライアンス: SOC2・ISO27001 監査を受けると認証システムも対象。別途工数。

5 年累計、10 万 MAU の B2C アプリで非常に単純化したシミュレーション:

Clerk Pro + MAU 追加:
  年平均 4 万ドル × 5 年 = 20 万ドル
  人件費（運用） = 5K（統合作業）+ ほぼ 0（運用） = 5K
  合計: 約 20.5 万ドル

Better Auth セルフホスト:
  ライセンス: 0
  インフラ: 月 800 ドル × 60 ヶ月 = 4.8 万ドル
  人件費: 0.2 FTE × 5 年 × 15 万ドル/年 = 15 万ドル
  合計: 約 20 万ドル

驚きの結果: 5 年 TCO がほぼ同じになる。セルフホストは「タダ」ではない。人件費を正直に計算すると SaaS とほぼ同じになる。SaaS が勝つとき: 認証がコア事業ではなく、小規模チームで、運用時間を他に使いたいとき。セルフホストが勝つとき: データ主権要件、1M MAU 超の帯、認証を深くカスタマイズする必要、認証をうまく運用できる SRE が既にいるとき。

第 7 章 · Clerk vs WorkOS — 最頻出の比較

最もよく受ける質問だ。両方とも作りの良い会社で、カテゴリが違う。

Clerk が勝つケース:

• フルスタック・B2C・Next.js 優先。
• <SignIn />・<UserButton /> のような UI コンポーネントで 30 秒で画面を作りたい。
• 組織機能は「あれば良い」レベル。
• 小規模チーム・インディー・スタートアップ初期。

WorkOS が勝つケース:

• B2B SaaS でエンタープライズ顧客が売上の大きな割合。
• SAML・SCIM が事実上必須（Okta・Azure AD・OneLogin・Google Workspace 連携）。
• 自前のサインアップ UI は既にあり、エンタープライズ readiness だけ追加したい。
• あるいは新規プロジェクトで AuthKit（WorkOS のホスト型ログイン）の 1M MAU 無料が魅力的。

両方使うケースもある。 一部の会社は B2C 部分に Clerk を、エンタープライズ connection に WorkOS を併用する。綺麗ではないが可能。

2026 年の変化: WorkOS AuthKit が SAML・SCIM 以外にソーシャル・パスワードレス・passkey も全部含むホスト UI に進化し、Clerk の領域と重なり始めた。1M MAU 無料ポリシーでインディー・スタートアップも引き込み中。Clerk は反対方向に B2B Organizations・Enhanced Authentication を強化し WorkOS 側に侵入。カテゴリ境界が薄れつつある。

第 8 章 · パスワードレス・passkey・magic link — 2026 年のデフォルト

2026 年の新規プロジェクトでは「パスワードログイン」はデフォルトではない。デフォルトは次の三つのいずれか。

• passkey（WebAuthn）。 デバイスあるいは 1Password・Bitwarden などのパスワードマネージャに保存される公開鍵。iCloud Keychain・Google Password Manager がデバイス間で同期。ユーザは「パスワードを覚える」必要がない。UX 最強・セキュリティ最強。
• Magic link。 メールで一回限りのリンクを送り、クリックするとログイン。UX は非常に単純だが、メール到達遅延・メール認証自体への懐疑がある。
• OTP（メール または SMS）。 6 桁コード。SMS は SIM swap リスクと通信費から推奨度が下がる傾向。

2026 年のトレンドは passkey 優先・magic link 予備・SMS 廃止。Apple・Google・Microsoft が全て OS レベルで passkey をサポートし、デバイス採用率は 80 パーセント超。ユーザの学習曲線も平坦化中。

各プロバイダの passkey 深さ:

magic link はほぼ全プロバイダにある。差はメール到達率・テンプレート カスタマイズ・再送ロジック・attempt rate limit といった細部に出る。

第 9 章 · Lucia 移行 — どこへ何を

Lucia のメンテナ pilcrowOnPaper は 2025 年 3 月に次のメッセージを公式発表した。

• Lucia は「ライブラリ」としての保守を終える。
• 彼が書いた認証学習ガイドは GitHub で無料学習リソースとして維持される。
• 彼が書いた OAuth クライアントライブラリ Arctic は引き続き維持・活発に開発される。
• 新規プロジェクトでは別のライブラリ（または自前実装）を推奨。

移行オプション:

オプション 1 · Better Auth へ — Lucia の精神的後継。TypeScript ネイティブ・セッションベース・DB アダプタ・プラグイン。ユーザテーブル・セッションテーブルのスキーマが似ており（id・user_id・expires_at）、メール+パスワードフローも似ている。2025-26 年の最も人気のある移行経路。

オプション 2 · Auth.js v5 へ — Next.js 中心ならば。アダプタ API が違い、コールバックモデル・セッション処理も違うので変換がやや大きい。

オプション 3 · Arctic + 自前セッション管理 — Lucia から OAuth 部分だけ分離。セッションは自前 DB・cookie で直接管理。「Lucia ガイド精神」をそのまま保つ経路。学習コストは最小だが、コードベースに散らばるセッション管理コードを受容する必要。

オプション 4 · Clerk・WorkOS のような SaaS へ — Lucia の直接管理コストが負担なら。パスワードハッシュ形式の互換性確認が必須。argon2・bcrypt 形式の import はほぼサポートされるが、SCRAM・古い Lucia の SHA-256 のような変種は自前マイグレーションスクリプトが必要なことも。

移行チェックリスト:

• ユーザテーブル export -> 新スキーマへ import。
• パスワードハッシュ形式の互換性検証。
• セッショントークン・cookie 名変更・既存セッション無効化ポリシー。
• メール認証・リセットトークンの処理。
• ソーシャル連携（OAuth provider ごとの user_id マッピング）の保存。
• 段階的移行（dual-write）と一気に切り替え（big-bang）の選択。

第 10 章 · NextAuth（Auth.js）vs Better Auth — Next.js ライブラリの選択

セルフホストライブラリを選ぶならば二つに絞られる。

Auth.js（旧 NextAuth） — 古くからの安定性・大きなユーザベース・多くの統合。v5 で auth() ヘルパー・App Router 友好・@auth/core でフレームワーク中立化。短所: コールバック API が複雑（signIn・session・jwt）で、DB アダプタごとに挙動が微妙に違う。深く入ると学習曲線が急。

Better Auth — 2024 年登場・2025-26 年に爆発的成長。API がより直感的でプラグインシステムがすっきりしており、DB スキーマ自動生成・CLI ツール提供。TypeScript の型推論がより強力。Drizzle・Prisma・Kysely・MongoDB アダプタ。Next.js・Nuxt・SvelteKit・Solid・Astro・Hono・Express・Tanstack Start を全て一級サポート。

選択基準:

• 既に Auth.js を使っており挙動に満足 -> あえて移る理由なし。
• 新規プロジェクト -> Better Auth が優勢。DX・プラグインシステム・ドキュメントが良い。
• マルチフレームワーク（Next.js 以外にも SvelteKit・Hono など）で同じ認証を使う -> Better Auth。

2026 年現在の npm トレンド: Auth.js は安定したユーザベースを維持、Better Auth は爆発的成長中。Auth.js メンテナも Better Auth の一部設計を取り込み始めている。

第 11 章 · アンチパターン — よくある誤り 10 個

ここ 1 年のコードレビュー・技術コンサルで見た実例。

1. JWT をセッション代わりに使い revoke がない。 Access token TTL 24 時間 + revoke なし = 解雇された社員が 1 日中 API を叩ける。短い TTL + refresh + revoke リストかセッションベースに。
2. Auth0 を使いながら全機能を自前実装。 サインアップフォーム・メール送信・MFA を自分で作るならば Auth0 を買った理由がない。Universal Login か SDK ウィジェットを使え。
3. Clerk・Stytch の移行コストを 0 と仮定。 「MAU が増えたら他へ移せばいい」 — 実際にパスワードハッシュ・ソーシャル連携・セッションが export できるか事前確認。
4. WorkOS を SAML なしで高く買う。 WorkOS の第一価値はエンタープライズ SSO。SAML・SCIM がないなら WorkOS の価値の半分を使っていない。
5. Supabase Auth + 別 Postgres。 Supabase Auth は Supabase Postgres にユーザテーブルが住んでこそ RLS・トリガが自然。別 DB に登録情報を移すと不自然になる。
6. passkey を追加したがバックアップ fallback がない。 デバイスを失ったユーザはロックアウト。magic link または復旧コードのバックアップフローが必須。
7. SAML デバッグを自前実装で試みる。 Okta・Azure AD・OneLogin・Google Workspace それぞれの quirk があり、IdP-initiated と SP-initiated のフローも違う。2 週間泥沼に入る。WorkOS が高い理由。
8. MAU 価格を自社の MAU 定義と一致させていない。 プロバイダの MAU 定義（例: 月に 1 度でもログインしたユーザ、あるいはセッションが期限切れでないユーザ）と自分のビジネスの MAU が違うかもしれない。登録 100 万・実アクティブ 5 万ならば請求書が違う。
9. passkey を「追加した」だけで計測しない。 実利用率はサインアップフロー・UI コピー・iOS/Android 比率に大きく左右される。計測・実験なしで「あり」のチェックだけ埋めると ROI が疑わしい。
10. Lucia を使っていて移行計画がない。 1 年以内に必須になる。先延ばしするな。

エピローグ — 決定チェックリストと次回予告

決定チェックリスト

• ターゲット市場の明確化: B2C・B2B・ハイブリッドのどれか?
• 1 年・3 年の予想 MAU シミュレーション。
• エンタープライズ顧客の割合・SAML・SCIM 義務性。
• セルフホスト vs SaaS の決定（TCO 5 年比較）。
• passkey・magic link・MFA ポリシー。
• 移行コストの事前評価（lock-in 軸）。
• データ主権・リージョン要件（特に EU・韓国・日本）。
• コンプライアンス要求（SOC2・ISO27001・HIPAA・GDPR・APPI）。
• 運用負担 vs 人件費の正直な評価。
• そして最も重要なこと: 「最も悪く見えるオプションは自前で作ることだ」 — 2 年後に後悔する。

アンチパターン総括

• 認証を自前で作る。
• MAU 価格を最初だけ計算し 1 年後を見ない。
• Auth0 をデフォルトで選ぶ（2026 年にはもはやデフォルトではない）。
• セルフホストを「無料」と仮定する。
• passkey を追加するが計測・fallback なし。

次回予告

• 「WorkOS AuthKit ハンズオン — Next.js に 1M MAU 無料認証 30 分セットアップ」
• 「Better Auth フルスタック セットアップ — Drizzle・Postgres・Resend・passkey プラグインガイド」
• 「エンタープライズ SAML デバッグ — Okta・Azure AD・OneLogin・Google Workspace 互換マトリクス」
• 「認証マイグレーション — パスワードハッシュ互換と段階的カットオーバーパターン」

次のプロジェクトの認証を決める必要があるなら、本稿の 8 軸・10 オプション・決定ツリーで 30 分以内に候補を 2-3 個に絞れ。そしてその 2-3 個の価格ページを直接開いて自分のワークロードで実見積もりを取れ。推測で認証を決めるな。

参考 / References

• Clerk Pricing
• Clerk B2B SaaS Authentication Guide
• Clerk vs Auth0 — Comparison
• WorkOS Pricing
• WorkOS AuthKit — 1M MAU Free
• WorkOS vs Auth0 — Documentation
• Auth0 Pricing
• Auth0 by Okta — Official site
• Stytch Pricing
• Stytch Fraud Prevention
• Better Auth — Official site
• Better Auth GitHub
• Lucia Deprecation Announcement — pilcrowOnPaper
• Migrating off Lucia — Better Auth docs
• Auth.js (NextAuth) v5 Docs
• SuperTokens — Open Source Authentication
• SuperTokens vs Auth0 — Comparison
• Kinde Pricing
• Logto — Open Source Identity
• Supabase Auth Docs
• Firebase Authentication Pricing
• WebAuthn / Passkeys — W3C Spec
• FIDO Alliance — Passkeys Overview
• SCIM 2.0 RFC 7644
• SAML 2.0 Core Specification