旅館の予約担当と客室係からの宿泊約款・キャンセル規定・プランの条件・館内の決まりの質問に、根拠の条文付きでチャットで答える

処理の起点を決める

起点は、従業員がチャットに予約番号と質問を送ったことです。 チャットは館内のスマートフォンとフロントの端末から開き、従業員の Google アカウントでログインします。ログインした従業員の所属（予約担当／フロント／客室係）が、閲覧の範囲と答え方の長さを決めます。

予約番号を必須にします。 予約に関係しない質問（「大浴場は何時まで」）もありますが、それは「予約なし」を選んで送ります。予約番号のある質問は、必ずその予約の条件で答えます。 予約番号を省いて質問すると、どのプランのどの版で答えるかが決まらないからです。

1件の質問は、1つのセッションで最後まで続けます。 「では1名だけ減らす場合は」のような続けての質問も同じセッションでつなぎ、別の予約の質問は新しいセッションで始めます。 前の予約の条件が言い換えの中に残るからです。

入力データを集める

宿泊客の氏名や連絡先は、この構成には入れません。 予約システムから引くのはプランと経路と人数と日付だけで、誰の予約かは画面に出しません。 決まりを答えるのに、宿泊客の名前は要らないからです。

質を決めるのは、回す条件の表です。 「事情がある」「体調」「天候で交通機関が止まった」「まけてほしい」「他の客とのもめごと」のような値が選ばれたら、答えを作らずに回す、という規則をこの表に書きます。 天候による取消は、館によって取消料を取らない運用をしていることがあり、それは支配人がその日に決めることです。

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

約款・プランの条件・利用規則・回答集は、Cloud Storage に置いてデータストアに取り込みます。 文書ごとのメタデータに、文書の種類、プランコード、予約経路、適用開始日、適用終了日、閲覧の範囲を持たせます。

絞り込みの式は、プランと経路と版で書きます。 項目を索引可能にしておけば、(doc_type: ANY("plan") AND plan_code: ANY("SP24A") AND channel: ANY("ota_b")) OR doc_type: ANY("terms", "house_rules") に、valid_from <= "2026-08-14" のような日付の条件を加えて書けます。日付は ISO 8601 の形式でメタデータと検索の文をそろえます。 プランの条件は予約を受けた日の版で、利用規則は宿泊日の版で絞ります。

旅行会社との契約条件には、閲覧の範囲を付けます。 そこには卸の料金も書かれているため、acl_info に予約担当のグループだけを書き、客室係の検索には出しません。この設定はデータストアの作成時にしか選べません。アクセス制御はプレビューの機能なので、使わない場合は契約条件だけを別のデータストアに分け、予約担当の画面からしか呼ばない形にします。

取消料の率は、データストアではなく表から引きます。 中継プログラムがプランの条件表を、プランコード・予約経路・版・取消の通知を受ける日の区分で引き、率をそのまま回答に添えます。

AIへ渡す前に整形する

1. プランの条件を表にそろえる … 季節ごとの表計算を、プランコード×予約経路×版の1枚の表にします。予約サイトに条件を変えて出したプランは、経路ごとに行を分けます
2. プランの条件を文書にも起こす … 表の各行から、取消料・食事・子供料金・連泊・ペットの条件を文章にした1ページの文書を作り、メタデータを付けます
3. 約款を条ごとに分ける … 約款のPDFは条の見出しが付いた形のまま取り込み、別表は表として読ませます
4. 利用規則を場所ごとに分ける … 大浴場、食事処、客室、駐車場のように場所の見出しを立てます
5. 版の適用開始と終了を付ける … プランを作り直すたびに、旧版に終了日を書きます
6. 回答集を整える … 根拠の条文を書き添え、今の約款やプランで通用しない回答には終了日を付けます
7. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

2番目の「表を文書にも起こす」が、この構成でいちばん効きます。 検索は文章を引くもので、表計算の1行からは「このプランは夕食なしで、子供は添い寝のみ」という説明が出てきません。率は表から機械で引き、説明は文書から検索で引く、と役割を分けます。

7番目は、データストアを作る前に決めます。 分割はデータストアの作成のあとでは有効にも無効にもできず、見出しを含める設定は既定では無効です。 利用規則の「午後11時まで」という断片は、見出しが無いと大浴場の話か食事処の話か分かりません。分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、予約の条件に当たる約款・プランの条件・利用規則の記載を見つけ、従業員が宿泊客にそのまま伝えられる短い答えを、根拠を付けて返すことです。 何を聞き返すか、何を回すかは、回す条件の表で中継プログラムが決めます。

answer メソッドの設定は次のようにします。

filteringLevel を高くすると、答えが返らずに責任者へ回る質問が増えます。 最初の1か月は回る件数を見て、多すぎれば低い設定と比べます。

4行目がいちばん起きやすい失敗です。 回答を作るモデルは、一般的な旅館の取消料の相場を知っています。それで補うと、自館のどこにも書いていない率が、自館の決まりのように宿泊客へ伝わります。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは旅館のフロントの責任者として、
予約担当・フロント・客室係から、宿泊客に聞かれた決まりの質問に答えます。
読むのは、宿泊客を待たせて確かめている従業員です。短く答えてください。

【前提】
検索の文の最初に、予約経路、プランコード、予約を受けた日、
宿泊日、人数、泊数、質問の種類が並んでいます。
その予約に当たる記載だけを使って答えてください。

【根拠の順】
プランの条件に書いてあることを先に使ってください。
プランの条件に書いていないことだけ、宿泊約款と館内の利用規則で答えてください。
プランの条件と約款が違うときは、プランの条件で答え、そのことを書いてください。

【答え方】
1. 最初に、宿泊客に伝える答えを2〜3文で書いてください。
2. 次に、根拠の文書の名前と条（またはプランコードと版）を書いてください。
3. 宿泊客に伝えるときに言い添えることがあれば、1つだけ書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  一般的な旅館の慣習や、他の宿の決まりの知識で補わないでください。
- 取消料・追加料金の金額を計算しないでください。
  率は別に表示されるので、文章の中で数字を作らないでください。
- 宿泊を断るか、契約を解除するか、取消料をまけるかを書かないでください。
  そうした質問には「責任者へ回します」とだけ書いてください。
- 別のプラン、別の予約経路の条件を並べないでください。
- 該当する記載が見つからないときは、
  「プランの条件・約款・利用規則に該当する記載が見つかりません。責任者へ回します」
  とだけ書いてください。

「プランの条件を先に使う」が、この指示の要です。 モデル宿泊約款は、宿が特約に応じたときは特約が約款より優先するとしています。プランの条件は、その予約についての特約にあたる位置にあります。 指示が無いと、約款の一般的な条文を先に引き、プランで変えている点を落とします。

検索の文は、中継プログラムが組み立てます。 例えば「経路：予約サイトB、プラン：SP24A（版：2026年8月）、予約日：2026-08-14、宿泊日：2026-10-08、大人2名・子供1名（小学生）、1泊。質問の種類：取消・変更。前日の取消の扱いと、子供1名だけ減らす場合の扱いを教えてください」のように、予約の条件を先に並べ、従業員の質問の文を最後に足します。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、チャットと記録に渡します。

{
  "inquiry_id": "",
  "session_id": "",
  "staff_role": "reservation | front | room_attendant",
  "booking": { "booking_ref": "", "plan_code": "", "plan_version": "", "channel": "", "booked_on": "", "stay_date": "", "adults": 0, "children": 0, "nights": 0 },
  "category": "cancel_change | charge | meal | house_rule | other",
  "status": "answered | escalated | skipped",
  "escalate_reason": "refusal_or_termination | waiver_request | complaint | not_in_documents | version_mismatch | skipped | user_request | none",
  "answer_text": "",
  "cancel_rate": { "notice_band": "", "rate_percent": null, "source_row": "" },
  "refs": [ { "doc_type": "plan | terms | house_rules | qa", "title": "", "article": "", "version": "", "uri": "" } ],
  "feedback": "resolved | escalated_after | wrong | none"
}

1つ目の理由は、booking を回答と一緒に残せることです。 責任者へ回すとき、引いた予約の条件がそのまま渡るので、責任者は予約システムを開き直さずに判断に入れます。 宿泊客と行き違いが起きたときも、どの版の条件で答えたかが分かります。

2つ目は、cancel_rate を回答の文と分けられることです。 率は表から引いた数値で、source_row に表の行を残します。回答の文の中に数字が出てきたら、中継プログラムが表の率と照らし、食い違えば回答を出さずに回します。 モデルが文の中で率を作ったときの歯止めです。

3つ目は、escalate_reason で回った理由を数えられることです。 not_in_documents が多い話題は利用規則の書き足しが要り、waiver_request が多い時期は、天候のときの取消料の扱いを先に決めておく材料になります。

システムへ連携する

予約システムには、書き込みません。 取消や人数の変更を受けるのは従業員で、チャットが出すのは決まりの案内までです。 書き込みを足すと、案内の誤りがそのまま予約と料金に入ります。

予約システムの照会は、照会のAPIがあればそれを使い、無ければ定時に書き出した予約の一覧を読む形にします。 この部分は製品に合わせた個別の実装が必要です。

人が確認する

従業員は、回答を読んだあと、根拠の条文とプランの条件を画面で確かめてから宿泊客に伝えます。 画面には、回答の上に引いた予約の条件（経路・プラン・版・人数）を必ず並べます。

1. 予約の条件が合っているかを見る … 経路とプランが、宿泊客の話と食い違っていないかを確かめます
2. 根拠の順を見る … プランの条件で答えているか、約款だけで答えていないかを見ます
3. 評価を付ける … 解決した／責任者へ回した／誤りを選びます

1番目を軽く見ないでください。 宿泊客が「自社サイトで取った」と思っていても、実際は予約サイト経由ということがあります。取消料の率は経路で変わるため、画面に出た経路を宿泊客に伝えて確かめます。

責任者は、回ってきた質問だけを見ます。 判断したら、その判断を回答集に足すかを、週に一度まとめて見直します。 天候のときの扱いのように何度も同じ判断をしているものは、支配人と決めてプランの条件か利用規則に書き足します。

目標は、540件をならして1件4分です。 チャットで解決した質問の確認と、回ってきた質問を責任者が判断する時間の平均です。

例外に対処する

4行目と5行目は、運用の約束として全員に伝えておきます。 モデル宿泊約款は、宿泊を断ったときや契約を解除したときに、宿泊客がその理由の説明を求められるとしています（第5条の2、第7条の2）。説明できるのは判断した人だけです。

記録を残す

• 質問の文、選んだ聞き返しの値、日時、従業員の所属
• 引いた予約の条件（経路・プラン・版・人数・泊数）。宿泊客の氏名は残さない
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（回答、出典、根拠のスコア、回答しなかった理由）
• 表から引いた取消料の率と、その行
• 回す・回さないの判定と、その理由、責任者が最終的に答えた内容
• そのとき効いていたプランの条件と約款の版

最後の行は、「あのとき無料と言われた」という申し出に、当時の版の条件と返した回答を並べて確かめるためのものです。