ケーブルテレビ局に届く視聴・インターネットの不具合の問い合わせを、症状と地域で分け、遠隔・訪問・障害対応へ振り分ける

処理の起点を決める

起点は3つです。

受付用のフォームは、Authentication を n8n User Auth にします。 n8n にログインした受付だけが開けるようにし、外から問い合わせを作られないようにします。公開用のフォームは加入者が送るので、Ignore Bots をオンにして、リンクのプレビューやクローラーからの送信を無視します。

フォームの時刻は Use Workflow Timezone をオンにします。 既定は UTC で、オフのままだと submittedAt が9時間ずれます。系統ごとの件数を「直近30分」で数えるので、入口ごとに時刻の基準がずれると、重なりを見落とします。

Gmail Trigger は、不具合の窓口のアドレスに届いたメールに付くラベルで絞ります。 1回の取得の件数（Max Emails per Poll）は既定で10、上限で50で、残りは次の回に回ります。障害のときはメールが一度に増えるので、上限の50にし、取得の間隔は短くします。 取り残しが次の回に回るだけで消えはしませんが、件数を数える時刻が遅れます。

入力データを集める

質を決めるのは、系統の表です。 町丁目だけで系統が1つに決まらない地区（同じ丁目が2つの光ノードにまたがる、集合住宅だけ別の引き込み）があるので、集合住宅は名前で、それ以外は町丁目で引けるように行を分けます。 1つに決まらない地区は、系統の記号を2つ並べた行にし、後段で「系統未確定」として扱います。

系統の世帯数を持たせるのは、しきい値を系統の大きさで変えるためです。 200世帯の系統で30分に3件と、2,000世帯の系統で30分に3件は、意味が違います。

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

顧客管理システムには、この構成から直接つなぎません。 夜間に出力される加入者の一覧を取り込んで引きます。当日に加入・住所変更があった加入者は引けないことがあり、その場合は「加入者未確認」として受付に返します。

Data Table の容量に注意します。 公式のページでは、インスタンスのすべての Data Table の合計は既定で200MiBまでとされ、自社で動かす場合は N8N_DATA_TABLES_MAX_SIZE_BYTES で変えられます。上限を超えると、行を足したり書き換えたりする実行が失敗します。 加入者4万世帯の一覧は容量を食うので、持たせる列は引き当てに使うものだけにし、問い合わせの記録は月ごとに外へ書き出して古い行を消します。

Code ノードは Data Table の値を直接読めません。 公式のページにそう書かれています。件数を数えるときは、Data Table ノードの Get で直近の行を取ってから、Code ノードに渡して数えます。

AIへ渡す前に整形する

1. 入口ごとの形をそろえる … 3つの入口の項目を、同じ名前にそろえます。メールは件名と本文をつなげ、署名と引用を外します
2. 加入者を引く … 契約番号、なければ電話番号で引きます。引けなければ「加入者未確認」の印を付けます
3. 系統を引く … 集合住宅の名前、なければ町丁目で引きます。2つに当たれば「系統未確定」の印を付けます
4. 個人の情報をAIへの材料から外す … 名前・電話番号・契約番号・住所は渡さず、症状の文と受付が選んだサービスだけを渡します
5. 同じ問い合わせをまとめる … 同じ加入者から直近2時間に同じサービスの問い合わせがあれば、件数に足さず、先の問い合わせに書き足します
6. 緊急の語の印 … 「緊急通報」「110番」「119番」「固定電話がかからない」などの語があれば、AIの区分とは別に印を付けます

5番目を省くと、障害の疑いが実際より早く立ちます。 1軒の加入者が電話とメールの両方で問い合わせると2件に数えられ、4軒が2回ずつ連絡しただけで「8件」になります。 数えるのは問い合わせの数ではなく、問い合わせてきた世帯の数です。

6番目は電話のサービスのためです。 固定電話がつながらない加入者は、緊急の通報もできない状態にあるかもしれません。AIの区分を待たずに、規則で優先の印を付けます。

AIに処理させる

させるのは2つです。症状を区分することと、機器の状態の手がかりを書かれたとおりに書き出すことです。

症状の区分は Text Classifier ノードで行います。 区分ごとに名前と説明を書きます。

When No Clear Match は「Output on Extra, 'Other' Branch」に変えます。 既定の「Discard Item」のままだと、どの区分にも当たらない問い合わせは黙って捨てられ、受付に届きません。 Other に出たものは、受付がそのまま読みます。

Allow Multiple Classes To Be True はオフにします。 「テレビもネットも全部だめ」は、区分ではなく書き出しの側の services_affected で拾います。複数のサービスが同時に止まっているという事実は、障害の疑いのいちばん強い手がかりなので、区分の1つに埋もれさせないためです。

書き出しは Information Extractor ノードで行います。 画面に出ている番号やメッセージ、モデムのランプ、いつからか、家の中の全部か一部か、を書かれたとおりに写させます。

指示内容を固定する

Information Extractor ノードの System Prompt Template に次の文を入れます。

あなたはケーブルテレビ局の不具合の受付で、問い合わせの文を読んで
技術の担当に渡す手がかりを整える立場です。
文に書かれていることだけを、決まった項目に書き出してください。

【書き出すもの】
- services_affected：止まっているサービス（放送／ネット／電話）。
    文に書かれているものだけ。複数あればすべて
- screen_message：画面に出ているメッセージや番号。書かれたとおりに写す
- device_lights：モデムやチューナーのランプの色・点滅。書かれたとおりに写す
- scope_in_home：家の中のテレビ・機器の全部か一部か
- since_text：いつからか（「今朝から」「30分前から」など書かれたとおり）
- tried：加入者がすでに試したこと（再起動、配線の確認など）
- weather_or_work：雷・強風・近所の工事などの記載
- missing：行き先を決めるのに足りない情報
- questions_for_reception：受付が加入者に確かめるべきこと

【厳守事項】
- 書かれていない項目は空にしてください。推測で埋めないでください。
- screen_message は、番号や記号を補ったり言い換えたりせず、そのまま写してください。
- 「全部だめ」とだけ書かれている場合は、どのサービスのことかを
  questions_for_reception に書き、services_affected には入れないでください。
- 機器の故障・障害・復旧の見込みについて書かないでください。
- 料金や修理代について書かないでください。
- 機器の分解や配線の工事を勧める内容を書かないでください。

【受付が選んだサービス】{service_selected}
【症状の区分（別のノードの結果）】{symptom_class}
【問い合わせの文】{inquiry_text}

「全部だめ」を推測で広げないのは、件数の数え方に効くからです。 放送だけ契約している加入者の「全部」は放送のことで、ネットと電話を足すと、「複数のサービスが同時に止まっている」という強い手がかりが、事実でないまま立ちます。

screen_message を言い換えさせないのは、番号そのものが手がかりだからです。 技術の担当は、表示された番号で受信の状態か機器の状態かの見当を付けます。AIが「受信できないというメッセージ」と言い換えると、その手がかりが消えます。

出力形式を固定する

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

{
  "symptom_class": "放送_全部 | 放送_一部 | ネット_不通 | ネット_品質 | 電話 | 機器の操作 | other",
  "services_affected": ["放送", "ネット"],
  "screen_message": "",
  "device_lights": "オンラインのランプが点滅",
  "scope_in_home": "全部",
  "since_text": "19時ごろから",
  "tried": ["モデムの電源の入れ直し"],
  "weather_or_work": "",
  "missing": [],
  "questions_for_reception": []
}

この後ろに、Code ノードが規則で次を足します。

1つ目の理由は、route を表の値で決められることです。 「ネット_不通でモデムのランプの記載あり」は遠隔対応、「放送_全部で家の中の全部」は遠隔で受信の状態を見たうえで訪問、のように、組み合わせごとに表の1行で決めます。 判断を直すときは表を直せばよく、AIの指示は変えません。

2つ目は、outage_suspect を件数と内容の2つの材料で立てられることです。 件数が少なくても、放送とネットが同時に止まった世帯が同じ系統に2軒あれば、伝送路の側を疑う理由になります。

3つ目は、記録がそろうことです。 区分と系統と時刻が同じ形で残るので、障害だった場合にいつから何世帯の問い合わせがあったかを、記録から数えられます。

システムへ連携する

障害の疑いの知らせは、Slack の Send and Wait for Response で送ります。 Response Type を Approval にすると、技術の担当が Slack のボタンで答えたところでワークフローが続きます。Capture Who Responded をオンにして、誰が答えたかを記録に残します。 Restrict Who Can Approve で、答えられる人を技術の担当に絞ります。

承認されたら、同じ系統の新しい問い合わせの行き先の案を「障害対応中」に切り替えます。 受付は個別の訪問の予約を入れず、加入者には「地域で調べています」と案内します。切り替えを戻すのも技術の担当の操作で、機械が勝手に戻しません。

顧客管理システムと訪問の予約表には書き込みません。 予約を入れるのは受付の手で、この構成は行き先の案を出すまでです。

人が確認する

1. 受付は行き先の案を見てから案内する … 案は画面に出るだけで、加入者に何を伝えるかは受付が決めます
2. Other と加入者未確認は受付がそのまま見る … 区分に当たらないものと、加入者を引けなかったものは、案を出さずに受付へ返します
3. 障害の疑いは技術の担当が決める … 監視の画面と設備の状況を見て、Slack で承認か却下を選びます
4. 行き先を変えたら記録する … 案と違う行き先にしたときは、理由を選んで残します

3番目を自動にしないでください。 件数のしきい値を超えても、同じ集合住宅の数軒が同じ時間に同じ操作で迷っただけ、ということがあります。 逆に、件数が少なくても設備の監視に出ているなら障害です。件数は、技術の担当が監視の画面を見に行くきっかけです。

目標は、1,200件をならして1件2分です。 受付は案を読んで確かめ、違えば直すだけにします。

例外に対処する

6行目の「件数の集計は続ける」は、障害のときほど効きます。 障害で問い合わせが一度に増えると、AIの呼び出しが遅れたり失敗したりすることがあります。区分が付かなくても、系統ごとの世帯数は数えられます。 区分を待って件数の集計を止めると、いちばん知りたいときに知らせが出ません。

記録を残す

• 問い合わせの文と入口、受け付けた時刻
• AIの区分と書き出しの結果（JSON）
• 系統の記号、直近の世帯数、障害の疑いの印、行き先の案
• 受付が決めた行き先と、案と違ったときの理由
• Slack での承認・却下、答えた人、答えた時刻
• 障害対応中への切り替えと解除の時刻

4つ目を必ず残します。 案と違う行き先が続く区分は、行き先の規則の表が現場に合っていないということです。月に一度、案と違った件を区分ごとに数えて表を直します。

5つ目と6つ目は、障害だった場合の報告の材料になります。 総務省のページでは、重大な事故の詳細な報告の中で、利用者からの電話やメールによる問い合わせの件数を算出方法とともに書くとされています。いつから何世帯の問い合わせがあったかを、この記録から数えられるようにしておきます。