宿泊予約サイトと客室管理システムをつなぐ案件は、宿泊業のデジタル化が進むほど増えています。ただし現場で聞こえてくるのは「項目名をそろえれば済む」という単純な話ではありません。観光庁の調査事業でまとまった提言書には、接続そのものが妨げになっている実態と、そろえようとしても最後までそろわない項目があるという、二段構えの詰まり所が記録されています。この記事では、その詰まり所がどこにあり、外から入るエンジニアが何を線引きする仕事なのかを整理します。

1. 詰まっているのは業務ではなく接続

「入れたいのに入れられない」という声

宿泊施設の現場でよく語られるのは、「新しいシステムを入れたいのに、既存のPMSとつながらない」という悩みです。予約管理や顧客管理を効率化するツールを検討しても、最後は接続の壁に当たって話が止まってしまいます。

観光庁の調査事業のアンケートでは、宿泊施設の63%（24施設中15施設）が「PMSの制約により導入したいシステムの導入を断念した経験がある」と回答しています¹。この数字が示しているのは、業務そのものの難しさではなく、接続の難しさだという点に注意が必要です。

断念の理由は業務ではなく、接続そのもの

「業務が複雑だから標準化が進まない」という見立てを耳にすることがあります。しかし今回の調査が拾っているのは、業務プロセスそのものではなく、既存のPMSが外部システムとの接続を前提にしていないという構造です。入れたい機能があっても、土台となるシステムが受け止められなければ導入は止まります。

現場が抱えているのは、業務知識の問題ではなく、接続経路が用意されていないことです。ここを取り違えると、標準化の案件に入るエンジニアも見当違いの改善提案をしてしまいます。

断念の経験があるという回答は、この調査に協力した24施設という限られた標本の中での割合です¹。全国すべての宿泊施設で同じ比率が起きているとは言えませんが、複数の施設で共通して「接続で止まる」という声が上がっている点は、案件の設計を考えるうえで見過ごせない手がかりです。

外から標準化の案件に入るエンジニアにとって、最初に見るべきは業務フローの複雑さではなく、既存のPMSがどんな接続方式を持っているか、持っていないかです。ここを最初に確認する視点があるかどうかで、提案の的中率が変わります。

接続の窓口をどう棚卸しするかで、案件に入った直後の動き方が変わります。窓口が無ければゼロから設計するところから、既にあれば標準データセットの型に合わせるところから始めるため、最初の見立てがそのまま後工程の見積もりに影響します。同じ「標準化案件」という名前でも、中身はこの見立て次第でまったく違う仕事になります。

出典：観光庁「データセット仕様に関する提言書」（2026年3月）をもとに作成

2. 現場は標準化を求めている

接続方式の標準化を望む声が8割を超える

断念の経験がある施設が目立つ一方で、現場からは前向きな要望も上がっています。同じ調査では、宿泊施設の83%（24施設中20施設）がAPI接続方式の標準化を期待し、71%（24施設中17施設）が連携費用の低減を期待していると回答しています²。

この2つの数字は、接続の入口と、接続にかかる負担の両方に不満があることを示しています。標準化を求める声のほうが費用低減を求める声よりわずかに高いのは、まず「つながる形」が定まらないことには、費用の話をする土台すらできないという事情がうかがえます。

求めているのは費用の妥当性であって、無償化ではない

費用を下げることよりも、先に接続の形を決めることのほうが優先度が高いという読み方ができます。順番を取り違えると、値下げの交渉をしても接続方式が変わらないまま費用だけを議論することになりかねません。

外から標準化の案件に入るエンジニアが担う役割は、この期待に応える設計です。API接続方式そのものを案件ごとに作り直すのではなく、共通の型に寄せていく作業が、現場が最も求めていることに直結します。

ここでも忘れてはいけないのは、この数字が24施設という標本の中での割合だという点です²。業界全体を代表する数値として一人歩きさせず、複数の施設で共通して挙がった要望として受け止めるのが妥当です。

現場が挙げた2つの期待

表1に、この2つの期待の内訳をまとめます。数字の近さは、接続方式と費用が別々の課題ではなく、ひとつながりの課題として現場に認識されていることを表しています。

現場が期待していること	該当施設数	回答した施設に占める割合
API接続方式の標準化	20/24施設	83%
連携費用の低減	17/24施設	71%

現場が挙げているのは接続方式と費用の2点ですが、いずれも一度型を決めてしまえば、その後の連携でも繰り返し使える資産になります。個別の案件ごとに一から接続方式を検討する状態から、共通の型を土台に差分だけを詰める状態へ変わることが、標準化が現場にもたらす一番の効果です。

この作業に必要なのは、個別のPMSの仕様に詳しいことよりも、複数のシステムの違いを共通の言葉に置き換えられる設計力です。API設計やデータのマッピングを扱ってきた経験は、宿泊業に限らずこうした案件で生きてきます。

3. そろえる作業は進んでいる

国内外6つの仕様を比較し、共通の型を作る

標準化と聞くと途方もない作業に思えますが、進んでいる部分もあります。国内外6つの標準仕様を体系的に比較分析し、日本の宿泊業界に適した標準データセットの第一版が策定されました³。

バラバラだった仕様を並べて、共通する部分と異なる部分を仕分ける作業は外から見えにくいものの、着実に前に進んでいる工程です。ゼロから型を作るのではなく、既にある6つの仕様を土台にしている点は、標準化案件に入るエンジニアにとって心強い材料です。

252項目という規模感

この第一版は、6カテゴリ・252項目という規模で定義されています。内訳は個人情報31項目、客室情報27項目、予約情報110項目、売上会計45項目、施設・設備31項目、宿泊情報8項目です⁴。

項目数の多さそのものより、どのカテゴリに項目が集中しているかを見るほうが、案件の難所を予測する手がかりになります。予約情報が110項目と突出しているのは、予約という工程が最も細かい条件分岐を抱えていることの表れです。

一方で、この土台をそのまま使える状態のPMSは限られています。国際標準仕様に対応しているPMSベンダーは、調査に協力した5社のうち0社でした⁵。

標準データセットという共通言語ができても、それを話せるシステムがまだ揃っていない状態です。ここに、外から標準化の案件に入るエンジニアが担う変換層の設計という仕事が生まれます。

出典：観光庁「データセット仕様に関する提言書」（2026年3月）をもとに作成

252項目の内訳

策定された標準データセットの252項目は、6つのカテゴリに分かれています。表3にその内訳をまとめました。予約情報が110項目と他のカテゴリに比べて突出しており、細かい条件分岐が必要になることがうかがえます⁴。

カテゴリ	項目数
予約情報	110項目
売上会計	45項目
個人情報	31項目
施設・設備	31項目
客室情報	27項目
宿泊情報	8項目

表3の内訳を見ると、予約情報のように工程が複雑なカテゴリほど項目数が多いことが分かります。標準化案件でどのカテゴリから着手するかを判断するとき、この内訳は優先順位を考える手がかりになります。

変換層の設計は一度作れば終わりではありません。新しいPMSが増えたり、自治体の条例が変わったりすれば、そのたびに更新が必要になります。ここを見込んで拡張しやすい形で設計しておくと、後から手戻りが少なくなります。

4. そろえられない項目がある

同じ「子供料金」でも軸が違う

ここまでは「そろえる」話でした。ところが同じ提言書には、そろえようとしても最後までそろわない項目も記録されています。代表例が子供料金体系です。

とりわけ子供料金体系の差異は、データ構造レベルでの互換性がなく、単純な変換では対応できません。日本の区分は旅館文化の「1泊2食付き」という料金体系から派生した商習慣であり、国際標準の年齢ベースの区分とは、分類の軸そのものが異なります⁸。

「変換表を作れば済むはず」と考えたくなる場面ですが、軸そのものが違う項目に変換表を当てはめると、どこかで意味がずれます。サービス内容を基準にした区分と、年齢を基準にした区分は、同じ「子供料金」という言葉を使っていても測っているものが違います。

軸が違う項目は、変換ではなく別の欄として残す

この違いは料金の単位にも表れています。宿泊施設の83%（24施設中20施設）が「1人あたり」を基本的な料金設定単位としています⁶。1室あたりで考える国際標準の発想とは、出発点が異なります。

「項目を合わせること」よりも「軸が違うと見極めること」のほうが、この場面では価値が大きい仕事です。合わせられない項目を無理に合わせようとすると、どこかの施設で数字がずれます。

さらに機能そのものが無い場合もあります。PMSベンダーの60%（5社中3社）は、子供料金の設定機能を持っていません⁷。軸の違いを設計で吸収する以前に、そもそも入力する欄が無いケースです。

分類の軸の違いを一覧にする

子供料金をめぐる軸の違いを表2に整理しました。基準にしているものが違うため、片方をもう片方に単純に変換すると意味がずれます⁸。

項目	そろわない内容
子供料金の分類軸	日本はサービス内容ベース（1泊2食付きの料金体系から派生）、国際標準は年齢ベースで、分類の軸そのものが異なります8
料金設定の単位	宿泊施設の83%（20/24施設）が「1人あたり」を基本の単位にしています6
PMS側の対応	PMSベンダーの60%（3/5社）が子供料金の設定機能を持っていません7

この線引きの仕事は、要件を言葉にして残す経験があるほど力を発揮しやすい領域です。データを変換する実装そのものよりも、なぜ変換できないのかを仕様書に書き残す作業のほうが、後工程のやり直しを防ぎます。

5. 制度の側でも分かれている

同じPMSでも、自治体が変われば必要な項目が変わる

そろわない理由は、システムの設計だけにあるわけではありません。同一のPMSであっても、施設の所在自治体によって宿泊者名簿に必要なデータ項目が異なるため、全国統一のデータ標準化が構造的に困難な状況にあります⁹。

同じ製品を使っていても、自治体ごとに求められる項目が違えば、標準データセットの中に「この自治体では必須」「別の自治体では不要」という分岐が残ります。これはPMSベンダー側の話ではなく、宿泊者名簿の項目を定める仕組みが自治体ごとに存在しているという、制度の成り立ちによるものです。

全国共通の型を作りにくいのは、システムの問題だけではない

「なぜ全国共通のフォーマットにできないのか」という疑問を持つのは自然です。ただしこの差異は、特定の自治体の対応が遅いという話ではなく、宿泊者名簿という制度そのものが、自治体ごとの条例に基づいて運用されてきた経緯を反映しています。

システムの標準化よりも先に、制度の標準化が必要な場面があるということです。標準データセットの設計に入るエンジニアは、この2つを混同せず、システム側で吸収できる差異と、制度側の違いとして残る差異を分けて扱う視点を持てると強みになります。

制度側の違いをシステムだけで解消しようとすると、どこかの自治体の運用に合わなくなります。むしろ自治体ごとに異なる項目を「可変の欄」として設計に残しておくほうが、実態に合った作り方です。

ここまで見てきた3つの詰まり所は、接続の壁、分類の軸の違い、そして制度による違いです。共通しているのは、どれも「そろえれば解決する」という単純な話ではなく、そろわない理由がそれぞれ別の場所にあるという点です。

自治体ごとの違いを一覧にして要件定義書に明記しておくことが、後から案件に加わるメンバーの手間を減らします。制度による違いは無くせませんが、見える形にしておくことはできます。

図の作成：Remogu編集部。観光庁「データセット仕様に関する提言書」（2026年3月）の記述をもとに整理したもので、統計データではありません

6. まとめ

この記事で見た3つの詰まり所は、宿泊業に限った話ではありません。接続の壁、分類の軸の違い、制度による違いは、業種を問わずデータ連携の案件で繰り返し現れる型です。自分が関わる連携案件でも、同じ問いを立ててみることができます。

ここまで見てきた詰まり所を並べると、共通する答えが見えてきます。標準化の仕事は、項目をひとつ残らずそろえることではなく、そろう項目とそろわない項目を見分け、そろわないものを「変換しない」と決めて設計に残すことです。

接続の壁は解消できる部分がありますが、分類の軸の違いや、自治体ごとの制度の違いは、変換ではなく「別の欄」として残すしかない場面があります。すべてをそろえようとする設計は、どこかで破綻します。

「全部そろえる」という前提を疑うところから、標準化の設計は始まります。何を変換し、何を変換しないと決めるかを言葉にできれば、それは特定の業種に縛られない強みになります。

全部そろえる設計よりも、そろわない理由を言語化できる設計のほうが、長く使えるシステムになります。国際標準に対応しているPMSベンダーは、調査対象の5社中0社でした⁵。つながっていない場所は、まさにこれから作られていく領域です。

案件の90%以上がフルリモート可能です¹⁰。このような線引きの仕事に携わる経験は、次の案件でも通用する判断材料になります。まず登録して、自分の経験がどの詰まり所に生きるのかを、実際の案件情報で確かめてみるのも一つの進め方です。

7. よくある質問

宿泊施設24施設という調査規模で、実態を語ってよいのでしょうか

今回取り上げた数字は、観光庁の事業に協力した宿泊施設24施設、PMSベンダー5社という調査に基づくものです¹。全国の宿泊施設を網羅した数字ではないため、断定的な傾向として広げず、複数の施設で共通して挙がった課題として読むのが適切です。案件の現場では、この調査と同じ傾向が出ることもあれば、出ないこともあります。案件に入るときは、この調査の傾向を仮説として持ちつつ、実際の現場で確かめる姿勢が実務では役立ちます。

そろえる作業と、そろえない判断は、どちらが難しいのでしょうか

項目をそろえる作業は手間がかかりますが、進め方自体は見えています。実際に6カテゴリ・252項目の標準データセットの第一版が策定されています⁴。難しいのは、子供料金体系のように分類の軸そのものが異なる項目を見極め、変換せずに残すと決める判断です⁸。ここは経験による見極めが必要な部分です。

外から入るエンジニアは、まず何を確認すればよいのでしょうか

最初に確認したいのは、既存のPMSがどんな接続方式を持っているか、持っていないかです。国際標準仕様に対応しているPMSベンダーは、調査対象の5社中0社でした⁵。接続の土台がどこまで整っているかを見極めることが、設計の出発点になります。

そろう項目とそろわない項目は、どう仕分ければよいのでしょうか

仕分けの考え方を図4に整理しました。項目ごとに「変換して統一する」か「そのまま別の欄として残す」かを分けて扱うのが、この記事で見てきた3つの詰まり所に共通する解き方です。

図の作成：Remogu編集部。この記事で取り上げた詰まり所を整理したもので、統計データではありません

分類の軸が違う項目は、無理に変換せず別の欄として設計に残すという判断が重要です⁸。制度によって変わる項目も同様に、そのまま残す設計が実態に合っています⁹。仕分ける視点を持てるかどうかが、標準化案件で信頼を得られるかの分かれ目です。まず登録して、自分の経験が生きる案件を探してみるのも一つの選択です。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊2 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊3 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊4 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊5 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊6 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊7 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊8 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊9 観光庁「データセット仕様に関する提言書」観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査業務（2026年3月）
＊10 Remoguサイト公開情報（フルリモート可能案件の割合）