はじめに

前回の記事では、ログイン機能の根底にある「認証（本人確認）」と「認可（権限チェック）」の違いについて整理しました。

その中で、一度ログインした後はパスワードを毎回送るのではなく、「ログイン証明書」を使い回してやり取りしているという全体像をお話ししました。

Next.jsで認証を実装する際の定番ライブラリであるNextAuth（Auth.js）を使う場合、この証明書の持たせ方として2つの選択肢が用意されています。

それが「JWT（トークン）戦略」と「データベースセッション戦略」です。

「とりあえず動いたからデフォルトのままでいいや」と流してしまいがちな部分ですが、この2つの仕組みとトレードオフを理解していないと、後々インフラのコストやセキュリティの設計で頭を抱えることになります。

今回は、それぞれの裏側の仕組みと、個人開発における現実的な選定基準を解説します。

1. そもそも「ログイン状態」はどう保持されるのか

具体的な方式の話に入る前に、そもそもなぜわざわざ証明書を発行して持ち歩く必要があるのか、その前提を押さえておきましょう。

Webの通信（HTTPプロトコル）には、もともと「ステートレス（状態を保持しない）」という冷たいルールがあります。

ユーザーがログインに成功して「マイページ」へ移動したとしても、サーバー側は「さっきログインしてきた、あの人だ」ということを自動的には覚えてくれません。

リクエストが届くたびに、すべて「はじめまして」の真っ新な状態として扱われてしまいます。

そのため、ログイン成功時にサーバーから「この人はログイン済みですよ」という目印（証明書）をブラウザに渡し、

以降はページを移動するたびに、ブラウザからサーバーへその証明書を提示し続けるという泥臭いキャッチボールを行っています。

この証明書を「どんなデータ構造で実現するか」によって、JWT方式とセッション方式の2つに分かれます。

2. JWT方式とは

JWT（JSON Web Token）方式を一言で表すなら、「必要な情報がすべて書き込まれた、偽造不可能なデジタル身分証明書」です。

ログインが成功すると、サーバーはユーザーのIDや権限（ロール）などのデータを1つのJSONにまとめ、それを秘密鍵で暗号化した文字列（トークン）を発行してブラウザに渡します。

sequenceDiagram
    autonumber
    actor User as ユーザー（ブラウザ）
    participant Server as サーバー（アプリケーション）

    User->>Server: 1. ログイン（ID/パス）
    Note over Server: ユーザー情報をJSON化し、<br>署名を施してJWTを作成
    Server-->>User: 2. JWT（トークン）を返却
    User->>Server: 3. 次のページを開く（＋JWTを添付）
    Note over Server: 秘密鍵を使って<br>JWTの署名が正しいか検証（DBアクセス不要）
    Server-->>User: 4. ページを表示

💡 なぜ「ステートレス」なのか？

JWTの最大の強みは、サーバー側が「誰がログインしているか」の履歴をデータベースに一切保存しなくてよい点にあります。

リクエストと一緒にJWTが送られてきたら、サーバーは手持ちの秘密鍵を使って「このデータは改ざんされていないか？」という暗号パズルを解く（CPUの検証処理を行う）だけで、本人確認が完了します。

わざわざデータベースに SELECT * FROM sessions WHERE ... のようなクエリを投げる必要がありません。

DBへのI/Oコストがゼロになるため、アクセスが大量に集中してもサーバーやデータベースが重くなりにくいのが特徴です。

これが「ステートレス（状態を持たない）」と呼ばれる理由です。

3. セッション方式とは

一方のデータベースセッション方式は、「実体はサーバー（DB）側で管理し、ユーザーにはその引き換え券（鍵）だけを持たせる」という伝統的なスタイルです。

ログインが成功すると、サーバーはデータベースの「セッションテーブル」に、「セッションID：XXX、ユーザー：Aさん、有効期限：〇〇」というレコードを1行インサートします。

そしてブラウザには、そのランダムな文字列（セッションID）だけを返します。

sequenceDiagram
    autonumber
    actor User as ユーザー（ブラウザ）
    participant Server as サーバー（アプリケーション）
    participant DB as データベース（セッションテーブル）

    User->>Server: 1. ログイン（ID/パス）
    Server->>DB: 2. セッション情報を保存（INSERT）
    Server-->>User: 3. セッションID（鍵）だけを返却
    User->>Server: 4. 次のページを開く（＋セッションIDを添付）
    Server->>DB: 5. このIDは有効か、誰のものかを照会（SELECT）
    DB-->>Server: 6. ユーザー情報を返却
    Server-->>User: 7. ページを表示

💡 なぜ「ステートフル」なのか？

ブラウザが持っているのはただの「ランダムな鍵」なので、サーバーはリクエストがあるたびに、

毎回データベースのセッションテーブルを読みに行く（SELECTクエリを発行する）必要があります。

サーバー側に常に最新の状態（ステート）を保持しておく必要があるため、「ステートフル」と呼ばれます。

ページをめくるたびに必ずDBアクセスが1回発生するため、データベースへの負荷（I/Oコスト）はJWTに比べて高くなります。

4. NextAuth（Auth.js）における選択とトレードオフ

Next.jsでNextAuthを採用する場合、この2つのどちらを使うかで実装の難易度が変わります。

NextAuthでは、デフォルトの挙動として「JWT戦略」が採用されています。

そのため、データベースをまだ用意していない開発初期段階であっても、Googleログインなどの認証機能を一瞬で実装して動かすことができます。

個人開発をサクッと始める上では、この手軽さは圧倒的な正義です。

一方で、「データベースセッション戦略」を選ぼうとすると、途端に準備が大変になります。

NeonやSupabaseなどのデータベースとNextAuthを接続するための「Prisma Adapter」や「Drizzle Adapter」といった設定を行い、

データベース側にセッション情報を保存するための専用テーブル（Session や User など）をマイグレーションであらかじめ作成しておかなければなりません。

5. どちらを選ぶべきか

機能の手軽さだけを見ればJWTの圧勝に見えますが、実務でどちらを選ぶべきかの決定打は「ログイン状態を、サーバー側からリアルタイムにコントロール（強制終了）したいか」という一点に尽きます。

JWT方式は、サーバー側に保存の手間がないぶん、シンプルな構成で始められます。

個人開発や小規模なアプリで、まずは動くものを作りたい場合には扱いやすい選択です。

一方で、「このユーザーを強制的にログアウトさせたい」「不正利用が疑われるアカウントのログイン状態を即時に無効化したい」といった、ログイン状態をサーバー側から操作する必要があるプロダクトでは、データベースセッション方式が向いています。

JWTは一度発行してしまうと、有効期限が来るまで内容を後から取り消すことが難しいという特性があるためです。

ここまでのトレードオフを一覧表に整理しました。

観点	JWT方式	データベースセッション方式
構成のシンプルさ	シンプル	やや複雑
データの実体	ブラウザ側（暗号化されたトークン）	サーバー側（DBのテーブル内）
データベースへの保存	不要	必要
毎回の通信コスト	CPUでの暗号検証のみ（高速・DB負荷ゼロ）	毎回セッションDBの参照が発生（SQLコストあり）
導入の難易度	コード数行ですぐ動く（DB不要）	アダプターの設定やテーブル構築が必要
ログイン状態の即時無効化	難しい	しやすい
強制ログアウト	有効期限が切れるまで実質不可能	DBのレコードを消すだけで即時可能
向いているプロダクト	個人開発・小規模アプリ	管理機能が求められるプロダクト

💡 個人開発における現実的な最適解

迷ったら「JWT戦略」で始める：

個人開発や小規模なアプリ、あるいはB2Bの社内ツールなどであれば、まずはNextAuthのデフォルトであるJWT戦略で始めるのが最も打率が高いです。

DBの管理コストや初期設定の手間を限界まで削り、アプリの機能そのものの開発に集中できるからです。
「セキュリティと管理画面」が必要ならセッション戦略：

「管理者が、不正なユーザーをその場で強制ログアウトさせたい」「ユーザーが『他のデバイスからログアウトする』を選べるようにしたい」といった、状態の即時性・コントロールが必要なプロダクトを作る場合は、最初からコストを払ってでもデータベースセッション戦略を選ぶべきです。

JWTは一度発行してブラウザに渡してしまうと、サーバー側から「そのトークンを無効化する」という操作が非常に困難だからです。

まとめ

NextAuthにおけるJWTとセッションの思想の違いについて整理しました。

JWT（ステートレス）： サーバーの負荷を下げ、初期設定も不要にする、個人開発に優しいモダンなアプローチ。
セッション（ステートフル）： 毎回DBを叩くコストはあるものの、いざという時のコントロール権をサーバー側が握り続ける、堅実でセキュアな伝統的アプローチ。

自分が作ろうとしているアプリに「強制ログアウト」のような厳格なセッション管理が必要かどうかを見極めること。

それこそが、NextAuthのconfigファイルを開いたときに、自信を持って strategy: "jwt" か "database" かを選択するための明確な基準になります。