エアコンクリーニングの依頼のフォームを Make で受け、機種・台数・設置の場所を1台ずつ整えて、作業の時間と人数から日程の候補を出す

処理の起点を決める

依頼のフォームが送られた時点を起点にします。 夜や週末に届いた依頼にも、その場で明細と下書きまで作っておきます。担当は朝いちばんに確かめて送るだけになります。

夜の間に自動で送らないのは、日程の候補が会社の約束の一部になるからです。 候補に出した枠に、別の依頼の予定を担当が先に入れてしまうこともあります。送る直前に、担当がカレンダーを見て候補がまだ空いているかを確かめます。

受信の返事は、Webhook response のモジュールで返します。 公式のページでは、このモジュールを途中に置くと後のモジュールの誤りに気づけないことがあり、最後に置けばどこで誤りが起きても通知されるとされています。依頼者の画面には「ご依頼を受け付けました。担当から日程の候補をお送りします」とだけ返します。

入力データを集める

質を決めるのは、標準の作業時間の表です。 例えば次のような表を、作業員の長と一緒に作ります。

「見分けの目安」の列を、AI への指示にもそのまま渡します。 AI にも担当にも同じ基準を見せることで、依頼者の書き方からどの区分とするかが、担当の頭から表に移ります。 第3章の（b）は、この表で止めます。

「不明」の行を長いほうの時間にしているのは、日程を外さないためです。 分からない機種を標準の90分で取ると、行ってみて自動お掃除付きだったときに、次の訪問先へ遅れます。

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

timeZone は必ず指定します。 省くと UTC で返り、午前の枠が9時間ずれて見えます。 候補が夜中に出たら、まずここを疑います。

空きは、希望の日の範囲だけを引きます。 希望の日を含む範囲で、行ける作業員のカレンダーを並べて引き、busy の区間の外側で、合計の時間に移動の時間を足した長さが収まる枠を探します。 2人で入る作業は、2人の枠が同じ時間に重なるところだけを候補にします。

作業時間の表は、AI の出力を受けた後に引きます。 AI には作業時間を見せません。見せると、機種の区分を時間の短いほうへ寄せて書くことがあります。

AIへ渡す前に整形する

1. 必須の欄の確認 … 住所の市区町村と希望の日が無いものは、明細を作る前に質問の候補にします
2. 台数の欄の確認 … 数字でないもの、20を超えるものは、明細を作ったうえで人に回す印を付けます
3. AI に渡す範囲を絞る … 依頼者の名前、番地、電話番号、メールアドレスは渡しません。台数、機種の選択、自由記述、建物の種類と階だけにします
4. 希望の日の整え … 「来週の土日」のような書き方は、受け付けた日を基に Make の側で日付に直します。直せないものは質問の候補にします

3番目で番地を外しても、移動の時間は市区町村で決まります。 自由記述に部屋番号や家族の名前が書かれていることもあるので、明細には部屋の呼び方（リビング、寝室など）だけを書くよう指示します。

4番目を AI に任せないのは、日付の計算がずれやすいからです。 曜日と日付の対応は、機械の関数で出します。

AIに処理させる

させるのは、依頼の文と選択の欄から、1台ずつの明細を抜き出すことです。

機種の食い違いで自由記述を採るのは、選択の欄のほうが誤りやすいからです。 依頼者は「壁掛け」の言葉だけを見て選びがちで、「天井についている」「自動で掃除する」は、見たままを書いた言葉です。 それでも確かめる質問は必ず付けます。

2行目がいちばん起きやすい失敗です。 依頼者が型番を書いてくると、AI はそれらしく「この型番は自動お掃除付き」と書きます。型番は明細の model_text にそのまま写すだけにし、区分は依頼者の書き方と表の目安だけで付けます。

指示内容を固定する

あなたはエアコンクリーニングの受付で、依頼の内容を1台ずつの作業の明細に整える立場です。
渡した依頼の内容だけを見て書いてください。推測で埋めないでください。

【機種の区分と見分けの目安】{unit_types}
【依頼の台数の欄】{count_field}
【依頼の機種の選択】{type_field}
【建物の種類と階】{building}
【依頼の自由記述】{free_text}

【やること】
1. エアコンを1台ずつ units に並べてください。
2. 各台に、部屋の呼び方、機種の区分、設置の高さ、室外機の置き場所、
   下の家具を動かす必要があるかを入れてください。
3. 機種の区分は、見分けの目安の言葉に当たるものだけで選んでください。
   当たらなければ unknown にしてください。
4. 台数の欄と units の数が違うとき、機種の選択と自由記述が食い違うとき、
   unknown の項目があるときは、依頼者に聞く質問を questions に書いてください。

【厳守事項】
- 書かれていない項目は unknown にしてください。建物の種類や階から推さないでください。
- 型番が書かれていても、型番から機能や区分を推さないでください。
  型番は model_text にそのまま写すだけにしてください。
- 作業の時間、人数、料金は書かないでください。
- 部屋の呼び方は「リビング」「寝室」のような呼び方だけにしてください。
  部屋番号、家族の名前、住所は書かないでください。
- 台数の欄と units の数が違うときに、どちらかに合わせて台数を作らないでください。
  自由記述から数えた台を units に入れ、違いは questions に書いてください。
- questions は依頼者が一言で答えられる聞き方にしてください。
  例：「寝室のエアコンは、天井についているものですか、壁についているものですか」
- evidence には、各台の区分の根拠にした依頼の文をそのまま写してください。

「建物の種類や階から推さない」を書くのは、事務所や店舗の依頼で起きるからです。 何も言わないと、店舗と書いてあるだけで天井埋め込みにします。区分の根拠は依頼者の言葉だけにします。

「どちらかに合わせて台数を作らない」も同じ理由です。 台数の欄が「3」で自由記述に2台しか書かれていないと、AI は3台目を「不明の部屋」として作ります。作った1台の分だけ時間が延び、取れたはずの枠が消えます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "request_id": "",
  "units": [
    {
      "room": "リビング",
      "unit_type": "wall_standard | wall_autoclean | ceiling | unknown",
      "height": "standard | high | unknown",
      "outdoor_unit": "ground | roof_or_wall | unknown",
      "furniture_below": "yes | no | unknown",
      "model_text": "",
      "evidence": ""
    }
  ],
  "count_field": 0,
  "count_mismatch": true,
  "type_mismatch": false,
  "questions": [""]
}

1つ目の理由は、1台ずつ表を引けることです。 units の要素ごとに unit_type で作業時間の表を引き、height と outdoor_unit で加算を引きます。合計は Make の集計で出します。

2つ目は、unknown を時間に変える決まりを機械に置けることです。 unit_type が unknown の台は表の「不明」の行で長いほうの時間を取り、outdoor_unit が unknown なら加算を入れたほうで取ります。 決まりは表の側にあるので、事業者が変えられます。

3つ目は、questions を返信の文にそのまま使えることです。 担当は、質問が一言で答えられる聞き方になっているかだけを見ます。

システムへ連携する

カレンダーには書き込みません。 候補を出した時点で仮の予定を入れると、返事の来ない依頼の仮の予定で、カレンダーが埋まります。 予定を入れるのは、依頼者が日程を選んだ後の担当です。

その代わり、依頼の一覧に「候補に出した枠」の列を持たせます。 次の依頼の空きを探すときに、返事待ちの枠を候補から外すか、重ねてよいかを事業者の決まりで選べます。

人が確認する

人が見るのは、すべての下書きです。 ただし見るところを絞ります。

1. 明細の台数と区分を見る … evidence を読み、依頼の文と合っているかを見ます
2. 質問を見る … 一言で答えられる聞き方か、聞かなくてよいことを聞いていないかを見ます
3. 候補がまだ空いているかを見る … 送る直前にカレンダーを開いて確かめます
4. 料金の目安を添えて送る … 料金は担当が料金表から添えます

1番目を省かないでください。 区分を1台取り違えると、作業の時間が1時間違います。依頼者に返す前に人が見る最後の機会です。

目標は、300件をならして1件3分です。 明細が表のとおりに決まっているものは1分ほど、unknown と食い違いのあるものは質問を直すので5分ほどかかります。

例外に対処する

上の2行が大半を占めます。 どちらも AI の問題ではなく、作業員の人数と枠の問題です。 候補が出ない依頼が続く時期は、作業員の予定の組み方を見直す材料になります。

記録を残す

• 依頼の内容（AI に渡さなかった項目を含む）と受け付けた日時
• AI が返した明細の JSON と questions
• そのときに使った作業時間の表の版と、計算した合計の時間・人数
• 候補に出した枠と、依頼者が選んだ枠
• 人が明細を直した記録 … どの台の、どの項目を、どちらに変えたか
• 作業の後の実際の時間 … 作業員が記録した開始と終了の時刻

最後の行が、作業時間の表を育てます。 表の90分や150分は最初は作業員の長の目安ですが、実際の時間と並べると、区分ごとのずれが見えます。 数か月分を見て表を直すと、候補の精度が上がります。