Grok Voice Transcribe 2.0 対 Gemini 3.5 Transcribe：ストリーミング分野はどちらか一方のものだ

Grok Voice Transcribe 2.0とGemini 3.5 Transcribeは、競合ラボによる最新のフロンティア音声文字起こしモデルであり、正直に比較するなら、まず両者が同じ用途向けに作られていないことを認めるべきだ。SpaceXAIのGrok Voice Transcribe 2.0は2026年9月18日リリースで、ストリーミングファーストのモデルにバッチモードを付属させたものだ。最終トランスクリプトでは単語誤り率2.7%、最初の部分結果では3.4%でAA-WERストリーミングボードの首位に立ち、どちらも発話終了から0.49秒後に到着する。Gemini 3.5 Transcribeは2026年8月26日リリースで、ストリーミングSKUを付属させたバッチファーストモデルであり、その二つの部分は大きく異なる挙動を示す — 録音済み経路はArtificial Analysisの非ストリーミングボードでAA-WER 2.6%を計測する一方、別個のgemini-3.5-transcribe-liveエンドポイントはストリーミングボードで4.0%を0.40秒で計測する。これら4つの数字を並べれば、この対決の構図は明らかだ。Gemini 3.5 Transcribeが強い領域では精度で両者は接近しており、Grok Voice Transcribe 2.0が強い領域では接近していない。

彼らが二人とも戦う唯一のレーン

両モデルともライブ音声を文字起こしできるため、ストリーミングは単純比較が意味を持つ唯一の領域です。そこでは、Grok Voice Transcribe 2.0 が最終文字起こし精度で Gemini 3.5 Transcribe Live を1.3ポイント上回っています — 同じハーネス、同じ約8時間の音声、AA-AgentTalk、VoxPopuli、Earnings22 にわたる同じ50/25/25の重み付けで、WERは2.7%対4.0%です。これは丸め誤差ではありません。そのエラー率では、Googleモデルが文字起こしする約75語ごとに1語余分に間違える程度に相当します。最初の部分文字起こしでは差はさらに広く、3.4%対5.8%であり、部分文字起こしはライブ音声エージェントが話者が話し終える前に行動しなければならない文字起こしです。

遅延は逆方向に効いてくる。そして、これがこの比較で見落とされがちな部分だ。Gemini 3.5 Transcribe Live は発話終了の 0.40 秒後に最終文字起こしを返すのに対し、Grok は 0.49 秒。最初の部分結果は 0.25 秒対 Grok の 0.49 秒で、最初に使える語までおよそ 2 倍速い。どちらのモデルも、このランキングで真に高速な側と競っているわけではない。そこでは Deepgram Flux が 0.02 秒、Soniox v5 が 0.05 秒を記録している。しかしこの 2 者の間ではトレードオフは明白だ。Google は話し始めるのが速く、SpaceXAI は話すときに正しい可能性が高い。通話者を遮ってはならないターンテイキング型エージェントにとって、部分結果の遅延が 0.24 秒増えるのは現実的なコストであり、精度の向上がそれを正当化しなければならない。

Gemini 3.5 Transcribeが実際に優位に立つ場面

言語カバレッジは最も明快な点であり、しかもその差は大きい。Googleのモデルは85以上の言語を扱い、Grok Voice Transcribe 2.0は数十言語をサポートしており、書き言葉形式の整形——話し言葉の数字、日付、通貨、メールアドレスを書き言葉の形に変換する逆テキスト正規化——が25言語で文書化されている。もし音声がポルトガル語、ベトナム語、あるいは一文の中で2言語がコードスイッチングした混在であるなら、Artificial Analysisのリーダーボード上でどちらのモデルがより正確かという問いは、ほぼ学術的なものになる。なぜなら、そのリーダーボードは英語に重み付けされており、エージェント関連の会話が多いからだ。Googleは自社の多言語スイートでFLEURSにおけるストリーミングWER 5.50%、非ストリーミングWER 5.04%を報告している。これはベンダーによる報告であり、独立に再現されたものではないが、少なくとも多言語の場合について何らか記述してはいる。

第二の利点は無料枠です。Gemini 3.5 Transcribe は Google の API 上で入力・出力トークンが無料で、ただし無料枠のコンテンツは Google 製品の改善に利用され、有料枠のコンテンツは利用されないという注意点があります。プロトタイプ、サイドプロジェクト、あるいは本来なら文字起こしにお金を払わないような音声を処理する社内ツールにとって、これは時間単位課金のベンダーには到底太刀打ちできない現実的な選択肢です。Grok Voice Transcribe 2.0 は最初の音声1時間から有料です。

第三に、Gemini 3.5 Transcribe は文字起こしモードを備えた汎用マルチモーダルモデルであり、文字起こし専用に設計された ASR サービスではないということだ。プロンプトを与えることもでき、テキストをコンテキストとして受け取ることもでき、Google が提供する他のあらゆるものと同じ API サーフェス上に存在している。文字起こしが、その文字起こし結果に対する推論も必要とするパイプラインの一段階であるなら、両方を 1 回のモデル呼び出しで済ませられることには、単語単位の誤り率では捉えきれない価値がある。

価格の計算、1,000分あたり

Artificial Analysisは両モデルを音声1,000分あたりのコストに正規化しています。これが時間単位の定額料金とトークン課金を比較する唯一の方法です：

• バッチ、事前録音 — Grok Voice Transcribe 2.0 は1,000分あたり$1.67（1時間あたり$0.10）に対し、Gemini 3.5 Transcribe は1,000分あたり$5.00（1時間あたり$0.30、100万入力トークンあたり$2.00、100万出力トークンあたり$12.00から）

• ストリーミング — Grok Voice Transcribe 2.0 は1,000分あたり$3.33（1時間あたり$0.20）、これに対し Gemini 3.5 Transcribe Live は1,000分あたり約$5.40で、1Mオーディオ入力あたり$3.50と1Mテキスト出力トークンあたり$21.00をブレンドしたもの

• バッチスループット — Grok Voice Transcribe 2.0 は約162倍のリアルタイム、Gemini 3.5 Transcribe は同じボード上で約88倍なので、ファイル作業では安価なモデルの方が高速でもある

• ライブセッション上限 — Grok Voice Transcribe 2.0 は WebSocket 経由でストリーミングし、チームあたり同時 100 セッション以外に公表されたセッション上限はない。一方、Gemini 3.5 Transcribe Live は 1 セッションあたり 10 分に制限されている

その最後の行は、精度の数値以上に多くのアーキテクチャを左右する運用上のディテールだ。ライブセッションにおける10分の上限は、長時間の通話、長時間の会議、長時間のストリームを分割して再確立しなければならないことを意味し、再確立のたびにコンテキストが失われる継ぎ目になる。Grokのストリーミングエンドポイントは、バッチ経路では500MBのファイルサイズ上限、ストリーミング経路ではチームあたり100セッションの同時実行上限という、別種の制約を抱えている——持続時間ではなくスループットという制約だ。

トークン課金は、Google側を選ぶと決める前に理解しておく価値があります。請求額が1つではなく2つの変数の関数になるからです。Geminiは音声入力とテキスト出力を別々に課金するため、冗長な書式を生成したり同じ内容を繰り返したりするモデルは、そうでないモデルよりもコストが高くなり、単語が長い言語は短い言語よりもコストが高くなります。Grokの時間単位の定額料金は、そうしたどれにも左右されません。大量のワークロードでは定額のほうが予測しやすく、またOrcaRouterはプロバイダーの定価を0%のマークアップでそのまま反映するため、どちらかのベンダー側での変更は、次回の契約更新時ではなく、それが起きた日に請求に反映されます。

機能の形：それぞれが拒むこと

能力の一覧は、精度の数値が示唆する以上に大きく食い違っており、その隔たりは特定のアプリケーションにとって重要な箇所に現れている：

• 話者ダイアライゼーション — Grok Voice Transcribe 2.0 では追加料金なしで含まれています。Gemini 3.5 Transcribe Live ではサポートされていないため、話者を紐付けたライブ文字起こしはそのエンドポイントでは一切利用できません

• 単語レベルのタイムスタンプ — Grok Voice Transcribe 2.0 は単語ごとの信頼度スコアとともにこれらを返す。一方、Gemini 3.5 Transcribe Live は一切返さないため、信頼度によるしきい値処理と正確なキャプション整列は成立しない

• マルチチャンネル音声 — Grok Voice Transcribe 2.0 は最大8つの独立したチャンネルを1回の処理で文字起こしできます。Gemini 3.5 Transcribe Live には同等の機能がないため、マルチチャンネルの通話録音ではチャンネルごとにセッションを分ける必要があります

• キータームバイアス — Grok Voice Transcribe 2.0はリクエストごとに最大100個のドメイン用語を受け付け、Gemini 3.5 Transcribeはカスタム語彙と言語ヒント（任意）を受け付けます

• 音声エージェントの基盤 — Grok Voice Transcribe 2.0 はフィラーワード除去と Smart Turn によるターン終了検出を搭載。Gemini 3.5 Transcribe Live はストリーミングケースをカバーするが、ターンロジックはアプリケーションに委ねる

• 入力の扱い — Grok Voice Transcribe 2.0 は、12 種類の音声フォーマットに対応し、最大 500 MB のファイルを直接アップロードして処理できます。Gemini 3.5 Transcribe の録音済み音声向けの経路では、公開 HTTPS URL が必要で、15 分・300 MB が上限となり、スマートフォーマットモードを単語タイムスタンプや話者ラベルと組み合わせることはできません。

そのリストに見られるパターンは、SpaceXAIが文字起こし製品を作り、Googleが文字起こし機能を作ったということだ。話者分離、タイムスタンプ、チャンネル分割、発話ターン検出は、文字起こしそのものがアプリケーション全体である場合に必要になる機能であり、プロンプト対応性、言語の幅広さ、すべてを1つのAPIでというのは、文字起こしがより大きなものの中の一工程にすぎない場合に求めるものだ。どちらのリストも抽象的に優れているわけではなく、精度だけで選ぶチームは、必要としなかったほうの機能群を結局は見落とすことになる。

それらのどちらを選ぶか、そして何が答えを変えるのか

Grok Voice Transcribe 2.0 の出番は、音声がまだ再生されている間に文字起こしが正確でなければならない場合です。たとえば、ライブエージェントのターンテイキング、誤りが許されないリアルタイム字幕、話者帰属とチャネル分離が要件の一部となるコンタクトセンターのストリーム、または 1,000 分あたり $1.67 と 162× のスループットの両方が重要なバッチパイプラインなどです。Gemini 3.5 Transcribe の出番は、音声が多言語で、Grok のドキュメントに記載された言語セット外の言語を含む場合、文字起こしが、その内容について推論も行う必要があるモデルに渡される場合、無料枠でプロトタイプを作りたい場合、またはバッチ経路の 2.6% AA-WER が今行っていることにとって十分で、追加の言語カバレッジが価格差以上の価値がある場合です。

ほとんどのチームが実際にここでやっているのは、どちらかを選ぶことではない。両方のモデルは、200以上の他のモデルとともに、1つのOrcaRouter APIキーを通じて利用できる。つまり、2つのベンダー契約、2つの請求関係、2セットの認証情報を維持することなく、ライブのエージェントトラフィックをGrok Voice Transcribe 2.0へ、長い多言語アーカイブをGemini 3.5 Transcribeへルーティングできる。これこそが、自分の音声に関する精度の疑問を解決する方法でもある。同じ録音で両方を実行し、実際に得られた文字起こしを比較し、ルーティングDSLにトラフィックを然るべき場所へ送らせるのだ。リーダーボードは、他人の英語エージェント通話8時間分でどのモデルが勝つかを教えてくれるにすぎない。自分の音声でどちらが勝つかを教えてくれるのは、自分の音声だけだ。

未解決の問いは、Googleが次にLiveエンドポイントを改訂したとき、そのストリーミングの差がどうなるかだ。Gemini 3.5 Transcribe Liveはパブリックプレビューで公開され、その4.0%という数値は呼び出し可能になってからおよそ1日後に測定された——強い初期シグナルだが、今その背後に位置するGrokの数値より、落ち着くまでの時間が短い。もしGoogleが0.25秒の部分レイテンシを維持したまま1.3ポイントのストリーミング差を埋めれば、このトレードオフはトレードオフではなくなり、Grokの優位性は価格と機能に狭まる。それまでは分かれ方は明確だ。最速の部分結果はGoogleのもので、最も正確なものはSpaceXAIのものであり、ボード上のどのモデルも両方を兼ね備えてはいない。