予約を在庫として管理する｜一元化の前に決める売れる時間枠の設計

電話で受けた予約は台帳に書き、WEBの予約は別の画面で確認する。二重予約は防げても、この枠をあと何件売れるのか、どの枠をいくらで売るのかは、担当者の頭の中にある。

宿泊、体験、スクール、レンタル、サロンなど、時間や部屋・席・担当者を予約で売る業種で、少人数のまま複数の予約経路を管理している会社では、このような状態に心当たりはないでしょうか。

予約管理のDX（デジタルトランスフォーメーション）で予約を一元化しても、予約を「受付の記録」として持つだけでは、枠や価格、キャンセルの改善に使えるデータは残りません。しかし、予約を「売れる時間枠の在庫」として持てば、あと何枠売れるのか、いくらで売るのかを、データで判断できるようになります。

本記事では、観光庁が示した宿泊分野の項目分解を手がかりに、予約を日時・提供資源・チャネル（予約を受ける経路）・価格・状態の5項目で在庫として定義し、項目ごとの正本と、取消・販売停止の反映時点を決める手順を解説します。予約システムを比較する前に、自社で何を決めておけばよいかを整理できます。

二重予約の防止だけでは、予約の一元管理は終わらない

予約の一元化とは、電話、自社サイト、外部予約サイトなど、別々の場所に入る予約を、1つの画面や1つのデータにまとめて管理することです。予約を1つの画面に集めることは、二重予約を防ぐ第一歩です。

ただし、集めただけでは、あと何枠売れるのか、どの枠をいくらで売るのかという判断は変わりません。なぜでしょうか。予約の件数を数えることと、あと何枠売れるかを知ることは、別のことだからです。

この章では、予約の一元化で解決できることと、解決できずに残ることを分けて説明します。そのうえで、残る判断を支えるために、予約を件数ではなく「売れる枠の在庫」として数える考え方を示します。

受付の記録と、売れる在庫の違い

受付の記録は、誰が、いつ、何を予約したかを残したものです。予約の件数や顧客の情報は分かりますが、あといくつ売れるのかは、記録を眺めても分かりません。

売れる在庫は、これから売れる時間枠が何枠残っているかを示したものです。宿泊なら「今夜の空室は何部屋か」、サロンなら「この時間に施術できる枠は何枠か」にあたります。

この2つが別のものになるのは、予約1件が使うのが、1つの枠だけではないからです。サロンの施術なら、提供している間、担当者と席、必要な設備を同時に使います。準備と片付けの時間も、枠を消費するのです。この、提供に使う部屋・席・担当者・設備などを、ここでは資源と呼びます。件数が同じでも、消費する時間と資源が違えば、残る枠は違います。

たとえば、個室が1室、担当者が1人のサロンに予約が1件入ったとします。受付の記録に残るのは「1件」だけです。しかし在庫の側では、その時間の個室と担当者がふさがり、前後の準備と片付けの時間も売れなくなります。つまり、単純に件数を数えるだけではこの売れなくなった分が見えないのです。

一元化が解決する問題と、残る問題

二重予約とは、同じ枠に別々の経路から予約が入り、利用者が重なってしまうことです。電話の予約は台帳に、WEBの予約は別の画面にと、予約が別々の場所に入っていると、お互いの埋まり具合が分からず二重予約が起こり得ます。

反対に、電話、自社サイト、外部予約サイトの予約を1つの画面に集めると、どの経路から入った予約でも同じ画面で枠の埋まり具合を確かめられるため、二重予約は起こりにくくなります。これが、一元化で解決できることです。

ただし、一元化しても二重予約がなくなるわけではありません。システム間の同期には遅れがあり、手作業で入れた予約が反映されないこともあるからです。一元化しても、二重予約は起こり得るのです。

さらに、二重予約を防げたとしても、一元化だけでは次の判断が残ります。

この3つは、予約が1つの画面に集まっているだけでは答えが出ません。答えるには、予約を「何件入ったか」の記録ではなく、「どの時間枠の、どの資源が、いくらで、どの状態で埋まっているか」を数えられる在庫として定義し直す必要があります。

定義の方法は、次の章以降で順に説明します。まずは、電話・自社サイト・外部予約サイトの予約が、いまどこに記録されているかを書き出しましょう。

予約が消費する能力を、日時・提供資源・チャネル・価格・状態で定義する

予約1件が何を消費するのかを、どう分ければ売れる枠として数えられるのでしょうか。この章では、観光庁の項目分解を手がかりに、予約を5つの項目に分けて持つ方法を示します。

観光庁の標準データセットが示す項目分解

予約を項目に分ける考え方は、観光庁が公表した『観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査結果について』に見られます。顧客予約管理システム（PMS：Property Management System）と各種システムの連携仕様が標準化されていないことが、観光産業の生産性を下げる一因だとして、データ項目と形式をそろえる取組が進められています。この調査結果を掲載している観光庁のWEBページの更新日は、2026年3月30日です。

観光庁WEBページに掲載されている『標準データセット利用の手引き』では、予約情報（予約基本情報、宿泊期間、人数、料金プランなど）と客室情報（客室のタイプ、設備、ステータスなど）が分かれ、予約ステータスや、OTA（外部予約サイト）・旅行会社を識別する会社コードなども整理されています。つまり、自社の既存項目との対応表を作る考え方も示されているのです。

本記事では、この観光庁の分類をもとに、予約を日時・提供資源・チャネル・価格・状態の5項目に整理して解説します。5項目と、観光庁の資料で近い項目は、次のとおりです。

ただし、この資料の対象は宿泊施設のPMSです。体験、スクール、サロンなどの業種では、項目の名前をそのまま使うのではなく、自社の予約に合わせて読み替えます。読み替えの例は、次のとおりです。

つまり、観光庁の資料から借りるのは、項目の名前ではありません。予約を項目に分け、自社の予約の項目と対応づけていく進め方です。

5項目のデータ辞書

予約を5項目に分けても、「日時」や「状態」の欄に何を書くかが決まっていなければ、担当者ごとに書き方がばらつき、枠を数えられません。そこで、項目の名前と、それぞれに持たせる内容を、一覧表にして決めておきます。この一覧表を、データ辞書と呼びます。5項目のデータ辞書の骨格は、次のとおりです。

自社の予約を、この5項目に当てはめて書き出してみましょう。

出典・参照：

• 観光庁／観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査結果について（2026年3月30日）
• 観光庁／標準データセット利用の手引き（2026年3月16日）

項目ごとに正本と更新権限を決め、取消・販売停止の反映時点を揃える

5項目を決めても、運用では予約の内容が食い違うことがあります。電話の予約は台帳へ、WEBの予約は外部サイトへというように、経路ごとに別々の保管先へ予約が入っていると、同じ予約の内容が食い違ったときに、どちらが正しいのかを決められないからです。

そこで、項目ごとに、正しいデータの置き場所と、書き換えられる人を決めます。あわせて、取消や販売停止が起きたときに、いつ枠を戻し、いつすべてのチャネルへ反映するのかも決めます。この章では、この2つの決め方を順に説明します。

正本と書込み権限

正本とは、複数のデータが食い違ったときに、正しいと扱う元のデータです。次の表は、正本を決めるための記入例です。自社の運用に合わせて埋めてみてください。

この表の中身は、自社の運用に合わせて書き換えます。大事なのは、「反映の直後」「前日まで」のように、反映の時点を空欄にしないことです。

取消受付・返金・在庫復元は別のイベント

キャンセルを受けても、その枠をすぐ売り直せるとは限りません。キャンセルの処理は、取消の受付、キャンセル料の確認、返金、資源の解放（使っていた部屋や担当者を空きにすること）という、別々の出来事に分かれているからです。

どの出来事が済んだ時点で枠を売り直せるのかは、事業の取消条件によって変わります。たとえば、取消の連絡を受けた時点で売り直す設計もあれば、返金が済んでから売り直す設計もあります。

この、取消された枠を売れる状態に戻すことを在庫復元と呼びます。次の表は、4つの出来事と在庫への影響を整理した、事業ごとに決める項目の記入例です。

枠を戻す時点を決めないままだと、同じ取消でも、チャネルや担当者によって枠が戻る時点が変わってしまいます。つまり、枠を戻す時点を自社で1つに決め、資源が空きになった時刻を状態の項目に記録するのです。

販売停止の権限と全チャネルへの反映

設備の故障や担当者の欠勤で枠を売れなくなったとき、その枠への予約を止めることを、販売停止と呼びます。止める人が決まっていても、すべてのチャネルへ反映されるまでに時間がかかれば、その間に予約が入ってしまうこともあるでしょう。そこで、販売停止について、次の4つを決めておきます。

3で記録した2つの時刻の差を見れば、反映が遅れるチャネルが分かります。自社では、止める人と反映を確かめる人が決まっているでしょうか。

安全余白と、価格・キャンセル条件の表示を揃える

提供能力を使い切る売り方は、遅れや故障が起きたときに破綻します。余白を残す根拠と、利用者に見せる条件を、内部のデータと揃えます。

安全余白は業務別に決める

安全余白とは、予約を満席まで入れず、あえて残しておく余裕のことです。業務ごとに余白を必要とする理由が違うため、一律の割合は置かず、次のような理由から業務別に決めます。

余白の根拠と、決めた日を記録します。見直したときに、どの理由で余白を増減したのかをたどれるようにするためです。

価格・取消条件の表示と内部データを合わせる

利用者に見せる価格やキャンセル条件と、内部の価格・状態のデータがずれると、トラブルのもとになります。観光庁の『オンライン旅行取引の表示等に関するガイドライン』は、予約を完了する前に、キャンセル料の発生時点や金額、返金の方法などを分かりやすく表示する考え方を示しています。対象はオンライン旅行取引で、旅行以外のすべての予約に同じ義務があるわけではありません。

それでも、表示している条件と、内部の価格・状態のデータが一致しているかを確かめる視点は、どの業種でも使えます。動的に価格を変える場合は、表示の透明性、キャンセル条件、外部予約サイトの規約も確認が必要です。価格や取消条件を予約済みの利用者に不利に変えることは、避けるべきです。

効果を見る指標

定義した在庫の効果は、予約データから次の指標を集計し、月ごとに見ます。売上を見る指標と、現場の負担を見る指標があります。

一元化しただけでは、予約をまとめて確認する手間が減ったかどうかしか示せません。在庫として定義した予約データがあれば、一元化の前後で、稼働率や平均単価がどう変わったか、重複件数が減ったかを比べられます。手間の削減だけでなく、売上と現場の負担の両方で一元化の効果を説明できるようになります。

出典・参照：

• 観光庁／オンライン旅行取引の表示等に関するガイドライン（2015年6月）

まとめ：予約を在庫として定義してから、システムを選ぶ

予約の一元化は、予約を1つの画面に集めるだけでは終わりません。集めた予約を「売れる時間枠の在庫」として数えられるようにして初めて、あと何枠売れるのか、いくらで売るのかを、データで判断できます。

自社で決めることは、次の4つです。順に進めると、予約システムを比較する前に、自社に必要な条件を整理できます。

この4つが決まれば、一元化の成果は、手間の削減だけでなく、売上と現場の負担の両面で確かめられるようになります。

まずは、電話・自社サイト・外部予約サイトの予約が今どこに記録されているかを書き出し、5項目のデータ辞書の1行目を埋めてみてはいかがでしょうか。