ベンチマーク

ポッドキャスト・講義・カンファレンス・ニュース・決算説明会・国会中継など、日本語の動画 100 本（20 チャンネル、合計 81.7 時間）を、GPU 1 枚のデスクトップ PC だけで処理しました。

結論

• 文字起こしは音声 1 時間あたり約 5.5 分（実時間の 0.09 倍）。6.3 時間の国会中継も含めて、長さによる失敗や VRAM 不足は起きませんでした。
• 文字誤り率（CER）は 4.5〜16%。誤りの多くは固有名詞と同音異義語（「副首都」→「福祉」など）です。
• 要約は gemma4:e4b が速く、正確。音声 1 時間あたり gemma4:e4b は約 9.5 分、qwen3.5:4b は約 17 分。人の採点（正確さ、5 点満点）は 3.9 と 2.7 でした。
• qwen3.5:4b の要約には、中国語の混入（100 本中 8 本）や、参考資料にしかない内容の混入がありました。gemma4:e4b ではどちらも見られませんでした。
• 一方で、話者分けは人数を多めに数えがち（決算説明会で 8〜18 人など）で、gemma4:e4b の要約は長め（中央値 7,300 字）です。

速度と負荷

アプリの「音声ファイルのアップロード」に 1 本ずつ渡し、普段の利用と同じ流れで、話者付きの文字起こしと要約まで作りました。

• 通しでは、1 時間の音声が文字起こし＋要約で 15〜23 分です（gemma4:e4b で 15 分、qwen3.5:4b で 23 分）。
• GPU 使用率は平均 63%。VRAM は 6GB 中 最大 5.8GB で、ほかに GPU を使うアプリがあると足りなくなる水準です。
• 参考資料のあるセッションでは、録音後に「今回使った資料の範囲」を見直してコンテキストを作り直す処理に、1〜2 分かかりました。
• 長い音声ほど効率がよくなります。6.3 時間の国会中継は、待ち時間の無音が長く、18 分で終わりました。
• 要約の時間は、音声の長さより文字起こしの文字数にほぼ比例します。いちばん文字数の多い 3.3 時間の国会中継（4.7 万字）でも崩れませんでした。

文字起こしの品質

• フィラー（「えー」「あの」など）を両方から消しても、CER はほぼ変わりません（0.1 ポイント以内）。Whisper がもともとフィラーをあまり書き起こさないためです。
• 国会の 2 本（16.4%・14.8%）は、文字起こしの文字数が会議録より 1〜2 割少なく、動画と会議録で収録の範囲が少し違う影響を含みます。
• 誤りの傾向は、固有名詞（人名「簗」→「柳田」、登壇者名）と同音異義語（「副首都」→「福祉」、「歩行者天国」→「保護者天国」）。要約は、これらの誤りをそのまま引き継ぎます。用語リストは、この種の誤りを減らすための仕組みです。

正解テキストのない動画も含めた 100 本では、次のような結果でした。

• 定番の文（「ご視聴ありがとうございました」など、無音から作られやすい文）: 決算説明会で 1 本 9〜13 回と多いものの、質疑応答で実際に話されているもので、聞き間違いではありませんでした。ほかのカテゴリでは 1 本あたり 0〜2 回です。
• 30 秒以上の抜け: 国会中継・決算説明会・ニュースに多く（1 本最大 10〜12 か所）、採決や待ち時間、VTR の BGM の区間でした。音声のある区間の取りこぼしではありません。
• 同じ文の繰り返し: 最大でも 1 本 8 回（ニュース）。長い繰り返しで崩れた本はありませんでした。
• 話者分け: ポッドキャスト・講義・カンファレンスでは人数がほぼ正確でした。決算説明会では同じ人を別人として数えがちで（期待 2〜8 人に対して 8〜18 人）、国会中継では少なめに数えました。

要約の品質

同じ文字起こしから、Ollama 上の 2 つのモデル（どちらも 4B 級）で要約を作り、比べました。

• qwen3.5:4b は 1 秒あたりの出力は速いものの、答える前の「思考」に多くのトークンを使うため、全体では gemma4:e4b の 1.8 倍かかりました。

• 要約の文が元の話に支えられている割合は、gemma4:e4b 89%・qwen3.5:4b 85%。決算説明会と国会中継は、数字や固有名詞が多く、どちらのモデルでも低めでした。

• 人の採点（20 本、5 点満点）では、網羅（要点の拾い方）に大きな差はなく、差が出たのは正確さと読みやすさでした。

• qwen3.5:4b の減点の主な理由: 意味の通らない文、誤記（「サピア・フーフ」「法説」）、開催日・金額などの誤り、参考資料に入っていた別の回の内容の混入（3 本）。

• gemma4:e4b の減点の主な理由: 文字起こしの誤りの引き継ぎ、決算説明会などで要約が長すぎる（12,000〜16,000 字）。

計測の条件

結果は、次の条件とセットで載せます。条件が変われば、別の結果として扱います。

用語の説明:

• CER（文字誤り率）: 正解の文章と比べて、何文字分の置き換え・抜け・余計な文字があったかの割合。句読点と空白を除いて比べます。0% が完全一致。
• 実時間の〜倍（RTF）: 処理にかかった時間 ÷ 音声の長さ。0.1 なら 1 時間の音声を 6 分で処理できます。
• 音声 1 時間あたり: 1 本ごとの「処理時間 ÷ 音声の長さ」の中央値を、1 時間に換算した値。国会中継には待ち時間や無音が数時間続く本があり、合計で割るとその分だけ速く見えるため、中央値を使います。
• 要約の文が支えられている割合: 要約の箇条書きを 1 つずつ取り出し、文字起こしの近い箇所と照らして、多言語の推論モデル（NLI）で「支持・矛盾・不明」を判定した割合。機械判定なので目安です。

データセット

1 チャンネルあたり 5 本です。最初に選んだ 1 本（ニュース）が非公開になっていたため、同じ番組の別の回に差し替えました。動画の一覧（タイトル・URL・長さ・カテゴリ・参考資料の有無）は、上の「100 本の数字」とデータセットの CSV にあります。

失敗と、作り直したもの

最終的に、100 本すべてで文字起こしと 2 モデルの要約がそろい、計測から外した本はありません。途中で起きたことと、その扱いは次のとおりです。

• 作り直しのあいだ、ほかのアプリは GPU を使っていませんでした。集計に入れた数字は、すべて作り直した後のものです。
• 要約が止まったあと、アプリは自動では作り直しませんでした。今は手で作り直す必要があります。

限界

• 参考資料: スライドを用意したのは、資料を使う 3 チャンネル（AWS・トヨタ・ソフトバンクグループ）の 1 本目だけでした。チャンネル単位のプロジェクトで資料を共有したため、2〜5 本目は別の回の資料を参考に処理されています。用語リストの効果は正しく測れておらず、qwen3.5:4b の要約に別の回の内容が混じった原因にもなっています。
• 正解テキストがあるのは 10 本だけで、カテゴリ別の CER は出せていません。
• 要約の「支えられている割合」は機械の判定、人の採点は 1 人・20 本で、どちらも目安です。
• 1 台の PC での結果です。GPU やドライバが違えば、数字は変わります。
• 録音中のリアルタイムの文字起こし・要約は、今回の計測の対象外です。