1回のAPIコールで「検索→予約」を完結させる——Gemini APIのツール統合が変えること

この記事のポイント

エージェントを設計するときに一度は直面する問題がある。「リアルタイムのウェブデータを取得してから、そのままバックエンドのAPIを叩きたい」——なのに、ビルトインツールとカスタム関数を同じリクエストに混ぜられない。だからLLMの外側で手動オーケストレーションを書くことになる。

Googleが2026年3月に発表したGemini APIのツールアップデートは、その前提を覆す内容だった。「ツールコンテキストサーキュレーション」という仕組みにより、ビルトインツール（Google検索、Googleマップ等）とカスタム関数呼び出しを1回のAPIコールで組み合わせられるようになった。Gemini 3モデル（Flash Preview / Pro Preview）からの対応で、Googleマップグラウンディングも同モデル向けに解禁されている。

従来の問題：ビルトインとカスタムは分離されていた

Gemini APIには従来から強力なビルトインツールが存在する。Google検索によるリアルタイム情報取得、Googleマップでの場所・経路情報グラウンディング、URLコンテキスト、ファイル検索、コード実行。これらはモデルが内部で自律的に呼び出せる機能だ。

一方、カスタム関数呼び出し（function calling）は開発者がAPIレスポンスを受け取り、クライアント側で実行して結果を返すフローを取る。問題はここにあった。両者を同じリクエストに混在させることができなかった。

たとえば「今日の天気を調べて、条件を満たすなら会場を予約する」というタスクを考えると、従来は最低2回のAPIコールが必要だった。1回目でGoogle検索を使って気象データを取得し、その結果をコンテキストに手動で積み直してから、2回目でカスタムの予約APIを叩く——この手作業の連携が、エージェント設計の複雑さを増す原因になっていた。

ツールコンテキストサーキュレーションの仕組み

新機能の核心は「コンテキストの循環（circulation）」にある。

ビルトインツールがサーバー側で実行された際、そのツール呼び出しとレスポンスを会話コンテキストに保持し、後続のステップ（カスタム関数呼び出しを含む）がそのデータにアクセスして推論できる仕組みだ。モデルはツールを呼ぶ順番を自分で決め、ビルトインツールで得た文脈をそのままカスタムツールに引き渡す。

実装側で必要な変更は2点だけだ。

response = client.models.generate_content(
    model="gemini-3-flash-preview",
    contents="今日の天気に合った会場を予約して",
    config=types.GenerateContentConfig(
        tools=[types.Tool(
            google_search=types.ToolGoogleSearch(),
            function_declarations=[book_venue]  # カスタム予約関数
        )],
        include_server_side_tool_invocations=True  # ← これが鍵
    )
)

include_server_side_tool_invocations=True を立てることでコンテキストサーキュレーションが有効になり、function_declarations にカスタム関数を渡すだけでビルトインツールと共存させられる。

レスポンスには toolCall（サーバー側ツールの実行記録）と functionCall（クライアント側で処理すべきカスタム関数）が混在して返ってくる。さらに各パーツには thought_signature という暗号化された文脈識別子が埋め込まれており、これを次ターンでそのまま返すことでモデルが文脈を復元する。この署名は省略できないため、レスポンスパーツをそのまま次リクエストのコンテンツに積む実装が求められる。

Googleマップグラウンディングの対応モデル拡大

同タイミングで、Googleマップグラウンディングが Gemini 3 モデルに対応した。

Googleマップグラウンディングは、モデルが場所情報・営業時間・経路・ローカルビジネスデータといったリアルタイムな地理空間データにアクセスできる機能だ。従来は一部のモデルに限られていたが、Gemini 3 Flash Preview / Gemini 3 Pro Preview で使えるようになった。

ツール統合との組み合わせが自然に映る。たとえばGoogle検索でイベント情報を取得し、Googleマップで会場の場所と経路を確認してから、カスタムのチケット予約APIを叩く。このフローを1リクエストの中でモデルが自律的に構成できる。開発者が書くオーケストレーションコードの量が、設計方針によっては大幅に削減できる。

実用で意識すべき制約

便利な機能だが、いくつかのハードルを把握しておく必要がある。

対応モデルはGemini 3系のみ。Gemini 1.5 Pro / Flash といった旧モデルには適用されない。プロダクションで使う場合、Gemini 3モデル（現時点ではプレビュー段階）への移行コストを考慮する必要がある。

ツール選択モードは VALIDATED のみ。カスタム関数呼び出しで使える AUTO モード（モデルが自由にツールを選ぶ）は現時点で非対応だ。どのツールを使うか制御するには VALIDATED モードを明示的に設定する。

thought_signature は必ず保持する。各レスポンスパーツに埋め込まれたこの識別子を次のリクエストで渡し忘れると、コンテキストが断絶してモデルが文脈を失う。特にストリーミングで実装する場合は注意が必要だ。

また、system_instruction やカスタム関数の説明文に位置情報・時間情報を含めると、ビルトインツールの動作と干渉するケースがあるとドキュメントは注記している。ビルトインツール側でその情報を取得させる設計にするか、関数定義側の記述を整理するかで対応できることが多い。

エージェント設計への影響

この機能が面白いのは、「モデルの内側でオーケストレーションが完結する」という設計思想にある。

従来のエージェント設計では、LLM呼び出しと外部ツール実行を繋ぐ「グルーコード」をアプリケーション層で書くことが多かった。検索結果を整形してコンテキストに積む、複数ツールの呼び出し順を管理する、エラー時のリトライを組む——こうした処理をモデルに委ねられるなら、アプリ側のコードはシンプルになる。

ただし、モデルに委ねることで「何をどの順番で呼んだか」のトレーサビリティが下がる面もある。デバッグ用に新設された**ツールコール識別子（id）**は、並列関数呼び出し時やマルチステップの非同期処理でどのレスポンスがどの呼び出しに対応するかを追跡するために使う。本番実装ではこの ID をログに残す設計を最初から組み込んでおくことを勧める。

Vercel AI SDKでも @ai-sdk/google でこの機能のサポートが検討されており（Issue #13911）、エコシステム側の対応も進み始めている。