予約表では空室なのに、まだ案内できない部屋。客室清掃と予約のつなぎ方

たとえば、チェックアウトを受け付けた部屋へ、次のお客様を案内してよいでしょうか。予約表では空いていても、清掃前なら案内はできません。清掃が終わった後も、施設で決めた点検とフロントの承認が必要です。退室、清掃、点検、停止理由の解消、最新の予約割当の照合を経て、フロントが案内を承認します。部屋だけでなく、人や設備もまとめて押さえる予約の重なりは、人・部屋・設備の二重予約を防ぐ方法で扱っています。

8室の連絡を例に、担当ごとの次の作業を見ていきます（想定例）。時刻は2026年9月15日・日本時間です。施設の清掃規程やチェックイン手続きに合わせて使ってください。

13時の201号室と203号室は、どちらも退室・清掃済みです。それでも、次のお客様を案内できるかは違います。

13時に分かっていること	201号室	203号室
清掃後の点検	12:25に確認済み	未確認
フロントの案内承認	12:30に承認済み	保留
次の担当がすること	到着時に予約と部屋を照合して案内	確認担当が点検し、フロントへ結果を渡す

予約の空きと、お客様を案内できる部屋の違い

予約は「誰が、いつ、どの部屋を使う予定か」、在室は「その部屋を宿泊客が利用中か」、清掃は「どこまで作業したか」、確認は「誰が結果を点検したか」です。在室には外出中の宿泊客も含め、目の前に人がいないことを退室と取り違えないようにします。

Oracleの旧版資料「Using the Housekeeping Board」では、Clean（清掃済み）とInspected（責任者による確認済み）が別の状態です。Inspectedは設定を有効にした場合の任意の状態で、Dirtyは清掃が必要な状態を示します。「清掃中」「当日清掃不要」や以下の担当分担は、この概念を参考にした運用案です。

一覧は部屋IDを軸にし、利用中・直前の予約IDと次回の予約IDを分けます。宿泊日と割当の変更履歴も残します。表1・表2は同じ13時の情報です。予約上の空きと、現場の準備が済んだ部屋を見比べてください。

ほかの部屋も、停止理由と次の担当を同じ13時の時点でそろえます。

表1　架空8室の客室状態と案内判定（13:00）

予約IDの左側は利用中、退室後は直前の予約です。208は入室後のR906です。在室の部屋は清掃済みでも新しい宿泊客へ案内できません。

部屋IDごとの確認者・変更・不備を見る

表2　同じ8室の確認者・次回到着・変更・不備・忘れ物（13:00）

部屋ID	確認者・時刻	次回到着	変更	不備	忘れ物
201	確認担当A 12:25	15:00	なし	なし	なし
202	未実施	16:00	12:40 退室を反映	未点検	未点検
203	未実施	15:00	なし	なし	F001 充電器／12:00保管済み・返却未了
204	未実施	未割当	08:30 清掃不要を確定／08:35 清掃側受領	報告なし	対象外（滞在中）
205	確認担当A（失効） 11:20	未割当	12:50 次回R904を206へ変更	M001 水漏れ／未解消	なし
206	確認担当B 11:35	15:30	12:50 次回R904を205から受入れ	なし	なし
207	未実施	17:00	12:35 清掃開始	未点検	未点検
208	確認担当B 12:05	なし（入室済み）	12:30 早着承認／12:50 R906入室	報告なし	対象外（滞在中）

「未割当」は次の予約が部屋に割り当てられていない状態です。「未点検」「報告なし」は不備・忘れ物の有無を調べる前の情報です。205の11:20の点検は、水漏れ発見後に失効しています。

清掃から点検、フロントへどう渡すか

201号室は、フロントの退室受付から清掃、点検、案内承認へと、次の図の順に受け渡しています。清掃担当が完了を押した時点では、確認者欄は空欄のままにします。

確認担当は、施設で決めた点検項目と、不備や忘れ物が客室内に残っていないかを確かめます。小規模施設で担当を兼ねる場合も、作業完了と点検の記録は分けます。203号室は12:20に清掃済みでも、13:00には点検前なので保留です。担当の引継ぎ時刻になったら、次の点検担当へ渡します。

更新時には部屋ID、予約ID、状態、時刻、更新者、引継先を残し、受け手が変更を見たことも記録します。通信が切れている、在室情報が食い違う、更新日時が古い場合は案内を保留し、現地とフロントで突き合わせてから記録を直します。

図1　201号室を案内できるまでの受け渡し（想定例）

連泊・早着・部屋変更が入ったら

204号室はR804が連泊し、当日清掃不要です。8:30にフロントが確定し、8:35に清掃責任者が受領しました。部屋は引き続き宿泊客が利用中です。清掃を省く対象日と受領者を記録し、翌日以降まで不要として扱わないようにします。清掃不要と、入室を控えてほしいという意思表示も分けて扱います。

早着の希望を受けたら清掃の優先順を見直し、点検は通常どおり行います。208号室では到着希望を15:00から12:50へ変更し、客室準備と施設の早着条件を照合して12:30に承認、12:50に入室を記録しました。13:00には在室なので、再び案内可として表示しません。

205号室で水漏れが見つかったため、到着前の予約R904を12:50に206号室へ割り当て直します。旧室・新室・予約ID・変更日時を一組で残し、清掃側が12:52に受領、フロントは12:55に再照合して206を案内可にします。205の停止は維持します。滞在中の部屋移動なら、旧室の実際の退出と新室への入室も別々に記録します。

15時にどう変わったか：13時の判定と混ぜない

部屋IDごとの10時・13時・15時の経過を見る

表3　8室の10:00・13:00・15:00の推移

部屋ID	10:00	13:00	15:00
201	退室済み・未清掃	案内可／R901 15:00	R901入室済み
202	R802在室	退室済み・未清掃	案内可／R902 16:00
203	R803在室	清掃済み・未確認	R903入室済み
204	連泊・当日清掃不要	R804在室・清掃不要	R804在室・清掃不要
205	退室済み・清掃中	水漏れ・案内停止	水漏れ・案内停止
206	退室済み・清掃中	案内可／R904 15:30	案内可／R904 15:30
207	R807在室	退室済み・清掃中	案内可／R905 17:00
208	退室済み・清掃中	R906入室済み	R906在室

15:00の列は、13:00の後に起きた出来事を示します。202の14:30の承認、203の13:20の承認等を、13:00の判定に先取りして使わないでください。詳しい更新順序はExcelの「時系列_記入例」「更新履歴」に載せています。

不備の解消と、忘れ物の返却を追う

不備は「205・11:30・確認担当A・水漏れM001」のように部屋、発見時刻、報告者、管理番号を結び付け、写真や修理担当、入室停止の要否を記録します。修理後の点検者と停止を解除する担当を決め、報告と解消は別々に記録します。205のように一度確認済みでも、新しい不備が出たら要再確認へ戻します。

Oracleの同資料では、Out of Serviceは入室に利用できなくても販売在庫に残り得る一方、Out of Orderは割当対象と販売在庫から外れる状態として区別されています。各機能の有効化が条件です。利用中の宿泊管理ソフトでの設定と販売への影響を調べ、設備停止を単に「空室」へ置き換えないようにします。

忘れ物も報告と返却を分けます。203号室では11:50に充電器を発見し、12:00にフロント担当が受け取り、所定の棚で保管した設定です。部屋内から回収済みでも返却は未了です。客室の案内判定と忘れ物案件の完了を分け、保管・連絡・返却の記録を別に管理します。写真や氏名などは必要な担当者だけが見られる運用にします。

既存の宿泊管理と清掃の記録をつなぐ

まず、現在の宿泊管理ソフト（PMS）で必要な状態、確認者、変更履歴を扱えるかを調べます。標準機能で担当者間の受け渡しまで成立するなら、その機能を使って運用を整えられます。次の比較は、連携方式を選ぶ際の比較項目です。

方法	向いている条件	情報を確定する場所と更新方法	見ておく弱点
既存PMSの標準機能	在室・清掃・確認・変更履歴を必要な担当が扱える	PMSで確定。独自表は参照用に限定	施設の設定、権限、変更受領、停止理由の表現
CSV等の受渡し	即時性を要さず、更新間隔と担当を固定できる	予約はPMS。清掃結果を決めた担当が取込み・照合	出力日時、取込漏れ、上書き、次回更新までの遅れ
API等の追加連携	PMSを残し、現場入力や受領の記録だけ補う	項目ごとに更新元を一つに決める	接続許可、ID・更新順序、重複、失敗時の再送と通知

CSVは表のデータを受け渡すファイル、APIはソフト同士で情報をやり取りする方法です。個別PMSの接続可否は、製品の仕様と契約で調べてください。

連携を足す場合は「予約と割当はPMS」「清掃の入力は現場画面」など、項目ごとに正しい情報を確定する場所を決めます。部屋IDと予約IDに加え、宿泊日、変更日時、必要なら更新番号を渡し、古い変更で新しい状態を上書きしないようにします。清掃状態と設備停止が別項目なら、片方の完了でもう片方を解除しません。

客室状態の記入例と空欄票（Excel）には、室状況・時系列・更新履歴・引継チェックを収録しています。未記入版へ実際の担当と点検条件を当てはめて使ってください。案内判定は人が入力し、数式は入力の矛盾を知らせる補助です。PMSへの接続や自動取得は設定していません。客室状態の引継ぎチェック表（PDF）には記入例と未記入版を用意しました。

運用開始前には、部屋変更、連泊清掃不要、設備不良、連携停止を試します。「203号室は清掃済み」だけで終わらず、「確認担当の点検待ち。結果をフロントへ渡す」と表示できれば、交代した担当者も次の作業を判断できます。

まず清掃が終わった一室を選び、点検した人と、次のお客様を案内できるかが一覧で分かるかを見てください。

部屋変更の受領や清掃結果の戻し方が既存機能だけでは合わない場合は、利用中のPMS名、出力できる項目、8室の記入例を基に、必要な範囲を整理できます。連絡表の整備、既存宿泊管理の利用、受け渡しの開発を比較して選べます。

リネンの回収と納品も担当する場合は、輸送中や洗い工程の数量まで同じ時点で見比べます（リネンの数量確認｜回収・洗い・納品の差をたどる）。

ホテル・旅館の予約・客室・清掃連携の相談内容を見る

参考出典

• Oracle「Using the Housekeeping Board」：Room StatusのClean／Inspected／Dirty／Out of Service／Out of Order。URL上doc.201の旧版、発行日不明、確認2026年9月15日。状態の定義と設定条件を参照。担当分担・案内条件・8室のデータは、この状態の区別を参考にした運用例