観光業ステークホルダー相関図入門：自治体・DMO・OTA・PMS・事業者・旅行者の関係を一枚で理解する
補足
対象読者：自治体観光部門、DMO / DMC、宿泊・体験・交通などの地域事業者、観光 DX に関わる技術者 想定読了時間：8〜10分 前提知識：OTA、PMS、DMO という言葉を聞いたことがある程度 最終更新：2026-05-23
TL;DR
観光業は、自治体・DMO / DMC・OTA・PMS / Site Controller ベンダー・地域事業者・旅行者の6アクターが交差する構造産業です。
DX の初期設計では「誰が需要を持つか」「誰が在庫を持つか」「誰が地域政策を持つか」を押さえると、関係者間の分断を整理しやすくなります。
「誰がどのデータを持ち、お金がどこを通り、どこで分断が起きるか」を一枚で押さえると、地域観光 DX の打ち手が見えます。
本記事は OYKOT の他 Tips、特に「Destination OS とは」「DMO / DMC の違い」「宿泊予約データのライフサイクル」を読む前の地図として位置付けます。
1. 観光業の6つの主要アクター
観光業のステークホルダーは多層的です。宿泊だけを見ても、旅行者、宿泊施設、OTA、PMS、サイトコントローラー、決済事業者、清掃会社、自治体、DMO、観光協会、交通事業者などが関わります。
本記事では、最初の理解を優先して6アクターに絞ります。理由は、地域観光 DX の設計で最初に見るべき論点が次の3つだからです。
需要接点：旅行者と OTA が、検索・比較・予約の入口を握る
在庫・実績接点：地域事業者と PMS / Site Controller が、予約・在庫・宿泊実績を持つ
地域戦略接点：自治体と DMO / DMC が、観光政策・KPI・地域全体の施策を設計する
6アクターは次のように整理できます。
旅行者：意思決定と支払いの起点。旅前・旅中・旅後で接点が異なる。
OTA（Booking.com / 楽天トラベル / じゃらん 等）：旅行者と事業者をつなぐ流通プラットフォーム。検索、比較、口コミ、予約導線を握る。
PMS / Site Controller ベンダー：事業者の予約・在庫・顧客台帳・料金・チャネル連携を管理する基盤。
地域事業者：宿泊・飲食・体験・交通・物販などを提供する現場。予約、来訪、購買、口コミなどの一次データが発生する。
DMO / DMC：地域全体のマーケティング、誘客、回遊設計、KPI 設計、事業者連携を担う中間組織。
自治体（観光課・地域振興部門など）：観光戦略、条例、補助金、宿泊税、公共インフラ、地域合意形成の主体。
ヒント
観光協会、観光ガイド、鉄道・バス・航空、決済プロバイダは重要な補助アクターです。特に二次交通は、地域回遊、混雑分散、ラストワンマイル、インバウンド対応に直結するため、宿泊予約だけを見ていると見落としやすい領域です。まず6アクターで骨格を作り、その後に交通・決済・観光協会・ガイドなどを重ねると理解しやすくなります。
2. お金の流れ
観光業のお金の流れは、旅行者の支払いから始まります。ただし、支払い先、手数料、税、補助金、交付金が複数の経路で動くため、売上と地域収益が一致しない点に注意が必要です。
旅行者 → OTA：宿泊代金や体験代金を OTA 経由で支払う。OTA が一時的に代金を預かる場合と、現地決済・事業者直接決済の場合がある。
OTA → 事業者：OTA 手数料を差し引いて送金される。手数料は契約、地域、販売条件、プロモーション参加有無、決済方式で大きく異なるため、記事上の一般論ではなく各 OTA の契約書・管理画面・キャンペーン条件で確認する。
旅行者 → 事業者（直接予約）：自社サイト、電話、メール、現地予約など。OTA 手数料は発生しないが、広告費、予約エンジン利用料、決済手数料、CRM 運用費は別途発生する。
事業者 → 決済プロバイダ：クレジットカード、QR 決済、オンライン決済の手数料を支払う。料率は契約、決済手段、売上規模、リスク審査、入金サイクルで変わるため、見積書・加盟店契約・返金時の手数料条件まで確認する。
旅行者 / 事業者 → 行政：宿泊税・入湯税などの地方税、消費税・地方消費税などが発生する。ただし、納付主体、納付先、申告方法は税目により異なる。宿泊税は自治体ごとに制度、税率、免税点、対象施設、施行時期が変わり、改正も多い。実務では記事中の例示ではなく、対象自治体の最新条例、税務資料、FAQ、施行日を確認する。
自治体 → DMO / 事業者：観光振興予算、補助金、委託費、交付金が年度単位で配分される。観光 DX、地域周遊、受入環境整備、省力化、高付加価値化では、制度ごとに対象経費、補助率、上限額、申請主体、地域計画の要否が異なる。たとえば観光 DX 推進、省力化投資、インバウンド安全・安心対策、観光地再生・高付加価値化支援は目的も要件も異なるため、「補助率1/2」「上限数百万円〜数千万円」と一括りにせず、制度名と公募要領単位で確認する。
DMO / DMC → 事業者 / 外部ベンダー：プロモーション、データ分析、Web サイト運用、広告、CRM、コンテンツ制作、地域予約基盤などに支出する。委託費でデータ基盤や予約システムを導入する場合は、成果物の権利、データの持ち出し可否、契約終了後の移行、ログの引き渡し条件を契約時に確認する。
注意
宿泊税、入湯税、消費税・地方消費税、補助金、交付金、委託費は制度変更が多い領域です。2026年5月時点の実務では、必ず自治体の最新条例、国税庁・総務省・観光庁・内閣府・経済産業省など所轄監督庁の最新情報、観光庁ページ、最新公募要領、税務資料を確認してください。
3. データの流れ：どこに何が貯まるか
観光 DX の難しさは、データが存在しないことではありません。むしろ、データは各所にあります。問題は、データの保管場所、閲覧権限、粒度、更新頻度、利用目的が揃っていないことです。
OTA：予約数、キャンセル率、販売チャネル、国・地域別ミックス、口コミ、検索・閲覧行動の一部を持つ。事業者が閲覧できるのは原則として自社施設・自社商品に関する範囲であり、地域全体や競合施設の詳細データは限定的。
PMS：宿泊予約、在庫、料金、宿泊実績、チェックイン情報、顧客台帳、リピーター情報を持つ。閲覧権限は宿泊施設の管理者、フロント、予約担当、経理担当などに分かれる。個人情報を含むため、DMO や自治体が直接アクセスする設計には慎重な権限管理が必要。
Site Controller：複数 OTA と PMS の在庫・料金・予約通知を同期する。オーバーブッキング防止や料金更新には重要だが、地域横断の分析基盤として使えるとは限らない。
決済プロバイダ：決済金額、決済日時、決済手段、取引 ID、返金情報などを持つ。カード番号などの機微情報は PCI DSS v4.0.1 を前提に、カード会員データを自社で保持しない設計、トークン化、委託先の準拠状況確認を行う。
地域事業者：宿泊、飲食、体験、交通、物販の現場データを持つ。紙台帳、Excel、POS、予約システム、Google フォーム、LINE、電話予約などが混在しやすい。現場入力の負荷が高いと、データ基盤を作っても欠損や転記ミスが増える。
DMO / DMC：人流データ、Web アクセス、広告配信結果、観光地点訪問数、アンケート、キャンペーン応募、地域 KPI を持つ。一方で、個社の予約・顧客データを原票レベルで持たないことが多い。
自治体：宿泊統計、観光客動態調査、宿泊税収、入湯税、住民・事業者向けアンケート、補助金申請情報などを持つ。統計・税務・補助金データは所管部署が分かれやすく、庁内連携が課題になりやすい。
データ保管期間の典型例は次の通りです。
宿泊者名簿：旅館業法に基づき、作成日から3年間保存する。詳細な対象項目・保存方法は最新法令と所轄保健所に最終確認。
会計・税務証憑：法人税・消費税・インボイス対応の観点から、帳簿・請求書・領収書などは7年程度の保存が必要になるケースが多い。欠損金や制度要件により期間が変わるため、税理士・所轄税務署に最終確認。
PMS の顧客プロファイル：法定保存データ、会計・税務データ、マーケティング利用データを分け、利用目的ごとに保持期間を決める。リピーター施策で長期保有する場合は、同意、配信停止、削除依頼対応、不要情報の削除・匿名化を明確にする。
アクセスログ・操作ログ：不正アクセス調査、監査、障害対応、委託契約上の要件に応じて保持期間を決める。個人情報や識別子を含む場合は、目的外利用を避け、閲覧権限と削除ルールを明確にする。
分析用集計データ：個人を識別できない粒度に集計・匿名化したうえで、年度比較や施策評価のために数年単位で保管することがある。
データ連携を始める前に、次の区分を整理します。
共同利用：自治体、DMO、事業者などが個人データを共同で使う場合は、共同利用するデータ項目、共同利用者の範囲、利用目的、管理責任者を本人に通知または公表する。
第三者提供：事業者の顧客データを DMO、自治体、外部ベンダーへ渡す場合は、本人同意の要否、提供記録、委託との違いを確認する。
委託：予約管理、CRM、広告配信、分析基盤の運用を外部ベンダーに委託する場合は、委託先監督、再委託、アクセス権限、ログ、契約終了時のデータ返却・削除を契約で定める。
匿名加工情報・仮名加工情報・統計情報：地域全体の分析に使う場合は、個人を識別できる原票をそのまま渡すのではなく、目的に応じて加工・集計する。匿名加工情報として扱う場合は、作成方法、含まれる項目、公表、識別行為の禁止などのルールを確認する。
AI 活用：口コミ要約、需要予測、問い合わせ対応、旅程推薦に AI を使う場合は、個人情報、著作権、誤案内時の責任分界、学習利用の有無、出力の確認体制を明確にする。
注意
個人情報、決済情報、税務情報、宿泊者名簿、統計データは、単に「データ連携すればよい」ものではありません。個人情報保護法、旅館業法、税法、PCI DSS、自治体の情報セキュリティポリシー、委託契約、共同利用の公表事項を確認し、所轄監督庁・所轄保健所・税務署・個人情報保護委員会などの最新情報に基づいて最終確認してください。
注意
観光庁の宿泊旅行統計調査は、2026年1月調査分から層化基準が「従業者数」から「客室数」に変更されています。延べ宿泊者数、稼働率、地域別・施設規模別の推移を見るときは、2025年以前との単純な前年同月比較だけで判断せず、調査設計変更の影響を確認してください。確認先：観光庁「宿泊旅行統計調査」ページ、層化基準見直し資料。
4. 分断が起きる典型ポイント 3 つ
事業者間の分断：宿の予約と近隣の体験予約が別システムになっている。旅行者は宿泊、食事、体験、交通を別々に予約し、地域側も旅程全体を把握できない。
縦の分断：DMO や自治体がリアルタイムの予約・在庫・価格データを持てない。施策は月次・四半期・年度単位の事後集計に依存し、需要変動への即応が難しい。
時間軸の分断：旅前の検索、旅中の消費、旅後の口コミ・再訪意向がつながらない。結果として、リピート促進、CRM、地域内回遊、混雑分散の設計が断片的になる。
この3つの分断は、単なるシステム課題ではありません。地域観光では、事業者の商流、自治体の政策目的、DMO の KPI、旅行者の体験価値が同時に絡みます。したがって、DX の初期段階では「どのアクターの不便を解くのか」と「どのデータを、誰が、どの権限で見るのか」を分けて設計する必要があります。
アクターごとに見る KPI も異なります。
自治体：延べ宿泊者数、観光消費額、宿泊税収、混雑分散、住民満足度、地域内回遊、インバウンド比率
DMO / DMC：広告 ROAS、Web 流入、来訪意向、地域内回遊率、キャンペーン参加数、再訪意向、事業者参加率
宿泊事業者：稼働率、ADR、RevPAR、直販比率、キャンセル率、リピーター比率、口コミ評価
体験・飲食・交通事業者：予約数、利用者数、客単価、時間帯別需要、在庫消化率、送客元、満席・満車による機会損失
技術ベンダー：連携対象システム数、API 稼働率、データ更新頻度、エラー率、権限管理、運用工数、問い合わせ件数
ヒント
OYKOT が提唱する Destination OS（DOS）は、この分断を前提に、地域内の予約、在庫、顧客接点、施策評価をつなぐ考え方です。本記事では概念整理に留め、実装論は別記事で扱います。DOS 記事では、ここで整理した6アクターを「地域で何をつなぎ、何を分けて管理するか」を考えるための構成要素として読み替えると理解しやすくなります。
5. 明日使えるステークホルダー棚卸しシート
地域観光 DX を始めるときは、最初から大きな基盤を作るより、関係者ごとに「保有データ」「権限」「商流」「課題」を棚卸しするほうが失敗しにくくなります。
棚卸し項目
アクター：自治体、DMO / DMC、宿泊、体験、飲食、交通、OTA、PMS、決済、広告、コールセンターなど
保有データ：予約、在庫、料金、顧客、決済、口コミ、アクセスログ、人流、アンケート、税、補助金申請
更新頻度：リアルタイム、日次、週次、月次、四半期、年度
閲覧権限：自社のみ、DMO 閲覧可、自治体閲覧可、委託先閲覧可、集計値のみ共有
個人情報区分：個人データ、仮名加工情報、匿名加工情報、統計情報、個人を含まない業務データ
商流：旅行者の支払い先、手数料、送金タイミング、キャンセル時の処理、税・入湯税・宿泊税の扱い
契約：OTA 契約、PMS 契約、委託契約、共同利用の公表、第三者提供の同意、再委託条件
現場課題：紙台帳、電話予約、LINE 予約、Excel 転記、二重入力、欠損、入力ルールの不統一
連携可否：API、CSV、管理画面エクスポート、手入力、連携不可、契約変更が必要
優先 KPI：宿泊者数、消費単価、ADR、RevPAR、直販比率、回遊率、再訪意向、混雑分散、省力化時間
ベンダー質問例
このシステムから、予約・在庫・料金・顧客・決済・口コミのどのデータを出力できますか。
API、CSV、管理画面エクスポートのどれに対応していますか。更新頻度と取得上限はありますか。
DMO や自治体に共有できるのは、個票データですか、施設別集計ですか、地域別集計ですか。
個人情報を含む項目はどれですか。匿名化、仮名化、項目マスキング、権限分離はできますか。
共同利用、第三者提供、委託のどの整理を前提にしていますか。標準契約書や公表文例はありますか。
再委託先、データ保管場所、ログ保管期間、障害時の連絡体制、契約終了時のデータ返却・削除方法を提示できますか。
補助金や委託事業で導入する場合、見積書、仕様書、成果物定義、運用費、保守範囲を分けて提示できますか。
AI 機能がある場合、入力データが学習に使われるか、出力の根拠確認ができるか、誤案内時の責任範囲を説明できますか。
NG サイン
「何でも連携できます」と言うが、API 仕様、CSV 項目、更新頻度、制限値を提示できない。
個人情報を含むデータと集計データの区別が曖昧。
DMO、自治体、事業者、委託先の閲覧権限を同じ管理者権限で運用しようとする。
契約終了時のデータ返却・削除、ログ引き渡し、移行費用が決まっていない。
補助金の対象経費と通常運用費、初期費用と保守費、システム費と広告費が見積書上で分かれていない。
現場の入力負荷を確認せず、紙・電話・LINE・Excel の運用を「後で統一する」としている。
統計データの調査設計変更や速報値・確報値の違いを無視して、前年同月比だけで成果を判断している。
6. ステークホルダー別の「最初に読むべき Tips」
自治体・DMO：DMO / DMC の違い → KPI 設計入門 → DX 補助金ガイド → Destination OS とは
事業者：PMS とは → 宿泊予約データのライフサイクル → サイトコントローラーとは → 直販比率と OTA 手数料の見方
技術者・大手企業：本記事 → Destination OS とは → 宿泊予約データのライフサイクル → 業務観測エージェント
観光協会・地域中間支援組織：本記事 → DMO / DMC の違い → 地域回遊 KPI 設計 → 観光データガバナンス入門
ヒント
この相関図は、本サイトの他 Tips を読むときに「今どのアクターの視点か」を意識するためのベースマップとして使ってください。次に読む記事としては、「Destination OS とは」「DMO / DMC の違い」「宿泊予約データのライフサイクル」がおすすめです。
