話者ダイアライゼーションとは？仕組みと活用例
- 公開日
話者ダイアライゼーションは、話者数が不明なオーディオストリームから、ラベル付きセグメントのタイムラインを生成します。たとえば、0:00～0:42は話者A、0:42～1:15は話者B、1:15以降は再び話者Aといった形です。システムは話者が誰なのかは把握していませんが、別人であることを認識し、録音全体でラベルの一貫性を保ちます。
この処理により、複数話者のオーディオを活用できるようになります。会議メモ、コールセンター分析、インタビューの文字起こし、ポッドキャスト編集、法的記録では、何が話されたかだけでなく、誰が話したかを把握することが重要です。
このガイドでは、ダイアライゼーションの仕組み、セグメンテーションや識別など関連技術との違い、利用できるオープンソースツール、ダイアライゼーションシステムの性能を測定する方法を解説します。
概要
- 話者ダイアライゼーションは、誰が話しているかに基づいて録音をセグメント化し、氏名を特定せずにラベル付きの話者ターンを生成します。
- 話者ダイアライゼーションは、話者の切り替わり時点を検出する話者セグメンテーションや、声と実名を照合する話者識別とは異なります。
- ダイアライゼーションの性能は、全体的な精度を示すダイアライゼーションエラー率（DER）と、すべての話者で精度が維持されているかを確認するジャッカードエラー率（JER）で測定します。
話者ダイアライゼーションとは？どのように機能する？
話者ダイアライゼーションとは、誰が話しているかに応じてオーディオストリームをセグメントに分割する処理です。話者ダイアライゼーション付きの文字起こしでは、各オーディオセグメントに話者IDのラベルが付与されます。簡単に言えば、「誰がいつ話したか？」に答えるものです。
会議の通常の文字起こしでは発話内容だけがわかります。一方、ダイアライゼーション済みの文字起こしでは、話者1が質問し、話者2が回答し、話者3が途中で割り込んだことまでわかります。
多くの話者ダイアライゼーションシステムは、次の4段階のパイプラインに従います。
各段階を詳しく見ていきましょう。
音声区間検出（VAD）
音声区間検出は、発話をそれ以外の要素、つまり無音、バックグラウンドノイズ、音楽、キーボードの打鍵音から分離します。実際の発話を含むオーディオセグメントのみが次の段階に進みます。
この段階でエラーが発生すると、以降のすべての段階に影響します。
セグメンテーション
次に、発話を含むセグメントを、話者が切り替わった可能性が高い箇所で分割します。たとえば、声色の変化、発話ターン間の間、ピッチパターンの変化などです。多くのシステムは、候補となる境界の両側にある音響的特性を比較して、こうした変化点を直接検出します。
一部のセグメンテーションツールは、オーディオを2秒単位などの短く均一なウィンドウに分割し、同じ話者に属する隣接ウィンドウをクラスタリング段階で結合します。
埋め込み抽出
各発話セグメントは話者埋め込み、つまりそのセグメントで話している人の声の特徴を捉えた数値ベクトルに変換されます。同じ話者の埋め込みはベクトル空間内で近くに集まり、異なる話者の埋め込みはより離れた位置に配置されます。
クラスタリング
次に埋め込みをグループ化し、同じ話者のセグメントに同じラベルを付けます。通常、システムは事前に話者数を把握していないため、クラスタリングアルゴリズムが推定する必要があります。少し異なる声のセグメントが新しい話者なのか、同一人物が別の声色で話しているだけなのかを判断します。
出力は、通常は文字起こしとともに提供される、時間範囲に紐づいた話者ラベルのセットです。たとえば、2人による通話のダイアライゼーション済み文字起こしは次のようになります。
- [speaker_0] お電話ありがとうございます。どのようなご用件でしょうか？
- [speaker_1] こんにちは。先月の請求書についてお電話しました。
- [speaker_0] 承知しました。確認します。
ラベルは匿名であり、内部的に一貫しています。Speaker_0は出現するたびに同じ声を指しますが、システムはspeaker_0の名前がFergalであることを知りません。実際の人物IDを紐づけるのは別のタスクで、後ほど説明します。
話者セグメンテーションと話者識別の主な違い
話者セグメンテーションと話者識別はいずれもダイアライゼーションと密接に関係しているため、この3つは混同されがちです。
それぞれが解決する問題は少し異なるため、ツールを評価する際は違いを理解することが重要です。
前述のとおり、話者セグメンテーションはパイプラインの初期に行われるダイアライゼーション内のステップです。ラベルを付けずに、話者がある声から別の声へ切り替わる境界を見つけます。セグメンテーションでは、0:42で変化が起きたことがわかります。ダイアライゼーションでは、その結果得られたセグメントをグループ化して完全なラベル付き出力を生成するため、1:15の声が録音の冒頭で話していた声と同じであることまでわかります。
話者識別はダイアライゼーションとは別の機能ですが、両者はよく組み合わされます。識別では、その話者が実際に誰なのかを判定します。識別システムは、既知の話者の参照情報を使って声を登録済みのボイスプリントと比較し、本人のIDを返します。識別後、speaker_0とspeaker_1は「Fergal」と「Eric」になります。
多くのプロダクトは、より包括的な最終文字起こしを作成するためにこれらのツールを組み合わせています。会議ツールでは、TeamsやMeetで設定されている名前などの文字列を取得して、自動的に処理することもあります。これにより手動で確認しなくても、各参加者の発言を名前で紐づけられます。
主要なオープンソースの話者ダイアライゼーションツールとライブラリ
制御性、柔軟性、またはローカル環境へのデプロイが必要な場合は、オープンソースの話者ダイアライゼーションツールを検討する価値があります。最適な選択は、扱うオーディオの種類（電話、会議、ポッドキャスト、放送）、レイテンシー要件、投入できるエンジニアリング時間によって異なります。
代表的な選択肢をご紹介します。
Pyannote.audio
Pyannote.audioは、話者ダイアライゼーション専用に構築されたPyTorchベースのツールキットで、最も広く使われているオープンソースの選択肢の一つです。VAD、セグメンテーション、埋め込み、クラスタリングを含むダイアライゼーションスタック全体をカバーする事前学習済みパイプラインに加え、独自データでモデルを学習または微調整するための構成要素も提供しています。
事前学習済みモデルはHugging Faceを通じて配布されており、大規模な文字起こしプロジェクトではダイアライゼーションレイヤーとしてよく使われています。
WhisperX
WhisperXは、OpenAIのWhisperによる文字起こしと、ダイアライゼーション、強制アラインメントを組み合わせています。Whisper単体でも高品質な文字起こしを生成できますが、話者ラベルは付与せず、タイムスタンプもおおよそのものです。WhisperXは単語レベルのタイムスタンプアラインメントを追加し、pyannoteベースのダイアライゼーションを統合することで、各単語に正確なタイムスタンプと話者ラベルの両方が付いた文字起こしを生成します。
NVIDIA NeMo
NVIDIA NeMoは、より広範な会話型AIフレームワークの一部としてダイアライゼーションを提供しています。重複発話を処理するエンドツーエンドのアプローチを含む、学習可能なダイアライゼーションモデルを備え、GPUインフラ上でカスタム音声システムを大規模に構築するチーム向けに設計されています。
これらのツールでは、モデルのデプロイ、スケーリング、監視、更新を含むダイアライゼーションインフラを管理する必要があります。こうした運用負荷を避けたいチームには、マネージド型の音声ダイアライゼーションAPIがよりシンプルな代替手段になります。既存のワークフローに統合することも、ダイアライゼーションパイプライン全体を担うこともでき、カスタマーサポート分析、会議の文字起こし、ポッドキャスト処理といった本番用途に適しています。
リアルタイムダイアライゼーション：課題と活用例
リアルタイムダイアライゼーションは、システムが不完全な文脈で判断しなければならないため、録音完了後のダイアライゼーションより大幅に困難です。
オフラインシステムは、判断を確定する前に録音全体を確認できます。2分時点の声と40分時点の声を比較し、両方の時点を同時に利用できるため、同じ話者であると確信を持って判断できます。リアルタイムシステムにはその余裕がありません。次に話される内容にはアクセスできず、一度下した判断を修正する機会もほとんど、あるいはまったくない状態で、到着した瞬間に発話へラベルを付けなければなりません。
将来の文脈が欠けているため、リアルタイムでは特に次の3つの問題が大幅に難しくなります。
- レイテンシーと精度のトレードオフ：会話全体を行き来して確認できないため、より厳しい応答時間の要件を満たそうとすると、その分だけ精度が犠牲になります。
- 重複発話：複数人が同時に話す場合、オーディオを再処理できるシステムであれば分離できる可能性があります。リアルタイムシステムでは、その場で単一のラベルに割り当てるか、重複発話に対応した専用モデルに頼る必要があります。
- 短い発話：短い「はい」や「どうぞ」では、システムが判断するための声の情報がほとんど得られません。周囲の文脈も利用できない中で、即座にラベルを確定する必要があります。
難しさはありますが、録音が終わるまで待てないアプリケーションもあります。ライブキャプションでは、会議や放送中に話者の発話に合わせて話者ラベルが必要です。コンタクトセンターソフトウェアが通話中にエージェントへガイダンスを提示するには、顧客がどのような言葉を使っているかをリアルタイムで把握する必要があります。音声エージェントは、複数の参加者との通話で、誰が何を質問しているかを遅延なく追跡する必要があります。どのケースでも、精度はやや低くても即時に結果が得られるシステムのほうが、より高精度でも遅延するシステムより優れています。
分析、コンプライアンスレビュー、文字起こし生成など、リアルタイムのラベルを本当に必要としないワークロードでは、大幅に精度が高いバッチダイアライゼーションのほうが適しています。
話者ダイアライゼーションの性能評価方法
ダイアライゼーションの精度を測定する際に重要な指標は2つあります。全体的な精度を示すダイアライゼーションエラー率（DER）と、その精度がすべての話者で維持されているかを確認するジャッカードエラー率（JER）です。
DERは、誤って帰属された発話時間が全発話時間に占める割合を算出します。次の3種類のエラーを組み合わせた指標です。
- 誤検出発話：誰も話していないのに、システムがセグメントを発話としてラベル付けした場合です。
- 発話の見逃し：誰かが話していたのに、システムが無音としてラベル付けした場合です。
- 話者の混同：発話は検出されたものの、誤った話者に帰属された場合です。
DER = （誤検出 + 発話の見逃し + 話者の混同）/ 総発話時間
DERが10%の場合、3種類のエラーを合計した時間が総発話時間の10分の1に相当することを意味します。低いほど優れており、スコアを比較できるのは、同じ条件で同じデータを測定した場合のみです。DERは、オーディオ品質、話者数、録音に含まれる重複発話の量によって大きく変動します。
ジャッカードエラー率（JER）は、話者ごとにダイアライゼーション精度を個別に測定し、その結果を全話者で平均します。各参照話者について、評価者はシステム内で最も近い話者ラベルを対応付け、正しく重複している時間と、いずれかの話者に割り当てられた総時間を比較します。
たとえば、話者Aが50分、話者Bが10分話す60分間の会議を考えてみましょう。ダイアライゼーションシステムが、話者Aの50分のうち48分を正しくラベル付けした一方で、話者Bの10分のうち正しくラベル付けできたのが4分だけだったとします。会議の大半は話者Aによるものなので、全体のDERは比較的良好に見えるかもしれません。しかしJERでは、話者Aと話者Bを個別に評価してからスコアを平均するため、話者Bの低い結果も同じ重みで反映されます。
JER_speaker = 1 - （correct_overlap / （ref_time + sys_time - correct_overlap））
最終的なJERは、話者ごとのエラー率の平均です。
JER = （1 / N） * Σ[JER_speaker_i]、i = 1..N
DERとJERの両方を追跡することで、ダイアライゼーションの精度をより包括的に把握できます。DERは全体的な精度、JERは発話頻度の低い人を含むすべての参加者で精度が維持されているかを示します。
本番環境を代表するオーディオでのテスト
話者ダイアライゼーションシステムを評価する際は、実際のデプロイ条件に合うオーディオでDERとJERの両方を算出してください。具体的には、一般的な話者数、オーディオ品質、クロストークの量です。
公開されているベンチマークスコアは、スタジオ録音のような、実際の通話録音やライブ会議の音声とはほとんど一致しない、クリーンで制御されたデータセットで測定されている場合があります。ベンチマークで高スコアのシステムでも、ノイズや重複発話を含む実環境のオーディオでは大幅に性能が低下することがあります。ダイアライゼーションプロダクトを導入する前に、自社のデータでテストしてください。
ElevenAPIで話者ダイアライゼーションを始める
複数話者に対応した文字起こし機能を構築する準備ができたら、Scribe v2なら、ElevenLabsの話者ダイアライゼーションを単一のスピーチtoテキストAPIで利用できます。diarize=trueを指定してエンドポイントにオーディオを送信すると、JSONレスポンスで各単語に話者IDが付与されます。最大32人の話者、90以上の言語、最長10時間のファイルに対応しています。
標準のダイアライゼーション出力は、2つのオプションで拡張できます。通話録音では、detect_speaker_roles=trueを指定すると、匿名の番号ではなくagentとcustomerとして話者をラベル付けします。ワークスペースに話者プロフィールが登録されている場合は、use_speaker_library=trueにより、検出された話者を登録済みの声と照合できます。これにより、1回のリクエストでダイアライゼーションと識別を組み合わせられます。
ダイアライゼーションしきい値パラメータを使うと、話者を過剰に分割するか統合するかのトレードオフを調整できます。また、ステレオ通話録音のように、話者がすでに別々のオーディオチャンネルに分離されている場合は、マルチチャンネル文字起こしがチャンネルごとに話者を割り当てるため、ダイアライゼーションを完全に省略できます。
スピーチtoテキストのクイックスタートでは、最初のインテグレーションをステップごとに解説しています。規制対象のデプロイメント向けに、このプラットフォームはSOC 2、ISO 27001、PCI DSS L1、HIPAAに準拠しており、EUデータレジデンシーとゼロ保持モードも利用できます。
システムに話者ダイアライゼーションを組み込む準備はできましたか？まずはAPIキーを取得するか、ElevenLabsドキュメントで詳細をご確認ください。
