--- title: "MAI-Transcribe-2とは？使い方・料金とストリーミング版の実装手順【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18300/" published: 2026-10-13 updated: 2026-10-13 categories: ["AI"] publisher: "株式会社一創" --- # MAI-Transcribe-2とは？使い方・料金とストリーミング版の実装手順【2026年10月】 MAI-Transcribe-2は、Microsoft AIが自社開発した音声認識モデルです。2026年9月3日にファイルを一括で処理するバッチ版が、10月1日には話している最中に文字を返すストリーミング版が公開されました。対応する60言語には、日本語も含まれる仕様です。この記事では、Fast Transcription APIとRealtime APIでの呼び出し方をコード付きで示したうえで、1時間0.10ドルという導入価格の期限、国内リージョンで動かないことの影響、採用と見送りの条件までを扱います。仕様と価格は2026年10月13日時点の公式ドキュメントに基づきます。 ## まとめ：MAI-Transcribe-2の要点と、日本企業が導入前に確かめる条件 MAI-Transcribe-2は、Azure Speechの高速文字起こし（Fast Transcription API）から `enhancedMode.model` を指定して呼び出すバッチ用のモデルです。話者分離、単語単位のタイムスタンプ、製品名などを寄せるキーワードバイアス、フィラーを残すか消すかの出力スタイル切り替えを備えます。ストリーミング版のMAI-Transcribe-2-Streamingは、OpenAIのRealtime APIに近いWebSocketプロトコルか、Speech SDK v1.52.0から使います。 価格はバッチ版が1時間あたり0.10ドル、ストリーミング版が0.54ドル。いずれも2026年末までの導入価格で、恒久価格は公表されていません。 導入前に確かめるべき条件は2つあります。1つ目は、2026年10月13日時点でどちらのモデルも東日本・西日本リージョンでは直接呼べないこと。音声を国内で処理する要件がある案件では、この時点で候補から外れます。2つ目は、全モデルがパブリックプレビューでSLAが付かず、Microsoft自身が本番利用を推奨していないことです。多言語の録音を安く大量に文字起こしする検証や、社内ツールへの組み込みから始めるなら試す価値があります。 ## MAI-Transcribe-2の全体像｜バッチ版・ストリーミング版・音声合成の関係 同じ名前で2つの認識モデルがあり、同時期に音声合成も出ています。まず役割を切り分けます。 ### 9月公開のバッチ版と10月公開のストリーミング版の役割の違い バッチ版の `MAI-Transcribe-2` は、録音済みのファイルを1回のリクエストで送り、全文を受け取る使い方です。[REST APIの参照ページ](https://learn.microsoft.com/en-us/rest/api/speechtotext/transcriptions/transcribe)では、送れる音声は2時間未満かつ250MB未満とされています。形式はWAV・MP3・FLACの3種類です。 ストリーミング版の `MAI-Transcribe-2-Streaming` は、音声を細切れに送り続け、話し終わる前から仮の文字列を受け取る用途に向きます。コールセンターのオペレーター支援、会議や講義の字幕、音声で操作するアプリが想定されています。 機能は同じではありません。話者分離・単語タイムスタンプ・キーワードバイアス・出力スタイルの各パラメータは、バッチ版のドキュメントにだけ載っています。ストリーミング版をRealtime APIで呼ぶ場合、指定できるのは音声形式と言語ヒントに絞られている点に注意してください。 ### FLEURS平均WER5.2%と「10倍速い」という公表値の読み方 [バッチ版の発表](https://microsoft.ai/news/mai-transcribe-2-is-the-fastest-most-accurate-and-cheapest-speech-recognition-model-in-the-world/)によれば、60言語のFLEURSベンチマークで平均単語誤り率（WER）5.2%を記録し、首位とされています。速度はArtificial Analysisの評価をもとに、GPT-Transcribeより10倍、ElevenLabsのScribe v2より7倍、Gemini 3.5 Transcribeより5倍速いという説明です。 読み方には2つの注意が要ります。同じ発表の中で、Artificial AnalysisのWERリーダーボードでは2位とも書かれていること。そして60言語の平均値は、日本語単独の精度を示していないことです。日本語のWERは公表されていません。 ストリーミング版は[10月1日の発表](https://microsoft.ai/news/our-first-streaming-transcription-model/)で、Artificial Analysisの暫定結果と確定結果の両方で精度1位、最初の暫定結果が音声受信から100ミリ秒強で返るとされました。いずれもMicrosoftの発表値です。自社の録音で、固有名詞と数字の誤りを数えて確かめる前提で読んでください。 ### 前世代1.5から増えた17言語とMAI-Voice-2.1の位置づけ [Microsoft Learnの言語表](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/mai-transcribe)を数えると、MAI-Transcribe-1.5の43言語に対し、2ではアフリカーンス語・ペルシャ語・ヘブライ語・広東語など17言語が増えています。日本語（`ja`）は1.5から対応済みです。初代のMAI-Transcribe-1は2026年8月20日に非推奨になりました。 ストリーミング版と同じ日に、音声合成のMAI-Voice-2.1とMAI-Voice-2.1-Flashも公開されています。2.1は23言語・26ロケールに対応し、価格は100万文字あたり22ドル。Flashは1回に45秒まで生成でき、エンドツーエンドの遅延150ミリ秒、価格は100万文字あたり15ドルです。認識から合成まで同じMAIシリーズでそろえる構成が取れるようになりました。同シリーズのセキュリティ特化モデルについては[MAI-Cyber-1-Flashの解説](https://www.issoh.co.jp/tech/details/15792/)で扱っています。 ## MAI-Transcribe-2のREST実装｜録音送信と話者分離の指定 バッチ版は新しいエンドポイントではなく、既存の高速文字起こしAPI（Fast Transcription API）にフラグを足して呼び出します。 ### Speechリソースの作成と日本から使う対応6リージョンの選び方 必要なのはAzureサブスクリプションと、Speech用のMicrosoft Foundryリソースです。Foundryのリソース構成や料金体系の全体は[Microsoft Foundryの解説](https://www.issoh.co.jp/tech/details/10568/)にまとめています。 リージョン選びで最初につまずきます。[リージョン一覧のLLM speechタブ](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/regions?tabs=llmspeech)でMAI-Transcribeに対応しているのは、centralindia・eastus・northeurope・southeastasia・westus・westus2の6つだけ。japaneastもjapanwestも入っていません。日本から使うなら、地理的に近いsoutheastasiaが現実的な選択肢になります。Speechのキーはリージョン単位で発行されるため、別リージョンのキーを使うと認証エラーになります。 ### curlで会議録音を送り話者分離付きの日本語テキストを得る手順 公式のcurl例に、話者分離・単語タイムスタンプ・clean出力・キーワードバイアスをまとめて足した形です。`YOUR_RESOURCE` と `YOUR_KEY` は自分の値に置き換えます。 ``` curl --location 'https://YOUR_RESOURCE.cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15' \ --header 'Ocp-Apim-Subscription-Key: YOUR_KEY' \ --form 'audio=@"meeting_20261013.wav"' \ --form 'definition={ "enhancedMode": { "enabled": true, "model": "MAI-Transcribe-2", "modelOptions": { "transcribeStyle": "clean", "timestamps": "word" } }, "diarization": {"enabled": true}, "phraseList": {"phrases": ["一創", "Microsoft Foundry", "見積書"]} }' ``` 応答の `phrases` 配列には、話者分離を有効にすると話者番号の `speaker` が、単語タイムスタンプを有効にすると語ごとの `words` が入ります。全文は `combinedPhrases` にまとまって返る構造です。 ### 話者分離・タイムスタンプ・出力スタイルの既定値と録音用途別の指定方法 話者分離の `diarization`、タイムスタンプの `timestamps`、出力スタイルの `transcribeStyle` は既定で無効か控えめな値になっているため、必要なものだけを明示します。表の出力スタイルは `modelOptions.transcribeStyle` を指します。 | パラメータ | 既定値 | 指定できる値 | 使う場面 | | ------------------------- | -------- | --------------------- | ------------- | | `diarization.enabled` | false | true / false | 会議・通話の話者別記録 | | `modelOptions.timestamps` | none | word / segment / none | 字幕の同期、録音の頭出し | | 出力スタイル | verbatim | verbatim / clean | 監査用は逐語、公開用は整形 | | `phraseList.phrases` | 空配列 | 文字列の配列 | 社名・製品名・略語 | | `locales` | 自動判定 | 言語コード1つ | 自動判定が外れる場合のみ | 見落としやすいのが2点あります。話者分離を有効にすると、扱える録音の長さが無効時より短くなるとドキュメントに明記されています。2時間の録音を丸ごと送る前に、分割して送る設計にしてください。もう1つは `locales` で、モデルへの非常に強いヒントになるため、録音の言語が確実で自動判定が機能しない場合以外は指定しないよう求められています。日英が混ざる会議では指定しないほうが安全です。キーワードバイアスも「強制ではなくヒント」と書かれており、登録した語が必ず出力されるわけではありません。 ## MAI-Transcribe-2-Streamingの接続設定と字幕表示の実装 ストリーミング版は接続方式を2つから選べます。ここではMAI-Transcribe-2-StreamingをOpenAI互換のRealtime APIで動かすWebSocket実装として、接続設定から字幕表示までの手順を示します。 ### Foundryでのモデルデプロイと接続URL・認証ヘッダーの組み立て [Realtime APIのガイド](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/mai-transcribe-2-streaming-realtime)では、先にFoundryポータルの「Build」から `MAI-Transcribe-2-Streaming` をデプロイし、そのデプロイ名を設定で指定します。接続先は `wss://{リソース名}.services.ai.azure.com/mai/v1/realtime?intent=transcription` です。 認証はMicrosoft EntraのBearerトークンが推奨で、`api-key` ヘッダーも使えます。ブラウザーからは接続前のヘッダーを付けられないため、クエリ文字列でキーを渡す方法も用意されています。ただし、キーをフロントエンドへ置く構成は避け、サーバー側で中継してください。 もう一方の[Speech SDK経由](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/mai-transcribe-2-streaming-speech-sdk)はv1.52.0が必要で、`speech_config.model` に `mai-transcribe-2-streaming` を入れるだけで既存の連続認識コードが動きます。接続管理や再試行をSDKに任せたいならこちらを選びます。 ### session.updateでPCM16・16kHzを宣言しWAVを流すPython例 16kHz・モノラル・16bitのWAVファイルを実時間相当で送り、暫定と確定の文字列を表示する最小の例です。公式ガイドのイベント仕様に沿って、マイク入力の部分をファイル読み込みに置き換えています。`pip install websockets` で依存を入れ、環境変数を設定してから実行します。 ``` import asyncio import base64 import json import os import wave from websockets.asyncio.client import connect # 例: https://my-resource.services.ai.azure.com を wss の接続URLへ組み替える ENDPOINT = os.environ["AZURE_MAI_ENDPOINT"].rstrip("/") URL = ENDPOINT.replace("https://", "wss://") + "/mai/v1/realtime?intent=transcription" HEADERS = {"api-key": os.environ["AZURE_MAI_API_KEY"]} DEPLOYMENT = os.environ["AZURE_MAI_DEPLOYMENT_NAME"] CHUNK_MS = 20 # 遅延を詰めるなら10〜20ミリ秒単位で送る async def wait_for(ws, event_type): while True: event = json.loads(await ws.recv()) if event.get("type") == "error": raise RuntimeError(event) if event.get("type") == event_type: return async def receive(ws): finalized = "" # delta で確定した文字列を積み上げる while True: event = json.loads(await ws.recv()) kind = event.get("type", "") if kind.endswith("transcription.delta"): finalized += event["delta"] elif kind.endswith("transcription.intermediate"): # 暫定部分は毎回まるごと置き換わる print("\r" + finalized + event["intermediate"], end="", flush=True) elif kind.endswith("transcription.completed"): print("\n[確定]", event["transcript"]) return elif kind == "error" or kind.endswith("transcription.failed"): raise RuntimeError(event) async def main(path): async with connect(URL, additional_headers=HEADERS) as ws: await wait_for(ws, "session.created") # 音声を1バイトでも送った後は設定を変えられないので最初に送る await ws.send(json.dumps({ "type": "session.update", "session": { "type": "transcription", "audio": {"input": { "format": {"type": "audio/pcm", "rate": 16000}, "transcription": {"model": DEPLOYMENT, "language": None}, "turn_detection": None, "noise_reduction": None, }}, }, })) await wait_for(ws, "session.updated") receiver = asyncio.create_task(receive(ws)) with wave.open(path, "rb") as wav: if (wav.getframerate(), wav.getnchannels(), wav.getsampwidth()) != (16000, 1, 2): raise ValueError("16kHz・モノラル・16bitのWAVを指定してください") frames = wav.getframerate() * CHUNK_MS // 1000 while chunk := wav.readframes(frames): await ws.send(json.dumps({ "type": "input_audio_buffer.append", "audio": base64.b64encode(chunk).decode("ascii"), })) await asyncio.sleep(CHUNK_MS / 1000) # サーバー側の発話検出がないため、区切りは自分で commit する await ws.send(json.dumps({"type": "input_audio_buffer.commit"})) await receiver asyncio.run(main("sample_16k_mono.wav")) ``` 音声はWAVヘッダーを含まない生のPCM16をbase64にして送る仕様です。`wave` モジュールの `readframes` はヘッダーを除いたサンプルだけを返すため、そのまま送れます。サンプリングレートは16000か24000の2択です。 ### intermediateとdeltaの2イベントで字幕を描画する組み方 受信側の作りを誤ると、字幕が二重に表示されたり単語がつながったりします。ガイドが定めるイベントは次の4種類です。表では `...transcription.intermediate` を「暫定結果」、`input_audio_buffer.committed` を「commit受理」、`...transcription.completed` を「確定全文」と表記します。 | イベント | 中身 | クライアントの扱い | | ------------------------ | --------------- | -------------- | | `...transcription.delta` | 新たに確定した部分 | 確定バッファへ追記する | | 暫定結果 | 確定部分より後ろの暫定全体 | 前回の暫定を丸ごと置き換える | | commit受理 | commitの受理 | 確定処理はこの後も続く | | 確定全文 | 前回commit以降の確定全文 | 保存用の全文として使う | `intermediate` はMAI独自のイベントで、OpenAIのRealtime APIには存在しません。画面に出す文字列は「これまでのdeltaの連結＋最新のintermediate」です。deltaを連結するときに空白を足したり削ったりしないよう、ガイドは明示しています。OpenAI向けに書いた受信処理を流用する場合は、このイベントを読み飛ばすと暫定表示が出ないことになります。 ### サーバー側VADなし・1セッション1時間上限を前提にしたcommit設計 Realtime APIの `turn_detection` と `noise_reduction` は `null` しか受け付けません。サーバーが発話の区切りを判定しないため、クライアントが無音を検出して `input_audio_buffer.commit` を送る必要があります。公式のマイク入力サンプルは、3秒分の音声がたまるごとにcommitする実装でした。 もう1つの制約は、1セッションが最長1時間であることです。会議を通しで字幕化するなら、55分前後で新しいセッションを張り直し、確定済みの文字列を引き継ぐ処理を最初から組み込んでください。コールセンターの通話は大半が1時間に収まるため、通話ごとに1セッションを張る設計で足ります。 ## 料金と提供条件｜導入価格の適用期限と国内リージョン非対応の影響 単価が安いことは確かです。ただし、その単価が続く期間と、音声がどこで処理されるかを合わせて見ないと判断を誤ります。 ### 1時間0.10ドルと0.54ドルの導入価格が年末で切れる前提の試算 月1,000時間の録音を処理するケースで計算します。バッチ版なら月100ドル、ストリーミング版なら月540ドル。どちらも2026年12月31日までの導入価格で、2027年以降の価格は2026年10月13日時点で公表されていません。年をまたぐ予算を組むなら、導入価格を前提にした見積もりは避け、従来のAzure Speechの単価で上限を置いておくのが安全です。既存の標準モデルの料金体系は[Azure AI Speechの料金解説](https://www.issoh.co.jp/tech/details/5335/)で確認できます。 なお、ここで使った単価の出典はMicrosoft AIの発表ページです。Realtime APIのガイドは料金の参照先としてFoundry Modelsの料金ページを案内しているため、契約前には請求単価をそちらでも突き合わせてください。 ### 東日本・西日本で動かない構成と国内処理の要件に関わる音声データの処理場所 [ストリーミング版の概要ページ](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/mai-transcribe-2-streaming)が挙げる提供リージョンは、swedencentral・centralus・eastus2・southeastasiaの4つです。バッチ版の6リージョンと合わせても、国内は1つもありません。 Azure Speechは、リソースを作ったリージョンで音声を保存・処理すると明記しています。例外はVoice Liveで、japaneastのリソースから `mai-transcribe-2` を入力音声の認識に使えますが、処理範囲は「Global」と表示されています。つまり国内リソースを経由しても、認識処理が国外で行われうる構成です。医療・金融・自治体のように音声を国内に留める契約がある案件では、2026年10月13日時点では採用できません。 ### パブリックプレビューでSLAなし・本番非推奨という条件の重さ Microsoft Learnの各ページには、SLAなしで本番ワークロードには推奨しないという注記が付いています。適用されるのは[Azureプレビューの補足利用規約](https://azure.microsoft.com/en-us/support/legal/preview-supplemental-terms/)で、機能の制限や変更がありうる前提です。 実務上の影響は、障害時に返金や補償を求められないことと、パラメータの仕様が予告なく変わりうることの2つ。顧客向けサービスの中核に据えるなら、従来モデルへ切り替えられる経路を残しておくべきです。 ## MAI-Transcribe-2を採用する条件と見送るべき場面の判断基準 ここまでの仕様と制約を踏まえ、採否を条件付きで言い切ります。 ### 採用が見合う場面｜多言語の録音を安く一括で文字起こしする用途 採用を勧めるのは、次の条件がそろう場合です。録音済みの音声を後からまとめて処理できる。英語・中国語・東南アジアの言語が混ざる。音声を国外リージョンで処理することに契約上の制約がない。たとえば海外拠点との会議録や、多言語のコールログを月数百時間単位で検索可能にする社内基盤なら、話者分離と単語タイムスタンプが1回のリクエストで返る点がそのまま工数削減になります。 検証の進め方としては、既存の文字起こし結果と同じ録音を流し、固有名詞・数字・話者の取り違えを数えて比較するのが確実です。こうした比較検証からシステムへの組み込みまでを外部に任せたい場合は、[AI音声認識システム開発](https://www.issoh.co.jp/service/ai/speech%5Frec/)で要件整理から相談を受けています。 ### 見送る場面｜国内処理必須・長時間の話者分離・SLA必須の案件 次のいずれかに当たるなら、現時点では見送ります。 - 音声データを国内リージョンで処理する契約・規程がある - 2時間近い録音を分割せずに話者分離したい - 顧客向けサービスの中核で、SLAと障害時の補償が必要 - ストリーミングで話者ラベルや単語タイムスタンプを取りたい 最後の条件は見落とされがちです。ストリーミング版のドキュメントには、話者分離もキーワードバイアスも設定項目として載っていません。ライブの字幕はストリーミング版、確定版の議事録は録音をバッチ版へ流して話者分離する、という二段構成にすれば回避できます。 ### GPT-Live-Transcribeなど他社ストリーミングと比べる3つの軸 競合として並ぶのはOpenAIの[GPT-Live-Transcribe](https://www.issoh.co.jp/tech/details/15859/)です。どちらもRealtime APIに近いプロトコルで動くため、比較の軸は性能より運用条件に置きます。 1つ目は暫定結果の扱いで、MAIは独自の `intermediate` で暫定全体を置き換える方式です。2つ目は文脈指定で、MAIのストリーミング版は言語ヒントしか受け付けません。3つ目はデータの処理場所と契約で、Azureの既存契約や閉域接続の中に収めたい企業にはMicrosoft側が有利になります。主要な文字起こしAPIを料金と日本語対応で横並びにした比較は[文字起こしAPIの比較と選び方](https://www.issoh.co.jp/tech/details/2981/)にまとめています。 ## よくある質問 MAI-Transcribe-2の導入を検討する際によく出る疑問に答えます。 ### MAI-Transcribe-2は日本語の文字起こしに対応していますか？ 対応しています。Microsoft Learnの言語表で、バッチ版・ストリーミング版とも日本語（ja）にチェックが入っています。既定は多言語モードで言語を自動判定するため、日本語の録音でも言語指定は不要です。ただし公表されている精度は60言語平均のWER5.2%で、日本語単独の数値は2026年10月13日時点で公開されていません。社内の実際の録音で、固有名詞と数字の誤り率を確かめてから判断してください。 ### 無料で試す方法はありますか？ Microsoft AIの発表によれば、ブラウザーで試せるMAI Playgroundにデモが用意されています。APIとして呼ぶ場合はAzureサブスクリプションとSpeech用のFoundryリソースが必要で、導入価格のバッチ版は1時間0.10ドルかかります。10分の録音なら1本あたり約0.017ドルで、数本流しても1ドルに届かない計算です。OpenRouterからも呼び出せるため、Azureの契約前に精度だけ確かめる経路もあります。 ### Whisperや従来のAzure Speechの標準モデルから乗り換えるべきですか？ 本番の処理系をすぐに置き換えるのはおすすめしません。MAI-Transcribe-2はプレビューでSLAがなく、国内リージョンにも対応していないためです。乗り換えを検討する価値があるのは、多言語の録音が多く、国外処理の制約がない場合に限られます。まずは同じ録音を両方に流し、精度と処理時間と費用を並べて比べる検証から始めてください。 ### ストリーミング版で話者を分けた字幕は作れますか？ 2026年10月13日時点のストリーミング版では作れません。Realtime APIの設定項目は音声形式・モデル・言語ヒントに限られ、話者分離のパラメータがないためです。会議の字幕はストリーミング版で表示し、終了後に録音をバッチ版へ送って `diarization` を有効にした確定版を作る二段構成が現実的です。この場合、話者分離時は扱える録音長が短くなる点にも配慮が要ります。 ### MAI-Transcribe-1や1.5を使っている場合はどうすればよいですか？ MAI-Transcribe-1は2026年8月20日に非推奨となったため、早めに移行してください。1.5から2への変更は、リクエストの `enhancedMode.model` の値を書き換えるだけで済みます。2では対応言語が43から60に増え、話者分離・単語タイムスタンプ・出力スタイルの指定がドキュメント上で2向けの機能として整理されました。これらを使う場合は2を指定する必要があります。 ## 関連記事 - [音声認識とは？AIの仕組み・精度の考え方・業務導入の判断基準を解説](https://www.issoh.co.jp/column/details/12929/)：音声認識の基本と導入判断の全体像。 - [AI議事録・自動文字起こしとは？仕組み・精度・法人での選び方](https://www.issoh.co.jp/column/details/15434/)：議事録業務として導入する場合の選び方。 - [gpt-4o-transcribe-diarizeとは？話者分離の使い方・料金と2027年2月の提供終了への備え](https://www.issoh.co.jp/tech/details/9861/)：話者分離を他社モデルで組む場合の比較材料。 - [音声合成AIとは？仕組み・音声認識との違い・業務での使いどころと導入判断](https://www.issoh.co.jp/column/details/16421/)：MAI-Voice-2.1と組み合わせる音声合成の基礎。 - [WhisperをPyTorchで動かす手順](https://www.issoh.co.jp/tech/details/1541/)：音声を外部に出せない場合の自前実装。 --- 出典: [MAI-Transcribe-2とは？使い方・料金とストリーミング版の実装手順【2026年10月】]()（株式会社一創）