先に結論
2026年3月の Gemini API 更新は、単なる小さな機能追加ではありません。「モデルに質問する API」から、「複数ツールをまたぐエージェント実行基盤」へ一歩進める更新です。
今回のポイントは3つです。
- built-in tools と custom functions を同じリクエストで組み合わせやすくなった
- tool の実行結果を次の tool に流し込みやすくなった
- Google Maps grounding が Gemini 3 系に広がり、位置情報を含む実装がやりやすくなった
特に重要なのは、アプリ側でゴリゴリ書いていたオーケストレーション処理を、以前より薄くできる可能性があることです。AI エージェント、業務自動化、RAG 連携、社内 API 連携を考えているチームなら、今回の更新は見逃さない方がいいです。
何が発表されたか
Google は 2026年3月17日、Gemini API のツール利用まわりで以下を発表しました。
1. tool combination
これまでは、Google Search や Maps のような built-in tools と、自社バックエンドを叩く custom functions をどう切り分けるかを、アプリ側でかなり丁寧に面倒を見る必要がありました。
今回の更新では、built-in tools と custom functions を同じリクエスト内で扱える方向に進んでいます。たとえば次のような流れです。
- Gemini が Google Search で公開情報を取る
- その結果を踏まえて自社 API を呼ぶ
- 必要に応じてさらに別の tool を呼ぶ
この流れを、以前より自然に1つの対話の中で扱いやすくなったのが大きいです。
2. context circulation
複数ステップの workflow では、最初の tool の結果を次の tool にどう渡すかが地味に面倒です。ここで効くのが context circulation です。
Google の説明では、built-in tool の呼び出し結果と応答をモデルの文脈に保持し、後続の reasoning や tool 呼び出しで参照しやすくする考え方です。
要するに、
- 検索して終わり
- 地図を引いて終わり
- 関数を1回叩いて終わり
ではなく、ツールをまたぐ連続処理を前提にした設計へ寄せてきた、ということです。
3. tool response IDs
地味ですが、実務ではかなり重要です。各 tool call に 一意の ID が付くようになり、非同期実行や並列 function calling で「どの tool 呼び出しに対する応答なのか」を突き合わせやすくなりました。
AI エージェント実装では、賢さより先に デバッグしやすさ が効きます。ここが整理されるのは、プロトタイプより本番運用に効く改善です。
4. Google Maps grounding の拡張
今回の発表では、Google Maps grounding が Gemini 3 ファミリーで使いやすくなった点も見逃せません。
位置情報、店舗情報、移動時間、地理文脈は、実サービスではかなり強い素材です。たとえば以下です。
- 近隣店舗の比較
- 来店導線の提案
- 配送や訪問営業の候補整理
- 地域イベントや施設の案内
- ローカル検索と社内在庫・予約情報の組み合わせ
これまでも似た体験は作れましたが、Maps を grounding として扱いやすくなることで、検索 → 地理情報取得 → 社内データ照合 の流れがかなり組みやすくなります。
なぜ重要か
一言でいえば、エージェントの価値はモデル単体ではなく、ツールをまたいだ処理全体で決まるからです。
2025年までの比較では、どうしても「どのモデルが賢いか」に話が寄りがちでした。しかし実務で詰まるのは、むしろ以下です。
- 検索結果をどう次の処理に渡すか
- 社内 API と外部データをどうつなぐか
- 並列実行の結果をどう対応づけるか
- ログとデバッグをどう見るか
- オーケストレーションをアプリ側でどこまで持つか
今回の Gemini API 更新は、このボトルネックを少し Google 側に寄せてくれる可能性があります。
つまり、モデルの IQ を 5 点上げる話というより、エージェント実装の配管工事を減らす話です。ここは導入コストに直結します。
どんな読者に影響するか
エージェント実装を始める開発チーム
最も影響が大きい層です。built-in tools と custom functions を分離して管理する実装負荷が下がるなら、PoC の速度も本番実装の保守性も改善しやすくなります。
店舗・地理・営業導線を扱う事業者
Maps grounding は、EC よりむしろ 実店舗・営業・移動・予約 を持つ事業に効きます。ローカル検索や最寄り候補の提示を、AI 体験の中に自然に埋め込みやすくなるからです。
OpenAI / Anthropic 中心で比較中のチーム
すでに他社モデルを使っているチームにも影響があります。理由は、今回の更新が「Gemini の出力品質」だけでなく、ワークフロー実装の総コストを比較対象に乗せてくるからです。
関連動向との比較
OpenAI / Anthropic との違いはどこか
OpenAI も Anthropic も、tool use や function calling 自体はすでに重要機能です。ただ、今回の Gemini の更新で目立つのは、Google Search と Google Maps という Google 固有のデータ面の強みを、そのままツール実行体験に寄せていることです。
この差は、単なる API 機能一覧では見えにくいですが、以下のユースケースでは効きます。
- 検索と地理情報を同時に扱う
- 実世界の場所を前提に提案する
- 社内関数と公開情報をまたいで答える
とくに Maps grounding は、汎用 LLM の比較表では埋もれがちですが、ローカル文脈が重要なプロダクトではかなり大きい差になります。
次に見るべき論点
今回の発表を見て終わりにせず、実務では次の論点を確認したいです。
1. 料金と token コスト
tool use が増えるほど、プロンプト設計より 総コスト管理 が重要になります。Search や Maps を含む実行でどこまで料金が膨らむかは、PoC の時点で見ておくべきです。
2. 失敗時の扱い
複数 tool をまたぐほど、1回の失敗が全体フローを壊します。リトライ、fallback、途中結果の保持、監査ログの設計は相変わらず重要です。
3. 観測性とデバッグ性
tool response IDs は良い方向ですが、実運用ではそれだけで十分とは限りません。ログ基盤、トレース、評価基準まで含めて整えられるかが差になります。
4. どこまで Google 依存を許容するか
Search や Maps が強いのは事実ですが、そのぶん設計は Google 依存になります。将来のマルチモデル戦略やクラウド中立性を重視するなら、抽象化レイヤーを残しておく判断も必要です。
どう判断すべきか
結論としては、次の整理がわかりやすいです。
- 検索・位置情報・社内 API をまたぐ体験を作りたい → Gemini を強く再検討する価値がある
- 単純なチャット補助や文章生成が中心 → 今回の更新の優先度はそこまで高くない
- エージェント実装の配線コストに困っている → 今回の更新はかなり重要
- マルチベンダー前提でベンダーロックを避けたい → 採用しても抽象化設計は残したい
モデル性能の派手なベンチマークより、こういう地味な API 更新の方が、実際には導入判断を変えることがあります。
まとめ
Gemini API の今回の更新は、tool combination・context circulation・Maps grounding を通じて、Gemini をエージェント実装向けの基盤として押し上げる更新でした。
重要なのは、「Gemini がまた1つ機能を足した」という話ではなく、検索・地理情報・社内関数をまたぐ実務フローを、以前より少ない配線で組める可能性が出てきたことです。
AI ツール選定でまだモデル単体の精度だけを見ているなら、比較軸を一段上げた方がいいです。これからは、どのモデルが賢いかだけでなく、どの基盤が仕事の流れを最も楽に実装できるか が勝負になります。