OpenAI が実時間音声モデル GPT-Realtime-2.1 と GPT-Realtime-2.1-mini を発表：mini モデルも推論能力を搭載、遅延は25%低下

音声アシスタントはこれまで何に詰まっていたか

音声アシスタントは、ツールを呼び出す際によく固まっていた。モデルは関数呼び出しをトリガーした瞬間に沈黙してしまい、ユーザーは電話が切れたと思って声を上げて割り込んだり、そのまま切ってしまったりする。会話の状態は乱れ、結局中途半端な結果しか得られず、もう一度やり直すはめになる。

推論が mini クラスに搭載、沈黙問題をどう解決したか

このセクションが今回の発表の核心だ——推論能力が低価格の mini クラスに降りてきたことと、「口頭での予告」の組み合わせが、まさに前セクションで挙げた沈黙による切断という古い課題を解決する。

ここでいう「推論」とは何か

推論(reasoning)とは、モデルが返答する前に、この発話をどう処理すべきか、ツールを呼ぶべきかどうかを頭の中で先に考えることを指す。聞こえたものにすぐ反射的に答えるのではない。mini クラスも今回からツール呼び出し(function calling)に対応したため、まず1歩計画を立ててから関数を呼び出し、それから答えを返せるようになった。

ツールを伴う1回の対話を分解すると、時系列はこうなる。

推論強度は5段階、遅延と品質をどうトレードオフするか

推論強度は設定可能で、低いほうから minimal、low、medium、high、xhigh の5段階がある。low がデフォルトで、単純な対話の遅延を抑える。強度が上がるほど遅延と出力トークン量も増える。OpenAI は、大半の本番環境の音声アシスタントはまず low から始め、難しいタスクに直面したときだけ引き上げることを推奨している。

2機種、どう選ぶか

一言でいえば:最強のリアルタイム推論、ツール呼び出し、指示追従、音声アシスタント性能が欲しいなら完全版 gpt-realtime-2.1。より速く、より安く、能力は必要十分でよいなら gpt-realtime-2.1-mini。

遅延25%減、キャッシュがなぜコスト削減になるか

今回の遅延改善は、キャッシュ最適化によるものだ。そしてキャッシュは時間を節約するだけでなく、コストも大幅に下げる。

まず「p95 遅延」とは何かを押さえる

p95 遅延とは、すべてのリクエストの応答時間を速い順に並べ、95%の位置にある値を指す。これは最も遅い5%のユーザーが実際にどれだけ待たされたかを表すもので、平均処理時間ではない。リアルタイム音声にとって、ユーザーが実際に感じる「引っかかり」は、まさにこの最も遅い部分に潜んでいる。この部分を少なくとも25%削ることで、通話の体感は明らかに向上する。

キャッシュヒットで、なぜ価格が急落するのか

キャッシュヒット入力(cached input)とは、今回の対話が以前処理済みのシステムプロンプトや履歴内容を引き継いでいる場合、サービス側が「この部分は計算済み」と認識し、再計算せずそのまま再利用することで、価格が急落する仕組みを指す。システムプロンプトは最初のターン以降キャッシュされるため、対話が長くなり再利用が増えるほど節約になる。mini 版の音声入力を例に、キャッシュヒット価格と新規価格の差はこうなる。

3モデルの価格全貌

価格はすべて100万トークンあたりで、テキスト・音声・画像の3種に分かれる。タブをクリックして切り替え、mini の列はハイライト済み。

どんな用途に向くか

代表的な4つのシーンで、それぞれ推論、ツール呼び出し、認識改善がどう活きるか。

導入するとどうなるか

最小構成の実装はこうだ:まずサーバー側で短命なクライアント認証情報を発行する(標準の API key はサーバー側に留め、外部に漏れない)。ブラウザはこの短期認証情報を使い、WebRTC で直接接続し、マイクトラックとイベント送受信用のデータチャネルを確立する。

接続方式はシーンによって選ぶ:ブラウザやモバイル端末が直接音声を収録・再生する場合は WebRTC、サーバー側がすでに生の音声ストリームを持っている場合(コールセンター、メディアパイプライン)は WebSocket、電話音声エージェントは SIP を使う。

// Server: mint a short-lived client secret
const r = await fetch("https://api.openai.com/v1/realtime/client_secrets", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    session: {
      type: "realtime",
      model: "gpt-realtime-2.1-mini",
      instructions: "You are a support agent. Reply in one or two short sentences.",
      reasoning: { effort: "low" },
      tools: [
        {
          type: "function",
          name: "lookup_account",
          description: "Look up a customer account by email.",
          parameters: {
            type: "object",
            properties: { email: { type: "string" } },
            required: ["email"]
          }
        }
      ],
      tool_choice: "auto"
    }
  })
});
const { value: EPHEMERAL_KEY } = await r.json(); // pass this to the browser

// Browser: connect to the Realtime API over WebRTC
const pc = new RTCPeerConnection();

const audioEl = document.createElement("audio");
audioEl.autoplay = true;
pc.ontrack = (e) => { audioEl.srcObject = e.streams[0]; };

const mic = await navigator.mediaDevices.getUserMedia({ audio: true });
pc.addTrack(mic.getTracks()[0]);

const events = pc.createDataChannel("oai-events");
events.addEventListener("message", (e) => console.log(JSON.parse(e.data)));

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

const sdp = await fetch("https://api.openai.com/v1/realtime/calls", {
  method: "POST",
  body: offer.sdp,
  headers: {
    Authorization: `Bearer ${EPHEMERAL_KEY}`,
    "Content-Type": "application/sdp"
  }
});
await pc.setRemoteDescription({ type: "answer", sdp: await sdp.text() });

今回は正式な GA インターフェースであり、ベータ版ではない。エンドユーザーの身元を区別するアプリケーションについては、認証情報発行のリクエストに OpenAI-Safety-Identifier ヘッダー(たとえば内部ユーザー ID のハッシュ値)を付与することを公式が推奨している。これにより、プラットフォームが不正利用を監視する際、アカウント全体を誤って停止するのではなく、特定のユーザーをピンポイントで特定できる。

強みはどこか、限界はどこか

OpenAI 公表の内容に基づく、今回の発表の両面。