OpenAIのRealtime 2、音声AIのプロンプトを「会話の仕様書」にした
OpenAIのRealtime prompting guideを読むと、gpt-realtime-2は単に反応が速い音声モデルではありません。推論量をどこまで使うか、待ち時間に何を短く話すか、どの工具をいつ呼ぶか、聞き間違いをどう扱うかまで、プロンプト側で設計する前提になっています。Realtime 2の変化は、音声AIのプロンプトを「キャラクター設定」から「会話体験の仕様書」へ近づけたことにあります。
Realtime 2は「考えてから話す」音声モデルになった
OpenAIはgpt-realtime-2を、低遅延の音声対話向けでありながら、推論、指示追従、ツール選択、長い文脈保持を強めたモデルとして説明しています。Realtime and audioガイドでも、音声エージェントではreasoning.effortをまずlowから始め、タスクの複雑さとレイテンシ許容度で調整するよう促しています。
ここで大事なのは、音声AIを「すぐ返すほどよい」だけで見なくなった点です。スマートホームのような単純操作ならminimalでよく、診断や複雑な振り分けではmedium以上が必要になる。つまり開発者は、会話の速さだけでなく、どの場面で考えるべきかをプロンプトと設定で切り分ける必要があります。
短い進行発話が、待ち時間のUIになる
Realtime 2のガイドで面白いのは、preamblesをかなり具体的に扱っていることです。これは隠れた思考を見せるものではなく、「注文を確認します」のような短い進行発話です。ツール呼び出しや複数ステップの判断で沈黙が不自然になるときだけ使い、すぐ答えられるときや音声が不明瞭なときは使わない、という境界まで書かれています。
音声インターフェイスでは、画面のローディング表示の代わりに沈黙が発生します。そこへ毎回「考えています」と言わせると煩わしい一方、完全に黙ると止まったように感じます。OpenAIのガイドは、この隙間をプロンプトで設計する対象として扱っています。声のAIにおける進行表示は、UI文言そのものです。
ツール実行と聞き間違いは、プロンプトで境界を決める
ガイドは、ツールをいつ呼ぶかもかなり細かく分けています。読み取り専用で低リスクの検索なら、意図と必要情報がそろえば実行してよい。一方、送信、購入、キャンセル、アカウント変更のような外部影響がある操作は、何が変わるかを要約し、ユーザーに確認してから動く。ここは音声AIの安全設計であり、プロンプトがそのまま操作権限の境界になります。
聞き間違いへの扱いも同じです。注文番号、電話番号、メールアドレスのような高精度の値は、推測で補わず、必要なら一文字ずつ確認する。背景音やテレビ音声、横の会話には反応しないためのwait_for_userのような設計も示されています。Realtime 2では、会話の自然さだけでなく、黙る、聞き返す、確認する、実行するという分岐を製品側が明示する必要があります。
| 設計項目 | ガイドが求めること | UIとしての意味 |
|---|---|---|
| 推論量 | minimalからxhighまで、失敗コストと遅延許容度で選ぶ | すぐ返す場面と考えてから話す場面を分ける |
| preambles | 必要なときだけ短い進行発話を出す | 画面のローディング表示に近い役割を声で担う |
| ツール実行 | 読み取りは早く、変更や送信は確認してから実行する | 会話から外部操作へ移る境界を明示する |
| 高精度の値 | IDや電話番号は推測せず、必要なら一文字ずつ確認する | 聞き間違いがそのまま誤操作になるのを防ぐ |
| 背景音 | 応答不要の音には待機ツールを使う | 話しかけられていないときに反応しない |
Realtime 2のプロンプト設計は、音声AIを「よくしゃべるボット」から、操作を任せられる会話UIへ近づけるための細かい作業です。推論量、進行発話、ツールの積極性、聞き間違い、正確な値の確認、無音への対応。これらをプロンプトに落とすほど、音声AIの体験はモデル性能だけでなく、どこで止め、どこで任せるかの設計問題になります。