最適化ガイド

最適化戦略

セキュリティ

セキュリティのベスト プラクティスを確認

API キーは、ユーザー ID やパスワードと同じ予防措置となるプロジェクト用の認証情報です。意図しない使用によって、アカウントで割り当ての不当な消費や不測の課金が生じるリスクからキーを守るため、API キーのベスト プラクティスを確認してください。

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

API キーは、Google Maps Platform API へのアクセス用の推奨の認証方式です。古いクライアント ID は引き続きサポートされますが、API キーはきめ細かいセキュリティ管理に対応しており、特定のウェブアドレス、IP アドレス、モバイル SDK(Android および iOS)と連携させることもできます。API キーを作成して保護する方法については、使用する各 API や SDK の「API キーの取得」のドキュメントをご覧ください(Maps JavaScript API の場合は API キーの取得など)。

パフォーマンス

指数バックオフによるエラー処理

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

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

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

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

地図を動かしているときにオーバーレイ コンテンツを非表示

Draw() メソッドを使用して、ユーザーが地図を移動しているときにカスタム オーバーレイ コンテンツを表示するのは避けます。ユーザーがマップを移動するたびにマップが再描画されるため、オーバーレイ コンテンツを地図に同時に配置すると、遅延や視覚的な途切れが生じることがあります。ユーザーが地図のパンやズームを停止したときにのみ、オーバーレイ コンテンツを追加または削除します。

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

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

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

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

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

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

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

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

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

使用量の最適化

使用量のモニタリングと制限

予算を設定して費用を管理するには、次のような方法があります。

  • 予算アラートを設定して、特定の金額に対して利用額がどの程度になっているかを追跡します。予算を設定しても、API の使用の上限は設定されません。利用額が指定された金額に近づいた場合にのみ通知されます。
  • 1 日あたりの API 使用量の上限を設定し、課金対象となる API の利用料を管理します。1 日あたりのリクエスト数に上限を設定すると、利用料を制限できます。簡単な計算式で、希望の予算に基づいた 1 日の上限を決めます。たとえば、(「1 か月の予算」÷「各 SKU の料金」)÷ 30 = 1 日のリクエスト数上限(1 API あたり)などとなります。課金対象となる API を複数使用する場合は、必要に応じて式の要素を調整してください。Google Maps Platform では毎月 200 ドル分の無料クレジットを利用できるため、この金額も考慮する必要があります。

地図

地図表示を最適化するには、1 ページにつき 1 つの地図を使用します。通常、ユーザーは一度に 1 つの地図を操作します。アプリでは、ユーザーの操作やニーズに合わせて地図をコントロールし、さまざまなデータセットを表示することができます。

静止画像の使用を検討

動的画像(動的地図や動的ストリートビュー)を使用するリクエストは、静的地図や静的ストリートビューよりもコストが高くなります。地図やストリートビュー(ズームまたはパン)に対するユーザーの操作を予測できない場合は、これらの 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 のリクエストは、課金レートが高くなります。リアルタイムの交通状況データは、出発時刻を now に設定すると有効になります。

交通状況データがリクエストから除外された場合は、結果は物理的要素(道路、距離、制限速度)のみに基づきます。

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

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

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

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

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

プレイス

ユースケースに合ったオートコンプリート オプションを使用

コストに差はないため、ユースケースに最適なオートコンプリート オプションを特定します。違いは、アプリケーションのエンドユーザーによる API の使用方法です。

  • Autocomplete - Per Request: ユーザーが入力する住所フォームなど、入力 1 回で十分な場合に適しています。
  • Autocomplete - Per Session: ホテルやレストランの検索など、入力が複数回必要な場合に適しています。

Autocomplete - Per Session では、結果は無制限になりますが、セッションの有効性を確認するため、トークンを実装する必要があります。Autocomplete - Per Request では、無効なセッションが発生した場合、キー入力ごとに課金されるため、請求金額が高くなる可能性があります。この機能の詳細については、プレイス オートコンプリートをご覧ください。

プレイス詳細リクエストとプレイス検索リクエストで特定のフィールドのデータを返す

プレイス詳細リクエストとプレイス検索リクエストをカスタマイズして、アプリケーションで使用される特定のフィールドのデータを返すことができます。これらのフィールドは、基本、連絡先、雰囲気のカテゴリに分けられます。フィールドを指定しないリクエストでは、すべてのフィールドのデータが返されます。

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

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

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

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