地方観光に足りないのはアプリではない。OS だ ── Destination OS がつくる「面のDX」

Destination OS がつくる面の DX のカバー画像

TL;DR

  • 訪日需要は拡大している。地方部の宿泊も回復しているが、訪日需要全体の増分は三大都市圏がより大きく取り込んでおり、外国人延べ宿泊者数の三大都市圏シェアは 2019年 62.7% から 2024年 69.1% へ上昇している。

  • ボトルネックは観光資源の不足「だけ」ではない。多くの地域では、既にある観光資源が「予約できる商品」「移動できる動線」「比較できる情報」「改善できるデータ」に変換されていない ── 個別最適に積み上がった「点のDX」が地域単位として接続されていない。

  • Destination OS(DOS) は、その分断を解く “面のDX” 基盤。地域全体を一つの OS と見立て、自治体・事業者・旅行者・働き手をひとつのデータとサービスで接続する。

  • OS の前提は「どのデータが・いつ・誰のものか」が常に検証可能であること。本記事の最後に、それを毎日担保するための仕組み(業務観測エージェント)を、DOS のデータ品質レイヤーとして紹介する。

1. なぜ訪日需要は、地方の滞在・消費に変わりにくいのか

2024年、訪日外客数は2019年比 +15.6% の約3,687万人と過去最高を更新した(JNTO 訪日外客数(2024年年間値))。外国人延べ宿泊者数も +42.2% の約1.64億人泊 まで伸びている(観光庁 宿泊旅行統計 2024年年間値(確定値))。

にもかかわらず、宿泊は三大都市圏への集中をむしろ強めた。三大都市圏の構成比は2019年の62.7%から2024年には69.1%へ上昇し、地方部は37.3% → 30.9% に下がっている(観光庁 宿泊旅行統計 2024年確定値(近畿運輸局 集計))。

図1:外国人延べ宿泊者数の三大都市圏シェアは2019年62.7%→2024年69.1%へ上昇。絶対値は両方とも増えているが、増分の取り込みに差がある。出典:観光庁 宿泊旅行統計 2024年確定値・近畿運輸局集計。

なお、本稿では地域別宿泊構造を精緻に見るため、宿泊旅行統計については確定値が公表されている2024年を主な分析対象とする。補助線として、2025年の年間速報値では外国人延べ宿泊者数が1億7,787万人泊、前年比 +8.2%まで伸びていることにも触れておく(観光庁 宿泊旅行統計 2025年年間値速報値)。また、2025年の訪日外客数も2024年比 +15.8% の約4,268万人JNTO 訪日外客数(2025年年間値))と、需要全体はさらに拡大している。

補足:2024年単年の前年比では、外国人延べ宿泊者数は三大都市圏 +35.0%、地方部 +51.4% と地方部の伸び率の方が大きい。ただしコロナ前の2019年との構造比較では、三大都市圏 +56.5% に対し地方部は +18.0% にとどまる。需要は地方にも戻りつつあるが、訪日需要全体の増分をより大きく取り込んでいるのは依然として三大都市圏である(近畿運輸局 2024年宿泊旅行統計 確定値 PDF)。

問題は、地方に需要が来ていないことではない。地方部の宿泊も伸びている。しかし、訪日需要全体の伸びを、三大都市圏ほど取り込めていない ── 地方観光の課題は「需要不足」ではなく、需要を滞在・消費・回遊に変換する仕組みの不足にある。

地方が伸びない要因は複合的。だが「分断」は非対称に効く

地方観光が伸びない要因は本来複合的だ ── 二次交通、宿泊供給、航空路線、価格、言語、旅前認知、OTA掲載力、現地体験の予約可能性、災害・天候、自治体・DMOの予算、人材不足。

その中で「点のDX」の限界が、特に地方で重く効く。理由は事業者構造の非対称にある。

  • 旅前:地方の体験・宿泊・二次交通は別事業者にまたがり、OTA 上で「ワンパッケージ」として比較されにくい。検討段階で、都市の単一ホテルに負ける。

  • 旅中:宿・交通・体験が接続されていないため動線が組めず、滞在日数が伸びない。1泊で都市に戻る選択が合理的になる。

  • 旅後:顧客台帳・購買データが事業者ごとに閉じ、地域単位でリピート・LTV を設計できない。再訪需要を都市が回収する。

つまり、都市部は単一事業者の中で完結できるが、地方は地域内連携が必須。点のDXによる分断は、地方で非対称に強く効く。

具体例:宿は OTA で予約できるが、近隣の体験商品は電話予約のみ。タクシー会社は配車状況を持つが、宿泊施設・DMO の予約データとはつながっていない。観光案内所は旅行者の困りごとを最前線で知るが、その情報は翌月の施策改善に使われない。データは地域に存在しているのに、旅程を組む単位では接続されていない

多くの地域でボトルネックになっているのは、観光資源そのものの不足だけではない。むしろ、既にある観光資源が「予約できる商品」「移動できる動線」「比較できる情報」「改善できるデータ」に変換されていないことだ。その背景にあるのが、予約・交通・決済・POS・チケット・顧客対応が個別最適に導入され、地域単位として接続されていない「点のDX」のボトルネックである。

ただし、本稿は、地方観光のすべての課題を DX で解けると言いたいわけではない。交通供給、宿泊キャパシティ、人材、価格、航空路線といった制約は残る。それらの制約を前提にしても、地域内に既に存在する予約・交通・体験・消費データが接続されていないことは、地方が需要を取り込むうえで共通して現れる横断ボトルネックである ── ここが DOS の射程である。

必要なのは「もう一つの新しいツール」ではなく、ツール同士を束ねる土台 だ。

2. Destination OS という “見立て”

スマートフォンを思い出してほしい。iOS が無ければ、カレンダーも地図も決済アプリも、ばらばらの便利機能でしかない。OS があるからこそ、アプリ同士が連携して 1 つの「体験」になる。

地域も同じだ。Destination OS(DOS)は、地域を構成するすべてのプレイヤーを、ひとつの OS の上に乗せる構想である。

図2:Destination OS のアーキテクチャ。App Layer の個別アプリが OS Core Layer の5本柱(標準データモデル / ID管理 / 決済 / ガバナンス / 外部連携API)に接続される。データの所有権は地域・事業者側に残る。

OS Core が標準データモデル・外部連携 API・権限/監査・データガバナンスを提供し、その上で各業務アプリ(周遊バス電子チケット、AI 音声ガイド、地域 OTA、多言語 AI コンシェルジュ、分析ダッシュボードなど)が動く。個別アプリを追加するたびに、データは「共有資産」として OS Core に蓄積されていく。

OS Core を構成する 5 つの柱(実装イメージ):

  • 標準データモデル:予約・顧客・在庫・決済・周遊の地域共通スキーマ

  • ID 管理:旅行者 ID と従業員 ID を地域横断で発行・連携(同じ人を別事業者でも同じ ID で扱える)

  • 決済:複数事業者にまたがる精算・分配・払い戻しの共通レール

  • ガバナンス:権限・監査・改ざん検知、データの出所と保管場所の検証(§4 のデータ品質レイヤーが土台)

  • 外部連携 API:OTA・PMS・チケット発券・地図・決済端末との接続点

OS Core は単一ベンダー支配の構造ではなく、データの所有権は地域・事業者側に残り、外部連携 API と権限・監査の仕組みによって複数事業者が同等に参加できる前提で設計する。OS と呼ぶのは「土台を共通化する」ためであって、「特定の事業者がデータを抱え込む」ためではない。

この上に、周遊バス電子チケット、AI 音声ガイド、地域 OTA、多言語 AI コンシェルジュ、分析ダッシュボードなどの App Layer が乗る。

これが「点のDX(バラバラの最適化)」から「面のDX(地域全体の最適化)」への転換である。

3. DOS が見ているのは 4 つのレイヤー

DOS の設計図は、関わるステークホルダーごとに 4 つのレイヤーに分かれる。

図3:DOS が支える4つのレイヤー(旅行者体験 / 地域経営 / 事業者運営 / データ・技術基盤)と該当ステークホルダー。

3-1. 旅行者体験レイヤー ── 旅前・旅中・旅後をシームレスに

旅前のパーソナライズ計画と多言語動画、旅中のワンストップ決済・移動・案内、旅後の口コミ蓄積とリピート化。情報・予約・交通が「同じ ID」でつながり、言語の壁を AI が吸収する。

3-2. 地域経営レイヤー ── 勘と経験から、データドリブン経営へ

DMO・自治体にとっての DOS は、まず「KPI ダッシュボード」として現れる。来訪者数・消費額・滞在時間・動態データをリアルタイムで可視化し、混雑平準化や周遊促進の戦略を立案、補助金や予算確保の根拠としても使える。Web 解析に取り組む自治体は現状 40% 未満。逆に言えば、ここを整えるだけで自治体の打ち手の質は一段上がる。

3-3. 事業者運営レイヤー ── 少ないリソースで、高い生産性

宿泊・飲食・体験・交通の現場では、人手不足が最大の制約だ。共通 PMS による予約・在庫・決済の統合、AI チャットボットによる問い合わせ自動化、AI を活用したバックオフィスの自動化により、現場スタッフは「おもてなし」という高付加価値業務に集中できる。

実際に和歌山県那智勝浦で運用支援している宿泊事業者は、スタッフ増員なしで施設数を 3 軒 → 10 軒まで拡大 した。OS が定型業務を肩代わりした結果である。

3-4. データ・技術基盤レイヤー ── すべてを支える共通基盤

ここが本記事で最も強調したいレイヤーだ。地域共通データプラットフォーム(匿名化・集約)、API 連携、データガバナンス(セキュリティ・プライバシー)、そして持続的な運用体制。OS は「動き続ける」ことに価値がある。停まったら、いっせいに地域全体が止まる ── これは耐震構造を組むのに似ている。

4. DOS の信頼性は「データが正しく届くこと」から始まる ── データ品質レイヤーとしての業務観測

ここからは実装面の話だ。DOS が掲げる「面のDX」は技術的には次の前提に立っている。

どの計測装置から発生した、どのデータが、いつ・どこに保管され、誰がアクセスしたかを、すべて検証可能であること。

ここを担保できないと、ダッシュボードの数字は信頼できない。AI が学習する材料も濁る。データガバナンスはスローガンではなく、毎日の現場運用そのものだ。

DOS の階層で言えば、これはApp Layer・OS Core Layer の下に位置する「データ品質レイヤー」にあたる。私たちはこの層を、自社プロダクト運用に投入している 業務観測エージェント(Chrome 拡張+Windows/macOS デスクトップエージェント+バックエンド API)で具体化している。画面録画とイベントログをチャンク単位で安全にアップロードし、次の 5 ステップで「データが正しく届く」ことを毎日担保する。

図4:業務観測エージェントが担保する5ステップ(Sense → Store → Bind → Verify → Surface)。
  1. 計測(Sense): 各端末が短いセグメントで録画。

  2. 保存(Store): 暗号化したうえでクラウドストレージへ転送。

  3. 接続(Bind): 標準化された Session / Recording モデルに紐付け。

  4. 検証(Verify): ストレージ上のオブジェクト数・サイズ・マニフェストとデータベースの状態を毎日突き合わせ、欠損がないかを自動で点検。

  5. 可視化(Surface): ダッシュボードから経営層・現場が同じ事実を見る。

たとえばつい今朝も、ある稼働中セッションについて以下を 1 分以内に確認できた。

  • セッションは active、最新ハートビートは 8 秒前。

  • 録画は 25 本、うち 15 本が ready、10 本が進行中。

  • 過去 25 分間で 540 MB / 43 ファイルがストレージに到達。最新オブジェクトは 7 秒前。

  • 全 ready 録画に対して merged な MP4 が 100% 揃っている。

これは派手なデモではない。DOS が約束しているものを、毎日 1 件もズレなく届けるための地味な背骨 だ。観光分野の DOS でも、同じ厳密さで予約データ・決済データ・周遊データを扱う。

「OS と名乗る以上、止まらず、ロスせず、改ざんさせない」 ── これが OYKOT の技術的なコミットメントである。

5. これからご一緒したい方へ

Destination OS は、一社で完結する SaaS ではなく、地域に住むようにつくる長期インフラ だ。だからこそ、初期から関わってくださるパートナーを探している。

  • 自治体・DMO:人流・消費・動態データを KPI として使えるようにしたい方

  • 地域事業者(宿泊・飲食・体験・交通):少人数で運営の質と売上を伸ばしたい方

  • 大手企業:自社プロダクト・コンテンツを地域チャネルに乗せたい方

  • 技術パートナー:データガバナンスや AI のレイヤーで力を貸してくださる方

すでに田辺市熊野ツーリズムビューロー、WhyKumano、Stella Locals、尾花沢タクシー、Link and Motivation などとの実証/連携が進んでいる。「面のDX」を一緒に組み立てたい方は、ぜひお気軽にお声がけください。

株式会社 OYKOT

設立: 2024 年 4 月 2 日 / 代表: 佐藤 彗斗(元 株式会社 ZEALS CTO)

拠点: 東京・渋谷 / 和歌山・那智勝浦

事業: 観光 DX「Destination OS」開発、システム開発・コンサル、宿泊業 ほか


出典・参考資料

本記事の統計値は以下の一次資料に基づく(最終確認: 2026年5月)。本文中の数値は丸めて表記している箇所がある。

なお、§3-2 の「Web 解析に取り組む自治体は 40% 未満」、§3-3 の那智勝浦事例(3軒→10軒)、§4 の業務観測エージェントの運用数値は OYKOT 社内データに基づく。出典提供可。