GPT-Transcribe と GPT-Live-Transcribe：料金、API の違い、移行方法

TL;DR

録音が完了した音声には gpt-transcribe（音声1分あたり $0.0045）、マイク・通話・ライブメディアには gpt-live-transcribe（音声1分あたり $0.017）を使用。OpenAI は公開ベンチマークで、ライブモデルが GPT-Realtime-Whisper よりも低い転写エラー率と報告。ただし、最適な選択はテキスト出力のタイミング、必要な出力フィールド、実運用オーディオでの両モデルの性能に依存。

GPT-Transcribe と GPT-Live-Transcribe の概要

音声が録音完了後にのみ転写が必要なら gpt-transcribe。音声が到着中にテキスト化が必要なら gpt-live-transcribe。最大の違いは価格だけでなく、転写が開始されるタイミングと、アプリがサポートすべき API ワークフロー。

gpt-transcribe は、完了したファイルやコミット済みの音声ターンを処理中に部分的な転写更新を返すことができるものの、連続ライブストリーミングルートではない。ライブ字幕、通話、マイク入力には gpt-live-transcribe が適切。

より広い比較については、CometAPI の「2026 年版：最高の音声認識 API 6 選」を参照。

GPT-Transcribe と GPT-Live-Transcribe とは？

OpenAI は 2026 年 7 月 29 日に gpt-transcribe と gpt-live-transcribe を導入。gpt-transcribe は完了済み録音、ストリームされたファイル転写、コミット済み Realtime ターンを処理し、gpt-live-transcribe はマイク、通話、ライブメディアからの音声到着に合わせて低遅延の転写更新を返す。

両モデルは一般的なファイル転写とライブ転写の新しいデフォルトルートを提供するが、タイムスタンプ、翻訳、字幕、話者分離には従来の Whisper や GPT-4o の転写ワークフローが依然として必要。

GPT-Live-Transcribe はいつ高コストに見合うのか？

OpenAI のAPI 料金ページでは、gpt-transcribe は1分あたり $0.0045、gpt-live-transcribe は1分あたり $0.017。ライブルートは音声1分あたり約3.8 倍高い。

これらの転写コスト見積りは、OpenAI 公開の基本レート（音声時間 × 60 × 分単価）のみを使用。ストレージ、ネットワーク転送、再試行、アプリホスティング、後処理、人手修正、フォールバックプロバイダの費用は除外。

即時字幕、エージェント支援、モデレーション、リアルタイム対話が要件の一部であれば gpt-live-transcribe を選択。会議、通話、インタビュー、メディアのアップロード完了後にのみ転写が必要なら gpt-transcribe を選択。二経路アーキテクチャでは、ユーザー体験向けにライブ転写、ポストコール処理やバックフィル向けにファイル転写を併用可能。

OpenAI は現在、GPT-Realtime-Whisper と gpt-live-transcribe の料金をともに $0.017/分としている。ライブルート間の移行評価は、掲載価格ではなく、採用転写品質、遅延、イベント処理、運用互換性を基準に。

GPT-Transcribe と GPT-Live-Transcribe の API はどう違う？

主な違いは、音声がどのようにシステムへ入るか、転写イベントがいつ始まるか。gpt-transcribe は完了ファイルやコミット済み音声ターンを受け付け、gpt-live-transcribe は Realtime 接続を維持して音声到着中に転写更新を発行。

完了済み音声には GPT-Transcribe を使用

録音が完了したファイルは /v1/audio/transcriptions に送信。OpenAI のファイル転写ガイドは、mp3、mp4、mpeg、mpga、m4a、wav、webm 形式で 25 MB までのファイルを受け付ける。

from openai import OpenAI

client = OpenAI()
with open("support-call.wav", "rb") as audio_file:
    transcript = client.audio.transcriptions.create(
        model="gpt-transcribe",
        file=audio_file,
        prompt="A support call about a premium plan and account AC-42.",
        extra_body={
            "keywords": ["premium plan", "AC-42", "billing"],
            "languages": ["en"],
        },
    )
print(transcript.text)

stream=True を設定すると、アップロードした録音を OpenAI が処理する間、転写デルタイベントを受信可能。可視テキストの待ち時間は短縮されるが、ファイルエンドポイントがライブのマイク入力受付に変わるわけではない。

到着中の音声には GPT-Live-Transcribe を使用

type: "transcription" の Realtime セッションを作成し、gpt-live-transcribe を選択。サーバー側メディアパイプラインには WebSocket、ブラウザ音声には WebRTC を使用。

{
  "type": "session.update",
  "session": {
    "type": "transcription",
    "audio": {
      "input": {
        "format": {
          "type": "audio/pcm",
          "rate": 24000
        },
        "transcription": {
          "model": "gpt-live-transcribe",
          "prompt": "A support call about a premium plan and account AC-42.",
          "keywords": ["premium plan", "AC-42", "billing"],
          "languages": ["en"],
          "delay": "low"
        },
        "turn_detection": null
      }
    }
  }
}

input_audio_buffer.append で音声チャンクを追加。アプリケーションは input_audio_buffer.commit でターンをコミットするか、サーバー側の音声活動検出を設定可能。

Realtime 転写ガイドは、conversation.item.input_audio_transcription.delta によるインクリメンタルテキストと、コミットされたアイテムに対する conversation.item.input_audio_transcription.completed を返す。異なるターンの完了イベントは到着順の保証がないため、到着順ではなく item_id で突合すること。

即時テキストが不要な場合はコミット済みターンのルートを使用

gpt-transcribe は WebSocket を用いた Realtime 転写セッション内でも動作可能。音声ターンがコミットされた後に転写が始まり、モデルはそれ以前に転写されたターンを文脈として利用でき、完了イベントには検出言語を含められる。

このコミット済みターンのルートは、ターン単位のストリーミングや言語検出が、話者が話している最中にテキストを表示することより重要な場合に有用。gpt-live-transcribe の連続・低遅延の動作とは混同しないこと。

Prompts、Keywords、Languages、Delay は転写にどう影響する？

両モデルは、名前、数字、略語、製品用語、アクセントのある発話、多言語音声、コードスイッチングの認識を改善し得るコンテキストを受け付ける。

新モデルでは、languages が従来の単数 language フィールドを置き換える。両方を送らないこと。各キーワードは1行に収め、<、>、キャリッジリターン、改行を含めないこと。無効な値はリクエストまたはセッション更新が拒否される原因となる。

gpt-live-transcribe は minimal、low、medium、high、xhigh の遅延設定をサポート。低設定は早期の部分テキストを優先し、高設定はより多くの音声文脈を取り入れて転写品質の向上が見込まれる。OpenAI は各レベルの固定遅延を保証していないため、代表的なマイク、コーデック、ネットワーク、言語、セッション長でファーストデルタと最終転写までの時間を測定すること。

OpenAI の精度ベンチマークは何を示している？

OpenAI のリリース告知によれば、gpt-live-transcribe は 2 つの多言語転写テストで GPT-Realtime-Whisper-1 を上回った。また、自由形式のコンテキストが Context Aware ASR 評価で意味的正確性を改善したと報告。

防御可能な結論は限定的：新しいライブモデルは OpenAI が報告したテストでより良好に動作し、コンテキストは報告上の意味的正確性スコアを改善した。これらはベンダーの報告であり、すべての言語、電話コーデック、マイク、遅延設定、ドメイン用語、修正方針で同様の改善を保証するものではない。

Whisper や GPT-4o Transcribe を使うべきケースは？

新モデルがすべての音声認識ワークフローを置き換えるわけではない。

話者分離はファイル Transcriptions API が必要で、Realtime 転写セッションでは話者ラベリング非対応。30 秒超の録音では、chunking_strategy を "auto" に設定するか、音声活動検出の構成を使用。

タイムスタンプ、字幕、翻訳、既存の Whisper ワークフローについては、CometAPI のWhisper API ガイドおよびWhisper-1 モデルページを参照。別の OpenAI ファイル転写ルートを評価するチームは GPT-4o Transcribe モデルページも確認可能。

Whisper からどう移行するべきか？

モデル ID の変更は第一歩に過ぎない。本番トラフィックを切り替える前にワークフロー全体を検証すること。

GPT-Realtime-Whisper からの移行では、音声フォーマット、ターン検出方針、テストセット、遅延目標を不変に保つ。公開ライブ料金が不変のため、優先すべきは採用転写率、遅延分布、出力安定性、パイプライン互換性。

移行ガイド（Whisper / 既存モデルから）

OpenAI は公式クックブックを提供：Whisper から GPT-Transcribe と GPT-Live-Transcribe へ移行。

高レベルのルール:

1. 録音済み/バッチ音声 → 既存の /v1/audio/transcriptions エンドポイントで gpt-transcribe に切替。
2. 連続ライブ音声 → Realtime 転写セッションで gpt-live-transcribe に切替。
3. コミット済みターン後の高精度 → Realtime セッション内で gpt-transcribe を使用。

最小限のファイル移行例（Python）:

Python

# Before (Whisper)with open("meeting.wav", "rb") as audio:    result = client.audio.transcriptions.create(        model="whisper-1",        file=audio,        language="en",        prompt="Support call about AC-42"    )# After (GPT-Transcribe)with open("meeting.wav", "rb") as audio:    result = client.audio.transcriptions.create(        model="gpt-transcribe",        file=audio,        prompt="A customer support call about billing",        extra_body={            "keywords": ["AC-42", "Premium Plus"],            "languages": ["en", "fr"]        },        response_format="json"  # or stream=True for deltas    )

ライブ移行の注意点:

• 同じ Realtime セッション / WebSocket アーキテクチャを維持。
• モデル ID を変更し、単数の language を languages 配列に置換。
• 任意で prompt、keywords、delay（例："low"）を追加。
• 同一の delta/completed イベント処理を継続。
• language と languages を同時に送らないこと。

移行時の重要な注意事項:

• GPT-Transcribe/GPT-Live-Transcribe は語単位タイムスタンプ、SRT/VTT、Whisper と同方式の英訳をサポートしない。これらが必要な場合は Whisper を継続利用。
• レスポンス形式は異なる—text、verbose_json、srt、vtt が同一に動作すると仮定しないこと。
• キーワードは単一行リテラル（<、>、CR、LF 禁止）。違反時はリクエストが拒否。
• 公開 WER に頼らず、代表的な本番音声（アクセント、雑音、ドメイン用語、短発話）でテスト。

クイック推奨

• 新規の既定：ファイル/バッチは GPT-Transcribe、ライブストリーミングは GPT-Live-Transcribe。
• 既存の Whisper や GPT-4o-Transcribe 統合は引き続き動作するが、出発点としては推奨されない。
• コスト重視のバッチジョブは、GPT-Transcribe への切替で大きな恩恵（$0.0045 vs $0.006）。

最新情報は公式モデルページと OpenAI 開発者サイトの転写概要ガイドを確認。

本番音声で 2 つのモデルをどう評価する？

デモ用のきれいなクリップだけでなく、製品を代表するライセンス済み音声を使用。

1. 主要ユースケース、言語、デバイス、音声条件にわたって少なくとも 50 本を選定。
2. アクセント、中断、背景雑音、コードスイッチング、数字、日付、通貨、メールアドレス、ドメイン語彙を含める。
3. 完了録音を gpt-transcribe で、コンテキストあり/なしの両方で実行。
4. 同じライブサンプルを gpt-live-transcribe で 3 つの delay 設定で再生。
5. フォーマット、ターン境界、プロンプト、採点規則を各ランで一貫させる。
6. 転写エラー、ドメイン用語再現率、部分テキストの改訂、p50/p95 遅延、失敗、再試行、人手修正時間を測定。
7. 「採用された転写あたりのコスト」を計算し、選定したルーティング方針を本移行前にカナリア適用。

最終設計は 1 モデルでも両モデル併用でもよい。意思決定指標は、分単価だけでなく「採用可能な本番転写のコストと信頼性」であるべき。

FAQ

どのモデルを使うべき？GPT-Transcribe か GPT-Live-Transcribe か？

録音完了後の転写や非同期ジョブには gpt-transcribe。音声ストリーミング中にテキストが必要な場合は gpt-live-transcribe。

GPT-Transcribe と GPT-Live-Transcribe の料金は？

OpenAI は gpt-transcribe を音声1分あたり $0.0045（$0.27/時）、gpt-live-transcribe を $0.017/分（$1.02/時）と掲示。

GPT-Live-Transcribe は GPT-Realtime-Whisper より高精度？

OpenAI の 9 言語 Real-World Audio Recording ベンチマークでは、報告された転写エラー率が 11.65% から 9.60% に低下。自社音声での検証を推奨。

GPT-Live-Transcribe は話者分離や語タイムスタンプに対応？

いいえ。話者ラベル、語単位タイムスタンプ、信頼度スコアは返さない。これらが必要な場合は、対応するファイルモデルやフォールバック手順を使用。

GPT-Realtime-Whisper からの移行は単なるモデル差し替え？

いいえ。セッション構成、言語フィールド、コンテキスト入力、遅延設定、イベント順序、機能依存、遅延、出力品質を検証してから本番トラフィックを移行すること。

CometAPI で転写ルートをテスト

実装前にCometAPI 料金ページで最新のモデル提供状況とルート料金を確認し、CometAPI ドキュメントで OpenAI 互換のリクエストパターンを参照。テストではモデル ID を固定し、音声長、遅延レベル、ファーストデルタ遅延、最終転写遅延、再試行、採用転写率をログ化して、ルーティング判断がワークフローの総コストを反映するようにすること。