OpenAIの新しい文字起こしAPIは、録音済み音声向けの gpt-transcribe と、到着中のライブ音声向けの gpt-live-transcribe に分かれます。会議ログ、コールセンター、字幕、バッチ処理など、テクノロジー現場でSTTを本番投入するとき、まずこの用途二分を固定しないと、遅延・精度・移行コストが混線します。
📑目次
固有名詞、顧客ID、金額、型番が1語ずれるだけで、CRM検索や要約、チケット分類が連鎖的に壊れます。
本記事では、次の一次情報と独立整理を突き合わせます。
- 公式 Transcription ガイド
- Cookbook の移行手順
- OpenAI Developer Community のベンチマーク告知
- 窓の杜・GIGAZINE・Microsoft Foundry の独立整理
そのうえで、使い分け・コンテキスト指定・Whisper系からの非ドロップインギャップ・料金シグナル・導入チェックリストまで実務順に整理します。
GPT-TranscribeとGPT-Live-Transcribeの位置づけ
新規統合の推奨開始
結論から言うと、新規統合の推奨開始は次の二分です。
- 完了ファイル →
gpt-transcribe - Realtimeのライブ到着 →
gpt-live-transcribe
OpenAIのTranscriptionガイドは、この対応をワークフロー表で明示しています。
ストリーミング出力とライブ入力の違い
ここで混同しやすいのが「ストリーミング出力」と「ライブ入力」です。
- 録音がすでに揃っているファイルなら、Realtimeセッションなしでもストリーミング出力を選べます。
- マイクや通話が今届いているなら、低遅延向けの
gpt-live-transcribeをRealtime経路で使う判断になります。
Microsoft Foundryの整理でも、用途は次のように分かれます。
- 非同期: 会議・ボイスメール・メディア
- ライブ: キャプション・コンタクトセンター・アクセシビリティ
レガシーモデルとの関係
既存の次のモデルは継続利用できます。
gpt-4o-transcribegpt-4o-mini-transcribegpt-realtime-whisper
ただし公式の「新規推奨開始」は新しい2モデル側です。全部をRealtimeに寄せる必要はありません。バッチ高精度とライブ低遅延を、プロダクト要件ごとに分離して選ぶのが安全です。
発表メッセージの読み方
GIGAZINEやOpenAI Developer Communityの告知では、次の耐性が強調されています。
- 短いフレーズ
- 数字
- 専門用語
- 大音量ノイズ
- アクセント横断
楽器を鳴らしながら話すデモのようなノイズ耐性アピールもありますが、自社ドメインの固有名詞精度は自前フィクスチャで測る前提で読んでください。
ファイル／ライブ／レガシーの使い分け表
分類の分岐点
まずは自プロダクトの音声を「完了音声」か「到着中音声」かに1行で分類してください。その一行がモデル選定の分岐点になります。
用途別の対応表
| 用途 | 推奨モデル | 入力の形 | 主な強み | 注意点 |
|---|---|---|---|---|
| 録音済み会議・Voicemail・メディア | gpt-transcribe | 完了ファイル／バッチ | 高精度、検出言語メタ | SRT/VTT・単語タイムスタンプは非対応想定 |
| ライブ字幕・到着中マイク | gpt-live-transcribe | Realtime連続ストリーム | 低遅延、delay調整 | 初期契約では検出言語予測なし |
| 確定ターン後の最終文 | gpt-transcribe（Realtime commit） | input_audio_buffer.commit 後 |
チャンク確定後の高精度 | 連続ライブ字幕とは別経路 |
| 字幕SRT/VTT・単語TS | whisper-1 継続 | ファイル | 既存フォーマット互換 | 新モデルへドロップイン不可 |
| 英語翻訳 | translations＋対応モデル | ファイル | 翻訳専用経路 | 新モデル置換ではない |
| 話者分離 | gpt-4o-transcribe-diarize | ファイル diarized_json | 話者ラベル | Realtime非対応。長い音声はchunking要確認 |
出典（2026年8月時点）
表の読み方
表の読み方は単純です。出力契約（字幕、単語TS、話者ラベル、翻訳）が現行必須なら、新モデルへ全部寄せずレガシー経路を残します。逆に、会議要約や検索用の全文テキストが主目的なら、gpt-transcribe を中心に寄せられます。
コンテキスト指定 — prompt / keywords / languages
3種パラメータの役割
精度改善の中核は「先に言っておく」をAPIパラメータとして分離することです。公式が示す3種は次のとおりです。
prompt
会議の議題、通話の場面、参加者属性など自由記述の文脈。タスク説明の再掲は不要です。keywords
製品名、薬剤名、略語、社内コードなどリテラル用語のヒント。必須出力ではありません。languages
想定入力言語の配列。旧来の単数languageと同時送信しないでください。日英混在なら["ja","en"]のような形を試します。
セッション運用での自動コンテキスト
Realtimeや専用transcriptionセッションで gpt-transcribe を使う場合、先行ターンの書き起こしが自動コンテキストになる点も運用設計に効きます。
- ライブ連続字幕
- commit後の最終確定
この2つを分けて設計すると、途中の揺れと最終精度を切り分けやすくなります。
ベンチマークが示す方向
ベンチマークは「コンテキストありで上がる」方向を示します。OpenAI Developer Community告知では、次のように報告されています。
- Context Aware ASRの意味的精度: free-form context なし 38.5% → あり 44.6%
- Common Voice 22言語のエラー率: 19.70%（比較対象 GPT-Realtime-Whisper-1 は 20.33%）
- Real-World Audio 9言語: 9.60% 対 11.65%
報道の「誤認識が半減」表現はベンチマーク文脈の要約であり、自社音声での再現を約束するものではありません。
keywordsの実務注意
keywordsの実務注意は2点です。
- Cookbook上、keywordsは単一行リテラルで、
<>や改行を含めるとリクエスト全体が拒否されます。 - keywordsは強制辞書ではありません。発話されていないヒント語が出力に混入する keyword hallucination は、評価で落とすべき失敗です。
現場では、用語集を keywords、議題を prompt、混在言語を languages に分け、用語集の更新担当を決めると再現性が上がります。
Whisper系からの移行と置き換えできない機能
移行パスの3本
エンドポイントが同じでも、フィールド契約と出力契約は変わります。Cookbook（2026-07-28）の移行パスは次の3本です。
- 録音ファイル:
whisper-1→gpt-transcribe（POST /v1/audio/transcriptions） - 連続ライブ:
gpt-realtime-whisper→gpt-live-transcribe（session.update） - 手動commit後の高精度: Realtimeで
gpt-transcribe＋input_audio_buffer.commit
主な契約変更
主な変更点は次です。
- 単数
language→languages[] - 自由形式promptへの語彙混在をやめ、
promptとkeywordsを分離 - 検出言語メタは
languages:[{code}]。信頼が低い場合は空配列[]があり得る - ライブ側は
delay（例: low）で、部分文の速さと最終精度をトレードオフ
ドロップインではない機能
ドロップインではない機能は先に棚卸ししてください。
- 字幕 SRT/VTT、単語タイムスタンプ →
whisper-1継続 - 英語翻訳 → translationsエンドポイント
- 話者分離 →
gpt-4o-transcribe-diarize
よくある誤り
よくある誤りは次の4つです。
- ファイルのストリーム出力をマイクライブ入力と混同する
languageとlanguagesを同時送信する- 検出言語の空配列
[]をAPIエラーと誤認する keywordsを必ず出る用語だと誤解する
移行前に、現行が必要とする response_format、字幕、diarize、翻訳を一覧化し、「残す経路」と「新モデル経路」を分けた設計図を書いてください。
料金シグナルと導入前チェックリスト
料金シグナルの読み方
料金はチャネル表記が異なります。報道・整理で見える例は次のとおりです。
- 窓の杜・GIGAZINE（OpenAI API 系 per-minute 報道）: Live $0.017/分、Transcribe $0.0045/分
- Microsoft Foundry Global Standard の例: Live $1.02/hour、Transcribe $0.27/hour（audio）
最終的な source of truth は各コンソールの現行価格表です。単位換算だけ揃えて比較し、本番トラフィックで再試算してください。
導入前チェックリスト
導入前評価は、WERだけ見て切替えないことが要点です。Cookbookと公式テスト指針を実務チェックに落とすと次のようになります。
- 固有名・ID・数字の exact-match を測る（WER以外）
- ノイズ／短発話／コードスイッチ／ささやきの代表音声を含める
- keyword hallucination（未発話ヒント語の挿入）がゼロか確認する
- ファイルstreamとライブの TTFT / p95 を分けて測る
- 部分テキストの揺れと item_id の突合方法を決める
- 再接続・空音声・中断セッションを再現する
- 価格と rate limit を本番想定トラフィックで試算する
比較条件の置き方
比較条件は最低3つが扱いやすいです。
- baseline（現行モデル）
- model-only（新モデル、コンテキスト最小）
- context付き（prompt / keywords / languages を本番相当に設定）
代表音声は5〜10本を固定セット化し、カットオーバー条件を「keyword hallucinationゼロ」と「p95遅延がSLO内」に置くと、感覚論の切替えを避けられます。
関連記事:
- ChatGPTのGPT-Liveとは｜全二重音声・Live-1とmini・制限と設定
- Adobe for ChatGPTの導入手順｜70超ツール統合と制限
- OpenAI「長時間モデル時代の safety/alignment」— 軌道監視・サンドボックス迂回・反復配備の教訓
よくある質問（FAQ）
Q1. gpt-transcribe と gpt-live-transcribe の最短の選び方は？
音声がすでに揃っているなら gpt-transcribe。マイクや通話が今届いているなら gpt-live-transcribe です。
Q2. prompt には何を書けばよいですか？
録音の場面、トピック、参加者属性など自由記述です。固有名詞のリテラル一覧は keywords に分離してください。
Q3. keywords を渡せば、その語は必ず出力されますか？
されません。ヒントです。未発話語の挿入は評価で落とすべき失敗です。
Q4. Whisper の SRT 出力をそのまま新モデルで使えますか？
ドロップインではありません。字幕や単語タイムスタンプが必要なら whisper-1 継続を検討してください。
Q5. 検出言語が空配列 [] はエラーですか？
Cookbook上、信頼できない場合の有効な結果です。失敗と扱わないでください。
Q6. Azure Foundry と OpenAI 直の料金は同じですか？
表記単位もチャネルも異なります（$/分と$/hourの例など）。各コンソールの現行価格表を確認してください。
Q7. 既存の gpt-4o-transcribe はすぐ捨てるべきですか？
継続利用は可能です。ただし新規統合の推奨開始は gpt-transcribe / gpt-live-transcribe です。
まとめと次のアクション
新しい文字起こしは、用途二分（ファイル高精度／ライブ低遅延）とコンテキスト3種（prompt / keywords / languages）が中核です。人気記事の「誤認識半減」表現はベンチマーク文脈で読み、自データの exact-match と遅延で検証してください。
次に取る実務手順は次の4つです。
- 自システムの音声を「完了」か「ライブ」に分類する
- 用語集を
keywords、議題をprompt、混在言語をlanguagesに載せる - 字幕／タイムスタンプ／翻訳／diarize の要否でレガシー経路を残すか決める
- 代表音声で baseline／置換／context付きを比較し、keyword hallucination と p95 をゲートにする
関連して、ChatGPT側のフルデュプレックス音声設計は GPT-Live の整理記事、ノーコード寄りの音声エージェント構築は Grok Voice Agent Builder の記事、多言語リアルタイム翻訳は Gemini Live Translate の記事も参照できます。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す