こんにちは！
KDDIアイレットの取り組みとして6月22日〜7月3日の期間で開催中の「Google Cloud Next '26 / Google I/O やってみた系ブログリレー」、最終日の投稿です。
今回は「Google検索によるグラウンディング」を対象に、実際に検証してみた様子をお届けします！
前回の記事はこちらです。
はじめに
本記事では、Gemini の「Google 検索によるグラウンディング」をテーマに、基本の仕組みから実装方法、ハルシネーションへの効果、課金の仕組みまでを、Gemini Enterprise Agent Platform（旧 Vertex AI）経由で実際に動かしながら解説します。
また、Google Cloud Next '26 では、グラウンディングソースとして「画像付き Google 検索」「Google マップのルート案内」が新たに追加されました（いずれもプレビュー）。これらの新機能も合わせて検証してみたいと思います。
この記事で分かること
- グラウンディングの基本と RAG との違い
-
google-genaiSDK でのグラウンディングの実装方法 - ハルシネーションがグラウンディングでどう変わるか（あり/なし比較）
- 新機能「画像付き Google 検索」「Google マップのルート案内」の挙動
- 課金の仕組み（Gemini 2.x と 3 系で課金単位が違う）と、1 プロンプトで実際に何クエリ課金されるかの実測
- ハマりどころ（旧ツール名・旧 SDK・Dynamic Retrieval の廃止など）
グラウンディングとは（RAG との違い）
グラウンディング（Grounding）は、「自分の知識だけで答えるのではなく、外部の情報を参照して答える」仕組みです。
Gemini の Google 検索グラウンディングでは、モデルが必要と判断したタイミングで Google 検索を実行し、その結果に基づいて回答を生成します。
RAG と何が違うの？と思われるかもしれませんが、整理するとこうなります。
| RAG（自前構築） | Google検索 Grounding | |
|---|---|---|
| 検索対象 | 自分で用意したドキュメント（社内文書など） | Google 検索（公開 Web 全体） |
| 検索基盤 | ベクトル DB 等を自前で構築・運用 | Google がマネージドで提供 |
| 検索実行の判断 | アプリ側で制御 | モデルが自動で判断 |
セットアップ
1. Agent Platform API を有効化（旧 Vertex AI）
現在の正式名称は「Gemini Enterprise Agent Platform」ですが、有効化する API 名は従来どおり aiplatform.googleapis.com です。（名前がズレているので注意）
2. パッケージインストール（google-genai）
pip install google-genai
3. 認証（ADC）
gcloud auth application-default login
Gemini グラウンディングを実際に試してみた
実験設計：何をどう比較したか
以下の条件で検証しました。
-
モデル:
gemini-3.5-flash - temperature: 1.0（グラウンディング利用時の公式推奨値）
-
実装: 基本の実装は以下だけです。
toolsにGoogleSearch()を渡すだけでグラウンディングが有効になります。
from google import genai
from google.genai.types import (
GenerateContentConfig, GoogleSearch, Tool
)
client = genai.Client(
vertexai=True, project="PROJECT_ID", location="global"
)
response = client.models.generate_content(
model="gemini-3.5-flash",
contents="Gemini Omniについて教えて",
config=GenerateContentConfig(
tools=[Tool(google_search=GoogleSearch())],
temperature=1.0,
),
)
print(response.text)
ハルシネーション検証（あり / なし比較）
最新情報を問うプロンプトで、グラウンディングあり/なしの回答を比較します。
プロンプト：Gemini Omni について教えて
グラウンディングなし
「Gemini Omni（ジェミニ・オムニ）」という名称のサービスやモデルは、実は公式には存在しません。
おそらく、以下の2つの最新AI技術が混ざって（混同されて）認知されている可能性が高いです。
OpenAIの「GPT-4o（ジーピーティー・フォー・オムニ）」
Googleの「Gemini（ジェミニ）」シリーズ（特にリアルタイム音声機能の「Gemini Live」など）
ここでは、この混同を整理した上で、「GPT-4o（オムニ）」と、それに対抗するGoogleの最新AI「Gemini」の機能について分かりやすく解説します。
1. 「オムニ（Omni）」の正体：OpenAIの「GPT-4o」
「Omni（オムニ）」はラテン語で「全能の」「あらゆる」を意味します。
2024年5月にOpenAI社が発表した最新AIモデルが**「GPT-4o（GPT-4 Omni）」**です。
特徴： テキスト、音声、画像を瞬時に、かつ一体的に処理できる「ネイティブ・マルチモーダル」AIです。
音声会話： 人間とほぼ同じ速度（0.3秒以下）で応答し、感情豊かな会話や、途中で話を遮っての会話が可能です。
2. Googleの対抗馬：最新の「Gemini」
Googleが提供するAIサービスが**「Gemini（ジェミニ）」**です。GPT-4o（Omni）に匹敵、あるいは超える機能を持っています。
もし「Gemini版のOmniのような機能」を探している場合、以下の技術が該当します。
① Gemini Live（ジェミニ・ライブ）※GPT-4oの音声機能に対抗
概要： Googleが提供する、最新のリアルタイム音声会話機能です（現在Androidなどで順次展開中、日本語にも対応）。
特徴： GPT-4oの音声モードのように、スマホに向かって話しかけると、自然な日常会話のペースでキャッチボールができます。話の途中で遮って質問し直すことも可能です。
② Gemini 1.5 Pro / Flash（モデル）
超長文の理解（コンテキストウィンドウ）： Geminiの最大の強みです。最大200万トークンという膨大なデータを一度に読み込めます。これは**「1時間の動画」「約22時間の音声」「本数冊分（約150万文字）」を一度にAIに読み込ませて質問できる**レベルであり、GPT-4oを大きく上回っています。
③ Project Astra（プロジェクト・アストラ）※未来の「Omni」
概要： Googleが開発中の「未来のAIアシスタント」のプロトタイプです。
特徴： スマホのカメラで映している映像をリアルタイムで理解し、「そこにあるものは何？」「さっき鍵をどこに置いたっけ？」といった質問に、映像と音声で即座に答えてくれます。
Gemini Omniは2026年5月19日に開催された「Google I/O 2026」にて、発表された実在するサービスですが、存在しないと出力されました
グラウンディングあり
Gemini Omniは、Google（Google DeepMind）が開発した、最先端の**「any-to-any（あらゆる入力からあらゆる出力を生成する）」マルチモーダル生成AIモデル**です。
単にテキストから動画を生成するだけの従来のAIモデルとは異なり、Geminiの持つ高度なテキスト推論・文脈理解能力と、Google最高峰のメディア生成技術を融合した**「統合型オムニモデル」**として設計されています。
1. 主な特徴と機能
① 「世界モデル（World Model）」としての高い物理・世界理解
Gemini Omniは、単に「それらしい映像」をピクセル単位でつなぎ合わせるのではなく、現実世界のルール（重力、運動エネルギー、流体力学などの物理法則）や、科学・歴史・文化的背景を理解した上で映像を構築します。 これにより、複雑な連鎖反応の動きや、キャラクターの自然な挙動などを破綻なくシミュレートした、ストーリー性のある映像を生成できます。
② 対話によるステップ・バイ・ステップの動画編集（会話型動画編集）
従来の動画編集ソフトのようにタイムラインを操作する必要はありません。「背景を夜にして」「照明を暗くして」「腕を反射する鏡のような金属素材に変えて」といった自然な言葉での指示を通じて、対話形式で動画を何往復も修正・編集していくことができます。
③ マルチリファレンス入力（マルチモーダル・ミキシング）
テキスト、画像、既存の動画、スケッチ、音声など、異なる種類の素材（リファレンス）を自由に組み合わせて、1つのブレンドされた一貫性のある動画を作ることができます51112。手描きのラフスケッチから複雑なアニメーション映像に変換すること（スケッチ・トゥ・ビデオ）なども可能です。
2. 提供されているモデルと利用方法
現在、Omniファミリーの最初のモデルとして**「Gemini Omni Flash」**が提供されています。このモデルは、以前の動画生成AI「Google Veo（Veo 3.1）」の後継・代替モデルとして位置づけられています。
一般ユーザー向け（Gemini アプリ / Google Flow）
Googleの有料サブスクリプションプラン（Google AI Plus、Pro、Ultraユーザー向け）として、Geminiアプリ内や、クリエイティブワークフローツール「Google Flow」で利用できます。
YouTube ShortsやYouTube Createアプリなどでも順次、一部機能が連携・提供されています。
開発者・企業向け（Gemini API / Google AI Studio）
開発者向けのパブリックプレビュー版（gemini-omni-flash-preview）として、API経由でアクセスが可能です。
高品質な動画生成と対話型編集を低コスト（動画出力1秒あたり0.10ドルなど）で利用できます8。現在は10秒までの動画生成に対応しており、順次機能が拡張されています8。
3. 安全性への配慮（SynthIDの自動適用）
AIによって生成された動画による偽情報の拡散などを防ぐため、Gemini Omniで生成された動画には、人間の目には見えないデジタル透かし技術**「SynthID」**が自動的に埋め込まれます36。これにより、後からその動画がAIによって作られたものかどうかを検出・判定することが可能になっています。
まとめ
Gemini Omniは、単なる「動画を作る道具」を超えて、AIに話しかけながら一緒に映像作品を創り上げていく**「対話型の動画クリエイティブパートナー」**です1112。今後はさらに上位のモデル（Omni Proなど）の展開や、より長い動画生成、音声・キャラクターの一貫性の強化など、継続的なアップデートが予定されています。
グラウンディングありでは、最新の発表内容を正確に踏まえた回答が返ってきました
実際に何を検索したのか
groundingMetadata.web_search_queries を見ると、モデルが裏で実行した検索クエリが確認できます。
grounding_metadata = response.candidates[0].grounding_metadata
print("--- Web Search Queries ---")
print(grounding_metadata.web_search_queries)
print("--- Grounding Chunks (引用元) ---")
for chunk in grounding_metadata.grounding_chunks or []:
print(chunk.web.title, chunk.web.uri)
--- Web Search Queries ---
['Gemini Omni', 'Google Gemini Omni', 'Gemini Omni とは']
--- Grounding Chunks (引用元) ---
geminiomni.co https://vertexaisearch.cloud.google.com/grounding-api-r...
note.com https://vertexaisearch.cloud.google.com/grounding-api-redire...
weel.co.jp https://vertexaisearch.cloud.google.com/grounding-api-redi...
note.com https://vertexaisearch.cloud.google.com/grounding-api-redire...
ai-souken.com https://vertexaisearch.cloud.google.com/grounding-api-r...
qiita.com https://vertexaisearch.cloud.google.com/grounding-api-redi...
blog.google https://vertexaisearch.cloud.google.com/grounding-api-re...
itmedia.co.jp https://vertexaisearch.cloud.google.com/grounding-api-red...
ここで注目したいのが 1 つのプロンプトから複数の検索クエリが生成される 点です。
これが後述する Gemini 3 系の課金形態に直結します。
画像付き Google 検索（プレビュー）を試す
Next '26 で発表された新機能で、Google 画像検索から取得したウェブ画像を、画像の生成時のビジュアル コンテキストとして使用できるようになりました。
今回は「モデルが知らないはずの実在の建物を、検索で見つけた実際の画像に基づいて生成できるか」を試します。
題材は、2026 年 3 月 28 日に開業したばかりの JR 大井町駅直結の複合施設「OIMACHI TRACKS（大井町トラックス）」です。
開業から日が浅く、モデルの学習データにはほとんど含まれていないと考えられる被写体です。
from google import genai
from google.genai.types import GenerateContentConfig, GoogleSearch, ImageSearch, SearchTypes, Tool
client = genai.Client(
vertexai=True, project="PROJECT_ID", location="global",
)
response = client.models.generate_content(
model="gemini-3.1-flash-image",
contents="OIMACHI TRACKS（大井町トラックス）の外観画像を生成して",
config=GenerateContentConfig(
tools=[Tool(google_search=GoogleSearch(search_types=SearchTypes(image_search=ImageSearch())))],
temperature=1.0,
response_modalities=["TEXT", "IMAGE"],
),
)
# 生成画像を保存
for i, part in enumerate(response.candidates[0].content.parts):
if part.inline_data:
with open(f"generated_{i}.png", "wb") as f:
f.write(part.inline_data.data)
# 実行された画像検索クエリと参照画像を観測
metadata = response.candidates[0].grounding_metadata
queries = (metadata and metadata.image_search_queries) or []
for query in queries:
print(query)
print("--- Grounding Chunks (参照画像) ---")
for chunk in (metadata and metadata.grounding_chunks) or []:
if chunk.image:
print(chunk.image.title, chunk.image.image_uri)
グラウンディングなし
比較のため、まずはツールを指定せずに同じプロンプトを実行してみます。
AIが勝手に予想して、実際の外観とはかけ離れた建物が生成されました。
グラウンディングあり
完全一致とはいきませんが、比較的近しい外観が生成されました。
=== 画像検索クエリ ===
['大井町駅周辺 開発', '大井町トラックス', 'OIMACHI TRACKS', 'OIMACHI TRACKS 外観']
=== グラウンディングチャンク ===
[0] Tokyo's New Landmark: <b>Oimachi Tracks</b> Opens Today! 3/28 [4K ...
掲載ページ: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEkpsGDdkYG...
画像URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEVfu-FinJw...
[1] <b>Oimachi Tracks</b> | Things to do in Oimachi, Tokyo
掲載ページ: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHcIouEx2hi...
画像URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQH_PI2qUqRg...
[2] 大井町駅直結「<b>大井町トラックス</b>」の見どころは？多彩なショップ ...
掲載ページ: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHTpGOCWmo_...
画像URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEs9X-kyAlQ...
[3] <b>大井町</b>駅に直結する大型複合施設「OIMACHI <b>TRACKS</b>」に ...
掲載ページ: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFIqTGKp06L...
画像URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEwlMCmR_uP...
[4] <b>OIMACHI TRACKS</b>でしかできない6のこと
掲載ページ: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQF4rCJUBy-T...
画像URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFJFQfTFT3B...
[5] <b>大井町駅周辺</b>広町地区<b>開発</b>（仮称）に本格着手します～2023年4月 ...
掲載ページ: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGgUJaq0q8o...
画像URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFOT5wGXMqt...
[6] JR東日本、品川区の<b>大井町駅周辺</b>を再<b>開発</b> 2万㎡弱の商業施設も ...
掲載ページ: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHNJC5BNvza...
画像URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGxizdHmLx7...
検証して分かったこと
画像生成でもグラウンディングが発動し、クエリはモデルが賢く組み立てる
プロンプトには施設名しか入れていませんが、image_search_queries を見ると「OIMACHI TRACKS 外観」のように生成意図（外観）を汲んだクエリや、日本語/英語の表記ゆれ、さらに「大井町駅周辺 開発」という周辺文脈のクエリまで、4 件が自動生成されていました。Web グラウンディングで見た「1 プロンプト = 複数クエリ」の挙動は画像検索でも同じです。
Google マップのルート案内（プレビュー）を試す
同じく Next '26 で発表された新機能で、Google マップの経路・所要時間・交通情報をグラウンディングソースとして使えます。
Google 検索と同一のグラウンディングの仕組みで利用可能です。
発表内容によると、この機能のポイントは次の 3 つです。
- Google マップのルート案内機能で、ユーザーからの質問に対応できる
- 興味のある場所を検索した後、そこへの行き方を質問すると、様々な交通手段に対応した最新のルート案内を受け取れる
- 開発者は、視覚的なルート案内をアプリケーションに統合できる
あえて移動手段を指定せず、判断ごと Gemini に任せるプロンプトで試してみます。
from google import genai
from google.genai.types import GenerateContentConfig, GoogleMaps, Tool
client = genai.Client(
vertexai=True, project="PROJECT_ID", location="global"
)
response = client.models.generate_content(
model="gemini-3.5-flash",
contents="今から渋谷から成田空港まで向かう場合、最適な移動手段と所要時間、料金を比較して",
config=GenerateContentConfig(
tools=[Tool(google_maps=GoogleMaps())],
temperature=1.0,
),
)
print(response.text)
grounding_metadata = response.candidates[0].grounding_metadata
queries = grounding_metadata.retrieval_queries or []
print(f"--- Retrieval Queries ({len(queries)} 件) ---")
for query in queries:
print(query)
print("--- Grounding Chunks (引用元) ---")
for chunk in grounding_metadata.grounding_chunks or []:
print(chunk.maps.title, chunk.maps.uri)
回答の冒頭部分がこちらです（全文は折りたたみ内）。
今から（平日の18時台前半）渋谷から成田空港へ向かう場合、最適な移動手段は**「確実性と速さ」を重視するか「安さ」を重視するか**によって異なります。
特に**平日の夕方・夜間は道路渋滞や電車の帰宅ラッシュが発生する時間帯**であるため、それを考慮した以下の4つのルートを比較して最適な方法をご提案します。
回答の全文はこちらを展開
今から（平日の18時台前半）渋谷から成田空港へ向かう場合、最適な移動手段は**「確実性と速さ」を重視するか「安さ」を重視するか**によって異なります。
特に**平日の夕方・夜間は道路渋滞や電車の帰宅ラッシュが発生する時間帯**であるため、それを考慮した以下の4つのルートを比較して最適な方法をご提案します。
---
### 1. 【おすすめ：最速・確実】京成スカイライナー（日暮里乗り換え）
渋谷から山手線で日暮里駅へ向かい、そこから最速の特急「スカイライナー」に乗り換えるルートです。
* **ルート：** 渋谷駅 ──（JR山手線：約30分）── 日暮里駅 ──（京成スカイライナー：約36分）── 成田空港
* **所要時間：** **約75分〜80分**（乗り換え時間含む）
* **料金：** **2,778円**（IC運賃）
* 内訳：JR山手線 208円 ＋ スカイライナー 2,570円（乗車券1,270円＋ライナー券1,300円）
* ※京成の「スカイライナーeチケット」をネットで事前購入すると、ライナー券が割引（乗車券込みで2,300円）になり、合計**2,508円**になります。
* **メリット：**
* とにかく早く、運行本数も約20分間隔と多いため、今すぐ出発するのに最適です。
* ほぼ遅延がなく、最も予定が立てやすい確実なルートです。
* **デメリット：**
* 日暮里駅での乗り換えが必要です。また、18時台の山手線は帰宅ラッシュで混雑しているため、大きなスーツケースを持っている場合は移動に少し体力を要します。
---
### 2. 【一番ラク：直通・快適】JR特急「成田エクスプレス（N'EX）」
渋谷駅から乗り換えなしで、確実に座って成田空港まで直行できるルートです。
* **ルート：** 渋谷駅 ──（JR成田エクスプレス：直通）── 成田空港
* **所要時間：** **約75分〜80分**
* **料金：** 通常 **3,440円**
* 内訳：乗車券 1,710円 ＋ 指定席特急券 1,730円
* ※JR東日本の「えきねっとチケットレスサービス」を利用すると200円引きの**3,240円**になります。
* **メリット：**
* 渋谷から乗り換えなし。荷物置き場も広く、車内WiFiやコンセントもあり、圧倒的に移動が楽です。
* **デメリット：**
* 渋谷駅に停車する成田エクスプレスは**1時間に1本程度**と本数が限られています。
* ※直近の出発便がない場合、山手線で新宿駅や中央線等で東京駅に出てから乗車することになり、直通のメリットが薄れてしまいます。まずは駅の電光掲示板やスマホで直近の運行時間を確認してください。
---
### 3. 【安さ重視：通常電車】半蔵門線 ＋ 京成アクセス特急
特急料金を払わず、一般の通勤電車を乗り継いで安く済ませるルートです。
* **ルート：** 渋谷駅 ──（東京メトロ半蔵門線：約30分）── 押上駅 ──（京成成田スカイアクセス線・アクセス特急：約55分）── 成田空港
* ※半蔵門線は東武線・京成線方向へ直通運転しているため、押上駅での乗り換えがスムーズ（または不要な場合も）です。
* **所要時間：** **約90分〜100分**
* **料金：** **1,411円**（IC運賃）
* 内訳：東京メトロ 242円 ＋ 京成線 1,169円
* **メリット：**
* 交通費を半額以下に抑えられます。
* **デメリット：**
* 一般の通勤電車のため、18時台は帰宅ラッシュと重なり、車内が非常に混雑します。大きな荷物を持っていると周囲への配慮が必要になり、座れない可能性も高いため、移動だけでかなり疲れます。
---
### 4. 【要注意：普段は便利だが今は非推奨】リムジンバス
渋谷の主要スポットから成田空港へ直行するバスです。
* **ルート：** 渋谷マークシティ / 渋谷フクラス / セルリアンタワー等 ──（リムジンバス）── 成田空港
* **所要時間：** 通常 約85分〜110分（※渋滞がない場合）
* **料金：** **3,600円**
* **メリット：**
* 重い荷物をバスのトランクに預け、座席で寝ているだけで到着します。
* **デメリット（現在の時間帯における致命的な欠点）：**
* **平日の夕方（18時台）は首都高速道路や湾岸線で激しい帰宅渋滞が発生する時間帯です。** 予定より1時間以上遅れるリスクが極めて高いため、フライトの時間に余裕がない場合は**今からの利用は避けてください。**
---
### 💡 結論：今から行くならどれが良い？
1. **「今すぐ駅に向かい、最も早く、確実に着きたい」**
👉 **【京成スカイライナー】** がベストです。山手線は少し混みますが、日暮里から先は非常に快適で、時間も正確です。
2. **「とにかく乗り換えが面倒。多少高くても座って楽に行きたい」**
👉 すぐにスマホ等で直近の **【成田エクスプレス（N'EX）】** の渋谷駅発車時刻を調べ、ちょうど良い便があればそれを予約するのが最も快適です。
3. **「フライトまでかなり時間があり、安さを最優先したい」**
👉 帰宅ラッシュの混雑を覚悟の上で、**【半蔵門線（押上乗り換え）アクセス特急】** をご利用ください。
--- Retrieval Queries (56 件) ---
渋谷 成田空港 アクセス 比較
渋谷 成田エクスプレス 時刻表
渋谷 日暮里 スカイライナー 時間 料金
渋谷 成田空港 バス リムジンバス 料金
渋谷 成田エクスプレス 料金 2026 OR 2025
日暮里 成田空港 スカイライナー 料金
渋谷 成田空港 リムジンバス 料金 時刻表
渋谷 成田空港 安い 電車 ルート
渋谷から成田空港 成田エクスプレス 料金 乗り換えなし
渋谷 日暮里 スカイライナー 料金 所要時間
渋谷から成田空港 電車 安い 乗り換え
渋谷 成田空港 バス 料金 渋谷フクラス 渋谷マークシティ
成田エクスプレス 渋谷 成田空港 料金 所要時間
京成スカイライナー 日暮里 成田空港 料金 所要時間
渋谷 成田空港 リムジンバス 料金 所要時間 2025 OR 2026
渋谷 成田空港 最安 ルート 料金 所要時間
"渋谷" "成田空港" 料金 比較 2025 OR 2026
渋谷から成田空港 行き方 2025 OR 2026
成田エクスプレス 渋谷から成田空港 料金 時刻
渋谷から日暮里 スカイライナー 料金
渋谷駅 成田空港 アクセス
成田エクスプレス 料金 渋谷 成田空港
スカイライナー 料金 日暮里 成田空港
渋谷駅 成田空港 バス リムジンバス
"成田エクスプレス" "渋谷" 料金 2025 OR 2026
"スカイライナー" "日暮里" 料金 2025 OR 2026
"リムジンバス" "渋谷" "成田空港" 料金 2025 OR 2026
渋谷 成田空港 アクセス特急 運賃
"成田エクスプレス" 渋谷 成田空港 運賃
"京成スカイライナー" 日暮里 成田空港 運賃
"リムジンバス" 渋谷 成田空港 運賃
"アクセス特急" 押上 成田空港 運賃
"スカイライナー" 日暮里 成田空港 運賃 OR 料金
"成田エクスプレス" 渋谷 成田空港 運賃 OR 料金
"渋谷" "成田空港" 運賃 OR 料金
"アクセス特急" 押上 成田空港 運賃 OR 料金
"成田エクスプレス" 渋谷 成田空港 料金
"スカイライナー" 日暮里 成田空港 料金
"リムジンバス" 渋谷 成田空港 料金
"アクセス特急" 押上 成田空港 料金
成田エクスプレス 渋谷 成田空港 料金
スカイライナー 日暮里 成田空港 料金
リムジンバス 渋谷 成田空港 料金
アクセス特急 押上 成田空港 料金
成田エクスプレス 料金 ブログ
スカイライナー 料金 日暮里 ブログ
リムジンバス 渋谷 成田空港 ブログ
アクセス特急 押上 成田空港 ic運賃
京成電鉄 運賃表
えきねっと チケットレス 割引額
東京空港交通 運賃
スカイライナー ネット予約 料金
京成スカイライナー特急料金 2025
成田エクスプレス料金表 2025
渋谷 成田 リムジンバス 料金改定
渋谷 成田空港 交通 比較 2025
--- Grounding Chunks (引用元) ---
Nippori Station https://maps.google.com/?cid=11556275923419300798
Narita Airport Terminal 2･3 Station https://maps.google.com/?cid=1664459653031276625
Shibuya Station https://maps.google.com/?cid=3707351856262064934
Narita Airport Terminal 1 Station https://maps.google.com/?cid=14838926946087169132
Oshiage Sta.(SKYTREE) https://maps.google.com/?cid=11632191348918607801
Narita Airport Terminal 1 Station https://maps.google.com/?cid=14838926946087169132
Shibuya Station https://maps.google.com/?cid=3707351856262064934
渋谷駅（渋谷フクラス） https://maps.google.com/?cid=1441470097982754956
セルリアンタワー東急ホテル（バス）（成田空港線・上り） https://maps.google.com/?cid=6626730746996674897
検証して分かったこと
① 移動手段を指定しなくても、状況判断つきで複数ルートを提案してくる
プロンプトで指示したのは出発地と目的地だけですが、回答は
「最速・確実」「直通・快適」「安さ重視」「要注意」の 4 ルートを自発的に構成してきました。
単に経路を列挙するのではなく、「何を重視するかで最適解が変わる」という枠組みで整理し、リムジンバスには「今からの利用は避けてください」と明確な非推奨判定まで付けています。
発表内容の「様々な交通手段に対応した最新のルート案内」が、Agent 的な判断込みで機能していることが分かります。
② 「今」を理解した回答が返ってくる
プロンプトには曜日も時刻も入れていないのに、回答は「今から（平日の18時台前半）」という現在時刻の文脈から始まり、帰宅ラッシュによる山手線・半蔵門線の混雑や首都高の渋滞リスクを各ルートの評価に織り込んでいます。
さらに「スカイライナーeチケットなら合計2,508円」「えきねっとチケットレスで200円引き」といった割引情報まで拾ってきており、静的な乗換案内の再現ではなく、リアルタイムの状況と最新の料金情報を統合した提案になっています。
③ 引用元が Google マップの「場所」になる
groundingMetadata の引用元を見ると、通常の Web グラウンディングの vertexaisearch.cloud.google.com/grounding-api-redirect/... 形式ではなく、https://maps.google.com/?cid=... という Google マップの場所への直接リンク が返ってきました。
--- Grounding Chunks (引用元) ---
Nippori Station https://maps.google.com/?cid=11556275923419300798
Narita Airport Terminal 2･3 Station https://maps.google.com/?cid=1664459653031276625
Shibuya Station https://maps.google.com/?cid=3707351856262064934
Oshiage Sta.(SKYTREE) https://maps.google.com/?cid=11632191348918607801
渋谷駅（渋谷フクラス） https://maps.google.com/?cid=1441470097982754956
セルリアンタワー東急ホテル（バス）（成田空港線・上り） https://maps.google.com/?cid=6626730746996674897
...
提案された 4 ルートの乗換駅（日暮里・押上）やバス乗り場（渋谷フクラス、セルリアンタワーのバス停）が、そのまま地図上の場所として返ってきています。
④ 1 プロンプトで 56 クエリ — 課金単位の違いが最も効くケース
移動手段すら指定していない 1 プロンプトに対して、実行されたクエリは 56 件 でした。
クエリ一覧を眺めると、
| 流れ | クエリ |
|---|---|
| 序盤 | 渋谷 成田空港 アクセス 比較 |
| 中盤 | アクセス特急 押上 成田空港 運賃 |
| 終盤 | 「えきねっと チケットレス 割引額」「京成電鉄 運賃表」 |
というように、広いクエリから始まり、ルート候補が固まるにつれて自ら発見したルートを深掘りする方向にクエリが進化 していく様子が観察できます。
これを後述の課金の話に先回りして当てはめると:
- Gemini 2.x 世代: 何クエリ走っても 1 プロンプト = 1 課金
- 今回（gemini 3.5 flash）の場合: 56 クエリが課金対象
Google 検索グラウンディングの料金形態
グラウンディングは モデルのトークン課金とは別に、ツール利用料が発生 します。
ここを理解せずに全リクエストでグラウンディングを有効にすると、請求額が想定を大きく超える可能性があります。
なお、本記事は Gemini Enterprise Agent Platform（旧 Vertex AI）経由での利用を前提としているため、以下は Agent Platform の料金体系 です（Gemini Developer API とは無料枠などの体系が異なります）。
「Web 結果が返ったときだけ」課金される
Agent Platform の Grounding with Google Search は、プロンプトが Web 検索結果を正常に返した場合（レスポンスに Web の grounding support URL が 1 件以上含まれる場合）のみ 課金されます。グラウンディングを有効にしていても、モデルが検索結果を使わなかったリクエストはツール利用料の課金対象になりません（モデル自体のトークン課金は別途発生します）。
課金単位が Gemini 2.x と 3 系で違う
| Gemini 2.x 系 | Gemini 3 系 | |
|---|---|---|
| 課金単位 | 検索プロンプトごと（内部で何クエリ実行されても 1 カウント） | 検索クエリごと（1 プロンプトから複数クエリが生成されうる） |
| 単価の目安 | $35 / 1,000 グラウンディングプロンプト | $14 / 1,000 検索クエリ |
| 無料枠 | Flash 系: 1,500 件/日、Pro: 10,000 件/日 | 5000クエリ/月 |
単価・無料枠は執筆時点の Agent Platform 料金ページに基づきます。
無料枠の区分はモデル・世代ごとに細かく異なるため、必ず 最新の料金ページ を確認してください。
参考: Gemini Developer API 側は別体系で、Gemini 3 系は月 5,000 プロンプトの無料枠（Gemini 3 間で共有）、超過後 $14 / 1,000 検索クエリです。
一見 Gemini 3 系のほうが安く見えますが、単位が「プロンプト」と「クエリ」で異なる ため単純比較はできません。
先ほどの「Gemini Omniについて教えて」の検証で見たとおり、1 プロンプトから複数の検索クエリが走ることは全然起こりうるので注意が必要です。
実測：1 プロンプトで何クエリ課金されるのか
そこで、いくつかのプロンプトで web_search_queries の件数を実測してみました。
| プロンプト | 生成された検索クエリ数 |
|---|---|
| 今から渋谷から成田空港まで向かう場合、最適な移動手段と所要時間、料金を比較して | 56 件 |
| 2025年 人気の犬種ランキングを調べて | 8 件 |
| Gemini Omni について教えて | 3 件 |
今回の検証では、ランキングのように網羅性が求められるプロンプトでは 8 件、ルートと所要時間のように複数の観点（経路・所要時間・路線など）を含むプロンプトでは 56 件という結果になりました。
コストを見積もる際は「1プロンプト＝1クエリ」ではなく、余裕を持った試算を心がけましょう。
Dynamic Retrieval によるコスト最適化は 「もうできない」
かつて Dynamic Retrieval という機能があり、「検索が本当に必要か」をモデルがスコアリングし、閾値（dynamic_threshold）を超えた場合だけ検索を実行する、というコスト制御ができました。
しかしこれは旧 google_search_retrieval ツールに紐づく機能で、Gemini 2.0 以降では未対応 です。現行モデルで google_search ツールを有効にした場合、検索を実行するかどうかの判断はモデルに完全に委ねられ、閾値によるコントロールはできません。
ハマりどころ・注意点
google_search_retrieval ではなく google_search を使う
Gemini 2.0 以降のモデルでは google_search ツールが標準です。
旧 google_search_retrieval は Gemini 1.5 世代のレガシーで、現行モデルに指定すると「そんなツールはない」というエラーになります。
- # ❌ 旧（Gemini 1.5 世代）
- tools = [Tool.from_google_search_retrieval(...)]
+ # ✅ 現行（Gemini 2.0 以降）
+ tools = [Tool(google_search=GoogleSearch())]
SDK も新旧が混在しがち
上と同根の問題で、旧 SDK google-generativeai と新 SDK google-genai を混同しているサンプルもあり、
AI に相談すると「閾値の設定は可能」や「そのためにはgoogle-generativeai を使用しましょう」と言われがちですが、罠です。
現行は google-genai に統一しましょう。
Dynamic Retrieval（閾値の設定）← 現在はできない
前述のとおり。dynamic_retrieval_config は現行の google_search ツールでは使えません。「検索するかどうか」の制御はアプリ側の設計で対応する必要があります。
課金単位の違い
これも前述のとおり、Gemini 3.x 系は検索クエリ数ごと、Gemini 2.x 系は 1 プロンプトあたり の課金です。
閾値による調整が出来ないことに加え、3.x 系に移行するとリクエスト数が同じでも課金カウントが増える可能性があるため、移行時は気をつけましょう。
その他の細かい注意
- グラウンディング利用時の temperature は 1.0 が公式推奨
- Google 検索によるグラウンディングは 1 日 100 万クエリの上限 あり（それ以上はサポートに要相談）
まとめ
Google 検索グラウンディングは tools に 1 行足すだけで使えて、ハルシネーション対策としての効果も明確でした。
Next '26 では画像付き Google 検索と Google マップのルート案内がグラウンディングソースに追加され（いずれもプレビュー）、表現の幅がさらに広がっています。
ただし課金単位は世代で異なり、2.5 以前はプロンプトごと、3 系は検索クエリごとです。
3 系では 1 プロンプトから複数クエリが走りうるので、web_search_queries などで実測してから見積もるのが大切だと感じました。
最後まで読んでいただきありがとうございました！！