Google Gemini 3.5 Transcribe、APIを公開——語誤り率2.6%で5位、リアルタイムストリーミングには3つの制約

2026年8月26日、GoogleはGemini 3.5 TranscribeをGemini API経由で外部開発者に正式公開した。GoogleのオフィシャルブログがArtificial Analysisの独立評価を引用したところによると、本モデルの非ストリーミング時の語誤り率（WER）は2.6%、リアルタイムストリーミング時は4.0%で、ストリーミング遅延は発話終了後0.4秒以内に最終結果を出力する。モデルはGoogle AI StudioおよびGemini Enterprise Agent Platformで提供が開始されており、Artificial Analysisのデータによると価格は1,000分あたり約5ドルとなっている。今回の発表はGemini 3.5 LiveおよびGemini 3.5 Live Experimentalと同日に行われ、Googleの新たな「Gemini Audio」プロダクトラインを形成する。責任者はGoogleのGemini Audioエンジニアリング担当シニアディレクター、Diego Melendo Casadoが務める。

2つのエンドポイント——差異はマーケティング資料が示す以上に大きい

Gemini 3.5 Transcribeはアーキテクチャ上、まったく異なるユースケースに対応する2つの独立したエンドポイントに分割されているが、両者の能力差はマーケティングの面で十分に強調されていない。

録音済み音声エンドポイント（gemini-3.5-transcribe）はオフラインのバッチ処理向けで、1回あたり最長1時間の音声に対応し、話者識別（最大8チャンネル）および単語レベルのタイムスタンプ機能を提供する。ただし、話者識別またはタイムスタンプを有効にした場合、1回あたりの処理上限は即座に1時間から30分に短縮される。さらに、3チャンネルを超える話者の識別ラベリングについては、Googleのドキュメントで「実験段階」と明示されており、複数人が参加する会議の文字起こしシナリオにとってはこれが実質的な制約となる。

リアルタイムストリーミングエンドポイント（gemini-3.5-transcribe-live）はWebSocketによる双方向通信を実現し、低遅延の音声アプリケーションを主な用途とするが、1回のセッション上限はわずか10分で、話者識別とタイムスタンプはサポートされていない。つまり、リアルタイム性と話者ラベリングの両方を求める開発者は、現行バージョンでは単一のエンドポイントでこれを実現することができない。10分を超える連続音声シナリオでは、アプリケーション層で独自の分割・継続ロジックを実装する必要があり、エンジニアリングの複雑さが増す。

カスタム語彙機能では最大1,000件のドメイン固有用語を入力できるが、Googleのドキュメントには「最良の結果を得るには通常100件以内を推奨」とも記載されている。この実質的な推奨上限である100件は、大量の薬品名・法律用語・金融商品コードを網羅する必要がある垂直産業にとって、ユーザー自身が評価すべきハードルとなる。

スマート文字起こし——「逐語記録」から「意図理解」へ

Gemini 3.5 Transcribeの最も差別化された能力は、対応言語数の多さではなく、Googleが「Smart Transcription（スマート文字起こし）」と呼ぶ処理レイヤーにある。従来の音声認識は逐語的に出力し、話者の自己修正、口癖、非構造的な口語表現をそのまま保持するが、Gemini 3.5 Transcribeは文字起こしプロセスに意味理解のレイヤーを介在させる。

具体的には、話者の自己修正を認識し（「火曜日——いや、水曜日に会いましょう」を2つの並列出力ではなく最終的な意図として処理）、「えー」「あの」などのフィラーワードを自動除去し、口語表現を構造化テキストにフォーマット化する（郵便番号・注文番号などの英数字混在エンティティの正確な処理を含む）。この能力はGoogleの自社製品において内部検証済みだ——GboardのAndroid版Rambler音声入力機能およびmacOS版Geminiアプリはいずれもこのモデルをベースとして動作している。この大規模な内部展開実績は、外部開発者がベンチマーク数値以外に参照できる信頼性の根拠となる。

一方、現時点で制限されている能力がある。Function Calling（関数呼び出し）は複雑なタスクを他のGeminiモデル（画像生成、ファイル分析など）に委任できる機能だが、Googleのドキュメントによれば、現在はGemini macOSアプリでのみ利用可能で、API開発者にはまだ公開されていない。

競争環境——中堅での参入、最優とはいえず

DeepgramやAssemblyAIなどの既存の音声テキスト変換スタートアップに対し、Googleは今回の発表でコアビジネス領域に正面から圧力をかけている。低遅延リアルタイムストリーミング、話者識別、カスタム語彙という3つの能力をすべてカバーしているのだ。価格面では、Artificial Analysisのデータによると、AssemblyAIのストリーミングエンドポイントは1,000分あたり約7.5ドル、Deepgramのストリーミングサービスは約7.7ドルであり、Googleの5ドルは中価格帯として一定の競争力を持つ。

ただし、この競争においてGoogleが一方的に優位というわけではない。Artificial Analysisの非ストリーミングランキングでは、公開当日時点でGemini 3.5 TranscribeはWER 2.6%で5位にとどまっている。上位に位置するElevenLabs Scribe v2はWER 2.2%で価格は1,000分あたり3.67ドル——精度が高く価格も低く、2つの指標でGoogleを上回る。Microsoft MAI-Transcribe-1.5はWER 2.4%で3位につけており、価格こそ6ドルとGoogleより高いが、精度ではやはり優れている。

Googleが示す縦方向の比較データはより説得力がある。Artificial Analysisのデータによると、前世代のChirp 3モデルと比較して、Gemini 3.5 Transcribeは「発話終了から最終文字起こし出力まで」の所要時間を70%短縮した。この数値は同一ベンダー内での世代間の改善幅を示しており、すでにGoogleの音声サービスを利用している既存ユーザーにとって、アップグレードの価値は明確だ。

精度数値の背後にある利用条件

Googleのブログが引用する2.6%と4.0%はいずれもArtificial Analysisの標準化ベンチマーク評価に基づいており、約8時間の音声を対象に3つのデータセットで加重平均したものだ。これは現時点で入手できる最も独立性・透明性の高い評価ソースといえる。しかし、ベンチマーク数値が前提とする録音品質・言語分布・ドメイン範囲と、実際のビジネスシナリオとの間には乖離がある——医療問診における専門用語の密度、カスタマーサービス録音の背景雑音、多人数会議でのアクセントの混在は、いずれも実際のWERをベンチマーク値から大きく乖離させる要因となりうる。

これこそが、Googleのカスタム語彙機能が価格体系において基本機能として含まれており、有料オプションではない理由だ——ドメイン適応能力の優劣は、実際の展開において汎用ベンチマーク数値よりも最終的な体験を左右することが多い。

Googleの真の戦略——APIは入口、Chromeが最終目標

Googleの公開された動向を見ると、APIの公開は今回の発表における中核的な戦略目標ではなく、より大きな構想の一部にすぎない。GoogleはGemini 3.5 TranscribeをChromeブラウザに導入することをすでに発表しており、実現すればユーザーはあらゆるウェブページのテキスト入力ボックスで直接音声入力が可能になる——メッセージの返信、投稿の作成、AIへの指示など日常的なシナリオを網羅する。

Chromeはグローバルブラウザ市場で長期にわたり60%超のシェアを維持しており、音声入力がChromeレベルでシームレスに組み込まれれば、ユーザーの入力習慣を変えるハードルは大幅に下がる。Googleにとって、この戦略的ロジックは「音声を『特定アプリ内の機能』から『OS レベルのインタラクションレイヤー』へ昇格させる」ことにある。音声インタラクションのたびに生成される実世界の音声データは、理論的にはモデルの精度向上にフィードバックされ、閉じたデータフライホイールを形成する。

Gemini 3.5 TranscribeとGemini 3.5 Liveの同日発表も、Googleが完全な音声インフラの構築を目指していることを裏付けている。前者は文字起こし精度に特化し、後者はリアルタイム対話に特化することで、両者が合わさって「発話→理解→実行」というチェーンの異なる段階をカバーする。

開発者・企業向けの実践的提言

現時点で判明している情報に基づく実務的な提言を以下に示す。

• 迅速なプロトタイプ検証シナリオ：Google AI Studioは無料枠を提供しており、ベンチマーク数値だけで選定を決めるのではなく、自社の実際の音声サンプルで精度をテストするのに適している。特にドメイン固有の音声（医療・法務・カスタマーサービスなど）での比較実験を推奨する。
• リアルタイム音声アプリケーション：10分のセッション上限は現行バージョンのハードな制約であり、超過シナリオでは分割・継続のエンジニアリングコストを評価したうえで、リアルタイムストリーミングエンドポイントの採用を判断すべきだ。
• 会議録音・通話分析：バッチ処理エンドポイントは話者数が2チャンネル以下でリアルタイム出力が不要なシナリオで最も安定したパフォーマンスを発揮する。3チャンネル以上の話者については、実験的なラベリングがビジネス上の許容誤差を満たすかどうかを確認する必要がある。
• 既存ベンダー契約がある企業：Artificial Analysisのランキングはが示す通り、ElevenLabs Scribe v2は精度と価格の両面でGoogleの現行バージョンを上回っている。プラットフォームのブランド力を前提に判断するのではなく、ベンダー切り替え前に並行評価を行う価値がある。