AIで常連客の好みを記録・活用する「おもてなしDB」事例

結論：常連客のデータを「記憶」から「仕組み」に変えると、リピート率が上がる

常連客が「また来た」と感じるのは、前回の好みをスタッフが覚えていて、何も言わなくても反映されているときだ。だが熟練スタッフの記憶に頼る運営は、退職や異動で一瞬にして崩れる。

ある温泉旅館では、AIと顧客管理ツールを組み合わせて「おもてなしDB」を構築した結果、スタッフ交代後もゲスト一人ひとりの好みを来館前に把握できるようになり、リピーター比率が6ヶ月で約8ポイント上昇した。本記事ではその具体的な仕組みと導入手順を解説する。

なぜ「記憶頼り」のおもてなしが限界なのか

旅館の現場では、ベテランの仲居やフロントスタッフが「山田様はいつも禁煙の角部屋」「鈴木様は辛いものが苦手」といった情報を頭に入れて接客している。この個人的な記憶は非常に強力だが、3つの弱点がある。

1つ目は、退職・異動による情報喪失。長年の常連客の情報がスタッフとともに消える。 2つ目は、担当外スタッフへの非共有。その日たまたま担当が替わると、情報が活かされない。 3つ目は、客数増加への非スケーラビリティ。客室が30室を超えると、全常連客の好みを記憶し続けることは現実的でなくなる。

DBに情報を記録・共有する仕組みがあれば、この3つをすべて解決できる。

おもてなしDBとは何か

おもてなしDBとは、ゲストごとの好み・要望・過去の滞在履歴を一元管理するデータベースのことだ。記録する情報の例を以下に示す。

項目	具体例
部屋の希望	禁煙・角部屋・離れ棟・高層階
食事の好み	魚介類が苦手・アレルギー（そば・卵）・少食
布団・アメニティ	硬めマットレス・枕2個・特定シャンプーを希望
嗜好品	日本酒は辛口のみ・コーヒーはブラック
記念日情報	毎年8月に結婚記念日で来館
過去のクレーム	前回空調が効きすぎてクレームあり
スタッフメモ	話し好きなので時間があれば会話を

これを紙や個人メモでなく、全スタッフが閲覧・更新できる共有DBに置くことで、「仕組みとしてのおもてなし」が成立する。

AIが担う3つの役割

ただ情報を蓄積するだけなら、以前からCRMやPMSのメモ欄で試みた旅館は多い。続かなかった理由は「記録が面倒」と「見返す時間がない」の2点に集約される。AIはこの2つを解消する。

役割1：チェックアウト後の自動サマリー生成

チェックアウト後、スタッフが会話や接客で気づいたメモを音声または短文で入力すると、ChatGPT（またはGemini）が構造化されたDB用フォーマットに変換する。

スタッフの入力例：「山田様、今回は料理の量が多いとおっしゃってた。あと源泉かけ流しの露天を特に気に入っていた様子。来年の同日に記念日で来るって言ってた」

AIが変換した出力例：

【食事】量：少なめ希望
【施設】露天風呂（源泉かけ流し）を特に好む
【次回予定】来年同日（記念日）に再来の意向あり → 記念日サービス検討

この変換作業は1件あたり1〜2分で完了する。手書き台帳への転記と比べ、記録の負担が大幅に下がる。

役割2：来館前ブリーフィング資料の自動生成

翌日のチェックインゲストリストをDBと照合し、「今日来るゲストのポイント」を朝礼用に自動でまとめる。

出力例：

【本日のVIPゲスト情報】
14:00 鈴木様（ご夫婦・3回目）
- 部屋：禁煙和室を希望（前回同様）
- 食事：奥様が甲殻類アレルギー ★必ず厨房へ共有
- 前回メモ：浴衣のサイズがLLのご主人、Mの奥様
- 特記：昨年のアニバーサリープランが好評。今回は通常プランだが、
  メッセージカードを部屋に置くと喜ばれる可能性あり

この資料があることで、担当スタッフが初対面でも「覚えていてくれている」という体験をゲストに提供できる。

役割3：傾向分析とサービス改善提案

データが蓄積されると、AIに「直近1年の常連客のメモを分析して、改善すべきサービスを3つ挙げて」と聞ける。複数ゲストに共通する不満や要望を横断的に抽出し、施設改善の判断材料になる。

導入手順：小規模旅館でも3週間で動かせる

ステップ1：記録ツールの選定（1週目）

客室数や予算に応じてツールを選ぶ。

規模	推奨ツール	月額目安
10室以下	Notionの無料プラン + ChatGPT	3,000〜5,000円
10〜30室	Airtable + GPT-4 API	8,000〜15,000円
30室以上	PMS連携型CRM（SUITEBOOK等）	要見積

最初はNotionで十分だ。ゲストDBのテンプレートを作り、各フィールド（好み・アレルギー・部屋希望・自由メモ）を定義する。

ステップ2：AIプロンプトの準備（1週目）

ChatGPTに渡す変換プロンプトを1本作る。基本形は以下のとおりだ。

あなたは旅館のゲスト情報管理担当です。
スタッフのメモを以下の項目に整理してください。
項目：食事の好み / 部屋の希望 / アメニティ / 記念日・特記事項 / 次回への申し送り
メモ：[ここにスタッフのメモを貼り付け]

このプロンプトはプロンプト集記事に応用例を載せているので参照してほしい。

ステップ3：記録フローの習慣化（2週目）

最大の課題は「入力を続けること」だ。成功した旅館に共通するのは、記録のタイミングをチェックアウト業務に組み込んだことだ。具体的には「チェックアウト処理をPMSで完了させたら、30秒でメモを残す」という順番を作った。

入力をSlackのチャンネルやLINE WORKSに送信するだけにしておき、夜間にまとめてAI変換してDBに格納するフローにすると、スタッフの負担がさらに下がる。

ステップ4：来館前ブリーフィングの試験運用（3週目）

毎朝の朝礼前に担当者がDBを確認し、当日チェックインのゲスト情報をチャットに流すフローを試す。最初の1〜2週間は手動でも問題ない。慣れたらPythonスクリプトやZapierで自動化する。

AI議事録を活用した引き継ぎ効率化の事例と組み合わせると、朝礼時間をさらに短縮できる。

実際の事例：客室18室の温泉旅館

石川県の客室18室の旅館では、2025年1月にNotionとChatGPTでおもてなしDBを構築した。導入前の課題は「ベテランの仲居が2名退職し、常連客への対応が急激に劣化した」ことだった。

導入前の状況

常連客情報は退職した仲居の個人ノートに記載
引き継ぎノートはあったが、300名分の情報を読み込む時間がなかった
「先日も来たのに全然覚えていない」というクレームが月3〜5件

導入後（6ヶ月時点）の変化

常連客クレーム件数：月3〜5件 → 月0〜1件
リピーター比率：32% → 40%（8ポイント上昇）
朝礼でのゲスト確認時間：15分 → 5分
新人スタッフの接客満足度（アンケート）：「また来たい」が導入前比12ポイント増

特に効果が大きかったのは「新人スタッフが初対面でも的確に対応できるようになった」点だ。ベテランが数年かけて習得していた「記憶」を、新人が初日から参照できる状態になった。

担当スタッフのコメント：「名前を呼びながら『前回ご希望の禁煙の角部屋をご用意しました』と言うだけで、お客様の表情が変わります。この一言のためにDBを続けています」

個人情報の取り扱いで注意すべき点

おもてなしDBには食事アレルギーや健康状態に関する情報が含まれることがある。これらは個人情報保護法上の「要配慮個人情報」に該当する可能性があるため、取り扱いには注意が必要だ。

最低限おさえるべき事項は3点だ。

利用目的の明示：チェックイン時または予約時に「より良いサービス提供のため、ご要望を記録します」と伝える
アクセス権限の限定：DBの閲覧・編集権限を必要なスタッフのみに絞る
保管期限の設定：退会または最終来館から数年後に削除するルールを決める

詳細な要件は個人情報保護委員会のガイドラインで確認してほしい。旅館規模によっては、プライバシーポリシーへの追記も必要になる。

顧客管理・OTA戦略との連携を検討する際も、データ活用の範囲と同意取得のタイミングを事前に整理しておくと後から対処しやすい。

よくある失敗と対策

失敗1：情報を入力し続けられない 対策：入力を30秒以内で終えられる形式にする。「長く丁寧に書く」より「短くても続ける」を優先する。

失敗2：DBを見る習慣ができない 対策：チェックイン前日の自動通知を設定する。見ないと始まらないフローに組み込む。

失敗3：情報が増えすぎて探しにくくなる 対策：半年に1回、来館のないゲスト情報をアーカイブに移す。Notionであれば検索で即座に見つかるが、定期的な整理で鮮度を保つ。

失敗4：スタッフによって記録の粒度がバラバラ 対策：「何を書くか」ではなく「何を書かないか」を先にルール化する。アレルギー・部屋希望・前回クレームの3項目だけは必ず記録する、といった最低基準を設ける。

PMSとの連携で得られるさらなる効果

規模が大きくなると、PMSにゲストメモ機能が搭載されているケースも多い。しかし多くのPMSのメモ欄はテキストボックスに過ぎず、構造化されていないため検索や分析に使いにくい。

PMSからゲストIDと滞在履歴をエクスポートし、Notionや Airtableと突合させることで、「何泊したか」「いつ来たか」という行動データと「何が好みか」という属性データを組み合わせた分析が可能になる。

たとえば「3回以上来館かつアニバーサリープラン未購入の常連」をリストアップし、来館1ヶ月前にパーソナライズしたDMを送る、という施策は、このデータ統合なしには実現できない。需要予測とリピーター施策の組み合わせ事例も参考にしてほしい。

まとめ

おもてなしDBの本質は、熟練スタッフの「記憶」を施設全体の「資産」に変えることだ。AIはその変換コストを劇的に下げ、記録→活用のサイクルを継続しやすくする。

導入は小さく始められる。まずNotionに10名分の常連客情報を登録し、ChatGPTでチェックアウト後のメモを構造化する習慣を1週間続けてみてほしい。それだけで、翌月から来館前ブリーフィングに使えるデータが手に入る。

旅館の競争優位はサービスの「再現性」にある。一度来てくれたゲストを「覚えている」ことを仕組みで保証できれば、スタッフが変わっても旅館としての信頼が続く。

FAQ

Q. おもてなしDBを作るのに専用システムは必要ですか？ 必ずしも専用システムは不要です。NotionやGoogleスプレッドシートにChatGPTを組み合わせる方法から始められます。PMS連携が必要になるのは客室数30以上が目安です。

Q. スタッフが交代しても引き継げますか？ DBに記録が残るので、初めて担当するスタッフでも来館前にゲストの好みを確認できます。引き継ぎミーティングを不要にした旅館の事例もあります。

Q. 個人情報の取り扱いはどうすべきですか？ 食事アレルギーや健康情報は要配慮個人情報に該当します。プライバシーポリシーへの明記と利用目的の限定、アクセス権限の管理が最低限必要です。詳細は個人情報保護委員会のガイドラインで確認してください。

Q. 効果はいつ頃から出ますか？ データが100件を超えた頃から接客判断に使えるようになります。ある旅館では6ヶ月後にリピーター比率が8ポイント上昇しました。