No.19 住所データの正規化で起こる典型的なトラブル：日本の住所はなぜこれほど難しいのか

「住所くらい、郵便番号さえあれば簡単に正規化できるだろう」この甘い考えは、企業データ構築のプロジェクトにおいて、遅かれ早かれ粉々に打ち砕かれます。

日本の住所表記システムにおける「ゆらぎ」の多様さと複雑さは、世界でもトップクラスと言っても過言ではありません。都道府県、市区町村、町域、番地、号、建物名、階数……。これらの要素が、入力者によってあまりにも自由に記述されるため、単なる文字列マッチングでは全く太刀打ちできないのです。

本記事では、私がこれまでのキャリアで直面し、頭を抱え、そして克服してきた「住所データ正規化」における典型的なトラブルと、その解決へのアプローチを共有します。3000文字を超える詳細な解説となりますが、これを読めば「住所正規化」という魔境の歩き方が見えてくるはずです。

1. なぜ日本の住所は「カオス」なのか

根本的な問題は、日本の住所システムが「街区方式（住居表示）」と「地番方式」のハイブリッドであり、さらに歴史的な経緯による「通称名」や「行政区画の変更」が複雑に絡み合っている点にあります。

構造化されていない入力フォーム

多くの場合、Web上の入力フォームは「住所（都道府県）」と「住所（それ以降）」程度にしか分かれていません。ユーザーは「住所（それ以降）」の欄に、思い思いのフォーマットで情報を詰め込みます。

パターンA: 東京都千代田区大手町1-1-1
パターンB: 東京都千代田区大手町１丁目１番１号
パターンC: 千代田区大手町一の一の一
パターンD: 大手町1-1-1 （都道府県省略）

これらを同一の地点として認識させること。これが正規化のゴールですが、道のりは険しいものです。

2. 典型的なトラブル事例集

ここからは、実際にシステムを破壊しにかかる「住所の罠」を具体的に見ていきましょう。

トラブル①：「数字」と「漢数字」と「ハイフン」の無限の組み合わせ

最も頻出するのが、丁・番・号の表記ゆらぎです。

1-2-3
１ー２ー３ （全角ハイフン）
１丁目２番３号
一丁目二番三号
1の2の3

これらを正規化するには、まず「漢数字をアラビア数字に変換」し、「丁目・番・号などの区切り文字をハイフンに統一」し、「全角数字を半角に変換」するといった前処理（プリプロセッシング）が不可欠です。しかし、単純な置換だけでは問題が起きます。「一番町」のような地名に含まれる漢数字や、「六本木」のような固有名詞を変えてはいけないからです。

トラブル②：「京都市」という名の迷宮

京都の住所には「通り名（通称）」が含まれることが一般的です。

入力例: 京都市中京区寺町通御池上る上本能寺前町488番地
正規化したい形: 京都市中京区上本能寺前町488

「寺町通御池上る」は、場所を特定するための非常に便利な情報ですが、住所の正規化においては「ノイズ」となり得ます。ジオコーディングAPIによっては、この通り名が含まれていると正しくパースできず、エラーを返すものがあります。正規化エンジンは、この「通り名」部分を検出し、削除するか、あるいは別管理するためのロジックを持たなければなりません。

トラブル③：「大字（おおあざ）・字（あざ）」の省略と混入

地方の住所では「大字」「字」が入る場合と省略される場合があります。

パターンA: 愛知県＊＊市大字＊＊123
パターンB: 愛知県＊＊市＊＊123

これらは同じ場所を指しますが、文字列としては不一致です。また、「ケ」と「ヶ」と「が」の表記ゆらぎも頻発します（例：千駄ヶ谷 vs 千駄ケ谷）。これらを吸収する辞書（シソーラス）のメンテナンスは、終わりのない旅のようなものです。

トラブル④：合併による地名変更の亡霊（旧住所）

平成の大合併などで市町村名が変わったにもかかわらず、ユーザー（企業）側がWebサイトや名刺の表記を更新していないケースは非常に多いです。

旧住所: 埼玉県浦和市…
新住所: 埼玉県さいたま市浦和区…

20年前に消滅した「浦和市」が、データベース上では現役で生き残っています。これを正規化するには、「旧住所 → 新住所変換テーブル」を持つ必要があります。日本郵便が提供する郵便番号データなどを用いて、旧住所を検知し、自動的に新住所へ書き換えるロジックが必要です。

トラブル⑤：ビル名と階数の自由すぎる記述

住所の末尾、ビル名や階数の部分こそが、最もカオスな領域です。

表記例1: 丸の内ビルディング 3F
表記例2: 丸ビル3階
表記例3: 丸の内ビル３０１
表記例4: 丸の内ビルディング（受付２階）

これらを「建物名」と「部屋番号/階数」にきれいに分離するのは、至難の業です。「F」「階」「号室」などのキーワードを頼りに正規表現でパースしますが、「3F」が「3階」なのか「3rd Floor」という意味なのか、あるいはビル名の一部なのか、文脈依存の場合もあります。特に企業データにおいては、同じビルに入居している別企業を識別するために「階数・部屋番号」が重要なキーになりますが、ここが揺れていると名寄せ（重複排除）に失敗し、「同じ会社が別会社として2レコード登録される」事態を招きます。

3. 解決へのアプローチ：3段構えの防衛戦

これらに対処するために、私たちはどのようなアーキテクチャを採用すべきでしょうか。

Approach 1: ジオコーディングAPIの活用（Google Maps Platformなど）

最も手っ取り早く、かつ強力なのが、Google Maps APIなどの外部サービスを利用することです。Googleの検索アルゴリズムは非常に優秀で、多少の表記ゆらぎや旧住所であっても、賢く解釈して正しい（と思われる）正規化住所と緯度経度を返してくれます。

メリット: 実装が容易。カバレッジが広い。精度が高い。
デメリット: コストがかかる（従量課金）。利用規約（TOS）により、取得したデータを保存（キャッシュ）して二次利用することに制限がある場合が多い。

特に「データの保存制限」は、自社データベース構築においては致命的なハードルになることがあります。利用規約を熟読する必要があります。

Approach 2: 公的データ（アドレス・ベース・レジストリ）の利用

デジタル庁が推進する「アドレス・ベース・レジストリ」など、公的に整備された住所マスターデータを活用する動きが加速しています。また、日本郵便の郵便番号データや、街区レベル位置情報データなど、オープンデータとして入手可能なマスターを利用し、自前で正規化エンジンを構築する方法です。

ライブラリの活用: Pythonであれば jaconv ライブラリなどで文字種の統一を行い、有志によって開発されている住所正規化ライブラリ（例: normalize-japanese-addresses）を組み込むのが現実的な第一歩です。

Approach 3: 「正規化後」と「入力値」の並列保持

どれほど優れたアルゴリズムを用いても、100%完璧な正規化は不可能です。誤変換のリスクは常にあります。したがって、データベース設計においては、以下の2つのカラムを必ず用意すべきです。

Original Address: 収集した生データ（一切手を加えない）
Normalized Address: 正規化後のデータ

常にオリジナルを保持しておくことで、正規化ロジックにバグが見つかった際や、ロジックを改善した際に、いつでも再計算（Re-normalization）が可能になります。正規化後のデータだけを上書き保存してしまうのは、絶対に行ってはいけないアンチパターンです。

4. 企業データにおける「名寄せ」への影響

住所正規化の最大の目的の一つは、企業データの「名寄せ（Aggregation）」です。「株式会社テックサンプル」という社名が2つあったとき、住所が一致すれば「同一企業」と判定できます。しかし、住所正規化に失敗していると、これらは「別の会社」として扱われてしまいます。

「住所ID」の生成

正規化プロセスの中で、住所文字列をきれいにするだけでなく、町域や街区レベルでの「住所ID（Address ID）」を付与することを推奨します。文字列同士の比較（String Comparison）は計算コストが高く、表記ゆらぎに弱いですが、ID同士の比較であれば高速かつ確実です。

例：

東京都千代田区大手町1-1-1 → AddressID: 13101001001001
東京都千代田区大手町一丁目１番１号 → AddressID: 13101001001001

このようにID化されていれば、名寄せの精度は劇的に向上します。

5. まとめ：終わりのない戦いに備える

住所データの正規化は、一回やれば終わりというものではありません。新しいビルが建ち、区画整理が行われ、市町村が合併するたびに、住所は変化します。そして、人間が手入力する限り、独創的な「誤入力」は生まれ続けます。

「完璧を目指さない」ことが、精神衛生上もプロジェクト進行上も重要です。まずはAPIやライブラリで90%〜95%の自動化を実現し、残りの数%は「例外」としてフラグを立て、人間が目視で確認・修正するプロセス（Human-in-the-loop）を組み込むこと。これこそが、現実解としての最適解です。

最後に、参照すべき有用なリソースを挙げておきます。

デジタル庁アドレス・ベース・レジストリ: 日本の住所マスターデータの決定版を目指して整備が進められています。
- https://www.digital.go.jp/policies/base_registry_address/
Geolonia 住所データ: オープンソースでメンテナンスされている高品質な住所データ。
- https://geolonia.com/
郵便番号データダウンロード: 日本郵便が提供する基本中の基本データ。
- https://www.post.japanpost.jp/zipcode/download.html

住所正規化という泥臭い作業の先にこそ、真に価値ある「使えるデータ」が待っています。諦めずに、地道な改善を積み重ねていきましょう。