「PMS連携」という説明だけでは、現場で何が変わるかは判断できません。予約を読めるのか、顧客メモを書けるのか、手配を登録できるのか、更新は即時か定期かによって、必要な運用は大きく変わります。
連携方式にはAPI、CSVなどのファイル、手入力があります。自動化の度合いだけで優劣を決めず、対象データ、更新方向、失敗時の確認方法を含めて選びます。
最初に「何を、なぜ連携するか」を一文で決める
目的が「二重入力をなくす」だけでは範囲が広すぎます。「確定予約をPMSで参照する」「送信した回答の要約を予約履歴へ残す」「未完了の手配を当日一覧へ渡す」など、業務結果で表します。
目的ごとに、読み取りだけでよいのか、書き込みが必要か、誰の承認を経るかが変わります。PMS側の仕様、契約、権限、提供されている接続方法を必ず確認します。
CSV・API・手入力にはそれぞれ注意点がある
CSVはまとまったデータを扱いやすい一方、出力時点と取込時点の差、文字コード、項目順、重複取込などの確認が必要です。APIは処理をつなぎやすい反面、利用できる項目、回数制限、認証、エラー応答、保守範囲を確認します。
手入力は少量の例外や、人の判断後だけ記録したい内容に向きます。ただし入力漏れや表記揺れを防ぐため、担当、期限、必須項目、確認手順を決めます。自動であることより、結果を検証できることが重要です。
項目名ではなく意味と共通の管理番号を合わせる
両方に「備考」「顧客ID」「状態」という項目があっても、意味が同じとは限りません。予約単位か顧客単位か、上書きか追記か、空欄が削除を意味するかなどを項目ごとに確認します。
予約を結び付けるときは、氏名だけに頼らず、PMS予約ID、外部予約番号、宿泊日など、利用可能で確かな見分けるための情報を使います。IDが変わる処理や、分割・統合された予約も試験対象にします。
失敗を前提に検知・停止・復旧を設計する
通信エラー、権限変更、項目追加、予約更新の競合など、連携は止まる可能性があります。失敗した件数だけでなく、どの予約の、どの項目が、どの理由で失敗したかを確認できる状態にします。
再実行で二重登録されないか、途中まで書き込まれた場合に戻せるか、緊急時はどの手順で手入力へ切り替えるかも必要です。導入前の業務整理はPMS導入前の洗い出しをご覧ください。
正常に見える処理も定期的にサンプル確認します。送った件数と受け取った件数、更新時刻、代表項目を照らし合わせます。静かに欠落している状態を早めに発見します。
現場で確認してみましょう
- 連携目的を具体的な業務結果で説明できるか
- 読み取り・書き込み・更新方向と頻度を確認したか
- 項目の意味、上書き・追記、空欄の扱いを決めたか
- 予約を結ぶ共通の管理番号と例外パターンを試したか
- エラー通知、再実行、手入力への切替手順があるか
「連携できます」を、項目と失敗時の動きまで分解する
PMS連携は、APIという言葉だけで良し悪しを判断できません。どの項目を、どちら向きに、どの頻度で、誰の権限で更新し、失敗時にどう検知・再送するかが重要です。CSVでも目的に合えば十分な場合があり、APIでも必要項目がなければ手入力は残ります。
予約情報をAPI取得できても、手配品を書き戻すAPIがなければ、メール側で登録したケーキはPMSへ自動反映されません。画面に「連携済み」と表示する前に、読み取りと書き込み、対象項目、成功応答、PMS実画面の反映を別々に検証します。
迷わないための考え方
連携目的を一文で決める
「予約変更の二重入力をなくす」「顧客検索の候補を表示する」など、目的と利用者をはっきりさせます。目的が曖昧な連携はデータを増やすだけになります。
読み取りと書き込みを分ける
予約を参照できることと、PMSを更新できることは別です。項目ごとに取得、作成、更新、キャンセルのできるかどうかと権限を確認します。
一意キーと照らし合わせルールを決める
予約番号がシステム間で異なる場合、対応表や外部IDを残します。氏名と日付だけの曖昧照らし合わせで自動更新しません。
失敗を利用者へ正直に見せる
通信の時間切れや項目エラー時に成功表示をせず、未同期、再試行中、要確認をはっきり書きます。手動対応した場合も後から二重反映しないよう記録します。
CSV・API・手入力を選ぶ確認手順
- 対象項目と件数を決める予約、顧客、料金、手配など、必要項目、更新頻度、日次件数、許容遅延を整理します。
- 公式仕様と契約を確認するAPI・CSVの提供範囲、追加費用、利用申請、レート制限、保守窓口、仕様変更通知をベンダーの現行情報で確認します。
- データ対応表を作る項目名、型、必須、文字数、コード、税区分、時刻、文字コードを対応付けます。変換できない値の扱いも決めます。
- 正常・異常・キャンセルをテストする新規だけでなく変更、重複、欠損、キャンセル、通信断、再送を検証し、両システムの実画面とログを照らし合わせます。
- 監視と手動手順を用意するエラー件数、最終成功時刻、未同期一覧を確認できるようにし、復旧までの手入力と復旧後の突合手順を決めます。
連携を確認する三者
業務責任者
何の二重入力・見落としを減らすか、必要項目、許容遅延、完了条件を決めます。APIありという説明ではなく、現場で何が変わるかを受入条件にします。
技術・ベンダー担当
認証、項目、方向、頻度、制限、エラー、再送、監視、仕様変更を確認し、データ対応表を作ります。送信要求と相手側反映を分けて記録します。
現場テスト担当
検証予約で新規、変更、キャンセル、重複、通信断を操作し、両システムの実画面を照らし合わせます。失敗表示から手動対応へ迷わず移れるかを確認します。
連携仕様書に必要な具体項目
連携できるかどうかを一つの丸印で表さず、データ項目と操作ごとに取得、作成、更新、キャンセル、成功確認を記録します。未対応と未検証も分けます。
- 予約取得：PMS予約番号、外部番号、宿泊日、人数を五分間隔で取得。最終成功時刻を表示する。
- 手配書込：対象APIなし。メーラー内記録はOS未同期として表示し、標準転記を行う。
- 成功条件：HTTP成功だけでなく、相手側予約IDと項目結果を記録し、可能なら再取得で照らし合わせる。
- 再試行：外部IDで同一処理を見分け、通信が時間切れになった後の再送で重複明細を作らない。
- 障害時：未同期一覧を担当へ通知し、手動更新した項目を復旧後の自動再送から除外する。
30日で一つの連携を検証する
- 1週目目的、対象項目、件数、許容遅延、最新情報の置き場所、契約と公式仕様を確認します。
- 2週目項目型、コード、必須、方向、一意キー、権限、エラー対応の対応表を作ります。
- 3週目正常、欠損、重複、変更、キャンセル、通信断、再送を検証環境で試します。
- 4週目実際の画面での確認、監視、手動手順、切戻しを受入試験し、未検証範囲を公開説明から除外します。
責任者が見ておきたいこと
責任者は、APIかCSVかではなく、目的に必要な正確性、頻度、監視、復旧を見ます。未同期を成功のように隠さず、利用者が次の行動を選べる表示を求めます。連携後に手動補正が増えた場合は、効率化ではなく品質問題として見直します。
よくある失敗と防ぎ方
- APIがあるだけで双方向・全項目対応と思う。操作と項目単位で確認します。
- 成功応答だけ見てPMS実画面を確認しない。代表予約を両側で照らし合わせます。
- CSV取込を本番データで初めて試す。検証環境とバックアップ、少量テストを使います。
- 未同期を利用者へ隠す。状態と次の行動をはっきり書き、誤った完了判断を防ぎます。
改善できたかを数字で確かめる
システムを入れただけで終わらせず、現場の仕事がどう変わったかを定期的に確認します。
- 同期成功率と最終成功時刻
- 件数だけでなく、いつまでのデータが反映済みかを確認し、静かな停止を早く見つけます。
- 手動補正件数
- 連携後にスタッフが直した項目と理由を記録し、変換・最新情報の置き場所・仕様不足を改善します。
- 重複・欠損・遅延件数
- 正常成功率に隠れる品質問題を別々に追い、業務影響の大きいものを優先します。
よくある質問
API連携とCSV連携はどちらが優れていますか？
目的次第です。頻繁な双方向更新にはAPIが向きますが、定期集計や初期移行はCSVが簡単な場合があります。必要項目、頻度、監視、費用、失敗時運用で選びます。
手入力はすべてなくすべきですか？
頻度が低い例外や人の確認が必要な判断は、手入力が適切な場合があります。重要なのは最新情報の置き場所、入力者、確認、二重反映防止を決め、無自覚な転記を減らすことです。
連携後に「OS同期済み」と表示する条件は何ですか？
送信要求を出しただけでなく、対象PMSが成功を返し、予約IDと反映項目を記録できた状態を基本にします。可能ならPMS側の再取得で照らし合わせます。失敗・保留は未同期としてはっきり書きます。
まとめ
PMS連携では、APIかCSVかという方式より先に、何をどちらへ渡し、どの結果を正しいとするかを決めます。項目の意味、共通の管理番号、更新競合、失敗時の復旧まで確認して初めて、現場が頼れる連携になります。未確認の書き込みをいきなり自動化せず、読み取り、下書き、人の承認、限定運用の順に確かめる方法も有効です。関連する記事はPMSを入れ替えない改善、一覧はこちらです。
