補足

対象読者：自治体、DMO、宿泊事業者、地域 OTA・体験事業者、観光 DX に関わる技術者

想定読了時間：約 8〜10 分

前提知識：OTA、PMS、サイトコントローラー、CRM の基本用語を知っていると理解しやすい

最終更新：2026-05-23

TL;DR

• 予約 1 件は、OTA / 直販 / 地域 OTA → サイトコントローラー → PMS → 顧客台帳 → CRM → DMO・分析基盤へ流れることで、地域活用できるデータ資産になる。

• 現場の多くは、在庫、決済、本人確認、体験予約、レビュー、DMO 集約のどこかで分断され、データが「点」で止まる。

• 予約・決済・売上確定は同じイベントではなく、状態遷移として分けて扱う必要がある。

• Destination OS が解こうとしているのは、宿泊予約を起点に、顧客・在庫・決済・周遊・地域 KPI を一気通貫で扱うための共通基盤である。

1. 予約 1 件のフルライフサイクル

宿泊予約データは、単なる「予約番号」ではありません。旅行者の検討、予約、決済、本人確認、滞在、地域消費、再訪施策、DMO 集約までをつなぐ、地域観光の基礎データです。

1. 検討：旅行者が OTA / 自社サイト / 比較サイト / 地域 OTA で情報収集

目安時間：数分〜数日。旅行者は価格、空室、口コミ、アクセス、周辺体験、キャンセル条件を比較します。インバウンドでは、多言語表示、決済手段、交通接続、荷物対応なども意思決定に影響します。

1. 予約：OTA、直販、地域 OTA、旅行会社経由で予約成立

目安時間：数十秒〜数分。この時点で、宿泊日、人数、料金、プラン、代表者情報、キャンセルポリシー、販売チャネルが確定します。地域 OTA が関与する場合、宿泊だけでなく、交通、体験、飲食、ガイド予約と同じ導線で扱われることがあります。

1. 在庫同期：サイトコントローラー / PMS で各販売チャネルへ反映

目安時間：数秒〜数分。OTA、直販サイト、地域 OTA、旅行会社枠などに販売在庫を反映します。同期が遅れると、オーバーブッキングや販売機会損失が起きます。関連記事「サイトコントローラーとは」で扱う領域です。

1. 事前決済・予約確認：決済プロバイダから PMS へ状態反映

目安時間：数秒〜数分。クレジットカード、オンライン決済、OTA 上の事前決済などのステータスを PMS に連携します。ここで重要なのは、金額だけでなく、決済済み、未決済、オーソリ済み、返金済み、キャンセル料対象といった状態を正しく持つことです。

1. チェックイン：宿泊者名簿作成・必要に応じた本人確認・鍵発行

目安時間：対面で 3〜10 分、セルフチェックインで 1〜5 分。旅館業法上の宿泊者名簿作成、必要に応じた本人確認、部屋割り、鍵発行、館内案内が行われます。日本国内に住所を有しない外国人宿泊者については、氏名・住所・連絡先等に加えて、国籍・旅券番号の記載、旅券の呈示、旅券の写しの保存が求められるため、最新の法令・自治体運用を確認してください。

1. 滞在中：館内消費・地域体験予約・問い合わせが発生

目安時間：数秒〜数時間。レストラン、売店、レンタサイクル、温浴、アクティビティ、ガイドツアー、地域交通などの消費が発生します。多くの地域では、宿泊予約と体験予約サイトが別システムで動いており、ここが大きな分断ポイントになります。

1. チェックアウト・最終精算：PMS で売上確定

目安時間：1〜10 分。宿泊料、追加料金、入湯税・宿泊税、キャンセル料、返金、ポイント利用などを確定します。自治体税や法定外目的税の扱いは地域ごとに異なるため、所轄自治体・所轄監督庁に最終確認してください。

1. 顧客台帳更新：氏名・連絡先・滞在履歴・同意情報を記録

目安時間：自動連携なら数秒、手作業なら数分〜数十分。PMS、顧客台帳、CRM、会員基盤に情報が反映されます。ここでメール配信同意、個人情報利用目的、リピート履歴、同行者情報の扱いを整理しておかないと、後続の CRM 施策に使えません。

1. アフター：レビュー収集、メルマガ、リピート施策

目安時間：配信処理は数秒〜数分、運用設計は数時間〜数日。OTA レビュー、Google ビジネスプロフィール、アンケート、メール、LINE、会員アプリなどを通じて接点が続きます。誰が、どの施設に、何回泊まり、何を体験したかがつながっていれば、再訪提案の精度が上がります。

1. 集約：DMO / 自治体 / 分析 BI に統合

目安時間：自動連携なら数分〜数時間、月次集計なら数日〜数週間。業界が目指す姿は、個社の予約・稼働・属性・周遊・消費データを、個人情報保護と事業者ごとのデータ管理権限・利用条件を守りながら地域単位で集約し、施策判断に使える状態にすることです。観光庁の宿泊旅行統計調査など公的統計と突き合わせる場合は、2026年1月分から層化基準が「従業者数」から「客室数」に変更された点も確認が必要です。

注意 宿泊者名簿、日本国内に住所を有しない外国人宿泊者の旅券確認・写し保存、宿泊税、入湯税、個人情報の共同利用は、法令・条例・自治体運用によって扱いが変わります。2026年5月時点では、厚生労働省の旅館業法関連情報、観光庁の宿泊旅行統計調査、各自治体の宿泊者名簿・宿泊税資料など、最新の公的資料を参照し、必要に応じて所轄監督庁に確認する前提で設計してください。確認先例：厚生労働省 旅館業のページ https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000110603.html ／ 外国人宿泊者に係る旅券の呈示及びコピーに関する案内 https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000130600_00001.html ／ 観光庁 宿泊旅行統計調査 https://www.mlit.go.jp/kankocho/tokei_hakusyo/shukuhakutokei.html

2. チェックイン時決済という別パターン

事前決済だけを前提にすると、宿泊業の実務は見誤ります。日本の宿泊施設では、現地決済、チェックイン時決済、チェックアウト時精算、法人請求、旅行会社精算、OTA 事前決済が併存します。

チェックイン時決済で起きること

• 予約時点では未決済で、来館時に宿泊料を支払う

• 追加料金や宿泊税を、チェックイン時またはチェックアウト時に分けて徴収する

• OTA 上では「現地決済」と表示され、PMS 側では未収として扱う

• 旅行者が現金、クレジットカード、QR コード決済、電子マネーを選ぶ

• インバウンドでは、カードブランド、デポジット、通貨表示、領収書要件が問題になりやすい

データ連携上の注意点

チェックイン時決済では、予約成立と売上確定のタイミングがずれます。そのため、PMS、決済端末、会計システム、CRM、DMO 集計で、どの時点を「売上」と見るかを揃える必要があります。

• 予約額：予約が入った時点の予定金額

• 決済額：実際に支払われた金額

• 売上確定額：チェックアウト後に確定した金額

• 未収額：請求済みだが回収前の金額

• 返金額：キャンセル、減泊、過請求などで返金した金額

ヒント Destination OS のような地域基盤では、「予約」と「決済」と「売上確定」を同じイベントとして扱わず、状態遷移として設計することが重要です。これにより、現地決済、事前決済、法人請求、地域クーポン利用を同じライフサイクル上で扱えます。

3. 各段階で起きる分断

宿泊データの分断は、単にシステムが古いから起きるわけではありません。宿泊、交通、体験、飲食、小売、観光案内、行政報告が、それぞれ異なる事業者・システム・責任範囲で運用されているために起きます。

よくある分断ポイント

• 在庫同期遅延

OTA、直販、地域 OTA、旅行会社枠の在庫反映に遅れが出て、オーバーブッキングや販売停止が発生する。

• 顧客台帳の手作業

チェックイン時に紙、Excel、PMS、会員管理システムへ二重入力する。誤記、抜け、表記ゆれが起きる。

• 決済状態の不一致

OTA では事前決済済み、PMS では未決済、会計では売上未確定という状態が混在する。

• チェックイン時決済の断絶

決済端末と PMS が連携しておらず、フロント担当者が金額を手入力する。過不足、税区分ミス、領収書再発行が起きやすい。

• 地域 OTA / 体験予約サイトとの分断

宿泊は PMS に入り、体験予約は別の管理画面に入る。宿泊者がどの体験を予約したか、施設側・DMO 側で即時に把握できない。

• レビューの個別管理

OTA ごと、Google ごと、アンケートツールごとにレビューを開いて確認する。地域全体の満足度や課題が見えにくい。

• DMO への集約断絶

個社データが上がらず、月次・四半期の概算しか見えない。混雑、稼働、周遊、消費、満足度を同じ時間軸で分析できない。

• 同意・権限管理の不足

予約データを CRM や DMO 分析に使う際、利用目的、共同利用、第三者提供、委託、匿名加工・仮名加工・統計化の整理が後回しになる。

注意 個人情報を地域単位で扱う場合、単に API で接続すればよいわけではありません。利用目的、同意取得、共同利用の範囲、第三者提供の有無、委託先監督、保存期間、削除対応を設計し、必要に応じて専門家・所轄監督庁に最終確認してください。DMO や自治体が受け取るデータは、目的に応じて個人単位、予約単位、施設単位、日次集計、匿名統計を分けることが重要です。

4. データが分断されると何ができなくなるか

分断の問題は、現場の入力負荷だけではありません。地域経営の判断が遅れ、旅行者体験も途切れます。

• リアルタイム需要予測ができない

在庫、予約、キャンセル、価格、イベント情報が別々にあるため、地域全体の需給を読めない。

• 旅前・旅中・旅後の一貫した顧客体験が作れない

OTA の予約者、チェックインした宿泊者、体験参加者、レビュー投稿者が同じ人物としてつながらない。

• 地域単位の KPI が過去集計になる

DMO や自治体が見る数字が、月次・四半期の報告に偏り、施策の改善サイクルが遅くなる。

• リピート設計ができない

誰が何回来訪し、どの宿に泊まり、どの体験を選び、どの季節に戻ってきたかが分からない。

• インシデント時の影響範囲を即座に出せない

災害、交通障害、決済障害、感染症、施設トラブルが起きたとき、対象者と予約経路をすぐ抽出できない。

• 地域 OTA や体験予約サイトの価値を測れない

送客数だけは分かっても、宿泊、周遊、消費、満足度、再訪への貢献が見えない。

5. 一気通貫したときにできること

宿泊予約データが一気通貫すると、単なる業務効率化を超えて、地域経営の設計が変わります。ただし、データ接続だけで自動的に成果が出るわけではなく、データ品質、更新頻度、同意・契約、分析人材、運用責任の設計が必要です。

• パーソナライズドオファー

旅前の関心を、旅中の体験予約、飲食、交通、土産、ガイドへつなげられる。

• 需要把握と販売判断支援

個社の価格決定を前提に、地域全体のイベント、天候、交通、稼働、体験在庫を参考情報として把握し、各事業者が自社の販売判断に活用しやすくなる。

• 自治体・DMO の早期 KPI 把握

参加事業者からの連携データに基づき、延べ宿泊者数、稼働、予約リードタイム、キャンセル、国・地域別動向、周遊、体験参加を、月次集計待ちではなく早期に把握できる。

• インシデント対応の高速化

交通停止、災害、決済停止、予約変更、施設休業が起きたとき、対象予約・対象顧客・対象チャネルを抽出しやすくなる。

• 地域 OTA / 体験予約サイトの改善

どの体験が宿泊と相性がよいか、どの導線で離脱しているか、どの施設から送客されているかを分析できる。

• データガバナンスの標準化

個社が持つデータを無理に奪うのではなく、共通スキーマ、権限、同意、集計単位を揃えて、地域として使える状態にできる。

注意 地域単位で需要や稼働を共有する場合でも、個社の価格決定や販売条件を制限したり、競争事業者間で現在・将来の価格方針を共有したりする設計は避ける必要があります。独占禁止法・競争政策上の扱いは、公正取引委員会の事業者団体ガイドライン等を確認し、必要に応じて専門家・所轄監督庁に確認してください。確認先例：公正取引委員会 事業者団体の活動に関する独占禁止法上の指針 https://www.jftc.go.jp/dk/guideline/unyoukijun/jigyoshadantai.html

6. Destination OS の位置づけ

Destination OS は、個別の OTA、PMS、体験予約、CRM、BI を置き換える単一システムではありません。地域観光に必要なデータを、事業者のデータ管理権限・利用条件を尊重しながら接続するための OS です。

ここで重要になるのが、OS Core の 5本柱です。DOS に限らず、地域データ基盤を設計する際は、次の 5 領域を分けて確認すると実装の抜け漏れを減らせます。

予約

予約の柱は、OTA、直販、地域 OTA、旅行会社、体験予約サイトから発生する予約イベントを共通の形式で扱います。

ライフサイクル上では、ステップ 2「予約」、ステップ 3「在庫同期」、ステップ 9「アフター」に効きます。予約経路、プラン、人数、日付、キャンセル状態が揃うことで、施設単位だけでなく地域単位の需要が見えるようになります。

確認すべき項目：予約変更、キャンセル、ノーショー、減泊、OTA マスクメールをどのイベントとして記録できるか。

顧客

顧客の柱は、宿泊者、同行者、予約者、体験参加者、会員、レビュー投稿者を、適切な同意と権限のもとで扱うための基盤です。

ライフサイクル上では、ステップ 5「チェックイン」、ステップ 8「顧客台帳更新」、ステップ 9「アフター」に効きます。氏名や連絡先を単に集めるのではなく、滞在履歴、同意状態、コミュニケーション履歴、再訪可能性を扱えるようにします。

確認すべき項目：同一人物判定、同行者情報、メール配信同意、削除・停止依頼への対応を分けて管理できるか。

在庫

在庫の柱は、客室だけでなく、体験枠、ガイド枠、交通枠、飲食枠など、地域内の供給を扱うための基盤です。

ライフサイクル上では、ステップ 1「検討」、ステップ 3「在庫同期」、ステップ 6「滞在中」に効きます。地域 OTA や体験予約サイトとの接続により、「宿は空いているが体験が満席」「体験は空いているが宿が足りない」といった需給のずれを把握できます。

確認すべき項目：客室在庫と体験在庫を同じ更新頻度・同じ粒度で扱う必要があるか。

決済

決済の柱は、事前決済、現地決済、チェックイン時決済、チェックアウト時精算、法人請求、地域クーポン、返金を状態として扱うための基盤です。

ライフサイクル上では、ステップ 4「事前決済・予約確認」、ステップ 7「チェックアウト・最終精算」、独立節で扱った「チェックイン時決済」に効きます。予約額、決済額、売上確定額、返金額を分けて扱うことで、会計・CRM・DMO 集計のずれを減らせます。

確認すべき項目：予約額、決済額、売上確定額、未収額、返金額、税区分を別項目として出せるか。

周遊

周遊の柱は、宿泊施設の外で起きる体験、飲食、交通、買い物、観光案内、イベント参加をつなぐための基盤です。

ライフサイクル上では、ステップ 1「検討」、ステップ 6「滞在中」、ステップ 10「集約」に効きます。宿泊予約だけでは見えない地域内消費や移動を把握することで、DMO は単なる宿泊者数ではなく、地域経済への波及を設計できます。

確認すべき項目：個人単位で追う必要があるデータと、日次・施設単位の統計で足りるデータを分けられるか。

ヒント DOS の技術的な意味は、個別アプリの上に統合層を作ることです。OTA、PMS、地域 OTA、体験予約、CRM、BI を無理に一本化するのではなく、共通スキーマ、イベント、権限、同意、集計単位を揃えることで、地域単位の「面の DX」を実現します。

7. 実装時に最初に確認すべきこと

システム連携を始める前に、いきなり API の有無だけを見ると失敗します。まず、業務、データ、契約、運用の境界を確認します。

現場ヒアリング項目

• 予約経路：OTA、直販、地域 OTA、旅行会社、電話、団体、法人、体験予約サイトを列挙する。

• 責任範囲：PMS とサイトコントローラーのどちらが在庫、料金、予約変更、キャンセルを正とするかを決める。

• 決済パターン：事前決済、現地決済、チェックイン時決済、チェックアウト時精算、法人請求、返金を分ける。

• 宿泊者名簿と顧客台帳：法令上必要な記録と、CRM で使う顧客情報を混同しない。

• 地域 OTA / 体験予約サイト：宿泊者がどの体験を予約したか、施設側・DMO 側でどこまで見えるべきかを決める。

データ項目チェック

• 予約：予約 ID、チャネル、宿泊日、人数、プラン、料金、キャンセル状態、変更履歴。

• 顧客：氏名、連絡先、同行者、会員 ID、同意状態、配信停止、削除依頼。

• 決済：予約額、決済額、売上確定額、未収額、返金額、税区分、領収書発行状態。

• 周遊：体験予約、飲食、交通、物販、イベント参加、地域クーポン利用。

• 集計：個人単位、予約単位、施設単位、日次集計、匿名統計のどれで DMO に渡すか。

契約・同意確認

• 共同利用：共同利用する項目、利用目的、共同利用者の範囲、管理責任者を明示できるか。

• 第三者提供：DMO、自治体、別事業者、広告配信基盤に個人データを渡す場合、提供根拠と記録を説明できるか。

• 委託：システムベンダー、分析会社、コールセンターが委託先に当たる場合、委託先監督と再委託条件を確認しているか。

• 匿名加工情報・仮名加工情報・統計情報：地域分析に必要な粒度が本当に個人単位なのか、統計化で足りるのかを先に判断する。

• AI 利用：需要予測、問い合わせ対応、レビュー分析に AI を使う場合、個人情報や旅券情報を学習・外部送信しない設計になっているか。

API・運用確認

• API の有無だけでなく、予約変更、キャンセル、返金、ノーショー、減泊、同意更新のイベントを取得できるか。

• バッチ連携かリアルタイム連携か、更新頻度と遅延許容時間を決める。

• アクセス権限、監査ログ、暗号化、バックアップ、保存期間、削除依頼対応を確認する。

• 観光庁の宿泊旅行統計調査など外部統計と比較する場合、2026年1月分以降の層化基準変更を踏まえ、過年度比較の前提を明記する。

• 補助金を使う場合、観光庁の令和8年度「全国の観光地・観光産業における観光DX推進事業」等を確認し、対象経費、補助率、上限額、交付決定前着手、API 連携費、伴走支援費の扱いを公募要領単位で確認する。

ベンダー質問例

• 「予約変更、キャンセル、ノーショー、減泊は、それぞれ別イベントとして API 取得できますか」

• 「OTA のマスクメール、同行者情報、配信同意は、CRM 側でどの項目に入りますか」

• 「現地決済、事前決済、チェックイン時決済、返金は、会計・BI に同じ定義で連携できますか」

• 「DMO に渡すデータを、個人単位ではなく日次・施設単位・匿名統計に切り替えられますか」

• 「共同利用、第三者提供、委託、再委託の整理に必要なログや契約資料を出せますか」

• 「AI 機能を使う場合、入力データが学習利用されるか、外部送信されるかを制御できますか」

NG サイン

• 「API はあります」と言うが、予約作成以外の変更・返金・同意更新を説明できない。

• DMO 集約に必要なデータ粒度がすべて個人単位になっており、統計化や匿名化の選択肢がない。

• PMS、決済端末、会計、CRM で「売上」の定義が揃っていない。

• 共同利用、第三者提供、委託の違いをベンダー・事務局・施設側の誰も説明できない。

• アクセス権限や監査ログが管理者一括で、施設別・役割別に分けられない。

• 補助金の交付決定前に契約・発注・着手してよいかを確認しないまま進めている。

注意 補助金や観光 DX 関連事業で PMS、サイトコントローラー、CRM、データ連携基盤を導入する場合、対象経費、補助率、上限額、交付決定前着手の可否、API 連携費の扱いは制度ごとに異なります。2026年5月時点では、観光庁の令和8年度「全国の観光地・観光産業における観光DX推進事業」等が確認対象になりますが、必ず最新の公募要領を要確認です。確認先例：観光庁 令和8年度 観光DX推進事業 公募 https://www.mlit.go.jp/kankocho/kobo06_00047.html ／ 個人情報保護委員会 ガイドライン https://www.ppc.go.jp/personalinfo/legal/

8. まとめ

宿泊予約データのライフサイクルは、OTA から PMS に予約が入って終わりではありません。検討、予約、在庫同期、決済、チェックイン、滞在中消費、チェックアウト、顧客台帳、アフター施策、DMO 集約まで続きます。

この流れが分断されると、現場は二重入力に追われ、旅行者体験は途切れ、DMO は過去集計に頼ることになります。一方で、予約・顧客・在庫・決済・周遊を共通基盤で扱えるようになると、宿泊施設単体の DX から、地域全体の観光経営へ進むことができます。

Destination OS が目指すのは、個別システムを置き換えることではなく、地域のデータを接続可能にすることです。宿泊予約 1 件を、地域の顧客理解、周遊設計、需要予測、危機対応、再訪施策につなげること。そのためには、共通スキーマや API だけでなく、同意、権限、委託先監督、匿名化・統計化、更新頻度、補助制度の要件まで含めて設計する必要があります。そこに、DOS の実務的な価値があります。

関連：Destination OS の詳細／PMS とは／サイトコントローラーとは／地域 OTA とは／観光データガバナンス入門／宿泊業の CRM 設計