GPT-Live-1、ついに発信対応：SIP GAが実際にもたらすもの、そして依然としてできないこと

OpenAIの音声エージェントができるようになった最も有用な新機能は、「1を押す」ことだ。2026年11月4日の遅く以降、GPT-Live-1のセッションはSIPトランク経由で実際の電話番号に発信し、応答したメニューを聞き取り、キーパッドのトーンを回線の向こうへ送り返すことができる。この最後の部分、すなわち双方向DTMFこそが、ただ話すだけの音声エージェントと、自動音声応答のツリーをくぐり抜けて本当に必要な部署までたどり着ける音声エージェントとの違いである。

モデル自体は新しいものではない。GPT-Live-1は2026年7月8日からChatGPT Voiceで、2026年9月10日からはAPIで毎分0.05ドルで提供されている。11月4日に変わったのはトランスポートだ。OpenAIのJustin Ubertiは、アウトバウンド電話APIが「たった今…GAに昇格した」と発表し、「任意のSIPトランクプロバイダー（例：TelnyxやTwilio）」経由で「開発者がLive音声エージェントから電話をかけられるようにする」ものだと述べた。Greg Brockmanは同じ夜にそれを広めた。発表ではさらに、通話はHD Voiceを使用でき、キーパッドイベントを送受信できると付け加えている。

つまりこれはモデルの話ではなく機能の話であり、興味深い内容は投稿ではなくドキュメントにある。OpenAIのTelephony and SIPガイドは現在、アウトバウンド発信について「Live APIを通じてすべての組織が利用でき、Realtime APIのcall-creationエンドポイントではない」と明記している。この2文は、人々が再利用しようとする統合の大部分を静かに除外している。

「GA」が変えたこと、そして変えなかったこと

プロモーションの前にもアウトバウンド通話は存在していたが、一般には利用可能ではなかった——それが「promoted」の意味である。仕組みはすでに構築されており、扉は開かれていた。OpenAIのドキュメントには今、それに対応する文が掲載されている。アウトバウンドSIP通話は「Live APIを通じてすべての組織が利用できる」というもので、ページ上でGA宣言に最も近い記述だ。ガイド自体にはbeta、preview、alphaのラベルがどこにも付いていない。

変わっていないのは音声モデルです。OpenAI 自身のドキュメントにあるアウトバウンドの例では、今でも model: "gpt-live-1" と設定されており、パートナー向けチェックリストも依然として、インテグレーターに「gpt-live-1 をサポートするパッケージバージョン」を探すよう伝えています。アウトバウンド専用のモデルも、別料金も、テレフォニー向けの階層もありません。音声レイヤーに支払う1分あたり0.05ドルは9月と同じです。ただ、サーバーの外に出る通話にその費用を使えるようになっただけです。

運用上の注意点が1つ、発表ではなくガイドの中に隠れています。OpenAIは、「このフローを使用する前に、GPT-Live SIPサポートが自分のプロジェクトで有効になっていること、およびプロバイダーのSIPトランクがそのプロジェクトにルーティングされていることを確認するよう」指示しています。GAという表示と、プロジェクト設定が有効であることは同じではありません。そして週の最初のサポートチケットは、片方だけを満たしている人からのものになるでしょう。

トランクがそもそも機能するかどうかを決める前提条件

OpenAIはSIPを一般的な意味で採用したわけではない。採用したのはSIPの狭く現代的に限定された一部であり、次のいずれかを満たさないトランクは、「あらゆるSIPトランクプロバイダー」に対応すると発表で約束されていても接続できない。

• シグナリング — TLSは必須であり、任意ではありません。UDPやTCPによる平文のSIPは対象外です。

• メディア — SDES-SRTP が必須であり、SRTP はプロバイダー側で有効化されている必要があります。単に対応しているだけでは不十分です。

• プロバイダー URL — sips: エンドポイントが想定され、デフォルトではポート 5061 を使用し、認証情報、パス、URI パラメーターは付加されません。

• 宛先 — {{1}}+14155550123{{/1}} のような E.164 番号のみで、それ以外は受け付けません。SIP URI は明示的にサポート対象外のため、内部内線の仕組みで代用することはできません。

• 認証 — ダイジェスト。SIPユーザー名とパスワード、さらに caller_numberはE.164形式で、着信側に表示される発信者IDになります。

• ネットワーク衛生 — ローカルホスト名とリテラルのプライベートIPアドレスは拒否されるため、ラボのマシンを指すテストリグは排除されます。

• 音声フォーマット — audio.format は未設定のままにしてください。SIP がネゴシエートするためです。設定すると、一見親切そうに見えて通話を壊す類のパラメータになります。

「任意のプロバイダー」という主張にとって、これが何を意味するかに注意してください。TLSシグナリングとSDES-SRTPメディアを扱うプロバイダーならどれでも機能します。非常に多くの安価なSIPトランクは依然としてUDPとプレーンRTPをデフォルトとしており、その一文の対象には含まれません。接続の仕組みはWebhookではなくセッション作成です。POSTする際は /v1/live/sessions を使用し、transport.type を sip に設定します。ガイドには「アウトバウンド通話には、着信通話用のWebhookも承諾リクエストも必要ありません」と明記されています。

返ってくるのは session.id とトランスポート種別です。そしてドキュメントは、それと現実とのギャップについて異例なほど率直にこう述べています。「このレスポンスは、通話が応答されたことを意味しません。」呼び出し、応答、失敗は後から transport.ringing、transport.answered、transport.failed イベントとしてサイドバンド WebSocket で到着します。接続先は /v1/live/sessions/{session_id}/attach。すぐにアタッチしてください — リプレイされるのは直前3秒間のイベントのみです — そして event_id で重複排除してください。ガイドは重複配信が正常であると警告しているからです。

エンベロープ：3分で鳴らし、2時間で話す

ガイドに示された2つの具体的な数値が、どのアウトバウンドのユースケースが実現可能かを左右するが、そのどちらも発表内容には含まれていなかった。

• 呼び出し時間の上限 — 3分。それまでに応答がない通話は終了します。

• 接続上限 — 2時間。その後は、何が行われていてもセッションは終了します。

• コントロールサーフェス — 転送は/v1/live/sessions/{id}/refer、切断は/v1/live/sessions/{id}/hangup、DTMF はサイドバンド経由でtransport.dtmf.sendを使って送信します。

• 障害モード — 不正なセッション設定は作成時に明示的に失敗し、トランスポートのセットアップは502を返す可能性があり、初期化のタイムアウトは504を返し、それ以降に発生するものはすべて非同期的にtransport.failed。

3分間の呼び出しはコンシューマー向けアウトバウンドには問題ありませんが、通話を保留する企業の電話交換機には扱いにくいものです。2時間の上限は余裕がありますが、エージェントをサポート待ち行列に配置すると、長時間の保留に長い会話が加わり、現実的にその上限に近づく可能性があります。どちらの制限もリアルタイム音声製品では驚くことではありません。どちらも、顧客にキャンペーンのSLAを約束する前に把握しておきたい類のものです。

通話にかかる費用を、正直に

OpenAIの料金ページには、GPT-Live-1の音声セッションが1分あたり0.05ドルと記載されており、「秒単位で請求され、1分単位に切り上げられることはない」とされています。これが公開価格のすべてであり、アウトバウンド通話で発生する2つの請求のうちの1つにすぎません。もう1つはキャリアの終端料金で、宛先、通話量、および選択したトランクプロバイダーによって異なります。OpenAIは音声処理とセッションロジックを担い、PSTN区間はプロバイダーが所有します。

• 応答があった1分間の通話 — OpenAI から $0.050、さらに通信事業者の1分あたりの料金。

• 4分間の通話 — OpenAIから$0.200、さらに通信事業者。

• 4分の通話1,000件——合計4,000分、つまりOpenAIから200ドル、さらに通信キャリア費用。

• 1時間の通話 — OpenAI から 3.00 ドル、加えて通信事業者の料金。

そのメーターについては、注意すべき点が2つあります。第一に、課金単位はセッション分であり、料金ページには音声と無音を区別する記載が一切ないため、エージェントが保留音を聞いて過ごす秒数も、話して過ごす秒数と同じレートで加算されます。第二に、ガイドには、3分間呼び出し音が鳴り続けて誰も応答しなかった通話が課金対象のセッションになるかどうかが記載されていません。これは、大量のダイヤラー運用を始める前にサポートへ確認する価値のある質問であり、始めた後に確認するものではありません。

バックエンドモデルとツールの利用は、委任先のモデルに応じた料金で別途請求されます。その区間をOrcaRouter経由にする場合、0%のマークアップとパススルー価格が、音声の1分料金ではなく、そちらに適用されます — そのため、推論モデルでプロバイダーが値下げすれば同じ日に請求書へ反映され、gpt-live-1の値下げは反映されません。

ご利用の Realtime 統合は引き継がれません

今週犯しうる最も高くつく単一の過ちは、動作するRealtime APIテレフォニースタックが、そのまま動作するGPT-Liveスタックでもあると仮定することだ。OpenAIのパートナーページは率直にこう述べている。「Realtime統合は自動的にGPT-Liveと互換になるわけではない」。エンドポイントは異なり、セッションモデルも異なり、委任はRealtimeが同じ形では持たない概念であり、ガイドがパートナーごとに確認するよう求めている音声フォーマットや中断のセマンティクスも引き継がれない。

パートナー一覧は、発表の言い回しも複雑にしている。OpenAIは音声エージェント向けにLiveKitを、電話の「着信と発信」向けにTwilio Agent Connectを、「アウトバウンド通話体験」向けにTelnyxを、SIP経由の「着信」向けにBandwidthを、そしてLiveサービス全般向けにDaily/Pipecatをそれぞれ文書化している。つまり、Bandwidthはインバウンド連携として文書化されており、LiveKitとPipecatは通話方向を一切示さずに文書化されている。「任意のSIPトランクプロバイダー」というのはプロトコル互換性についての記述であって、OpenAIの5社のパートナーのうちどれがアウトバウンド対応を提供済みかについての記述ではない。

Twilioをご利用の場合、今日時点でアウトバウンド経路が文書化されているのはそのマイグレーションです。受信にBandwidthをご利用の場合、その統合経由での送信はまだドキュメントで保証されているものではありません。

誰も尋ねなかったバージョンの問い

この名前には現時点で未解決の曖昧さがあります。GPT-Live-1.1 は 2026年10月15日に ChatGPT Voice に統合され、6言語に対応した新しい音声が追加されましたが、OpenAI はまだ gpt-live-1.1 モデル ID を API 利用者向けに公開していません。テレフォニーガイドのすべてのアウトバウンド例では gpt-live-1 を使用しています。同僚が、ChatGPT が使っているからという理由でアウトバウンドエージェントが 1.1 で動作していると言う場合、その同僚は消費者向け製品について説明しているのであり、あなたのセッション構成について説明しているのではありません。

実務的には、計画にgpt-live-1を記載し、1.1 APIの可用性については別個のイベントとして、その日付に独自に検証すべきものとして扱ってください。

思考が行われる場所、そしてそれがあなたの操るレバーである理由

GPT-Liveは真っ二つに分かれています。ドキュメント自体の要約では、「推論とツールの使用をバックエンドに委任し、自身は音声による会話を管理する」とされています。音声レイヤーがタイミング、割り込み、韻律を処理し、別個のモデルが思考を担ってツールを呼び出します。そのバックエンドはセッションごとにdelegationの下で、2つのモードのいずれかで設定されます。

• Responses への委任 — delegation.type: "responses" には必須のバックエンド model があり、さらに instructions、tools、tool choice、トークン制限、サービスティアを指定します。OpenAI のガイドでは、まず gpt-6-luna、または gpt-6-sol をより難しい作業向けとして推奨し、「Responses モデルは音声モデルとは独立して選択できます」と述べています。

• クライアント委任 — delegation.type: "client"。これは、お使いのアプリケーション自身がバックエンドを実行する形態です。OpenAIの表現によれば、これにより「アプリケーションが運用する任意のモデル、エージェント、またはサービス」が許可されます。

アウトバウンドエージェントのコストと品質が実際に決まるのはここであり、このページで本当にあなたの裁量に委ねられている唯一のアーキテクチャ上の選択です。音声モデルは固定されており、たまたまOrcaRouterのカタログにはありません — GPT-Live-1はOpenAIから購入するテレフォニーフロントエンドであり、ルーティングの工夫をどれだけ凝らしてもそれは変わりません。バックエンドは話が別です。クライアント委任の場合、それはあなたのコードが行う通常のモデル呼び出しであり、つまり200以上のモデルに対応する1つのAPI、評価対象のベンダー間で1つのキー、キャンペーン中にプロバイダーが劣化した場合の自動フェイルオーバー、通話タイプごとのモデル選択——IVRメニューをたどるには安価なモデル、人間が出たらより強力なモデル——が可能になります。

Responses delegation では、OpenAI がその部分を実行し、OpenAI 自身の料金体系で請求します。どちらも正当な方法で、判断を下す場所が異なるだけです。バックエンドの選択をルーティング上の判断にしたいなら、client delegation がそれを実現するモードです。

発表が省いたこと

GAの告知記事としては、デプロイを左右する事柄についての説明が薄い。リージョンごとの提供状況、レイテンシ、同時実行数の上限、SLAについては何も触れていない。録音、開示、同意に関する義務についても何も触れていない。そしてアウトバウンド通話は、この製品においてそれらの義務が理論上の話ではない唯一の領域だ。米国では、同意なく消費者に自動通話をかけることは、エンジニアリングの問題である前にTCPAの問題である。EUでは、相手に伝えずに通話を録音すること自体が問題となる。APIが提供するのはcaller_numberと通話終了エンドポイントだけだ。コンプライアンスは利用者の責任である。

「HD Voice」も仕様ではなく主張として扱う価値がある。OpenAIのドキュメントは、SIPが音声フォーマットをネゴシエートすると述べているだけで、コーデックは一切記載していない。したがって、投稿にある広帯域音声は、どこにも公に数値化されていないベンダーの主張である。スライドに入れる前に、自社のキャリアで検証すること。

これで今週何をする？

すでにWebRTC上でGPT-Live音声エージェントを運用している場合、アウトバウンド経路は書き直しではなく2つ目のトランスポートです。新しいセッションを次で作成し、transport.type: "sip"、TLSとSDES-SRTPを話すトランク、そしてリンギング・応答・DTMFを監視するサイドバンドWebSocketを用意します。1日を見込むべきはトランクであり、エージェントではありません。

Realtimeを使用している場合は、それが設定変更であると想定して移行をスケジュールしないでください。まず委任とセッションのセクションを読み、バックエンドをOpenAIのものにするか自社のものにするかを決め、その後でパートナーを選んでください。というのも、インバウンドですでに使用しているパートナーが、文書化されたアウトバウンド経路を持つパートナーとは限らないからです。

アウトバウンド音声をそもそも構築する価値があるかどうかをまだ判断しているのであれば、重要な数字は、キャリア課金前で接続1時間あたり$3.00、これに対して2時間のハードキャップと3分のリングだ。これはテストするには十分安く、待ち時間が偶発的なものではなく設計上の判断になるほど高くつく。GAはゲートを取り除いた。だが算術を取り除いたわけではない。