GPT-Transcribe は OpenAI が API に追加した非同期文字起こし向けのモデルで、ライブ用の GPT-Live-Transcribe と用途・単価・対応エンドポイントが分かれています。
📖 この記事で分かること
- 新モデル2種の用途と単価の違い
- 対応エンドポイントが片方だけ限定な理由
- 固有名詞の精度を上げる3つの入力
- 公式が明示していない項目の範囲
💡 知っておきたい用語
- 文字起こしモデル: 音声を聞き取って文字にするAIモデル。会議録や字幕の自動生成に使われる
- 非同期処理: 録音が終わったファイルをまとめて処理する方式。その場での即時応答を求めない
最終更新日: 2026年7月29日
▶ 公式ページ
- GPT-Live-Transcribe モデルページ(OpenAI)
- GPT-Transcribe モデルページ(OpenAI)
- 文字起こしガイド(OpenAI)

OpenAIが追加した2つの文字起こしモデル
この記事のポイント
- OpenAIが2026年7月29日、APIに文字起こしモデル2種を追加しました。
- ライブ用は1分$0.017、非同期用は1分$0.0045(2026年7月時点)。
- ライブ用はリアルタイム用エンドポイントのみ対応で、用途を決めると単価も決まります。
OpenAIは、API向けの文字起こしモデルとして「GPT-Live-Transcribe」と「GPT-Transcribe」(2026年7月時点)の2種類を追加しました。1つのモデルで用途を兼ねる構成ではなく、音声が流れている最中に文字が要るのか、録り終えた音声をまとめて処理するのかで、モデル自体を分けたのが今回の要点です。
公式の告知では、アクセントや言語をまたぐ実環境の音声、短いフレーズ、数字、専門用語、背景ノイズの大きい音声での精度向上が挙げられています。
2モデルの違いは「遅延が要るか」で決まる
選択の分かれ目は精度の優劣ではなく、遅延の要否です。そしてその判断が、そのまま単価と接続先の決定になります。
GPT-Live-Transcribe(モデルID: gpt-live-transcribe)は低遅延のライブ文字起こし向けで、マイク入力や通話のように話しながらテキストが必要な場面を想定しています。単価はリアルタイム音声1分あたり$0.017(2026年7月時点)。対応するのはリアルタイム文字起こしのエンドポイント(v1/realtime/transcription_sessions)のみで、ファイル文字起こしの窓口には接続できません。遅延の調整に対応します。
GPT-Transcribe(モデルID: gpt-transcribe)は録音済みファイルやバッチ処理向けの非同期文字起こしで、公式はファイル文字起こしの推奨モデルとしています。単価は1分あたり$0.0045(2026年7月時点)で、ライブ用の約3.8分の1です。エンドポイントはv1/audio/transcriptionsとリアルタイム側の両方に対応し、自動言語検出も備えます。リアルタイムAPIのセッション内などで動く場合、それ以前に文字起こしされたターンを自動的にコンテキストとして使う挙動も公式に記載されています。
つまり、設計時に「即時性が本当に必要か」を決めた時点で、コストと接続先が連動して決まる構造です。会議録や問い合わせ音声の事後処理のように待てる処理をライブ用に流すと、単価差がそのまま無駄になります。
3種類のコンテキスト入力で固有名詞に対処
両モデルは3種類のコンテキストを受け取れます。従来型の音声認識が固有名詞や専門用語で崩れやすい問題への、直接的な対処です。
- prompt: 録音の話題や状況についての自由記述のコンテキスト
- keywords: 音声に出てきうる語。製品名、薬剤名、略語などを渡す
- languages: 複数言語が混じりうる録音向けに、想定される入力言語を並べる
公式ドキュメントは、keywordsについて「キーワードはヒントであって出力必須ではない。音声に含まれるときだけ文字起こしに現れるべき」と明記しています。渡した語を強制的に出力させる仕組みではないため、社内用語を並べておいても、実際に発話されなければ混入しない設計です。狙いは専門用語、多言語音声、そして会話の途中で言語が切り替わるコードスイッチングでの精度改善とされています。
一方で、公式ドキュメントに書かれていない項目もあります。具体的な精度指標や単語誤り率の数値、既存モデルとの定量比較は記載がありません。対応言語の具体的なリスト、最大ファイルサイズや最大長、遅延の実測値も同様です。Whisperが置き換えや廃止になるのかについても明言はなく、公式は両モデルを「新規の文字起こし導入における推奨の出発点」と位置づけるに留めています。
編集部の見方
編集部は、今回の更新で実務に最も効くのはモデルの精度そのものより、keywordsによる固有名詞の制御だと見ています。
- 根拠1: 業務音声で文字起こしが使いものにならなくなる原因の多くは、一般語の誤変換ではなく製品名・社内略語・人名の崩れです。公式が明示的にkeywordsを受け口として用意したことは、この失敗モードへの直接の手当てにあたります。
- 根拠2: keywordsが「ヒントであって出力必須ではない」と定義されている点が実用上重要です。強制置換型の辞書機能は、渡した語を発話していない箇所にも押し込む副作用が起きますが、その挙動を公式が否定しています。
- 根拠3: 単価差は用途で分かれるため削減余地が明確です。事後処理でよい音声を$0.0045側に寄せる判断は、精度検証を待たずに実行できます。
この見方が変わる条件は、精度指標が公式に開示された場合です。単語誤り率などの定量データが出て、既存の文字起こし基盤との差が数値で確認できるようになれば、判断の重心はコンテキスト入力の設計から素の認識精度の比較へ移ります。現時点では公式に数値の記載がないため、自社の音声で試すほかありません。
よくある質問
Q: 2つのモデルはどちらを選べばよいですか
A: 音声が流れている最中にテキストが必要ならGPT-Live-Transcribe、録り終えた音声を処理するならGPT-Transcribeです。後者は単価が約3.8分の1で、ファイル文字起こしの推奨モデルとされています。
Q: ライブ用のモデルでファイルを処理できますか
A: できません。GPT-Live-Transcribeが対応するのはリアルタイム文字起こしのエンドポイントのみです。ファイル処理はv1/audio/transcriptionsに対応するGPT-Transcribeを使います。
Q: Whisperは使えなくなりますか
A: 公式ドキュメントに置き換えや廃止の明言はありません。新規に文字起こしを組む場合の推奨の出発点として、今回の2モデルが案内されています。
まとめ
OpenAIがAPIに追加した文字起こしモデルは、ライブ用のGPT-Live-Transcribeが1分$0.017、非同期用のGPT-Transcribeが1分$0.0045で、用途によってモデルと単価と接続先が同時に決まる構成です。両モデルはprompt、keywords、languagesの3種類のコンテキストを受け取り、専門用語や多言語音声の精度改善を狙います。精度指標や対応言語の具体的な一覧は公式ドキュメントに記載がないため、導入判断は自社の音声での検証が前提になります。
【用語解説】
- コードスイッチング: 1つの会話の途中で話者が言語を切り替えること。日本語の会議に英語の専門用語が混ざる場面などが該当する
- エンドポイント: APIの接続先となる窓口のURL。同じサービスでも用途ごとに窓口が分かれている
- 単語誤り率: 文字起こしの精度を測る代表的な指標。正解の文章に対して誤った単語の割合を示す
引用元:
- [1] GPT Live Transcribe Model(OpenAI)
- [2] GPT Transcribe Model(OpenAI)
- [3] Transcription guide(OpenAI)
- [4] OpenAI Developers 公式告知(X)
この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。
15 年以上の開発経験を持つソフトウェアエンジニア / テクノロジーライター。AI エージェントの実務活用を研究し、現場や経営者向けセミナーでその知見を発信。本メディア tech-noisy.com では、一次情報に基づく最新ニュース・解説記事を執筆。また、音楽生成 AI による DJ パフォーマンスを企業イベントで行うなど、テクノロジーと表現の融合も探求している。