同じ Whisper なのに、なぜ精度が違うのか

最終更新：2026年9月18日

同じモデルなのに、なぜ結果が違うのか

「完全ローカル文字起こしはfaster-whisperを使っているんですよね。それなら自分でfaster-whisperを動かせば同じでは？」——よくいただく質問です。答えは「モデルは同じ、結果は違う」です。

Whisper large-v3は優秀なモデルですが、素のまま使うと実務の音声で決まった失敗をします。動画の終わりに「ご視聴ありがとうございました」と書く、無音で同じ語を延々と繰り返す、専門用語を似た音の別の語にする、電話録音で結果が白紙になる、誰が話したか分からない——これらはモデルの限界ではなく、モデルの前後の処理が無いことによる失敗です。完全ローカル文字起こしは、こうした失敗を実際の音声で一つずつ検証し、原因を測り、対策を積み上げてきました。

以下、5つの層と配布前のチェックに分けて紹介します。数値はすべて実測に基づくものです。

第1層：音声を正しく読み込む

逆位相ステレオの救済。電話録音アダプタの一部は、左右チャンネルを逆位相で記録します。再生すると普通に聞こえますが、文字起こし前にモノラル化（左右の平均）すると数学的に打ち消し合って完全な無音になり、結果が白紙になることがあります。完全ローカル文字起こしは、モノラル化した結果がほぼ無音のときだけ左右チャンネルを読み直し、片方に寄せた方が明らかに音量が大きければ「打ち消し」と判定して、その単一チャンネルで文字起こしします。実際にお客様から届いたご報告をきっかけに実装した機能です。

電話音声の実測とlarge-v3固定。8kHz・帯域制限の通話録音で、large-v3・medium・smallを比較計測しました。large-v3は一致率90.1%（クリーンな音声での上限は93.4%）、mediumは4.5ポイント、smallは12.6ポイント低い結果でした。速さのために小さいモデルへ切り替える製品もありますが、完全ローカル文字起こしの配布版はlarge-v3を同梱し、小さいモデルへは落としません。速さは推論エンジン（CTranslate2のint8/float16量子化）とCPUスレッド数の使い方で稼いでおり、スレッド数を機械的に固定せず論理コア数の半分（4〜8）を自動で使うようにしているため、コア数の多いPCほど有利に働きます。

動画も、壊れかけのファイルも。mp4・mov・mkvなどの動画は音声トラックを取り出して処理します。読み込みに失敗した形式は同梱のffmpegで再変換して再試行します。さらに厄介なのが「途中で静かに止まる」ファイルです。一部の音声形式は1か所データが乱れるとそこで復号が止まり、デコードに使うライブラリの仕様上エラーが外へ伝わらず、一見正常な短い結果がそのまま返ってしまうことがあります。完全ローカル文字起こしは、音声本来の長さと実際にデコードできた長さを比較し、一定割合に届かなければ打ち切りとみなしてffmpegで再変換し、それでも届かなければ結果に注記を残します。「無言で完了扱い」にしないのが方針です。

第2層：モデルが暴走しない設定で回す

faster-whisperの文字起こし処理は設定できる項目が多く、既定値のままでは実務向きではありません。完全ローカル文字起こしは次の設定で統一しています。

• 言語をあらかじめ日本語に固定。自動判定で英語や中国語と誤判定されると出力が丸ごと崩れるため。
• 前の窓の文字起こし結果を次の窓の文脈に使わない設定。前の窓が誤ると誤りを連鎖させ、反復ループの温床になるため。
• ビームサーチの探索幅を5に設定。

温度フォールバックと退化検知。生成の「温度」を0から1.0まで複数段階用意し、圧縮率・平均対数確率・無音の確からしさから見て出力がおかしい（同じ文字を繰り返す「退化」）と判断した窓だけ、温度を上げて振り直します。良好な音質の窓は温度0の結果がそのまま使われるため、普通の音声の出力は一切変わりません。末尾の無音やノイズ窓でモデルが同じ文字を吐き続け、処理がそこから先へ進まなくなることがある既知の症状への対策です。

VAD（無音区間の自動カット）をあえて使いません。VADを挟むとデコードの単位が変わって語の精度が落ちる例を実測しました（VADあり「白玉菌」・VADなし「悪玉菌」）。電話音声のベンチマークでも、VADを使うと精度が下がる結果が出ています。無音の扱いはVADに任せず、①窓全体が無音ならスキップ、②窓の境界を無音点へ寄せて語が境界で割れないようにする、③モデル自身の無音の確からしさ、④圧縮率、⑤定型文フィルタ、の5段で守ります。

録音の窓は30秒です。Whisperは入力を内部で30秒の単位にそろえて処理するため、30秒窓は境界の数が最少で語が割れにくく、各窓がフルの文脈で精度が出ます。以前の15秒窓では「ボスポラス海峡」が「ボス」と「スパラス海峡」に境界で割れることがありました。現在は境界の影響を最小化する30秒窓に統一しています（最初の1窓だけは15秒にして、最初の文字が出るまでの待ち時間を短くしています）。

第3層：幻の文章・反復を、音声そのものと突き合わせて除去する

Whisperは動画の字幕データで学習しているため、無音や動画末尾で「ご視聴ありがとうございました」「チャンネル登録お願いします」を捏造することがあります。単純な文字列フィルタで消すと、会議の最後に本当に言った「ありがとうございました」まで消えてしまうため、完全ローカル文字起こしは2段構えで対処しています。

• 視聴・宣伝系の定型文は、全文一致のときのみ常に除去（長文の一部は触りません）。
• 「ご清聴ありがとうございました」「お疲れ様でした」のような本当に言うこともある挨拶は、モデルが「無音寄り」と判断したときだけ除去し、はっきり話された場合は残します。

リストにない未知の捏造文には話速ガードが効きます。有声時間に対して物理的に話しきれない量の文字が乗っていれば捏造と判定します。実測では、実際の発話は毎秒最大11.96モーラ程度でしたが、捏造された文章は毎秒55モーラに達しており、しきい値を毎秒18モーラに設定しています。「はい」「うん」のような短い相槌は確実に除外対象から外し、有声時間がほぼゼロで信頼できない場合は、圧縮率など補強証拠が無い限り捏造と断定しません。

消しすぎない設計。電話録音では、相手側の声だけがマイク側より極端に小さく記録されることがあります。話速ガードをそのまま適用すると、この小さな発話を無音と誤判定して消してしまう恐れがあるため、全体の音量が「小さいが無音ではない」帯域では話速ガードそのものを無効化します。捏造を1つ見逃すより、実際に話した内容を1つ消してしまう方が、この製品にとって影響が大きいと考えているためです。判定は音声全体ではなく短い区間ごとに行い、無音判定のしきい値も絶対値ではなく周囲の雑音レベルからの相対値にしているため、大声の話者と小声の話者が混ざる通話でも機能します。

反復にも手当てがあります。圧縮率が高すぎる区間は即座に除外し、「普通の文＋反復」が混ざったケースは、区切り記号で連結された同一語の3回以上の反復だけを1回に畳みます。「りんご、みかん、りんご、ぶどう」のような自然な列挙は壊しません。

単語帳を使う機能特有の事故として、「登録語の丸写し」もあります。小音量の窓でモデルが自信を失うと、認識のヒントとして与えた登録語をそのまま書き写してしまうことがあります。完全ローカル文字起こしは、登録語そのものが複数並ぶ区間を丸写しと判定して除去し、その窓をヒント無しで即座に再デコードして実際の発話を救済します。

第4層：専門用語・固有名詞を「ヒント」と「置換」の両方で正す。修正から自動で学ぶ

Whisperに専門用語を教える正攻法は、文字起こし開始時に渡す指示文（プロンプト）です。素のfaster-whisperでは毎回自分で文章を書いて渡す必要があり、しかも既定の設定では冒頭の窓にしか効きません。完全ローカル文字起こしは、日本語のファイル文字起こしで単語帳の登録語を最大180語、自然な文として自動生成して渡します（手動でプロンプトを書く必要はありません）。すべての窓に効かせたい場合は、実験的な機能として既定オフの追加ヒント（最大40語）も選べます。

ただし、ヒントは諸刃の剣です。音量が小さいと無音の確からしさが上がり（実測では-25dBの減衰で確からしさが0.32から0.53に上昇）、モデルがヒントをそのまま書き写してしまいます。そのため全体音量が小さいファイルではヒントを自動で外し、録音経由の文字起こしでは最初からヒントを渡しません。用語の認識ヒントより、実際に話した内容が潰されないことを優先する方針です。

後段の置換は語境界アンカーという方式です。単純な文字列の置換では、たとえば「化→科」を登録すると「文化」が「文科」に変わってしまったり、姓名の一部を登録すると関係ない語の内部まで置き換わってしまったりします。完全ローカル文字起こしは形態素解析でトークンの境界を求め、マッチの両端が語の境界に乗ったときだけ置換します。境界に乗らない部分一致は安全側で置換しません。登録語は長い順にマッチさせるため、長い固有名詞が短い語に横取りされることもありません。

そして自動学習です。結果編集画面で誤りを直すと、その修正が一定の基準（短い語であること、数字だけの語や話者ラベルを含まないこと、単語帳の他の登録と矛盾しないことなど）を満たした場合に、自動で単語帳へ登録され、過去に文字起こしした履歴全体へも反映されます。文字起こしのたびに表記ゆれの候補も自動抽出され、一定回数以上出現した候補は自動での置換に昇格します。誤認識されていそうな固有名詞をAIが見つけて単語登録を提案する機能もあり、本文に実在しない候補は破棄する安全網が付いています。使うほど、その現場の言葉に合っていくのは、この仕組みのためです。

第5層：「誰が言ったか」を付ける

文字起こしの精度は文字だけでは決まりません。会議録や通話記録では「誰が話したか」が無いと使えないことが多くあります。

左右のチャンネルに話者が分かれているステレオの通話録音は、左右を別々に文字起こしして時刻順に統合します。AIで推定するより確実だからです。モノラル録音の場合は、AIによる話者分離（発話区間の検出＋声の特徴の照合）を組み合わせて話者を見分けます。

モデルの選定は日本語の実際の音声で行いました。英語の学習データが中心のモデルでは、日本語の多人数会話で話者ターンの一致率が40.5%にとどまり、4人中1人しか検出できないことがありましたが、日本語を含むデータで学習されたモデルに切り替えると、同じ条件で一致率89.5%・4人全員の検出まで改善しました。人数をあらかじめ指定した場合はさらに別のモデルで強制的に分割し、声質の近い話者どうしでも正答率が0.804から0.964まで改善することを確認しています。無理に分割した結果が使い物にならない状態にならないよう、分割の品質を機械的な指標（クラスタのまとまりの良さ・切り替わりの頻度）でチェックし、基準を満たさなければ分割前の状態に戻します。誤った話者ラベルは、ラベルが無い状態より有害だと考えているためです。

配布前に、精度が落ちていないことを機械で確かめる

最後に、ここまでの主張を支えているのは検査の仕組みです。お客様の実際の音声で見つかった誤りをもとに評価用のデータを作り、新しいバージョンを配布する前に毎回自動でチェックしています。専門用語の聞き取り・話者分離それぞれに合格基準を設けており、基準を下回った場合はそのバージョンを配布しません。

推論エンジンを切り替えた際も、切り替え前の実装と同一の音声で出力を比較し、99.28%が一致すること（文字の誤り率0.72%）を確認したうえで切り替えました（当時の計測条件下の数値です）。

ハルシネーションとして削除した区間は、理由・時刻・本文・無音の確からしさなどの記録が残るため、あとから確認できます。単語帳を適用する前の本文も別途保存でき、結果編集画面から該当箇所の音声を再生して確認することもできます。AIが黙って消したり埋めたりしないことも、実務での精度の一部だと考えています。

使用しているAIモデル・エンジン

音声認識・話者分離に使っているAI・エンジンは次の通りです。いずれも配布ZIPに同梱された状態でお届けし、実行時に外部からダウンロードされることはありません。モデル本体がPC内で動作するため、音声・文字起こし結果が処理のために外部へ送信されることはありません。

CAM++・ERes2NetV2は、Alibaba DAMO Academyの3D-Speakerプロジェクトが公開しているオープンソースモデルで、開発元は中国です。いずれも配布ZIPに同梱されたモデルファイルとして端末内だけで実行され、モデルの開発元を含め、推論のためにいかなる外部サーバーとも通信しません。モデルの開発国にかかわらず、音声・テキストが外部に送信される経路自体が存在しない設計です。詳しくはFAQ Q32をご覧ください。要約機能で使用しているAIモデル（Gemma 4 12B・Google DeepMind製）についてはローカルAI要約ガイドをご覧ください。

よくある質問