「渋谷区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 に関する公式リンク一覧です。