MAI-Transcribe-2-Streaming 対 Gemini 3.5 Transcribe Live：同じ$9、異なるトレードオフ

MAI-Transcribe-2-StreamingとGemini 3.5 Transcribe Liveは同じ金額がかかり、ストリーミング文字起こしが何のためにあるかについて正反対の理論に基づいて作られている。どちらもストリーミング音声1,000分あたりおよそ9.00ドルに落ち着く。Microsoftのモデルは2026年10月1日にリリースされた精密機器だ。最終文字起こしまで0.13秒で、ストリーミング単語誤り率は2.5%と主張され、Microsoft自身の説明によれば最終および部分文字起こしの両方で精度首位であり、Artificial Analysisのストリーミング手法で測定されているが、そのボードではまだ1行としてプロットされていない。もう一方のモデルは、2026年8月26日から公開プレビュー中で、Live API経由で提供されており、網羅性を重視した機器だ。ストリーム途中での切り替えに対応した85以上の言語、無料枠、そして0.40秒でストリーミング単語誤り率4.00%——Artificial Analysisが同モデルについて測定している数値だ。どちらも明白な選択肢ではなく、その理由は、両者が実際には同じワークロードをめぐって競合しているわけではないからだ。

数字が実際に示しているとおりの直接対決は次のとおりです — ベンダー報告の数値にはラベルを付け、トラッカーの数値には出典を明記し、一方のモデルが、もう一方がまったく争わない次元で勝っている部分も示します。

一行バージョン

• 精度とレイテンシ — 公表された数値における MAI-Transcribe-2-Streaming。Microsoft は、最終トランスクリプトまで 0.13 秒でストリーミング WER 2.5%、最終トランスクリプトと部分トランスクリプトの両方で精度首位、最初の部分トランスクリプトを 0.12 秒で 2.5% と主張している。これに対して、Artificial Analysis は Gemini 3.5 Transcribe Live を 0.40 秒で 4.00% としている。Microsoft が主張する優位性は 1.5 ポイントで、確定まで約 3 倍速い。ただし注意点として、トラッカーはまだ MAI-Transcribe-2-Streaming 自体をプロットしていない — リーダーボードの現在の首位は Grok Voice Transcribe 2.0 で 2.73% と 0.49 秒、Muse Voice Transcribe は 3.06% と 0.16 秒である — つまり 2.5% は、トラッカーが実際に測定している領域と比較して読まれたベンダー公表値である。両モデルが公表している軸においては僅差ではないが、その片側だけが独立に公表されている。

• 言語の幅 — Gemini 3.5 Transcribe Live。85言語を自動検出し、セッションを再起動せずにストリームの途中で言語を切り替える機能を備えている。これはGoogleのLive APIの目玉の主張である。MAI-Transcribe-2-Streamingは、自動連続言語検出により60言語をカバーする。Microsoftの方が高い；Googleの上限はより広く、その25言語の差は主に、単一言語のストリーミングモデルが全く使用できない言語にある。

• セッションの形態 — Gemini 3.5 Transcribe Live、これは諸刃の剣だ。Live API は 10 分に上限が設定された WebSocket セッションであり、音声エージェントの 1 ターンには問題ないが、1 時間の会議には扱いにくい。Microsoft は自社のストリーミングモデルについて、同等のセッション上限を公表していない。これは、作業単位が会話の 1 ターンではなく通話である場合に重要だ。

• {{1}}Gemini 3.5 Transcribe Live{{/1}}のコスト。無料枠があり、Googleのブレンド料金はトークンベースの価格設定で1分あたり約$0.009になる。Microsoftの音声1時間あたり$0.54は、Microsoftによると年末まで続く導入価格であり、標準価格は開示されていない — 9月のバッチリリースと同じ構造だ。

なぜ精度の差は見た目より大きいのか

1.5ポイントの単語誤り率の差は、コストを算出するまでは丸め誤差のように聞こえる。ストリーミングWER 4.00%では、Gemini 3.5 Transcribe Live は1,000語あたり約40語を誤る。マイクロソフトが主張する2.5%では、MAI-Transcribe-2-Streaming は25語だ。リアルタイムパイプラインが生み出す量——サポート組織が月に5,000時間の通話を処理するなら30万分、会話の速度で4,500万語以上——では、その差は年間数百万語の誤りとなり、しかも下流システムが依存するエンティティ、すなわちアカウント名、チケット番号、投薬量、住所に集中する。

レイテンシの差は、より売り込むのが難しいものだ。発話終了後0.13秒対0.40秒は、ライブキャプションのストリームでは知覚できる——約0.2秒未満なら同時に感じられ、3分の1秒だと文字起こしが話者を追いかけているように見える——しかし、人間の時間尺度で更新されるエージェント支援パネルでは知覚できない。もし消費者が読みながら追う人間なら、Microsoftのレイテンシ優位が製品そのものだ。もし消費者がターン終了時に最終的な文字起こしを受け取るモデルなら、それはただの数字だ。

どちらの数値も同じ注意点を伴っており、一度だけ述べておく価値がある。これらは37モデル分の深さがあるトラッキングボードから得た単一実行の数値であり、そのボード上の1位と3位の差は1ポイント未満だ。再実行すれば、ストリーミングのリーダーボードの上位は、バッチボードでの2ポイント差では起こり得ない形で入れ替わりうる。また、Microsoftの2.5%はまだこのボードにはまったく載っていない。それはトラッカーの方法論で測定されたベンダーによる主張であり、トラッカーが公表する行とは別物だ。

限界こそが、決断が実際に宿る場所だ

機能の限界は、ベンチマークよりも速くこの2つを分かつ。そして両者は逆方向に進む。

Gemini 3.5 Transcribe Live には、文書化された3つの制約があります。Live API の10分間のセッション上限、話者ダイアリゼーション非対応、単語レベルのタイムスタンプ非対応です。1つ目はアーキテクチャ上のもので、WebSocket セッション経由のストリーミングには設計上限界があり、長時間のライブ文字起こしはセッションをまたいでつなぎ合わせる必要があり、その継ぎ目の処理は利用者に委ねられます。残り2つは絶対的です。製品で発話を話者に帰属させる必要がある場合、あるいは検索や字幕同期のために単語をタイムスタンプに配置する必要がある場合、Gemini 3.5 Transcribe Live はどんな価格でもそれは行いません。

MAI-Transcribe-2-Streaming の制約はあまり文書化されていないが、それ自体が情報である。Microsoft はストリーミングモデルについて話者分離（ダイアリゼーション）を主張しておらず、単語タイムスタンプも主張していない。バッチ版の MAI-Transcribe-2 は話者分離を同梱し、単語レベルのタイムスタンプを返すが、それはバッチ製品であり、ストリーミング SKU がそれらを継承していると仮定するのは、まさにローンチ資料が防ぐために存在する類の推論である。Microsoft が実際に主張しているのは、継続的な言語検出を備えた60言語、および精度対レイテンシにおけるパレートフロンティア上の位置づけだ。どちらも、トラッカーのデータと整合するベンダーの主張である。

率直に機能を読み解くと、どちらのストリーミングモデルも話者分離や単語タイムスタンプを公開していません。Gemini 3.5 Transcribe Live には公開されたセッション上限と無料枠があります。MAI-Transcribe-2-Streaming には公開された言語数があり、公開された上限はありません。要件に話者分離が含まれるなら、これらのどちらも答えではなく、ストリーミング層を前段に無理やり付けたバッチ文字起こしを検討することになります。

価格パリティが本当に伝えていること

2社が同じ1,000分あたり9ドルという金額に、正反対の方向から到達していることが、この比較で最も興味深い事実だ。GoogleはLive APIセッションにおけるトークン課金を通じてそこに到達した。音声入力は100万トークンあたり3.50ドル、テキスト出力は100万トークンあたり21ドルで、消費量は1分あたりおよそ175テキストトークンという概算であり、これを合わせると1分あたり約0.009ドルになる。Microsoftは、バッチ版の同族モデルが0.10ドルで動作するファミリーに属するモデルについて、音声1時間あたり0.54ドルという定額を提示することでそこに到達した。一方は従量制のリアルタイムセッションであり、もう一方は導入割引付きの1分あたり定額料金だ。

それらの構造は、スケールするにつれて異なる挙動を示します。定額料金は予測可能で、予算を立てやすいです。一方、トークン従量制のセッションは、モデルがどれだけ応答するか、セッションがどれだけアイドル状態で開いているかによって変動します。大量処理のパイプラインでは、定額料金の方がより親しみやすい請求書となります。プロトタイプや低ボリュームの機能では、無料枠とトークン単位の課金の方がより親しみやすい入り口です。

どちらの構造をとっても変わらないのは、トランスクリプトより上の層だ。どちらのモデルが生成するにせよ、ライブトランスクリプトは要約、分類、秘匿化、ルーティングへの入力であり、それらのステップには独自のコストと品質の曲線がある——通常は1つではなく複数のモデルにまたがって実行される。それがOrcaRouterがカバーする層だ。200以上のモデルにわたる単一API、プロバイダー定価を0%のマークアップでそのまま通す仕組み、自動フェイルオーバー、そしてワークロードごとにトランスクリプトを異なるモデルへ送れるルーティングDSL。MAI-Transcribe-2-StreamingもGemini 3.5 Transcribe Liveもその名簿にはない——それぞれMicrosoftとGoogle自身の音声スタックを通じて提供される——そして要点はそれらをルーティングすることではなく、それらの下流にあるすべてをポータブルに保つことだ。

どちらを選ぶべきですか

精度と確定までの時間が製品そのものになる場合は、MAI-Transcribe-2-Streaming を選んでください。人間が読むライブキャプション、聞き間違えたエンティティにコストが伴うリアルタイムのコンプライアンスや品質スコアリング、あるいは Gemini の10分という上限のせいでつなぎ合わせざるを得ない長時間セッションに適しています。カバレッジが製品そのものになる場合は、Gemini 3.5 Transcribe Live を選んでください。事前に列挙できない言語をまたぐグローバル展開、ストリーム途中の言語切り替え、あるいは無料枠とトークン単位の課金によってコミットメントが不要になるプロトタイプに適しています。両方を必要とするチームも行き詰まりません — 両者は異なるセッションモデルを持つ別々の API であり、誠実なアーキテクチャはどちらか一方に標準化するのではなく、ワークロードごとにルーティングすることです。

この比較から持ち帰るべき主張は、Microsoft が勝ったということではない。ストリーミング文字起こしには今や、同じ価格で提供される信頼できる最先端の選択肢が 2 つ存在するということだ。つまり、判断は「何が利用できるか」から「この特定のワークロードには何が必要か」へと移った。そのほうが、抱えるにはより良い問題である。