Gemini APIは、Google Searchなどのbuilt-in toolと開発者が定義したcustom functionを一つのinteractionで併用できるようになった。modelが外部情報でgroundingした後に社内APIを呼ぶ、といったagent workflowを単一のcontext historyで構成できる。一方、tool間でdataと権限が連鎖するため、個別toolの安全性だけでは不十分である。

何が変わったか

Geminiはbuilt-in tool callとcustom function callのcontextを保持してmodelへ公開し、同じinteractionで両者を組み合わせられる。公式guideはgoogle_searchとgetWeather custom functionを例示している。機能はpreviewでGemini 3 model向けに提供され、Python例では2.0.0より新しいSDKが必要とされる。

変更前後の差

従来は検索groundingと業務API呼び出しをapplication側で別requestとして接続し、contextを手動で組み立てることが多かった。新方式ではmodelがtool sequenceを判断できる。反面、検索結果に含まれるuntrusted textがcustom functionのargument生成へ影響するため、prompt injectionと権限昇格の境界が近くなる。

誰に影響するか

Gemini 3でresearch agent、support agent、travel・commerce assistant、社内knowledge agentを作るteamが対象である。Google Search、URL Context、Code Executionなどのbuilt-in toolと、CRM、ticket、order、databaseなどcustom functionを組み合わせる構成で影響が大きい。

期限

強制移行期限はない。preview機能のため、productionのcritical writeへ直接使わず、read-onlyまたはapproval付きworkflowから導入する。

必要な対応

custom functionのJSON schemaを狭くし、server側でauthorizationとvalidationを再実行する。built-in tool結果を信頼済みdataとして扱わない。tool call回数、総実行時間、cost、同一function再呼び出し回数に上限を設ける。write operationにはhuman confirmationまたはpolicy engineを入れる。

実装・移行手順

  1. built-inとcustom toolの責任範囲を分ける
  2. custom functionをread-onlyから作る
  3. argument schemaとserver validationを定義する
  4. tool call historyをstructured logへ保存する
  5. injectionを含む検索結果でred-team testを行う
  6. loop・timeout・cost上限を設定する
  7. write toolへconfirmationを追加する
  8. preview仕様変更を吸収するadapterを置く

失敗しやすい点

model生成argumentをそのまま実行する、検索結果をsystem instruction相当として扱う、tool nameを広すぎる権限へ紐付ける、call loop上限を設けない、SDK・model制約を確認しない、といった問題が起きやすい。

リスク

prompt injectionからの不正function call、個人情報やsecretのtool間流出、重複write、cost増加、preview breaking changeがある。built-in toolのcitationがあっても、custom functionへ渡す値の正当性は別途検証する必要がある。

評価方法

  • task成功率
  • tool sequence正解率
  • invalid argument率
  • authorization拒否率
  • tool loop発生率
  • human confirmation拒否率
  • 1task当たりtool call数とcost
  • injection test突破率
  • p95 latency

ロールバック

combined modeをfeature flagで止め、検索requestとcustom function実行をapplication側の二段階orchestrationへ戻す。write toolをread-onlyへ降格し、未完了transactionをidempotency keyで確認する。SDK更新が原因ならlockfileとadapterをrevertする。

編集部分析

tool combinationはagentの実装量を減らすが、信頼境界を消すものではない。むしろ検索というuntrusted inputと業務writeをmodel reasoningで直結するため、server-side policyの重要性が増す。modelへ任せるのは順序選択であり、最終権限判断ではない。

実務チェックリスト

  • [ ] Gemini 3とpreview条件を確認した
  • [ ] SDK versionを固定した
  • [ ] custom function schemaを狭くした
  • [ ] server側で再認可する
  • [ ] tool loopとcost上限を設定した
  • [ ] injection testを実施した
  • [ ] write operationへconfirmationを入れた

一次情報