AI英会話は誰が話したかを判別できるのか。話者分離の上限と条件を公式ドキュメントから分解した

公開日 2026年9月13日(日) 13:02更新日更新なし

AI英会話を使っていると、「いま話したのが自分なのか、AIなのか、それとも隣にいる人なのかを、機械は分かっているのか」という疑問が出てくる。

これは感覚の話ではなく、音声認識の側に「話者を分ける」という名前の付いた機能があるかどうかの話だ。

その機能の名前はダイアライゼーション（diarization）という。

AIの部品を売っている会社の開発者向けドキュメントには、この機能が何人まで扱えるのか、扱えなくなったときに何が起きるのかまで書かれている。

そして英語学習の現場でいちばん効いてくるのは、人数の上限ではなく「声が重なったときの扱い」のほうだった。

この記事では、公式ドキュメントに実在する記述だけを材料にして、AI英会話における話者の扱いを1つずつ開けていく。

サービスの順位づけはしない。仕組みの話だけをする。

TOC

【結論】AI英会話の話者の判別は、機能としては存在するが、会話の最中に効いているとは限らない

先に答えを置く。

「誰が話したか」を扱う経路は、公式ドキュメント上で3本に分かれている。

何を分けたいか	使われる機能	公式に書かれている条件
1本のマイクに混ざった複数の声を、あとから分ける	ダイアライゼーション	音声サービスは最大35人の異なるスピーカーを識別できる。35を超えるとエラーがスローされる
最初からマイク（チャネル）ごとに分けて録る	マルチチャネル文字起こし（プレビュー）	リアルタイムでは最大2つのオーディオチャネルを個別に文字起こしし、結果にソースチャネルのタグを付ける
リアルタイムの文字起こしで話者ラベルを受け取る	ストリーミング文字起こし	`gpt-live-transcribe` は話者ラベルを返さない。必要ならファイル文字起こしのモデルか、アプリ側のフォールバックを使う

⇒ 「分けられる」と「いま分けている」は別の話で、リアルタイムの会話では後者が成立していないことがある。

そのうえで、英語学習にとっていちばん重い記述はこれだ。

複数の人が同時に話した声、あるいは音量の違う声は、背景雑音として解釈されて無視されることがある、とグーグルの公式ドキュメントに書かれている。

つまり重なった声は「別の話者としてラベルが付く」のではなく、そもそもテキストにならずに消えることがある。

AI英会話の話者を分ける方法は2つある｜混ざった音を分けるか、最初から分けて録るか

この2つを混同すると、話がまったくかみ合わなくなる。

1つめが、すでに1本の音声に混ざってしまった声を、後から機械が推定して分ける方法だ。

1つめの方法には、はっきりした定義が公式に書かれている。

マイクロソフトの音声テキスト変換のドキュメントは、ダイアライゼーションを「オーディオ録音で異なるスピーカーを区別および分離するプロセス」と説明し、会話・会議・マルチスピーカーの音声コンテンツの文字起こしに特に役立つ、と位置づけている。

2つめが、そもそも混ぜずに、チャネルを分けて録る方法だ。

同じドキュメントにはマルチチャネル文字起こし（プレビュー）という項目があり、リアルタイムの音声テキスト変換で最大2つのオーディオチャネルを個別に文字起こしし、各結果にソースチャネルのタグを付けられると書かれている。

想定されている用途として挙げられているのは、カスタマーサポートの通話の両側のように、チャネルごとに別の話者が乗っているステレオ音源だ。

グーグル側にも同じ役割の項目があり、Cloud Speech-to-Text のドキュメントの目次には「Detect different speakers（異なる話者を検出する）」が独立した1項目として置かれている。

ダイアライゼーション＝混ざった音から話者を推定する。人数の上限がある。
チャネル分離＝録音の時点で物理的に分かれている。推定ではないので取り違えが起きにくい。
グーグルもベストプラクティスで、1人ずつ別チャネルに録れているならチャネルごとに分けて送ったほうがよい結果になる、と書いている。
逆に、全員が1チャネルに混ざった録音なら、そのまま送れとも書かれている。

ここが分かると、AI英会話で自分の声がきれいに拾われる条件が見えてくる。

自分の口に近いマイク1本だけが自分の声を運んでいる状態は、機械にとっていちばん推定の要らない状態だからだ。

AI英会話の話者分離は何人まで届くのか｜公式には最大35人と書かれている

数字が明記されているのは、ここだ。

マイクロソフトのドキュメントには、音声サービスは1つのオーディオ録音で最大35人の異なるスピーカーを識別できると書かれている。

そして、サービスが35を超えるスピーカーを認識した場合はエラーがスローされる、と続く。

ここは「精度が落ちる」ではなく「エラーになる」と書かれている点が重要だ。

使う場面	音に入りうる人数	35人の上限に当たるか
ひとりで自宅から練習する	1人	当たらない
家族が同じ部屋にいる	2〜4人	当たらない
カフェでイヤホンマイクを使う	周囲の声が断続的に入る	通常は当たらない
教室で複数人が同時に練習する	10〜30人	近づくが、ふつうは届かない

⇒ 英語学習の場面で35人の上限が問題になることは、まず無い。

だから「何人まで分けられるか」は、学習者にとって実は重要な数字ではない。

効いてくるのは人数ではなく、声が同時に鳴ったかどうかのほうだ。

AI英会話でリアルタイムに分けられるのは最大2チャネル｜「別のマイク」がいちばん強い

リアルタイム側の上限は、35ではなく2だ。

マルチチャネル文字起こしの説明には、リアルタイム音声テキスト変換で個別に文字起こしできるのは最大2つのオーディオチャネルと書かれている。

しかもこの機能には（プレビュー）という注記が付いている。

プレビューという表記は、仕様が変わりうる段階であることを示す表現として使われている。

分け方	上限	タイミング	取り違えの起きやすさ
ダイアライゼーション	最大35人	録音を処理するとき	推定なので、条件が悪いと乱れうる
マルチチャネル（リアルタイム）	最大2チャネル	話している最中	チャネルが物理的に別なので起きにくい

この2つを並べると、AI英会話で自分の声を確実に自分のものとして扱わせる方法がはっきりする。

自分専用のマイクに口を近づけること、それ自体が「話者分離」の代わりになる。

グーグルのベストプラクティスも、マイクは可能なかぎり話している人の近くに置くこと、とくに背景雑音があるときはそうすべきだと書いている。

AI英会話で声が重なると何が起きるか｜同時に話した声は背景雑音として無視されうる

この記事でいちばん大事な1文が、ここにある。

グーグルのSpeech-to-Text のベストプラクティスには、次の記述がある。

Multiple people talking at the same time, or at different volumes may be interpreted as background noise and ignored.

同時に話している複数の声、あるいは音量の異なる声は、背景雑音として解釈され、無視されることがあるという意味だ。

同じページには、認識器は追加のノイズキャンセルなしで背景の声とノイズを無視するように設計されているとも書かれている。

つまり「無視する」のは不具合ではなく、設計どおりの動作だ。

ここから、AI英会話で起きることが2つ導ける。

まわりの声が混ざっても、勝手に文字起こしされて会話に割り込むとは限らない。無視される側に倒れる設計になっている。
ただし、その「無視」は自分の声にも起こりうる。誰かと同時に話した瞬間の自分の声も、背景雑音の側に落ちる可能性がある。
音量の差も条件に挙がっている。小さい声で話すと、大きい音のほうに引っぱられる余地が生まれる。

AIの返事に相づちをかぶせる練習、相手の発話を途中でさえぎる練習は、人間相手なら自然な行為だ。

だが認識の側から見ると、それは「重なった声」という、いちばん落ちやすい条件にあたる。

かぶせて話したのに反応が返らなかったとき、原因は英語力ではなく重なりのほうにあることがある。

AI英会話のリアルタイム処理では、話者ラベルそのものが返らないことがある

「話者を分ける機能がある」ことと、「いま使っている経路がそれを返す」ことは別だ。

OpenAI のリアルタイム文字起こしのガイドには、gpt-live-transcribe は単語単位のタイムスタンプ・話者ラベル・文字起こしの信頼度スコアを返さない、と明記されている。

そして、タイムスタンプや話者ラベルが必要なアプリケーションは、対応するファイル文字起こしのモデルを使うか、アプリケーション側のフォールバックを追加せよ、と書かれている。

同じページの本番前チェックリストにも、タイムスタンプ・話者ラベル・信頼度が使えない場合のフォールバック経路を用意しておくことという項目が入っている。

ここから言えることは1つだ。

画面に「あなた」「AI」と表示されていることは、音声認識が話者を判別した結果とは限らない。

アプリは、自分がマイクから送った音と、自分が鳴らした音声の区別を、音を聞かなくても知っている。

表示上の話者名は、その情報から付けることもできる。

また同じガイドには、サーバー側にターンの区切りを検出させたい場合は音声アクティビティ検出（VAD）を設定する、という記述があり、設定例では turn_detection が null になっている。

ターン検出が見ているのは「誰が話したか」ではなく「いま音声が続いているか」であり、話者の判別とは別の仕組みだ。

AI英会話をカフェや家族のいる部屋で使うと何が起きるか

ここまでの記述を、実際に使う場所に落とす。

グーグルのベストプラクティスには、録音と送信の条件について具体的な指示が並んでいる。

サンプリングレートは16,000 Hz 以上で録る。低いレートは精度を下げうる。
録音・送信にはロスレスのコーデックを使う。FLAC か LINEAR16 が推奨として挙げられている。
過度の背景雑音とエコーは精度を下げうる。ロスの多いコーデックを併用しているとなおさら、と書かれている。
送る前にノイズ低減の信号処理をかけると、通常は認識精度が下がる。サービス側がノイズのある音声を扱う前提で作られている。
オートゲインコントロール（AGC）は使わない。音の割れ（クリッピング）も避ける。

この並びを、英語学習の場面にそのまま当てはめると次のようになる。

使う場所	仕組みのうえで起こりうること	打てる手
静かな自室	推定すべき要素がいちばん少ない	特になし
家族がいる部屋	まわりの声は無視される側に倒れやすいが、同時に話すと自分の声も巻き込まれうる	相手が話していない間に発話する。口元にマイクを寄せる
カフェ	背景雑音とエコーが精度を下げうる	マイクを口に近づける。過度なノイズ処理を通さない
車内・屋外	音量差が大きく、重なりも増える	風やエンジン音が入る向きを避ける

共通しているのは、機械の設定をいじるより、口とマイクの距離を詰めるほうが効くという点だ。

マイクの位置は、公式ドキュメントが名指しで2回書いている数少ない項目でもある。

AI英会話の話者判別は「その場」より「あと」のほうが得意｜バッチ文字起こしの話

話者分離は、軽い処理ではない。

マイクロソフトのバッチ文字起こしのドキュメントは、待機時間を決める要因を列挙している。

その中に「話者ダイアリゼーションや言語識別などの追加機能が必要かどうか」という項目が入っている。

要求に含まれる音声の合計長、ジョブ待ち行列の長さ、ハードウェア構成と並んで、話者分離が処理時間の変数として扱われている。

同じページには、90パーセンタイルの待機時間は6時間未満だと書かれており、正規化された待機時間の計算式として ProcessDuration - AudioLength/5 が示されている。

この式の「5」は、システムがおよそ実時間の5倍の速さで音声を処理することを意味する、という説明も付いている。

バッチはファイルに格納された大量の音声を非同期に処理する仕組みで、会話の最中に答えを返す用途ではない。

⇒ 話者をきれいに分けた記録がほしいなら、それはレッスン中ではなく、終わったあとの処理に向いている。

会話のテンポを保ったまま、同時に高精度の話者分離もかける、という要求は、この2つのドキュメントの想定からは外れている。

AI英会話の字幕表示と話者表示は別の話｜部分結果は途中で書き換わる

画面に出る文字の挙動も、話者の話と混同されやすい。

マイクロソフトのキャプションの概念のドキュメントは、扱う範囲を自分で線引きしている。

そこには、このガイドは音声のキャプション付けについて説明するが、話者IDやベルの音などの効果音は含まないと書かれている。

つまり字幕を出す話と、誰が話したかを示す話は、ドキュメントの単位でも分かれている。

同じページには、部分的な結果の扱いも説明されている。

発話がまだ認識されている途中では、音声認識の結果は変化しうる。

イベント	意味	学習者から見える挙動
Recognizing	部分的な結果	単語が増えていく。句読点は使えない
Recognized	確定した結果	文として整い、句読点が入る

ドキュメントには、部分的な結果が正確でないこともあり、不安定な部分結果は表示時に「揺らぎ」として認識されうる、という説明まで入っている。

画面の英文が途中で書き換わるのは、話者の取り違えではなく、確定前の結果を出しているからだ。

この挙動を知らないと、「AIが自分の言ったことを別人の発言として拾った」と読み違えてしまう。

AI英会話の話者についてよくある質問

公式ドキュメントの範囲で答えられるものだけを挙げる。

Q. AI英会話は、自分の声とAIの声を取り違えることがあるのか。 A. 取り違えるかどうかは各サービスの実装しだいで、一般化はできない。公式ドキュメントから言えるのは、話者を分ける機能が存在し、その上限が最大35人、リアルタイムのチャネル分離が最大2チャネル、そしてリアルタイム文字起こしでは話者ラベルが返らない場合がある、というところまでだ。

Q. 家族が近くで話していたら、その声も文字にされてしまうのか。 A. グーグルのベストプラクティスには、認識器は追加のノイズキャンセルなしで背景の声とノイズを無視するよう設計されている、と書かれている。さらに、同時に話す複数の声や音量の異なる声は背景雑音として解釈され無視されうる、とも書かれている。つまり拾われるより、無視される側に倒れやすい。

Q. 話者分離は何人まで対応しているのか。 A. マイクロソフトの音声テキスト変換のドキュメントには、最大35人の異なるスピーカーを識別できると書かれている。35を超えるスピーカーを認識した場合はエラーがスローされる、と明記されている。

Q. リアルタイムのやりとりでも、必ず話者ラベルが返ってくるのか。 A. 返らない場合がある。OpenAI のリアルタイム文字起こしのガイドには、gpt-live-transcribe は単語単位のタイムスタンプ・話者ラベル・信頼度スコアを返さないと書かれており、必要な場合はファイル文字起こしのモデルかアプリ側のフォールバックを使うよう案内されている。

Q. ノイズキャンセリングを強くかければ、認識は良くなるのか。 A. グーグルのベストプラクティスは逆のことを書いている。サービスへ送る前にノイズ低減の信号処理をかけると通常は認識精度が下がる、AGCは使わない、ノイズ低減処理はすべて無効にする、と並んでいる。代わりに推奨されているのは、マイクを話している人の近くに置くことだ。