Gemini Provider Tools

参照元: LiveKit Agents Documentation ロードマップ: 学習ロードマップ

対象ページ: https://docs.livekit.io/agents/models/llm/gemini/#provider-tools

What（何についてか）

Google GeminiをLiveKit Agentsで利用する際のProvider toolsを整理する。対象となるツールは GoogleSearch、GoogleMaps、URLContext、FileSearch、ToolCodeExecution の5種類である。これらはモデルサーバ側で実行されるビルトイン機能であり、エージェントコード内のFunction toolsとは実行責務が異なる。

Why（なぜ必要か）

Gemini連携ではツールの種類だけでなく、APIモードごとの制約を理解しないと設計が破綻する。特に重要なのは、Provider toolsとFunction toolsの同時利用可否がモード依存である点である。Realtime要件、開発速度、制御性のバランスを判断するために、この制約を先に把握する必要がある。

How（どう動くか）

GeminiのProvider toolsは google.LLM(...) と tools=[...] の組み合わせで有効化する。旧 _gemini_tools パラメータは廃止され、Provider tools方式へ統一されている。FileSearch は file_search_store_names が必須であり、他ツールは用途に応じてオプションを指定する。

また、利用モードに応じた制約がある。

graph TD
    A[Gemini integration] --> B[Gemini Live API]
    A --> C[Gemini text models]
    B --> D[Provider tools + Function tools 併用可]
    C --> E[どちらか片方のみ]

この制約により、実装時は「機能要件」より先に「推論モード」を決める必要がある。

Key Concepts

用語	説明
Provider tools	モデル提供側サーバで実行される組み込みツール。Geminiでは5種を提供。
Function tools	エージェントコード側で定義する関数ツール。ロジック制御に向く。
Gemini Live API	Provider toolsとFunction toolsの併用が可能なモード。
Gemini text models	Provider toolsまたはFunction toolsのどちらか片方のみ利用可能。
FileSearch	ファイルストア検索ツール。file_search_store_names が必須。

実装メモ

最小構成例（Python）:

from livekit.plugins import google
 
agent = MyAgent(
    llm=google.LLM(model="gemini-2.5-flash"),
    tools=[google.tools.GoogleSearch()],
)

制約吸収の設計方針として、上位では「必要能力」を宣言し、下位でProvider tools/Function toolsへの振り分けを行うアダプタ層を設けると、APIモード差分を局所化できる。

一言まとめ

Gemini Provider toolsは強力だが、Live APIとtext modelで併用条件が異なるため、ツール選定より先に推論モードを決める設計が必要である。