会議や取材の録音を文字にしたい。でも、長い音声の処理時間や、音声をどこに預けるかが気になる――そんな人に新しい選択肢が登場しました。
Third Intelligenceが公開した「Haas-ja-v1.0」は、日本語に特化した音声認識モデルです。開発元の評価では、比較したオープンモデルの中で高い認識精度と処理速度を両立しました。音声を自分の環境で処理できる一方、公式の実行コードにはGPUなどの条件があります。
Haasの強みは何か。数字の意味から、長い録音や固有名詞を扱うときの注意点まで見ていきましょう。
音声から日本語テキストを作るHaas
Haas-ja-v1.0は、録音された日本語の音声をテキストに変換するモデルです。開発元の公開リポジトリではモデルの重みと推論コードを公開しており、いずれもApache 2.0ライセンスと説明しています。利用時には、組み合わせる外部ソフトの条件も別途確認が必要です。
音声を読み取る部分にFastConformer、文字列を出力する部分にTDTという構成を採用し、予測ネットワークにはKimi Delta Attentionを使っています。利用者にとっての焦点は構造の名前よりも、自分の音声で十分な精度が出るか、必要な時間内に処理できるかです。
文字誤り率6.12%は何を表す？
開発元は日本語の公開テストセット5種類を使うasr-ja-bench v1.1で評価し、重み付きの厳格な文字誤り率（CER）が6.12%だったと報告しています。この条件では、比較したオープンモデルの中で最良だったという結果です。
CERは、正解の文字列に対して置き換え、脱落、余分な文字がどのくらい生じたかを見る指標です。低いほど誤りが少ないことを示しますが、6.12%という数字があらゆる会議や録音で再現されるわけではありません。
数字は開発元が選んだデータと評価方法での結果です。専門用語、騒音、話者の重なりを含む自分の録音でも試すことが大切です。
速度も開発元の測定では高速です。ただしGPU、音声の長さ、処理をまとめる方法などで実際の待ち時間は変わります。ベンチマークの順位だけでなく、手元の環境で精度と処理時間を一緒に見て判断したいところです。
長い会議や固有名詞にはどう対応する？
Haasは最大30秒の発話で学習されており、公式コードには長い音声を無音に近い場所で区切り、複数の断片をまとめて処理する機能があります。長時間の録音を扱う際は、この分割が一つの鍵になります。
人名や製品名など、認識しにくい言葉を登録するカスタム語彙の仕組みも用意されています。読み方と表記を指定することで、必要な単語が出やすくなります。
語彙の登録は万能ではありません。実際には話されていない登録語が出力されることもあるため、必要な語に絞り、音声と照合しましょう。
「誰が話したか」は別モデルと組み合わせる
文字起こしでは、発言内容だけでなく話者も分かると議事録を追いやすくなります。公式リポジトリには、NVIDIAのNemotron-3-Diarizationを組み合わせて話者ラベルを付ける例があります。これはHaas単体の文字認識とは別の処理です。
話者分離の考え方は、以前紹介したNemotron 3 Diarizationの記事でも取り上げています。複数人が同時に話す場面や名前の割り当ては、そのまま正しいと決めつけず、人が録音と照らし合わせたい部分です。
会議録なら、まず文字起こしを作り、必要に応じて話者分離を追加する。最後に名前、数字、決定事項を人が聞き直す流れが実用的です。
手元で試す前に知っておきたい条件
公式の推論コードが求めるのはLinuxとNVIDIA GPU、Python 3.11以降、NeMo 2.7です。公式実装がどの環境でも動くという意味ではありません。話者ラベルのサンプルには別の環境が必要です。
ローカルで動かせば、音声を外部の文字起こしAPIに送らず処理する構成を選べます。ただし、モデルの入手経路や連携するサービス、保存先まで含めて設計しなければ、データが外に出ないとは言い切れません。録音の扱いには組織のルールと参加者への配慮も必要です。
モデルが軽快でも、環境構築やGPUの用意には手間がかかります。まず短いサンプルで動作と精度を見てから、長時間の処理へ広げましょう。
日本語の音声認識を自分の環境で試せることは、議事録や字幕の作り方を選ぶうえで大きな一歩です。Haasの測定結果を出発点に、実際の録音で誤変換と処理時間を確かめれば、便利さと確認作業のバランスが見えてきます。
