音声文字起こしを選ぶとき、長く基準になってきたのがWhisperだ。
しかし会議字幕や音声エージェントでは、録音を最後まで受け取ってから高精度に処理するだけでは足りない。
話している途中から文字が出て、発話の区切りをすばやくアプリへ返せることが重要になる。
MicrosoftのMAI-Transcribe-2-Streamingは、このリアルタイム用途を前提にしたSpeech-to-Textモデルだ。
Realtime APIへ音声を連続送信し、途中結果を更新しながら最終結果を確定する。
日本語も公式対応言語に含まれる。
ただし現在はPublic Previewであり、「日本語対応」という仕様と、固有名詞や雑音を含む実際の日本語会議でどこまで正確かは分けて評価したい。
MAI-Transcribe-2-StreamingはMicrosoft AIの音声認識モデルで、リアルタイム転写向けに設計されている。
音声ストリームを送ると、話者が発話中の段階からincremental transcriptsを返し、後からfinal resultで各セグメントを確定する。
これは録音ファイルを一括アップロードするバッチ文字起こしと異なる。
字幕、音声エージェント、ライブ会議など「相手が話し終わる前後にアプリが反応する」用途で価値が出る。
一方、Public Previewでは機能制約がある。
Microsoft LearnはSLAがなく、本番ワークロードには推奨しないと明記しているため、正式版と同じ可用性を前提に組み込むべきではない。
Microsoft公式ドキュメントではMAI-Transcribe-2は60言語に対応し、Japanese（ja）も一覧に含まれる。
Streaming APIではlanguageを明示でき、nullならautomatic detectionとして動作する。
多言語会議では言語を固定しない運用が便利だが、自動判定がすべての日本語・英語混在会話を同じ精度で処理する保証はない。
製品説明上のlanguage supportと、自社音声でのWERや固有名詞精度は別の評価項目だ。
導入前には会議室マイク、オンライン会議、電話音声、専門用語など実際の入力条件を使い、誤認識と確定タイミングを測りたい。
ストリーミング認識では、途中結果が早く出ても、その文字列は後から書き換わる。
ユーザー体験を左右するのは、最初のpartial result、安定したpartial、final result、アプリ側が応答を始めるまでの合計だ。
MicrosoftのRealtime APIは音声を連続的に送り、intermediate resultsを更新する。
現在の仕様ではserver-side turn detectionやnoise reductionはnullのみで、自動commitをサービスへ任せる構成ではない点にも注意が必要だ。
音声エージェントなら、ASR単体のレイテンシーだけでなくVAD、ネットワーク、LLM推論、音声合成まで含めてend-to-endで測る。
音声認識は「100万token」より音声1分・1時間で考える方が予算を立てやすい。
MAI-Transcribe-2-Streamingの価格はMicrosoftのAzure／Foundry側の料金ページと利用リージョンを基準に確認する必要があり、preview期間の導入価格がある場合も恒久価格として扱わない。
比較対象のOpenAI APIでは、2026年10月6日時点でwhisper-1が0.006ドル／分、つまり単純換算で0.36ドル／音声1時間。
現行のOpenAI transcription系にはgpt-transcribe 0.0045ドル／分、gpt-4o-mini-transcribe 0.003ドル／分、リアルタイム系は別料金のモデルもある。
価格だけなら最安モデルを選びたくなるが、ライブ用途では遅延、同時接続、リージョン、SLA、開発工数も総コストになる。
Microsoft LearnのQuickstartでは、MAI-Transcribe-2-StreamingをFoundryでdeploymentし、Realtime APIへWebSocketで接続する。
認証後、session.updateで入力音声形式、model deployment、languageなどを設定する。
対応入力の例はraw signed little-endian PCM16、mono、16kHzまたは24kHz。
モデル名にはFoundry上のdeployment nameを指定する。
音声チャンクを継続送信し、返ってくるintermediateとfinal eventをUIや後続処理へ渡す。
preview中は仕様変更も想定し、SDKやAPI versionを固定して検証環境を持つ方がよい。
Whisperという言葉は、OpenAIのAPIモデルとGitHubで公開されたオープンソースモデルの両方を指すことがある。
比較ではここを分けないと判断を誤る。
リアルタイム性を最優先するならMAI-Transcribe-2-Streamingを実測する価値がある。
録音後処理や完全ローカルが必要ならWhisper系が依然有力だ。
ライブ会議で画面へ字幕を出すなら、途中結果が頻繁に返るStreaming型が使いやすい。
発話中に文字が更新されるため、視聴者は文末まで待たずに内容を追える。
ただし日本語では文末まで意味が確定しにくいことがあり、partial transcriptの書き換えが目立つ場合がある。
字幕UIでは確定前の文字を薄く表示するなど、モデル精度だけでなく表示設計も必要だ。
議事録として残す場合は、ライブ字幕の結果をそのまま最終版にせず、録音後に再処理したり、固有名詞辞書やLLMによる整形を別工程で行う選択肢もある。
音声エージェントでは「文字起こしが正しいか」だけでなく「いつ次の処理を開始できるか」が重要だ。
partial resultを使って先読みできれば、LLMの応答開始を早められる可能性がある。
一方、途中結果で重要な操作を確定すると誤認識が事故につながる。
住所、金額、契約変更、本人確認などはfinal resultや復唱を待つ設計が必要になる。
コールセンターでは日本語の固有名詞、電話品質、方言、重なり発話を含む自社データで評価する。
60言語対応という仕様だけで本番品質を判断しない。
リアルタイム性が不要なら、Streamingモデルを使う理由は小さくなる。
大量の録音を夜間バッチ処理する場合は、単価、並列処理、話者分離、timestamp、長時間音声への対応が重要だ。
Microsoftには非StreamingのMAI-Transcribe-2もあり、enhanced modeなど別機能を持つ。
Whisper系もクラウドAPIとローカル処理を選べる。
機密性が高く外部送信を避けたい録音では、OSS Whisperを自社GPUで動かす利点が大きい。
逆にGPUを管理したくない小規模チームならクラウドAPIの方が総工数を抑えやすい。
MAI-Transcribe-2-StreamingはPublic Previewで、MicrosoftはSLAなし、production workloads非推奨としている。
本番のコールセンターを全面移行するなら正式提供後のSLAやリージョンを確認したい。
音声は個人情報や機密情報を含みやすい。
クラウドAPIでは利用するAzure／OpenAI契約のデータ処理条件、保存、リージョン、アクセス制御を確認する。
ローカルWhisperは音声を外部へ送らずに処理できるが、自社側で保存、暗号化、ログ、アクセス権を管理する責任が残る。「
ローカルだから自動的に安全」でもない。
MAI-Transcribe-2-Streamingは、Microsoftがリアルタイム音声認識へ明確に寄せたモデルだ。
日本語を含む60言語を公式サポートし、Realtime APIで途中結果を更新しながら文字起こしできる。
Whisperと比較すると、選択軸は精度だけではない。
ライブ字幕や音声エージェントなら低遅延ストリーミング、録音後処理なら単価と最終精度、機密音声ならローカル実行の可否が効いてくる。
現在はPublic Previewなので、本番採用ではSLAと提供地域を慎重に見る必要がある。
自社の日本語音声で、partialからfinalまでの遅延、固有名詞精度、1時間あたりの総コストを同じ条件で測ってから選ぶのが確実だ。
.png){kind=logo}
