1. 結論：ホテル・旅館なら、何から始めるか
宿泊施設でAIを使うなら、最初の一手は多言語のレビューと問い合わせをAIで処理することです。次が要望と滞在中の依頼を、予約IDの下でタスク化すること、その次が要求の経緯を記録できる形にしておくことです。
この順番になるのは、宿泊施設の仕事に「1件の要望が複数部門を同時に動かす」という構造があるからです。アレルギー対応、記念日、部屋の変更——ひとつの依頼が、フロント・客室・厨房・清掃を同時に動かします。他の業種では部門がイベントを順に処理しますが、宿泊施設は同時です。
そして、多言語のレビューは人手では読み切れません。読めていない部分に、改善の材料が眠っています。
一方で、AIに渡せない領域もあります。アレルギー対応の可否、客室の販売停止、緊急対応、宿泊の可否——いずれも安全と法定の要件に関わる判断です。
この記事が想定しているのは、宿泊料を受けて人を宿泊させる営業を行うホテル・旅館です。住宅宿泊事業（民泊）や、宿泊を伴わない飲食・宴会のみの施設は、適用される制度が変わるため範囲に入れていません。
2. 業務全体の流れ
- 需要と客室在庫を見て、料金と販売枠を決める
- 予約をチャネル横断で統合する
- 問い合わせに答える——多言語で来ます
- 事前の要望を部門タスクに分解する
- チェックインし、宿泊者名簿を作る
- 客室を割り当てる
- 清掃し、客室のステータスを管理する
- シフトと人員を配置する
- 館内サービスと食事を提供する
- 滞在中の依頼・不具合に対応する——部門をまたぎます
- クレームに対応する
- 宿泊拒否・特定要求行為に対応する——記録が必要になる場合があります
- 緊急・安全対応を行う
- チェックアウトし、会計する
- レビュー・アンケートを分析する
- 販促・CRMを行う
- チャネル別の実質収益を見る
- 施設・設備を保全する
この流れの特徴は、「予約時点では滞在中に何が起きるか確定しない」ことです。そして、起きたことが記録に残っているかどうかが、後の判断を左右します。
3. AI導入優先Top3
Top 1：多言語のレビューと問い合わせをAIで処理する
何をするか。口コミ・アンケートを言語横断でテーマ別に分類・要約し、改善課題に接続します。問い合わせには、FAQ・予約条件・施設情報から多言語の回答案を作ります。
なぜ最初か。この業種で最もAI適合が高く、効果が早く見えるからです。多言語の処理は人手では追いつかず、しかも判断を伴わない部分が大きい。インバウンドの比率が上がるほど価値が増します。
どう始めるか。直近3か月のレビューだけを分類・要約させ、担当者が読んだ内容と比較します。返信の自動生成は、分類の精度を確認してからで十分です。
何を測るか。
- レビューの確認率——「読んだ」ではなく、担当者がAIの分類結果を確認した割合として定義します（言語別）
- 問い合わせへの回答までの時間
- 改善課題として起票された件数
どこがAIの仕事か。 分類・要約・翻訳の下書きはAIが担えます。確約を含む回答は別です。
次の問い合わせに、AIの出力をそのまま返信しないでください。
| 内容 | なぜ |
|---|---|
| 料金・キャンセル規定・返金 | 金銭の合意になる。プラン・時期・チャネルで条件が変わる |
| アレルギー・食事制限への対応可否 | 厨房と設備の条件による。「対応できます」は安全に関わる確約 |
| バリアフリー・介助の可否 | 施設の構造と人員体制による |
| 本人確認・宿泊の可否に関わること | 現場で確認すべき事項が残る |
多言語では、この危うさが増します。 訳された文面は言い切りの形になりやすく、原文にあった条件や留保が落ちることがあるためです。確約に当たる部分は、人が確認してから返す運用にしてください。
注意。件数の多いテーマが、重要なテーマとは限りません。
Top 2：要望と滞在中の依頼を、予約IDの下でタスク化する
何をするか。予約の備考・問い合わせ・滞在中の依頼から要望を抽出し、担当部門のタスクに分解して確認状態（未確認・確認済・対応済）を追跡します。
なぜ2番目か。この業種で最もクレームに直結するからです。要望の伝達漏れと滞在中の積み残しは、レビューの評価を直接下げます。Top 1でレビューが読めるようになると、この2つが主要因だと分かることが多いはずです。
どう始めるか。1つの部門（たとえば厨房への食事要望）だけをタスク化し、確認状態を持たせます。全部門への展開はその後で十分です。
何を測るか。
- 要望の伝達漏れ件数
- 滞在中の未対応件数
- 要望に起因するクレーム件数
注意。アレルギー等の安全に関わる要望について、AIが「対応可能」と判断しないでください。AIが担うのは、抽出と部門への伝達までです。
そして、分類に載せてはいけない要望があります。
障害のある方からの申し出や、合理的な配慮を求める要望を、「その他の要望」や「特別対応」として一律に処理しないでください。 内容によっては、対応の可否ではなくどう対応するかを話し合うことが求められます。
エスカレーションの条件は、あらかじめ決めておきます。
- 障害・介助・補助犬・医療機器に関わる申し出——分類で止めず、責任者へ上げる
- アレルギー・食事制限——厨房の確認を経るまで、回答しない
- AIが分類に迷ったもの——「その他」に落とさず、未分類として人へ回す
「AIが分類できなかったもの」を『その他』に入れると、見えなくなります。 未分類は未分類として残してください。
Top 3：要求の経緯を記録できる形にしておく
何をするか。要求の内容・日時・対応・繰り返しの有無を、客観的な事実として記録し、過去の記録と照合できるようにします。
なぜ3番目か。発生頻度は低いのですが、発生したときに記録が無ければ判断できないからです。宿泊を拒める場合のひとつは「厚生労働省令で定める要求を繰り返したとき」であり、「繰り返した」ことを判断するには過去の記録が必要です（節9）。Top 1・Top 2が日常の改善であるのに対し、これは備えです。
どう始めるか。記録様式を1枚作ります（日時・要求の内容・対応・担当者・繰り返しの有無）。運用は「該当しそうな事案があったら書く」から始めれば十分です。
ただし、この記録は扱いを間違えると危険です。 要求の経緯には、健康状態、障害の有無、宗教上の事情、家族の事情といった、本人にとって重い情報が混ざります。次の4つを、記録を始める前に決めてください。
| 決めること | 中身 |
|---|---|
| 目的 | 何のために残すのか。目的の外へ使わないことを明文化する |
| 権限 | 誰が見られるか。全従業員が閲覧できる状態にしない |
| 保存 | いつまで残すか。期限を決めて消す |
| 訂正 | 事実と違う記載があったとき、誰がどう直すか |
そして、この記録を「要注意客リスト」に転用しないでください。 目的の定まらない名簿は、事実でない評価が一人歩きする元になります。残すのは客観的な事実——いつ、何があり、どう対応したか——であって、人物への評価ではありません。
なお、改正法の附則により、当分の間、第5条第1項第1号又は第3号を理由に宿泊を拒んだときは、厚生労働省令で定める方法により理由等を記録しておくものとされています（節9）。すべての拒否が対象ではありません。
何を測るか。
- 要求の記録が残っている割合
- 記録が無く判断できなかった件数
- 判断に要した時間
注意。AIが該当性を判断しません。法律は「客観的な事実に基づいて判断し」と定めています（節9）。AIは材料の整理までです。
4. AIに任せやすい仕事
形を整える。予約条件（キャンセル規定・食事・送迎）を構造化する。要望を部門タスクに分解する。滞在中の依頼を受け付けてタスク化する。
照らし合わせる。OTA・自社・電話の予約をPMSに統合する。予約条件・要望・清掃状況から客室の割当候補を作る。
違いを見つける。消化・CPA相当の指標や稼働の異常を抽出する。前月・前年同月との差分を出す。
足りないものを探す。未対応・積み残しのタスクを検出する。検査項目に相当する記録の不足を出す。点検・修繕の期限を抽出する。
下書きを作る。多言語の回答案を作る。レビューの分類・要約・返信案を作る。利用明細を集計する。OTA手数料・原価・人件費を含む実質収益を集計する。
探し出す。過去の対応記録から、同種の要求・クレームの経緯を引く。
5. AI支援に向く仕事
- 例外・クレーム性のある問い合わせの見極め——エスカレーションの候補は出せます。判断は人です
- 例外的なアップグレード・変更——割当候補は作れます。承認は人です
- 滞在中の対応の優先度と引き継ぎ——未対応の検出はできます。優先度の判断は運営です
- 公開返信と重大な指摘への対応——返信案は作れます。承認は責任者です
- 修繕の優先度と客室販売への影響——点検予定と履歴は管理できます。判断は運営です
6. 人に残す仕事・判断
- 料金・販売制限・停止日の決定
- 重複・オーバーブックの対応
- アレルギー等、安全に関わる要望の提供可否
- 本人確認と例外対応——宿泊者名簿の正確性の確保に関わります
- 故障・衛生上の理由による客室販売停止
- 夜間・緊急時の体制の確定
- 補償・謝罪・対応方針の決定
- 宿泊を拒むかどうかの判断と、理由の丁寧な説明
- 緊急対応の決定と実施
- 障害のある方からの申し出への対応方針の決定——分類で止めず責任者へ上げます（節3 Top 2）
- 返金・値引の承認
- 許諾の範囲の確認と、配信・価格施策の決定
- チャネル構成・プラン構成の決定
「AIが90%正しくても、人が全部確認する仕事がある」——アレルギー情報の伝達がそれです。抽出の精度が高くても、「対応できるかどうか」は厨房と設備の条件によります。
7. Best Practice
ひとつ。要望とイベントを、予約IDの下で部門横断のタスクとして持つ。事前の要望も滞在中の依頼も、同じ予約IDでタスク化され、担当部門と確認状態を持ちます。未対応の積み残しが検出されます。
ふたつ。安全に関わる判断は、記録・照合と分けて人に置く。記録はAIが担い、判断は人が担う。この分離ができていれば、判断に必要な材料が揃った状態で人が決められます。
みっつ。宿泊拒否の判断材料を、平時から記録できる形にしておく。記録は事後に作れません。
よっつ。チャネル別の実質収益で判断する。客室単価ではなく、OTA手数料・食事原価・清掃/人件費を含めた実質収益でチャネルとプランを比較します。
8. Before / After
Before。予約の要望はフロントのメモに残り、朝礼で共有します。滞在中の依頼は無線と口頭で伝わり、対応したら終わりです。レビューは件数が多く、日本語のものだけ目を通します。クレームがあれば経緯を思い出して対応します。チャネル別の売上はPMSで見ますが、手数料は月末の請求書で確認します。
この流れには理由があります。滞在中の対応は即応が求められ、記録を待っていては間に合いません。もしそうなっているとすれば、それは現実的な運用です。
After。要望は予約IDの下で部門タスクになり、確認状態を持ちます。滞在中の依頼も同じ予約IDでタスク化され、未対応が検出されます。レビューは言語を問わず分類・要約され、テーマ別に改善課題へ接続します。要求の経緯は客観的な事実として記録され、判断が必要になったときに材料が揃っています。チャネル別の収益は手数料と原価を引いた実質で比較されます。
変わるのは対応の速さではありません。「何が起きて、どう対応したか」が後から出せることです。
9. 法令・規制・情報管理
宿泊を拒める場合は限定されている
営業者は、次のいずれかに該当する場合を除いては、宿泊を拒んではならないとされています（旅館業法第5条第1項）。
| 号 | 内容 |
|---|---|
| 第1号 | 宿泊しようとする者が特定感染症の患者等であるとき |
| 第2号 | 宿泊しようとする者が賭博その他の違法行為又は風紀を乱す行為をするおそれがあると認められるとき |
| 第3号 | 宿泊しようとする者が、営業者に対し、その実施に伴う負担が過重であって他の宿泊者に対する宿泊に関するサービスの提供を著しく阻害するおそれのある要求として厚生労働省令で定めるものを繰り返したとき |
| 第4号 | 宿泊施設に余裕がないときその他都道府県が条例で定める事由があるとき |
さらに同条第2項は、旅館業の公共性を踏まえ、宿泊しようとする者の状況等に配慮してみだりに宿泊を拒むことがないようにするとともに、宿泊を拒む場合には、前項各号のいずれかに該当するかどうかを客観的な事実に基づいて判断し、求めに応じてその理由を丁寧に説明することができるようにするものとすると定めています。
「客観的な事実に基づいて判断し」——この文言が、記録の必要性の根拠になります。
★ 拒否の記録は「当分の間」の措置であり、「第1号又は第3号を理由に拒んだとき」に限られる
2023年（令和5年）12月13日に施行された改正法の附則第3条第2項は、次のとおり定めています。
営業者は、当分の間、旅館業法第5条第1項第1号又は第3号のいずれかに該当することを理由に宿泊を拒んだときは、厚生労働省令で定める方法により、その理由等を記録しておくものとする。
そして、旅館業法施行規則の附則（令和5年）第2項が、その方法を定めています。
旅館業法第5条第1項第1号又は第3号に掲げる場合ごとに、宿泊を拒んだ理由等に関する記録を書面・ファイル・電磁的記録媒体をもって調製するファイルにより作成し、その作成の日から3年間保存するものとする。
一律化しないでください。
- 記録の対象は「第1号又は第3号を理由に拒んだとき」です。第2号（違法行為・風紀を乱す行為のおそれ）や第4号（満室等）を理由とする場合は、この記録義務の対象ではありません
- これは改正法附則による「当分の間」の措置です。本則の恒久的な義務ではありません
- 宿泊者名簿の3年保存とは別の記録です（後述）。保存期間が同じであることをもって同一視しないでください
感染症に関する協力の求め
営業者は、宿泊しようとする者に対し、旅館業の施設における特定感染症のまん延の防止に必要な限度において、特定感染症国内発生期間に限り、政令で定める者の区分に応じ、所定の協力を求めることができます（旅館業法第4条の2第1項）。
これは「協力を求めることができる」という規定であり、拒否の根拠ではありません。 「感染対策に応じない客は宿泊を拒否できる」と一般化しないでください。拒否の根拠は第5条第1項の各号に限られ、第1号は「特定感染症の患者等であるとき」です。
宿泊者名簿
宿泊者名簿は、正確な記載を確保するための措置を講じた上で作成し、その作成の日から3年間保存するものとされています（旅館業法施行規則第4条の2第1項。法第6条第1項に基づく）。
- 備える場所は旅館業の施設又は営業者の事務所（同条第2項）
- 記載事項は宿泊者の氏名、住所及び連絡先のほか、宿泊者が日本国内に住所を有しない外国人であるときはその国籍及び旅券番号、その他都道府県知事が必要と認める事項（同条第3項）
国籍及び旅券番号は、「日本国内に住所を有しない外国人であるとき」の記載事項です。すべての宿泊者について記載する事項ではありません。
チェックインをどこまで自動化するかは、名簿の正確性を確保できる範囲で決めることになります。
個人情報
宿泊者の氏名・住所・連絡先・旅券番号、食事のアレルギー情報、滞在中の記録を扱います。
- 利用目的の特定（個人情報保護法第17条第1項）、利用目的による制限（同法第18条第1項）
- 販促・CRMでの利用は、取得時の利用目的と許諾の範囲内かを確認します
- OTA・決済代行・清掃委託先への提供は、第三者提供または委託に当たり得ます（同法第27条第1項・第25条）
- アレルギーや健康上の事情が要配慮個人情報に当たる場合があります（同法第2条第3項）
AIへ投入してよい情報
宿泊者の氏名・連絡先・旅券番号、アレルギーや健康上の事情、滞在中の記録を扱います。次を確認したうえで使います。
- 必要最小限の情報だけを入れる（レビューの分類に、宿泊者が特定できる情報は要りません）
- AI事業者が入力データを学習に使わない設定・契約になっているか
- 保存期間と削除の方法
- 契約上の機密保持とデータの取扱条件（OTA・決済代行・清掃委託先との間）
- アクセス権限と操作ログが残るか
- 再委託・国外保管など、自社の規程上あらかじめ決めておくべき事項
旅券番号と、健康・障害に関わる情報は投入しないと決めておくほうが安全です。扱うのは会社が利用を承認したアカウント・サービスに限ります。
その他の規制
施設の構成によっては、食品衛生法（館内の飲食提供）、消防法、公衆浴場法（温浴施設を併設する場合）等が関わり得ます。適用は施設の構成によって異なるため、本記事では個別の内容に立ち入りません。
法令・制度の記述について
※法令・制度に関する記述は、内容確認日時点の一般的な整理です。実際の適用は、業務内容、契約関係、事業規模、地域、施行時点の法令・行政解釈等によって異なります。重要な判断は、最新の一次情報と自社の具体的な条件を確認してください。
10. 最初の30日プラン
1週目：測ることから始めます。
直近3か月のレビューと、進行中の事前要望を対象にします。測るのは、①レビューの件数と、実際に読んだ件数（言語別） ②要望の件数と、伝達漏れ・対応漏れの件数 ③滞在中の依頼のうち記録に残っている割合。この週はAIを使いません。
2週目：ルールを決めます。
要望の確認状態（未確認・確認済・対応済）を持つ様式を決めます。1部門（厨房への食事要望）をタスク化の対象に選びます。要求の経緯を記録する様式を1枚作ります（日時・内容・対応・担当者・繰り返しの有無）。AIへ投入してよい情報の線引きを決めます（宿泊者の旅券番号・健康上の事情を含めない）。
3週目：低リスクな範囲でAIを使います。
過去のデータで試します。進行中の予約でいきなり使わないでください。多言語レビューの分類・要約を、直近3か月分で試します。問い合わせへの回答案を、過去の問い合わせで試し、実際の回答と比較します。
4週目：同じ測り方で比べます。
判断するのは、①読めていなかった言語のレビューから改善課題が出たか ②要望の伝達漏れが減ったか ③回答案の修正率はどの程度か。
①で課題が出たなら、それは今まで見えていなかった顧客の声です。Top 2の優先度が上がります。
11. AI活用成熟度
レベル1：人に依存している。要望も対応も担当者の記憶と口頭伝達によります。レビューは目についたものだけ読みます。
レベル2：台帳やツールがある。PMSがあり、予約と会計は一元化されています。ただし要望と滞在中の対応は別の場所（メモ・無線）にあります。
レベル3：一元化されている。予約IDの下に、要望・滞在中のイベント・クレーム・レビューがつながっています。要求の経緯が記録されています。ここまで来て、はじめてAIに分類と追跡をさせる意味があります。
レベル4：AIが支援している。多言語の回答案・レビューの分類・要望のタスク化・未対応の検出・実質収益の集計をAIが担い、人は安全判断・宿泊の可否・補償・経営判断に時間を使っています。
レベル5：仕組みになっている。この業種のレベル5は「AIが接客する」ことではありません。スタッフが「人にしかできない接客」に時間を使えている状態がレベル5です。要望の転記、無線での確認、レビューの読み込み、手数料の計算に時間を使っていない。そして、判断が必要になったときには材料が揃っています。
12. よくある質問
宿泊を拒むことは、どこまで認められますか。
営業者は、旅館業法第5条第1項各号のいずれかに該当する場合を除いては、宿泊を拒んではならないとされています。加えて同条第2項は、公共性を踏まえてみだりに拒まないようにするとともに、客観的な事実に基づいて判断し、求めに応じて理由を丁寧に説明できるようにすることを求めています。「自由に拒める」わけではありません。
感染対策に応じないお客様は、宿泊を拒否できますか。
そう一般化することはできません。旅館業法第4条の2は、特定感染症のまん延の防止に必要な限度において、特定感染症国内発生期間に限り、協力を求めることができるという規定であり、拒否の根拠ではありません。拒否の根拠は第5条第1項の各号に限られ、第1号は「特定感染症の患者等であるとき」です。
宿泊を拒んだら、必ず記録が必要ですか。
すべての拒否について記録が求められているわけではありません。改正法の附則により、当分の間、第5条第1項第1号又は第3号を理由に拒んだときは、厚生労働省令で定める方法により理由等を記録しておくものとされています。第2号や第4号を理由とする場合は、この記録義務の対象ではありません。
その記録は何年保存しますか。宿泊者名簿と同じですか。
いずれも3年間ですが、別の記録です。拒否の理由等の記録は改正法附則と省令附則に基づくもの（作成の日から3年間）、宿泊者名簿は施行規則第4条の2に基づくもの（作成の日から3年間）です。保存期間が同じであることをもって同一視しないでください。
宿泊者名簿には、全員の旅券番号を書く必要がありますか。
いいえ。国籍及び旅券番号は、「宿泊者が日本国内に住所を有しない外国人であるとき」の記載事項です（旅館業法施行規則第4条の2第3項）。
AIに問い合わせの返信を任せてよいですか。
FAQ・予約条件・施設情報から回答案を作ることには使えます。ただし、料金・キャンセル規定・アレルギー対応について、AIに確約させないでください。例外性・クレーム性のある問い合わせは、人へエスカレーションする設計にしてください。
レビューの件数が多いテーマから改善すべきですか。
件数の多さが重要度とは限りません。件数が少なくても、安全や設備に関わる指摘は優先度が高いことがあります。分類はAIが担えますが、どれに手を付けるかは人が決めます。
13. 関連する業種の記事
- 訪問介護事業所のAI活用——AIが記録の草案を作り、人が確定させるという構造が共通します
- 食品卸のAI活用——安全に関わる判断と記録の関係が同型です
- 運送会社のAI活用——イベント駆動型として、例外の検出がAIの中心になる点が共通します
シリーズの一覧は業種別AI活用からご覧いただけます。
14. この記事を自社に当てはめたい方へ
同じ宿泊施設でも、インバウンドの比率と料飲部門の比重によって最初の一手は変わります。
インバウンドが多い施設は、多言語のレビューと問い合わせから始めるほうが効果が早く出ます。料飲の比重が大きい旅館では、アレルギー対応の伝達の仕組みが先になります。
この記事の内容を自社に当てはめるところから始めたい方は、次の診断をお使いください。
15. 無料AI戦略診断／AI顧問サービス
AI戦略診断は無料・登録不要です。回答すると、自社のAI活用がいまどの段階にあるかと、最初に取り組むべき領域が分かります。
より踏み込んだ伴走をご希望の方は、AI顧問サービスもご覧ください。個別のご相談はお問い合わせから承ります（30分の無料リモート面談）。
