AIのあとしまつ

事例・基礎知識

Clerk vs NextAuth：AI開発のMVPで選ぶべき認証機能はどっち？実装の手間とコスト比較

MVP開発において認証機能の選定は重要です。実装の手軽さとカスタマイズ性の観点で、ClerkとNextAuthを比較解説します。

Clerk NextAuth 比較認証機能 実装 選び方MVP ログイン機能Clerk 料金 メリットNextAuth 使い方認証 SaaS 比較Next.js 認証 おすすめログイン機能 外注 vs 自作

MVP開発において、必ず必要になるにも関わらず実装が面倒で、かつミスると取り返しのつかない機能があります。それが「認証（ログイン）」です。

なぜ取り返しがつかないのか。認証に脆弱性があると、ユーザーのアカウントが乗っ取られ、個人情報が漏洩し、最悪の場合はサービスそのものを終了せざるを得なくなります。7payが3ヶ月でサービス終了した事例は、認証の設計ミスがいかに致命的かを示しています。

現在、Next.jsでの開発において主流な選択肢は Clerk と NextAuth.js（Auth.js） の2つです。「どちらを選ぶべきか」に対して、明確な答えを出します。

比較表：Clerk vs NextAuth

項目ClerkNextAuth.js
初期実装時間30分〜1時間1〜3日
必要なコード量数十行数百行
セキュリティのデフォルト値高い（設定済み）自分で設定が必要
UIコンポーネント付属（カスタマイズ可）自前で実装
OAuth対応Google, GitHub, Apple等 20以上同等
MFA（多要素認証）デフォルトで対応自前実装が必要
無料枠10,000 MAU/月無制限（自費ホスト）
スケール時コスト$25/月〜（Pro）サーバー費用のみ
管理ダッシュボード充実（SaaS UI）なし
カスタマイズ性中（制約あり）高（何でもできる）
サポート品質ドキュメント充実、有料プランでサポートコミュニティ依存

Clerk：爆速開発の選択肢

実装のシンプルさが圧倒的

Clerkの最大の強みは、数行のコードで本番レベルの認証が完成することです。

// middleware.ts — これだけで全ページに認証を適用できる
import { clerkMiddleware, createRouteMatcher } from "@clerk/nextjs/server";

const isPublicRoute = createRouteMatcher(["/", "/sign-in(.*)", "/sign-up(.*)"]);

export default clerkMiddleware(async (auth, request) => {
  if (!isPublicRoute(request)) {
    await auth.protect();
  }
});

export const config = {
  matcher: ["/((?!.*\\..*|_next).*)", "/", "/(api|trpc)(.*)"],
};

// layout.tsx — ClerkProviderでラップするだけ
import { ClerkProvider } from "@clerk/nextjs";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <ClerkProvider>
      <html lang="ja">
        <body>{children}</body>
      </html>
    </ClerkProvider>
  );
}

これだけで、サインアップ・ログイン・パスワードリセット・プロフィール管理・セッション管理がすべて動きます。ログイン画面のUIも既製品が提供されています。

Clerkに含まれている機能

  • メールアドレス＋パスワード認証
  • マジックリンク（パスワードなしのメールログイン）
  • Google、GitHub、Apple等のOAuth（20以上のプロバイダ）
  • SMS認証
  • MFA（多要素認証）
  • ユーザー管理ダッシュボード
  • Webhook（ユーザー作成・削除イベントを外部に通知）
  • 組織・チーム機能（Proプラン以上）

料金

  • Free: 月間10,000 MAUまで無料。個人開発の初期フェーズはほぼこれで賄える
  • Pro: $25/月〜（10,000 MAUを超えた分は追加課金）
  • 注意点: MAU（Monthly Active User）課金なので、ユーザーが増えるほどコストが上がる

Clerkの制約

UIコンポーネントのデザインカスタマイズには一定の制約があります。CSSで色やフォントは変更できますが、コンポーネントのレイアウト自体を大きく変えることは難しい。また、Clerkへの依存が深くなるため、後でNextAuthに移行する場合はそれなりの工数が発生します。

NextAuth.js（Auth.js）：完全制御の選択肢

何が提供されていて何を自前で作る必要があるか

NextAuthが提供するもの：

  • OAuthプロバイダとの接続処理
  • JWTベースのセッション管理
  • DBアダプター（Prisma、Drizzle等と接続する仕組み）

自前で実装する必要があるもの：

  • ログイン画面のUI（全部）
  • サインアップフロー（NextAuthにはデフォルトのサインアップがない）
  • メール確認フロー
  • パスワードリセット機能（メール送信含む）
  • アカウント管理画面

つまりNextAuthを選ぶということは、「認証ライブラリを使いながらも、認証関連の画面・フロー・UIを全部自分で作る」ということです。これは思ったより工数がかかります。

NextAuthのよくある罠

  • JWTシークレットのローテーション: シークレットを変更すると既存の全セッションが無効になる。ユーザーが強制ログアウトされる
  • メールアドレス変更時のセッション無効化: ユーザーがメアドを変更しても、古いセッションが残り続ける。これはセキュリティリスク
  • セッションの有効期限管理: デフォルト設定のままだと長すぎる有効期限になることがある

NextAuthが適しているケース

  • 完全にカスタムな認証フローが必要（例：社内システムとのSSO連携）
  • 特定のDBスキーマに合わせた実装が必要
  • 将来的にエンタープライズ向けに拡張する可能性がある
  • MAUが多くClerkのコストが無視できなくなってきた

第3の選択肢：Supabase Auth

Supabaseを使っている場合は、Supabase Authという選択肢もあります。データベースと認証が統合されており、RLSポリシーでDBレベルのアクセス制御が書きやすいのが特徴です。無料枠は5万MAUまで対応しており、Supabaseを中心に構築するアーキテクチャなら最も自然な選択肢です。

ただしClerkほどUIが整っていないため、ある程度の実装は自分で必要です。

結論：2025年のMVPにはClerkが正解

AIを使って「2週間でリリースしたい」と考えるなら、迷わずClerkを選んでください。

理由は3つです。

  1. 認証機能の実装に3日かけるより、コア機能の開発に使うべきだから。Clerkなら認証周りは30分〜1時間で終わる
  2. セキュリティのデフォルト値が高く、事故が起きにくいから。自前実装でよくある「パスワードリセットの設計ミス」「セッション管理の不備」がない
  3. 無料枠（10,000 MAU）はほとんどのMVPには十分すぎるから

「認証機能でバグが出てリリースできない」「認証の設計ミスでユーザーデータが漏洩した」——こうした事態を防ぐためにも、実績のある認証SaaSに任せることを強くすすめます。コストが問題になるのは、ユーザーが増えてからです。それは嬉しい悩みです。

ブログ一覧へ戻る