注文だけが残った夜 (原子性)

事故 — 注文だけが残った夜

ある EC サイトの受注は、受注ボタンが押されるたびに 2 段階の Excel マクロで処理されていた。 まず注文シートに 1 行追加し、次に商品シートの在庫を 1 減らす。ある夜、注文シートに書き込んだ直後にネットワークが瞬断してマクロが止まった。翌朝スタッフが気付いた時には、 注文は残ったまま 商品の在庫が減らされていない 状態だった。

これが単発の 1 件で終わればまだ被害は小さい。実際、冒頭の「壊れた Excel」でも P-042 座布団は 1 日で 5 件売れたはずなのに在庫はまだ 12 のまま — 初日は数個の差にすぎない。 しかしマクロは毎日何百件も実行され、同じ形の中断が週に数件のペースで起き続けた。数週間後、商品シートの在庫は実在庫より 20 個以上多い値 を示すようになっていた。

営業担当が「在庫あり」と表示された商品を客に売っても、倉庫には物理的に商品が無い。 出荷指示を受けた倉庫スタッフから何度も返品連絡が入り、顧客対応が破綻した。

原因 — Excel には「まとめて確定」の単位がない

Excel / Sheets には 「複数の変更を 1 つのトランザクションとして扱う」 仕組みがない。 マクロで擬似的に順番に実行しても、どこかで止まれば「片方だけ適用された中途半端な状態」が残る。 RDB ならこの時点で自動 ROLLBACK が走って両方戻せるが、Excel には ROLLBACK 相当の機能がない。 マクロがどこまで進んだかも、変更がまとめて COMMIT されたかどうかも、記録されない。

解決策 — トランザクション (BEGIN / COMMIT / ROLLBACK)

RDB では複数の SQL 文を BEGIN と COMMIT で挟む ことで、その間の全ての変更を「1 つの塊」として扱える。 途中でエラーが起きたら ROLLBACK で全て戻す。COMMIT する前の変更は誰にも見えず、COMMIT した瞬間にまとめて確定する。

BEGIN;
INSERT INTO orders (customer_id, product_id, qty)
  VALUES ('C-001', 'P-042', 1);
UPDATE products
  SET stock = stock - 1
  WHERE id = 'P-042';
COMMIT;

この BEGIN...COMMIT の間で通信が切れたりサーバがクラッシュしても、RDB は自動で ROLLBACK する。「注文は追加されたが在庫は減らない」中途半端な状態は構造的に発生しない。

境界事例と誤解

• オートコミットの罠: 多くのクライアントは既定でオートコミット (各文が独立トランザクション)。 複数文を原子的に扱いたい時は明示的に BEGIN しないと、片方だけ確定するリスクが残る。
• トランザクションの入れ子: SAVEPOINT で部分的な戻しは可能だが、 外側の BEGIN..COMMIT を跨いだ「片方コミット」はできない。
• 原子性は分離性を含意しない: 「途中で止まらない」と「他人の同時変更から守る」は別問題。 後者は次の 同時実行制御 で扱う。