Gemini 3.5 Transcribe 公開 — 言い淀みを整えて出す音声認識が、85言語超で API 提供へ

要約

2026-08-26、Google は音声認識モデル Gemini 3.5 Transcribe を公開しました。従来モデル Chirp 3 の後継にあたります。

このモデルの位置づけを一言で言うと、「音声をテキストにする」から「音声を読める文章にする」へ移したということです。公式の説明はそこを明確にしています——従来の音声認識モデルは背景ノイズ、専門用語、言い淀みの除去を苦手としてきたが、Gemini 3.5 Transcribe は生の音声から直接、正確で整形済みのテキストへ変換する。

具体的に何が変わるか。言い直しを吸収します。「火曜日に会おう——いや水曜日」と話せば、水曜日として記録されます。フィラーを除去します。「えーと」「あのー」は落ちます。自動で整形します。改行も句読点も、後から人が入れるものではなくなります。従来はこれらを LLM による後処理でやっていた領域です。

開発者向けの提供は2系統に分かれています。 これは用途の違いがそのまま API の違いになった形です。

• リアルタイムストリーミング: Live API の gemini-3.5-transcribe-live。サブ秒レイテンシの双方向ストリーミングで、対話型の音声アプリ向け
• 録音済み音声: Interactions API の gemini-3.5-transcribe。会議録音、通話ログなどを話者帰属と単語レベルのタイムスタンプ付きで処理

提供面は Gemini API（Google AI Studio）と Gemini Enterprise Agent Platform。

精度の数字も出ています。 Artificial Analysis の計測で、WER（単語誤り率）は平均 4.0%（ストリーミング）/ 2.6%（非ストリーミング）。多言語ベンチマーク FLEURS の主要言語・ロケールでは 5.50%（ストリーミング）/ 5.04%（非ストリーミング）。そして最終テキストが確定するまでの時間は Chirp 3 比で約70%改善しています。精度より、この待ち時間の短縮の方が体感には効きます。

多言語対応は 85言語超の自動検出。地域アクセントと方言の差も扱うとしています。話者の識別は録音済み音声で最大3話者まで（3話者超は experimental）。

function calling に対応している点も見逃せません。音声認識モデルが、画像生成やファイル分析といった重い処理を他の Gemini モデルへ委譲できます。現時点では Gemini macOS アプリで利用可能。音声入力が、文字起こしの入口ではなく操作の入口になるという設計です。

製品側では、Android の Gboard 新機能 Rambler（話した内容を整形済みテキストに変換し、音声で編集・修正・文体変更ができる）、Google Antigravity（許諾のうえ画面コンテキストとチャット履歴を参照してファイル名やエージェントの思考の認識精度を上げる）、Google AI Studio の Build モード（音声でのコーディング）、Gemini macOS アプリで使われています。Chrome への搭載は近日で、任意の Web 入力欄で音声入力ができるようになる予定です。

何が変わったか

• Gemini 3.5 Transcribe を公開。従来の Chirp 3 の後継
• API は2系統: Live API の gemini-3.5-transcribe-live（リアルタイム、サブ秒レイテンシ）と Interactions API の gemini-3.5-transcribe（録音済み、話者帰属＋単語レベルタイムスタンプ）
• 提供面は Gemini API（Google AI Studio）と Gemini Enterprise Agent Platform
• 言い直しの吸収、フィラー除去、自動整形を音声から直接実行（後処理を前提にしない）
• 85言語超の自動検出、カスタム語彙への適応、録音音声で最大3話者の帰属（3話者超は experimental）
• 精度: WER 平均 4.0%（ストリーミング）/ 2.6%（非ストリーミング）。FLEURS で 5.50% / 5.04%。最終確定までの時間は Chirp 3 比 約70%改善
• function calling 対応。他の Gemini モデルへ画像生成・ファイル分析を委譲（現時点では Gemini macOS アプリ）
• 製品搭載: Gboard の Rambler（Android）、Google Antigravity、AI Studio Build モード、Gemini macOS アプリ。Chrome は近日

業務インパクト（一般企業向け）

議事録運用を組んでいる企業は、後処理の層を1つ減らせる可能性があります。 よくある構成は「音声認識 → LLM で整形・要約」の2段です。フィラー除去や言い直しの吸収を認識側が担うなら、整形のための LLM 呼び出しが不要になるか、少なくとも軽くなります。コストとレイテンシの両方に効きますし、段が減ればトラブルシュートも楽になります。ただし要約は別の話です。整形は認識側、要約は LLM 側、という切り分けになります。

「最大3話者」という制約は、導入前に必ず確認してください。 1対1の商談、2〜3人の打ち合わせなら問題ありません。5人以上の会議では、話者の識別が実用にならない可能性があります（3話者超は experimental とされています）。議事録用途で全社展開を考えるなら、自社の会議が実際に何人で行われているかを先に数えることをお勧めします。ここを確認せずに導入して「話者が混ざる」と現場から苦情が出るのは、よくある失敗です。

カスタム語彙への対応は、業界特化の現場で効きます。 製品名、社内用語、人名、型番。汎用の音声認識で最も辛いのがここで、「毎回同じ単語を間違える」ストレスは導入定着を直接妨げます。語彙を渡せる設計になっているなら、導入初期に用語集を作る工程を見込んでおくと、体感精度が変わります。逆に言えば、用語集を用意しない導入は本来の性能を出せません。

85言語超の自動検出は、多国籍拠点を持つ組織にとって具体的な効用があります。 「日本語用の設定」「英語用の設定」を分けずに済むということは、運用上のスイッチが1つ減るということです。海外拠点との会議で言語が混ざる場面でも、切り替えを意識しなくてよい。地味ですが、現場の摩擦が減る種類の改善です。

そして、function calling への対応は先を示しています。 音声認識モデルが他のモデルへ処理を委譲できるということは、「文字起こしを得る」から「話しかけて仕事をさせる」へ用途が移るということです。現時点では Gemini macOS アプリに限られますが、この方向を前提に置いておくと、いま作るものの設計が変わります。「音声 → テキスト → 人が読む」ではなく「音声 → 行動」を最終形に置けるかどうか。

副業・個人活用視点

発信をしている人にとって、Rambler 的な使い方は直接効きます。 記事、note、SNS、提案書。書く前に話すというやり方は昔からありますが、これまでは「文字起こしを整える」という重い工程が挟まっていました。フィラーと言い直しが最初から落ちているなら、移動中に話した内容が、そのまま下書きとして使える水準に近づきます。ゼロから書くより、直す方が速い人は多い。

クライアントワークでは、通話ログの活用が現実的になります。 打ち合わせの録音から、話者帰属と単語レベルのタイムスタンプ付きで文字起こしができるということは、「あの話はどこで出たか」を検索できるということです。認識の齟齬が起きたとき、記憶ではなく記録で確認できるのは、信頼の面でも効きます。ただし録音には相手の同意が要ります。技術的にできることと、やってよいことは別です。

副業の商材としては、「議事録自動化」より「用語集を作る仕事」の方が単価が付きます。 音声認識の導入で実際に詰まるのは、モデルの性能ではなく業界固有の語彙をどう渡すかです。カスタム語彙に対応したモデルが出たということは、その語彙を整備する工程に価値が生まれたということでもあります。ツールを入れるだけの提案は誰でもできますが、業務用語を棚卸しして辞書に落とす作業は、その業界を知っている人にしかできません。

支援先へ提案する立場なら、「まず3人以下の会議から」という入り方が使えます。 全社の議事録を一気に自動化しようとすると、話者数の制約で必ず失敗します。1対1の商談記録、少人数の定例——制約に収まる場所から始めて、実績を作ってから広げる。制約を隠して導入するのではなく、制約に合う場所を選んで提案する方が、結果として定着します。この順序を提案できるかどうかが、導入支援の質の差になります。