サービスは安定して稼働していますか？

はい。日本国内の複数データセンターに分散配置された冗長構成で運用しています。

一部インフラ障害が発生しても、DNS / ロードバランサ制御によりサービス継続を前提とした設計です。

apis.postcode-jp.comへのリクエストは、高可用性・低レイテンシなグローバルDNSによりIPアドレスへ変換されます。
APIへのアクセスは、世界中に分散されたスケーラブルなロードバランサを経由し、アクセス元に最も近いデータセンターにルーティングされます。

計画停止はありますか？

原則ありません。
データ更新・バージョン切り替えは無停止で実施され、API提供を止めることはありません。

無料プランと有料プランの違いは？

API機能・レスポンス品質・データ内容は同一です。
差分は以下のみです。

• 1日あたりのリクエスト上限
• 秒間リクエスト数（レート制限）

開発・本番ともに同一API仕様で利用できます。

郵便番号データ更新やAPIの機能追加等によりサービス停止は発生しますか?

郵便番号データはバージョン管理されているため、データ更新中であってもサービス停止は発生せず、常に整合性の取れた郵便番号データにアクセスできます。
新しい郵便番号データは、APIが参照しているオンラインバージョンとは別の新バージョンとして作成し、準備が整い次第オンラインバージョンを切り替えます。

APIの機能追加・改善のリリース時には、Google Kubernetes Engine のローリングアップデートを利用することで、サービスを停止することなく順次アップデートを適用しています。

SLA（稼働率保証）はありますか？

現時点では数値保証付きSLAは提供していません。
ただし、商用サービス利用を前提とした可用性設計・監視・迅速な障害復旧体制を採っています。

PostcodeJP APIは無停止に近い高品質なサービス提供を目標とし、継続的にシステムアーキテクチャの改善を行っています。
2019年1月には、可用性・レイテンシ・機能品質のさらなる向上のため、大幅なシステムアーキテクチャ変更を実施しました。

APIは地理的に離れた複数拠点でホストされ、ユーザ管理を行うバックエンドサービスと分離されたことで可用性が向上しています。
また、郵便番号データをホストするデータベースを NoSQL からリレーショナルデータベースへ移行することで、内部レイテンシの短縮と提供可能な機能の拡張を実現しました。

導入実績はありますか？

2017年のサービス開始以来、直近時点で約5,600件のアクティブアカウントに利用されています。

（処理実績の一例）イベントチケット販売プラットフォームの事例では、 1日あたり最大約126,000リクエストのピークトラフィックを安定して処理しています。

業種例：

• ECサイトにおける配送先住所・請求先住所入力フォームへの住所補完JavaScriptおよび郵便番号APIの導入
• Webサービスの申込画面で、お客様システムのアプリケーションサーバ側から郵便番号APIを実行し住所補完を実現
• 介護支援専門員向け顧客情報管理サービスでの顧客住所入力フォームおよび地図表示機能への郵便番号API導入
• 事業者向け請求管理スタンドアローンアプリケーションへの郵便番号API導入
• イベントチケット販売プラットフォームのWebアプリ・モバイルアプリからの郵便番号API利用
• C2C向けモバイルアプリにおける契約者住所・配送先住所入力への郵便番号API導入
• 生命保険販売員向けWebシステムの顧客情報入力時における郵便番号APIの利用
• 金融機関の新規口座Web申込における住所入力での郵便番号API・都道府県市区町村APIの利用

※ 個別企業名やロゴは非公開としていますが、EC・物流、金融・決済、SaaS・業務システム、不動産・保険、医療、行政関連など幅広い業種で導入されています。

データ更新頻度は？

• 毎日定期更新
• 必要に応じて不定期の品質改善更新を実施

定期更新の実行時間帯は、運用状況に応じて見直す場合があります。

更新中も常に整合性が保たれるよう、バージョン切替方式で反映されます。

ロケーション（緯度・経度）は何を根拠に、どのように算出していますか？

PostcodeJP API のロケーションは、国土数値情報（行政区域データ）および 国土交通省の位置参照情報（街区・町丁目等）を統合し、 住所の粒度（都道府県 / 市区町村（区を含む） / 郵便番号）ごとに 定められた優先順位に基づいて算出しています。

座標系には SRID=4326（WGS84） を使用し、 経度 → 緯度（lon, lat）の順で扱います。 ロケーションを確定できない場合は返却されません。

1) 都道府県のロケーション

都道府県単位のロケーション（代表点）は、以下の優先順位で算出し、 最初に取得できたものを採用します（後続の手順で上書きはしません）。

1. 行政区域データ（N03）の都道府県代表点
   事前生成した代表点データから都道府県コード（2桁）で取得します。
2. 位置参照情報（MLIT）から算出した都道府県単位の重心
   位置参照情報（大字町丁目）のポイント群から、都道府県単位で単純平均（重心）を算出して採用します。
3. 最終フォールバック：県内の代表的な市区町村の代表点（N03）
   上記で確定できない場合、当該都道府県内で「ユニーク郵便番号数が最も多い市区町村」を代表として選び、 その市区町村代表点を採用します（海上など不自然な位置への落ち込みを避けるためのフォールバックです）。

補足) 都道府県ロケーションと県庁所在地の違いについて

都道府県のロケーションは、都道府県の行政区域全体を代表する位置として算出されます。 そのため、沖縄県や東京都など、島嶼部を含む・広域に分散する都道府県では、 一般的に想起される県庁所在地（例：那覇市、千代田区）と一致しない場合があります。 これは算出ロジック上の仕様であり、異常や誤りではありません。

2) 市区町村（区を含む）のロケーション

市区町村（政令指定都市の区を含む連結単位）のロケーション（代表点）は、 以下の優先順位で算出し、最初に取得できたものを採用します（後続の手順で上書きはしません）。

1. 行政区域データ（N03）の市区町村代表点
   事前生成した代表点データから自治体コード（5桁）で取得します。
2. 区単位の重心（MLIT）
   区情報が存在し、位置参照情報（大字町丁目）のポイント群から区単位の重心を算出できる場合に採用します。
3. 市区町村単位の重心（MLIT）
   位置参照情報（大字町丁目）のポイント群から市区町村単位の重心を算出して採用します。
4. 最終フォールバック：都道府県代表点（N03）
   上記で確定できない場合、都道府県代表点を採用します。

補足) 市区町村ロケーションについて

市区町村（政令指定都市の区を含む）のロケーションも、庁舎所在地（市役所・区役所）を示すものではありません。 行政区域全体を代表する位置として算出されるため、地理的に分散した区域や島嶼部を含む自治体では、 地図上の見た目が直感と異なる場合がありますが、仕様上は正常な挙動です。

3) 郵便番号のロケーション

郵便番号単位のロケーションは、国土交通省の位置参照情報（街区・大字町丁目）を優先し、 取得できない場合は同一郵便番号内の重心や市区町村単位の重心へフォールバックします。

1. 街区レベルの代表点
   街区情報を解釈でき、位置参照情報（街区）から取得できる場合に採用します。
   ※ 同一キーに複数点が存在する場合は平均（重心）を採用します。
2. 町丁目レベルの代表点
   丁目を解釈でき、位置参照情報（大字町丁目）から取得できる場合に採用します。
   ※ 同一キーに複数点が存在する場合は平均（重心）を採用します。
3. 町域レベルの代表点
   丁目が無い／解釈できない場合に、町域単位で位置参照情報（大字町丁目）から取得できる代表点を採用します。
4. 同一郵便番号内の重心
   同一郵便番号内で、上記(1)〜(3)により直接取得できた座標が一定数以上集まる場合に限り、 その平均値（重心）を採用します。
   
5. 市区町村（区を含む）単位の重心
   参照データから市区町村（区を含む連結単位）の重心を算出し、最終フォールバックとして採用します。

郵便番号ロケーションの補足

郵便番号のロケーションは、建物や施設の所在地を示すものではありません。

また、入力データの住所表記（丁目・街区など）の有無や、参照データ側の収録状況により、 ロケーションの粒度が 街区 → 町丁目 → 町域 → 郵便番号重心 → 市区町村重心 の順に変化します。

※ ロケーションは住所入力補完や地図表示を目的とした位置情報であり、 建物単位の正確な座標を保証するものではありません。

レスポンス項目名・返却形式の詳細は APIリファレンス に記載の定義に準拠します。

出典および利用条件について

PostcodeJP API では、以下の日本郵便株式会社および関係行政機関が提供する公的データを、 各データの利用規約に従って取得・加工・統合し、 ロケーション算出および住所の正規化・解析に利用しています。

• 住所の郵便番号（日本郵便株式会社）
  「住所の郵便番号（CSV形式、ローマ字）、事業所の個別郵便番号（CSV形式）」（日本郵便株式会社）
• 位置参照情報（国土交通省 国土数値情報）
  「国土数値情報（街区レベル位置参照情報、大字・町丁目レベル位置参照情報）」（国土交通省）
  「国土数値情報（行政区域データ）」（国土交通省）
• アドレス・ベース・レジストリ（デジタル庁）
  「アドレス・ベース・レジストリ（都道府県マスター、市区町村マスター、町字マスター、住居表示-街区マスター、住居表示-住居マスター、地番マスター）」（デジタル庁）

※ 各データの利用条件・提供条件については、リンク先に記載の利用規約に準拠しています。
※ これらの原データはそのまま再配布するものではなく、PostcodeJP API 独自の正規化・補正・代表点算出等の処理を行った結果を提供しています。

無料プランの上限（1日/秒間）は？

無料プラン/有料プランの違いは、1日あたりの上限と秒間レート制限です。
上限値はプランにより異なります。最新の上限値は 料金プラン をご確認ください。

目安：Freeプランは 384 回/日、レート制限は 1 回/秒 です。

レート制限に達した場合の挙動は？

秒間レート制限を超えた場合、APIは HTTP 429 (Too Many Requests) を返します。
一定時間待ってから再試行してください。

※ クライアント実装では、指数バックオフ（exponential backoff）やリトライ間隔の制御を推奨します。
レート制限時のレスポンスには Retry-After ヘッダが含まれます。指定された秒数待ってから再試行してください。

APIキーはどこで発行できますか？漏洩した場合は？

APIキーは ダッシュボード から発行・管理できます。

万一APIキーが漏洩した可能性がある場合は、ダッシュボードで当該キーを無効化し、新しいキーを発行してください。
（キーのローテーションにより、影響を最小化できます）

ログは保存されますか？個人情報の扱いは？

サービスの安定運用・不正利用対策のため、アクセスログ（時刻、リクエスト量、エラー率など）を記録します。
取り扱いはプライバシーポリシーに基づき、運用改善とセキュリティ目的の範囲で利用します。

住所入力フォームで扱われる情報はサービス上センシティブになり得るため、運用上の取り扱い（保存項目・保存期間）は必要最小限となるよう設計しています。
詳細は プライバシーポリシー をご確認ください。

送信元IP制限はできますか？

はい、送信元IP制限に対応しています。ダッシュボードからAPIキーに対して許可IPを登録してください。

支払い方法を教えてください

以下に対応しています。

適格請求書（インボイス）に対応していますか？

はい。2026年1月以降の請求分より、適格請求書の発行に対応しています。

※ 2025年12月31日以前に提供した役務に関する請求は、適格請求書の対象外となります。

初期導入費用は必要ですか?

PostcodeJP API の利用開始にあたって、初期導入費用は発生しません。
料金プランに記載されている月額料金のみをお支払いいただきます。

商用利用は可能ですか？

可能です。追加料金・クレジット表記義務はありません（利用規約の範囲内）。

請求書は毎月メールで送付されますか?

はい。お支払い方法（クレジットカード / 請求書払い）によらず、毎月の請求書・領収書はメールで自動送付されます。
あわせて、ログイン後のダッシュボードからもPDF形式で請求書・領収書をダウンロードしていただけます。

請求サイクル（課金タイミング）はどのようになっていますか?

【請求サイクルの要点】
・はじめての有料プラン → 14日間の無料トライアル
・トライアル終了時刻が請求サイクルの起算点
・請求は「各請求サイクルの開始時点」で発生
・アップグレードは即時反映、差額は次回請求時に自動調整
・ダウングレードは現在のサイクル終了後に適用

PostcodeJP API の有料プランは 月払い / 年払い のサブスクリプション方式です。
初めて有料プランを選択された場合は、最初に 14日間の無料トライアル が開始され、 トライアル終了日の翌日から最初の請求期間が開始されます。

各請求期間の開始タイミング（プラン選択日またはトライアル終了日）を起点に、1か月または1年ごとに自動更新されます。
請求は 各請求期間の開始時点 に発生します。

Stripe の仕様により、請求期間は日単位ではなく 時間単位 で管理されています。
例）4月10日 15:20 にトライアル開始 → 4月24日 15:20 にトライアル終了 → 同時刻に有料期間開始

アップグレード（上位プランへの変更）
プラン変更は即時反映され、API キーの制限値も即座に上位プランへ更新されます。
現在の請求期間内の残期間に応じた 差額は自動的に按分（proration）計算 され、
その差額は 次回請求時にまとめて清算 されます（Stripe 標準仕様）。

ダウングレード（下位プランへの変更）
申請時点では即時反映されず、現在の請求期間が終了した時点で自動的に適用されます。
請求期間中に下位プランへ切り替わることはありません。

請求書・領収書
支払い方法（クレジットカード / 請求書払い）にかかわらず、毎月の請求書・領収書はメールで自動送付されます。
また、ダッシュボードからいつでも PDF をダウンロードできます。

請求書払いの条件（審査・支払期限など）は？

請求書払いをご希望の場合は、ダッシュボードから申請してください。申請後、数営業日以内に請求書払いが有効になります。

審査では、以下の情報をもとに請求先の正当性を確認します。

• アカウントや請求先のメールアドレスのドメイン
• 入力された請求先名（法人名等）
• 入力された請求先住所

支払期限は、請求書発行日から62日です。

どのような導入サポートを受けることができますか?

料金プランの選定、API仕様に関するご質問、実装方法のご相談などについて、メールによる技術サポートを提供しています。
ご不明点がありましたら、サポート窓口までお問い合わせください。

お客様プロダクトのソースコードへの実装作業など、個別の開発を伴う対応については、別途ご契約のうえで承る形となります。

今後、法人による運営をされる予定はありますか? サービスの永続性はありますか?

現時点では、運営主体を変更する具体的な時期は未定です。
PostcodeJP API として今後も実現したい機能や改善計画が多くあり、サービスの継続的な提供を前提として運営しています。

運営主体の変更を理由として、予告なくサービスを恒久的に停止することは想定していません。
運営方針や体制に大きな変更がある場合は、事前に公式サイトおよびメールで告知します。

障害等でシステムダウンが発生した場合の復旧は迅速に行われますか?

システムダウンが発生した場合には、できる限り迅速に復旧対応を行います。
APIのヘルスチェックに異常が検知された際は、即座に開発者に通知され、影響範囲の把握と並行して復旧作業を開始します。状況については APIステータスページにて随時ご案内します。

クラスタ構成で吸収できないインフラ障害が発生した場合には、地理的に離れた別リージョン / ゾーンにシステム全体を再構築することで復旧を行います。
データベースに障害が発生した場合は、自動的にスタンバイデータベースへのフェイルオーバーを行い、サービス継続を図ります。

お客様のアカウント情報やプラン情報等の重要なマスタデータは、クラウドベンダのデータストア上で自動レプリケーションされ、さまざまな障害から保護されています。これにより、万が一APIが稼働するインフラが完全にダウンした場合でも、正常なゾーンへサービスを復元することが可能です。

PostcodeJP API ではサービスリリース以来、想定される障害パターンに備えたシステムアーキテクチャの継続的な更新とともに、障害発生時の復旧プロセスをステージング環境で定期的に検証し、サービス提供品質の向上に取り組んでいます。