GPT-Live-1 APIが動かない｜Responses非対応と移行手順

「gpt-realtime を gpt-live-1 に置き換えるだけ」——2026年9月10日のGA（一般提供開始）直後、そう考えて手を動かした開発者の多くが、最初のリクエストで止まりました。モデル名だけ差し替えても動かないのは、設定ミスでもレート制限でもなく、GPT-Live-1 が呼び出し口そのものを別に持っているからです。この記事では、何が「Not supported」なのかを表で確定させ、gpt-realtime 系からの移行で必ず書き換えることになる4か所と、詰まったときの切り分け手順を整理します。

結論から言うと、GPT-Live-1 は v1/live/sessions という専用エンドポイントでしか呼べません。Responses API・Chat Completions・Realtime API・Batch・Fine-tuning は、OpenAI の公式ドキュメント上すべて「Not supported」と明記されています。つまり既存の client.responses.create(model="gpt-live-1", ...) のような書き方は、どれだけ引数を直しても通りません。さらに課金軸も1分あたり0.05ドルの秒課金へ変わっており、トークン単価を前提にしたコスト計算コードもそのままでは破綻します。

まず確定させる：何が使えて、何が「Not supported」か

移行作業でいちばん時間を溶かすのは、「どこかに抜け道があるのでは」と探し続けることです。先に対応表を確定させてしまうのが早道です。公式ドキュメントの記載は次のとおりです。

この表を見て「機能が足りない」と感じたなら、それは設計思想の読み違いです。GPT-Live-1 は会話のリズムだけを担当する層として作られており、推論もツール実行も自分ではやりません。足りない機能は、GPT-Live-1 に足すのではなく後段に置くのが正しい形です。

「推論もツールも自分ではやらない」という前提

GPT-Live-1 は full-duplex（全二重）で、相手の音声を受け取りながら同時に発話を生成し続けます。この性質を成立させるために、重い処理は外へ逃がす設計になっています。逃がし先は2通りです。

• Responses delegation：GPT-6 Astra など Responses API 側のモデルに推論・ツール呼び出しを委譲する。GPT-Live-1 は会話を止めずに待つ。
• client delegation：自分たちのバックエンドに委譲する。社内DBの参照や基幹システムへの問い合わせなど、OpenAI 側に置けない処理はこちら。

ここで見落とされやすいのが課金です。後段のモデル呼び出しとツール利用は、GPT-Live-1 の分課金とは別に請求されます。「1分0.05ドルだから安い」と見積もると、実際の請求は委譲先の分だけ上振れします。委譲設計を先に決めないとコストが読めない、というのはこのためです。委譲先として Responses API を使う場合の書き換えどころは、GPT-6 Astra APIへの移行手順をまとめた記事が参考になります。

gpt-realtime から移行するとき、必ず書き換わる4か所

実装を触る前に、影響範囲を4つに分けて洗い出しておくと手戻りが減ります。

1. 接続コード（器そのもの）。Realtime API のセッション確立・イベント送受信のコードは流用できません。v1/live/sessions でセッションを作る形に組み直します。ここは「直す」ではなく「書き直す」規模だと最初から見積もってください。

2. コスト計算ロジック。gpt-realtime 系は音声の入出力トークン単価（100万トークンあたり入力32ドル・出力64ドル）で課金されますが、GPT-Live-1 は接続していた時間で課金されます。トークン数を集計していた箇所は、セッションの接続秒数を集計する形へ置き換えが必要です。なお秒課金なので、30秒の通話が1分に切り上げられることはありません。

3. レート制限の監視。ここが最も事故になりやすい点です。GPT-Live-1 の制限はトークンではなく同時セッション数で、Tier 1 で25、Tier 5 で500です。TPM（1分あたりトークン数）を見ていた監視・アラートは、そのままでは何も検知しません。しかも同時接続数の上限は、混雑時間帯に一気に張り付く性質があります。Free ティアでは利用できないため、検証用のアカウントが従量課金に切り替わっているかも先に確認してください。

4. 出力の受け口。structured outputs が使えないので、JSON スキーマで戻り値を固定していた箇所は設計変更になります。構造化したいデータは、GPT-Live-1 の出力から抜くのではなく、委譲先のモデル（Responses API 側）で構造化して受け取る形に寄せるのが素直です。

なお、公式はテレフォニー（電話網）への対応を明記しており、割り込み処理は Speak の評価で従来比およそ80%削減されたとしています。会話品質そのものは前進しているので、詰まっているのはほぼ例外なく「入口」と「周辺の前提」のほうです。

私たちMihataでも、音声まわりのAPIをお客様の既存システムに合わせて組み込む仕事をしております。記事の途中で恐縮ですが、「どこまで自社で持ち、どこから委譲するか」の線引きでお困りでしたら、よろしければ合わせてご覧いただけたら嬉しいです。

動かないときの切り分け手順

エラーメッセージだけでは原因が特定しにくいので、上から順に潰していくのが結局いちばん速いです。

1. 呼び出し先URLを確認する。/v1/responses・/v1/chat/completions・/v1/realtime を叩いていないか。SDK 経由だと URL が見えないので、ログにリクエスト先を出して確認します。
2. ティアを確認する。Free ティアでは利用できません。支払い方法が登録され、Tier 1 以上になっているかを確認します。
3. 同時セッション数を確認する。単発では通るのに負荷時だけ落ちるなら、TPM ではなく同時接続数の上限に当たっています。Tier 1 なら25が天井です。
4. 入出力の種別を確認する。画像やファイルを混ぜていないか。audio と text 以外は受け付けません。
5. structured outputs の指定を外す。スキーマ指定が残っていると弾かれます。構造化は委譲先へ移します。
6. ツール実行の置き場所を確認する。GPT-Live-1 に直接ツールを持たせようとしていないか。Responses delegation か client delegation のどちらかに置きます。

この6項目でほとんどのケースは説明がつきます。逆に言えば、ここを通過してもなお動かない場合は、モデル側ではなく音声ストリームの扱い（サンプリングレート、バッファリング、ネットワーク経路）を疑う段階に入ります。

移行の進め方：捨てるものを先に決める

実務で失敗しやすいのは、gpt-realtime の実装を「活かしながら」移行しようとすることです。入口が別である以上、共通化できるのは音声の入出力まわりと業務ロジックだけで、API 呼び出し層は共有できません。次の順で進めるのが現実的です。

第一に、既存コードのうち API 呼び出し層と業務ロジックを物理的に分離します。ここが混ざっていると、移行が全面改修になります。第二に、委譲の境界を決めること。どの問い合わせを Responses delegation に出し、どれを自社バックエンドで処理するかを、コードを書く前に一覧にします。第三に、同時セッション数を前提にした負荷設計に切り替えること。「何人が同時に話しているか」がそのまま上限になるので、待ち行列やフォールバック（テキスト応答への切り替え等）を最初から用意します。

そして、gpt-realtime 系をすぐ捨てる必要はありません。両者は課金軸も入口も違う別系統のモデルであり、用途によって使い分けが成立します。GPT-Live-1 側の機能・料金・ChatGPT アプリでの提供状況は、GPT-Live音声AIでできることと料金を整理した記事にまとめてあります。API の世代交代で似た構図を踏んだ例としては、Assistants APIからResponses APIへの移行を扱った記事も、影響範囲の洗い出し方の参考になるはずです。

移行の判断でいちばん大事なのは、「動かない」を設定の問題だと思い込まないことです。GPT-Live-1 は、既存の API 構成に挿し込む部品ではなく、会話の層を新しく1枚足すものだと捉えると、どこを直すべきかが一気に見通せるようになります。自社の構成でどこまで作り替えが必要か迷われている場合は、お気軽にご相談ください。