「レースコンディション」という言葉を聞いたことがあるでしょうか。Webアプリケーションの脆弱性診断やセキュリティ事故の報告書に登場するこの用語は、日本語では「競合状態」とも訳され、現代のシステム開発で見落としやすい根本的な問題の一つです。

レースコンディション（Race Condition）とは、複数のプロセスやスレッドが同じ共有リソースに対してほぼ同時にアクセスするとき、処理の実行順序やタイミングによってプログラムの動作結果が変わってしまう問題のことです。「競争（Race）」の勝者によって結果が変わる——という意味でこの名がつきました。

レースコンディションは単なるバグに留まらず、悪意ある攻撃者に悪用されるセキュリティ脆弱性にもなります。ECサイトでの二重決済、銀行口座からの不正な二重引き出し、Linux カーネルの権限昇格（Dirty COW）など、実際の被害は多岐にわたります。本記事では、レースコンディションの仕組みからセキュリティリスク・対策まで、最新情報をもとに体系的に解説します。

レースコンディションとは？

レースコンディション（Race Condition）は、複数の処理が同一の共有リソース（変数・ファイル・データベースレコードなど）に対して同時並行でアクセスするとき、処理の実行順序によって結果が変わってしまう状態を指します。日本語では「競合状態」とも呼ばれます。

CWE（Common Weakness Enumeration：共通脆弱性タイプ一覧）では CWE-362「Concurrent Execution using Shared Resource with Improper Synchronization」として分類されており、ソフトウェアの脆弱性として広く認識されています。

レースコンディションの仕組み

レースコンディションがどのように起きるかを、銀行口座の残高更新という具体的な例で見てみましょう。

問題が起きる処理の流れ

Aさんの口座残高が10,000円で、ATM端末①と端末②から同時に5,000円の出金が行われるケースを考えます。

正常な処理では「①が5,000円引いて残高5,000円 → ②がさらに5,000円引こうとして残高不足エラー」となるはずです。しかし、レースコンディションが発生すると以下のようになります。

1. 端末①が残高10,000円を読み取る
2. 端末②も（①が書き戻す前に）残高10,000円を読み取る
3. 端末①が「10,000 – 5,000 = 5,000円」を計算して書き戻す
4. 端末②が「10,000 – 5,000 = 5,000円」を計算して書き戻す（①の更新を上書き）
5. 結果：10,000円から10,000円が引き出されたはずなのに残高が5,000円に

この「一方の更新が消える」問題をロストアップデート（更新の消失）と呼びます。一連の「読み込む→計算する→書き戻す」という操作が分割可能（不可分でない）なことが根本原因です。

レースコンディションの種類

レースコンディションは発生パターンによっていくつかの種類に分類されます。

ロストアップデート（更新の消失）

複数の処理が同じデータを読み取り、それぞれが計算した結果を書き戻す際に、一方の更新が消えてしまうケースです。在庫数・残高・カウンタなど数値データの更新で頻繁に発生します。

二重処理（ダブルサブミット）

同じリクエストが短時間に複数回送信または処理され、本来1回のみであるべき処理（決済・注文確定・ポイント付与など）が重複して実行されるケースです。ネットワーク遅延や通信エラーの再試行がトリガーになることが多く、ECサイトや金融サービスで特に注意が必要です。

カウンタの不整合

複数のスレッドが共有カウンタ変数に対してロックなしでインクリメント（加算）処理を行う場合に発生します。本来100回加算されるはずのカウンタが、競合により70回分しか反映されないといった問題が生じます。

在庫のオーバーブッキング

在庫の「確認」と「確保」の間に別の注文が割り込み、在庫がないにもかかわらず複数の購入が成立してしまうケースです。残り1点の商品が複数人に購入確定されるといった事象です。この確認と利用の間の競合は特に「TOCTOU」と呼ばれ、セキュリティ上の重大な脆弱性にもなります。

TOCTOU攻撃とは

TOCTOU（トクトゥー）とは 「Time of Check to Time of Use（チェック時と利用時の間の競合）」の略で、レースコンディションの中でも特にセキュリティ上重要なパターンです。

プログラムがリソース（ファイル・権限・トークンなど）を「チェック（確認）」してから「使用（処理）」するまでの間に、攻撃者が割り込んでその状態を変更することで、意図しない動作を引き起こす攻撃手法です。

TOCTOUの典型的な攻撃フロー

1. プログラムがファイルAへのアクセス権限をチェックする（「安全」と判定）
2. 攻撃者がチェックと処理の間にファイルAをシンボリックリンクで別ファイルBに差し替える
3. プログラムがファイルAへの処理を実行する（実際にはBに対して実行される）
4. 結果：権限のないファイルBへのアクセスや書き込みが成立する

TOCTOU攻撃はUnix/Linux系OSのファイルシステム操作、setuid プログラム、一時ファイルの作成処理などで特に発生しやすく、権限昇格（一般ユーザーがroot権限を取得する）につながるリスクがあります。

レースコンディションのセキュリティリスク

レースコンディションはプログラムのバグとして起きますが、悪意ある攻撃者に意図的に悪用されると、深刻なセキュリティ被害につながります。

権限昇格（Privilege Escalation）

一般ユーザー権限でしかアクセスできないシステムに対して、レースコンディションを利用して管理者（root）権限を取得する攻撃です。2016年のDirty COW（CVE-2016-5195）はその代表例で、Linuxカーネルのメモリ管理機構のレースコンディションを悪用して権限昇格が可能でした。

二重引き出し・不正決済

金融サービスやECサイトの残高チェックと決済処理の間を突くことで、残高不足でも決済を成立させたり、1回の購入で複数回のポイント付与を受けたりする攻撃です。

認証バイパス

セッション管理や認証トークンの検証と利用の間を狙い、正規ユーザーのセッションを乗っ取ったり、認証を迂回したりする攻撃です。複数の端末から同時ログインが発生した場合のセッション競合が悪用されます。

情報漏えい

Java ServletなどのWebアプリケーションでインスタンス変数にリクエストデータを格納している場合、マルチスレッドによる競合でAさんの画面にBさんの個人情報が表示されてしまう「別人問題」が起きることがあります。

発生しやすい環境と場面

レースコンディションは以下の環境・場面で特に発生しやすくなります。

マルチスレッドのWebアプリケーション

同一のサーブレットやコントローラーが複数のリクエストを並行処理する際、インスタンス変数やグローバル変数に状態を保持していると競合します。Java ServletやPHPなどでは一般的な落とし穴です。

データベースのトランザクション管理

複数のトランザクションが同じレコードを同時に読み取って更新する場合、適切なトランザクション分離レベルが設定されていないと更新の消失や不整合が発生します。

ファイルの同時アクセス

複数のプロセスが同じファイルへの読み書きを行う場合、ロック機構がないと内容の破損や上書きが起きます。一時ファイルを使う処理はTOCTOU脆弱性の温床になりやすいです。

setuidプログラム・OS権限管理

Linux/Unix系のsetuidビットが設定されたプログラムは一般ユーザーが実行しても昇格権限で動作するため、TOCTOU攻撃の標的になりやすいです。

排他制御（ロック）の基本

レースコンディションを防ぐ最も基本的な手段が「排他制御（ロック）」です。共有リソースへのアクセスを同時に1つの処理だけに制限し、他の処理はその完了を待たせます。

ミューテックス（Mutex）

ミューテックス（Mutual Exclusion：相互排除）は、共有リソースへの同時アクセスを1つに制限するための同期オブジェクトです。処理がリソースに入る際にロックを取得し、完了後にアンロックします。ロック中は他の処理が待機状態になります。

セマフォ（Semaphore）

ミューテックスが「1つのみ許可」なのに対し、セマフォは「N個まで同時アクセスを許可」できます。データベース接続プールのように、一定数の同時接続を管理する場面で使われます。

デッドロックへの注意

複数のロックを組み合わせる際は「デッドロック」に注意が必要です。処理Aがロック①を持ちながらロック②を待ち、処理Bがロック②を持ちながらロック①を待つ状態になると、両方が永遠に待ち続けて処理が停止します。

レースコンディションの対策

レースコンディションには複数の対策手法があり、状況に応じて使い分けることが重要です。

アトミック操作

インクリメント・デクリメント・比較と交換（CAS: Compare and Swap）など、単純な操作を「不可分（途中で割り込めない）」な1回の処理として実行します。PythonやJavaの標準ライブラリにはアトミック操作をサポートするクラスが含まれています。シンプルなカウンタ操作に最適です。

排他制御（ミューテックス・ロック）

共有リソースへのアクセス箇所をロックで囲み、同時に1つの処理しかアクセスできないようにします。確実な排他が可能ですが、待ち時間（レイテンシ）が生じるため、ロックを保持する時間はできる限り短くする設計が重要です。

トランザクションと分離レベルの設定

データベース操作は適切なトランザクション分離レベル（SERIALIZABLE・REPEATABLE READ等）を設定し、読み取りと書き込みを一貫した状態で扱います。楽観的ロック（バージョン番号での競合検出）と悲観的ロック（SELECT FOR UPDATE）を使い分けます。

冪等性（べきとうせい）の設計

同じリクエストを何度実行しても結果が変わらない「冪等な」設計にします。リクエストに一意の識別子（Idempotency Key）を付与し、同じキーのリクエストが重複して届いても1回だけ処理するよう実装します。決済APIで広く採用されている手法です。

キューによる直列化

同時に届いたリクエストをキュー（待ち行列）に入れ、1件ずつ順番に処理します。競合を根本的に排除できますが、処理が順番待ちになるため応答時間が長くなる可能性があります。在庫の確保や予約処理に適しています。

アクセス権の最小化とファイル設計

IPA（情報処理推進機構）の指針に従い、共有リソースへのアクセス権限を必要最小限に絞ります。一時ファイルは予測不可能なランダムな名前で作成し、作成から使用まで同一プロセスが管理します。TOCTOU対策には、チェックと使用を分離せず、ファイルオープン（open）をアトミックに行うことが効果的です。

被害事例

被害事例①：Dirty COW（CVE-2016-5195）— Linuxカーネルのレースコンディション脆弱性（2016年）

2016年10月に公開された「Dirty COW（ダーティ・カウ）」は、Linuxカーネルのメモリ管理機構（Copy-On-Write処理）に存在したレースコンディション脆弱性です（CVE-2016-5195）。COWはコピーオンライトの略で、ファイルの書き込み処理とメモリマッピングの間の競合を悪用することで、一般ユーザーがroot（管理者）権限を取得できるという深刻な権限昇格の脆弱性でした。

この脆弱性はLinuxカーネルの2.6.22以降（2007年から）に存在していたとされ、公開当時9年以上にわたって潜伏していたことが判明して大きな衝撃を与えました。Android OSもLinuxカーネルをベースにしているため、数億台のAndroidデバイスが影響を受け、攻撃者がデバイスを完全に制御できる可能性がありました。

Linuxの主要ディストリビューションとAndroidは迅速にパッチを適用しましたが、アップデートが適用されていない古い機器は長期間リスクにさらされました。Dirty COWはレースコンディション脆弱性が実際のサイバー攻撃に悪用された代表的な事例として、セキュリティの教科書に掲載されるほど広く知られています。

レースコンディションとは？仕組み・TOCTOU攻撃・セキュリティリスクと対策をわかりやすく解説

2024.9.3

「レースコンディション」という言葉を聞いたことがあるでしょうか。Webアプリケーションの脆弱性診断やセキュリティ事故の報告書に登場するこの用語は、日本語では「競合状態」とも訳され、現代のシステム開発で見落としやすい根本的な問題の一つです。

被害事例②：WebアプリケーションのTOCTOU脆弱性を悪用した不正決済・二重引き出し（継続発生）

ECサイトや金融サービスにおいて、残高確認と引き落とし処理の間を突いたレースコンディション攻撃による不正決済や二重引き出しの被害が継続的に報告されています。

攻撃者は同一のAPIエンドポイントに対して短時間に大量のリクエストを同時送信する手法（レースコンディション攻撃）を使い、残高チェック（残高あり）と決済処理（引き落とし）の間にタイミングを割り込ませます。これにより、口座残高が不足しているにもかかわらず決済が成立したり、1回分のポイントや特典が複数回付与されたりする被害が発生します。

特にAPIの冪等性設計が不十分な決済システムや、トランザクション分離レベルが適切に設定されていないデータベースを持つシステムが狙われやすく、IPA・JPCERTもWebアプリケーション開発者向けに排他制御と冪等性設計の重要性を繰り返し注意喚起しています。

よくある質問（FAQ）

Q. レースコンディションとデッドロックの違いは何ですか？

A. レースコンディションは「排他制御がないために複数の処理が競合して予期しない結果になる問題」で、データの不整合や誤動作が発生します。一方、デッドロックは「適切に排他制御を実装したが、複数のロックが循環して取得できなくなる問題」で、処理が永遠に待ち続けて停止します。

デッドロックはレースコンディションを防ごうとロックを使う際に新たに生じる問題であり、設計時の注意が必要です。レースコンディション対策（ロック）がデッドロックを生み、デッドロック対策（ロック順序の統一・タイムアウト設定）が必要になるという関係にあります。

Q.レースコンディションはなぜ発見・テストが難しいのですか？

A. レースコンディションは「再現性の低さ」が最大の特徴です。同じコード・同じ入力でも、OSのスケジューリングや処理負荷によってタイミングが変わるため、テスト環境では正常に動作し、本番環境の高負荷時だけに発生するケースが多くあります。

また、問題が発生してもエラーメッセージが出ずにデータが静かに壊れることもあり、原因の特定が困難です。発見にはコードレビュー・静的解析ツール・同時アクセスを意図的に発生させる負荷テストを組み合わせることが効果的です。

Q. TOCTOUとはどういう意味ですか？どう発音しますか？

A. TOCTOUは「Time of Check to Time of Use（チェック時から利用時まで）」の頭文字を取った略語で、「トクトゥー」と発音します。プログラムが何らかの条件を「チェック（確認）」してから、それを「使用（実行）」するまでの間に生じる競合を指します。

たとえばファイルの存在確認後にそのファイルを操作する場合、確認と操作の間に別のプロセスがファイルを差し替える余地があります。セキュリティの文脈では権限昇格やファイル操作の改ざんに直結する重要な概念です。

Q. 冪等性（べきとうせい）とは何ですか？どう実装しますか？

A. 冪等性（Idempotency）とは、「同じ操作を何度繰り返しても、結果が同じであること」を指す数学・コンピュータサイエンスの概念です。決済APIであれば、同じ注文リクエストが重複して届いても1回だけ処理されるように設計することが冪等性の実装です。

具体的には、リクエストに一意の識別子（Idempotency Key）を付与し、サーバー側でそのキーを記録して二重処理を防ぎます。Stripe・PayPalなど主要な決済APIは冪等性キーの仕組みを標準搭載しており、ネットワークの再送によるレースコンディションを防いでいます。

Q. シングルスレッドのアプリケーションでもレースコンディションは発生しますか？

A. シングルスレッドのプログラム単体ではレースコンディションは発生しませんが、外部のシステム（データベース・ファイルシステム・外部API）を共有している場合は例外です。同じデータベースに複数のシングルスレッドプロセスがアクセスすれば競合します。

また、Node.jsのようなシングルスレッドの非同期処理環境でも、非同期のawait間に別のリクエストが割り込むことでレースコンディションが起きる場合があります。「シングルスレッドだから安全」とは言い切れない点に注意が必要です。

Q. フレームワークを使っていればレースコンディション対策は不要ですか？

A. いいえ、フレームワークを使っていても排他制御は開発者が明示的に設計・実装する必要があります。SpringやDjangoなどの主要フレームワークはHTTPリクエストの処理やデータベース接続の管理を支援しますが、ビジネスロジック内の共有リソースへの同時アクセス制御は開発者の責任です。

フレームワークに依存していると「対策されているはず」という誤解が生じやすく、むしろ脆弱性を見落としやすい状況になることがあります。コードレビューとセキュリティ診断で定期的に確認することが重要です。

まとめ

レースコンディションとは、複数のプロセスやスレッドが同じ共有リソースに対してほぼ同時にアクセスするとき、処理の実行順序やタイミングによってプログラムの結果が変わってしまう問題です。CWE-362として分類されるセキュリティ脆弱性でもあり、銀行口座の二重引き出し・在庫のオーバーブッキング・権限昇格攻撃・情報漏えいなど、実際の被害は多岐にわたります。

特に注意が必要なのがTOCTOU（Time of Check to Time of Use）です。条件チェックと処理の間に攻撃者が割り込む手法で、2016年に発覚したLinuxカーネルのDirty COW（CVE-2016-5195）はその代表例です。9年以上潜伏し、数億台のAndroidデバイスに影響を及ぼしたこの脆弱性は、レースコンディションが単なる開発上のバグに留まらず、現実の攻撃に使われる深刻な脆弱性であることを示しています。

対策の基本は「排他制御」ですが、ミューテックス・セマフォ・トランザクション・アトミック操作・冪等性設計・キューによる直列化と、状況に応じた手法を使い分けることが重要です。また、レースコンディションは再現性が低くテストで検出しにくいため、コードレビュー・静的解析・負荷テストを組み合わせた多層的な検証が不可欠です。

Webアプリケーション開発では「共有リソースへの並行アクセスに排他制御があるか」を設計段階から意識し、フレームワーク任せにしない姿勢がセキュリティ品質を高める第一歩です。

書籍「セキュリティ対策の基礎知識」
メルマガ登録でプレゼント！

セキュリティ対策で何をして良いかわからない
企業の情シス部門の方必見！

メルマガ登録はこちらから