「土曜です」と途中で言い直せるGPT-Live 1、API公開で予約窓口はどう変わる？

「金曜の夕方で予約したいです」

AIが空きを調べ始めたところで、利用者が「あ、金曜ではなく土曜です」と言い直す。人との電話なら、ごく普通の訂正です。でも音声AIでは、この“途中で言い直す”場面に、会話と業務処理の設計がぎゅっと詰まっています。

OpenAIは2026年9月10日、GPT-Live 1をAPIで一般提供したと変更履歴で案内しました。
この記事で確認したのは日本時間の2026年9月11日です。
出典：OpenAIの公式発表

これは、ChatGPTの一般画面に新しい音声機能が搭載された、という発表とは別の話です。アプリやサービスを作る側が、モデルID gpt-live-1 をAPIから使い、音声で応対する窓口を組み込めるようになった、という意味です。

今回気になったのは、単に「声で話せる」ことではありません。AIが話している途中にも利用者が話しかけられる全二重の会話と、検索・推論・予約変更のような裏方の作業を別の仕組みに委ねられる点です。

自然に割り込める会話は目立ちますが、本当に大事なのは、その訂正が裏側の予約記録まで正しく届くこと。
ここを混ぜると、感じのよい受け答えなのに予約が違う日付のまま、という少し怖い窓口になってしまいます。

GPT-Live 1は「話しながら聞く」音声モデル

GPT-Live 1は、利用者の発話を待ってから一方的に返すだけでなく、話しながら聞く全二重の音声会話に対応します。

たとえばAIが「金曜日の18時は――」と説明している途中に、「土曜です」と言えば、その言葉を会話に入れられる設計です。電話で相手の説明を遮って訂正する、あの感じに近づけやすいわけですね。

もちろん、これを「従来の音声AIには割り込みが一切なかった」と言い切る話ではありません。音声サービスごとに実装は違います。今回のポイントは、GPT-Live 1の公式資料が、発話中にも聞けることと、会話を続けながらバックエンドへ作業を委任できることを仕様として説明している点です。

音声会話のモデルIDは gpt-live-1。画像・動画入力は非対応です。

つまり、電話や音声チャットの窓口には向いていても、「写真を見て商品の傷を判定して、そのまま会話する」といった設計を、このモデル単体の入力仕様として考えることはできません。音声受付に何を任せ、画像が必要な場面はどう別導線にするか。地味ですが、先に決めておきたい境目です。

想定例：「金曜ではなく土曜です」は、どこへ届く？

ここからは、仕組みを説明するための架空の予約問い合わせです。
実際にGPT-Live 1で試した会話記録や性能評価ではありません。

利用者： 「金曜の夕方、2名で予約できますか？」

AI： 「確認します。金曜日の17時以降で、2名様ですね」

利用者： 「あ、金曜ではなく土曜です」

このとき、GPT-Live 1が担うのは、まず会話を受け止める役です。「承知しました。土曜日に変更して確認します」と自然に言い直せると、利用者は訂正が伝わったと感じやすくなります。

一方で、空席検索や予約枠の確保、変更内容の記録は、バックエンド側の担当です。
バックエンドとは、予約台帳、在庫、顧客情報、検索機能など、実際のデータや業務操作を扱う裏方の仕組みのことです。

会話ができることと、予約を変更できることは別の能力です。
ここを分けて考えると、音声AIのニュースが急に実務の話として読めてきます。

会話と作業の流れ

利用者の発話
→ GPT-Live 1が聞き取り、会話を続ける
→ バックエンドが空席検索・日付変更・予約処理を行う
→ アプリが処理結果を確認する

→ GPT-Live 1が確認済みの結果を利用者へ伝える

この構成では、AIが「土曜へ変更します」と会話をつなぐ間にも、裏方は予約システムへ確認できます。

ただし、会話の速さだけを追いかけないことが大切です。
予約枠を取れたか、変更前の仮押さえが残っていないか、日付と人数が一致するか。
最後に必要なのは、気の利いた相づちではなく、確認済みの結果です。

「説明を止めて」と「予約を取り消して」は別の命令

ここがGPT-Live 1の資料で特に引っかかったところでした。
利用者がAIの発話に割り込んだからといって、バックエンドで進んでいる処理が自動で取り消されるとは限りません。

たとえばAIが予約候補を説明中に、利用者が「もう説明は止めて」と言ったとします。これは会話の発話を止める依頼です。

でも「予約を取り消して」は、予約システムに対する業務操作です。権限を確認し、対象の予約を特定し、取消処理が成功したことを確認する必要があります。同じ“止める”でも、ぜんぜん別の話です。日本語、こういうところが容赦ないです。

公式のガイドでも、発話への割り込みはバックエンド処理を自動キャンセルしないこと、予約の変更や取消しはバックエンドで処理し、結果を確認してから伝えることが案内されています。

そのため、音声窓口では「会話を中断」「処理を保留」「予約を取消」「接続を終了」を別々に設計する必要があります。

特に避けたいのは、裏方の結果が返る前に「予約できました」「取消しました」と口頭で断定することです。会話モデルには、確認前の完了報告をしない役割を持たせる。これは派手ではないけれど、予約・注文・変更受付ではかなり重要な仕様です。

裏方への渡し方は2種類ある

GPT-Live 1では、会話担当とバックエンド担当を分けられます。
公式資料では、主にResponses delegationとclient delegationという2つの考え方が説明されています。

Responses delegationは、GPT-Live側から指定したResponsesモデルへ作業を渡し、結果をライブ会話へ戻す方式です。

予約窓口なら、「土曜の空きを調べて」という依頼を、設定したバックエンドモデルへ渡し、その結果を受けてGPT-Live 1が「土曜18時ならご案内できます」と話すイメージです。接続や受け渡しをAPI側の仕組みに寄せたい場合に検討しやすい方法です。

client delegationは、アプリ側が任意のモデル、エージェント、外部サービスを選び、必要な文脈を渡して処理し、その結果をGPT-Live 1へ返す方式です。

すでに予約台帳や独自の顧客管理、社内の確認フローを持っているなら、こちらは自由度があります。
その代わり、どの情報を渡すか、誰に操作権限を与えるか、処理がどこまで進んだかを、アプリ側でより丁寧に管理する必要があります。

非エンジニアとして相談するときは、「どちらが新しいか」よりも、「今ある予約システムを残せるか」「失敗した変更を誰が検知するか」を聞くほうが実りがあります。

音声が自然でも、裏方モデルまで同じとは限らない

GPT-Live 1の音声モデルと、推論・検索・ツール利用を担うバックエンドのモデルは、独立して選べます。

公式の委任ガイドでは、開始候補としてGPT-5.6 Terra、コストを重視する候補としてGPT-5.6 Lunaが例示されています。
ただし、低コストの候補が、品質や遅延まで同じという意味ではありません。

予約のように訂正が多い窓口では、「金曜」を「土曜」に直せるかだけでなく、店名、人名、商品名、時間帯などの固有名詞をどう扱うかが気になります。

音声側が聞き取れても、裏方へ渡した文字列が違っていたら結果はずれます。
逆に、裏方の検索が正しくても、会話側が古い候補を口にしたら混乱します。

だからモデル比較は、短い雑談だけで決めないほうがよさそうです。
同じ条件の会話で、訂正、聞き返し、予約変更、処理失敗時の案内までを確かめる。

全面入れ替えの前に、既存の業務の仕組みへ音声窓口をつなぐ小さな試験から始めるのが現実的です。

料金は、まず音声セッションだけを切り出す

GPT-Live 1の音声セッション料金は、継続時間1分あたり0.05米ドルです。
秒単位で課金され、次の1分へ切り上げられません。
2026年9月11日の確認時点では、公式の利用制限表で無料のAPI利用区分（Free）は非対応です。無料枠で試せる前提にはせず、利用区分と予算を確認してから接続します。
出典：GPT-Live 1の公式料金・利用制限

計算式はシンプルです。

音声セッション料金（米ドル）＝ 継続時間
（分）× 0.05

音声セッション継続時間と料金（音声部分）
5分：0.25米ドル
10分：0.50米ドル
30分：1.50米ドル

これは公式単価からの単純計算です。
実測した請求額ではありません。

また、この料金例は人が発声した時間だけの料金でも、サービス全体の費用でもありません。
セッションの継続時間を対象にした音声部分だけの試算です。

バックエンドモデルの利用料、検索や予約システム連携などのツール利用料は別途かかります。
さらに、アプリの開発・保守、電話回線や音声入出力の仕組み、為替も総費用には影響します。

「1分5セントなら安い」とだけ判断するより、1件の問い合わせで会話が何分続き、裏方の確認を何回行い、どこで有人対応へ切り替えるかまで置いて考えるほうが、導入後の驚きは減らせます。

導入前に確かめたい5つのこと

ここからは、GPT-Live 1の実測結果ではなく、試験や開発相談で確認したい観点です。
サービスの種類が違っても、この5つはかなり使い回せます。

「金曜ではなく土曜」が、会話だけでなく検索条件・予約記録・確認メッセージまで直っているかを見ます。

AIが「予約できました」と言った内容と、予約台帳に残った日時・人数・メニューが一致するかを確かめます。

人名、店舗名、商品名、地名を復唱し、利用者が訂正できる流れがあるかを確認します。

会話を終える、処理だけを待つ、処理を取り消す、有人窓口へ渡す。それぞれが混線しないかを見ます。

音声セッション料だけでなく、バックエンドモデル、ツール、外部サービス、保守を含めた上限や通知条件を決めます。

画像・動画入力が非対応であることも、ここで確認したい制約です。
写真確認が必要な問い合わせを受けるなら、画像を受け取る別のフォームへ案内するのか、有人対応へつなぐのかを先に決めておくと迷いません。

開発者に相談するときの短いメモ

下は完成済みアプリのコードではなく、相談時に要件を伝えるためのメモです。
角かっこを自分のサービスに合わせて置き換えて使います。

使う場所：開発会社・社内担当者との初回相談、試験導入の依頼文です。

変更する箇所：目的、操作を行う条件と完了を伝える条件、停止時の扱い、費用上限です。

入力例：予約変更を受ける音声窓口を想定しています。
期待する結果は、会話が自然でも未確認の変更完了を伝えない設計が共有できることです。

音声会話の目的：［予約の空き確認と変更
受付］

会話中に訂正があった場合：［日付・人数・
名前を復唱し、最終記録まで反映する］

実行と完了案内の条件：［権限・必要な確認
を満たしてから予約・取消しを実行し、
成功結果を確認するまで完了と案内しない］

「話を止めて」と言われた場合：［発話だけ
を止める／裏で進行中の処理は状態を確認
する］

「予約を取り消して」と言われた場合：［
本人確認後にバックエンドで取消し、結果
確認後に案内する］

接続終了時の扱い：［進行中処理の状態を
案内し、必要なら有人窓口へ引き継ぐ］

費用の確認範囲：［音声セッション、バック
エンドモデル、ツール、外部連携を含めた
月額上限］

GPT-Live 1のAPI公開は、「AIが途中で話を聞いてくれる」という会話体験を作りやすくするニュースです。

でも予約や変更受付で価値になるのは、割り込みへの反応そのものより、訂正を正しい処理へつなぎ、確認できた結果だけを伝えることです。
話し上手な窓口と、間違えずに仕事を終える裏方。

この二人三脚として見ると、検討すべき点がかなり具体的になります。

参考資料

https://developers.openai.com/api/docs/changelog

https://developers.openai.com/api/docs/models/gpt-live-1

https://developers.openai.com/api/docs/guides/live

https://developers.openai.com/api/docs/guides/live-delegation

https://developers.openai.com/api/docs/guides/live-prompting