まず最も硬い数字——誤り率が半分以下に

OpenAI は画像を6枚公開しました。モデル2組、ベンチマーク3種です。まずファイル文字起こしの組から。図に示された指標は WER、単語誤り率で、低いほど良い数値です。

Common Voice（22言語）でのファイル文字起こし組。whisper-1 の40.37%が最下位。図：OpenAI

Real World Audio Recording（9言語）でのファイル文字起こし組。図：OpenAI

40.37%とはどれくらいでしょうか。おおよそ5語につき2語が誤りです。この原稿は基本的に録音を聞き直さないと使えません。19.27%も完璧とは言えませんが、5語につき1語なら、少なくとも下書きとして直せます。「作り直す」と「手を入れる」の違いです。

8.98%はおよそ11語に1語の誤り。whisper-1 の15.21%は6〜7語に1語です。どちらも「人手の校正が不要」の水準ではありませんが、校正という作業の性質が変わりました。録音を頭から聞き直す作業から、ざっと目を通して数カ所直す作業へ。

リアルタイム組は、差がずっと小さい

Common Voice リアルタイム組：19.70%対20.33%。図：OpenAI

実環境録音リアルタイム組：9.60%対11.65%。図：OpenAI

Common Voice では gpt-live-transcribe の19.70%に対し gpt-realtime-whisper が20.33%。差は0.63ポイントです。実環境録音では9.60%対11.65%で、差は2.05ポイントでした。

ファイル文字起こし側の半減という幅に比べると、リアルタイム側の向上はずっと控えめです。これも筋が通ります。リアルタイム文字起こしの前任は whisper-1 ほど古い土台ではなく、出発点が高い分だけ絞れる余地が小さいのです。

本当に新しいのは、この録音が何についてかを先に伝えられること

従来の文字起こしモデルは目隠しで聞いていました。どんな音声を渡されても初めて聞くものとして扱い、これがサポート通話なのか医師の問診なのかを知りません。「この注文番号を控えておいて、AC-42 です」と言えば、音は聞こえます。しかしその音の連なりが注文番号だとは分からず、御社の注文番号がどんな形をしているかも知らない。読みから表記を推測するしかありません（イメージ）。

新モデルは3種類のコンテキストを受け取ります。いずれもリクエスト時に一緒に送ります。

prompt は自由記述のテキストで、この録音がどんな場面かを説明します。公式ドキュメントの例は「上位プランとアカウント AC-42 に関するカスタマーサポートの通話」。ドキュメントはわざわざ注意を添えています。音声に関係する背景だけを書き、文字起こしという作業そのものの指示を繰り返さないこと。

keywords は語句のリストで、聞こえてくると想定される字面の語を書きます。製品名、薬品名、略語など。ここには踏みやすい落とし穴があり、公式ははっきり明言しています。

キーワードはヒントであり、必ず出力されるべきものではありません。音声中で実際に発話された場合にのみ、文字起こしに含まれるべきです。

OpenAI 文字起こしガイド

つまりキーワードを詰め込んで、ある語を原稿に「ねじ込む」ことはできません。「アスピリン」を並べても、その場面で医師がまったく触れていなければ、出てくるべきではないのです。ドキュメントは実測も勧めています。キーワードを足したことで精度が上がったのか、それとも発話されていない語が湧き出すようになったのかを確かめる、ということです。

languages は想定される言語のリストです。複数形である点に注目してください。このフィールドは「1本の録音に複数の言語が混ざる」場面のために設けられており、公式ドキュメントの例もそのまま ["en", "fr"] です。旧モデルの単数形 language フィールドを置き換えるもので、両方を同時に送ることはできません。

4つ目のコンテキストもあり、これは送信不要です。gpt-transcribe はリアルタイムセッションで動くとき、直前の数ターンですでに書き起こした内容を自動的にコンテキストとして引き継ぎます。前のターンの原稿を手動で渡し直す必要はありません。

デモ動画では、多言語対応が直感的に示された

公式ポストには2分あまりの動画が添えられ、2つのモデルがそれぞれ実演されています。

前半はリアルタイムのデモです。ノートパソコンに向かって話す人物、ブラウザではローカルのデモページが動き、右上に gpt-live-transcribe と表示されています。声が入ると文字が湧き出てきます。最も説得力があるのは途中の一場面。英語で話していた話者が、スペイン語で3文話し、また英語に戻ります。同じセッション内で手動の切り替えは一切なし。文字起こしがそのまま言語を変えて続きます。画面に残った原稿は英語とスペイン語が混在し、はっきり見て取れます。

後半は同じデモの Offline タブに切り替え、右上の表示は gpt-transcribe。25分・23.2 MB の会議録音ファイルを投入し、完全な原稿を待ちます。

言語コードは書式どおりに。間違えるとリクエスト全体が拒否される

これは実務上の細部で、間違えるとデバッグ1回分が無駄になります。ドキュメントは3種類の書き方を挙げています。ISO 639-1 の2文字コード（en、es、fr）、一部の ISO 639-3 の3文字コード（eng、spa、広東語の yue、標準中国語の cmn）、そして中国語の地域コード（zh-cn、zh-tw、zh-hk）です。ドキュメントは「限定」ではなく「含む」という表現なので、この3種類は例示であり、完全なリストではありません。

サポート対象外、または書式を誤った言語コードは、API が拒否します。黙って無視されるのではありません。

同じヒントを旧モデルに与えても、精度は動かない

ここまでの3点セットは、いかにも筋が通って聞こえます。背景を多めに渡せば、モデルはより正確に聞き取れるはず。ならば自然な疑問が出てきます。これは新モデルでなければいけないのか。旧モデルに prompt を突っ込んでも上がるのではないか。

OpenAI はこのために Context Aware ASR Benchmark という専用のベンチマークを作り、意味的正解率（高いほど良い）を測りました。各モデルを2回ずつ走らせています。1回目は背景情報なし、2回目はあり。ポストによれば、ここで与えたのは自由記述の場面説明です。5つのモデルの2回分の成績は2枚の図に分かれて描かれており、以下は当サイトがそれらを1つにまとめて再構成したものです。

まず1つ、不在の話から。whisper-1 はこの5つに入っていません。この記事はタイトルから価格まで一貫して whisper-1 を基準にしてきましたが、この項目だけは不参加です。ドキュメントで確認できる関連事実としては、whisper-1 の prompt には224トークンの長さ上限があり、keywords と複数形の languages フィールドにも対応していません。ただしこの図に入っていない理由について、OpenAI は説明していません。

ファイル文字起こし組の原図：gpt-transcribe は41.6%→45.2%、旧モデル2つはほぼ横ばい。図：OpenAI

リアルタイム組の原図：gpt-live-transcribe は6.1ポイント上昇、gpt-realtime-whisper は逆に32.4%から32.2%へ。図：OpenAI

ただし、この図にはもう一面がある

最高成績の gpt-transcribe でも45.2%です。合格にはほど遠く聞こえますが、この数字が何を意味するのかは外部からは計算できません。OpenAI が自分で問題を作り、自分で受験し、自分で採点した新しいベンチマークで、データセットは非公開、構築方法も未公表、「意味的正解率」の計算方法も明かされていません。問題の難易度が外からは見えないのです。

したがってこの図が支えるのは1つの結論だけです。この種の難問では、新モデルは旧モデルよりはるかに強い。「コンテキストの問題は解決した」も支えられませんし、「45.2点だから半分以上を間違えている」も支えられません。後者はどちらも、目盛りのない物差しで絶対的な長さを測ろうとする読み方です。

安くなった、しかも大幅に

モデルのリリースはたいていこの筋書きです。強くなったが高くなった、あとは自分で天秤にかけてくれ。今回は違います。

gpt-transcribe は1分あたり $0.0045。置き換える対象の whisper-1 は $0.006 で、中間世代の gpt-4o-transcribe も $0.006 です。旧モデルより25%安く、実環境録音の誤り率は4割減。両方が同時に良い方向へ動くのは、モデルのリリースでは珍しいことです。

リアルタイム側は事情が違います。gpt-live-transcribe は1分あたり $0.017 で、置き換える gpt-realtime-whisper とまったく同額。価格は据え置きで、精度が少し上がりました。

表の中にもう1つ、計算してみる価値のあるものがあります。gpt-4o-mini-transcribe は1分あたり $0.003 で、数字の上では依然として最安です。しかし実環境録音での単語誤り率は15.46%。gpt-transcribe の8.98%より7割高い数字です。

この計算は手戻りコスト次第です。1時間の録音を処理した場合、両者の差額は $0.09。日本円で十数円ほどです（1分あたり $0.0015 の差、60分で計算、イメージ）。この1時間の原稿に増えた誤りを人が聞き直して直すのなら、十数円の節約に意味はありません。大量の音声をざっと選別する用途で、誤りがあっても支障がないなら、mini は今も合理的な選択です。

もう1つ、注意すべき基準の違いがあります。価格ページのその列の見出しは「推定コスト」です。gpt-transcribe、gpt-live-transcribe、whisper-1 は純粋に音声の分数で課金され、1分あたりの単価がそのまま効きます。一方gpt-4o-transcribe と gpt-4o-mini-transcribe はトークン課金で、$0.006 と $0.003 は換算して見せた推定値にすぎません。実際の請求は入出力のトークン量によります。この2つと新モデルの単価を単純に比べることはできません。

リアルタイムのモデルは、遅延をひねれる

gpt-live-transcribe には delay というパラメータがあり、5段階です。長めに聞いてから文字を出せば、得られるコンテキストが多くなり誤りが減ります。急いで出せば、推測に頼ることになります。

公式の表現はこうです。具体的な遅延のミリ秒数はモデルの構成によって変わる。ある段階が特定の固定遅延に等しいと決めつけず、自分の実際の音声で測ること。

注目したいのは、ドキュメント全体を通して具体的なミリ秒数が1つも出てこないことです。gpt-live-transcribe の中核の売りは「低遅延」ですが、その「低」がどこまで低いのか、リリース資料には検証可能な数字がなく、5つの段階名だけが示されています。

リアルタイム字幕を作る前に、これを詰めておく

リアルタイム文字起こしは細切れに出力されます。文を言い終えるのを待ちません。この細切れ1つを公式は デルタ（delta）と呼びます。厄介なのは、後から出てきた断片が、すでに表示済みの文字を遡って書き換えることです。

例を挙げます（イメージ）。マイクに向かって「上海行きの航空券を予約して、便名は CA1501」と話したとします。

こうして画面にすでに書き出されていた「シーエー一五〇一」が、ユーザーの目の前で CA1501 に変わります。これはエラーではなく、まさにモデルの自己修正です。しかしユーザーから見れば、文字が勝手に動いたようにしか見えません。

難しいのはここです。文字が書き換わるその瞬間、UI はどう見せるべきか。そのまま置き換えれば、ユーザーは文字が跳ぶのを目にし、読んでいた行が突然変わります。未確定の部分を淡い色で示せば、まだ変わると分かる代わりに、ページ全体がちらつき続けます。文が確定してから表示すれば、リアルタイム字幕はリアルタイムでなくなります。3つの道にはそれぞれ代償があり、選ぶのはあなたです。

公式はこの項目を本番運用チェックリストに入れています。モデルの精度とは無関係で、純粋に UI 設計の問題です。しかもモデルがどれだけ正確になっても消えません。聞きながら出力する以上、推測して直す瞬間は必ず生まれます。

同じチェックリストにもう1つ、見落としやすい項目があります。「この文は言い終わった」というモデルからの通知は、到着順が保証されません。2人が続けて話し終えても、通知がその順で手元に届くとは限らない。各通知に付く item_id で紐づけて並べ替える必要があり、受信した順にそのままつなげてはいけません。

できないこと——ここが上のベンチマーク全部より価値があるかもしれない

以下の制約はすべて OpenAI 自身のドキュメントに基づきます。ベンチマークが良いからといって、そのまま乗り換えられるとは限りません。いま依存している機能が残っているかを先に確認してください。

この表で whisper-1 は3回登場します。汎用の文字起こしという道では席を譲りましたが、タイムスタンプ、字幕フォーマット、英語への翻訳の3つについては、ドキュメントは今日も whisper-1 を推奨しており、代替品は示されていません。公式の非推奨ページにも提供終了の時期は載っていないので、「whisper-1 は淘汰された」という言い方には根拠がありません。汎用の文字起こしで第一候補ではなくなった、それだけです。

いま whisper-1 をテキスト原稿を得るためだけに使っているなら、今回の移行には十分な理由があります。より正確で、より安い。もし動画字幕に使っているなら、当面はどこにも行けません。

リクエストが即座に弾かれる硬い決まりもいくつか

ファイルは最大25 MB。対応形式は mp3、mp4、mpeg、mpga、m4a、wav、webm の7種類です。超える場合は自分で分割しますが、文の途中で切らないよう公式がわざわざ注意しています。コンテキストを切り落とすと精度が落ちるためです。

keywords は1件を必ず1行に収める必要があり、<、>、復帰、改行を含められません。1件でも違反するとリクエスト全体が拒否されます。その1件だけ無視して続行、ではありません。prompt がモデルの長さ上限を超えた場合も、同じくリクエスト全体が拒否されます。

複数形の languages と旧来の単数形 language は同時に送れません。3点セットの説明でも一度触れましたが、ここで改めて挙げておきます。既存コードを移行するときに最も見落としやすい箇所だからです。

公式が勧めるテストのやり方

ドキュメントにはテスト方法だけを扱った節が丸ごとあります。この手法はベンダーを選ばず、どこの音声認識モデルにもそのまま当てはまります。ドキュメントの中で最も持ち帰りやすい部分です。

1つ目はきれいなサンプルだけでテストしないこと。実際のマイクで録り、電話の音質で録り、なまり・背景ノイズ・コードスイッチング・分野固有の専門用語を入れ、さらに長時間の会話でも測ります。テストセットには数字、日付、通貨の金額、メールアドレス、製品名を必ず入れること。文字起こしモデルが最も転びやすく、しかも人間が誤りに気づきやすい箇所です。

2つ目はさらに価値があります。単語誤り率だけを見ないこと。ドキュメントの例では、医療の現場なら薬品名が正しく起こせているか、カスタマーサポートなら注文番号が正しいかを測るべき、としています。

3つ目は3種類の障害を個別に集計すること。空の文字起こし（1文字も出ない）、途切れた文字起こし（途中で止まる）、遅延した文字起こし（いつまでも出ない）。この3つは単語誤り率にはほとんど表れませんが、実際の製品ではユーザーの苦情を最も招きます。

最後に、リアルタイムを扱うならさらに2つ決めておくこと。delay を調整する前に許容できる遅延と精度の目標を先に確定し、調整しながら基準を動かさないこと。そして対象の言語は1つずつ個別に測り、ある1言語の成績から他言語を推し量らないことです。

指標は単語誤り率です。機械が起こした原稿と正解原稿を単語単位で突き合わせ、100語のうち何語が誤りかを見ます。聞き違い、抜け、余計に出てきたものもすべて誤りに数え、低いほど良い数値です。

8.98%はおよそ11語に1語、15.21%は6〜7語に1語の誤りです。校正という作業の性質が変わりました。録音を頭から聞き直す作業から、ざっと目を通して数カ所直す作業へ。より正確で同時に安いというのは、モデルのリリースでは珍しいことです。両ベンチマークとも OpenAI の自社測定で、第三者による再現はまだありません。

同じ図には、ポストが触れていない事実もあります。中間世代の gpt-4o-transcribe は実環境録音で22.21%。本来なら超えているはずの whisper-1 より悪いのです。「世代を追うごとに強くなる」という直感は、この系譜では成り立ちません。

従来の文字起こしモデルは目隠しで聞いていました。サポート通話か医師の問診かも分からず、アルファベットと数字の連なりを聞いても、読みから表記を推測するしかありません。新モデルはリクエスト時に3つのものを一緒に渡せます。

keywords はあくまでヒントです。音声で発話されていない語が原稿に現れるべきではなく、語を詰め込んで原稿にねじ込むことはできません。languages は複数形で、1本の録音に複数の言語が混ざる場面のためのもの。途中で言語が変わっても手動の切り替えは不要です。

では、これは新モデルでなければいけないのか。旧モデルに同じ背景を渡しても上がるのではないか。OpenAI は5つのモデルを2回ずつ走らせました。1回目は背景なし、2回目はあり。

もう一面も明確にしておきます。最高でも45.2%です。これは OpenAI が自分で問題を作り、自分で受験し、自分で採点した新しいベンチマークで、データセットも採点方法も非公開。問題の難易度は外からは見えません。したがってこの図が支えられるのは「新モデルは旧モデルよりはるかに強い」という1点だけです。

ベンチマークが良いからといって、そのまま乗り換えられるとは限りません。以下の制約はすべて OpenAI 自身のドキュメントに基づきます。