「渋谷区3-21-3」と「渋谷3丁目21番3号」は同じ？ — 現場で起きる日本住所の表記ゆれ10選

住所正規化・ジオコーディングAPI 「Staddress（スタドレス）」 開発チームです。
連載第2回は、現場でよく見る「表記ゆれ」10パターンを整理します。

「同じお客様なのに、CRM上は別人扱い」「配送先が微妙に違う文字列で登録されている」——こうした事故の多くは、住所文字列の見た目の違いから起きます。

同じ住所なのに、システム上は「別データ」になる

たとえば次の2行は、人間が見れば同じ場所です。

東京都渋谷区道玄坂2-6-2
東京都渋谷区道玄坂2丁目6番2号

しかし DB 上では 完全一致しない ため、名寄せや重複チェックから漏れます。
EC の配送先、CRM の顧客マスタ、問い合わせ履歴——どのシステムでも起きうる問題です。

本記事では、現場で遭遇しやすい表記ゆれを Before → After で10例紹介します。
（After は Staddress API で正規化した結果の例です）

日本住所の表記ゆれ10選

以下、現場で遭遇しやすい10パターンを Before → After で紹介します。

1. 丁目・番・号 vs ハイフン表記

入力（Before）	正規化後（After）
`渋谷区道玄坂2-6-2`	`東京都渋谷区道玄坂2丁目6-2`
`港区虎ノ門二丁目2番3号`	`東京都港区虎ノ門2丁目2-3`

現場での起き方: EC フォームは 2-6-2、基幹システムは 2丁目6番2号 と入力ルールがバラバラ。

2. 漢数字 vs 算用数字

入力（Before）	正規化後（After）
`千代田区丸の内一丁目 2`	`東京都千代田区丸の内1丁目2`
`埼玉県春日部市８丁目 234`	`埼玉県春日部市八丁目234`

現場での起き方: 手入力・OCR・古い帳票データで漢数字が混在。8 と 八 を別住所と誤判定しがち。

3. 全角・半角の混在

入力（Before）	正規化後（After）
`東京都千代田区丸の内１－2`	`東京都千代田区丸の内1丁目2`
`千葉県印西市小倉台１丁目１`	`千葉県印西市小倉台1丁目1`

現場での起き方: Excel コピペ、旧システム連携、スマホ入力で全角数字が紛れ込む。

4. 都道府県・市区の省略

入力（Before）	正規化後（After）
`千代田区丸の内 1-1`	`東京都千代田区丸の内1丁目1`
`霞ケ関`	`東京都千代田区霞が関`

現場での起き方: 社内略称や「都内」「23区内」など、文脈依存の省略がそのまま DB に入る。

5. ビル名・フロア・部屋番号の表記ゆれ

入力（Before）	正規化後（After）
`港区虎ノ門一丁目23番1号虎ノ門ヒルズ森タワー 19F`	`東京都港区虎ノ門1丁目23-1 虎ノ門ヒルズ森タワー 19F`
`港区虎ノ門二丁目2番3号１９０１号室`	`東京都港区虎ノ門2丁目2-3 1901号室`

現場での起き方: 番地と建物名の区切りがない、19F と 1901号室 の書き方がバラバラ。

6. 旧字体・異体字・「ケ/ヶ/が」の揺れ

入力（Before）	正規化後（After）
`茨城県竜ケ崎市`	`茨城県龍ケ崎市`
`千葉県市川市相ノ川1丁目1-1`	`千葉県市川市相之川1丁目1-1`

現場での起き方: 自治体公式表記と入力表記の差、旧字体が残ったマスタデータ。

7. 京都の通り名（上ル・下ル・東入）

入力（Before）	正規化後（After）
`京都市中京区烏丸通四条上ル笋町123`	`京都府京都市中京区笋町123`
`京都市下京区河原町通五条下ル本塩竈町590-1`	`京都府京都市下京区本塩竈町590-1`

現場での起き方: 通り名ベースの住所は他地域とルールが異なり、正規表現だけでは破綻しやすい。

8. 郵便番号と住所の不一致・混入

入力（Before）	正規化後（After）
`〒060-0817 北海道札幌市北区北17条西8丁目北海道大学キャンパス`	`北海道札幌市北区北17条西8丁目北海道大学キャンパス`

現場での起き方: 郵便番号が住所欄に混ざる、または郵便番号と本文が食い違う。

9. 市町村合併・旧行政区名

入力（Before）	正規化後（After）
`埼玉県浦和市常盤六丁目4番4号`	`埼玉県さいたま市浦和区常盤6丁目4-4`
`埼玉県大里郡江南町`	`埼玉県熊谷市江南`
`東京都荏原区中延一丁目`	`東京都品川区中延1丁目`

現場での起き方: 合併前の地名が古い顧客データに残り、現行マスタと突合できない。

10. 会社名・宛名・ノイズの混入

入力（Before）	正規化後（After）
`新宿高島屋`	`東京都渋谷区千駄ヶ谷5丁目24-2 新宿高島屋`
`東京と葛飾区たかさご5ちょうめ100番1ごう`	`東京都葛飾区高砂5丁目100-1`

現場での起き方: 建物名だけの入力、ひらがな混じり、社名が住所欄に入っている。

なぜ正規表現だけだと破綻するのか

表記ゆれ対策として、次のような正規表現を足していくチームは多いです。

全角数字 → 半角数字
3-21-3 → 3丁目21番3号
丁目 の有無を吸収

しかし実際には、

例外が際限なく増える（京都通り名、合併前地名、大字/字の有無……）
文脈が必要なケースがある（霞ケ関 だけでは都道府県が不明、新宿高島屋 は建物名から住所を復元）
メンテ担当者が辞めるとルールがブラックボックス化する

結果、「住所正規化 regex ファイル」が誰も触れないレガシーになる——これはよくある話です。

Staddress ではどう解くか（概要）

Staddress では、単一の正規表現ではなく 多段パイプライン で表記ゆれを吸収しています。

ルールベース前処理 — 全角半角・記号統一など、機械的に処理できる部分
AI 住所解析 — 省略・誤字・旧地名・建物名のみ入力など、文脈が必要な部分
3ソース照合 — ABR（アドレス・ベース・レジストリ）、日本郵便データ、Google Maps を突き合わせ、信頼度スコアを付与

次回予告: 15分で試せる — Staddress API クイックスタート（curl / Node.js / Python）

住所データでお困りの方は、ぜひフォロー・いいねをお願いします！

Staddress ホームセット

Staddress に関する公式リンク一覧です。