【ブラウザ文字起こし】Whisperが動く仕組みとメリット

「ブラウザだけでWhisperが動く」という説明を聞いても、裏側が見えないと不安になります。実際には、音声ファイルをサーバーに送るのではなく、端末のメモリ上でモデル推論を行う構成になっています。情シスや法務への説明では「アップロード先のクラウド」ではなく「利用者端末内の処理」という言葉が効きます。本記事では、技術者でなくても追える粒度で流れを整理します。

クラウドASRと何が違うのか

従来のクラウド文字起こしは、音声をAPI経由で送り、サーバー側GPUで推論してテキストを返す形が主流でした。ブラウザ内Whisperは、その推論場所がユーザー端末に移ります。代わりに初回にモデル重み（ONNX）をダウンロードし、ブラウザキャッシュに保持します。長尺処理では端末メモリがボトルネックになりやすい一方、機密会議では「送信しない」メリットが大きくなります。詳細なプライバシー観点はローカルWhisperとプライバシーを参照してください。

処理の流れ（6段階）

1. ユーザーが音声・動画ファイルを選択またはドロップする。
2. ブラウザがオーディオをデコードし、Whisper向けの16kHzモノラルへ変換する。
3. 長い音声は約30分単位のチャンクに分割され、タイムスタンプ用オフセットが付く（長尺分割）。
4. 各チャンクがWeb Workerへ渡され、メイン画面の操作をブロックしない。
5. Transformers.js経由でONNX形式のWhisper系モデルが推論し、セグメント単位のテキストが返る。
6. 結果が画面に反映され、途中経過がIndexedDBなどに保存される。

音声文字起こしツールはこの構成で、登録やAPIキーなしで試せます。日本語向けモデル（kotoba-whisper系）と汎用軽量モデルを切り替えられる点が、日本語会議録向けの実務的な設計です。

Web Workerが重要な理由

Whisper推論は秒〜分単位でCPU/GPUを使います。メインスレッドで動かすと、タブ全体が固まり、ユーザーは「落ちた」と感じます。Workerに逃がすことで、文字起こし中もテキスト編集や頭出し再生ができます。エディタとして使うツールでは、この分離が体験品質を左右します。進捗表示やキャンセルもWorker経由で実装され、長尺でも操作感を保ちやすくなります。

モデル取得とキャッシュの考え方

初回アクセス時、モデルファイルがCDNから取得されます。軽量モードで150〜200MB、高精度で650〜750MB程度が目安です。2回目以降はブラウザキャッシュが効き、待ち時間が短くなります。社内一斉導入日は帯域を押さえ、事前に各PCでダミー録音を1回本実行してキャッシュを温めると現場がスムーズです。プロキシでブロックされる場合はIT部門への許可確認が必要です。

WebGPU・WASMと速度の関係

WebGPUが使える端末では、推論が大幅に速くなることがあります。非対応環境ではWASMへフォールバックし、同じ精度でも時間が伸びます。速度より安定を取るなら軽量モード＋用語辞書の方が、総作業時間は短く終わるケースもあります。録音品質はマイク環境で半分決まる点も変わりません。

クラウドASRとの比較表

メリットを活かす4つのポイント

1. 軽量モードで試し、日本語の誤変換が多ければ高精度モードへ切り替える
2. 30分超の録音は長尺分割を前提に計画する
3. 固有名詞は辞書とポストエディットで仕上げる
4. 字幕が必要ならSRT・VTT書き出しまで一連で確認する

よくある誤解

「ブラウザ＝常に弱い」わけではありません。一方で「サーバー級GPUと同じ速度」も期待できません。用途を議事録ドラフトや字幕の一次稿に置くと、期待値と実装が噛み合います。会議録音の実務フローは会議録音の議事録手順が具体例になります。

まとめ

ブラウザ文字起こしは「アップロード不要のローカル推論」が核心です。初回だけモデル取得があり、その後はオフラインに近い運用が可能になります。仕組みを理解しておくと、落ちたとき・遅いとき・精度が足りないときの打ち手が選びやすくなります。音声文字起こしツールで短い録音から体験し、スマホ録音の文字化と組み合わせた一日フローを試してみてください。