Gemini Live API の tool use は「呼んだ後を誰がつなぐか」が本題

要点

要点まとめ

この docs の一番大事な点は、AI が『道具を使いたい』と言っただけでは処理は終わらず、実行して結果を戻し、会話をつなぐ責任は client 側に残ると示していることだ。
争点は tool use の有無ではなく、その後の待ち時間、再送、失敗時の戻し方まで含めた会話運用にある。
Google は model ごとの対応差も明記しており、その場で終わる呼び出ししかできない model と、非同期も扱える model を分けている。
読後にやるべきことは tool を増やすことではなく、『誰が実行し、誰が結果を返し、会話をどこで再開するか』を図にすることだ。

読解

何が変わったのか

docs は Live API を Gemini のリアルタイム対話向け API として扱い、その中で Search と Function calling を使えると説明しています。ただし重点は『使えること』ではなく、model ごとに `synchronous` 呼び出しだけか、`asynchronous` 呼び出しも持つかを分けて見せている点です。さらに `toolCall` はモデルが『この道具を使いたい』と知らせるイベントで、実際の tool 実行は client 側責務です。実行後に `send_tool_response` 相当の返答を戻して会話を再開する manual loop を前提にしており、realtime tool use を音声 UX の一部ではなく state machine として前面化したのが変化点です。

日本の文脈

なぜ重要か

日本語圏では voice agent の話が『自然にしゃべれるか』に寄りがちですが、実際に壊れるのは tool call 後です。待ち時間をどう埋めるか、失敗した時に何を言うか、再送で二重実行しないかは、会話品質そのものに直結します。この docs は、その責任をぼかさない点に価値があります。prompt や音声品質より前に、tool call から tool response までの流れを誰が持つかを決めないと、本番では会話がつながりません。

技術ポイント

技術的ポイント

Live API は Gemini のリアルタイム対話向け API で、Search と Function calling を使えるが、model ごとの対応差がある。
`toolCall` は『モデルが道具を使いたい』という合図で、実際の呼び出しと結果回収は client 側責務のままだ。
`send_tool_response` は client が tool 実行結果を会話へ戻す処理で、ここで会話を再開する。
`synchronous` はその場で順に完結させる呼び出し、`asynchronous` は別に進行管理が必要な呼び出しで、model により両方使えるとは限らない。
Search と custom function を併用できるため、tool orchestration と待機中 UX の設計が普通の request-response より重要になる。

用語

英日キーワード

英語	日本語	補足
Live API	Live API	Gemini のリアルタイム対話向け API。会話と tool 実行のつなぎ目まで設計対象になる。
toolCall	ツール呼び出し要求	モデルが外部 tool 実行を求めるイベント。実行そのものは client 側責務のまま残る。
send_tool_response	ツール応答返却	client が tool 実行結果を会話へ戻す処理。ここがないと対話は途中で止まりやすい。
synchronous	同期型	その場で順に完結させる呼び出し。待ち時間の扱いが UX に直結する。
asynchronous	非同期型	実行完了を待たずに進行管理が必要な呼び出し。再送や状態更新の設計が要る。
state machine	状態機械	会話と tool 実行の進み方を管理する流れ。voice agent では曖昧にすると壊れやすい。

試す

試すなら

tool call 発生後の client 側処理を図にし、誰が API を叩き、誰が結果を返し、どこで会話を再開するかを固定する。
自分の model が synchronous だけで足りるのか、asynchronous の設計まで要るのかを先に確認する。
音声 UI なら、tool 待ち中の一言や待機音を先に設計する。
Search と custom function を同時に使うなら、どちらの結果を優先し、失敗時にどう言い換えるかを決める。

注意

注意点

Live API で tools が使えても、tool execution 自体が自動で安全になるわけではない。権限、再試行、二重実行防止は別設計だ。
model ごとに synchronous / asynchronous の対応差があるため、一つのサンプルを他 model にそのまま当てはめるのは危険だ。
`Published date` はページ上に見当たらず、ここでは `Last updated 2026-06-01 UTC` のみ確認できた。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。