地場の不動産会社から、売地情報が毎日FAXで届く。営業事務がExcelに手入力するが、忙しい週は束が積み上がる。同じ土地が別の会社から届いて台帳に2行並び、すでに売れた土地も残ったまま。土地なし客の多い工務店で、珍しくない光景である。本記事では、売地のPDFをAIで読み取って台帳に自動で書き込み、重複や売却済みまで整理する仕組みと、AIに任せきらないための設計を解説する。
土地から探している客を抱える工務店にとって、土地情報は営業の武器そのものである。ところが、その武器の管理は驚くほどアナログなまま残っていることが多い。
売地情報は、地場の不動産会社からFAXで届く。書式は会社ごとにばらばらで、手書きのメモが添えられていることもある。営業事務や営業担当は、この束を1枚ずつ見ながら、住所・価格・坪数・用途地域などを台帳に打ち込んでいく。1枚あたりの作業は数分でも、毎日届けば確実に積み上がる。見学会の準備が重なる週には、入力が数日遅れることも珍しくない。
入力が遅れると、提案が遅れる。客から「この学区で40坪くらいの土地はないか」と聞かれたとき、台帳に入っていない土地は提案できない。机の上のFAXの束の中にあったと後で気づいても、その頃にはもう他社が紹介しているかもしれない。
もう1つの問題は、台帳の中身が古くなることだ。同じ土地を複数の不動産会社が扱っていれば、FAXも複数届く。手入力では、それが同じ土地だと気づかずに2行登録してしまう。さらに厄介なのは、売れた土地の情報である。売却されたことは、わざわざFAXで知らせてくれるとは限らない。台帳に残ったままの土地を客に紹介し、問い合わせたら「もう売れています」と言われる。これを2回繰り返せば、客の信頼は確実に落ちる。
入力の遅れ、重複、売却済みの放置。この3つは、人の注意力では防ぎきれない構造的な問題である。
なぜ土地情報の管理にここまでこだわるのか。土地から探す客は、土地情報の質で住宅会社を選んでいるからである。
土地探しをする客の多くは、複数の住宅会社や不動産会社に同時に声をかけている。どの会社も扱う土地にそれほど差がないなら、差がつくのは、どれだけ早く、どれだけ客の条件に合った土地を出せるかだ。
条件の中でも、学区の比重は大きい。子育て世帯にとって、どの小学校・中学校に通うかは、土地の価格や広さと同じくらい重い判断材料になる。ノウハウ集でも、分譲地の販売ページには学区や周辺施設の情報を厚く載せるべきだとしている。土地情報を学区で絞り込めるかどうかは、提案の質に直結する。
一方で、土地情報には正確さも求められる。価格を1桁読み間違えた、坪数を取り違えた、売れた土地を紹介した。こうしたミスは、たった1回でも「この会社の情報は当てにならない」という印象を残す。
つまり、土地情報の管理に必要なのは、速さと正確さの両立である。手入力では速さが出ない。かといって、AIに丸投げすれば正確さが怪しくなる。G-Boostで構築した仕組みは、この2つの両立を前提に設計している。
仕組みの流れはシンプルだ。
まず、届いたFAXを複合機などでPDFにして、Googleドライブの「売地資料」フォルダに入れる。GAS（Google Apps Script。Googleが無料で提供している自動処理の機能）が、15分ごとにこのフォルダを確認し、新しいPDFがあればAI（AnthropicのClaude）に渡して内容を読み取らせる。読み取った情報は、Googleスプレッドシートの台帳に1物件1行で書き込まれる。（住宅会社のClaude活用方法についてはこちら）
AIが読み取る主な項目は次のとおりである。
書式がばらばらのFAXでも、AIは「どこに価格が書いてあるか」を読み取って項目ごとに振り分けてくれる。手入力では見落としがちな備考欄のセールスポイントも、拾い漏らしにくい。
台帳の各行には、元のPDFへのリンクが付く。読み取り結果に疑問があれば、ワンクリックで元のFAXを確認できる。処理が終わったPDFは、自動で「処理済み」フォルダに移される。同じPDFを二度読み込むことはない。
もう1つ、地味だが効いている工夫がある。番地の列は、あえて文字列として固定している。スプレッドシートは「1-2」のような番地を、勝手に「1月2日」という日付に変換してしまうことがある。住所が日付に化けた台帳は、それだけで使い物にならない。
ここが、この仕組みで最も大事な部分である。AIは書式のばらばらなFAXを驚くほどうまく読む。それでも、AIの出力をそのまま信用する設計にはしていない。
FAXは、そもそも読み取りにくい。かすれた数字、手書きの訂正、斜めに送られた原稿。人間でも読み間違える資料を、AIが100%正しく読める保証はない。しかもAIは、読み取れなかった箇所をもっともらしく埋めてしまうことがある。価格や坪数がもっともらしく間違っている台帳ほど、危ないものはない。
そこで、AIの出力のあとに、プログラム側で必ずもう一度チェックをかけている。
金額や坪数など、数字で確定できなかった項目は、AIがどう判断したかに関係なく、プログラムが強制的に「要確認」にする。たとえば金額が「応相談」と書かれていたり、数字がかすれて判読できなかったりした場合、その行の抽出ステータスは「要確認」になり、理由も自動で記録される。FAXの更新日が読めなければ、日付の欄は「確認中」と表示される。
学区も同じ考え方だ。AIが学区を読み取れなかった場合は、公式の学区データから自動で補う。ただし、その住所が公式データ上で「〇〇の一部」となっていて、番地の単位まで学区を特定できない場合は、あえて自動で確定させない。誤った学区を自信満々に表示するより、「要確認」と正直に出す方がましだからである。
人が確認した行には、「確認済み」のチェックを入れる。チェックを入れると、その日付が最終確認日として自動で記録される。確認前の行は赤字で目立つように表示されるので、どの行がまだ人の目を通っていないかが一目で分かる。
AIに任せるのは、大量の読み取りという作業である。その結果が正しいかどうかの最終判断は、人が握る。AIを使うほど、人が確認すべき場所をはっきりさせておく必要がある。
土地情報の管理で手入力では防ぎにくいのが、重複と売却済みの放置である。仕組みでは、この2つにも対処している。
まず重複について。新しい物件が台帳に追加されると、既存の物件と番地・金額・坪数を比べ、近い物件を「同一物件の疑い」として検出する。完全一致ではなく「近い」で拾うのは、同じ土地でも不動産会社によって番地の書き方や価格の端数が微妙に違うことがあるからだ。ただし、検出はあくまで「疑い」であり、自動で1行にまとめることはしない。本当に同じ土地かどうかは、人が元のFAXを見比べて判断する。
次に売却済みの管理。多くの不動産会社は、定期的に自社の取扱物件の一覧表を出している。この一覧のPDFを「業者一覧」フォルダに入れると、仕組みが台帳と突き合わせる。
突き合わせの手がかりには、不動産会社が付けている土地番号を優先して使う。番号がなければ、番地で照合する。
ここで1つ、意図的にかけている制限がある。売却済みの判定は、必ず同じ不動産会社の物件の中だけで行う。A社の一覧にB社扱いの土地が載っていないのは当たり前だからだ。この制限を外すと、他社の扱っている売れていない土地まで売却済みになってしまう。便利さより、誤判定を防ぐことを優先した設計である。
台帳がたまってきたら、使う場面に合わせて絞り込む。台帳には、住所から地区名を揃えた「エリア分類」の列があり、絞り込み用のタブではエリアを選ぶだけで該当する土地を一覧にできる。表記揺れのある地名も、既知の地名リストで正規化している。スプレッドシートの標準のフィルタやピボットテーブルを使えば、エリアごとの件数や価格帯の集計もできる。
客との商談では、地図で見せたい場面も多い。台帳には地図用のタイトル・住所・説明の列があり、CSVとして書き出してGoogleマイマップに取り込める。
ただし、マイマップへの取り込みだけは自動化していない。マイマップには、外部から自動でデータを流し込むための公式の手段（API）がないからだ。非公式な方法で無理に自動化すれば、仕様変更のたびに壊れるリスクを抱えることになる。地図の更新は、商談前などに人がCSVを取り込む運用にした。自動化しない部分を決めておくことも、仕組みを長く使うための設計である。
導入する前に、社内で決めておきたいことが3つある。
1つ目は、FAXをPDFにしてフォルダに入れる担当を決めることだ。仕組みはフォルダに入ったPDFしか読まない。ここが滞れば、自動化の意味はない。複合機にスキャンしたPDFをGoogleドライブへ直接保存する設定があれば、この手間はさらに減る。
2つ目は、「要確認」の行を誰がいつ確認するかである。要確認が数十件たまった台帳は、結局信用されなくなる。毎朝10分、営業事務が赤字の行を確認する、といったルールを決めておく。
3つ目は、費用の考え方だ。スプレッドシートとGASは無料で使えるが、AIの読み取りには読み取ったPDFの量に応じた利用料がかかる。1日に届くFAXの枚数から、月にどれくらい使うかを事前に試算しておく。
構築と運用の過程では、実際にいくつかのつまずきがあった。
エラーが起きても、ほかのPDFの処理は止まらない。エラーになったPDFはフォルダに残り、15分後に自動で再挑戦する。結果は処理ログのシートに記録されるので、台帳に何が起きたかは後から追える。
なお、この仕組みは売地情報に特化している。賃貸や中古住宅など、ほかの物件種別に応用したり、ほかの地域の学区データに差し替えたりする場合は、別途の調整が必要になる。
土地なし客への提案が遅れるのは、営業の努力が足りないからではない。毎日届くFAXの束を手で台帳に移し、重複と売却済みを人の記憶で管理するやり方に無理がある。読み取りと書き込みはAIに任せ、数値が確定しない項目や学区の曖昧な物件は「要確認」として人に戻す。重複は疑いとして示し、売却済みの判定は同じ会社の中に限る。
AIは、読み間違えないから使うのではない。読み間違えたときに人が気づける形で使う。その線引きを最初に設計した会社だけが、土地情報の速さと正しさを両立できる。土地から探す客の信頼を守る、見えない土台。
