セッションとCookieの仕組みをわかりやすく解説

Cookieはブラウザに置かれる小さなデータ

Cookieは、Webサイトがブラウザに保存させる小さなデータです。ログイン状態を扱う場面では、セッションIDのような識別用の文字列がCookieに入ることがあります。

大事なのは、Cookieはブラウザ側に保存され、同じサイトへアクセスするときに自動で送られるという点です。会員証を財布に入れておき、お店に行くたびに見せるイメージです。

セッションはサーバー側のログイン記録

セッションは、サーバー側で「この人はログイン済み」「このユーザーIDとして扱う」といった状態を覚える仕組みです。ユーザー情報そのものを毎回ブラウザへ持たせるのではなく、サーバー側で管理します。

ブラウザからCookieに入ったセッションIDが送られてくると、サーバーはそのIDに対応するセッションを探します。見つかれば、ログイン済みとして画面を返せます。

ログイン後に会員証を受け取る

ログインに成功すると、サーバーはセッションを作り、そのセッションを見つけるためのIDをブラウザへ渡します。ブラウザはそのIDをCookieとして保存します。

次にマイページなどを開くと、ブラウザはCookieを自動で送ります。サーバーはCookieの中のIDを見て、対応するセッションを探し、「この人はログイン済み」と判断します。

ログアウトは会員証を使えなくすること

ログアウトすると、多くの場合はサーバー側のセッションを削除したり、ブラウザ側のCookieを消したりします。どちらかだけではなく、両方をそろえて扱うことで、次のアクセスでログイン済みと判断されないようにします。

また、一定時間操作がないと自動でログアウトされるサービスがあります。これは、セッションに期限を設けて、古いログイン状態を使い続けられないようにするためです。

Cookieに何でも入れるわけではない

Cookieはブラウザに保存されるため、ユーザー名や権限情報などをそのまま詰め込む設計には注意が必要です。特にログイン状態に関わる情報は、サーバー側のセッションで管理し、Cookieには識別用のIDだけを入れる形がよく使われます。

実際のサービスでは、Cookieに HttpOnly や Secure などの設定を付け、安全に扱えるようにします。細かな実装はサービスごとに異なりますが、「Cookieは持ち歩く札、セッションはサーバー側の記録」と覚えると入口として十分です。

ここまでのまとめ

Cookieはブラウザに保存される小さなデータで、セッションはサーバー側でログイン状態を覚える仕組みです。ログイン後は、Cookieに入ったIDを手がかりに、サーバー上のセッションを探します。

Cookieは「会員証の番号」、セッションは「お店側の会員情報」。2つを組み合わせることで、ログイン状態を保てます。