本記事のサマリ
2025年9月に、長らくNext.jsエコシステムで愛用されてきたAuth.js（旧NextAuth.js）がBetter Authチームによって正式に引き継がれました。この記事では、このニュースの背景と、TypeScript firstで設計されたBetter Authの特徴、従来のAuth.jsとの違いについて調べた結果をまとめています。
はじめに - 認証ライブラリに起きた大きな変化
9月のある日...Web開発界隈に少し驚きのニュースが流れました。Next.jsアプリケーションの認証といえば必ずといっていいほど名前が挙がるAuth.js（旧NextAuth.js）が、Better Authという新しいチームによって引き継がれることになったのです。
Auth.jsは長年にわたってJavaScript/TypeScriptエコシステムで広く使われてきた認証ライブラリです。ChatGPT、Google Labs、Cal.comなど、名だたるサービスでも採用されているほどの信頼と実績があります。そんな重要なプロジェクトが新しいチームに引き継がれるというのは、なかなかインパクトのある出来事です。
でも、なぜこんなことが起きたのでしょうか？公式発表によると、Auth.jsチームは認証の将来像について大きなビジョンを持っていたものの、様々な理由でそれを完全に実現できずにいたとのことです。具体的には「アプリケーションが複雑化し、認証のニーズが進化する中で、Auth.jsの当初の設計範囲では限界が見え始めていた」と述べられています。同じプリミティブを何度も再実装するような状況が発生していたようです。
GitHubの公式発表では、より率直に「この1年でメンテナンスのペースが落ちた。メンテナーが異動し、時間が限られ、プロジェクトの規模が責任を持ってサポートできる範囲を超えてしまった」と認めています。Better Authチームは同様の課題感を持ち、既にその解決策を形にしていました。両者のゴールが一致していることから、この引き継ぎが実現したとのことです。
つまり、Auth.jsは完全に新規開発を停止するわけではなく、Better Authチームによってセキュリティパッチと緊急の問題対応は継続されます。ただし、新機能の開発は基本的にBetter Authに集約される方向性です。
Better Authとは何か
Better Authは2024年に登場したTypeScript向けの包括的な認証・認可フレームワークです。「TypeScript first」を謳うだけあって、型安全性を重視した設計になっています。
特徴的なのは、従来の認証ライブラリでは追加の設定や外部パッケージが必要だった機能が、最初から標準で搭載されていることです。2要素認証（2FA）、組織管理、マルチセッション対応、レート制限など、現代のWebアプリケーションで求められる機能が揃っています✨
また、フレームワーク非依存の設計も注目すべき点です。Next.jsだけでなく、SvelteKit、Express、Fastifyなど、様々なフレームワークで利用できます。プラグインシステムによって機能を拡張できるのも魅力的ですね。
完全にオープンソースで、使用量に基づく課金もありません。これは管理サービス型の認証ソリューションと比較すると、大きなアドバンテージです。
Auth.jsとの違いを見てみる
では、具体的にAuth.jsと何が違うのでしょうか？実際に比較してみます。
実は、Better AuthとAuth.jsの違いは単なる「機能の追加」や「設定の簡単さ」といった表面的なものだけではありません。設計思想そのものが大きく異なります。
設計思想の違い：サーバー専用 vs クライアント/サーバー混在
まず根本的な違いとして、Auth.jsは「クライアント/サーバー混在型」の設計です。useSession のようなクライアントフックがあり、クライアント側でもセッション情報を直接扱えます。
これはNextAuthから引き継がれた設計で、フロントエンドとバックエンドの境界が曖昧になりがちでした。
一方、Better Authは「完全にサーバー専用」の思想で設計されています。
認証処理はすべてサーバー側で完結し、クライアントはサーバーが発行したトークンを使うだけ。この明確な役割分担が、コードの見通しを良くしています。
セッション管理の違い：ハイブリッド方式 vs Cookie中心
セッション管理のアプローチも大きく異なります。
Auth.jsはCookieベースのセッションを中心に設計されており、JWTやDBセッションは後付けで切り替えるような形でした。
この設計のため、データベーススキーマについてAuth.js側は基本的に関与しません。
Better Authは「DBセッション + 署名済みCookie」のハイブリッド方式を標準としています。
セッション情報をデータベースにしっかり保存しつつ、署名済みCookieでトークンを管理する。この設計のため、データベース構造に強く依存します。だからこそ、（Sessionテーブルなどについて）スキーマの自動生成やマイグレーション機能が不可欠になっているわけです。
API設計の違い：コードファースト vs 設定型
Auth.jsは「設定型」の設計で、プロバイダーを配列で並べて設定していくスタイルです。
カスタマイズは主にコールバック関数で行いますが、複雑な認可ロジックはMiddlewareで実装することになり、コードが分散しがちでした。
Better Authは「コードファースト」で、すべてが関数ベースです。
カスタムロジックを「設定」ではなく「コード」として自然に書けるため、TypeScriptの型システムの恩恵を最大限受けられます。
セットアップの簡潔さ
こうした設計思想の違いが、実際のセットアップにも表れています。Auth.jsでは複数のファイルを作成し、アダプターやプロバイダーの設定を行う必要がありました。一方、Better Authは設定ファイル1つでほぼ完結します。
なぜデータベーススキーマの自動生成が必要なのか？
ここが重要なポイントです。Better AuthがDBスキーマを自動生成する理由は、単なる「便利機能」ではありません。Better Authのセッション管理戦略（DBセッション + 署名済みCookie）を正しく動かすために、データベース構造が不可欠だからです。
Auth.jsはCookieセッション中心の設計だったため、データベース構造に深く関与する必要がありませんでした。一方、Better Authはセッション情報をデータベースでしっかり管理するため、スキーマの定義が認証機能の中核となります。
Better Authはデフォルトで軽量なクエリビルダー「Kysely」を内蔵していますが、PrismaやDrizzleなどの既存ORMとも連携できるアダプター方式を採用しています。
CLIツールの generate コマンドは、使用しているORM/アダプターに応じた適切なスキーマファイルを生成してくれます。Prismaならば .prisma ファイル、Drizzleならば TypeScript の schema 定義、Kyselyならば SQL ファイルといった具合です。
ただし、ここで重要なのは generate はあくまで「スキーマファイルの生成」までしか行わないという点です。例えばPrismaを使っている場合、Better Authが .prisma ファイルを作ってくれた後、実際にデータベースにテーブルを作成するのは prisma migrate dev など、各ORMの責任になります。
一方、migrate コマンドは Kysely アダプター使用時のみ動作し、データベースに直接マイグレーションを実行します。これはKyselyが内蔵されているため、Better Auth側で完結できるわけです。
つまり、Better Auth自体がORMになっているわけではなく、「セッション管理に必要なテーブル定義を標準化し、それを各ORMの形式で生成してくれるツール」という位置づけです。この仕組みがあるからこそ、Better Authのハイブリッドセッション戦略が機能するわけですね。
型安全性の向上
Better Authの最大の売りの一つが型安全性です。設定から実際の使用まで、全てがTypeScriptの型システムの恩恵を受けられるように設計されています。
Auth.jsも型定義は提供していましたが、Better Authはより徹底しています。例えば、プラグインを有効化すると、それに関連するAPIメソッドや型定義が自動的に利用可能になります。開発時のインテリセンスやエラーチェックがより効果的に働くということです。
データベーススキーマの違い
技術的な違いとして、データベーススキーマの設計思想が異なります。
主な違いをいくつか挙げると：
- 命名規則：Auth.jsは
snake_case、Better AuthはcamelCase - セッションテーブル：Auth.jsの
sessionTokenに対してBetter Authはtoken - タイムスタンプ：Better Authは
createdAtとupdatedAtを標準で含む - アカウントテーブル：Better Authは
accountIdフィールドを追加し、内部IDと区別
これらの違いは、Better Authがより現代的なAPI設計を志向していることを示しています。
機能面での違い
こうした設計思想の違いは、提供される機能にも表れています。
Auth.jsは「最小限の認証機能」をベースに、必要に応じて拡張していくスタイルでした。
これはコールバックベースの設計と相性が良く、シンプルなユースケースでは扱いやすかったものの、複雑な要件に対応しようとするとカスタマイズが難しくなりがちでした。
Better Authは「包括的な認証機能」を最初から提供するスタイルです。
2要素認証、組織管理、マルチセッション対応、レート制限など、現代のWebアプリケーションで求められる機能が標準搭載されています。これらは単なる「おまけ機能」ではなく、コードファーストのAPI設計と型安全性の恩恵を受けながら、自然に扱えるように設計されています。
特に組織管理機能が標準搭載されているのは大きな違いです。
SaaSアプリケーションを開発する場合、チーム機能やロール管理は必須ですが、Auth.jsではこれらを自前で実装し、認証ロジックとは別に管理する必要がありました。Better Authではプラグインとして統合されており、認証フローと一体化して扱えます。
実際のコード例で比較してみる
具体的なコード例で違いを見てみましょう。
Better Authの設定例：
// auth.ts
import { betterAuth } from "better-auth"
import { organization } from "better-auth/plugins"
export const auth = betterAuth({
database: {
dialect: "postgresql",
url: process.env.DATABASE_URL
},
emailAndPassword: {
enabled: true
},
socialProviders: {
github: {
clientId: process.env.GITHUB_CLIENT_ID!,
clientSecret: process.env.GITHUB_CLIENT_SECRET!
}
},
plugins: [
organization({
allowUserToCreateOrganization: true
})
]
})
同等の機能をAuth.jsで実現しようとすると、より多くの設定が必要になります：
// auth.config.ts
import GitHub from "next-auth/providers/github"
import Credentials from "next-auth/providers/credentials"
export default {
providers: [
GitHub({
clientId: process.env.GITHUB_CLIENT_ID,
clientSecret: process.env.GITHUB_CLIENT_SECRET
}),
Credentials({
// 独自の認証ロジックを実装
})
]
}
// auth.ts
import NextAuth from "next-auth"
import { PrismaAdapter } from "@auth/prisma-adapter"
import authConfig from "./auth.config"
export const { auth, handlers } = NextAuth({
adapter: PrismaAdapter(prisma),
session: { strategy: "jwt" },
...authConfig,
callbacks: {
// 組織管理などは独自に実装が必要
}
})
クライアント側のAPIも、Better Authの方がより直感的です：
// Better Auth
import { authClient } from "./lib/auth-client"
const { data, error } = await authClient.signUp.email({
email: "user@example.com",
password: "password123",
name: "John Doe"
})
// Organization作成も簡単
const { data: org } = await authClient.organization.create({
name: "My Company",
slug: "my-company"
})
Auth.jsからの移行について
既存のAuth.jsプロジェクトをBetter Authに移行したい場合はどうでしょうか？
公式のマイグレーションガイドが用意されており、データベーススキーマの違いや設定の変更点が詳しく説明されています。自動マイグレーションツールも提供されているので、手動でのデータ移行作業は最小限に抑えられそうです。
ただし、マイグレーションはそれなりに慎重に進める必要があります。特にプロダクション環境で稼働しているアプリケーションの場合、ユーザーデータの整合性を保ちながら移行を進めることが重要です。
公式発表では、Auth.jsは引き続きセキュリティパッチや緊急の問題には対応するとのことですから、すぐに移行しなければならないわけではありません。ただし、新機能の追加はBetter Authに集約される方向性なので、新規プロジェクトについてはBetter Authの使用が推奨されています👍
エコシステムの分断を避け、収束させていくという明確な意図があるようです。
おわりに - どう選ぶべきか
では、結局どちらを選ぶべきでしょうか？
既存のAuth.jsプロジェクトが問題なく動いている場合、急いで移行する必要はないと思います。Better Authチームが引き継いだ形でセキュリティパッチや緊急の問題対応は継続されます。ただし、新機能の開発は基本的にBetter Authで行われることになるので、長期的にはBetter Authへの移行を検討することになるでしょう。
一方、新規プロジェクトや、認証周りで課題を抱えているプロジェクトについては、Better Authを検討する価値は十分にあります。特にTypeScriptを使っているプロジェクトや、組織管理機能が必要なSaaSアプリケーションでは、Better Authのメリットを大きく感じられるはずです。
認証は複雑な分野で、一つの解決策が全ての課題を解決してくれるわけではありません。でも、Better AuthがAuth.jsの後継として開発され、実際に引き継がれたという事実は、その完成度と将来性を示していると考えられます。
Auth.jsが「設定型で柔軟なCookieセッション」を武器にしてきたのに対し、Better Authは「コードファーストでDBセッション中心」という別のアプローチを選択しました。この設計思想の違いが、セットアップの簡潔さ、型安全性、機能の充実度といった形で表れているわけです。
Better AuthがAuth.jsの遺産を受け継ぎつつ、さらに良い開発体験を提供してくれることを期待しています！
参考資料
- Better Auth公式ドキュメント：https://www.better-auth.com/docs/introduction
- Auth.js引き継ぎの発表：https://www.better-auth.com/blog/authjs-joins-better-auth
- マイグレーションガイド：https://www.better-auth.com/docs/guides/next-auth-migration-guide
- Better StackによるAuth比較記事：https://betterstack.com/community/guides/scaling-nodejs/better-auth-vs-nextauth-authjs-vs-autho/
株式会社StellarCreate（stellar-create.co.jp）のエンジニアブログです。 プロダクト指向のフルスタックエンジニアを目指す方募集中です！ カジュアル面談で気軽に雑談しましょう！→ recruit.stellar-create.co.jp/
Discussion