Gemini Live API の proactive audio は自発的に喋らない
「AI の側から自発的に喋り続ける」音声エージェントを設計していたとき、Gemini Live API の proactive audio という機能名を見つけて、発話の駆動をこれに任せる前提で設計を組みました。proactive（能動的な）audio です。名前だけ見れば、モデルが自分から喋り出す機能に読めます。
実装前の事実確認で、定義が逆であることが分かりました。
公式リファレンスの定義
Live API の WebSockets リファレンスの proactivity.proactiveAudio の定義はこうです（2026-08 時点）。
If enabled, the model can reject responding to the last prompt. For example, this allows the model to ignore out of context speech or to stay silent if the user did not make a request, yet.
有効にすると、モデルは直前の入力への応答を拒否できるようになります。文脈外の音声を無視したり、まだ何も頼まれていないなら黙っていられる。capabilities ガイドの表現も同じ向きです。
When this feature is enabled, Gemini can proactively decide not to respond if the content is not relevant.
つまり proactive audio は「喋らせる」機能ではなく、「黙る自由」を与える機能です。proactive なのは発話ではなく、「応答しない」という判断の方でした。
既定のモデルは「入力が来たら必ず何か応答する」動作です。マイクを開きっぱなしにする構成では、環境音や独り言にまで律儀に応答してしまう。それを抑えるのがこの機能で、常時リスニングの音声エージェントでは確かに重要です。ただし解決するのは「喋りすぎ」の問題であって、「喋らない」問題ではありません。
設計をどう変えたか
私の要件は「AI が主導権を持って喋り続ける」でした。proactive audio がその駆動源にならないと分かった時点で、優先順位を反転しました。
- ベースライン: 発話タイミングの主導権をアプリ側に置く。アプリが進行に合わせてテキストキュー（
clientContent+turnComplete: true）を注入し、モデルはそれに応答する形で喋る。この方式の初動遅延は実測 0.6〜1.0 秒（thinking 無効時）で、実用域でした - proactive audio の位置づけ: 「喋らせる仕組み」から、「マイク経由の環境音に反応しすぎる場合の抑制オプション」へ降格
「自発的に喋っているように見せる」のは、モデルの機能ではなくアプリの演出で作る、という整理です。結果的にこの方が発話タイミングを完全に制御できるので、要件には合っていました。
モデルの対応状況
もうひとつ確認しておくべき点があります。proactive audio（と affective dialog）は 2.5 Flash Live 系限定です。capabilities ガイドのモデル比較では、gemini-3.1-flash-live-preview は proactive audio / affective dialog ともに Not supported と記載されています（2026-08 時点）。
将来 3.1 系に移行する予定があるなら、proactive audio を設計の中心に据えること自体がリスクになります。私のケースでは「抑制オプション」に降格していたので、移行の障害にはなりませんでした。
この構成で気をつけること
- proactive audio は「自発的に喋る」機能ではない。定義は「応答を拒否できる」。向きが逆
- 「AI から自発的に喋り続ける」を作りたいなら、発話の主導権はアプリに置く。テキストキュー駆動（
turnComplete: true）で実測 0.6〜1.0 秒の初動が出る - proactive audio は常時リスニング構成での「反応しすぎ」対策として使う
- 2.5 Flash Live 系限定（2026-08 時点）。3.1 系への移行計画があるなら依存を軽くしておく
機能名から動作を推測して設計を進めたのが敗因でした。API リファレンスの定義文はたった 2 文で、読むのに 1 分もかかりません。設計に組み込む前にその 1 分を使うべきでした。