結論 PMSの選定基準は客室数ではなく運用の型で決まります。夜間体制・兼務の範囲・宴会や売掛の有無――この3問に答えれば、自館に合うシステムの型が絞れます。
根拠 同じ50室でも、夜間1人体制の施設と3交代の施設では障害時の対応力が違います。兼務の範囲が広い施設では画面遷移の少なさが死活問題です。客室数は料金の目安にはなりますが、運用への適合は決めません。
まずやること 3問の答えを整理し、候補2〜3社にデモを依頼します。デモでは自館の日常業務が標準機能で回るかを、台本を手元に置いて確認します。
位置付け PMS選定の規模軸です。会社の選び方は「会社」で選ぶ、費用の確かめ方は費用の内訳にあります。
確認する問い 答えの例(小規模) 答えの例(中規模) 選定で効くこと
夜間のフロント体制は? 1人。深夜帯はフロントと電話を兼務 2〜3交代。常時2人以上 障害時に1人で回せる仕組みとサポート体制
兼務の範囲は? フロント・経理・予約・仕入れを1人で フロントと経理は別の担当 画面遷移の少なさと操作の途中保存
宴会・団体・売掛はあるか? 宿泊のみ。売掛は旅行会社の数件だけ 宴会・団体あり。代理店10社以上の売掛 標準設定で足りるか、個別開発が要るか

300室未満の施設を想定。「小規模」は客室10〜50室、「中規模」は51〜300室の目安

「客室数」で絞ると、合わないシステムを引く

営業から届いたデモ画面を開く。「うちには大きすぎないか」。あるいは「50室以下はこちらのプランです」と案内され、客室数だけで候補が決まってしまう。

客室数はPMSの料金体系に使われる数字であって、運用に合うかどうかを決める数字ではありません。同じ50室でも、夜間にフロント1人で全業務を回す旅館と、フロント・経理・予約を分業するビジネスホテルでは、システムに求める条件が違います。

客室数でプランを絞った後に「運用してみたら合わなかった」が起きるのは、この食い違いが原因です。選定の起点は客室数ではなく、自館の運用の型です。

「50室以下向け」「100室以上向け」といった分類は、各社の料金プランの区切りです。自館の運用に合うかどうかは、その分類では分かりません。

夜間体制が1人なら、止まらない仕組みが先

深夜2時、チェックイン端末が固まる。フロントには自分1人。ゲストが目の前に立っている――この場面で何ができるかが、300室未満の施設にとっての最初の選定基準です。

クラウド型のシステムなら、フロントの端末が止まっても別の端末(事務室のPC・タブレット)からログインして業務を続けられます。ただしインターネット回線の障害には弱く、回線が切れると全端末が使えません。オンプレミス型は館内のサーバーで動くため回線障害に強い一方、サーバー自体が止まると予備機がなければ復旧まで手作業になります。

障害の種類 クラウド型の場合 オンプレミス型の場合
端末の故障 別端末でログインして継続 予備端末があれば継続。なければ手作業
インターネット回線の障害 全端末が停止。復旧まで手作業 館内サーバーで動き続ける
サーバー障害 提供元が復旧。自館では対応不要 保守会社に連絡。駆けつけ時間に依存

1人体制の施設は「自分1人で回せる障害対応」が選定の第1基準になります

サポート体制も確認します。夜間の電話サポートが契約に含まれるか、別料金か。リモートで画面を操作してもらえるか、電話での口頭案内だけか。1人体制の施設では、障害時に「電話で説明を聞きながら自分で操作する」余裕がありません。リモート操作で直接対応してもらえるかが分かれ目です。

夜間1人体制の施設が確認する項目

兼務の幅で、画面の限度が決まる

チェックインの処理をしている途中で、経理から「先月の売掛一覧を出して」と声がかかる。画面を切り替えて経理の帳票を開き、用が済んだらフロント画面に戻る。戻った時に、さっきの入力途中のデータが消えている――兼務の現場では日に何度も起きます。

フロント・経理・予約・仕入れを1人で兼務する施設が見るべきは、画面遷移の回数と、途中保存の仕組みです。分業が成り立つ施設なら「フロント画面が速い」だけで十分ですが、兼務の施設では「画面を行き来しても入力が消えない」ことが前提条件になります。

デモ時の確認台本

台本
「チェックインの入力を途中まで進めた状態で、売掛の残高確認画面を開いて、またチェックイン画面に戻った時に、入力した内容は残っていますか。実際にやって見せてもらえますか」
「予約の確認と日報の出力を同時にやることがあります。予約画面を開いたまま日報を出力できますか。タブやウィンドウを複数開いて同時に操作することはできますか」

デモではきれいに動いていた操作が、実際の現場では「ゲストが目の前にいる状態」で行われます。デモ時の台本は、自館の日常業務をそのまま再現する内容にします。カタログの機能一覧ではなく、日々の操作の流れで試します。

兼務が多い施設は「1日の操作の流れ」をメモに書き出してからデモに臨みます。朝の日報出力→チェックアウト処理→売掛確認→チェックイン→夜の締め処理――この流れが1つの画面体系で回るかを見ます。

宴会・団体・売掛がある施設は「設定の深さ」を先に聞く

「カスタマイズできますか」と聞けば、どの会社も「できます」と答えます。ただし「標準機能の設定でできる」と「個別開発になる」は、費用も納期もまるで違います。

宴会・団体の管理や、代理店ごとに締め日が異なる売掛の精算は、PMSの標準機能だけでは回らない場合があります。自館の運用が標準の範囲に収まるか、個別に作り込む必要があるかを、見積もりの前に切り分けます。

対応の層 内容 費用の目安
標準機能の設定 管理画面のパラメータ変更で済む範囲。料金体系の追加、帳票の出力項目の並び替えなど 追加費用なし、または定額
個別対応 標準機能の組み合わせと設定の工夫で対応する範囲。既存の帳票テンプレートの微調整など 作業費として数万〜十数万円
個別開発 自館のために画面や帳票を新規に作る範囲。団体の分割精算、代理店ごとの締め日管理など 要件次第で幅が大きい。過去事例を聞いて確認

「できます」の中身がどの層かを先に切り分けないと、契約後に費用の追加が出ます

電話で聞く台本

台本
「うちは団体の売掛を代理店ごとに月末締めと20日締めで分けています。この運用は標準機能の設定でできますか、個別開発になりますか。個別開発の場合、同じ対応をした宿泊施設の事例はありますか」
「宴会の仮予約を宿泊の予約台帳と連動させたいのですが、標準の設定で動きますか。宴会の見積書と請求書を自館のフォーマットで出力することは可能ですか」

過去に同じ対応をした施設の事例があるかどうかは重要な判断材料です。事例があれば費用と納期の見通しが立ちます。事例がない場合は、要件定義から始まるため、費用と期間が読みにくくなります。

「カスタマイズできます」と言われた時に「標準設定・個別対応・個別開発のどれですか」と聞き返します。この1問で費用の桁が変わります。

費用が合う規模帯を、見積書の前に確かめる

運用の型が自館に合っていても、費用が合わなければ導入できません。見積もりを取る前に、費用構造の大枠を押さえます。

クラウド型は月額が客室数に連動するプランが多く、客室数が少ないほど月額は低くなります。ただし月額が安いプランでは、OTA連携や決済端末との接続が別料金になっている場合があります。「月額○千円」の数字だけで判断すると、連携費の追加で実質コストが想定を超えます。

オンプレミス型は初期に機器購入とライセンスの費用がかかる代わりに、月額の負担が軽い構造です。5〜10年の総額で比較すると、客室数が多く連携先も多い施設はオンプレミス型の方が総額で下回る場合があります。

費用の内訳と比較の仕方は「費用の内訳」の記事にあります。見積もりを依頼する前に、6区分(初期・月額・連携・保守・カスタマイズ・移行)のどこに費用がかかるかを把握しておくと、見積書の読み方が変わります。

「安いシステムで十分」と判断するのは、自館の運用の型を3問で整理した後です。安さで選んだシステムに宴会・売掛の個別開発を追加すると、結局は高くつく場合があります。

自館の型が決まれば、候補は2〜3社に絞れる

冒頭の3問に答えると、自館がどの型に当てはまるかが見えます。

自館の型 特徴 合いやすいシステムの方向
小規模・兼務・宴会なし 客室10〜50室。フロントが全業務を兼務。宿泊のみ 操作画面がシンプルなクラウド型。月額が客室数連動で低く抑えられる
小規模・兼務・宴会あり 客室10〜50室。兼務だが宴会や団体の売掛がある 宴会・売掛が標準設定で動くかが分かれ目。個別開発が要ると費用が跳ねる
中規模・分業・宴会なし 客室51〜300室。フロントと経理が分業。宿泊主体 端末台数と同時接続に強いシステム。夜間サポートの有無で差がつく
中規模・分業・宴会あり 客室51〜300室。分業体制で宴会・団体・売掛の運用が複雑 作り込みに応じられる会社。過去の類似事例と移行実績の数で選ぶ

4つの型はあくまで入口の分類です。デモで自館の業務を試して合うかどうかの最終判断をします

開業間もない小規模施設で、業務の手順がまだ固まっていない場合は、設定変更が容易なクラウド型から始めるのが合います。宴会・団体・売掛の固有運用が長年積み上がっている施設は、その運用を標準設定で再現できるか、個別に作り込めるかで候補が絞れます。

不向きな組み合わせもあります。「安いクラウド型を入れて、後から宴会の個別開発を足す」は、個別開発費がクラウド型の月額の安さを打ち消します。逆に、「宿泊のみ・兼務・宴会なし」の施設がオンプレミス型の大規模システムを入れると、使わない機能の初期費用と保守費用を払い続けます。

候補が2〜3社に絞れたら、各社にデモを依頼します。デモの場に冒頭の3問と本文の台本を持ち込み、自館の日常業務が標準機能で回るかを目の前で確認します。デモで確かめられなかった項目は、そのまま見積もり依頼の条件に入れます。

よくある質問

客室数が少ないほうがPMSは安くなりますか?
月額が客室数に連動するプランなら少ない方が安くなります。ただし宴会・売掛の管理や個別の帳票が必要な施設では、客室数が少なくてもカスタマイズ費用が加わるため総額が上がります。客室数だけでなく運用の内容で見積もりを取ります。
夜間にフロントが1人の場合、PMSに求める条件は何ですか?
システム障害が起きた時に1人で対応を続けられる仕組みが最優先です。クラウド型なら別の端末からログインできるか、オンプレミス型なら予備機があるかを確認します。加えて、夜間帯の電話サポートが契約に含まれるかも聞きます。
フロント・経理・予約を1人で兼務しています。PMSで気をつけることは?
画面の切り替え回数が少ないシステムを選びます。チェックイン処理の途中で経理画面に移り、戻った時に入力が消えるシステムは兼務の現場では回りません。デモの時に「チェックイン中に売掛の確認画面を開いて、戻った時に入力が残るか」を実際に試します。
小規模旅館でもPMSは必要ですか?
OTAからの予約を受け付けている施設なら必要です。サイトコントローラーとの連動がないと、予約の二重取りや在庫の手動更新が日常の作業になります。客室数が10〜30室でも、OTA連携と顧客台帳の管理はシステムに任せた方が事故が減ります。
宴会や団体の管理がある施設は、どこに注意して選びますか?
「団体の売掛を代理店ごとに締められるか」「宴会の仮予約を宿泊と連動できるか」を標準機能の設定でできるか、個別開発になるかを先に聞きます。個別開発になる場合は、同じ対応をした施設の事例があるかも確認します。事例がなければ開発コストが読みにくくなります。
300室未満の施設がPMSを選ぶ際の最初の一歩は?
夜間体制・兼務の範囲・宴会と売掛の有無の3問に答えることです。この3問で自館の運用の型が決まり、候補が2〜3社に絞れます。その上で各社にデモを依頼し、自館の日常業務が標準機能で回るかを実際の画面で確かめます。

出典

  1. ビジネスブレーン 導入フロー
    https://miyako.com/services/flow/ (取得日: 2026-08-10)
  2. ビジネスブレーン フロントクルーBE 製品情報
    https://miyako.com/services/frontcrew-be/ (取得日: 2026-08-10)
  3. ビジネスブレーン フロントクルー都 製品情報
    https://miyako.com/services/frontcrew-miyako/ (取得日: 2026-08-10)

選定基準は300室未満の施設を対象にした一般的な整理です。個別の条件は各社にご相談ください。2026-08-10時点の情報です。