Microsoftは10月1日、話している途中から文字起こし結果を返す「MAI-Transcribe-2-Streaming」と、音声合成モデル「MAI-Voice-2.1」「MAI-Voice-2.1-Flash」を発表した。Microsoft Foundryでの提供はいずれもパブリックプレビューで、現時点では本番運用を保証する段階にはない。
9月に発表した録音向けの文字起こしモデルに、リアルタイム音声認識と音声合成を加えた形だ。利用者が話し終える前から処理を始められる一方、途中で返される文字起こし結果は後から書き換わることがある。
新モデルが音声エージェントをどこまで実用に近づけるかは、発話途中に得られる暫定的な認識結果を、どの処理まで使うかにかかっている。
発話途中の認識結果は、後から書き換わる前提で扱う
MAI-Transcribe-2-Streamingは60言語に対応し、話されている言語を継続的に自動検出する。
Microsoftによると、音声を受信してから100ミリ秒強で最初の暫定的な文字起こし結果を返す。録音が終わってからまとめて認識する方式とは異なり、字幕を表示したり、質問に関係する情報を先に検索したりする処理を、利用者が話している間から進められる。
ただし、途中で返される文字列は、そのまま最終結果の先頭部分になるとは限らない。音声が追加されると、それまでの認識内容が書き換わる場合がある。
MicrosoftのRealtime API資料では、その扱いを明確に分けている。
deltaで届く文字は確定部分として末尾へ追加する。一方、MAI固有のintermediateで届く内容は、その時点の未確定部分全体を置き換える。
そのため、すべての受信結果を単純に順番へ追加すると、訂正前と訂正後の文章が重複してしまう。
ここでいう「確定」は、あくまで文字起こしとして確定したという意味だ。利用者の意図まで確定したとは限らない。
例えば、予約の会話で利用者が、
「来週金曜、いや木曜に」
と言い直したとする。
途中の「金曜」という認識結果を使って空き状況の検索を始めることはできる。しかし、その時点で予約そのものを確定してしまえば、後から「木曜」に訂正されたときに誤操作になる。
これは製品の動作試験ではなく、ストリーミング認識を使った処理設計の一例である。
検索や候補取得のように後から取り消せる処理と、予約確定や返金のように実際の状態を変更する処理を分ければ、発話途中の認識結果を活用しながら誤操作を抑えられる。
発話の区切りもアプリ側で判断する
発話の区切りを判断する処理も、アプリ側で用意する必要がある。
Realtime API経由では、サーバー側による発話終了の自動検出や、自動的な確定要求には対応していない。自然な間や録音終了などを判断し、アプリ側からcommitを送る必要がある。
音声活動検出を組み合わせる場合には、短い息継ぎと、本当に話し終わった状態をどう区別するかが応答速度を左右する。
区切りを早く判断しすぎれば、利用者がまだ話している途中で処理を始めてしまう。一方、待ちすぎれば、ストリーミング認識の利点である低遅延を十分に生かせない。
セッションの上限は1時間となっている。
同APIはOpenAI Realtime APIに似た形式で音声を送受信する。ただし、MAI固有のintermediateや、確定要求を送る条件まで同じというわけではない。
APIの形式が似ていることから完全な互換性を想定するのではなく、暫定結果の更新方法や、会話の区切りを正しく扱えるかを確認する必要がある。
「WER 2.5％」と「100ミリ秒強」は同じ指標ではない
MicrosoftがStreaming版のモデルカードに掲載したArtificial Analysisの評価では、最終的な文字起こし結果の単語誤り率（WER）は2.5％だった。
同じ表では、Grok Transcribe 2.0が2.7％、ElevenLabs Scribe V2 Realtimeが3.6％となっている。
WERは、正解文に対する単語の置換、挿入、削除の数を合計し、正解文の単語数で割った指標である。値が低いほど、文字起こしの誤りが少ない。
ただし、この2.5％を、日本語を含む60言語すべてを平均した精度と考えることはできない。
Artificial Analysisのストリーミング評価では約8時間の音声を使用し、会話データのAA-AgentTalkを50％、VoxPopuliとEarnings22をそれぞれ25％の割合で組み合わせている。
評価方法では、VoxPopuliの対象言語は英語とされている。
したがって、「60言語に対応していること」と、「60言語すべてで同じ精度が確認されていること」は別に考える必要がある。
9月3日に発表された通常版MAI-Transcribe-2については、60言語のFLEURSを使った評価で平均WER5.2％だったというMicrosoftの測定結果もある。
ただし、今回のStreaming版の2.5％とはモデルも評価データも異なる。
数字だけを比較して「誤りが半分以下になった」と結論付けることはできない。
遅延の測定開始点も、各指標で異なる
速度についても、数字の意味を分けて読む必要がある。
Microsoftが説明する「100ミリ秒強」は、音声を受信してから最初の暫定的な認識結果を返すまでの時間を指す。
一方、Artificial Analysisの遅延指標は、SileroVADで発話終了を検出した時点を測定開始点としており、通信遅延も含まれる。
つまり、
- 発話中に最初の文字が届くまでの速さ
- 話し終わった後に結果が返るまでの速さ
は別の指標である。
同じ「遅延」として単純に比較すると、実際の利用時の挙動を見誤る可能性がある。
音声合成についても同様だ。
MAI-Voice-2.1の比較表では、モデル推論の遅延を通常版で約550ミリ秒、Flash版で約45ミリ秒としている。
料金は100万文字あたり、通常版が22ドル、Flash版が15ドルだ。
またMicrosoftはFlash版について、45秒の音声を生成する場合に「end-to-end latency 150ms」と説明している。
ただし、公開資料では、この150ミリ秒がどの処理を含んだ値なのかについて、45ミリ秒のモデル推論遅延ほど詳しい定義は示されていない。
いずれにしても、認識の100ミリ秒強と、音声合成の45ミリ秒を単純に足しても、利用者が返答を聞くまでの時間にはならない。
その間には、
- 質問内容の理解
- 言語モデルによる回答生成
- 検索やデータベース参照
- 外部ツールの実行
- 音声再生開始までの処理
などが入る。
公開されている遅延値は各部品を選ぶ材料にはなるが、音声エージェント全体の応答速度は実際の構成で測る必要がある。
リアルタイム化で失う機能もある
Microsoftが2026年10月2日時点で公開している仕様では、通常版MAI-Transcribe-2とStreaming版はいずれも60言語に対応する。
一方、Streaming版には通常版が備える話者分離や専門用語の補正など、一部の機能がない。
下表は公式のバージョン比較表を同じ項目で整理したものだ。
価格は音声1時間あたりの米ドルで、通常版の発表文とStreaming版のモデルカードに記載された、2026年末までの導入価格を比較している。
| 項目 | MAI-Transcribe-2（通常版） | MAI-Transcribe-2-Streaming |
|---|---|---|
| 対応言語 | 60言語 | 60言語 |
| 発話中のストリーミング認識 | 非対応 | 対応 |
| 話者分離 | 対応 | 非対応 |
| 単語単位のタイムスタンプ | 対応 | 非対応 |
| キーワード指定による認識補正 | 対応 | 非対応 |
| 読みやすく整えた文／発話どおりの逐語文の選択 | 対応 | 非対応 |
| 音声1時間あたりの導入価格 | 0.10ドル | 0.54ドル |
通常版は、会議や通話を後から記録として残す用途に向いた機能を備えている。
誰が話したかを区別し、業務固有の単語を認識しやすくする機能も使える。
一方、Streaming版は、利用者の発話にできるだけ早く追いつき、その内容をリアルタイムで次の処理へ渡すことを重視している。
現時点では、リアルタイム化と引き換えに、後から読み返しやすい記録を作るための一部機能を別に用意する必要がある。
将来、これらの機能が追加される可能性まで否定するものではない。
通話中と終了後でモデルを使い分ける方法もある
この違いを利用し、通話中はStreaming版で認識して応答し、通話終了後に通常版でもう一度処理して、話者分離やタイムスタンプを含む記録を作る構成も考えられる。
これは実際の導入成果を示すものではなく、公開されている機能から考えられる使い分けの一例だ。
同じ音声を2回処理すれば、当然ながら追加の費用が発生する可能性がある。
それでも、
- 会話中は応答速度を優先する
- 終了後は記録品質を優先する
という形で、用途ごとに異なるモデルを使う設計は可能になる。
導入価格だけを比べると、Streaming版の音声時間単価は通常版の5.4倍となる。
0.54 ÷ 0.10 ＝ 5.4
ただし、この比率には言語モデルや音声合成など、その後の処理費用は含まれていない。
また、Streaming版の0.54ドルという価格は2026年12月31日までの導入価格で、その後の単価は今回の資料からは確定できない。
実際の通話1件あたりの費用を見積もるには、後続処理の料金と、導入価格の終了時期を含めて考える必要がある。
同じ声で23言語、日本語の音声合成には非対応
MAI-Voice-2.1とFlash版の対応言語は、音声認識モデルの60言語とは異なる。
通常版のモデルカードとFlash版のモデルカードでは、23言語への対応を掲げている。
対応する言語を切り替えても同じ話者らしい声質を維持し、感情や話し方を発話単位や文単位で指定できるという。
多言語の問い合わせ窓口などで、同じキャラクターの声を保ちながら、内容に応じて話し方を変える用途を想定できる。
声のクローン作成には、5〜60秒の参照音声を使い、追加学習は必要ないとしている。
ただし、短い録音さえあれば誰でも自由に声を複製できるわけではない。
Microsoftによる承認に加え、声を提供する本人が録音した同意音声も必要になる。開発者向け資料にも、申請と同意の手順が記載されている。
Flash版は生成した音声を順次出力できるため、利用者がAIの発話途中に話し始めたとき、再生を止めて次の処理へ移る「割り込み」への対応にも利用できる。
ただし、音声合成モデルが高速だからといって、自然な割り込み処理が自動的に完成するわけではない。
どの時点で再生を止めるのか、利用者が言い直した内容を次の回答へどう反映するのかは、アプリ全体で設計する必要がある。
日本語は認識できるが、新しい音声合成モデルでは話せない
日本語で利用する場合は、音声認識と音声合成を分けて考える必要がある。
MAI-Transcribe-2-Streamingの対応言語一覧には日本語が含まれている。
一方、今回発表されたMAI-Voice-2.1とMAI-Voice-2.1-Flashの対応言語一覧には、日本語が掲載されていない。
英語、中国語、韓国語などには対応するが、日本語の音声会話を今回の3モデルだけで完結できるという根拠はない。
日本語の認識結果に対して、別の日本語対応音声合成モデルを組み合わせるのであれば、その構成で音声品質や応答時間を改めて検証する必要がある。
パブリックプレビューから本番運用までは距離がある
Microsoft Learnでは、MAI-Transcribe-2-Streamingと音声合成モデルの双方をパブリックプレビューと位置付けている。
サービス水準を保証するSLAはなく、本番環境での利用も推奨されていない。
試作品を作れる段階と、顧客対応の窓口を常時任せられる段階は同じではない。
今回そろったのは、
- 音声を文字へ変換する処理
- 文字から音声を生成する処理
である。
その間で質問の意味を理解し、必要な業務情報を調べ、回答を作る言語モデルは別に選ぶ必要がある。
認識と音声合成にかかる時間が短くなれば、その分を回答の検証や外部ツールの利用に充てられる可能性がある。
一方で、検索先やデータベースの応答が遅ければ、音声モデルだけが高速でも会話全体の返答は遅くなる。
実用性は「会話全体」で測る必要がある
採用前には、モデル単体のベンチマークだけでなく、実際の利用環境で会話全体を測る必要がある。
例えば、
- 実際の通信回線で、利用者が話し終えてから音声再生が始まるまで何秒かかるか
- 「金曜、いや木曜」のような言い直しが、予約などの処理へ正しく反映されるか
- AIの発話中に利用者が割り込んだとき、すぐに再生を止められるか
- 割り込み後の次の回答が、訂正された内容を正しく使っているか
- 日本語の人名や商品名、業務用語をどの程度正確に認識できるか
といった点が重要になる。
日本語の業務用語を含む認識精度は、今回示されたランキングだけでは判断できない。
Microsoftは、利用者が話している間から次の処理を始めるための選択肢を増やした。
ただし、実用化できるかどうかを決めるのは、音声認識や音声合成の単体性能だけではない。
利用者が言い直しても誤った操作を行わず、途中で割り込まれても会話を自然に続けられ、導入価格の終了後も現実的な費用で運用できること。
こうした条件を会話全体で確認できれば、発話途中に得られる暫定的な認識結果を、利用者が安心して使える音声応答へつなげられる。
