住所検証・住所正規化・ジオコーディングの違い

「住所 API」で検索すると、まったく役割の違うサービスが同じ棚に並びます。選び間違えると、必要な機能が手に入らないか、必要のない費用を払うことになります。

入力と出力で整理すると、混乱しません。

4つの処理

郵便番号検索

7桁の数字を渡すと、対応する町域までが返ります。番地から先は返りません。

入力: 160-0022
出力: 東京都 / 新宿区 / 新宿

用途はほぼ1つ、入力の手間を減らすことです。会員登録や配送先入力で、郵便番号を入れたら都道府県以下が埋まる、あの挙動がこれです。

注意点が2つあります。

• 1つの郵便番号に複数の町域が対応することがあります。 1件目を勝手に採用せず、候補が複数あるなら選ばせてください。
• 返ってきた住所が正しいことの証明にはなりません。 続く番地が実在するかは誰も見ていません。

→ 郵便番号検索APIの比較

住所正規化

表記のゆれを吸収して、比較できる形に揃えます。

入力: 東京都新宿区西新宿２－８－１
      東京都新宿区西新宿2丁目8番1号
出力: どちらも 都道府県=東京都 / 市区町村=新宿区 / 町名=西新宿 / 番地=2-8-1

「同じ住所かどうか」を機械が判定できる状態を作るのが目的です。名寄せ、重複排除、既存データとの突合で必要になります。

正規化には2段階あります。

1. 形式の正規化 — 全角と半角、ハイフンの種類、〒記号、余分な空白。ライブラリも外部APIも要らず、ブラウザ内で完結します。
2. 構造の正規化 — 住所文字列を都道府県・市区町村・町名・番地へ分解する。これには住所マスタが必要です。

1 の範囲は住所整形ツールでそのまま試せます。2 は住所データを持つライブラリやサービスが必要です。

正規化は実在性を保証しません。 「東京都新宿区西新宿9-99-99」もきれいに正規化できます。

→ 全角・半角・ハイフンを整える住所正規化の基本

住所検証

その住所が実在するかを判定し、問題のある箇所を指摘します。

入力: 東京都新宿区西新宿2-8
出力: 判定=不完全 / 番地が不足している可能性 / 修正候補

「配送できる住所か」に近い問いに答えるのが検証です。 EC の配送先、本人確認、請求先の確認といった、間違っていると実害が出る場面で使います。

導入時に見落とされがちな点があります。検証APIは判定と候補を返すだけです。 候補をユーザーに見せて選ばせる UI がなければ、判定結果は使われません。導入コストの大半は API 費用ではなく、この UI の設計にかかります。

→ 日本向け住所検証API比較

ジオコーディング

住所を緯度経度に変換します。逆に座標から住所を求めるのがリバースジオコーディングです。

入力: 東京都新宿区西新宿2-8-1
出力: 緯度 35.68…, 経度 139.69…

地図表示、配送エリアの判定、店舗からの距離計算などに使います。

座標が返ってきたことは、住所が正しいことを意味しません。 多くのジオコーダは、番地まで特定できない場合に町域の代表点を返します。返ってきた座標の「精度レベル」を必ず確認してください。

もう1つ、結果を保存してよいかはサービスごとに違います。 呼び出し回数を減らすために DB へ保存する設計は一般的ですが、規約でキャッシュが制限されていることがあります。実装前に必ず確認してください。

→ 日本のジオコーディングAPI比較

よくある取り違え

自分に必要なものを決める

複数当てはまる場合でも、一度に全部入れないでください。 効果が測れなくなります。まず1つ選んで、改善したかを確認してから次に進むほうが確実です。

関連ページ

• 全角・半角・ハイフンを整える住所正規化の基本
• 日本の住所入力フォーム設計
• 住所整形ツール — 形式の正規化をブラウザ内で試す