開発現場で言われる『楽観ロック』とは？ 同時編集でデータが壊れるのを防ぐ仕組みをコード付きで解説

【楽観ロックの流れ】

1. Aさんが商品を開く（バージョン: 1）
2. Bさんも同じ商品を開く（バージョン: 1）
3. Aさんが保存 → バージョン1のまま？ → YES → 保存成功（バージョン: 2に更新）
4. Bさんが保存 → バージョン1のまま？ → NO（もう2になってる）→ 保存拒否！
   → 「他の人が更新しています。最新データを確認してください」

-- PostgreSQL
CREATE TABLE products (
  id         SERIAL PRIMARY KEY,
  name       VARCHAR(255) NOT NULL,
  price      INTEGER NOT NULL,
  version    INTEGER NOT NULL DEFAULT 1,  -- ← これが楽観ロック用
  updated_at TIMESTAMP DEFAULT NOW()
);

-- 楽観ロック付きのUPDATE
UPDATE products
SET
  name = '新しい商品名',
  price = 2000,
  version = version + 1,      -- バージョンをインクリメント
  updated_at = NOW()
WHERE
  id = 1
  AND version = 3;             -- 読み取り時のバージョンと一致するか確認

-- 影響行数が0 → 誰かが先に更新した → 競合エラーとして扱う

// 楽観ロック付きの更新処理
async function updateProduct(
  id: number,
  data: { name: string; price: number },
  currentVersion: number  // フロントから受け取った読み取り時のバージョン
) {
  const result = await db.query(
    `UPDATE products
     SET name = $1, price = $2, version = version + 1, updated_at = NOW()
     WHERE id = $3 AND version = $4`,
    [data.name, data.price, id, currentVersion]
  );

  // 影響行数が0 → 競合発生
  if (result.rowCount === 0) {
    throw new Error('他のユーザーがこのデータを更新しました。最新データを確認してください。');
  }

  return { success: true };
}

// フロントからのリクエスト例
const response = await fetch(`/api/products/${id}`, {
  method: 'PUT',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    name: '新しい商品名',
    price: 2000,
    version: 3,  // 取得時のバージョンをそのまま送る
  }),
});

if (!response.ok) {
  const error = await response.json();
  // 「他のユーザーが更新しました」のエラーメッセージを表示
  alert(error.message);
  // 最新データを再取得してフォームを更新
  await refetchProduct();
}

Q1. 同時に同じデータを編集する頻度は？
  → 低い（管理画面、CMS等）→ 楽観ロック
  → 高い ↓

Q2. 競合時に「やり直し」で許容できる？
  → YES → 楽観ロック
  → NO ↓

Q3. データの整合性が絶対に壊れてはいけない？
  → YES（在庫引き当て、残高更新）→ 悲観ロック
  → NO → 楽観ロック