引越しの見積り依頼をチャットで聞き取り、トラックと作業員数の概算と訪問見積りの要否を担当へ渡す

処理の起点を決める

客がチャットに1通送るたびに、Make のシナリオが1回動きます。 聞き取りの会話全体を1回の処理にするのではなく、1往復を1回の処理にします。 1回の処理でやることは、客の1通を受け取り、OpenAI API に渡し、返事を客の画面へ返し、そろった項目を記録することです。

チャットの入口は、フォームの送信直後の画面と確認メールに置きます。客がまだ家の中にいて、冷蔵庫を見に行ける時間のうちに始めてもらいます。

入口のURLには、フォームの受付番号を付けます。 チャットが始まるとき、Make はこの番号で見積り台帳を引き、予定日、市区町村、間取りを最初の入力として渡します。フォームで聞いたことを、チャットでもう一度聞かないためです。

会話の終わりもトリガーを持ちます。 すべての項目がそろってAIが ready を返したとき、または客が「あとで続けます」を選んだとき、台帳への書き込みと担当者への通知が動きます。 途中で画面を閉じた客のために、最後の1通から2時間たったら、そこまでの内容を「途中」として台帳に書く定時の処理も置きます。

入力データを集める

質を決めるのは、下の2つです。 聞く項目の一覧が無いと、AIは思いついた順に聞き、客によって聞く項目が変わります。 それでは第3章の（a）がそのまま残ります。

聞く項目の一覧は、経験の長い担当者の電話を1本ずつ書き起こして作ります。 家財の聞き方だけでなく、「トラックを止める場所」「前の道の幅」「エアコンの取り外し」のような、新人が聞き忘れる項目を拾うのが目的です。間取りごとに聞く家財を変え、最後に「ほかに大きな家具や家電はありますか」と1回だけ聞きます。

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

前の応答のIDは、チャット画面に持たせます。 客の画面が次の1通と一緒に送ってくれば、Make は受け取った値をそのまま使うだけで済みます。

換算点数の表は、AIに渡しません。 点数の計算は、聞き取りが終わってから Make の側で行います。AIには、何を聞くかだけを知らせます。 点数をAIに渡すと、会話の途中で「2トン車で足りそうです」と言い出す余地ができます。

AIへ渡す前に整形する

1. 受付番号の確認 … 見積り台帳に無い番号なら、チャットを始めずにフォームへ案内します
2. 二重の会話の確認 … 同じ受付番号で聞き取りが終わっていれば、「内容の追加・修正」として始めます
3. 客の1通の長さの確認 … 極端に長い文（家財の一覧を貼り付けたものなど）は、そのまま渡してかまいません。ただし上限の文字数を決め、超えたら分けて送るよう案内します
4. 個人情報の除去 … 客が電話番号や番地、カード番号のような数字の並びを書いたら、OpenAI API に渡す前に伏せ字にします。 番地は見積書に要りますが、チャットで聞く必要はありません
5. 写真の扱い … この構成では写真を受け取りません。写真が要ると判断した場合は、担当者から改めて依頼します

4番目を軽く見ないでください。 客が親切に番地まで書いてくることは珍しくありません。伏せたうえで、担当者が電話で確かめる項目として台帳に残します。

AIに処理させる

させるのは、聞く項目の一覧に沿って客に1問ずつ聞き、答えを決まった項目にそろえることです。

3行目がいちばん効きます。 客の「普通のサイズの冷蔵庫」は、人によって大きさがまったく違います。ドアの枚数で聞き直せば、客は見れば答えられます。 電話の上手な担当者の聞き直しを、例として指示文に書いておきます。

6行目が起きやすい失敗です。 「2LDKです」と聞いただけで、冷蔵庫、洗濯機、ダブルベッド、食器棚を埋めてしまうと、実際には無い家財で点数が膨らみます。 聞いていない項目は null のまま残させます。

指示内容を固定する

あなたは引越し会社の見積り受付で、客から家財と建物の条件を聞き取る係です。
料金の見積りはしません。担当者が見積書を作るための材料をそろえるのが仕事です。

【聞き方】
- 1回の返事で聞くのは1つだけにしてください。
- 下の【聞く項目の一覧】の順番に、まだ答えの無い項目を聞いてください。
- 選択肢のある項目は、選択肢を出してください。
- 客の答えが曖昧なときは、見れば答えられる質問に言い換えて聞き直してください。
  例：「普通の冷蔵庫」→「ドアは1枚、2枚、3枚以上のどれですか」
  例：「ベッドはある」→「シングル、セミダブル、ダブル以上のどれですか」
- 客が「わからない」と答えた項目は unknown とし、同じ項目を二度聞かないでください。

【厳守事項】
- 料金、料金の目安、トラックの大きさ、作業員の人数を言わないでください。
  聞かれたら「担当者から見積書でお伝えします」と答え、asked_questions に記録してください。
- 引越し日の空き状況を答えないでください。担当者に回してください。
- 訪問見積りをする・しないを約束しないでください。
- 客が答えていない項目を、間取りや他の答えから推測して埋めないでください。
  答えの無い項目は null のままにしてください。
- 番地、電話番号、カード番号を聞かないでください。書かれていても記録しないでください。
- ピアノ、金庫、美術品、骨董品、水槽、観葉植物の大きなもの、ペットが出てきたら、
  special_items に記録してください。運べるかどうかは答えないでください。
- 客の依頼が会社や店舗の移転だとわかったら、聞き取りを止め、
  handoff_reason に "business_move" と書いてください。
- すべての項目に答えか unknown が入ったら、status を ready にしてください。

【フォームで受け付けた内容】{form_data}
【聞く項目の一覧】{question_list}
【特別な扱いの家財の一覧】{special_list}

「料金を言わない」は、聞かれたときの答え方まで書きます。 禁じるだけだと、客に何度も聞かれたときに「一般的には数万円程度」と答えることがあります。答える文を決めておき、その質問を担当者に回す記録を残させます。

「間取りから推測しない」も同じです。 指示が無いと先回りして埋め、埋めた値は客が答えた値と区別がつきません。

出力形式を固定する

毎回の応答を、次の形のJSONで受け取ります。 Responses API の structured outputs で text.format に json_schema を指定し、strict を true にします。

{
  "reply_to_customer": "",
  "status": "collecting | ready | handoff",
  "handoff_reason": "",
  "origin": {
    "building_type": "detached | apartment | null",
    "floor": null,
    "elevator": "yes | no | unknown | null",
    "truck_parking": "front | nearby | far | unknown | null",
    "stair_width": "normal | narrow | unknown | null"
  },
  "destination": { "building_type": null, "floor": null, "elevator": null,
                   "truck_parking": null, "stair_width": null },
  "items": [ { "item": "fridge", "size": "large", "count": 1 } ],
  "boxes_estimate": null,
  "services": { "aircon_remove": null, "aircon_install": null, "disposal": null },
  "special_items": [],
  "asked_questions": [],
  "missing_fields": []
}

1つ目の理由は、客への返事と、聞き取った項目を分けて受け取れることです。 reply_to_customer だけを客の画面に返し、それ以外は Make が記録します。客に見せる文と、台帳に書く値が混ざりません。

2つ目は、status で次の処理を分けられることです。 collecting なら次の1通を待ち、ready なら換算点数の計算へ、handoff なら担当者へすぐ知らせます。

3つ目は、項目の値を決めた選択肢に絞れることです。 strict を有効にすると、必須のキーが抜けることも、決めていない選択肢の値が返ることもありません。 size が「大きめ」「L」「でかい」とばらつくと、換算点数の表を引けません。

スキーマには制約があります。 additionalProperties は false にする必要があり、すべての項目を必須にします。答えが無いことは、キーを省くのではなく null で表します。 また、モデルが安全上の理由で拒否した場合はスキーマではなく refusal のフィールドが返り、トークンの上限に達した場合もスキーマに沿わない応答になり得ます。 どちらも例外処理で扱います。

システムへ連携する

トラックの大きさと作業員数は、Make の計算で決めます。

1行目は、約款とも関わります。 標準引越運送約款では、動植物、ピアノ、美術品、骨董品など特殊な管理を要するものは、引受けを拒絶することがあるとされています。運べるかどうかをチャットで答えさせないのは、このためです。

台帳への書き込みは、聞き取りの結果と目安までです。 見積書の記載事項は約款に定められていて、出すのは担当者です。

人が確認する

担当者は、台帳の1行を読んでから客に連絡します。 読む順番を決めておきます。

1. handoff のものを先に見る … 事業所の移転や、客が強く急いでいるものです。その日のうちに電話します
2. special_items と訪問見積りの判定を見る … 訪問を勧めるものは、下見の日程を提案します
3. asked_questions を読む … 客がチャットで聞いたのに答えをもらえなかった質問です。最初の連絡で必ず答えます
4. unknown と missing_fields を見る … 電話で確かめる項目です。番地もここに入ります
5. トラックと作業員数の目安を見直す … 目安が経験と違えば、担当者が直します。直した記録を残します

3番目を省かないでください。 客は料金を聞いて「担当者からお伝えします」と返されています。

下見をするときは、費用の扱いを事前に伝えます。 約款では見積料は請求しないとされ、下見を行った場合に限り下見に要した費用を請求することがあり、その場合は見積りを行う前に金額を申込者に通知し、了解を得ることとされています。チャットではこの説明をさせず、担当者が伝えます。

目標は、1件6分です。 台帳を読むのに1〜2分、確認の連絡に3〜4分という想定です。

例外に対処する

上から4行目までが大半を占めます。 特に料金を強く求める客は、比べる材料を急いでいる客です。聞き取りが終わっていなくても、その日のうちに電話するほうが、決まる見積りにつながります。

7行目の文は、客のチャットでは必ず届きます。 料金も日程も答えられない作りにしておくことが、いちばんの防ぎ方です。

記録を残す

• 受付番号ごとの会話の全文（客の1通とAIの返事）と、各往復の時刻
• 各往復の応答のJSON（status、聞き取った項目、missing_fields）
• 換算点数の計算の内訳（家財ごとの点数、合計、引いた早見表の段）と、そのときの表の版
• 訪問見積りの判定と、当たった条件
• 担当者がトラックや人数の目安を直した記録 … どの値を、何から何へ
• 実際の作業の結果（当日のトラック、作業員数、当日に分かった追加の作業）

5つ目で、換算点数の表を直していきます。 担当者が毎回同じ方向に直しているなら、表の点数がずれています。最後の行と突き合わせれば、聞き取りで漏れた項目も見えます。

会話の全文は、自社の側に残します。 OpenAI の側の保存は既定で30日で、store を false にすれば残りません。