管理物件の入居者対応の記録から、オーナーへの月次報告の下書きを物件ごとに作る

処理の起点を決める

月初、入出金の締めが終わったことを起点にします。 滞納の有無は締めの後でないと確定しないため、日付で自動起動させず、担当者がCSVを出力した時点で始めます。 締めの前に動かすと、月末に入金された家賃が滞納として報告に載ります。

CSVを決められたフォルダに置くと、スクリプトが動きます。出力する期間は前月1日から末日までで、スクリプトは期間が1か月分であることを最初に確かめます。 期間を取り違えたCSVで120物件分を作ると、全件を作り直すことになります。

報告を出さない物件（オーナーの意向で四半期ごとにしている物件など）は、物件ごとの設定で外します。

入力データを集める

いちばん下の「前月の報告」が、第3章の（d）を防ぎます。 前月に持ち越した事項を今月の入力に入れ、今月の記録で片付いたか、まだ続いているかを書かせます。 担当者が替わっても、持ち越しは機械の側で引き継がれます。

入出金は、AIに渡しても文章には使わせません。 滞納の有無を「あり／なし」だけ渡し、金額は数字の表の側にだけ入れます。

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

管理システムの画面から、対応履歴・修繕・契約・入出金の4種類をCSVで出力します。出力の項目と順序を固定したテンプレートを管理システム側に保存しておきます。 担当者ごとに出力の設定が違うと、スクリプトが読めません。

管理システムにAPIがある場合は、CSVの代わりにAPIで取る構成もできます。ただし、その可否と取れる項目は管理システムごとに違うため、個別の確認が必要です。 本記事ではCSVの出力を前提にします。

AIへ渡す前に整形する

1. 期間の確認 … CSVの受付日が前月の範囲に収まっているかを見ます。外れた行があれば止めます
2. 物件ごとにまとめる … 物件コードで4種類のCSVを1つにまとめます
3. 氏名と連絡先を落とす … 入居者の氏名、電話番号、メールアドレスの列を削除します。内容の欄に書き込まれた氏名や電話番号も、パターンで探して伏せます
4. 部屋番号を仮番号に置き換える … 「203号室」を「部屋R3」のように置き換え、対応表はスクリプトの手元だけに持ちます
5. 分類ごとに件数を数える … 連絡の件数、修繕の件数と金額、空室数はここで数え、AIへ渡す前に数字の表を作っておきます
6. 記録が多い物件を確かめる … 連絡が極端に多い物件は、分類ごとに並べ直してから渡します
7. 前月の持ち越し事項を付ける … 前月の出力JSONから carry_over を読み、入力に加えます

3番目の「内容の欄」を軽く見ないでください。 窓口は「田中様より、203の上の階がうるさいと」のように内容の欄へ書きます。列を消すだけでは、氏名は外へ出ます。

5番目で数字を先に作るのは、AIに数えさせないためです。 件数を数え間違えた報告は、数字の表と本文で食い違います。数字はスクリプトが数え、AIは文章だけを受け持ちます。

入力の並べ方は、長い資料の扱いに関する公式の指針に合わせます。 長い資料は指示より前、プロンプトの上のほうに置き、問い（指示）は最後に置くと、複雑な複数の資料で応答の質が最大30％上がったとされています。資料は <document> タグで包み、<source> などの情報を付けます。記録の多い物件ほど効きます。

AIに処理させる

させるのは、5つの欄それぞれについて、記録から言えることだけを短く書くことです。

それぞれの文には、根拠にした記録の番号（record_ids）を付けさせます。 担当者は下書きを読みながら、その番号の記録だけを開けば確かめられます。公式の指針でも、長い資料では先に関係する部分を引用させてから本題に入ると、関係のない部分を無視しやすくなるとされています。

指示内容を固定する

<documents>
  <document index="1">
    <source>対応履歴（{property_code}／{period}）</source>
    <document_content>{inquiries}</document_content>
  </document>
  <document index="2">
    <source>修繕</source>
    <document_content>{repairs}</document_content>
  </document>
  <document index="3">
    <source>契約（退去予定・入居・募集）</source>
    <document_content>{leases}</document_content>
  </document>
  <document index="4">
    <source>滞納の有無（あり／なしのみ）</source>
    <document_content>{arrears_flags}</document_content>
  </document>
  <document index="5">
    <source>前月からの持ち越し事項</source>
    <document_content>{carry_over}</document_content>
  </document>
</documents>

あなたは賃貸管理会社の担当者として、物件のオーナーへ送る月次報告の文章を書きます。
上の記録だけを根拠に、5つの欄の文章を作ってください。

【欄】
1. inquiries ...... 入居者からの連絡の傾向と対応の結果、未完了のもの
2. repairs ........ 修繕の手配の内容と状況、オーナーの承認待ちの見積
3. leasing ........ 退去予定、入居、募集の状況
4. arrears ........ 滞納があるかないか、督促の対応状況
5. owner_decisions  オーナーに判断してほしい事項

【厳守事項】
- 金額・件数・日数などの数字を文章に書かないでください。
  数字は別の表に入ります。「複数」「いくつか」とも書かず、事実だけを書いてください。
- 部屋は「部屋R3」のような仮の番号のまま書いてください。
  号室に直したり、階や位置を補ったりしないでください。
- 入居者の家族構成、体調、勤め先、近隣とのもめごとの相手など、
  人を特定できる事情は書かないでください。「入居者間の生活音」のように書きます。
- 記録にないことを推測で書かないでください。
  「おそらく」「〜と思われる」「近く退去の可能性」は使わないでください。
- 記録が無い欄は「今月の記録はありません」と書いてください。空にしないでください。
- 修繕が必要かどうか、どの業者がよいかを判断しないでください。
- 前月からの持ち越し事項は、今月の記録で片付いたものは resolved、
  続いているものは open として carry_over_status に必ず全件を書いてください。
- 各文には、根拠にした記録の番号を record_ids に入れてください。
  根拠の番号が無い文は書かないでください（「今月の記録はありません」だけは空で可）。
- 1つの欄は200字以内、です・ます調で書いてください。

「数字を書かない」は、「複数とも書かない」まで言わないと守られません。 数字を禁じると「3件」の代わりに「複数件」と書き、表の件数が1件のときに食い違います。

記録を先に、指示を後に置いているのは、公式の指針に合わせたものです。 記録の多い物件では、欄の定義が記録の後ろにあるほうが、どの欄に何を書くかを取り違えにくくなります。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "property_code": "P-0412",
  "sections": {
    "inquiries":       [{ "text": "", "record_ids": [""] }],
    "repairs":         [{ "text": "", "record_ids": [""] }],
    "leasing":         [{ "text": "", "record_ids": [""] }],
    "arrears":         [{ "text": "", "record_ids": [""] }],
    "owner_decisions": [{ "text": "", "record_ids": [""] }]
  },
  "carry_over_status": [
    { "item_id": "", "status": "resolved | open", "note": "" }
  ],
  "needs_attention": false,
  "attention_reason": ""
}

スキーマでは5つの欄と carry_over_status をすべて required にし、オブジェクトは additionalProperties: false にします。status は enum で resolved と open に限ります。

1つ目の理由は、欄が抜けないことです。 必須の項目と型が守られるため、「修繕の欄を書き忘れた下書き」は出てきません。記録が無い欄にも「今月の記録はありません」が入ります。

2つ目は、文と根拠を1対1で持てることです。 record_ids があるので、担当者は下書きの1文ごとに元の記録へ戻れます。自由文で受け取ると、どの記録から書いたのかを探し直すことになります。

3つ目は、スクリプトが検査しやすいことです。 各欄の text を取り出して、数字、「号室」、禁止語を探せます。スキーマで守れない文字数と数字の混入は、ここで検査します。 なお、公式ドキュメントでは、応答の拒否や stop_reason が max_tokens の場合にはスキーマに合わない出力になりうるとされているため、stop_reason も必ず見ます。

needs_attention は、AIが「この物件は担当者がよく読むべき」と判断したときに立てます。 記録どうしが矛盾している、持ち越し事項の扱いが分からない、といった場合です。

システムへ連携する

バッチの結果は、投入した順に返ってくるとは限りません。 公式ドキュメントでも、結果は作成時の順序と一致しないことがあり、custom_id で突き合わせるよう書かれています。custom_id には物件コードを入れます。 使えるのは英数字とハイフン、アンダースコアで1〜64文字なので、物件コードに日本語が入る管理システムでは、スクリプト側で変換表を持ちます。

部屋の仮番号は、ひな形に流し込むときに戻します。 物件ごとの設定で「部屋番号を出す」としている物件だけ、R3を203号室に置き換えます。「出さない」物件では、仮番号の表記を消して文を整えます。

人が確認する

1. needs_attention の物件と、検査で止まった物件を先に読む … ここに時間を使います
2. 判断してほしいことの欄を確かめる … 見積の承認待ちが漏れていないかを、修繕の画面の「承認が要る」案件と見比べます
3. 書きすぎを消す … 入居者を特定できる書き方が残っていないかを読みます。部屋番号を出す物件では特に
4. 持ち越し事項の扱いを確かめる … resolved にされたものが本当に片付いたか
5. 上長が目を通して送る … 送信は担当者が行います

2番目を省かないでください。 オーナーにとって報告書でいちばん大事なのは、自分が何を決めればよいかです。承認待ちが漏れると、修繕が1か月遅れます。

目標は1物件12分です。 記録を読み返す時間が無くなり、下書きを読んで直す時間だけが残ります。

例外に対処する

バッチには24時間の期限があります。 多くは1時間以内に終わるとされていますが、需要によっては遅れ、24時間を過ぎた分は expired になります。月初の数日で報告を出すなら、締めの当日に投入します。

記録を残す

• 出力したCSVと、前処理の後にAIへ渡した入力（氏名を落とした後のもの）
• 部屋番号と仮番号の対応表（社内だけに置く）
• バッチのIDと、物件ごとの結果のJSON全文
• 検査で止まった物件と、その理由
• 担当者が直す前の下書きと、送った報告書のPDF
• 担当者が直した箇所の記録 … どの欄を、どう直したか

バッチの結果は作成から29日で取り出せなくなります。 公式ドキュメントにあるとおり、バッチ自体は見られても結果はダウンロードできなくなるため、結果のJSONは受け取った時点で自社の保存先へ移します。 翌月の持ち越し事項は、このJSONから読みます。

最後の行は、指示を直す材料です。 毎月同じ欄で同じ直しが入るなら、プロンプトに1行足します。