先日、最新の音声変換モデル gpt-realtime を、
Realtime API の一般提供開始および
多数の API 新機能とともに発表しました。Realtime API と音声変換（s2s）モデルは、モデルの品質、信頼性、開発者にとっての使いやすさが大幅に向上し、一般提供（GA）に移行しました。
API の新機能は ドキュメントと API リファレンスで確認できますが、ここでは見落としがちな機能をいくつか取り上げ、どのような場面で活用できるかを紹介します。 Realtime API の組み込みに取り組んでいる方に、この記事が参考になれば幸いです。
モデルの改善点
新しいモデルには、本番環境の音声アプリをより適切にサポートするためのさまざまな改善が含まれています。 この記事では API の変更点を中心に説明します。モデルの理解を深め、活用するには、発表時のブログ記事と リアルタイムのプロンプトガイドをおすすめします。ここでも、具体的なポイントをいくつか紹介します。
このモデルを使う際に押さえておきたいポイントをいくつか紹介します。
- リアルタイムの Playground でプロンプトを試してみてください。
- アシスタントの音声品質を最も高くするには、
marinまたはcedarの音声を使ってください。 - 新しいモデルに合わせてプロンプトを書き直してください。指示に従う能力が向上したため、具体的な指示が以前よりもはるかに強く作用するようになりました。
- たとえば、「Y のときは必ず X と言ってください」というプロンプトは、以前のモデルでは大まかな方針として扱われていたかもしれませんが、新しいモデルでは想定外の状況でもその指示に従う可能性があります。
- どのような指示を与えているか、その具体的な内容に注意してください。指示はそのとおりに実行されるものと考えてください。
API インターフェースの変更
GA のリリースに伴い Realtime API の仕様を更新したため、現在はベータ版と GA 版のインターフェースが存在します。GA インターフェースでは新機能を利用でき、ベータ版インターフェースは将来的に非推奨となるため、クライアントを GA インターフェースに移行することをおすすめします。
移行に必要な変更点の一覧は、ベータ版から GA への移行ドキュメントで確認できます。
ベータ版インターフェースでも新しい gpt-realtime モデルにアクセスできますが、一部の機能には対応していない場合があります。詳しくは以下をご覧ください。
機能の対応状況
Realtime API の GA リリースには、多数の新機能が含まれています。これらの機能には、以前のモデルでも利用できるものと、利用できないものがあります。
| 機能 | GA モデル | ベータ版モデル |
|---|---|---|
| 画像入力 | ✅ | ❌ |
| 長いコンテキスト | ✅ | ✅ |
| 非同期 Function Calling | ✅ | ❌ |
| プロンプト | ✅ | ✅ |
| MCP | ✅ 非同期 FC との併用が最適 | ✅ 非同期 FC がない場合は制限あり* |
| 音声トークン → テキスト | ✅ | ❌ |
| 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 リファレンスで説明していますが、ここでは組み込みや移行にあたって新機能をどう捉えるとよいかを紹介します。
会話のアイドルタイムアウト
アプリケーションによっては、ユーザーからの入力が長時間途絶えるのは想定外の状況です。電話を思い浮かべてください。相手の声が聞こえなくなったら、どうしたのか確認するでしょう。モデルがユーザーの発言を聞き逃したのかもしれませんし、ユーザーがモデルはまだ話しているのかと迷っているのかもしれません。そこで、「まだいらっしゃいますか？」といった発言をモデルが自動で行う機能を追加しました。
この機能を有効にするには、ターン検出用の server_vad 設定で idle_timeout_ms を設定します。
タイムアウト時間は、モデルの最後の応答音声の再生が終わってから計測されます。
つまり、タイムアウトが発生する時刻は、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 では関数呼び出しの完了を待つ間も、クライアントがセッションを継続できます。リアルタイムの会話を自然に続けられるため UX の向上につながりますが、モデルが実際には存在しない関数の応答内容を生成してしまうことがあります。
この問題を軽減するため、GA 版の Responses API では、関数の応答を待っている間もモデルが適切に対応できるよう、実験で評価・調整した内容の仮の応答を追加します。関数呼び出しの結果をモデルに尋ねると、「まだ結果を待っています」といった応答を返します。この機能は新しいモデルで自動的に有効になるため、利用側での変更は不要です。
EU データレジデンシー
gpt-realtime-2025-08-28 と gpt-4o-realtime-preview-2025-06-03 を対象に、EU データレジデンシーがサポートされました。データレジデンシーを利用するには、組織で明示的に有効化し、https://eu.api.openai.com 経由でアクセスする必要があります。
トレース
Realtime API は、リアルタイムセッション中の主要なイベントをトレースとして開発者コンソールに記録します。これは調査やデバッグに役立ちます。GA リリースに伴い、次のイベントタイプを新たに追加しました。
- セッションの更新（
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 と新しいリアルタイムモデルの変更点を理解する助けになれば幸いです。
変更点を把握したところで、リアルタイムのドキュメントを参照し、音声エージェントの構築、接続の開始、リアルタイムモデルへのプロンプト入力に取り組んでみてください。