不動産鑑定事務所に届く鑑定の依頼メールから、物件・依頼目的・価格時点・提出期限を整理して、受付票と見積の下書きを作る

処理の起点を決める

依頼のメールに「鑑定依頼」のラベルが付いたことを起点にします。 ラベルは Gmail のフィルタで付けます。条件は、件名や本文の「鑑定」「評価」「価格調査」「時価」の語と、取引のある金融機関・税理士事務所のドメインの組み合わせです。事務の担当者が手でラベルを付ける運用にはしません。 手で付けると、付け忘れた依頼がそのまま漏れます。

フィルタに当たらなかった依頼は、事務の担当者が同じラベルを手で付けて流れに乗せます。 初めての依頼者の短いメールは、語にもドメインにも当たらないことがあります。

New Labeled Email を選ぶ理由は、検知できる期間に制限が無いからです。 New Email と New Email Matching Search は1時間とされ、Zapier の側が一時的に止まっていたときに取りこぼす余地があります。依頼の取りこぼしは、金融機関の審査日に間に合わないことに直結します。

そのかわり、同じ会話に返信が足されたときにも動きます。 依頼者が「添付を追加します」と返信してきたり、事務の担当者が転送したりすると、もう一度 Zap が動きます。Zap の最初の段で受付台帳を Find Records で引き、同じスレッドの記録があれば、新しい記録は作らずに「追加の連絡あり」の印だけを付けます。

入力データを集める

質を決めるのは、依頼目的の一覧の書き方です。 依頼者は「融資の参考に」「遺産分割の協議で使う」「裁判所に出す」「減損の検討に」と書き、「担保評価」「相続」「訴訟」「会計」とは書きません。 一覧には、目的の名前と一緒に依頼者がよく使う言い回しを並べます。ガイドラインが依頼目的の例として挙げる、売買の参考、担保評価、不動産投信等の保有資産の調査、棚卸資産の低価法適用、賃貸等不動産の時価評価、訴訟に使用するための調査を、事務所で多い順に並べ直して使います。

添付ファイルの中身は渡しません。 登記事項証明書や公図は、鑑定士が確認書を作るときに自分で読む資料です。受付の段では、本文に書かれた所在と地番を写すだけにし、添付があったかどうかは事務の担当者が見て台帳に印を付けます。

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

データはトリガーが返す依頼のメールの中にあります。 別のシステムから取ってくるのは、受付台帳と報酬表だけです。

AIへ渡す前に整形する

1. 重複の確認 … スレッドIDで受付台帳を引き、記録があれば「追加の連絡あり」の印だけ付けて止めます
2. 引用部分を落とす … 返信の形で届いた依頼は、過去のやり取りが引用として下に続きます。「>」で始まる行と、「〜wrote:」「〜のメッセージ:」の行から下を落とします
3. 署名の扱い … 署名は依頼者の所属を写すのに要るので残します。ただし、電話番号と携帯番号は AI のステップに渡す前に消します
4. 本文の長さを見る … 事件の経緯が長く書かれた依頼は、本文の前半と後半で価格時点と期限が離れます。本文を切り詰めず、全文を渡します

4番目は、法律事務所の依頼で効きます。 経緯の最後に「相続開始日時点の価格について」と書かれていることがあり、前半だけを渡すと価格時点が落ちます。

AIに処理させる

させるのは、項目ごとに「書かれているか」と「その原文」を写し出し、書かれていない項目を挙げることだけです。 項目は、ガイドラインが確定を求める事項のうち、依頼のメールに書かれうるものを選んでいます。

価格時点と提出期限は、どちらも日付への言い換えをさせません。 「相続開始日時点」「決算期末」「来月末まで」のような書き方を日付に直させると、今日の日付や相続開始日の取り違えで、ずれた日付が台帳に載ります。 原文のまま鑑定士に見せれば、鑑定士が読み違えることはありません。

4行目は誤りやすいところです。 鑑定の前に事務所の名前で出た数字は、鑑定の結論の代わりに使われかねません。

指示内容を固定する

1つ目のステップ（Analyze and Return Data）の指示：

あなたは不動産鑑定事務所で、鑑定評価の依頼を受け付ける事務の担当者です。
依頼のメールの本文に書かれていることだけを使って、項目を埋めてください。
推測で埋めないでください。書かれていなければ not_stated にしてください。

【依頼目的】下の一覧から1つ選び、選んだ根拠の文を purpose_evidence に
そのまま写してください。当てはまらなければ other にしてください。
- 担保評価：融資・借換え・担保の見直し。「融資の参考に」「担保として」
- 売買の参考：購入・売却・交換の検討。「売却を検討」「買取の価格」
- 相続・贈与：遺産分割、相続税、贈与。「遺産分割の協議で」「相続税の申告」
- 訴訟：裁判所への提出、調停、紛争。「裁判所に提出」「調停で使う」
- 会計：減損、賃貸等不動産の時価、棚卸資産の評価。「減損の検討」「注記」

【価格時点と提出期限】
- 価格時点は「いつの時点の価格を求めるか」の記載です。
- 提出期限は「いつまでに報告書がほしいか」の記載です。
- 2つを取り違えないでください。どちらか判断できない日付は、
  date_unclear にその文を写してください。
- 日付への言い換え、曜日の補足、残りの日数の計算をしないでください。
  原文のまま写してください。

【厳守事項】
- 価格の種類、条件の設定、報酬の額、価格の見当を書かないでください。
- 所在・地番は本文の表記のまま写してください。住居表示を地番に
  直したり、番地を補ったりしないでください。
- 利用者の範囲は、成果報告書の提出先や開示先として書かれた名前だけを
  写してください。依頼者の所属を提出先として扱わないでください。
- missing_items には、not_stated になった項目の名前を並べてください。

【依頼のメールの件名】{subject}
【依頼のメールの本文】{body}

2つ目のステップ（足りない項目を尋ねる返信の下書き）の指示：

不動産鑑定事務所から、鑑定評価のご依頼をくださった方への最初の返信を
書いてください。次のことだけを書いてください。
- ご依頼のお礼と、内容を受け付けたこと
- 受け付けた内容の確認（物件の所在、依頼目的、価格時点、提出期限を、
  下の値のとおりに並べる。not_stated のものは並べない）
- 見積と確認書を作るために、下の「お尋ねしたいこと」を伺うこと
- 担当の鑑定士から改めて連絡すること
書かないこと：価格の見当、報酬の額、提出期限に間に合うかどうか、
鑑定の進め方。依頼をお受けするとも書かないでください。
【受け付けた内容】{property} ／ {purpose} ／ {value_date_text} ／ {deadline_text}
【お尋ねしたいこと】{questions}
【依頼者の氏名】{client_name}

2つ目の「お尋ねしたいこと」は、AIに考えさせず外から渡します。 missing_items の項目ごとに、事務所で決めた質問文を Lookup Table で引いて並べます。たとえば利用者の範囲が足りなければ「成果報告書をご提出になる先と、ほかに開示のご予定があればお知らせください」。鑑定士が言い回しを決めておけば、確認書に要る形で答えが返ってきます。

「依頼をお受けするとも書かない」を明記するのは、利害関係の確認が済んでいないからです。 受付の返信で「お引き受けします」と書くと、利害関係が見つかったときに断りにくくなります。

出力形式を固定する

1つ目のステップの出力は、Analyze and Return Data の出力項目として次のように定義します。

項目に分けて受け取る理由の1つ目は、区分の引き当てにそのまま使えることです。 property_type と purpose をつないだ「土地＋担保評価」のような文字列を Lookup Table のキーにすると、AIの文章を読み解く処理を挟まずに区分コードが決まります。 表に無い組み合わせは fallback の「要相談」に落ち、見積の下書きには区分を入れずに鑑定士へ回します。

2つ目は、missing_items と date_unclear で確認が速くなることです。 事務の担当者は受付台帳で、足りない項目と、価格時点か期限か分からなかった文を先に見られます。date_unclear が入っている依頼は、返信の下書きを作らずに鑑定士へ回します。

見積の下書きには、区分コード・区分の名前・基本の報酬と加算の条件の説明を差し込みます。 加算の有無と最終の額は空欄のまま鑑定士に回します。

システムへ連携する

返信は下書きまでにし、Send Email は使いません。 Gmail の説明でも、Create Draft と Create Draft Reply は送らずに下書きを作る操作とされています。依頼者へ出るものは、事務の担当者と鑑定士が見てから送ります。

見積の下書きは、受付台帳の行にリンクを書き戻します。 鑑定士は受付台帳から、写し出された項目・足りない項目・見積の下書きを1か所で見られます。見積書を PDF にして送るのは、鑑定士が額を決めた後です。

人が確認する

1. 写し出された項目を原文と見比べる … 事務の担当者が、所在・依頼目的・価格時点・提出期限を本文と見比べます。価格時点と提出期限が入れ替わっていないかを最初に見ます
2. 足りない項目と返信の下書きを確かめる … 尋ねる内容が足りない項目と合っているかを見て、鑑定士に回します
3. 利害関係と受けるかどうかを判断する … 鑑定士が、依頼者・提出先・対象不動産との関係を確かめます。この判断はこの構成の外で行います
4. 見積の額を決める … 鑑定士が区分と加算を見て額を決め、見積書を確定します
5. 送る … 事務の担当者が見積書と返信を送り、受付台帳の状態を更新します

1番目を省かないでください。 価格時点と提出期限の入れ替わりは、見積の段では誰も気づかず、確認書か成果報告書の段で見つかります。

目標は、80件をならして1件6分です。 6分を大きく超える月は、依頼目的の一覧の言い回しが足りていません。

例外に対処する

4行目は、金融機関の依頼で起きます。 共同担保の複数の筆を1件の受付票に押し込むと、見積の区分も確認書も1件分になります。

記録を残す

• 依頼のメールのスレッドID、受信日時、送信者、件名
• AI のステップが返した項目の全文（value_date_text、deadline_text、purpose_evidence など）
• 引き当てた区分コードと、そのときの報酬表の行
• 見積の下書きと返信の下書きのリンク
• 事務の担当者と鑑定士が直した記録 … どの項目を、何から何へ直したか
• 状態の履歴（受付、確認待ち、見積送付、受任、辞退）と、その日時

3つ目で「そのときの報酬表の行」を残すのは、報酬表が改定されるためです。 改定の前後で同じ区分コードの基本の報酬が変わり、当時の値が残っていないと、見積の額の根拠を後から説明できません。

5つ目が、依頼目的の一覧を育てる材料です。 直された purpose を月に一度数え、多い言い回しを一覧に足します。