ホテルでリピーターの到着前に、過去の滞在・要望・苦情・アレルギーの記録を氏名の表記ゆれも含めて探し、その日の申し送りにまとめる

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは毎晩の定時です。 宿泊の管理システムからは前日までのチェックアウトの記録と顧客のプロフィールの変更を、苦情の対応記録とレストランの予約台帳からは前日に追加・更新された行を取り出します。苦情の記録は対応が終わってから書き足されることが多いので、更新された行も取り直します。

検索は、到着前日の15時に動かします。 この時刻なら、翌日の到着予定がほぼ出そろい、担当者が候補を確かめて申し送りを確定するまでの時間が夕方までに残ります。当日の朝に入った予約は、10時にもう一度動かして拾います。

過去5年分の記録は、別に一括で取り込みます。 このときは結びつきの確認が取れていないので、どの記録も「未確認」の状態から始めます。 一括の取り込みで名寄せをしようとしないでください。確認は、実際に到着する人の分から順に積み上がります。

入力データを集める

質を決めるのは、苦情の対応記録の氏名の書き方です。 表計算に「渡辺様（1205号室）」とだけ書かれていると、氏名の手がかりが漢字だけになり、部屋番号と日付から予約に結び直す必要があります。取り込みの段で、日付と部屋番号から予約番号を引き、予約の氏名・電話・メールを記録に付けます。

アレルギーの記録は、申し出の日付を必ず持たせます。 何年も前の申し出が今も同じとは限りません。申し送りでは「いつの申し出か」を必ず書き、本人への確認を前提にします。

データの取得方法を決める

宿泊の管理システムからは、予約と顧客のプロフィールを API か定時の書き出しで取ります。苦情の対応記録とレストランの予約台帳は、共有の場所に置かれた表計算のファイルを毎晩読むだけで足ります。

索引の項目は、次のように持たせます。

ふりがなが入っていない記録は、kuromoji の読みの変換で補います。 kuromoji_readingform は、トークンを読み（カタカナ、または use_romaji でローマ字）に置き換えるフィルタで、漢字には読みが複数あるため、kuromoji の辞書の読みを使うとされています。人名の読みは辞書どおりとは限らない（「東海林」「小鳥遊」など）ので、補った読みには印を付け、一致しても弱い手がかりとして扱います。

AIへ渡す前に整形する

1. 電話番号の正規化 … ハイフンと空白を除き、国番号付き（+81）と0始まりを同じ形にそろえます
2. メールアドレスの正規化 … 小文字にそろえます。予約サイトが中継用に発行するアドレスは、手がかりから外します
3. 氏名の分解 … 姓と名の区切りを判定し、ローマ字の姓名が逆順で入った予約は両方の順で持たせます
4. ふりがなの補完 … ふりがなが無い記録は、読みの変換で補い、補ったことを印にします
5. 苦情の記録と予約の結び直し … 日付と部屋番号から予約を引き、氏名・電話・メールを付けます
6. 記録の文からの要点の取り出し … Claude で、苦情とアレルギーの記録から部署・要点・対応の結果を取り出します

2番目を見落とすと、名寄せが崩れます。 予約サイトによっては、宿泊客の本当のアドレスではなく予約ごとの中継用のアドレスが届きます。それを強い手がかりに使うと、一致しないのが普通になり、強い手がかりが働きません。

3番目の逆順は、海外の予約サイトで頻繁に起きます。 「TARO WATANABE」と「WATANABE TARO」は、ローマ字の一致では別の語の並びです。両方の順で索引に入れ、どちらで当たったかを候補に書きます。

AIに処理させる

AIの仕事は2か所です。取り込み時の要点の取り出しと、確かめた記録からの申し送りの案です。 同じ人の候補を探すのは検索基盤で、AIに名寄せをさせません。

2行目がいちばん外せない線です。 苦情の記録を要約させると、AIは「クレームの多いお客様」「要注意」のような言葉でまとめたがります。その一言が申し送りに載ると、スタッフの接し方が変わります。 書くのは「前回、何があり、何をしたか」までです。

指示内容を固定する

取り込み時（苦情の記録の要点）：

あなたはホテルのゲストリレーションの担当です。
苦情とご意見の対応記録から、次回の滞在に役立つ要点を取り出します。
記録に書かれたことだけを根拠にしてください。推測で埋めないでください。

【取り出す項目】
- departments：関係する部署（front／housekeeping／restaurant／facility）
- issue：何があったか（1〜2文。事実だけ）
- resolution：ホテルが行った対応（返金、部屋の変更、お詫びの品など）
- next_time：記録に書かれた「次回の配慮」。書かれていなければ空

【厳守事項】
- 宿泊客の人柄、性格、態度を表す言葉を使わないでください。
  「要注意」「クレーマー」「気難しい」などの評価を書かないでください。
- 記録に書かれていない対応や配慮を足さないでください。
- 健康状態やアレルギーに関する記載があれば、内容を要約せず
  health_mention を true にしてください（別の扱いにします）。

到着前（申し送りの案）：

あなたはホテルのフロントの担当で、翌日到着のお客様の申し送りを作ります。
渡された検索結果（担当者が同じ人だと確かめた記録）だけを根拠にしてください。

【予約】{reservation}
【確かめた過去の記録】検索結果として渡します

【書くこと】部署ごとに分けて
1. フロント：過去の滞在の回数と直近の日付、客室の希望
2. 客室：部屋の位置や設備についての過去の要望と対応
3. レストラン：アレルギーの申し出（申し出の日付を必ず添える）
4. 前回の滞在での苦情と、ホテルが行った対応

【厳守事項】
- アレルギーは「○年○月の申し出」と日付を書き、
  「到着時に本人へ現在の内容を確認」の一文を必ず付けてください。
- お客様の人柄や評価を書かないでください。
- 記録に無い好みを推測しないでください。
- 記録が3年以上前のものは、その旨を書いてください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の記録を1つの search_result にし、source に記録の番号、title に記録の種類と日付、content に記録の本文を入れます。公式の説明では、引用は content の中のテキストブロックを単位に付き、引用された範囲がブロックの番号で返ります。 申し送りの1文ごとに、どの記録から来たかを担当者が辿れます。この仕組みは Amazon Bedrock でも使えます。

出力形式を固定する

到着前の候補の一覧は、次の形で担当者の画面に出します。

{
  "reservation_id": "R-20261008-0412",
  "arrival": "2026-10-08",
  "guest_on_booking": { "name_latin": "watanabe taro", "channel": "ota_overseas" },
  "candidates": [
    {
      "profile_id": "P-0031877",
      "match": ["phone_exact", "name_kana", "name_latin_fuzzy"],
      "name_kanji": "渡邊 太郎",
      "last_stay": "2025-11-14",
      "records": { "stay": 4, "complaint": 1, "allergy": 1 },
      "status": "unconfirmed | confirmed_same | confirmed_different"
    }
  ]
}

1つ目の理由は、match に一致の種類を並べられることです。 電話の完全一致があるか、名前だけの一致かで、担当者の確かめ方が変わります。 名前だけの候補は、過去の住所や年齢層を開いて確かめます。

2つ目は、confirmed_different を残せることです。 別人だと判断した組を記録しておくと、次回の検索で同じ候補を出し続けずに済みます。

3つ目は、records の件数で、開く順番を決められることです。 苦情とアレルギーの記録がある候補を先に確かめます。

検索の要求は、次のように組みます。

{
  "query": {
    "bool": {
      "should": [
        { "term": { "phone": { "value": "+819012345678", "boost": 5 } } },
        { "term": { "email": { "value": "[email protected]", "boost": 5 } } },
        { "match": { "name_kana": { "query": "ワタナベ タロウ", "boost": 2 } } },
        { "match": { "name_latin": { "query": "watanabe taro",
                                     "fuzziness": "AUTO", "operator": "and" } } }
      ],
      "minimum_should_match": 1
    }
  }
}

ローマ字の近い一致は、fuzziness の AUTO に任せます。 公式のドキュメントでは、AUTO は語の長さで許す違いの数を変え、0〜2文字は完全一致、3〜5文字は1文字まで、6文字以上は2文字までとされています。「sato」と「satou」、「ono」と「ohno」は1文字の違いで拾えます。operator を and にするのは、姓だけ・名だけの一致で候補が膨らむのを防ぐためです。

システムへ連携する

宿泊の管理システムと2つの台帳には、書き込みません。 確かめた結びつき（guest_key）は検索基盤の側に持ち、管理システムのプロフィールの統合は、管理システムの手順で人が行います。

人が確認する

確認は2か所です。同じ人の候補と、申し送りの案です。

1. 電話かメールが一致した候補 … 名前と最後の滞在日を見て、同じ人として確定します。ほとんどはここで済みます
2. 名前だけが一致した候補 … 過去の住所、同伴者、利用の傾向を開いて確かめます。決めきれなければ「未確認」のまま残し、申し送りには使いません
3. 申し送りの案を読む … 引用を辿り、部署ごとの文を直して確定します。アレルギーの行に日付と確認の一文があるかを必ず見ます
4. 到着時に本人に確かめる … アレルギーと前回の要望は、フロントかレストランが本人に現在の内容を確かめます

1件あたり3分を目安にします。 電話やメールが一致する候補は数十秒で確定し、名前だけの候補とアレルギーの記録がある予約に時間を使います。ならして3分です。

2番目で「未確認」のまま残すことを、失敗と考えないでください。 決めきれない候補を無理に結びつけるより、到着時にフロントが「以前にもお泊まりいただいていますか」と一言たずねるほうが確かです。本人の答えで結びつきを確定し、その場で記録に残します。

例外に対処する

1行目を軽く見ないでください。 見つからないことは、初めてのお客様であることを意味しません。 旧姓、勤務先の名義、同伴者の名義で泊まっていた可能性があります。

7行目は、取り込みの段で分けます。 苦情の記録には「体調を崩された」「持病の薬を部屋に忘れた」のような記載が混ざることがあります。要点に含めると、苦情の要点を見られる役割の全員に健康の情報が見えてしまいます。 取り込みの指示で health_mention を立てさせ、その記録だけ閲覧の役割を絞った項目に移します。

記録を残す

• 取り込んだ記録の元の台帳と行、取り込んだ日時
• 到着前の検索ごとの予約、候補、一致の種類
• 担当者が同じ人・別人と判断した記録 … 誰が、いつ、何を見て判断したか
• Claude に渡した記録と、返ってきた申し送りの案と引用
• 担当者が確定した申し送りと、案からの直し
• 到着後に、記録の結びつきが誤っていたと分かった件

最後の行が、この構成の精度を測る材料です。 別人の記録を結びつけていた件は、どの一致の種類で起きたかを見て、名前だけの一致の扱いを見直します。