司法書士事務所に届く不動産の決済の依頼メールから、物件・当事者・決済日・必要書類を案件票にそろえ、足りない情報の確認メールを作る

処理の起点を決める

受付用のアドレスへの新しいメールを1通ずつきっかけにします。 Gmail の New Email Matching Search は、検索条件に合う新しいメールを受け取ったときに動きます。検索条件には、受付用のアドレス宛てで、処理済みのラベルが付いていないものを書きます。

New Labeled Email を使わない理由があります。 ラベルの付いたスレッドに返信が足されたときにも動くため、依頼元とのやり取りが続くたびに同じ案件が何度も処理されます。 依頼の受付は新しいメールの1回だけにしたいので、検索条件で絞るほうを選びます。

処理が終わったメールには、最後の段で Add Label to Email で処理済みのラベルを付けます。 失敗したときはラベルを付けないので、処理済みのラベルの無いメールが、そのまま未処理の一覧になります。

入力データを集める

書類チェックリストは、事務所で決めているものを使います。 たとえば所有権移転では、登記識別情報（または登記済証）、売主の印鑑証明書、買主の住民票の写し、固定資産評価証明書、委任状、といった並びです。どの書類が要るかは案件ごとに司法書士が決めるので、この構成では「依頼メールに書類のことがどう書かれているか」を拾うだけにします。

印鑑証明書の発行日は、書かれていれば拾います。 書面で申請する場合、申請書や代理人の権限を証する書面に付ける印鑑に関する証明書は、作成後3か月以内のものでなければならないとされています。決済日と発行日の両方が分かれば、案件台帳の計算式で期限を過ぎていないかを出せます。期限の計算はAIにさせません。

添付ファイルの中身は、AIに読ませません。 契約書の写しや登記事項証明書が添付されていても、案件票に書くのは本文から拾える項目だけにし、添付があることを印にして、補助者が開きます。

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

同じ決済の案件は、物件と決済日の2つで引きます。 Lookup Spreadsheet Row は、主の検索列に加えて補助の検索列と値を指定でき、両方に合う行だけを探せます。 物件の地番を主、決済日を補助にします。地番が missing のときは引けないので、決済日と依頼元で引き直し、見つかったものは「同じかもしれない」として知らせます。

依頼元の一覧は、差出人のアドレスで引きます。 一覧に無いアドレスからの依頼は、新しい依頼元として補助者に知らせ、案件票の作成は続けます。

AIへ渡す前に整形する

1. 転送と自動の通知を外す … 検索条件で、事務所の内部の転送と、システムからの自動の通知を除きます
2. 引用された過去のやり取りを外す … 返信の形で届いた依頼は、本文の下に過去のメールが引用されています。引用の部分を残すと、前の案件の物件や日付を拾います
3. 署名を残す … 依頼元の担当者の名前と連絡先は、案件票の依頼元の欄に使います
4. 添付の有無を記録する … ファイル名だけを記録し、中身は渡しません
5. 1通に複数の決済が書かれていないかを見る … AIに件数を返させ、2件以上なら補助者に回します
6. 全角と半角をそろえる … 地番や家屋番号の数字は、案件台帳の検索に使うので形をそろえます

2番目が、この構成でいちばん効く前処理です。 依頼元は前の案件のメールに返信する形で新しい依頼を送ることがあり、本文の下には前の物件と決済日がそのまま残っています。 確実に効くのは、指示で「引用の部分を読まない」と書くことです。 加えて、主な依頼元のメールソフトが使う引用の区切りの文字列（「-----Original Message-----」など）を一覧にしておき、Zap の中でその手前だけを渡す設定を組めるかを、Zapier の画面の変換の機能で確かめます。区切りの書き方は依頼元ごとに違うので、外し切れなかった分を指示が受け止める、という二段構えにします。

AIに処理させる

させるのは、本文から決められた項目を抜き出し、項目ごとに書かれていたかどうかの印を付けることです。

物件の address_only が、この構成でいちばん大事な区別です。 住居表示は郵便が届く住所で、登記に使う地番とは別のものです。住居表示しか書かれていない依頼を filled にすると、地番の欄に住居表示が入ります。 区別して、依頼元に地番を聞く下書きに回します。

4行目は、法令上の義務に関わります。 犯罪による収益の移転防止に関する法律では、司法書士が顧客のために宅地または建物の売買に関する行為または手続の代理または代行を行う場合が対象とされ、顧客の本人特定事項や取引を行う目的などの確認を行わなければならないとされています。依頼メールに「本人確認済み」と書かれていても、それは依頼元の確認で、事務所の確認ではありません。 案件票のこの欄は、AIが埋めない欄にします。

指示内容を固定する

あなたは司法書士事務所の受付で、不動産の決済の依頼メールを案件票に転記する立場です。
メールの本文だけを読んで、項目ごとに値を抜き出してください。推測で補わないでください。

【読まない部分】
- 「-----Original Message-----」「〇〇 wrote:」「> 」で始まる行より下の、
  引用された過去のメール
- 署名より下の、広告や定型の注意書き

【項目と status】
各項目に status を付ける。
- filled ........ 本文に書かれている
- missing ....... 本文に書かれていない
- unclear ....... 書かれているが一つに決まらない（「来月中旬」「〇日か〇日」など）
- address_only .. 物件について、住居表示だけが書かれ、地番・家屋番号が無い

【厳守事項】
- 書かれていない項目は value を空にし、status を missing にしてください。
  他の項目や一般的な形から補って埋めないでください。
- 住居表示（〇丁目〇番〇号）を、地番や家屋番号として扱わないでください。
  住居表示だけなら status を address_only にしてください。
- 当事者の名前は、本文の表記をそのまま写してください。
  旧字体を新字体に直す、ふりがなから漢字を推測する、をしないでください。
- 日付は本文の表記をそのまま original に写し、解釈した日付を date に入れてください。
  曜日と日付が食い違うときは status を unclear にしてください。
- 書類については、本文に書かれていることだけを拾ってください。
  書かれていない書類は not_mentioned です。「届いていない」とはしないでください。
- 「本人確認済み」などの記載があっても、本人確認の状況の項目は作らないでください。
- 1通に複数の決済が書かれているときは、settlement_count に件数を入れ、
  最初の1件だけを抜き出してください。
- 書類がそろっているか、登記ができるかの判断を書かないでください。

【登記の種類ごとの書類の一覧】{checklist}
【依頼元の情報】{sender_profile}
【本文】{body}

「曜日と日付が食い違うときは unclear」は、転記の誤りの多くを入口で拾うための一文です。 依頼元が「10日（金）」と書いて、10日が木曜日だったということは珍しくありません。どちらが正しいかはAIにも補助者にも分からないので、依頼元に聞きます。

名前の表記を「そのまま写す」と書くのは、登記では文字の違いがそのまま問題になるからです。 「髙」と「高」、「邊」と「辺」を、AIは親切に一般的な字に直そうとします。

出力形式を固定する

Analyze and Return Data の出力の項目を、次の形で定義します。

{
  "settlement_count": 1,
  "registration_types": { "value": ["所有権移転", "抵当権設定"], "status": "filled" },
  "property": {
    "land": { "location": "", "lot_no": "", "status": "filled | missing | address_only" },
    "building": { "location": "", "house_no": "", "status": "" },
    "residential_address": ""
  },
  "parties": [
    { "role": "seller | buyer | mortgagee | debtor", "name": "",
      "address": "", "status": "filled | missing" }
  ],
  "settlement": { "original": "", "date": "", "time": "", "place": "",
                  "status": "filled | missing | unclear" },
  "documents": [
    { "name": "", "state": "received | arranging | not_mentioned" }
  ],
  "seal_certificate_issued": "",
  "attachments": [""],
  "questions": [""]
}

questions には、missing・unclear・address_only の項目と、not_mentioned の書類について、依頼元に聞く文を1つずつ入れます。

1つ目の理由は、案件台帳の列にそのまま書けることです。 項目ごとの status を列として持つと、台帳を missing で絞り込むだけで、聞き返しが済んでいない案件が並びます。

2つ目は、Paths の規則をこの項目だけで書けることです。

3つ目は、original と date を分けていることです。 補助者は本文の表記と解釈した日付を並べて見られ、「10日」が何月の10日かの解釈の誤りに気づけます。

システムへ連携する

決済日まで7日を切る案件は、案件台帳の計算式で印を付け、知らせのメールの件名の先頭に「至急」と付けます。 残りの日数の計算は台帳の側で行い、Paths はその印の値を見るだけにします。

聞き返しの下書きには、questions を箇条書きで並べ、依頼元の担当者の名前を宛名に入れます。 補助者が直して送ります。依頼元が回答を返信してきたら、それは同じスレッドへの返信になるので、この Zap は動きません。 回答は補助者が読んで案件票に書きます。

人が確認する

補助者は、すべての案件票をメールの本文と見比べて確かめます。 書く作業は無くなりますが、確かめる作業は残します。

1. 物件の欄を最初に見る … 地番と家屋番号が本文の表記どおりか、address_only が正しく付いているか
2. 決済日の original と date を見比べる … 月と日、曜日
3. 当事者の名前の字を見る … 本文の表記と一字ずつ
4. 聞き返しの下書きを直して送る … 依頼元との関係に合わせて文面を整えます
5. 取引時確認の段取りは司法書士に渡す … 案件票のこの欄は人が埋めます

1番目と3番目は省かないでください。 物件と名前の誤りは、登記の申請の準備の段まで気づかれずに進むものです。入口で見るのが最も安くつきます。

目標は、180件をならして1件6分です。 書かれていることが多い依頼は2〜3分、聞き返しの多い依頼は10分前後かかります。

例外に対処する

2行目は、依頼元の癖として毎月同じ相手から来ます。 依頼元の一覧の「ふだんの書き方」の列に記録しておき、その依頼元には本文に主な項目を書いてもらうよう、一度頼んでみるのが根本の対策です。

記録を残す

• 依頼メールの原文（受付用の Gmail。これまでどおり）
• AIの出力（項目ごとの値と status、questions）
• 補助者が直した箇所 … どの項目を、どの値に直したか
• 聞き返しの送信日時と、依頼元からの回答の日時
• 同じ決済として扱った案件の対応 … どのメールをどの案件の追加の連絡としたか
• Zap の実行の履歴（成功・失敗）

3つ目の記録は、依頼元ごとの癖を知る材料になります。 特定の依頼元だけ物件の欄の直しが多いなら、その依頼元は住居表示で書く習慣だと分かり、最初の聞き返しに地番の確認を入れておけます。