Webサービスを作ったり、ログイン機能を扱ったりすると必ず出てくる言葉があります。それが Cookie と セッション です。
プログラミングを勉強し始めた人の多くが、ここで一度つまずきます。
「Cookieとセッションって何が違うの？」 「ログイン状態ってどうやって保持されているの？」 「なぜ両方出てくるの？」
こうした疑問を持ったことがある人も多いはずです。
実はこの2つ、仕組みとしてはそこまで難しくありません。 ただし「役割」と「関係性」を整理して理解しないと、ずっとモヤモヤしたままになってしまいます。
この記事では、Cookieとセッションの関係をメインで解説していきます。 Webアプリのログイン処理やユーザー管理の仕組みの理解がしやすくなると思います。
Cookieとセッションの前に知っておきたいWebの基本
まず最初に、Webの仕組みを1つだけ押さえておく必要があります。
それは HTTPは基本的に「記憶しない通信」である ということです。
これを「ステートレス」と呼びます。
例えばブラウザで次のような操作をしたとします。
- ログインする
- マイページを見る
- 商品ページを見る
人間からすると、これは「同じ人が操作している」と当たり前に感じます。
しかしWebサーバーから見ると違います。
サーバーは次のように見ています。
- リクエスト1（ログイン）
- リクエスト2（ページ表示）
- リクエスト3（商品ページ）
実は 全部バラバラの通信 なのです。
サーバーは基本的に
「この通信は誰から来たのか」
を覚えていません。
つまり、何もしなければこうなります。
ログイン → ページ移動 → ログイン状態が消える
これではWebサービスとして成立しません。
そこで登場するのが Cookieとセッション です。
Cookieとは何か
まずCookieから説明します。
Cookieとは一言でいうと
ブラウザに保存される小さなデータ
です。
サーバーはユーザーのブラウザに対して
「このデータを保存しておいて」
とお願いできます。
ブラウザはそれを保存し、次のリクエストのときに自動でサーバーへ送ります。
イメージとしてはこんな感じです。
サーバー 「このメモを持っていてください」
ブラウザ 「分かりました」
次のアクセス時
ブラウザ 「さっきのメモ持ってきました」
この メモの役割 がCookieです。
Cookieに保存できる情報の例は次のようなものです。
- ログイン識別子
- ユーザー設定
- サイトの表示設定
- ショッピングカート情報
ただしCookieには重要な特徴があります。
それは
ユーザー側（ブラウザ）に保存される
という点です。
つまり、ユーザーが消そうと思えば消せます。
また、保存できるサイズもそれほど大きくありません。
そのため、重要なデータをそのままCookieに保存するのは危険です。
ここで次に登場するのがセッションです。
セッションとは何か
セッションとは
サーバー側に保存されるユーザー情報
です。
Cookieがブラウザに保存されるのに対して、セッションはサーバーに保存されます。
つまりこうなります。
- Cookie→ブラウザに保存
- セッション →サーバーに保存
ではなぜセッションが必要なのでしょうか。
それは 安全にユーザー情報を管理するため です。
例えばログイン機能を考えてみます。
もしCookieに次のようなデータを入れていたらどうなるでしょう。
ユーザーID 権限 ログイン状態
これは危険です。
なぜならCookieはユーザー側にあるため、改ざんできる可能性があるからです。
そこで実際のWebアプリでは次のような仕組みが使われます。
- セッションをサーバーに保存
- セッションIDをCookieに保存
つまり
本体はサーバー、鍵だけブラウザ
という構造です。
Cookieとセッションの関係をイメージする
ここが一番大事なポイントです。
Cookieとセッションの関係は、よく次のような例えで説明されます。
ロッカーと鍵
この例がとても分かりやすいです。
まずサーバーにロッカーがあります。
そこにユーザー情報を保存します。
このロッカーが セッション です。
次に、そのロッカーの鍵を渡します。
この鍵が セッションID（Cookieに保存） です。
つまりこういう仕組みです。
ユーザーがログインする
サーバー 「ロッカー作りました」
セッション ユーザー情報を保存
サーバー 「この鍵を持ってください」
Cookie セッションID
次のアクセス
ブラウザ 「この鍵です」
サーバー 「この鍵のロッカーですね」
セッション読み込み
ログイン状態維持
これがCookieとセッションの関係です。
整理するとこうなります。
Cookie セッションIDを保存する
セッション ユーザー情報を保存する
つまり
Cookieはセッションを探すための目印
という役割です。
ログイン処理の流れを簡単に見る
実際のログイン処理を簡単に見てみましょう。
1 ログイン
ユーザーがログインします。
サーバーは次の処理をします。
- セッション作成
- ユーザー情報保存
- セッションID発行
そして
セッションIDをCookieとしてブラウザに保存させます。
2 ページ移動
ブラウザはページ移動のたびに
Cookieを自動送信します。
Cookie: session_id=abc1233 サーバー側処理
サーバーは次のように処理します。
- 1 セッションID取得
- 2 セッション検索
- 3 ユーザー情報取得
その結果
ログイン状態を維持できます。
これがWebサービスの基本構造です。
なぜCookieだけではダメなのか
ここでよくある疑問があります。
Cookieに全部入れればいいのでは？
実はそれには問題があります。
理由は主に3つあります。
セキュリティ
Cookieはユーザー側にあります。
そのため改ざんされる可能性があります。
データ容量
Cookieはサイズ制限があります。
一般的には 約4KB程度 です。
管理の問題
ユーザー情報をCookieで持つと、更新管理が難しくなります。
そのため
重要データはサーバーに置く
というのが基本設計になります。
実務で知っておくと役立つポイント
ここからは、実務で役立つポイントを紹介します。
セッションは永遠ではない
セッションには 有効期限 があります。
これはセキュリティのためです。
例えば
- 30分
- 1時間
- 24時間
などです。
期限が切れるとログインが解除されます。
Cookieにも期限がある
Cookieも保存期間を設定できます。
例えば
- セッションCookie（ブラウザ終了で消える）
- 長期Cookie（数日〜数ヶ月）
ログイン状態を保持する場合は長期Cookieが使われます。
セッションIDは絶対に推測できてはいけない
セッションIDは
ランダムで長い文字列
になっています。
例
xc3batrw3gnzi9mzもし推測できてしまうと、他人のセッションにアクセスできてしまいます。
そのため
- 暗号学的ランダム生成
- 十分な長さ
が必要です。
HTTPSは必須
Cookieは通信で送られます。
もしHTTPのままだと、盗み見される可能性があります。
そのため
ログイン機能は必ずHTTPS
が基本です。
一問一答で理解を整理
Cookieとセッションで初心者がよく疑問に思うポイントを整理します。
- Cookieは危険？
-
危険というより 使い方次第 です。
重要なデータを直接保存しないことが重要です。
- セッションはどこに保存される？
-
多くの場合は次のどれかです。
- メモリ
- ファイル
- Redis
- データベース
大規模サービスではRedisなどがよく使われます。
- セッションは複数作られる？
-
はい。 ユーザーごとに1つずつ作られます。
まとめ
Cookieとセッションは、Webアプリを理解するうえで非常に重要な仕組みです。
最初は難しく感じますが、ポイントを整理するとシンプルです。
Cookie
ブラウザに保存されるデータ
セッション
サーバーに保存されるユーザー情報
そして両者の関係は次の通りです。
Cookieはセッションを見つけるための鍵
セッションは
ユーザー情報を保存するロッカー
というイメージで覚えると理解しやすくなります。
この仕組みが分かると、次のようなWeb機能の理解も深まってきますよ。
- ログイン機能
- 認証システム
- ショッピングカート
- ユーザー管理
Web開発を学ぶなら、Cookieとセッションは必ず通る重要ポイントです。
難しい概念に感じるかもしれませんが、「ロッカーと鍵」のイメージで考えると一気に理解しやすくなります。 まずはこのイメージを頭の中に作るところから始めてみてください。
