はじめに
日本国内で利用できる住所検索API・郵便番号APIを、郵便番号→住所、住所→郵便番号の逆引き、住所検索、住所解析・正規化、住所入力UIといった実装用途ごとに比較してみます。
筆者はPostcodeJPという、日本の住所入力・住所処理向けサービスを開発・運営しています。
PostcodeJPの製品改善や、今後の新しい機能・製品を検討するために国内の住所関連サービスを改めて調べていたのですが、ひとことで「郵便番号API」「住所検索API」といっても、サービスごとに解いている問題がかなり違います。
たとえば、
- 郵便番号から住所を取得したい
- 住所から郵便番号を逆引きしたい
- 都道府県・市区町村・町域などを条件に住所を検索したい
- 入力途中の町域名などから候補を検索したい
- 自由入力された住所を解析・正規化したい
- 今ある住所フォームへ住所補完を追加したい
- 住所検索・候補選択UIそのものを組み込みたい
では、必要な仕組みが異なります。
そこで今回は、**「どのAPIが一番いいか」ではなく、「最終的に何を実装したいか」**という観点から整理してみます。
本記事は2026年9月4日時点で、各サービスの公式サイト・公式ドキュメントから確認できる公開仕様を中心に整理しています。サービスによっては詳細なAPIリファレンスがログイン後のみ公開されているため、公開情報から確認できない仕様は推測していません。
※前述のとおり、筆者は比較対象の1つであるPostcodeJPの開発・運営者です。
TL;DR
- 郵便番号→住所だけなら、シンプルなAPIを含め選択肢は多い
- 住所→郵便番号の逆引きは、部分一致・フリーテキスト・正規化などサービスによって方式がかなり違う
- 住所fieldを指定して検索したい場合は、完全一致だけでなく前方一致・部分一致やAND・ORを組み合わせられるAPIもある
- 自由入力住所の解析・正規化は、単純な郵便番号検索とは別に考えた方がよい
- 既存フォームへ住所補完したいならJavaScript型も選択肢になる
- 住所検索UI自体を作りたくないならWidget型も選択肢になる
「郵便番号API」という製品カテゴリから選ぶより、作りたい住所機能から逆算した方が選びやすいと思います。
今回比較するサービス
今回は以下を取り上げます。
| サービス | 郵便番号→住所 | 住所→郵便番号 | 主な検索・住所処理の考え方 | 主な認証 |
|---|---|---|---|---|
| PostcodeJP | ○ | ○ ※field条件から郵便番号を取得 | field指定、AND/OR、完全一致・前方一致・部分一致。自由住所解析は別製品 | API Key / Public Key（Widget） |
| 日本郵便 郵便番号・デジタルアドレスAPI | ○ | ○ | 郵便番号・デジタルアドレス検索、住所から郵便番号、フリーワード検索 | OAuth 2.0 / OpenID Connect |
| ケンオール | ○ | ○ | フリーテキスト検索、構文検索、住所正規化 | Token（API Key） |
| zipcloud | ○ | × | 7桁郵便番号の完全一致検索 | なし |
| ZIPCODA | ○ | ○ | 住所の部分一致、空白区切りAND検索 | なし |
| ZIP-JP | ○ | ○ | 部分一致、文字不足、新旧字体、数字表記差などを考慮 | API Key |
ここで重要なのは、同じ「住所→郵便番号 ○」でも、検索モデルが同じではないことです。
またPostcodeJPの「住所→郵便番号」は、住所全文をフリーテキストで逆引きする意味ではありません。都道府県、市区町村、町域などの住所fieldを検索条件として指定し、その結果から郵便番号を取得する方式です。
自由入力された住所そのものを解釈・構造化する処理は、Address Parserという別製品に分けています。
郵便番号から住所を検索できるAPIを比較する
最もシンプルなのは、
1000001
↓
東京都
千代田区
千代田
のような郵便番号→住所検索です。
この用途なら、今回取り上げたサービスの多くが対応しています。
zipcloud
zipcloudは分かりやすい例です。
7桁の郵便番号を指定して住所を検索するREST APIで、ハイフン付き郵便番号にも対応しています。JSONPも利用できます。
2026年9月4日時点では、2026年8月31日更新分の日本郵便データを使用していることも公式ページで公開されています。
「郵便番号を入力したら都道府県・市区町村・町域をフォームへ入れたい」という用途だけなら、高機能な住所検索APIが必須とは限りません。
住所から郵便番号を検索する「逆引きAPI」の違い
ここからサービスごとの差がかなり大きくなります。
ZIPCODA
ZIPCODAではaddressパラメータへ住所文字列を渡すことで、住所→郵便番号検索ができます。
住所検索は部分一致で、空白文字で区切ることでAND検索もできます。
たとえば、
東京都 千代田区 千代田
のような文字列から候補を検索するタイプです。
またCORSに対応しています。アクセス方法や制限については公式ドキュメント・利用条件を確認した方がよいでしょう。
- 公式: ZIPCODA API
ZIP-JP
ZIP-JPにはfindzipcodeという住所→郵便番号検索APIがあります。
特徴的なのは、単純な部分一致だけでなく、
- 住所途中の文字不足・脱字
- 新字体・旧字体
- 漢数字
- 全角・半角数字
などを考慮することが公式仕様に記載されている点です。
「入力された住所が必ずしも完全に正しいとは限らない」という前提を検索側である程度吸収する設計です。
- 公式: ZIP-JP APIリファレンス
ケンオール
ケンオールの住所→郵便番号APIは、さらに住所処理寄りです。
検索方法として、
- フリーテキスト検索
- 構文検索
の2種類が用意されています。
フリーテキスト検索では住所文字列をそのまま渡し、検索と同時に住所の正規化結果も取得できます。都道府県、市区町村、町域、番地、建物、階・部屋などへ分解された結果を扱えます。
一方、構文検索では項目別検索やファセット、事業所名などを条件にできます。フリーテキスト検索と構文検索の併用も可能です。
そのため、
郵便番号を逆引きしたい
だけではなく、
手元にある住所データを解析・整形したい
という用途まで含んでいるAPIです。
住所fieldを指定し、部分一致なども組み合わせるPostcodeJP Address Search API
PostcodeJP Address Search APIは、前述したフリーテキスト型の逆引きとは少し設計が違います。
自由な住所全文を1つの検索文字列として渡すのではなく、
field + operator + value
という形で、検索対象となるfieldを明示して条件を組み立てます。
たとえば、
pref==東京都
や、
pref==東京都;city==新宿区
さらに、
pref==東京都;city==新宿区;town==市谷*
のように検索できます。
fieldを指定する方式ですが、完全一致しかできるわけではありません。
現在の公開仕様では、
- 完全一致
- 前方一致
- 部分一致
- AND / ORによる複数条件
を組み合わせて検索できます。
そのため、
都道府県と市区町村は確定しているが、町域はユーザーの入力途中なので前方一致で候補を取得する
といった検索ができます。
現在は31のfilter fieldを公開しており、住所・郵便番号だけでなく、
- 事業所名
- 自治体コード
- ひらがな
- 半角カナ
- 全角カナ
- English
- 一般郵便番号／事業所個別郵便番号の区分
なども検索条件として利用できます。
またfieldsで返却項目を絞り、必要に応じてcursorやsortも指定できます。
つまりPostcodeJPのAddress Search APIは、
自由入力された住所全文を解釈して、最も近そうな住所を推測する
タイプではなく、
住所の各fieldを検索軸として指定し、その中で完全一致・前方一致・部分一致・複数条件を柔軟に組み合わせる
タイプの検索APIです。
「曖昧な検索」と「住所の誤字補正」は分けて考える
ここは少し紛らわしいところです。
この記事で「曖昧な検索」と呼んでいるのは、たとえば、
town==市谷*
のように、検索fieldを特定したうえで入力途中や部分一致を許容して候補を探せるという意味です。
一方、
東京都新宿区市ヶ谷本村町...
のような自由入力住所について、表記揺れや入力誤りも含めて住所を解釈し、住所要素へ分解する処理は別の問題です。
PostcodeJPでは、こちらをAddress Parserとして分離しています。
フリーテキスト住所からの逆引きが主目的なら、ケンオール、日本郵便、ZIPCODA、ZIP-JPのような方式の方が直接的な場合があります。一方、自社側で検索fieldや検索UIを制御したい場合は、PostcodeJPのようなfield条件型が使いやすいケースがあります。
住所解析・住所正規化APIは、郵便番号検索とは別の問題
たとえば、
東京都新宿区市谷本村町3-23
という1つの文字列から、
都道府県: 東京都
市区町村: 新宿区
町域: 市谷本村町
番地: 3-23
のような構造を取り出したい場合があります。
これは単純な郵便番号検索とは別の問題です。
ケンオール
前述したとおり、ケンオールではフリーテキスト住所を住所要素へ分割し、正規化した結果を取得できます。
住所マスタのクレンジング用途として、正規化結果だけを利用する方法も公式ドキュメントで案内されています。
PostcodeJP Address Parser
PostcodeJPでは、この用途をAddress Search APIへ含めず、PostcodeJP Address Parserという別製品として扱っています。
現在公開しているAddress ParserはPreviewです。自由形式で保存・取込された日本語住所を、都道府県・市区町村・町域・番地などの住所要素へ整理し、後続処理につなげる用途を想定しています。
また現在、筆者側ではAddress Parserをさらに発展させ、実際の住所データ処理でより有用なパースや周辺機能を扱えるよう開発を進めています。
この部分はまだ開発中なので、本記事の比較では現在公開されている仕様だけを対象とします。
日本郵便公式の「郵便番号・デジタルアドレスAPI」
2026年現在は、日本郵便自身も「郵便番号・デジタルアドレスAPI」を提供しています。
公開ページでは、
-
searchcode：郵便番号・デジタルアドレス等から住所等を取得 -
addresszip：住所から郵便番号を取得 -
token：API利用トークンを取得
というスコープが案内されています。
2026年3月からはver2.0が提供され、ビジネスデジタルアドレスにも対応しています。APIの利用は無料です。
また、日本郵便の公開ページではフリーワード検索に対応することや、郵便番号マスターデータの更新に合わせてAPI側へ反映することも案内されています。
認証・認可にはOAuth 2.0 / OpenID Connectが採用されています。
一方、利用開始までには、
- ゆうIDの登録
- ビジネスアカウント・組織登録
- API利用登録・利用システム登録
- 利用開始
という導入フローがあります。
詳細なAPIリファレンスやテスト用API情報はログイン後に提供されるため、本記事では公開ページから確認できる範囲に限定しています。
APIの認証方式も「API」と「Widget」で違う
住所機能をブラウザへ組み込む場合、認証方式も重要です。
PostcodeJPでは、製品によって使用する認証情報を分けています。
| PostcodeJP製品 | 認証情報 | 主な利用場所 |
|---|---|---|
| Address Search API | API Key | Browser / Server |
| Address AutoComplete JavaScript | API Key | Browser |
| Address Parser | API Key | API client |
| Address Selector Widget | Public Clientから取得するPublic Key | Browser |
Address Search APIをBrowserから利用する場合はHTTP Referer、Serverから利用する場合はIP/CIDRによる利用元制限を設定できます。
一方、Address Selector Widgetは通常のAPI Keyを使用しません。
管理画面で利用するWebサイトのOriginを指定してPublic Clientを作成し、そこで発行されるPublic KeyをWidgetへ設定します。
ブラウザではPublic Keyを使って短時間有効なaccess tokenを取得し、WidgetからAPIへアクセスする構成です。
つまり、
REST API
↓
API Key
既存フォームへの住所補完
↓
API Key
住所選択Widget
↓
Public Client / Public Key
という分け方になっています。
APIだけでなく「住所入力UI」をどう作るかも考える
住所検索APIを利用して住所選択機能を作る場合、APIを呼び出すだけでは終わりません。
たとえば、
- 検索入力
- 入力途中での検索
- 検索条件の組み立て
- 候補一覧の表示
- 候補選択
- 一般住所と事業所住所の扱い
- エラー処理
- 選択結果のフォーム連携
などのUI・状態管理も必要になります。
PostcodeJPでは、APIとは別に住所入力方法を2種類用意しています。
今あるフォームへ住所補完を追加したい
Address AutoComplete JavaScriptは、既存の郵便番号・住所フォームを活かしたまま、郵便番号を起点に住所補完を追加するためのHosted JavaScriptです。
フォーム自体の設計は既にあり、「郵便番号から住所欄を補完したい」という場合はこちらの考え方です。
住所検索UI自体を作りたくない
Address Selector Widgetは、住所の検索・候補表示・選択までをWeb Componentとして組み込むWidgetです。
つまり、
住所検索APIが欲しい
のではなく、
ユーザーに住所を検索して選んでもらう機能が欲しい
のであれば、APIから検索UIを自作する方法だけでなく、Widgetを利用する方法も比較対象になります。
PostcodeJPでは、Address Selector、Address Search API、Address AutoComplete JavaScriptについてはPlaygroundで実際に試せます。
「何を作りたいか」から選んでみる
ここまで調べてみると、サービス名から選ぶよりも、実装したい機能から逆算する方が分かりやすいと思います。
郵便番号を入力したら住所を取得したい
選択肢はかなり多くあります。
単純な郵便番号→住所だけでよければ、zipcloudのようなシンプルなAPIでも要件を満たせる場合があります。
住所文字列から郵便番号を逆引きしたい
日本郵便、ケンオール、ZIPCODA、ZIP-JPなどが候補になります。
特に、
- 単純な部分一致でよいか
- 表記ゆれを考慮したいか
- 文字不足・脱字も考慮したいか
- 住所正規化まで必要か
で選択肢が変わります。
住所fieldを指定しつつ、入力途中や部分一致でも検索したい
PostcodeJP Address Search APIのような、
- field指定
- 完全一致
- 前方一致
- 部分一致
- AND / OR
を組み合わせられる検索方式が候補になります。
「検索対象となる項目は分かっているが、値は必ずしも完全一致していない」という業務検索や候補検索と相性があります。
自由形式の住所を解析・構造化したい
ケンオールの住所正規化や、PostcodeJP Address Parserのような住所解析系機能を検討することになります。
検索と解析は似ていますが、実際には別の問題として考えた方がよさそうです。
今ある住所フォームへ郵便番号補完を追加したい
PostcodeJPの場合はAddress AutoComplete JavaScriptがあります。
既存フォームを大きく作り直さず、郵便番号入力を起点に住所fieldを補完する方式です。
住所検索UI自体を作りたくない
PostcodeJP Address Selector Widgetのような、検索・候補表示・選択UIをまとめて提供する方式を検討できます。
APIの機能だけではなく、最終的なUIを自社でどこまで実装するかも選定条件になります。
今回の調査で改めて感じたこと
今回ほかのサービスを調べ直して改めて感じたのは、「どんなAPIを提供するか」よりも、利用者が最終的に何を完成させたいかから考える必要があるということです。
郵便番号から住所を取得する、住所を逆引きする、自由住所を解析する、既存フォームを補完する、検索・選択UIを提供する――これらは似ているようで別の課題です。
PostcodeJPでも現在は、検索をAddress Search API、既存フォーム補完をAddress AutoComplete JavaScript、選択UIをAddress Selector Widget、自由住所の解析をAddress Parserという形で分けています。
今後の製品・機能検討でも、APIの機能数を増やすこと自体ではなく、利用者が最終的に完成させたい住所機能から逆算して考えていきたいと思います。
まとめ
今回はPostcodeJPの製品改善や、新しい機能・製品を検討するために、日本国内の住所検索API・郵便番号APIを改めて調べてみました。
一口に住所・郵便番号APIといっても、
- 郵便番号→住所
- 住所→郵便番号
- fieldによる条件検索
- 前方一致・部分一致などを使った候補検索
- 自由入力住所の解析・正規化
- 既存フォームへの住所補完
- 検索・候補選択UIそのもの
では、解いている問題が違います。
そのため、
「郵便番号APIではどれが一番いいか」
から考えるより、
「最終的にどんな住所機能を作りたいか」
を先に決めてからサービスを比較する方が、選びやすいと思います。
PostcodeJPについては筆者自身が開発しているため、今回調べた各サービスの設計や機能も参考にしながら、引き続き改善していく予定です。