土地を地図に置くまでには、
見えない処理がある。
地番を検索して、地図に色を塗る。
見た目だけなら、仕組みは単純に見えるかもしれません。
しかし実際には、所在・地番の表記揺れ、座標系の違い、複数ポリゴン、
土地と建物の関係、登記記録との照合、現況との差異など、
不動産特有の例外を一つずつ処理する必要があります。
JON SYSTEMは、GISだけでも登記だけでも成立しません。 空間データ処理と土地家屋調査士の実務知識を組み合わせて構成しています。
住所と地番と土地の形は、
同じ情報ではない。
一般的な地図は、住所や施設名を起点に場所を探します。 しかし不動産実務では、「東京都○○区○○1丁目」という住所だけでは足りません。 一つの住所の中に複数の地番が存在し、一つの敷地が複数筆で構成されることもあります。
さらに、登記所備付地図データには公共座標系のものと任意座標系のものがあり、 すべてをそのまま一般地図へ重ねられるわけではありません。 同じ地番に複数の形状が存在するケース、分筆・合筆後の履歴、建物と土地の対応関係など、 機械的な一致だけでは判断できない場面もあります。
JONは「地図に表示されたから正しい」とは考えません。 データの出所、位置精度、登記記録、現地との関係を区別しながら、 どこまでを自動処理し、どこから専門家が確認すべきかを設計しています。
一枚の地図の裏側で、
複数の不動産情報を重ねる。
JON SYSTEMは、一つのデータだけで土地を判断しません。 地図・登記・建物・現場をレイヤーとして持ち、対象地を共通キーに結び付けます。
筆・地番データ
所在、地番、筆ポリゴン。土地を「点」ではなく一筆の形として扱う基礎レイヤーです。
登記情報
地目、地積、表題部等、取得・確認した登記情報を対象地と紐付けて整理します。
建物情報
建物形状、家屋番号、建物登記情報等を土地との位置関係から照合します。
背景地図・航空写真
道路、駅、河川、周辺建物など、対象不動産を取り巻く現実の環境と重ねて確認します。
現場情報
現地写真、コメント、確認事項、工程情報などを対象地に直接結び付けます。
「地番リスト」を、
「使える地図」に変える8つの処理。
全国規模の不動産データでは、取得した情報をそのまま表示するだけでは足りません。 正規化、空間照合、例外処理、品質確認を経て初めて企業が使える情報になります。
所在・地番を正規化
全角・半角、ハイフン表記、枝番、所在表記等の違いを整理し、 検索・照合できる形へ統一します。
対象筆を探索
所在・地番と地図情報を照合し、候補となる筆形状を抽出。 完全一致だけに依存しない探索を行います。
座標情報を判定
地図へ直接重ねられるデータか、追加処理が必要なデータかを区別。 座標の性質を無視して一律に表示しません。
形状を整える
同一地番に複数形状がある場合の統合、無効形状の確認など、 地図表示に必要なジオメトリ処理を行います。
建物・点情報を照合
緯度経度を持つ建物・家屋番号等を、どの土地上に存在するか空間演算で照合します。
隣接・近接を分析
別地番でも連続する土地、道路を挟んだ土地、近接する社有地等を 距離・接触関係から発見します。
属性情報を結び付ける
地目、地積、取得日、管理情報、確認日などを一筆へ集約し、 地図と一覧を同じ情報モデルで扱います。
例外を確認する
機械処理だけでは確定できない案件を抽出。 専門家が確認すべき対象を明確にして品質を管理します。
「同じ地番だから」ではなく、
位置関係を計算する。
緯度経度とポリゴンがあるからこそできるのが空間演算です。 JONでは、不動産データ同士の関係を地理的に判定する考え方を取り入れています。
この建物は、どの土地上にあるか。
建物や家屋番号等の位置情報を、筆ポリゴン内部に含まれるかどうかで判定します。
どの形状と重なっているか。
建物形状と筆形状の重なりから、単純な住所一致では分からない土地・建物関係を確認します。
最も近い対象はどれか。
点がポリゴン外にある場合など、距離を用いて候補を抽出し、次の確認対象を絞り込みます。
別地番でも、つながっていないか。
境界を共有する筆や極めて近接する筆を抽出し、一体利用できる土地のまとまりを見つけます。
複数形状を、一つの対象として扱う。
同一の管理単位や同一地番として扱う必要がある複数ポリゴンを統合し、視認性を高めます。
周辺○mに何があるか。
対象地の周囲に一定範囲を設定し、近接する自社資産や確認対象を抽出する考え方です。
不動産データは、
「例外」の方に知見が出る。
全国を扱うほど、きれいな一対一対応ではないケースが増えます。 ここを機械的に処理しないことが、不動産システムの品質を左右します。
一筆の土地に、複数の建物がある。
工場、学校、社宅、施設用地等では、一筆の中に複数棟が存在することがあります。 「一土地＝一建物」という前提では情報を正しく整理できません。
家屋番号の枝番が、部屋番号とは限らない。
区分建物では枝番が専有部分と対応するケースがありますが、 同一筆上に複数の非区分建物が存在する場合など、同じ読み方では整理できません。
地図の線と、法的な境界は同義ではない。
デジタル地図上のポリゴンは資産把握に有用ですが、 境界の法的確定を意味するものではありません。 処分や建築等では別途境界確認・測量が必要になる場合があります。
登記記録と現況が一致しないことがある。
地目、建物の有無、形状、利用状況など、登記記録と現在の状態の間に 確認が必要なケースがあります。
同じ会社でも、名称の履歴がある。
商号変更、合併、組織再編等により、社内台帳と登記上の名義を 単純な文字列一致だけで結び付けられないことがあります。
取得時点が違えば、情報の鮮度も違う。
登記情報、地図データ、現地写真、社内台帳は更新時点が異なります。 すべてを同一時点の事実として扱わないことが重要です。
自動化するところと、
自動化しないところを分ける。
JON SYSTEMの考え方は「すべてAI・すべて自動」ではありません。 大量データは機械で絞り込み、法的・現場的な意味を持つ判断は専門家へ戻します。
データを増やすことより、
「どこから先は人が見るべきか」
を知っていることが重要です。
「何が表示されているか」だけでなく、
「いつ・どこから来た情報か」を持つ。
不動産情報は時間とともに変化します。 信頼できる管理には、値だけでなく出所と確認時点が必要です。
SOURCE / 出所
登記、地図、社内台帳、現地確認など、その情報がどこから得られたかを区別します。
TIME / 確認時点
登記取得日、資料更新日、現地撮影日など、情報の時点を持たせて鮮度を判断します。
QUALITY / 確認状態
自動照合、資料確認済み、現地確認済みなど、どの段階まで確認された情報かを分けます。
HISTORY / 履歴
分筆・合筆、建替え、名義変更等で変化する情報を、現在値だけでなく履歴として捉えます。
複雑な処理は裏側へ。
利用者には、直感的な地図を。
技術が複雑だからといって、操作まで複雑である必要はありません。 最終的には、対象地を見れば必要な情報へたどり着ける状態を目指します。
全国 → 一筆までズーム
大きな資産ポートフォリオから、一つの土地へ同じ地図で移動します。
地番ポリゴンをクリック
対象地を選ぶと、その筆に結び付いた属性・資料・確認情報を呼び出します。
建物・写真・資料を同じ場所へ
「ファイル名を探す」のではなく「土地を選ぶ」ことで関連情報へアクセスします。
例外は確認対象として残す
自動判定できないものを隠さず、専門家が確認する対象として見える状態にします。
企業の既存台帳を捨てず、
「地図」という共通キーを追加する。
JONの考え方は、固定資産台帳や既存の管理システムをすべて置き換えることではありません。 既存情報に「どの土地か」という空間情報を加え、相互に行き来できる状態を設計します。
企業内の既存情報
現在使っている台帳・管理番号・案件情報等を活かします。
- 固定資産台帳
- Excel / CSV
- 社内管理番号
- 拠点・案件情報
地番・地図レイヤー
既存情報に、土地の場所・形・周辺関係を加えます。
- 所在地・地番
- 筆ポリゴン
- 建物・登記情報
- 位置・隣接・距離
企業の意思決定
地図から資産を見つけ、既存の業務へ戻します。
- 資産棚卸し
- 拠点再編
- 売却・活用
- 測量・登記・追加調査
システムが、
勝手に確定しないこと。
技術を披露するからこそ、限界も明示します。 地図上の推定と、法的な確定・専門判断は別です。
- 境界の法的確定 — 地図ポリゴンだけで筆界・所有権界を確定しません。
- 現況の完全把握 — 航空写真や建物データだけで現地状態を断定しません。
- 登記の要否判断 — データ差異だけで登記申請が必要と決めません。
- 所有関係の最終判断 — 一覧・台帳だけで現在の権利関係を確定しません。
- 任意座標データの無条件表示 — 位置根拠を確認せず一般地図へ重ねません。
一筆の現場知識を、
全国規模のデータ処理へ。
JON SYSTEMは、地図ソフトの紹介ではありません。 土地家屋調査士の実務で蓄積した「土地・建物・登記の例外知識」を、 空間データ処理と組み合わせるための考え方です。 法人所有不動産の棚卸し、継続案件、地図化・データ連携についてご相談ください。