LASSIC Media らしくメディア
宿泊管理システム(PMS)の要件｜予約・客室・料金の一元管理
LASSIC IT事業部｜元請（プライムベンダー）として業務システムの開発・保守を受託
この記事のポイント
- 宿泊管理システム(PMS)は、予約(OTA・直販・サイトコントローラ連携)、客室在庫と料金、チェックイン/アウトと宿泊者名簿、清掃・請求・会計連携という宿泊業の運営に特化した仕組みで、事前予約を主とする汎用の予約管理システムとは扱う業務が異なります。
- 宿泊事業者には旅館業法第6条により宿泊者名簿の備付けが義務づけられ、令和5年12月13日施行の改正で記載事項は氏名・住所・連絡先(外国人は国籍・旅券番号)へと見直されたと厚生労働省などが示しています。
- 外注では、予約・客室料金・チェックイン名簿・清掃会計の対応範囲を切り分け、既存のサイトコントローラや会計との連携まで含めて確認できるかが分かれ目になります。
目次
宿泊運営が抱える課題——予約サイト・客室・会計に情報が分散する
ホテルや旅館などの宿泊施設では、一つの客室をめぐって多くの業務が時間差で発生します。複数の予約サイト(OTA)や自社サイトからの予約受付、客室在庫と料金の調整、チェックインとチェックアウト、宿泊者名簿の記録、客室清掃の手配、そして宿泊料金の請求と会計への反映です。これらが客室ごと・予約ごとに並行して動くため、稼働する客室数が増えるほど情報の突合が運営の中心的な負荷になりがちです。
表計算やホワイトボードに頼った運用は、規模が大きくなるほど手詰まりを起こしやすくなります。複数のOTAと自社サイトのそれぞれで在庫を手作業で更新していると、更新の遅れが重複予約(オーバーブッキング)や販売機会の取りこぼしを招きがちです。料金の設定も、繁忙期と閑散期でサイトごとに個別に書き換える運用では手間がかさみます。フロントでのチェックイン対応と宿泊者名簿の記録、清掃担当への客室状況の伝達、月末の売上集計と会計処理までが別々の台帳やツールに分かれていると、担当者の異動や繁忙期の増員のたびに引き継ぎが難航し、属人化も進んでいきます。
とりわけ神経を使うのが、宿泊者名簿の管理です。宿泊事業者には旅館業法にもとづく名簿の備付けが義務づけられており*1*3、記載事項や保存の扱いを運用に落とし込む必要があります。こうした予約から精算までの情報を一つの仕組みで束ね、宿泊業の流れに沿って扱えるようにするのが、宿泊管理システム(PMS)の役割です。
宿泊管理システム(PMS)とは——予約から客室・会計までを束ねる仕組み
宿泊管理システム(PMS。Property Management Systemの略)とは、宿泊施設の運営にかかわる情報と業務を一元的に管理するシステムを指します。予約の受付、客室在庫と料金の管理、チェックインとチェックアウト、宿泊者名簿の記録、清掃の手配、宿泊料金の請求と会計への連携までを、一つの流れとして扱えるようにするのが基本の考え方です。フロント担当者は画面上で予約状況と客室の空き、料金、宿泊者情報を突き合わせられるため、当日の客室割当から月次の売上集計まで一連の作業でつなげられるようになります。
土台になるのが、客室・料金・予約を関連づけて保持するデータ構造です。どの客室に、いつからいつまで、どのプラン・料金で、誰が宿泊するかを一元的に持つことで、在庫の販売、チェックインの受付、精算までが同じ情報を起点に進みます。予約情報と客室情報が別々に管理されていると生じがちな重複予約や転記ミスも、起点をそろえることで抑えやすくなるでしょう。
もう一つの柱が、外部サービスとの連携です。宿泊業では、複数のOTAへの在庫・料金の配信を束ねるサイトコントローラや、施設内の決済端末、会計システムなどと連動させて運営することが一般的になっています。観光庁も、宿泊業について生産性の低さと担い手不足が指摘されているとして、業務効率化の取組を支援する姿勢を示しており*5、システム化は業務の重複を減らす手立ての一つに位置づけられます。宿泊管理システムは、こうした外部サービスとの接続点を持ちながら、施設運営の中核データを保持する存在です。
なお、宿泊施設を営む事業者には、旅館業法にもとづく義務があります。同法第6条は、営業者に宿泊者名簿の備付けと、都道府県知事の要求があったときの提出を求めています*1*3。システム化にあたっては、こうした宿泊事業者としての義務を業務フローに織り込めるかどうかも、初期から検討したい観点になります。
汎用の予約管理システムとの違い——宿泊業の運営に特化する領域
当サイトでは、これまで汎用の予約管理システム(事前予約)も扱ってきました。宿泊管理システム(PMS)は、これと隣り合う領域に見えて、扱う業務は明確に別物です。似ているからと汎用の仕組みを流用すると、宿泊業に固有の要件が抜け落ちる原因になります。
汎用の予約管理システムは、来店予約やサービスの事前予約など、業種を問わず「時間枠や席を事前に押さえる」用途を広く扱います。予約カレンダーと空き枠の管理、予約者への通知が中心で、幅広い業務に使える反面、特定業界の運営業務までは踏み込みません。一方で宿泊管理システムが扱うのは、客室という宿泊業固有の管理単位と、そこに紐づく予約・料金・宿泊者・清掃・会計という、施設運営の一連の流れです。予約を「受け付ける」ところで完結せず、チェックインから退館後の精算までを運営する点が、決定的な違いになります。
この違いは、機能要件の細部にも表れます。たとえば宿泊管理では、単なる予約枠の管理にとどまらず、複数のOTAと自社サイトの在庫を同期させ、日ごと・プランごとに料金を出し分ける処理が必要です。チェックイン時には宿泊者名簿への記録という、汎用の予約管理にはない業務が加わります*1*2。退館時の精算も、宿泊料金に飲食や物販などの付帯売上を合算し、会計へ連携するところまでが業務範囲に含まれます。3つのシステムの主な違いを整理すると、次の通りです。
| システム | 主に扱う業務 | 中心となるデータ |
|---|---|---|
| 汎用の予約管理(事前予約) | 来店・サービスの事前予約、空き枠管理、予約者への通知(業種横断) | 予約枠・空き状況・予約者連絡先 |
| 顧客管理(CRM) | 顧客情報・対応履歴の蓄積とリピート施策への活用 | 顧客情報・利用履歴・販促 |
| 宿泊管理(PMS) | 予約(OTA・直販連携)、客室在庫と料金、チェックイン/アウトと名簿、清掃・請求・会計連携 | 客室・料金、予約・宿泊者、清掃状況、請求・売上 |
整理すると、宿泊管理システムに固有の要件は、(1)予約(OTA・直販・サイトコントローラ連携)、(2)客室在庫と料金(レートプラン・ダイナミックプライシング)、(3)チェックイン/アウトと宿泊者名簿、(4)清掃・請求・会計連携の4点に集約できます。汎用の予約管理や顧客管理の仕組みを転用しても、これらは埋まりません。「宿泊業のフロントから客室、会計までの運営」に特化した設計が要る点が、他システムとの分かれ目です。
機能要素の4本柱——予約OTA連携・客室料金・チェックイン名簿・清掃会計
宿泊管理システムを検討するときは、機能を4つの柱に分けて考えると整理しやすくなります。予約とOTA連携、客室在庫と料金、チェックイン/アウトと宿泊者名簿、そして清掃・請求・会計連携です。
予約・OTA連携——複数チャネルの在庫と予約を束ねる
1つ目が、予約の受付とチャネル連携です。宿泊予約は、複数のOTAと自社サイト(直販)、電話や店頭など、複数の経路から入ってきます。これらを個別に管理していると在庫更新が追いつかず、重複予約や販売機会の取りこぼしにつながりがちです。そこで、サイトコントローラ(複数のOTAへ在庫・料金を一括配信し、予約を取り込む仕組み)と連携し、各チャネルの在庫を一元的に同期させる構成が広く採られています。予約が入った時点で客室在庫を減らし、キャンセルがあれば戻すという反映を、経路をまたいで整合させられるかどうかが要点です。自社サイトからの直販予約を取り込むエンジンとの連動も、この柱に含めて検討します。
客室在庫と料金——レートプランとダイナミックプライシング
2つ目が、客室在庫と料金の管理です。客室のタイプごとに在庫を持ち、日付単位で販売状況を管理します。料金は、素泊まりや朝食付きといったレートプランを複数用意し、曜日や季節、予約の入り具合に応じて出し分けるのが一般的です。需要に応じて料金を変動させるダイナミックプライシングの考え方を取り入れる場合は、料金の算定ルールをどこまでシステムで支えるか、あるいは外部の料金設定サービスと連携するかを決める必要があります。設定した料金を、前述のサイトコントローラを通じて各チャネルへ齟齬なく配信できることも、あわせて確認したい要素になります。
チェックイン/アウトと宿泊者名簿——本人確認と法定記録
3つ目が、チェックインとチェックアウト、そして宿泊者名簿の記録です。ここには法令上の要件が関わります。旅館業法第6条は、営業者に対し、施設に宿泊者名簿を備え、宿泊者の氏名・住所・連絡先その他の事項を記載し、都道府県知事の要求があったときは提出することを求めています*1*3。記載事項は、令和5年12月13日施行の改正で見直され、従来の「職業」が削られ「連絡先」が加わりました*4。現在の記載事項は、氏名・住所・連絡先に加え、日本国内に住所を持たない外国人宿泊者についてはその国籍と旅券番号とされ、名簿は作成の日から3年間保存するものとされています*2*4。
システム側では、チェックイン時にこれらの項目を漏れなく記録し、保存期間の管理まで扱える設計が求められます。近年はチェックイン端末(セルフチェックイン)やスマートロックと連携する構成も見られますが、その場合でも宿泊者名簿の記載事項と保存の要件を満たせるかを起点に据えることが実務的です。個別の運用が法令の求めに合致するかは、所管の保健所や公式情報での確認を前提としてください。
清掃・請求・会計連携——客室整備から売上計上まで
4つ目が、清掃の手配と、請求・会計への連携です。チェックアウト後の客室は清掃を経て次の販売に回るため、清掃担当へ客室ごとの状況(清掃待ち・清掃済み・点検済み)を共有できると、当日の販売可否の判断がしやすくなります。会計面では、宿泊料金に飲食や物販などの付帯売上を合算して請求を作成し、退館時に精算します。ここで作成した売上のデータを会計システムや決済サービスへ連携できると、月次の集計や記帳の手間を抑えられるでしょう。宿泊業では日々の売上を客室・プラン単位で把握することが運営の基礎になるため、請求と会計の連携をどこまで仕組みで支えるかは、初期から設計に織り込みたい要素です。
外注で確認したい要件のポイント——対応範囲を切り分けて依頼する
宿泊管理システムの開発を外注する場合、依頼範囲の切り分けが要件定義の分かれ目になります。次の5点を確認しておくと、認識のずれを抑えられます。
第一に、予約とチャネル連携の範囲です。どのOTAや自社サイトの予約を取り込むか、サイトコントローラと連携するのか、在庫同期の反映をどの粒度で行うかを、早い段階ですり合わせます。第二に、客室在庫と料金の設計です。レートプランの持ち方、ダイナミックプライシングを内製の算定で扱うか外部サービスと連携するか、料金配信の経路を具体化しておきます。
第三に、チェックイン/アウトと宿泊者名簿の機能です。名簿の記載事項(氏名・住所・連絡先、外国人宿泊者の国籍・旅券番号)と保存の要件を満たせるか、セルフチェックイン端末やスマートロックと連携する場合の記録の扱いを確認します*1*2*4。制度の判断そのものは所管窓口の領域ですが、必要な記載事項を漏れなく記録・保存できる設計かどうかは、システムの要点です。第四に、清掃・請求・会計連携の範囲です。清掃状況の共有から付帯売上を含む請求、会計システムや決済サービスとの連携までをどこまで仕組みに載せるかを決めます。
第五に、公開後の保守体制です。OTAやサイトコントローラ、決済サービスの仕様変更、宿泊にかかわる制度の見直しに追随できる運用体制があるかを見ておきます。宿泊者名簿の記載事項が改正で見直された経緯もあり*4、業務フローの前提が変わる可能性は残ります。観光庁も宿泊業の業務効率化を支援する取組を示しており*5、こうした周辺の動きまで見据えて相談できる相手かどうかも、判断材料になるでしょう。
これらを一括で依頼するか、部分的に切り出すかは、客室数や既存システムの構成によって変わってきます。自社だけで要件を固め切るのが難しい場合は、要件整理の段階から相談できる相手を選ぶ方法が現実的です。あわせて、予約の取り込みから在庫同期、チェックイン、精算までが想定どおり動くかを検証環境で確認できる範囲を、契約段階で決めておくと、公開後の不安を抑えられます。連休や大型イベント時の予約集中は、実運用が始まってから初めて表面化しやすい論点になります。
まとめ：宿泊管理システム(PMS)の要件で押さえる3つの判断軸
本稿では、宿泊管理システム(PMS)の位置づけと機能要素、外注時の確認点を、旅館業法・厚生労働省の情報・観光庁の資料など公式情報をもとに整理しました。要点は次の3つです。第一に、宿泊管理システムは、予約(OTA・直販・サイトコントローラ連携)、客室在庫と料金、チェックイン/アウトと宿泊者名簿、清掃・請求・会計連携という宿泊業の運営に特化した仕組みで、事前予約を主とする汎用の予約管理とは扱う業務が異なります。第二に、宿泊事業者には旅館業法第6条により宿泊者名簿の備付けが義務づけられ、令和5年12月13日施行の改正で記載事項が氏名・住所・連絡先(外国人は国籍・旅券番号)へと見直されたと厚生労働省などが示しています*1*3*4。第三に、要件定義では予約OTA連携・客室料金・チェックイン名簿・清掃会計の対応範囲を切り分け、既存のサイトコントローラや会計との連携まで含めて確認することが、判断軸になります。
よくある質問
宿泊管理システム(PMS)と汎用の予約管理システムは何が違うのですか。
汎用の予約管理は、来店やサービスの事前予約を業種横断で扱い、空き枠管理と予約者への通知が中心です。これに対し宿泊管理システムは、客室を軸に予約とOTA連携、客室在庫と料金、チェックイン/アウトと宿泊者名簿、清掃・請求・会計連携までを扱います。中心となるデータも、宿泊管理は客室・料金・宿泊者・売上と異なるため、汎用システムの転用では固有要件が埋まりません。
宿泊管理システムでは宿泊者名簿をどう扱えばよいですか。
旅館業法第6条は、営業者に宿泊者名簿の備付けと、都道府県知事の要求があったときの提出を求めています*1*3。令和5年12月13日施行の改正により、記載事項は氏名・住所・連絡先(日本国内に住所を持たない外国人は国籍・旅券番号)へ見直され、名簿は作成の日から3年間保存するものとされています*2*4。システムでは、これらの項目の記録と保存を扱える設計が要点です。個別の該当可否は所管の窓口や公式情報での確認を前提にしてください。
複数のOTAの在庫はどのように同期するのですか。
複数のOTAへ在庫と料金を一括配信し、予約を取り込むサイトコントローラと連携する構成が広く採られています。予約が入った時点で客室在庫を減らし、キャンセル時に戻す反映を経路をまたいで整合させることで、重複予約や販売機会の取りこぼしを抑えやすくなります。どのOTAと連携するか、在庫同期の粒度をどうするかは、要件定義で具体化しておくとよいでしょう。
ダイナミックプライシングはシステムで対応できますか。
需要に応じて料金を変動させる考え方は、内製の算定ルールで扱う方法と、外部の料金設定サービスと連携する方法があります。いずれの場合も、設定した料金をサイトコントローラを通じて各チャネルへ齟齬なく配信できることが実務上の要点です。どこまでを自社で持ち、どこから外部に委ねるかを、レートプランの設計とあわせて整理しておくと判断しやすくなります。
外注する際に最初に確認すべきことは何ですか。
予約とチャネル連携の範囲、客室在庫と料金の設計、チェックイン/アウトと宿泊者名簿の記録・保存、清掃・請求・会計連携の範囲を、まず確認します。あわせて個人情報の取扱いにかかわる要件と、OTAや決済サービスの仕様変更・制度改定に追随できる公開後の保守体制も契約前にすり合わせておくと、後工程での手戻りを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：e-Gov法令検索「旅館業法（昭和二十三年法律第百三十八号）」第6条（ https://laws.e-gov.go.jp/law/323AC0000000138 ）
- *2 出典：e-Gov法令検索「旅館業法施行規則（昭和三十二年厚生省令第二十八号）」第4条の2（ https://laws.e-gov.go.jp/law/323M40000100028 ）
- *3 出典：厚生労働省「旅館業法」（ https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000130600.html ）
- *4 出典：大阪市「宿泊者名簿への記載事項について」（https://www.city.osaka.lg.jp/kenko/page/0000006422.html）
- *5 出典：観光庁「宿泊施設における生産性向上の促進」（ https://www.mlit.go.jp/kankocho/seisaku_seido/kihonkeikaku/jizoku_kankochi/kankosangyokakushin/saiseishien/seisanseikojo.html ）
