補足

対象読者：旅館・ホテル・簡易宿所・民泊運営者、自治体・DMO、地域観光 DX 担当者、PMS・予約システム・Destination OS 関連の技術者

想定読了時間：8〜10 分

前提知識：予約管理、宿泊者名簿、PMS、OTA、決済代行の基本用語

最終更新：2026-05-23

TL;DR

• 宿泊業のデータガバナンスでは、最低限 旅館業法上の宿泊者名簿、個人情報保護法、PCI DSS、Cookie 等の外部送信規律 を分けて管理する。

• 宿泊者名簿は、旅館業法施行規則上、作成日から 3 年保存する。自治体条例・細則で追加記載事項や様式運用が定められる場合があるため、施設所在地の所轄保健所にも確認する。

• 個人情報では、第三者提供・委託・共同利用を分ける。DMO や地域事業者とデータを扱う場合は、共同利用の公表事項、委託先監督、再委託、事故通知期限まで確認する。

• 2022 年 4 月施行の改正個人情報保護法により、一定の漏えい等では個人情報保護委員会への報告と本人通知が義務化され、保有個人データの開示請求対応も強化された。

• EU/EEA 居住者向けに宿泊サービスを提供する場合、GDPR、越境データ移転、OTA・決済代行の所在地・委託関係も確認対象になる。

• 決済情報は自社で持たない。2026 年 5 月時点では PCI DSS v4.0.1 を前提に、SAQ 種別、決済代行との責任分界点、事故時連絡先を確認する。

• DOS のデータ品質レイヤーは、入力項目、権限、監査ログ、保持期間、削除証跡、連携先台帳を技術側で支える基盤になる。関連記事：Destination OS のデータ品質レイヤー／業務観測エージェント

1. 旅館業法上の宿泊者名簿

宿泊事業者は、旅館業法に基づき宿泊者名簿を備える必要がある。目的は、感染症対応、治安・安全確認、行政調査への協力などであり、単なる予約台帳とは性質が異なる。

旅館業法施行規則上の主な記載事項は次のとおりである。

• 氏名

• 住所

• 連絡先

• 日本国内に住所を有しない外国人の場合の国籍・旅券番号

• その他、都道府県知事が必要と認める事項

宿泊日、到着日、出発日、部屋番号、同行者、予約経路などは、実務上の台帳管理や予約照合で重要になる。ただし、法令上の基本項目、自治体条例・細則で追加される項目、施設独自の運用項目は分けて整理する。

外国人ゲストについては、日本国内に住所を有しない場合、国籍・旅券番号の記録が法定項目となる。パスポート写しの取得・保存は、自治体・保健所の運用や本人確認実務として求められる場合があるため、法定項目とは分けて、取得目的、保存場所、保存期間、削除ルールを明確にしておく。特にインバウンド比率が高い地域では、フロント、セルフチェックイン端末、PMS、OTA 連携のどこで情報を取得し、どこに保存するかを明確にしておく。

宿泊者名簿の保管期間は、旅館業法施行規則上、作成の日から 3 年である。自治体条例・細則で追加記載事項、様式、旅券写しの保存運用などが定められる場合があるため、施設所在地を管轄する所轄保健所に確認する。

注意 法令・自治体運用は改正されることがある。宿泊者名簿の項目、保存期間、旅券写しの扱いは、最新の厚生労働省資料、自治体ページ、所轄保健所の案内を確認する。

電子保存を行う場合は、紙の台帳を PDF 化するだけでは不十分なことがある。最低限、次の観点を確認する。

• 記録後に不正に改ざんできないこと

• 誰が、いつ、どの項目を登録・変更したか分かること

• 保健所等から提示を求められた際に速やかに出力できること

• PMS やチェックインシステムの障害時にも代替手段があること

• 保存期間満了後の削除・廃棄ルールがあること

ヒント DOS では、宿泊者名簿を「予約データの一部」ではなく、法定保存・本人確認・監査証跡を持つ別レイヤーとして設計すると、自治体・DMO・地域事業者間のデータ連携で扱うべき範囲を切り分けやすくなる。

3 層で整理する場合は、次のように分けると実務に落とし込みやすい。

• 法定保存データ：宿泊者名簿、本人確認記録、保健所提示用の出力履歴

• 業務データ：予約、部屋割り、清掃、問い合わせ、キャンセル、請求、顧客対応履歴

• 分析データ：稼働率、宿泊者数、地域回遊、再訪傾向、施策効果、統計連携用の集計値

2. 個人情報保護法での宿泊者情報の扱い

宿泊者情報は、氏名、住所、電話番号、メールアドレス、旅券番号、決済関連情報、宿泊履歴、問い合わせ履歴などを含む。PMS、OTA、CRM、MA ツール、POS、アンケート、Wi-Fi 認証ログを組み合わせると、個人の行動履歴に近いデータセットになる。

最低限、次の 4 点を整理する。

1. 利用目的の明示

予約、本人確認、宿泊サービス提供、決済、問い合わせ対応、法令対応、マーケティング配信など、目的を分けて記載する。

1. 取得経路の把握

自社サイト、OTA、電話、旅行代理店、現地チェックイン、LINE、Google フォームなど、どこから取得した情報かを記録する。

1. 第三者提供・委託・共同利用の区別

OTA、決済代行、清掃委託、CRM、メール配信、BI ツールへの連携が、第三者提供なのか、委託なのか、共同利用なのかを整理する。

1. 保有個人データへの請求対応

本人からの開示、訂正、利用停止、削除等の請求を受ける窓口、本人確認方法、回答期限、記録方法を決める。

自治体・DMO・地域事業者が関わる DOS 型の運用では、特に共同利用と委託先監督が論点になりやすい。共同利用を行う場合は、共同して利用される個人データの項目、共同利用者の範囲、利用目的、管理責任者などの公表事項を確認する。委託の場合は、契約書だけでなく、再委託の有無、アクセス権限、ログ閲覧、事故時の通知期限、契約終了時の削除・返却証跡を確認する。

地域分析や観光統計に使う場合も、「匿名化した」と言うだけでは足りない。個人が識別できないよう加工し、復元や照合のリスクを管理する必要がある。匿名加工情報や仮名加工情報として扱う場合は、作成方法、加工方法等情報の管理、第三者提供時の公表・明示、他データとの照合禁止を確認する。小規模地域では、宿泊日、国籍、施設、人数の組み合わせだけで個人が推測されることがあるため、集計単位を粗くする、少数セルを伏せる、公開範囲を限定するなどの対策が必要である。

2022 年 4 月施行の改正個人情報保護法では、宿泊事業者にとって特に次の点が重要である。

• 一定の漏えい等が発生した場合、個人情報保護委員会への報告と本人通知が必要になる

• 漏えい等報告は、速報と確報の 2 段階で求められる場合がある

• 不正アクセス、要配慮個人情報、財産的被害のおそれ、大規模な漏えい等では、初動判断を誤ると対応遅延になりやすい

• 保有個人データの開示方法について、本人が電磁的記録での提供を求める場面が増える

• 第三者提供記録の開示も実務上の確認対象になる

宿泊業では、パスポート画像、身分証画像、クレジットカード関連情報、同行者情報、未成年者情報、アレルギー・配慮事項など、漏えい時の影響が大きい情報を扱う。単に「予約管理のため」とまとめず、情報の種類ごとに保存場所、アクセス権限、保持期間を決めることが重要である。

| データ区分 | 主な例 | 保存場所 | 保持期間 | 権限の目安 | | --- | --- | --- | --- | --- | | 宿泊者名簿 | 氏名、住所、連絡先、国籍、旅券番号 | PMS、宿泊者名簿システム、紙台帳 | 作成日から 3 年 | フロント責任者、管理者 | | 予約・業務データ | 宿泊日、部屋番号、人数、問い合わせ | PMS、OTA、メール | 業務上必要な期間 | 予約・運営担当 | | 決済データ | 決済 ID、トークン、請求履歴 | 決済代行、会計システム | 契約・会計上必要な期間 | 経理、管理者 | | マーケティング | メール配信、CRM、アンケート | CRM、MA、配信ツール | 利用目的に応じて設定 | マーケティング担当 | | 施設運用ログ | Wi-Fi 認証、入退室、監視カメラ | 各管理システム | 目的別に短期設定 | 施設管理者 | | 分析・統計 | 稼働率、地域別宿泊者数、回遊傾向 | BI、DOS、集計基盤 | 集計粒度に応じて設定 | 分析担当、DMO |

注意 漏えい等報告の要否、本人通知の内容、報告期限は事案の性質によって変わる。実際の事故時は、最新の個人情報保護委員会ガイドラインを確認し、顧問弁護士または専門家に相談する。

3. GDPR・越境データ移転・外部送信規律

インバウンド対応施設では、日本法だけでなく、海外居住者の個人データを扱う場面がある。特に EU/EEA 域内の個人に向けて宿泊プラン、広告、言語ページ、通貨表示、ニュースレター、リピーター CRM を提供する場合は、GDPR の適用可能性を確認する。

最低限の確認項目は次のとおり。

• EU/EEA 居住者向けに宿泊プラン、広告、言語ページ、通貨表示を提供しているか

• EU/EEA からの予約者データを自社で直接取得しているか

• OTA、決済代行、CRM、メール配信ツールの拠点やデータ保存先が EU/EEA または第三国にあるか

• プライバシーポリシーで処理目的、法的根拠、保存期間、権利行使窓口を説明しているか

• 削除、アクセス、訂正、異議申立て等の請求に対応できるか

OTA や決済代行が EU/EEA 拠点、または EU/EEA 内のデータセンターを利用している場合、越境データ移転の論点が発生することがある。日本から外国にある第三者へ個人データを提供する場合、本人同意、提供先国の制度情報、提供先が講ずる保護措置、委託契約、標準契約条項などの確認が必要になる場合がある。

また、2023 年改正電気通信事業法により、Web サイトやアプリで Cookie、広告タグ、アクセス解析、チャット、ヒートマップ、SNS 埋め込み等を使う場合、利用者情報の外部送信について通知または公表が必要になることがある。

ただし、すべての宿泊施設サイトに一律で同じ義務がかかるわけではない。自社予約サイト、会員機能、口コミ・投稿機能、アプリ、チャット、地域ポータルなどが、電気通信事業法上の一定の電気通信役務に該当するかを確認する。そのうえで、送信される情報、送信先事業者、利用目的、オプトアウトや設定変更の方法を整理する。

宿泊事業者が確認すべき代表例は次のとおり。

• Google Analytics、広告タグ、Meta ピクセル等で送信される情報

• OTA 予約ウィジェット、決済フォーム、チャットボットの外部送信

• 送信先事業者名

• 送信される情報の内容

• 利用目的

• オプトアウトや設定変更の方法

• Cookie ポリシー、プライバシーポリシー、外部送信規律ページの整合性

補足 GDPR や越境移転は、ホテル単体ではなく、OTA、決済代行、PMS、CRM、広告運用会社を含むサプライチェーン全体で確認する。最新の公募要領ではなく、最新の法令・ガイドライン・契約条件を要確認。

4. 決済情報：PCI DSS の最低ライン

宿泊業では、事前決済、現地決済、デポジット、キャンセル料、ノーショー課金などでカード情報を扱う。カード番号、有効期限、セキュリティコードを自社サーバー、Excel、紙メモ、チャット、メールで保持する運用は避けるべきである。

2026 年 5 月時点では、PCI DSS は v4.0.1 を前提に確認する。PCI SSC は v4.0.1 を 2024 年 6 月に公表し、PCI DSS v4.0 は 2024 年 12 月 31 日に退役している。SAQ も v4.0.1 ベースで、どの種別に該当するかは決済代行、アクワイアラ、必要に応じて QSA に確認する。

最低限の実務ラインは次のとおり。

• カード情報を自社サーバーに保存しない

• Stripe、Square、PayPay、各種決済代行などのトークン化機能を利用する

• セキュリティコードを保存しない

• 電話受付時にカード番号を紙やチャットへ転記しない

• OTA 管理画面でカード情報を閲覧できる権限を最小化する

• 加盟店として求められる PCI DSS v4.0.1 ベースの SAQ 種別を確認する

• 決済代行の契約、責任分界点、事故時連絡先を台帳化する

• 決済フォーム、リダイレクト、埋め込み iframe、予約エンジンのどこまでが自社管理範囲か確認する

特に小規模旅館・民泊では、キャンセル料徴収のためにカード番号を手元で控える運用が残りやすい。これは漏えい時の影響が大きく、事業継続やブランド毀損にも直結する。決済情報は、PMS や DOS の中核データベースに入れず、決済代行側のトークンだけを参照する設計が望ましい。

ベンダー質問例

• 当施設の決済方式では、PCI DSS v4.0.1 のどの SAQ 種別を想定していますか。

• カード番号、セキュリティコード、トークン、決済 ID は、それぞれどこに保存されますか。

• 予約エンジンや決済フォームの改ざん監視、脆弱性対応、ログ保管は誰の責任ですか。

• 事故発生時、何時間以内に誰へ通知されますか。

• 契約終了時に、決済関連データやログはどのように返却・削除されますか。

NG サイン

• カード番号をメール、チャット、紙、Excel で受け取る運用がある

• セキュリティコードを保存できる、または後から閲覧できる

• 決済代行から SAQ 種別や責任分界点の説明がない

• 共有アカウントで OTA や決済管理画面を運用している

• 決済フォームのタグやスクリプトを誰が管理しているか不明

5. 退職者・契約終了時の処理

宿泊業のデータ漏えいは、外部攻撃だけでなく、退職者、業務委託先、元アルバイト、清掃会社、運用代行会社の権限残りから起きることがある。退職・契約終了時の SOP は、口頭確認ではなく、チェックリスト化して証跡を残す。

退職者対応 SOP の例は次のとおり。

1. 対象アカウントの棚卸し

PMS、OTA 管理画面、メール、Google Workspace、Slack、LINE 公式、決済代行、会計、Wi-Fi 管理、監視カメラ、鍵管理システムを一覧化する。

1. 最終出勤日・契約終了時刻の確定

退職日ではなく、実際に業務アクセスを止める日時を決める。深夜チェックインや休日対応アカウントも確認する。

1. 権限の停止・削除

共有アカウントを避け、個人アカウントを停止する。共有 ID を使っていた場合は、パスワード、二要素認証、API キーを変更する。

1. 端末・データの回収

貸与 PC、スマートフォン、IC カード、物理鍵、USB、紙の宿泊者名簿、印刷済み予約表を回収する。私物端末に業務データがある場合は削除確認を行う。

1. 引き継ぎデータの分離

業務上必要な資料は共有ドライブやナレッジベースへ移し、個人のメールボックスやローカルフォルダに残さない。

1. 証跡の保存

誰が、いつ、どの権限を停止し、どの端末を回収したかを記録する。委託先終了時は、データ返却または削除証明書を取得する。

委託先にも同じ観点を適用する。PMS、予約エンジン、清掃会社、広告運用会社、CRM、コールセンター、Web 制作会社には、再委託の有無、担当者変更時の権限削除、ログ閲覧範囲、事故通知期限、契約終了時の削除証跡を確認する。

委託先管理チェックリスト

• 契約書に個人データの取扱範囲、再委託、秘密保持、事故通知、削除・返却が明記されている

• 管理画面の権限が個人単位で付与され、共有 ID が残っていない

• 担当者の異動・退職時に、委託先側でも権限削除される

• ログ、バックアップ、エクスポートデータの保持期間が説明されている

• 事故発生時の一次連絡先と通知期限が台帳化されている

NG サイン

• 「委託先に任せているので分からない」で終わる

• 再委託先や海外保存先を説明できない

• 退職者アカウントが OTA、PMS、決済代行に残っている

• 契約終了後も CSV、予約表、顧客リストの削除証跡がない

ヒント 業務観測エージェントを導入する場合も、退職者の操作ログ、API 利用履歴、データ持ち出し兆候を確認できる設計にしておくと、人的リスクの検知に役立つ。関連記事：業務観測エージェント

6. インシデント対応の備え

宿泊事業者のインシデント対応では、スピードと記録が重要である。漏えいが確定していない段階でも、調査開始時刻、検知経路、影響範囲、判断者、外部連絡先を残す。

初動 SOP には、最低限次の内容を入れる。

• 検知後、誰が一次判断するか

• PMS、OTA、決済代行、Web サイト、メール等のどこで発生したか

• 影響を受ける可能性のある本人の範囲

• 漏えいした可能性のある項目

• システム停止、権限停止、パスワード変更、API キー無効化の判断基準

• 個人情報保護委員会、保健所、警察、決済代行、OTA、顧客への連絡要否

• 顧客通知文、FAQ、プレス・SNS 対応の窓口

• 再発防止策と経営報告の期限

個人情報保護委員会への報告が必要な場合、速報は速やかに、確報は原則 30 日以内、不正目的のおそれがある場合は 60 日以内が目安になる。ただし、報告対象、期限、記載事項は事案により変わるため、最新の公的資料を参照する。

自治体・DMO・地域事業者が関与する DOS 型の運用では、単一施設の事故が地域全体の信頼に影響する。データ連携先、委託先、共同利用先を含めた連絡網を平時から整備しておく必要がある。

初動チェックリスト

• 検知時刻、検知者、検知経路を記録した

• 影響システムと影響データを仮分類した

• 管理者権限、API キー、共有アカウントを確認した

• 決済代行、PMS、OTA、Web 制作会社への連絡要否を判断した

• 個人情報保護委員会への報告要否を一次判断した

• 顧客通知、FAQ、問い合わせ窓口の準備担当を決めた

• 復旧後に再発防止策と経営報告の期限を設定した

NG サイン

• 誰が最終判断者か決まっていない

• 影響範囲を確認するためのログが残っていない

• ベンダーの緊急連絡先が担当者個人のスマートフォンにしかない

• 顧客通知文を現場担当者がその場で作る運用になっている

• 原因究明前にログや端末を初期化してしまう

7. 統計・補助指標・補助制度でのデータ利用

宿泊データは、施設内の運営改善だけでなく、自治体・DMO の観光施策、補助事業、地域回遊分析にも使われる。このときは、個人データと統計データを混同しないことが重要である。

補助指標として使いやすいものは次のとおりである。

• 稼働率

• 延べ宿泊者数

• 外国人延べ宿泊者数

• 平均客室単価

• RevPAR

• 予約経路別構成比

• キャンセル率

• リピーター比率

• 地域内回遊率

• 問い合わせから予約までの転換率

観光庁の宿泊旅行統計調査では、2026 年 1 月分調査から層化基準が「従業者数」から「客室数」へ変更された。過年度比較や地域ベンチマークに使う場合は、2025 年以前と 2026 年以降で集計設計が変わっている点を注記する。施設側の DOS や BI で作る指標も、定義、分母、除外条件、更新頻度を固定しないと、行政統計や補助事業報告と数字がずれやすい。

補助制度を使って PMS、予約エンジン、CRM、データ連携基盤、観光 DX 基盤を導入する場合は、機能要件だけでなく、証跡管理も確認する。

• 補助対象経費と、個人データを扱う機能の範囲を分けて説明できる

• 導入前後の指標定義を固定している

• 事業報告に使う集計値が、個人データから安全に作成されている

• ベンダー契約、委託先監督、保守範囲、再委託を説明できる

• 補助期間終了後も、保持期間、削除、ログ管理を継続できる

ヒント DOS は「補助金で入れるシステム」ではなく、データ定義、権限、監査ログ、保持期間、連携先台帳を横断してそろえる運用基盤として設計する。補助制度を使う場合も、成果指標と個人情報管理を同じ台帳で混ぜないことが重要である。

ヒント 関連：Destination OS のデータ品質レイヤー／業務観測エージェント。宿泊者名簿、個人情報、決済情報、外部送信、退職者権限を別々の台帳で管理しつつ、DOS 側では監査ログと保持期間を横断的に見られる設計が望ましい。

注意 法令の解釈・運用は所轄監督庁・顧問弁護士に最終確認してください。本記事は実務理解のための概観です。