GPT-Live-Transcribeとは？OpenAIの低遅延ストリーミング文字起こしの実装手順とGPT-Transcribeとの使い分けを解説【2026年7月版】

通話中のオペレーター画面に、相手が話し終える前から文字を出したい。この要件をWhisperで組むと、音声を数秒ずつ切って投げる自作の分割処理に行き着き、切れ目で単語が欠ける問題と延々つき合います。2026年7月28日、OpenAIはこの用途に振り切ったモデル gpt-live-transcribe をAPIへ追加しました。本記事では、対応エンドポイントの制約、prompt・keywords・languagesの3種のコンテキスト指定、delayの5段階チューニング、同時発表された gpt-transcribe との使い分けまでを2026年7月時点の公式一次情報で整理します。

まとめ：GPT-Live-Transcribeの位置づけと採否の結論

GPT-Live-Transcribeは、ライブ音声から低遅延で転記デルタを受け取るためのストリーミング音声認識モデルです。モデルIDは gpt-live-transcribe、料金は音声1分あたり0.017ドル。使えるのはRealtimeの転記セッション専用エンドポイントだけで、従来の転記APIからは呼べません。

精度面の新しさは、モデルへ渡せる文脈が3種類に増えた点です。収録状況を自由文で伝える prompt、固有名詞や型番を字面で登録する keywords、想定言語を並べる languages。この3つで、短いフレーズ・数値・専門用語・背景雑音下の取りこぼしを詰めます。

採否の軸は単純です。「話している最中に文字が出る」ことが仕様なら採用、そうでないなら見送る。録音済みファイルの一括処理なら同時発表の gpt-transcribe が1分0.0045ドルで、3.8倍を払う理由がありません。話者ラベルと語単位タイムスタンプが返らない点も、議事録用途では二段構えを要求します。

GPT-Live-Transcribeとは何か｜ストリーミング専用モデルという位置づけ

低遅延のtranscript deltaを返す設計と、Realtime専用という制約

gpt-live-transcribe は、マイク・通話・配信といった流れ続ける音声を受け取り、確定を待たずに転記の断片（デルタ）を返し続けるモデルです。公式のモデルページで機能欄に挙がるのはストリーミングのみ。入力は音声とテキスト、出力はテキストです。

実装で最初に効くのが、対応エンドポイントの狭さです。使えるのは v1/realtime/transcription_sessions だけで、Chat Completions・Responses・通常のRealtime・ファイルを送る転記API（v1/audio/transcriptions）はいずれも非対応と明記されています。

つまり、既存のバッチ文字起こしのコードに引数を1つ足す移行はできません。音声をチャンクで送り、イベントで受け取る双方向の接続を新しく組む前提。ここを見誤ると工数が途中で倍に膨らみます。

GPT-Transcribeと同時発表された理由｜ライブ処理とバッチ処理の分担

2026年7月28日、OpenAIは転記モデルを2つ同時にAPIへ追加しました。ライブ転記に向けた gpt-live-transcribe と、収録済み音声の非同期・バッチ処理に向けた gpt-transcribe です。両者は競合ではなく、入力の性質で役割を分けた対の関係にあります。

gpt-transcribe 側は v1/audio/transcriptions と転記セッションの両方に対応し、言語検出も返します。単価は1分0.0045ドル。従来の gpt-4o-transcribe（0.006ドル）より安いうえ、文脈指定は新しい世代の仕組みが入っています。

公式ガイドは「収録済み音声の一般的な転記には gpt-transcribe を推奨」と明記しています。ライブ表示が要件でないなら、新しいからという理由だけで gpt-live-transcribe を選ぶ必要はありません。

GPT-Live-1・GPT-Realtime-Whisperとの関係と座標

名前が似たモデルが並ぶため、座標を先に固定します。gpt-live-transcribe は「聞いて文字にするだけ」のモデルです。相手の発話に音声で応答するフルデュプレックスの対話モデルは別物で、そちらはGPT-Live-1のフルデュプレックス音声モデルとRealtime APIとの違いで扱っています。

ストリーミング転記という機能自体は、先行する gpt-realtime-whisper が担っていました。単価も同じ1分0.017ドル。両者を含む音声モデル群の全体像はGPT-Realtime-2と音声3モデルの仕様・料金の比較にまとめてあります。

本記事が扱うのは、その中で最後発の gpt-live-transcribe に固有の実装面です。公式のRealtime転記ガイドは、遅延を最も詰めたいストリーミング転記の第一候補としてこのモデルを名指ししています。

精度を左右する3種のコンテキスト指定｜prompt・keywords・languages

promptに収録状況を書いて固有名詞の取り違えを減らす指定例

prompt は、これから流れてくる音声がどういう場面なのかを自由文で伝えるフィールドです。話題・設定・場の性質を書きます。「関東圏の建設会社の週次工程会議」のような一文で構いません。

旧来の whisper-1 にも prompt はありましたが、224トークンという上限があり、実質は語彙の呼び水でした。新しい2モデルの prompt にその窮屈さはなく、文脈そのものを説明する道具として設計されています。

書き始めは、業務ドメインと想定される話題の範囲を2〜3文で置く程度で足ります。長く書くほど効くわけではないため、実際に誤認識が出た箇所を見てから足す順序で詰めてください。

keywordsで型番・略語・薬剤名を拾わせるときの語数と粒度の目安

keywords は、音声に出てくる可能性がある語を字面のまま登録するフィールドです。公式ドキュメントが例に挙げるのは製品名・薬剤名・略語の3種類。文脈から推し量りにくく、間違うと業務上の実害が出る語が対象になります。

登録する粒度には向き不向きがあります。「SR-2400H」のような型番、社内外の略語、自社サービス名や取引先名。逆に一般語や長い文を入れても効きは薄く、字面が特殊で音の似た一般語に吸い寄せられやすいものほど効果が出ます。

公式ドキュメントに語数の上限の記載はありません。とはいえ語彙集をまるごと流し込む運用は避け、誤認識の実例から逆算して登録語を選ぶほうが保守も評価もしやすくなります。

languages複数指定によるコードスイッチング対応と旧languageとの差

languages は、入力に含まれうる言語をリストで渡すフィールドです。日本語と英語が混ざる会議のように、1つの音声の中で言語が切り替わる（コードスイッチング）状況を想定した仕組みになっています。値はISO 639-1と、一部のISO 639-3コードを受け付けます。

注意したいのが命名の変更です。新しい2モデルは複数形の languages、旧世代は単数形の language。移行時にフィールド名をそのまま引き継ぐと、指定が黙って無視される事故につながります。

日本語のみの通話でも、製品名や技術用語が英語で挟まる現場は珍しくありません。日英2言語を並べるだけで、英単語部分がカタカナへ潰れる誤りが減ります。

実装手順｜transcriptionセッションの確立からdeltaイベント受信まで

WebSocketとWebRTCの選び分け｜サーバー側収音とブラウザ収音

接続方式は2つ用意されています。公式ガイドの整理はこうです。サーバー側で音声パイプラインを組むなら WebSocket、ブラウザのマイクから直接つなぐなら WebRTC。

分かれ目は、音声が最初にどこへ届くかです。PBXや配信基盤から自社サーバーへ入る構成なら、その延長でWebSocketをつなぐのが素直。Web会議画面のマイク音声をそのまま文字にするなら、ブラウザからWebRTCで直結したほうが経路が短くなります。

通話録音の取り扱いに社内規程がある業種なら、遅延がわずかに増えてもWebSocket側を選ぶ判断が成り立ちます。音声が自社サーバーを通る時点で、ログ・監査・マスキングの処理を挟めるためです。

セッション生成時のaudio形式24kHzとturn_detectionの扱い

セッションは種別 transcription で作成します。実装で必ず触るのは次の4つです。

• audio.input.format：音声コーデックとサンプリングレート。audio/pcm と24kHzが推奨値
• audio.input.transcription.model：gpt-live-transcribe または gpt-transcribe を指定
• audio.input.turn_detection：null にするとターンの区切りを手動で確定する動作になる
• audio.input.transcription.delay：遅延の段階指定（次のh3で扱う）

音声の送信は input_audio_buffer.append にbase64化したPCMを載せて繰り返す形。turn_detection を null にした場合は、区切りたい時点で input_audio_buffer.commit を投げてターンを確定させます。

プッシュトゥトークのUIや、電話交換機側から話者交代の信号が取れる構成なら、手動コミットのほうが区切りは正確になります。常時マイクが開いている会議用途は、自動の発話区間検出に任せるほうが実装が軽い。

deltaとcompletedの2イベントを画面表示へ反映する組み立て

受信側で扱うイベントは2種類。混同すると画面がちらつくため、役割を分けて実装します。

1. conversation.item.input_audio_transcription.delta を受け、delta フィールドの断片を「確定前の行」へ追記していく
2. conversation.item.input_audio_transcription.completed を受け、確定した転記で「確定前の行」を置き換え、次の行へ送る

UI側の定石は、確定前と確定後を視覚的に分けることです。確定前をグレーの薄い文字にしておけば、途中で文言が書き換わっても読み手は混乱しません。

確定イベントで返る検出言語のフィールドは gpt-transcribe のみの提供です。gpt-live-transcribe で言語判定の結果を業務ロジックへ渡す設計にしていると、値が来ずに詰まります。言語を分岐条件に使うなら languages で明示指定する側へ寄せてください。

delayの5段階を実音声で詰める手順と、遅延と精度の交換関係

可変レイテンシは audio.input.transcription.delay で指定し、minimal・low・medium・high・xhigh の5段階から選びます。値を大きくするほど参照できる先の音声が増え、短い相槌や語尾の判断が安定する代わりに、文字が出るまでの待ちが伸びます。

公式ガイドの助言は「まず delay を設定し、自分たちの実際の音声で試せ」というもの。段階が5つしかない以上、机上で理屈を積むより実録音を流して見比べたほうが早く決まります。

当たりの付け方はこうです。字幕やオペレーター画面のように読み手が待つ場面は minimal 側から試し、崩れる語が多ければ1段ずつ上げる。録画へ字幕を焼き込む用途は high 側から入る。評価では単語誤り率だけを見ず、名前・数値・日付・英数字混在の文字列・専門用語の誤りを数えます。公式の転記ガイドが評価指針として挙げている観点です。

返らない3つの情報と料金差｜gpt-transcribeとの使い分けの判断材料

語単位タイムスタンプ・話者ラベル・信頼度が返らない前提と回避策

公式ドキュメントは制約を明示しています。返らないのは語単位のタイムスタンプ、話者ラベル、転記の信頼度スコアの3つ。設定で有効化できるものではなく、モデルの仕様です。

影響が大きいのは話者ラベルです。「誰がいつ何を言ったか」を残す議事録では、この情報が成果物の本体にあたります。回避策は二段構えで、ライブ表示は gpt-live-transcribe、確定版は録音ファイルを話者分離モデルへ流す構成。分離側の仕様と料金はgpt-4o-transcribe-diarizeによる話者分離の使い方と料金で扱っています。

信頼度スコアが無い点は、怪しい箇所を自動で色付けするUIが作れないことを意味します。人手のレビュー工程を置くか、keywords で誤りやすい語を先回りして潰すか。どちらかを設計へ織り込んでください。

1分あたり単価の比較表｜ライブ側3.8倍の価格差を吸収する設計

2026年7月29日時点の公式料金ページの数値です。単位は音声1分あたりの米ドル。

gpt-live-transcribe と gpt-transcribe の差は約3.8倍です。1日8時間・月20営業日ぶんを通すと9,600分となり、ライブ側は約163ドル、バッチ側は約43ドル。差額は月120ドルほどで、席数に比例して開きます。

吸収の仕方は経路を分けることに尽きます。ライブ表示が要るのは通話中の画面だけなので、その区間を gpt-live-transcribe に通し、保存用の全文は録音から gpt-transcribe で作り直す。2回処理しても合計は毎分0.0215ドルで、表示品質と保存品質の両方が上がります。

Whisperからの移行判断｜旧モデルを残してよい条件と切替の目安

whisper-1 は公式ドキュメント上でレガシー扱いになりました。ただし語単位・セグメント単位のタイムスタンプが取れること、英語への翻訳ができることの2点は新モデルにない特性です。字幕ファイルのタイミング情報を機械生成している既存システムは、無理に切り替える理由がありません。

逆に、単価だけを理由に whisper-1 を残している場合は見直す局面です。Whisperは1分0.006ドル、gpt-transcribe は0.0045ドル。安いうえに文脈指定の仕組みが新しい。

他社を含めた横断比較で決めたいなら、主要7サービスの料金・日本語対応で選ぶ文字起こしAPI比較で候補を絞ってから本記事の制約条件で決める順序が回り道になりません。

GPT-Live-Transcribeを採用してよい3条件と、見送るべき2つの場面

採用してよい3条件｜画面表示の即時性・雑音環境・専門用語の密度

判断を言い切ります。次の3条件のうち1つ目が必須で、2つ目と3つ目は上乗せの理由です。

• 話者が話している最中に文字が画面へ出ることが、仕様として要求されている（通話オペレーター支援・配信字幕・会議のライブ共有）
• 収録環境に背景雑音があり、短いフレーズや数値の取りこぼしが業務の実害につながる
• 型番・薬剤名・社内略語のように、keywords と prompt で先回りできる語が明確に列挙できる

1つ目を満たさないなら、他の2つがどれだけ当てはまっても採用しません。雑音耐性と文脈指定は gpt-transcribe 側にも同じ仕組みがあるためです。

見送るべき2場面｜録音済みファイルの一括処理と議事録の話者分離

1つ目は、録音済みファイルをまとめて処理する用途です。既存の音声資産を一括で文字にする、日次でコールログを流し込む。こうした処理にライブ転記モデルを使うのは過剰で、そもそも v1/audio/transcriptions から呼べないため、ファイルを疑似的にストリームへ流し込む余計な実装まで抱えます。ここは gpt-transcribe 一択です。

2つ目は、話者ごとに区切った議事録を成果物とする用途での単独採用です。話者ラベルが返らない以上、これ1つでは要件を満たせません。ライブ字幕と議事録の両方が要るなら二段構成にしてください。1モデルで両方賄う設計にすると、どちらかの品質が必ず落ちます。

迷いが残るのは、要件定義で「リアルタイム」という語が曖昧なまま通っている場合です。話し終えて3秒後に出れば足りるのか、話しながら出る必要があるのか。ここを詰めずに実装へ入ると、要らない場面で3.8倍の構成を抱え込みます。

音声認識の実装を外部へ委ねるとき見積書で確かめる4つの記載項目

実装を外部の開発会社へ委ねる場合、見積書に次の4点が書かれているかで後工程の揉め方が変わります。

1. どのモデルを使うか（gpt-live-transcribe / gpt-transcribe / 話者分離モデル）と、想定月間音声時間から算出した単価の内訳
2. 接続方式（WebSocket か WebRTC か）と、音声が自社サーバーを経由するかブラウザから直結するかの経路
3. keywords と prompt を誰がどの頻度で更新するか、その反映を session.update でどう回すかの運用手順
4. 話者分離と語単位タイムスタンプの要否、要る場合の二段構成の分担と追加費用

とりわけ3つ目は見落とされがちです。語彙の保守は納品して終わりではなく、商品名や担当者名が増えるたび更新が要る。担い手を決めずに納品すると、精度は半年で目に見えて落ちます。要件整理から相談したい場合はAI音声認識システム開発の範囲を確認してみてください。

よくある質問

導入検討でよく挙がる論点を、公式ドキュメントの記載に沿って整理します。

gpt-live-transcribeは日本語に対応していますか？

対応しています。公式ドキュメントは複数言語のヒント指定に対応すると明記しており、languages フィールドはISO 639-1コードと一部のISO 639-3コードを受け付けます。ただし言語ごとの精度の公式な数値は2026年7月29日時点で未公開です。自社の実音声で評価する際は、単語誤り率だけでなく固有名詞・数値・日付の誤りを数えて判断してください。

Whisperから乗り換えるとコードはどれくらい書き直しになりますか？

ファイルをPOSTする実装からの移行は、部分修正ではなく作り直しに近くなります。gpt-live-transcribe が対応するのは Realtime の転記セッションだけで、音声をチャンクで送り続ける処理とデルタ・確定の2イベントを受け取る処理を新規に組む必要があるためです。一方、ライブ性が不要なら移行先は gpt-transcribe で、こちらは従来の転記APIにも対応します。モデル名の変更と language から languages への修正が中心の軽い移行で済みます。

話者ごとに分けた議事録を作るにはどのモデルを組み合わせますか？

ライブ表示を gpt-live-transcribe、確定版の議事録を gpt-4o-transcribe-diarize に分ける二段構成が基本形です。前者は話者ラベルを返さない仕様のため、単独では話者別の議事録を作れません。後者は話者ラベルと開始・終了時刻を持つセグメントを返しますが、prompt に非対応で Realtime セッションでも使えない。会議中は字幕を出し、終了後に録音を話者分離へ流して清書する流れなら双方の制約を回避できます。

遅延はどのくらいまで詰められますか？

公式ドキュメントは delay の5段階（minimal・low・medium・high・xhigh）を示していますが、各段階が何ミリ秒に相当するかの数値は2026年7月29日時点で公開されていません。実際の待ち時間は音声の経路・ネットワーク・発話の区切り方でも変わるため、公開されたとしても目安にとどまります。自社の実音声で段階を上下させて決める前提で工数を見ておいてください。

オンプレミス環境や閉域網でも動かせますか？

gpt-live-transcribe はOpenAIのAPI経由でのみ提供され、自社環境へ配置して動かす形態はありません。音声を外部へ出せない要件があるなら、選択肢はローカルで動かせるモデルへ移ります。サーバー側にGPUを用意できるならWhisper系の自前実装、端末内で完結させたいならAppleのオンデバイス音声認識という方向。いずれも prompt や keywords による文脈指定は使えないため、精度の詰め方を設計し直す前提で比較してください。

関連記事

• WhisperをPyTorchで動かす音声認識実装ガイド：自前環境で動かす場合の実装手順。
• SpeechAnalyzerとは？Appleのオンデバイス音声認識API：端末内で完結させたい要件の選択肢。
• Moonshine Voiceとは？Whisper比較・日本語モデル・導入手順：軽量モデルとの比較検討に。
• AI議事録・自動文字起こしとは？仕組み・精度・法人での選び方：業務としての導入判断。
• ChatGPTで録音・議事録作成する方法：APIを組まずに済ませる場合の限界。