このパターンは「TOCTOU（Time-Of-Check to Time-Of-Use）」と呼ばれ、チェックした時間と実際にその結果を使う時間の間に生まれるすべての不具合の縁名です。Webアプリでは、「クーポンが未使用か確認→使用済みに備付け」「残高が十分か確認→引き出しを実行」「在庫があるか確認→注文を確定」など、「確認してから実行する」最も基本的な処理パターンの中に潜んでいます。

TOCTOUは新しい概念ではなく、CWE（Common Weakness Enumeration）でも&#x300CCWE-367」として古くから分類されている、ソフトウェア工学の基本的な欠陥パターンの一つです。ファイルシステムの操作やOSのプロセス管理など、複数の処理が同時に走る環境では何十年も前から知られています。Webアプリケーションが普及し、1つのサーバーが同時に何千ものリクエストを処理するようになったことで、この古典的な欠陥が新しい形で表面化しています。

ほとんどのWebアプリの処理は、極簡化すると次の3段階で成り立っています。①チェック（現在の状態を読む）②待機（DB問い合わせや外部API呼び出しなど&#x306EI/O待ち）③書き込み（状態を更新する）。②の待機は何もしていないわけではなく、データベースやキャッシュシステムとの通信、ログ記録など、現実には必ず何厘秒かの時間がかかります。

レースコンディションの厳しい点は、1件ずつ順番にオク・テストする限り完全に正常に動く点です。QAエンジニアが手動で1回ずつテストしても、コードレビゥーで処理の流れを1本ずつ読んでも、どちらも問題に気づきません。問題が表面化するのは、本番環境で大量のユーザーが同時にアクセスし、たまたま雕のタイミングで複数のリクエストが重なった時だけです。

注文機能も同じ構造的な雕を持ちやすい処理の代表例です。「在庫数を確認してから注文を確定させる」という流れは、残高やクーポンの例と完全に同じ構造をしています。在庫1個に対して注文が1件だけ来るという通常時の動作確認だけでは、この問題に気づくことはできません。

架空の「やさいポイント」システムには、1回の引き出しで300ポイントを減算する機能があります。初期残高&#x306F1000ポイントです。内部の処理は「残高を確認（チェック）→少し待機（処理遲延を再現）→残高を減算（書き込み）」という手順で動いています。

• アトミック操作：DBのUPDATE accounts SET balance=balance-? WHERE id=? AND balance≥?のように、チェックと書き込みを1つの不可分な命令にする
• ロック（悲観的排他制御）：SELECT ... FOR UPDATEで行をロックし、他のトランザクションが同じ行を同時に書き書き込めないようにする
• 冪等性キー：一意なリクエストID（Idempotency Key）を発行し、同じIDのリクエストは2回上処理しない（決済APIの標準対策）
• トランザクション分離レベル：SERIALIZABLE等の高い分離レベルを使い、並行実行時に矛盾する更新をDB自体に拒否させる

データベースが行単位の更新を内部で必ず順番に実行するという仕組みを利用すれば、アプリケーション側で明示的にロックを書かなくても安全になります。重要なのは「チェックと書き込みを別の文として書かない」という原則であり、そのための手段はDBや言語エコシステムによっていくつも用意されています。

第5話では、チェックと書き込みの間の雕を突くレースコンディションを体験しました。次回はクラウドIAM権限昇格という、個別には無害な権限の積み重ねが特権昇格につながる構造を扱います。