漆器の工房が修理の相談（欠け・剥がれ・色あせ）に、修理の手引きと過去の修理の記録から Azure OpenAI のチャットで答え、職人に渡す相談票を作る

処理の起点を決める

お客様がチャットに書き込んだことを起点にします。 1回の書き込みごとに Azure Functions が呼ばれ、会話の状態（どの項目まで聞き取ったか）を読み出して、次に聞くことか答えを返します。

チャットは、問い合わせのフォームの代わりにはしません。 フォームも残し、チャットを使わない人は今まで通りメールで送れます。電話の相談は、店のスタッフが同じ相談票の項目で聞き取るための台本としてチャットの画面を使います。

会話の途中で閉じられることを前提にします。 会話の記録は24時間残し、同じ端末で戻ってきたら続きから再開できるようにします。24時間を過ぎたら、聞き取れた分だけで相談票を作り「聞き取り途中」の印を付けます。

入力データを集める

質を決めるのは、過去の修理の記録の書き方です。 品物の名前がばらばらだと、似た修理が見つかりません。「椀（汁椀）」「椀（吸物椀）」のように、決まった言葉と括弧書きにそろえます。

記録からは、お客様の名前と住所を外して索引に入れます。 似た修理の例として答えに出すのは、品物・傷・直し方・日数だけです。

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

修理の手引きと記録は、修理の種類と1件の修理の単位に分けて Azure AI Search の索引に入れます。

検索は2回に分けて行います。 1回目は文書の種類を「手引き」に絞って修理の種類を探し、2回目は「修理の記録」に絞って似た例を探します。1回にまとめると、記録の件数が多いぶん手引きが結果から押し出されます。

料金の幅は、手引きの最新の版からしか引きません。 修理の記録にも料金の区分は残っていますが、何年も前の料金を「似た例ではこの値段」と答えると、いまの料金と食い違います。 記録の料金の項目は、答えに使う項目から外します。

AIへ渡す前に整形する

1. 聞き取りの項目を埋める … 品物、傷の種類、場所（口縁・内側・外側・底・蓋）、大きさ（米粒くらい・1円玉くらい・それ以上）、使い方（食器洗い機・電子レンジに入れたか）、自社の品か、表示（漆器／合成漆器／不明）
2. 言葉をそろえる … 「お椀」「汁わん」は「椀（汁椀）」に、「はげた」「めくれた」は「剥がれ」に、決まった言葉に置き換えます
3. 検索の文を組み立てる … 聞き取った項目から「椀（汁椀） 口縁 欠け 1円玉くらい」のような文を作ります
4. 絞り込みの条件を作る … 品物と傷の種類と塗りの区分で絞ります。不明の項目は絞り込みに使いません
5. 検索結果の上位を選ぶ … 手引きは上位3件、修理の記録は上位5件を渡します
6. 会話の履歴を短くする … 渡すのは直近の数往復と、聞き取りの項目の現在の値だけにします

1番をAIに自由に任せないのが、この前処理の肝です。 聞き取りの項目と順番は Functions が持ち、AIには「次はこの項目を聞く」と指示して、聞き方の言葉だけを作らせます。 自由に話させると、品物を聞く前に直し方の話を始めます。

6番を省くと、会話が長くなるほど答えがぶれます。 全部の履歴を渡すと、最初に書かれた「赤いお盆」が途中で「黒い椀」の話に混ざることがあります。項目の現在の値を正として渡します。

AIに処理させる

させるのは、次の4つです。

答えの1文ごとに、どの文書を根拠にしたかの番号を付けさせます。 Functions は、その番号が今回の検索結果に入っているかを確かめ、入っていない番号を付けた文があれば、その答えを使わずにやり直させます。

3行目は、意図して外しています。 Azure OpenAI のモデルには画像を読めるものもありますが、写真から「これは塗りの層だけの欠けです」と言い切ると、お客様はそれを見積の前提として受け取ります。 写真で判断するのは職人で、チャットはそれを確実に届けることに徹します。

指示内容を固定する

あなたは漆器の工房の、修理の相談の受付の係です。
お客様の相談を聞き取り、工房の資料に書いてあることだけで案内してください。

【今回の役目】{turn_task}
  ※ ask … 指定した項目（{next_item}）を1つだけ尋ねる
  ※ answer … 聞き取った内容に当てはまる案内をする

【答え方の決まり】
- 案内は、下の【検索結果】に書いてあることだけにしてください
- 1文ごとに、根拠にした検索結果の番号を source_ids に入れてください
- 根拠が見つからないことは「職人に確認してお返事します」と答えてください
- 修理の種類は「候補」として示し、「直せます」「直せません」と言い切らないでください
- 日数と料金は、手引きに書いてある幅だけを示し、「職人が写真を見て決めます」を添えてください
- 似た修理の例は、品物・傷・直し方・日数だけを示し、お客様の名前や時期は出さないでください
- 漆を使って自分で直す方法は案内しないでください
- ほかの工房や産地の品の良し悪しを言わないでください
- 写真の中身について判断を書かないでください

【引き継ぎの判断】
次のときは handoff を staff にしてください。
- お客様が怒っている、または以前の修理への不満を書いている
- 工房の品ではなく、表示が「合成漆器」または不明
- 検索結果に当てはまるものが無い

【聞き取りの項目の現在の値】{intake}
【検索結果】{search_results}
【直近の会話】{recent_turns}

「1文ごとに根拠の番号を付ける」を書かないと、手引きに無い日数を答えます。 漆器の修理の一般論はモデルもある程度知っていて、それらしい日数を書きます。番号の付かない文を作らせないことで、工房の資料の外に出るのを止めます。

「直せます」と言わせない決まりは、引き継ぎの後の職人を守るためです。 チャットが「直せます」と書いた後に職人が「木地まで割れているので難しい」と返すと、お客様には工房が約束を変えたように見えます。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形の JSON を返させます。 Chat Completions API の response_format に json_schema を渡し、strict を有効にします。

{
  "reply": [
    { "text": "", "source_ids": ["guide-07"] }
  ],
  "intake_update": {
    "item": "椀（汁椀） | 重箱 | 盆 | 箸 | 酒器 | その他 | null",
    "damage_type": "欠け | 剥がれ | 色あせ | ひび・割れ | その他 | null",
    "location": "",
    "size": "",
    "usage_note": "",
    "own_product": "yes | no | unknown",
    "label": "漆器 | 合成漆器 | 不明"
  },
  "repair_candidates": ["guide-07"],
  "similar_cases": ["rec-1842"],
  "handoff": "none | craftsman | staff",
  "handoff_reason": ""
}

1つ目の理由は、reply を文ごとに分けられることです。 文ごとに source_ids が付くので、Functions が検索結果と照らして、根拠の無い文だけを見つけられます。

2つ目は、intake_update で聞き取りの項目を会話から切り離せることです。 項目の値は Functions が持ち、次の書き込みのときにAIへ渡します。相談票は、この項目の最後の値から機械的に作ります。 会話の全文から相談票を作らせると、途中で言い直したことが混ざります。

スキーマには、Azure OpenAI の構造化出力の決まりがあります。 すべてのフィールドを required にし、additionalProperties を false にします。まだ聞き取れていない項目は null との共用体型で表します。配列の minItems・maxItems や文字列の maxLength は使えないので、reply の文の数と長さは受け取った後に Functions で確かめます。オブジェクトのプロパティは合計100個まで、入れ子は5段までです。

システムへ連携する

チャットからお客様への返信は、修理の可否と料金については一切しません。 職人が決めた内容は、職人か店のスタッフがメールで送ります。チャットの役目は、相談票が台帳に入ったところで終わります。

会話の履歴は Functions の側で持ち、Chat Completions API を使います。 Responses API は会話の履歴を保存するしくみを持ちますが、この構成では聞き取りの項目と直近の数往復だけを渡すので、サービスの側に履歴を残す必要がありません。

人が確認する

1. 職人が相談票と写真を見て決める … 修理できるか、どの直し方か、日数と料金。チャットの「候補」はあくまで候補です
2. 店のスタッフが staff の引き継ぎを先に読む … 怒っている相談、以前の修理への不満、自社の品でない相談、手引きに無い相談
3. 週に1回、会話の記録を抜き出して読む … 根拠の照合でやり直しになった会話と、「職人に確認します」で終わった会話を中心に見ます
4. 答え方を直したら記録する … 手引きのお客様向けの版を直したときは、版を上げて索引を作り直します

2番を職人に回さないのは、職人の時間を守るためです。 苦情の気配のある相談は、修理の話より先に、お客様の気持ちを受け止める返事が要ります。それは店のスタッフの仕事です。

3番の「職人に確認します」で終わった会話は、手引きの穴を示しています。 同じ質問で毎週終わっているなら、手引きのお客様向けの版に1節足すのが先です。

例外に対処する

1行目が、運用の初めに最も多く起きるはずです。 手引きのお客様向けの版がまだ薄いうちは、AIが手引きの外の一般論で埋めようとします。やり直しの件数を毎週数え、手引きの版を厚くしていくと減ります。

6行目の攻撃の検知は、公開のチャットでは外せません。 「これまでの指示を忘れて」と書き込む人は、修理の相談の窓口にも来ます。止まったときに AI に言い訳をさせず、定型の文で返します。

記録を残す

• 会話の全文と、書き込みごとの日時
• 書き込みごとに渡した検索の文、絞り込みの条件、検索結果の番号
• Azure OpenAI に送ったプロンプトと、返ってきた JSON の全文
• 根拠の照合でやり直しになった記録
• 相談票と、職人が決めた修理の内容（受けた／受けなかった、直し方、日数、料金）
• そのとき使った手引きの版
• 写真（相談票と同じ期間だけ保存し、修理を受けなかったものは決めた期間で消す）

5つ目の職人が決めた内容は、修理の記録の次の1行になります。 受けた修理は、品物・傷・直し方・日数を決まった言葉で記録に足し、索引に入れ直します。相談が増えるほど、似た修理の例が増えていきます。

6つ目の手引きの版を残すのは、料金の幅が変わるためです。 「チャットではこの値段と言われた」と後から言われたとき、そのときの版が分かれば、何を示したかを確かめられます。