何が発表されたか
Googleは音声認識モデル「Gemini 3.5 Transcribe」を投入しました。85を超える言語を自動で認識し、話者が発する「えーと」といったフィラー語を取り除き、言い間違いを訂正し、テキストの整形までモデル自身が行います。精度は単語誤り率（WER）でストリーミング音声4.0%、録音音声2.6%。遅延は前モデルのChirp 3から70%下がりました。
提供形態は2つのインターフェースに分かれます。低遅延のリアルタイム処理を担うLive API（gemini-3.5-transcribe-live）と、録音音声を話者の割り当て（誰が話したか）とタイムスタンプ付きで処理するInteractions API（gemini-3.5-transcribe）です。Google AI StudioとGemini Enterprise Agent Platformから利用でき、AndroidのGboardには「Rambler」として、macOS版Geminiアプリにも既に組み込まれています。Chrome対応も近く予定されています。
なぜ重要か：ASRが「部品」から「入り口」に変わる
注目すべきは精度の数字そのものより、後処理がモデル内部に取り込まれた点です。これまで音声を業務で使うには、ASR（音声認識）で文字を起こし、別のLLMでフィラー除去・整形・要約をかける二段構成が定番でした。Gemini 3.5 Transcribeはその整形工程を吸収しています。つまり「ASRベンダー＋LLMベンダー」という組み合わせで作っていた社内パイプラインの中間層が、丸ごと不要になり得るということです。
さらにfunction callingへの対応が意味を持ちます。文字起こし中に画像生成やWeb検索といったタスクを他のGeminiモデルへ受け渡せる。これは「音声を文字にする部品」ではなく、「音声がエージェントの入力チャネルになる」という位置づけの変更です。会議中の発話がそのまま検索や資料生成のトリガーになる設計が、モデル1つで組めることになります。
85言語自動判別と70%の遅延削減が効く場面
言語を事前指定せずに85言語超を認識できる点は、コールセンターや小売の接客現場のように、話者の言語が事前にわからない環境で効きます。従来は「言語判定 → 該当ASRへルーティング」という設計が必要でしたが、その分岐が消えます。
遅延70%削減は、リアルタイム字幕・音声UI・通話中のリアルタイム支援といった、応答速度が体験そのものを規定する用途の実用ラインを押し上げる数字です。逆に言えば、遅延を理由に見送ってきた社内の音声企画は、前提条件が変わったので再評価すべきタイミングにあります。
二つのAPIの使い分けが設計判断になる
Live APIとInteractions APIの分離は、単なる機能差ではなく設計上の選択を求めています。リアルタイム性を取るならLive API、監査・議事録・コンプライアンス用途で「誰がいつ何を言ったか」を残すならInteractions APIの話者割り当てとタイムスタンプが必要です。両方を要件に持つ業務（例：通話のリアルタイム支援＋事後の記録保全）では、同一モデル系列内で二系統を併用する構成が現実解になります。
💼 事業会社視点：これは自社にどう効くか
最も直接影響を受けるのは、議事録・文字起こし・音声要約を機能の中心に据えるSaaSと、そこを受託で作ってきた開発会社です。フィラー除去や整形といった「作り込みで差別化していた後処理」がモデル標準機能に吸収されたため、その部分の付加価値は急速に薄れます。役員が今問うべきは「自社の音声機能のうち、モデル側に吸収されない部分はどこか」です。業界固有の用語辞書、社内システムとの連携、法定保存やアクセス権限といった運用要件——差別化はこちら側に移ります。
日本企業の一般的な事業部門にとっては、85言語超の自動認識と70%の遅延削減が、インバウンド接客・海外拠点との会議・多言語カスタマーサポートの内製ハードルを下げます。特にECでは、越境問い合わせの音声対応を「外注の多言語オペレーター」から「モデル＋日本語オペレーター」に組み替える検討余地が出ます。
動くべきは3点です。第一に、既存のASR契約とLLM後処理の二段構成を棚卸しし、重複コストを特定すること。第二に、WER 2.6%という数字を鵜呑みにせず、自社の業界用語・方言・電話回線品質で実測すること。第三に、function callingによる音声起点のエージェント設計を、既存業務フローのどこに刺すか小さく検証することです。ベンダー選定より先に、自社の音声データがどこに溜まっていて誰が使えるかの整理が先行課題になります。