AIは複数話者をどう処理するのか：限界と設定

エンジンはどうやって話者を切り分けるのか

複数話者の録音をアップロードすると、AIは2つの別々の作業を行います。言葉を文字起こしすることと、それぞれの言葉を誰が話したのかを特定することです。 多くの人はこの2つが同時に行われると思っています。実際にはそうではありません。文字起こしモデルとダイアリゼーションモデルは並列に動作し、その出力は最後に結合されます。この分離を理解すると、複数話者文字起こしがうまくいかない理由の大半が説明できます。

「誰が何を言ったか」という処理の技術的な名称は「話者ダイアリゼーション（speaker diarization）」です。基盤となるモデルの仕組みを詳しく知りたい方は、話者ダイアリゼーションの解説をご覧ください。この記事では実務的な側面、すなわちエンジンが複数話者の音声をどう扱うか、文書化されている話者数の上限はいくらか、そしてどこで精度が落ちるかに焦点を当てます。

2モデルアーキテクチャ

典型的な文字起こしエンジンは、すべての音声に対して2つのモデルを実行します。

文字起こしモデルは、音声波形を単語レベルのタイムスタンプ付きテキストに変換します。出力は「0.4秒：the、0.6秒：meeting、0.9秒：starts、1.2秒：now」のようなイメージです。何人が話しているかはまったく分かりません。

ダイアリゼーションモデルは、まったく別の種類の出力、すなわち話者タイムラインを生成します。「0.0秒から14.2秒までは話者A、14.2秒から16.0秒までは話者B」といった具合です。話者が何を言ったかはまったく分かりません。

両方のモデルが完了すると、エンジンはそれらを整列させます。各単語には、ダイアリゼーションのタイムラインがそのタイムスタンプに割り当てた話者ラベルが付与されます。その結果が、話者ラベル付きの文字起こしです。

ダイアリゼーションモデル自体は通常、3つのステップで動作します。音声活動検出（音声内の発話区間を見つける）、話者埋め込み（短い音声セグメントを、声の個人特性を符号化したベクトルに変換する）、クラスタリング（類似したベクトルをグループ化して話者ラベルにする）です。内部実装としては、ほとんどの商用APIがこのパイプラインの亜種を使っており、多くの場合、事実上の標準であるオープンソースのダイアリゼーションフレームワークpyannoteをベースにするか、そこから着想を得ています。

重要な注意点：ダイアリゼーションモデルは話者を名前で特定しません。クラスタラベルを割り当てるだけです。「話者1」「話者2」はクラスタIDであって、実際の人物ではありません。名前の割り当て（行われる場合）は、話者登録、カレンダーのメタデータ、手動でのリネームといった別の仕組みで行われます。

「最大話者数」設定が実際に意味するもの

ほとんどの文字起こしAPIは話者数のパラメータを公開しています。以下は2026年半ば時点で主要エンジンが文書化している内容です。

表からは読み取れないことがいくつかあります。パラメータの上限が高くても、その上限で正確な出力が得られるわけではありません。AWS TranscribeでMaxSpeakerLabels=30を設定しても、AWSが30人の異なる話者を確実に識別できるという意味にはなりません。システムが試みるだけです。どのエンジンでも、範囲の上限付近の精度は2〜4人の場合より大幅に低くなります。

話者数が増えると精度はどう低下するか

話者を増やすほど、1分あたりに各話者が占める音声は減り、クラスタリングの問題は難しくなります。 2人の会話なら、モデルは1人あたり数分の音声信号を得て、信頼できる声のプロファイルを構築できます。10人の電話会議では、1人あたり90秒程度の断片的な発言しか得られないかもしれません。

ベンチマークデータセットはいくつかの参考値を提供してくれますが、これらは管理された条件下での数値です。AMI会議コーパス（マイク録音、3〜4人の話者、管理された条件）では、最先端のシステムでもダイアリゼーション誤り率（DER）は約7%に達します。DIHARDはノイズが多く多様な音声を含むはるかに難しいデータセットで、強力なシステムでもDERは約18%に上昇します。マイク設置が不適切で発話が重なり、話者が多い現実世界の録音では、通常DIHARDの水準に近いか、それ以上に悪化します。

DERは、誤った話者クラスタに割り当てられた発話時間の割合に、検出漏れや誤検出を加えたものです。1時間の録音でDERが7%ということは、約4分の音声が誤ってラベル付けされていることを意味します。会議の要約なら許容できますが、逐語的な法的記録としては許容できません。

DERを一貫して押し上げる条件は次のとおりです：

話者数が多い場合。 6人以上になると、ほとんどのエンジンが限界に近づき始めます。クラスタが重なり始め、短い発言が誤って割り当てられ、似た声の話者が統合されてしまいます。

短い発言。 「うん」「そうだね」「なるほど」。こうした一言の発言は、埋め込みモデルにとってほぼ判断材料になりません。同じ話者の長い発言が正しく識別されていても、これらは頻繁に誤ってラベル付けされます。

似た声。 同じ性別で年齢もアクセントも近い2人は、埋め込み空間で近い位置に配置されることがあります。クラスタリングアルゴリズムは、ときに両者を統合したり、会話の途中でラベルを入れ替えたりします。

単一マイクと部屋の音響特性。 会議室の天井マイクは、信号処理が行われる前にすべての声を混ぜ合わせてしまいます。個別マイクからのチャネルごとの信号は、ダイアリゼーションが格段に容易です。発話の重なりについては、発話の重なりへの対処および重なる話者の修正をご覧ください。

Whisperのギャップ

Whisperは多くの文字起こしツールの基盤となっているため、特別に取り上げる価値があります。OpenAIのWhisperモデルには、ネイティブのダイアリゼーション機能がまったくありません。 出力される文字起こしには話者ラベルが含まれません。

素のWhisperをベースにした製品は、ダイアリゼーションを完全に省略するか、WhisperX（Whisperの出力をpyannoteに通すもの）を追加するか、同じ音声に対して別のダイアリゼーションモデルを実行しています。あるツールが「Whisper搭載」を謳いながら話者ラベルを提供している場合は、どのダイアリゼーションモデルを使っているのか、整列はどこで行われているのかを尋ねてください。難しい音声での精度に関わる重要なポイントです。

Whisperと専用APIの比較については、Whisper vs Google Cloud Speech 2026および2026年の最高の音声認識APIをご覧ください。

会議ボット vs ファイルアップロードのダイアリゼーション

アーキテクチャが異なれば、精度の特性も異なります。

会議ボット（Otter、Firefliesなど）は、参加者の1人として通話に参加します。プラットフォームから参加者ごとの音声ストリームを取得でき、出席者名を含むカレンダーのメタデータにアクセスでき、話者ラベルをリアルタイムで実際の名前に紐づけられます。これは会議向けのユースケースにおける構造的な強みです。Firefliesは1つの会話で最大50人の話者に対応すると文書化しており、これはほとんどのファイルアップロード型APIより高い数値です。参加者ごとのストリーム分離によってダイアリゼーションの問題がはるかに簡単になることが一因です。

ファイルアップロード型APIはモノラルまたはステレオのミックス音声を処理します。参加者ごとのストリームの利点は一切ありません。会議の録音については、同じ会議にライブで参加したボットの方が通常精度が高くなります。その他の音声タイプ（ポッドキャスト、インタビュー、法廷記録など）については、ファイルアップロード方式が唯一の選択肢です。

私見ですが、録画された会議での複数話者精度については、ネイティブの会議ボットが構造的に有利です。それ以外については、現在のベンチマークと文書化された話者数の範囲に基づけば、Deepgram Nova-3とAssemblyAIが最も有力なファイルアップロード型の選択肢です。ただし、パイプラインを確定する前に、自分の音声でテストしてください。DERベンチマークは管理されたデータセットで測定されています。あなたの録音は管理された環境ではありません。

ダイアリゼーションをオフにすべきとき

すべての複数話者録音にダイアリゼーションが必要なわけではありません。価値よりもノイズをもたらすケースをいくつか挙げます：

たまに背景の声が入る単独録音。 めったに話さない共演者がいるナレーターの録音などです。背景の声が入るたびに、ダイアリゼーションは偽の話者交代を生成してしまいます。

クローズドキャプションと動画字幕。 視聴者は動画を見ているので、話者構成は目に見えて分かります。ラベルはただのノイズになります。

非常に短いクリップ。 2分未満なら、話者構成は通常文脈から自明であり、モデルには信頼できるクラスタを構築するのに十分な音声がありません。

単一話者のファイルについては、ほとんどのエンジンでダイアリゼーションを明示的に無効化できます。無効にしましょう。よりクリーンな文字起こしと高速な処理が得られます。

既存の文字起こしで間違った話者ラベルを修正する必要がある場合は、間違った話者ラベルの修正の記事で修正ワークフローを解説しています。

複数話者文字起こしで確認すべきポイント

複数話者向けにエンジンを評価する際の簡単なチェックリストです：

1. 話者数を自動検出するか、自分で設定するか？ 自動検出は柔軟ですが、カウントを誤ることがあります。話者数が分かっている場合は、期待する話者数を設定する方が一般に精度が向上します。
2. 最大話者数の上限が文書化されているか？ AWS Transcribeは30、AssemblyAIの非同期処理は20と明記しています。Google Cloudの厳密な上限はあまり明確に文書化されていません。Deepgramは公表していません。自分が扱うツールの仕様を把握しておきましょう。
3. 話者ラベルとともに単語レベルのタイムスタンプを提供しているか？ 整列の品質はタイムスタンプの精度に依存します。単語レベルのタイムスタンプがないと、話者ラベルの境界が実際の話者交代より遅れたり先行したりすることがあります。
4. 後処理でラベルを修正できるか？ 誤ったラベル付けは避けられません。クラスタの名前変更や統合ができる編集インターフェースや構造化エクスポートがあれば、重要度の高い文字起こしの作業時間を節約できます。

会議ボットをセットアップせずに迅速で正確な文字起こしが必要な場合は、ConvertAudioToTextが番号付きの話者ラベルと、ダウンロードやコピーが直接可能な構造化出力で複数話者のアップロードを処理します。テストにアカウント登録は不要です。

FAQ

話者ダイアリゼーションとは何ですか？なぜ文字起こしとは別に実行されるのですか？

話者ダイアリゼーションとは、音声をセグメントに分割し、各セグメントを話者クラスタに割り当てる処理です。文字起こしとは別に実行されるのは、2つのモデルが異なる問題を解決しているためです。一方は音声をテキストにデコードし、もう一方は声の個人特性をベクトルにエンコードしてクラスタリングします。ほとんどのエンジンは両方を並列に実行し、タイムスタンプで出力を整列させます。分けておくことで、文字起こしモデルを再学習させることなく、ダイアリゼーションのバックエンドを差し替えられるというメリットもあります。

AI文字起こしエンジンは実際に何人くらいの話者まで正確に処理できますか？

公表されているパラメータの上限は高めです（AWS Transcribeは最大30、AssemblyAIの非同期処理は最大20）が、その数字に達する前に精度は低下します。実際には、発言の間に明確な間のある2〜4人の話者であれば信頼できる出力が得られます。6人以上になると精度は顕著に落ちます。特に単一マイクでの録音で顕著です。短い発言や似た声質は、話者数に関係なく問題を悪化させます。

OpenAI Whisperは話者ダイアリゼーションに対応していますか？

いいえ。Whisperが出力する文字起こしには話者ラベルがありません。Whisperの上にダイアリゼーションを追加している製品は、WhisperX（pyannoteをWhisperパイプラインに組み込んだもの）を統合しているか、別のダイアリゼーションモデルを実行して出力を整列させています。話者ラベルが重要なら、どの音声認識モデルを使っているかだけでなく、裏側でどのダイアリゼーションモデルが動いているかを確認してください。

ダイアリゼーションをオフにすべきケースはいつですか？

単一話者の音声、2分未満の短いクリップ、そして字幕やクローズドキャプションなど話者構成が視覚的に自明なユースケースです。単一話者の音声にダイアリゼーションを実行すると、偽の話者交代が発生して文字起こしが雑然としてしまいます。ほとんどのエンジンでは明示的に無効化でき、処理も速くなります。

参考資料

• AWS Transcribe API リファレンス、Settings.MaxSpeakerLabels： https://docs.aws.amazon.com/transcribe/latest/APIReference/API_Settings.html （2026年7月確認）
• AssemblyAI「Top Speaker Diarization Libraries and APIs 2026」： https://www.assemblyai.com/blog/top-speaker-diarization-libraries-and-apis （2026年7月確認）
• Deepgram、話者ダイアリゼーションドキュメント： https://developers.deepgram.com/docs/diarization （2026年7月確認）
• Google Cloud Speech-to-Text「Detect different speakers」： https://docs.cloud.google.com/speech-to-text/docs/multiple-voices （2026年7月確認）
• Picovoice「State of Speaker Diarization 2026」（pyannote vs Falconベンチマーク）： https://picovoice.ai/blog/state-of-speaker-diarization/ （2026年7月確認）
• pyannote.ai「What is Speaker Diarization」： https://www.pyannote.ai/blog/what-is-speaker-diarization （2026年7月確認）