【比較】CookieとSessionの違い

概要

Webアプリケーションにおいて、HTTPプロトコルの「ステートレス（状態を保持しない）」という性質を補い、ユーザーの状態を管理するために使われるのが「Cookie」と「Session」です。この2つは密接に関連して動作しますが、データをどこに保存するかという点で決定的な違いがあります。

一言で言うと、Cookieは「ブラウザに貼る小さな名札」 であり、Sessionは「サーバー側で管理する、その名札に対応した顧客台帳」 のような関係です。Cookie はクライアント側の保存・伝送のしくみ、Session はサーバー側で保持する状態であり、両者は対立概念ではなく役割分担です。

詳細比較

項目	Cookie (クッキー)	Session (セッション)
データ保存場所	クライアント側（Webブラウザ）	サーバー側
保存できるデータ	文字列のみ。比較的小容量（1つあたり約4KB）	サーバーのリソースが許す限り、多様なデータを保存可能
セキュリティ	比較的低い（改ざんや盗聴のリスク）	比較的高い（実データはサーバー上にある）
パフォーマンス	サーバー負荷は低いが、リクエスト毎に送信されるため通信量が増える	サーバーに負荷がかかる
有効期限	任意に設定可能。ブラウザを閉じても保持できる	基本的にブラウザを閉じるまで。任意に設定も可能
役割	ユーザーを識別するためのIDや、少量の情報を保持する	ユーザーごとの詳細な状態（ログイン情報、カートの中身など）を管理する

1. Cookie (クッキー)

Cookieは、Webサーバーからの指示（Set-Cookie ヘッダ）で、WebブラウザがユーザーのPC内に保存する小さなデータです。ユーザーが同じサイトを再訪した際、ブラウザは保存しているCookieを Cookie ヘッダでサーバーに送信します。サーバーはこれを受け取ることで、以前アクセスしたユーザーであることを識別できます。

主な特徴と用途

• クライアント側保存: データはユーザーのブラウザ（PC）に保存されます。
• データ量の制限: RFC 6265 では、ユーザーエージェントは1つの Cookie あたり少なくとも 4096 バイト（名前＋値＋属性の合計）をサポートすべきとされ、実装上の上限は概ね約4KBです。ドメインあたりの数にも制限があります。
• セキュリティリスク: テキストデータとして保存されるため、中身を盗み見られたり、改ざんされたりするリスクがあります。そのため、パスワードなどの機密情報を直接保存すべきではありません。
• 主な用途:
  • Session IDの保持（後述）
  • ログイン状態の維持（「次回から自動的にログインする」機能）
  • ユーザー設定の保存（言語設定、テーマ設定など）
  • 広告配信のためのトラッキング

2. Session (セッション)

Sessionは、ユーザーごとの情報をサーバー側で一時的に保持する仕組みです。ユーザーがサイトにアクセスすると、サーバーは各ユーザーを識別するためのユニークな「Session ID」を発行します。このIDだけをCookieに保存してブラウザに送り返し、以降の通信ではそのIDを使ってサーバー上のデータとユーザーを結びつけます。

主な特徴と用途

• サーバー側保存: ログイン情報やカートの中身といった実データは、サーバーのメモリやデータベースに保存されるため、Cookieより安全です。
• データ量の柔軟性: サーバーのリソースに依存するため、Cookieのような厳しい容量制限はありません。
• セキュリティ: ブラウザとサーバー間でやり取りされるのはSession IDのみなので、機密情報が漏洩するリスクを低減できます。
• 主な用途:
  • ログイン状態の管理
  • ECサイトのショッピングカート機能
  • 複数ページにまたがるフォーム入力内容の一時保存

連携の仕組み（一般的な流れ）

多くのWebアプリケーションでは、CookieとSessionは以下のように連携して動作します。

1. 初回アクセス:

   • ユーザーがWebサイトに初めてアクセスする。
   • サーバーがユニークなSession IDを生成し、サーバー側でセッション情報を保存する領域を作成する。
   • サーバーは、生成したSession IDをCookie（Set-Cookie）に含めてクライアント（ブラウザ）に送る。

2. 2回目以降のアクセス:

   • ブラウザは、リクエストの際にSession IDが書き込まれたCookieを自動的にサーバーへ送信する。
   • サーバーは受け取ったSession IDを元に、サーバー上に保存されているセッション情報を探し出す。
   • サーバーはユーザーを特定し、そのユーザーの状態（ログインしているか、カートに何が入っているか等）に応じたレスポンスを返す。

3. セッションの終了:

   • ユーザーがログアウトするか、ブラウザを閉じると、サーバー上のセッションデータが破棄され、セッションが終了する（設定による）。

このように、Sessionの実態はサーバーにあり、CookieはそのSessionを呼び出すための「鍵」や「合鍵」の役割を果たしているのです。

よくある誤解

• 「Session ＝ Cookie」は誤り。 Cookie は「クライアント側にデータを保存し、リクエストごとにサーバーへ送る伝送・保存のしくみ」、Session は「サーバー側に保持されるユーザーごとの状態」です。RFC 6265 でも、Cookie はステートレスな HTTP 上で状態を保つための仕組みであり、Session ID はその Cookie に載せて運ぶ値の一例にすぎません。Cookie は Session 専用ではなく、Session も Cookie 以外（URL 書き換え等）で ID を運べます。

• 「Cookie はサーバーに保存される」は誤り。 Cookie はクライアント（ブラウザ）に保存されます。サーバーは Set-Cookie で発行を指示し Cookie ヘッダで受け取るだけで、保存場所はあくまでユーザー側です。サーバー側に実データを置くのは Session の役割です。

• 「Cookie に上限がないので何でも入れてよい」は誤り。 RFC 6265 はユーザーエージェントに1 Cookie あたり最低 4096 バイト、ドメインあたり最低 50 個程度のサポートを求めるだけで、これは下限の保証です。さらに Cookie は同一ドメインへのリクエストごとに毎回送信されるため、サイズを増やすと全リクエストの通信量が増えます。

実務での選び分け

• 少量の識別子・設定を端末に保持したい → Cookie。Session ID、表示言語、テーマなど。機密情報は入れず、必要に応じて Secure / HttpOnly / SameSite を付ける。
• ログイン状態やカートなど、漏らせない実データを保持したい → サーバー側 Session（メモリ／DB／Redis 等）に置き、Cookie には ID のみを載せる。
• 大きめのデータをクライアントに保持したい（フォーム下書き等） → Cookie ではなく Web Storage API（localStorage / sessionStorage）や IndexedDB を使う。Cookie は毎リクエスト送信されるため不向き。
• API トークンを端末に置きたい → 用途に応じて HttpOnly Cookie（XSS でのトークン窃取を防ぐ）か、ストレージ＋ヘッダ送信かを設計上トレードオフで選ぶ。

ひとことまとめ

Cookie は「クライアント側に保存され毎リクエスト送られる小さなデータ」、Session は「サーバー側に保持されるユーザーごとの状態」であり、多くの場合 Session ID を Cookie に載せて両者を結びつけますが、Cookie ＝ Session ではありません。

出典・参考

• Using HTTP cookies - MDN Web Docs — Cookie の保存場所（クライアント側）、Set-Cookie/Cookie ヘッダ、Session ID によるセッション管理、毎リクエスト送信の性質
• RFC 6265 - HTTP State Management Mechanism — Cookie の標準仕様。1 Cookie あたり最低 4096 バイト等の下限、ステートレス HTTP 上でのセッション維持の定義