ビルの所在地の管理、ただそれだけで難しい

f:id:aruke_aruke:20211202153737p:plain はじめに

株式会社estie（単にestieとも）は主にオフィスビル情報や賃貸オフィスマッチングサービスを提供する会社です。

私はestieに10月に入社し、データそのものを管理しています。扱うのはビルのデータだけではありませんし、もちろん所在地だけでもないですが、今回はビルの所在地という狭い分野に焦点を当てて記事を書きました。

是非、「住所入れればいいんじゃないの？」と気軽に読み始め、深い沼を楽しんでください。

これは Calendar for estie Advent Calendar 2021 の13日目の記事です。

住居表示の基礎
ジオコーディングとは
難しいところ
泥臭さ
おわりに（採用情報）
参考文献

住居表示の基礎

いわゆる住所*1のことで、多くのestie社員も単に住所と言っています。市町村が建物に対して与えるもので[1]、住居表示という名ですが、住居以外の建物にも与えられています。例えば現在estieのオフィスがある東京大学は住居ではないですが、「東京都文京区本郷七丁目3番1号」という住居表示を持っています。

日本で主に使われている住居表示は街区方式と呼ばれる方式で、道路や河川などに囲まれた「区画（街区）」を基準に地名や番地を付与する方式です。上記の東京都文京区本郷七丁目3番1号も街区方式によって表されています。

市には郡が無いとか、区は政令指定都市にのみにあるなどの様々な例外がありますが、大雑把に階層構造っぽく表すと

都道府県-郡-市町村/特別区-区-字-番地-号

のようになっています*2。

都道府県-郡-町村-字-番地-号を基本とし、

　町村が市になって都道府県-市-字-番地-号

　政令指定都市の一部では都道府県-市-区-字-番地-号

　東京23区だけ例外として都道府県-特別区-字-番地-号

　北海道や島嶼部には支庁……

などと例外は多いですが、ある程度階層的な構造です*3。

先述の住居表示は東京都文京区本郷七丁目3番1号と分解でき、更に字は大字（本郷）と小字（七丁目）にも分解できます*4。

この階層構造をデータベース上に構築し、ビル毎に対応する番号を振ることで、estieのサービスでは

都道府県の中から東京都
東京都の中から文京区
文京区の中から本郷

と絞り込んでビル情報を扱えます。

ジオコーディングとは

位置を表すには住居表示以外に緯度経度があります。他にもwhat3wordsなど、位置を表す方法は様々ありますが、estieでは住居表示と緯度経度を主に使っています。

多くのビルのデータは、ビルの所在地を住居表示で表示しています。最近は地図でも表示するサービスが増えてきましたが、ビルの住居表示がわかっても緯度経度がわからなければビルの位置を地図で表示できませんし、逆にビルの緯度経度のみがわかっていても「文京区のビル」の検索はできません。住居表示から緯度経度を得たい……そこで出てくるのがジオコーディングです。

f:id:aruke_aruke:20211202152635p:plain

住居表示などから緯度経度を与えることを「ジオコーディング」といい、逆に緯度経度から住居表示を与えることを「逆ジオコーディング」といいます。この技術を使って、estieではビルの位置を地図上でも表示できるようにしています。

難しいところ

ここまでは位置情報を扱うときによくある話・基礎知識ですが、7万件以上のビルの所在地扱った私だからこそ見つけられ、そして困った、細かめの話をしていきます（といっても、説明・対処がしやすくて、知見になりそうな事象を書きます）。

住居表示の表記揺れ

東京都文京区本郷七丁目3番1号
東京都文京区本郷7丁目3-1
文京区本郷7-3-1
本郷7丁目3-1

これらを人は同じ場所だと思えるが故に、このような様々なフォーマットでビルの所在地が書かれています*5。

省略だけでなく、地名によっては

虎の門
虎ノ門
虎ﾉ門
虎門

のように表記が揺れることもありますし、ハイフンが全角だったりマイナス記号だったりもします。

estieでは住居表示を「東京都文京区本郷7丁目3-1」や「虎ノ門」の形式に統一して保持・表示しています*6。このように統一（正規化）されたデータと入力クエリの正規化によって、高速で便利な検索を実現できます。

様々な表現で書かれた元データから機械的に変換しましたが、その変換が不自然にならないよう、いろんな所在地表現を見て最適な統一処理を探し、また例外処理の実装も行っています。

重複する地名

府中市は東京都にも広島県にもあります。読み方が違っても漢字だけでしか書かれなければ区別はほぼ不可能です。このような同名の市町村はたくさんありますが、その大半は前後を見れば大抵区別できます。というか、そうでなければ困るので大抵名前は被らないようにつけられます。しかし全てがそうだとは限りません。

例えば京都府京都市中京区亀屋町はなんと5つあります。こちらは面している通りの名前や交差点からの方角などで区別されることもあり、先ほどの階層構造では表せない「区別のための文字」が住所に含まれることがあります。他にも京都・北海道の地名は複雑で、語れることが多いです*7。

法律上、各市区町村が"合理的"にするよう務めているはずなのですが、地名には愛着があるため難しい問題です。我々としては「府中市1-1の府中ビル」というデータがあった場合、地図を見て判断することになります。地名を扱うにはそういう覚悟がいります。

番地は数字だけ？

普段見る"住所"のほとんどは、「10番地」のように番地が数字です。しかし、実は数字とも限りません。株式会社estieでは番地をint型（整数型）で持つようなことはしていませんが、数字だと仮定した処理は危険です。

前述の通り、住居表示は道路や河川などよって区画が定められるため、境界上にあるビルの地名は原則通りにならない傾向にあります。例えば東京の四ツ谷駅 *8は江戸城の外濠だった場所に作られています。その結果、四ツ谷駅の所在地は「東京都新宿区四谷一丁目無番地」となっています。四ツ谷駅に限らず、区画の境界である線路の上に建設される駅ビルの所在地は難しい問題です。

四ツ谷駅の場合、Null番地なのか「無」番地なのかは文字からだけではわかりませんが、番地が数字ではありません。外部サービスには0番地を返すものもありました。他のビルについても調べた結果、アルファベットや漢字などの更にいろいろな値が入ることも判明し、estieでは正規化した文字列で保持しています。

道路方式での住居表示

日本では少ないですが、面している道を基準に付与する住居表示もあります。例えば山形県東根市で「板垣大通り」「板垣中通り」「板垣北通り」のように使われています[2]。日本の公的な場面ではあまり使われない一方で、道案内では「本郷通りを北に〜」などと使われています。地図のように俯瞰的に見るのではなく、通行人の目線では特に便利そうだと思いながら過ごしています。町を歩いていて「ここから二丁目」という案内はあまり見ませんが、「この道は○○通り」という通り名標識や国道の標識はよく見かけるので、いつかは「本郷通り沿い」のような検索も必要とされるのではないかと考えています。

同じ住居表示を持つ、異なる建物が存在する

区画内の「号」は、約10メートル毎に右回りに付けられています[3][4]*9。この原則によって住居表示から位置を特定しやすくなっていますが、「約10メートル毎に」付与されるため、幅が狭いビルが並んだ場合には同じ「号」が割り振られます。*10こうして、同じ住居表示を持つビルが生まれます。

f:id:aruke_aruke:20211202152659p:plain

estieでは住居表示が被っているビルを数千件扱っています。様々な工夫によりそれらが本当に異なるビルである状態へと改善できました。ビルはほぼ毎日追加されるため今でもたまーに重複データが見つかりますが、同じビルを複数保持してしまう「ビルの重複削除」が社内で重大かつ有名なプロジェクトです。所在地の住居表示が同じでも重複データとは限らないため、住居表示は銀の弾*11にはならず、様々な工夫が必要でした（一例：【Python】不動産データに対して編集距離から類似度を計算してみた - Qiita）。

また、住居表示順の並び替えが一意にならないことにもつながります。

同じ住居表示を持つと、ジオコーディングした際に同じ緯度経度になる

同じ住居表示は更に問題を生み出します。ジオコーディングは、先述の通り住居表示から緯度経度に変換することです。入力された住居表示が同じなら、出力される緯度経度も同じです。すると、異なるビルが同じ住居表示を持っているだけなのに、サービス上の地図で見ると同じ場所にビルが存在してしまいます。

具体例を挙げると、同じ住居表示「東京都港区北青山3丁目5-9」を持つ5棟のビルはジオコーディングによって同じ代表点を持つため、単にジオコーディングサービスを用いただけでは1枚目の図のようになってしまいます*12。正しくは2枚目のようにビルが存在しているのに、4棟のビルの所在地が間違ってしまっています（水田ビルは東京都港区北青山3丁目5-8）。

f:id:aruke_aruke:20211121163454p:plain f:id:aruke_aruke:20211121163512p:plain

不動産業界では、ビルが地図上で正しい位置に表示されることがとても重要なため、このような緯度経度の修正が必要です。ビルの名前から緯度経度が取得できる場合もありますが、最終的には複数の地図やストリートビューを駆使してビルの位置を5000件ほど修正しました。緯度経度が少しだけ間違っている状態の検出は難しいので、まだまだあると思いますが……。

住居表示かと思ったら、地番

地番とは、法務局が土地に対して与えた地名（番号）のことで*13、都道府県から字までは住居表示とほぼ同じです*14。住居表示は辿り着きやすいように位置の順に数字を付けますが、地番は重複がないように数字を付けるため、今では番地や号はかなり異なっています。

よく見れば「番地」か「番」かで住居表示と見分けられますが、書いてなかったりハイフンで済ませられたり、判別には苦労します。住居表示かと思って取得、保持してしまうこともあります。運悪く住居表示で解釈できてしまえば、ジオコーディングの結果、全く違う緯度経度でビルを表示することにもつながります。

しかも地番が地番だとわかっても住居表示はすぐにはわかりません。竣工中のビルデータを扱うことで将来のオフィスの需給などをサービスに反映させたいのに、竣工前には地番しか無いことも多く、住居表示に仮のデータを入れざるを得ないこともあります。

このようなときには建築確認看板や現地の様子から所在地を特定し、推測した住居表示を入力することもあります。地番と住居表示の対応サービスも存在するのですが、最新のデータや未確定のデータまで扱おうとすると、泥臭い仕事が必要になります。

地名の変更

地名はたまに変わります。有名なところで言えば、市町村の合併で地名は変わり、当然住居表示も変わります。そんなとき、その土地にあるビルの住居表示の書き換えが必要になります。しかも番号が振り直されることもあり、機械的には困難な書き換えが突然数百件も必要になることもあります。例えば2018年に東京都新宿区の三栄町は四谷三栄町へと変更されましたが、いまだに三栄町のデータは世の中にたくさん残っています*15。

このように既に無い所在地は要修正所在地へと判別しています。新旧対照表などが手に入る場合もありますが、結局は新旧の地図を照らし合わせて最新の住居表示を探す……なんて仕事もしています。

緯度経度からはどの測地系なのかがわからない

緯度経度は数字なんだから表記揺れにも苦しめられず、似たような表示もなく、全世界で統一された基準として使える……と思ったら実は違います。

今では多くのサービスが、WGS84や日本測地系2011などの世界測地系と呼ばれる緯度経度システムを採用しています。estieでもこの緯度経度を使っています。

しかし、旧日本測地系という別の測地系も存在します*16。日本測地系と世界測地系では緯度経度共に12秒（=1/300度）ほどずれているので、ビルの位置を旧日本測地系で保存しようものなら100メートル以上ずれてしまいます。そのため、どの測地系かを明確にしたいですが、緯度経度自体は数字です。気がつかずに入力してしまったのか、たまに旧日本測地系で入力された緯度経度由来のような大きなズレが存在していました。

最近はほぼ大丈夫なようです*17。サービスによって測地系や緯度経度の値が異なることを期待して日本橋にある日本国道路元標の緯度経度を取得したところ、

Yahoo! 地図：35.68404, 139.77448

Google Map：35.68405, 139.77449

国土地理院地図：35.68403, 139.77448

MapFan：35.68405,139.77449

などとほとんど同じ値でした*18。緯度や経度は1度が約100キロメートルなので、小数点以下5桁は約1メートル精度です*19。このような感覚は生のデータを何度も見ることでこそ身につくと思っています。

その他様々な誤り

大半の所在地は人間が打ち込んだデータなので

似た文字への誤字（両国国技館の地名は横網だが横綱になってるなど）
全く違う地名と勘違いしているもの（都道府県名が違うことも……）
脈絡のない脱字（西新宿が新宿になってしまっているなども）
12-3が1-23になっているもの
変換ミスや読み間違い
所在地の欄にビル名や緯度などの異なるデータが混入
テストデータ「あああああビル」などの混入
1丁目で終わっていて番地が入力されていないもの

などなど、突拍子もないものを含めて様々な入力が存在します[6]。

大量のビルを調査することで新たなエラーを発見し、修正し、バリデーションに追加する繰り返しです。

泥臭さ

株式会社estieは不動産テック企業なので、もちろん上記のような内部での処理も検出や修正はできるだけ効率的・機械的に行おうとしています。泥臭い作業には無駄がありそうに見えますが、泥臭い作業が無駄だとは限りません。

効率的に不動産データを扱えるために、泥臭い仕事が必要になることもあります。泥臭く思えた作業が最も効率的・効果的なこともあります。泥臭くデータを見続けたからこそ得られる知見もあります。そして、泥臭い作業の末に他人が見つけにくい誤りを見つけ、泥臭さを楽しみながら修正し、社内wikiにまとめる私がいます。我々が泥臭い作業をすればするほど、後の作業から泥臭さを取り除ける……そんな作業を社内では「浄水」と呼ぶこともあります。