旅館のOTA返信はAIで｜自社が月5時間損する境目3つと比較表

宿泊業の予約対応でよく聞くのが、こんな一言です。「17時を過ぎたあたりから、OTAの未読メッセージがまた増えていく」——この構造の悩みは、宿の規模を問わず定番になっています。サイトが2社、3社と増えるほど管理画面は分かれ、通知の鳴り方も違い、返信の言い回しは担当者の頭の中にしかありません。フロント対応と電話の合間に1件ずつ手で書いていくと、1件8分の作業が静かに1日を削っていきます。

結論から書きます。旅館のOTA返信は、AIに「下書きまで」なら任せられます。逆に送信の判断まで渡すと事故が起きます。この記事では、自社でChatGPTを使う運用・OTA標準の定型文・仕組みとして組む、という3つの境目がどこにあるのかと、月50件で約5時間ぶんの手間がどこで分かれるのかを、費用の目安と比較表で整理します。

OTA予約の返信が終わらない仕事になっている宿の構造

予約が入るのは嬉しい。けれど返信が終わらない。1件の予約に対して、予約確認・日程変更・食事の質問・到着時刻の連絡と、2〜4件のやり取りが積み上がります。OTAを3社ぶん使っていれば、管理画面は3つ、通知は3系統、テンプレートも3セット。さらに宿を探す導線自体が変わり始めていて、検索結果だけでなくAI検索で宿の情報が引用される流れも広がっています。露出を増やして取りこぼしを減らそうとするほど、返信の総量は静かに増えていく——これが今の宿泊業の構造です。

返信が集中するのは、フロントが一番動けない15時〜21時

チェックインが始まる15時から、夕食対応が落ち着く21時までの6時間は、館内が最も動く時間帯です。そしてこの6時間は、宿泊者が「明日の朝食は何時からか」「駐車場は空いているか」を確認したくなる時間帯とも重なります。結果として、返信は22時以降か翌朝の8時前に回されます。1日2回のまとめ返信になり、返信までの平均待ち時間は数時間単位に伸びます。

問題は、この2回のまとめ返信が「1日の終わりの作業」と「1日の始まりの作業」を両方潰すことです。22時から40分、翌朝7時半から30分。合わせて1日70分です。宿は週7日動きますから、70分×7日＝490分、つまり週8時間前後が返信だけに消えている計算になります。1件8分の返信が1日10件届く日なら80分を超え、週では9時間前後まで伸びます。しかもこの70分から80分という時間は、繁忙期ほど長くなります。人が足りない日ほど返信が溜まり、返信が溜まる日ほど電話での問い合わせが増える。この往復が、宿の予約対応を「終わらない仕事」に変えています。

観光白書が示す、宿泊施設72.2%という前提条件

この苦しさは、特定の宿の段取りの悪さではありません。産業全体の構造です。出典：観光庁「令和8年版観光白書」（令和8年7月公表）の概要版PDFによると、宿泊施設へのアンケート（n=522）で「人手不足の状況にある」と答えた施設は全体の72.2%。規模別に見ると、小規模施設（n=153）が66.0%、中規模施設（n=280）が77.1%、大規模施設（n=83）が69.9%で、最も高いのは中規模施設の77.1%でした。

さらに、人員が不足していると答えた施設（n=377・複数回答）が挙げた課題の内訳が重要です。1位は「特定の時期・時間帯に人員が不足し、既存従業員の負担が増加している」で79.3%。2位が「追加人員を採用するためにコストや時間がかかる」で50.4%、3位が「サービスを一部縮小せざるを得なくなっている」で40.6%、4位が「事業を拡大したいが人員不足により断念している」で21.5%です。つまり約8割の施設が、採用ではなく「今いる人の負担」の話をしています。

白書は同時に、一人当たり付加価値額で見た宿泊業の労働生産性がコロナ禍を除いて全産業の7割程度の水準にとどまること、有形・無形の設備投資が全産業に比べて低水準で推移していることにも触れています。そのうえで、生産性向上に向けた対応策の選択肢のひとつとして「稼働率の向上を目的としたDX、生成AI等の導入・活用」を挙げています（施設アンケート n=313）。返信の自動化は、宿の都合ではなく産業の課題として位置づけられている領域だと私は捉えています。

1件8分の積み上げが、月50件で約5時間になる

数字に落とすと、この負担は驚くほど地味です。返信文の作成は、1件あたり平均8分。AIに下書きを作らせて人が確認する形にすると、1件あたり1〜2分まで短縮できるというのが、BoostXが業務自動化ツール開発で用いている削減の目安です。差は1件あたり6〜7分。月50件の返信があるなら、6分×50件＝300分、7分×50件＝350分で、約5時間以上に相当します。

5時間と聞くと小さく感じるかもしれません。ただ、この5時間は「まとまった5時間」ではなく、1日10分・20分に分割されて1ヶ月に散らばっている5時間です。分割された時間は、他の仕事に転用できません。だからこそ体感の疲労は5時間より大きくなります。同じ構造は宿泊業以外でも起きていて、たとえば見積書作成が月20時間から15分になった自動化の事例も、元をたどれば「1件ずつ手で書き直していた」という同じ問題でした。

AIに肩代わりさせられる返信の範囲と、人が最後に持つ判断

「AIで返信を自動化」と聞くと、届いたメッセージにAIが勝手に答えて送信まで済ませる姿を想像する方が多いと思います。私は、宿泊業でその設計を選ぶべきではないと考えています。宿の返信には料金・キャンセル規定・食事内容という、間違えると金銭トラブルになる情報が必ず絡むからです。任せる範囲は「下書きの生成」と「必要な情報の引き当て」まで。ここを間違えなければ、AIは1件8分を1〜2分に変える戦力になります。

任せられるのは下書きまで。送信ボタンは人が押す

実務では、返信は3つの工程に分解できます。①予約内容と過去のやり取りを読む、②宿のルールに沿った文面を組み立てる、③内容を確認して送る。このうち①と②は型が決まっており、AIが得意な領域です。所要時間で言えば、8分のうち6〜7分がここに使われています。③の確認は1分もかかりません。つまり、送信の判断を人が持ったままでも、削れる時間の大半は削れます。

私は、自動化で最も重要なのは、AIに何をどう判定させるかのプロンプト設計だと考えています。「丁寧に返信して」では宿ごとの言い回しは再現できません。館内ルール・料金体系・キャンセル規定・繁忙期の対応方針を、判定できる形に翻訳する作業が本体です。この翻訳は1回30分で終わる仕事ではなく、宿の運用を棚卸しする作業になります。だからこそ、ツール選びより先にどこを自動化するかの設計から入る必要があります。

予約確認・変更・キャンセル規定の照会は、型が決まっている返信

宿に届くメッセージを1ヶ月ぶん並べると、種類はそれほど多くありません。予約内容の確認、到着時刻の連絡、日程変更の可否、キャンセル料の照会、駐車場と送迎、朝食と夕食の時間、館内設備の質問。この7種類が、繰り返し届くメッセージの中身です。そして、このうち予約データとルール表を突き合わせれば答えが一意に決まるものは、決して少なくありません。

一意に決まる返信こそ、AIの下書きが最も効く領域です。たとえばキャンセル料の照会なら、予約日・宿泊日・プラン区分の3つが分かれば、規定表から該当行を引いて文面にするだけです。人がやる場合は、規定表を開き、日数を数え、文面を書き、金額を再確認する、という手順を毎回踏むことになります。AIの下書きがあれば、人は金額の1点だけを確認して送れます。1件あたりの差は小さく見えても、毎日届く問い合わせに掛け算されると、週単位でまとまった差に育ちます。

食事・アレルギー・送迎は、AIの下書き＋人の確認で速くなる

一方で、アレルギー対応や送迎の可否は、その日の厨房とスタッフの状況で答えが変わります。ここを「AIが判断して送信」にしてしまうと、実現できない約束を宿が背負うことになります。1件のアレルギー事故は、5時間の削減では到底埋め合わせられません。

正しい設計は、AIに「確認が必要な項目を明示した下書き」を作らせることです。たとえば「そばアレルギーのご相談。厨房確認が必要。代替献立の可否を要確認」という注記付きの下書きが上がってくれば、担当者は厨房に1本電話を入れて、2分で返信できます。ゼロから状況を把握して文面を作るより、短い時間で返せます。判断は人、下書きと論点整理はAI。この線引きが、宿泊業でのAI返信の要点です。

インバウンドの多言語返信は、ゼロから書かない分だけ短くなる

海外からの予約が入ると、返信の所要時間は一気に伸びます。英語で1件書き、翻訳ツールと辞書を往復して表現を確認する、という状態は珍しくありません。どこまで伸びるかは宿によって差がありますが、日本語の1件より重い作業になる点は共通しています。しかも書き手が1人に固定されるため、その担当者が休みの日は返信が止まりかねません。

多言語の下書き生成は、AIが最も分かりやすく効く場面です。宿のルールと日本語の意図を渡せば、英語・中国語・韓国語の下書きが同時に出てきます。人がやるのは、金額・日付・館内ルールの3点が正しいかを確認する作業だけです。ゼロから文面を組み立てる作業が消えるだけで、1件あたりの負担は大きく下がります。海外からの予約が増えるほど、この差は月単位でまとまった時間になっていきます。同じ発想で工数を圧縮した例として、請求書まわりで月12時間を削った自動化があります。書式が決まっている文書ほど、AIとの相性は良くなります。

効果は速さではなく、返信の待ち行列が消えること

1件8分が1〜2分になる、という話は分かりやすいのですが、宿にとって本当の効果はそこではありません。「未読が溜まっている」という状態が視界から消えることです。未読が12件あると、人は12件ぶんの重さを1日中背負います。返信を4件済ませても、残り8件が気になり続けます。この心理的な負荷は、労働時間には計上されないのに、判断の質に影響します。

下書きが自動で用意されていれば、待ち行列は「確認待ち」に変わります。確認は1件1分なので、10件でも10分です。10分で終わると分かっている10件は、8分×10件＝80分かかる10件とは、まったく別の重さになります。工数の削減量よりも、この「終わりが見える」状態を作れることのほうが、現場では大きい変化だと私は考えています。

自前ChatGPT運用・OTA標準の定型文・仕組み化——3つの境目を比較

OTA返信を楽にする手段は、大きく3つに分かれます。①担当者が自分でChatGPTを開いて下書きを作る、②OTA管理画面の定型文機能を使う、③予約データと連動した仕組みとして組む。どれが正解というものではなく、宿の規模と返信件数で最適解は変わります。ここでは同じ軸で3つを並べ、どこに境目があるのかを整理します。

比較表：3つの選択肢を同じ軸で並べる

比較軸	自前でChatGPTを使う	OTA標準の定型文	仕組みとして組む
返信の型の置き場所	担当者の頭とチャット履歴	各OTAの管理画面の中（3社なら3セット）	宿のルールとして外部に一元化
1件あたりの所要時間の目安	8分より短くはなるが、貼り付けと修正の手作業が残る	定型に当てはまる1〜2件は即答、外れると8分に戻る	1件8分→1〜2分が目安
予約データとの突き合わせ	人が画面を見て手入力	予約者名など一部のみ差し込み	予約日・プラン・人数を自動で引き当て
例外（変更・アレルギー等）	担当者の判断に依存	定型文では対応不可	要確認フラグ付きの下書きで人に渡す
多言語対応	可能だが品質が担当者次第	用意した言語のみ	3言語同時生成＋人の3点確認
担当が1人替わったとき	ほぼ再現できない	定型文は残るが使い分けは残らない	ルールが外にあるため引き継げる
初期費用の目安	開発費0円（ツールのプラン料金は別途）	0円（OTA機能の範囲内）	33万〜110万円
月額の目安	ツール利用料のみ	0円	3.3万〜11万円（最低3ヶ月）
向いている宿（目安）	月10〜20件程度（目安）・担当が1人で固定	質問の型が2〜3種類に収まる小規模（目安）	月50件以上・OTA2社以上・担当が2人以上（いずれも目安）
限界	属人化が進み、休むと止まる	例外にまったく効かない	設計と運用ルールの整備に3ヶ月かかる

表を眺めると分かるとおり、3つの差は「性能」ではなく「型をどこに置くか」で決まっています。以下、境目を3つに絞って掘り下げます。

境目①：返信の型が人の頭の中にあるか、外に出ているか

自前でChatGPTを開いて返信を作る運用は、始めるのに0円で、その日から使えます。ここは大きな利点です。ただし、この運用では「どんな指示を出すと宿らしい文面になるか」が担当者の頭の中に蓄積されます。3ヶ月も続ければ、その担当者は自分なりの型を掴んで速く返せるようになるかもしれません。しかし2人目の担当者は、また1件8分からのスタートです。

仕組みとして組む、というのは高機能なツールを買うことではありません。頭の中にある型を、宿の資産として外に出す作業です。館内ルール、キャンセル規定のパターン、繁忙期の対応方針。これらを判定可能な形にまとめて初めて、誰が返しても同じ品質になります。整理そのものには相応の時間がかかりますが、一度外に出しておけば、担当者が入れ替わっても効き続ける資産になります。1件8分の作業を毎日繰り返すことと、型を1度外に出すこと。どちらに時間を使うかという選択です。

境目②：例外が起きたときに、止められる人がいるか

3つの選択肢の分かれ目として最も重い境目が、例外時の挙動です。OTA標準の定型文は、想定外の質問には1文字も答えられません。自前ChatGPTは、答えを作れてしまうぶん危険です。実在しないプランを提案する、規定にない返金条件を書く、といった出力が混ざったとき、確認する仕組みが無ければそのまま送信されます。

仕組みとして組む場合は、ここに設計を入れます。予約データと照合できない情報が出てきたら下書きを生成せず、担当者に確認を促す。金額に触れる文面には必ず確認フラグを立てる。この「止める設計」があるかどうかで、リスクの水準は大きく変わります。私は、最初の1〜2ヶ月ぶんくらいは出力を確かめてみて、人間のダブルチェックもしていくべきだと考えています。1〜2ヶ月で挙動が読めるようになってから、確認の頻度を落とせばよいのです。

境目③：担当が1人替わっても、同じ品質で返せるか

宿泊業は、人の入れ替わりが産業構造として大きい業界です。出典：厚生労働省「令和6年雇用動向調査結果の概況」の統計ページによると、一般労働者の入職率・離職率は、産業計が11.8%・11.5%であるのに対し、「宿泊業，飲食サービス業」は21.2%・18.1%。パートタイム労働者では、産業計が22.7%・21.4%であるのに対し、「宿泊業，飲食サービス業」は33.3%・29.9%です。就業形態を揃えて比べても、いずれも産業計を上回っています。ちなみに産業計（全体）の入職率は14.8%、離職率は14.2%でした。なお「宿泊業，飲食サービス業」は16大産業のうちの1分類で、旅館単独の数値ではない点には注意が必要です。

それでも、パートの3人に1人近くが1年で入れ替わる可能性を前提に運用を組む必要がある、という示唆は動きません。返信の型が担当者の頭の中にしかない宿では、1人辞めるたびに品質が1件8分の初期状態に戻ります。逆に型が外に出ていれば、新しい担当者でも、その型をなぞる形で早く戦力になれます。どんな形で型を外に出しているかは、実際の自動化の事例を見ると具体的にイメージしやすいはずです。

自前で組んだときにつまずく落とし穴

33万〜110万円かけるなら、うちのスタッフが勉強して作れないか——これは自然な発想です。実際、GASやAPIを使えば形にはなります。ただし、つまずきやすい落とし穴が5つあります。このうち①〜③は、BoostXが業務自動化ツール開発を支援するなかで、実際に直面してきた技術的な落とし穴です。④と⑤は、自前構築で構造的に起きやすい論点として挙げます。順に見ていきます。

落とし穴①：予約データの形式がバラバラで、そもそも動かない

自前構築で最初に止まるのが、ここです。OTAごとに予約データの書式が違い、日付が「2026/08/20」「2026-08-20」「8月20日」と3通りに混在します。人数の欄が「2」なのか「大人2名」なのかも統一されていません。この状態でAIに読ませると、判定がずれます。1件でもずれれば、キャンセル料の計算が狂います。

整形処理を書けば解決しますが、この整形は「一度書いて終わり」になりません。OTA側の仕様変更が入るたびに書き直しが必要です。その変更に自社で追随し続けられるかどうか。ここが自前構築の最初のハードルになります。

落とし穴②：GASの6分制限に、繁忙期の件数が引っかかる

GASで組んだ処理には、1回の実行が6分で強制終了されるという制限があります。通常期に1日10件を処理している間は問題になりません。ところが連休前に予約が集中し、1日40件、50件と増えた瞬間に、6分の壁に当たって処理が途中で止まります。

やっかいなのは、この障害が「一番忙しい日に限って起きる」ことです。通常期の3ヶ月間まったく問題が無かったから安心していたら、繁忙期の初日に止まる。分割実行やトリガー設計で回避できますが、それを見越して最初から組んでおく必要があります。件数が2倍、3倍になっても壊れない設計かどうかは、作る前に決まります。

落とし穴③：エラー通知が無く、止まったことに誰も気づかない

3つ目が最も怖い落とし穴です。自前で組んだ処理は、エラー通知の設定が後回しになりがちです。その結果、処理が止まっても誰も気づきません。「返信の下書きが上がってこないな」と思ったときには、3日ぶん、20件ぶんの返信が未対応で溜まっています。

自動化は、動いている間は誰も見ません。だからこそ、止まったことを知らせる仕組みが本体とセットで必要です。失敗を1件検知したら5分以内に担当者へ通知が飛ぶ、といった設計が入っているかどうかで、事故の大きさは1件規模と20件規模に分かれます。

落とし穴④：宿泊者の個人情報をどこまでAIに渡すかが決まっていない

宿の予約データには、氏名・電話番号・住所・宿泊日という個人情報が揃っています。自前で組む場合、「とりあえず全部AIに渡す」構成になりがちです。しかし返信の下書きに必要なのは、プラン区分・宿泊日・人数の3項目程度で、氏名や電話番号まで渡す必要はありません。

渡す情報を3項目に絞れば、万一の際の影響範囲も3項目で済みます。ここは技術より運用ルールの問題で、社内で決めておかないと担当者の判断でどんどん広がります。こうしたルール作りと定着まで含めて外部の視点を入れたいなら、月額11万円からのAI伴走顧問のような継続支援のほうが向いている場合もあります。

落とし穴⑤：作った担当者が辞めたら、誰も触れなくなる

5つ目は、技術ではなく組織の話です。自前で組む場合、作れるのは社内で1人だけ、というケースは珍しくありません。その1人が異動や退職でいなくなると、コードの中身を誰も説明できなくなります。動いている間は問題ありませんが、OTAの仕様変更で止まった日に、修正できる人が0人になります。

この状態を「安く作れた」と評価してよいのかは、判断が分かれるところです。初期0円で作った仕組みが、2年後に止まって手が付けられず、結局1件8分の手作業に戻る。それなら、開発体制ごと社内に持てる形を検討する選択肢もあります。エンジニアを採用せずに自走できる状態を作るClaude Code構築サービスのような進め方は、この属人化への回答のひとつです。作る前に「3年後、誰が直すのか」を決めておくことが要点です。

ビフォーアフター：OTA返信の1週間がここまで変わる

ここまでの話を、1週間という単位に落として並べてみます。数字はいずれも目安で、ここでは1日10件前後・月200件規模の宿を例にします。返信件数が月50件の宿なら、後半に示すとおり工数の差は約5時間以上が目安になります。

違いを生んでいるのはツールではなく運用設計

BeforeとAfterで使っているAIの性能は、実は同じです。差を生んでいるのは、返信の型をどこに置いたか、例外をどう止めるか、誰が最終確認をするか、という運用設計です。同じChatGPTを使っていても、担当者の頭の中だけで運用すれば、速くなるのはその1人だけで属人化し、宿のルールとして外に出せば1件1分の確認で誰でも回せます。33万〜110万円という初期費用の中身も、ソフトウェアの値段ではなく、この設計と定着にかかる時間の対価だと考えてください。

「うちはまだBefore寄りだ」と感じた方は、次のセクションで、どこから手を付けるかの相談先を案内します。

よくある質問

公開日：2026年8月