音声アシスタントは何につまずいていたのか

音声アシスタントはツールを呼び出す時、よくつまずいていた。モデルは関数呼び出しを一度トリガーすると黙り込んでしまい、ユーザーは電話が切れたと思って声を出して割り込むか、そのまま切ってしまう。対話の状態は乱れ、結局中途半端な結果しか得られず、もう一度かけ直す羽目になる。

推論が mini クラスに入ったことで、無言問題はどう解決されたのか

このセクションが今回の発表の核心だ:推論能力が低価格の mini クラスにまで降りてきて、「口頭での予告」と組み合わさることで、前のセクションで触れた無言による切断という長年の問題をちょうど解決する。

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

推論(reasoning)とは、モデルが答え始める前に、この一言をどう処理すべきか、ツールを呼び出すべきかを頭の中でまず整理することを指す。聞いたことをそのまま即座に口にするのではない。mini クラスも今回ツール呼び出し(function calling)に対応したので、先に一手先を計画してから関数を呼び出し、その上で答えを返せるようになった。

ツールを伴う一連の対話を分解すると、時系列はこうなる:

推論強度は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 キーはサーバー側に留めて外部に漏らさない)。ブラウザはこの短期認証情報を使い、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 インターフェースで、beta 版ではない。アプリがエンドユーザーの身元を区別する場合、公式は認証情報発行リクエストに OpenAI-Safety-Identifier ヘッダー(内部ユーザー ID のハッシュ値など)を付けることを推奨している。プラットフォームが不正利用を監視する際、アカウント全体を誤って凍結するのではなく、特定のユーザーを正確に特定できるようにするためだ。

強みはどこにあり、限界はどこにあるか

OpenAI が公表した内容に基づく、今回の発表の両面:

今回の変化:モデルに「まず考えてから話す」を覚えさせ、しかも調べながら話し続けられるようにした。開口一番「今すぐ確認します」と一言添える。ユーザーはずっと声が聞こえるので、切れたと誤解することはない。

なぜ調べながら話しても混乱しないのか?それを支えるのが新たに加わった「推論」だ。この一連の流れがどんな形か、下の図を見てほしい。

推論(reasoning)とは、モデルが話し始める前に頭の中でひとしきり考えることだ:この一言にどう応じるか、ツールを呼んで調べるべきか。考えがまとまったら、まず口頭で予告してから動き出す。以下では、小互が電話で注文を確認するシーンを使って、新旧2つの流れを並べて見てみよう。

同じ注文確認のリクエストで、旧方式は「ツール呼び出し」中ずっと無言になり、ユーザーは切れたと思って割り込み、結果は中途半端に終わる。新方式はまず「今すぐ確認します」と一言添え、話しながら進めて最後までやり遂げる。

考える時間が長いほど周到になるが、その分遅くもなる。推論は5段階(minimal / low / medium / high / xhigh)に分かれ、デフォルトでは最速で事足りる low を使い、より難しいタスクに出会った時だけ引き上げる。

普通の人には「何倍速くなったか」と言われてもピンとこない。お金に換算するのが一番わかりやすい。同じ100万トークン(おおまかに文字・語数の量と捉えていい)の音声入力でも、キャッシュなしなら10ドル、「キャッシュヒット」(対話が続く際、以前計算済みの部分をそのまま再利用し、計算し直さない)なら0.3ドルで済む。