賃貸管理会社に紙やFAXで届く退去届・解約通知を読み取り、解約日・精算の条件・立会いの希望日を台帳に転記し、入居者への受付連絡の文案を作る

処理の起点を決める

15分おきの定時実行にします。 FAXは夜間にも届き、郵送のスキャンは午前にまとまって入ります。ファイルが入るたびに動かすと、複数ページのFAXが途中で処理されることがあるため、最後の更新から5分以上たったファイルだけを対象にします。

受け付けた日時は、この時点で記録します。 FAXは受信の日時、メールは受信の日時、郵送はスキャンした日ではなく開封した担当者が付けた到着日を使います。この日時が、契約上の解約日を数える起点になります。起点をどれにするかは、管理を受託しているオーナーとの取り決めに合わせて決めておきます。

処理済みの印は、台帳の下書きまで作れたときだけ付けます。途中で止まったものは、次の回にやり直します。

入力データを集める

質を決めるのは、契約の情報の「解約予告の条件」が項目になっているかです。 契約書の本文にしか書かれていなければ、スクリプトは日付を数えられません。最初の準備は、管理している契約の予告の条件を、「1か月前」「30日前」「2か月前（法人）」のような決まった値の項目にすることです。

連帯保証人と法人契約の担当部署も欠かせません。 差出人の照合は、この2つと契約者の氏名の3つで行います。

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

Enterprise Document OCR には、次の2つを指定して送ります。

Form Parser からは、次の2つを取ります。

手紙の形の届出には、欄がありません。 formFields がほとんど返らないページは、OCRの全文を生成AIに渡し、文章から項目を取り出させます。

契約の検索は、部屋番号と物件名を先に、氏名を後にします。 氏名から探すと、法人契約の社宅で入居している社員の名前が契約者の欄に無く、契約が見つかりません。

AIへ渡す前に整形する

1. 形式をそろえる … Document AI が受け付ける画像は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などで、HEIC は対応形式に含まれていません。 スマートフォンの写真は JPEG に変えます
2. むやみに圧縮しない … 非可逆の形式で小さくすると、読み取りの精度が落ちるとされています。変換は1回だけにします
3. FAXの送付状を分ける … 1ページ目が送付状のFAXは多く、届出の本体と分けて扱います。送付状の送信元の名前と番号は、差出人の照合に使います
4. 品質の足りないページを分ける … qualityScore が0.5を下回ったページは、不具合の種類とともに needs_retake の候補にします
5. 口座番号の領域を覆う … 「口座番号」「振込先」の欄の値は、Form Parser の結果からだけ取り、生成AIに渡す全文と画像からは塗りつぶします
6. 同じ届出の重複を落とす … FAXとメールで同じ届出が2回届くことがあります。物件・部屋・日付の組で重複を見つけます

5番目は、口座の値を生成AIが書き換える経路をなくすためです。 1桁の読み違いを「それらしい番号」に直されると、原本と見比べたときに気づきにくくなります。 口座はOCRの値と信頼度をそのまま見せ、担当者が画像で確かめます。

AIに処理させる

生成AIにさせるのは、届出の種類の判定と、決まった項目の取り出しだけです。

4行目で、日付を欄の名前と組で取り出すのが要点です。 書面には「退去日」「解約日」「引越し日」「鍵の返却日」が混在し、生成AIはそれを1つの「退去日」にまとめたがります。 まとめずに並べさせ、どの日付を契約上の解約日と比べるかはスクリプトが規則で選びます。

指示内容を固定する

あなたは賃貸管理会社の窓口で、入居者から届いた退去の届出を読む担当です。
渡された読み取り結果だけを見て、項目を取り出してください。
日付の計算や、解約が有効かの判断はしないでください。

【届出の種類】
- move_out : 退去届・解約通知
- withdraw : 前に出した解約の申し出を取り消す連絡
- other    : それ以外（修繕の依頼、更新の書類など）
other の書面からは項目を取り出さないでください。

【取り出す項目】
物件名、部屋番号、書面上の契約者名、署名した人の氏名、
差出人の立場（本人／同居人／連帯保証人／会社の担当／代理人／not_stated）、
書かれた日付のすべて（欄の名前か文中の言葉と組で）、
立会いの希望日と時間帯のすべて、退去後の住所と電話番号

【厳守事項】
- 記載がなければ status を missing にしてください。推測で埋めないでください。
- 日付は、欄の名前や文中の言葉（「退去日」「解約日」「鍵返却」など）と
  組にして、書かれたものをすべて並べてください。
  複数の日付を1つの退去日にまとめないでください。
- 「月末」「中旬」のように日が書かれていない場合は、日を補わず、
  書かれた言葉のまま text に入れ、date を空にしてください。
- 差出人の立場は、書面に書かれた言葉だけで決めてください。
  筆跡や文面の印象から本人かどうかを推測しないでください。
- 契約上の解約日、日割りの賃料、敷金の精算額を書かないでください。
- 口座番号は塗りつぶされています。補ったり推測したりしないでください。
- 日付は西暦（YYYY-MM-DD）に直し、元の表記を evidence に残してください。
- evidence には、根拠にした文字列をそのまま写してください。

【読み取り結果（ページごと、品質不足のページには印）】{pages}
【FAXの送付状から読んだ送信元】{fax_sender}
【受け付けた日時】{received_at}

「月末」を補わない指示が、いちばん効きます。 何も言わないと、生成AIは「3月末」を3月31日に直します。その月の末日が土日なら引越しの都合で前の金曜を指していることもあり、直した日付は書面の事実ではなくなります。

「筆跡から推測しない」も外せません。 生成AIは、契約者名と署名が同じなら本人と書きます。同じ名前を家族が書くこともあり、本人かどうかは書面の言葉と契約のデータでしか確かめられません。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。 要求の output_config.format に、type を json_schema として、スキーマを渡します。

{
  "notice_id": "",
  "doc_type": "move_out | withdraw | other",
  "property": { "name": "", "room": "", "status": "ok | missing | unreadable" },
  "parties": {
    "contract_holder": "", "signer": "",
    "sender_role": "tenant | cohabitant | guarantor | company | agent | not_stated",
    "evidence": ""
  },
  "dates": [
    { "label": "", "date": "", "text": "", "label_known": true, "evidence": "" }
  ],
  "inspection_requests": [ { "date": "", "slot": "am | pm | any", "evidence": "" } ],
  "forwarding": { "address": "", "phone": "", "status": "ok | missing" }
}

スキーマでは doc_type と sender_role を enum で固定し、日付には format の date を使います。 Claude の構造化出力は、minimum のような数値の制約や文字数の制約をサポートしないため、部屋番号の桁や日付の範囲はスクリプトの側で確かめます。

受け取ったあと、スクリプトが契約と照らした結果を足します。

{
  "contract_id": "",
  "received_at": "",
  "notice_rule": "1_month | 30_days | 2_months",
  "earliest_end_date": "",
  "written_end_date": "",
  "date_gap_days": 0,
  "sender_check": "holder | company_contact | not_holder | unknown",
  "account": { "value": "", "confidence": 0 },
  "verdict": "ready | needs_human | needs_retake"
}

written_end_date が契約上の最も早い解約日より前の場合が、受付で最も揉める形です。 予告の期間が足りていないことを入居者に伝える必要があり、伝え方は担当者が決めます。 連絡の下書きは出さず、needs_human にします。

システムへ連携する

台帳には下書きとして書き出します。 契約上の解約日、立会いの希望、退去後の連絡先、口座を入れた状態にし、担当者が確かめて登録するまで、退去の予定として扱いません。

受付連絡の下書きに入れるのは、受け付けた日、契約上の解約日、立会いの候補日、鍵の返却と公共料金の手続きの案内です。 敷金の精算額と原状回復の負担には触れません。どちらも立会いの後に決まることだからです。

人が確認する

1. needs_human を先に見る … 差出人が本人でないもの、予告の期間が足りないもの。本人への確認の電話か、委任状の依頼をします
2. 日付の並びを確かめる … dates の一覧と原本の画像を見て、どの日付を退去の日と読んだかが正しいかを確かめます
3. 口座番号を原本と見比べる … OCRの値と信頼度を見て、画像の該当箇所と1桁ずつ照らします
4. 台帳に登録し、受付連絡を送る … 下書きを直したところは記録します

3番目は全件で行います。 口座の誤りは敷金の誤送金に直結し、取り戻すのに入居者とオーナーの両方を巻き込みます。 信頼度が高くても省きません。

それ以外の項目は、根拠の文字列を流し見るだけにします。 書面を一から読み直す運用にすると、第10章の3分には収まりません。

例外に対処する

件数として多いのは、4行目です。 社宅の多い管理会社では、社員本人からの届出が日常的に届きます。法人の担当部署の連絡先を契約のデータに持たせておくと、確認が1本の電話で済みます。

記録を残す

• 届出の原本と、受け付けた日時と経路（FAX・メール・郵送）
• Document AI が返した結果の全文と、Claude API に渡した全文（口座を覆ったもの）と返ったJSON
• スクリプトが足した結果と、そのとき使った解約予告の条件と受付の規則の版
• 担当者が直した項目と、直す前と後の値
• 本人以外の届出について、確かめた方法（電話、委任状）と日時
• 受付連絡を送った日時と、その文面

受け付けた日時と規則の版は、後から解約日をめぐって入居者と行き違ったときの根拠になります。 いつ届いたものを、どの条件で数えたかが残っていれば、説明が一度で済みます。

直した項目の記録は、指示を直す材料にもなります。 同じ様式の届出で同じ日付の読み違いが続くなら、その様式の欄の名前を指示に書き足します。