日本郵便APIとzipcloudの違い

どちらも「7桁の郵便番号を渡すと住所が返る」APIです。この一点だけを見ると差がないように見えますが、運営主体も、使い始めるまでの手順も、検索できる対象も違います。

先に結論を書きます。

• 今すぐ動かして挙動を確かめたい

  zipcloud。ドキュメントに認証の記載がなく、URLを叩けば JSON が返ります。ただし規約では、アクセス回数やアクセス時間の制限を設けることがあるとされ、損害については責任を負わないと定められています。

  zipcloud の詳細

• 日本郵便のデータを一次情報として直接使いたい

  日本郵便の郵便番号・デジタルアドレスAPI。「ご利用は無料です」と記載されていますが、ゆうID・組織登録・OAuth 2.0 / OpenID Connect の実装が前提になります。

  日本郵便APIの詳細

• 住所から郵便番号を引きたい（逆引き）

  日本郵便API。住所から郵便番号を返す addresszip スコープが用意されています。zipcloud のドキュメントには、逆引きに関する記載はありません。

• 事業所個別番号も検索対象に入れたい

  日本郵便API。searchcode スコープが事業所個別番号からの検索に対応すると記載されています。zipcloud のドキュメントには、事業所個別番号に関する記載はありません。

並べて見る

公式ページに記載があった項目だけを並べます。記載が見つからなかった項目は、空欄にせず「記載なし」と書いています。

導入コストの差が最も大きい

機能差よりも先に効いてくるのが、ここです。

zipcloud は、ドキュメントに認証の記載がありません。エンドポイントに郵便番号を渡すだけです。

curl 'https://zipcloud.ibsnet.co.jp/api/search?zipcode=1600022'

日本郵便APIは、利用ガイドに「ゆうIDを登録」→「郵便番号・デジタルアドレス for Bizの登録」→「郵便番号・デジタルアドレスAPIの利用登録」→「ご利用スタート」という順序が示されています。認証は OAuth 2.0 / OpenID Connect で、トークンを取得する token スコープが別に用意されています。

つまり日本郵便APIは、コードを書く前に組織としての登録が終わっている必要があります。 個人が思いついた日の夜に試す、という使い方には向きません。逆に言えば、組織として正式に使うことが決まっているなら、この手順は一度きりのコストです。

検索できる対象が違う

ここが機能面での実質的な差です。

逆引き（住所 → 郵便番号）

日本郵便APIには addresszip スコープがあり、「住所から該当する郵便番号を返却」と記載されています。zipcloud のドキュメントに、住所から郵便番号を引く機能の記載はありません。

既存の住所データに郵便番号を補完したい、という要件があるなら、この時点で候補は絞られます。

事業所個別番号

大口の事業所には、町域とは別に個別の郵便番号が設定されています。日本郵便が公開している郵便番号データの読み仕様には、次のように書かれています。

このデータファイルには、町域に設定した郵便番号のみを入れており、大口事業所へ個別に設定する郵便番号は入れておりません。

一方、日本郵便APIの searchcode スコープは「デジタルアドレス/郵便番号/事業所個別番号から該当する住所とビジネス情報を返却」すると記載されています。

zipcloud のドキュメントには、データについて「2026年6月30日更新分の全国一括データ（加工済バージョン）」と記載されていますが、事業所個別番号を扱うという記載はありません。

法人向けサービスで、企業の住所入力に郵便番号補完を使う場合は、ここを実際のデータで確かめてください。 個別番号が引けないと、該当なしになります。

デジタルアドレス

日本郵便APIの searchcode スコープは、デジタルアドレスからの検索にも対応すると記載されています。zipcloud にはこの概念自体がありません。

レスポンスの扱い方の差

zipcloud はレスポンスの項目がドキュメントに明記されています。

type ZipcloudResult = {
  zipcode: string // 7桁の郵便番号
  prefcode: string // JIS X 0401 の2桁都道府県コード
  address1: string // 都道府県名
  address2: string // 市区町村名
  address3: string // 町域名
  kana1: string // 都道府県名カナ
  kana2: string // 市区町村名カナ
  kana3: string // 町域名カナ
}
 
type ZipcloudResponse = {
  status: number // 200 / 400 / 500
  message: string | null
  results: ZipcloudResult[] | null // 該当なしのとき null
}

エラーコードは 400（入力パラメータエラー）と 500（API内部で発生したエラー）が記載されています。

カナが返ってくるのは、実装上ありがたい点です。フリガナ欄を持つフォームでは、kana1 〜 kana3 をそのまま使えます。

日本郵便APIについては、利用ガイドにレスポンス項目の一覧の記載が見つかりませんでした。実装前に、利用登録後のドキュメントで確認してください。 本サイトでは、確認できていない項目を推測で埋めることはしません。

results が配列で返る点にも注意が必要です。zipcloud には limit パラメータがあり、「同一の郵便番号で複数件のデータが存在する場合に返される件数の上限値」と説明されています。既定値は 20 です。

→ 郵便番号APIが返す複数候補をどう扱うか

どちらを選ぶか

両方を併用する構成も現実的です。 開発と検証は zipcloud で進め、本番の切り替え先として日本郵便APIの登録を並行して進める、という順序です。その場合は、外部APIを呼ぶ層を1ファイルに閉じ込めておいてください。

→ Next.jsで郵便番号から住所を自動入力する方法

どちらを選んでも変わらない注意点

→ 住所APIの利用規約とキャッシュ制限を確認するポイント

関連ページ

• 日本の郵便番号検索API比較 — 他の選択肢も含めた一覧
• 日本郵便 郵便番号・デジタルアドレスAPI
• zipcloud 郵便番号検索API
• 住所検証・住所正規化・ジオコーディングの違い