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

APIの選定でいちばん高くつく間違いは、実装を終えてから規約を読むことです。

料金や機能なら、あとから比べ直せば済みます。しかし「取得したデータを保存してはならない」と書かれていた場合、直すのは設定ではなくアーキテクチャです。キャッシュを前提にした構成は、丸ごと組み直しになります。

このページでは、住所APIで実際に問題になる6つの条項と、その探し方をまとめます。

1. キャッシュ・保存

最初に読むべきはここです。呼び出し回数を減らすために結果をDBへ保存する設計は一般的ですが、それを禁じている規約が実在します。

NAVITIME API の利用規約には、次の条項があります。

お客様は、本申込書に定めたデータを本申込書に定めた用途のために保存する場合を除き、本件サービスを通じてナビタイムから提供を受けたデータ（本件サービスの使用により出力された緯度経度情報も含みますがこれに限られません。）をキャッシュ等に保存してはならないものとします。（第5条第5項）

読み落としやすいのは括弧の中です。**「出力された緯度経度情報も含む」**と明記されています。「住所文字列は保存していないから大丈夫」という理屈は通りません。

探すときのキーワードは「キャッシュ」「保存」「複製」「蓄積」「データベース」です。英語の規約なら cache、store、copy、retain を探します。

2. 商用利用

「無料」と「商用利用可」は別の話です。

zipcloud の利用規約は、禁止事項を定めた第2条に13項目を挙げており、その中に「当社が、過度若しくは不適切と判断する商用目的の宣伝・広告行為」（第7号）が含まれます。

条項の形は、おおむね次のどれかです。

• 商用利用を明示的に許可している
• 商用利用を明示的に禁止している
• 特定の商用利用の形だけを禁止している（zipcloud はこの形）
• 何も書かれていない

3つ目と4つ目が判断に迷うところです。禁止されている行為に自社の使い方が当てはまらないとしても、それは「許可された」という意味ではありません。

3. 第三者提供・再配布

自社サービス内で使うのか、他社に提供するのかで、可否が変わります。

日本郵便の郵便番号・デジタルアドレスAPI の利用ガイドには、「本APIの第三者企業への提供は利用規約で禁じられています」と記載されています。

NAVITIME の規約にも、対応する条項があります。

お客様は、本契約に明示的な定めがある場合又はナビタイムの事前の書面による承諾がある場合を除き、本件サービスを第三者に対して、譲渡、使用許諾、貸与その他の一切の処分をしてはならないものとします。（第5条第2項）

自社が SaaS を提供していて、その機能の一部として住所APIを使う場合、この条項に当たる可能性があります。 該当しそうなら、実装前に提供元へ確認してください。ここは自己判断で押し切ってよい種類の条項ではありません。

4. クレジット表示・権利表示

表示が必須なら、それはデザインの制約になります。フッターに1行入れるだけで済むこともあれば、地図の上に常時表示が求められることもあります。

NAVITIME の規約は、権利表示を「除去、変更その他これに類する一切の行為」をしてはならないと定めています（第5条第4項）。これは既存の表示を消してはいけないという規定であり、新たにクレジットを掲出せよという規定とは別のものです。本サイトでは、この2つを混同しないよう、NAVITIME のクレジット要否は「要確認」として扱っています。

一方、HeartRails Geo API と Yahoo! ジオコーダAPI は、クレジット表示が必須です。

5. レート制限

数値が公開されているかどうかで、できることが変わります。

日本郵便APIの利用ガイドは「一定時間内のリクエスト数に制限（レートリミット）を設けています」と記載し、具体的な数値は公開していません。zipcloud の規約も「ユーザによる本APIの利用に一定の制約（たとえば本APIへのアクセス回数、アクセス時間の制限など）を設けることがあります」（第4条第2項）と定めています。

数値が公開されていないAPIを一括処理に使うのは、最も危険な使い方です。 深夜に数万件を流したところで遮断された、という事態を規約上は止められません。

6. 免責・SLA

障害時に何が保証されるかです。

zipcloud の規約は、本APIの使用または使用不能等に起因する損害について「責任を負わないものとします」と定めています（第6条第3項）。これは無償で公開されているAPIとしては一般的な条項ですが、業務システムの必須経路に置いてよいかどうかは別の判断になります。

住所補完が止まったときに、フォーム全体が使えなくなる設計にしないでください。手入力で先へ進める導線があれば、免責条項があっても被害は限定されます。

「記載がない」をどう扱うか

これが最も重要な区別です。

実例を挙げます。Google Maps Platform の利用規約は分量が多く、キャッシュに関する条項は License Restrictions の節にあります。本サイトでは、この節の内容を最後まで読み切って確定させるに至っていないため、Google の2つのAPIのキャッシュ可否は「要確認」のままにしています。

分からないことを分かったふりで埋めるより、分からないと書いてあるほうが、読む側にとって安全です。 皆さんの社内ドキュメントでも同じにしてください。

確認手順

規約は、上から順に読むと時間がかかります。次の順で探すほうが早く終わります。

1. 規約のURLを見つける。 ドキュメントのフッターか、料金ページの近くにあります。見つからない場合、その時点で「要確認」です。
2. キャッシュ・保存の条項を探す。 ここが設計に最も影響します。
3. 自社の使い方に当てはまる禁止事項を探す。 第三者提供、再配布、商用利用。
4. 表示義務を探す。 クレジット、権利表示。
5. 数値のある制限を拾う。 レート制限、URL長、1回あたりの件数上限。
6. 免責条項を読む。 障害時に何が保証されないかを把握します。

各項目について、次の3点を記録してください。

確認日: 2026-07-29
URL: https://example.com/terms
条項: 第5条第5項
原文: 「…をキャッシュ等に保存してはならないものとします。」
判断: キャッシュ禁止。DB保存を前提にした設計は不可。

原文をそのまま残すことが要点です。 要約だけを残すと、半年後に「本当にそう書いてあったか」を確かめられません。URLと条項番号があれば、次に確認する人が同じ場所を開けます。

チェックリスト

ベンチマークを公開する前に

自分で測った速度や精度を公開したくなったときにも、規約の確認が先です。測定結果の公開を制限している規約が存在します。

本サイトがベンチマークの実測値を1件も掲載していないのは、この確認が終わっていないためです。ページの構造は用意していますが、結果は空のままにしています。順序を逆にすると、公開したあとで取り下げることになります。

関連ページ

• 日本郵便APIとzipcloudの違い
• 郵便番号APIが返す複数候補をどう扱うか
• VercelでAPIキーを安全に扱う方法
• 日本の郵便番号検索API比較 — 各社の条件を一覧で比較