藏立裕太

Delta PMSの特徴

前回の記事「PMSの成り立ち」では、PMS（Property Management System）の歴史的な経緯を整理しました。本記事では、その前提を踏まえ、Delta PMSの設計方針（構成・連携・運用）を説明します。

既存PMSの「構造的な限界」

まず、宿泊業界で一般的に見られるシステム構成上の論点を整理します。

日本の宿泊業界では、PMS・サイトコントローラー・OTA/予約エンジンという3つのシステムが、それぞれ別のベンダーによって提供され、独立して動いています。いわゆる「サイロ構造」です。加えて、チェックイン／本人確認、決済、ゲスト向けCRM・メッセージング、清掃・メンテナンス管理などの周辺領域も、個別システムとして導入されることが多く、全体としてサイロが増えやすい構造になっています。

この構造により、連携遅延や同期不整合が発生しやすくなります。

PMS上で料金を変更しても、チャネル側の反映にタイムラグが出る場合があります。在庫同期でエラーが起きると、ダブルブッキング等の運用リスクが増えます。その結果、スタッフが複数システムの確認や転記、補助的な表計算での管理を行うケースが発生します。

次に、導入形態（オンプレミス／クラウド）と外部連携（API等）の設計が、運用コストと拡張性に影響します。国内ではオンプレミス運用の製品も多く、更新作業や連携開発がボトルネックになりやすい構造があります。JHTA（Japan Hospitality Technology Association）が、国際標準APIの枠組み（HTNG Express等）の活用を掲げているのは、データ連携の標準化が業界課題として認識されていることを示します。

また、宿泊施設では24時間稼働が前提となるため、更新・移行・障害対応のリスクが相対的に高くなります。これが製品更新やリプレイスの難易度を上げ、結果としてレガシー化が進みやすい要因になります。大手が自社開発を選択するケースがある背景として、個別要件への最適化や運用制約への適応が挙げられます。

システムの断片化は、運用負荷（確認・転記・例外対応）を増やしやすい構造要因です。

厚生労働省の「雇用動向調査」では、宿泊業・飲食サービス業は入職率・離職率ともに高い水準にあります（就業形態別の数値は年次で変動）。また、帝国データバンクの「人手不足に対する企業の動向調査（2024年7月）」では、「旅館・ホテル」で人手不足（正社員）を感じる企業割合が65.3%と報告されています。人手不足下では、運用負荷の増加がサービス品質や収益性に影響するため、システム設計・連携の改善余地が大きくなります。

なぜDelta PMSをオールインワンで設計したか

ニセコでの現場ヒアリングでは、複数システム間の確認・転記・例外対応が、現場時間を消費しているケースを確認しました。Delta PMSは、この運用負荷を設計で減らすことを目的にしています。

Delta PMSの設計方針は、以下の3点です。

オールインワン。 PMS・チャネルマネージャー・予約エンジンを一体で設計し、データ整合と運用を単一の基盤で扱います。構成分割に起因する連携遅延・同期不整合・例外対応を減らすことを目的にしています。

クラウドネイティブ／AIファースト。 クラウド運用は前提としたうえで、AIを標準機能として組み込み、定型業務の自動化と意思決定補助を最初から設計に含めます。

カスタマイズ可能。 施設・運営会社ごとの運用差分に合わせて、要件定義から実装まで対応します。他ベンダーが受け付けない領域のカスタマイズも、提供価値と運用負荷の改善が見込めるものは対象にします。

PMSは、在庫（客室）・料金・運用・会計・分析の整合を維持するための基盤として位置づけます。

オールインワンSaaSという選択

Delta PMSは、PMS・チャネルマネージャー・ブッキングエンジンを一体化したオールインワンSaaSです。

「なぜ分けないのか」という質問には、構成分割が連携遅延・同期不整合・例外対応を増やしやすい、という観点で回答します。

3つのシステムが同じデータベース上で動いているということは、料金を変更した瞬間にすべての販売チャネルに反映されるということです。在庫の更新にタイムラグはありません。ダブルブッキングのリスクは構造的に排除されます。1つのダッシュボードで、客室の稼働状況、各OTAの販売状況、自社予約の推移、売上データをリアルタイムで把握できます。

ここでの狙いは、整合確認や例外対応に使われる時間を減らし、業務時間の再配分を可能にすることです。

AI Digital Workerという考え方

Delta PMSには、AIによる業務自動化機能を組み込んでいます。私たちはこれを「AI Digital Worker」と呼んでいます。

具体的には、予約処理の自動化、需要予測に基づく料金最適化（レベニューマネジメント）、ゲストからの問い合わせ対応などです。これらはいずれも、定型的でありながらスタッフの時間を大量に消費する業務です。

運用上の原則は、「提案・生成」はAI、「意思決定・責任」は人間です。

AIが需要予測に基づいて料金案を提示する。でも最終的にその料金で販売するかどうかを決めるのは人間です。AIがゲストの問い合わせに対する回答を生成する。でもその回答を送信するかどうか、あるいはここは人間が直接対応すべきかの判断をするのは人間です。

Delta PMSにおけるAIの役割は、定型業務の自動化・意思決定補助により、運用負荷を下げることです。

業務時間のうち、システム操作やデータ転記に相当する比率が大きい場合、削減余地は運用効率（処理量、ミス率、教育コスト等）に直結します。

OEM対応 ── ホテルが「自分たちのシステム」を持てるように

Delta PMSはOEM提供にも対応しています。これは、ホテルチェーンや運営会社が、Delta PMSをベースにした「自社ブランドのPMS」を持てるということです。

大手が自社PMS開発を選択する背景として、個別要件への適合、運用制約への適応、継続的な改善サイクルの確保などが挙げられます。

しかし、すべてのホテルチェーンが自社でPMSをゼロから開発できるわけではありません。Delta PMSのOEMモデルは、この課題に対する現実的な解決策です。クラウドネイティブなプラットフォームをベースに、各社のブランド体験やオペレーションフローに最適化した「自前のシステム」を、ゼロから開発するよりもはるかに短期間・低コストで実現します。

OEMは、ブランド要件や運用フローの差分を、単一プロダクトの枠内で吸収するための提供形態です。

3層戦略 ── Delta PMSはゴールではなくスタートライン

最後に、Delta PMSの位置づけを整理します。

私たちには3層の戦略ロードマップがあります。

Layer 1: オペレーションオールインワンSaaS。 これがDelta PMSです。まず、宿泊施設のオペレーションをデジタライズし、セントラル化する。バラバラだったシステムを一つに統合し、データが一箇所に集まる基盤を作る。

Layer 2: エコシステム構築。 ホテルを起点に、周辺の飲食店、アクティビティ事業者、交通機関など、地域のビジネスをつなぐプラットフォームを構築します。ホテルは地域経済のハブになりえます。

Layer 3: AI Agent化。 Layer 1で蓄積されたデータを活用し、AIがより高度な業務判断をサポートします。人手不足が構造的な問題である以上、AIによる業務代替は避けて通れません。

Delta PMSは、この3層戦略のLayer 1です。上位レイヤー（エコシステム、AI活用）を成立させるための前提として、運用データと業務フローの基盤を整備します。

おわりに

Delta PMSは、運用負荷の削減とデータ整合の担保を目的に、クラウド、API、モジュール構成を前提として設計しています。これにより、連携・運用・改善のコストを下げ、現場運用の安定化と意思決定の高速化を支援します。

参考文献・参照元