競売物件情報サイト（BIT）で毎週出る新着物件の3点セットを n8n で読み、仕入れの条件に合う物件を選んで要点と確認事項をまとめる

処理の起点を決める

n8n の Schedule Trigger で、毎週月曜の13時に動かします。 Schedule Trigger は、週の間隔・曜日・時・分を指定できます。担当が午前中に3点セットを保存し終える前提で、昼過ぎに置きます。

タイムゾーンを先に確かめてください。 公式ページでは、ワークフローにタイムゾーンが無ければ n8n のインスタンスのタイムゾーンを使い、自前で立てた n8n の既定はニューヨークとされています。日本の13時のつもりが夜中に動く、ということが起きます。ワークフローの設定で Asia/Tokyo を指定します。

ワークフローは保存して公開しないと、トリガーとして動きません。 試しに手で動かして結果がよかったのに、翌週の月曜に何も起きない、という形でつまずきます。

ファイルの保存をきっかけにしないのは、 受付表の記入が終わる前に処理が始まり、価額の欄が空のまま判定することになるからです。

入力データを集める

質を決めるのは、仕入れの条件の書き方です。 「立地のよいもの」「状態のよいもの」と書いてあると、AIは何と照らせばよいか分かりません。「市区町村がこの一覧のどれか」「専有面積が50平方メートル以上」「建築の年が○年以降」のように、3点セットの事実と照らせる形に書き直します。

価額は受付表から渡します。 売却基準価額と買受可能価額は BIT の詳細画面で見られるので、担当が受付表に書きます。3点セットの評価書の評価額とは別の値なので、AIに評価書から拾わせて混ぜることをしません。 買受可能価額は、売却基準価額からその20パーセントに相当する額を引いた額で、入札はこの額以上でなければなりません。

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

3点セットは、1物件1ファイルにまとめて保存してもらいます。 BIT からは物件ごとに3点セットとして取れますが、担当によって3つに分けて保存したり、1つにまとめたりすると、ワークフローの側で拾い方が分かれます。 ファイル名の決まりも「裁判所の略称_事件番号_物件番号.pdf」にそろえます。

同じ事件番号を検討表で先に引きます。 期間入札で買受けの申出が無かった物件は、特別売却として改めて出ることがあります。前に条件外とした物件が、価額が変わらないまま再び新着に入ってくるので、過去の区分を添えて担当が見分けられるようにします。

AIへ渡す前に整形する

1. 受付表の欄の確かめ … 事件番号・裁判所・買受可能価額・入札期間が空の行は、判定に回さず担当へ戻します
2. ファイルの確かめ … ファイル名の決まりに合うか、ファイルが本当にあるかを確かめます
3. 大きさとページ数の確かめ … 1回のリクエストが32MB、ページが100（コンテキストが100万トークン未満のとき）を超えるものは、3つの書類に分けて送ります
4. 暗号化の確かめ … パスワードや暗号化のある PDF は Claude に渡せません。開けないものは担当へ戻します
5. 入札期間の確かめ … 入札期間の終わりまでの日数を計算し、日の近い物件から順に処理します
6. 重複の確かめ … 同じ事件番号・物件番号が検討表にあれば、前の区分を添えます

3番目は、写真の多い物件で引っかかります。 公式ページでは、小さな文字のページや複雑な表、画像の多い PDF は、ページの上限より先にコンテキストを使い切ることがあるとされています。分けて送るときは、物件明細書・現況調査報告書・評価書の順に、書類の境目で分けます。 ページの途中で切ると、表が2つの呼び出しに分かれます。

5番目は、担当の確認の順番のためです。 入札期間の終わりが近い物件から検討表に並べておけば、担当は上から読めば間に合う順になります。

AIに処理させる

させるのは、仕入れの条件ごとに3点セットから事実を拾い、条件と照らして4つのどれかを付け、根拠のページと原文を写すことです。

右端の not_stated が、この構成でいちばん大事な値です。 書かれていないことを「問題なし」と読むと、読むべき物件を見落とします。 unreadable は、ページはあるが文字や図が読み取れないときに付けます。

要点と確認事項も書かせます。 要点は、候補の物件の特徴を条件の順に3〜5行で。確認事項は、現地や裁判所で確かめるべきことで、たとえば占有者がいるときの退去の見込み、内覧ができるか、評価書に書かれた建物の不具合です。

3行目は、物件明細書の性格から来ています。 BIT の用語集では、物件明細書は裁判所書記官が記録上表れている事実等とそれに基づく認識を記載したものにすぎず、当事者の権利関係を確定するものではないとされています。AIに「この賃借権は対抗できない」のような評価をさせると、資料に無い結論が検討表に載ります。

指示内容を固定する

あなたは中古の戸建・マンションを買い取る不動産会社の仕入れ部で、
裁判所の競売物件の3点セットを読み、仕入れの条件ごとに事実を拾う担当です。
入札するかどうかは判断しません。資料に書かれた事実を条件の順に並べます。

【入力】
- 3点セット（物件明細書・現況調査報告書・評価書）のPDF
- 受付表の値：事件番号、物件番号、裁判所、売却基準価額、買受可能価額、入札期間
- 仕入れの条件：{conditions}

【条件ごとの status の選び方】
- match ........ 資料に書かれた事実が条件に合う
- mismatch ..... 資料に書かれた事実が条件に合わない
- not_stated ... 資料に該当する記載が見当たらない
- unreadable ... 該当しそうなページはあるが、文字や図が読み取れない
迷ったときに match を選ばないでください。

【厳守事項】
- 書かれていない事実を補わないでください。築年・面積・接道の幅を
  写真や周りの記載から推し量らず、not_stated にしてください。
- 「なし」と書かれていることと、記載が見当たらないことを分けてください。
  前者は match または mismatch、後者は not_stated です。
- 価額は受付表の値だけを使ってください。評価書の評価額と混ぜないでください。
- 権利関係について、対抗できる・できないなどの法的な評価を書かないでください。
  物件明細書に書かれた文言をそのまま写してください。
- 入札するべきか、いくらで入札するかを書かないでください。
- 占有者の氏名は書き写さず、「所有者」「賃借人」「第三者」「不明」で表してください。
- evidence には、根拠にした原文をそのまま写し、page に PDF のページ番号を入れてください。
- 確認事項には、現地または裁判所で確かめるべきことだけを書いてください。
- 3点セットでない書類が混ざっていれば、document_check に書いてください。

「なし」と「見当たらない」を分ける一文が、いちばん効きます。 書かないと、物件明細書の引き受ける権利の欄が読み取れなかった物件にも match を付けます。見落としたかったのではなく、空欄を「なし」と読んでいるのです。

占有者の氏名を写させないのは、検討表に要らないからです。 現況調査報告書には、不動産を占有している者の氏名が書かれています。仕入れの判断に要るのは占有の形で、名前ではありません。 検討表を社内で回すときに、個人の名前が残らないようにします。

出力形式を固定する

Messages API の output_config.format に JSON スキーマを置き、次の形で受け取ります。 公式ページでは、構造化出力はスキーマに合う JSON を返すとされ、数値の最小・最大の制約はスキーマに書けないので、範囲の確かめはワークフローの側で行います。

{
  "case_no": "",
  "property_no": "",
  "document_check": "ok | missing_document | other_document",
  "facts": {
    "address_city": "",
    "property_type": "detached | condominium | land_only | other",
    "floor_area_sqm": "",
    "built_year": "",
    "occupancy": "owner | tenant | third_party | vacant | unknown"
  },
  "criteria": [
    { "item": "area", "status": "match | mismatch | not_stated | unreadable",
      "value": "", "page": 0, "evidence": "" }
  ],
  "summary_points": [],
  "site_checks": []
}

criteria には、条件の数だけ要素を並べます。item は area ／ type ／ floor_area ／ built_year ／ burden_rights ／ occupancy ／ road_access ／ arrears です。価額の条件は、受付表の値を使って Code ノードで比べ、AIには渡しても判定させません。

区分は Code ノードで、次の規則で決めます。

1つ目の理由は、status と区分を別の層に置けることです。 条件ごとの事実はAIが拾い、区分は規則が決めます。「賃借人の占有は条件外」とするか「要確認」とするかは、仕入れの方針で変わります。

2つ目は、引き受ける権利と占有を needs_review に寄せていることです。 この2つは、外れていても値付け次第で仕入れる会社があります。機械で条件外に落とさず、担当の目に入る側に置きます。

3つ目は、page と evidence で確認が速くなることです。 担当は3点セットを最初から開かず、示されたページに飛んで原文を見ます。

システムへ連携する

検討表には、入札期間の終わりの日で並べて書きます。 担当が上から読めば、間に合う順になります。条件外の物件も1行ずつ残し、外れた条件を書きます。 あとで条件を見直すときの材料になります。

メールは社内の仕入れ部だけに送ります。 物件の要点を社外に出すことはしません。BIT のご利用条件が無断転載を禁じているので、3点セットの文や写真を検討表の外へ持ち出さない決まりにします。

人が確認する

担当が見るのは、candidate と needs_review の物件です。 out_of_scope は一覧で外れた条件だけを流し見ます。

1. needs_review を先に見る … not_stated と unreadable の条件について、示されたページを開き、本当に書かれていないのかを確かめます
2. candidate の根拠を確かめる … 引き受ける権利・占有・接道の evidence を原文と見比べます
3. 確認事項を足す … 写真や図面を見て、AIが拾っていない不具合や周りの状況を書き足します
4. 現地を見るかを決める … 決めたら検討表に書き、部長に上げます
5. 判定を直したら記録する … どの条件を、どちらに直したかを残します

1番目を省かないでください。 not_stated の多くは、資料に本当に書かれていないか、ページの写りが悪いかのどちらかです。前者なら裁判所で記録を確かめる材料、後者ならAIの読み落としで、 混ぜたまま候補から外すと、読むべき物件を落とします。

目標は、120件をならして1件5分です。 保存と受付表への記入に2分、検討表の確認に3分です。条件外の物件は数十秒で終わり、候補と要確認の物件は原文を開くので10分以上かかります。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの問題ではなく、保存のしかたの問題です。 保存の決まりを1枚にまとめて担当の机に置くほうが、プロンプトを直すより効きます。

6行目は、AIには分かりません。 手元のPDFには取下げが出てこないので、入札期間の前に担当が BIT で確かめます。

記録を残す

• 受付表の行（事件番号、物件番号、裁判所、価額、入札期間、保存した日と担当）
• Claude API に送った条件の表の版と、返ってきた JSON の全文
• Code ノードが決めた区分と、そのとき使った規則の版
• 担当が判定を直した記録（どの条件を、どちらに直したか）
• 現地を見に行ったか、入札したか、その結果
• 3点セットの PDF は、入札期間と開札が終わったあと、社内で決めた期間で消す

2つ目と3つ目で「版」を残すのは、条件と規則が後から変わるためです。 エリアを広げたり面積の下限を変えたりすると、過去の区分の意味が変わります。当時の条件が残っていないと、なぜその物件を落としたのかを後から説明できません。