OpenAI Realtime API V2 — Beta終了、GAで何が変わったのか

Realtime APIとは何か（おさらい）

OpenAI Realtime APIは、音声を音声のまま入出力できるAPI群です。 従来のVoice AIは STT（音声→テキスト）→ LLM（テキスト推論）→ TTS（テキスト→音声）の3段パイプラインで構築するのが定石でした。 Realtime APIはこの3つを1つのモデルにまとめ、音声トークンを直接やり取りすることで、レイテンシ・抑揚・割り込み処理を一段引き上げます。

graph LR
  subgraph 従来パイプライン
    A1["🎤 音声"] --> B1["STT"] --> C1["LLM"] --> D1["TTS"] --> E1["🔊 音声"]
  end
  subgraph Realtime API V2
    A2["🎤 音声"] --> B2["gpt-realtime<br/>（Speech-to-Speech）"] --> E2["🔊 音声"]
  end

2024年10月にBetaとしてリリースされたRealtime APIは、2025年8月にGAへ昇格。 そして2026年5月7日、Beta時代のSDK・モデル・エンドポイント群が完全に廃止され、V2と呼ぶべき新世代に統一されました。 本記事ではこの「V2＝GA」の姿を、Beta時代を知る開発者向けに整理します。

タイムライン: Beta → GA → V2統一

新モデル3兄弟

V2では、Realtime APIに紐づくモデルが用途別に3つに分かれました。 「全部gpt-realtimeでよい」ではなく、翻訳と書き起こしは専用モデルに寄せるのがGAで明確になった設計思想です。

特に gpt-realtime のreasoning levelsは実務的に重要です。 low なら最初の音声が 約1.1秒、xhigh なら 約2.3秒で返り始める一方、後者は複雑な手順や多段ツール呼び出しを正確にこなします。 「カスタマーサポートの一次受けは low、契約照会や予約調整は medium 以上」のように、シナリオごとにレベルを切り替えるのがV2のセオリーです。

3つの接続方式の使い分け

V2では WebRTC / WebSocket / SIP の3つの接続方式が並列に提供されます。 Beta時代はWebSocketが主流でしたが、GAではブラウザ／モバイル端末から直接繋ぐ場合はWebRTCが第一選択へと推奨が切り替わりました。

graph TB
  subgraph Client
    B["🌐 ブラウザ"]
    M["📱 モバイル"]
    P["📞 電話"]
    S["🖥️ サーバー"]
  end
  subgraph "Realtime API V2"
    RTC["/v1/realtime/calls<br/>（WebRTC）"]
    WS["wss://...realtime<br/>（WebSocket）"]
    SIP["SIP Gateway"]
    Model["gpt-realtime"]
  end
  B --> RTC
  M --> RTC
  P --> SIP
  S --> WS
  RTC --> Model
  WS --> Model
  SIP --> Model

Beta→V2のBreaking Changes

既存のRealtime APIコードがV2でそのまま動かない最大の理由は、エンドポイントとイベント名の刷新です。 最低限の差分は次のとおりで、ここを直さないと 404 または unknown event が返ってきます。

新エンドポイント

イベント名の変更

エフェメラルトークンとセッション起動

ブラウザから直接Realtime APIに繋ぐ際、生のAPIキーを露出させるわけにはいきません。 V2では POST /v1/realtime/client_secrets で短命のクライアントシークレットを発行し、それをブラウザに渡してWebRTC接続に使います。 Beta時代は「Session作成APIの戻り値に紛れて鍵が返ってくる」という分かりにくい設計でしたが、専用エンドポイントとして独立しました。

// サーバー側: エフェメラルトークンの発行（Node.js / TypeScript）
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',            // V2では type 指定が必須
      model: 'gpt-realtime',
      voice: 'cedar',
      instructions: 'あなたは丁寧で簡潔な日本語アシスタントです。',
    },
  }),
});

const { client_secret } = await r.json();
// client_secret.value をブラウザに返す（数分で失効するので毎接続ごとに発行）
return Response.json({ token: client_secret.value });

// ブラウザ側: WebRTCで /v1/realtime/calls に繋ぐ
const token = await fetch('/api/realtime-token').then((r) => r.json());

const pc = new RTCPeerConnection();
const localStream = await navigator.mediaDevices.getUserMedia({ audio: true });
localStream.getTracks().forEach((t) => pc.addTrack(t, localStream));

// モデルからの音声を <audio> で再生
pc.ontrack = (e) => {
  const audioEl = document.querySelector<HTMLAudioElement>('#bot-audio')!;
  audioEl.srcObject = e.streams[0];
};

// 任意のイベント送受信用 DataChannel
const dc = pc.createDataChannel('oai-events');
dc.onmessage = (e) => console.log('event:', JSON.parse(e.data));

// SDP Offer を作って /v1/realtime/calls に投げる
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

const sdpResp = await fetch(
  'https://api.openai.com/v1/realtime/calls?model=gpt-realtime',
  {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${token.token}`,
      'Content-Type': 'application/sdp',
    },
    body: offer.sdp!,
  },
);

await pc.setRemoteDescription({ type: 'answer', sdp: await sdpResp.text() });

ポイントは2点です。(1) session.type をBeta時代のように省略すると弾かれます。 (2) SDPの送信先は /v1/realtime ではなく /v1/realtime/calls に変わりました。

V2で増えた「電話オペレータ級」の能力

リモートMCPサーバー連携

V2の gpt-realtime は、外部ツール接続の標準としてMCP（Model Context Protocol）サーバーをネイティブサポートします。 これまでは関数呼び出しの定義をセッション内に列挙する必要がありましたが、V2ではセッション開始時にMCPサーバーのURLを1つ渡すだけで、サーバー側が公開する全ツールを音声エージェントが使えるようになります。 「予約システムのMCPサーバー」「CRMのMCPサーバー」のように業務システム単位でツール群を管理する設計が、音声エージェントでも自然に成立します。

SIPによる電話通話

TwilioなどのSIPトランクから直接Realtime APIへ接続できるため、電話番号にかけたらAIが出る体験を最小構成で組めます。 Beta時代のように「Twilio Media Streams → 自社サーバー → OpenAI WebSocket」と3段リレーする必要がなくなり、レイテンシも実装量も激減します。

画像入力

音声会話の途中で画像をセッションにアタッチすると、モデルがそれを参照しながら音声で応答します。 「カメラに映した家電の型番を読み上げて操作を案内」「画面共有してエラーログを解説」といったマルチモーダル音声体験がV2で実現可能になりました。

関数呼び出し精度の大幅向上

V2の gpt-realtime は ComplexFuncBench（音声）で66.5%を記録。Beta末期の gpt-4o-realtime-preview（49.7%）から大幅にスコアを伸ばしました。 「適切なタイミングで」「適切な引数で」「適切な関数を」呼べる確率が上がったことで、ツール多用型のエージェント（業務オペレーション、サポート、予約調整）でようやく実用域に達したと言ってよい段階です。

価格と選択指針

GA化と同時に音声トークン単価が 20%引き下げられ、加えてキャッシュ済み入力が $0.40/Mトークンという破格設定になりました。 長時間セッション・同じシステムプロンプトを使い回すボットほど、V2への移行で実コストが下がる構造になっています。

V2でも「Realtime APIを使わない」選択肢

V2は強力ですが、すべての音声ユースケースをRealtime APIに寄せるべきとは限りません。 応答テキストをLLMに任せた上で、音声生成だけTTSに渡したい場合、レイテンシ要件が緩い場合、画面UIとの整合性を細かく制御したい場合は、従来のSTT＋LLM＋TTSパイプラインの方が運用が楽です。

まとめ

Realtime API V2は、Betaが「動くデモ」だったとすれば、GAは「電話オペレータとしての本番投入に耐える」段階に踏み込んだと言えます。 接続方式・モデル・エンドポイント・イベントが整理され、MCP / SIP / 画像入力という業務系で効く3点セットが揃いました。 既存のBetaコードを抱えているなら、5月7日の廃止を機に、エンドポイントとSDKの差し替えだけでも先に済ませておくのが最も損が少ないアップグレード戦略です。