対象読者：旅館・ホテル・簡易宿所・民泊運営者、自治体・DMO、地域観光 DX 担当者、PMS・予約システム・Destination OS 関連の技術者。前提知識：予約管理、宿泊者名簿、PMS、OTA、決済代行の基本用語。最終更新：2026-05-27。
この記事の要点
宿泊施設のデータガバナンスでは、宿泊者名簿、個人情報、決済情報、Cookie 等の外部送信、委託先、共同利用を分けて管理する。
宿泊者名簿は法定保存・本人確認・監査証跡を持つ別レイヤーとして扱い、PMS や CRM の業務データと混ぜない。
カード情報は自社で持たない設計を原則にし、決済代行、トークン、管理画面権限、返金フロー、ログを確認する。
DMO・自治体・地域事業者とデータを扱う場合は、第三者提供、委託、共同利用、集計・匿名化の線引きを事前に決める。
- 取得目的
誰が、何のために使うか
- 保管場所
保存先と外部送信の有無
- 閲覧権限
誰が、どこまで見られるか
- 保存と削除
保存期間と削除方法
- 委託先
外部委託先とデータの扱い
法令や制度の個別判断は、所轄機関・専門家への確認と分けて行います。
宿泊施設のデータガバナンスとは
宿泊施設のデータガバナンスとは、宿泊者名簿、予約情報、決済情報、パスポート情報、問い合わせ履歴、口コミ、CRM データなどを、誰が、何の目的で、どこまで見られるかを決めて運用することです。
インバウンド対応、セルフチェックイン、地域 OTA、Destination OS のような連携を進めるほど、データを集める前に、取得目的、保存場所、閲覧権限、保存期間、削除方法、外部委託先を整理しておく必要があります。
注意：本記事は宿泊施設・DMO向けの実務整理を目的とした一般情報です。法令・制度・ガイドラインは変わるため、個別判断では所轄保健所、個人情報保護委員会、税務署、決済代行会社、専門家に確認してください。
1. 旅館業法上の宿泊者名簿
宿泊者名簿は、予約台帳や CRM とは性質が異なる法定保存データです。氏名、住所、連絡先、宿泊日、外国人ゲストの国籍・旅券番号など、法令・自治体運用・施設独自項目を分けて整理します。
法定項目：氏名、住所、職業、宿泊日など、宿泊者名簿として必要な項目。
本人確認情報：旅券番号、パスポート写し、本人確認ログなど。取得目的と閲覧権限を限定する。
業務項目：予約経路、部屋番号、同行者、キャンセル、清掃、請求など。法定保存データと混同しない。
電子保存を行う場合は、紙の台帳を PDF 化するだけでは不十分です。誰が、いつ、どの項目を登録・変更したか、保健所等から提示を求められた際に速やかに出力できるか、障害時の代替手段があるかを確認します。
ヒント：DOS では、宿泊者名簿を「予約データの一部」ではなく、法定保存・本人確認・監査証跡を持つ別レイヤーとして設計すると、自治体・DMO・地域事業者間のデータ連携で扱うべき範囲を切り分けやすくなります。
2. 個人情報保護法での宿泊者情報の扱い
- 保管場所
どの国・リージョン・委託先に保存されるか。
- 保持期間
取得目的・法令・契約と、削除方法を確認する。
- 閲覧権限
誰が何の目的で見られるか。異動・退職時の停止方法。
- 暗号化
保存理由・暗号化・マスキング・削除期限を確認する。
宿泊者名簿・本人確認情報・予約情報・決済関連情報・問い合わせ履歴を分けて整理します。
宿泊者情報は、氏名、住所、電話番号、メールアドレス、旅券番号、決済関連情報、宿泊履歴、問い合わせ履歴などを含みます。PMS、OTA、CRM、MA ツール、POS、アンケート、Wi-Fi 認証ログを組み合わせると、個人の行動履歴に近いデータセットになります。
利用目的：予約、本人確認、宿泊サービス提供、決済、問い合わせ対応、法令対応、マーケティング配信を分けて記載する。
取得経路：自社サイト、OTA、電話、旅行代理店、現地チェックイン、LINE、フォームなどを記録する。
第三者提供・委託・共同利用：OTA、決済代行、清掃委託、CRM、メール配信、BI ツールへの連携を分類する。
削除・訂正・配信停止：本人からの依頼に対応できる担当、期限、ログを決める。
3. GDPR・越境データ移転・外部送信規律
海外ゲスト、海外 OTA、海外 SaaS、LLM、広告タグ、アクセス解析を使う場合は、データの保存国、移転先、再委託、学習利用、Cookie 等の外部送信を確認します。
海外 OTA・予約エンジン：ゲスト情報がどの国のサーバーに保存され、誰がアクセスできるかを確認する。
広告・解析タグ：送信される識別子、送信先、利用目的を把握し、プライバシーポリシーへ反映する。
AI・翻訳ツール：宿泊者情報、決済情報、旅券番号、健康・宗教・食事制限などを入力しないルールを作る。
NG サイン：どのツールに何のデータが送られているか説明できない、退職者アカウントが残っている、共有 ID で管理画面を使っている、委託先の再委託先が不明。
4. 決済情報：PCI DSS の最低ライン
カード番号やセキュリティコードのような機微な決済情報は、自社で保持しない設計を基本にします。決済代行のホスト型決済、トークン化、権限分離、返金フローを選ぶことで、宿泊施設側の管理範囲を小さくできます。
カード番号を自社 DB、スプレッドシート、メール、チャット、紙メモに保存しない。
返金、取消、事前決済、現地決済、デポジットの処理権限を分ける。
管理画面の権限、2段階認証、監査ログ、退職者削除を定期確認する。
PMS や予約エンジンにカード情報が残る場合は、保存理由、暗号化、マスキング、削除期限を確認する。
5. ベンダー・委託先管理
図を拡大 ↗PMS、予約エンジン、CRM、チャット、清掃管理、広告、分析基盤など、宿泊施設のデータは多くの委託先に触れます。契約前に、データ保管場所、再委託、ログ、削除、返却を確認します。
ベンダー質問例
宿泊者情報、決済関連情報、問い合わせログはどの国・リージョンに保存されますか。
退職者・異動者のアカウント停止、権限変更、監査ログ確認は誰が行いますか。
契約終了時に、データの返却、削除証跡、バックアップ削除はどのように行われますか。
障害・漏えい・誤送信が起きた場合、何時間以内に誰へ連絡されますか。
6. インシデント対応の備え
- 検知
誰が、何を、いつ発見したかを記録する。
- 緊急対応
アカウント停止・公開停止・委託先連絡・証跡保全。
- 報告
対象者・項目・件数・期間・委託先・外部送信先を確認。
- 通知
法令・契約・社内規程に沿って判断する。
- 復旧
原因・再発防止・権限見直し・ログ保存・教育。
影響範囲を洗い出し、法令・契約・社内規程に沿って報告・通知を判断します。
漏えい、誤送信、不正アクセス、端末紛失、委託先事故は、起きてから手順を作ると遅れます。初動連絡先、影響範囲、停止判断、報告、復旧手順を事前に決めます。
検知：誰が、何を、いつ発見したかを記録する。
緊急対応：アカウント停止、公開停止、委託先連絡、証跡保全を行う。
影響範囲：対象者、項目、件数、期間、委託先、外部送信先を洗い出す。
報告・通知：法令、契約、社内規程に沿って判断する。
復旧：原因、再発防止、権限見直し、ログ保存、教育を行う。
7. 統計・補助指標・補助制度でのデータ利用
稼働率、ADR、OCC、RevPAR、国籍別宿泊者数、地域内回遊、クーポン利用、問い合わせ種別のような集計データは、地域施策や補助制度の成果説明に使いやすい情報です。一方で、元データに個人情報が含まれる場合は、集計単位、匿名化、目的外利用、共同利用の範囲を明確にします。
DMO や自治体へ共有する場合は、原票ではなく集計・匿名化したデータを基本にし、元データへ戻せる担当者を限定します。Destination OS では、法定保存データ、業務データ、分析データを分けることで、地域全体のデータ活用と個人情報保護を両立しやすくなります。
参考資料
厚生労働省・自治体の旅館業法関連資料。確認日：2026-05-27。
個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」。確認日：2026-05-27。
PCI Security Standards Council「PCI DSS」およびデータ保存に関する FAQ。確認日：2026-05-27。