OpenAI · Realtime API 2.1
音声エージェントに、
「軽量版」が入る。
推論・コーディング・サイバー防御に力を注いできた OpenAI が、しばらく手薄だった低遅延の音声エージェント領域に戻ってきました。新しい Realtime API では、フル機能の GPT-Realtime-2.1 と、コストと遅延を絞った軽量版 GPT-Realtime-2.1 mini を並べて選べます。作りたいのがコールセンターか、案内ボットか、社内 IVR か——選択肢が二段になった意味を図で解きます。
The Gap
推論とコーディングに寄っていた
ここ数ヶ月
2026 年前半の OpenAI の主戦場は、推論の強化（chain-of-thought の効率化）、コーディングエージェント、そして自社モデルを使ったサイバー防御の実験——テキストと思考の側でした。その裏で、Realtime API を軸にした音声エージェントのラインナップは、しばらく大きな更新がありませんでした。Anthropic や ElevenLabs、Google の Gemini Live などが音声の低遅延化を進める間、OpenAI は「音声はある。ただ、そこに全力ではない」という距離感でした。
そこに戻ってきたのが、今回のリリースです。低遅延音声エージェント向けの新モデルとして、フル機能の GPT-Realtime-2.1 と、軽量版の GPT-Realtime-2.1 mini が同時に追加されました。単に「新モデルが 1 個追加」ではなく、フル版と軽量版の二段構えで出てきたところが意味を持ちます。
Anatomy of Latency
音声エージェントの
遅延はどこで生まれるか
「反応が遅い」の中身は、実は 3 段階に分解できます。軽量版の効きどころを見るには、まずこの構造を押さえるのが早道です。
聴き取り（音声 → テキスト）
マイクから来た音を認識してテキストにするフェーズ。ノイズ環境が悪くない限り、今どきは秒未満で終わります。ここは軽量版でもフル版でもほぼ同じ体感です。
考えて答える（モデル推論）
一番遅延に効くのがここ。フル版は文脈を深く追って気の利いた回答を返せる代わり、応答の一語目までの待ち時間が伸びやすい。軽量版はここを削ることで、返事の立ち上がりを速くします。
合成して喋る（テキスト → 音声）
回答テキストを声に戻すフェーズ。ここもストリーミング合成が主流なので、体感遅延の主因ではありません。「聴こえ方」の自然さはモデル側の抑揚にも寄りますが、待ち時間には直結しません。
2.1 vs 2.1 mini
どちらを使うか、
基準は「遅延と会話量」
難しいポリシー分岐は要らず、シンプルに 2 軸で決まります。
厳密な料金・latency 数値は公開資料次第で変わるため、ここでは使い分けの原理だけ押さえます。フル版の GPT-Realtime-2.1 は、複数ターンにまたがる複雑な要件確認や、ドメイン知識に踏み込んだ相談に向きます。ユーザーが同じ話題を長く続ける、あるいは判断そのものを AI に委ねる系のシナリオです。
軽量版の GPT-Realtime-2.1 mini は、会話量が多く、1 発話あたりのやりとりは短いケースが本領。予約変更、メニュー案内、フォーム記入補助、社内 IVR の一次受け——こうした「秒で返って欲しい」系で効きます。フル版で足りている用途を無理に mini に落とす必要はなく、逆にヘビーな用途は最初から 2.1 で組んだ方が結局速く仕上がります。
Where It Lands
どこで効くか
コールセンター一次受け
「予約変更」「営業時間」「配送状況」といった定型 8 割の問い合わせを mini で捌き、複雑な相談だけ人間または 2.1 にエスカレーション。全量を人間にせず、全量を高精度モデルにもしない構成が組みやすくなります。
店頭・受付の音声案内
混雑時にすぐ返事が返らないと体験が壊れる場面。mini の立ち上がりの速さが、そのまま「聞かれてから答えるまでの秒数」に効きます。多言語対応も同じモデルで組めます。
社内 IVR・アシスタント
予定確認、経費入力の受付、社内ナレッジ検索の音声版など、業務での「短い問い返し」に強い。回答の質より応答性が体験を決めるので、mini の適性が高い領域です。
So What
テキスト派には遠く、
音声を作る側には追い風
チャット UI だけを扱う開発者にとっては、今回のリリースは直接影響しません。「Realtime API のラインナップが増えた」以上の意味は薄いままです。裏を返せば、音声を作る側にとってはまとまった選択肢が入ったということ。フル版一択で組んで遅延を我慢するか、外に音声用の別モデルを立てるかしかなかった構成が、OpenAI 内で二段に分かれた——ここが実務的な変化です。
設計の勘所は 2 つ。第一に、「まず mini で組んで、体験が破綻する場面だけ 2.1 にフォールバック」の順に試すこと。逆順だと遅延を体感する機会を失って、後から mini にできる余地に気づけません。第二に、推論の重い分岐はテキスト側に逃がすこと。音声応答は「聞こえた→返す」の速さを守り、深い判断は非同期のテキストパイプに移すと、mini の得意領域を活かしきれます。