Cookieとセッションの違い：Webの状態管理を理解しよう

はじめに

Webは本来「ステートレス（状態を持たない）」な仕組みです。
しかし、ユーザーのログイン状態や買い物カゴの中身など、状態を保持する必要がある場面は数多く存在します。
そこで重要になるのが Cookie と セッション という2つの仕組みです。本記事ではそれぞれの役割と違い、使い分けのポイントを解説します。

基本情報・概要

Cookie：クライアント（ブラウザ）側に保存される小さなデータ。次回以降のリクエストに自動送信される。
セッション（Session）：サーバー側で管理される一時的な状態情報。通常はCookieに格納されたID（セッションID）と紐づく。

両者は連携して使われることも多く、それぞれにメリットと制約があります。

比較・分類・特徴の表形式まとめ

項目	Cookie	セッション
保存場所	クライアント（ブラウザ）	サーバー（メモリ、DB、Redisなど）
容量制限	約4KBまで	制限なし（サーバー側の実装依存）
セキュリティ	改ざん・盗聴リスクあり（Secure/HttpOnly属性で対策）	クライアントにはIDだけ送信することで安全性を確保
有効期限	明示的に設定可能（期限切れ後は破棄）	セッションタイムアウトで自動消滅
用途	自動ログイン、言語設定、トラッキングなど	ログイン状態、カート情報、ユーザー状態保持など

深掘り解説

Cookieの基本構文（HTTPヘッダー）：

  Set-Cookie: token=abc123; Path=/; HttpOnly; Secure; Max-Age=3600

```
HttpOnly
```
：JSからのアクセス禁止（XSS対策）
```
Secure
```
：HTTPS通信時のみ送信（盗聴対策）
```
SameSite
```
：クロスサイト制御（CSRF対策）

セッションの流れ（典型的な例）：

  1. ログイン成功 → サーバーでセッションIDを発行（UUIDなど）
  2. クライアントに `Set-Cookie: session_id=xxxx` を送信
  3. クライアントが以降のリクエストでCookieを送信
  4. サーバーは `session_id` に紐づいた情報を参照して状態を維持

Node.js + Expressの例：

  const session = require("express-session");

  app.use(session({
    secret: "your-secret",
    resave: false,
    saveUninitialized: true,
    cookie: { secure: true, httpOnly: true }
  }));

応用・発展的な使い方

セッションストアの選択肢：
- メモリ（小規模・開発向け）
- Redis（スケーラブル・マルチノード対応）
- DB（ログイン履歴と統合も可）
JWTとの比較と組み合わせ：
- JWTはセッションレス方式。Cookieに格納して使うハイブリッドも可能
セキュリティ強化のための運用：
- セッション固定攻撃（Session Fixation）の防止
- ログアウト時のセッション削除
- IP/UAチェックによる不正検知

よくある誤解と注意点

Cookieだけで認証を管理すると「改ざん・盗聴」リスクが高まる：署名付きトークン or セッションID + サーバー管理が推奨
セッションはサーバーのリソースを消費するため、スケーラビリティを考慮してRedis等を使う
Cookieにパスワードや個人情報は絶対に保存しない

まとめ

Cookieとセッションは、Webにおける状態管理の両輪です。

Cookieはクライアント側の記憶
セッションはサーバー側の状態管理

この違いを正しく理解し、セキュアに組み合わせて使うことで、安全で快適なユーザー体験を実現できます。
開発フェーズやサービスの特性に応じて、最適な運用戦略を設計しましょう。