予約前の問い合わせに多言語のチャットで一次回答する

処理の起点を決める

入口ごとにメッセージを受け取った時点が起点になります。

LINE公式アカウントの場合、利用者がメッセージを送ると、LINEプラットフォームから、Webhookイベントオブジェクトを含むHTTP POSTリクエストが、こちらのサーバーへ送られます。イベントには、送信元の情報、メッセージの内容、返信に使う応答トークン（replyToken）、重複検知用のIDなどが含まれます。公開ドキュメントでは、受け取ったリクエストが本当にLINEプラットフォームから送られたものかを署名で検証してから処理すること、そして処理は非同期で行うことが案内されています。ここは省かないでください。

自社サイトのチャットは、画面に置いた入力欄から自社のサーバーへ送る形になります。この部分は利用環境に応じた個別実装が必要です。

メールと予約サイトのメッセージは、最初の対象から外します。まず、その場で返せる入口だけで始めます。

入力データを集める

料金表そのものと空室情報は入れません。 理由は「AIに何をさせるのか」で書きます。

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

案内資料の検索： Azure AI Search のハイブリッド検索を使います。公開ドキュメントによると、ハイブリッド検索は、全文検索とベクトル検索を1回のリクエストで並行して実行し、Reciprocal Rank Fusion（RRF） という方式で両方の結果を統合して1つの順位にまとめるものです。全文検索はBM25、ベクトル検索はHNSWなどの手法を使い、それぞれ得意が異なります。

なぜ両方が要るのかというと、言い回しの違いに強いのがベクトル検索、固有名詞や記号に強いのが全文検索だからです。「お風呂は何時まで」と「大浴場 利用時間」は文字が一致しませんが、意味は同じです。一方で、部屋タイプの名称やプラン名は、文字が一致することが重要になります。

多言語についても、公開ドキュメントに記載があります。埋め込みの空間に多言語の内容が含まれていれば、言語アナライザーや翻訳を用意しなくても、ベクトル検索で該当箇所を見つけられます。 つまり、資料が日本語のままでも、英語の質問から日本語の該当箇所を引ける構成にできます。

さらに、セマンティックランカーを有効にすると、最初の検索結果を並べ替えて関連性を上げられます。これは任意です。

過去の回答： 受信箱から直近1年分の返信を抽出し、質問と回答の組にして資料に加えます。ただし、個人情報を含む部分は落としてから入れます。

AIへ渡す前に整形する

1. 個人情報の切り離し … 氏名・電話番号・予約番号・メールアドレスが本文に書かれることがあります。検索と回答生成へ渡す前に伏せ字にし、原文は別に保管します
2. 会話の履歴の整理 … 直前の数往復だけを渡します。全部渡すと、古い話題に引っ張られます
3. 資料の分割 … 案内資料を見出し単位に分け、それぞれに番号（faq-018 のような識別子）を振ります。この番号が、後で根拠を示すために必要になります
4. 短い相づちの除外 … 「ありがとう」「了解しました」だけのメッセージは、検索も生成もせずに定型で返します

AIに処理させる

検索と生成で役割を分けます。

検索基盤にさせること： 質問に関係する資料の箇所を見つけること。ここは生成AIにさせません。

生成AIにさせること：

回答の言語については、Claudeの公開ドキュメントに、会話から言語を推測させるのではなく、システムプロンプトで返信する言語を明示するほうが確実だという案内があります。利用者が言語を選べる作りなら、その選択をシステムプロンプトへ差し込みます。

多言語での能力についても公開の評価があり、英語を100％としたときの相対値として、日本語・中国語（簡体字）・韓国語などが公表されています。ただし、これは自社の案内文で測った数字ではありません。 自社の資料と実際の質問で確かめてください。

答えさせない質問を、先に決めます。

これらは「回答しない」のではなく、「予約システムの画面をご案内したうえで、担当者からご連絡します」と返して人へ渡します。

指示内容を固定する

あなたは宿泊施設の予約前の問い合わせに一次回答する案内係です。

【厳守事項】
- 回答は、与えられた【資料】に書かれている内容だけで作ってください。
  資料に無いことは、推測せず、handoff を true にしてください。
- 使った資料の番号を sources に必ず入れてください。
  番号を出せない内容は回答に含めないでください。
- 回答は、利用者が書いた言語（{user_language}）で書いてください。
  同時に、管理用の日本語の要約を summary_ja に書いてください。
- 次のいずれかに当たる質問には、内容を答えないでください。
  handoff を true にし、handoff_reason に該当する区分を入れてください。
    (1) 空室の有無  (2) 料金の確定額  (3) 予約の確定・変更・取消
    (4) 食物アレルギーへの対応可否  (5) 介助・バリアフリーの可否
    (6) 団体・貸切・特別な手配
- 「できます」「対応しています」と断定するのは、資料にその記載がある場合だけです。
  記載が条件付きなら、条件も必ず書いてください。
- 体調不良・事故・危険に関する内容が含まれる場合は、
  回答を作らず urgent を true にしてください。

【資料（検索で見つかった箇所）】
{retrieved_documents}

【直前のやり取り】
{conversation_history}

【今回の質問】
{user_message}

「資料に無いことは推測せず、人へ渡す」の1行が、この構成の安全弁です。 宿泊や飲食の案内は、断定した一言が当日の期待になります。「できます」と答えて当日できなければ、その場で対応することになります。

出力形式を固定する

{
  "answer": "",
  "answer_language": "ja | en | zh-Hant | zh-Hans | ko | other",
  "summary_ja": "",
  "sources": ["faq-018", "access-03"],
  "handoff": false,
  "handoff_reason": "",
  "urgent": false,
  "category": "",
  "unanswered": false
}

sources が空の回答は、送信せずに人へ回します。 根拠を示せない回答は、資料に書いていないことを書いた回答だからです。ここを機械的に止めることで、誤案内の大半を防げます。

category は、後で「どの質問が多いか」を集計するために付けます。unanswered は、資料に無くて答えられなかったことを示します。この2つが、案内資料を育てるための材料になります。

システムへ連携する

回答は、質問が届いた入口へ返します。

LINEの場合は、Webhookイベントで受け取った応答トークン（replyToken）を使って応答メッセージを送ります。公開ドキュメントによると、1回のリクエストで最大5つのメッセージオブジェクトを送れます。 回答本文と、予約ページへのリンクを分けて送るといった使い方ができます。

引き継ぎになった場合は、既存の問い合わせ管理ツールへ、次の内容を付けて起票します。

• 原文（利用者が書いた言語のまま）
• 日本語の要約
• 引き継ぎの理由（どの区分に当たったか）
• 検索で見つかった資料の箇所（担当者の下調べを省くため）

予約システムには書き込みません。 この構成は、予約データを一切変更しません。空室や料金を見せたい場合も、予約ページへのリンクを返すだけにします。リンクを返すのと、数字を答えるのは別のことです。

人が確認する

引き継ぎ条件に当たるものは、人が答えます。事前の確認です。

それ以外の回答は、送信後に人が見ます。事後の確認です。 全件を送信前に人が見る作りにすると、営業時間外に返せなくなり、この構成の目的が消えます。

事後の確認は次のように行います。

• 毎朝、前日のやり取りを担当者が一覧で見る（1件10秒程度）
• sources の資料が質問に合っていないものを拾う
• 利用者が同じことを2回聞いているやり取り（伝わっていない印）を拾う
• 拾ったものを資料の修正に回す

運用開始から1か月は、全件を見てください。 誤りの傾向はこの期間に出ます。件数が安定したら、抽出に切り替えます。

例外に対処する

記録を残す

• やり取りの全文（利用者の言語のまま）と、日本語の要約
• 検索で返った資料の番号と、生成AIが使った番号
• 引き継ぎの有無と理由
• 事後確認で「誤り」と判定されたやり取り
• 資料に無くて答えられなかった質問（unanswered）

最後の項目が、いちばん価値があります。答えられなかった質問の一覧は、そのまま案内資料に足すべき項目の一覧です。 月に一度これを見て資料を直すと、翌月の引き継ぎ率が下がります。

保存期間と閲覧できる人の範囲は、個人情報の扱いとして先に決めてください。