はじめに
PRレビューで「これ、レースコンディションになりますね」と言われた。
正直、初めて聞いた言葉だった。調べてみると、自分のコードのあちこちに潜んでいた。テストは全部通っていたのに。
この記事では、レースコンディションを知らなかった自分が、レビューで指摘されて理解するまでに学んだことをまとめる。
この記事でわかること：
- レースコンディションとは何か（一言で）
- なぜ開発中に見つからないのか
- 危ない3つのパターンと、それぞれの防ぎ方
- Go + GORM + PostgreSQL での実例
想定読者：
- レースコンディションという言葉を初めて聞いた人
- Web APIを書いていて「同時アクセス」をあまり意識したことがない人
- 言語は問わない（実例セクションのみ Go）
レースコンディションとは
2つの処理が同時に同じデータを触ると、結果が壊れること。
日常の例え
銀行口座に10万円入っている。あなたとパートナーが同時にATMで3万円引き出す。
あなた パートナー
──────────────────────────────────────────
10:00:00 残高を確認 → 10万円
10:00:01 残高を確認 → 10万円
10:00:02 10万 - 3万 = 7万で更新
10:00:03 10万 - 3万 = 7万で更新
──────────────────────────────────────────
結果: 残高 7万円（本来は4万円のはず！）
6万円引き出したのに、3万円しか減っていない。
ポイント: 1人ずつやれば正しい結果になる。「同時」が問題を起こす。
なぜ開発中に見つからないのか
- 開発環境 = 自分1人がポチポチ触る世界
- 本番 = 100人が同時にリクエストを送る世界
100回中99回は「たまたま」タイミングがずれて正しく動く。1回だけ壊れる。
だからテストを書いても見つからない。レビュアーが「これ同時に来たらどうなる？」と頭の中でシミュレーションして初めて気づく。
3つの「危ないパターン」
ここからは、自分が実際にレビューで指摘を受けたリアルタイム通話（ハドル）機能を例に説明する。仕組みはシンプルで、登場人物は4つだけ：
- セッション: 通話部屋。目標ごとに1つ作られる
- 参加者: 誰が通話中かを表すレコード。入室・退出を記録する
- Heartbeat: 「まだ通話中だよ」と定期的に送る生存確認
- クリーンアップ: 一定時間Heartbeatがない参加者を自動退出させるバッチ処理
この4つの処理が同時に走ることで、問題が起きた。
パターン① 上書き: 読んで → 変えて → 全部戻す
HeartbeatとLeave（退出）が同時に走るケース。
Heartbeat Leave
──────────────────────────────────────────────────────
10:05:00 DBから参加者を取得
→ { heartbeat: 10:00:00,
left_at: NULL }
10:05:01 DBから参加者を取得
→ { heartbeat: 10:00:00,
left_at: NULL }
10:05:02 left_at = 10:05:02 にセット
Save() → DB反映 ✅
10:05:03 heartbeat = 10:05:03 に更新
Save() → DB反映
→ { heartbeat: 10:05:03,
left_at: NULL } ← 退出が消えた！
──────────────────────────────────────────────────────
Heartbeat は heartbeat だけ変えたかった。でも Save() は全カラムを上書きするから、10:05:00 時点で読んだ古い left_at: NULL まで書き戻してしまう。
退出したはずなのに、退出していないことになる。
このパターンの本質: 自分が変えたいカラム以外も巻き添えで上書きする
パターン② すれ違い: 確認して → 判断して → 実行する
クリーンアップとJoin（入室）が同時に走るケース。
クリーンアップ join（suzukiが入室）
──────────────────────────────────────────────────────
10:30:00 tanakaを放置扱いで退出させる
10:30:01 残り参加者を数える → 0人
10:30:02 suzukiを参加者として追加 ✅
10:30:03 0人だったのでセッション終了！
10:30:04 suzuki「入れたのに
セッション終了してる…？」
──────────────────────────────────────────────────────
クリーンアップは10:30:01の時点で正しい判断をしている。「0人だから終了」は論理的に正しい。
でも実行する10:30:03の時点では、もう1人いる。
このパターンの本質: 確認した事実が、実行する時にはもう変わっている
パターン③ 重複: 「ないから作る」を2人同時にやる
2人が同時にJoinし、どちらも「セッションがない」と判断するケース。
tanaka suzuki
──────────────────────────────────────────────────────
10:00:00 セッションある？ → ない
10:00:01 セッションある？ → ない
10:00:02 ないので作る → room-A ✅
10:00:03 ないので作る → room-B ✅
──────────────────────────────────────────────────────
結果: 同じ通話なのにセッションが2つできた
パターン②と共通するのは「確認」と「実行」の間に隙間があること。ただし結果が逆方向になる：
- ②すれ違い → まだあるのに消してしまう
- ③重複 → 1つでいいのに2つできてしまう
対策もそれぞれ違うので、分けて考える価値がある。
どう防ぐ？ 3つのアプローチ
防ぎ方① 必要な部分だけ変える（パターン①に効く）
全部上書きしなければいい。
-- ❌ 全部上書き → 他の変更を巻き込む
UPDATE participants
SET heartbeat = '10:05:03', left_at = NULL, name = 'tanaka', ...
WHERE id = 'tanaka';
-- ✅ 変えたいカラムだけ
UPDATE participants
SET heartbeat = '10:05:03'
WHERE id = 'tanaka' AND left_at IS NULL;
AND left_at IS NULL がポイント。もう退出済みなら更新が空振りする。「自分が触っていいのは、まだ退出してないレコードだけ」というルールをSQLレベルで強制できる。
防ぎ方② 順番待ちさせる（パターン②に効く）
隙間が問題なら、隙間に割り込ませない。
レストランの例：
❌ 隙間あり:
あなた「空いてる？」→ 店員「1席あります」
友達 「空いてる？」→ 店員「1席あります」
→ 2人とも予約できてしまう
✅ 順番待ち（ロック）:
あなた「空いてる？」→ 店員「確保しますね」→ 予約完了
友達 「空いてる？」→ 店員「埋まりました」
「確認」から「実行」まで他の人を待たせる。これがロック。
PostgreSQLでは Advisory Lock で「この部屋に関する操作は1人ずつ」を強制できる:
クリーンアップ join（suzuki）
──────────────────────────────────────────────────────
10:30:00 🔒 room-Aのロック取得
10:30:01 参加者を数える → 0人
10:30:02 🔒 ロック取得したい → 待ち ⏳
10:30:03 0人なのでセッション終了
🔓 ロック解放
10:30:04 🔒 取得できた！
セッション確認 → 終了済み
→ 新しいセッションを作る ✅
──────────────────────────────────────────────────────
防ぎ方③ 物理的に弾く（パターン③に効く）
DBのUNIQUE制約で「2つ作る」を物理的に不可能にする。
-- 「アクティブなセッションは1つの目標につき1つだけ」
CREATE UNIQUE INDEX idx_active_session
ON sessions (objective_id)
WHERE status = 'active';
2人目が作ろうとした瞬間、DBが弾く:
tanaka suzuki
──────────────────────────────────────────────────────
10:00:02 INSERT → ✅ 成功
10:00:03 INSERT → ❌ UNIQUE違反！
→ 既存のセッションを取得して参加
──────────────────────────────────────────────────────
アプリのコードではなく、DBが「2つ存在させない」ことを保証する。
なぜパターン②と③で対策が違うのか
どちらも「確認と実行の間に隙間がある」のが原因だが、性質が違う：
| パターン② すれ違い | パターン③ 重複 | |
|---|---|---|
| 結果 | あるのに消す | ないのに2つ作る |
| 起きる場面 | 複数の処理が1つのリソースを操作 | 複数のリクエストが同じリソースを作成 |
| 最適な対策 | ロック（処理を直列化） | DB制約（物理的に弾く） |
ロックは「操作の順番」を保証する。DB制約は「結果の一意性」を保証する。守りたいものが違うから、対策も違う。
対応表
| パターン | 問題 | 防ぎ方 |
|---|---|---|
| ① 上書き | 変更が消える | 必要なカラムだけ更新する |
| ② すれ違い | 判断が嘘になる | ロックで順番待ちさせる |
| ③ 重複 | 2つできてしまう | DB制約で物理的に弾く |
自分のコードで起きてないかチェックする視点
以下に当てはまるコードがあったら、レースコンディションを疑ってみてほしい。
-
ORMの
Save()やupdate()でレコード全体を上書きしていないか？ - 読み取り → 判定 → 書き込みの間に、別の処理が割り込む余地はないか？
- 「なければ作る」パターンで、同時実行時に2つできないか？
- 「これ、同時に2人がやったらどうなる？」とシナリオを想像してみる
実例: Go + GORM + PostgreSQL
ここからは実際のコードで見る。Go に馴染みがなくても、コメントと SQL を追えば雰囲気はわかるはず。
パターン①の修正: Save() → Targeted UPDATE
Before（危険）:
// heartbeat.go — Save()は全カラム更新
func (uc *heartbeatUseCase) Execute(ctx context.Context, req HeartbeatReq) error {
participant, err := uc.participantRepo.FindActiveByMemberID(ctx, memberID)
if err != nil {
return err
}
participant.UpdateHeartbeat() // heartbeat だけ変えたつもり
return uc.participantRepo.Save(ctx, participant) // ← 全カラム上書き！
}
Save() が発行する SQL:
UPDATE huddle_participants
SET last_heartbeat_at = '10:05:03',
left_at = NULL, -- ← 触るつもりないのに含まれる
... -- ← 全カラム
WHERE id = 'xxx';
After（安全）:
// heartbeat.go — 変えたいカラムだけ更新
func (uc *heartbeatUseCase) Execute(ctx context.Context, req HeartbeatReq) error {
participant, err := uc.participantRepo.FindActiveByMemberID(ctx, memberID)
if err != nil {
return err
}
if participant == nil {
return nil // 参加していない → 何もしない
}
// ピンポイントUPDATE（last_heartbeat_at のみ、left_at IS NULL ガード付き）
return uc.participantRepo.UpdateHeartbeat(ctx, participant.ID())
}
リポジトリの実装:
func (r *participantRepository) UpdateHeartbeat(ctx context.Context, id string) error {
result := db.Model(&HuddleParticipant{}).
Where("id = ? AND left_at IS NULL", id).
Updates(map[string]interface{}{
"last_heartbeat_at": time.Now(),
"updated_at": time.Now(),
})
return result.Error
}
発行される SQL:
UPDATE huddle_participants
SET last_heartbeat_at = NOW(), updated_at = NOW()
WHERE id = 'xxx' AND left_at IS NULL;
-- left_at を触らない。退出済みなら空振りする。
パターン②の修正: Advisory Lock で直列化
Before（危険）:
// cleanup.go — ロックなし
func (uc *cleanupUseCase) cleanupStaleParticipants(ctx context.Context) error {
// stale な参加者を退出させる
for _, p := range staleParticipants {
p.Leave()
uc.participantRepo.Save(ctx, p)
}
// 残り参加者を数える
count, _ := uc.participantRepo.CountActiveBySessionID(ctx, sessionID)
// ↑ ここで 0 を確認
// ← この隙間で join が割り込む可能性 →
if count == 0 {
session.End() // ← 実はもう1人いるのに終了してしまう
uc.sessionRepo.Save(ctx, session)
}
return nil
}
After（安全）:
// cleanup.go — Advisory Lock で排他制御
func (uc *cleanupUseCase) cleanupStaleSession(
ctx context.Context,
session *huddle.Session,
staleParticipants []*huddle.Participant,
) (bool, error) {
var ended bool
// 🔒 同一セッション（目標単位）のロックを取得
// join / leave / cleanup すべてこのキーで直列化される
err := uc.txManager.WithAdvisoryLock(
ctx,
"huddle:session:"+session.ObjectiveID(),
func(txCtx context.Context) error {
// ロック内なので、他の処理は割り込めない
for _, p := range staleParticipants {
if err := p.Leave(); err != nil {
continue
}
uc.participantRepo.Save(txCtx, p)
}
count, _ := uc.participantRepo.CountActiveBySessionID(txCtx, session.ID())
if count > 0 {
return nil // まだ参加者がいる
}
session.End()
uc.sessionRepo.Save(txCtx, session)
ended = true
return nil
},
)
return ended, err
}
join 側も同じロックキーを使う:
// join.go — 同じキーでロック
err := uc.txManager.WithAdvisoryLock(
ctx,
"huddle:session:"+objectiveID, // ← 同じキー
func(txCtx context.Context) error {
// セッション取得 or 作成 + 参加者追加
// cleanup と同時に実行されることはない
},
)
パターン③の修正: UNIQUE制約 + フォールバック
マイグレーション:
-- アクティブなセッションは目標ごとに1つだけ
CREATE UNIQUE INDEX idx_huddle_sessions_active_objective
ON huddle_sessions (objective_id)
WHERE ended_at IS NULL;
アプリ側（UNIQUE違反時のフォールバック）:
// join.go — UNIQUE違反を検知して既存セッションに合流
if saveErr := uc.sessionRepo.Save(txCtx, newSession); saveErr != nil {
if domainErrors.IsDuplicate(saveErr) {
// 別のリクエストが先にセッションを作った
// → 既存セッションを取得して、そちらに参加する
existing, _ := uc.sessionRepo.FindActiveByObjectiveID(txCtx, objectiveID)
if existing != nil {
session = existing
}
}
}
DBが弾く → アプリがリカバリする。この2段構えで、重複は絶対に起きない。
まとめ
- レースコンディション = 2つの処理が同時に同じデータを触って結果が壊れること
- 開発中に見つからない。本番の同時アクセスで初めて起きる
- 危ないパターンは3つ: 上書き、すれ違い、重複
- 防ぎ方も3つ: 必要な部分だけ更新、ロックで直列化、DB制約で物理的に弾く
- 「これ、同時に2人がやったらどうなる？」と考える習慣が一番大事