ホテル管理システム移行チェックリスト：データを失わない10ステップ

2026年8月17日

長年オンプレミス型システムを運用してきた4〜5つ星ホテル、リゾート、チェーンにとって、システム入れ替えを検討するときの最も難しい問いは「新しいシステムのほうが優れているか」ではありません。難しいのはその中に蓄積された20年分のデータはどうなるのかという問いです。顧客プロファイル、滞在履歴、旅行会社の売掛金、翌年の繁忙期にすでに予約が入っている団体の預り金。この不安はまったく正当なものであり、本来もっと早く下すべきだった判断を多くの経営陣が先送りしてきた理由でもあります。

本稿は機能の話ではありません。責任を負う立場の方 — 総支配人、経理部長、フロント責任者、情報システム部門 — のための運用チェックリストです。このシリーズの前の記事ではベンダー評価の基準と国際基準でのP&Lの読み方を扱いました。本稿が扱うのは一つだけ — データを失わず、営業を止めずに移行する方法です。

第1部：ホテル管理システムを入れ替えるとデータは失われるのか

結論から述べます。統制されたプロセスに沿って移行するなら、失われません。データが失われるのは次の三つの場合だけで、いずれも防げます。

• 移行前に範囲を確定していない。「データ移行」に何が含まれるかについて双方の理解が食い違っている。go-live当日に前年度の滞在履歴が対象外だったと判明したのでは手遅れです。
• 数値で突合していない。移行が終わり、画面にデータが出ていれば完了とみなしてしまう。差異は期間別の売上合計、売掛残高、レコード件数に潜んでおり、二つの表を並べて一行ずつ比べて初めて表に出ます。
• 退路を確保していない。移行当夜に旧システムを停止し、完全バックアップも取らず、ロールバック計画もない。この状態では小さな障害が大きな障害に変わります。戻る場所がないからです。

適切に準備されたある移行案件で、当社チームは6万件を超える顧客プロファイルと5,000件を超える予約の移行を実施しました。処理は15分未満、突合は100%一致、そして全工程にロールバックを用意していました。突合結果が基準を満たさなければ、システムは移行前の状態に戻る設計です。この数字は特定の案件のものであり、すべてのホテルへの約束ではありません。要点は所要時間ではなく、移行が測定でき、かつ元に戻せる作業であるという点です。

第2部：いま使っているシステムが進化を止めた兆候

古いシステムがすべて入れ替えを要するわけではありません。10年以上安定して稼働し、いまも十分に役立っているオンプレミス製品もあります。問題が生じるのは、ソフトウェアが開発を止めたときだけです。そのとき製品自体が悪くなるわけではありませんが、周囲の世界は変わっていきます。以下は自社システムを点検するための客観的な基準であり、特定のベンダーを評価するためのものではありません。

検証できる四つの基準

• 長期間、新しい更新がない。システムのバージョン履歴を開いて確認します。直近の更新はいつ、何を含んで公開されたか。生きている製品は規則的な痕跡を残します。稼働中のバージョンが数年止まっているなら、それは感覚ではなく事実です。
• 新しい法令に追随していない。法令には明確な期日があるため、これが最も検証しやすい基準です。通達99/2025/TT-BTCに基づく企業会計制度、税務当局と接続する電子インボイス、国内客・外国客の宿泊者情報の自動申告。このうちいくつをシステムが支えており、残りを部門は毎月何時間の手作業で処理しているでしょうか。
• サポートが遅い、あるいは応答がない。運用チームから実際の数字を取ります。直近3件の問い合わせは、返答までに何日、解決までに何日かかったか。稼働している連絡窓口はどれか。「何度電話しても誰も出ない」という感覚は、会議に持ち込む前に日数に換算すべきです。
• 製品ロードマップが公表されていない。ベンダーに率直に尋ねます。今後12か月で製品に何が加わるのか、施行が迫る規定にいつ対応するのか、誰が責任者か。投資が続いている製品なら、必ず書面で答えられます。答えがないこと自体も一つの答えです。

なぜこれが4〜5つ星ホテルとチェーンにとって重要なのか

• コンプライアンス上のリスクはホテル側に集まり、ソフトウェア側には行かない。法令が変わったのにシステムが対応していないとき、監督官庁と監査法人に説明するのはホテルの経営陣です。
• 手作業のコストは実在するコストである。毎月数十時間の手入力、手作業の突合、手作業のレポート出力は、年間で合計すると二つの選択肢のライセンス費の差をはるかに超えるのが通常です。
• 先送りするほど移行は難しくなる。データは日々積み上がり、旧システムに詳しい人は一人ずつ退職し、技術資料は失われていきます。移行が最も容易な時期は、来年と比べれば常に今日です。

二つ以上の基準に該当するなら、継続的に開発されているプラットフォームへ移ることが妥当な方向です。背後にエンジニアチームがあり、リリース計画があり、法令対応を書面で約束しているものを選びます。それはAIホテル管理システムDiHotelが、ベトナムと日本の300を超える宿泊施設とともに20年以上維持してきたことです。

第3部：安全に移行するための10ステップ・チェックリスト

ここが本稿の中核です。以下の10ステップは、4〜5つ星およびチェーン領域の移行案件に当社が適用している手順です。どのベンダーとの検収項目としても、そのままお使いいただけます。

第4部：売掛金、期首残高、滞在中ゲストのデータをどう移すか

多くの移行案件がつまずくのがここです。二種類のデータは似て見えるのに、扱い方は正反対でなければなりません。当社が用いる原則は「旧台帳を締め、新台帳を開く」です。

取引先の過去売掛金：明細は移行しない

• 新システムへ移すのは期首残高のみ。取引先ごとに1行だけとし、過去数年分の請求や入金の明細は持ち込みません。
• 各残高行には明細一覧を添付します。必要なときは完全に参照できますが、新システム内の数千件の取引レコードではなく、文書として保持します。
• ホテルと各旅行会社・販売チャネルとの間で双方署名の債権確認書が必要です。これが期首計上額の法的な根拠になります。これを欠くと、後の議論に拠り所がなくなります。
• 旧システムは3〜6か月間、参照専用で維持し、異議申し立てや照合の際に取引履歴を追えるようにします。
• 明細を移さない理由：数年分の売掛データには、ほぼ必ず累積した差異が含まれます。そのまま移すことは、過去の差異をすべて新システムへ持ち込み、新しいデータと混ぜることを意味し、後になって誤りの出どころが誰にも判別できなくなります。

滞在中ゲストのフォリオ：予約単位で必ず移行する

• 切替時点でホテルに滞在中のゲストは、予約単位でそのまま新システムへ移す必要があります。正しい部屋、正しい料金、正しい到着日と出発予定日、正しい人数で。
• フォリオに計上済みの項目 — 宿泊済みの夜の室料、レストラン、スパ、ランドリー、部屋付けの計上 — はすべて明細行単位で移し、合計1行にまとめてはいけません。
• 理由はきわめて実務的です。ゲストは新システムでチェックアウトし、明細付きの請求書を求めます。合計1行ではゲストに説明できず、売上を正しい部門に分けられず、両期間のレポートを誤らせます。
• Xアワーの前に、旧システムから滞在中ゲスト全員のフォリオ一覧を印刷します。移行後に部屋ごと、金額ごとに照合します。在室数はそれほど多くないのが通常なので、手作業での確認は十分に可能であり、行う価値が高い作業です。

この切り分けにより、新しいホテル管理システムは初日から清潔に保たれます。新台帳に載るのは生きているものだけ — 滞在中のゲスト、将来予約、確定した残高 — で、過去は保管場所に収まり、参照はできても運用数値を濁らせません。

第5部：システム入れ替え時の将来予約の預り金の扱い

預り金は移行で最も失われやすい項目です。受領済みだがサービスは未提供の資金であり、資金繰りと売上の境界に位置するためです。1年先まで予約を受けるリゾートや宴会型ホテルでは、その規模は決して小さくありません。

扱いの原則

• 主原則 — 予約が特定できる預り金は、その予約に直接紐づける。各預り金に予約番号、ゲスト名または団体名、到着予定日、金額、受領日、支払方法を添えます。「預り金合計」という一つの数字にまとめることは、ゲストが到着した日に誰もその入金を見つけられなくする最も確実な方法です。
• 団体契約と宴会契約の預り金にはもう一段の情報が要る。多くの契約は進捗に応じた複数回の入金、日程変更条項、キャンセル料の定めを持ちます。新システムへは、受領額だけでなく入金スケジュールも保持して移す必要があります。
• Xアワー前に三方向で突合する。旧システムの預り金一覧 — 銀行明細と現金出納帳 — 将来予約の一覧。この三つが一致しなければなりません。ずれがあればその場で解明し、新システムへ持ち込んで後で処理しようとしないことです。
• オンライン販売チャネル経由で受領した預り金は、チャネル名と照合状態を明記します。計上時点と実際の入金時点がずれることが多いためです。
• 営業部門と予約部門への周知。移行週に新たに受領する預り金は、合意したXアワーを基準に一つのシステムにのみ記録します。これはソフトウェアではなく人の取り決めであり、最も混乱が生じやすい箇所でもあります。

例外：どの予約に属するか特定できない預り金

長年稼働したシステムには、必ず宙に浮いた項目群が残ります。日程が未確定のまま先に預かった保証金、一つの窓口でまとめて受領しゲスト別に分けていない預り金、集約用の口座や資金保持用の「仮想部屋」に置かれた金額など。これらは特定の予約に紐づけられません。扱いの原則は次のとおりです。

• 置き場所を作るためだけに、任意の予約へ押し込んではならない。無関係な予約に架空の預り金が生まれ、チェックアウト時に金額が合わず、出どころも遡れなくなります。
• これらは会計モジュール側の期首残高として、貸方残で計上します。本質はホテルが預かっているゲストの資金、すなわち売上ではなく負債だからです。
• 1件につき1行とし、合計にまとめず、明細一覧を添付します。受領日、金額、入金者または窓口、状況のメモ。この一覧があれば、後日ゲストが日程を確定したり取引先が照合に来たりした際、経理はすぐに遡れます。
• 宙に浮いた項目の帰属が判明したら、新システムで通常どおり処理します。該当予約に充当するか返金し、計上した期首残高を減額します。最初の四半期末には残額がほぼゼロに近づくはずです。それでも大きいなら、それは移行の失敗ではなく、預り金受領の手順を締め直すべき兆候です。

多施設チェーンではこの作業が施設数に比例して増え、進捗を追う単一の窓口が必要になります。ホテルチェーン管理システムDiHotelは、ポートフォリオ全体の預り金と将来予約の一覧を一か所に集約し、施設別に分けながら全体も見られる形にすることでこれを解決します。

第6部：決める前に、オンプレミス型とクラウド型を比較する

移行は、単にソフトウェアの名前を変えるだけでなく、アーキテクチャを見直す数少ない機会です。以下の表は、4〜5つ星ホテル、リゾート、チェーンの運用に実際に影響する観点で二つのモデルを比較したものです。

すべての場合に正しいモデルというものはありません。回線がまだ安定しない地域のリゾートや、データを現地に保持する固有の要件があるホテルには、オンプレミス型を維持する正当な理由があります。ただし、その上で動くソフトウェアがいまも開発され続けていることが条件です。同じポートフォリオ内の小規模施設には、費用面でクラウドAIホテル管理システムDiCloudが妥当な選択となることが多く、大規模施設、リゾート、宴会型ホテルは複雑な業務のためにリゾート管理システムDiHotelを使います。二つは同じエコシステムにあるため、手作業で結合せずに報告を連結できます。

第7部：並行稼働、突合、そしてロールバック計画

この三つはプロジェクト全体の緩衝装置です。どれを省いても、節約できる時間以上にリスクが増えます。

並行稼働の正しいやり方

• 二か所への二重入力はしない。職員が二度入力すれば疲れ、誤りが生じ、最後には両システムの数字が合わなくなります。避けたいのはまさにそれです。並行稼働とは、旧システムを参照用に開き、新しい取引は新システムにのみ記録することを指します。
• 妥当な期間：最初の数週間は厳密な監視期間とし、その後は照会需要のために3〜6か月間、旧システムを参照専用で維持します。
• 判断の窓口は一つに。この時期には必ず前例のない状況が生じます。シフトごとに扱いが変わるのを防ぐため、その場で決められる権限者が一人必要です。

どの数字を突合するか

• 日別・部門別の売上 — 客室、料飲、その他サービス — を最初の数日間、両システムで比較します。
• 各夜の在室数、宿泊人数、稼働率。
• 切替時点の取引先別売掛残高と預り金合計。
• 顧客プロファイルと将来予約のレコード件数。

ロールバック計画は事前に書く。障害発生時に考えるものではない

• 発動条件を明記します。どの差異の閾値を超えたら、どの種類の障害が起きたら、中止して戻すのか。
• 誰に決定権があるか、そして何分・何時間以内に判断するかを明記します。
• 戻す手順を明記します。旧システムの書き込み権限の再開、その短い間に新システムへ記録された取引の処理、どの部門へ通知するか。
• 冒頭で触れた移行案件でも、結局は使わずに済みましたがロールバック計画は完全に準備されていました。それがあったからこそ、チームは切替ボタンを押せたのです。

第8部：go-live後 — 何を、どれだけの期間突合するか

go-live当日はゴールではありません。本当の差異の大半は最初の締めで初めて表に出ます。したがってgo-live後の監視スケジュールは、契約締結の時点で決めておく必要があります。

初日

• ベンダー担当者の立ち会いのもとでナイトオーディットを実行し、その夜のうちに当日の売上を旧システムと照合します。
• 在室中の全室を確認します。部屋、料金、フォリオの明細行がすべて正しいか。

最初の一週間

• 売上を日ごとに照合します。初めて発生する頻度の低い業務を点検します。滞在中の部屋移動、フォリオの分割と統合、団体の一部精算、返金、ノーショー。
• 連携先へ送られるデータを確認します。オンライン販売チャネル、電子インボイス、宿泊者情報の申告。
• 部門別に課題ログを取ります。これが週末の補習研修の材料になります。

最初の1か月と最初の締め

• 月次締めが最も重要な試験です。部門別売上、売上に係る付加価値税、売掛金、預り金残高 — そのすべてが会計帳簿と一致しなければなりません。
• 計上した期首残高を、署名済みの債権確認書と照合し、差異が生じていないことを確認します。
• 検収書の残課題一覧を見直し、各課題を具体的な期日とともに完了させます。

最初の四半期

• 運営指標 — 稼働率、平均客室単価、販売可能客室1室あたり売上 — を前年同期と比較し、日次突合では見えない体系的なずれを見つけます。
• 旧システムの参照専用を終了して保管へ移す時期を決めます。日常的な照会がもう不要だと確信できてからにします。
• 権限設定を見直します。誰が実際にどの権限を必要とするかは、数か月の実運用を経て初めて分かります。

最初の四半期の終わりまでに、オーナーはポートフォリオ全体を同一の指標定義で見られる状態になっているべきです。それはホテル管理の統合ソリューションDiHotelとオンラインAIホテル管理システムDiCloudが、同じエコシステム内の施設に標準で提供しているものです。より小規模な施設の視点、すなわち多くの場合Excelから専用システムへのデータ移行という課題については、DiCloud Blogの同時期記事で扱っています。

まとめ

システム入れ替えでデータを失うのは宿命ではありません。紙に書き出せる程度の数工程を飛ばした結果です。本稿の10ステップは三つの原則に集約されます。何かに手を触れる前に範囲を確定しバックアップを取ること。ホテル側の人間が署名する形で数値により突合すること。そして旧システムの参照専用維持とロールバック計画によって常に退路を残すこと。業務面では、正反対の二つの扱いを覚えておいてください。過去の売掛金は期首残高としてのみ移し、滞在中ゲストのフォリオと将来予約の預り金は予約単位で必ず紐づけて移します。

いま使っているシステムが長く更新されておらず、通達99/2025/TT-BTC、電子インボイス、宿泊者情報の自動申告に追随せず、サポートが遅く、製品ロードマップも公表されていないのであれば、継続的に開発されるプラットフォームへ移ることは技術的な好みの問題ではなく、リスク管理の判断です。4〜5つ星、リゾート、チェーンの領域では、ハイエンド向けホテル管理システムDiHotelが20年以上の継続的な開発とともにベトナムと日本の300を超える宿泊施設を支えています。同じポートフォリオ内のより小規模な施設はホテル管理の総合ソリューションDiCloudを使い、それでも報告は一か所に連結できます。手順どおりに行えば移行は1日で済みます。誤れば、失うものははるかに大きくなります。