Webシステムや業務アプリケーションを利用していて、「自分が入力したはずのデータが、他の人の更新によって上書きされて消えてしまった」といった経験はないでしょうか。複数人が同時にシステムを利用する現代において、このようなデータの不整合を防ぐための技術が「排他制御（同時実行制御）」です。
その排他制御を実現する代表的な手法のひとつが「楽観的ロック（オプティミスティックロック）」です。
データベースの設計やシステム開発に関わると必ず耳にする言葉ですが、「悲観的ロックとどう違うの？」「どちらを選べばいいの？」と迷ってしまう方も多いかもしれませんね。
この記事では、楽観的ロックの基本的な仕組みから、悲観的ロックとの決定的な違い、メリット・デメリット、そして実際のシステム開発における最適な使い分けまでを、初心者の方にもわかりやすく丁寧に解説していきます。さらに、マイクロサービスやREST APIなど、現代の技術トレンドにおける楽観的ロックの扱い方といった専門的な視点も交えて深掘りしていきます。
システムの信頼性を高め、ユーザーにとって使いやすいアプリケーションを設計するためのヒントとして、ぜひ最後までお役立てください。
楽観的ロック（オプティミスティックロック）の基本概念
まずは、楽観的ロックがどのような考え方に基づいているのか、その根底にあるデータベースの仕組みから紐解いていきましょう。
データベースの排他制御（同時実行制御）とは
楽観的ロックを理解するためには、そもそもなぜ「ロック（鍵をかけること）」が必要なのかを知る必要があります。
多くのWebシステムでは、裏側でデータベース（DB）が動いており、日々大量のデータが読み書きされています。ここで問題になるのが、複数のユーザーが「まったく同じデータに対して、同時に更新をかけようとした場合」です。
たとえば、在庫が残り「1個」の人気商品を、AさんとBさんが同時にカートに入れ、同時に購入ボタンを押したとします。もしシステムに何の制御もされていなければ、データベース上ではAさんの購入処理とBさんの購入処理が衝突し、本来は1個しかない在庫がマイナスになってしまったり、後から処理されたBさんのデータだけで上書きされてAさんの購入履歴が消えてしまったりする危険性があります。これを専門用語で「ロストアップデート（更新の消失）」と呼びます。
このようなデータの矛盾や破壊を防ぐため、ある人がデータを操作している間は、他の人がそのデータを変更できないように制御する仕組みが「排他制御」です。
楽観的ロックの定義と根底にある考え方
排他制御の手法のひとつである「楽観的ロック」は、その名の通り「データに対する同時更新（競合）はめったに起こらないだろう」と楽観的に捉えるアプローチです。
ユーザーがデータを画面に表示して編集している間は、データベース側には一切ロックをかけません。誰もが自由にデータを読み込み、編集作業を進めることができます。そして、ユーザーが「保存」ボタンを押して実際にデータベースへ書き込もうとした瞬間にだけ、「自分がデータを読み込んでから保存するまでの間に、他の誰かがこのデータを更新していないか？」をチェックします。
もし他の誰かが先に更新を済ませていた場合は、後から保存しようとした人の処理をエラー（排他エラー）として弾き、「データが他のユーザーによって更新されています。最新のデータを確認してからやり直してください」といったメッセージを画面に表示して処理を中断させます。
つまり、楽観的ロックは「事前に鍵をかける」のではなく、「事後報告で矛盾がないかを確認する」というスタンスをとる手法なのです。
楽観的ロックの仕組みと具体的な処理フロー
では、システムはどのようにして「他の誰かが先に更新したこと」を検知しているのでしょうか。ここでは、実際のデータベース内部でどのような処理が行われているのか、具体的な仕組みを解説します。
バージョン番号やタイムスタンプを利用した制御
楽観的ロックを実現するためには、データベースのテーブルに、データそのものとは別に「更新のたびに変化する目印」を持たせる必要があります。この目印として最もよく使われるのが「バージョン番号（version）」です。
データベースの各レコード（行）に、整数の数値が入るバージョン管理用のカラム（列）を追加しておきます。データが新しく作成された時点では、このバージョン番号は「1」です。そして、誰かがそのデータを更新するたびに、この数値を「2」「3」「4」と1つずつカウントアップしていくルールをシステムに組み込みます。
バージョン番号の代わりに、データが更新された日時を記録する「タイムスタンプ（更新日時）」を利用することもあります。ただし、タイムスタンプはデータベースの精度（ミリ秒単位など）によっては、まったく同時刻に処理が走った際に競合を検知できないリスクがあるため、より確実なバージョン番号（数値のインクリメント）を採用するのが一般的なベストプラクティスとされています。
データ更新時の流れ（具体例を交えて）
社員情報を管理するシステムを例に、楽観的ロックの処理の流れを具体的に追ってみましょう。対象のデータは「社員ID：100」の「鈴木さん」のプロフィール情報で、現在のバージョン番号は「1」だとします。
人事部のAさんとBさんが、偶然同じタイミングで鈴木さんのプロフィール編集画面を開きました。
画面を開いた時点でデータの読み込みが行われます。
Aさんのパソコン：鈴木さんのデータ（バージョン1）を取得
Bさんのパソコン：鈴木さんのデータ（バージョン1）を取得
この時点では、データベースには何のロックもかかっていません。
Aさんが鈴木さんの「所属部署」を変更し、Bさんより先に「保存」ボタンを押しました。
システムはデータベースに対し、「社員IDが100、かつバージョンが1のデータを更新し、バージョンを2にせよ」という命令（SQL）を送ります。
条件に合致するデータが存在するため更新は成功し、データベース上のバージョン番号は「2」に書き換わります。
その数分後、Bさんが鈴木さんの「電話番号」を変更し、「保存」ボタンを押しました。
システムは同じように、「社員IDが100、かつバージョンが1のデータを更新し、バージョンを2にせよ」という命令を送ります。
しかし、データベース上の鈴木さんのデータは、すでにAさんの処理によってバージョンが「2」に上がっています。そのため「バージョンが1」という条件に一致するデータが見つからず、更新処理は空振り（更新件数0件）に終わります。
システムは「更新件数が0件だった＝自分が画面を開いた後に、誰かが別の更新を行った」と判断し、Bさんに対して「競合エラー」を返します。これが楽観的ロックの正確な処理フローです。
Ruby on Railsの「ActiveRecord」や、Javaの「JPA（Hibernate）」など、現代の主要なWebアプリケーションフレームワークの多くは、このバージョン番号を用いた楽観的ロックの仕組みを標準機能として備えており、開発者は複雑なSQLを意識することなく手軽に導入できるようになっています。
楽観的ロックと悲観的ロックの決定的な違い
排他制御を語る上で、楽観的ロックと必ず対比されるのが「悲観的ロック（ペシミスティックロック）」です。この2つの手法は、思想も実装方法も対極にあります。
悲観的ロック（ペシミスティックロック）とは
悲観的ロックは、「データに対する同時更新（競合）は頻繁に起こるものであり、必ず衝突するに違いない」と悲観的に捉えるアプローチです。
ユーザーがデータを更新する目的で読み込んだ瞬間に、データベース上で対象のデータに対してガチャンと物理的な「ロック（鍵）」をかけてしまいます。Aさんがデータを編集している間は、Bさんが同じデータを読み込もうとしても、データベース側で「現在Aさんがロック中なのでお待ちください」と待機させられます（あるいは即座にエラーになります）。
Aさんが編集を終えて保存を完了し、ロックを解除して初めて、Bさんはデータにアクセスできるようになります。文字通り「他の人を完全に締め出す」ことでデータの整合性を100%保証する、非常に強固な手法です。
比較表で見る両者の違い
それぞれの特性をより直感的に理解できるよう、主要な項目で比較表にまとめました。
| 比較項目 | 楽観的ロック（Optimistic） | 悲観的ロック（Pessimistic） |
| 基本的な考え方 | 競合はめったに起きないと考える | 競合は頻繁に起きると考える |
| ロックをかけるタイミング | 保存（UPDATE）の瞬間のみ | データ取得（SELECT）の瞬間から完了まで |
| 他ユーザーへの影響 | 編集作業自体は同時に行える | ロック解除まで待機、またはエラーになる |
| データベースへの負荷 | 非常に軽い | ロックを保持し続けるため負荷が高い |
| デッドロックの発生リスク | 原則として発生しない | 発生しやすい（複数テーブル操作時など） |
| ユーザー体験（UX） | 最後に保存しようとした人がエラーになり落胆する | 待たされるが、入力が無駄になることは少ない |
システムのパフォーマンスとスケーラビリティ（拡張性）を重視する場合は「楽観的ロック」、絶対にデータの矛盾や処理の遅延を許さない厳密な業務処理には「悲観的ロック」を選ぶのが、システム設計の基本セオリーとなっています。
データベースの設計や排他制御の基本をより深く体系的に学びたい方には、以下の書籍がおすすめです。システム開発の現場で長く読み継がれている名著であり、初心者から中級者へのステップアップに最適です。
楽観的ロックのメリット・デメリット
ここまで仕組みを解説してきましたが、楽観的ロックを採用することで具体的にどのような利点があり、逆にどのような課題を抱えることになるのでしょうか。
導入によって得られるメリット
パフォーマンスの向上とデータベースへの負荷軽減
楽観的ロックの最大のメリットは、何と言ってもシステムのパフォーマンスが高いことです。ユーザーが画面上でウンウンと悩んでデータを入力している数十秒、数分間、データベースには一切ロックがかかりません。データベースのリソース（メモリや接続セッション）を占有しないため、アクセスが集中する大規模なWebサービスでもサクサクと動かすことができます。
デッドロックの回避
データベースにおける「デッドロック」とは、複数の処理がお互いに相手が持っているロックの解除を待ち合ってしまい、システム全体がフリーズしてしまう恐ろしい現象です。楽観的ロックは、そもそも長い時間ロックを保持しないため、データベース層でのデッドロックを引き起こすリスクが極めて低くなります。これは運用上の大きな安心材料となります。
注意すべきデメリットと課題
競合発生時のリトライ処理とユーザー体験（UX）の悪化
楽観的ロックの最大の弱点は、「エラーに気づくのが一番最後（保存ボタンを押した瞬間）になる」という点です。
せっかくユーザーが長文の入力フォームを一生懸命埋めて保存ボタンを押したのに、「他の人が更新したため、最初から入力し直してください」という無慈悲なエラー画面が出てしまうと、ユーザーは強いストレスを感じます。
競合が頻繁に発生するような画面で楽観的ロックを採用してしまうと、使い勝手の悪いシステムという烙印を押されかねません。
アプリケーション側での複雑な制御
データベース側でのロックに頼らない分、エラーが起きた後の処理（どうやってユーザーに通知するか、入力したデータをどう復元させるかなど）を、アプリケーションのプログラム側で丁寧に作り込む必要があります。これは開発者にとって手間のひとつとなります。
楽観的ロックが適しているシステム・適さないシステム
メリット・デメリットを踏まえた上で、実際のプロジェクトではどのような機能に楽観的ロックを適用すべきでしょうか。適しているケースと、避けるべきケースを具体例とともに分類します。
楽観的ロックを採用すべき具体例
基本的には「読み込み操作が圧倒的に多く、同時に同じデータを更新する確率が低いシステム」に最適です。現代のWebアプリケーションの8〜9割は、この楽観的ロックで十分に対応できると言われています。
- ユーザーのプロフィール設定やマイページ自分自身のデータを編集する画面であり、他人が同時にアクセスして書き換えることは通常あり得ません。そのため、システムを軽く保てる楽観的ロックが最適です。
- Wikiシステムやブログの管理画面複数人で編集する可能性はありますが、まったく同じ記事の同じ箇所を、同じ秒数で同時に編集する確率は低いです。万が一衝突した場合は、差分を表示してユーザーに手動でマージ（統合）させるようなUIを組み合わせるのが一般的です。
- 社内の顧客管理システム（CRM）何千件もの顧客データの中から、営業担当者がそれぞれ別の顧客データを編集するようなケースでは、競合はほとんど発生しないため楽観的ロックで軽快に動作させます。
悲観的ロックを優先すべき具体例
一方で、「絶対にデータが競合してはならない」「お金や在庫が絡むシビアな処理」「入力のやり直しが許されない処理」には、パフォーマンスを犠牲にしてでも悲観的ロック（またはテーブルロック）を採用します。
- コンサートの座席予約システム「A列1番」というひとつの座席に対して、全国から何万人もが同時に予約ボタンを押すようなシステムです。楽観的ロックにしてしまうと、数万人に「予約完了画面」の直前まで進ませた挙句、最後に1人以外全員をエラーにしてしまうことになり、大クレームに発展します。取得の段階でガッチリとロックをかける必要があります。
- 銀行口座の残高更新・振込処理金融システムにおいて、残高の計算間違いやデータの喪失は絶対に許されません。処理が遅延してでも、順番に直列で処理を完了させるための厳密な悲観的ロックが求められます。
- ECサイトの在庫引き当て処理商品の残り在庫数を減らす処理も、同時に購入が殺到した場合に「在庫がないのに売れてしまう（オーバーセル）」を防ぐため、悲観的ロックでの確実な処理が行われます。
現代のシステム開発における楽観的ロックの最新動向
近年、システム開発のアーキテクチャ（構造）が進化するにつれて、楽観的ロックの使われ方や重要性も新しい形へと変化してきています。ここでは、中級者以上の方に向けて、現代の技術トレンドとの関係性を解説します。
REST APIとHTTPヘッダー（ETag）による楽観的ロック
現在主流となっているフロントエンド（ReactやVue.jsなど）とバックエンド（API）を分離したWeb開発において、API経由で楽観的ロックを実現するために標準的に使われているのが、HTTPヘッダーの「ETag（エンティティタグ）」です。
ETagは、対象のデータ（リソース）のバージョン番号やハッシュ値を表す文字列です。データの取得時（GETリクエスト）にサーバーからETagを受け取り、データを更新する際（PUTやPATCHリクエスト）に「If-Matchヘッダー」としてそのETagを送り返します。
サーバー側は、受け取ったETagと現在のデータベースのバージョンを比較し、一致していれば更新を許可し、違っていれば「412 Precondition Failed（前提条件スタッツ）」というエラーコードを返します。これはまさにWeb標準の技術を使った楽観的ロックの実装であり、広く採用されているベストプラクティスです。
マイクロサービスアーキテクチャと分散システム
巨大なシステムを小さなサービスの集合体に分割する「マイクロサービスアーキテクチャ」では、複数の異なるデータベースをまたいでデータを整合させる必要が出てきます。
従来のシステムであれば、データベース全体の強力なトランザクション機能を使って悲観的ロックをかけることができましたが、ネットワーク越しに複数のサービスをロックし続けること（分散トランザクション）は、システムの停止リスクやパフォーマンスの劣化を招くため、現代ではアンチパターンとされています。
そこで、「最終的にデータが一致すればよい（結果整合性）」という考え方のもと、システム全体を緩やかに連携させるイベント駆動アーキテクチャが主流となっています。この環境下では、各サービス内部での更新はスケーラブルな「楽観的ロック」で処理し、万が一競合やエラーが発生した場合は「補償トランザクション（処理を取り消すための逆の処理）」を実行する、といった高度な設計が求められるようになっています。
NoSQLデータベースにおける条件付き書き込み
リレーショナルデータベース（RDB）だけでなく、Amazon DynamoDBのようなスケーラビリティに特化したNoSQLデータベースでも、楽観的ロックの概念は重要です。
DynamoDBなどには、従来のRDBのような複雑なテーブルロック機構はありません。その代わり、「対象項目の特定の属性（バージョン番号など）が、指定した値と一致している場合のみ書き込みを許可する」という「条件付き書き込み（Conditional Writes）」という機能が提供されています。これにより、超分散環境・超高速レスポンスを維持したまま、ロストアップデートを防ぐ楽観的ロックが実現されています。
楽観的ロック実装時のベストプラクティス
実際にシステムに楽観的ロックを組み込む際、単にデータベースにバージョン番号を持たせるだけでは、ユーザーにとって親切なシステムとは言えません。開発現場で意識すべき重要なポイントをまとめました。
例外処理（排他エラー）の適切なユーザー通知
デメリットの項目でも触れた通り、楽観的ロックによるエラーはユーザーにとって不意打ちとなります。そのため、エラーメッセージの工夫が不可欠です。
単に「システムエラーが発生しました」や「排他エラーです」といった専門用語を見せるのはNGです。「あなたが編集している間に、他のユーザーがこのデータを更新しました。申し訳ありませんが、最新のデータを確認のうえ、再度入力をお願いします」といった、理由と次にとるべき行動が明確にわかるメッセージを表示するようにしましょう。
さらにUXを高めるのであれば、エラー画面で「ユーザーが入力していたデータ」と「データベース上の最新データ」を並べて表示し、どこが変更されたのかをハイライトしてあげるような画面設計が理想的です。
自動リトライ処理の組み込み（バックグラウンド処理の場合）
人間が画面から入力するのではなく、バッチ処理や非同期のワーカー（プログラム）が裏側でデータを更新するようなケースでは、楽観的ロックエラーが発生した際に「自動的に最新データを取得し直し、もう一度更新処理を試みる（リトライする）」ロジックをプログラムに組み込むのが鉄則です。
数ミリ秒のタイミングのズレで競合しただけであれば、1〜2回リトライすれば正常に処理が完了することがほとんどです。これにより、システム全体のエラー発生率を劇的に下げることができます。
楽観的ロックに関するよくある質問（FAQ）
最後に、楽観的ロックの学習中によく抱く疑問にQ&A形式で回答します。
Q. バージョン番号ではなくタイムスタンプを使っても良いですか？
A. 可能な限りバージョン番号（数値）を使用することを強く推奨します。
古いシステムでは更新日時（タイムスタンプ）をロックの判定に使っていることもありますが、タイムスタンプには「精度の限界」というリスクが伴います。データベースの時刻精度が「秒」や「ミリ秒」単位の場合、それよりも短いマイクロ秒単位のわずかな差で2つの処理が同時に走った場合、まったく同じタイムスタンプが付与されてしまい、競合を検知できずにデータが上書きされてしまう恐れがあります。確実なインクリメント（+1ずつ増やす）が行われる数値型のバージョン番号のほうが安全です。
Q. 楽観的ロックはデータベースに「ロック」をかけていないのに、なぜ安全なのですか？
A. ユーザーが操作している間はロックしませんが、書き込む「一瞬」だけはデータベースの機能で安全が担保されるからです。
データベース（RDB）には、UPDATE文（データの更新命令）を実行するまさにその瞬間、対象の1行だけを他のアクセスから守る機能（行ロック）が備わっています。楽観的ロックにおける「バージョン番号が一致しているか」の確認と「バージョン番号を増やす」という一連の処理は、このデータベースの基本機能によって安全に、かつ瞬時に実行されるため、データがすり抜けることはありません。
Q. 楽観的ロックを採用していれば、デッドロックは絶対に発生しませんか？
A. 「原則として」発生しにくくなりますが、絶対にゼロになるわけではありません。
楽観的ロック自体はデッドロックを引き起こす原因にはなりませんが、同じトランザクション（一連の処理のまとまり）の中で、複数のテーブルをまたいで順番に更新をかけていくような複雑なプログラムを書いている場合、その処理の順番の矛盾によってデータベース上でデッドロックが発生する可能性は残ります。これは楽観的ロックの問題というよりも、トランザクション設計自体の問題と言えます。
システム特性に合わせて最適な排他制御を選ぼう
この記事では、データベースの整合性を守る「楽観的ロック」について解説してきました。重要なポイントを振り返ってみましょう。
- 楽観的ロックとは：競合はめったに起きないという前提のもと、更新の直前に「バージョン番号」等を用いて他の人の更新がないかを確認する手法。
- 最大のメリット：データベースにロックを保持しないため、システムのパフォーマンスが非常に高く、デッドロックのリスクも低い。
- 悲観的ロックとの使い分け：一般的なWebシステムやマイページ等は「楽観的ロック」。座席予約や金融系など絶対に競合が許されない処理は「悲観的ロック」。
- UXへの配慮が必要：排他エラーが発生した際のユーザーへの通知や、入力データの復元など、アプリケーション側での丁寧な設計が求められる。
システムの設計に「常にこれが正解」という銀の弾丸はありません。開発する機能の性質、ユーザーの利用頻度、そして万が一競合が発生した際のビジネスへの影響度合いを総合的に判断して、楽観的ロックと悲観的ロックを適切に使い分けることが、優秀なエンジニアやディレクターの腕の見せ所です。
コメント