先日の発表では、最新の音声変換モデル gpt-realtime、Realtime API の一般提供開始、そして API の数々の新機能を紹介しました。Realtime API と音声変換（s2s）モデルは、モデルの品質、信頼性、開発者にとっての使いやすさが大幅に向上し、一般提供（GA）に移行しました。
API の新機能はドキュメントと API リファレンスで確認できます。この記事では、見落としやすい機能をいくつか取り上げ、どのような場面で役立つかを紹介します。Realtime API をアプリケーションに組み込む際の参考になれば幸いです。
モデルの改善点
新しいモデルには、音声アプリを本番環境で運用しやすくするための改善がいくつも盛り込まれています。この記事では API の変更点を中心に取り上げます。モデルの特性や使い方を詳しく知りたい場合は、発表記事とリアルタイムモデルのプロンプトガイドをご覧ください。ここでも、モデルを使う際のポイントをいくつか紹介します。
このモデルを使う際は、次の点を意識してください。
- リアルタイム Playground でさまざまなプロンプトを試してください。
- アシスタントの音声品質を最大限に引き出すには、
marinまたはcedarを選んでください。 - 新しいモデルに合わせてプロンプトを書き直してください。指示に従う能力が向上し、具体的な指示が以前よりもはるかに強く応答に反映されます。
- たとえば「Y のときは必ず X と言ってください」というプロンプトを、以前のモデルは大まかな指針として扱うことがありました。新しいモデルは、想定していなかった場面でもこの指示に従う可能性があります。
- モデルが指示どおりに動くことを前提に、個々の指示の内容をよく確認してください。
API インターフェースの変更点
一般提供の開始に合わせて Realtime API のインターフェースを更新したため、現在はベータ版と GA 版のインターフェースがあります。GA 版では新機能を利用でき、ベータ版はいずれ非推奨となるため、クライアントを GA 版のインターフェースに移行することをおすすめします。
移行に必要な変更の一覧は、ベータ版から GA 版への移行ガイドをご覧ください。
新しい gpt-realtime モデルはベータ版のインターフェースでも利用できますが、一部の機能はサポートされない場合があります。詳しくは以下をご覧ください。
モデル別の対応機能
Realtime API の GA 版には、いくつもの新機能が含まれています。以前のモデルで利用できるのは、その一部です。
| 機能 | GA モデル | ベータモデル |
|---|---|---|
| 画像入力 | ✅ | ❌ |
| 長いコンテキスト | ✅ | ✅ |
| 非同期 Function Calling | ✅ | ❌ |
| プロンプト | ✅ | ✅ |
| MCP | ✅ 非同期 Function Calling との併用を推奨 | ✅ 非同期 Function Calling がないため制限あり* |
| 音声トークン → テキスト | ✅ | ❌ |
| EU データレジデンシー | ✅ | ✅ 06-03 のみ |
| SIP | ✅ | ✅ |
| アイドルタイムアウト | ✅ | ✅ |
*ベータモデルは非同期 Function Calling に対応していないため、まだ結果が返っていない MCP ツール呼び出しを適切に扱えない場合があります。MCP には GA モデルの使用をおすすめします。
temperature の変更点
GA 版のインターフェースでは、モデルパラメーターから temperature を削除しました。ベータ版のインターフェースでは、temperature の設定範囲は 0.6 - 1.2 で、デフォルト値は 0.8 です。
「応答の再現性を高めたいときなどに、temperature を自由に設定できないのはなぜだろう」と思うかもしれません。このモデルのアーキテクチャでは temperature の作用が従来と異なり、ほとんどの場合、推奨値の 0.8 に設定するのが最適です。
これまでに確認した限りでは、temperature を低くしても毎回同じ音声応答が得られるわけではなく、高くすると音声に異常が生じます。モデルのこうした挙動を調整するには、プロンプトを変えて試すことをおすすめします。
新機能
ベータ版から GA 版への移行に伴う変更に加え、Realtime API にいくつかの新機能を追加しました。
すべての機能はドキュメントと API リファレンスで説明しています。ここでは、API の導入時や移行時に新機能をどう活用できるかを紹介します。
会話のアイドルタイムアウト
アプリケーションによっては、ユーザーからの入力が長時間途切れるのは想定外です。たとえば電話で相手の声がしばらく聞こえなければ、どうしたのか声をかけるでしょう。モデルがユーザーの発言を聞き逃したのかもしれませんし、ユーザーにはモデルがまだ話しているのか分からないのかもしれません。そこで、「まだつながっていますか？」といった声かけをモデルが自動で行う機能を追加しました。
この機能を有効にするには、idle_timeout_ms をターン検出の server_vad 設定で指定します。タイムアウトの計測は、モデルの直前の応答音声の再生が終わってから始まります。つまり、タイムアウトの発生時刻は、response.done の時刻に音声の再生時間と指定したタイムアウト時間を足した時刻です。その間に音声アクティビティ検出（VAD）が発話を検出しなければ、タイムアウトが発生します。
タイムアウトが発生すると、サーバーは input_audio_buffer.timeout_triggered イベントを送信し、空の音声セグメントを会話履歴にコミットして、モデルの応答を開始します。空の音声をコミットすることで、モデルは、その間に VAD が検出し損ねたユーザーの発話がなかったかを確認できます。
クライアントでは、次のように設定してこの機能を有効にできます。
{
"type": "session.update",
"session": {
"type": "realtime",
"instructions": "You are a helpful assistant.",
"audio": {
"input": {
"turn_detection": {
"type": "server_vad",
"idle_timeout_ms": 6000
}
}
}
}
}長時間の会話とコンテキストの管理
Realtime API での長時間セッションの扱いを調整しました。押さえておきたい点は次のとおりです。
- リアルタイムセッションの上限は、従来の 30 分から 60 分に延びました。
gpt-realtimeモデルのコンテキストウィンドウは 32,768 トークンです。応答には最大 4,096 トークンを使用できるため、入力の上限は 28,672 トークンです。- セッションの指示とツールの合計は最大 16,384 トークンです。
- セッションが 28,672 トークンに達すると、サービスは自動的に古いメッセージを削除します。この動作は設定で変更できます。
- GA 版のサービスでは、文字起こしがある場合、トークンを節約するために一部の音声トークンを自動的に削除します。
切り詰めの設定
会話のコンテキストウィンドウがトークンの上限に達すると、Realtime API はセッションの先頭から、古いメッセージを順に自動で削除します。"truncation": "disabled" を設定すると、自動で切り詰める代わりに、応答の生成に必要な入力トークンが多すぎる場合にエラーが発生します。切り詰めを有効にしておくと、入力がモデルの上限を超えてもセッションを継続できます。Realtime API は削除したメッセージの要約やコンパクションを行いませんが、必要に応じて独自に実装できます。
切り詰めで会話の先頭のメッセージが変わると、それまでのプロンプトキャッシュが効かなくなるという欠点があります。プロンプトキャッシュは、プロンプトの先頭から内容が完全に一致する部分を識別します。以降の各ターンでキャッシュされるのは、先頭から変わっていないトークンだけです。切り詰めによって会話の先頭が変わると、キャッシュできるトークンが減ります。
この影響を抑えるため、切り詰めが発生したときに、必要な分よりも多く削除できるようにしました。保持率を 0.8 に設定すると、入力トークン数を上限内に収めるために必要な分だけを削除するのではなく、コンテキストウィンドウの 20% を削除します。毎回少しずつ削るよりも、多めのトークンを一度に削ることで、キャッシュが効かなくなる頻度を減らせます。この方法なら、入力上限に達する長時間のセッションでも、キャッシュを活用してコストを抑えられます。
{
"type": "session.update",
"session": {
"truncation": {
"type": "retention_ratio",
"retention_ratio": 0.8
}
}
}非同期 Function Calling
Responses API では関数を呼び出した直後にその結果を返す必要がありますが、Realtime API では関数呼び出しの結果を待つ間もクライアントはセッションを継続できます。リアルタイムの会話を自然に続けられるため、ユーザーにとっては使いやすくなります。ただし、モデルがまだ返ってきていない関数の結果を作り上げてしまうことがあります。
この問題を軽減するため、GA 版の Responses API では、関数の結果を待っている間もモデルが適切に受け答えできるよう、プレースホルダー応答を追加しました。応答の内容は実験を通じて評価し、調整しています。たとえば、関数呼び出しの結果をモデルに尋ねると、「まだ結果を待っています」といった返答が得られます。新しいモデルではこの機能が自動的に有効になるため、利用側での変更は不要です。
EU データレジデンシー
EU データレジデンシーは、gpt-realtime-2025-08-28 と gpt-4o-realtime-preview-2025-06-03 で利用できるようになりました。利用するには、組織の設定でデータレジデンシーを明示的に有効にし、https://eu.api.openai.com 経由でアクセスする必要があります。
トレーシング
Realtime API は、リアルタイムセッション中の主要なイベントをトレースとして開発者コンソールに記録します。問題の調査やデバッグに活用できます。一般提供の開始に合わせて、次のイベントタイプを追加しました。
- セッション更新（
session.updatedイベントがクライアントに送信されたとき） - 出力テキスト生成（モデルがテキストを生成したとき）
ホスト型プロンプト
Realtime API でプロンプトを利用できるようになりました。アプリケーションコードからプロンプトを参照し、コードとは別にプロンプトを編集できます。プロンプトには、指示のほか、ターン検出などのセッション設定も含まれます。
リアルタイム Playground でプロンプトを作成し、必要に応じて改良を重ねながらバージョンを管理できます。クライアントからは、次のように ID を指定してプロンプトを参照できます。
{
"type": "session.update",
"session": {
"type": "realtime",
"prompt": {
"id": "pmpt_123", // your stored prompt ID
"version": "89", // optional: pin a specific version
"variables": {
"city": "Paris" // example variable used by your prompt
}
},
// You can still set direct session fields; these override prompt fields if they overlap:
"instructions": "Speak clearly and briefly. Confirm understanding before taking actions."
}
}上の例のように、プロンプトの設定とセッションに直接渡した設定が重複する場合は、セッションに直接渡した設定が優先されます。クライアントは、プロンプトの設定をそのまま使うことも、セッション中に変更することもできます。
サイドバンド接続
Realtime API では、クライアントから WebRTC または SIP 経由で API サーバーに直接接続できます。一方、ツールの実行やその他のビジネスロジックは、実装を非公開にし、クライアントに依存しないようにするため、アプリケーションサーバーで扱いたい場合が多いでしょう。
サイドバンドの制御チャネル経由で接続すると、ツールの実行やビジネスロジックなどの実装をサーバー側で保護できます。現在は SIP と WebRTC のどちらの接続でもサイドバンドを利用できます。
サイドバンド接続では、同じリアルタイムセッションに対して、ユーザーのクライアントとアプリケーションサーバーからそれぞれ 1 本ずつ、合計 2 本の接続を同時に維持します。サーバー側の接続を通じて、セッションの監視、指示の更新、ツール呼び出しへの応答ができます。
詳しくは、サイドバンド接続のドキュメントをご覧ください。
開発の第一歩
この記事が、一般提供を開始した Realtime API と新しいリアルタイムモデルの変更点を理解する一助になれば幸いです。
これらの変更点を踏まえて、Realtime API のドキュメントを参考に、音声エージェントの構築、接続の確立、リアルタイムモデルへのプロンプトの送信を試してみてください。