話者分離できる無料の文字起こし｜会議の録音から誰が話したかを自動で分ける方法

作成日：2026年9月20日 7:58更新日：2026年10月8日 21:23読了時間：約 15 分

会議やインタビューの録音をそのまま文字起こしすると、どの発言が誰のものか分からない一続きのテキストが出てきます。この文字起こしを発言者ごとに分ける処理が「話者分離」と呼ばれるもので、後から議事録として読み返すつもりなら、ここまで済ませておかないと結局は音声を聞き直すことになります。

ところが、文字起こしに広く使われている Whisper 自体にはこの機能がありません。無料で使えるクラウド型のサービスにも話者分離はありますが、月あたりの利用時間に上限があるうえ、音声データをアップロードすることが前提になっています。

この記事では、ブラウザだけで話者分離つきの文字起こしをする手順を説明します。後半では、私がこの機能を実装したときに実際に測った精度と、どういう場面で精度が出ないのかも書きました。

この記事でわかること

Whisper だけでは話者を分けられない理由
無料で話者分離する方法の比較
ブラウザで話者を分けて文字起こしする手順
Teams・Zoom の録画を文字起こしする方法
話者がうまく分かれないときの直し方

PC と Chrome または Edge のブラウザ、会話が記録された音声ファイルがあれば始められます。会員登録やアプリのインストール、ファイルのアップロードをしなくても、最後まで進められます。

話者分離と Whisper の関係

「Whisper に話者分離の機能がある」と書かれているのを見かけますが、これは誤りです。Whisper は音声をテキストに変換するモデルであって、声の主を見分ける仕組みそのものを持っていません。

誰が話したかを分けるには、話者分離を専門にする別のモデルが必要です。この分野でよく使われるのが「pyannote.audio」で、音声を細かく区切って声の特徴を数値の並びとして取り出し、似た特徴どうしをまとめることで同じ人物の発言を復元していきます。

話者分離つきの文字起こしは、文字起こしのモデルと話者分離のモデルを組み合わせて成り立ちます。クラウド型のサービスはこの 2 つをどちらもサーバー側で動かすため、利用するには音声データをアップロードすることになります。

無料で話者分離する方法の比較

無料でできる方法は大きく 3 つに分かれます。それぞれ準備にかかる手間も、使える時間の制限も、音声データがサーバーに送信されるかどうかも違いますので、先に並べて比べておきます。

方法	準備	時間の制限	サーバーへの送信
クラウド型のサービス	会員登録	無料枠は月 120〜300 分が目安（2026 年 9 月時点）	あり
Python で自分で組む	Python と GPU の環境構築	なし	なし
ブラウザの中で処理する	不要	なし	なし

Python で組む方法は自由度が高い反面、CUDA や ROCm の導入でつまずくことが多くあります。私も最初はこの経路で試していましたが、記事を読んだ人に毎回その環境を用意してもらうのは現実的ではないと考えて、同じ処理がブラウザの中だけで完結する形に作り直しました。

ここではブラウザで処理する手順を説明します。Python で自分で組むほうに興味があれば、環境構築から順に書いた記事を末尾に置いてあります。

手順：ブラウザで話者を分けて文字起こしする

ここで使うのは私が作った「Transcriber」です。話者分離も文字起こしもブラウザの中で動きますので、録音した音声が端末の外へ出ることはありません。

無料・無制限のAI文字起こし｜登録不要・アップロード不要 - Transcriber

音声・動画ファイルをブラウザだけで文字起こし。会員登録もアップロードも不要で、音声データは端末の外に出ません。時間・回数の制限なしで完全無料。Whisper AI による話者分離と SRT 字幕の書き出しに対応し、MP3・WAV・M4A・MP4 など主要形式を読み込めます。

transcriber.tools.ryusei.io

「Transcriber」をブラウザで開きます。
「話者分離」を「有効」にします。
「話者数（0 = 自動）」は「自動」のままにします。
「モデル」と「言語」を選びます。
音声ファイルを枠に読み込ませます。読み込んだ時点で処理が始まります。

話者数は「自動」のままにする

ブラウザから GPU を使う仕組みの「WebGPU」が使える PC（Firefox を除く）で Whisper か Qwen3-ASR のモデルを使うときは、「話者数（0 = 自動）」が「自動」のままなら NVIDIA の話者分離モデル「Nemotron 3 Diarization」で処理され、人数を指定すると「pyannote」を使う以前からの方式に切り替わります。日本語・中国語・韓国語の初期設定の SenseVoice Small は CPU で動作するため、話者分離も以前からの方式になります。私が英語の 2 人の会話と、3 人が話す 6 分の録音で比べたところ、話者の判定を誤った時間の割合（DER）は、「自動」のままなら 2.3% と 1.7%、正しい人数を指定すると 5.1% と 4.0% でした。

以前からの方式だけで比べても、人数を指定して精度が上がることはありませんでした。上の 2 つの録音では、以前からの方式を「自動」で動かしたときの DER も 5.1% と 4.0% で、人数を指定したときと同じ値になります。

7 人が話す 25 分の国会の委員会の録音では、以前からの方式を「自動」で動かすと DER は 4.3%、文字起こしの行ごとに付けた話者のうち正しかった行の時間の割合（以下、行ごとの正解率）は 99.0% でした。画面で選べる上限の 6 人を指定すると、DER は 24.2% に上がり、行ごとの正解率は 79% に下がりました（正しい人数の 7 人を指定しても同じでした）。委員長の発言は 1 秒ほどの呼び上げだけで、ほかの人の声と分けられないため、指定した人数に合わせて話者の数を増やすと、長く話している 1 人が 2 人に分けられていました。

Teams・Zoom の録画を文字起こしする

会議の録画を後から文字起こしするときは、先に録画ファイルを PC に保存してから、上の手順で読み込みます。保存のしかたは会議ツールごとに違うので、2026 年 9 月時点の Zoom ヘルプと Microsoft Learn の記述をもとに手順をまとめます。

Zoom の場合

Zoom の「ローカル記録」は無料の「ベーシック」アカウントでも使えますが、Windows・macOS・Linux のデスクトップアプリが必要で、スマートフォンやタブレットのアプリではローカル記録を使えません。

会議が終わると、Windows では C:\Users\<ユーザー名>\Documents\Zoom、macOS では /Users/<ユーザー名>/Documents/Zoom に、動画の video<数字>.mp4 と音声だけの audio<数字>.m4a が保存されます。Transcriber は動画を読み込むと先に音声を取り出す処理を挟むため、音声だけの m4a を選んだほうが早く文字起こしに入れます。

Teams の場合

Teams の会議の録画は、開催者の OneDrive にある「レコーディング」フォルダーに保存されます。チャネル会議の場合は、チームの SharePoint の「ドキュメント」内にある「レコーディング」フォルダーです。

既定でダウンロードできるのは開催者と共同開催者だけで、ほかの参加者は再生はできてもファイルを保存できません。参加者の立場で文字起こししたい場合は開催者にファイルを共有してもらう必要があり、組織の設定によってはダウンロードそのものが禁止されていることもあります。

Teams にも文字起こしの機能はありますが、組織の管理者が有効にしている必要があります。Microsoft の説明では 1 時間の録画が約 400 MB なので、Transcriber が PC で読み込める上限の 2 GB には収まります。

うまく分かれないときの直し方

話者分離は完全ではありません。とくに短い発言では精度が落ち、1 秒前後の相づちや呼びかけは、その前後にある長い発言と同じ話者として扱われてしまいます。この弱点はモデルを変えても残るため、結果の画面で後から直すことになります。

国会の委員会の音源で調べたときは、「委員長、山井君。」のような短い呼び上げが 6 箇所あり、以前からの方式ではそのうち 4 箇所が、音声を区切る最初の段階ですでに次の発言者と同じ扱いになっていました。まとめ方の問題ではなく、その手前の段階で区別が失われているので、閾値をどう動かしても直りません。国会会議録と照らし合わせて数えると、はっきりした呼び上げは 11 箇所あり、以前からの方式でも Nemotron 3 Diarization でも、別の話者として分けられたものは 0 箇所でした。

モデル側で直しきれない以上、後から人の手で直せることのほうが重要になります。そこで結果の画面には、行ごとに話者を変える、話者の名前を実名に変える、誤って分かれてしまった 2 人を統合する、長い行を途中で分割する、といった機能を用意してあります。

話者バッジをクリックすると、名前の変更と別の話者への統合ができます
行の話者だけを変えたいときは、その行のバッジから選び直します
「編集を元に戻す」で、本文・話者・分割の編集を 1 つずつ戻せます

仕組みと、実装したときに測った精度（エンジニア向け）

ここからは内部ロジックの話になりますので、使うだけであれば読み飛ばしてもらって構いません。仕組みを知っておくと、なぜ短い発言で失敗するのかが分かり、結果を直すときの見当もつけやすくなります。

話者分離の方式は 2 つあります。2026 年 9 月 24 日からは、PC で文字起こしが WebGPU で動き、「話者数（0 = 自動）」を「自動」にしている場合に限り、NVIDIA の「Nemotron 3 Diarization」を使っています。WebGPU が使えない PC、スマートフォン、Firefox、話者数を指定したとき、Nemotron の処理が失敗したときは、「pyannote 3.1」の構成をブラウザ向けに移植した以前からの方式で処理します。Firefox では WebGPU で Nemotron を動かすと毎回エラーになり、以前からの方式での出し直しも同じエラーで失敗していたため、2026 年 9 月 28 日からは Nemotron を使わずに以前からの方式で処理しています。

以前からの方式は 3 段階に分かれます。まず音声を 10 秒ずつに区切って、それぞれの区間の中で「いつ誰が話しているか」を推定します。次に、その区間ごとに話している人の声の特徴をベクトルとして取り出し、最後に似たベクトルどうしをまとめることで、録音全体を通して同じ人物の発言を復元します。

1 段目には pyannote の区切り用モデル「segmentation-3.0」、2 段目には「WeSpeaker」の「ResNet34」を使っています。区切り用のほうは 6 MB しかないため、ブラウザで読み込んでも待たされることはありません。処理の重さのほとんどは 2 段目の埋め込みと、その後のまとめ上げが占めています。

1 人の独話が 8 人に分かれていた話

最初の実装には、声の特徴ベクトルから全体の平均を引くという処理を入れていました。録音ごとのマイクや部屋の違いを打ち消す狙いだったのですが、後から測ってみると、これが精度を下げる原因になっていました。

話者が 1 人しかいない録音で全体の平均を引くと、平均そのものがその人の声の特徴と一致するため、引いた結果には話者を区別する情報が残りません。2 人の場合も同じ人物どうしの距離がかえって広がり、手元のシミュレーションでは同一話者間の距離が 0.39 から 1.00 まで開いていました。

結果として、1 人だけが話している録音も 2 人の会話も、自動判定では上限である 8 人まで分かれていました。まとめる際の閾値も実測せずに決めた値だったので、私は閾値を調整する前に、まず数字を出せる状態を作るところからやり直しています。

pyannote 3.1 の構成に作り直した後の実測

pyannote 3.1 と同じ構成へ作り直したうえで、同じ音源を使って測り直しました。精度の指標には DER を使っています。これは、話者を取り違えた時間に、発話を見落とした時間と、声のない区間を発話と判定した時間を足して、正解の発話時間の合計で割った値で、低いほど正確に分けられていることを意味します。

音源	最初の実装（自動）	pyannote 3.1 の構成（自動）	pyannote 3.1 の構成（話者数を指定）
英語の会話 30 秒・2 人	8 人・DER 57.1%	2 人・5.1%	5.1%
日本語の独話 41 秒・1 人	8 人・80.3%	1 人・0.1%	—
上の会話を 25 回つないだ 12.5 分	—	2 人・5.9%	—

12.5 分まで伸ばしても DER が 5.9% に収まっているので、長い録音になったからといって急に精度が落ちることはありません。ただしこれは人手で正解ラベルを付けた 2 つの音源で測った値であって、どんな録音でもこの精度が出るという意味ではない点には注意してください。7 人が話す 25 分の国会の委員会の録音でも測っていて、その結果はこの節の最後に Nemotron と並べて載せています。

pyannote をそのまま移しても精度は出なかった

pyannote の手順をそのまま持ってくると、30 秒のサンプルが 3 人に分かれました（DER 12.3%）。短い発言が重なる区間から互いに似たベクトルが大量に作られ、それらが実在しない 3 人目としてまとめられていたためです。

自動判定のときだけ、区間内の発話が 2 秒に満たないベクトルをクラスタの種から外すようにして解決しました。話者数を指定したときは外しません。

もう 1 つ手間だったのは、ブラウザ向けのライブラリが区切り用モデルの後処理を持っていなかったことです。このモデルは「誰と誰が同時に話しているか」という組み合わせの形で結果を出しますので、それを話者ごとの時間に戻す処理は、私が自分で書くしかありませんでした。

Nemotron 3 Diarization への切り替えと実測

NVIDIA が 2026 年 9 月 23 日に公開した「Nemotron 3 Diarization」は、パラメータ数が約 1 億の話者分離モデルで、「Streaming Sortformer」の系統に属し、最大 8 人まで分けられます（ライセンスは「OpenMDW-1.1」）。Transcriber では公開の翌日から、Hugging Face の「onnx-community」が公開している ONNX 形式の版を、4 ビットの重みでブラウザの中で動かしています。重みのファイルは 73 MB（GPU が 16 ビットの浮動小数点数に対応していない場合は 83 MB）で、初めて使うときだけブラウザが Hugging Face からダウンロードします。

比較には、公開されている評価結果と、私の手元の音源の両方を使っています。評価用データ「DIHARD III」について公開されている結果では、同じ採点条件で「pyannote 3.1」の DER が 21.7%、Nemotron が 12.7% です。手元の音源のうち国会の委員会の録音は 7 人が話す 25 分のもので、冒頭と最後に、その委員会で発言していた議員が 2026 年に収録した解説が含まれています。正解ラベルは、国会会議録と Whisper の文字起こしを突き合わせて作りました。

音源と指標	pyannote 3.1 の移植（以前からの方式）	Nemotron 3 Diarization
英語の会話 30 秒・2 人（DER）	5.1%	2.3%
英語の会話 30 秒と日本語の独話 41 秒を 5 回つないだ 6 分・3 人（DER）	4.0%	1.7%
国会の委員会 25 分・7 人（行ごとの正解率）	99.0%	99.3%（統合後）
国会の委員会 25 分・7 人（DER）	4.3%	4.4%（統合後）
国会の委員会 25 分の処理全体（私の PC・Whisper tiny を含む）	240 秒（話者数 6 を指定）	190 秒

英語の会話と 6 分の録音では、DER が半分以下になりました。国会の音源では行ごとの正解率が 0.3 ポイント上がり、DER は 0.1 ポイント悪くなったので、以前からの方式とほぼ同じ結果です。国会の音源の DER は、発言の境目の前後 0.25 秒と、話者を判別できない 4 つの区間を採点から外して計算しているので、英語の音源の DER とは直接比べられません。

速度は私の PC（Minisforum UM870、内蔵 GPU の Radeon 780M）で 27 秒ぶんの区間 1 つあたり約 0.14 秒で、1 時間の音声に換算すると、Nemotron の計算にかかる時間は 16〜20 秒ほどになります。表の処理全体の時間のうち、以前からの方式の 240 秒は、WebGPU の PC で以前からの方式に切り替えるために話者数を 6 と指定して測った値です。

ただし、Nemotron の出力をそのまま使うと、国会の音源の行ごとの正解率は 83% に下がりました。最後の解説（172 秒）が、冒頭の解説と同じ議員の声であるにもかかわらず、別の話者として扱われていたためです。分かれたのは委員会の映像から最後の解説に切り替わったところからで、その直前まで、同じ議員の委員会での発言は冒頭の解説と同じ話者として扱われていました。原因は確かめられていませんが、Nemotron が話者を見分けるために保持する音声（「スピーカーキャッシュ」）が話者ごとに数秒ぶんしかないことが関係していると、私は考えています。

そこで Nemotron の処理の後に、話者ラベルごとに「WeSpeaker」（以前からの方式でも使っているモデル）で声の特徴ベクトルを取り出して平均し、余弦距離が 0.25 より近いラベルどうしを 1 人にまとめる処理を追加しました。国会の音源では、分かれてしまった 2 つのラベルの距離は 0.07 で、別人どうしはどの組も 0.54 以上離れていたため、この処理で 1 人にまとめられたのは同じ議員の 2 つのラベルだけです。表の国会の音源の値はこの統合を入れた後のもので、英語の 2 つの音源は統合の前後で値が変わりません。

WebGPU が使えない PC とスマートフォンでは、以前からの方式を残しています（スマートフォンでは、WebGPU が使えても WASM で処理しています）。Nemotron を 1 スレッドの WASM で動かすと 27 秒ぶんの区間 1 つに 4.6〜5.1 秒かかり、同じ CPU の 1 コアで比べた処理時間は以前からの方式とほぼ同じで、速くはなりません。一方で、最初にダウンロードする重みは 12.7 MB から 83 MB に増えます。今でも、話者分離の段階で失敗した 15 件のうち 7 件がスマートフォンのメモリ不足（2026 年 9 月 15〜24 日の統計）なので、重みを増やすことは避けました。

話者数を指定したときも以前からの方式で処理するのは、Nemotron に人数を指定する仕組みがないためで、指定しても精度が上がらないことは「話者数は『自動』のままにする」に書いたとおりです。

よくある質問

何人まで分けられますか。

自動判定では 8 人まで分けられます。参加者がそれより多い会議では分けきれず、声の近い人どうしが 1 人にまとまることがあります。人数を指定する場合は、画面で選べる 6 人までです。

本当に無料ですか。回数の制限はありますか。

無料で使えます。回数の制限も時間の制限もありません。話者分離も文字起こしも利用者の PC の中で動いているので、こちら側にサーバーの費用が発生しないためです。

音声データがサーバーへ送られることはありませんか。

ありません。話者分離のモデルも文字起こしのモデルもブラウザの中で動きますので、音声が端末の外へ出ることはありません。モデルの取得のほかに、Transcriber は不具合を直すための統計（端末の性能や処理にかかった時間など）をサイトのサーバーへ送信していますが、音声、文字起こしの結果、ファイル名、IP アドレスは含みません。この送信は、ページ下部の「サービス品質向上へのご協力のお願い」にあるスイッチで止められます。

話者分離をすると処理はどれくらい遅くなりますか。

文字起こしとは別に、同じ音声をもう一度読み直すぶんの時間がかかります。私の PC（内蔵 GPU の Radeon 780M）で WebGPU を使い、話者数を「自動」のままにした場合、話者分離のモデルの計算は 1 時間の音声に換算して 16〜20 秒ほどになります。25 分の録音で文字起こし（Whisper tiny）を含めた処理全体を測ると 190 秒で、話者数を指定して以前からの方式で処理した場合は 240 秒でした。WebGPU が使えない PC やスマートフォンでは以前からの方式を CPU で動かすので、話者分離にかかる時間はそれより長くなります。

スマートフォンでも使えますか。

動きはしますが勧めません。話者分離は文字起こしとは別にメモリを使いますので、そのぶん途中で止まりやすくなります。スマートフォンで録音したファイルを、PC で処理してください。

話者の名前を実名に変えられますか。

変えられます。話者バッジから名前を変更でき、そこで付けた名前は TXT や SRT として書き出したファイルにも反映されます。