設備工事の会社が排水管の詰まりの問い合わせを Make で受け、症状・場所・急ぎ度で分けて、当番と作業班に振り分ける

処理の起点を決める

経路は3つで、入口は2つです。 Web の問い合わせフォームと聞き取りの入力は、送信と同時に Custom webhook に届きます。受け付けたリクエストには、Webhook response のモジュールを置かなければ、ステータス200と「Accepted」という本文が返るとされています。フォームの側は、この応答を受けて「受け付けました」の画面を出します。

管理会社の依頼メールは、Gmail の Watch emails で拾います。 フィルターには、条件を選ぶ簡単なフィルターと、Gmail の検索の書き方で指定する方法があり、1回に扱う上限は500件以下とされています。取引のある管理会社の送信元だけに絞り、5分ごとに動かします。 夜にメールで来る依頼も、至急なら当番に届く必要があるからです。

拾ったメールにはラベルを付けます。 「処理済み」のラベルは、受付台帳への書き込みまで通ったときだけ Update email labels で付けます。既読にする設定は使いません。

電話は、聞き取りの入力に打ち込みます。 項目は、依頼者の名前と連絡先、住所、聞いた内容をそのまま書く欄の4つだけにします。作業中の当番が項目を選ぶ余裕は無く、分けるのは AI の仕事です。

入力データを集める

質を決めるのは、管理会社の表の物件の名前の列です。 入居者は物件の名前を通称で言うことがあり、管理会社の表に通称を並べておけば、住所と物件の名前から管理会社を引けます。 引けないものは要確認に回します。

写真は AI に渡しません。 Web のフォームで写真が付いていれば、受付台帳にリンクを残し、現地に向かう班が見ます。 区分に要るのは、依頼者が書いた症状の言葉です。

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

Web の問い合わせは、項目ごとに分かれたまま届きます。 症状の説明の欄と物件の種類の選択を、1つの文面にまとめて Claude に渡します。住所・名前・連絡先は渡しません。 Make が元の項目から受付台帳に写します。

急ぎ度は、時間帯で表を分けます。 日中の表と夜間・休日の表を持ち、受信の時刻で Make がどちらを引くかを決めます。 夜は当番が2名しかいないので、同じ「台所の流れが止まった」でも、日中は当日、夜は翌朝の予約にします。

管理会社の表を物件の名前で引くときは、Search Rows の Limit を1にしません。 同じ名前の物件を2つの管理会社が持っていることがあり、2行返ったら住所の市区町村で絞り、それでも1つにならなければ要確認に回します。

管理会社の物件で夜間の出動が不可なら、至急でも管理会社へ回すルートに入れます。 入居者には、管理会社の夜間の窓口を案内します。取引の条件を破って出動しないためです。

AIへ渡す前に整形する

1. 送信元の確認 … メールは取引のある管理会社の送信元か確かめます
2. 本文を文字にする … HTML を改行つきの文字にし、署名と過去のやり取りの引用を外します
3. 個人の情報を外す … 名前・電話番号・メールアドレス・住所の番地を外し、市区町村までを残します
4. 文面をまとめる … Web の問い合わせは、症状の説明と物件の種類の選択を1つの文面にします
5. 同じ相談の二度目を外す … 同じ連絡先から30分以内に同じ内容が来たら、前の受付に追記します

3番目で市区町村を残すのは、作業班の担当の地域を引くためです。 番地は区分に要りません。

5番目は、急いでいる依頼者がフォームを何度も送るためです。 二度目を新しい受付にすると、当番に同じ知らせが2回届きます。

AIに処理させる

させるのは、相談の文面を決めた区分に分けることだけです。

区分ごとに、根拠にした文言を写させます。 「2階のトイレは使えます」と書かれていれば、それが使えない設備の数の根拠です。受付が台帳を見たときに、なぜその区分かが一目で分かります。

shared（共用部の疑い）は、文面に手がかりがあるときだけにさせます。 「下の階の人も流れが悪いと言っている」「1階の排水ますからあふれている」のような書き方です。手がかりが無いのに共用部と決めると、管理会社へ回す相談が増えすぎます。

指示内容を固定する

あなたは給排水の修理の会社の受付で、排水の詰まりの相談を区分に分ける担当です。
渡された相談の文面だけを読み、決められた区分の値を選んでください。
文面に書かれていないことを推測しないでください。

【分けるもの】
- symptom：slow / stopped / overflow / backflow / odor / noise / unknown
  複数当てはまるときは、いちばん重いもの（overflow → backflow → stopped
  → slow → odor → noise の順）を symptom に、残りを other_symptoms に入れる
- location：kitchen / bath / toilet / washbasin / laundry / outdoor_basin /
  multiple / unknown
- other_fixture_available：同じ種類の設備がほかにあり使えると書かれていれば
  true、ほかに無い・使えないと書かれていれば false、書かれていなければ null
- property_type：house / apartment / shared / store / unknown
  shared は、ほかの部屋や下の階でも起きている、共用の排水ますからあふれている、
  など、共用の排水管を疑う手がかりが文面にあるときだけ選ぶ
- requester_role：owner / tenant / manager / other / unknown
- property_name：物件の名前が書かれていれば、書かれた呼び方のまま

【厳守事項】
- 区分ごとに、根拠にした文言をそのまま evidence に写す。
- 原因を書かない。料金・作業の時間・自分で直す方法を書かない。
- 急ぎかどうかを書かない。
- 文面が詰まりの相談でない（給湯器の故障、水漏れだけ、など）ときは
  is_drain_clog を false にし、区分は unknown にする。

【受信日時】{received_at}
【経路】{channel}
【相談の文面】{text}

「いちばん重いものを symptom に入れる」の順を書いているのは、急ぎ度の表を1つの値で引くためです。 「流れが遅くて臭う」なら slow、「止まって逆流してきた」なら backflow です。順を決めておかないと、同じ文面でも返る値が揺れます。

「詰まりの相談でないとき」を入れているのは、水漏れや給湯器の相談が同じ窓口に来るためです。 これらは別の担当に回すので、詰まりの急ぎ度の表で引きません。

出力形式を固定する

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

{
  "is_drain_clog": true,
  "symptom": "backflow",
  "other_symptoms": ["odor"],
  "location": "toilet",
  "other_fixture_available": false,
  "property_type": "apartment",
  "requester_role": "tenant",
  "property_name": "◯◯ハイツ",
  "evidence": {
    "symptom": "流すと水が上がってきて、臭いもします",
    "location": "トイレ",
    "other_fixture_available": "トイレはここ1つだけです",
    "property_type": "アパートの2階です",
    "requester_role": "借りている部屋です"
  }
}

1つ目の理由は、急ぎ度の表を区分の組み合わせで引けることです。 区分を enum で決めておけば、表の行と一字違わずに照合できます。自由文で返させると、「逆流」「上がってくる」「戻ってくる」が別の値になります。

2つ目は、ルーターの条件に使えることです。 Make のルーターは、ルートを順に処理し、ほかのどのルートの条件にも合わないものをフォールバックのルートで処理するとされています。

順を、要確認・管理会社・至急の並びにしているのは、共用部の相談を至急で出動させないためです。 共用部の疑いがあるものは、まず管理会社に回します。ただし、管理会社へ回すルートでも、症状が overflow なら当番にも知らせ、受付が管理会社と電話で段取りを決めます。

3つ目は、evidence で受付の確認が速くなることです。 台帳の1行に、区分と根拠の文言が並びます。

システムへ連携する

当番への知らせは、メールに加えて受付が電話します。 夜間に当番がメールを見られるとは限らないので、至急のものは受付（夜は当番の相方）が電話で確かめます。 メールは記録として残す意味が大きいものです。

依頼者への返信は、定型の文面に区分の値と目安を差し込んで下書きにします。 文面には、伺う時間の目安、現地で状況を見てから作業の内容と料金を説明し、了承を得てから作業に入ること、見積の費用の扱い（会社の料金表のとおり）を書きます。国民生活センターの資料では、「見積もり無料」のはずが見積もりの費用を請求されたという相談も挙がっています。見積の扱いを最初の返信ではっきり書くのは、そのためです。

人が確認する

1. 至急のものを先に見る … 区分と根拠を見て、当番に電話します
2. 要確認の一覧を見る … unknown が出たもの、詰まりの相談でないもの。依頼者に電話で聞き直します
3. 管理会社へ回すものを見る … 管理会社への連絡の下書きを確かめて送ります
4. 当日・予約のものを流し見る … 区分と根拠が合っているかを見て、作業班の候補から班を決めます
5. 返信の下書きを確かめて送る … 伺う時間の目安を、作業班の予定と合わせて直します

overflow の相談には、返信の下書きとは別に、受付が電話で「その場所の水を流すのをやめてもらう」案内をします。 あふれが続くと床や下の階に広がるからです。案内の言い方は会社が決めた文面にし、AI には書かせません。

4番目は、全件を詳しく見る作業ではありません。 区分と根拠が並んでいるので、根拠の文言を読んで違和感が無ければ次に進みます。 human_check を「条件付き」にしているのは、この流し見と、至急・要確認・管理会社のものだけを詳しく見る運用だからです。

目標は、480件をならして1件2分です。 当日・予約は流し見と返信で1分ほど、至急と要確認は電話をかけるので数分かかります。

例外に対処する

上の3行が大半を占めます。 どれも区分の問題というより、聞き取りの短さの問題です。 聞き取りの入力の欄の上に「場所、流れの具合、ほかに使えるか、持ち主か借りているか」と書いておくと、夜の当番の聞き取りでも区分がそろいます。

記録を残す

• 相談の原文（Webhook の中身、メールの ID と本文）と受信の日時
• Claude が返した JSON の全文
• 引いた急ぎ度の表・管理会社の表の行と、出した急ぎ度とルート
• 当番に知らせた日時と、受付が電話で確かめた結果
• 返信を送った日時と、下書きから直した点
• 現地で分かった原因と、区分が合っていたか

最後の行が、急ぎ度の表の見直しの材料になります。 「slow で予約に回したが、現地では管の奥で止まりかけていた」が続くなら、slow に臭いや音が重なる組み合わせを当日に上げる、といった直し方ができます。