Gemini Live API の proactive audio は自発的に喋らない
「AI の側から自発的に喋り続ける」音声エージェントを設計していたとき、Gemini Live API の proactive audio という機能名を見つけて、発話の駆動をこれに任せる前提で設計を組みました。proactive は「能動的な」という意味で、名前だけ見ればモデルが自分から喋り出す機能に読めます。
実装前にリファレンスを確かめると、定義は名前から読める動作と逆でした。
公式リファレンスの定義
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 audio で、常時リスニングの音声エージェントでは確かに重要です。ただし proactive audio が解決するのは「喋りすぎ」の問題で、「喋らない」問題は解決しません。
設計をどう変えたか
私の要件は「AI が主導権を持って喋り続ける」でした。proactive audio ではモデルに喋り出させられないと分かった時点で、テキストキューと proactive audio の扱いを入れ替えました。
- ベースライン: 発話のタイミングはアプリが決める。アプリが進行に合わせてテキストキュー（
clientContent+turnComplete: true）を注入し、モデルはそのキューに応答して喋る（turnComplete: false で送ったテキストは無視される。Gemini Live API にテキストを送っても音声が返らない原因）。この方式の初動遅延は実測 0.6〜1.0 秒（thinking 無効時。Gemini Live API の音声応答が 6 秒遅れる原因は thinking）で、実用域でした - proactive audio の位置づけ: 「喋らせる仕組み」から「マイク経由の環境音に反応しすぎる場合の抑制オプション」へ降格
AI が自発的に喋っているように見える動作は、アプリがテキストキューを送るタイミングで作ります。結果的にこの方式なら発話タイミングを完全に制御でき、要件に合っていました。
モデルの対応状況
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 は抑制に使い、発話はアプリが起こす
- proactive audio の定義は「応答を拒否できる」で、モデルを自発的に喋らせる機能ではない
- AI が自発的に喋り続ける動作を作りたいなら、アプリがテキストキュー（
turnComplete: true）を注入して発話のタイミングを決める。この方式の初動は実測 0.6〜1.0 秒 - proactive audio は常時リスニング構成での「反応しすぎ」対策として使う
- 2.5 Flash Live 系限定（2026-08 時点）。3.1 系への移行計画があるなら proactive audio に頼る部分を少なくしておく
機能名から動作を推測して設計を進めたのが敗因でした。API リファレンスの定義文はたった 2 文で読むのに 1 分もかからないので、設計に組み込む前にその 1 分を使うべきでした。