ホテルの客室・館内で起きた事故・苦情・設備トラブルの過去の対応記録を検索し、似た事案の対応手順と補償の判断を夜間の当直者に示す

処理の起点を決める

当直者がフロントの端末かタブレットで状況を入力し、検索を押したときに動かします。 夜間の事案は予告なく起きるので、定時の一括処理にはしません。 入力の画面は、場所（客室番号・大浴場・駐車場など）と事案の種類（けが・設備・苦情・紛失・破損）を選び、状況を一言で書くだけにします。長い文章を書かせると、入力に時間がかかってお客さまを待たせます。

検索の結果を見て当夜の対応を終えた後、当直者が経過を入力すると、日報・事故報告書・申し送りの下書きを作る2回目の処理が動きます。

過去の対応記録の取り込みは、これとは別に動かします。毎朝、前夜までに確定した事故報告書と日報をS3の取り込みフォルダに置いたことを起点に、事案ごとのまとめ、仮名への置き換え、ベクトルの作成、索引への登録を行います。

入力データを集める

質を決めるのは、過去の対応記録の「決裁者」と「その後の経過」の欄です。 決裁者が無ければ、補償の前例が誰の判断だったのかを示せません。その後の経過が無ければ、翌朝に何が問題になったかを申し送りに書けません。 古い記録では空欄が多いため、取り込みのときに空欄のまま残し、空欄であることを検索の結果に出します。

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

取り込みでは、1つの事案を1つの記録にまとめ、次の項目を持たせます。

ベクトルは Amazon Titan Text Embeddings V2 で作ります。入力は最大8,192トークン・50,000文字で、出力は既定で1,024次元です。公式は、長い文書を段落や節のような論理的な単位に分けることを勧めています。 1つの事案の経過が長いものは、本文を「状況」と「対応」に分けて別のベクトルにします。日本語は多言語対応の言語の一覧に含まれています。

社内の補償基準は、対応記録とは別の索引に置きます。 前例の検索の結果に基準が混ざると、基準の文が「似た事案」として並び、前例と基準の区別がつかなくなります。 補償基準は事案の種類で引き、検索の結果とは別の欄に出します。

検索の絞り込みは、hybrid クエリの filter で行います。filter はすべての検索に同じように効くため、館・場所の種類・事案の種類の条件は1つの bool クエリにまとめます。点数の正規化は normalization-processor を使い、既定の min_max と arithmetic_mean から始めます。当直者の入力は短いので、意味の近さの重みを最初から少し重くします。 重み（weights）は合計が1.0になるように決めます。

検索の形は、おおむね次のとおりです（値は例）。

{
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "summary_text": "客室 浴室 転倒 頭" } },
        { "knn": { "embedding": { "vector": [0.021, -0.008], "k": 30 } } }
      ],
      "filter": {
        "bool": {
          "filter": [
            { "term": { "location_type": "客室" } },
            { "term": { "incident_type": "けが" } }
          ]
        }
      }
    }
  },
  "size": 5
}

館の絞り込みは、最初は入れません。 3館で設備も客層も違いますが、浴室での転倒のような事案は館をまたいで参考になります。結果に館の名前を出し、当直者が自分の館の前例かどうかを見分けられるようにします。 館ごとの設備のトラブル（特定の型の給湯器など）を探すときだけ、館で絞ります。

AIへ渡す前に整形する

1. お客さまの氏名を仮名に置き換える … 取り込みのときに、氏名・電話番号・メールアドレスを仮名に置き換えます
2. けがや体調の記述を分ける … 病院名・診断の内容など体調に関わる記述は、別の項目に分けて検索の本文から外します
3. 同じ事案をまとめる … 日報とメールと事故報告書で、館・客室・日時が同じものを1つの事案にまとめます
4. 事案の種類を付け直す … 古い記録の分類の名前がばらばらなら、今の分類に読み替えます
5. 当直者の入力の客室番号を場所の種類に変える … 「302」は「客室」、「B1」は「駐車場」のように、館ごとの対応表で変えます
6. 補償基準の版を確かめる … 基準を改めたら、古い版を索引から外し、新しい版だけを引くようにします

1番目と2番目を省かないでください。 夜間の検索の結果は、フロントの画面に出ます。ほかのお客さまの氏名や、けがの内容が画面に出る設計にしてはいけません。 仮名で検索しても、前例として必要な情報は失われません。

AIに処理させる

させるのは、検索で見つかった事案を、決まった観点ごとに並べて書き出すことだけです。

補償の前例には、必ず決裁者と事情を並べさせます。 「宿泊料の半額を返金」だけが当直者の目に入ると、それが当直者の権限で約束できることのように見えてしまいます。

1行目がいちばん起きやすい失敗です。 前例に返金の事案が並ぶと、AIは「今回も同様に宿泊料の一部返金が考えられます」とまとめがちです。その一文が、当直者の口からお客さまへの約束として出ていきます。 前例は前例として並べさせ、勧めの形で書かせません。

4行目は法律の定めに関わります。 旅館業法第5条は、営業者は定められた事由に当たる場合を除いて宿泊を拒んではならないとし、宿泊を拒む場合には、該当するかどうかを客観的な事実に基づいて判断し、求めに応じて理由を丁寧に説明できるようにするものとしています。過剰な要求を繰り返すお客さまの事案でも、AIはその判断に踏み込ませません。

指示内容を固定する

あなたはホテルの夜間の当直者を手伝う係です。
渡された【当直者の入力】【検索で見つかった事案】【社内の補償基準】だけを見て、
似た事案を観点ごとに並べてください。推測で埋めないでください。

【並べる観点】
1. actions ....... 当夜の対応手順（過去の事案で当直者がとった対応を順に）
2. contacts ...... 連絡した先
3. compensation .. 補償の内容と、それを決めた人（決裁者）
4. aftermath ..... 翌朝以降に問題になったこと
5. rule .......... 社内の補償基準のうち、この事案の種類に当てはまる文（そのまま写す）

【厳守事項】
- 事案ごとに、記録の番号（case_id）を必ず付けてください。
- 記録に書かれていない観点は "not_recorded" としてください。
- 補償の前例には、必ず決裁者（approver）を書いてください。
  決裁者が記録に無ければ "approver_unknown" としてください。
- 今回、補償をすべきか、いくら補償すべきかを書かないでください。
  「今回も同様に」「〜が考えられます」のような勧めの書き方をしないでください。
- 自社に責任があるかどうかを書かないでください。
- けがの程度や、受診が必要かどうかを書かないでください。
- 宿泊を断るべきかどうかを書かないでください。
- 検索で見つかった事案に無い対応を書き足さないでください。
- お客さまの氏名や体調の内容を書かないでください。仮名と事案の番号だけを使ってください。
- 社内の補償基準は、言い換えずにそのまま写してください。

【当直者の入力】{night_input}
【検索で見つかった事案】{cases}
【社内の補償基準】{rules}

「勧めの書き方をしない」に具体的な言い回しを2つ挙げているのには理由があります。 「判断しないでください」とだけ書くと、AIは判断の言葉を避けつつ「〜が考えられます」と書いて、実質的に勧めの文を作ります。 禁じる言い回しを名指しします。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とスキーマを指定）を使い、形の崩れた応答を当直者の画面に出さないようにします。

{
  "query_id": "",
  "rule": { "text": "", "status": "found | no_rule" },
  "cases": [
    {
      "case_id": "",
      "hotel": "",
      "occurred_at": "",
      "similarity_note": "",
      "actions": ["", ""],
      "contacts": [""],
      "compensation": { "content": "", "approver": "", "status": "recorded | not_recorded | approver_unknown" },
      "aftermath": ""
    }
  ],
  "handover_items": [""]
}

1つ目の理由は、補償の前例と補償基準を別の欄に置けることです。 当直者の画面では、rule を上に、cases の補償の前例をその下に出します。約束してよい範囲が先に目に入る並びにします。

2つ目は、case_id で原本に戻れることです。 当直者は気になった前例を、その番号で事故報告書の原本から開けます。検索の結果が原本と違っていれば、原本を正とします。

3つ目は、handover_items を申し送りの下書きに使えることです。 似た事案の aftermath から、翌朝に決める必要のあることを拾って並べます。

システムへ連携する

予約・客室管理の仕組みへは書き込みません。 部屋の移動や返金の処理は、当直者が既存の手順で行います。検索の結果から直接、返金や割引が処理される経路を作りません。

OpenSearch の権限は、細かいアクセス制御で絞ります。 細かいアクセス制御（fine-grained access control）は、索引・文書・項目の単位で見せる範囲を決められ、特定の項目を消さずに匿名化する項目のマスキングも使えます。当直者の役割には、仮名と体調の項目を見せない設定にします。有効にするには、HTTPS・保存データの暗号化・ノード間の暗号化が要り、一度有効にすると無効に戻せません。

人が確認する

当直者は、検索の結果をすべて読みます。 結果は1回の検索で5件ほどに絞って出すので、全件を読めます。

1. 補償基準（rule）を先に読む … 当直者が約束してよい範囲を確かめます
2. 前例の決裁者を見る … 支配人の判断だった補償を、当直者が約束しないようにします
3. 当夜の対応手順と連絡先を、今夜の状況に合わせて選ぶ … 前例の手順をそのまま使わず、現場の状況と照らします
4. 日報・事故報告書・申し送りの下書きを直して確定する … 下書きは当直者の入力から作るので、事実と違うところは当直者が直します
5. 翌朝、支配人が前例と当夜の対応を見比べる … 前例と違う対応をした理由を、申し送りで確かめます

2番目を省かないでください。 決裁者が支配人だった前例を当直者が約束すると、翌朝、支配人がその約束を覆すか、基準を超えた補償を追認するかの二択になります。 どちらもお客さまとの関係を損ねます。

例外に対処する

上から1行目が、この構成のいちばん大事な例外です。 検索は、命と建物を守る行動の後に使うものです。入力の画面の最初に「救護・通報が要る場合は先に行う」の表示を出し、検索のボタンより上に置きます。

記録を残す

• 当直者の入力と、検索の日時・館
• hybrid クエリの結果（事案ごとの点数と順位）と、そのときの重み
• 生成AIの整理の結果（rule、cases、handover_items）
• 当直者が実際にとった対応と、お客さまに伝えた内容
• 日報・事故報告書・申し送りの下書きと、当直者が確定した版
• 翌朝の支配人の判断と、前例と違う対応をした理由

4つ目と最後の行は、次の事案の検索の対象になります。 確定した事故報告書を毎朝取り込むので、今夜の対応が、次の夜の当直者の前例になります。 決裁者とその後の経過の欄を空けたまま確定させないことが、検索の質を保つ条件です。