Azure AI Speech の話者分離と話者認識を整理する
Teams 会議に複数の人が 1 つの会議室から参加し、1 台の PC のマイクで話すと、録音や文字起こしでは発言がその PC の参加者にまとめて紐づくことがあります。「同じ部屋にいた誰が話したのかを分けたい」という相談を受け、Microsoft のサービスだけでどこまで対応できるかを調べました。
この記事では、Azure AI Speech の話者分離と個人を特定する話者認識を切り分け、録音を後処理する構成と、Teams Rooms を使って会議中から名前を付ける構成を整理します。
実際の音声ファイルで Azure AI Speech と GPT-4o の結果を比較したい場合は、話者分離デモを試せます。
目次
- 先に結論
- Azure AI Speech でできること
- 話者分離と話者認識は別の機能
- Azure AI Speech で録音を話者分離する
- 同時発話では何が起きるか
- gpt-4o-transcribe-diarize という代替
- 旧 Speaker Recognition は廃止された
- LLM で話者名を推定する
- Teams の会議室なら Teams Rooms を優先する
- このケースでの選び方
- まとめ
先に結論
今回の要件は、次の 2 段階に分けると判断しやすくなります。
- 誰と誰の発言が違うかを分ける：Azure AI Speech の Diarization（話者分離）を使う
- 分けた話者が誰なのか名前を付ける：Teams Rooms の People Recognition を使うか、文字起こしの内容から Azure OpenAI で推定する
Azure AI Speech の Diarization は、同じマイクに入った音声を Guest-1、Guest-2 のような匿名の話者 ID に分けます。これは声から本人を特定する機能ではありません。
録音済み音声を Azure OpenAI で処理する場合は、gpt-4o-transcribe-diarize も匿名の話者分離を含む代替になります。ただし、2026年8月21日時点では Preview であり、Azure AI Speech の大量 Batch 処理や Custom Speech と同じ機能を持つわけではありません。
以前は、声紋を登録して本人を照合する Azure AI Speaker Recognition がありました。しかし、公式の Azure Updates では 2025年9月30日に廃止された機能として案内されています。2026年8月21日時点で、一般的なアプリケーションから利用できる後継の Azure 話者識別 API は公式に示されていません。
一方、Teams 会議室という今回の用途には、Microsoft Teams Rooms の People Recognition があります。利用者が Teams に音声プロファイルを登録し、会議室側で認識を有効にすると、会議中の文字起こし、会議後の Recap、Copilot で発言者名を扱えます。新しく会議室を設計できるなら、録音後に独自処理を追加するより、まず Teams Rooms を検討するのが自然です。
Azure AI Speech でできること
Azure AI Speech は、音声を扱うアプリケーション向けの機能群です。Speech SDK、Speech CLI、REST API を通じて利用できます。一部の機能は Cloud または Container で実行できます。
| 機能 | 主な用途 |
|---|---|
| Speech to text | Streaming Audio や録音 File を文字に変換する |
| Text to speech | Text を自然な合成音声に変換する |
| Speech translation | 音声を認識し、別の言語へ翻訳する |
| Language identification | Audio から話されている言語を判定する |
| Pronunciation assessment | 発音の正確性や流暢さを評価する |
| Custom Speech | 業界用語や固有名詞に合わせて認識精度を調整する |
| Voice Live | 人と AI Agent が音声で対話する Interface を作る |
Speech to text には、Streaming Audio 向けの Real-time transcription、録音 File を短時間で処理する Fast transcription、大量の録音を非同期処理する Batch transcription があります。
会議室の録音を後から処理する今回の用途では、Fast transcription または Batch transcription が候補です。独自 Application で会議中の Audio Stream を取得できる場合は、Real-time diarization も利用できます。
話者分離と話者認識は別の機能
日本語ではどちらも「誰が話したか」に見えますが、Diarization と Speaker Recognition は答える問いが違います。
| 処理 | 答える問い | 出力例 | 音声プロファイル |
|---|---|---|---|
| Diarization（話者分離） | どの発言が同じ話者か | Guest-1 と Guest-2 | 不要 |
| Speaker identification（話者識別） | 候補者のうち誰が話したか | User A | 事前登録が必要 |
| Speaker verification（話者照合） | 発言者が申告した本人か | Accept／Reject | 事前登録が必要 |
Speech to text の Transparency Noteでは、Diarization は単一 Channel の録音でも話者の声を区別し、文字起こしの各 Segment に Guest1、Guest2 といった Tag を付ける機能として説明されています。
つまり、次のような結果までは Azure AI Speech だけで作れます。
Guest-1: 今日のリリース判定を始めます。
Guest-2: テストはすべて完了しています。
Guest-1: では、田中さんから監視状況をお願いします。
Guest-3: エラー率は通常範囲です。この時点では、Guest-1 が誰なのかは分かりません。同じ声の特徴を使って発言をまとめていますが、組織のユーザーや氏名とは照合していないためです。
なお、Speech SDK の SpeechRecognizer は音声を文字に変換するための Class 名です。個人を特定する旧機能の名称は Speaker Recognition であり、両者は別物です。
Azure AI Speech で録音を話者分離する
録音済みの Teams 会議を後処理する場合、全体の流れは次のようになります。
- Teams の録画または録音を、Speech to text が対応する Audio 形式として用意する
- Fast transcription または Batch transcription で Diarization を有効にする
- Segment ごとの開始時刻、終了時刻、Text、Speaker ID を保存する
- 必要に応じて Azure OpenAI へ文字起こしと会議 Context を渡し、話者名の候補を推定する
- 確信度が低い箇所を人が確認してから議事録へ反映する
Real-time diarization の Quickstartでは、Speech SDK の ConversationTranscriber を使い、認識結果の Speaker ID を取得します。この ID は会話内で割り当てられる汎用的な識別子です。
録音品質は、文字起こしと話者分離の両方に影響します。マイクから遠い人、同時発話、反響、空調音、似た声質は誤りの原因になります。Diarization を有効にしただけで、すべての発言が正確に分かれるとは限りません。処理前に、実際の会議室、参加人数、着席位置、マイクで評価する必要があります。
また、録音と文字起こしには発言内容だけでなく、声という個人に関係する情報が含まれます。会議参加者への通知、同意、保存期間、閲覧権限、削除手順を先に決めます。
同時発話では何が起きるか
Azure AI Speech は、単一 Channel の録音から「誰がいつ話したか」を推定します。しかし、2 人の声が同じ時刻に同じ Microphone へ混ざると、元の Audio に独立した Channel がないため、常に両方の発言を完全に復元できるわけではありません。
Speech to text の Transparency Noteでは、同時発話が文字起こし精度を下げる要因として挙げられています。実際の出力では、次のような失敗を想定します。
- 声量が大きい話者だけが文字起こしされ、もう一方の単語が欠落する
- 2 人の発言が 1 つの Segment に混ざり、片方の Speaker ID にまとめられる
- 発言の途中で Speaker ID が切り替わり、短い Segment に分断される
- Text は合っていても、単語または Segment が別の話者へ割り当てられる
これらは必ず起きる固定動作ではなく、同時発話で精度が落ちたときに現れ得る症状です。公式資料は、重複した音声を常に別々の文字列へ分離する保証を示していません。話者分離の品質は WDER（Word Diarization Error Rate）、文字起こしの品質は WER（Word Error Rate）で分けて評価します。
1 台の会議室 Microphone を使う限り、Model の変更だけでは入力段階で混ざった声を完全には戻せません。同時発話が重要な会議では、実際の着席位置と音量差を含む Test Audio を用意し、「重複区間の WER」「話者割り当ての正解率」「欠落した発言数」を個別に測ります。複数 Channel を保持できる収録機器を使えるなら、Channel 情報も利用する方が分離の手掛かりを増やせます。
gpt-4o-transcribe-diarize という代替
Azure OpenAI の gpt-4o-transcribe-diarize は、Audio を直接文字起こししながら Speaker Label を付ける Model です。Azure AI Speech で Diarization を実行した後に汎用 LLM へ Text を渡す構成ではなく、文字起こしと匿名の話者分離を 1 つの Model で行う別の入口です。
Azure の音声認識技術の選択ガイドでは、録音済み Audio を /audio/transcriptions で処理し、gpt-4o-transcribe-diarize が Speaker Diarization を含むと説明されています。Azure OpenAI の Model 一覧では、2026年8月21日時点で Model Version 2025-10-15 は Preview、Audio File は 1 Request あたり最大 25 MB です。利用可能な Region と Deployment Type は事前に確認します。
| 観点 | Azure AI Speech の Diarization | gpt-4o-transcribe-diarize |
|---|---|---|
| 主な入力 | Real-time Stream、短い録音、大量の録音 | 主に録音済み Audio File |
| 処理 | Speech to text と話者分離 | GPT-4o 系 Model による文字起こしと話者分離 |
| 話者名 | 匿名 ID。本人は特定しない | 匿名 Label。本人は特定しない |
| 大量処理 | Batch transcription がある | File 単位の Audio API。25 MB／Request |
| 調整 | Phrase List、Custom Speech などを選べる | Speech の Custom Speech と同じ調整機能ではない |
| 提供状態 | Speech Service の機能 | Model Version 2025-10-15 は Preview |
gpt-4o-transcribe-diarize を「LLM が文脈から話者名まで判断する機能」と混同しないことが大切です。この Model が付ける Speaker Label と、後段の Azure OpenAI が参加者一覧や発言内容から氏名候補を推定する処理は別です。名前が必要なら、どちらの文字起こし経路を選んでも、後段の推定と人の確認が必要です。
また、公式資料には gpt-4o-transcribe-diarize が同時発話を常に完全分離するという保証はありません。同じ会議録音を Azure AI Speech と両方へ入力し、通常区間と重複区間を分けて WER、話者割り当て、Latency、Cost を比較するのが堅実です。Preview のため、Production 採用では Model 更新、提供 Region、Quota、API 変更への追随も運用計画に含めます。
旧 Speaker Recognition は廃止された
Azure AI Speaker Recognition には、声紋を登録して候補者から話者を選ぶ Speaker Identification API と、申告した本人かを照合する Speaker Verification API がありました。
ただし、Azure AI Speaker Recognition の廃止に関する Azure Updatesでは、2025年9月30日が廃止日として示されています。過去の Limited Access の案内では登録制の機能でしたが、現在は新規受付だけが止まった状態ではなく、廃止日を過ぎています。
公式の廃止案内では、同じ機能を提供する後継の汎用 Azure API は示されていません。Diarization は匿名の話者を分けられますが、登録済みの声紋と照合して本人を特定する代替にはなりません。
Microsoft 製品の範囲で考えると、選択肢は次の 2 つです。
- Teams 会議室で使うなら、Teams Rooms または BYOD Rooms の Speaker Recognition を利用する
- 独自 Application なら、Diarization の結果に対して Azure OpenAI で発言内容から名前を推定し、最終確認を人に残す
後者は声紋認証ではありません。本人確認、Access Control、不正検知の根拠には利用できません。
LLM で話者名を推定する
会議では、発言内容に名前を推定できる手掛かりが含まれることがあります。
- 「インフラ担当の佐藤です」のような自己紹介
- 「田中さん、テスト結果をお願いします」の直後の応答
- 会議招待の参加者一覧と担当 Role
- Agenda に記載された説明担当者
- 「私が作成した Pull Request」のような、事前に分かっている担当情報
これらを Azure OpenAI に渡せば、Guest-2 は田中さんの可能性が高い、と推定できます。実装では、単に氏名へ置換させるのではなく、根拠と確信度を構造化して返します。
{
"speakerId": "Guest-2",
"candidateName": "田中",
"confidence": "high",
"evidence": [
"Guest-1 が田中さんへテスト結果を依頼した直後に応答した",
"参加者一覧で田中がテスト担当になっている"
],
"needsReview": false
}推定処理は次の境界で設計します。
| LLM に任せること | LLM に任せないこと |
|---|---|
| 発言内容と Agenda から候補者を絞る | 声そのものから本人を認証する |
| 根拠と確信度を付ける | 根拠がない発言者へ無理に名前を付ける |
| 同じ Speaker ID の発言をまとめて評価する | 推定結果だけで公式議事録を確定する |
unknown を返す | Attendance や権限確認へ流用する |
Prompt には、参加者の候補を会議招待に含まれる人へ限定すること、明示的な証拠がなければ unknown を返すこと、推定の根拠となる発言を示すことを含めます。氏名を扱うため、入力と出力の保存範囲も最小化します。
この方法は、自己紹介や呼び掛けがある会議では機能します。しかし、「はい」「了解です」のような短い発言だけでは、LLM にも判断材料がありません。LLM は Diarization の不足を補う後処理であり、Speaker Recognition の代替となる生体認証ではありません。
Teams の会議室なら Teams Rooms を優先する
今回のように、Teams 会議へ 1 つの会議室から複数人が参加する用途には、Microsoft Teams Rooms の People Recognitionが用意されています。
Teams Rooms では、初期状態でも会議室内の参加者を Speaker 1、Speaker 2 のように分離できます。さらに Voice Recognition を有効にし、利用者が Teams Desktop App で Voice Profile を登録すると、登録済みの参加者を名前付きで識別できます。未登録の参加者は Speaker X のまま表示されます。
| 構成 | 主な要件 | 特徴 |
|---|---|---|
| Teams Rooms | Windows または Android の Teams Rooms Device、Room Resource Account、Teams Rooms Pro License | 会議室として管理し、Voice Recognition を利用できる |
| BYOD Rooms | Windows／macOS の Teams Desktop Client、USB 接続の Speaker Microphone、Host の Teams Premium または Copilot License | 既存 PC と Microphone を活用できる |
Intelligent Speaker の公式要件では、Teams Rooms は Teams Rooms Pro License、BYOD Rooms は Room Host の Teams Premium または Copilot License が必要です。識別される人は Voice Profile を登録し、予定された会議に招待されている必要があります。日本語は、会議中の文字起こしで Voice Recognition を利用できる言語に含まれます。
Teams Rooms on Windows と Android は Voice Recognition に対応します。Face Recognition は Teams Rooms on Windows と対応 Camera の組み合わせに限られます。今回の要件は発言者の識別なので、まず Voice Recognition を評価します。
認識精度が重要な会議室では、Teams 認定 Intelligent Speaker も候補です。Microsoft は全 Teams Rooms Device へ Speaker Recognition を拡張していますが、複数 Microphone を備えた認定 Intelligent Speaker の方が、音声品質と認識精度で有利になる場合があると説明しています。
このケースでの選び方
相談内容に対する優先順位は次のようになります。
| 状況 | 推奨する方法 |
|---|---|
| 既存の録音を、まず匿名の話者ごとに分けたい | Azure AI Speech の Fast／Batch transcription と Diarization |
| 録音済み Audio を GPT-4o 系 Model で文字起こしと話者分離したい | gpt-4o-transcribe-diarize を比較検証する。Preview であり、1 Request あたり 25 MB の制限を許容できる場合に選ぶ |
| 録音後に、発言内容から名前の候補を付けたい | Diarization と Azure OpenAI。根拠、確信度、人の確認を必須にする |
| Teams 会議中から、会議室内の発言者名を記録したい | Teams Rooms Pro と Voice Recognition |
| 既存 PC と USB Microphone を活かしたい | Teams Premium または Copilot License を持つ Host で BYOD Rooms を検証する |
| 本人認証や Access Control に使いたい | LLM 推定は使わず、別の認証方式を設計する |
まず既存環境で小さく試すなら、同意を得た実際の会議録音を Diarization にかけ、何人まで安定して分離できるかを確認します。その上で、会議参加者一覧と Agenda を使った LLM 推定の正解率と unknown 率を測ります。
継続的な Teams 会議室運用が目的なら、独自 Pipeline の精度改善と保守を続けるより、Teams Rooms または BYOD Rooms で Voice Recognition を検証する方が、会議中の表示、Transcript、Recap、Copilot まで一貫します。
まとめ
Azure AI Speech の Diarization は、1 台の Microphone に集まった複数人の発言を匿名の Speaker ID へ分けられます。ただし、それだけでは氏名は分かりません。同時発話では声が同じ Channel に混ざるため、発言の欠落、混在、誤った話者割り当てを想定し、重複区間を分けて評価する必要があります。
録音済み Audio には、Azure OpenAI の gpt-4o-transcribe-diarize で文字起こしと話者分離を一度に行う選択肢もあります。2026年8月21日時点では Preview で、1 Request 25 MB の制限があります。Azure AI Speech の単純な上位互換ではないため、同じ実録音で精度、Latency、Cost、運用性を比較します。
個人の Voice Profile と照合する旧 Azure AI Speaker Recognition は 2025年9月30日に廃止され、一般的な Application 向けの後継 Azure API は示されていません。Azure OpenAI を組み合わせれば、自己紹介、呼び掛け、参加者一覧、Agenda から話者名を推定できますが、これは内容に基づく推論です。本人確認として扱わず、根拠と確信度を示し、推定できない場合は unknown を返し、人の確認を設計に含めます。
今回のような Teams 会議室の課題には、Teams Rooms の People Recognition が最も直接的な Microsoft の解決策です。Teams Rooms Pro、利用者の Voice Profile、会議 Policy を整えれば、会議室内の発言を名前付きで Transcript、Recap、Copilot へつなげられます。既存 PC を使う場合は、Teams Premium または Copilot License を前提とした BYOD Rooms も比較対象になります。
参考資料
- What is Azure Speech?
- Quickstart: Create real-time diarization
- Use cases for Speech to text
- Choose an Azure speech recognition and generation technology
- Foundry Models sold by Azure: Audio models
- Azure OpenAI image, audio, and video REST API reference
- Azure AI Speaker Recognition retirement
- Speaker Recognition REST API archive
- Manage voice recognition for Intelligent Speaker
- Enable People Recognition on Teams Rooms