GoogleマップをそのままAIに渡せるようになった — Gemini APIの新ツール"Maps Grounding"を触ってみる

「近くで夜中まで開いてる作業向きのカフェ、教えて」とLLMに聞いて、ちゃんと今日の営業時間つきで答えてくれた経験が、これまでどれくらいあっただろう。

ほとんどの人にとって、その答えは「ない」だ。ChatGPTに同じことを聞いても、学習時点のデータで答えるか、検索機能で遠回りに情報を拾ってくるか、そもそも最近の営業時間は分かりません、と言われるかのどれかだった。

Googleが4月7日にGemini API向けにひっそりと公開した「Grounding with Google Maps」は、この「LLMに地図情報を渡せない問題」を正面から解きに来た機能だ。しかも従来のGoogle検索グラウンディングとは別軸で、Google Mapsの生データを、Gemini 3モデルファミリーに直接接続できる。

Maps Groundingとは何か

一言で言うと、Gemini APIのツール呼び出しに「google_maps」という新しいツールが増えた、というだけの話だ。ただ、その中身は思ったより重い。

Googleマップは世界で2億5千万以上の店舗・場所のデータを持ち、その上で通勤時間、交通状況、ユーザーレビュー、写真、営業時間、バリアフリー情報などを常時更新している。このデータを「リアルタイムにLLMのプロンプトの一部として渡す」API経由の仕組みが、これまでGoogle社内のGemini Appでしか動いていなかった。今回ようやく外部開発者も自分のアプリから呼び出せるようになった、という話だ。

特にうれしいのは、Google検索グラウンディングや自作のFunction Callingと一緒に、1回のリクエストで並走させられる点。「旅行プランを練っていて、まず検索で今週の東京のイベントを調べて、その次に会場近くの静かなカフェを地図から引いて、最後に顧客の好みをカスタム関数で参照する」といった複雑なワークフローが、1リクエストで通るようになった。

最小構成のPythonコード

公式ドキュメントの例を、少し手直ししてみる。

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3-pro-preview",
    contents="東京駅から徒歩15分圏内で、Wi-Fiと電源があって夜22時以降も開いているカフェを3件教えて。営業時間と最短の道順もつけて",
    config=types.GenerateContentConfig(
        tools=[types.Tool(google_maps=types.GoogleMaps())],
        # 位置情報を補助的に与えるとさらに精度が上がる
        tool_config=types.ToolConfig(
            retrieval_config=types.RetrievalConfig(
                lat_lng=types.LatLng(latitude=35.6812, longitude=139.7671),
            )
        ),
    ),
)

print(response.text)

types.Tool(google_maps=types.GoogleMaps()) を渡すだけで、Gemini側が必要に応じてGoogle MapsのバックエンドにアクセスしてPlace情報を拾ってくる。lat_lng は任意で、ユーザーの現在地が分かっているときに渡すと、より絞り込んだ回答が返ってくる。

バックエンドの仕組みとしては「LLMが答えに必要なPlaceを自動判定 → Maps側のQueryエンジンに問い合わせ → 返ってきた構造化データをモデルコンテキストに差し込む」という流れになっている。Function Callingと違い、ツール呼び出しの制御ロジックを自分で書かなくていいのが楽な点だ。

料金はどうなっているのか

ここがまだ曖昧な部分で、記事執筆時点ではGemini API公式料金ページに「tools are priced at their own rates」とだけ書いてあり、Maps Grounding固有の正確な単価は明示されていない。

分かっているのは以下のポイントだ。

• Google検索グラウンディングと同様に、1リクエスト内で発生した個別の地図クエリごとに従量課金になる
• 取得したコンテキスト自体は入力トークンとしては課金されない（検索グラウンディングと同じ扱い）
• Geminiモデル本体のトークン課金は通常通り発生する

「お試しで触る」レベルであれば、Gemini 3 Flashや3 Proの無料枠の範囲で十分遊べる。ただしプロダクションでユーザートラフィックが乗ると、Maps APIを直接叩いていた時代と変わらない水準の課金は想定しておいたほうが安全だ。

何が作れるようになるのか

これまで「地図系アプリ × AI」というジャンルは、Maps APIを叩いたあと、LLMに結果をテキスト化させる、というフロー設計が必要だった。これを開発者が手でつなぐ必要があった。Maps Groundingはそこを一気に縮める。以下はすぐに思いつくユースケースだ。

旅行プランナー。 旅行代理店のチャットボットや個人旅行者向けアプリで、「4泊5日、京都と奈良、1日あたり2万円以内、足が悪い高齢者と同行」といった制約を受け取り、行き先・移動時間・バリアフリー情報まで含めて1本の会話で計画する体験は、これまで複数APIを繋がないと実現できなかった。Maps Groundingで、少なくともプロトタイプは1日で組めるようになる。

店舗向けカスタマーサポート。 飲食チェーンや小売業のチャットボットに組み込めば、「最寄り店舗の在庫と営業時間を教えて」や「駐車場がある店舗だけ見せて」といった問い合わせに対して、構造化データ＋自然言語の返答で対応できる。これまでは自社DBと地図APIとLLMを別々に実装して繋ぐ必要があったが、その一部をGoogleに任せられる。

防災・緊急時の情報アプリ。 災害時に「現在地から最も近くで空きのある避難所」や「徒歩で向かえる薬局」を即座に返すような用途は、地図データの鮮度とLLMの自然言語理解の両方が必要で、今までは外部ベンダーを複数組み合わせないと作れなかった。Maps Groundingを使えば、最小限のPythonスクリプトから始められる。

これらはいずれも、**「Googleマップを単独で使うのは難しかったが、LLMが自然言語で制約を受け取り、裏で地図を触って答える」**というパターンだ。エンドユーザーは「AIに話しかけるだけ」で済み、アプリ開発者は「LLMとMaps APIを手でつなぐグルーコード」から解放される。

使ってみた上での注意点

実際にいくつか叩いてみて気になった点を、3つだけ挙げておく。

ひとつめは、対応モデルが限定されていること。現状で Maps Grounding が動くのは gemini-3-pro-preview と gemini-3-flash-preview のみ。Gemini 2.5系や旧APIでは動かない。新しいモデルに乗り換える前提になっているので、既存アプリの改修時は要注意だ。

ふたつめは、日本ロケールでの動作精度。Googleマップ自体の日本データはかなり充実しているのだが、Gemini側がクエリを組み立てるときに「カタカナ／漢字／ローマ字」の揺れに引きずられる場面がある。lat_lng で位置をはっきり渡してやると、この手の揺れはかなり抑えられる印象だ。

みっつめは、プライバシー。ユーザーの現在地をプロンプトに含める以上、Geminiへの送信データに位置情報が乗ることになる。アプリ側でユーザーの同意取得や、lat_lng を粗めの精度に丸めて送るといった配慮は、プロダクションでは必須になる。

位置付けの整理

Google検索グラウンディングが「Web上の最新情報をLLMに渡す機能」だとすると、Maps Groundingは「現実世界の場所情報をLLMに渡す機能」、と整理するのが分かりやすい。OpenAIやAnthropicの側には、地図データに直接アクセスするネイティブのツールはまだない。特定の地理系ワークロードに限って言えば、短期的にはGoogleが明確なアドバンテージを持つ領域になりそうだ。

筆者の個人的な興味としては、「国内の飲食店探索」や「不動産の周辺環境調査」といった、日本語ユーザーの検索意図が明確な領域で、このツールがどれくらい早く日本のアプリに組み込まれるかを見ている。SDKが整ったことで、エンジニアが1人いれば週末プロジェクトでプロトタイプまで持っていけるレベルに下がっている。

すぐにプロダクションに投入できるツールというより、「今のうちに触って、半年後のアプリに組み込む素振りをしておく」タイプの機能だと思う。それでも、API経由で扱えるようになった瞬間から、地図系アプリの設計原理がひとつ変わったのは間違いない。