旅館の宿泊管理システム｜一泊二食・部屋食・入湯税で変わる要件と既製＋カスタマイズの境界

旅館の予約1件とビジネスホテルの予約1件では、扱う情報量の違いが明確です。客室と宿泊者を押さえるだけでなく、夕食と朝食を何名分どこで出すか、部屋出しなら何時に誰が運ぶか、入湯税を何名分徴収するかまでが同じ1件にぶら下がります。この記事では、一泊二食・部屋食・仲居アサイン・団体バス・入湯税という旅館固有の要件を整理し、ホテル向けの宿泊管理システムでどこから合わなくなるかを具体化して解説します。客室10〜30室の小規模宿で成立する構成、製品タイプ3系統の見極め方、既製システムの設定で収まる線と受託開発に踏み込む線まで、受託開発会社としての判断基準が分かる内容です。

まとめ｜旅館の宿泊管理システムで先に決める食事管理とアサインの範囲

製品を並べる前に決めることが2つあります。食事の管理をシステムに載せるか、客室と担当者のアサインをシステムに載せるか。この2つを紙や口頭のまま残す前提なら、宿泊管理システムはホテル向けの標準的な製品で足ります。逆に、どちらか一方でも載せると決めた瞬間、候補は旅館特化型か、既製システムへの個別カスタマイズの2択に絞られます。

判断の順番はこうです。まず1泊の予約に紐づく情報を書き出す。夕食・朝食の会場と時刻、食事の枚数、アレルギーとお子様食、部屋出しの担当、入湯税の課税人数。次にそのうち何を転記作業で回しているかを数える。転記が月20時間を超えていれば、載せる価値があります。

費用は客室数課金だけで見ると、実際の総額を読み違える構造です。旅館は客室数が少なくても、食事・宴会・売店といった館内の売上区分が多く、オプション加算で総額が動きます。宿泊管理システムそのものの機能範囲やクラウド型の料金構造はホテル管理システム（PMS）の機能範囲と費用構成を整理した記事で扱っているため、この記事は旅館業態に固有の要件と、既製で収まるかどうかの線引きに絞ります。

ビジネスホテル向けPMSが旅館で合わなくなる、一泊二食と部屋食の管理単位の差

ホテル向けの宿泊管理システムは、1泊＝1室＝1料金という単位で設計されています。旅館はこの単位では収まらない業態です。どこでズレるのかを、予約情報の粒度から順に見ていきます。

宿泊人数ではなく食事枚数と時間帯で動く、旅館の予約情報が持つ粒度

一泊二食の宿では、予約が入った時点で確定させる数字が3種類あります。宿泊人数、夕食の枚数、朝食の枚数です。この3つは一致しません。3名の予約でも、幼児1名が食事なしなら夕食は2枚、朝食は3枚といった組み合わせが日常的に発生します。

ホテル向けの製品では、この差を備考欄のテキストで持つことになります。備考欄に入った情報は集計できません。調理場が翌日の仕込み数を出すには、結局その日の予約を1件ずつ開いて数えることになり、システムを入れても紙の食事表が残ります。

旅館向けを名乗る製品が持つのは、予約明細の下に「食事区分×人数×時間帯」を独立した行として持つ構造です。夕食18時30分から2名、夕食19時から4名、朝食8時から6名という粒度で入っているから、日別・時間帯別の枚数がボタン1つで出ます。見積の前に確認すべきは機能名ではなく、この行がデータとして独立しているかどうかです。

部屋食と食事処の切り替えで生じる配膳計画と、客室アサインへの逆流

部屋食を提供する宿では、食事の会場が客室そのものです。ここで在庫の考え方が反転します。ホテルでは客室を決めてから付帯サービスを決めますが、部屋食の宿では「部屋出し対応が可能な客室か」「配膳の動線に無理がないか」が客室アサインの制約になります。

実務で詰まるのは繁忙日です。2階の3室が同時刻に部屋食を希望した場合、配膳が回りません。時刻を30分ずらすか、1組を食事処へ振り替えるか、客室を分散させるか。この調整を成立させるには、客室アサインの画面から食事の時刻と会場が同時に見えている必要があります。

会場と客室が別画面に分かれている製品では、この調整が人の頭の中に残る状態です。結果として、システム上は空室でも実際には受けられない日が生まれ、販売可能在庫が実態とずれていきます。部屋食を主力にする宿ほど、この一点で製品の適合が決まります。

素泊まり・子ども料金・連泊で崩れる料金マスタと、プラン設計の持ち方

旅館の料金は、客室料金と食事料金が分かれた構造をしています。同じ客室でも一泊二食と素泊まりで金額が変わり、子ども料金は「大人に準ずる」「お子様食」「布団のみ」「添い寝」で4段階に分かれるのが一般的です。連泊では2泊目の夕食を変える宿もあります。

この構造を、客室単価に人数を掛ける料金マスタへ押し込むと、プラン数が組み合わせの数だけ増えます。子ども区分4段階×食事3パターン×客室タイプ5種類で60プラン。改定のたびに60件を手で直すことになり、OTA側の登録も同じ数だけ膨らみます。

持ち方の判断基準は、料金を構成する単位です。料金を「客室料金＋食事料金＋付帯」の加算式で組める製品なら、改定は食事料金の1行で済みます。加算式を持たない製品を選ぶなら、プラン数を先に絞る運用側の決断が必要です。どちらも取ろうとすると、稼働後にプラン整理の作業が毎シーズン発生します。

旅館・小規模宿の宿泊管理システムに求める機能範囲と、館内業務を含む線引き

旅館の宿泊管理システムは、フロント業務の外側まで守備範囲が広がります。ただし全部を載せる必要はありません。載せる価値が高い順に見ていきます。

仲居・客室係の担当アサインと引き継ぎを、システムに載せる範囲の見極め

担当制を敷く宿では、客室ごとに仲居・客室係を割り当てます。この情報がシステムに乗ると効くのは、当日の割り当てそのものより、引き継ぎのほうです。前回の滞在で何を聞いたか、常連客の食事の好み、記念日の申し送り。これらが顧客台帳に紐づいていれば、担当が変わっても対応の質が落ちません。

一方で、シフト作成まで同じシステムに載せるかどうかは慎重な判断が必要です。旅館のシフトは、料飲・客室・フロント・調理で勤務時間帯が別々に動き、中抜け勤務も入ります。宿泊管理システムのシフト機能は日別の人数配置を前提にしたものが多く、中抜けや複数部門の兼務を表現できないことがあります。

線引きの目安は、勤怠の締めを誰がどこでやっているかです。給与計算まで既存の勤怠システムで完結しているなら、宿泊管理システム側に持たせるのは客室担当の割り当てと申し送りに留めるほうが、二重入力を増やさずに済みます。

調理場への食事予定連携で必要な、アレルギー・お子様食・部屋出し時刻の粒度

調理場が翌日までに知りたいのは4つです。何名分か、何時か、どこへ出すか、通常と変える必要がある膳はどれか。この4点が揃った一覧が前日夕方に出れば、食事表の手書きは消えます。

実装例としては、陣屋コネクトが料理予定表のデジタル化とデシャップ機能を公開しています（2026年8月時点の公式サイト記載）。デシャップは配膳と下膳の進行を管理する機能で、部屋食の時刻がずれた場合に調理場と客室係が同じ画面で状況を見られる作りです。旅館特化型が館内業務まで守備範囲を広げているのは、この連携部分に価値があるためです。

アレルギー情報の扱いには注意が要ります。備考欄のテキストで持つと、当日の膳と突き合わせる作業が人の目に依存します。アレルゲンを選択式の項目として持ち、食事一覧に色や記号で出る作りかどうか。ここは見積前にデモ画面で実物を見て確認する箇所です。

入湯税150円の特別徴収と月次申告に必要な、人数集計と免除区分の管理

温泉地の旅館は入湯税の特別徴収義務者になります。入湯税は鉱泉浴場の所在市町村が入湯客に課す目的税で、標準税率は1人1日150円（地方税法第701条）。宿の側が宿泊料金と一緒に預かり、市町村へ納入します。

システム要件になるのは免除区分です。小田原市の条例を例に取ると、宿泊入湯客150円・日帰り入湯客100円という区分に加え、12歳未満、共同浴場・一般公衆浴場の利用者、入湯料金1,200円以下（税別）の施設利用者、学校行事の生徒と引率者などが免除対象として定められています（小田原市公表）。つまり宿は、宿泊者を課税・非課税で分けて数え、月次で申告する必要があります。小田原市の申告納入期限は毎月末日です。

ここを手作業で回すと、月末に宿泊者名簿から12歳未満を数え直す作業が発生します。予約時点で年齢区分を持ち、課税人数と免除人数が自動で分かれ、月次の集計表として出力できるか。温泉地の宿では、この1点が既製品の適合を分ける実務要件になります。宿泊税を導入している自治体では、これに加えて宿泊料金の区分ごとの税額計算が乗り、京都市のように改定が入ることもあります。税率区分をシステム側の設定で変更できるかは、契約前に確認しておく箇所です。

団体・バス手配と宴会場の在庫を、客室在庫と分けて持つべき条件

団体客を受ける宿では、1件の予約が客室10室と宴会場1室、バス2台の到着時刻に同時に紐づきます。客室在庫と宴会場在庫を同じ枠として持つ製品では、この関係を表現できません。

分けて持つべきかどうかの判断条件は明確です。宴会場を宿泊客以外にも販売しているか、または団体予約が月に数件以上あるか。どちらかに当てはまるなら、宴会・会議室の在庫は客室とは別のカレンダーで持つ構成にします。当てはまらない宿は、備考と手書きの台帳で回るため、この機能に費用を掛ける必要はありません。

バスの到着時刻は在庫ではなく、当日の運営情報として持ちます。到着が15時と18時では、チェックイン体制も夕食の開始時刻も変わるためです。団体名・人数・到着時刻・添乗員の連絡先が予約に紐づいて当日一覧に出れば、フロントと調理場の準備が揃います。

客室10〜30室の小規模宿で成立するシステム構成と、費用から逆算する導入範囲

小規模な旅館ほど、機能を足すより構成を絞るほうが成果が出ます。10〜30室の宿で何をシステムに載せ、何を載せないかを費用から逆算します。

客室数課金で旅館の費用が跳ねる構造と、10室規模で回収できる工数の目安

宿泊管理システムの料金は客室数課金が主流で、客室数の少ない旅館は一見すると安く収まります。跳ねるのはオプションのほうです。食事管理、宴会場管理、顧客台帳、レポート、OTA接続の追加。旅館が必要とする機能はオプション側に置かれていることが多く、基本料金の安さで選ぶと総額が読めません。

回収の目安は工数で見ます。10室の宿で、予約の転記・食事表の作成・OTA在庫の手動調整に月30時間を使っているなら、時給1,500円換算で月4.5万円分の工数です。ここに月額1〜2万円のシステムを入れて転記の8割が消えるなら、初期費用を含めても1年以内に釣り合います。逆に月10時間程度なら、投資回収は2〜3年かかる計算になり、導入は繁忙期の負荷軽減という別の理由で判断することになります。

製品別の料金水準と比較の軸は宿泊管理ソフトを6つの軸で比較した記事で整理しています。旅館側で先に固めるのは、オプション込みの見積を取ることと、客室数が増えたときの加算単価を契約前に確認することの2点です。

サイトコントローラーとの2本立てにする条件と、PMS単体で足りる販売経路

販売経路が楽天トラベルとじゃらんnetの2つ、月間の予約件数が100件未満という宿なら、各OTAの管理画面を直接触る運用でも回ります。在庫調整の手間はありますが、システムを2本持つ費用のほうが上回ります。

2本立てが要るのは、OTAが3つ以上ある宿、または自社サイトからの直販を伸ばしたい宿です。在庫と料金を1か所で持ち、各販売チャネルへ配分する仕組みがないと、繁忙期にオーバーブッキングが出ます。接続方式による在庫の持ち方の違いはサイトコントローラーのOTA在庫連動の仕組みを解説した記事で詳しく扱っています。

旅館固有の注意点が1つあります。プランの多さです。食事内容で分かれた多数のプランをOTAへ配信すると、連携の設定作業そのものが負担になります。2本立てにするなら、先にプランを整理してから接続する順番にします。

導入時に載せない業務の決め方と、紙台帳を残してよい3つの場面

一度に全部を載せる導入は失敗します。稼働直後の繁忙期に操作が定着せず、紙とシステムの二重運用に戻るためです。初期に載せるのは、予約・客室アサイン・食事枚数・会計の4つに絞ります。

紙のまま残してよい業務は、次の3つです。1つめは日次の清掃指示で、10室規模なら朝礼の口頭とホワイトボードで足ります。2つめは常連客の細かな申し送りで、担当者の手帳のほうが情報量が多い場合はそのまま並行させます。3つめは売店・自販機の売上管理で、宿泊会計と切り離せるなら別管理で構いません。

載せる業務を絞ると、稼働から3か月ほどで操作が定着します。定着してから清掃管理や顧客台帳を追加する順番のほうが、結果的に早く全体が乗ります。

旅館向け製品タイプ3系統と、比較段階で見落とされる旅館固有の確認項目

「旅館対応」と書かれた製品は多数ありますが、対応の中身は3系統に分かれます。どの系統が自宿に合うかを先に決めると、比較対象は絞れます。

旅館特化型・ホテル汎用型・小規模宿向けSaaSの3系統と適合する施設像

旅館特化型は、食事管理と調理場連携、客室係のアサインまで守備範囲に入る製品群です。一泊二食が主力で、客室20室以上、宴会や団体も受ける宿が対象になります。機能は揃いますが、費用は3系統で最も高く、導入時の設定作業も数か月単位で見る必要があります。

ホテル汎用型は、フロント業務の標準機能が厚く、食事管理は簡易またはオプションという構成です。素泊まりや朝食のみのプランが主体で、宿泊特化に近い運営をしている旅館に向きます。

小規模宿向けSaaSは、月額1万円前後で予約管理とOTA連携に絞った製品群です。客室10室前後、食事は固定メニューで枚数管理だけできれば足りる宿なら、この層で十分に回ります。

「食事管理に対応」の実体を見積前に確かめる4つの具体的な確認項目

製品ページの機能一覧では、食事管理の中身は判別できません。デモの場で確認する項目は4つです。

• 食事区分と枚数が、予約明細と独立した行として持てるか（備考欄ではないか）
• 日別・時間帯別の食事枚数を、集計表として出力できるか
• アレルゲンが選択式の項目で、食事一覧に記号や色で表示されるか
• 部屋食と食事処の会場区分を持ち、客室アサイン画面から同時に見えるか

4つのうち2つ以上が備考欄での運用になる製品は、旅館の食事管理には届きません。宴会場管理をオプションで持つ製品もあるため、団体を受ける宿は加算額も同じ場で確認します。

既製＋個別カスタマイズと受託開発の境界線と、旅館で踏み込むべき要件

ここが判断の本題です。旅館の要件は既製品から外れやすく、カスタマイズの相談に進むケースが多いのですが、踏み込む条件と見送る条件ははっきり分かれます。

既製の設定で収まる条件と、カスタマイズ費用が総額を逆転する分岐点

単一施設で、客室30室以下、食事のパターンが10種類以内、会計を宿泊と食事の2区分で締めている宿は、既製品の設定範囲で収まります。この条件下でカスタマイズを検討しているなら、要件ではなく製品選定を疑うほうが早い。系統違いの製品を候補にしている可能性が高いためです。

分岐点は費用の比率で見ます。既製システムの5年総額に対して、カスタマイズ見積が3割を超えたら判断を切り替えます。カスタマイズは初期費用だけでなく、製品側のバージョンアップのたびに追随費用が発生し、5年で見ると当初見積の1.5倍前後まで膨らむのが通例だからです。3割を超えるなら、その予算で要件に合う別製品を探すか、次のh3の条件に照らして受託開発を検討します。

カスタマイズを避けるべき箇所も明確です。予約データの構造そのものに手を入れる改修は、以後のアップデートを受けられなくなるため見送ります。帳票の追加や画面項目の増設に留まるものは、費用対効果が読める範囲です。

受託開発・アドオンに踏み込む3条件と、本部集計・自社会員基盤の要件

受託開発を選ぶ条件は3つあり、いずれか1つでも該当するなら検討する価値があります。

1. 複数館を運営し、本部で予約・売上・原価を横断集計する必要がある（既製品は単一施設単位の設計が多く、本部側の集計をExcelで再入力する運用になりやすい）
2. 自社の会員基盤やポイント制度を持ち、宿泊実績と会員情報を同じデータベースで扱う必要がある
3. 基幹会計や既存の顧客管理と双方向でデータ連携し、日次で締める必要がある

この3条件は、いずれも「既製品の外側にある業務」を指しています。宿泊管理そのものではなく、宿泊データを他の業務へつなぐ部分に要件が集中しているなら、既製PMSを土台に置いてAPI連携部分だけを開発する構成が現実的です。全部を作り直す必要はありません。当社でも予約管理システムの受託開発では、既製システムとの連携部分に限定した開発から、複数施設の本部集計を含む基盤の構築まで、要件の切り分けから相談を受けています。

受託開発を見送るべき場面と、刷新が失敗する旅館の共通パターン

単一施設・客室30室以下・年商規模が数億円までの宿で、システム刷新を自社開発で進めるのは見送るべきです。開発費が投資回収の範囲を超えるうえ、稼働後の保守体制を宿側で持てないためです。この規模なら、旅館特化型の既製品を選び、足りない帳票だけをアドオンで足す構成に収めます。

失敗するパターンは共通しています。現行の紙の運用をそのまま画面に写す要件定義です。旅館の帳票は、担当者ごとに書式が分かれたまま長く運用されていることが多く、それを全て再現しようとすると画面数と項目数が膨らみます。開発費が当初見積の2倍を超え、稼働時期が繁忙期にずれ込む。この経路をたどった刷新は定着しません。

先に決めるのは、やめる業務です。二重に付けている台帳、使っていない集計項目、部門ごとに分かれた同じ内容の帳票。これらを整理してから要件を起こすと、開発範囲は当初想定の半分程度まで落ちます。刷新の成否は開発の巧拙より、この整理を導入前に済ませたかどうかで決まります。

旅館の宿泊管理システムの費用・機能・導入に関するよくある質問

旅館の宿泊管理システムについて、選定の場で繰り返し出る質問をまとめました。

旅館の宿泊管理システムは、ホテル向けのPMSと何が違いますか？

守備範囲が館内業務まで広がる点が、ホテル向けとの違いです。ホテル向けは予約・客室在庫・チェックイン・宿泊会計が中心ですが、旅館向けは食事の枚数と時間帯の管理、部屋食の配膳、客室係のアサイン、宴会場の在庫、入湯税の課税人数集計まで扱います。1泊の予約に紐づく情報量が多く、それを備考欄ではなくデータ項目として持てるかどうかが分かれ目になります。

客室10室ほどの小規模な旅館でも、導入する価値はありますか？

判断基準になるのは転記作業の量です。予約の入力・食事表の作成・OTA在庫の調整に月30時間ほど使っているなら、月額1〜2万円の製品でも1年以内に釣り合います。月10時間程度なら投資回収は2〜3年かかるため、繁忙期の負荷やオーバーブッキングの防止といった別の判断理由が必要です。

入湯税や宿泊税の計算は、宿泊管理システムで対応できますか？

製品によります。入湯税は標準税率が1人1日150円（地方税法第701条）ですが、税率や免除の範囲は市町村の条例で定められ、小田原市では12歳未満や入湯料金1,200円以下の利用者などが免除対象です。予約時点で年齢区分を持ち、課税人数と免除人数を分けて集計し、月次の申告用に出力できるかを確認します。宿泊税を導入している自治体では、宿泊料金の区分ごとの税額計算が加わり、京都市のように税額が改定されることもあるため、設定で税率区分を変更できるかも合わせて確認します。

一泊二食の食事管理に対応する製品は、どのくらいありますか？

「対応」と書かれた製品は多数ありますが、中身は分かれます。食事区分と枚数を独立した行として持ち、日別・時間帯別の集計を出力でき、アレルゲンを選択式で管理し、部屋食と食事処の会場区分を持つ。この4点を満たすのは旅館特化型に限られるのが実情です。ホテル汎用型は備考欄またはオプション対応が中心で、集計まで届かないことが多いため、デモ画面での確認を見積前に行います。

既製システムのカスタマイズと受託開発は、どちらを選ぶべきですか？

既製システムの5年総額に対してカスタマイズ見積が3割以内なら既製＋カスタマイズ、超えるなら別製品の検討か受託開発へ切り替えます。受託開発に踏み込む条件は、複数館の本部集計、自社会員基盤との統合、基幹会計との双方向連携の3つです。単一施設で客室30室以下ならこの条件に該当しにくく、旅館特化型の既製品＋帳票アドオンに収めるほうが総額も保守負担も軽くなります。

関連記事

• ホテル管理システム（PMS）とは？フロント業務の機能範囲とクラウド移行・受託開発の判断基準：宿泊管理システム全体の定義・機能範囲・クラウド型とオンプレミス型の費用構成を整理しています。
• 宿泊管理ソフトの比較6軸と規模別の選び方｜失敗パターンと乗り換え判断：製品を比較する6つの軸と、選定で繰り返される失敗パターンを扱っています。
• サイトコントローラーとは？OTA在庫連動の仕組みとPMS・予約エンジンの役割分担：OTAとの在庫連動の仕組みと、1WAY・2WAY・3WAY連携の違いを解説しています。
• ホテル予約システムとは？機能・料金の選び方とOTA・PMS連携から見る自社開発の判断基準：販売側の予約システムに絞って、機能と料金の選び方を整理しています。