最適化ガイド

このガイドでは、セキュリティ、パフォーマンス、使用量の観点から、Google Maps API の使用量を最適化するための複数の戦略について説明します。

セキュリティ

セキュリティに関するベスト プラクティスを確認する

API キーはプロジェクト主導型の認証情報で、ユーザー ID やパスワードと同じように取り扱いに注意を要するものです。目的外の使用によりアカウントの割り当てを不当に消費してしまい、不測の請求を受けることのないように、API セキュリティに関するベスト プラクティスを確認してください。

API キーを使用して Maps API にアクセスする

API キーは、Google Maps API にアクセスする際に推奨されている認証方式です。クライアント ID もまだサポートされていますが、API キーはきめ細かいセキュリティ管理に対応しており、特定のウェブアドレス、IP アドレス、モバイル SDK(Android および iOS)と連携させることもできます。API キーの作成と保護について詳しくは、各 API または SDK の [API キーを使用する] ページをご覧ください(たとえば、Maps JavaScript API については、そのページの [API キーを使用する] をご覧ください)。

パフォーマンス

指数バックオフを使用してエラー処理を行う

QPS エラーなど、短時間の過剰な API 呼び出しによりエラーが発生する場合は、リクエストの処理に指数バックオフを使用することをおすすめします。

指数バックオフは、500 番台のエラーに対して最も効果的です。詳しくは、HTTP リターン ステータス コードの処理をご覧ください。

指数バックオフとは、具体的に説明すると、クエリの送信ペースの調整です。コードで、クエリ間の待機時間として S 秒追加します。それでもクエリの際に QPS エラーが繰り返される場合は、待機期間を 2 倍にしてから別のクエリを送信し、クエリがエラーなしで返されるまで、待機時間を調整していきます。

ユーザー操作リクエストをオンデマンドで送信する

ユーザー操作を含む API へのリクエストは、オンデマンドでのみ送信する必要があります。つまり、エンドユーザーが API リクエストを開始する操作(on-click など)を実行するまで待機してから、その結果を使用して地図の読み込み、目的地の設定、適切な情報の表示を行います。オンデマンド送信により API に対する不要なリクエストを回避して、API の消費を減らすことができます。

地図を動かしているときにオーバーレイ コンテンツが表示されないようにする

ユーザーが地図を移動する可能性がある状況で、Draw() を使用してカスタム オーバーレイ コンテンツを表示するのは避けます。ユーザーが地図を動かすたびに再描画されるため、同時にオーバーレイ コンテンツを地図に配置すると遅延やスタッタリング(視覚的な途切れ)が生じる可能性があります。ユーザーが地図のパンやズームを停止してから、オーバーレイ コンテンツを追加または削除します。

Draw メソッドで負荷の大きいオペレーションを回避する

一般的に、Draw() メソッドでは、負荷の大きい非描画オペレーションを回避することをおすすめします。たとえば、Draw() メソッドのコードでは、次のことは避けてください。

  • 大量のコンテンツを返すクエリ
  • 表示されるデータの大幅な変更
  • 多数のドキュメント オブジェクト モデル(DOM)要素の操作

このようなオペレーションでは、地図のレンダリング時にパフォーマンスが低下し、遅延やスタッタリングが生じることがあります。

マーカーにラスター画像を使用する

マーカーを追加して地図上の場所を識別する際に、.PNG 形式または .JPG 形式の画像などのラスター画像を使用します。Scalable Vector Graphics(SVG)画像は使用しないでください。SVG 画像をレンダリングすると、地図が再描画される際に遅延が発生する場合があります。

マーカーを最適化する

最適化すると、多数のマーカーが単一の静的要素としてレンダリングされ、パフォーマンスが向上します。最適化は、多くのマーカーが必要な場合に便利です。デフォルトでは、Maps JavaScript API がマーカーの最適化を行うかどうかを判断します。マーカーが多数ある場合、Maps JavaScript API はマーカーを最適化してレンダリングを試みます。ただし、すべてのマーカーを最適化できるわけではなく、最適化せずにレンダリングしなければならない場合もあります。アニメーション GIF または PNG の場合、または各マーカーを個別の DOM 要素としてレンダリングする必要がある場合、レンダリングの最適化を無効にしてください。

マーカー表示を管理するためにクラスタを作成する

地図上の場所を特定するマーカー表示を管理しやすいように、マーカー クラスタ ライブラリを使用してマーカー クラスタを作成します。マーカー クラスタ ライブラリには、次のオプションがあります。

  • グリッドサイズ: クラスタ内でグループ化するマーカーの数を指定します。
  • 最大ズーム: クラスタを表示する最大ズームレベルを指定します。
  • マーカー アイコンとして使用するグラフィック画像の画像パス。

使用量

予算の設定や費用の管理を行うには、以下の手順を行います。

  • 予算アラートを設定し、特定の金額を超えないように費用をトラッキングします。予算を設定しても API 使用量の上限は設定されません。指定した金額に費用が近づいた際にアラートが通知されるだけです。
  • 1 日あたりの API 使用量の上限を設定し、課金対象となる API の費用を管理します。1 日あたりのリクエスト数の上限を設定すると、費用を制限できます。簡単な計算式で、ご希望の予算をもとに 1 日の上限を求めることができます。たとえば、(「1 か月の予算」÷「各 SKU の料金」)÷ 30 = 1 日のリクエスト数上限(1 API あたり)などとなります。課金対象となる API を複数使用する場合は、必要に応じて式の要素を調整してください。Google Maps API では毎月 200 ドル分の無料クレジットを利用できるため、この金額も考慮する必要があります。
  • 複数のプロジェクトを使用して、使用量の切り分けを行い、優先順位を付け、トラッキングします。たとえば、テストで Google Maps Platform API を定期的に使用するとします。その場合はテスト用に別のプロジェクトを作成し、そのプロジェクト用の割り当てと API キーを設定することで、不意の予算超過を回避しながら詳細なテストを行うことができます。

マップでの使用量を管理する

地図表示を最適化するには 1 ページに 1 つの地図を使用するのがよいでしょう。ほとんどの場合、ユーザーが一度に 2 つ以上の地図を操作することはないためです。ユーザーの操作やニーズに合わせて表示するデータセットを差し替えられるように、アプリで地図をコントロールします。

静止画像を使用する

動的画像(動的地図や動的ストリートビュー)を使用するリクエストは、静的地図や静的ストリートビューよりもコストが高くなります。地図やストリートビュー(ズームまたはパン)に対するユーザーの操作を予測できない場合は、これらの API の静的バージョンを使用することをおすすめします。

サムネイル(非常に小さな地図や写真)も、静的地図や静的ストリートビューに適しています。こうしたアイテムは課金レートが低く、ユーザーの操作(クリック)が発生すると、Google マップの全機能を利用できる動的バージョンにユーザーを誘導できます。

Maps Embed API を使用する

Maps Embed API を使用すると、マーカーが 1 つの地図や、動的な地図を無料で追加できます。Maps Embed API は、マーカーが 1 つだけ必要で、地図のカスタマイズが不要なアプリケーションに使用します。Directions モード、View モード、Search モードを使用する Embed API リクエストは、今後課金対象となります(料金表を参照)。

モバイルアプリにはモバイル地図用の SDK を使用する

モバイルアプリの場合は、地図を表示する際に、Maps SDK for Android または Maps SDK for iOS を使用します。要件によりモバイル SDK の使用が認めらない場合は、Maps Static API または Maps JavaScript API を使用します。

ルートでの使用量を管理する

Directions API の地点を制限する

可能であれば、クエリでのユーザー入力を最大 10 地点に制限します。10 を超える地点を含むリクエストは、課金レートが高くなります。

Directions API の最適化によって最善のルートを表示する

地点の最適化引数を使用するリクエストは、課金レートが高くなります。詳細については、地点の最適化をご覧ください。

最適化引数は、地点を並べ替えて的確なルートを表示します。たとえば、A から E への移動では、最適化した(A-B-C-D-E)ルートの方が、ランダムな並びの最適化されていないルート(A-D-B-C-E など)よりも的確なルートになります。

Directions API と Distance Matrix API でリアルタイム交通情報のモデルを使用する

リアルタイム交通情報のモデルを含む Directions API と Distance Matrix API のリクエストは、課金レートが高くなります。リアルタイム交通情報のモデルは、departure time が now に設定されると有効になります。

リクエストに交通情報モデルが含まれていない場合、物理的要素(道路、距離、制限速度)のみに基づいてリクエストの結果が返されます。

GPS データが正確でない場合は、走行したルートと最も近い道路を使用する

Maps Roads API の Route Traveled(走行したルート)と Nearest Road(最寄りの道路)の各機能は上位の階層に含まれ、課金レートが高くなります。これらの機能は GPS データが不正確な場合に使用します。Roads API は適切な道路の特定に役立ちます。Roads API のもう 1 つの機能である Speed Limits(制限速度)は、アセット トラッキングを使用しているお客様のみご利用いただけます。

制限速度の場所は 5 分~15 分間隔でサンプリングする

Maps Roads API の Speed Limit サービスの呼び出しを最小限に抑えるため、5~15 分間隔でアセットの場所をサンプリングします。正確な値はアセットの移動速度によって異なります。アセットが静止している場合は、1 つの場所をサンプリングするだけで十分です。複数の呼び出しを実行する必要はありません。

全体的なレイテンシを最小限に抑えるため、モバイル アセットの場所を受け取るたびに API を呼び出すのではなく、ある程度データが蓄積されたら Speed Limit サービスを呼び出すことをおすすめします。

プレイスでの使用量を管理する

Place Autocomplete 実装を最適化する

Place Autocomplete の使用コストを最適化するには:

  • JavaScriptAndroidiOS の Autocomplete ウィジェットのフィールド マスクを使用して、必要な場所のデータ フィールドのみを返すように設定します。

  • お支払いオプションの選択は、ユースケースによって異なります。オートコンプリート セッションを使用するかどうかによって、Autocomplete - Per Request SKU または Autocomplete - Per Session SKU のいずれかに対して課金されます。

ユースケースに適したオプションを選択するための詳細情報とガイダンスについては、Place Autocomplete の使用コスト最適化のヒントに関するページをご覧ください。

Place Details と Place Search のリクエストで特定のフィールドのデータを返す

Place Details と Place Search のリクエストをカスタマイズして、アプリケーションで使用するフィールドのデータのみ返されるようにすることができます。これらのフィールドは、BasicContactAtmosphere のカテゴリに分けられます。フィールドを指定しなければ、すべてのフィールドのデータが返されます。

Place Details リクエストに対する課金は、リクエストされたデータの種類と金額に基づきます。フィールドを指定していないリクエストは、満額で課金されます。詳しくは、Place DetailsPlace Search をご覧ください。

Geocoding API を使用してコストを削減する

ユーザー入力による住所を処理するアプリケーションで、入力された住所があいまいな場合があります(抜けがある、綴りが間違っている、書式が不適切など)。 Autocomplete を使用すると、住所のあいまいさを排除できます。そのうえで、プレイス ID を使用して場所を取得します。

ただし、正確(またはほぼ正確)な住所がある場合は、Autocomplete の代わりに Geocoding を使用するとコストを削減できます。詳細については、住所のジオコーディングに関するベスト プラクティスをご覧ください。

Google Maps Platform の割り当ての仕組み

どの API でも、顧客ごとに行える呼び出し数には上限があります。これらの割り当ては分単位で構成されます。1 分間に所定の API の呼び出し回数が上限に達すると、その次の 1 分まで残りの呼び出しは受け付けられません。

正常に処理されたリクエスト、およびサーバーエラーを発生させたリクエストのみが割り当てを消費します。認証に失敗したリクエストは割り当てを消費しません。

Maps API の中には、分単位の割り当てに加え、秒単位で割り当てが課せられるものがあります。秒単位の割り当ては、1 分間全体で使用量を均一にするためでも、1 分間の割り当ての上限に達するのを防ぐものでもありませんが、1 分間の最初の 1~2 秒で割り当てを使い果たしたり、使用量が急増したためにサービスが中断されたりする事態を回避することはできます。この 2 つの割り当ての違いをうまく活かすには、QPM の使用量を QPS で平均化して、割り当ての消費方法と要件の計画を立てることをおすすめします。

秒単位の割り当てが適用される Google マーケティング プラットフォームの API は、Directions API、Distance Matrix API、Elevation API、Geocoding API、Places API、Roads API です。

リクエストの合計件数に基づいて、Google マーケティング プラットフォームの API サービスの費用を見積る