オンライン会議や配信にリアルタイムの字幕をつけたいが、クラウドの音声認識APIは使うほど課金がかさむし、通話の内容を外部に送るのも気が引ける。かといってGPUを積んだPCは手元にない。
そんな状況で選べる手段が1つ増えた。GPUもクラウドAPIも使わず、CPUだけで動くリアルタイム多言語音声認識ツール「早耳(Hayamimi)」が公開された。日本語なら発話が終わってから約100ミリ秒で字幕が確定し、対応言語は1600以上。英語・中国語・韓国語・スペイン語などへの翻訳字幕や、話者ごとのラベル付けまでこなす。
気になるのは、どれくらいの精度が出るのか、そしてCPUだけでそれがなぜ可能になったのかだ。
早耳は何ができるのか
早耳は、個人開発者「oboroge0」がGitHubでMITライセンスで公開しているオープンソースソフトだ。GitHubのREADMEによると、PyTorchやCUDAを使わず、INT8量子化したONNXモデルを音声認識エンジン「sherpa-onnx」上で動かす。GPUが要らないため、グラフィックボードのない一般的なノートPCでも動く。
できることは3つある。1つめはライブ字幕で、発話中は約0.5秒ごとに暫定の字幕を更新し、話し終えてから日本語は平均約100ミリ秒で確定行を出す。この速さはGitHubのREADMEとGIGAZINEの記事の両方で確認できた。2つめは話者ラベル付けで、--speakersオプションを付けると誰が話しているかをリアルタイムで区別する。3つめは翻訳字幕で、--translateオプションを付けると日本語の字幕を英語・中国語・韓国語・スペイン語などへその場で翻訳する。
メモリ使用量は--max-residentというオプションで制御でき、既定では2GB未満に収まる。常駐するモデルをLRU方式(使っていない順)で退避させる仕組みだ。
基本の機能はここまでだ。クラウドの大きなモデルと比べて、どれくらい速く正確に動くのか。
速さと正確さ
GitHubのREADMEには、言語ごとの単一クリップでの測定値が載っている。CER(文字誤り率)は文字単位の誤りの割合、WER(単語誤り率)は英語のような分かち書きの言語で単語単位の誤りを見る指標で、どちらも小さいほど正確だ。RTF(Real-Time Factor)は処理にかかった時間を音声の長さで割った値で、1より小さいほど速い。
| 言語 | 誤り率 | RTF(小さいほど速い) |
|---|---|---|
| 日本語 | CER 3.8% | 0.090 |
| 英語 | WER 2.3% | 0.102 |
| 中国語 | CER 6.6% | 0.084 |
| 韓国語 | CER 8.1% | 0.060 |
| 広東語 | CER 6.1% | 0.043 |
出典: GitHub oboroge0/hayamimi(確認日時: 2026-10-11)
RTF 0.09前後は、6コアのデスクトップCPUで実時間の約11倍の速さで処理できることを意味する。速いのは分かった。問題は、その速さと引き換えに精度を犠牲にしていないかだ。
READMEは、実際のテレビ放送の日本語音声を使った比較も載せている。同じ音声クリップを、GPUが要る大型モデル「Whisper-large-v3-turbo」と早耳の両方にかけた結果だ。
軽量・高速をうたうツールは、その分どこかで精度を削っているものだと身構えていた。だが同じ音声クリップでの比較を見ると、GPUなしの早耳のほうが誤りが少ない。この数値は開発者自身が公開した測定値で、第三者による独立した検証ではないが、「軽い処理は不正確」という自分の思い込みのほうが崩れた。
なぜCPUだけの軽量なツールが、GPUを使う大型モデルより正確な場面があるのか。
なぜCPUだけでそれだけ正確なのか
READMEが説明する仕組みは2段構えになっている。
- 発話ごとに言語を自動判定し、その言語専用の小さなモデルへ振り分ける。Whisperのような1つの大きなモデルがあらゆる言語を1モデルでこなすのに対し、早耳は日本語なら日本語専用、英語なら英語専用のモデルに仕事を任せる。専用モデルは扱う範囲が狭い分、同じ計算量でも精度を出しやすい
- 2秒の無音を検知すると、直前の発話をもう一度まとめて読み直す「2パス補正」をかけ、精度の高い「清書」を作る
READMEによると、この2パス補正によって日本語の実放送音声でのCERは15.5%から12.0%まで改善したという。話者ラベル付けも同じ発想だ。リアルタイムではCAM++という軽い方式でタグ付けし、2パス目でpyannote/segmentation-3.0による再分離をかける。AMI会議の録音5件での話者分離誤り率(DER)は、リアルタイム時の25.7%から2パス後に13.9%へ下がった。
発話ごとに最適な専用モデルへ振り分け、話し終えたあとに裏で読み直す2段構成。この組み合わせが、1つの巨大なモデルに頼らずに精度を底上げしている。
仕組みはここまでだ。日本語以外の言語や、複数人が同時に話す場面では、どこまで使えるのか。
対応言語・翻訳・話者分離の範囲
READMEによると、専用モデルが用意されているのは日本語・中国語・韓国語・広東語・英語の5言語と、欧州の24言語だ。それ以外の約1600言語は、Meta製の「Omnilingual ASR」という汎用モデルにフォールバックして処理する。専用モデルほどの精度は見込めないが、対応言語自体は非常に広い。
翻訳は、日本語の字幕を英語(FuguMTという専用モデルを使用)・中国語・韓国語・スペイン語などへリアルタイムに変換できる。ただし品質が確認されているのは中国語・韓国語・スペイン語への翻訳だけで、それ以外の言語は対応はしていても精度は未検証だ。中国語・韓国語への翻訳では、数値や金額を誤って訳すことがあるとREADMEに注意書きがある。なお日→英の翻訳モデルはCC BY-SA 4.0ライセンスで、コード本体のMITライセンスとは別に扱われる。
話者分離にも限界がある。会話に登場する話者を自動でラベル付けするが、2人が同時に話す場面は分離できない。また話者の人数は実際より多く見積もられる傾向があるとREADMEは断っている。会議の字幕用途では、聞き取れる程度の精度でよいか、発言の正確な帰属まで必要かで、この限界が気になるかどうかが変わる。
対応範囲はここまでだ。最後に、自分の環境で実際に試すには何が要るのかを確認する。
自分の環境で使うには
READMEが挙げる必要環境は、Python 3.10以上と、PATHが通ったffmpegだけだ。手順は次のようになる。
git clone https://github.com/oboroge0/hayamimi.gitでリポジトリを取得する- 仮想環境を作り、
pip install -r requirements.txtで依存関係を入れる scripts/download_models.pyでモデルを取得する。フル構成は約3.1GBだが、--minimalを付けると日本語・英語だけの約1.1GBで済むscripts/realtime_transcribe.pyを実行する。--translateや--speakersなどのオプションはここで指定する
開発と検証はWindows 11を中心に行われており、macOS・Linuxは「動作するはず」とされているが、エンドツーエンドの検証はまだ済んでいない。Windows以外の環境で試す場合は、この前提を踏まえておく必要がある。
既知の制限も残っている。
- 1つの文の中に複数の言語が混ざる発話(コードスイッチ)には対応していない
- 効果音やBGMの直後の短い発話では、言語判定を誤ることがある
- 句読点を補う機能は、既定では感嘆符を出さない
いずれも字幕の趣旨を変えるほどの欠陥ではないが、使ってみて気になった場合はREADMEのオプション一覧を確認するとよい。
まとめ
早耳は、GPUもクラウドAPIも使わずCPUだけで、日本語を含む1600以上の言語にリアルタイムで字幕を付けられるオープンソースツールだ。発話ごとに専用モデルへ振り分け、無音を検知してから読み直す2パス補正という2段構えの設計を持つ。この設計により、日本語の実放送音声ではGPU必須のWhisper-large-v3-turboより誤りが少なかった。英語・中国語・韓国語・スペイン語などへの翻訳字幕や話者ラベル付けもでき、Python 3.10以上とffmpegがあれば今すぐ試せる。
コメント
気づきや感想をどうぞ記事への補足や、読んで考えたことをお寄せください。個人情報や、他の人を傷つける内容の投稿はお控えください。
投稿にはGoogleログインが必要です。
Googleでログイン投稿にはGoogleアカウントの表示名が公開されます。メールアドレスは取得・公開しません。
コメントを読み込んでいます…