OpenAIは、音声をテキストに変換する新しい文字起こしモデル「GPT-Transcribe」と「GPT-Live-Transcribe」をAPIに追加しました。前者は録音済みファイルやバッチ処理の非同期文字起こしに、後者は低遅延のライブ文字起こしに最適化されています。両モデルとも文脈の理解力が高められており、短いフレーズ、数字、専門用語、背景ノイズの大きい音声など、実環境で精度が落ちやすい条件に強いことが特徴とされています。

2つのモデルの位置づけ

• ▸GPT-Transcribe — 完成した音声ファイルやバッチワークロードの非同期文字起こしに最適化。ファイルをアップロードして最終的な書き起こしを受け取るか、処理中にテキストをストリーミングできる
• ▸GPT-Live-Transcribe — マイク・通話などのライブ音声ストリームから、話された端からテキストを得る低遅延のリアルタイム文字起こし向け

両モデルは文脈の理解力が高められており、アクセントや言語を問わず、短いフレーズ、数字、専門用語、背景ノイズの大きい音声といった実環境の音声に対して、より正確な文字起こしを提供するとしています。なお「ストリーミング出力」と「ライブ音声」は別の判断であり、完成済みファイルの文字起こしをストリーミングするだけならRealtimeセッションは不要で、音声がライブで到着する場合や持続的な接続が必要な場合にのみRealtimeを使うことが案内されています。

3種類の文脈ヒントで精度を高められる

• ▸prompt — 録音の話題や場面など、自由記述のコンテキスト
• ▸keywords — 製品名・薬品名・略語など、音声中に登場しうる具体的な用語
• ▸languages — 複数言語が混ざる可能性がある場合の、想定される入力言語のリスト

これらの入力は音声に関係する文脈にのみ使い、文字起こしタスク自体の指示を書かないこと、キーワードはあくまでヒントであり、音声に含まれる場合にのみ書き起こしに反映されることが注記されています。また新モデルは単数形の language ではなく複数形の languages フィールドを使います(既存モデルは従来どおり language)。Realtime APIセッションで入力文字起こしを行う場合や専用の文字起こしセッションでは、それまでに書き起こしたターンが自動的に文脈として利用されます。

ベンチマーク結果

• ▸文脈理解(Context Aware ASRベンチマーク) — GPT-Live-Transcribeの意味的精度は自由記述コンテキストなしで38.5%、ありで44.6%に向上。GPT-Transcribeは41.6%から45.2%に向上
• ▸Common Voice(22言語) — GPT-Transcribeの文字起こしエラー率は19.27%で、Whisper(whisper-1)の40.37%を大きく下回る。GPT-Live-Transcribeは19.70%で、GPT-Realtime-Whisper-1の20.33%を上回る精度
• ▸Real-World Audio Recordingベンチマーク(9言語) — GPT-Transcribeは8.98%(whisper-1は15.21%)、GPT-Live-Transcribeは9.60%(GPT-Realtime-Whisper-1は11.65%)のエラー率

特化機能が必要な場合の使い分け

• ▸話者ラベル付きの書き起こし(ダイアライゼーション) — gpt-4o-transcribe-diarize(ファイル文字起こし)
• ▸単語タイムスタンプや srt / vtt 字幕 — whisper-1(ファイル文字起こし)
• ▸録音の英語への翻訳 — whisper-1(audio translationsエンドポイント)
• ▸入力言語の検出 — gpt-transcribe(ファイル文字起こし)
• ▸WebSocket経由のターン確定型文字起こし — gpt-transcribe(リアルタイム文字起こし)

既存の統合では gpt-4o-transcribe、gpt-4o-mini-transcribe、gpt-realtime-whisper を引き続き利用できますが、新規の文字起こし統合で最初に選ぶモデルとしては推奨されていません。

導入前のテストに関する案内

OpenAIは、アプリケーションが実際に遭遇する音声条件でテストすることを推奨しています。具体的には、対象言語・アクセント・言語切り替えのパターン、背景ノイズ・マイク品質・電話音声、名前・数字・日付・英数字列・ドメイン用語、短い発話・長時間録音・中断された発話を含めること、そして単語誤り率だけに頼らず、医療ワークフローなら薬品名、サポートワークフローなら注文番号のように、アプリケーションにとって重要なエラーを追跡することを挙げています。