補足
対象読者：自治体観光部門、DMO / DMC、宿泊・体験・交通などの地域事業者、観光 DX に関わる技術者。想定読了時間：8〜10分。前提知識：OTA、PMS、DMO という言葉を聞いたことがある程度。最終更新：2026-05-27。
TL;DR
観光業のステークホルダー整理では、「誰が需要を持つか」「誰が在庫を持つか」「誰が地域政策を持つか」を分けて見ることが重要です。
需要接点：旅行者と OTA が、検索・比較・予約の入口を握る。
在庫・実績接点：地域事業者と PMS / Site Controller が、予約・在庫・宿泊実績を持つ。
地域戦略接点：自治体と DMO / DMC が、観光政策・KPI・地域全体の施策を設計する。
観光業のステークホルダーを整理する理由
観光業では、自治体、DMO、宿泊事業者、体験事業者、OTA、PMS、旅行者がそれぞれ異なる目的で動いています。関係者を整理しないまま DX を進めると、誰の業務を変える施策なのか、どのデータを誰が扱うのか、どこで費用対効果を見るのかが曖昧になります。
ステークホルダー相関図では、お金の流れ、予約データの流れ、問い合わせの責任分界点、KPI の持ち主を分けて見ると、地域観光 DX の打ち手を整理しやすくなります。本記事は OYKOT の他 Tips、特に「Destination OS とは」「地域 OTA」「宿泊予約データのライフサイクル」を読む前の地図として位置付けます。
1. 観光業の6つの主要アクター
宿泊だけを見ても、旅行者、宿泊施設、OTA、PMS、サイトコントローラー、決済事業者、清掃会社、自治体、DMO、観光協会、交通事業者などが関わります。最初からすべてを扱うと複雑になるため、まずは6アクターに絞ると全体像を把握しやすくなります。
旅行者：意思決定と支払いの起点。旅前・旅中・旅後で接点が異なる。
OTA：旅行者と事業者をつなぐ流通プラットフォーム。検索、比較、口コミ、予約導線を握る。
PMS / Site Controller：事業者の予約・在庫・顧客台帳・料金・チャネル連携を管理する基盤。
地域事業者：宿泊・飲食・体験・交通・物販などを提供する現場。予約、来訪、購買、口コミなどの一次データが発生する。
DMO / DMC：地域全体のマーケティング、誘客、回遊設計、KPI 設計、事業者連携を担う中間組織。
自治体：観光戦略、条例、補助金、宿泊税、公共インフラ、地域合意形成の主体。
ヒント
観光協会、観光ガイド、鉄道・バス・航空、決済プロバイダも重要な補助アクターです。まず6アクターで骨格を作り、その後に交通・決済・観光協会・ガイドなどを重ねると理解しやすくなります。
2. お金の流れ
観光業のお金の流れは、旅行者の支払いから始まります。ただし、支払い先、手数料、税、補助金、交付金が複数の経路で動くため、売上と地域収益が一致しない点に注意が必要です。
旅行者 → OTA / 事業者：OTA 経由、直接予約、電話、メール、現地予約などで支払い経路が分かれる。
OTA → 事業者：OTA 手数料を差し引いて送金される。料率は契約、地域、販売条件、決済方式で変わる。
事業者 → 決済プロバイダ：クレジットカード、QR 決済、オンライン決済の手数料が発生する。
自治体 → DMO / 事業者：観光振興予算、補助金、委託費、交付金が年度単位で配分される。
注意
宿泊税、入湯税、消費税・地方消費税、補助金、交付金、委託費は制度変更が多い領域です。2026年5月時点の実務では、必ず自治体の最新条例、国税庁・総務省・観光庁・内閣府・経済産業省など所轄監督庁の最新情報、観光庁ページ、最新公募要領、税務資料を確認してください。
3. データの流れ：どこに何が貯まるか
観光 DX の難しさは、データが存在しないことではありません。むしろ、データは各所にあります。問題は、データの保管場所、閲覧権限、粒度、更新頻度、利用目的が揃っていないことです。
主なデータの保管場所
OTA：予約数、キャンセル率、販売チャネル、国・地域別ミックス、口コミ、検索・閲覧行動の一部。
PMS：宿泊予約、在庫、料金、宿泊実績、チェックイン情報、顧客台帳、リピーター情報。
Site Controller：複数 OTA と PMS の在庫・料金・予約通知の同期情報。
地域事業者：紙台帳、Excel、POS、予約システム、Google フォーム、LINE、電話予約などの現場データ。
DMO / DMC・自治体：人流、Web アクセス、広告配信結果、観光地点訪問数、統計、税、補助金申請情報。
データ連携前に整理すること
地域横断でデータを使う場合は、共同利用、第三者提供、委託、匿名加工情報・仮名加工情報・統計情報のどれに当たるのかを先に整理します。個社の予約・顧客データを原票レベルで渡すのではなく、目的に応じて集計・匿名化・権限分離する設計が必要です。
注意
個人情報、決済情報、税務情報、宿泊者名簿、統計データは、単に「データ連携すればよい」ものではありません。個人情報保護法、旅館業法、税法、PCI DSS、自治体の情報セキュリティポリシー、委託契約、共同利用の公表事項を確認してください。
注意
観光庁の宿泊旅行統計調査は、2026年1月調査分から層化基準が「従業者数」から「客室数」に変更されています。延べ宿泊者数、稼働率、地域別・施設規模別の推移を見るときは、2025年以前との単純な前年同月比較だけで判断せず、調査設計変更の影響を確認してください。
4. 分断が起きる典型ポイント
地域観光 DX で起きやすい分断は、単なるシステム課題ではありません。事業者の商流、自治体の政策目的、DMO の KPI、旅行者の体験価値が同時に絡みます。
事業者間の分断：宿の予約と近隣の体験予約が別システムになっている。
縦の分断：DMO や自治体がリアルタイムの予約・在庫・価格データを持てない。
時間軸の分断：旅前の検索、旅中の消費、旅後の口コミ・再訪意向がつながらない。
DX の初期段階では、「どのアクターの不便を解くのか」と「どのデータを、誰が、どの権限で見るのか」を分けて設計する必要があります。
アクターごとに見る KPI
自治体：延べ宿泊者数、観光消費額、宿泊税収、混雑分散、住民満足度、地域内回遊。
DMO / DMC：広告 ROAS、Web 流入、来訪意向、地域内回遊率、キャンペーン参加数。
宿泊事業者：稼働率、ADR、RevPAR、直販比率、キャンセル率、リピーター比率、口コミ評価。
技術ベンダー：連携対象システム数、API 稼働率、データ更新頻度、エラー率、権限管理、運用工数。
ヒント
OYKOT が提唱する Destination OS（DOS）は、この分断を前提に、地域内の予約、在庫、顧客接点、施策評価をつなぐ考え方です。DOS 記事では、ここで整理した6アクターを「地域で何をつなぎ、何を分けて管理するか」を考えるための構成要素として読み替えると理解しやすくなります。
5. 明日使えるステークホルダー棚卸し
地域観光 DX を始めるときは、最初から大きな基盤を作るより、関係者ごとに「保有データ」「権限」「商流」「課題」を棚卸しするほうが失敗しにくくなります。
棚卸し項目
アクター：自治体、DMO / DMC、宿泊、体験、飲食、交通、OTA、PMS、決済、広告、コールセンターなど。
保有データ：予約、在庫、料金、顧客、決済、口コミ、アクセスログ、人流、アンケート、税、補助金申請。
権限と契約：閲覧権限、共同利用、第三者提供、委託契約、再委託条件、ログ保管期間。
現場課題：紙台帳、電話予約、LINE 予約、Excel 転記、二重入力、欠損、入力ルールの不統一。
優先 KPI：宿泊者数、消費単価、ADR、RevPAR、直販比率、回遊率、再訪意向、混雑分散、省力化時間。
ベンダーに確認する質問
予約・在庫・料金・顧客・決済・口コミのどのデータを出力できますか。
API、CSV、管理画面エクスポートのどれに対応していますか。更新頻度と取得上限はありますか。
DMO や自治体に共有できるのは、個票データですか、施設別集計ですか、地域別集計ですか。
個人情報を含む項目はどれですか。匿名化、仮名化、項目マスキング、権限分離はできますか。
契約終了時のデータ返却・削除、ログ引き渡し、移行費用は明確ですか。
NG サイン
「何でも連携できます」と言うが、API 仕様、CSV 項目、更新頻度、制限値を提示できない。
個人情報を含むデータと集計データの区別が曖昧。
DMO、自治体、事業者、委託先の閲覧権限を同じ管理者権限で運用しようとする。
補助金の対象経費と通常運用費、初期費用と保守費、システム費と広告費が見積書上で分かれていない。
6. ステークホルダー別の「最初に読むべき Tips」
自治体・DMO：DMO / DMC の違い → KPI 設計入門 → DX 補助金ガイド → Destination OS とは。
事業者：PMS とは → 宿泊予約データのライフサイクル → サイトコントローラーとは → 直販比率と OTA 手数料の見方。
技術者・大手企業：本記事 → Destination OS とは → 宿泊予約データのライフサイクル → 業務観測エージェント。
ヒント
この相関図は、本サイトの他 Tips を読むときに「今どのアクターの視点か」を意識するためのベースマップとして使ってください。