✅ はじめに

Webアプリケーションにおいて「ログイン状態を維持する」「ユーザーを識別する」といった機能は、すべてセッション管理に支えられています。

本記事では、

HTTP通信とステートレス
Cookieの基礎から詳細仕様
セッション管理の広義の定義
セッションベース vs トークンベースのセッション管理

これらをまとめて丁寧に解説します。

✅ 1. HTTP通信はステートレス

● ステートレスとは？

HTTPは「ステートレス（stateless）」なプロトコルです。
つまり、1回のリクエストとレスポンスが完結しており、前後の状態を保持しないという特徴があります。

「このリクエストは誰から来たのか？」をサーバーは覚えていません。
毎回のリクエストが“初対面”のような扱いになります。

🙋 たとえば…

ログイン後に別ページを開いたとしても、サーバーは「この人がログイン済み」という情報を持っていないため、
ログイン状態を維持できません。

● ではステートフルとは？

一方で、「ステートフル（stateful）」な通信とは、リクエストとレスポンスの間で状態を保持する仕組みです。

つまり、「このリクエストは前にも来たあの人からだな」とサーバーが前回のやり取りを覚えている状態です。

サーバーは過去の接続情報やユーザーの状態を保持し、それをもとに次の処理を行います。

たとえばログイン後のユーザーに対して、「こんにちは、◯◯さん」と名前を出すような振る舞いは、サーバーが状態（セッション情報など）を記憶していることで可能になります。

● なぜHTTPはステートレスに設計されたのか？

HTTPは元々「文書を取得する」ための仕組みとして設計されました。
たとえば静的なHTMLや画像などをやり取りするだけなら、リクエストごとに完結している方がシンプルで効率的です。

ステートフルにすると、サーバー側で接続状態やユーザー情報を常に保持する必要があり、負荷が高まる・拡張性が低下するなどのデメリットもあるため、意図的に「ステートレス」に設計されているのです。

● ステートレスの限界とセッション管理の必要性

一方で、ユーザーごとの状態を保持したいケース（ログイン状態の維持、買い物かごの中身など）は多く存在します。

これを実現するために登場するのが「Cookie」や「セッション」、「トークン」などの仕組みです。

HTTP自体はステートレスですが、アプリケーションレベルで状態を補完する手段を使って、ユーザーとの継続的なやり取りを実現しているわけです。

🍪 2. Cookieとは何か？

Cookieは、Webブラウザに保存される小さなテキスト情報です。
主にサーバーとクライアント間でユーザーを識別するために使われます。

項目	内容
保存場所	ブラウザ内の Cookieストア
1件あたりのサイズ制限	約4KBまで（4096バイト前後）
ドメインごとの上限	おおよそ20〜50個（ブラウザ依存）
全体の上限	約300個まで（Chromeなど）
自動送信	同一ドメインへのリクエストに自動添付される

🔁 3. セッション管理とは？

セッション管理とは「ユーザーの一連の操作を同一人物として扱う仕組みです。
つまり、「今アクセスしている人が誰か」をサーバーが識別・維持することです。

🧠 4. セッション管理の2つの方式

セッション管理には、主に以下の2つの方式があります。

🅰️ セッションベース（サーバーが覚える方式）

■ 例え話：

記憶喪失の店員に「これ、私の会員カードです（セッションID）」と見せると、
店員はカード番号から顧客情報（名前・購入履歴など）を裏で確認してサービスを提供してくれる。

■ 特徴：

クライアントには セッションIDだけ を渡す（中身は持たない）
サーバーがそのIDに紐づいたユーザー情報を保持
サーバーが状態を持つ → ステートフル

■ メリット：

高いセキュリティ（情報はサーバー側にある）
セッションを削除すれば即ログアウト可能

■ デメリット：

スケールしにくい（状態を持つので分散構成が複雑）
再起動などでセッションが失われるリスク（DB保存で対策可）

🅱️ トークンベース（クライアントが覚える方式）

■ 例え話：

記憶喪失の店員に「この身分証明書（JWT）を見てください」と見せると、
店員はその場で情報（名前、権限、有効期限など）を確認し、サービスを提供してくれる。

■ 特徴：

クライアントが**認証情報を含むトークン（JWT）**を保持
サーバーは署名を検証して正当性を確認
サーバーは状態を持たない → ステートレス

■ メリット：

サーバーにセッションストアが不要
スケーラビリティに優れ、マイクロサービスやAPIと相性が良い

■ デメリット：

トークンが漏れると止めにくい
トークンの中身はBase64で誰でも見られる（※暗号化ではない）

🍪 5.Cookieは「箱」——中に何を入れるかで方式が変わる

Cookieはあくまで「クライアントに保存される小さな 箱（入れ物）」です。
この箱の中に 何を入れるか によって、認証の仕組みが変わります。

🅰️ セッションベース認証

Cookie の中には セッションID（session_id） を入れます。
サーバーはこの ID を使って、セッションストア上の
{ session_id: user_id } という対応表からユーザー情報を取得します。
サーバーがユーザー情報を保持するため、stateful（状態あり） な方式です。
セッションIDの中にはユーザーIDを直接含みません。
（セッションIDはただの識別子であり、意味のある情報を持たない）

🅱️ トークンベース認証（JWT）

Cookie の中には JWT（署名付きトークン） を入れます。
JWT の中身（Payload）には、user_id などの ユーザー情報が直接含まれます。
サーバーは署名を検証するだけで正当性を確認でき、セッションストアを持つ必要がありません。
したがって、こちらは stateless（状態なし） な方式です。

💡 比較

比較項目	セッションベース	トークンベース（JWT）
Cookieの中身	セッションID（ユーザーIDは含まない）	JWT（署名付きでユーザーIDを含む）
状態管理	サーバーが保持（stateful）	クライアントが保持（stateless）
サーバーの役割	IDからユーザーを照合	署名を検証して中身を信頼
セキュリティ	IDを盗まれると成りすまし	トークンを盗まれると成りすまし（改ざんは不可）

このように、Cookieそのものは単なる「入れ物」に過ぎません。
その中に セッションIDを入れるか、JWTを入れるか によって、
セッションベース認証とトークンベース認証の動作原理が変わります。

🔐 6. セキュリティ比較

比較項目	セッションベース	トークンベース（JWT）
状態の保持	サーバー側	クライアント側
情報の保存	IDのみ（サーバーに実体）	ユーザー情報を含むトークン
XSS対策	`HttpOnly` Cookieで対策可能	`localStorage`はXSSに弱い。Cookie推奨
CSRF対策	`SameSite`, トークン併用	Cookie保存時は同様に必要
漏洩時の対応	セッション削除で即無効化可	ブラックリスト、短期有効期限で対応

⚖️ 7. どちらを選ぶべき？

シーン	推奨方式	理由
管理画面・社内ツール	セッションベース	セキュリティ重視、構成がシンプル
SPA（Reactなど）+ API構成	トークンベース	ステートレスAPIと相性◎
モバイルアプリ	トークンベース	サーバーレスに適応しやすい
分散構成 / マイクロサービス	トークンベース	サーバー間でセッション共有不要

📝 まとめ

技術	状態管理者	保存場所	適性
Cookie	クライアント	ブラウザ	状態を運ぶ入れ物
セッションベース	サーバー	セッションIDをCookie	安全・即時制御しやすい
トークンベース（JWT）	クライアント	Cookie or localStorage	スケーラブル、APIと相性良し

📌 おわりに

HTTPは本質的に「記憶喪失の店員」のように、毎回“誰かわからない”設計です。
だからこそ、Cookieでメモを残し、セッションやトークンで文脈を再構築する必要があります。

技術選定では、安全性、拡張性、アプリの規模や性質に応じて、
「どこに状態を持つか」を適切に設計することが、セッション管理の本質です。