このガイドでは、セキュリティ、パフォーマンス、消費の観点から、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 キーを使用するをご参照ください）。
パフォーマンス
指数バックオフを使用してエラー処理を行う
割り当てエラーなど、短時間の過剰な API 呼び出しによりエラーが発生する場合は、リクエストの処理に指数バックオフを使用することをおすすめします。
指数バックオフは、500 番台のエラーに対して最も効果的です。詳細は HTTP リターン ステータス コードの処理をご確認ください。
指数バックオフとは、具体的に説明すると、クエリの送信ペースの調整です。コードで、クエリ間の待機時間として S 秒追加します。それでもクエリの際に割り当てエラーが繰り返される場合は、待機期間を 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 モードを使用する Maps 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 に設定されると有効になります。
リクエストに交通情報モデルが含まれていなければ、物理的要素（道路、距離、制限速度）のみに基づいてリクエストの結果が返されます。
Route Traveled と Nearest Road は 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 の使用コストを最適化するには:
JavaScript、Android、iOS の Autocomplete ウィジェットのフィールド マスクを使用して、必要な場所のデータ フィールドのみを返すように設定します。
お支払いオプションの選択は、ユースケースによって異なります。オートコンプリート セッションを使用するかどうかによって、Autocomplete - Per Request SKU または Autocomplete - Per Session SKU のいずれかに対して課金されます。
ユースケースに適したオプションを選択するための詳細情報とガイダンスについては、Place Autocomplete の使用コスト最適化のヒントに関するページをご確認ください。
Place Details と Place Search のリクエストで特定のフィールドのデータを返す
Place Details と Place Search のリクエストをカスタマイズして、アプリケーションで使用するフィールドのデータのみ返されるようにすることができます。これらのフィールドは、Basic、Contact、Atmosphere のカテゴリに分けられます。フィールドを指定しなければ、すべてのフィールドのデータが返されます。
Place Details リクエストに対する課金は、リクエストされたデータの種類と金額に基づきます。フィールドを指定していないリクエストは、満額で課金されます。詳細は、Place Details と Place Search をご確認ください。
Geocoding API を使用してコストを削減する
ユーザー入力による住所を処理するアプリケーションで、あいまいな住所（抜けがある、綴りが間違っている、書式が不適切など）が入力されることがある場合、Autocomplete を使用することで住所のあいまいさを排除できます。そのうえで、プレイス ID を使用して場所を取得します。
ただし、正確（またはほぼ正確）な住所がある場合は、Autocomplete の代わりに Geocoding を使用するとコストを削減できます。詳細は住所のジオコーディングに関するベスト プラクティスをご確認ください。
Google Maps Platform の割り当ての仕組み
どの API でも、呼び出し数にはお客様ごとに上限があります。これらの割り当ては分単位で構成されます。1 分間に所定の API の呼び出し回数が上限に達すると、その次の 1 分まで残りの呼び出しは受け付けられません。
正常に処理されたリクエスト、およびサーバーエラーを発生させたリクエストのみが割り当てを消費します。認証に失敗したリクエストは割り当てを消費しません。