地図APIの月次請求が、前月比で3倍を超えた月があった。
サービスのPVが伸びた結果だ。嬉しいはずの数字が、怖い数字に変わる瞬間を初めて体験した。
「アクセスが増えると請求も増える」——頭ではわかっていた。でも感覚として理解できていなかった。
地図を扱うサービスを開発・運用していれば、多かれ少なかれ一度は直面する問題だと思う。そしてこの問題は、サービスが成功するほど深刻になるという厄介な性質を持っている。
Google Maps Platformの料金を整理する
Google Maps Platformは、API呼び出し回数に応じた従量課金モデルだ。月200ドル相当の無料枠があるので、小規模サービスではほぼ気にならない。問題はその先にある。
主なAPIの単価（目安）を整理する。
| API | 単価（1,000リクエストあたり） |
|---|---|
| Maps JavaScript API（地図表示） | 約7ドル |
| Geocoding API（住所→座標変換） | 約5ドル |
| Directions API（ルート案内） | 約10ドル |
| Places API（場所検索） | 約17〜32ドル |
数字だけ見ると安い。しかし月100万リクエストを超えてくると話が変わる。Places APIは上限側の32ドルで計算すると、100万リクエストで32,000ドル。日本円で月額480万円だ。無料枠の200ドルなど誤差にすぎない。年間にすれば5,000万円を超える。地図APIだけでそれだけのコストが発生するという事実は、知っておくべきだろう。
「1アクション＝1リクエスト」ではない
ここが盲点だった。
地図サービスでは、ユーザーが1回操作するたびに複数のAPIが並行して走る。地図表示・住所検索・ルート案内をセットで提供していれば、1アクションあたり3〜5リクエストが飛んでいることも珍しくない。
モバイルアプリではさらに厄介だ。バックグラウンドでも地図タイルを更新する仕様になっていることがある。ユーザーが画面を見ていない間も、カウンターは静かに回り続ける。開発時のテスト環境では気づきにくい。本番に出して、ユーザー数が増えた段階で初めて顕在化する。
コスト管理ツールでアラートを設定しても、「想定外のスパイク」は定期的に起きる。これは設定の問題ではない。従量課金という構造そのものが持つ本質的なリスクだ。
成長がリスクになるという逆説
従量課金モデルでは、サービスの成長がそのままコストリスクの拡大になる。ユーザーが増えるほど、請求の予測が難しくなる。
Webサービスなら、広告やサブスク収益が追いつく前にAPIコストが先に跳ね上がる。業務システムなら、利用部署が増えるたびに追加コストの交渉が必要になる。予算申請のたびに「地図のせいで」という説明をしなければならない。
「地図を使う」という判断が、スケールするほど重荷になる。そういう構造であることに、もっと早く気づくべきだった。成長を喜べない仕組みの上にサービスを載せてはいけない。
従量課金ではない選択肢
地図を使う方法はGoogle Maps Platformだけではない。
GISの世界にはライセンス型のSDKがある。リクエスト数ではなく年間ライセンスで費用が決まる。アクセスが増えても請求額は変わらない。
業務システムへの組み込みを前提に設計されたものもある。オンプレミス環境で動き、既存の業務DBとそのまま連携できる。地図データを自社サーバーに置けるので、個人情報や位置情報を外部に出さずに済む。
両者を比較するとこうなる。
| 項目 | クラウド型API | ライセンス型SDK |
|---|---|---|
| 課金モデル | リクエスト数に比例 | 年間固定 |
| コスト予測 | PV次第で変動 | 立てやすい |
| オフライン利用 | 基本不可 | 可能 |
| データの置き場 | クラウド側 | 自社内保持 |
| .NET業務系との親和性 | 限定的 | 対応製品あり |
| サポート | 英語ドキュメント中心 | 国内対応あり |
クラウド依存がないため、セキュリティポリシーの厳しい自治体や金融機関でも導入しやすい。年間固定費なので予算も組みやすい。この差は、特に中長期で効いてくる。
選択肢を知らなかった理由
「地図を使う＝Google Maps」という思考の固定があった。検索しても、チュートリアルも事例もGoogle Maps関連ばかり出てくる。他の選択肢が視界に入りにくい環境だった。
特に業務システム開発の現場では、ライセンス型・オンプレ型の国産GISエンジンという存在は意外と知られていない。「選べる」と知っているかどうかで、設計の初期段階から判断が変わる。RFPに「地図機能」と書く時点で、Google Maps前提になっているケースが多いのではないか。要件定義の段階で選択肢を持っておくことが、5年後・10年後の運用コストを左右する。
まとめ
- Google Maps Platformは従量課金。PVが増えるほど請求も増える。
- 1アクション ≠ 1リクエスト。実際はその数倍が走っている。
- 成長するほどコスト予測が難しくなるのは構造上の問題。
- 年間ライセンス固定のGIS SDKという選択肢がある。
- オンプレ・国産・.NET対応で探すと、見えていなかった世界がある。
地図APIのコストに悩んでいる方、これから業務システムに地図機能を組み込もうとしている方の参考になれば幸いだ。
補足しておくと、Google Maps Platformが悪いわけではない。プロトタイプや小規模サービスには非常に便利だし、ドキュメントも充実している。問題は「それしか選択肢がない」と思い込んでしまうことだ。選択肢を知った上で、自分のサービスの規模と成長計画に合った方を選ぶ。その判断ができるかどうかが分かれ目になる。
コメント