社員寮を持つ会社の総務が入寮・退寮・修繕の依頼を Make で受け、AI で種類を分けて寮の管理会社と社内の担当に振り分ける

処理の起点を決める

フォームの回答のシートに行が増えたときと、寮の代表アドレスにメールが届いたときの2つを起点にします。 フォームの回答は Google Sheets の Watch New Rows で、メールは Gmail の Watch emails で「寮の依頼」のラベルを見張ります。ラベルは Gmail のフィルタで、寮の代表アドレスあてのメールすべてに付けます。 管理会社からの返事はラベルを分け、このシナリオでは拾いません。

どちらも5分おきにします。 修繕の依頼は分単位を争うものではありませんが、急ぎの印が付いた依頼を担当に知らせるのが遅れないように、間隔を短めにします。 本当に急ぐものは、フォームの冒頭で管理会社の緊急の番号に電話するよう案内しています。この構成は、電話をかけ忘れた人の依頼を拾う二重の網です。

フォームの冒頭の案内は、こう書きます。 「水が止まらない、ガスのにおいがする、火・煙が出ている、部屋に入れない、閉じ込められた、は、このフォームではなく下の番号に電話してください」。その下に、寮ごとの管理会社の緊急の番号を並べます。

入力データを集める

質を決めるのは、寮と管理会社の対応表です。 1行に1つの寮を置き、「管理会社に回す種類」の列に、修繕・備品・退去の立会いのように、管理会社が受け持つ依頼の種類を並べます。 単身赴任者の寮は備品を会社が直接手配する、のような寮ごとの違いを、この列で表します。

別名の列があるのは、入居者が寮を正式な名前で書かないからです。 「東寮の305」と書かれた依頼を A寮に結び付けるのは、AIではなくこの表です。

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

フォームの依頼は、寮・部屋番号・依頼の種類が選択の欄で届きます。 それでもAIに読ませるのは、内容の欄に書かれたことが、選んだ種類と違うことが多いからです。 「備品」を選んで「エアコンから水が垂れる」と書かれていれば、それは修繕です。選択の欄とAIの分類が食い違う依頼は、総務へ回します。

メールの依頼は、寮も部屋も本文に書かれています。 書かれていなければ、送信元のアドレスで入居者の名簿を引きます。名簿で引けた寮・部屋と、本文に書かれた寮・部屋が違えば、総務へ回します。 友人の部屋のことを書いている場合や、異動したばかりで名簿が古い場合があります。

AIへ渡す前に整形する

1. 急ぎの印 … 内容の欄と本文に「水が止まらない」「漏れ」「ガス」「におい」「火」「煙」「鍵」「閉じ込め」「入れない」が含まれていれば、urgent_flag を立て、AIの呼び出しより前に寮の担当へ知らせます
2. 重複の確認 … 同じ社員番号・同じ部屋で3日以内の依頼があれば、新しい依頼として回さず、前の依頼に追記として結び付けます
3. 返信の引用を落とす … メールの返信に付いてくる前のやり取りを落とします
4. AIに渡す範囲を絞る … 社員番号・氏名・所属は渡しません。AIに渡すのは、内容の欄と本文、選択の欄の値、寮の名前の一覧だけです
5. 寮の名前の一覧を渡す … 対応表の寮の名前と別名を、AIが写すときの手がかりとして渡します

1番目は、拾いすぎる前提で作ります。 「鍵」は「鍵付きのロッカーが欲しい」でも当たります。それで担当に知らせが届いても、開いて急ぎでないと分かれば1分で済みます。 逆に言葉を絞って付き漏れると、真冬にお湯が出ない部屋が翌日まで放置されます。

4番目で名前を渡さないのは、分類に要らないからです。 依頼の種類と部位は内容で決まり、誰の依頼かは名簿で引けば足ります。

AIに処理させる

させるのは、依頼の文を決まった種類に分類することと、寮・部屋・部位・希望の日を項目にそろえることの2つです。

living を分けるのがこの構成で大事な区別です。 騒音や共用部の使い方の困りごとには、ほかの入居者が出てきます。 これを修繕と同じように管理会社へ自動で送ると、苦情の相手の部屋番号が社外に出ます。living は必ず総務へ回し、管理会社に伝えるかどうかは総務が決めます。

指示内容を固定する

あなたは会社の総務部で、社員寮に届く依頼を受け付ける担当です。
下に渡す依頼を読み、種類を分け、項目にそろえてください。
どこへ回すか、費用を誰が持つかは決めないでください。

【すること】
1. request_type を次から1つ選ぶ。
   repair / equipment / move_in / move_out / living / other / unclear
   - 壊れた・動かない・漏れる・効かないは repair
   - 足りない・欲しい・交換したい（壊れていない）は equipment
   - 騒音・におい・共用部の使い方など、ほかの入居者が関わるものは living
2. 寮の呼び方を dorm_as_written に写し、下の寮の一覧の名前か別名に
   当たるものを dorm に入れる。当たらなければ null。
3. 部屋番号、部位、希望の日、立会いの可否を写す。
4. repair と equipment のときは、管理会社への依頼の文を3行以内で書く。
   部位・症状・いつからか だけを書く。
5. フォームで選ばれた種類と、内容から読んだ種類が違えば
   form_mismatch を true にする。

【厳守事項】
- 書かれていない部屋番号・日付を推し量らない。null にする。
- 原因を書かない。「〜が原因と思われます」を管理会社への文に入れない。
- 費用の負担、入居者の過失の有無に触れない。
- living のときは、管理会社への依頼の文を書かない。
- 依頼の文に出てくるほかの入居者の名前や部屋番号を、
  管理会社への文に写さない。
- 急ぎかどうかを判断しない。

【寮の一覧（名前と別名）】{dorm_list}
【フォームで選ばれた種類（ある場合）】{form_type}
【依頼の内容】{request_text}

「原因を書かない」を明記するのは、AIが親切に書き足すからです。 「エアコンが効かない」に「フィルターの清掃で改善する場合があります」と添えると、管理会社への依頼が、入居者の手入れ不足を示す文に読めてしまいます。 費用の負担の話し合いが、その一文から始まります。

「ほかの入居者の部屋番号を写さない」も同じ理由です。 「上の階の水漏れで天井が濡れた」という依頼は修繕ですが、上の階の部屋番号は、管理会社が現地で確かめれば足ります。 依頼の文に残すと、上の階の入居者が原因であるかのように伝わります。

出力形式を固定する

次の形の JSON を返させます。

{
  "request_id": "",
  "request_type": "repair",
  "form_mismatch": false,
  "dorm_as_written": "東寮",
  "dorm": "A寮",
  "room": "305",
  "part": "エアコン",
  "symptom": "冷房にしても風がぬるい",
  "since": "3日前から",
  "preferred_date": null,
  "entry_permission": "not_stated",
  "vendor_message": "A寮305号室。エアコンの冷房の風がぬるい。3日前から。"
}

1つ目の理由は、AIの分類と回す先の決定を別の層に置けることです。 JSON はAIが埋め、回す先はシナリオが対応表と規則で決めます。

2つ目は、dorm_as_written と dorm を両方持てることです。 入居者が書いた呼び方と、AIが当てた寮が並んでいれば、当て違いを受付の一覧で一目で見つけられます。

3つ目は、entry_permission で管理会社とのやり取りが1往復減ることです。 不在のときに部屋に入ってよいかが分かっていれば、管理会社は日程の連絡の前に修理に行けます。not_stated なら、入居者への受付の連絡で尋ねます。

システムへ連携する

ルーターのルートは、総務→入寮・退寮→修繕・備品→フォールバックの順に並べます。 公式のページでは、ルートは1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックのルートが処理するとされています。総務のルートを先頭に置くのは、living や食い違いのある依頼が、管理会社への自動送信まで流れないようにするためです。 ルートの条件は互いに重ならないように書きます。

管理会社への依頼のメールは、寮・部屋・部位・症状・立会いの可否だけにします。 入居者の氏名と連絡先は、管理会社との取り決めで要ると決めたものだけを足します。社員番号と所属は送りません。

入居者への受付の連絡は、送った先と受付の番号だけを書きます。 「X社に修理を依頼しました。受付番号 D-1027」。修理の日はまだ書きません。 決まるのは管理会社の返事の後です。

管理会社の返事は、別のラベルで受けます。 件名に受付の番号を入れてもらう取り決めにし、返事が来たら担当が受付の一覧の状態を「日程決定」に書き換えます。 管理会社に送ってから5日たっても状態が変わらない依頼は、毎朝のシナリオが一覧から拾って寮の担当に知らせます。第3章の（b）の「まだ来ない」を、入居者より先に総務が見つけるための仕組みです。

人が確認する

寮の担当が見るのは、総務へ回った依頼と、入寮・退寮の下書きと、急ぎの印です。

1. 急ぎの印を真っ先に見る … 知らせを開いて内容を読み、急ぎなら管理会社の緊急の番号に電話します。 急ぎでなければ印を外し、通常の流れに戻します
2. living を見る … 騒音や共用部の困りごとは、総務の中で対応を決めます。管理会社や相手の入居者に伝えるかは、ここで決めます
3. 食い違い・寮が決まらない依頼を見る … 入居者に聞き返すか、名簿を確かめて正しい寮に回し直します
4. 入寮・退寮の下書きを確かめる … 人事部の手続きの状況と日付が合っているかを見て送ります
5. 自動で送った分を流し見る … 毎夕、管理会社に送った依頼の件数と寮を一覧で見ます

修繕の費用をどちらが持つかは、この確認の中では決めません。 管理会社が現地で見た結果を受けて、総務が寮の規程に照らして決めます。

例外に対処する

上の4行が大半を占めます。 どれもAIの誤りではなく、フォームの作り方と対応表・名簿の持ち方の問題です。 食い違いが多いなら、フォームの選択の欄の言葉を、入居者が使う言葉に合わせて直すほうが早く効きます。

記録を残す

• 依頼の元の項目とメールの本文（引用を落とす前のもの）
• 急ぎの印が付いたかどうかと、付いた言葉、担当が開いた時刻
• 返ってきた JSON の全文と stop_reason
• 引いた対応表の行と名簿の行（そのときの値）
• 回した先と、管理会社・入居者に送った本文
• 担当が回し直した記録と、その理由

2つ目で担当が開いた時刻を残すのは、急ぎの網が働いているかを見るためです。 印が付いてから開くまでの時間が長い日があれば、知らせの届け方を見直します。

最後の行は、対応表とフォームを直す材料になります。 同じ理由の回し直しが続けば、別名の列か選択の欄が足りていません。