Google Maps APIs ウェブサービスの使用制限

このページは、以前の Maps APIs for Work または Maps API for Business ライセンスのユーザーのみを対象にしています。このページの内容は、2016 年 1 月から利用可能になった新しい Google Maps APIs Premium Plan のユーザーには適用されません。

2011 年 12 月

Google Maps APIs ウェブサービスの使用に関しては、24 時間あたりのリクエスト量に特定の制限が適用されます。これらの制限を超えてリクエストを送信すると、エラー メッセージが返されます。

使用制限については、 Google Maps APIs for Work の以前のライセンスのよくある質問で説明しています。

この記事は、Google Maps APIs for Work ユーザーでこのような使用制限に達した方や、ウェブサービスを効率良く使うためにアプリケーションを最適化する必要がある方を対象としています。

基本

Google Maps は、アプリケーション内で使用する Google マップのデータをリクエストするインターフェースとしてのウェブサービスを提供します。これらのサービスは Google マップと併用する場合に限り使用が可能です。これらのサービスから取得したデータを Google マップに表示せずに使用することは禁止されています。詳細については、Google Maps APIs 利用規約のライセンス制限をご覧ください。

Google Maps APIs ウェブサービスには、使用制限として、長期間(1 日あたりの割り当て)と短期間(リクエスト レート割り当て)の 2 つの割り当てタイプがあります。使用制限を超えるかサービスを乱用した場合、ウェブサービスにより特定のエラー メッセージが返されます。制限の超過が続くと、ウェブサービスへのアクセスがブロックされる場合があります。403 Forbidden レスポンスを受信することもあります。

注: クライアント側の API には別の制限が適用されます。Maps JavaScript API は、マップ セッションごとにレートが制限されるため、リクエストはユーザーに分散されます。これにより、ユーザー数の増加に応じてブラウザベースの使用を拡張できます。サーバー側のウェブサービスと、同等のクライアント側のウェブサービスのどちらを選択するかを決める方法については、ジオコーディングの方法のドキュメントをご覧ください。

問題点

以下の状況で、Google Maps APIs ウェブサービスの使用制限を超過する可能性があります。

  • 1 日に送信するリクエストの量が多すぎる。
  • リクエストの送信が速すぎる(つまり、1 秒間のリクエスト数が多すぎる)。
  • 長期間にわたってリクエストの送信が速すぎるか、ウェブサービスを乱用している。
  • 他の使用制限を超過している(Google Maps Elevation API の 1 リクエストあたりの地点数など)。

使用制限の超過

使用制限を超過した場合、レスポンスとして OVER_QUERY_LIMIT ステータス コードが返されます。

つまり、ウェブサービスは通常のレスポンスを停止し、使用が再び許可されるまでステータス コード OVER_QUERY_LIMIT のみを返します。この状況は次の間続く可能性があります。

  • アプリケーションが 1 秒間に送信したリクエストが多すぎたためにエラーを受信した場合は、数秒間。
  • アプリケーションが 1 日に送信したリクエストが多すぎたためにエラーを受信した場合は、次の 24 時間。1 日の割り当ては、午前 0 時(太平洋標準時)にリセットされます。

このスクリーンキャストでは、適切なリクエスト スロットリングとエラー処理について順を追って説明しています。これは、すべてのウェブサービスに適用されます。

ステータス コード OVER_QUERY_LIMIT を伴うレスポンスを受信した場合、アプリケーションではどの使用制限が超過したのかを判断する必要があります。これは、2 秒間一時停止して同じリクエストを再送信することで実行できます。ステータス コード OVER_QUERY_LIMIT を受信し続ける場合、アプリケーションは 1 日に送信できるリクエスト数を超過しています。リクエストに成功した場合、アプリケーションは 1 秒あたりのリクエスト数を超過しています。

次に、Python での実装例を示します。

url = "MAPS_API_WEBSERVICE_URL"
attempts = 0
success = False

while success != True and attempts < 3:
  raw_result = urllib.urlopen(url).read()
  attempts += 1
  # The GetStatus function parses the answer and returns the status code
  # This function is out of the scope of this example (you can use a SDK).
  status = GetStatus(raw_result)
  if status == "OVER_QUERY_LIMIT":
    time.sleep(2)
    # retry
    continue
  success = True

if attempts == 3:
  # send an alert as this means that the daily limit has been reached
  print "Daily limit has been reached"

注: 次の場合でも、OVER_QUERY_LIMIT エラーが返される場合があります。

アプリケーションでは、リクエストを送信する前にこれらの制限に達していないことを確認する必要があります。

HTTP 403 レスポンス

ウェブサービスへのリクエストでは、HTTP 403 (Forbidden) エラーを受信することがあります。多くの場合、その原因は無効な URL 署名です。これを確認するには、clientsignature パラメータを削除して再試行します。

  • レスポンスが HTTP 200 (OK) である場合、署名に問題があります。
    これは使用制限とは関係ありません。詳細については、Google Maps APIs for Work ドキュメントのウェブサービスの章の認証の問題のトラブルシューティングをご覧ください。
  • レスポンス HTTP 403 (Forbidden) エラーを受信し続ける場合は、必ずしも署名が問題とは限りません。使用制限が関連している可能性があります。
    通常、これはアプリケーションが長期間使用制限を超過しているか、ウェブサービスを不正使用しているという理由で、ウェブサービスへのアクセスがブロックされていることを意味します。この問題が発生した場合は、Google Cloud Support Portal にアクセスしてください。連絡先情報は、サポートとリソースのページでも確認できます。

ウェブサービスへのすべてのリクエストには URL 署名が必要です。client パラメータが含まれていて signature パラメータが欠落している場合、またはその逆の場合も、リクエストは HTTP 403 (Forbidden) エラーで拒否されます。

解決策

上述の問題は、次の 2 つのアプローチの組み合わせで解決できます。

  1. ウェブサービスを効率良く使用できるようにアプリケーションを最適化して、使用量を削減する。
  2. Google Maps APIs for Work ライセンスの追加割り当てを購入して、使用制限を引き上げる(可能な場合)。

この記事では、ウェブサービスをより効率的に使用するためにアプリケーションを最適化する方法について重点的に説明します。

サニティ チェック

ウェブサービスをより効率的に使用する方法を詳しく検討する前に、サービスとライセンスが正しく使用されているかどうかチェックすることをお勧めします。

ユースケースを検証する

Google Maps APIs ウェブサービスは、エンドユーザーからのリアルタイム入力がないアプリケーションや、ウェブブラウザが使用できない環境でアプリケーションを使うケースに最適です。通常、ユーザー入力に関係のないデータセットを取得する場合、このような状況になります。たとえば、不動産のウェブサイト上の一連の販売物件や一連の店舗情報など、ジオコーディングが必要な確定した住所のデータセットがある場合などです。

Google Maps APIs ウェブサービスを使用する場合、すべてのリクエストはクライアント ID の(1 日および 1 秒あたりの)割り当てを消費します。この割り当ては各クライアント ID に対してグローバルに適用され、リクエストの送信元となる IP アドレスの数とは関連がありません。

ブラウザでクライアント側の Maps JavaScript API サービスを使用する場合、1 マップ セッション単位でレートが制限されます。これは、リクエスト数がすべてのユーザーに分散され、ユーザー数の増加に伴ってその数が増えることを意味します。従って、クライアント側 API が常に推奨され、可能な限りこれが使用されます。このような用途は、リアルタイムでジオコーディングが必要な住所をユーザーから収集している場合に最適です(ユーザーの自宅に近い店舗を検索する場合など)。

このトピックの詳細については、ジオコーディングの方法のドキュメントをご覧ください。このドキュメントの推奨事項はジオコーディングに特化していますが、サーバー側のウェブサービスとクライアント側の同等の機能の使い分けに関する説明は、あらゆるウェブサービスにあてはまります。

Google Maps APIs for Work ライセンスを使用する

Google Maps APIs for Work ライセンスをお持ちの場合、リクエストにクライアント ID が正しく含まれていることを確認してください。

Google Maps APIs for Work のユーザーには、Google Maps APIs ウェブサービスに対して、無料版 API のユーザーの利用制限よりも緩和された利用制限が適用されます。このメリットを受けるには、このガイドのウェブサービスの章で説明しているように、アプリケーションに client パラメータを正しく設定する必要があります。

Google Maps APIs for Work クライアント ID を正しく使用していない場合はビジネス用のアプリケーションはとしては扱われず、ビジネス専用の機能や緩和された制限などのメリットを受けることができません。また、Google Maps APIs for Work SLA の対象とならず、テクニカル サポートを利用できません。また、一般向けの Google Maps APIs 利用規約のライセンス制限が適用されます。

最適化の方法

ウェブサービスをより効率的に使用することは、2 つの主な方針に要約されます。それは、本当に必要な場合のみリクエストを送信して使用量を減らすこと、そして使用量を均等に分散して制限下に維持することです。

結果をキャッシュする

Google Maps APIs 利用規約の第 10.5.d 項では、「ネットワーク レイテンシが生じている状況で Google Maps APIs 実装のパフォーマンスを向上させる目的に限り、コンテンツを一定量保存できます(Google による正確な使用状況のトラッキングを阻止する目的では保存できません)。またこのような保存は次の条件を満たす必要があります。一時的なものである(いかなる場合でも暦日で 30 日を超えない)、セキュアである、コンテンツまたは本サービスのいかなる部分も操作または集約しない、いかなる方法でも属性を変更しない」と規定されています。

これは、ウェブサービスのレスポンスを一時的にキャッシュして、短時間に重複したリクエストを送信することを回避できることを意味します。ウェブサービスからのレスポンスには必ず Cache-Control HTTP ヘッダが含まれ、結果をキャッシュできる期間(現在は 24 時間)が示されています。

Cache-Control: public, max-age=86400

このヘッダには、常に従う必要があります。キャッシュ機能は、ウェブプロキシを使用して実装できます(ウェブプロキシをそのまま使用するか、独自の実装を使用します)。一部の HTTP クライアント ライブラリでも、HTTP レスポンスをキャッシュします。

キャッシュ ヒット率を上げるには、LatLng 座標を小数点以下 6 桁で丸めて正規化します。これにより、赤道上の差で約 11 センチメートルの精度が実現します。これ以上小数点以下の桁数を増やしてもウェブサービスからの結果は変わらず、キャッシュ ヒット率が低下してしまいます。

リクエストのスロットリング(絞り込み)

アプリケーションは、リクエストをスロットリングして使用制限を超過しないようにする必要があります。これは、リクエスト送信元の IP アドレスの数とは関係なく、各クライアント ID が対象となることに注意してください。

リクエストのスロットリングは、リクエストが送信されるタイミングを管理するキューにリクエストを入れることで実現できます。10 QPS(1 秒あたりのクエリ数)では、11 個目のリクエストの送信時に、アプリケーションは最初のリクエストのタイムスタンプを確認して 1 秒経過するまで待機する必要があります。1 日あたりの制限にも同様に対応する必要があります。

スロットリングが適切に実装されていても、アプリケーションはステータス コード OVER_QUERY_LIMIT を伴うレスポンスを監視する必要があります。このようなレスポンスを受信したら、上述の使用制限の超過セクションで説明しているように、一時停止と再試行のメカニズムを使用して、どの制限が超過しているのかを判別する必要があります。

未処理リクエストの処理

スロットリングが適切に実装されると、使用制限の超過時にウェブサービスへのリクエストは送信されません。ただし、アプリケーションは、ウェブサービスの使用制限の許容範囲を超える大量または高速の入力を受信する可能性があります。その結果、スロットル キューの量が増加し、未処理(待機中)のリクエストが発生します。

アプリケーションが大量の未処理リクエストを処理しているうちに、1 日の使用制限に達してしまうことがあります。1 日の使用制限に対してスロットリングが適切に実装されている場合、アプリケーションはリクエストの送信を停止します。スロットリングが適切でない場合は、ステータス コード OVER_QUERY_LIMIT を伴うレスポンスが発生します。どちらの場合でも、未処理のリクエストは減少しません。

1 日または 1 週間を通しての平均リクエスト数が使用制限を下回っている場合、アプリケーションで入力フローが少ないときに未処理リクエストを送信できるようにする必要があります。もしくは、Google Maps APIs for Work ライセンスの 1 日の使用制限を引き上げる必要があります(次のセクションを参照)。

最適化が不十分である場合

上記の最適化をすべて実装済みでも、1 日単位または 1 日の中での時間ベースの未処理リクエストの数が変わらずに増加し続ける場合、Google Maps APIs for Work ライセンスの 1 日あたり、または 1 秒あたりの使用制限を引き上げることをお勧めします。この場合、Google Maps APIs for Work Account Manager に、お問い合わせいただき、利用可能なオプションについてご相談ください。