Next.js × Vercel、認証は何を選ぶ？実務で使える選定基準

Next.js × Vercel、認証は何を選ぶ？実務で使える選定基準

本記事のサマリ

Next.jsアプリをVercelにデプロイする際、認証をどう実装するか迷っていませんか？Auth.js、Clerk、Supabase Auth、Firebase Auth、それとも自前実装？この記事では、それぞれの特徴を整理し、プロジェクトの要件に応じた選定基準を解説します。予算、開発スピード、カスタマイズ性、運用保守の観点から、実務で判断する際のポイントをまとめました。

Next.jsで選べる認証の選択肢

では、Next.jsアプリでユーザー認証を実装したい場合、どんな選択肢があるのでしょうか？主要なものを挙げてみます：

1. Auth.js（旧NextAuth.js）- オープンソースの定番ライブラリ
2. Clerk - DX重視のマネージドサービス
3. Supabase Auth - データベースと統合された認証サービス
4. Firebase Auth - Googleが提供する老舗認証サービス
5. 自前実装 - Next.js公式ドキュメントに従った独自実装

それぞれの特徴を見ていきましょう。

Auth.js（NextAuth.js）- オープンソースの定番

Auth.jsは、長年Next.jsコミュニティで愛用されてきた認証ライブラリです。以前はNextAuth.jsという名前でしたが、他のフレームワークにも対応するためAuth.jsに名称変更されました。

https://authjs.dev/

主な特徴

• 完全に無料で使用可能
• OAuth（Google、GitHub、Twitter等）から認証情報ベース、マジックリンクまで幅広いプロバイダーに対応
• セッション管理機能が組み込まれている
• データベースアダプターが豊富で、様々なデータベースと連携可能

ただし、正直に言うと課題もあります。v5は現在もベータ版扱いで、ドキュメントの質について不満の声を聞くことも多いです。GitHubのIssueを見ても、「ドキュメントがわかりにくい」という議論がよく見られますね。

とはいえ、本番環境で使用している企業も多く、実績は十分にあります。コストを抑えつつ、柔軟なカスタマイズを求める場合の第一選択肢と言えるでしょう。

Clerk - DX重視のマネージドサービス

Clerkは、開発者体験（DX）に特化したマネージド認証サービスです。近年、特にスタートアップ界隈で人気が高まっています。（これは私知りませんでした...）

主な特徴

• セットアップから本番レベルの認証実装まで、約30分程度で完了
• 美しいUIコンポーネントが最初から提供される
• ユーザープロファイル、組織管理、多要素認証などが標準装備
• ダッシュボードでユーザー管理が簡単にできる

有料サービスではありますが、無料枠もあります。何より、「とにかく早く認証機能を実装したい」という場面では圧倒的に便利です。

プロトタイプを作る時や、アイデア検証段階では本当に重宝するサービスだと思います！

Supabase Auth - データベースと統合

Supabaseは、「オープンソースのFirebase代替」として注目されているBaaS（Backend as a Service）です。その一部として提供されているのがSupabase Authです。

主な特徴

• PostgreSQLデータベースと認証機能がセットで提供される
• オープンソースなので、セルフホスティングも可能
• リアルタイムデータベース機能と組み合わせて使える
• Auth.jsと比べて、データベースとの連携設定が簡単

データベースも必要なプロジェクトの場合、Supabaseなら認証とデータベースを一箇所で管理できるので、運用が楽になります。特に、リアルタイム機能を使いたいアプリには相性が良いですね。

Firebase Auth - Googleのサービス

Firebase Authenticationは、Googleが提供する長い実績を持つ認証サービスです。Firebaseエコシステムの一部として提供されており、多くの企業で採用されています。

主な特徴

• Google、Apple、Facebook、Twitter等の主要SNSログインに対応
• 電話番号認証、匿名認証など豊富な認証方法
• Firestoreやその他Firebase サービスとシームレスに連携
• 無料枠が大きい（月間50,000認証まで無料）
• モバイルアプリとの統一した認証基盤を構築できる

Firebase Authは、Web単体でも十分強力ですが、モバイルアプリも開発する予定がある場合に特に強みを発揮します。Next.jsとFirebaseの組み合わせは少し設定が必要ですが、Firebase SDKが充実しているため実装はそこまで難しくありません。

すでにFirebaseの他の機能（Firestore、Cloud Functions等）を使っている場合は、認証もFirebaseで統一する方が管理しやすいですね。ログイン状態を各サービスで共有できるので、バックエンドの実装もシンプルになります。

自前実装 - Next.js公式アプローチ

Next.js公式ドキュメントでは、認証の自前実装についても詳しく解説されています。

https://nextjs.org/docs/pages/guides/authentication

特徴

• 完全に自分でコントロールできる
• セキュリティ要件が厳しい企業向け
• JWTやSession Cookieを使った実装方法が学べる
• iron-sessionやjoseなどのライブラリを活用

ただし、セキュリティを正しく実装するには相当な知識が必要です。特に、セッション管理やCSRF対策、XSS対策などを適切に行う必要があります。よほどの理由がない限り、既存の認証ライブラリを使うことをおすすめします。

選定基準を整理する

さて、どの認証方式を選ぶかは、プロジェクトの要件によって変わってきます。判断の軸を整理してみましょう。

予算と運用コスト

完全無料

• Auth.js
• 自前実装

無料枠あり（一定規模まで無料）

• Clerk（月間10,000MAU、10,000API呼び出しまで無料）
• Supabase（月間50,000MAU、500MBデータベースまで無料）
• Firebase Auth（月間50,000認証まで無料）

データベース込みでお得

• Supabase（認証とPostgreSQLデータベースがセット）

開発スピード

最速（30分程度）

• Clerk - UIコンポーネント付きで、設定だけで済む

中程度（半日〜数日）

• Firebase Auth - Firebase プロジェクト設定とSDK統合が必要
• Supabase Auth - データベーススキーマの設計が必要
• Auth.js - プロバイダー設定とUI実装が必要

時間がかかる（1週間以上）

• 自前実装 - セキュリティ考慮で慎重な実装が必要

カスタマイズ性

高い

• 自前実装 - 全て自分で制御可能
• Auth.js - コールバック関数やアダプターでカスタマイズ性が高い

中程度

• Supabase Auth - RLS（Row Level Security）でデータアクセス制御可能

限定的（ただし十分）

• Clerk - テーマや一部UIはカスタマイズ可能、ほとんどのユースケースはカバー

運用保守

楽

• Clerk - 完全マネージド、アップデートやセキュリティ対応不要
• Firebase Auth - Google管理の安定したサービス、スケーラビリティも高い
• Supabase - マネージドサービス、バックアップも自動

自分で管理

• Auth.js - ライブラリのアップデート、セキュリティ対応が必要
• 自前実装 - 全責任を自分で負う

私の選択基準

実務でプロジェクトの技術選定に関わる中で、以下のような判断基準を持っています：

プロトタイプやスタートアップの初期段階
→ Clerk

理由：とにかくスピード重視。アイデア検証が最優先で、認証機能にかける工数は最小にしたい。UIも綺麗だから、デモやピッチでも見栄えが良い。

データベースも必要な一般的なWebアプリ
→ Supabase

理由：認証とデータベースを一箇所で管理できて運用が楽。PostgreSQLなので、将来的にスケールしても安心。オープンソースだから、将来的にセルフホスティングに移行することも可能。

コストを抑えたい、細かくカスタマイズしたい
→ Auth.js

理由：完全無料で、OAuth プロバイダーも豊富。ドキュメントに課題はあるものの、コミュニティが活発でStack Overflowなどで情報は見つかる。

Firebaseエコシステムを利用中、またはモバイルアプリも視野に
→ Firebase Auth

理由：すでにFirestore等を使っている場合は認証も統一する方が楽。将来的にモバイルアプリを開発する際もWebとUIDを統一できる。Googleの安定した基盤で運用できる安心感もある。

セキュリティ要件が厳しい、完全にコントロールしたい
→ 自前実装

理由：金融系など、認証周りを外部サービスに依存したくない場合。ただし、セキュリティエンジニアがチームにいることが前提。

まとめ

Next.jsで認証を実装する際の選択肢は：

1. Auth.js - 無料でカスタマイズ性重視
2. Clerk - 開発スピード重視
3. Supabase Auth - データベースとセット、バランス型
4. Firebase Auth - モバイルとの統合、安定性重視
5. 自前実装 - 完全制御が必要

どれを選ぶかは、プロジェクトの予算、開発期間、セキュリティ要件、チームのスキルレベルなどを総合的に判断して決めることが重要です。

迷った時は、まずNext.js公式の認証ガイドを読んで、認証の基本概念を理解することから始めることをおすすめします👍

認証は、どのWebアプリでも避けて通れない重要な機能です。適切な選択をして、セキュアで使いやすいアプリを作っていきましょう！

😱おまけ：「Vercel Auth」という誤解について

最後に、よくある誤解について触れておきます。「Vercel Auth」や「Vercel Authentication」と聞くと、Next.jsアプリ用の認証ライブラリがあるように思えませんか？

実は、これは誤解です。

Vercel Authenticationは、アプリのユーザー認証機能ではありません。これは、Vercelにデプロイしたアプリ自体へのアクセスを制限するための「デプロイ保護機能」です。

https://vercel.com/docs/deployment-protection/methods-to-protect-deployments/vercel-authentication

具体的には、プレビューデプロイやステージング環境にアクセスする際に、Vercelアカウントでログインしているユーザーのみがそのデプロイを閲覧できるようにする機能です。開発チームの内部メンバーや承認された関係者だけが、本番環境に公開する前のバージョンを確認できるようにするためのものですね。

つまり、アプリのユーザーが「ログイン」や「会員登録」を行うための機能とは全く別物です。混同しないように注意しましょう👍