セッション | ぽち先生と学ぶ IT基礎ノート

要点

セッションとは、サーバー側で利用者ごとの状態を一時的に覚えておく仕組みで、ブラウザには「セッションID」という短い識別子だけを渡します。
セッションIDの受け渡しには、多くの場合Cookieが使われます。HttpOnly・Secureなどの属性で、盗聴やスクリプトによる窃取から守ることが重要です。
複数サーバーで動かす場合は、セッションの実体をRedisなどの外部ストアにまとめて置く必要があります。
近年は、サーバー側に状態を持たない「トークン認証（JWTなど）」との使い分けも重要な設計判断になっています。

復習：HTTPは状態を覚えない

HTTPには「ステートレス」という性質があり、1回のリクエストが終わるたびに関係がリセットされます。サーバーは「さっき誰が何をしてきたか」を基本的に覚えていません。

1回目の
リクエスト

覚えていない

2回目の
リクエスト

しかし実際のWebアプリでは「ログインしたまま複数ページを見て回りたい」という要望があります。この課題を解決するのがセッションです。

セッションとは何か

セッションは、サーバー側のメモリやデータベース（「セッションストア」と呼ばれます）に、利用者ごとの状態を一時的に保存しておく仕組みです。

ブラウザには保存先を指し示す「セッションID」という短い文字列だけを渡します。実際のデータ本体はサーバー側に置いたままにしておくのがポイントです。

サーバー
（セッションストア）

IDだけ発行

ブラウザは
IDだけ保持

ぽち先生のヒント病院の受付番号に似ているよ。あなたの診察情報（カルテ）はすべて病院側で管理されていて、あなた自身が持ち歩くのは「番号札」だけ。番号を見せれば、病院側が該当するカルテをすぐ探し出してくれるんだ。

セッションIDの発行と照合の流れ

初回アクセス時にサーバーがセッションIDを発行し、それ以降のリクエストではブラウザがそのIDを毎回送り返すことで「本人確認」が行われます。

初回アクセス
IDを発行

ブラウザが
IDを保存

次回以降
IDを送信

サーバーが
IDで照合

ぽち先生のヒント駅のコインロッカーにそっくりだよ。荷物（実際のデータ）はロッカーの中に預けたままで、あなたが持ち歩くのは「鍵（番号）」だけ。鍵さえ見せれば、ロッカー側が「これはあなたの荷物です」と中身を出してくれるんだ。荷物そのものを毎回持ち歩く必要はないんだよ。

セッションIDの受け渡しに使われるCookie

セッションIDは、多くの場合Cookieに乗せて受け渡しされます。初回アクセス時のレスポンスに「Set-Cookie」ヘッダーでIDを渡し、以降のリクエストではブラウザが「Cookie」ヘッダーで自動的に送り返します。

サーバー

Set-Cookie:
session_id=abc123

ブラウザが
保存

Cookie:
session_id=abc123

サーバーが
IDで照合

セッションIDを乗せるCookieには、HttpOnly（JavaScriptから読み取れなくする）とSecure（HTTPS通信でしか送らない）を必ず付けるのが基本です。この2つを外すと、あとで見るセッションハイジャックのリスクが一気に高まります。Cookieの仕組みそのものは、Cookieの個別トピックで詳しく解説しています。

セッションストアの実体

セッションデータの保存先（セッションストア）は、サーバーの構成によって選び方が変わります。特に「サーバーを複数台に増やす」場面で、保存先の選択が重要な設計判断になります。

💻 サーバー内メモリ実装が簡単で、単一サーバーなら手軽に使えるサーバーを複数台に増やすと、別のサーバーがIDを認識できず不整合が起きる

🗃️ 外部ストア（Redisなど）全サーバーから共通のセッションストアを参照できる再起動してもセッションが消えにくく、大規模なサービスの定番構成

負荷分散装置（ロードバランサー）で「同じ利用者を毎回同じサーバーに送る」設定（スティッキーセッション）で回避する方法もありますが、サーバー障害時にセッションが失われやすいという弱点があります。

セッションのセキュリティリスクと対策

セッションIDは「本人確認の鍵」そのものなので、盗まれたり悪用されたりすると、なりすましにつながります。代表的なリスクと対策は次のとおりです。

セッションハイジャック通信の盗聴やXSSなどでIDを盗まれ、なりすまされるリスク。

対策：HTTPS化＋HttpOnly／Secure盗聴と、スクリプトからの読み取りの両方を防ぐ。

セッション固定攻撃攻撃者が用意したIDを利用者に使わせ、あとから乗っ取るリスク。

対策：ログイン成功時にIDを再発行認証の前後でセッションIDを必ず変える。

ぽち先生のヒントコインロッカーの鍵を落としたり、他人にすり替えられたりしたら大変だよね。セッションIDも同じで、「鍵そのものを守る」工夫が欠かせないんだ。

セッションタイムアウト

セッションは永久に有効なわけではありません。一定時間操作がないと自動的に無効になる「セッションタイムアウト」という仕組みが設けられています。

操作中セッション有効。ログイン状態を維持。

一定時間経過タイムアウトが近づく。警告表示することも。

タイムアウトセッション失効。再ログインが必要に。

これもセキュリティ上の配慮のひとつです。離席中に第三者にセッションを乗っ取られるリスクを減らすため、銀行系のサイトなどでは特に短いタイムアウト時間が設定されています。

セッションの主な用途

セッションは、ログイン状態の保持だけでなく、Webアプリの様々な機能や、デジタルマーケティング・マーケティングオートメーション（MA）ツールでも活用されています。

🔑 アプリケーション実装での用途ログイン状態の保持: 認証情報を毎回送らず、ログインしたまま画面を移動できるカート・入力途中フォームの一時保持: 会員登録前のカート内容や、複数ステップの入力内容を保存フラッシュメッセージ・CSRF対策トークン: リダイレクト直後の通知や、不正リクエスト対策用トークンの保管

📈 デジタルマーケティング・MAツールでの活用匿名訪問者の行動をセッション単位で記録し、フォーム送信のタイミングで実名の「リード」情報に紐付ける広告・メール経由の流入元（UTMパラメータなど）をセッション中保持し、コンバージョンを正しい施策に紐付ける（アトリビューション）セッション内で閲覧したページや行動をもとに、表示するコンテンツやオファーを出し分ける（パーソナライゼーション）

ぽち先生のヒントMAツールが使う「セッション」も、考え方はここまで見てきた仕組みと同じだよ。一定時間操作がないと区切られる点も共通していて、この区切りのおかげで「どの広告から来て、何を見て、最終的に問い合わせたか」を1つのまとまりとして追跡できるんだ。

ステートレスな代替手段：トークン認証

セッションIDのように「サーバー側に状態を持つ」方式（ステートフル）に対して、近年は「サーバー側に何も保存しない」方式（ステートレス）も広く使われています。代表例がJWTなどのトークン認証です。

🎫 セッションID（ステートフル）サーバー側にセッションストアが必要サーバー側でいつでも強制的にセッションを無効化できる

🔏 トークン（ステートレス）署名を検証するだけでよく、サーバー側の保存が不要サーバーを増やしてもスケールしやすいが、発行済みトークンを個別に無効化しにくい

どちらか一方が常に正解というわけではなく、実際のシステムでは要件に応じて使い分けたり、組み合わせたりします。

まとめ

セッションは、サーバー側に利用者ごとの状態を一時保存し、ブラウザには軽いIDだけを渡すことで「継続したやり取り」を実現する仕組みです。IDの受け渡しにはCookieが使われ、HttpOnly・Secureといった属性や、ログイン時のID再発行、適切なタイムアウトが、なりすましを防ぐための土台になります。サーバーを複数台構成にする場合は外部ストアへの保存が定番で、JWTなどのステートレスなトークン認証との使い分けも重要な設計判断です。