クッキーは「ブラウザに保存される預かり札」、セッションは「サーバー側で管理される預けた荷物本体」です。ログイン状態などの実データはサーバー側のセッションに置き、それを呼び出すための番号（セッションID）だけをクッキーとしてブラウザに持たせる――これが、Webサイトでログインが続く仕組みの基本形です。
ログインの仕組みを調べると必ず一緒に出てくるので、同じもののように感じている方も多いのではないでしょうか。編集部で仕組みを調べ直してみると、混乱の原因は「情報をどこに置くか」の違いに加えて、「セッションクッキー」という紛らわしい用語にあることも見えてきました。レストランやホテルの「クローク（荷物預かり）」のたとえを使って整理します。
執筆：資格スキルアップ編集部／最終更新：2026年10月26日
結論：セッションとクッキーは何が違う？
違いは「情報をどこに置くか」です。クッキーは利用者のブラウザに、セッションはWebサイトのサーバーに保存されます。
- クッキー（Cookie）：ブラウザに保存される小さなデータ。ログイン用途では多くの場合「識別用のID」だけを持つ
- セッション（Session）：サーバー側に保存される、そのユーザーに関する実際の情報（ログイン状態やカートの中身など）
- クッキーは「預かり札」、セッションは「預けた荷物本体」の関係になっている
この区別が大切なのは、「この情報は利用者の手元にあるのか、サーバーにあるのか」で、盗まれたときのリスクも、消えるタイミングもまったく変わるからです。
そもそも、なぜセッションやクッキーが必要なの？
Webの通信に使われるHTTPは、もともと「前のやり取りを覚えていない（ステートレスな）」仕組みだからです。
MDN Web Docs（Mozillaが運営する開発者向けドキュメント）でも、HTTPプロトコルは既定ではステートレスであり、Cookieによって状態を記憶できるようになると説明されています。何もしなければ、サーバーにとってはページを移動するたびに「初めて来た人」になってしまいます。
たとえるなら、毎回ちがう店員が対応するお店で「さっきコートを預けた者です」と言っても通じないようなもの。そこで必要になるのが「番号札」と「店の奥の棚」という2つの仕組みです。
クッキーとは？手元に残る「預かり札」のようなもの
クッキーとは、Webサイトを訪れたときにブラウザに保存される小さなテキストデータで、次に同じサイトにアクセスするとブラウザが自動でサーバーへ送り返します。
クロークでコートを預けると、店員から番号札を渡されます。番号札には、コートの色も素材も書かれていません。書かれているのは番号だけです。
- 番号札（クッキー）は利用者の手元（ブラウザ）に残る
- 番号札を見ても、預けた荷物の中身はわからない
- 荷物を受け取るときは、この番号札を店員に見せる
ログイン用途のクッキーには、多くの場合「セッションID」と呼ばれる識別用の文字列だけが入っています。名前やカートの中身といった実データを入れないのは、クッキーが利用者のブラウザ側にあり、設定画面から中身を見たり書き換えたりできてしまうためです。手元に置くのは「なくしても中身が分からない札」だけ、という設計になっています。
セッションとは？クロークの奥で管理される「荷物本体」
セッションとは、サーバー側で管理される、あるユーザーに関する一時的な情報のまとまりです。ログイン中かどうか、カートに何を入れたかといった情報がここに保存されます。
クロークのたとえで言えば、セッションは「店の奥の棚に置かれた、あなたのコートそのもの」です。
- コート本体（セッション情報）は店の奥（サーバー）で管理されている
- 利用者は番号札（クッキー）を持っているだけで、コートを持ち歩いているわけではない
- 番号が一致して初めて、正しいコートが取り出される
ユーザーがログインすると、サーバーに「このユーザーはログイン済み」という情報を持つセッションが作られ、それを識別する番号（セッションID）だけがクッキーとしてブラウザに渡されます。実データがサーバー側にあるため、サーバーがセッションを破棄すれば、番号札を持っていても中身は取り出せません。これが「一定時間操作しないと自動でログアウトされる」仕組みの正体です。
セッションとクッキーの違いを表で比べると？
違いを一覧にすると、次のとおりです。
| 項目 | クッキー（Cookie） | セッション（Session） |
|---|---|---|
| 保存場所 | ブラウザ（クライアント側） | サーバー側（メモリ・データベースなど） |
| 主な中身 | セッションIDなどの識別情報 | ログイン状態・カートの中身などの実データ |
| 有効期限の管理 | クッキーの属性（Expires／Max-Age）で設定 | サーバー側の設定（タイムアウトなど）で管理 |
| 利用者から見えるか | ブラウザの開発者ツールなどで確認できる | 直接は見えない |
| 消える主なタイミング | 期限切れ・利用者による削除・ブラウザ終了（セッションクッキーの場合） | タイムアウト・ログアウト・サーバー側の破棄 |
| 主なリスク | 盗まれると「なりすまし」に悪用されるおそれ | 利用者が増えるほどサーバーの資源を消費する |
表で押さえてほしいのは「消える主なタイミング」の行です。クッキーを消すと番号札がなくなり、セッションが消えると荷物本体がなくなる。どちらが消えてもログイン状態は終わりますが、原因の場所が違います。ログインがすぐ切れるトラブルを調べるとき、この切り分けがそのまま役に立ちます。
「セッションクッキー」は「セッション」と同じもの？
結論から言うと、別物です。名前が似ているせいで、セッションとクッキーの違いを分かりにくくしている一番の原因だと編集部は考えています。
MDN Web Docsによると、クッキーには2種類あります。
- セッションクッキー：有効期限（Expires・Max-Age属性）を指定していないクッキー。現在のセッションが終わると削除される
- 永続的クッキー：Expires属性で指定した日時、またはMax-Age属性で指定した期間が過ぎると削除されるクッキー
ここでの「セッション」は、サーバー側のセッション情報ではなく「ブラウザを使っている一続きの時間」という意味です。つまり「セッションクッキー」は「ブラウザを閉じると消えるタイプのクッキー」のことで、サーバーのセッションそのものではありません。
さらに、MDNは「ブラウザによっては再起動時にセッションを復元することがあり、セッションクッキーがいつまでも有効な状態になる問題が起こりうる」とも注意しています。「ブラウザを閉じれば必ずログアウトされる」とは限らない、ということ。共用PCで使ったあとは、ブラウザを閉じるだけでなくログアウトボタンを押すのが確実です。
セッションIDを守るクッキーの設定にはどんなものがある？
セッションIDが第三者に盗まれると、その番号を使って本人になりすましてログインされる「セッションハイジャック」のリスクがあります。そのため、セッションIDを入れるクッキーには、安全に扱うための属性を付けるのが基本です。
| 属性 | 何をするか（MDN Web Docsの説明をもとに編集部で要約） | 防ぎたいこと |
|---|---|---|
| Secure | HTTPSの暗号化された通信のときだけクッキーを送る | 通信途中での盗み見 |
| HttpOnly | JavaScriptの document.cookie から読み取れなくする | 不正なスクリプトによる持ち出し |
| SameSite | 他のサイトからのリクエストにクッキーを付けるかを Strict・Lax・None で指定する（None の場合は Secure も必須） | 他サイト経由での意図しない送信 |
| Expires／Max-Age | クッキーの有効期限を指定する（未指定ならセッションクッキー） | 必要以上に長く残ること |
MDNでは、SameSite属性を指定しない場合は既定で Lax として扱われると説明されています（実際の挙動はブラウザによって異なる場合があります）。
あわせて、OWASP（Webアプリケーションの安全性向上に取り組む国際的なコミュニティ）のSession Management Cheat Sheetでは、セッションIDを推測されにくい形式にすること、ログイン後にセッションIDを再発行することなども推奨されています。
クロークで言えば、番号札を「店内でしか出せない」「ポケットから勝手に抜き取れない」「他の店では使えない」ようにする工夫です。番号札が単なる番号である以上、札そのものの扱いを厳しくするしかない。編集部としては、「識別情報だけを手元に持たせ、その識別情報を徹底的に守る」という発想が、セキュリティ設計全般に応用できる考え方だと感じています。HTTPSについてはHTTPとHTTPSの違いを解説した記事で詳しく整理しています。
ログインからページ移動まで、2つはどう連携している？
ログイン時にサーバーがセッションを作り、そのIDをクッキーでブラウザに渡し、以降はブラウザがIDを送り返すたびにサーバーが照合する、という流れです。
ECサイトにログインしてカートに商品を入れる場面で見てみましょう。
- ユーザーがIDとパスワードを入力してログインする
- サーバーはログインを確認し、「ログイン済み」という情報を持つセッションを作成する
- サーバーは、そのセッションを識別する番号（セッションID）を発行し、
Set-Cookieヘッダーでブラウザに送る - ブラウザはクッキーを保存し、以降のページ移動のたびに自動でサーバーへ送り返す
- サーバーは受け取ったセッションIDから対応するセッション情報を探し、ログイン状態やカートの中身を照合する
- 一致すれば、ログイン済みのユーザーとしてページが表示される
クッキーが「番号を運ぶ役割」、セッションが「実際の情報を持つ役割」を分担しているからこそ、ページを移動してもログイン状態が続きます。実際にブラウザの開発者ツール（Chromeなら「アプリケーション」タブの「Cookie」）を開くと、ログイン中のサイトのクッキーと、その名前・値・有効期限・HttpOnlyなどの属性を確認できます。教科書の用語が自分のブラウザの中に実在すると分かると、理解は一段深くなります。
まとめ：番号札は手元に、荷物本体は店の奥に
- クッキー＝ブラウザに保存される「番号札」。ログイン用途ではセッションIDだけを持つことが多い
- セッション＝サーバー側で管理される「荷物本体」。ログイン状態などの実データを持つ
- セッションクッキー＝ブラウザを閉じると消えるタイプのクッキーで、サーバーのセッションとは別物
セッションとクッキーの違いは、ITパスポートや基本情報技術者試験のセキュリティ分野、Webアプリの開発、日々のブラウザ操作のどれにもつながる知識です。気になった方は、まず今使っているブラウザの開発者ツールで、ログイン中のサイトのクッキーを一つ開いてみてください。属性の意味が分かる自分に、きっと気づくはずです。
▶ 次に読みたい関連記事：クッキーとローカルストレージの違い（ブラウザ側の保存方法の違い）／認証と認可の違い（ログインの仕組みそのもの）
よくある質問
Q. クッキーを削除すると、ログイン状態はどうなりますか？
A. 多くの場合、ログアウトした状態と同じになります。クッキーに保存されていたセッションIDが失われるため、サーバー側にセッション情報が残っていても、それを呼び出す番号札がない状態になり、再ログインが必要になります。
Q. セッションには有効期限がありますか？
A. あります。多くのWebシステムでは、一定時間操作がないとサーバー側でセッションを自動的に破棄する「タイムアウト」の仕組みが使われています。オンラインバンキングなどで一定時間操作しないと自動ログアウトされるのは、この仕組みによるものです。
Q. 「セッションクッキー」と「セッション」は同じものですか？
A. 別物です。セッションクッキーは、有効期限（Expires・Max-Age属性）を指定していないクッキーのことで、ブラウザのセッションが終わると削除されます。サーバー側でログイン状態などを管理する「セッション」とは意味が異なります。
Q. ブラウザを閉じれば必ずログアウトされますか？
A. 必ずではありません。MDN Web Docsによると、ブラウザによっては再起動時にセッションを復元するため、セッションクッキーが残り続ける場合があります。また、有効期限付きの永続的クッキーを使うサイトでは、ブラウザを閉じてもログイン状態が続きます。共用PCではログアウト操作をするのが確実です。
Q. セッションIDを入れるクッキーには、どんな設定が推奨されますか？
A. HTTPS通信のときだけ送るSecure属性、JavaScriptから読み取れなくするHttpOnly属性、他サイトからのリクエストでの送信を制限するSameSite属性が代表的です。OWASPのSession Management Cheat Sheetでは、推測されにくいセッションIDを使うことや、ログイン後にセッションIDを再発行することも推奨されています。
コメント