直接予約サイトをAirbnb・Booking.comと同期する方法

直接予約サイトのOTA同期とは、ホテル公式サイトで客室が売れたら、AirbnbやBooking.comの販売可能数にも直ちに反映される仕組みです。逆方向も同様に、OTA予約が入ったら、別の宿泊者が同じ客室を予約する前に直接予約ページの在庫を減らす必要があります。

3つのカレンダーを別々に管理してはいけません。予約エンジン、ホテル管理システム（PMS）、チャネルマネージャーを一つの循環として構成し、料金、販売制限、予約、例外処理について明確なルールを設けます。

本ガイドでは、この循環をオーナーの運用視点から解説します。

直接予約サイトとOTAを同期する仕組み

ホテルのPMSには、客室構成と予約記録を保持させます。予約エンジンはホテル公式サイトにリアルタイムの客室と料金を表示し、チャネルマネージャーはAirbnb、Booking.com、その他のオンライン旅行代理店（OTA）と対応データを交換します。

通常の流れは次のとおりです。

宿泊者が公式サイトで予約 → 予約がPMSに登録 → 客室タイプの在庫が減少 → チャネルマネージャーがAirbnbとBooking.comへ新しい在庫数を送信

OTA予約では逆の経路をたどります。

宿泊者がOTAで予約 → 予約がPMSに登録 → 在庫が減少 → ホテル公式サイトと他の接続済みチャネルが新しい在庫数を受信

多くの構成では、各チャネルはPMSとチャネルマネージャー、または統合型プラットフォームを介してデータを交換します。

公式サイトとOTAの間で同期すべき情報

共通の情報源から同期するデータと、チャネル固有のコンテンツを分けます。

在庫と予約は、誤りによって最後の1室を二重販売する恐れがあるため、最も厳密な管理が必要です。料金と販売制限も重要ですが、OTA独自のプロモーション、手数料、税表示、割引、非対応ルールにより、宿泊者向けの表示結果が異なる場合があります。

Smart Orderは、ホテル予約エンジンをPMS在庫およびホテル向けチャネルマネージャーと連携させます。直接予約は運用カレンダーに登録され、対象の客室在庫を減らし、接続済みOTAへ更新後の在庫数を送信します。

唯一の正しい情報源を決める

接続前に、各項目をどのシステムでスタッフが管理するか決めます。一般的な構成は次のとおりです。

• PMSまたはチャネルマネージャーが、客室タイプ、基本料金、在庫、対応する販売制限を管理する。
• 予約エンジンが承認済みの直接予約向けプランを読み込み、直接予約をPMSに書き込む。
• AirbnbとBooking.comは対応する更新を受信し、必要に応じてチャネル固有のコンテンツ、プロモーション、手数料、ポリシー、上書き設定を保持する。

複数のスタッフが3つの管理画面で同じ基本在庫を変更しないようにします。障害時には手動変更が適切な場合もありますが、内容を記録し、後で情報源と照合する必要があります。

唯一の正しい情報源には責任者も必要です。客室マッピング、料金ロジック、意図的なチャネル別在庫、接続商品の変更は、1人の担当者が承認します。

在庫は同じ実在客室を基準にする

まず、ホテルが実際に割り当てられる客室を基準にします。宿泊者にとって相互に代替可能な客室だけを、1つの販売可能な客室タイプにまとめます。

例えば、施設にデラックスキングが4室あるとします。公式サイトとOTAの変更可能プランと返金不可プランは異なる料金プランですが、同じ4室の在庫を使用します。どれか1つが売れたら、その客室在庫に紐づく他のすべてのプランでも販売可能数を減らします。

直接予約ページに独自の在庫割り当てがある場合や、2つのOTA商品が同じ実在客室の別々のコピーを参照している場合、問題が生じます。更新成功と表示されても、全チャネルで実在数を超えて販売する可能性があります。

余裕のある日、ほぼ満室の日、販売停止中の客室、最後の1室をテストします。直接予約サイトとOTAの同期が信頼できるのは、各イベントで正しい共通在庫数が変化する場合だけです。

料金同期は公開価格の完全一致を意味しない

基本料金の情報源を選び、チャネルごとの調整を文書化します。ホテルは直接予約限定プラン、OTA向け上乗せ、OTAプロモーション、異なるキャンセル条件を意図的に利用できます。

同期の目標は承認済みの料金戦略であり、すべての画面に同じ金額を表示することとは限りません。客室と料金プランごとに、次を確認します。

• 基本料金を保持するシステム
• チャネル料金が固定、派生、調整済みのいずれであるか
• 表示合計額に影響する税金、手数料、食事、人数追加料金、割引
• 接続が対応する販売制限

公開中の公式サイト、Airbnb、Booking.comで1泊と連泊を検索します。PMSから送信された料金だけでなく、宿泊者に表示される合計額と条件を比較してください。

親料金を変更したら、派生するすべての直接予約料金とOTA料金を確認します。基本料金の更新成功だけでは、子料金の計算や公開合計額が正しいとは証明できません。

AirbnbとBooking.comでは接続の仕組みが異なる

Airbnbが公式に対応するソフトウェア同期には、「すべてを同期」と「料金と在庫のみを同期」があります。後者では、ホストがAirbnb上でリスティング内容と予約設定を管理でき、ローカル上書きが可能なこともあります。どの項目をPMSで管理し、どれをAirbnb側に残すか把握してください。

Booking.comでは、個々の施設が直接API接続を構築するのではなく、通常はチャネルマネージャーを介して接続すると案内しています。接続ツールは料金と在庫に対応しますが、その他の機能はプロバイダーの接続仕様と施設設定によって異なります。

そのため「両方のチャネルに接続済み」だけでは十分な運用ルールになりません。各プラットフォームの在庫、料金、販売制限、コンテンツ、プロモーション、税金、決済、予約変更、キャンセルの情報源を示す管理表を用意します。

Airbnbのカレンダー専用iCal接続を完全な双方向API接続と同等だと考えてはいけません。カレンダーフィードは販売停止日が中心となる場合があり、料金、販売制限、予約詳細、更新を同じ範囲で交換できるとは限りません。

在庫公開前に客室タイプと料金プランをマッピングする

マッピングにより、どの商品が同等かをシステムに伝えます。公式サイトの「デラックスキング」がBooking.comでは「スーペリアダブルルーム」と呼ばれ、Airbnbでは別名の場合があります。名称が違っても、提供する実在客室の条件は一致させます。

販売中の各商品について、客室在庫、最大宿泊人数、ベッド構成、眺望またはカテゴリー、料金条件、キャンセルポリシー、食事、決済方法を確認し、各料金プランを対象プランにマッピングします。

同じ客室を使うという理由だけで、公式サイトの返金可能料金をOTAの返金不可料金にマッピングしてはいけません。在庫は共有しても、料金とポリシーは別にできます。

未マッピングのOTA商品は販売停止にするか、マッピングを解決します。放置されたリスティングは、同期フロー外で販売を続ける可能性があります。

遅延、失敗、手動上書きを理解する

「リアルタイム」は運用目標であり、配信状況を無視してよいという意味ではありません。更新は複数のシステムを経由し、マッピング、認証情報、レート制限、非対応の販売制限、チャネル側メンテナンスなどでOTAがメッセージを拒否・遅延させる場合があります。

ホテルPMSまたはチャネルマネージャーには、失敗した更新、対象の日付と商品、再試行状況、スタッフの対応に十分な詳細を表示できる必要があります。

簡潔な障害対応ルールを作成します。

1. 影響を受ける客室、料金、日付、チャネルを特定する。
2. 直ちに過剰販売の恐れがある場合は、手動で在庫を保護する。
3. 一時的なOTA上書きを記録する。
4. 情報源またはマッピングのエラーを修正する。
5. 再送信するか、承認済みの再試行を待つ。
6. すべての公開チャネルを照合し、一時的な上書きを解除する。

内部カレンダーが変わっただけで更新成功と判断してはいけません。公開予約ページが最終的な販売画面です。

すべての経路でテスト予約を行う

リスクの低い将来の日付を使い、開始時の在庫、料金、販売制限、公開合計額を記録します。その後、直接予約、Airbnb予約、Booking.com予約を少なくとも1件ずつ実行します。

各予約について、PMS上の客室タイプ、料金プラン、日付、宿泊者、予約元、外部ID、料金、決済状況、ポリシーを確認します。公式サイトと両OTAで在庫が減ることも確認します。

対応している場合は日付と宿泊人数を変更します。予約をキャンセルし、PMSの既存レコードが重複なしで変更され、在庫が1回だけ正確に戻ることを確認します。

最後の1室は個別にテストします。残り1室にして予約を完了し、全チャネルで販売停止になることを確認します。実在客室の在庫グループごと、および特殊な販売制限や決済条件を持つ料金ごとに繰り返します。

予約ID、タイムスタンプ、スクリーンショット、期待結果、実際の結果、解決メモを保存します。修正後は循環全体を再テストします。

運用開始後の同期を監視する

最初の48時間は、新規・変更・キャンセルされたすべての予約と、今後30日分の在庫を確認します。販売集中時には障害ログを複数回確認します。

安定後はアラートを毎日監視し、公開料金と客室在庫を定期監査します。客室の追加・改名、料金追加、人数別料金や販売制限の変更、新しいOTA接続、チャネルマネージャー変更時は再テストします。

障害を原因別に記録します。マッピングエラー、手動上書き、キャンセル欠落、古い在庫、料金拒否の繰り返しは、偶然ではなく設定または管理責任の問題です。

よくある質問

ホテル公式サイトをAirbnbやBooking.comと直接同期できますか？

通常、公式サイトの予約エンジンをPMSとチャネルマネージャーに接続し、対応するOTA接続を管理します。Booking.comはチャネルマネージャー経由を案内し、Airbnbは承認済みPMSまたはチャネルマネージャーとの接続に対応しています。

直接予約の後、何が更新されるべきですか？

予約がPMSに登録され、正しい客室タイプの在庫が減り、運用カレンダーが更新され、Airbnb、Booking.com、その他の接続済みチャネルに新しい在庫数が送信される必要があります。

料金はすべてのチャネルで同一にする必要がありますか？

いいえ。直接予約向けプラン、チャネル別調整、OTAプロモーションを利用できます。オーナーは意図する関係を定め、最終表示される合計額、ポリシー、販売制限を確認します。

iCalだけで二重予約を防げますか？

iCalはカレンダーの販売停止情報を交換できますが、その範囲と更新動作は完全なAPI接続とは異なります。タイミング、項目、制限事項を確認し、料金や詳細な販売制限まで同期されるとは考えないでください。

OTA同期はどのくらいの頻度でテストすべきですか？

運用開始前と、客室、料金、販売制限、宿泊人数、マッピング、連携を変更するたびにテストします。アラートを毎日監視し、最後の1室も定期的に確認します。

1つの在庫情報源、3つの販売チャネル

確実な同期には、1つの実在客室在庫構造、承認済みマッピング、明確な料金管理責任、対応する接続、確認可能な障害対応が必要です。

公式サイトを別カレンダーではなく実際の販売チャネルとして扱います。すべての予約が同じPMSレコードに登録され、AirbnbとBooking.comの在庫を更新すれば、手作業や回避可能な過剰販売リスクを増やさずに直接予約を伸ばせます。