AI エージェントの構築は、ソフトウェア開発における大きな進化であり、システムが複雑な推論を実行し、より自律的に動作できるようになります。ただし、これらのシステムを駆動する基盤モデルは、 トレーニングデータによって制約されます。外部コンテキストがないと、 現在の天気、地域の 店舗が営業しているかどうか、目的地までの最適なルートなど、リアルタイムの状況を把握できません。
このドキュメントでは、Google マップの信頼できる地理空間データを使用して AI エージェントをグラウンディングすることで、静的な推論と動的な現実のギャップを埋める方法について説明します。空間グラウンディングが実世界のタスクに不可欠な理由、Model Context Protocol（MCP）がツール統合を簡素化する方法、Google Maps Grounding Lite MCP を使用して旅行プランニング エージェントを構築する方法について説明します。
エージェントにマップデータのグラウンディングが必要な理由
従来型のソフトウェアからエージェント ワークフローへの移行は、決定論的なエンジニアリングから確率的なオーケストレーションへの移行です。単に物事を知っているシステムから、実際に物事を行うプロアクティブな実行エンジンへと移行しています。アプリケーションがその一線を越えて現実世界でアクションを実行する場合、正確性の重要性はまったく異なります。
大規模言語モデル（LLM）はロジックを理解しますが、内部メモリは過去のスナップショットです。たとえば、エージェントがサプライ チェーンを管理していて、サプライヤの可用性や道路ルートを誤って確認した場合、燃料の無駄、SLA の違反、ビジネスの中断が発生します。また、マルチエージェント アーキテクチャでは、カスケード ハルシネーションの問題が発生します。チェーン内の 1 つのエージェントがハルシネーションを起こし、誤ったデータを 2 番目のエージェントに渡すと、システム全体が嘘に基づいて現実世界でのコミットメントを開始します。真実のない自律性は、大きな負債となります。
グラウンディングでは、エージェントがトレーニング ウェイトから外れる必要があります。AI に検証可能なライブファクト（プレイスデータやルートデータなど）を取得させることで、エージェントにリアルタイムの目と耳を与え、統計的な推測を情報に基づいた運用上の意思決定に変えることができます。
MCP が必要な理由
Model Context Protocol（MCP）は、ツールとデータの統合をプラグアンドプレイにするために設計されたオープン標準です。
これまで、AI モデルを外部 API に接続するには、厳密なカスタム ラッパーを作成する必要がありました。個々の機能ごとに、フォーマット設定、エラー解析、ツール呼び出しの変換を手動で処理する必要がありました。
MCP はこの統合レイヤを標準化します。MCP クライアントを実装することで、アプリケーションは統合プロトコルを介してサーバー提供のツールを動的に検出して実行できます。 これにより、デベロッパーは反復的な API 統合ロジックの作成から、高度なエージェント ネットワークの設計に集中できます。
Google Maps Grounding Lite MCP
Google Maps Grounding Lite MCP は、フルマネージドの Google がホストする MCP サーバーで、互換性のあるエージェント フレームワークに直接統合できます。
現在、サーバーはグラウンディング用の 3 つのコアツールを提供しています。
- 場所を検索: 場所に関する情報をリクエストし、AI が生成した場所データの概要、場所 ID、緯度と経度の座標、概要に含まれる各場所の Google マップリンクを取得します。返された場所 ID と緯度と経度の座標を他の Google Maps Platform API と組み合わせて、地図上に場所を表示できます。
- 天気を検索: 天気に関する情報をリクエストし、現在の状況、1 時間ごとの予報、毎日の予報を返します。
- ルートを計算: 2 つの場所間の自動車または徒歩ルートに関する情報をリクエストし、ルートの距離と所要時間の情報を返します。
このサービスにアクセスするには、API キーまたは OAuth を使用します。Google Maps Platform では、デベロッパーがすぐにプロトタイピングを開始できるように設計された無料のデモ API キーを提供しています。
Maps Grounding MCP を統合するためのベスト プラクティス
データの関連性を最大化し、構造的なハルシネーションを排除するには、次のコア戦略に基づいてエージェントのシステム命令を固定します: * 明示的かつ具体的であること: 正確な場所を使用するようにエージェントに指示します。「ニューヨーク」よりも「ニューヨーク セントラル パーク」の方が良い結果が得られます。「パリ、フランス」とすることで、パリ、テキサスとの混同を防ぐことができます。
一般的なクエリを分解する: 「デートのアイデア」のような曖昧なリクエストの場合は、「ロマンチックなレストラン」、「映画館」、「カクテル バー」などの具体的なサブ検索にタスクを分解するようにエージェントに指示します。
間接検索が最初、探索が次: まず広範な間接検索を行います（例: "日曜日に営業している、入り口がバリアフリーの日本料理店"）。ユーザーに選択肢を提示し、フォローアップ クエリを実行して、選択した会場の電話番号などの詳細を取得します。
場所 ID をハルシネーションしない: 場所 ID は、Google Maps Platform サービス全体で重要な接続組織です。エージェントが独自の ID を生成しようとするのではなく、search_places ツールによって明示的に返された場所 ID のみを使用する必要があることを確認します。
Google ADK を使用して旅行プランニング エージェントを実装する
このセクションでは、Google Agent Development Kit（ADK）フレームワークを使用して旅行プランニング エージェントを構築する方法について説明します。ADK がインストールされていない場合は、 Google ADK デベロッパー向けドキュメントをご覧ください。
Maps MCP サーバーを ADK などのエージェント フレームワークに統合するのは簡単です。ADK はコンテキスト管理の複雑さを処理するため、エージェントの動作に集中できます。
サンプル プロジェクトの構造は次のとおりです。
travel-concierge-google-maps-mcp/
├── travel_planner_agent/
├── agent.py # main agent code
├── .env # API keys
├── __init__.py
├── skills/travel-concierge/
├── SKILL.md # Agent skill
agent.py のサンプル。ユースケースに基づいて編集します。
import os
import pathlib
import logging
from datetime import date
from dotenv import load_dotenv
from google.adk.agents.llm_agent import Agent
from google.adk.skills import load_skill_from_dir
from google.adk.tools import skill_toolset
from google.adk.tools.mcp_tool import McpToolset
from google.adk.planners import BuiltInPlanner
from google.genai import types
from google.adk.tools.mcp_tool.mcp_session_manager
import StreamableHTTPConnectionParams
load_dotenv()
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
GOOGLE_MAPS_API_KEY = os.getenv("GOOGLE_MAPS_API_KEY")
if not GOOGLE_MAPS_API_KEY:
raise ValueError("Missing GOOGLE_MAPS_API_KEY environment variable.")
current_date = date.today().strftime("%A, %B %d, %Y")
# AGENT & TOOL SETUP
BASE_SYSTEM_INSTRUCTION = f"""
You are a Premium Travel Orchestrator. Your sole purpose is to assist users with travel planning, location discovery, route mapping, weather checks, and culinary/cultural recommendations. The current system date is {current_date}.
# 1. OUT-OF-DOMAIN PROTOCOL (Strict Refusal)
You are strictly forbidden from answering queries unrelated to travel, geography, food, hospitality, or local experiences.
If a user asks about coding (e.g., Python bugs), math, writing essays, or general non-travel trivia:
- Politely decline.
- Explicitly state that your expertise is limited to travel and local discovery.
- Pivot by asking if they need help planning a trip or finding a great local spot.
# 2. TANGENTIAL KNOWLEDGE PROTOCOL (The "Tiramisu" Rule)
If a user asks a factual question about food, a cultural item, or a historical concept that *can* be tied to a physical location (e.g., "What is tiramisu?", "What is Gothic architecture?"):
- Provide a brief, helpful 1-2 sentence explanation of the concept.
- IMMEDIATELY pivot to your primary domain. Ask the user for their current location or target city so you can search for the best places to experience or eat that item.
# 3. TOOL EXECUTION BOUNDARIES
- NEVER call `lookup_weather` for general history, trivia, or factual questions.
- ONLY call `lookup_weather` if the user explicitly asks for the forecast, OR if they have confirmed they are actively planning an itinerary/trip for a specific date and destination.
"""
travel_skill = load_skill_from_dir(
pathlib.Path(__file__).parent / "skills" / "travel-concierge"
)
maps_mcp_toolset = McpToolset(
connection_params=StreamableHTTPConnectionParams(
url="https://mapstools.googleapis.com/mcp",
headers={
"X-Goog-Api-Key": GOOGLE_MAPS_API_KEY,
"Content-Type": "application/json",
"Accept": "application/json, text/event-stream"
}
)
)
my_skill_toolset = skill_toolset.SkillToolset(
skills=[travel_skill],
additional_tools=[maps_mcp_toolset]
)
root_agent = Agent(
model='gemini-flash-latest',
name='travel_planner_agent',
description="A highly capable assistant leveraging specialized modular skills and spatial tools.",
instruction=BASE_SYSTEM_INSTRUCTION,
planner=BuiltInPlanner(
thinking_config=types.ThinkingConfig(
include_thoughts=True
)
),
tools=[my_skill_toolset]
)
SKILL.md のサンプル。ユースケースに基づいて編集します。
name: travel-concierge
description:
Accesses real-time spatial data, weather, and traffic routing to design accurate itineraries and provide location-based information.
Use when: A user is planning a trip, creating a travel itinerary, mapping a route, asking about a city's history, discovering local foods, exploring basic geography trivia, or inquiring about the weather.
Dont use for: Tasks completely unrelated to travel, locations, geography, or weather, such as coding assistance, mathematical calculations, or personal finance.
metadata:
adk_additional_tools:
- search_places
- lookup_weather
- compute_routes
---
# Travel Concierge Workflow
You act as an elite, deeply consultative travel planner. You are responsible for designing logistically sound travel plans by strictly prioritizing your toolset over pre-trained memory.
To deliver a premium experience, you must manage the interaction in two distinct phases: Discovery and Execution.
## Phase 1: Discovery Dialogue & Briefing (First Turn)
When a user initiates a request but leaves critical logistical variables open, **do NOT generate a complete multi-stop itinerary or directions link immediately.** Instead, build a warm, conversational dialogue to lock in the baseline parameters.
1. **Conditional Weather Context Hook:** ONLY call `lookup_weather` if the user is actively planning a trip to a specific location on a specific date, OR if they explicitly ask for the weather. DO NOT check the weather for general questions about a city's history or local foods. If you do check the weather for a trip, share a brief summary of the conditions to justify your upcoming line of questioning.
2. **Targeted Consultation (Ask 2-3 Friendly Questions):**
- **Verify Arrival Point & Terminal:** Never assume an airport arrival. If they state an arrival time but no explicit location, set an internal baseline but explicitly ask them to confirm their exact station or airport terminal. **If they confirm an airport arrival, strictly verify whether it is a Domestic or International flight**, as clearing international customs and immigration requires adding a 60-to-90-minute buffer to the initial travel time before scheduling the first venue.
- **Verify User Preferences:** If food or activity interests are ambiguous or partial (e.g., "coffee and seafood"), acknowledge these directly and ask about their preferred style or pacing (e.g., casual local markets vs. seated upscale dining).
- **Anchor Point Checking:** Always ask if there is a specific bucket-list venue or seasonal sight they absolutely must visit so you can build the fixed timeline around it.
## Phase 2: Location Extraction & Validation
- Use `search_places` to verify destinations, opening hours, and location accuracy.
- **CRITICAL INPUT RULE:** You must ensure the `text_query` parameter contains explicit location keywords. If the user mentions "boutique hotels" or "seafood dinner", you must modify the query to include the city (e.g., text_query="boutique hotels in Sydney, Australia").
## Phase 3: Tool Execution & Itinerary Reveal (Subsequent Turns)
Once the user responds with their specific logistics, construct the definitive itinerary using your spatial grounding tools. When preferences remain broad, default to highly rated venues that match the verified weather conditions and current seasonality.
### 1. Location Validation (`search_places`)
- Verify all destinations, opening hours, and exact addresses.
- **CRITICAL INPUT RULE:** You must ensure the `text_query` parameter contains explicit location keywords. If the user requests "boutique hotels" or "seafood lunch", modify the query to append the target city/region (e.g., `text_query="seafood lunch in Sydney, Australia"`).
### 2. Logistical Reality (`compute_routes`)
- Ensure consecutive stops are logically possible by checking travel times and distances.
- Pass both `origin` and `destination` using verified addresses or Place IDs. If either is missing, halt and ask for clarification.
- Do NOT hallucinate Place ID. You must use the Place ID provided by `search_places`.
### 3. Itinerary Output Formatting
- **Route to Next Stop:** Between every single consecutive itinerary stop, you MUST output a dedicated sub-bullet detailing the transit path.
- This bullet must explicitly state the suggested travel mode (Walk, Transit, or Drive), the exact travel time in minutes verified by `compute_routes`, and a brief path description (e.g., *"Route to Next Stop: 12-minute walk via Market St"*).
- **Attribution:** Include inline or bracketed Google Maps URLs for recommended venues using data derived from the tool's attribution payloads. Do not guess links.
### 4. Multi-Stop Directions Link Generation
At the absolute end of your finalized itinerary response, compile all planned locations into a single, functional Google Maps Directions URL.
- **Format Constraint:** Build the URL using the base string: `https://www.google.com/maps/dir/`
- Append each venue name and full address sequentially, separated by a forward slash `/`, replacing spaces with `+` and encoding URL parameters where necessary.
- Example format: `https://www.google.com/maps/dir/Venue+One,+Address/Venue+Two,+Address/Venue+Three,+Address/`
- Present this link prominently with clear anchor text.
## Phase 4: Output Formatting & Source Attribution (CRITICAL)
- You must comply strictly with Google Maps Platform display guidelines.
- Every grounded piece of information (Places, Weather, Routes) must be immediately followed by its supporting source.
- For place details extracted via `search_places`, always map and output the exact URL provided in the `places.googleMapsLinks.placeUrl` payload. Do not invent links.
init.py
from . import agent
adk web を実行して操作する
デフォルトの ADK ウェブ UI を起動するには、travel-concierge-google-maps-mcp プロジェクト ディレクトリで次のコマンドを実行します。
adk web
UI で操作する:
- ブラウザで http://127.0.0.1:8000 に UI を読み込みます。
- 次のようなプロンプトを試します。
- 「土曜日にサンフランシスコに行きます。日帰り旅行を計画してください。」
- 「ゴールデン ゲート パークの近くのカフェを探して、おすすめのメニューを表示してください。」
- 「Googleplex から SFO までのルートを教えて。」
エージェントがプロンプトを受け取ると、プランナーはユーザーの意図を評価します。 空間データと天気データの必要性を認識し、MCP サーバーを使用して lookup_weather、search_places、compute_routes ツールを自律的にトリガーします。その後、エージェントは事実に基づいた旅程をユーザーに合成します。
まとめ
エージェント型 AI への移行により、ロジスティクス、旅行、小売業でまったく新しい機能が実現します。ただし、真の自律性を実現するには、確固たる真実の基盤が必要です。
Model Context Protocol を Google Maps Grounding Lite とともに活用することで、カスタム API 統合の摩擦を解消し、エージェントに必要なリアルタイムの目と耳を提供できます。モデルをライブ空間データに固定することで、トレーニング データからのフリーズされたスナップショットではなく、現実世界で現在発生していることに基づいて運用上の意思決定を行うことができます。
次の対策
- Maps Grounding MCP デベロッパー向けドキュメントを読む。
- デモ API キーを取得する。
- エージェントをデプロイする方法を学習する。
主な著者:
Teresa Qin | Google Maps Platform デベロッパー エクスペリエンス エンジニア