水道局が住民からの漏水・濁り水の通報を n8n で受け、場所・症状・緊急度の材料を整理して、症状の区分ごとに当番へ振り分ける

処理の起点を決める

2つのフォームの送信を起点にします。 住民が使う Web のフォームと、受付の職員が電話や窓口の通報を入れるフォームです。どちらも n8n の Form Trigger で作り、同じ後段につなぎます。 経路を分けると、片方だけ区分の付け方が違う期間ができます。

住民のフォームは、送信してすぐに受付の完了を返します。 Form Trigger の応答のタイミングは「フォームが送信されたとき」と「ワークフローが終わったとき」から選べます。後者を選ぶと、AI の処理の間、住民は画面の前で待つことになり、途中で失敗すると住民に送信の失敗が表示されます。 完了の画面には、「水が噴き出している、道路が陥没しているなど急ぎの場合は、お電話ください」と決まった文を出します。

本番は Production URL で受けます。 n8n の説明では、作っている間の Test URL と、保存して公開した後の Production URL は別で、本番の送信の内容はエディターではなく実行の履歴で見ます。ホームページに貼る URL を Test URL のまま公開しないことを、公開の手順に入れます。

入力データを集める

住民のフォームの「症状の選択」は、AI の区分と別に残します。 住民が「漏水」を選んでいても、自由記述に「水が白く濁っている」とあれば、区分は濁り水です。選択と区分が食い違った通報は、受付の確認に回します。

写真は AI に渡しません。 写真は当番の知らせに付け、当番が見ます。写真に写った家や人を AI に読ませる理由がありません。

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

重なりの候補は、町名と区分で引きます。 AI に取り出させた町名と、同じ区分、過去24時間で台帳を引き、当たった通報の受付の番号を並べます。同じ漏水かどうかは決めません。 当番が知らせの中で「〇〇町で同じ区分の通報が他に2件」と読めれば足ります。

町名の一覧も Data tables に置きます。 住民は「〇〇二丁目」「〇〇町2丁目」「〇〇2」と書くため、一覧には町名ごとに書き方の揺れを列で持たせ、AI にはその一覧を渡して当たるものだけを選ばせます。一覧に無い書き方が出たら、受付が列に足していきます。

当番は、区分から係を決め、日付と時間帯で引きます。 道路の漏水と断水は工務課、濁り水と異臭は浄水課、敷地内の漏水はお客さまセンターです。当番が引けなかったときは、係長の宛先に送ります。

AIへ渡す前に整形する

1. 自由記述の長さを確かめる … 空のときは、症状の選択だけで区分を決め、印を付けます
2. 連絡先を AI に渡さない … 氏名と電話番号は台帳にだけ入れ、AI のノードには場所と様子だけを渡します
3. 住所の表記をそろえる … 全角と半角、丁目の書き方を、町名の一覧で引けるようにそろえます
4. 受付の時刻を付ける … 職員のフォームでは、電話を受けた時刻を入力させ、送信の時刻と分けて持ちます
5. 同じ人の続けての送信を見る … 同じ連絡先から10分以内の送信は、2件目に印を付けます

2番目は、この構成で外せない手順です。 区分と材料を出すのに、氏名も電話番号も要りません。AI に渡す範囲を、判断に要るものだけに絞ります。

AIに処理させる

Information Extractor には材料を取り出させ、Text Classifier には区分を付けさせます。

いちばん大事なのは、Text Classifier の「当てはまらないとき」の設定です。 n8n の説明では、どの区分にも当てはまらないときの扱いの既定は「その項目を捨てる（Discard Item）」です。既定のままだと、判断のつかない通報が誰にも届かずに消えます。 必ず「Other の出口に出す」に変えます。

敷地内と道路の境目は、AI に決めさせません。 水道法は、配水管から分岐して設けられた給水管とこれに直結する給水用具を「給水装置」と定めていますが、どこまでを水道局が直し、どこからを住民の側で直すかは、それぞれの水道事業の取り決めによります。 AI には「家の前」「メーターの箱」と書かれた言葉を取り出させ、区分に迷えば Other に回します。

区分は1つだけにします。 複数の区分を許す設定もありますが、1件が2人の当番に届くと、どちらも相手が出ると思って動かないことがあります。漏水と濁り水が両方書かれた通報は、濁り水の区分に入れる説明にしておきます。

2行目がいちばん起きやすい失敗です。 「少し茶色いが、しばらく流せば大丈夫と思われます」のような一文を、AI は丁寧さとして足します。その一文が当番への知らせに入ると、濁り水の通報が軽く読まれます。

指示内容を固定する

（Information Extractor の System Prompt Template）
あなたは市の水道局の受付で、住民からの通報を整理する立場です。
通報の文面だけを見て、決めた材料を取り出してください。推測で埋めないでください。

【厳守事項】
- 書かれた言葉をそのまま入れてください。言い換えたり、程度を強めたり
  弱めたりしないでください。書かれていなければ null です。
- 町名は、渡した町名の一覧に同じものがあるときだけ入れてください。
  似た町名に寄せないでください。
- 水が安全か、飲んでよいか、修理の費用を誰が負担するかについて、
  何も書かないでください。
- 「道路が陥没している」「道路が水につかっている」と書かれているときだけ
  road_damage を true にしてください。

（Text Classifier の System Prompt Template）
住民からの水道の通報を、次の区分のどれか1つに分けてください。
{categories}
- 蛇口から出る水の色・臭い・異物について書かれていれば、漏水が一緒に
  書かれていても「濁り水と異臭」にしてください。
- 道路か敷地内か書かれていない漏水は、どちらかに決めず Other にしてください。
- 迷ったときは Other にしてください。

「程度を強めたり弱めたりしない」を明記するのは、緊急度の条件がその言葉で決まるからです。 「にじんでいる」を「流れている」に書き換えると、ワークフローの条件で緊急度が上がります。逆に弱めると、噴き出している漏水が通常の知らせになります。

「道路か敷地内か書かれていない漏水は Other」にするのも同じ理由です。 どちらかに寄せると、工務課とお客さまセンターのどちらかが、自分の係でない通報を受け取ります。 Other は受付の職員が住民に聞き返して決めます。

出力形式を固定する

Information Extractor は「JSON Schema で定める」を選び、次の形を決めます。

{
  "town": "〇〇町二丁目",
  "address_text": "〇〇公園の向かいの角",
  "place_type_text": "歩道",
  "flow_text": "噴き出している",
  "color_odor_text": null,
  "extent_text": null,
  "occurred_text": "朝7時ごろから",
  "road_damage": false
}

JSON の例から作る方式を使わないのは、全部の項目が必須になるからです。 n8n の説明では、JSON の例から形を作ると、すべての項目を必須として扱います。必須にすると、書かれていない項目を AI が埋めにいきます。 JSON Schema で書き、null を許します。

Text Classifier の出口は区分ごとに分かれ、そこに上の材料が付いて次へ流れます。緊急度は Switch のノードで、次の条件から付けます。

1つ目の理由は、緊急の条件が書かれた言葉だけで決まることです。 どの言葉で緊急になったかが、知らせの中で読めます。

2つ目は、町名の null を受付の確認に回せることです。 場所の分からない通報を当番に送っても、当番は動けません。受付が住民に聞き返してから送ります。

システムへ連携する

緊急の知らせは、Teams の Send and Wait for Response で送ります。 n8n の説明では、チャットのメッセージで承認のボタンを出し、応答があるまでワークフローを止められ、待つ時間に上限を付けられます。 ボタンは「出動する」「係長に回す」とし、15分応答がなければ係長の宛先へ同じ知らせを送ります。

通常の知らせは、チャットのメッセージで送ります。 区分・町名・場所の原文・水の出方・重なりの候補・写真の有無を並べ、台帳の受付の番号を先頭に置きます。

住民への連絡は、この構成からは送りません。 受付の完了はフォームの画面の決まった文で、その後の連絡は当番か受付の職員が電話で行います。

人が確認する

当番と受付の職員が、それぞれ次を見ます。

1. 当番：緊急の知らせに応答する … 出動するか、係長に回すかを選びます。給水を止めるかどうかは、現地を確かめて当番と係長が決めます
2. 当番：通常の知らせを読む … 重なりの候補を見て、同じ現場ならまとめて対応します
3. 受付：「受付の確認」を見る … Other、選択と区分の食い違い、町名の無い通報です。住民に電話で聞き返し、区分を決めて当番へ送り直します
4. 受付：区分を直したら台帳に残す … どの区分からどの区分へ直したかを書きます
5. 当番：対応の結果を台帳に返す … 修理した、敷地内で住民の側の修理を案内した、濁りは解消した、などです

3番目を当番に任せないのは、当番が現場に出ているからです。 聞き返しは受付の仕事にします。夜間は、当番の受付の担当が同じ一覧を見ます。

災害で通報が急に増えたときも、確認の順は変えません。 緊急の知らせに応答し、受付の確認を片づけ、通常の知らせは町名でまとめて読む。件数が多いときほど、濁り水の区分を最初に見ることを、当番の手順書に書いておきます。

目標は、360件をならして1件4分です。 区分の決まった通常の通報は、受付が台帳を流し見て1〜2分、受付の確認に回ったものは聞き返しで10分前後かかります。

例外に対処する

1行目と5行目は、どちらも「黙って消える」型です。 捨てられた通報も、書き込めなかった通報も、エラーとして目に見えないまま、住民からの2度目の電話で初めて分かります。 毎朝、前日のフォームの送信の数と台帳の行数を比べます。

記録を残す

• フォームの全項目（写真を含む）と受付の時刻
• AI が取り出した材料と区分、使ったモデルのデプロイの名前
• 緊急度と、その緊急度になった条件
• 知らせた当番、知らせの時刻、応答の時刻と内容
• 受付が区分を直した記録
• 当番の対応の結果

3つ目で「その緊急度になった条件」を残すのは、後から説明できるようにするためです。 住民から「なぜ対応が遅れたのか」と問われたとき、どの言葉でどの区分と緊急度になったかを示せます。

5つ目は、区分の説明を直す材料です。 受付が同じ型の通報を何度も直しているなら、Text Classifier の区分の説明に一文足します。説明を直したら日付を残し、直す前と後で受付の直しの件数がどう変わったかを月ごとに比べます。 台帳の保存の期間は、自治体の文書の保存の決まりに合わせます。