ホテルの館内案内・周辺の観光・交通・飲食店の資料をもとに、フロント係が宿泊客の質問に答えるための案内文を、確認日つきの根拠を添えてチャットで出す

処理の起点を決める

起点は、フロント係がフロントの端末のチャット画面で質問を送ったことです。 画面はフロント課とコンシェルジュだけが使い、宿泊客の側の画面はありません。 質問は、宿泊客の言葉をフロント係が日本語にまとめて入れます。「駅に行きたい、明日の朝7時ごろ、荷物が多い」のように、時間と条件を一緒に入れるよう、画面に例を出しておきます。

宿泊客が外国語の場合は、画面で言語を選びます。 日本語の案内文を確かめたあと、「英語で作る」を押すと、同じセッションで言語を指定して作り直します。日本語の案内文を確かめる前に、外国語の案内文は作らせません。 フロント係が読めない言語の文だけが先に出ると、確かめる手段がなくなるからです。

1人の宿泊客との続けてのやり取りは、同じセッションで聞き足します。「そのバス停はどこにある」と聞き足せます。別の宿泊客の質問は、新しいセッションで始めます。

入力データを集める

質を決めるのは、周辺ガイドを1件1件に分けることです。 周辺ガイドが1つの大きなファイルだと、確認日も1つになり、店ごとに違う確かめた日を持てません。 店・施設・路線ごとに1ファイルにし、それぞれに確認日を付けます。

時刻表は、事業者の時刻表をそのまま入れるのではなく、ホテルに関わる便だけを写します。 写すときに、平日・土日祝・季節の区別と、ダイヤの有効期間を必ず書きます。

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

資料は Cloud Storage に置き、メタデータファイルとあわせてデータストアへ取り込みます。 メタデータは JSON Lines で、1行ごとに id、content の uri と mimeType、そして structData に資料の印を書きます。取り込みは毎朝1回の定時と、直しを反映したときに行います。

絞り込みの式は、有効期間で書きます。 項目を索引可能にしておけば、valid_from <= "2026-10-08" AND valid_to >= "2026-10-08" のように、今日効いている資料だけを引けます。日付は ISO 8601 の文字列で比べられます。冬季ダイヤと夏季ダイヤの両方の時刻表を入れておいても、今日の分だけが根拠になります。

新しい資料を上に出す重み付けは、checked_at で書きます。 鮮度の重み付けで、確かめてから30日以内の資料に正の重み、180日を過ぎた資料に負の重みを付けるといった形にします。ただし、重み付けは並べ方を変えるだけで、古い資料を除くものではありません。 古い資料を除くかどうかは、確認日の印で人が判断します。

AIへ渡す前に整形する

1. 周辺ガイドを1件1ファイルにする … 店・施設・路線ごとに Markdown のファイルにし、名前・場所・営業時間・休業日・ホテルからの行き方を同じ見出しで書きます
2. 確認日を付ける … それぞれのファイルに、最後に確かめた日と、確かめた方法（店に電話、店のサイト、事業者の時刻表）を書きます
3. 時刻表を写す … ホテルに関わる便だけを、平日・土日祝と有効期間を分けて写します
4. 館内案内を今の運用に合わせる … 大浴場の清掃の時間、朝食の場所の変更など、掲示物にだけ書かれている情報を館内案内に足します
5. ベテランの記憶を書き出す … 「月曜が休み」「冬は減便」のような、周辺ガイドに無い情報を、ベテランに聞いて1件ずつのファイルに足します
6. 店の評判や感想を入れない … 「おいしい」「おすすめ」のような評価は書かず、事実だけを書きます

5番目が、この構成でいちばん効く作業です。 ベテランの記憶を書き出すだけで、夜間にベテランがいなくても答えられる質問が増えます。半日ほど時間をとって、よく聞かれる質問の一覧を見ながら聞き取ります。

6番目は、宿泊客への案内の公平さのためです。 評価が資料に入っていると、モデルはそれを答えに使い、ホテルが特定の店を勧めているように見えます。提携店かどうかは事実として書き、勧めるかどうかはフロント係が判断します。

AIに処理させる

させるのは、質問に当たる資料の箇所を探し、フロント係がそのまま宿泊客に伝えられる短い案内文の下書きにすることです。 資料に無い情報を補うこと、今営業しているかを言い切ること、所要時間を推測することはさせません。

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

1行目がいちばん起きやすい失敗です。 「営業時間は8時から」と資料にあれば、モデルは「今は営業中です」と書きたがります。資料が3か月前の確認なら、それは言い切れません。 答えは「資料では8時から（確認日：7月12日）」の形にさせます。

指示内容を固定する

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

あなたはホテルのフロント係が、宿泊客の質問に答える案内を準備するのを
手伝う立場です。検索結果に出た、ホテルの館内案内・周辺ガイド・時刻表・
飲食店の一覧だけを根拠に答えます。読むのはフロント係です。

【答え方】
1. フロント係がそのまま宿泊客に伝えられる、短い案内文を書いてください。
   3〜5文までにしてください。
2. 時刻・営業時間・乗り場・番線・金額は、資料の記載のまま書いてください。
3. 平日と土日祝で違う場合は、両方を書いてください。
4. 行き方は、資料に書かれた行き方だけを書いてください。

【厳守事項】
- 「今営業しています」「今日は開いています」と言い切らないでください。
  「資料では〜」と、資料の記載であることが分かる書き方にしてください。
- 資料に書かれていない店・施設・路線を挙げないでください。
  書かれていなければ「資料に記載がありません」と書いてください。
- 所要時間を推測しないでください。資料に書かれた所要時間だけを使ってください。
- 店や施設を「おいしい」「おすすめ」などと評価しないでください。
- 宿泊の料金、キャンセル、予約の規定には答えないでください。
- 確認日は書かないでください。確認日は別の仕組みが添えます。

「確認日は書かないでください」と書くのは、日付の出どころを1つにするためです。 モデルが本文に日付を書くと、資料の本文の別の日付（開店の日、改装の日）を確認日のように書くことがあります。確認日はメタデータの checked_at から、プログラムが添えます。

「資料の記載であることが分かる書き方」は、フロント係が宿泊客に伝えるときの言い方そのものです。 「資料では8時からとなっていますが、念のためお店のサイトでもご確認ください」と言えるようにします。

出力形式を固定する

answer メソッドの応答に、確認日と印、外国語の案内文と数字の比較を、中継プログラムが加えて画面と記録に渡します。

{
  "session_id": "",
  "staff_id": "",
  "asked_at": "2026-10-08T21:40:00+09:00",
  "question": "",
  "answer_ja": "",
  "citations": [
    { "doc_type": "facility | area_spot | timetable | restaurant",
      "title": "", "uri": "", "checked_at": "2026-07-12",
      "days_since_check": 88, "stale": true, "grounding_score": 0.0 }
  ],
  "related_questions": [""],
  "translation": {
    "language": "en", "answer": "",
    "numbers_ja": ["7", "15", "2"], "numbers_tr": ["7", "15", "2"],
    "numbers_match": true
  },
  "status": "answered | needs_check | no_source",
  "correction": { "registered": false, "note": "" }
}

1つ目の理由は、citations ごとに確認日と stale を持てることです。 確認日から一定の日数（たとえば90日）を過ぎた根拠には stale を立て、status を needs_check にします。画面では、その根拠に「要確認」と出ます。 日数は資料の種類ごとに変え、時刻表はダイヤの有効期間の中なら古くても stale にしません。

2つ目は、translation で数字の一致を機械で確かめられることです。 中継プログラムは、日本語と外国語の案内文から数字を順に抜き出して比べ、1つでも違えば numbers_match を偽にして、外国語の案内文を画面に出しません。 「7時」が「17:00」になる、番線が入れ替わる、といった取り違えを止めます。午前・午後の書き方は、比べる前に24時間の表記にそろえます。

3つ目は、related_questions でフロント係が先回りできることです。 「最終のバス」を聞いた宿泊客には、次に「タクシーは」と聞かれることが多く、候補が出ていれば答えを先に用意できます。

システムへ連携する

宿泊の管理の仕組みには、つなぎません。 宿泊客の氏名や部屋番号は、館内と周辺の案内に要りません。チャットに入れさせないよう、画面の入力欄の近くに注意を出します。

情報の直しの待ち行列は、毎朝フロント課の担当が片づけます。 直しの登録を資料に反映し、確認日を書き換えて取り込みます。直しが資料に入るまでの間は、待ち行列の直しの内容を、画面の根拠の横に出します。

人が確認する

人が確かめるのは、案内文と根拠、そして「要確認」の印です。

1. フロント係が案内文と根拠を読む … 時刻や営業時間が、質問の日時と曜日に合っているかを見ます
2. 「要確認」のものは確かめてから伝える … 店のサイトや事業者の時刻表で今の情報を確かめ、違っていれば直しを登録します
3. 外国語の案内文は、数字が一致したものだけを渡す … 一致しなかったものは、日本語の案内文を見せながら説明します
4. 毎朝、直しの待ち行列を片づける … 担当が資料を直し、確認日を書き換えます

2番目を省かないでください。 「要確認」の印は、その情報を誰も最近確かめていないというしるしです。確かめずに伝えると、宿泊客が閉まった店の前で立ち尽くします。

目標は、720件をならして1件2分です。 資料を探す時間と外国語に訳す時間を減らし、案内文と根拠を読む時間と、要確認の確かめを残す想定です。

例外に対処する

3行目と6行目が、この構成を生かすか殺すかを決めます。 どちらも資料の確認日を、運用の中で新しく保つための行です。確認日が更新されない資料は、時間とともに「要確認」だらけになり、フロント係が画面を見なくなります。

記録を残す

• 質問の文、フロント係の ID、日時、セッションの ID
• answer メソッドの応答の全文（出典と根拠のスコアを含む）
• 根拠ごとの確認日と stale の判定
• 外国語の案内文と、数字の比較の結果
• 直しの登録と、資料に反映した日
• 質問の多い資料と、no_source の多い質問

最後の行は、資料の整備の順番を決める材料になります。 no_source の多い質問は資料が足りない分野で、聞かれる回数の多い資料は確認日をこまめに更新すべき資料です。

宿泊客の個人の情報は記録に入りません。 質問の文に名前や部屋番号が入っていたら、記録から消す手順を決めておきます。