Cloud Service
Google Maps Platform
地図・経路・場所検索を自前で持たずに組み込める。Google の地図データと API でアプリに位置情報機能を追加する Google Maps Platform。AWS の Location Service に相当する。
- 1.地図表示・経路探索・場所検索などを API/SDK として提供する位置情報プラットフォーム。地図データの整備は不要。
- 2.Maps・Routes・Places の3系統が中心で、Web・モバイル・サーバーから API キーで呼び出して使う。
- 3.AWS の Amazon Location Service 相当。従量課金で、キー制限と利用量の管理がコスト・セキュリティの要になる。
Google Maps Platform は、Google が保有する地図・道路・場所のデータを API と SDK として提供し、アプリやサイトに地図表示・経路探索・場所検索などの位置情報機能を組み込めるようにするサービス群です。地図データの収集・更新やルーティングエンジンの運用を自前で抱えることなく、API キーで呼び出すだけで地図機能を実装できます。
解決する課題
- アプリやサイトに地図表示やピン・経路を入れたいが、地図データを自前で整備・更新する手段がない
- 住所や施設名から緯度経度を求めたい(ジオコーディング)、あるいはその逆を行いたい
- 出発地から目的地までの経路や所要時間・距離を、交通状況も踏まえて計算したい
- 近くの店舗・施設といった場所(スポット)情報を検索し、名称・住所・評価などを表示したい
- 住所入力欄にオートコンプリートを付けて、入力ミスや表記ゆれを減らしたい
- ルーティングや地図描画のためのインフラ運用・データ更新から解放されたい
主要概念と用語
- Maps(地図): 地図の表示そのものを担う系統。Web 向けの Maps JavaScript API、モバイル向けの Maps SDK、画像として地図を返す Static Maps、360度のストリートビューなどが含まれる
- Routes(ルート): 経路・所要時間・距離を計算する系統。経路探索の Directions、複数地点間の所要時間行列を返す Distance Matrix、新しい Routes API などが該当する
- Places(場所): 場所情報を扱う系統。施設の詳細(Place Details)、周辺検索、テキスト検索、住所のオートコンプリートなどを提供する
- ジオコーディング(Geocoding): 住所や地名を緯度経度に変換する処理。逆に緯度経度から住所を求めるのが逆ジオコーディング
- API キー: 各 API を呼び出す際の認証に使う鍵。利用するサービスごとに有効化し、利用制限をかけて使う
- Place ID: 特定の場所を一意に表す識別子。検索結果から詳細取得へつなぐときなどに使う
- クォータ / レート制限: プロジェクト単位・API 単位で設定される 1 秒あたりや 1 日あたりの呼び出し上限
- 利用規約(Terms of Service): 取得データのキャッシュ・保存・表示方法に制約があり、独自地図への流用などが禁じられる点に注意する
仕様・制限・クォータ
- 利用形態は大きく Web(JavaScript / Static / Embed)・モバイル SDK(Android / iOS)・Web Service(サーバーから呼ぶ REST 系) に分かれ、用途に応じて API を選ぶ
- 呼び出しには API キー(Web Service の一部はサービスアカウント等も)を使い、各 API をプロジェクトで個別に有効化する必要がある
- API ごとに 1 秒あたり / 1 日あたりのレート制限・クォータがあり、上限に達すると
OVER_QUERY_LIMIT系のエラーになる。大規模利用ではクォータ引き上げを申請する - 利用規約上の制約が強く、Places や Geocoding で得たデータの長期保存・再配布・独自地図化には制限がある。Place ID のように保存が許される識別子と、保存に制限がある属性を区別して扱う
- 対応機能・対応地域・属性の充実度は地域によって差があり、具体的なレート上限・対応範囲・属性一覧は変動するため、最新は公式ドキュメントで確認する
Places や Geocoding の結果は自由に永続保存できるわけではありません。多くの属性はキャッシュ期間や保存可否に制約があり、再配布や独自地図への流用は禁止されています。場所を後で参照したい場合は、属性そのものを溜め込むのではなく Place ID を保存して都度引き直す設計が安全です。
内部の仕組み
利用者から見ると、Google Maps Platform は Google が運用する地図データとエンジンを API/SDK として開いたマネージドサービスです。道路網・施設情報・地図タイル・交通データといった巨大なデータセットと、それを処理するジオコーディング・ルーティング・検索の各エンジンはすべて Google 側が保守し、利用者はキーを付けてリクエストを送るだけで結果を受け取ります。
たとえば経路探索では、出発地・目的地(住所や緯度経度)を渡すと、内部で必要に応じてジオコーディングを行い、道路網と交通状況をもとに最適経路・距離・所要時間を計算して返します。地図表示では、JavaScript API や SDK が地図タイルやベクターデータを取得・描画し、その上にマーカーや経路を重ねます。Places では場所のインデックスを検索し、Place ID をキーに詳細情報を引き当てます。データ更新・スケーリング・可用性確保はプラットフォーム側の責務で、利用者は API の使い方と利用量の管理に集中します。
設計パターン / ベストプラクティス
- 必要な API だけを有効化し、キーを用途別に分ける。Web 用・サーバー用・モバイル用でキーを分離し、それぞれに適した利用制限をかける
- クライアントに置くキーには参照元制限を必須にする。Web は HTTP リファラー、モバイルはアプリ署名・バンドル ID、サーバーは IP アドレスで制限する
- 保存は Place ID 中心に設計する。場所の属性を溜め込むのではなく Place ID を保存し、表示時に Place Details で都度取得して規約と鮮度の両立を図る
- オートコンプリートはセッショントークンを使う。入力中の候補取得と確定時の詳細取得をセッションで束ね、課金とリクエストを最適化する
- 静的な地図で足りる箇所は Static Maps を使う。インタラクティブが不要なサムネイル等は JavaScript の動的地図より軽量・低コスト
- 大量のサーバー処理はバッチ化・キャッシュする。同じ住所のジオコーディング結果(規約の範囲内)や距離行列を再利用し、無駄な呼び出しを減らす
運用・監視
- Google Cloud コンソールの API ダッシュボードで、API ごとのリクエスト数・エラー率・レイテンシ・クォータ消費を継続的に監視する
- Cloud Monitoring / Cloud Logging と組み合わせ、エラー急増やレイテンシ悪化、クォータ枯渇をアラートで検知する
- レート上限超過(
OVER_QUERY_LIMIT)に備え、クライアント・サーバーともに指数バックオフによる再試行とタイムアウトを実装する - キーごと・API ごとの利用量を可視化し、想定外の急増(漏えいや不正利用の兆候)を早期に発見できるようにする
- **予算アラート(Cloud Billing)**を設定し、従量課金が想定を超えたときに気づける状態にしておく
コスト
課金は基本的に API の呼び出し回数(リクエスト数)に応じた従量課金で、Maps の地図ロード、Routes の経路計算、Places の検索・詳細取得など、API(プロダクト)ごとに単価が異なります。一定の無料利用枠が用意される一方、単価・無料枠・課金区分は変動するため、見積もりは公式の料金ページで確認します。
| 課金軸 | 考え方 | コスト最適化のヒント |
|---|---|---|
| 地図ロード | Maps の表示回数に応じた課金 | 静的でよい箇所は Static Maps にして動的ロードを減らす |
| 経路・距離 | Routes の経路計算リクエスト数 | 結果を規約の範囲でキャッシュし重複計算を避ける |
| 場所検索・詳細 | Places の検索・詳細取得の回数 | オートコンプリートはセッショントークンで束ねる |
| ジオコーディング | 住所と座標の変換リクエスト数 | 同じ住所は変換結果を再利用し不要な呼び出しを抑える |
住所入力のオートコンプリートは、入力中に何度も候補取得 API を呼びます。各リクエストを個別課金にせず、入力開始から確定までを セッショントークンで1つのセッションとして扱うと、課金単位とリクエスト数を抑えられます。確定時の Place Details まで同じトークンで束ねるのが基本です。
セキュリティ
- API キーには必ず利用制限をかける。アプリ制限(HTTP リファラー / IP / Android アプリ / iOS アプリ)と API 制限(そのキーで呼べる API の限定)の両方を設定し、漏えい時の悪用範囲を狭める
- キーをリポジトリやクライアントへ直書きしない運用を徹底する。やむを得ずクライアントに置く場合も、参照元制限と API 制限を前提にする
- サーバーからの呼び出しは可能なら IP 制限付きのキーやサービスアカウント認証を使い、最小権限で運用する
- 利用量の急増を監視し、異常時はキーをローテーションできるようにしておく。キーは用途別に分け、影響を局所化する
- 取得した位置・場所データは規約とプライバシー規制に沿って取り扱う。ユーザーの位置情報は個人情報になりうるため、保存範囲・保持期間・同意を設計に組み込む
利用制限のない API キーを Web ページやアプリに埋め込むと、第三者にキーを抜き取られ、勝手に大量のリクエストを投げられて課金が膨らみます。クライアント配布が避けられないキーには参照元制限と API 制限を必ず設定し、利用量を監視してください。
関連サービス・比較
| 観点 | Google Maps Platform | Amazon Location Service |
|---|---|---|
| 位置づけ | 地図・経路・場所のマネージド API 群 | 地図・経路・場所のマネージド API 群 |
| 地図表示 | Maps JS / SDK / Static Maps | Maps(プロバイダ地図を利用) |
| 経路探索 | Routes / Directions | Routes(ルート計算) |
| 場所検索 | Places / Geocoding | Places / ジオコーディング |
| 認証 | API キー(利用制限あり) | IAM ロール |
| データ規約 | 保存・再配布に規約上の制約あり | プロバイダ条件に準ずる |
サーバー側で位置データを蓄積・分析するなら BigQuery、API 呼び出しの監視には Cloud Monitoring / Cloud Logging、課金管理には Cloud Billing の予算アラートを組み合わせるのが定番です。AWS で同等の機能を求める場合は Amazon Location Service が相当します。
ハンズオン / CLI例
# 1) プロジェクトで利用する Maps Platform の API を有効化(必要なものだけ)
gcloud services enable \
maps-backend.googleapis.com \
routes.googleapis.com \
places-backend.googleapis.com \
geocoding-backend.googleapis.com
# 2) API キーを作成(作成後にコンソールやコマンドで利用制限を必ず付ける)
gcloud services api-keys create --display-name "maps-server-key"
# 3) 作成済みキーの一覧を確認し、KEY_STRING を取得
gcloud services api-keys list
# 4) Geocoding API を呼び出して住所を緯度経度に変換する
# (API キーは利用制限付きのものを使う)
API_KEY="YOUR_RESTRICTED_KEY"
curl -s -G "https://maps.googleapis.com/maps/api/geocode/json" \
--data-urlencode "address=東京駅" \
--data-urlencode "language=ja" \
--data-urlencode "key=${API_KEY}"
Google Cloud Service
Google Maps Platformを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ビジネスアプリ
比較で見る軸
クラウド: Google Cloud / カテゴリ: ビジネスアプリ / 難易度: intermediate
導入後に効く点
Maps・Routes・Places の3系統が中心で、Web・モバイル・サーバーから API キーで呼び出して使う。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Google Cloud
- カテゴリ
- ビジネスアプリ
- 難易度
- intermediate
- 関連資格
- —
- 設計柱
- operational / cost / security
判断チェックリスト
- 自社の用途が「ビジネスアプリ / operational」に近いか確認する。
- 強みである「地図表示・経路探索・場所検索などを API/SDK として提供する位置情報プラットフォーム。地図データの整備は不要。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。