Gemini Agentとは？Google AI Agentがツール・API・関数を呼ぶ仕組み

最終更新は 2026年8月18日。技術的な記述は Google の Managed Agents（Gemini Agent）、Function calling、Using Tools with Gemini API で確認しています。

症状：資料に Gemini、Agent、Tools、Function calling が混在し、Interactions を使うのか自前ループなのか判断できない。
最短の切り分け：「モデルが呼び出しを提案した」ことと「副作用を誰が実行するか」を分ける。組み込みツールは Google 側、カスタム関数は function_result を返すまで自前です。

対象読者は、注文や社内 API に Google AI Agent を繋ぐバックエンド、自前 Agent Loop と Managed Agents を比較するアーキテクト、会話はできるが安全に DB へ書けない基盤チームです。

Gemini Agent が指す三つの層

会議で同じ言葉が三層を指します。混ぜると権限設計と障害対応が逆になります。

第一層は Gemini モデルです。関数スキーマを渡すと、自然文ではなく構造化 function_call を出せます。これは「何を呼ぶべきか分かるか」の話であり、DB パスワードを渡す話ではありません。

第二層は Gemini API のツールです。公式は、ターンや Live セッションでモデルが要求できる能力として、Search、Code Execution、URL Context、および独自 Function Calling をまとめています。Tools ドキュメントを参照してください。

第三層が製品としての Gemini Agent / Managed Agents です。システム指示、既定ツール、リモート MCP、カスタム関数、ファイル、AGENTS.md を ID 付きエージェントに固め、Interactions API で呼びます。既定は code_execution、google_search、url_context で、相互作用単位で上書きできます。Building Managed Agents

一回の構造化参照だけで足りるなら Function calling で十分です。サンドボックス、検索、コード実行、MCP、再利用設定が必要なら Managed Agents に上げます。Agent という名前だけで業務ルールをプロンプトに流し込まないでください。

ツール・API・関数の役割分担

• ツールはモデルに見せるカタログ。ホスト側ツールは Google が実行し、カスタムは宣言だけです。
• APIは業務 HTTP と照会。秘密はモデルに渡さず、自前サービスが正式に認証します。
• 関数はローカルコードやキュー投入。JSON Schema で宣言し、id で結果を突き合わせます。

公式の Function calling 用途は「行動」「知識の補強」「能力拡張」です。最終回答の形だけ縛る Structured Outputs とは別物です。中間ホップで自社システムに触るなら Function calling を使います。Function calling ガイド

ローカル Agent がモデルに届かないときは、スキーマより先に接続を疑います。Prime Agent Ollama 2026：接続障害の切り分け と同じ順で、まず伝送を証明してください。長時間の検証ノードが必要なら Mac mini M5 は待つべき？いつ買うと一番お得か の判断材料と、レンタル Mac の比較も併せて見てください。

関数呼び出しの一周

関数名が出た時点を成功としないでください。公式フローは五段です。

1. 名前・説明・JSON Schema を宣言し、呼んではいけない条件も書く。
2. ユーザー入力と tools を interactions.create または generateContent に送る。
3. モデルはテキストで答えるか、id と arguments 付き function_call を返す。
4. 型検証、認証、タイムアウト、冪等キーのあと、本物の API を叩く。カスタムコードはモデルが走らせません。
5. 同じ id で function_result を返し、必要なら previous_interaction_id を付けます。

{
  "type": "function",
  "name": "get_order_status",
  "description": "注文番号で履行状態を照会する。作成や取消には使わない。",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "description": "OD-20260818-001 のような業務番号"}
    },
    "required": ["order_id"]
  }
}

モデル引数を SQL やシェルに直結しないでください。スキーマ検証、内部 DTO、サービスアカウント、という順です。ストリームの arguments は JSON が揃ってから実行します。欠けた order_id で本番を叩かないでください。並列呼び出しは在庫と配送を同時に取れますが、合成呼び出し（地点のあと天気）は前段の結果待ちです。

組み込みツールとカスタム関数

「モデルがツールを要求した」ことを「サーバーが完了した」と誤解するのが典型障害です。組み込みは Google 管理で、対応する function_result が自動で付きます。カスタムはアプリ側です。

Managed Agents ではステップ照合が使われます。組み込みはサーバー完了、未実行のカスタムは requires_action になります。既に結果がある call_id を再実行すると、決済では事故です。元の call、実行ログ、result、interaction 状態の四つを残してください。

モード、MCP、合成呼び出し

tool_choice は auto / any / none、プレビューの validated です。天気照会を any にするのは妥当でも、本番削除を承認なしの any にしてはいけません。リモート MCP は name と url で外部ツールサーバーを足します。認証なしの公開 MCP をモデルの自制心に頼らないでください。Gemini 3 は同一 interaction で組み込みとカスタムを混ぜられ、previous_interaction_id が文脈を運びます。ログは HTTP 一発ではなく interaction 単位で保存します。

本番書き込み前の制御

1. 読み取りと書き込みを別関数にし、見せたくない能力は Schema から外す。
2. 作成・課金・メールは function_call.id または独自 request-id で冪等。
3. タイムアウトは型付きエラーを返し、空文字で再試行させない。
4. 返すのは状態・要約・次のヒントだけ。
5. ホップ数、経過時間、token に上限を置き、超過は人手へ。
6. スキーマ版、モデル版、引数、結果ハッシュを残して再現可能にする。

業務システムへ既に書いた可能性があるなら、冪等表を見てから動きます。「もう一度モデルに任せる」は禁止です。画面が二重表示しているだけなら集約を直し、プロンプトは触りません。

最終形だけ縛るなら Structured Outputs、自社 API に触るなら Function calling、サンドボックスと MCP と再利用設定が要るなら Managed Agents。三つを一つの製品に載せても、実行責任はアーキテクチャ図に書いてください。

スリープするノート PC で Gemini Agent を回すと、requires_action の戻りが消え、interaction ログが切れます。検証を繰り返すなら Kvmkit の Mac レンタル の方が個人マシンを占有するより安定します。条件は 日本語トップ でも確認できます。USB や専用網が必須なら自前機器を残してください。