宿の予約をオンライン化しようと調べると、「予約エンジン」「サイトコントローラー」「PMS」という言葉が出てきます。サービスによって呼び方や機能範囲が違い、一つの製品が複数の役割を持つこともあるため、名前だけでは選べません。
先に整理すると、主な役割は次のとおりです。
- 予約エンジン：宿の公式サイトなどで予約を受け付ける
- サイトコントローラー：複数の販売先の在庫・料金・予約情報を同期する
- PMS：予約後の部屋割り、チェックイン、清掃、会計、顧客情報などを管理する
この記事では、小さな民宿、旅館、ペンションを想定し、現在の予約経路と日々の業務から必要な仕組みを判断する方法を説明します。
まず予約の流れを一枚で考える
旅行者
├── 宿の公式サイト ── 予約エンジン ─┐
├── OTA A ───────────────────────┤
├── OTA B ───────────────────────┼─ サイトコントローラー ─ PMS
└── 電話・メール ─────────────────┘ │
├─ 部屋割り
├─ チェックイン
├─ 清掃・食事指示
└─ 会計・顧客管理
これは役割を理解するための一般図です。実際には、予約エンジンとサイトコントローラーが一体になった製品、PMSまで含む統合型、電話予約をPMSへ直接入力する運用などがあります。
「三種類の製品を必ず別々に契約する」という意味ではありません。
予約エンジン：公式サイトで予約を受ける入口
予約エンジンは、自社予約システム、Web予約システム、ブッキングエンジンなどとも呼ばれます。宿の公式サイトに「空室検索」「予約する」ボタンを設置し、旅行者が日付、人数、部屋、プランを選んで申し込む場所です。
主な機能の例は次のとおりです。
- 日付と人数による空室検索
- 客室・宿泊プラン・料金の表示
- 予約者情報の入力
- 予約受付と確認メール
- キャンセル受付
- クーポンや会員向け料金
- オンライン決済
- 多言語表示
- 予約規約やキャンセル条件の表示
予約フォームとの違い
普通の問い合わせフォームでも「宿泊希望日」を送れますが、空室を確定する仕組みとは限りません。宿が返信するまで予約が成立しないなら、予約リクエスト受付に近い運用です。
予約エンジンでは、在庫と料金を参照し、その場で予約を確定できる構成が一般的です。ただし、サービスや施設の設定により「リクエスト予約」もあるため、成立時点を利用規約と確認メールで明確にします。
予約エンジンだけで足りる可能性がある宿
- 客室数が少ない
- 販売先が公式サイト中心
- OTAを使わない、または一つだけ
- 部屋割りや清掃管理は現在の台帳で足りる
- 予約情報を毎日人が確認できる
ただし、電話予約とオンライン予約の在庫を同じ担当者がすぐ更新できるかを確認してください。
サイトコントローラー：複数の販売先をつなぐ
OTAは、オンライン旅行会社や宿泊予約サイトを指します。複数のOTAと公式サイトで同じ客室を販売すると、それぞれへ在庫と料金を登録し、予約やキャンセルのたびに更新する必要があります。
サイトコントローラーは、複数の販売先をまとめて管理し、在庫、料金、プラン、予約情報などを連携する役割を持ちます。英語圏のサービスではChannel Managerと呼ばれることがあります。
二重予約を減らす仕組み
残り一室がOTA Aで予約されたとき、OTA Bと公式サイトの在庫も速やかに止められれば、同じ部屋を二人へ販売する危険を減らせます。
ただし、サイトコントローラーを入れれば二重予約が絶対に起きないわけではありません。
- 連携に時間差がある
- 対応していないプランや販売先がある
- 電話予約を入力し忘れる
- 部屋タイプの紐付けを間違える
- 通信障害やメンテナンスが発生する
- OTA側と施設側で在庫の単位が違う
導入時は、どの販売先と何がリアルタイム連携されるかを確認します。「連携可能」という表示だけでは、在庫、料金、予約、キャンセル、プラン、決済情報のすべてが双方向に動くとは限りません。
サイトコントローラーが必要になりやすい宿
- 複数のOTAで同じ客室を販売する
- 公式サイトの予約在庫もOTAと共通にしたい
- 料金や販売停止を複数サイトへ一括反映したい
- 予約通知の転記作業が負担になっている
- 在庫更新の遅れや入力ミスが増えている
PMS：予約後の宿泊業務を管理する
PMSはProperty Management Systemの略です。観光庁は顧客予約管理システムとも表現しており、宿泊施設の予約と館内業務を支える中心的なシステムです。
製品や施設規模によって機能範囲は大きく違いますが、例として次があります。
- 予約台帳
- 客室の割り当て
- チェックイン・チェックアウト
- 宿泊者情報と顧客履歴
- 清掃状況と客室状態
- 食事、アレルギー、送迎などの指示
- 売上、請求、入金、領収書
- 稼働率や売上のレポート
- 宿泊者名簿に関する業務
- 電子錠、POS、決済、会計などとの連携
PMSは予約サイトではない
PMSに予約台帳があっても、それだけで旅行者が公式サイトから予約できるとは限りません。予約エンジンやOTAからデータを受け取る連携が別に必要な場合があります。
反対に、予約エンジンに簡易な顧客管理やチェックイン機能が付いていて、小規模施設なら別PMSが不要な場合もあります。
PMSが必要になりやすい宿
- 客室数やスタッフ数が増え、紙や表計算では共有しにくい
- 予約後の部屋割り、食事、清掃、会計を連動させたい
- 電話、OTA、自社予約の情報を一つへ集約したい
- 複数スタッフ・複数施設で同時に確認する
- 顧客履歴や売上・稼働率を運営改善へ使いたい
三つの違いを比較する
| 観点 | 予約エンジン | サイトコントローラー | PMS |
|---|---|---|---|
| 主な利用者 | 予約する旅行者と予約担当者 | 販売・予約担当者 | フロント、清掃、会計、経営者など |
| 主な役割 | 公式サイトで予約を受ける | 複数販売先の在庫・料金・予約を同期する | 予約後の宿泊業務を管理する |
| 主な対象 | 日付、人数、プラン、予約者入力 | OTA・公式予約の在庫と販売情報 | 部屋割り、宿泊者、客室状態、会計など |
| OTAが一つでも必要か | 自社予約を受けるなら候補 | 手作業で足りるなら不要な場合もある | 館内業務の複雑さで判断 |
| 二重予約対策 | 自社在庫内では管理できる | 複数販売先の同期が中心 | 連携予約と電話予約をまとめる |
| 製品形態 | 単体または統合型 | 単体または統合型 | 単体または統合型 |
この表は一般的な役割です。製品名に「PMS」と書かれていても、サイトコントローラーや予約エンジンを含む場合があります。比較時は製品分類ではなく、必要な業務がどこまで含まれるかを確認します。
「どれが正本か」を決める
複数システムを連携するとき、同じ予約や在庫をどこで修正するかが曖昧だと、データが食い違います。
たとえば、次を導入前に決めます。
- 客室と部屋タイプはどこで作成するか
- 基本在庫はどこへ入力するか
- 料金とプランはどこを正本にするか
- 電話予約をどこへ最初に登録するか
- キャンセルはどこで受け、どこまで自動反映するか
- 宿泊者情報の訂正をどこで行うか
- 決済済み・未払いをどこで確認するか
- システムごとに異なる数字が出たら何を正しいとするか
「全部つながる」と説明されても、修正方向や反映時間まで同じとは限りません。連携図と運用手順をサービス提供者へ確認します。
小さな宿の選び方
段階1：現在の予約経路を書き出す
過去一か月または繁忙期を例に、次の件数と作業を書きます。
- 電話予約
- メール・問い合わせフォーム
- 公式サイト予約
- OTAごとの予約
- 常連客や旅行会社からの予約
- 当日予約と飛び込み
予約、変更、キャンセルのたびに、誰がどの台帳を何回更新しているかも記録します。
段階2：困っている作業を一つ選ぶ
目的が違えば、先に必要な仕組みも違います。
| 主な困りごと | 最初に検討する役割 |
|---|---|
| 電話しか受けられず、営業時間外の予約を逃す | 予約エンジン |
| OTAごとの在庫更新が負担、二重予約が不安 | サイトコントローラー |
| 予約後の部屋割り、清掃、会計の共有が煩雑 | PMS |
| 三つすべてが分断され転記が多い | 連携可能な組み合わせまたは統合型 |
「高機能なシステムを導入する」ではなく、「毎日発生する一つの転記をなくす」のように目的を具体化します。
段階3：必要最低限から構成する
客室が少なく、公式予約中心
予約エンジンと、電話予約をすぐ在庫へ反映する運用で足りる可能性があります。高機能PMSを入れても入力作業が増えるだけなら適しません。
複数OTAと公式サイトで販売
サイトコントローラーの優先度が上がります。利用中のすべてのOTAと予約エンジンが対応し、部屋タイプとプランを正しく紐付けられるか確認します。
複数スタッフで館内業務を共有
PMSを中心に、サイトコントローラーと予約エンジンから予約を集約する構成が候補になります。フロントだけでなく、清掃や食事担当が必要な情報を必要な範囲だけ見られるかも確認します。
一人または家族経営
機能数より、設定代行、電話サポート、障害時の代替運用、請求の分かりやすさを重視します。一人しか設定を理解できない状態を避けます。
比較前にサービス提供者へ聞くこと
連携
- 現在利用中のOTA、予約エンジン、PMSと連携できるか
- 在庫、料金、予約、変更、キャンセルのどれが連携対象か
- 一方向か双方向か
- 通常の反映時間と障害時の挙動
- 部屋タイプ、食事付きプラン、連泊、子ども料金を扱えるか
- 連携先を後から変更できるか
予約運用
- 予約が成立する時点
- オーバーブッキング時の責任分担と対応窓口
- 電話予約、休館日、貸切、部屋止めの登録方法
- キャンセル料と返金をどう処理するか
- 予約変更が各販売先へどう伝わるか
決済
- 現地決済とオンライン決済の両方を扱えるか
- 決済代行会社と契約主体
- 決済手数料、返金手数料、入金周期
- カード情報を宿側で保持しない構成か
- キャンセル・無断不泊時の請求手順
予約システムと決済システムは役割が異なります。予約エンジンに決済機能が付いていても、契約、手数料、入金、返金、本人認証の条件を別に確認します。
データと権限
- 宿泊者情報をどこへ保存し、誰が閲覧できるか
- スタッフごとに権限を分けられるか
- 操作履歴が残るか
- 退職者や制作会社のアクセスを外せるか
- データの保存期間と削除方法
- 契約終了時に予約・顧客・売上データを出力できるか
- 出力形式と移行支援の有無
障害とサポート
- 障害時に予約を受けられるか
- 在庫同期が止まったことをどう通知するか
- 夜間・休日の連絡方法
- 復旧後に予約の重複や欠落をどう照合するか
- 初期設定、データ移行、スタッフ研修を誰が行うか
- マニュアルがITに不慣れな人にも理解できるか
デモでは実際の一日を再現する
機能一覧を見るだけでなく、架空の予約を使って次を操作します。実在する宿泊者の情報はデモへ入力しません。
- 公式サイトから一室を予約する
- 他の販売先の残室が変わるか確認する
- 電話予約を追加する
- 日付、人数、食事、部屋を変更する
- 一件をキャンセルする
- 返金または現地精算の状態を確認する
- 部屋割りと清掃状態を共有する
- 予約一覧と売上を出力する
- スタッフ権限を変える
- 通信できない場合の代替手順を聞く
日常操作だけでなく、変更、キャンセル、障害という例外を試すと、実際の負担が分かります。
よくある選び方の失敗
月額料金だけで選ぶ
初期費用、予約手数料、決済手数料、連携追加、サポート、データ移行、端末費用を含めた総額で比較します。安くても転記作業が残るなら、人の時間とミスの費用が続きます。
機能数が多いほど安心だと考える
使わない機能が多いと、初期設定、教育、権限管理、障害箇所も増えます。現在の業務と一年後に必要な業務を分けます。
対応OTAの数だけを見る
自分の宿が実際に使うOTAと、必要なプラン・在庫単位で正しく連携できることが重要です。
電話予約を運用図へ入れない
オンライン在庫が同期されても、電話予約を誰も入力しなければ二重予約は防げません。常連客、団体、旅行会社、貸切も含めます。
契約終了時を確認しない
乗り換え時に顧客・予約データを出せない、過去帳票を見られない、ドメインや決済契約が提供会社名義だった、という問題を避けます。宿が継続管理する資産と解約手順を契約前に確認します。
導入前チェックリスト
- 現在の予約経路と件数を書き出した
- 予約・変更・キャンセル時の転記作業を把握した
- 最初に解決する困りごとを一つ決めた
- 予約エンジン、サイトコントローラー、PMSの必要な役割を分けた
- どのシステムを在庫・料金・予約の正本にするか決めた
- すべての販売先との連携項目と方向を確認した
- 電話予約と貸切の登録方法を決めた
- オンライン決済の契約・手数料・返金条件を確認した
- スタッフ権限、操作履歴、個人情報の保存先を確認した
- 障害時の連絡先と紙・表計算などの代替手順を用意した
- デモで予約、変更、キャンセル、返金を試した
- 解約時のデータ出力と移行条件を確認した
- 月額だけでなく総費用を比較した
AIへ比較を手伝わせるプロンプト
サービスの料金や連携先は変わるため、公式ページと見積書の確認日を記録します。管理画面のパスワードや実在する予約者情報はAIへ渡しません。
小さな宿の予約システム選定を手伝ってください。
最初に、次を質問して整理してください。
- 客室数と部屋タイプ
- 電話、公式サイト、利用中OTAごとの予約件数
- 現在使っている予約台帳、決済、会計システム
- 予約、変更、キャンセルで困っている作業
- スタッフ数と必要な権限
- 必要な多言語、決済、清掃、食事、帳票機能
- 月額だけでなく初期費用・手数料を含む予算
その後、必要な役割を
「予約エンジン」「サイトコントローラー」「PMS」「決済」へ分けてください。
製品を一律におすすめせず、公式情報で確認できた機能、未確認事項、
見積もり時に質問することを表にしてください。
実在する宿泊者情報、パスワード、カード情報は扱わないでください。
まとめ
予約エンジンは公式サイトで予約を受ける入口、サイトコントローラーは複数販売先の在庫・料金・予約を同期する仕組み、PMSは予約後の部屋割り、チェックイン、清掃、会計などを管理する基盤です。
製品によって機能は重なります。三つを別々に買うことから考えず、現在の予約経路、転記作業、館内業務を書き出し、最初に解決したい問題から必要な役割を選んでください。
導入の成否は機能数だけでなく、連携範囲、正本となるシステム、電話予約の入力、障害時の代替運用、契約終了時のデータ移行まで決められるかで変わります。
具体的な候補を同じ条件で比べる方法は、小さな宿の予約システム比較で解説しています。
参考資料
- 観光庁：宿泊施設のためのIT活用事例集
- 観光庁：宿泊施設のためのIT活用ハンドブック
- 観光庁：観光DX推進に向けたデジタルツールのデータ連携における標準化
- 手間いらず公式：PMSとサイトコントローラーの違い
- ルーム・マネージャー・セカンド公式：統合型宿泊システム
※製品の機能、料金、連携先は変更されます。契約前に各サービスの公式情報と個別見積もりを確認してください。
