関係データベースにおける同時実行制御

作成: 2026-02-01 23:57

データベース工学という講義の課題2

このページでは、一般的な説明を行う一般モードと、具体的な説明を行う具体モードを切り替えて読むことができます。特に、本文背景色が変わっているところが、切り替えると別の文章が読める部分です。左上の一般モード/具体モードのボタンをクリックして切り替えてください。片方だけでは読めないこともないけど接続が変な部分もありますから、どちらも読むことをおすすめします。

概要

実験環境の準備

事前にDocker Desktopをインストールして起動しておいてください。

まず、PostgreSQL 17(.6) の Dockerイメージをダウンロードします。

docker pull postgres:17.6

compose.ymlの作成

適当な作業ディレクトリを開いて、compose.yml(または、docker-compose.yml)という名前のファイルを作成し、以下の内容を貼り付けて保存してください。

services:
  db:
    image: postgres:17
    container_name: postgres-concurrency-lab
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
      POSTGRES_DB: shop_db
    ports:
      - "5432:5432"

ファイルを作成して保存したら、ターミナルでそのディレクトリに移動し、以下のコマンドを実行してください。

docker compose up -d

これで、PostgreSQL 17 のコンテナが起動します。

ターミナルを2つ開いて接続する

並行処理（複数のユーザーが同時にアクセスする状態）を疑似体験するために、ターミナルのウィンドウを2つ開いてください。 これらを画面の左右に並べて配置することをおすすめします。

ここでは、左側のウィンドウをAさん、右側のウィンドウをBさんとして扱います。

両方のターミナルで、それぞれ以下のコマンドを実行し、PostgreSQLのコマンドラインツール（psql）に接続してください。

docker compose exec db psql -U postgres -d shop_db

プロンプトが

shop_db=#

psql での基本操作と終了方法

psql 内での基本的なルールは以下の通りです。

• SQLの実行

SQL文を入力し、Enterキーを押すと実行されます。結果が表示されます。文の最後には、セミコロン（;）をつける必要があります。セミコロンがないと、改行待ち扱いになりコマンドが実行されません。

• テーブル一覧の確認

\dt と入力してEnterを押すと、作成されているテーブルの一覧を確認できます（これにはセミコロンは不要です）。

• 終了

\q と入力してEnterを押すと、psqlから抜けることができます。あるいは、Ctrl + Dで終了することも可能です。

環境の削除

不要になったら、以下のコマンドを実行してコンテナを削除してください。

docker compose down -v

-v をつけることでデータベースの中身も綺麗に消去されます。

実験用テーブルの作成

実験で使用するテーブルを作成します。どちらか片方のターミナルで以下のSQL文を実行してください。

-- 既存のテーブルがあれば削除
DROP TABLE IF EXISTS inventory;

-- テーブルの作成
CREATE TABLE inventory (
    id SERIAL PRIMARY KEY,
    item_name VARCHAR(50) NOT NULL,
    category VARCHAR(50) NOT NULL,
    stock INT NOT NULL
);

-- 初期データの投入
INSERT INTO inventory (item_name, category, stock) VALUES
('限定スニーカー', 'shoes', 10),
('革靴', 'shoes', 5),
('限定Tシャツ', 'clothes', 10);

実験

これからの実験では、2人のユーザー（AさんとBさん）が同時にデータベースにアクセスしている状況を想定して、トランザクション分離レベルの違いによってどのようなアノマリーが発生するのか、またそれをどう防ぐのかを確認していきます。Aさんは上に、Bさんは下に書いてあるコマンドを順番(その時点では同時に)に実行した、ということにします(空である場合もありますというか、ほとんど片方は空です)。

実験1: Dirty Read（ダーティリード）

トランザクションT1がデータ項目を変更し、その変更がコミットまたはロールバックされる前に、別のトランザクションT2がそのデータを読み取ってしまう現象。もしT1がロールバックした場合、T2は「存在しなかったはずのデータ」を読み取って処理を進めたことになり、不整合を引き起こす。

Aさんが「限定スニーカー」をカートに入れ、決済の確認画面で悩んでいます（まだ購入確定＝コミットしていない）。この時、Bさんが在庫を確認すると、Aさんが買うかどうかわからないのに「在庫が減っている」ように見えてしまう状態です。もしAさんが「やっぱりやめた（ロールバック）」とした場合、Bさんは幻の在庫減少を見ていたことになります。

実は、PostgreSQLではこのDirty Readはシステム構造上、発生しません。それを確認してみましょう。

順番にしたがって、Aさんのターミナル、Bさんのターミナルでそれぞれコマンドを実行してみてください。

ステップ 1

Aさんがトランザクションを開始

BEGIN;

ステップ 2

Aさんが「限定スニーカー」の在庫を1減らす操作を実行（まだコミットしていない）

UPDATE inventory SET stock = stock - 1 WHERE item_name = '限定スニーカー';

ステップ 3

Bさんが「限定スニーカー」の在庫を確認

SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

ステップ 4

Aさんがトランザクションをロールバック。Bさんは在庫が減っていないことを確認（Dirty Readは発生しない）

ROLLBACK;

SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

PostgreSQLは、他の人が「編集中」のデータは決して見せず、常に「確定済み」の安全なデータだけを見せてくれることがわかります。

実験2: Non-repeatable Read（ノンリピータブルリード）

トランザクションT1が特定の行を読み取る。その後、別のトランザクションT2がその行を更新（または削除）してコミットする。T1が再び同じ行を読み取ると、1回目と異なる値を取得してしまう現象。一つのトランザクション内で「読み取り結果の再現性（Repeatable）」が失われる。

Aさんがスニーカーの在庫を確認し「お、まだ10個あるな」と安心して、他のページを見て回っています。その隙に、Bさんがスニーカーを購入し決済を完了（コミット）しました。Aさんがもう一度同じスニーカーの在庫を見ると、自分が何もしていないのに突然「9個」に変わってしまっている現象です。「さっき見たデータと違う！」という状態ですね。

PostgreSQLのデフォルト設定（READ COMMITTED）では、この現象は発生します。

順番に行っている場合は、stockの値を確認して、必要であれば 実験環境の準備 節まで戻ってテーブルをリセットしてください。

ステップ 1

Aさんがトランザクションを開始

BEGIN;

ステップ 2

1回目の確認。結果は「10」

SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

ステップ 3

Bさんがトランザクションを開始

BEGIN;

ステップ 4

Bさんが「限定スニーカー」の在庫を1減らす

UPDATE inventory SET stock = stock - 1 WHERE item_name = '限定スニーカー';

ステップ 5

Bさんがトランザクションを終了

COMMIT;

ステップ 6

Aさんが同じコマンドで2回目の確認。結果が「9」に変わっている！

SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

ステップ 7

Aさんがトランザクションを終了

COMMIT;

Aさんから見ると、同じコマンドを2回実行したのに、結果が異なる（Non-repeatable Read）という現象が発生しています。

Non-repeatable Readは、Fuzzy Readとも呼ばれます。同じ行を読んだのに、トランザクション中に値が曖昧（ファジー）に変わってしまう現象を指します。

実験3: Phantom Read（ファントムリード）

トランザクションT1がある検索条件（WHERE句など）を満たす行の集合を読み取る。その後、別のトランザクションT2がその条件を満たす新しい行を挿入（INSERT）してコミットする。T1が再び同じ条件で検索を行うと、1回目には存在しなかった「幻（ファントム）の行」が結果に現れる現象。Non-repeatable Readが「既存行の更新」であるのに対し、Phantomは「新規行の出現」を指す。

Aさんが「靴（shoes）カテゴリの商品リスト」を検索して、現在2種類あることを確認しました。そのリストをもとに社内資料を作っている最中に、Bさんが裏で新しく「ブーツ」を靴カテゴリに追加（INSERT）しました。Aさんが資料の最終確認でもう一度検索すると、さっきまで無かったはずの商品がリストに増えている（幻影が現れる）現象です。

これもデフォルト設定で発生します。

順番に行っている場合は、stockの値を確認して、必要であれば 実験環境の準備 節まで戻ってテーブルをリセットしてください。

ステップ 1

Aさんがトランザクションを開始

BEGIN;

ステップ 2

1回目の確認。結果は「限定スニーカー」と「革靴」の2行

SELECT item_name FROM inventory WHERE category = 'shoes';

ステップ 3

Bさんがトランザクションを開始

BEGIN;

ステップ 4

Bさんが「ブーツ」を靴カテゴリに追加

INSERT INTO inventory (item_name, category, stock) VALUES ('ブーツ', 'shoes', 5);

ステップ 5

Bさんがトランザクションを終了

COMMIT;

ステップ 6

Aさんが同じコマンドで2回目の確認。結果が「限定スニーカー」「革靴」「ブーツ」の3行に増えている！

SELECT item_name FROM inventory WHERE category = 'shoes';

ステップ 7

Aさんがトランザクションを終了

COMMIT;

Aさんから見ると、同じ検索条件で2回実行したのに、結果の行数が増えている（Phantom Read）という現象が発生しています。

実験4: Dirty Write（ダーティライト）

トランザクションT1があるデータ項目を更新し、それがまだコミットまたはロールバックされていない状態で、別のトランザクションT2が同じデータ項目を上書きしてしまう現象。

Aさんが「限定スニーカー」の在庫を更新処理している最中（まだ確定していない）に、Bさんも同時に同じ在庫を強制的に上書きしてしまう状態です。もしAさんがエラーで処理を取り消そうとしても、Bさんが書き込んだデータまで巻き戻ってしまい、データがぐちゃぐちゃになります。

PostgreSQLでは、Dirty Writeも発生しません。他の人が編集中（未コミット）の行を更新しようとすると、どうなるか見てみましょう。

順番に行っている場合は、stockの値を確認して、必要であれば 実験環境の準備 節まで戻ってテーブルをリセットしてください。

ステップ 1

Aさんがトランザクションを開始

BEGIN;

ステップ 2

Aさんが在庫を変更（未コミット）

UPDATE inventory SET stock = 5 WHERE item_name = '限定スニーカー';

ステップ 3

Bさんがトランザクションを開始

BEGIN;

ステップ 4

Bさんも同じ行を更新しようとする。Bの画面がフリーズ（待機状態）になる！

UPDATE inventory SET stock = 10 WHERE item_name = '限定スニーカー';

ステップ 5

Aさんがトランザクションを確定。その瞬間、Bのフリーズが解けて更新が実行される。

COMMIT;

ステップ 6

Bさんがトランザクションを終了

COMMIT;

PostgreSQLは、同時に同じ行を書き換えようとした場合、自動的に「行ロック（Row-level lock）」をかけて、後から来た人を待たせる仕組みを持っています。

実験5: Lost Update(更新の喪失)

トランザクションT1とT2が同じデータを読み取る（Read）。その後、T1がそのデータをもとに計算して書き込み（Write）、T2も同様に書き込む。結果として、T2の書き込みがT1の書き込みを上書きしてしまい、T1の更新内容が完全に失われる（Lost）現象。

AさんとBさんが同時にスニーカーの在庫（残り10個）を確認しました。「よし、買えるぞ」と、Aさんが「10 - 1 = 9」に更新しました。同時にBさんも、自分が最初に見た「10個」という数字をもとに「10 - 1 = 9」に更新しました。 2個売れたのだから本当は「8個」にならなければいけないのに、結果は「9個」になり、1個分の売上が消滅（ロスト）してしまいます。

実験5: Lost Update(更新の喪失)

トランザクションT1とT2が同じデータを読み取る（Read）。その後、T1がそのデータをもとに計算して書き込み（Write）、T2も同様に書き込む。結果として、T2の書き込みがT1の書き込みを上書きしてしまい、T1の更新内容が完全に失われる（Lost）現象。

AさんとBさんが同時にスニーカーの在庫（残り10個）を確認しました。「よし、買えるぞ」と、Aさんが「10 - 1 = 9」に更新しました。同時にBさんも、自分が最初に見た「10個」という数字をもとに「10 - 1 = 9」に更新しました。 2個売れたのだから本当は「8個」にならなければいけないのに、結果は「9個」になり、1個分の売上が消滅（ロスト）してしまいます。

ここで言う"アプリ"とは、データベースの操作を制御する(=このデータベースを利用して実行されるプログラム)アプリケーションソフトウェアのことです。

PostgreSQLのデフォルト設定では、Lost Updateも発生します。

順番に行っている場合は、stockの値を確認して、必要であれば 実験環境の準備 節まで戻ってテーブルをリセットしてください。

ステップ 1

Aさんがトランザクションを開始

BEGIN;

ステップ 2

Bさんがトランザクションを開始

BEGIN;

ステップ 3

Aさんが在庫を確認。結果は「10」

SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

ステップ 4

Bさんも在庫を確認。結果は「10」

SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

ステップ 5

Aさんがアプリ上で計算した「9」を直接書き込む（未コミット）

UPDATE inventory SET stock = 9 WHERE item_name = '限定スニーカー';

ステップ 6

Bさんもアプリ上で計算した「9」を直接書き込む（未コミット）。フリーズして待つ

UPDATE inventory SET stock = 9 WHERE item_name = '限定スニーカー';

ステップ 7

Aさんが確定。Bのフリーズが解ける

COMMIT;

ステップ 8

Bさんが確定。（Aさんが書いた9の上に、Bさんがさらに9を上書きしてしまう）

COMMIT;

ステップ 9

結果は「9」！ Aさんが買った事実が完全に消滅（Lost）した！

SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

同じような現象として、Cursor Lost Update(カーソルによる更新の喪失)があります。プログラムからデータベースを操作する際、「カーソル（Cursor）」という1行ずつデータを処理する仕組みを使った時に発生する Lost Update のことです。本質的な発生メカニズムは通常の Lost Update と同じです。

実験6: Read Skew

データxとyに一貫性の制約（例：xとyの合計が常に一定など）があるとする。トランザクションT1がxを読み取る。次にT2がxとyの両方を更新し、コミットする。その後、T1がyを読み取る。結果として、T1は「更新前のx」と「更新後のy」を読んでしまい、一貫性のない状態（Skew：偏り・歪み）を観測してしまう現象。

「Tシャツ（10着）」と「スニーカー（10足）」の在庫があり、店長が「現在庫の合計数」を集計しようとしています。店長（Aさん）がまずTシャツの在庫を「10」とメモしました。その直後、BさんがTシャツとスニーカーを1つずつセットで購入（Tシャツ9、スニーカー9に変更）しました。その後、店長がスニーカーの在庫を見ると「9」になっています。 店長は「10 + 9 = 19個」と集計してしまい、本来存在しないはずの合計数（偏ったデータ）を観測してしまいます。

Read Skewは、特に複数のデータ項目間に一貫性の制約がある場合に問題になります。例えば、銀行口座の残高と取引履歴のようなケースです。

順番に行っている場合は、stockの値を確認して、必要であれば 実験環境の準備 節まで戻ってテーブルをリセットしてください。

ステップ 1

店長(Aさん)が集計処理を開始

BEGIN;

ステップ 2

店長がTシャツの在庫を確認。結果は「10」（メモ帳に10と記録する）

SELECT stock FROM inventory WHERE item_name = '限定Tシャツ';

ステップ 3

客(Bさん)が購入処理を開始

BEGIN;

ステップ 4

客がセット購入のため、Tシャツの在庫を1減らす（9に更新）

UPDATE inventory SET stock = stock - 1 WHERE item_name = '限定Tシャツ';

ステップ 5

客がスニーカーの在庫も1減らす（9に更新）

UPDATE inventory SET stock = stock - 1 WHERE item_name = '限定スニーカー';

ステップ 6

客の購入が確定（DB上は正しく両方とも9になる）

COMMIT;

ステップ 7

店長が次にスニーカーの在庫を確認。結果は「9」！ 店長は「Tシャツ10 ＋ スニーカー9 ＝ 19個」という、絶対にあり得ない合計数を観測してしまう。

SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

ステップ 8

店長が集計処理を終了

COMMIT;

実験7: Write Skew

データxとyに「x + y > 0（どちらかは必ず正）」などの制約があるとする。T1とT2が同時にxとyを読む。T1はyが正であることを見てxを0に更新する。同時にT2はxが正であることを見てyを0に更新する。お互いの更新は競合しない（別の行を更新している）ため、両方ともコミットに成功してしまうが、結果として「x=0かつy=0」となり、制約が破綻する現象。

オンラインストアのルールで「Tシャツかスニーカー、どちらか1種類は必ず在庫を残して見栄えを保つ（両方ゼロにはしない）」という制約があるとします（現在どちらも10個）。 Aさんがスニーカーを0個にする処理を走らせ、同時にBさんがTシャツを0個にする処理を走らせました。お互い、処理の前に「相手の商品の在庫が残っているか」を確認します。同時に確認したため、どちらも「相手の在庫があるから、自分はゼロにしてもルール違反にならない！」と判断し、別々の商品の在庫をゼロに更新してしまいます。 結果、見事に両方の在庫がゼロになり、ルールが崩壊します。

ここで、「データベース側に最初から(例えば)『スニーカーの在庫 ＋ Tシャツの在庫 > 0』という制約をつけておけばいいのでは？」と疑問に思うかもしれません。

実は、PostgreSQLなどのリレーショナルデータベースにおける CHECK 制約は、基本的に「1つの行の中（単一レコード）」でしか判定できません（例：CHECK (stock >= 0) など）。今回のような複数行にまたがる制約をテーブルの機能だけで厳密に守らせることは、通常の機能では非常に困難です（複雑なトリガーなどを駆使する必要があります）。

そのため、実際のシステム開発では、このような複雑なビジネスルールはアプリケーション側でチェックします。 ここで言う「アプリ」とは、データベースを利用して処理を実行するプログラム（Web開発などで書くバックエンドのAPIサーバーなど）のことです。

今回のシナリオでは、アプリの内部に以下のような処理（IF文）が書かれていると想像してください。

// アプリ側の処理イメージ
// 1. まず現在の在庫を確認 (実験手順の SELECT に相当)
const sneaker = db.query("SELECT stock FROM inventory WHERE item_name = '限定スニーカー'");
const tshirt = db.query("SELECT stock FROM inventory WHERE item_name = '限定Tシャツ'");

// 2. 制約（ルール）を満たしているかチェック
if (sneaker.stock + tshirt.stock > 0) {
    // ルールクリア！在庫を0に更新する (実験手順の UPDATE に相当)
    db.query("UPDATE ..."); 
} else {
    throw new Error("両方をゼロにすることはできません！");
}

順番に行っている場合は、stockの値を確認して、必要であれば 実験環境の準備 節まで戻ってテーブルをリセットしてください。

ステップ 1

Aさんが少し厳しいレベルでトランザクションを開始

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

ステップ 2

BEGIN;

ステップ 3

Bさんも同じレベルでトランザクションを開始

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

ステップ 4

BEGIN;

ステップ 5

Aさんが両方の在庫を確認。「Tシャツが残っているから、スニーカーを0にしてもルール違反にならない」とアプリが判断

SELECT stock FROM inventory WHERE item_name IN ('限定スニーカー', '限定Tシャツ');

ステップ 6

Bさんも両方の在庫を確認。「スニーカーが残っているから、Tシャツを0にしてもルール違反にならない」とアプリが判断

SELECT stock FROM inventory WHERE item_name IN ('限定スニーカー', '限定Tシャツ');

ステップ 7

Aさんがスニーカーを0に更新（まだコミットしていない）

UPDATE inventory SET stock = 0 WHERE item_name = '限定スニーカー';

ステップ 8

BさんがTシャツを0に更新（まだコミットしていない）。更新する行が違うのでフリーズせず通る！

UPDATE inventory SET stock = 0 WHERE item_name = '限定Tシャツ';

ステップ 9

Aさんがトランザクションを確定

COMMIT;

ステップ 10

Bさんもトランザクションを確定。ルール違反の状態が完成！

COMMIT;

4つの分離レベル

ここまで数々の異常を発生させてきました。では、データベース設計者はこれらをどうやって防げばよいのでしょうか？

その答えが、ANSI SQL標準で定義された4つの分離レベルです。

各分離レベルとPostgreSQLの挙動

1. READ UNCOMMITTED（未コミット読取）

最も制限が緩く、他人のコミット前のデータ（Dirty Read）が見えてしまう危険なレベル。

実はPostgreSQLでは、このレベルを指定しても内部的には②の READ COMMITTED と全く同じ挙動になります（後述の表における※1）。MVCC（多版型同時実行制御）という仕組みを使っているため、構造上Dirty Readを起こすことができないのです。

2. READ COMMITTED（コミット済読取）

コミットされたデータしか読まない。

PostgreSQLのデフォルト設定です。Dirty Readは防げますが、「実験5」で体験した Lost Update（売上の消滅） などの致命的なバグはスルーしてしまいます。

3. REPEATABLE READ（反復可能読取）

トランザクション中に同じ行を何度読んでも、必ず同じ値が返ってくることを保証する。

トランザクションを開始した瞬間のスナップショットを見続ける仕組みです。

4. SERIALIZABLE（直列化可能）

複数の並行処理を、完全に「1列に並んで順番に処理（直列実行）」したのと同じ結果になることを保証する最高レベル。

「実験7」で猛威を振るった Write Skew（書き込みの偏り） を防げる唯一のレベルです。PostgreSQLは背後でデータの依存関係（読み書きのグラフ）を監視しており、矛盾が起きそうになるとコミット時にエラーを出してシステムを守ります。

PostgreSQLの内部実装はこのような標準規格が「発生してもよい」としているバグすら防いでいます(実際Dirty Readなどは起こりませんでしたね)。

PostgreSQLにおいて各分離レベルが、どれくらいの防御力があるのかについて表にまとめたものが以下です。

※2の凄さ: ANSI規格では「Phantom（幻の行の追加）は発生してもよい」とされていますが、PostgreSQLのスナップショットは優秀なのでPhantomまで完全に防ぎます。

※3の挙動: Lost Updateを起こそうとすると、後から更新しようとしたトランザクションに対して ERROR: could not serialize access due to concurrent update というエラーを発生させ、強制終了（ロールバック）させることでデータを守ります。

分離レベルの選択

すべての不整合（アノマリー）を防ぐために、常にデータベース全体を最高レベルの SERIALIZABLE に設定すれば良いかというと、実運用上はそうではありません。SERIALIZABLE や REPEATABLE READ は、競合を検知するとトランザクション自体をアボート（強制終了）させて整合性を守るため、システム全体の並行処理性能が大きく低下する原因となります。

では、Lost Update などのバグを防ぐために、常にデータベース全体を SERIALIZABLE にしておけば良いのでしょうか？
そんなことをしていると、少しでも競合が起きるたびにPostgreSQLがバンバンとエラー（could not serialize access...）を出して処理を止めてしまいます。結果として、Webアプリ側で「エラーが出たら最初からやり直す（リトライ）」という複雑なプログラムを書く必要があり、システムの動作も重くなってしまいます。

システムの要件によっては、厳密な整合性よりもスループット（単位時間あたりの処理量）が最優先され、低水準の分離レベルによるアノマリーが許容される場合があります。

大体、別に許容できるエラー（不整合）というのもあります。
例えば、YouTubeの再生回数やSNSの「いいね」の数です。1万人が一斉にボタンを押したとき、Lost Updateが発生して実際の「いいね」が9998回になってしまったとしても、誰も大きな問題にはしません。それよりも「いちいちエラー画面を出さずに、とにかく最高速度で処理を受け付ける」ことの方が圧倒的に重要だからです。

そのため、実際のシステム開発では、アプリケーションの要件や許容できるリスクに応じて、適切な分離レベルを選択し、SQLの書き方を工夫することが重要になります。実務でよく使われる2つのアプローチを紹介します。

楽観的並行性制御（楽観的ロック）

「トランザクション同士の競合はめったに起きないだろう」という楽観的な前提に基づき、事前のロックをかけずに処理を進めます。そして、コミット時に競合を検知した場合は処理をロールバックし、アプリケーション側でリトライを行います。一時的に分離レベルを引き上げる手法などがこれに該当します。

基本はデフォルト（READ COMMITTED）のままにしておき、集計処理や在庫の最終更新など「絶対に途中でデータが変わってほしくない時」だけ、一時的に分離レベルを REPEATABLE READ や SERIALIZABLE に引き上げる方法です。
（※Web開発の現場では version という数値を管理する専用カラムを作ってアプリ側で弾く手法も人気ですが、ここでは分離レベルによる防衛策を紹介します）

-- 処理の最初で、このトランザクションだけ分離レベルを引き上げる
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 現在の在庫を確認
SELECT stock FROM inventory WHERE item_name = '限定スニーカー';

-- アプリ上で計算後、更新を実行
UPDATE inventory SET stock = 9 WHERE item_name = '限定スニーカー';

-- もしこの間に他人の更新と衝突していれば、COMMIT時にPostgreSQLがエラーを返す
-- ERROR: could not serialize access due to concurrent update
COMMIT;

悲観的並行性制御（悲観的ロック / 排他ロック）

「トランザクション同士の競合は頻繁に起きるだろう」という悲観的な前提に基づき、データを読み取る時点で明示的に排他ロック（Exclusive Lock）を取得します。他のトランザクションは、ロックが解放されるまで待機（ブロック）されます。

分離レベルはデフォルトのまま、SQLの構文を使って「今からこの行を更新するから、私が終わるまで他の人は触らないで待ってて！」とデータベースに直接宣言する方法です。
Lost Update（売上の消滅）を防ぐための実務テクニックとして、最もよく使われる強力な手法です。具体的には、SELECT 文の末尾に FOR UPDATE をつけます。

-- === Aさんの処理 ===
BEGIN;
-- 単なる SELECT ではなく FOR UPDATE をつけることで「行ロック」を獲得！
SELECT stock FROM inventory WHERE item_name = '限定スニーカー' FOR UPDATE;

-- === Bさんの処理（Aさんがコミットするまで進めなくなる） ===
BEGIN;
-- Bさんも在庫を見ようとしますが、Aさんが FOR UPDATE で掴んでいるため、
-- ここで画面がピタッとフリーズして「待ち（待機状態）」になります。
SELECT stock FROM inventory WHERE item_name = '限定スニーカー' FOR UPDATE;

-- === Aさんの処理 ===
-- Aさんは安全に計算し、更新できる
UPDATE inventory SET stock = 9 WHERE item_name = '限定スニーカー';
-- Aさんがコミットした瞬間、ロックが解除される！
COMMIT; 

-- === Bさんの処理 ===
-- Aさんのコミットによりフリーズが解け、Bさんの SELECT がようやく実行されます。
-- ★超重要：このときBさんが取得する在庫数は、Aさんが更新した後の「9」になります！
-- そのため、Bさんは正しく「9 - 1 = 8」の計算を行うことができ、バグを防げます。
UPDATE inventory SET stock = 8 WHERE item_name = '限定スニーカー';
COMMIT;

問題

ここまで学んだ「同時実行制御」と「隔離レベル」に関する知識を確認しましょう。理論的な定義から、実務でのPostgreSQLの挙動まで、全10問を出題します。答えを頭の中に思い浮かべてから、「解答を見る」をクリックしてください。

演習

実際に手を動かしてロック制御のSQLを書く演習（5問）と、本記事全体の内容を問う総合問題（4問）を出題します。

まずは、演習用の少し複雑なテーブル（コンサートの座席予約システムと、銀行口座システム）を作成しましょう。以下のSQLを実行して準備してください。

-- 演習用テーブルの準備
DROP TABLE IF EXISTS concert_seats;
DROP TABLE IF EXISTS bank_accounts;

-- ① コンサート座席テーブル
CREATE TABLE concert_seats (
    id SERIAL PRIMARY KEY,
    seat_num VARCHAR(10) UNIQUE NOT NULL,
    status VARCHAR(20) NOT NULL -- 'available' (空席) または 'reserved' (予約済)
);
INSERT INTO concert_seats (seat_num, status) VALUES
('A-1', 'available'), ('A-2', 'available'), ('A-3', 'available');

-- ② 銀行口座テーブル
CREATE TABLE bank_accounts (
    id SERIAL PRIMARY KEY,
    user_name VARCHAR(50) NOT NULL,
    balance INT NOT NULL
);
INSERT INTO bank_accounts (user_name, balance) VALUES
('Alice', 10000), ('Bob', 10000);

-- ③ メタバースホテル予約システム用テーブル
CREATE TABLE users ( user_id SERIAL PRIMARY KEY, coins INT NOT NULL );
CREATE TABLE rooms ( room_id INT PRIMARY KEY, status VARCHAR(20), price INT );
CREATE TABLE bookings ( id SERIAL PRIMARY KEY, user_id INT, room_id INT );

INSERT INTO users (user_id, coins) VALUES (1, 10000);
INSERT INTO rooms (room_id, status, price) VALUES (101, 'available', 8000);

準備ができたら、以下の問題に挑戦してください。解答は「解答を見る」をクリックすると開きます。

SELECT * FROM concert_seats WHERE seat_num = 'A-1' FOR UPDATE;

SELECT * FROM concert_seats WHERE status = 'available' LIMIT 1 FOR UPDATE SKIP LOCKED;

SELECT * FROM bank_accounts WHERE id IN (1, 2) FOR UPDATE;

BEGIN;

-- 1. 競合を防ぐため、関係する行を全てロックして最新の状態を取得
SELECT * FROM rooms WHERE room_id = 101 FOR UPDATE;
SELECT * FROM users WHERE user_id = 1 FOR UPDATE;

-- (ここでアプリケーション側が「空室か？」「残高は足りているか？」をIF文でチェックします)

-- 2. 部屋を予約済みに更新
UPDATE rooms SET status = 'booked' WHERE room_id = 101;

-- 3. ユーザーの残高を減らす
UPDATE users SET coins = coins - 8000 WHERE user_id = 1;

-- 4. 予約履歴を作成
INSERT INTO bookings (user_id, room_id) VALUES (1, 101);

COMMIT;

SELECT * FROM players 
WHERE id IN (10, 20, 30) 
ORDER BY id 
FOR UPDATE;

本コンテンツの作成時間：約20時間

最終更新: 2026-02-23 22:40