賃貸管理会社に物件のオーナーから届くメールを、修繕の承認・送金の明細・募集条件・解約や売却の相談に分類して担当へ回し、返事の要るものを期限付きで台帳に載せる

処理の起点を決める

Watch emails を10分ごとに動かします。 対象は「オーナー窓口」のラベルが付いた未読のメールです。取り込んだときに既読にする設定にはしません。 窓口の担当が受信箱で未読のまま見られるようにし、処理が済んだかどうかは「振り分け済み」の別のラベルで示します。

1日1回のまとめての処理にはしません。 修繕の承認の返事は、オーナーが承認した時点から業者の手配が始められます。夕方にまとめて振り分けると、給湯器の故障で入居者がお湯を使えない時間が半日延びます。 解約の相談も、届いた日に店長が電話をかけられるかどうかで話の流れが変わります。

オーナーの一覧に無いアドレスから届いたメールも、窓口の宛先に来る以上は拾います。 Gmail のフィルターで「オーナー窓口」のラベルが付かないので、別に「宛先がオーナー窓口のアドレスで、ラベルが無い」メールを拾う2本目の Watch emails を置き、すべて確認の列に回します。 家族の代理や、オーナーが新しいアドレスから送ってきたメールがここに入ります。

入力データを集める

AIに渡すのは、メールの本文と、そのオーナーの物件の名前の一覧だけです。 物件の一覧を渡すのは、「例の駅前のアパート」「2号棟」といった書き方から物件を推し量る手がかりにするためです。オーナーの住所や口座、送金の金額は渡しません。 分類には要らないからです。

直近のやり取りは、AIには渡さずワークフローの側で使います。 「先日の件、お願いします」という返事が、どの見積への返事かを決めるのは、台帳の済んでいない行と、メールのスレッドのIDの突き合わせです。AIに過去の行を読ませて推し量らせると、別の見積を承認したことにしてしまいます。

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

オーナーは、差出人のアドレスで決めます。 オーナーの一覧を Search Rows で引き、メールアドレスの列が一致する行を探します。本文の署名に書かれた名前では決めません。 家族の代理のメールで、署名にオーナーの名前が書かれていないことがよくあります。

オーナーの一覧には、1人のオーナーに複数のアドレスを持たせます。 私用と仕事用、家族の代理のアドレスを別の列ではなく別の行にし、どの行もオーナーのコードでまとまるようにします。Search Rows の条件をアドレスの1列だけにできるので、設定が単純になります。

スレッドのIDも取っておきます。 こちらから送った修繕の見積のメールのスレッドIDを、送ったときに台帳の行に入れておけば、オーナーの返事がどの見積への返事かを、IDの一致で決められます。 見積を送るシナリオを別に組めない場合は、件名の見積番号を手がかりにし、見つからなければ確認の列に回します。

期限の規則の表は、シナリオの最初に1回だけ読みます。 区分の数は5つで表は小さいので、1通ごとに引き直す必要はありません。規則を変えたいときは、表を書き換えるだけで次の実行から効きます。

AIへ渡す前に整形する

1. 引用の除去 … 返事のメールに付いている、こちらが送った見積や送金明細の本文を外します。引用の中の「ご承認をお願いします」を、オーナーの言葉として読ませないためです
2. 署名と定型文の除去 … 「このメールは送信専用です」のような自動の文や、長い署名を外します
3. 本文の長さの確認 … 極端に長いもの（相続の経緯を細かく書いたものなど）は、そのまま確認の列に回します。長い相談ほど、人が最初から読むべきものだからです
4. 添付の確認 … 添付があれば「添付あり」とファイル名だけをAIに伝えます。写真や書類の中身は読ませず、人が見ます
5. 自動の通知の除外 … 金融機関の通知や広告など、オーナーのアドレスから自動で転送されてくるものを、件名の語で外します

1番目を省くと、いちばん困る誤りが起きます。 「承知しました」だけのオーナーの返事に、こちらが送った見積の本文が引用で付いていると、AIが引用の中の金額や工事の内容を読み、オーナーが具体的に承認したかのような根拠の文を書きます。 引用は Gmail の本文の中で「>」で始まる行や、「〜様からのメール」の行より下を外す形で落とします。

AIに処理させる

させるのは、本文を用件ごとに分け、それぞれに区分と根拠の文を付けることです。

修繕の承認には、さらに3つの返事の型を付けます。 approve（承認）／hold（保留・質問）／reject（断り）です。第3章の（b）がこの区別で、急いで読むといちばん取り違えやすいところです。 業者を手配してよいのは approve だけで、それも人が見積と照らしてから手配します。

返事の要否は、オーナーが何かを求めているかで決めさせます。 質問、依頼、相談があれば true、承認や「承知しました」だけなら false です。ただし approve は返事が要らなくても、業者の手配という次の作業があるので、台帳には載せます。

3行目がいちばん守らせたいことです。 同じオーナーが同じ週に2件の見積を受け取っていることは珍しくなく、「お願いします」だけの返事をどちらか一方に結び付けると、オーナーが承認していない工事を発注しかねません。

指示内容を固定する

あなたは賃貸管理会社のオーナー窓口で、物件のオーナーから届いた
メールを用件ごとに分ける担当です。本文に書かれていることだけで判断し、
推測で補わないでください。

【用件の区分】
- repair ....... 修繕の見積・故障の連絡への返事
- remittance ... 送金額・管理料・差し引いた費用、送金明細についての質問や依頼
- leasing ...... 賃料・敷金・広告料・入居条件、空室についての返事や相談
- termination .. 管理の解約、物件の売却・相続・建て替えについての相談
- other ........ 上のどれにも当たらないもの
迷ったときは other にし、reason にどの区分と迷ったかを書いてください。

【用件の分け方】
- 1通に複数の用件があれば、用件ごとに items に分けてください。
  「ところで」「それと」「別件ですが」の後は、別の用件として扱ってください。
- 引用（> で始まる行など）は渡していません。渡された本文だけを見てください。

【repair の返事の型】
- approve .. 見積や提案の内容で進めることをはっきり書いている
- hold ..... 質問、値下げの相談、検討中、家族と相談する、など
- reject ... 進めないことをはっきり書いている
「お願いします」「よろしく」だけで何をお願いしているかが書かれていなければ
approve にせず hold にしてください。

【厳守事項】
- evidence には、判定の根拠にした文を本文からそのまま写してください。
  言い換えたり要約したりしないでください。
- 物件は、本文の書き方をそのまま property_hint に写し、
  物件の一覧のうち当たりそうなものを property_candidates に挙げてください。
  1つに決められなければ、候補を全部挙げてください。決めつけないでください。
- オーナーが日付や期限を書いていれば、owner_date_text にそのまま写してください。
  日付に直したり、期限を計算したりしないでください。
- 対応の期限、担当者、返事の文面は書かないでください。
- 解約・売却・相続・建て替えに触れる文が1つでもあれば、
  その用件を termination にしてください。
  「考えている」「迷っている」程度の書き方でも termination です。

【メールの件名】{subject}
【本文（引用・署名を除いたもの）】{body}
【添付】{attachments}
【このオーナーの物件の一覧】{properties}

「お願いします」だけでは approve にしない、を明記しないと approve になります。 オーナーの短い返事の多くは「よろしくお願いします」で、AIは前後の文脈から見積の承認と読みたがります。承認の判断を、オーナーがはっきり書いた文だけに置きます。 迷った分は hold で窓口に回り、人がスレッドを開いて確かめます。

「考えている程度でも termination」と書くのは、取りこぼしのほうが重いからです。 解約の相談を other に入れると、第3章の（c）がそのまま残ります。店長が「まだ雑談の段階だ」と判断して閉じる手間は、取りこぼしよりずっと軽く済みます。

出力形式を固定する

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

{
  "items": [
    {
      "category": "repair | remittance | leasing | termination | other",
      "repair_response": "approve | hold | reject | none",
      "summary": "",
      "evidence": "",
      "property_hint": "",
      "property_candidates": [""],
      "reply_needed": true,
      "owner_date_text": "",
      "reason": ""
    }
  ],
  "language_note": ""
}

1つ目の理由は、用件の数だけ要素が並ぶことです。 items を配列にしておけば、Iterator がそのまま1件ずつに分け、Router が区分ごとに担当へ流せます。 用件が1つなら要素が1つ、3つなら3つです。

2つ目は、区分を enum で縛れることです。 構造化出力のスキーマでは enum で値の候補を決められ、オブジェクトには additionalProperties: false を付けます。「修繕・送金」のような区分の造語や、区分の書き間違いが出ないので、Router のフィルターが外れません。

3つ目は、evidence で窓口の確認が速くなることです。 台帳の行に根拠の文が並んでいれば、メールを開かなくても区分が合っているかが分かります。 違えばそこで直し、開くのは迷ったものだけです。

対応台帳には、AIの出力にワークフローが決めた列を足して1行にします。

オーナーの希望の日付は、原文のまま別の列に置きます。 「来週中に」「月末までに」を日付に直すのは、窓口の担当が見て決めます。規則の期限より早い希望が書かれていれば、台帳の行を目立つ色にする条件付き書式を置き、人に気づかせます。

システムへ連携する

賃貸管理システムには書き込みません。 修繕の発注、送金の訂正、募集条件の変更は、それぞれの担当が賃貸管理システムで行います。この構成が出すのは、誰がいつまでに何をするかの一覧までです。

通知には、メールの本文を貼りません。 台帳の行へのリンクと、区分と要点だけを送ります。オーナーの送金の質問の本文が、関係の無い担当まで並ぶチャットに流れないようにするためです。

人が確認する

1. 確認の列を先に見る … オーナー不明、区分が other で迷いがあるもの、termination、hold の修繕。窓口の担当が朝と昼過ぎに見ます
2. 台帳の新しい行を流し読む … 区分と根拠の文が合っているかを見て、違えば区分と担当を直します
3. 修繕の approve は見積と照らす … 建物管理の担当が、スレッドの見積番号と金額を確かめてから業者に手配します
4. termination は店長が開く … メールを最初から読み、電話するか、訪問するかを決めます
5. 直した記録を残す … 区分を変えたら、元の区分と変えた理由を台帳の列に書きます

3番目を省かないでください。 approve はオーナーがはっきり承認した文がある、というだけの印です。どの見積の、いくらの工事かを確かめるのは、手配する人の仕事です。

目標は、600件をならして1件2分です。 大半は台帳で根拠の文を流し読むだけで済み、確認の列に回るのは2割前後という想定です。 それより多い月は、オーナーの一覧のアドレスが古くなっているか、新しい書き方の用件が増えています。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの精度ではなく、オーナーの一覧と、見積を送ったときのスレッドIDの控え方の問題です。 一覧のアドレスを最新に保つほうが、指示を書き足すより効きます。

記録を残す

• 受信したメールのID、受信日時、送信者、スレッドID
• AIに渡した本文（引用・署名を外した後のもの）と、AIが返したJSONの全文
• 対応台帳の行（区分、担当、期限、状態）と、状態を変えた日時と人
• 窓口の担当が区分や担当を直した記録 … 元の区分、直した区分、理由
• 確認の列に回った理由（オーナー不明、物件不明、termination など）

4つ目は、指示を直す材料になります。 同じ区分の取り違えが続くなら、その書き方を指示の区分の説明に足します。

状態の変わった日時は、返事の遅れを見る材料になります。 区分ごとに、受信から 済 までの日数を月ごとに数えると、どの担当で止まりやすいかが一覧で分かります。