Whisper APIで日本語字幕生成を自動化する実務設計ガイド：前処理と整形ロジックで修正工数を劇的に減らす

導入

「Whisper APIを使えば、動画の字幕作成は完全に自動化できるはずだ」

そう考えて実装を進めたものの、実際に出来上がった字幕データを見て頭を抱えた経験はないでしょうか。無音のはずの区間で「ご視聴ありがとうございました」という謎のテキストが生成されていたり、話者の息継ぎを無視して文章が延々と続いていたり、あるいはタイムスタンプが微妙にズレていて動画と口元が合わない……。

多くのプロジェクトにおいて、これらはWhisperというモデルの特性を理解せずに「ただAPIを叩いただけ」のシステムで必ず発生する現象です。OpenAIのWhisperは確かに革命的な認識精度を誇りますが、それはあくまで「音声からテキストへの変換能力」の話であり、「字幕データとしての品質」を保証するものではありません。

実務で使えるレベルの字幕自動生成システムを構築するためには、APIの手前にある「前処理」と、出力後の「後処理」を含めたパイプライン全体の設計が不可欠です。特に後処理において、テキスト整形の目的でOpenAIの言語モデルを組み合わせるケースが一般的ですが、ここでも注意が必要です。OpenAI公式サイト（2026年2月時点）によれば、GPT-4o等のレガシーモデルが順次廃止され、GPT-5.2が新たな標準モデルへ移行するなど、APIの提供状況は常に変化しています。古いモデルに依存した設計のままでは、突然システムが稼働しなくなるリスクを抱えることになります。

パイプライン全体の設計をおろそかにすると、結局は人間がすべての字幕を手作業で修正することになり、導入コストに見合わない結果に終わります。

本記事では、Python等を用いたシステム実装を検討中のエンジニアや技術選定担当者の方に向けて、修正工数を最小限に抑えるための「字幕生成ワークフロー」の設計図を共有します。信号処理の観点から音声データを分析し、品質と速度のバランスを追求するアプローチに基づき、最新のAPIモデル移行にも柔軟に対応できる実践的な知見を提供します。

なぜWhisper API単体では「実務で使える字幕」にならないのか

まず、実務の現場で直面する課題の正体をはっきりさせましょう。Whisperは非常に優秀なモデルであり、現行の最新バージョンでは認識精度がさらに向上しています。しかし、動画の字幕生成というタスクにおいては、依然としていくつかの「仕様上の癖」が大きな障壁となります。

「高精度」の落とし穴：ハルシネーションと無音区間

Whisperを利用していて最も厄介なのが「ハルシネーション（幻覚）」です。これは、音声入力がない、あるいは単なるノイズしかない区間に対して、AIがもっともらしい文章を勝手に生成してしまう現象です。

特に日本語の学習データには動画配信サイトのコンテンツが多く含まれていると推測され、無音区間で突然「チャンネル登録お願いします」や「字幕：〇〇」といった、音声には存在しないテキストが出力されるケースが報告されています。APIに長時間の動画ファイルをそのまま投げると、BGMのみのシーンや長い沈黙において、最新モデルであってもこのハルシネーションが発生するリスクがあります。

これはモデルの不具合というよりは、確率論的に「次に続く単語」を予測する言語モデルの性質によるものです。したがって、API単体でこれを完全に防ぐことは難しく、システム側で「音声が存在しない区間はAPIに投げない」といったVAD（音声区間検出）などの制御が不可欠になります。

字幕生成特有の制約：文字数制限とタイムスタンプのズレ

「自動文字起こし（議事録）」と「字幕」は、似て非なるものです。議事録なら発言内容が正確なら問題ありませんが、字幕には視聴体験を損なわないための厳しい制約があります。

• 視認性の制約: 人間がパッと見て理解できる文字数は、一般的に1秒あたり4文字程度、1行あたり13〜15文字程度と言われています。Whisperは文法的な区切りでテキストを出力しますが、視認性を考慮した改行や行数調整までは行ってくれません。
• 同期の制約: 字幕は発話と同時に表示され、発話終了とともに消える必要があります。しかし、Whisperのタイムスタンプ出力はトークン単位の推論に基づいており、特に早口や不明瞭な発話、あるいはBGMが重なる箇所では、実際の音声波形の開始・終了時刻とズレることがあります。

APIの生の出力をそのままSRTファイル（字幕データ）に変換すると、画面いっぱいに文字が詰まった読みづらい字幕や、口パクと微妙に合っていない字幕が出来上がってしまいます。

手動修正コストが残るワークフローの共通点

結局のところ、API導入に失敗するプロジェクトの多くは、「APIからのレスポンス = 完成品」と捉えてしまっている傾向があります。

「誤字脱字の修正」「改行位置の調整」「タイミングの微調整」「幻覚の削除」。これらをすべて人間が後から行うのであれば、既存のGUIツールを使っているのと変わりません。目指すべきは、これらの修正作業を限りなくゼロに近づける、あるいは「確認してOKボタンを押すだけ」の状態にまで持っていくことです。

そのためには、APIを単なる「高精度な文字起こし機」として使うのではなく、前処理や後処理を含めた音声信号処理の知見を取り入れたシステム設計が必要になります。

修正工数を半減させる理想的な字幕生成パイプライン設計

では、具体的にどのようなアーキテクチャを組めばよいのでしょうか。実務運用において推奨される標準的なパイプラインを紹介します。

全体像：入力からSRT出力までの5段階プロセス

高品質な字幕を自動生成するためには、以下の5つのステップを順に実行するバッチ処理フローを構築します。

1. 音声抽出・正規化: 動画から音声を分離し、AIが処理しやすい形式に変換。
2. 前処理 (VAD): 音声区間検出を行い、発話がある部分だけを切り出す。
3. API実行 (Recognition): 切り出した音声に対してWhisper APIを実行。
4. 後処理 (Formatting): テキストの整形、フィラー除去、句読点調整。
5. 出力 (SRT Generation): タイムスタンプを再計算し、字幕ファイル化。

この中で特に重要なのが、ステップ2の「前処理」とステップ4の「後処理」です。多くの実装例ではここが省略されがちですが、こここそが品質を左右する肝です。

ボトルネックの特定：どこで精度が落ちるのか

なぜこのフローが必要なのでしょうか。Whisper API（特に whisper-1 モデル）には、一度に処理できるファイルサイズ（25MB）の制限があります。また、長時間の音声を一度に処理させると、後半に行くにつれて文脈を見失い、精度が低下したり、タイムスタンプが大きくズレたりする傾向があります。

さらに、APIは「音声をテキストにする」ことには長けていますが、「どこからどこまでが意味のある音声か」を判断するのは苦手です。この判断（セグメンテーション）をAPI任せにせず、前処理で明示的に行うことで、APIの負荷を下げつつ精度を安定させることができます。

コストと処理時間のトレードオフ検討

このパイプラインを採用すると、処理工程が増えるため実装工数は上がりますが、運用コスト（API利用料）の最適化にも寄与します。

無音区間やノイズ区間を前処理でカットすることで、APIに送信する総時間が減少し、従量課金のコストを削減できます。また、音声を細かく分割して並列処理（マルチスレッド化）することで、全体の処理時間を短縮することも可能です（ただしAPIのレート制限には注意が必要です）。

品質、コスト、速度。これらをコントロール下に置くためにも、パイプライン化は必須の戦略と言えます。

【Step 1: 前処理】AIが「聴き取りやすい」音声データの作り方

ここからは各ステップの詳細を解説します。まずはAPIに投げる前のデータの準備です。「Garbage In, Garbage Out（ゴミを入れたらゴミが出る）」はAIの鉄則です。

サンプリングレートとビットレートの最適解

動画ファイルに含まれる音声は、44.1kHzや48kHzのステレオ音声であることが一般的です。しかし、Whisperのモデル内部では 16kHzのモノラル音声 として処理されます。

API側で自動変換してくれる場合もありますが、通信量を減らし、予期せぬ変換エラーを防ぐために、クライアント側で ffmpeg 等を用いて事前に変換しておくことを強く推奨します。

• サンプリングレート: 16,000Hz
• チャンネル: モノラル (1ch)
• コーデック: MP3などのファイルサイズ効率が良いフォーマット

これにより、25MB制限の中でより長時間の音声を送ることが可能になります。

BGM・ノイズ除去の必要性とツール選定

インタビュー動画やセミナー動画では、BGMや環境音が認識精度を著しく下げることがあります。特に日本語の字幕生成では、BGMの歌詞を拾ってしまうケースも散見されます。

これを防ぐために、音声強調（Speech Enhancement）技術や音源分離技術を活用します。Pythonであれば、Meta社が公開している Demucs などのライブラリを使用することで、BGMとボーカル（話し声）をきれいに分離できます。処理時間はかかりますが、BGM入りの動画を扱う場合は、この「ボーカル抽出」の工程を挟むだけで、字幕の正解率は劇的に向上します。

Voice Activity Detection (VAD) による無音カットの理論

前処理の最重要パートが VAD（Voice Activity Detection：音声区間検出） です。

これは、「音声波形の中で、人間が喋っている区間はどこか」を判定する技術です。Silero VAD や WebRTC VAD といった軽量なライブラリで実装可能です。

Whisper APIに動画の音声を丸ごと投げるのではなく、VADを使って「発話区間（チャンク）」ごとに音声を切り出し、それぞれのチャンクに対してAPIリクエストを行います。

VAD導入のメリット:

1. ハルシネーションの撲滅: 無音区間をAPIに渡さないため、幻覚が発生する余地がなくなります。
2. タイムスタンプ精度の向上: 短い区間ごとに認識させるため、時間のズレが蓄積しません。
3. リトライの容易性: エラーが発生しても、そのチャンクだけ再実行すれば済みます。

VADの設定では、「何秒以上の無音で区切るか」「どの程度の音量を音声とみなすか」という閾値調整が重要になりますが、ここをチューニングすることで対象コンテンツに最適な分割が可能になります。

【Step 2: API実行】文脈を理解させるプロンプトエンジニアリング

前処理でクリーンな音声チャンクができたら、いよいよWhisper APIを呼び出します。ここではパラメータ設定が鍵を握ります。

initial_promptパラメータの正しい使い方

音声を細かく分割してAPIに投げると、「文脈が切れる」という問題が発生します。例えば、前のチャンクで「私は」と言い、次のチャンクで「エンジニアです」と言った場合、後者だけでは主語が分からず、誤変換（例：「エンジニアです」→「演じ、庭です」など）が起きる可能性があります。

これを解決するのが prompt（または initial_prompt）パラメータです。ここには、直前のチャンクで認識されたテキスト を入力します。

# 概念的なコード例
response = client.audio.transcriptions.create(
    model="whisper-1",
    file=audio_chunk,
    prompt="前のチャンクの認識結果テキスト..."  # ここで文脈を渡す
)

こうすることで、Whisperは「前の文脈」を理解した状態で次の音声を推論できるため、固有名詞の一貫性や文体の統一感が保たれます。これは分割処理を行うパイプラインでは必須の実装です。

専門用語と固有名詞の認識精度を高める辞書戦略

組織内の専門用語や製品名、特殊な業界用語は、デフォルトのWhisperでは正しく認識されないことが多いです。残念ながらWhisperには「辞書登録機能」そのものはありませんが、この prompt パラメータが擬似的な辞書として機能します。

プロンプトの先頭に、認識させたい単語リストや、文章のスタイルガイドを含めるのです。

• 例: 「KnowledgeFlow、Whisper API、Python。句読点を含めて書き起こしてください。」

このように指示を含めることで、未知の語彙に対する感度が上がり、また「、」や「。」の付与ルールも制御しやすくなります。

温度パラメータ（temperature）による創造性の制御

temperature パラメータは、モデルの「創造性」や「ランダム性」を制御します。字幕生成においては、創造性は不要です。事実を正確に書き起こしてほしいので、この値は可能な限り 0 に近づけます。

デフォルトでは0以外になっている場合もありますが、字幕用途では temperature=0 を基本とし、もし同じフレーズを繰り返すなどのエラーが出た場合のみ、わずかに数値を上げる（フォールバックする）ロジックを組むのが定石です。

【Step 3: 後処理】読みやすい字幕へ整形するルールベース処理

APIからテキストが返ってきても、まだ終わりではありません。ここからが「視聴者のための」調整です。

句読点と改行位置の自動調整アルゴリズム

Whisperが出力するテキストは、句読点が含まれていたりいなかったり、あるいは長文が一行で返ってきたりと不安定です。字幕として表示するには、適切な位置での改行が必要です。

ここでは、自然言語処理ライブラリを活用します。例えばGoogleが開発した BudouX などを使えば、日本語の文節を考慮した自然な改行位置を判定できます。

1. 文字数チェック: 1行が規定文字数（例：15文字）を超えているか確認。
2. 改行挿入: 超えている場合、BudouX等で判定した文節の区切りで改行コードを挿入。
3. 行数制限: 3行以上になる場合は、タイムスタンプを分割して別の字幕ブロックとして扱う。

このロジックを挟むだけで、字幕の読みやすさはプロの仕事に近づきます。

「えー」「あの」フィラー削除の最終フィルター

Whisperは「えー」「あー」といったフィラー（言い淀み）をある程度自動で削除してくれますが、完全ではありません。また、プロンプトで指示しても残る場合があります。

これらは、API実行後に単純な正規表現（RegEx）を用いたルールベースの置換処理で削除するのが確実です。

• 削除対象リスト: ^えー、, ^あのー、, ^そのー、 など

ただし、会話のニュアンスとして残したい場合もあるため、この処理はオプションとして切り替えられるように設計しておくと良いでしょう。

SRTフォーマットへの変換とタイムスタンプ補正

最後に、整形されたテキストと、VADで切り出した際のタイムスタンプ情報を結合し、SRT形式（またはVTT形式）に書き出します。

ここで重要なのが、タイムスタンプのオフセット加算 です。VADで音声を切り出すと、各チャンクの開始時間は「0秒」から始まります。これを、元の動画全体における「開始時間」に合わせてオフセット（加算）する必要があります。

SRT開始時間 = チャンクの動画内開始時間 + Whisperが出力した開始時間

この計算を正確に行わないと、動画が進むにつれて字幕がどんどんズレていくことになります。

運用と継続的改善：自社専用モデルへ近づける

システムを構築し、運用を開始した後も改善の余地はあります。完全自動化を目指しつつも、人間が関与する部分を戦略的に残す「Human-in-the-loop」の考え方が重要です。

誤認識パターンの蓄積と辞書更新フロー

運用していく中で、「この製品名は必ず間違えられる」「特定の名前の漢字が違う」といったパターンが見えてきます。これらを修正したログは宝の山です。

修正履歴を定期的に分析し、頻出する誤変換単語を prompt に注入する「辞書リスト」に追加していくフローを確立しましょう。これにより、システムを使えば使うほど、特定のドメイン知識に特化した高精度な字幕生成機へと育っていきます。

ユーザーフィードバックの収集サイクル

動画編集者や視聴者からのフィードバックも重要です。「字幕の表示時間が短すぎて読めない」「改行位置が不自然」といった声は、後処理ロジックのパラメータ（文字数制限や表示時間の最低保証値など）を調整するための重要な指標となります。

エラーハンドリングとリトライ戦略

APIは常に安定しているわけではありません。OpenAIのプラットフォームは急速に進化しており、利用可能なモデルや機能が頻繁に更新されています。これに伴い、APIの仕様変更やレート制限（Rate Limits）の変動が発生する可能性があります。

システム設計においては、エクスポネンシャル・バックオフ（指数関数的な待機時間増加）によるリトライ処理の実装が不可欠です。また、クラウド側のAPIが完全に応答しなくなった場合に備え、ローカル環境で動作するWhisperモデル（faster-whisperなど）へ自動的に切り替えるフェイルオーバー構成を検討することも、業務の可用性を高める有効な手段です。公式ドキュメントで最新のステータスと仕様を定期的に確認する運用フローを確立しましょう。

まとめ

Whisper APIを活用した字幕自動生成は、単にAPIを呼び出すだけでは完成しません。音声信号処理の観点からの「前処理」、言語モデルの特性を理解した「プロンプト設計」、そして視聴者視点での「後処理」。これらを組み合わせたパイプラインを構築することで初めて、実務で耐えうる品質と効率化が実現します。

• VADによる前処理で、ハルシネーションとタイムスタンプズレを防ぐ。
• 文脈考慮プロンプトで、固有名詞の精度と一貫性を保つ。
• ルールベースの後処理で、視認性の高い字幕フォーマットに整える。

この3点を押さえたシステム設計を行えば、従来の手作業による修正工数は劇的に削減されるはずです。AIは魔法の杖ではありませんが、正しいロジックで使いこなせば、強力なツールになります。

より詳細な実装手順やパイプラインの設計については、公式ドキュメントや専門的な技術資料を参照し、システム構築に役立てることをおすすめします。