LASSIC Media らしくメディア
Google Maps APIの利用料金を削減する外注
LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託
この記事のポイント
- Google Maps PlatformはSKU(機能単位)ごとの従量課金で、利用するAPIと呼び出し量によって料金が大きく変わります
- クォータ設定・APIキー制限・静的地図への切り替え・セッショントークン活用など、複数の削減施策を組み合わせると費用を大きく抑えられます
- 削減幅は実装パターンによって異なるため、外注パートナーの技術知見を活用すると見落としを防ぎながら対応できます
目次
Google Maps Platform APIの料金体系
Google Maps Platform APIの利用料金削減とは、SKU(Stock Keeping Unit:API機能単位)ごとの従量課金を把握し、使用量・使用方法を適切に制御することで月々のAPI費用を抑える取り組みです。2025年時点、Google Maps PlatformはSKU別の段階的な従量課金モデルを採用しており、利用量が増えるほど1,000件あたりの単価が段階的に下がる仕組みになっています*1。
Google Maps Platformには100種類以上のSKUが存在します。主要なSKUと2025年時点の料金は以下のとおりです*1。
| SKU名 | カテゴリ | 月間無料枠 | 超過料金(1,000件あたり) |
|---|---|---|---|
| Dynamic Maps | Maps(Essentials) | 10,000件 | $7.00〜$0.53(利用量増で逓減) |
| Static Maps | Maps(Essentials) | 10,000件 | $2.00〜$0.15(Dynamic比約1/3) |
| Autocomplete Requests | Places(Essentials) | 10,000件 | $2.83〜$0.21 |
| Geocoding | Places(Essentials) | 10,000件 | $5.00〜$0.38 |
| Compute Routes Essentials | Routes | 10,000件 | $5.00〜$0.38 |
| Dynamic Street View | Maps(Pro) | 5,000件 | $14.00〜$1.05 |
利用量が増えると1,000件あたりの単価は段階的に下がります。ただし、アプリのユーザー数が増えると無料枠を超える月間リクエスト数になりやすく、月々の請求額が想定以上に膨らむケースがあります。
2025年時点、Google Maps PlatformはSubscriptionプラン(Starter・Essentials・Proなど)と従量課金を組み合わせた体系に移行しており、料金の詳細は公式サイト(mapsplatform.google.com/pricing/)で最新情報を確認することを推奨します*1。料金体系は改定されうるため、都度公式の最新情報を参照してください。
料金を引き上げる4つのパターン
Google Maps APIの費用が予算を超えやすいのには、典型的な実装上のパターンがあります。発生原因を把握することが削減の第一歩です。
パターン1:不要なSKUの呼び出し
単純な住所表示にもかかわらず、Places Details(高価格SKU)を呼び出している場合があります。GeocodingやAutocompleteで代替できる用途に高機能APIを使い続けると、1リクエストあたりのコストが必要以上に高くなります。
パターン2:Dynamic Mapsの多用
ページの一覧表示やサムネイルにも動的地図(Dynamic Maps)を使うと、閲覧のたびにリクエストが発生します。Static Mapsに切り替えると、同じ無料枠でもコストは約1/3に下がります*1。
パターン3:セッションを束ねないAutocomplete呼び出し
住所入力補完(Place Autocomplete)でセッショントークンを使っていない場合、1文字入力するたびに個別のリクエストとして課金されます。ユーザーが「東京都渋谷区」と10文字入力すると、10件分のリクエストが発生します。
パターン4:制限なしAPIキーの放置
APIキーに利用制限やクォータ上限を設定していないと、誤用・第三者による悪用でリクエストが急増しても検知が遅れます。Googleの公式ドキュメントは「制限なしAPIキーによる悪用の財務的責任は利用者にある」と明記しています*2。
SKU選別とAPIキー制限でコストを下げる
コスト削減の土台となるのが、使用SKUの精査とAPIキーへのセキュリティ制限です。
必要なSKUのみを有効化する
Google Cloud Consoleで現在有効なAPIを一覧表示し、アプリが実際に使っていないAPIを無効化します。使用していないAPIが有効なままだと、誤った実装や悪用で意図しない課金が発生するリスクがあります。
用途別の代替SKUを検討することも有効です。たとえば、ユーザーが住所を入力する場面でも、最終的にPin留め機能が不要であれば、Places Details(高価格)の代わりにGeocoding APIで住所の座標変換だけを行うと費用を抑えられます。
APIキーに制限を設定する
Googleの公式ドキュメントは、APIキーに以下の2種類の制限を設定することを推奨しています*2。
- アプリケーション制限:Webアプリなら「HTTPリファラー(発信元URL)」、モバイルアプリなら「Androidアプリ」または「iOSアプリ」で使用先を限定する
- API制限:そのキーで呼び出しを許可するAPIを個別に指定し、不要なAPIへのアクセスを遮断する
制限が設定されていないAPIキーは外部に漏れると悪用され、予想外の高額請求につながります。開発用・本番用でキーを分け、本番キーにはアプリケーション制限とAPI制限の両方を設定してください。
地図の表示方式を見直してAPIコールを減らす
Dynamic Maps(動的地図)とStatic Maps(静的地図)の使い分けは、コスト削減に直結する設計判断です。
Static Mapsに切り替えられる用途
以下のケースではStatic Mapsで代替でき、同じ無料枠でもコストを大幅に抑えられます*1。
- 店舗一覧ページのサムネイル地図(インタラクションが不要)
- メールやPDFに埋め込む位置案内図
- マーカーが1〜2個だけの単純な地点表示
サムネイル→動的地図のクリック遷移パターン
Googleの公式ドキュメントは、Static Mapsをサムネイルとして表示し、クリック時だけDynamic Mapsに遷移させる実装パターンを推奨しています*2。これにより、ページを表示しただけのユーザーには静的地図を返し、実際に操作するユーザーにだけ動的地図を読み込む設計になります。
Dynamic Mapsは地図をスクロール・ズームする必要がある場合や、リアルタイムの交通情報・カスタムオーバーレイが必要な場合に絞って使うと、月間のAPIコール数を大きく減らせます。
Places/Autocompleteはセッショントークンで1回分に束ねる
住所入力補完機能を実装している場合、セッショントークン(Session Token)の活用は見落とされやすいコスト削減策の一つです。
セッショントークンの仕組み
Place Autocomplete(レガシー版)では、ユーザーが文字を1文字入力するたびにリクエストが発生します。セッショントークンを使うと、「入力開始から場所選択まで」の一連のリクエストと、その後のPlace Details呼び出しを、1回分のセッション料金として合算できます*3。
Googleの公式ドキュメントでは、セッショントークンはUUID version 4形式で生成し、セッションごとに新しいトークンを発行することを推奨しています*3。1つのトークンを複数セッションで再利用すると、セッション価格の適用外となり個別請求になります。
実装上の注意点
セッショントークンはサーバーサイドで生成・管理するか、クライアント側でUUID v4を生成してAPIリクエストに付与します。新しいPlaces API(New)ではセッションの扱いが一部変わっているため、使用するAPIのバージョンに合わせて公式ドキュメントを参照してください*3。
クォータ上限設定と予算アラートで予期しない課金を防ぐ
削減施策を実装した後も、リクエスト数の急増や実装ミスが残っている可能性があります。Google Cloud Consoleの管理機能を活用して、過剰請求を防ぐ仕組みを設けることが大切です。
クォータ制限の設定
Cloud ConsoleのAPIとサービス→クォータページで、API別に1日あたりのリクエスト数上限を設定できます*2。クォータ上限に達すると以降のリクエストはエラーを返すため、アプリの動作に影響しますが、想定外の高額請求を防ぐ歯止めとして機能します。
開発・テスト環境には低いクォータを設定し、本番環境とは別のAPIキー・プロジェクトで管理すると、テスト用APIコールが本番の費用に混入するリスクを避けられます。
予算アラートの設定
Cloud Billingの予算設定では、月間の利用額が設定した閾値に達した時点でメール・SMSなどで通知を受け取れます*2。Googleの公式ドキュメントは「予算設定は自動的に使用や請求をキャップしない」と明記しており、アラートはあくまで通知であって課金停止ではありません。アラートを受信したら速やかにクォータを絞るか、アプリの挙動を確認する運用フローを事前に定めておくことが望ましいです。
複数の通知チャネルを設定する
アラート通知はメール・Slack Webhook・PagerDutyなど複数チャネルに設定できます。担当者の休暇中にアラートを見逃すリスクを減らすため、複数の受信先を設定しておくことを検討してください。
規約の範囲でキャッシュを活用し再リクエストを減らす
Google Maps Platformの利用規約は原則としてレスポンスのキャッシュを禁止していますが、一部の例外があります。規約の範囲内でキャッシュを活用すると、同一データへの重複リクエストを削減できます。
キャッシュが許可される範囲
公式ドキュメントによると、Maps PlatformはほとんどのAPIでキャッシュを禁止していますが、一部のAPIでは30日間までのキャッシュが例外的に許可されています*2。どのAPIでキャッシュが許可されているかは、各APIの利用規約と公式ドキュメントを確認してください。
規約違反を避けるための確認ポイント
キャッシュ実装にあたっては、以下を事前に確認します。
- 対象APIのサービス固有利用規約でキャッシュが許可されているか
- キャッシュ有効期限が規約で定める上限(30日間まで)を超えていないか
- キャッシュしたデータをGoogle Maps Platformサービス外の目的に転用していないか
規約違反と判断されるとAPIキーが停止されるリスクがあります。不明点は実装前にGoogle Maps Platform公式のサポートチャネルで確認することを推奨します。
不要な再リクエストを減らすフロント実装
キャッシュとは別に、フロント側で重複APIコールを抑制する実装も有効です。たとえば、ユーザーが地図を小さくスクロールするたびに位置情報を再取得するのではなく、一定距離(閾値)を超えた移動のみ再取得するように実装するだけで、地図連動機能のAPIコール数を削減できます。
コスト削減を外注するメリットと発注時の確認ポイント
Google Maps APIのコスト削減には、SKU体系の理解・GCPコンソールの操作・フロント/バックエンド両面の実装改修・規約の継続確認など、横断的な技術知識が必要です。内製で対応する場合の工数と対応範囲を把握しておくことが大切です。
内製対応に必要なスキルと工数の目安
API費用の分析から削減施策の実装・テストまでを内製で行うには、以下の知識が必要になります。
- Google Cloud Platform(GCP)の請求・クォータ管理:Cloud Console操作、Cloud Billingの予算アラート設定
- Maps Platform SKU体系:どのAPIがどのSKUに対応するかの把握(100種類以上のSKUの中から対象を特定)
- フロント・バックエンドの実装改修:セッショントークン実装・フィールドマスク設定・静的/動的地図の切り替え
- 利用規約の読み込み:キャッシュポリシー・データ転用禁止等の規約確認
現状把握から施策特定・実装・モニタリング体制の整備まで、エンジニア1〜2名が数週間から数か月単位で取り組むボリュームになります。Maps Platform固有の知識があるエンジニアが社内にいない場合、調査フェーズだけで相当の工数が発生します。
外注パートナーを選ぶ際の確認ポイント
Maps APIコスト削減の外注先を探す場合、以下を発注前に確認することを推奨します。
| 確認ポイント | 内容 |
|---|---|
| Maps Platform対応実績 | Google Maps Platform固有のSKU最適化・セッショントークン実装・規約対応の経験があるか |
| GCPコンソール操作経験 | Cloud Billing・クォータ管理・予算アラート設定まで一貫して対応できるか |
| フロント・バックエンド両対応 | フロント側のAPI呼び出し最適化と、バックエンド側のキャッシュ・サーバーサイドトークン生成を両方対応できるか |
| 規約遵守の対応体制 | Maps Platform利用規約の改定をキャッチアップし、実装内容を随時見直す体制があるか |
| モニタリング継続支援 | 初期削減だけでなく、利用量増加時の追加対応・アラート運用を継続支援できるか |
外注することで、規約見落としによるAPIキー停止リスクや、実装ミスによる急増請求のリスクを低減できます。一方で、パートナー選定時に対応範囲と責任範囲を契約で明確にしないと、施策の実施後にモニタリング対応が宙に浮くケースがあります。発注前に対応スコープと継続支援の有無を確認してください。
まとめ:Google Maps APIコスト削減の3つの判断軸
本記事では、Google Maps Platform APIの利用料金削減に向けた主要な手法を整理しました。要点を3つに集約します。
第一に、使用SKUの選別と制限設定を土台にすることです。不要なSKUを無効化し、APIキーにアプリケーション制限・API制限を設定することが、コスト管理の出発点です。クォータ上限と予算アラートもあわせて設定することで、予期しない高額請求を防ぐ仕組みを作れます。
第二に、地図の表示方式とセッション設計を見直すことです。Dynamic MapsをStatic Mapsに切り替えられる場面を洗い出し、Place AutocompleteにはセッショントークンとPlace Detailsを組み合わせて1セッション料金にまとめる実装を採用することで、APIコール数を減らせます。
第三に、規約の範囲内でキャッシュ・再リクエスト抑制を実装することです。Google Maps Platformの利用規約はAPIごとにキャッシュの可否が異なるため、実装前に該当APIの規約を確認してください。規約違反はAPIキー停止につながるリスクがあります。
よくある質問
Google Maps Platformの月間無料枠はどの程度ですか?
Google Maps Platformの公式料金ページ(2025年時点)によると、Dynamic Mapsや Geocoding、Autocomplete Requestsなど多くのEssentialsカテゴリのSKUは月間10,000件の無料枠が設定されています*1。ProカテゴリのDynamic Street ViewやElevationは月間5,000件、Enterpriseカテゴリは月間1,000件が目安です。ただし無料枠の件数は料金改定で変更されうるため、最新情報はGoogle for Developersの公式料金ページで確認してください。
APIキーを制限しないとどのようなリスクがありますか?
Googleの公式ドキュメントは「制限なしAPIキーの悪用による課金は利用者の責任である」と明記しています*2。APIキーがソースコード内に露出していたり、HTTPSリファラー制限なしで公開ページに埋め込まれていたりすると、第三者がキーを利用して大量リクエストを発生させる可能性があります。アプリケーション制限(HTTPリファラー・IPアドレス等)とAPI制限(使用を許可するAPIの指定)を組み合わせることで、悪用リスクを大幅に下げられます。
セッショントークンを使わないとどれくらいコストが増えますか?
セッショントークンを使わない場合、ユーザーが1文字入力するたびにAutocomplete Requestsが個別に課金されます。Googleの公式ドキュメントによると、セッショントークンを使用すると一連の入力操作と最終的なPlace Detailsのコールが1セッション料金にまとめられます*3。入力文字数が多いほどトークンなしとの差が大きくなるため、住所入力補完を多用するアプリでは優先的に実装を検討することが望ましいです。
Google Maps APIのコスト削減を外注した場合、費用はどのくらいかかりますか?
外注費用は対応範囲・アプリの規模・既存実装の状態によって異なります。現状のSKU利用分析から削減施策の実装・テスト・モニタリング体制の整備までを含む場合、エンジニア1〜2名が数週間から数か月関与するボリュームになります。具体的な費用は複数のITアウトソーシング会社へ見積もりを依頼し、対応スコープと継続支援の有無を比較して判断することを推奨します。
Google Maps Platformの利用規約でキャッシュは禁止されていますか?
Googleの公式ドキュメントによると、ほとんどのMaps Platform APIはキャッシュを禁止していますが、一部のAPIでは30日間までのキャッシュが例外的に許可されています*2。許可されるAPI・条件は利用規約に記載されているため、実装前に対象APIのサービス固有利用規約を確認してください。規約違反と判断されるとAPIキーが停止されるリスクがあります。
著者:テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典:Google for Developers「Google Maps Platform の料金体系」(2025年・最終更新2026-06-26確認)
- *2 出典:Google for Developers「Google Maps Platform のコスト管理」(2025年・最終更新2026-06-26確認)
- *3 出典:Google for Developers「Place Autocomplete セッショントークン」(2025年確認)