Gemini 3.8 Live — 「話しながら考える」を1モデルに畳み込んだ音声API

5日差で出た2つの全二重音声モデル

2026年9月15日、Googleが Gemini 3.8 Live と Gemini 3.8 Live Extended Thinking を公開しました。 Gemini API・Google AI Studio・Gemini Enterprise（プライベートプレビュー）・Search Live・Gemini Live・Google Workspace へ同時に展開されています。

タイミングが面白いところで、その5日前の9月10日にOpenAIが GPT-Live-1 をAPI公開したばかりでした。 全二重（聞きながら話す）音声モデルのAPIが1週間のうちに2つ揃ったわけですが、この2つは「推論をどこに置くか」の設計が真逆です。 そしてその差は、そのまま課金構造と、あなたが書くイベントハンドラの形に効いてきます。

本記事では、Gemini 3.8 Live が何を変えたのかを「2モデルの棲み分け」「非同期推論が壊す前提」「非同期function calling」「課金構造」の4点で整理します。

ここまでの流れ

2つのモデルをどう使い分けるか

まず名前が紛らわしいので整理します。今回出たのは以下の2つです。

非同期推論 — 「考え終わってから喋る」をやめた

Extended Thinking の一番の売りは、推論と発話を同時に走らせることです。 従来の音声エージェントは、複雑な質問が来ると次の順で固まっていました。

1. ユーザーの発話終了を検出
2. 推論（thinking）を開始 — ここで音声が完全に止まる
3. 推論が終わったら音声生成を開始

2の間、ユーザーは無音を聞かされます。数秒の沈黙は電話越しだと「切れた？」と思われる長さで、 これが音声エージェントに重い推論を載せられなかった最大の理由でした。

Extended Thinking はこの2をバックグラウンドに逃がします。 推論を回しながら「少し確認しますね」といった繋ぎの発話を出し、 推論が終わった時点で会話に合流させる。人間が電話口でやっていることと同じ構造です。

sequenceDiagram
    participant U as ユーザー
    participant M as Extended Thinking
    participant T as 外部API
    U->>M: 先週の注文どうなってますか
    M-->>U: 確認しますね
    M->>T: check_order_status を非同期発行
    M->>M: バックグラウンドで推論継続
    U->>M: あと住所も変更したいです
    M-->>U: 住所変更も承ります
    T-->>M: 注文は発送済み
    M-->>U: 注文は昨日発送済みでした

turnComplete が意味を失う

ここが移行時に一番刺さるポイントです。公式ドキュメントは明確にこう書いています。

非同期推論を使うモデルでは、turnComplete: true はもはやモデルがアイドル状態であることを意味しません。

従来の Live API 実装では、turnComplete を「モデルの1ターンが終わった」という状態遷移のトリガーに使うのが定石でした。 UIのマイクアイコンを戻す、ログを1件確定する、次の処理をキックする——これらを turnComplete に紐づけていると、まだ裏で推論が走っている最中に「終わった」と判定してしまいます。

thinking_config の指定

推論の深さは thinking_level で3段階（low / medium / high）から選びます。 通常のGeminiにある minimal は Extended Thinking では選べません。include_thoughts を立てると思考サマリーを受け取れるので、デバッグ時は有効にしておくと挙動が追いやすくなります。

from google import genai
from google.genai import types

# proactive audio / affective dialog は v1beta が必要
client = genai.Client(http_options={'api_version': 'v1beta'})

config = types.LiveConnectConfig(
    response_modalities=["AUDIO"],
    thinking_config=types.ThinkingConfig(
        thinking_level="high",      # low / medium / high（minimalは不可）
        include_thoughts=True,      # 思考サマリーを受信（デバッグ用）
    ),
    enable_affective_dialog=True,   # ユーザーのトーンに応じて話し方を変える
    realtime_input_config=types.RealtimeInputConfig(
        automatic_activity_detection=types.AutomaticActivityDetection(
            silence_duration_ms=600,   # 推奨レンジは 500〜800ms
        )
    ),
)

async with client.aio.live.connect(
    model="gemini-3.8-live-extended-thinking",
    config=config,
) as session:
    ...

非同期 function calling と3つのスケジューリング

推論だけを非同期にしても、ツール呼び出しで会話が止まったら意味がありません。 そこで Gemini 3.8 Live では function calling も behavior: NON_BLOCKING に対応しました。 在庫照会やCRM問い合わせのように数秒かかる関数を、会話を止めずに投げられます。

check_order_status = {
    "name": "check_order_status",
    "description": "注文ステータスを問い合わせる。応答に数秒かかる",
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {"type": "string"},
        },
        "required": ["order_id"],
    },
    # これが無いと、関数が返るまで会話全体がブロックされる
    "behavior": "NON_BLOCKING",
}

非同期にした場合、結果が返ってきたときに「それをどう会話に差し込むか」を決める必要があります。 これが scheduling で、3種類あります。

function_response = types.FunctionResponse(
    name="check_order_status",
    id=fc.id,
    response={
        "result": "発送済み / 追跡番号 1234",
        "scheduling": "INTERRUPTED",   # SILENT / WHEN_IDLE / INTERRUPTED
    },
)
await session.send_tool_response(function_responses=[function_response])

課金構造 — GPT-Live-1 との決定的な違い

ここが今回いちばん実務に効く差分です。両者の価格を並べます。

Gemini 側は3モデル（3.8 Live / 3.8 Live Extended Thinking / 3.1 Flash Live Preview）が横並びの同一価格で、 thinking トークンは出力価格に含まれます。 つまり Extended Thinking に切り替えても単価は変わらない——ただしthinking_level を high にすれば出力トークンが増えるので、実コストは推論の深さに比例して上がります。 値上げではなく従量で効いてくる形です。

対して GPT-Live-1 の $0.05/分は音声層だけの値段です。 GPT-Live は「対話を回す層」と「重い推論を別モデルに委譲する層」の2層構成なので、 実際の請求は音声層 + バックエンドモデルのトークン + エージェントハーネスの3段重ねになります。 $0.05 と $0.023 を並べて「倍以上違う」と読むのは正しくなく、実際の差はもっと開きます。

ベンチマーク

Google が示した数値は以下のとおりです。音声系のベンチマークは評価軸がまだ固まりきっていないので、 順位そのものより「どの軸で測られているか」を見るほうが実務では役に立ちます。

注目すべきは τ-Voice-banking の 35.1% です。 総合品質で1位、音声推論で97.7%を出すモデルが、実業務ドメインのタスク完遂では3分の1しか通らない。 「会話は自然だが業務は任せきれない」という現在地を、これ以上ないほど正直に示している数字だと思います。 自動化率を見積もるなら、総合スコアではなくこちら側を基準に置くべきです。

97言語の自動検出

Gemini 3.8 Live は97言語を自動検出し、会話の途中で切り替えます。 「日本語で話していた顧客が固有名詞だけ英語で言う」「途中から英語に切り替える」といったケースで、 言語設定を明示しなくても追随します。

実装前に知っておきたい制約

• セッション長: 音声のみのセッションは15分が上限。ネイティブオーディオ系のコンテキストは128kトークンまで（それ以外のモデルは32k）。長時間の通話にはセッション再開の実装が要ります。
• v1beta 指定: proactive audio と affective dialog は api_version: "v1beta" でないと有効になりません。設定を書いたのに効かない場合はまずここを疑ってください。
• 非対応機能: code execution・caching・file search・構造化出力・画像生成はいずれも非対応。構造化出力が無いので、関数の引数スキーマ側で構造を担保する設計になります。
• 音声フォーマット: 入力は 16kHz・16bit PCM・リトルエンディアン、出力は 24kHz。画像は 1FPS 以下のJPEG。
• VAD: 自動VADは既定で有効。silenceDurationMs の推奨レンジは 500〜800ms。手動制御にする場合は disabled: True にして activityStart / activityEnd を自前で送ります。
• ホスト提供のみ: セルフホストの選択肢はありません。データ所在地が要件になる案件では最初に確認が必要です。

接続まわりは LiveKit・Pipecat・Agora・Fishjam・LangChain・Vercel・Vision Agents などが対応済みなので、 WebSocket を自前で握るより、既存のパイプラインに 3.8 Live を差すほうが早いケースが多いはずです。

まとめ — 選ぶ基準

2つのアプローチは優劣ではなく、推論の置き場所をどちらに寄せたいかの違いです。

実装面でひとつだけ持ち帰るとすれば、turnComplete を状態遷移のトリガーに使わない、これに尽きます。 非同期推論は体験を大きく改善する一方で、「ターンが終わった」という前提を静かに壊します。 既存の Live API 実装を 3.8 系に載せ替えるなら、まずイベントハンドラを読み直すところから始めてください。