代理店からの在庫・納期の問い合わせに、チャットで一次回答する

処理の起点を決める

代理店がチャットに質問を投稿したときを起点にします。代理店ポータルにログインした状態で使うため、どの取引先からの質問かが分かります。

取引先が分かることが、この構成の前提です。 取引先によって取扱商品や取引条件が違うため、誰からの質問かが分からないと答えられません。ログインを挟まない構成（公開のチャット）は、この業務には向きません。

電話での問い合わせをすぐに置き換えることは考えません。まずチャットを用意し、電話の前にチャットで解決する代理店を増やしていく進め方にします。

入力データを集める

3番目の型番マスタが、この構成の要です。 旧型番と現行型番の対応が整理されていないと、質問の半分に答えられません。ここが無い会社では、まず型番マスタを作ることが最初の仕事になります。

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

型番の正規化： 質問文から型番らしき文字列を取り出し、型番マスタと照合します。ハイフンの有無、英数字の全角半角、末尾の色記号の欠落を吸収します。候補が複数ある場合は、確定せずに選んでもらいます。

在庫・納期： 基幹システムのAPI、または照会用のビューへ問い合わせます。返すのは「現在の在庫数」ではなく、「出荷可能数」と「出荷可能日」にします。在庫が10台あっても、9台が引き当て済みなら答えは1台です。

資料： カタログ・図面・お知らせを検索基盤に取り込みます。検索は、キーワード検索とベクトル検索を同時に実行し、結果を統合する方式にします。型番のような文字列そのものはキーワード検索が、「お湯の出が悪いときに見る資料」のような言い換えの多い質問はベクトル検索が拾います。統合後の並べ替えでは、初期結果の上位50件が対象になるため、型番での絞り込みを先にかけて、候補を50件の中に入れておきます。

AIへ渡す前に整形する

1. 型番の取り出しと正規化 … 表記ゆれを吸収し、現行型番に寄せます
2. 廃番の判定 … 廃番であれば、後継品を型番マスタから取ります
3. 質問の種類の判定 … 在庫・納期／仕様・後継品／価格・特別対応／クレームの4つに分けます
4. 取引先の取扱範囲の確認 … その代理店が扱えない商品の在庫を答えないようにします
5. 在庫データの取得時刻の記録 … 回答文に「◯時◯分時点」と入れるために必要です

5番を省くと、「在庫ありと言われたのに翌日には無かった」という食い違いが起きます。時刻を明示することが、この業務での約束の線引きになります。

AIに処理させる

在庫数や納期をAIに計算させないでください。 「10台あるので3営業日で出せます」といった推論をさせず、基幹システムが返した値をそのまま文章に入れます。

指示内容を固定する

あなたは住宅設備メーカーの営業事務です。
代理店からの質問に、下の照会結果と検索結果だけを使って回答してください。

【厳守事項】
- 在庫数、出荷可能日は、照会結果の値をそのまま使ってください。
  計算し直したり、丸めたりしないでください。
- 照会結果に無いことを答えないでください。
  「おそらく来週には入ります」といった見込みを書かないでください。
- 在庫と納期の回答には、必ず「{取得時刻}時点の情報です」と添え、
  「正式な納期は担当営業からの回答をご確認ください」と書いてください。
- 価格、値引き、特別対応、返品、クレームに関する質問には回答せず、
  handover を true にして、担当営業へお繋ぎする旨だけを返してください。
- 仕様・取付条件の回答には、参照した資料名とページを示してください。
  資料に無いことは「資料で確認できません」と答えてください。
- 型番が特定できない場合は、候補を並べて選んでもらってください。
  1つに決め打ちしないでください。
- 廃番品については、後継品の型番をマスタの値で示し、
  仕様が同一であるとは書かないでください。

【取引先】
{dealer_code} / 取扱区分: {dealer_category}

【質問】
{question}

【型番の候補】
{model_candidates}

【基幹システムの照会結果（{取得時刻}時点）】
{stock_result}

【資料の検索結果】
{retrieved_docs}

「仕様が同一であるとは書かない」の一文は、後継品の案内で効きます。 後継品は寸法や接続口径が変わっていることがあり、「同じものです」と答えると現場で付かない事態になります。

出力形式を固定する

{
  "dealer_code": "",
  "question_type": "在庫・納期 | 仕様・後継品 | 価格・特別対応 | その他",
  "model_code": null,
  "model_candidates": [],
  "answer": "",
  "stock_snapshot": {
    "available_qty": 0,
    "shippable_date": "",
    "retrieved_at": ""
  },
  "citations": [
    { "doc": "", "page": "", "quote": "" }
  ],
  "handover": false,
  "handover_reason": "",
  "answered": true
}

stock_snapshot を回答と別に持たせるのは、後から「その時点で何と答えたか」を確認するためです。食い違いが起きたとき、照会時刻と値が残っていれば説明ができます。

answered が false のものを集計すると、この仕組みで答えられていない質問の傾向が分かります。

システムへ連携する

基幹システムへの書き込みは行いません。 受注の登録や引き当ては、この構成の対象外です。チャットから在庫を引き当てられる設計にすると、誤操作が出荷に直結します。

人が確認する

質問の種類によって扱いを分けます。

営業事務は、引き継がれたものと答えられなかったものだけを見ます。 すべてのやり取りを人が確認する運用にすると、工数が減りません。その代わり、週次で回答の抜き取り確認を行います。

例外に対処する

記録を残す

• 質問と回答の全文、取引先、日時
• 型番の特定結果（候補から選ばれたものを含む）
• 基幹システムの照会値と照会時刻
• 参照した資料と箇所
• 引き継いだ質問と、その後の対応
• 答えられなかった質問

3番目を残すことが、この業務ではとくに重要です。 在庫と納期は変わる情報なので、「いつ時点の値を返したか」が残っていないと、後から検証できません。

6番目は毎週見てください。 答えられなかった質問は、型番マスタの不備か、資料の不足か、そもそも人が判断すべき質問かのどれかです。1か月ためると改善の材料になります。