✅ はじめに
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でメモを残し、セッションやトークンで文脈を再構築する必要があります。
技術選定では、安全性、拡張性、アプリの規模や性質に応じて、
「どこに状態を持つか」を適切に設計することが、セッション管理の本質です。