予約のダブルブッキングを防ぐには：枠と在庫の排他制御の設計

予約のダブルブッキングは、「同時に二人が同じ枠を押さえる」「外部の予約サイトと自社の予約台帳の同期が遅れる」「電話や店頭で受けた予約を手で入力する」という三つの経路で起きます。システムで防げるのは主に前の二つで、三つ目は入力の手順と画面の作りで減らします。どれか一つだけ対策しても、残りの経路から重複は入り込みます。

結論から言うと、防止策の中心は「予約枠や在庫の残数を、ただ一か所の台帳で管理し、更新するときは必ず排他制御をかける」ことです。そのうえで、外部サイトとの連携は在庫を取り合う構造にせず、どちらが正の台帳かを決めて片方に寄せます。手入力は、台帳を見ながら登録する画面に統一し、紙やスプレッドシートの別台帳を残さないことが要になります。

この記事は、サロン・クリニック・スクール・施設貸し出し・体験ツアーなど、時間枠や席・部屋の在庫を売る事業で予約の仕組みを見直したい方、予約システムの開発を検討している方に向けています。重複が起きる原因の切り分け方、システム設計の具体的な選択肢、運用ルール、開発会社に確認すべき点までを順に整理します。

ダブルブッキングが起きる三つの経路

まず、自社で起きている重複がどの経路から来ているかを切り分けます。原因によって打ち手がまったく違うためです。

経路1：同時アクセスによる競合

残り1枠の時間帯に、二人の利用者がほぼ同時に予約ボタンを押したとします。システムが「残数を読む → 1以上なら予約を作る → 残数を減らす」という手順を、排他制御なしで実行していると、二人とも「残り1」を読んでしまい、両方の予約が成立します。アクセスが少ないうちは表面化しにくく、キャンペーンや予約開始時刻に申し込みが集中したときに初めて発覚するのが典型です。

経路2：外部予約サイトとの同期遅れ

ポータルサイトや比較サイト、宿泊・飲食・美容の予約サービスなど、複数の販路で同じ枠を売っている場合に起きます。外部サイトの在庫は、自社の台帳から定期的に送る、あるいは管理画面で手動更新する、という方法で合わせていることが多く、その間隔のあいだに両方で売れると重複します。同期の間隔が長いほど、また販路が多いほど起きやすくなります。

経路3：電話・店頭・メールでの手入力

電話で受けた予約をメモし、あとで予約システムに入力する運用では、メモから入力までの時間に別の予約が入ることがあります。また、スタッフごとに紙の台帳や個人のカレンダーを持っていると、どれが最新か分からなくなります。システムを入れても、この経路が残っていると重複はなくなりません。

システム側の基本：排他制御で残数を守る

同時アクセスによる重複は、設計で確実に防げます。ここでは技術の細部ではなく、発注側が理解しておくべき考え方を整理します。

「読んでから書く」の間に割り込ませない

重複の根本原因は、残数を読んでから予約を確定するまでの間に、別の処理が割り込めることです。これを防ぐ方法はいくつかあります。

• 行ロック（悲観的ロック）：予約枠のデータを読むときに「処理が終わるまで他は待て」と鍵をかける方法。確実ですが、同時アクセスが非常に多い枠では待ちが発生します。
• 条件付き更新（楽観的ロック）：「残数が1以上のときだけ1減らす」という一つの更新命令にまとめ、更新できた件数が0なら満席と判断する方法。待ちが少なく、多くの予約システムで扱いやすい手法です。
• 一意制約：「同じ枠・同じ席に有効な予約は一件だけ」というルールをデータベースに持たせ、二件目の登録自体をエラーにする方法。席番号や部屋番号が決まっている予約に向きます。

実務では、条件付き更新か一意制約を基本にし、どうしても複数のデータをまとめて押さえる必要があるときに行ロックを使う、という組み合わせが一般的です。データベースの基本は RDB（リレーショナルデータベース） の用語ページでも説明しています。

枠の持ち方を決める

排他制御をかけるには、「何を一つの単位として押さえるか」を決める必要があります。

• 時間枠ごとに定員を持つ（例：10時〜11時のレッスンに定員8名）
• スタッフ×時間で持つ（例：施術者Aの14時〜15時）
• 部屋・席・機材などの資源×時間で持つ（例：会議室Bの13時〜16時）
• 複数の資源を同時に押さえる（例：施術者Aと個室Cの両方が空いているときだけ予約可）

最後の「複数資源の同時確保」が最も重複を生みやすい設計です。施術者は空いているのに部屋が埋まっている、というケースを見落とすと、予約は通ったのに当日対応できない事態になります。複数の資源をまとめて押さえる処理は、全部取れたら確定、一つでも取れなければ全部取り消す、という一括処理（トランザクション）にしておく必要があります。

時間の重なり判定を正しくする

時間帯が自由に選べる予約（例：30分単位で開始時刻を選べ、所要時間がメニューごとに違う）では、「同じ枠」ではなく「時間が重なるか」で判定します。開始時刻が同じでなくても、片方の終了時刻がもう片方の開始時刻より後なら重なっています。片付けや移動のための前後の余白（バッファ）をどう扱うかも、ここで決めておきます。この判定をアプリの画面側だけで行い、データベースに登録する直前に再確認しないと、同時アクセスで重複が入り込みます。

仮押さえと決済待ちの扱い

予約の途中で決済や情報入力の画面が挟まる場合、「どの時点で枠を押さえるか」が問題になります。

確定時点で押さえる設計だと、利用者が決済画面で入力している間に枠が埋まり、決済後に「満席でした」となることがあります。逆に、選んだ時点で押さえる設計だと、途中で離脱した人の分の枠がいつまでも埋まったままになります。

そこで多くの予約システムは「仮押さえ」を使います。

1. 利用者が日時を選んだ時点で、有効期限付き（例：10分）の仮予約を作り、残数を減らす。
2. 情報入力・決済が期限内に完了したら、仮予約を確定予約に変える。
3. 期限を過ぎたら仮予約を自動で取り消し、残数を戻す。
4. 決済が完了したのに仮予約が期限切れになっていた場合の扱い（返金するか、空きがあれば確定するか）を決めておく。

4番目の「決済と期限切れのすれ違い」は見落とされがちです。決済サービスからの完了通知が遅れて届くこともあるため、通知を受けた時点で改めて枠を確認し、確保できなければ自動返金とお詫びの連絡を出す、といった手順を設計しておきます。事前決済の設計については 予約システムのキャンセル料・事前決済の実装方法 でも詳しく扱っています。

外部予約サイトとの連携で重複を防ぐ設計

複数の販路で同じ枠を売る場合、システムの排他制御だけでは足りません。販路ごとに別々の台帳があり、それぞれが独立して在庫を減らすからです。

正の台帳を一つに決める

最初に決めるべきは「どこが在庫の正本か」です。自社の予約システムを正本にして、外部サイトにはそこから空き状況を送るのが基本形です。外部サイトで入った予約は、自社システムに取り込んだ時点で正式に確定する、という扱いにできれば重複は大きく減ります。

連携方式を比較する

即時連携では、予約が発生した瞬間に相手へ通知する Webhook などの仕組みを使います。ただし通知が届かない・遅れることは必ず起きるため、定期的に双方の予約一覧を突き合わせる処理も併せて用意します。連携先がAPIを持たない場合は、在庫を販路ごとに配分してしまう方法が、売り切れ時の機会損失と引き換えに確実です。連携が失敗したときの再試行やデータ不整合への備えは API連携の障害対策 の記事も参考にしてください。

残り少ない枠の売り方を変える

完全な即時連携が難しいときの現実的な工夫として、「残りが少なくなったら外部サイトでの販売を止め、自社サイトと電話だけで受ける」というルールがあります。たとえば残り2枠を切ったら外部販路を自動で満席表示にする、と決めておけば、同期遅れによる重複はほとんど起きなくなります。

手入力経路をふさぐ運用と画面設計

システムが正しくても、スタッフが電話予約を後でまとめて入力していれば重複は起きます。

電話を受けながら登録する

電話予約は、通話中に予約システムの画面で空きを確認し、その場で登録まで済ませる運用にします。そのためには、スタッフ用の登録画面が速く、少ない操作で完結することが必要です。顧客検索、メニュー選択、日時選択、確定の4ステップ程度で終わる画面にすると、通話を待たせずに済みます。

別台帳をなくす

紙の予約表、スタッフ個人の手帳、共有のスプレッドシートなど、システム外の台帳が残っていると、どれかに書いて終わりにする人が必ず出ます。導入時に「予約はシステムに入っていないものは無効」と決め、別台帳は廃止します。スタッフの私用予定や休みも同じ仕組みで管理しないと、予約は入るのに担当者がいない、という別種の重複が起きます。スタッフの予定と予約枠の同期は 予約システムとGoogleカレンダー連携 で詳しく扱っています。

上書き権限を絞る

管理者が満席の枠に無理やり予約を追加できる機能は、現場では便利ですが重複の温床になります。上書きできる人を限定し、上書きした記録（誰が、いつ、なぜ）を残すようにします。

重複を早く見つける仕組みを持つ

どれだけ対策しても、外部連携の不具合や設定ミスで重複がゼロになるとは限りません。そこで「起きたらすぐ気づく」仕組みも用意します。たとえば、翌日分の予約について定員超過や時間の重なりがないかを毎晩自動でチェックし、見つかれば担当者にメールやチャットで知らせる処理です。前日に気づければ、お客様へ日時変更のお願いをする余裕が生まれます。当日の朝、来店直前に発覚するのとでは、お詫びの重さがまったく違います。

あわせて、管理画面の予約一覧に「定員超過」「時間重複」といった警告表示を出しておくと、日々の確認の中で異常に気づきやすくなります。重複を防ぐ仕組みと、重複を見つける仕組みは別物として、両方を設計に含めるのが安全です。

具体的な場面で考える（架空の例）

ここでは、架空の小規模ヨガスタジオを例に考えます。

このスタジオは、自社サイトの予約フォーム、外部のレッスン予約ポータル、電話の三つで予約を受けていました。自社フォームの内容はスプレッドシートに自動転記され、ポータルの予約は管理画面を見てスタッフが手で転記し、電話予約は受付のメモから夕方にまとめて入力していました。月に数回、定員8名のクラスに9人目が来てしまい、無料チケットでお詫びしていたとします。

見直しでは次のように整理しました。

1. 予約台帳を一つの予約システムに統一し、スプレッドシートは閲覧用の出力に格下げした。
2. クラスの定員管理を条件付き更新に変え、同時申し込みでも定員を超えないようにした。
3. ポータルはAPI連携に対応していなかったため、各クラスの定員8名のうち2名分だけをポータルに割り当て、残り6名分を自社サイトと電話で販売する配分方式にした。
4. 電話予約は受付端末で通話中に登録する運用に変え、メモからの後入力を禁止した。
5. 毎朝、ポータルの予約一覧と台帳を突き合わせる確認を5分の作業として手順書に入れた。

ポータル側で売れ残った枠は、前日の夕方に自社販売へ戻すルールにして機会損失を抑えました。このように、システムの改修と運用ルールの両方を組み合わせるのが現実的です。

よくある失敗と避け方

• 画面上の残数表示だけで判定している：画面に表示された時点の残数は、予約ボタンを押す時点では古くなっています。確定処理の直前にサーバー側で必ず再確認します。
• キャンセル時に残数を戻し忘れる：キャンセル・日時変更・仮押さえの期限切れのすべてで、残数が正しく戻るかをテストします。戻し忘れは「空いているのに満席表示」になり、売上の取りこぼしになります。
• 日時変更を「キャンセル+新規予約」で実装して、間に他人が入る：変更先の枠を先に確保してから元の枠を解放する順序にします。
• 外部サイトとの突き合わせを自動化に任せきりにする：同期処理が止まっても気づかない状態が一番危険です。同期が一定時間成功していなければ通知が飛ぶようにします。
• テストを一人ずつの操作でしか行わない：同時アクセスは手作業の確認では再現できません。複数の予約リクエストを同時に送る試験を、開発会社に必ず実施してもらいます。
• 営業時間や定休日の変更を台帳に反映しない：枠の設定変更が遅れると、存在しない枠に予約が入ります。設定変更の担当者と期限を決めます。

導入・改修前のチェックリスト

予約システムを新しく作る、または既存の仕組みを見直す前に、次の点を確認しておくと、開発会社との打ち合わせが具体的になります。

• 予約の単位は何か（時間枠・スタッフ・部屋・席・機材、またはその組み合わせ）
• 一つの予約で複数の資源を同時に押さえる必要があるか
• 予約受付の経路は何本あり、それぞれ誰が登録しているか
• 在庫の正本をどのシステムにするか決まっているか
• 外部サイトはAPIや通知の仕組みを提供しているか
• 仮押さえの有効期限と、期限切れ時の扱いを決めたか
• 日時変更・キャンセル・期限切れで残数が戻ることを確認する試験項目があるか
• 同時アクセスの試験を実施する計画があるか
• 管理者による上書き予約の可否と記録の方法を決めたか
• 同期が止まったときに誰が気づき、どう対処するか決めたか

予約システム全体にどんな機能が必要かは 予約システムに必要な機能一覧 にまとめています。

よくある質問

Q. 既製の予約SaaSを使えばダブルブッキングは起きませんか？

多くの予約SaaSは同時アクセスへの排他制御を備えていますが、外部販路との同期や手入力の経路までは保証しません。また、複数資源の同時確保や独自の時間ルールに対応していない場合、その部分を運用で補うことになり、そこから重複が生まれます。自社の予約単位と販路の構成を書き出し、SaaSで表現できるかを確認してから選ぶのが確実です。

Q. 予約数が少なくても排他制御は必要ですか？

必要です。重複は平均的なアクセス数ではなく、予約開始直後や人気枠に申し込みが集中した瞬間に起きます。排他制御は後から足すと既存の処理を広く直すことになるため、最初の設計で入れておく方が費用も手間も小さく済みます。

Q. 外部サイトとの即時連携ができない場合、どうすればよいですか？

在庫を販路ごとに配分する、残りが少なくなったら外部販路を止める、毎日の突き合わせを手順化する、の三つを組み合わせます。売り切れ時の機会損失は多少出ますが、重複によるお詫び対応や信頼低下に比べれば管理しやすい損失です。

Q. 既に起きてしまった重複予約はどう扱うべきですか？

まずは予約の受付時刻を記録から確認し、先着の予約を優先するなど、事前に決めた基準で対応します。基準がその場の判断になると、お客様ごとに対応が変わって不公平感が生まれます。お詫びの方法や代替枠の提示方法も、あらかじめ手順にしておくと現場が迷いません。

Otsumuに相談できること

予約の重複が月に一度あるかないかで、原因が電話予約の後入力だけなら、まずは運用ルールの見直しで十分です。通話中に登録する、別台帳をやめる、毎朝突き合わせる、という三つを徹底するだけで改善する例は少なくありません。既製の予約SaaSで予約の単位と販路が素直に表現できるなら、自社開発を急ぐ必要もありません。

一方で、スタッフと部屋を同時に押さえる、メニューごとに所要時間が違う、複数の外部販路と在庫を共有している、事前決済と仮押さえを組み合わせたい、といった条件が重なると、設計段階での判断が結果を大きく左右します。既存システムで重複が続いていて原因が特定できない場合も、データの流れを一度整理し直した方が早く解決します。

Otsumuでは、予約の単位と販路の構成を一緒に棚卸しし、どこを正の台帳にするか、どの経路をシステムで防ぎどこを運用で補うかを整理したうえで、必要な機能に絞って開発します。予約システム開発 のページで進め方を紹介しています。外部サービスとの連携が中心になる場合は API連携開発 としてもご相談いただけます。

自社の状況でどこから手を付けるべきか迷っている段階でも構いません。30分の無料相談 で、現在の予約の流れを伺いながら、優先して対策すべき経路を一緒に確認します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01