セッションとは｜意味・Cookieとの関係・切れる理由を実例で解説

HTTP はやり取りを1回ずつ忘れてしまうため、Web のセッションでは、サーバーが渡した「セッション ID」をブラウザが Cookie に入れて毎回持ってくることで、同じ人だと分かるようにしています。

flowchart TD
    A[ブラウザ<br>IDとパスワードを送る] -->|ログイン| S[サーバー<br>セッションIDを作る]
    S -->|Set-Cookie で<br>セッションIDを渡す| A
    A -->|次からCookieで<br>セッションIDを送る| S
    S -->|IDで記録を探す| D[(セッションの記録<br>だれ・いつまで)]

急いでいる人向けに、よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.4 LTS。Python 3.11.15 と Flask 3.1.3（Werkzeug 3.1.9）で、ログインのある小さなサーバーを2種類（Cookie に中身を入れる型と、サーバーに記録を置く型）作り、curl 8.5.0・requests 2.34.2・PyJWT 2.15.1 で、セッションが始まる・続く・切れる様子を確かめました。ブラウザの Cookie の扱いは Chromium 141.0.7390.37（playwright-core 1.64.1）、PHP 8.4.21 と Express 5.3.0（express-session 1.19.0、Node.js 22.22.2）の Set-Cookie も実際に出し、Django は 5.2.18 のソースで既定値を確かめました。TCP の接続は ss（iproute2 6.1.0）、DB のセッションは apt の PostgreSQL 16.15 の pg_stat_activity で見ています。PostgreSQL の試験用データベースは終わったあと削除しました。仕様は MDN・RFC 6265・RFC 7519・RFC 9293・OWASP・Flask・PHP・PostgreSQL・Google アナリティクスの公式ドキュメントで確かめました（確認日 2026年10月23日）。

セッションとは（意味と見分け方）

この節では、「セッション」という言葉の意味と、場面ごとに何を指しているかの見分け方が分かります。

セッション（session）は、もともと「ひと区切りの集まり・期間」という意味の英語です。 会議や学会の「セッション」、音楽の「ジャムセッション」も同じ言葉で、ひとまとまりの時間や集まりを指します。

IT では、「やり取りの始まりから終わりまでのひとまとまり」を指します。NTTドコモビジネスの用語解説も、通信の開始から終了までを指す、と説明しています。何と何のやり取りかによって、指すものが変わります。

ふだん「セッション」と言うときは、Web のログイン状態を指していることがいちばん多い言葉です。 この記事でも Web のセッションを中心に説明し、ほかの意味は後半の節で実物とともに見分けます。

なぜセッションが必要なのか（HTTPは状態を持たない）

この節では、Web にセッションという仕組みが要る理由が分かります。

Web で使う HTTP は、1回のリクエスト（頼みごと）と1回のレスポンス（返事）で完結し、前のやり取りを覚えていません。 これを「ステートレス（状態を持たない）」と言います。MDN も「HTTP プロトコルは既定ではステートレス」と説明しています。

たとえると、HTTP のサーバーは「毎回はじめて会う窓口の人」です。ログインのページで名前とパスワードを伝えても、次のページを開いた瞬間には、あなたがだれだったかを忘れています。これでは、ページを移るたびにログインし直すことになります。

セッションは、状態を持たない HTTP の上で「さっきの人ですね」を実現するための仕組みです。 番号札がセッション ID、番号札を入れて持ち歩く入れ物が Cookie にあたります。

Webのセッションの仕組み（セッションIDとCookieの流れ）

この節では、セッション ID と Cookie がどのヘッダーでやり取りされるのかが、実際の HTTP のヘッダーで分かります。

セッションに関わる HTTP ヘッダーは2つだけです。

後の節で動かしたサーバーがログイン時に返した、実際のヘッダーです。

HTTP/1.1 200 OK
Set-Cookie: sid=pTYY75Yp3VAaREjl4h9RpVERXFnhaLIDRMwvIxwy-mA; HttpOnly; Path=/; SameSite=Lax

Set-Cookie の後ろに付く属性は、Cookie の扱い方を決めます。どれもセッションを守るために使われます。

MDN は、Max-Age も Expires も無い Cookie を「セッション Cookie」と呼び、現在のセッションが終わると消える、と説明しています。ただし、ブラウザによっては再起動のときにセッションを復元するため、ブラウザを閉じても消えないことがある、とも書かれています。

主な Web フレームワークで、セッションを使ったときに返る Set-Cookie を実際に出すと、次のようになりました（Flask・PHP・Express は手元で実行、Django はソースの既定値）。

# Flask 3.1.3（permanent を true にしたとき）
Set-Cookie: session=eyJfcGVybWFuZW50Ijp0cnVlLCJ1c2VyIjoidGFybyJ9.atsePQ.0vPPktXs2RE8Cfw4I5XbcQVGpDM; Expires=Fri, 23 Oct 2026 08:43:51 GMT; HttpOnly; Path=/; SameSite=Lax
# PHP 8.4.21（session_start の既定）
Set-Cookie: PHPSESSID=1608f3822495d8fbe104639244ed9a6f; path=/
# Express 5.3.0 + express-session 1.19.0（既定）
Set-Cookie: connect.sid=s%3A_v5GkVoC7RP0cTqsXFxvBXjwiXDb-Y_n.V2pr3CisjjFkW5Ip8yp442Cwi4X%2FlHQ3so1ngSKsieM; Path=/; HttpOnly

同じ「セッション」でも、名前・期限・状態を置く場所はフレームワークごとに違います。 PHP の既定の Cookie には HttpOnly が付いていません（session.cookie_httponly の既定が 0）。使うフレームワークの設定で、次の節以降に出てくる属性と期限を確かめておくと、あとで「切れる・続かない」に迷いにくくなります。

手元のサーバーで試す（Flaskとcurlでセッションが続く・切れる）

この節では、ログインのある小さなサーバーを手元で動かし、セッションが始まる・続く・切れる様子を curl の出力で確かめられます。

ログインのあるサーバーを用意する

Flask の session を使った、ログイン・自分の確認・ログアウトだけのサーバーです。試しやすいように、有効期限を10秒にしています。

# app_cookie.py
from datetime import timedelta
from flask import Flask, request, session

app = Flask(__name__)
app.config.update(
    SECRET_KEY="demo-secret-change-me",          # 本番は secrets.token_hex() で作った値を環境変数から
    PERMANENT_SESSION_LIFETIME=timedelta(seconds=10),  # 試すために10秒
    SESSION_COOKIE_SAMESITE="Lax",
)
USERS = {"taro": "pass1234"}


@app.post("/login")
def login():
    name, pw = request.form.get("user"), request.form.get("password")
    if USERS.get(name) != pw:
        return "IDかパスワードが違います\n", 401
    session.clear()
    session["user"] = name
    session.permanent = True        # 有効期限つきのCookieにする
    return f"ログインしました: {name}\n"


@app.get("/me")
def me():
    if "user" not in session:
        return "ログインしていません（セッションが切れたか未ログイン）\n", 401
    return f"ログイン中: {session['user']}\n"


@app.post("/logout")
def logout():
    session.clear()
    return "ログアウトしました\n"


if __name__ == "__main__":
    app.run(host="127.0.0.1", port=37501)

python3 -m venv venv && ./venv/bin/pip install flask
./venv/bin/python app_cookie.py

ログインするとセッションが始まる

curl の -c ファイル は受け取った Cookie をファイルに保存し、-b ファイル はそのファイルの Cookie を送ります。ブラウザが自動でしていることを、手で再現できます。

$ curl -s http://127.0.0.1:37501/me
ログインしていません（セッションが切れたか未ログイン）

$ curl -s -i -c jar.txt -d user=taro -d password=pass1234 http://127.0.0.1:37501/login
HTTP/1.1 200 OK
Server: Werkzeug/3.1.9 Python/3.11.15
Date: Fri, 23 Oct 2026 08:43:41 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 31
Vary: Cookie
Set-Cookie: session=eyJfcGVybWFuZW50Ijp0cnVlLCJ1c2VyIjoidGFybyJ9.atsePQ.0vPPktXs2RE8Cfw4I5XbcQVGpDM; Expires=Fri, 23 Oct 2026 08:43:51 GMT; HttpOnly; Path=/; SameSite=Lax
Connection: close

ログインしました: taro

$ curl -s -b jar.txt http://127.0.0.1:37501/me
ログイン中: taro

$ cat jar.txt
# Netscape HTTP Cookie File
# https://curl.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

#HttpOnly_127.0.0.1 FALSE   /   FALSE   1792745031  session eyJfcGVybWFuZW50Ijp0cnVlLCJ1c2VyIjoidGFybyJ9.atsePQ.0vPPktXs2RE8Cfw4I5XbcQVGpDM

Cookie を付けないと「ログインしていません」、ログインで受け取った Cookie を付けると「ログイン中: taro」になりました。 サーバーは毎回のリクエストを忘れていますが、Cookie で同じ人だと分かっています。Expires はログインの10秒後（08:43:51）で、jar.txt の 1792745031 はその時刻を数字（1970年からの秒数）で書いたものです。

Cookieの中身を見る（署名はあるが暗号化はされない）

Flask の Cookie の値は「中身.時刻.署名」の3つに . で分かれています。先頭を base64 でデコードしました。

$ echo 'eyJfcGVybWFuZW50Ijp0cnVlLCJ1c2VyIjoidGFybyJ9' | base64 -d
{"_permanent":true,"user":"taro"}

Flask の既定のセッションは、中身をそのまま Cookie に入れています。 Flask の公式ドキュメントも、利用者は Cookie の中身を見られるが、署名に使う秘密鍵を知らなければ書き換えられない、と説明しています。中身の user を admin に書き換えて送ると、署名が合わず、ログインしていない扱いになりました。

$ curl -s -H "Cookie: session=eyJfcGVybWFuZW50Ijp0cnVlLCJ1c2VyIjoiYWRtaW4ifQ.atseYw.silo148aHAQfbYW664r8VT1RcwU" http://127.0.0.1:37501/me
ログインしていません（セッションが切れたか未ログイン）

Cookie に入れる型のセッションには、パスワード・個人情報など、見られて困るものを入れません。

有効期限が過ぎるとセッションが切れる

ログインした Cookie を、すぐと12秒後に送りました。

17:44:07
$ curl -s -H "Cookie: session=eyJfcGVybWFuZW50Ijp0cnVlLCJ1c2VyIjoidGFybyJ9.atseVw.nQicDyWpSHpSnXiYnwLReAiZdm0" http://127.0.0.1:37501/me
ログイン中: taro
17:44:19
$ curl -s -i -H "Cookie: session=（同じ値）" http://127.0.0.1:37501/me
HTTP/1.1 401 UNAUTHORIZED
ログインしていません（セッションが切れたか未ログイン）

同じ Cookie でも、10秒を過ぎると 401 になりました。 Flask の設定の説明どおり、既定の Cookie の実装は、PERMANENT_SESSION_LIFETIME より前に作られた署名を受け付けません。ブラウザ側で Cookie が消えるだけでなく、サーバー側でも期限を確かめているので、期限切れの Cookie を送り直しても通りません。これが「セッションが切れました」の正体です。

Pythonからセッションを続ける（requests.Session）

プログラムから Web にログインして続けて操作するときは、Cookie を覚えておく入れ物を使います。Python の requests では requests.Session です。

import requests

B = "http://127.0.0.1:37502"
s = requests.Session()            # Cookie を覚えておく入れ物
s.trust_env = False               # 手元のサーバーなのでプロキシを使わない
print(s.get(f"{B}/me").status_code)
r = s.post(f"{B}/login", data={"user": "taro", "password": "pass1234"})
print(r.status_code, r.text.strip())
print("覚えたCookie:", list(s.cookies.keys()))
print(s.get(f"{B}/me").text.strip())
print("Sessionを使わない場合:", requests.get(f"{B}/me", proxies={"http": None}).status_code)

401
200 ログインしました: taro
覚えたCookie: ['sid']
ログイン中: taro（保存中のセッション 1 件）
Sessionを使わない場合: 401

requests.get を毎回そのまま呼ぶと Cookie が引き継がれず、401 のままです。ブラウザ・curl の -b・requests.Session は、どれも「受け取った Cookie を次のリクエストに付ける」という同じことをしています。

セッションの保存場所（サーバー側・Cookie側・トークンJWTの違い）

この節では、セッションの状態をどこに置くかで3つの型があり、ログアウトや期限切れのふるまいが変わることが、実物で分かります。

セッションの状態は、サーバーに置くか、Cookie やトークンに書いてブラウザに持たせるかの2通りに分かれます。 上で使った Flask の既定は「Cookie に書く」型でした。比べるために、状態をサーバーのメモリに置く型も作りました。

# app_server.py（抜粋）
import secrets, time
IDLE_TIMEOUT = 10          # 最後のアクセスから10秒で切れる（試すための値）
STORE = {}                 # セッションID -> {"user": ..., "last": ...}（本番は Redis や DB に置く）

def current_user():
    sid = request.cookies.get("sid")
    data = STORE.get(sid)
    if data is None:
        return None
    if time.time() - data["last"] > IDLE_TIMEOUT:
        del STORE[sid]                      # 期限切れはサーバー側で消す
        return None
    data["last"] = time.time()              # アクセスのたびに期限を延ばす
    return data["user"]

@app.post("/login")
def login():
    # ……ID とパスワードを確かめたあと
    STORE.pop(request.cookies.get("sid"), None)   # ログイン前のIDは捨てる
    sid = secrets.token_urlsafe(32)               # 推測できない新しいID
    STORE[sid] = {"user": name, "last": time.time()}
    resp = make_response(f"ログインしました: {name}\n")
    resp.set_cookie("sid", sid, httponly=True, samesite="Lax", path="/")
    return resp

@app.post("/logout")
def logout():
    STORE.pop(request.cookies.get("sid"), None)   # サーバー側で無効にする
    resp = make_response("ログアウトしました\n")
    resp.delete_cookie("sid", path="/")
    return resp

secrets.token_urlsafe(32) は 32 バイト（256 ビット）の乱数から作る 43 文字の ID です。OWASP は、セッション ID には少なくとも 64 ビットのエントロピー（推測のしにくさ）が要り、暗号用の乱数で作るよう勧めています。

ログアウトしたあと、前のCookieはどうなるか

2つの型で、ログアウトしたあとに、ログアウト前の Cookie の値を送り直しました。

# サーバーに置く型（app_server.py）
$ curl -s -X POST -H "Cookie: sid=sjZTkD3r6JJ0vbNLypO080oYqI9CiTgPkNr43o72wrU" http://127.0.0.1:37502/logout
ログアウトしました
$ curl -s -H "Cookie: sid=sjZTkD3r6JJ0vbNLypO080oYqI9CiTgPkNr43o72wrU" http://127.0.0.1:37502/me
ログインしていません（セッションが切れたか未ログイン）

# Cookie に書く型（app_cookie.py）
$ curl -s -i -X POST -H "Cookie: session=（ログイン時の値）" http://127.0.0.1:37501/logout
Set-Cookie: session=; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Max-Age=0; HttpOnly; Path=/; SameSite=Lax
ログアウトしました
$ curl -s -H "Cookie: session=（ログイン時の値）" http://127.0.0.1:37501/me
ログイン中: taro

Cookie に書く型では、サーバーが「この値はもう使えない」と覚えていないため、期限内の値は通り続けます。 OWASP も、ログアウトではクライアントの Cookie を消すだけでなく、サーバー側でセッションを無効にするよう勧めています。ログアウトや強制ログアウトが大事なサービスでは、状態をサーバーに置く型（Flask なら拡張機能でサーバー側セッションにする）を選ぶか、期限を短くします。

トークン（JWT）を使う方法との違い

JWT（JSON Web Token）は、「だれか」「いつまで有効か」などを JSON で書き、署名を付けた文字列です。 RFC 7519 は JWT を「2者のあいだで受け渡すクレーム（主張）を表す、コンパクトで URL に使える方法」と定義しています。API では、Cookie の代わりに Authorization: Bearer トークン ヘッダーで送ることが多い形です。

PyJWT で、5秒で期限が切れるトークンを作りました。

import base64, json, secrets, time
import jwt   # PyJWT

KEY = secrets.token_bytes(32)   # 32バイト以上のランダムな鍵
token = jwt.encode({"sub": "taro", "exp": int(time.time()) + 5}, KEY, algorithm="HS256")
print(token)
for part in token.split(".")[:2]:
    print(base64.urlsafe_b64decode(part + "=" * (-len(part) % 4)).decode())
print("検証:", jwt.decode(token, KEY, algorithms=["HS256"]))
time.sleep(6)
try:
    jwt.decode(token, KEY, algorithms=["HS256"])
except jwt.ExpiredSignatureError as e:
    print(type(e).__name__, e)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0YXJvIiwiZXhwIjoxNzkyNzQ1MTIxfQ.-p8-bLrXfjYemVkjm8RTDp5Vu5WNzul1uUjYyR2d7QY
{"alg":"HS256","typ":"JWT"}
{"sub":"taro","exp":1792745121}
検証: {'sub': 'taro', 'exp': 1792745121}
ExpiredSignatureError Signature has expired

鍵を21バイトの文字列にしたときは、PyJWT が InsecureKeyLengthWarning: The HMAC key is 21 bytes long, which is below the minimum recommended length of 32 bytes for SHA256. という警告を出しました。HS256 の鍵は32バイト以上の乱数にします。

JWT の仕組みと注意点は、関連記事「JWTとは｜仕組みと、安全に使うための注意点」で扱っています。

セッションとCookieの違い

この節では、よく混同されるセッションと Cookie の違いが一言で分かります。

Cookie は「ブラウザに保存される小さなデータ（入れ物）」、セッションは「サーバーとブラウザのあいだで続いている状態」です。 多くの Web サービスでは、セッションを続けるために、Cookie という入れ物でセッション ID を運んでいます。

「セッション Cookie」は、有効期限の無い Cookie（ブラウザを閉じると消える）のことで、ログインのセッションとは別の言葉です。セッション ID が行き来する流れを図で追う解説は、関連記事「Cookieとセッションの違いと仕組み｜セッションIDの流れを図解」で扱っています。ブラウザのほかの保存場所との違いは、関連記事「localStorage・sessionStorage・Cookieの違い｜実測比較」で扱っています。

セッションの有効期限とタイムアウト（「セッションが切れました」の意味）

この節では、セッションが切れる2種類の期限と、期限が延びる仕組み、目安の長さが分かります。

「セッションが切れました」「セッションの有効期限が切れました」は、サーバーが覚えていたログイン状態が期限で消えたので、もう一度ログインが要る、という意味です。 入力中のフォームがあると、送信したときに内容が失われることがあります。

期限には2種類あります。

flowchart TD
    L[ログイン<br>セッション開始] --> A[有効<br>操作するたび期限を延長]
    A -->|操作なし| T[アイドル<br>タイムアウト]
    A -->|ログインから<br>一定時間| X[絶対<br>タイムアウト]
    T --> E[セッション終了<br>もう一度ログイン]
    X --> E

サーバーに置く型（期限10秒、アクセスのたびに延長）で、6秒おきに3回アクセスしてから、11秒あけました。

ログイン（ここから6秒おきにアクセス）
17:44:30 ログイン中: taro（保存中のセッション 1 件）
17:44:36 ログイン中: taro（保存中のセッション 1 件）
17:44:42 ログイン中: taro（保存中のセッション 1 件）
17:44:53 ログインしていません（セッションが切れたか未ログイン）

期限10秒のセッションが18秒続いたのは、アクセスのたびに「最後の操作の時刻」を更新していたからです。 操作が止まって10秒を過ぎた時点で、サーバーが記録を消しました。

期限の長さの目安です。

OWASP は、タイムアウトはサーバー側で確かめるよう勧めています。ブラウザの JavaScript のタイマーだけで切ると、書き換えられるためです。

ブラウザでセッションのCookieを見る（HttpOnlyと有効期限）

この節では、ブラウザがセッションの Cookie をどう保存し、JavaScript からどう見えるかが、Chromium で確かめた実物で分かります。

Chromium で2つのサーバーにログインし、ページの JavaScript から theme=dark という Cookie も作ってから、ブラウザが持っている Cookie を一覧にしました。

http://127.0.0.1:37502 ログイン前 401
ログイン後 200 ログイン中: taro（保存中のセッション 4 件）
document.cookie = "theme=dark"
http://127.0.0.1:37501 ログイン前 401
ログイン後 200 ログイン中: taro
document.cookie = "theme=dark"
theme 127.0.0.1 httpOnly=false expires=-1 sameSite=Lax
sid 127.0.0.1 httpOnly=true expires=-1 sameSite=Lax
session 127.0.0.1 httpOnly=true expires=1792745167.636993 sameSite=Lax
新しいコンテキスト 401 cookies= 0

セッション ID に HttpOnly を付けると、ページに悪いスクリプトが入り込んでも document.cookie からは読めません。 MDN も、HttpOnly はクロスサイトスクリプティング（XSS）の緩和に役立つ、と説明しています。Chrome の開発者ツールでは、Application パネルの「Storage」→「Cookies」でサイトを選ぶと同じ一覧が出ます。公式ドキュメントでは、期限の無いセッション Cookie は Expires / Max-Age の列に Session と表示されます。

TCPの接続・OSIのセッション層との違い

この節では、通信の「セッション（接続）」と、Web のログインのセッションが別物であることが、実際の接続の一覧で分かります。

TCP では、2台のあいだの1本の接続をセッションと呼ぶことがあります。 RFC 9293 は、TCP の接続を「1組のソケット（IP アドレスとポート番号の組）で決まるもの」とし、3ウェイハンドシェイクで始めると定めています。

同じログインの Cookie を付けて、curl で3回アクセスしました。%{local_port} は、この接続でブラウザ側（curl）が使ったポート番号です。

$ for i in 1 2 3; do curl -s -H "Cookie: sid=$S" -w '  ← 送信元ポート %{local_port}\n' http://127.0.0.1:37502/me; done
ログイン中: taro（保存中のセッション 2 件）  ← 送信元ポート 38118
ログイン中: taro（保存中のセッション 2 件）  ← 送信元ポート 38120
ログイン中: taro（保存中のセッション 2 件）  ← 送信元ポート 38136

1本の接続を開いたままにしているあいだに、ss で接続の一覧を見ました。

$ ss -tn state established '( dport = :37502 or sport = :37502 )'
Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
0      0          127.0.0.1:38142    127.0.0.1:37502       
0      0          127.0.0.1:37502    127.0.0.1:38142       

3回とも送信元ポートが違う、別々の TCP 接続でしたが、ログインのセッションは続いていました。 Web のセッションは Cookie の ID で続くので、TCP の接続が切れても、つなぎ直しても関係ありません。逆に、TCP の接続が続いていても、ログインの期限が切れれば Web のセッションは終わります。

OSI 参照モデルの第5層は「セッション層」と呼ばれます。 Cloudflare の解説では、2つの機器のあいだの通信の開始と終了を受け持つ層で、通信が開いてから閉じるまでの時間をセッションと呼ぶ、と説明されています。実際のインターネットで使う TCP/IP には独立したセッション層が無く、その役割はアプリや TLS などが受け持ちます。7層それぞれの役割は、関連記事「OSI参照モデルとは｜7層の早見表とTCP/IP対応・パケット実例」で扱っています。

データベースのセッション（PostgreSQLのpg_stat_activityで見る）

この節では、データベースの「セッション」が何を指すかと、PostgreSQL で今あるセッションを一覧にして、困ったセッションを見つける方法が分かります。

データベースのセッションは、アプリや psql とデータベースのあいだの1本の接続です。 PostgreSQL では、1つのセッションに1つのサーバープロセスが割り当てられ、pg_stat_activity というビューに1行ずつ出ます。

試験用のデータベース s375db に、在庫の表を作って3つのセッションをつなぎました。

• app_a：BEGIN して在庫を1減らし、確定（COMMIT）せずに止まっている
• app_b：SELECT 1 を実行したあと何もしていない
• app_c：app_a と同じ行の在庫を減らそうとしている

SELECT pid, application_name AS app, state, wait_event_type AS wait, left(query, 44) AS query
FROM pg_stat_activity
WHERE datname = 's375db' AND pid <> pg_backend_pid()
ORDER BY application_name;

SELECT application_name AS app, pg_blocking_pids(pid) AS blocked_by,
       backend_start::time(0) AS 接続, xact_start::time(0) AS トランザクション開始, state_change::time(0) AS 状態変化
FROM pg_stat_activity WHERE datname = 's375db' AND pid <> pg_backend_pid() ORDER BY 1;

 pid  |  app  |        state        |  wait  |                    query                     
------+-------+---------------------+--------+----------------------------------------------
 7630 | app_a | idle in transaction | Client | UPDATE stock SET qty = qty - 1 WHERE id = 1;
 7631 | app_b | idle                | Client | SELECT 1;
 7641 | app_c | active              | Lock   | UPDATE stock SET qty = qty - 1 WHERE id = 1;
(3 rows)

  app  | blocked_by |   接続   | トランザクション開始 | 状態変化 
-------+------------+----------+----------------------+----------
 app_a | {}         | 08:47:26 | 08:47:26             | 08:47:26
 app_b | {}         | 08:47:26 |                      | 08:47:26
 app_c | {7630}     | 08:47:28 | 08:47:28             | 08:47:28
(3 rows)

app_c は active ですが、wait が Lock で、blocked_by に app_a の pid 7630 が出ています。 確定しないまま止まっている app_a のセッションが行のロックを持ち続け、app_c を待たせています。時刻は DB サーバーの設定どおり UTC で表示されています。

app_a のセッションを切ると、app_c が進みました。

=> SELECT pg_terminate_backend(7630);
 pg_terminate_backend 
----------------------
 t
(1 row)

-- app_c の出力
UPDATE 1

=> SELECT qty FROM stock;
 qty 
-----
   9
(1 row)

在庫は10から9になりました。切られた app_a の変更は確定していないので取り消され、app_c の1回分だけが反映されています。pg_terminate_backend は相手のトランザクションを取り消すので、本番で使うときは、だれの何の処理かを pg_stat_activity で確かめてからにします。

止まったままのセッションを、PostgreSQL に自動で切らせる設定もあります。3秒にして試しました。

=> SET idle_in_transaction_session_timeout = '3s';
=> BEGIN;
=> SELECT qty FROM stock WHERE id = 1;
（5秒待つ）
=> SELECT qty FROM stock WHERE id = 1;
FATAL:  terminating connection due to idle-in-transaction timeout
server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
connection to server was lost

=> SET idle_session_timeout = '3s';
（5秒待つ）
=> SELECT 1;
FATAL:  terminating connection due to idle-session timeout

PostgreSQL のドキュメントは、idle_session_timeout を接続プールのソフトを通る接続にかけるときは注意するよう書いています。プールは予期しない切断にうまく対応できないことがあるためで、対話用のユーザーだけにかける例（ALTER ROLE … SET）が載っています。試験用のデータベースは、確かめたあと dropdb s375db で削除しました。

セッションの数の上限（max_connections、この環境では100）と、増えすぎたときの対処は、関連記事「PostgreSQL接続数の確認｜pg_stat_activityの見方と対処」で扱っています。

アクセス解析（GA4）のセッションとは

この節では、アクセス解析で使う「セッション」の意味と数え方、ページビュー・ユーザーとの違いが分かります。

アクセス解析のセッションは、サイトへの1回の訪問のことです。 Google アナリティクス 4（GA4）のヘルプは、セッションを「特定の期間内にウェブサイトまたはアプリで発生した一連のユーザー インタラクション」と説明しています。ログインの有無とは関係なく、ページを見に来た人すべてを数えます。

GA4 のヘルプに書かれている数え方です。

Web担当者Forum の解説では、以前のユニバーサル アナリティクス（UA）は日付が変わるときや参照元が変わるときにもセッションを区切りましたが、GA4 は30分以内なら同じセッションとして数える、とされています。そのため、UA と GA4 でセッション数が合わないことがあります。

30分の決まりで、アクセスの記録からセッションを数える Python の例です。

from datetime import datetime, timedelta

TIMEOUT = timedelta(minutes=30)   # GA4 の既定値と同じ30分
log = [  # (ユーザー, 時刻, ページ)
    ("A", "09:00", "/"), ("A", "09:05", "/price"), ("A", "09:20", "/contact"),
    ("A", "10:10", "/"),                       # 50分あいた → 新しいセッション
    ("B", "12:00", "/blog/1"),
    ("B", "12:29", "/blog/2"), ("B", "12:58", "/blog/3"),  # 29分ずつ → 続く
    ("B", "13:40", "/"),                       # 42分あいた → 新しいセッション
]
sessions, last = {}, {}
for user, t, page in log:
    now = datetime.strptime(t, "%H:%M")
    if user not in last or now - last[user] > TIMEOUT:
        sessions.setdefault(user, []).append([])
    sessions[user][-1].append(f"{t} {page}")
    last[user] = now
pv = len(log)
n = sum(len(v) for v in sessions.values())
for user, ss in sessions.items():
    for i, s in enumerate(ss, 1):
        print(f"ユーザー{user} セッション{i}: {', '.join(s)}")
print(f"ユーザー数 {len(sessions)} / セッション数 {n} / ページビュー {pv}")

ユーザーA セッション1: 09:00 /, 09:05 /price, 09:20 /contact
ユーザーA セッション2: 10:10 /
ユーザーB セッション1: 12:00 /blog/1, 12:29 /blog/2, 12:58 /blog/3
ユーザーB セッション2: 13:40 /
ユーザー数 2 / セッション数 4 / ページビュー 8

ユーザー B は 12:00 から 12:58 まで1時間近く見ていますが、間が29分ずつなので1つのセッションです。 「ブラウザを閉じたら終わり」ではなく、「最後の操作から30分」で区切るのが GA4 の数え方です。

セッション数は、検索結果からの流入・SNS や広告からの流入・メールなど、サイトに来る入口が増えると増えます。入口ごとのセッション数は、上の「トラフィック獲得」レポートでチャネル（流入元の種類）ごとに見られます。1回の訪問で何ページ見られたか（PV ÷ セッション）や、エンゲージメント セッションの割合を合わせて見ると、来た人が読み進めているかが分かります。

セッションが切れる・続かないときの原因と直し方

この節では、「すぐ切れる」「ログインが続かない」ときの原因を、実際に起こした例とともに表で引けます。

まず、Chromium で4種類の Cookie を同時に受け取らせ、どれがブラウザに保存されて次のリクエストで送られたかを確かめました。

（サーバーが返した Cookie）a_plain・b_secure（Secure）・c_none_nosecure（SameSite=None で Secure なし）・d_toolong（値が5,000バイト）
127.0.0.1 → 受け取ったCookie: a_plain, b_secure
localhost → 受け取ったCookie: a_plain, b_secure
192.0.2.2 → 受け取ったCookie: a_plain

UserWarning: The 'd_toolong' cookie is too large: the value was 5000 bytes but the header required 28 extra bytes. The final size was 5028 bytes but the limit is 4093 bytes. Browsers may silently ignore cookies larger than this.

Secure の Cookie は、http の 127.0.0.1・localhost では保存されましたが、http のほかのアドレス（192.0.2.2）では保存されませんでした。 SameSite=None で Secure の無い Cookie と、5,000 バイトの Cookie は、どのアドレスでも保存されませんでした。ブラウザはエラーを出さずに捨てるので、「ログインは成功と表示されるのに、次のページでログイン前に戻る」という形で現れます。

切り分けるときは、ブラウザの開発者ツールで「Set-Cookie が返っているか」「次のリクエストに Cookie が付いているか」を先に見ます。返っていなければサーバー側、返っているのに付いていなければ属性（Secure・SameSite・大きさ・Path）の問題です。

セッションを安全に扱うためのチェックリスト

この節では、セッションを使うアプリを作るときに守ることが、チェックリストで分かります。内容は OWASP の Session Management Cheat Sheet と MDN の説明にもとづきます。

• 1セッション ID は暗号用の乱数で作る64ビット以上の推測しにくさ。Python なら secrets.token_urlsafe(32) で256ビット
• 2ログインしたら ID を作り直す権限が変わるたびに新しい ID にし、前の ID は使えなくする（実物でもログイン前の ID は通らなかった）
• 3Cookie に HttpOnly・Secure・SameSite を付けるJavaScript から読めなくし、HTTPS だけで送り、ほかのサイトからの送信を絞る
• 4セッション ID を URL に入れないURL は履歴・ログ・Referer に残る。Cookie で運ぶ
• 5期限とログアウトはサーバー側で確かめるアイドルと絶対の2つの期限。ログアウトでサーバーの記録を消す
• 6Cookie やトークンに秘密を書かないFlask の Cookie も JWT も、中身は base64 で読めた
• 7トークンを localStorage に置かないOWASP は、同じオリジンのスクリプトから読めるため置かないよう勧めている
• 8秘密鍵をコードに書かない環境変数などから読み、リポジトリや質問の投稿に載せない

SameSite を使ってほかのサイトからのリクエストを防ぐ方法は、関連記事「CSRF対策とSameSite｜Cookie送信をChromeで実測し多層防御を実装」で扱っています。

よくある質問

Q. セッションとはわかりやすく言うと何ですか？ A. ひと続きのやり取りの始まりから終わりまでのことです。Web では、ログインしてからログアウトするまで「同じ人だ」と覚えてもらえている状態を指すことが多い言葉です。

Q. IT でいうセッションの意味は？ A. 場面によって、Web のログイン状態・アクセス解析の1回の訪問・TCP の1本の接続・データベースの1本の接続・OSI の第5層を指します。冒頭の見分け表で、始まりと終わりの違いをまとめています。

Q. セッション ID とは？ A. サーバーが、だれのやり取りかを見分けるために作る番号です。推測できない長い乱数で作り、Cookie に入れてブラウザに渡します。この記事のサーバーでは43文字でした。

Q. セッションと Cookie の違いは？ A. Cookie はブラウザに保存される小さなデータ（入れ物）、セッションはサーバーとのあいだで続いている状態です。多くのサービスは、Cookie でセッション ID を運んでセッションを続けています。

Q. 「セッションが切れました」と出たらどうすればよいですか？ A. もう一度ログインします。しばらく操作しなかったか、ログインから一定時間が過ぎて、サーバーが覚えていた状態が消えたという意味です。入力に時間がかかるフォームは、こまめに保存すると内容を失いにくくなります。

Q. セッションの有効期限はどのくらいですか？ A. サービスごとに決めています。既定値は Flask の permanent セッションで31日、Django で2週間、PHP のデータの掃除で24分でした。OWASP は、アイドルタイムアウトを重要なアプリで2〜5分、リスクの低いアプリで15〜30分とする例を挙げています。

Q. セッションとトークン（JWT）の違いは？ A. セッションは状態をサーバーに置き、ブラウザには ID だけを渡します。JWT は状態をトークンの中に書き、サーバーは署名と期限を確かめます。サーバー側セッションはログアウトですぐ無効にでき、JWT は期限まで有効です。

Q. アクセス解析のセッション数とは？ A. サイトへの訪問の回数です。GA4 では、操作が30分無いとセッションが終わり、次に来たときは新しいセッションとして数えます。1回の訪問で何ページ見ても1セッションです。

Q. セッションとページビュー（PV）の違いは？ A. ページビューは見られたページの数、セッションは訪問の回数です。この記事の例では、2人のユーザーで、セッション数4・ページビュー8になりました。

Q. TCP のセッションとは？ A. 2台のコンピューターのあいだの1本の TCP 接続のことです。3ウェイハンドシェイクで始まり、切断で終わります。Web のログインのセッションとは別で、接続が変わってもログインは Cookie で続きました。

Q. データベースのセッションとは？ A. アプリや psql とデータベースのあいだの1本の接続です。PostgreSQL では pg_stat_activity で一覧にでき、idle in transaction のまま止まったセッションがロックを持ち続けると、ほかの処理を待たせます。

Q. セッション層とは？ A. OSI 参照モデルの第5層で、通信の開始と終了を管理する層です。TCP/IP には独立した層が無く、その役割はアプリや TLS などが受け持ちます。

Q. 会議や音楽の「セッション」も同じ意味ですか？ A. もとは同じ英語の session（ひと区切りの集まり・期間）です。会議・学会では発表のまとまり、音楽では一緒に演奏する集まりを指し、IT ではやり取りのひとまとまりを指します。

まとめ

• セッションは「ひと続きのやり取りの始まりから終わりまで」。Web のログイン状態・解析の訪問・TCP や DB の接続・OSI の第5層で、それぞれ指すものが違う。
• HTTP は前のやり取りを覚えないので、サーバーがセッション ID を作り、ブラウザが Cookie で毎回送ることで同じ人だと分かる。
• Flask と curl で、Cookie を付けると「ログイン中」、10秒の期限を過ぎると 401 になった。期限切れの Cookie はサーバー側でも受け付けない。
• 状態をサーバーに置く型はログアウトですぐ無効になり、Cookie に書く型と JWT は期限まで有効だった。Cookie と JWT の中身は base64 で読める。
• 期限はアイドルと絶対の2種類。アクセスのたびに延びる型では、期限10秒でも操作が続けば18秒続いた。
• Secure の Cookie を http で、SameSite=None を Secure なしで、4KB を超える値を送ると、ブラウザは黙って捨て、ログインが続かない。
• PostgreSQL のセッションは pg_stat_activity で見られ、idle in transaction のまま止まったセッションがほかの処理を待たせていた。

参考・出典

確認日はいずれも 2026年10月23日です。

• NTTドコモビジネス「セッションとは」：https://ntt.com/bizon/glossary/j-s/session.html
• MDN Web Docs「HTTP Cookie の使用」：https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Cookies
• IETF「RFC 6265 HTTP State Management Mechanism」：https://www.rfc-editor.org/rfc/rfc6265
• IETF「RFC 7519 JSON Web Token (JWT)」：https://www.rfc-editor.org/rfc/rfc7519
• IETF「RFC 9293 Transmission Control Protocol (TCP)」：https://www.rfc-editor.org/rfc/rfc9293
• OWASP「Session Management Cheat Sheet」：https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
• Flask「Quickstart（Sessions）」：https://flask.palletsprojects.com/en/stable/quickstart/
• Flask「Configuration Handling」：https://flask.palletsprojects.com/en/stable/config/
• PHP マニュアル「実行時設定（セッション）」：https://www.php.net/manual/ja/session.configuration.php
• Django「Settings」：https://docs.djangoproject.com/en/stable/ref/settings/
• PostgreSQL 16 Documentation「The Cumulative Statistics System（pg_stat_activity）」：https://www.postgresql.org/docs/16/monitoring-stats.html
• PostgreSQL 16 Documentation「Client Connection Defaults」：https://www.postgresql.org/docs/16/runtime-config-client.html
• Cloudflare「OSIモデルとは？」：https://www.cloudflare.com/ja-jp/learning/ddos/glossary/open-systems-interconnection-model-osi/
• Google アナリティクス ヘルプ「[GA4] セッション」：https://support.google.com/analytics/answer/12798876?hl=ja
• Google アナリティクス ヘルプ「[GA4] アナリティクスのセッションについて」：https://support.google.com/analytics/answer/9191807?hl=ja
• Google アナリティクス ヘルプ「[GA4] トラフィック獲得レポート」：https://support.google.com/analytics/answer/12923437?hl=ja
• Google for Developers「Measure sessions and user engagement」：https://developers.google.com/analytics/devguides/collection/ga4/sessions
• Web担当者Forum「GA4とUAのセッション計測の違いとは？」：https://webtan.impress.co.jp/u/2021/02/10/39088

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。