住所検証API比較：日本の住所に使えるのはどれか

結論から

「住所検証」で探している人の多くが、実際に解決したいのは別々の3つの課題のいずれかです。まず、自分の課題がどれに当たるかを整理してください。

• 入力された住所が実在するか確かめたい

  この目的に直接対応するのは Google Address Validation API です。ただし、日本はプレビュー（GA前）扱いで、課金の有効化が前提になります。

  Google Address Validation の詳細

• 表記のゆれを吸収して比較・突合できる形にしたい

  それは「検証」ではなく「正規化」です。Geolonia の normalize-japanese-addresses のように、住所文字列を都道府県・市区町村・町名・番地へ分解する方法が向いています。

  Geolonia normalize の詳細

• 入力の手間を減らしたい・打ち間違いを減らしたい

  郵便番号から住所を補完するだけで足りることが多く、検証APIは不要です。無料で始められる選択肢もあります。

  郵便番号検索APIの比較

• 手元のデータの表記を整えたいだけ

  APIを入れる前に、ブラウザ内で完結する整形ツールで何がどこまで直るかを確認できます。

  住所整形ツールを試す

まず用語を分けます

日本語の記事では混同されがちですが、次の4つはまったく別の処理です。

やりたいこと	呼び方	入力	出力
その住所は実在するか	住所検証（Address Validation）	住所文字列	実在性の判定・修正候補・欠落している要素
表記を揃えて突合できる形にする	住所正規化（Normalization）	住所文字列	分解された住所要素
郵便番号から住所を埋める	郵便番号検索	7桁の郵便番号	都道府県・市区町村・町域
地図に置きたい	ジオコーディング	住所文字列	緯度・経度

郵便番号検索は検証ではありません。 160-0022 を渡せば「東京都新宿区新宿」が返りますが、続く「3-1-13」が実在するかは誰も見ていません。同じように、正規化は表記を揃えるだけで、揃った先の住所が存在するかは保証しません。

比較表

それぞれの守備範囲

Google Maps Platform Address Validation API

住所の検証・標準化・ジオコーディングをまとめて行い、コンポーネント単位で「どこが問題か」を返します。入力内容の修正をユーザーに促すUIを実装するときに、必要な情報がそろう選択肢です。

日本を使ううえで押さえるべき点が2つあります。

1. 日本はカバレッジ表に含まれるものの、プレビュー（GA前）扱いです。公式ドキュメントはプレビュー対象国について、リクエストに region_code を含めることを強く推奨しています。
2. 課金の有効化が前提です。SKU は Address Validation Pro と Address Validation Enterprise の2種類で、1,000リクエストあたりの単価は公式の料金表で確認してください。

なお公式ドキュメントには、USPS 向けに人工的に作られた住所のリクエストが監視されている旨の記載があります。テストデータを大量に投げる設計にはしないでください。

Geolonia normalize-japanese-addresses

こちらは検証ではなく正規化です。住所文字列を都道府県・市区町村・町名・番地へ分解します。ソースコードは MIT ライセンス、住所データはデジタル庁のアドレス・ベース・レジストリ由来で CC BY 4.0 です。

商用で使う場合の注意が明確に書かれています。

• 公開エンドポイントは現時点で「制限無しの無料公開」ですが、**「様子見ながら公開を停止や変更など行うことがあります」**と明記されています。
• 商用稼働については**「ご自身でデータを作成しホスティングすることを強くおすすめします」**とされています。
• データの網羅性は無保証で、デジタル庁側のマスターデータの状況によって欠けが出ることがあると書かれています。

つまり「無料のAPIとして本番環境から継続的に呼び出す」使い方は想定されていません。自前ホスティングを前提に検討してください。

zipcloud 郵便番号検索API（比較のための対照）

このページに並べているのは、検証の代わりにならないことを示すためです。

zipcloud が返すのは郵便番号に対応する都道府県・市区町村・町域までです。番地や建物名は扱いません。「住所が正しいか確かめたい」という要求に対して、この種のAPIは答えを持っていません。

一方で、入力ミスを減らすという目的なら十分に有効です。詳しくは郵便番号検索APIの比較を参照してください。

用途別の選び方

配送先の不備を減らしたい（EC・物流） Address Validation API が直接対応する用途です。ただし、日本がプレビュー扱いであることを踏まえ、まず自社の実データの一部で挙動を確かめてから全面導入を判断してください。費用は呼び出し量に比例します。

社内データの名寄せ・重複排除 必要なのは正規化です。同じ住所が「3-1-13」「三丁目1番13号」「３－１－１３」と書かれていても同一と判定できる状態を作ります。Geolonia のライブラリを自前ホスティングで使うのが現実的です。検証APIを呼ぶ必要はありません。

会員登録フォームの入力補助 郵便番号検索で足ります。検証APIを入れる前に、郵便番号からの自動入力とフォームの分割設計を見直すほうが、費用対効果は高くなります。

まず手元のデータに表記ゆれがどの程度あるか知りたい 住所整形ツールに貼り付けると、全角・半角、ハイフンの種類、〒記号、余分な空白といった「形式の問題」がどこまで自動で直るかが分かります。ブラウザ内だけで処理するので、データを外に出さずに試せます。

判断を間違えやすいところ

「検証APIを入れれば住所が正しくなる」わけではありません。 検証APIが返すのは判定と候補です。候補をユーザーに選んでもらうUIがなければ、判定結果を活用できません。導入コストの大半を占めるのは、APIの利用料ではなく、このUIの設計です。

正規化だけでは実在性は分かりません。 「東京都新宿区新宿9-99-99」はきれいに正規化できますが、実在するとは限りません。

無料の公開エンドポイントに本番トラフィックを流さないでください。 Geolonia は自前ホスティングを推奨しており、zipcloud の規約にもアクセス回数の制限を設ける場合があると書かれています。無料であることと、止まらないことは別です。

ほかの用途で選ぶ

実在性の判定までは要らない、という場合は別の種類のAPIが該当します。

• 郵便番号から住所を補完したいだけ → 郵便番号API比較
• 住所から緯度経度を求めたい → ジオコーディングAPI比較

料金・条件の確認について

このページに記載した内容は、上部に表示している確認日時点で各社の公式ドキュメントを確認したものです。仕様や規約は変わります。実装前に必ず公式ページで最新の内容を確認してください。

誤りを見つけた場合はお問い合わせからご連絡ください。