旅館の予約メールの転記をAIで減らす流れと比較

この記事が扱う業務と読む人

対象は、旅館・ホテルの予約担当が、自社サイトのフォームメール、電話、FAXで受けた予約をPMSへ登録し、確認の返信を出すまでの業務です。読む人は、総支配人、予約の責任者、フロント主任を想定します。OTA経由の予約は管理画面から取り込まれるため、この記事では自館が直接受ける予約の登録と、OTA分との突合までを扱います。

• 担当：予約担当。小規模な旅館では女将やフロント主任が兼務する
• トリガー：予約メールの受信、電話の着信、変更やキャンセルの連絡
• 入力：メール本文、通話の内容、空室状況、料金表、キャンセル規定
• 成果物：PMSの予約データ、予約確認の返信、到着予定表への反映、部門別の申し送り
• 関わるシステム：PMS、サイトコントローラー、メールと電話、予約控えのメモ、到着予定表
• 後工程：フロントのチェックイン準備、客室清掃の順序、料飲のアレルギー対応と食数

観光庁の「観光DX推進に向けたデジタルツールのデータ連携における標準化に関する調査結果について」は、宿泊事業者におけるPMSと各種システムのデータ連携の仕様が標準化されていないため連携が進んでおらず、観光産業の生産性低下の一因になっていると指摘しています。写し直しが残るのは担当者の段取りの問題ではなく、業界の構造として扱える論点です。

いまの流れ（現状）

メールと電話の予約をPMSへ手入力し、確認の返信を都度書いている旅館を前提に書きます。所要時間は1日あたりの予約件数とプランの複雑さで変わるため、ここでは数字を置かず、計測する箇所として示します。

1. 予約を受ける
   – 担当：予約担当。夕方以降はフロント
   – 入力：フォームメール、電話、FAX
   – 出力：受信箱のメール、予約控えのメモ
   – 判断：なし。ただし電話は聞き取りながら書き取る
   – 所要：受信自体は短い。着信が重なる時間帯に滞る
2. 空室と料金を確かめる
   – 担当：予約担当
   – 入力：PMSの空室状況、サイトコントローラーの在庫、料金表
   – 出力：受けられるかどうかの回答
   – 判断：部屋タイプの割り当て、料金の適用
   – 所要：プランと部屋タイプの組み合わせが多いほど伸びる
3. 内容を書き取る
   – 担当：予約担当
   – 入力：メール本文、通話の内容
   – 出力：氏名、日程、人数、部屋タイプ、プラン、食事、到着予定時刻、要望を書いたメモ
   – 判断：聞き漏らしがないか
   – 所要：電話は通話中に発生し、計測されにくい段階
4. PMSへ登録する
   – 担当：予約担当
   – 入力：段階3のメモ、メール本文
   – 出力：PMSの予約データ。備考欄に要望を記載
   – 判断：備考欄にどこまで書くか
   – 所要：登録作業の中心。ここを導入前に測る
5. 確認の返信を書く
   – 担当：予約担当
   – 入力：登録した予約、過去の類似メール、館内情報
   – 出力：予約確認の返信。到着時刻の確認、送迎の案内、食事の時間、キャンセル規定
   – 判断：どこまで書き添えるか。外国語の場合は表現
   – 所要：過去のメールを探して直す時間が積み上がる
6. OTA分とPMSを突き合わせる
   – 担当：予約担当
   – 入力：OTAの予約通知、PMSの予約データ、サイトコントローラーの在庫
   – 出力：重複や不一致の一覧
   – 判断：重複の扱い、宿泊客への確認の要否
   – 所要：日次。件数に比例し、連携できないOTAの分だけ手作業が残る
7. 要望を部門へ伝える
   – 担当：予約担当
   – 入力：備考欄の要望、アレルギーや記念日の情報
   – 出力：到着予定表への反映、料飲・客室・フロントへの申し送り
   – 判断：対応の可否、特別対応の内容
   – 所要：口頭と紙に分かれると、伝えたかどうかの確認にも時間がかかる

時間が消えるのは段階3から段階4です。メールには必要な情報がすでに文字で書かれているのに、担当者がそれを読んで理解し、PMSの入力欄に打ち直します。同じ情報を二度扱う構造で、観光庁が指摘する連携の未標準化がこの形で現れます。

二つめは段階5です。返信の型は決まっているのに、毎回過去のメールを探して日程と人数を書き換えます。担当者ごとに文面が違うため、同じ質問に対する答えが人によって少し変わります。

三つめは段階7です。要望が備考欄と口頭と紙に分かれると、料飲や客室に届かないまま当日を迎え、宿泊客の前で食い違いが出ます。

失敗が起きやすいのは段階3と段階7です。段階3では日程と人数と食事の有無の取り違えが起き、当日のトラブルになります。段階7ではアレルギーの情報が調理へ届かないことが最も重い失敗で、健康被害に直結します。観光庁の「宿泊旅行統計調査」2025年年間値（確定値）では、客室稼働率は全体61.6%、旅館38.2%、ビジネスホテル75.3%です。稼働率が低い業態ほど1件の予約の重みが大きく、取り違えや返信の遅れが売上に効きます。

AI活用後の同じ業務

文書生成AIによる項目抽出と、返信文・申し送りの下書き生成を組み合わせた形です。段階番号は現状と同じにし、置き換わる段階と増える段階を明示します。

1. 予約を受ける（人。変わらない段階）
   – AIが受け取るもの：受信したメール本文。電話は通話後に担当者が音声入力した内容
   – AIが返すもの：なし
   – 人が確認すること：着信の本数そのものはAIでは減らない
2. 空室と料金を確かめる（人＋PMS。変わらない段階）
   – AIが受け取るもの：なし
   – AIが返すもの：なし
   – 人が確認すること：空室と料金の確定は実データで人が行う
3. 項目に分解する（AI）
   – AIが受け取るもの：メール本文または通話の音声テキスト、自館の項目定義（氏名、日程、泊数、人数と内訳、部屋タイプ、プラン、食事、到着予定時刻、送迎、要望）
   – AIが返すもの：項目ごとに分解した一覧。書かれていない項目は空欄のまま残す。要望は文面のまま引用して残す
   – 人が確認すること：下書きの段階では確認しない。確認は段階4にまとめる
   – 推測で穴埋めさせない指示を固定で入れる。空欄が出ることが正しい動作
4. 確認して登録を確定する（人。新しく増える検証）
   – AIが受け取るもの：なし
   – AIが返すもの：なし
   – 人が確認すること：日程、泊数、人数の内訳、食事、部屋タイプの五点をメール原文と見比べる。この五点は誤りが当日まで残ると回復できない
   – PMSに外部から登録する方法があれば登録まで自動化できる。無い場合は確認済みの一覧を見ながら人が入力する
5. 確認の返信を下書きする（AI）
   – AIが受け取るもの：確定した予約データ、館内情報（送迎、食事の時間、チェックイン時刻、キャンセル規定）、宿泊客の使用言語
   – AIが返すもの：確認の返信の下書き。必要な言語での文面も同時に出す
   – 人が確認すること：料金と規定の記述、館内情報が最新か。送信は予約担当が押す
6. OTA分とPMSを突き合わせる（AI）
   – AIが受け取るもの：OTAの予約通知、PMSの予約データ
   – AIが返すもの：一致しない予約と、同一の宿泊客と見られる重複の候補だけを並べた一覧
   – 人が確認すること：重複の扱いと宿泊客への確認。連携できないOTAは対象外として明示しておく
7. 要望を分類して申し送りを作る（AI＋人）
   – AIが受け取るもの：備考欄の要望、過去の宿泊記録
   – AIが返すもの：部門別に振り分けた申し送りの下書きと、到着予定表への追記案
   – 人が確認すること：アレルギーに関する記述は、調理担当が原材料と突き合わせて可否を決める。AIの分類で完了と見なさない
8. 記録を残す（AI）
   – AIが受け取るもの：メール原文、抽出結果、確定版、確認者
   – AIが返すもの：一連の記録の保存
   – 人が確認すること：確定版だけを残さない。抽出の誤りを後から追えるようにする

例えば、「10月18日から2泊、大人2名と小学生1名、夕食は部屋出しで、子どもはえびが食べられません。到着は17時ごろ、駅からの送迎をお願いします」というメールが届いたとします。AIは日程、泊数、人数の内訳、食事の形式、要望、到着予定時刻、送迎の七項目に分解し、部屋タイプは書かれていないので空欄にします。えびの記述は要望としてそのまま引用し、料飲への申し送り候補として振り分けます。予約担当は五点を原文と見比べて登録を確定し、調理担当がえびの扱いを原材料で確認します。この例は仮想のもので、特定の施設の予約ではありません。

現状とAI活用後の比較

変わらないこと（人が決める範囲）

• 満室時の代替提案。別日、別の部屋タイプ、近隣の紹介のどれを出すかは、稼働の見込みと常連かどうかで変わります。AIは空室の事実を並べるところまでで、何を勧めるかは予約担当と支配人が決めます。
• キャンセル規定の例外の適用。規定どおりの計算はAIが下書きできますが、天候や交通の事情でどこまで認めるかは施設の判断です。適用した例外は理由とともに記録に残します。
• アレルギーと食事制限の可否。予約データからの集約をAIが行っても、原材料との突き合わせと提供の可否は調理担当が決めます。この工程を飛ばさないと手順に明記します。
• 宿泊者名簿への記載と宿泊の可否。旅館業法は宿泊者名簿の備付けと記載を求め、宿泊を拒むことができる事由を限定しています。記載と保管の責任は施設にあり、可否の判断はフロント責任者と総支配人が条文を確認して行います。
• 外部のAIサービスへ入れてよい情報の範囲。宿泊者名簿、本人確認書類の画像、宿泊履歴は個人情報の保護に関する法律の対象です。利用目的の特定と安全管理を前提に、入力してよい項目の一覧を施設として文書化し、本人確認書類の画像は外部へ送らない設計にします。

実装の型

1. トリガー：自社サイトのフォームメールの受信、または通話後に予約担当が音声入力を終えた時点。対象の経路を先に決め、FAXは当面は対象外にしてもかまいません。
2. 元データ：メール本文、音声テキスト、項目定義、館内情報、キャンセル規定、過去の宿泊記録。項目定義はPMSの入力欄の名称をそのまま使えば足ります。
3. AI処理：メール本文を項目に分解し、要望は文面のまま引用で残す。書かれていない項目は空欄にする指示を固定で入れる。返信と申し送りの下書きを同時に出す。
4. 検証：予約担当が日程・泊数・人数の内訳・食事・部屋タイプの五点を原文と見比べる。確認画面でこの五点を目立たせ、他の項目と同じ扱いにしない。
5. 例外の扱い：団体、宴会つき、長期滞在、複数室の予約は抽出の対象から外し、従来どおり人が登録します。連携できないOTAの予約も突合の対象外として明示します。
6. 人の承認：登録の確定と返信の送信は予約担当が行います。予約の責任者は週に一度、抽出結果と確定版の差を数件見ます。
7. 記録先：メール原文、抽出結果、確定版、確認者と確認日時を一か所に残します。PMSの備考欄だけに頼ると、誤りの原因を後から追えません。
8. 効果測定：導入前と導入後で「予約1件あたりの登録時間」「返信を出すまでの時間」「当日発覚した相違の件数」「要望の伝達漏れの件数」を記録します。予約の責任者が月次で見ます。

前提条件・費用の考え方・リスク

先にやることは、PMSのデータの取り出しと登録の方法をベンダーに確認することです。外部から予約を登録できるのか、データを取り出せるのか、費用はかかるのかを押さえないと、抽出はできても登録は手入力のまま残ります。見込みが立たない場合は、段階6の突合と段階7の申し送り生成から始めます。

費用は次の項目に分けて考えます。金額は施設の規模と既存の環境によるため、ここでは置きません。

• ライセンス：文書生成AIの利用料。予約に関わる人数分
• 設計：項目定義、確認画面の五点、返信の型、例外の線引き、館内情報の整理
• 連携：PMSやサイトコントローラーとの接続。手作業のコピーから始める選択もある
• 検証：導入前後の計測、抽出誤りの多い項目の見直し、館内情報の更新
• 運用：指示文の更新、担当者の交代時の引継ぎ、OTAや連携先の仕様変更への追随

リスクは三つです。誤出力は、書かれていない項目をAIが推測で埋め、整った形の誤りが記録に残ることです。対策は空欄を空欄のまま残す指示と、段階4の五点の確認です。情報漏えいは、宿泊者名簿や本人確認書類の画像が外部サービスに渡ることです。対策は入力してよい項目の一覧を先に文書化し、利用するサービスの保存と学習利用の扱いを規約と設定で確認することです。依存は、AIが止まった日に登録が止まることで、対策はPMSへの直接入力に戻す手順を1枚にしておくことです。

AIを入れない方がよい施設もあります。直接受ける予約の件数が少なく、予約のほとんどがOTA経由で管理画面から取り込まれている施設です。この場合、抽出の対象がほとんど無いのに確認の段階だけが増えます。先に経路ごとの件数を1か月数え、直接予約の比率を確かめます。本メディアでは、直接予約の比率を数えずに予約の自動化を始めることは勧めません。

最初の90日

• 30日：現状の計測と対象の切り分け。経路ごとの予約件数、段階4の登録時間、段階5の返信作成時間、当日発覚した相違をひと月分記録します。PMSの連携可否をベンダーに確認し、項目定義を作ります。成果物は計測表と項目定義と連携可否の回答。見る指標は直接予約の比率です。
• 60日：試行。自社サイトのフォームメールだけを対象に、抽出と確認、返信の下書きを回します。五点の確認画面、例外の線引き、記録先を運用に乗せます。成果物は抽出結果と確定版ひと月分。見る指標は項目別の修正件数と、例外として人が登録した件数です。
• 90日：比較と拡張の判断。導入前後の計測表を並べ、電話の音声入力に広げるか、段階6の突合に進むか、項目定義を直すかを総支配人が決めます。成果物は比較表と判断メモ。見る指標は登録時間の差、返信までの時間の差、当日発覚した相違の件数です。

本メディアでは、予約業務のAI化は、PMSへの自動登録より先に「抽出と確認画面」から入るべきだと判断します。理由は、PMSの外部連携の可否が施設ごとに異なるのに対し、読み取りと確認は受信箱と表計算だけで始められ、連携が実現したときにそのまま前工程として使えるからです。この判断が外れるのは、PMSに予約を登録する仕組みが既に用意されていて、費用も確認できている施設で、その場合は登録まで一気に通したほうが二度手間になりません。