Whisperなどを使えば会議音声を高精度に文字起こしできる。
しかし3人、4人と参加者が増えると、「この発言は誰のものか」が分からない議事録になりやすい。
そこで使われるのがSpeaker Diarization、つまり話者分離だ。
NVIDIAのNeMo Speechでは、Sortformerを使って音声の時間軸に話者ラベルを付けられる。
リアルタイム処理向けのStreaming Sortformerと、録音後にまとめて処理するOffline Sortformerが用意されている。
ここで注意したいのは、話者分離と文字起こしは別工程だという点だ。
Diarizationだけでは発言内容はテキストにならない。
ASRと組み合わせて初めて「誰が、何を話したか」を扱える。
「Nemotron 3 Diarization」という呼び方で検索されることがあるが、NVIDIAの現行ドキュメントでは話者分離機能はNeMo SpeechのSpeaker Diarizationとして整理され、推奨モデルにStreaming SortformerとOffline Sortformerが挙げられている。
Sortformerは音声フレームから各話者が発話している確率を推定し、時間軸へ話者ラベルを付ける。
NVIDIAのVoice AgentではSTTの直後にDiarization処理を置き、LLMへ渡すテキストにspeaker tagを追加する構成が採用されている。
つまり単独の文字起こしAIではなく、音声パイプラインの中で「話者情報を補う部品」と理解すると分かりやすい。
ASRは「何を話したか」を文字へ変換する。
一方、Diarizationは「いつ、誰が話したか」を推定する。同じ音声を入力しても出力の目的が違う。
実務では両方を統合する。
たとえばASRが「次の施策は来週決めます」と文字化し、Diarizationがその時間帯をspeaker_2と判定すれば、「Speaker 2：次の施策は来週決めます」という形にできる。
今回のブリーフには「最大8人」とあったが、2026年9月25日時点のNVIDIA公式ドキュメントでは推奨Sortformerは最大4話者として説明されている。
Voice Agentで標準採用されるnvidia/diar_streaming_sortformer_4spk-v2.1も4spkモデルだ。
さらに標準Voice Agent実装では1つのVAD turnにつきdominant speakerを1人だけ返す。
そのため同じ瞬間に2人が重なって話しても、標準パイプライン上では1つのspeaker tagへまとめられる。
4人を超える会議では、TitaNetを使うcascaded NeMo pipelineなど別方式が候補になる。
NVIDIAはTitaNetベースのクラスタリング方式について固定のアーキテクチャ上限を設けない構成を案内しているが人数が増えるほど識別は難しくなる。
NVIDIAのVoice Agent標準設定はdeviceにcudaを使う。
ASRとDiarizationが同じdevice設定を共有するため、リアルタイム音声エージェント用途ではCUDA GPUを前提にした構成が分かりやすい。
一方、録音ファイルを後処理する用途ではリアルタイム性が必須ではない。
CPU実行可能なランタイムやコミュニティ実装を使える場合、GPUなしでも処理できる可能性はあるがNVIDIA公式の特定GPU測定値を一般CPUへそのまま換算してはいけない。
必要スペックは「モデルが読み込めるか」より、音声1分を何秒で処理したいかで決める。
会議終了後に数分待てるならCPUも候補になるが、会話中にspeaker tagを付けたいならGPUの優先度が上がる。
NVIDIA NeMoを使う標準ルートではPython環境とPyTorch、NeMo Speechを用意し、Hugging Faceまたはローカル.nemoファイルからSortformerを読み込む。
Voice Agentの設定例ではnvidia/diar_streaming_sortformer_4spk-v2.1がデフォルトモデルでthresholdは0.5、frame_len_in_secsは0.08秒。
モデルは初回にHugging Faceから取得される。
ローカル化の利点は、会議音声を外部の文字起こしAPIへ送信せず処理できることだ。
ただしモデル取得時の通信や、ASR側にクラウドAPIを使っていないかも確認したい。
録音済み会議ではリアルタイムモデルにこだわる必要はない。
NVIDIAは「Determine who spoke when」の用途にStreaming SortformerとOffline Sortformerを推奨し、リアルタイムならstreaming、バッチならofflineと使い分けている。
基本フローは、音声ファイルの前処理→Diarization→ASR→タイムスタンプ統合だ。
Diarizationの区間とASRの単語・文タイムスタンプを突き合わせ、各発言へspeaker labelを付ける。
動画制作者なら、この出力を字幕生成へ流用できる。
ポッドキャストなら出演者別の発言時間集計などにも展開できる。
リアルタイム処理では短い音声を逐次モデルへ渡す。
Voice Agentの標準実装ではraw frameが16msで届き、80ms単位へまとめてモデルを呼び出す。
短いバッファは反応を速くできる一方、話者を判断する音声情報が少なくなる。
長く取れば判断材料は増えるが、speaker labelが確定するまでの遅延が増える。
会議用途では「最小遅延」を目指すより、誤って話者が頻繁に切り替わらない範囲でバッファを調整する方が実用的だ。
Whisperやfaster-whisperは発言内容を文字へ変換する役割を担当し、Sortformerは話者区間を担当する。
両方がタイムスタンプを持てば統合できる。
実装では、ASRセグメントの開始・終了時刻とDiarizationの話者区間の重なりを計算し、最も長く重なる話者を割り当てる方法が分かりやすい。
単語タイムスタンプを使えば、発言途中で話者が変わるケースも細かく処理できる。
LLMへ渡す前に「speaker_0」「speaker_1」のラベルを実名へ対応付ければ、会議要約、決定事項、担当者別ToDoの抽出まで自動化しやすくなる。
Diarizationは音声の言語内容そのものより声の特徴や時間構造を扱うため、ASRほど「日本語モデルか」が直接の条件にはなりにくい。
ただし、日本語会議で高精度だと無条件に断定することもできない。
アクセント、似た声質、短い相づち、重なり発話、会議室の反響、遠いマイクなどで誤認識が増える可能性がある。
NVIDIAのVoice Agentドキュメントもノイズや似た声で混同しやすい点を明記している。
導入前には実際の会議室、マイク、参加人数で録音し、DERだけでなく「議事録を人が直す時間がどれだけ減るか」を測るとよい。
機密会議では、音声そのものが重要情報になる。
ローカルDiarizationとローカルASRを組み合わせれば、音声を外部APIへ送らずに処理できる構成を作れる。
ただし「ローカルだからプライバシー問題がなくなる」わけではない。
録音ファイルの保存場所、アクセス権、バックアップ、削除期限、モデルが生成した議事録の共有範囲まで設計する必要がある。
クラウドストレージへ自動同期するPCなら、処理自体がローカルでも録音ファイルが外部へアップロードされる可能性がある。
モデルの利用条件は使用するチェックポイントごとに確認する。
NVIDIAのモデルカードに記載されたライセンスだけでなく、NeMo、ASR、周辺ライブラリのライセンスも企業利用では記録しておきたい。
会議録音では技術的に録音できることと、録音してよいことは別問題だ。
社内規程、就業規則、取引先との秘密保持、個人情報の扱いを確認し、必要に応じて参加者へ録音・AI処理を伝える。
特に顧客相談、採用面接、医療・金融などセンシティブな情報を含む場面では保存期間と利用目的を明確にすることが重要になる。
NVIDIAのSpeaker Diarizationを使うと、Whisperだけでは不足しがちな「誰が話したか」を会議音声へ追加できる。
文字起こしと話者分離を別工程として考えることが、最初のポイントだ。
2026年9月時点のNVIDIA公式推奨Sortformerは標準4話者で、Voice Agentの標準実装では1ターン内の重複発話をdominant speakerへまとめる。
8人対応を前提に選ぶのではなく、参加人数と重なり発話の多さに応じてSortformerかcascaded pipelineかを選びたい。
ローカル処理の価値は、音声を外へ出さず議事録を作れることにある。
まず実際の会議音声で話者精度と処理速度を測り、その後Whisperなどと統合する方が失敗しにくい。
.png){kind=logo}
