予約管理システム（Beds24）と自社サイトの同期設計

はじめに

民泊や貸別荘を運営していて一番怖いのは、同じ日に2組の予約を受けてしまうダブルブッキングです。しかも一棟貸しの場合、部屋を融通することができません。片方のお客様に断りの連絡を入れるしかなく、レビューにも響きます。

この記事では、公式サイトとAirbnbなどの予約サイト（OTA）で同じ宿を売りながら、在庫の食い違いを起こさないための同期設計の全体像を紹介します。

「在庫の正本」をどこに置くか

自社サイトは在庫を持たない

設計で最初に決めたのは、在庫・料金・予約の正本（唯一の正しいデータ）を予約管理システム側に置くことでした。公式サイトは自分のデータベースに空室情報を持たず、必要なときに毎回問い合わせます。

一見すると「自社DBにコピーを持ったほうが速いのでは」と思うかもしれません。しかしコピーを持った瞬間、「いつ同期するか」「ずれたらどちらが正しいか」という難問が発生します。正本を一つに絞ることが、結果的に一番シンプルで安全でした。

自社DBには「連携の状態」だけを持つ

とはいえ自社DBが空っぽなわけではありません。持っているのは、予約そのものではなく連携の進み具合です。

住所や到着予定時刻といった情報は、あえて自社DBに保存せず予約管理システムへ素通りさせています。持たなければ漏れない。個人情報は「持たない」ことが最良の対策になる場面が多いです。

APIとの付き合い方

窓口をひとつに絞る

外部APIを扱うコードは、あちこちに散らばりがちです。この案件では「予約管理システムへ通信するのは1つのファイルだけ」というルールを最初に決めました。

画面を作るコードも、決済のコードも、直接APIを叩くことはできません。必ずその窓口を経由し、返ってきたデータは検証を通してから使います。窓口が1か所なら、認証の更新も、エラーの扱いも、そこだけ直せば全体に効きます。

アクセストークンの扱い

Beds24のAPIは、長期利用できるリフレッシュトークンから24時間有効なアクセストークンを取得する方式です。アクセストークンは保存せず、サーバーのメモリ上に保持して期限が近づいたら自動更新するようにしました。

回数制限を意識する

APIには一定時間あたりの呼び出し回数制限があります。悪意ある第三者がURLのパラメータをいじって大量に検索を実行すれば、制限に到達して正規のお客様が予約できなくなる恐れがあります。

そこで、宿泊日数・人数・何日先までといった条件を、APIを呼ぶ前に自前で検証するようにしました。ありえない条件はAPIに届く前にはじく。この一段があるだけで、無駄な呼び出しは大きく減ります。

3つのサブテーマ

同期設計は範囲が広いので、それぞれ別の記事で掘り下げています。

空室と料金の取得

日別の料金を自分で足し算しないこと、取得に失敗したときに「満室」と表示しないこと。表示側の設計原則は「空室と料金をリアルタイムに見せる仕組み」で解説します。

予約の登録とダブルブッキング防止

予約を確定させる順序が、事故を防ぐ鍵になります。在庫確認つきの仮押さえを先に行い、カード登録は最後。この順序の理由は「ダブルブッキングを防ぐ予約登録フロー」で説明します。

変更・キャンセルの同期

OTAで予約が入ったとき、運営者が予約管理システム側で日程を変えたときに、公式サイト側をどう追随させるか。通知と定期突合を組み合わせた仕組みは「Webhookと毎時突合で崩れない同期を作る」で解説します。

まとめ

予約管理システムとの同期設計で軸にしたのは、次の3点です。

1. 正本は一つ — 在庫・料金・予約は予約管理システム側に置き、自社サイトは持たない
2. 窓口を絞る — 外部APIへの通信口を1か所に集約し、検証を通してから使う
3. 持たない情報を決める — 住所などは自社に保存せず、素通りさせて漏洩リスクを断つ