なぜ今「データ標準化」なのか──宿泊DX普及率16%の構造的課題

日本の宿泊業界におけるDX（デジタル・トランスフォーメーション）普及率は、2025年時点でわずか16%にとどまっています。欧米の主要ホテルチェーンがクラウドPMS（Property Management System＝宿泊管理システム）を標準採用し、AIによる需要予測やダイナミックプライシングを日常的に運用しているのに対し、日本ではいまだにオンプレミス型（自社サーバー設置型）のPMSが主流です。

この遅れの根本原因は、単なる「IT投資の不足」ではありません。システム間のデータ連携が標準化されていないという構造的な問題が横たわっています。各PMSベンダーが独自のAPI仕様を採用しているため、あるシステムから別のシステムへデータを受け渡すたびに個別のカスタム開発が必要になります。結果として、中小規模の施設ほど「導入コストが高すぎる」「ベンダーロックインが怖い」という理由でDXを見送ってきました。

こうした状況を打破するために、2026年1月に日本ホスピタリティーテクノロジー協議会（JHTA: Japan Hospitality Technology Alliance）が発足しました。JHTAが推進するHTNG ExpressというAPI標準規格は、PMSと各種外部システム（チャネルマネージャー、RMS、IoTデバイスなど）の間のデータ連携を、共通の「言語」で統一しようとする取り組みです。

本記事では、JHTAの設立背景からHTNG Express APIの技術的な仕組み、そして日本の宿泊施設がこの標準をどう活用すべきかまで、実装レベルで詳しく解説します。

JHTAとは何か──設立の背景と組織体制

設立の経緯

JHTAは、国内のPMSベンダー、OTA（Online Travel Agency）、ホテルチェーン、テクノロジーサービス企業が共同で設立した業界横断の技術標準化団体です。国際的なホスピタリティ技術標準化団体であるHTNG（Hospitality Technology Next Generation）の日本支部的な位置づけを持ちながら、日本市場特有の要件（旅館業法への対応、インバウンド旅客の本人確認フロー、旅行業法との整合性など）を標準仕様に織り込む役割を担っています。

設立メンバーには、大手PMSベンダー数社に加え、クラウドPMS新興企業、国内OTAプラットフォーマー、そしてAIソリューション企業が名を連ねています。経済産業省の「宿泊産業DX推進事業」の枠組みとも連携しており、官民一体でのデータ標準化を進める体制が整いました。

JHTAの3つのミッション

JHTAが掲げるミッションは、以下の3点に集約されます。

  1. HTNG Express APIの日本ローカライズと普及推進：国際標準をベースに、日本の法規制・商慣習に対応した拡張仕様を策定
  2. 認証プログラムの運営：HTNG Express準拠を証明するベンダー認証制度を設け、施設側が「標準対応」製品を安心して選べる環境を整備
  3. データガバナンスガイドラインの策定：個人情報保護法・旅館業法に準拠したデータ共有のルールを明文化

とくに2つ目の認証プログラムは実務上のインパクトが大きく、施設が新しいシステムを導入する際に「JHTA認証マーク」の有無でベンダー選定ができるようになります。これは、AIフロントデスクシステムの比較検討においても、今後重要な選定基準になるでしょう。

HTNG Expressとは──技術仕様の全容

HTNG Expressの設計思想

HTNG Expressは、ホスピタリティ業界向けに設計されたRESTful API標準です。従来のHTNG標準（SOAPベース）が大規模チェーン向けの重厚な仕様だったのに対し、Expressは「軽量・迅速・導入しやすい」をコンセプトに再設計されました。

技術的な特徴を整理すると、以下のようになります。

  • RESTful + JSON：SOAPやXMLではなく、REST APIとJSONフォーマットを採用。現代的なWebアプリケーション開発の標準的な技術スタックと親和性が高い
  • OAuth 2.0認証：APIアクセスにはOAuth 2.0によるトークンベース認証を使用。セキュリティと利便性を両立
  • イベント駆動型通知：Webhook（特定のイベント発生時にHTTP POSTで通知する仕組み）を標準サポート。チェックイン完了や客室ステータス変更などをリアルタイムで外部システムに通知
  • モジュール構成：必要な機能だけを選んで実装できるモジュール型。小規模施設は最小限のモジュールから始め、段階的に拡張可能

主要APIモジュール

HTNG Expressは、宿泊施設の業務領域ごとにAPIモジュールが定義されています。主要なモジュールを見ていきましょう。

1. Reservation API（予約管理）

予約の作成・変更・キャンセルに関するデータ交換を標準化します。OTAやチャネルマネージャーとPMS間のリアルタイム在庫同期が、ベンダーごとの個別開発なしで実現できるようになります。

具体的なエンドポイント例：

  • POST /reservations – 新規予約の作成
  • PUT /reservations/{id} – 予約内容の変更
  • DELETE /reservations/{id} – 予約のキャンセル
  • GET /reservations/{id}/status – 予約ステータスの照会

予約データには、宿泊者情報・宿泊日程・料金・特別リクエスト・支払い情報が標準フィールドとして定義されており、日本向け拡張として「食事プラン」「温泉利用区分」「旅行業法に基づく取引条件」などのフィールドが追加されています。

2. Guest Profile API（顧客情報管理）

宿泊者のプロフィール情報を安全に共有するためのAPIです。リピーター情報の施設間共有や、CDPを活用したハイパーパーソナライゼーションの基盤となるデータ層を提供します。個人情報保護法に準拠した同意管理（コンセント・マネジメント）の仕組みも標準仕様に含まれています。

3. Room Status API（客室ステータス管理）

客室の清掃状態・メンテナンス状況・IoTセンサーデータをリアルタイムで共有します。PMSとハウスキーピングシステム、スマートルームプラットフォーム間のデータ連携を標準化することで、客室運用の完全自動化への道を開きます。

4. Rate & Inventory API（料金・在庫管理）

料金設定と在庫（空室数）の管理を標準化します。ダイナミックプライシングエンジンやRMS（Revenue Management System＝収益管理システム）との連携が容易になり、AIによるリアルタイム料金最適化の技術的なハードルが大幅に下がります。

5. Financial API（会計・決済連携）

フォリオ（宿泊者ごとの会計明細）データの標準化により、PMSと会計ソフト・POSシステム・決済サービス間の自動連携を実現します。これは人的ミスの削減と経理業務の効率化に直結する実務的に重要なモジュールです。

日本のPMS市場が抱える「サイロ化」問題

現状の課題マップ

日本のPMS市場は、大きく3つの層に分かれています。

分類特徴シェア目安API対応状況
レガシーPMSオンプレミス型、独自プロトコル約45%独自仕様のみ、REST API非対応
国産クラウドPMSクラウド型だが独自API約35%各社独自のREST API
グローバルクラウドPMS国際チェーン向け約20%HTNG/OTA標準に部分対応

問題は、この3層間でデータの「方言」がまったく異なることです。たとえば、あるPMSでは宿泊者の氏名を guest_name というフィールドで扱い、別のPMSでは first_name + last_name に分割し、さらに別のPMSでは name_kanji + name_kana という日本固有のフィールドを持っています。

このフィールド定義の不統一は、AIモデルの学習データを作成する際にも深刻な問題を引き起こします。複数施設のデータを統合して需要予測モデルを構築しようとしても、まずデータのクレンジング（整形・標準化）に膨大な工数がかかるのです。

ベンダーロックインの実態

データ標準がない環境では、施設がPMSを乗り換えようとしても、過去の予約データ・顧客データの移行が極めて困難です。あるPMSベンダーのデータエクスポート形式が、新しいPMSのインポート形式と合わない——こうした事態が日常的に発生しています。

結果として、施設は「今のPMSに不満があっても乗り換えられない」というロックイン状態に陥ります。これはイノベーションの阻害要因であり、中小ホテルがAIを導入する際の最大の障壁の一つです。

HTNG Express導入がもたらす5つの変革

変革1：プラグ＆プレイのシステム連携

HTNG Express準拠のPMSとサードパーティシステムは、個別のAPI開発なしで相互接続できます。これは実際に導入すると、システム連携にかかるコストと時間を60〜80%削減できるという仕組みです。

具体例を挙げると、従来はPMSとチャネルマネージャーの連携に3〜6ヶ月のカスタム開発期間を要していたものが、HTNG Express準拠であれば設定ベースで2〜4週間で稼働開始できるようになります。

変革2：マルチベンダー環境の実現

標準APIにより、施設は「ベストオブブリード」（各領域で最も優れた製品を選んで組み合わせる）戦略を取れるようになります。PMSはA社、RMSはB社、ゲストコミュニケーションはC社——という組み合わせが、統合の心配なく実現できます。

変革3：AIモデルの精度向上

データフォーマットが統一されることで、複数施設・複数チェーンのデータを集約したAI学習が現実的になります。需要予測、料金最適化、パーソナライゼーションのいずれにおいても、データ量の増加はモデル精度の向上に直結します。

とくにダイナミックプライシングによるRevPAR最大化においては、市場全体の供給・需要データを標準フォーマットで取得できることが、予測精度を飛躍的に高めます。

変革4：IoTエコシステムの拡大

Room Status APIを通じて、スマートロック・環境センサー・空調制御システムなどのIoTデバイスがPMSとシームレスに連携できるようになります。これにより、チェックイン完了と同時に客室の空調を起動し、照明を歓迎モードに切り替える——といった自動化シナリオが、特別な開発なしで構築できます。

変革5：データポータビリティの確保

HTNG Express標準に基づくデータエクスポート/インポート仕様により、施設はPMSベンダーの乗り換えを自由に行えるようになります。これは市場の健全な競争を促進し、長期的にはサービス品質の向上と価格の適正化につながります。

実装ロードマップ──施設がいま取るべきアクション

フェーズ1：現状アセスメント（2026年Q2〜Q3）

まず自施設のシステム環境を棚卸しします。具体的には以下の項目を確認しましょう。

  • 現行PMSのAPI対応状況：REST APIが利用可能か、HTNG Express対応の計画はあるかをベンダーに確認
  • 連携システムの洗い出し：チャネルマネージャー、RMS、会計ソフト、IoTデバイスなど、PMSと接続しているシステムの一覧を作成
  • データフローの可視化：各システム間でどのようなデータが、どの頻度で、どの方向に流れているかをマッピング
  • ギャップ分析：現状とHTNG Express標準の差分を特定し、移行に必要な作業量を見積もる

フェーズ2：パイロット導入（2026年Q4〜2027年Q1）

最も効果の高い連携ポイントから段階的に実装を開始します。一般的に推奨される優先順位は以下のとおりです。

  1. Reservation API（予約連携）：OTA・チャネルマネージャーとのリアルタイム在庫同期を標準化
  2. Rate & Inventory API（料金・在庫）：ダイナミックプライシングエンジンとの接続
  3. Guest Profile API（顧客情報）：リピーター管理・パーソナライゼーション基盤の構築

この段階では、JHTA認証を取得したベンダーの製品を選定基準に含めることが重要です。認証ベンダーであれば、標準APIの互換性が担保されているため、連携テストの工数を最小限に抑えられます。

フェーズ3：全面展開とAI活用（2027年Q2〜）

パイロットで検証した連携パターンを全システムに拡大し、蓄積された標準化データを活用したAIソリューションの導入に進みます。

  • 需要予測AI：標準化された予約・市場データを入力に、高精度な需要予測モデルを運用
  • パーソナライゼーションAI：Guest Profile APIで統合された顧客データを基に、一人ひとりに最適化されたサービスを提供
  • 運用最適化AI：Room Status API・IoTデータを活用した清掃スケジュール最適化やエネルギー管理

セキュリティとデータガバナンス

データ標準化を進める上で避けて通れないのが、セキュリティとプライバシーの問題です。HTNG Expressでは、以下のセキュリティ要件が標準仕様に組み込まれています。

認証・認可

  • OAuth 2.0 + PKCE：APIアクセスにはOAuth 2.0のAuthorization Code Flow with PKCE（Proof Key for Code Exchange）を採用。トークンの漏洩リスクを最小化
  • スコープベースの権限管理：APIごとに読み取り・書き込みの権限を細かく制御。「予約データは読めるが顧客情報は読めない」といったアクセス制御が可能

データ保護

  • TLS 1.3必須：すべてのAPI通信はTLS 1.3による暗号化が必須
  • PII（個人識別情報）のトークン化：顧客の氏名・住所・カード情報などのPIIは、トークン化して保存・送信することを推奨
  • データ保持期間の明確化：各データ種別ごとに保持期間の上限を定義し、自動削除の仕組みを標準化

宿泊施設が取り扱う個人情報は非常にセンシティブです。ゼロトラストセキュリティの考え方を基盤に据えた上で、HTNG Expressの標準セキュリティ要件を確実に実装することが求められます。

導入コストと投資対効果

コスト構造

HTNG Express対応にかかるコストは、施設の現状環境によって大きく異なります。目安として以下の3パターンを示します。

施設タイプ現状移行コスト目安期間
クラウドPMS利用中ベンダーがHTNG Express対応予定50〜150万円（設定・テスト費用）1〜3ヶ月
クラウドPMS利用中ベンダーが未対応200〜500万円（ミドルウェア導入）3〜6ヶ月
レガシーPMS利用中オンプレミス・独自仕様500〜1,500万円（PMS移行含む）6〜12ヶ月

ROIの試算

投資回収の観点では、以下の効果が期待できます。

  • システム連携コストの削減：年間100〜300万円（個別API開発・保守費用の削減）
  • OTA手数料の最適化：リアルタイム在庫同期により、ダブルブッキングの防止とラストルームアベイラビリティ（LRA）の適正化で年間50〜200万円の機会損失を回避
  • AI活用による収益増：ダイナミックプライシングの精度向上でRevPAR 5〜15%改善
  • 業務効率化：データ入力の二重作業解消で、フロント業務の工数を月間20〜40時間削減

中規模ホテル（客室数50〜100室）の場合、HTNG Express対応への投資は1〜2年で回収できるケースが多いと見込まれています。

2027年に向けた業界展望

JHTAのロードマップによると、2027年末までに以下のマイルストーンが計画されています。

  • 2026年Q3：HTNG Express日本ローカライズ版v1.0の正式リリース
  • 2026年Q4：JHTA認証プログラムの開始。第一弾として主要PMSベンダー5〜10社の認証取得を目標
  • 2027年Q1：パイロット施設50件での実証実験結果を公開
  • 2027年Q2：データガバナンスガイドラインの最終版を公表
  • 2027年H2：HTNG Express対応PMSの市場シェア30%到達を目標

このロードマップが実現すれば、2027年末には日本の宿泊DX普及率が現在の16%から30〜35%まで引き上げられる可能性があります。データ標準化は、個々のAI・IoTソリューションの導入ハードルを下げる「共通インフラ」として機能するため、その波及効果は個別のテクノロジー導入以上に大きいと言えるでしょう。

とくに注目すべきは、生成AIを活用した宿泊プラン作成やOTA最適化との相乗効果です。標準化されたデータ基盤があれば、生成AIが参照できる情報の量と質が飛躍的に向上し、より精度の高いコンテンツ生成や価格提案が可能になります。

まとめ──データ標準化は「守り」ではなく「攻め」の投資

JHTA発足とHTNG Express標準の普及は、日本の宿泊業界にとって構造的な転換点です。データ標準化というと地味なインフラ整備に聞こえるかもしれませんが、実際にはAI活用・IoT連携・収益最適化といった攻めのDXを実現するための最も重要な前提条件です。

施設の経営者・DX推進担当者がいまやるべきことは、以下の3つです。

  1. 現行PMSベンダーにHTNG Express対応の計画を確認する：対応予定がなければ、移行を含めた選択肢の検討を開始
  2. JHTAの動向をウォッチする：認証プログラムの開始時期や対応ベンダーリストの情報を継続的に収集
  3. データフローの棚卸しを始める：現状のシステム連携マップを作成し、標準化移行の準備を進める

「まだ早い」と感じるかもしれませんが、データ基盤の整備には時間がかかります。2027年にAI活用の本格展開を目指すなら、いまこの瞬間が準備を始める最適なタイミングです。