GPT-Live-1をアプリに搭載|API料金と音声設計の3つの変更
代表取締役 上坂大地郎

自分のアプリに、話している途中でも相手の声を聞ける音声AIを組み込む選択肢が加わりました。 OpenAIは2026年9月10日、GPT-Live-1のAPI提供を発表しました。既存のChatGPT Voiceの紹介から、開発者が会話の裏側を設計する段階へ進んだニュースです。API提供の発表。
押さえたい変更は3つあります。
- 会話を扱う音声モデルと、調べたり処理したりするバックエンドを分けます。 話す・聞く役をGPT-Live-1、業務の判断やツール利用を別のモデルやエージェントが受け持ちます。
- APIの音声料金は1分0.05ドル、秒単位の課金です。 バックエンドのモデルとツールの費用は別にかかります。
- 発話への割り込みと、処理の取り消しは別です。 「ちょっと待って」と言われたときに、何を止めるかはアプリ側にも設計が必要です。
音声アプリを開発する人や、問い合わせ対応・作業支援に音声を加えたいプロダクト担当者に向けて、仕組みと利用条件を整理します。読み終えたら、接続方式を選び、費用の概算と試作の確認表を用意できます。仕様は9月11日時点の公式資料に基づき、通話品質や日本語の認識精度を独自に測った記事ではありません。導入資料、モデル・料金資料。
7月のChatGPT提供と、今回のAPI提供を分ける
GPT-Live-1という名前自体は、今回初めて出たものではありません。OpenAIは7月8日にGPT-Liveを発表し、GPT-Live-1とGPT-Live-1 miniのChatGPT向け展開を案内していました。その時点の本文では、API提供は今後の予定として説明されています。7月の発表。
発表元の掲載日 | 対象 | 今回との関係 |
|---|---|---|
2026年7月8日 | ChatGPT向けGPT-Live | 音声モデルと新しい会話体験の発表 |
2026年9月10日 | GPT-Live-1のAPI | 開発者向けの提供と構成・料金を案内 |
初期発表ページには後日追記もあるため、過去のアクセス状況をこの表だけで断定はできません。本記事では、9月10日に公式発表されたAPI提供を扱います。モデルの初登場、ChatGPT内の変更、APIで組み込める機能を分けて読むと、古い紹介記事との食い違いを整理できます。
ChatGPTの契約と、アプリのAPI利用は別に確認する
普段ChatGPTで音声を使っている人も、開発用にはAPIのモデルと料金を確認します。GPT-Live-1のモデル資料では、APIのFree利用階層は非対応とされています。ChatGPTで使えるという経験だけでは、開発プロジェクトから呼び出せることの確認にはなりません。
利用前には、対象のAPIプロジェクトでモデルへのアクセスと利用上限を確認してください。同時接続数や組織の設定も、実際に運用する環境で見る必要があります。本記事では、個別アカウントへの提供状態までは検証していません。モデルの利用階層。
話す・聞く・調べるを、どう分担するのか
全二重は「両方が同時に動ける」という意味
GPT-Liveの特徴である全二重、英語でfull duplexとは、音声を出しながら入力の音声も処理できる仕組みです。電話で相手の説明を聞きながら「その日ではなく翌日です」と差し込む場面を思い浮かべると近いでしょう。順番に完成した文を渡し合うだけの会話とは、扱う時間の流れが変わります。
ただし、全二重だから常に話をかぶせるわけではありません。相づち、言い直し、考えている間の沈黙にどう応じるかも会話の設計に入ります。OpenAIは自然な割り込み処理や会話の改善を説明していますが、実際の聞き取りやすさは、使う言語・音環境・プロンプトで評価する必要があります。 GPT-Liveの構成。
裏側の仕事は、別の担当へ渡す
在庫を調べる、注文内容を照合する、リポジトリを読むといった処理は、バックエンドへ委任します。受付担当が会話を続け、担当部署が調べた結果を戻すような分担です。GPT-Live-1に音声を任せても、使う業務ツールまで自動で用意されるわけではありません。
どの役割をどこに置くのかを、次の構成で確認できます。

会話の自然さを調整する場所と、業務処理を確定する場所を分けておくと、音声を加えた後も既存の確認手順を追いやすくなります。
声の口調を変えたいなら音声側、検索結果をどう扱うかを変えたいならバックエンド側、と修正箇所を分けられます。読者がまず決めるべきなのは、声の種類よりも会話の先で何を調べ、どの結果を返すのかです。文字起こしだけが必要な用途は、文字起こしAPIの記事も参考になります。
委任は2方式、既存アプリの構成から選ぶ
公式資料では、Responses delegationとclient delegationの2方式が示されています。違いは、バックエンドへの依頼や結果の受け渡しを、どこまで自分のアプリが扱うかです。委任方式の比較。
方式 | 主な担当範囲 | 検討しやすい場面 |
|---|---|---|
Responses delegation | 設定したResponsesモデルへの依頼と会話への結果返却をLive側が扱う | 対応するモデル・ツールの範囲で試作を始める |
client delegation | アプリが文脈を組み立て、バックエンドを実行して結果を返す | 既存のエージェントや独自の処理経路を接続する |
既存のテキストエージェントを音声から使う場合
すでに社内検索やコード調査のエージェントがあるなら、client delegationを検討できます。アプリ側で呼び出し先を選べる一方、会話の履歴、言い直された条件、処理中の状態を保持する仕事も必要になります。
たとえば「さっきの件、別のファイルでも確認して」と言われた場合、直前の一文だけでは対象がわかりません。音声の断片を受け取るだけでなく、どの依頼を続けているのかをバックエンドへ伝えます。音声が流れることと、仕事の文脈がつながることは、別々に確認したい項目です。
Realtimeのモデル名だけを置き換えない
GPT-Live-1は専用のLiveエンドポイントを使います。既存のRealtime接続にモデル名だけを入れ替える移行とは考えないほうがよいでしょう。公式移行資料も、音声用プロンプトとバックエンド用の手順を分け、既存のツール、業務ルール、権限、保存すべき状態を残す進め方を示しています。移行資料。
移行前に、現在のアプリで通る会話を保存しておくと比較しやすくなります。新しい会話が滑らかでも、今まで正しくできていた照会や訂正が失われていれば、そのまま置き換える理由にはなりません。
1分0.05ドルに、何を足して見積もるか
音声の時間と、バックエンドの費用を別に数える
9月11日時点のGPT-Live-1の音声料金は、1分0.05ドル、秒単位です。1分未満を次の1分へ切り上げる方式ではありません。バックエンドのモデル利用とツール利用は別に課金されます。料金表。
次は、正常に開始・終了したセッションの音声部分だけを計算した例です。税、通信、バックエンド、外部サービスの料金は含みません。
課金対象の音声セッション時間 | 計算 | 音声部分の金額 |
|---|---|---|
2分 | 2 × 0.05ドル | 0.10ドル |
10分 | 10 × 0.05ドル | 0.50ドル |
100分 | 100 × 0.05ドル | 5.00ドル |
見積もりの基本は「音声セッションの課金秒数÷60×分単価」に、実際に使ったバックエンドとツールの費用を加える形です。モデルごとの単価だけを比べるより、ひとつの依頼が終わるまでの合計で見るほうが、アプリの利用費に近づきます。
無音や待ち時間も、開いたままなら対象になる
公式の費用資料では、利用者やAIが話す時間だけでなく、両者が黙っている時間、バックエンドが作業している時間も稼働中のセッションに含まれます。 マイクをミュートしてもセッションは閉じません。費用の数え方。
さらにWebRTCでは、セッション作成時に初期化の15秒分が課金され、開始後の時間料金に充当されます。動作したセッションへ一律に15秒を足す計算にはせず、接続失敗や再接続が多い場合は作成時の費用も確認します。

安いモデルへ替えても、待ち時間が延びれば音声の費用は増えます。料金比較は、同じ依頼が完了するまでの合計にそろえて行います。
使い終えた後の終了操作も試作の範囲です。音を止めるボタンと、接続を閉じて利用量を回収する処理を混同しないようにします。
最初の試作は、問い合わせの「照会」から
入口はブラウザのWebRTCクイックスタート
公式の導入資料は、ブラウザとサーバーを使うWebRTCクイックスタートを案内しています。マイク、HTTPSまたはlocalhostで配信するページ、APIキーを保持する信頼できるサーバーを用意し、キーはサーバー側に置きます。APIとの接続開始を確認した後、音声の返答とバックエンドの結果をそれぞれ確かめます。導入手順。
試作の対象は、最初から予約や注文を変更するものに広げず、公開FAQの検索や架空の在庫の照会に絞る方法を提案します。何を聞いて、何が返れば正しいかを先に決められるためです。
音声側には短い役割と委任条件を書く
以下は、架空の備品貸出サービスを想定した未実行の試作用プロンプトです。公式資料の役割分担を参考にしています。実際には、バックエンドに用意した機能名とできることへ合わせて変更してください。
あなたは備品貸出の案内担当です。日本語で落ち着いて話してください。
返答は短くし、聞き取れない備品名は聞き返してください。
Backchannel policy:
相づちは控えめにし、利用者が考えている間を急いで埋めないでください。
Interruption policy:
利用者が話を差し込んだら説明を止め、追加の条件を聞いてください。
Delegation policy:
Backend tools:
- 備品照会:指定された備品の貸出状況を調べる。予約や変更はできない。
Delegate to the backend when:
- 利用者が貸出状況を尋ねたとき。
- 備品名や希望日を言い直したとき。
Do not delegate to the backend when:
- あいさつ、または直前の回答の繰り返しだけを求められたとき。
- 備品名が不明で、先に短い確認が必要なとき。
照会結果が届く前に、貸出可能だと答えないでください。
これはバックエンドの実装やツール定義を含むものではありません。「照会できる」と書く前に、実際の検索処理と結果の受け渡しを用意します。長い業務マニュアルを音声側へまとめて置くより、音声側は会話と依頼先の判断、バックエンド側は仕事の手順へ分けるのが公式の推奨です。プロンプト設計。
「話が止まった」を「処理が止まった」にしない
音声アプリで見落としやすいのは、聞こえ方と処理結果のずれです。 GPT-Liveが話すのを止めても、進行中のバックエンド処理まで自動的に取り消されるわけではありません。読み上げの中断、照会条件の訂正、実行中の変更の取り消しは分けて扱います。委任と処理状態。
言い直しを、最後の結果まで追う
想定シナリオとして、「プロジェクターを金曜に……いえ、木曜に借りたい」という発話を考えます。試作で見たいのは、声が自然に返ったかだけではありません。木曜として照会されたか、金曜の古い結果が後から読み上げられないか、画面の条件も木曜にそろっているかを見ます。
変更を伴うアプリなら、実行直前の条件と承認状態をアプリ側で照合する処理も必要です。音声プロンプトの「確認してから」という一文だけを、処理を制御する仕組みの代わりにしないようにします。
文字が届いたことも、読み上げ完了の証明ではない
セッション資料は、会話の文字列、音声再生、バックエンドの進捗を別に扱うよう説明しています。返答の文字列が届いた段階で、利用者が最後まで聞いたと判定するのは早すぎます。また、会話への文脈追加が受理されても、外部の操作が完了したことまでは示しません。セッション管理。
成功表示は、対応する処理結果を受けて出すようにします。障害時の停止・再開の考え方は、AIエージェントのランブックもあわせて確認できます。
採用の判断は、声と仕事を別々に確かめてから
OpenAIの評価ガイドは、音声のやり取りとタスクの実行品質を分けています。自然な完了報告が聞こえても、正しい処理が終わった証拠にはならないためです。音声エージェント評価ガイド。
次の表は、先ほどの備品照会を試すための編集上の提案です。測定結果ではなく、同じ条件で比較するための確認項目として使ってください。
試す会話 | 音声側で見ること | バックエンド・アプリ側で見ること |
|---|---|---|
備品名と希望日を一度で伝える | 聞き返しが必要か | 指定した条件で照会されたか |
説明中に希望日を言い直す | 追加発話を聞けるか | 最新の日付へ結果がそろうか |
途中で少し考える | 説明を急いで始めないか | 沈黙を実行承認として扱っていないか |
照会に時間がかかる | 未確定の結果を答えないか | 古い結果や重複処理が残らないか |
会話を終了する | 終了が利用者に伝わるか | 接続が閉じ、最終利用量を取得できるか |
評価時には、会話の入力、実際の照会条件、返った値、最終的な表示をセットで残します。日本語の備品名をよく間違えるなら、口調を整える前に聞き返し方や検索入力を見直します。正しい値が取れているのに説明が長いなら、音声側の返答を調整する余地があります。
日本語で使う試作では、静かな部屋だけでなく、利用を想定する場所の録音でも確認する方法を提案します。短い型番、似た名前、言い直し、近くの人への発話を混ぜ、元の発話と照会された文字列を見比べます。別の人へのひと言にAIが答えてしまう、訂正前の名前が検索に残るなど、失敗を具体的に記録できる形にします。
比較するときは、同じ会話素材と同じ開始状態を使います。音声側のプロンプトとバックエンドのモデルを同時に変えると、何が改善したのかを切り分けにくくなります。まず片方を固定し、成功した件数だけでなく、失敗した会話の費用も残してください。試験で確かめた条件の範囲を、そのまま採用判断の範囲にします。
最初の採否は「人間らしく話すか」だけで決めず、訂正された依頼を正しく処理し、その結果を伝え、終了まで確認できるかで判断するのが実務的です。ひとつの照会を通した後に、接続先や実行できる操作を広げてください。
参考・出典
- OpenAI「Introducing GPT-Live」https://openai.com/index/introducing-gpt-live/(参照日: 2026-09-11)
- OpenAI「Build more natural voice experiences with GPT-Live-1 in the API」https://openai.com/index/introducing-gpt-live-1-in-the-api/(参照日: 2026-09-11)
- OpenAI「Getting started with GPT-Live」https://developers.openai.com/api/docs/guides/live(参照日: 2026-09-11)
- OpenAI「GPT-Live 1 Model」https://developers.openai.com/api/docs/models/gpt-live-1(参照日: 2026-09-11)
- OpenAI「Delegation and tools in GPT-Live」https://developers.openai.com/api/docs/guides/live-delegation(参照日: 2026-09-11)
- OpenAI「Migrate to GPT-Live」https://developers.openai.com/api/docs/guides/live-migration(参照日: 2026-09-11)
- OpenAI「Cost optimization」https://developers.openai.com/api/docs/guides/voice-latency-cost?api=live(参照日: 2026-09-11)
- OpenAI「Prompting GPT-Live」https://developers.openai.com/api/docs/guides/live-prompting(参照日: 2026-09-11)
- OpenAI「Managing GPT-Live sessions」https://developers.openai.com/api/docs/guides/live-conversations(参照日: 2026-09-11)
- OpenAI「GPT-Live evaluation guide」https://developers.openai.com/cookbook/examples/audio/voice_agent_evaluation(参照日: 2026-09-11)


