PMS標準データセットとは？宿泊施設が知っておきたい中身と使いどころ
こんにちは、リテールアプリ共創部のmorimorikochan@大阪です
ホテル業界のDXについていろいろ調査してみるとPMS標準データセットなるものが存在していることを最近知りました。
せっかくなので、PMS標準データセットの中身の説明や宿泊施設事業者・ベンダーにとってどういう点が嬉しいのか感じたことについてまとめてみましたので、参考になれば幸いです。
PMS標準データセットとは
PMS標準データセットは、観光庁事業の成果物をもとにJHTAという団体が業界標準のデータセットとして仕様を整理したものであり、PMSが持つべきデータについて項目名やデータ型などを一つに揃えた定義書です。
一言でPMSとサイトコントローラー、自動チェックイン機、会計、CRMなどのシステム同士が使う、共通の辞書にあたります。
現在の版はv1.0で。定義書（Googleスプレッドシート）、PMSベンダー向けの利用の手引き（PDF）、国内外の仕様の比較表（PDF）の3点が公開されています。
宿泊施設にとって何が嬉しいのか
標準データセットに沿ったPMSや周辺システムが増えると、施設には次のような変化が期待できそうです。
入れたいシステムを、高額なカスタマイズ費用で諦めずに済む
新しいシステムを導入しようとしたとき、「PMSが対応していないため、高額なカスタマイズが必要」と見積もられて断念した経験はないでしょうか。
標準データセットの策定時に行われた調査では、宿泊施設の63%が同様の経験をしていました[1]。
PMSと周辺システムが同じ定義でデータを扱えれば、連携のたびに個別開発する部分が減り、導入のハードルが下がります。
周辺システムをつなぐ費用と期間が下がる
現在は、システム同士をつなぐたびに、項目名や値の意味をすり合わせる「通訳」の作業が発生しています。
たとえばゲストの「姓」ひとつ取っても、仕様ごとに呼び名が違います。
| 仕様 | 「姓」の項目名 |
|---|---|
| PMS標準データセット | name_last |
| GIF（デジタル庁） | familyName |
| HTNG Express | name_last |
| OpenTravel（OTA 1.0 / 2.0）[2] | PersonName / Surname |
| TravelXML | GuestSurName |
データの値も同じで、「未清掃」や「清掃中」をどんな値で表すかはシステムごとに異なります。
この対応付けを連携のたびに設計してテストするため、費用と期間がかかります。
双方が標準に沿っていれば、この作業を小さくできます。
標準がない場合とある場合のシステム連携の比較
PMSを替えるときにデータを持っていきやすい
PMSのリプレイスでは、予約、顧客、売上のデータ移行が大きな負担になります。
項目の意味とコードが標準で決まっていれば移行時の対応付けが楽になり、特定のベンダーに縛られにくくなります。
複数の施設やPMSのデータを同じ物差しで比べられる
複数の施設を運営していると、施設ごとにPMSが違うことがあります。
部屋タイプや売上科目の分け方が施設ごとに違うと、横並びで集計するたびに手作業の変換が必要です。
共通のコードを軸にすれば、施設をまたいだ集計や比較がしやすくなります。
海外OTAやインバウンド向けシステムとつなぎやすい
標準データセットは、世界の宿泊業界で広く参照されているOpenTravel Allianceのコードリストを21種採用しています。
海外OTAやCRS（セントラル予約システム）など国際的なシステムも同じコード体系を参照しているため、海外との連携を見据えたときの土台になります。
PMS標準データセットの中身
全体像
| カテゴリ | 主な内容 | 項目数 |
|---|---|---|
| 予約情報 | 予約番号、宿泊期間、人数、支払方法、キャンセル料 | 110 |
| 売上会計 | 売上明細、税、サービス料、支払区分 | 45 |
| 個人情報 | 氏名、連絡先、国籍、パスポート | 31 |
| 施設・設備 | 施設コード、名称、住所、館内設備 | 31 |
| 客室情報 | 部屋番号、広さ、部屋ステータス、清掃状態 | 27 |
| 宿泊情報 | チェックインからチェックアウトまでに使うデータのまとまり | 8 |
これとは別に、選択肢の値を定めたコードリストが約2,000件あります。
予約情報
最も多い110項目を占めます。
予約番号、チェックイン日、チェックアウト日、泊数、人数、支払方法、キャンセル料などです。
予約番号は、旅行会社側の番号、施設側の番号、CRSの番号を別々の項目として持ちます。
人数は大人を男女別に、子供を子供料金の区分（子供A〜D）ごとに持てるようになっており、日本の宿の料金体系に合わせています。
客室情報
部屋番号、階数、広さ、畳数、最大収容人数に加えて、部屋ステータスと清掃状態を持ちます。
部屋ステータスは「空室」「滞在中」「出発予定」「故障中」など7種類、清掃状態は「未清掃」「清掃中」「点検待ち」「点検完了」など6種類のコードで表します。
フロント、清掃担当、清掃管理システムの間で部屋の状態をやり取りする場面を想定した項目です。
売上会計
売上明細の1行ごとに、サービス料、消費税、入湯税、宿泊税を、それぞれ「込」「別」「対象外」などの区分と金額で持ちます。
領収書番号、POS伝票番号、売掛先もあり、会計システムやPOSとの連携に使えます。
個人情報、施設・設備、宿泊情報
- 個人情報：氏名（漢字とカナ）、国籍、言語、住所、電話番号、パスポート番号、食事制限やアレルギーなど
- 施設・設備：施設コード、名称、住所、施設種別、標準のチェックイン時刻、館内設備など
- 宿泊情報：チェックインからチェックアウトまでに使う情報。客室情報、予約情報、売上会計を参照する形で定義されています
定義書の読み方
各シートは共通の列で構成されています。
| 列 | 内容 |
|---|---|
| 項目名（日本語、英語） | 英語名（name_last など）はAPIのフィールド名に使える |
| 必須/推奨/任意 | 実装の必須度 |
| データ型、コードリスト | 値の型と、参照するコードリスト |
| 各種標準仕様マッピング | GIFやTravelXMLなど他の仕様で対応する項目名 |
全項目を読み込む必要はありません。
自社で使っているデータがどの項目にあたり、必須かどうかを拾い読みすれば十分だと考えています。
コードリストで選択肢まで揃える
コードリストとは
項目名を揃えても、中に入る値がばらばらだと連携はできません。
たとえばベッドタイプを、あるシステムは「TW」、別のシステムは「ツイン」と表す、といった状況です。
こうしたずれを防ぐために、選択肢の値をあらかじめ決めた一覧がコードリストです。
標準データセットには41種が定義されています。
| 種類 | 数 | 例 |
|---|---|---|
| OpenTravel準拠 | 21種 | ベッドタイプ、眺望、支払方法、食事プラン、施設種別、売上科目分類 |
| JHTA独自 | 14種 | 部屋ステータス、清掃状態、予約ステータス、消費税区分、入湯税区分、宿泊税区分 |
| ISO等 | 6種 | 国、通貨、言語、性別、日付と時刻の書式 |
日本の宿に合わせた独自コード
JHTA独自の14種は、国際標準ではカバーできない日本の業務に対応するためのものです。
清掃の優先度や、入湯税と宿泊税の「込」「別」のように、日本の宿ならではの区分が定義されています。
旅館や日本の宿ならではの項目
日本の宿には、国際標準にない客室仕様があります。
標準データセットでは、これらを次のように扱っています。
| 日本固有の仕様 | 扱い方 |
|---|---|
| 露天風呂付き客室 | 客室設備のコードで管理。OpenTravelに該当コードがなければ独自コードを付ける |
| 和洋室 | 「和室」「洋室」「和洋室」を独自項目として管理 |
| 部屋食 | 朝食と夕食の提供場所を独自項目として管理 |
| 畳数 | 独自項目として管理し、広さ（㎡）と併用 |
また、利用の手引きでは、策定の過程で見つかった「旅館」「露天風呂付き」「温泉付き」を、OpenTravelのコードへの追加申請の候補として挙げています。
申請はJHTA事務局を通じて行う方針のようです。
誤解しやすいポイントと、まだ決まっていないこと
標準データセットはAPIではない
標準データセットが決めているのは、データの項目名、データ型、コードまでです。
データをどう送受信するか（APIで送るのか、ファイルで受け渡すのか、どんな通信方式を使うのか）は決めていません。
共通の辞書はできたものの、電話回線は各社がそれぞれ用意する状態です。
共通の辞書と電話回線のたとえ
そのため、「標準データセットに対応すれば自動でつながる」わけではありません。
実際につなぐには、PMSと周辺システムがそれぞれ連携の口（APIなど）を用意し、項目を標準に合わせる、または変換する実装が必要です。
他の仕様との対応表も参考情報という位置づけで、手引き自身が、実際の連携では各仕様の原典を確認するよう注記しています。
対象外のもの
旅館業法に基づく宿泊者名簿や、省令に基づくパスポートの確認に必要な情報は、すべてが定義に含まれているわけではありません（定義書にも注記として記載されています）。
法令対応に必要なデータは、別途確認が必要です。
未定義、暫定のもの
滞在中に利用するサービスの情報（食事の受付や予約、貸切風呂などの設備予約、貸出備品）は、今回は定義されていません。
客室の属性を組み合わせて販売するABS（Attribute Based Selling）も、運用モデルが今後の検討課題とされ、暫定の位置づけです。
v1.0であり、今後更新される
標準データセットはJHTA事務局が管理し、更新履歴でバージョンを管理します。
手引きでは、PMS側で対応しているバージョンを管理することを推奨しています。
宿泊施設はどう活用すればよいか
PMSの選定やリプレイスで、対応方針を確認する
PMSを選ぶときやリプレイスを検討するときは、標準データセットへの対応方針をベンダーに確認します。
現時点で未対応でも、今後の方針を聞いておけば、周辺システムを追加するときやデータを移行するときの見通しが立ちます。
RFP（提案依頼書）には、たとえば次のように書けます。
データ項目名およびコード値について、JHTA PMS標準データセット（v1.0）への対応方針（対応の可否や対応範囲など）を提示してください。未対応の項目がある場合は、その一覧と理由を明記してください。
周辺システムの発注で、標準に合わせてもらう
自動チェックイン機、清掃管理、会員アプリなどを発注するときも、やり取りするデータの項目名とコードを標準データセットに合わせるよう依頼します。
PMS側が未対応でも、周辺システム側を標準に寄せておけば、将来PMSが対応したときや別のシステムを追加するときの改修が少なくて済みます。
複数施設のデータを集約するときの物差しにする
施設ごとにPMSが違う場合、データを集約するときの共通の形式として標準データセットを使えます。
各PMSのデータを標準の項目とコードに変換してから集めれば、部屋タイプや売上科目の分け方の違いを吸収できます。
自社独自のデータの扱いを決めておく
独自の設備や区分のように、標準のコードにない値を持つ施設もあるでしょう。
手引きでは、独自コードを持つ方法として次の2つを示しています。
- 同じ一覧で管理する：OpenTravelのコード（1〜999）と衝突しないよう、独自コードは1000番以降を使う
- 別の一覧で管理する：独自コードを別に持ち、OpenTravelのコードとの対応表を用意する
どちらを採るかはPMSの作りや連携先によって決まるため、ベンダーに確認しておきます。
開発者から見た定義書の良さ
ここからは、システムを開発する私の立場から、PMS標準データセットを読んで感じたことを書きます。
宿泊業のドメイン知識を習得しやすい
宿泊業向けのシステムを作るには、子供料金の区分（子供A〜D）、入湯税と宿泊税の扱い、清掃状態の移り変わりといった業界固有の知識（ドメイン）が欠かせません。
こうした知識は、これまで案件ごとに施設やPMSベンダーから聞き取って集めることが多くありました。
標準データセットにはこれらが252項目とコードリストとして整理されているため、宿泊業に新しく関わる開発者やベンダーにとって、ドメインを習得しやすくなります。
データ同士の関係が読み取れる
予約情報シートでは、分類名に「予約基本情報に対して部屋数分」「部屋に対して宿泊日数分」といった注記があり、データ同士の関係が読み取れます。
- 1件の予約に、部屋利用情報が部屋数分ある
- 部屋利用情報は、客室情報を必ず1つ参照する
- 部屋利用情報ごとに、宿泊料金情報が宿泊日数分ある
キーの指定まではありませんが、「1つの予約で3部屋を2泊」のような予約をどう持てばよいかが定義書から分かります。
テーブル設計やAPIのデータ構造を考えるときの出発点になります。
業務の段階ごとに情報を積み上げる構成
宿泊情報シートには、予約から会計までの流れに沿って、各段階で加わる情報を示した図があります。
単一のデータに予約の全段階の情報を持たせるのではなく、段階ごとに起きた事実を別の情報として足していく構成です。
これは、システム開発でイミュータブルデータモデル[3]と呼ばれる考え方に近いものだと思っています。
反対に、1つのテーブルに全段階の情報を詰め込みステータスや日時の列を上書きしていく設計では、開発する際や機能改修する際に以下のような問題が起きやすくなります。
- 段階ごとに「どの列を更新してよいか」というルールが増える。そのルールはテーブル定義から読み取れず各処理に散らばるため、更新漏れや意図しない上書きによる不具合につながる
- 上書きすると前の状態が残らない。「ある時刻に未清掃の部屋が何室あったか」のような集計や、障害時の原因調査が難しくなる
- 段階が増えるたびに列が増え、まだその段階に達していないデータには空の列が並ぶ
このような問題を構造上防ぐイミュータブルデータモデルが採用されている点は、
点はエンジニアとして安心感があり嬉しいです。
なお、標準データセットはシステム間でやり取りするデータの定義で、各社のテーブル設計まで決めているわけではありません。
図の見出しも「追加・更新していく」となっており、上書きを一切しない前提ではありません（鍵情報と利用サービス情報も今回は未定義です）。
それでも、業務の段階ごとに情報を分けた定義に沿って作れば、システム側も同じ分け方で設計しやすくなります。
まとめ
PMS標準データセットは、PMSが持つべきデータの項目名とコードを業界で揃えた、いわば共通の辞書です。
APIではないため、対応しただけでシステムがつながるわけではありません。
ただ、施設とベンダーが同じ言葉で話せるようになるため、PMSの選定や周辺システムの発注で「何に、どこまで対応しているか」を具体的に確認できます。
PMSの更新や新しいシステムの導入を検討する前に、一度目を通しておくとよいでしょう。
参考資料
宿泊施設24社とPMSベンダー5社を対象としたアンケート。83%の施設が「API標準化」を最も期待する機能に挙げ、回答したPMSベンダーはいずれもOpenTravelやHTNGなどの国際標準に対応していませんでした（JHTA「PMS標準データセット定義書の公開について」）。 ↩︎
手引きや定義書では「OTA」と略記されています。オンライン旅行会社（Online Travel Agent）のOTAと混同しないよう、この記事では「OpenTravel」と表記します。 ↩︎
kawasima さんが提唱するデータモデリング手法。エンティティを「リソース」と「イベント」に分け、イベントは追加のみで更新しないように設計する（イミュータブルデータモデル - kawasima）。 ↩︎
