ガイド

文字起こしが同じ文を何度も繰り返すのはなぜか

録音のせいでも、ダウンロードが壊れているせいでもありません。誰も話していないときに Whisper がすることであり、それを止める具体的な方法があります。

30 August 2026

長い録音を文字起こしして、結果を開くと、途中からこうなっています。

[ Silence ]
[ Silence ]
[ Silence ]
[ Silence ]

もっと悪い場合には、ファイルの前のほうにあった実在の文を選び、それらしいタイムスタンプを付けて 40 回繰り返します。まるで誰かが本当に「ご視聴ありがとうございました」を 1 秒に 1 回、1 分間言い続けたかのように。

これは自動文字起こしに対する苦情として最も多いもので、OpenAI の Whisper を土台にしたツールはほぼすべて、何らかの形でこれを抱えています。原因を理解しておく価値があります。解決策は「もっと大きいモデルを買う」ではないからです。

実際に起きていること #

Whisper は言語モデルです。「言葉を聞いて書き取る」のではなく、音声とそれまでに書いた内容から、次に来る可能性が最も高いテキストの塊を予測します。

この捉え方が、この不具合を説明します。音声に発話が含まれていれば、次に来る可能性が最も高いテキストは、話されている言葉です。音声に発話がない場合、たとえば間、部屋の環境音、保留音、拍手、講師がホワイトボードへ歩いていく時間には、それでもモデルは何かを出力しなければなりません。「ここでは何も起きていない」を表すトークンはないのです。

そこでモデルは、手がかりがないときに言語モデルがすることに立ち返ります。つまり、同じことを繰り返します。ある文を書いたばかりなら、その文の統計的に最も自然な続きは似た文であり、その推測を否定するものが音声にないので、ループに入ってしまいます。Whisper は音声を 30 秒のウィンドウで処理するため、あるウィンドウがループに入ると、そのウィンドウ全体が同じ行になり、次のウィンドウは新しく始まるものの、しばしば再び同じことをします。

だからこの問題は、非常にはっきりしたパターンで現れます。

• 長い録音。 無音が多く含まれるためです。
• ファイルの中盤と終盤。 本題が終わった後もレコーダーが回り続けているところです。
• 音楽と拍手。 言葉を含まない密度の高い音声です。
• 話し手が小さく部屋がうるさい録音。 モデルが両者を分離できません。

マイクの近くで行われた 5 分のインタビューでこれが起きることはほとんどありません。全員が退出した後も 20 分レコーダーが回っていた 2 時間の会議では、ほぼ確実に起きます。

「[ Silence ]」や「[BLANK_AUDIO]」が同じ原因の別の症状である理由 #

Whisper の学習データには、[ Silence ]、[BLANK_AUDIO]、(music)、♪♪♪ といった角かっこ付きの注記を含む文字起こしがありました。そのため、発話でない音声に遭遇したとき、出力候補のひとつがこうしたマーカーになり、それが何度も繰り返されます。

こちらはまだ穏当なほうです。少なくとも、そこに何もないことについて文字起こしは正直だからです。それでも文書は数百行のごみで埋まりますし、ツールが無音のデコードに実際の時間を費やしていることに変わりはありません。

直す 4 つの方法 #

おおむね効果の大きい順に並べます。

1. 音声区間検出（本当の解決策） #

音声区間検出（VAD）は、文字起こしの前に動く小さな別のモデルで、音声のどの部分に人の発話が含まれるかを示します。文字起こし側には、その部分だけが渡されます。

これは原因のところで問題を解決します。ループが起きるのは、発話のない音声を Whisper に渡したときだけだからです。無音がモデルに届かなければ、そこで幻覚を起こすものもありません。空の部屋を 20 分デコードする手間もなくなるので、長いファイルの処理も速くなります。

広く使われているのが Silero VAD で、最近のバージョンの whisper.cpp はこれを直接サポートしています。使っているアプリに VAD や「無音をスキップ」のオプションがあれば、オンにしてください。なければ、開発者に要望として伝えるのは妥当なことです。

2. 自分で無音を切り取る #

ツールに VAD のオプションがない場合は、手作業で大まかに同じことができます。文字起こしの前に録音の前後を切り落とし、帰り支度の 20 分がそもそも処理されないようにするのです。

どの音声編集ソフトでもできます。面倒ですし、ファイルの途中にある無音には効きません。しかし「終わりにレコーダーが長く回っていた」という非常によくあるケースなら、30 秒で最悪の部分を取り除けます。

3. 後からマーカーを取り除く #

文字起こしが [ Silence ] や ♪♪♪ だらけなら、これらは検索・置換で簡単に削除できます。見分けのつく形をした行全体だからです。

ひとつだけ注意してください。削除するのは、行全体がマーカーであるものだけにします。「それで——（笑）——リリースしたんです」のような行は本物の発話なので、残したいはずです。まさにこのルールを、優れたアプリなら代わりに適用してくれます。

4. ファイルを分割する #

ループは Whisper のウィンドウの範囲に収まるので、長い録音を短く切り分ければ被害を限定できます。悪いウィンドウが台無しにするのは 1 分ぶんで、繰り返しの壁と地続きにはなりません。内部でこれを行うアプリもあります。

これは解決策というより回避策です。被害範囲を小さくするだけで、無音に対してモデルが幻覚を起こすこと自体は止められません。

効かないこと #

大きいモデル。 Base から Large にすると時間とディスクを大きく消費しますが、ループはなくなりません。原因は能力不足ではなく、発話を含まないものを文字起こしさせられていることだからです。大きいモデルもループします。（サイズのトレードオフについて詳しくはこちら。）

クラウドサービス。 優れたクラウドツールはパイプラインの中で VAD と後処理を実行しており、だからこそこの問題に遭遇する頻度が低いのです。その下にある仕組みは同じで、静かなファイルで「ありがとうございます」を 50 回出力するものは今も少なくありません。分単位で払っても、別のデコーダーが手に入るわけではありません。

もう一度実行する。 Whisper のサンプリングは完全に決定的ではないので、2 回目は別の場所でループするかもしれません。それは解決ではなく、コイン投げです。

私たちの対応 #

ここで曖昧な答えは役に立たないので、具体的に書きます。

Offline Transcription は、文字起こしの前に Silero VAD を実行し、無音や非発話の区間がデコーダーに届かないようにしています。加えて、[ Silence ] のようにセグメント全体がマーカーである行や、音楽記号だけの行は結果から除外し、角かっこ付きの補足を含むだけの行は残します。そちらは本物の発話だからです。

長いファイルではウィンドウ単位で文字起こしし、各ウィンドウを音声の最も静かな点で区切ります。これにより、境界が文の途中ではなく文と文の間に落ちます。

正直な但し書きとして、これは繰り返し問題を非常に稀にしますが、起きないようにするわけではありません。Whisper ベースのツールは、私たちのものも含めて、予測を行う言語モデルであり、予測する以上は間違えることがあります。精度が重要なものを文字起こしするなら、頼りにするつもりの箇所は音声と突き合わせて読んでください。その手早いやり方はインタビューのガイドで扱っています。

まとめ #

このループは、発話のない音声に対して Whisper がテキストを予測している結果です。音声区間検出は、その音声をそもそも見せないことで原因を取り除きます。ツールに VAD がなければ、無音のトリミングとマーカーの除去が役立ちます。大きいモデルはまったく役に立ちません。