GPT-Live-1とは？同時発話・電話対応・導入条件から企業PoCの進め方まで
AI新規事業
AI新規事業のPoC・立ち上げ、何から始めるべきかご相談ください
要件定義からリリースまで、Mojiがワンチームで伴走します。
GPT-Live-1は、自然な音声会話の進行を担うOpenAI API向けの音声モデルです。ユーザーの発話を聞きながら応答し、途中の割り込みにも対応できます。一方、複雑な推論、社内情報の検索、CRMなどの業務システム操作は、別のバックエンドエージェントへ委任する設計です。つまり、GPT-Live-1だけで電話業務を自動化する製品ではなく、会話制御の層と、業務処理・権限管理の層を分けて構築するためのモデルと捉えるのが適切です。
OpenAIはGPT-Live-1を、同時に聞いて話せる「full-duplex」の音声モデルとして案内しています。2026年10月6日時点で、API料金はフロントエンドの音声レイヤーが1分あたり0.05米ドル、秒単位の課金です。バックエンドで使うモデル、ツール、検索などの料金は別途かかります。GPT-Live 1の公式モデル仕様およびOpenAIの発表を、導入前に必ず再確認してください。
本記事で示すPoCの手順、評価指標、権限設計テンプレートは、特記のない限りMojiによる実務上の提案です。業務の重要度、入力音声の品質、利用者の話し方、バックエンドモデル、評価データ、許容できない失敗によって結論は変わります。
GPT-Live-1でできること
GPT-Live-1の役割は、会話を止めずに進めることです。会話中にユーザーが補足・訂正・質問を重ねても、音声対話を継続しながら、必要なタイミングでバックエンドへ処理を依頼できます。OpenAIの公式ドキュメントでは、GPT-Liveが会話を扱い、バックエンドが推論、ツール利用、長い処理を担う構成を説明しています。GPT-Liveの開始ガイド
- 同時発話：ユーザーの発話を受けながら音声を返す会話体験を設計できる
- 割り込み対応：応答中にユーザーが話し始めた場合に、会話を切り替える設計ができる
- バックチャネル：「確認します」「少々お待ちください」など、バックエンド処理中の会話を維持できる
- バックエンドへの委任：検索、推論、ツール呼び出し、社内システムとの連携を別のモデル・エージェントへ任せられる
- 電話連携：SIPを接続方式として利用でき、電話音声を扱う構成を選べる
会話用の指示は短く保ち、詳細な業務手順、参照データ、権限判定、ツール実行条件はバックエンドへ置くことが、OpenAIの推奨です。会話を自然にする指示と、業務を正しく安全に実行する規則を一つの長いプロンプトへ混ぜない方が、修正・評価・監査を分けやすくなります。GPT-Liveのプロンプティングガイド
向く業務と、最初の対象にしにくい業務
GPT-Live-1が向くのは、「会話の自然さ」そのものが体験価値または業務効率に影響する業務です。特に、顧客が途中で条件を追加する、沈黙や言い直しがある、画面操作より電話・音声が自然な窓口で効果を検証しやすいでしょう。
適性 | 業務例 | 最初に設計すること |
|---|---|---|
高い | 予約受付、一次問い合わせ、注文・配送状況の案内 | 本人確認の要否、回答できる範囲、人への転送条件 |
高い | 社内ITヘルプデスク、手順案内、現場作業の案内 | 参照する正本、回答根拠、誤案内時のエスカレーション |
条件付き | 変更・取消・住所更新などの顧客情報操作 | 認証、再確認、実行前承認、取消・復旧方法 |
最初のPoCには不向き | 返金確定、契約変更、医療・法務の個別判断、緊急対応 | 人が最終判断するフローを先に整備し、音声AIは受付・下書きに限定 |
「電話に対応できる」ことと、「電話で完結する業務を自動化してよい」ことは別です。たとえば配送状況を読むだけなら低リスクでも、住所変更や解約を確定する操作には、本人確認・承認・監査証跡が必要になります。AIエージェントへ委ねる操作範囲の決め方は、AIエージェントはどこまで任せるべきかも参照してください。
TTS・音声認識・Realtime APIとの違い
音声AIを導入するときは、「音声を出せるか」ではなく、どの層の課題を解きたいかで選びます。下表は一般的な設計上の目安です。実際の品質・遅延・費用は、モデル、音声品質、ネットワーク、会話設計、バックエンド処理、評価指標で変わります。
方式 | 主な役割 | 向くケース | 設計上の注意 |
|---|---|---|---|
TTS | テキストを音声に変換する | 固定文の読み上げ、動画ナレーション、IVRの案内 | 会話のターン管理や業務判断は別途必要 |
音声認識（STT） | 音声をテキストに変換する | 文字起こし、録音の検索、後処理 | 会話応答、音声出力、割り込み制御は別途必要 |
STT→LLM→TTS | 各コンポーネントを連結する | 発話内容をテキストとして厳密に保存・制御したい場合 | 区切り判定、待ち時間、割り込み時の停止処理を自前で設計する |
GPT-Live-1 | 連続音声会話とバックエンド委任 | 自然な対話、割り込み、電話・音声エージェント | 業務ルール、ツール権限、承認はバックエンドで管理する |
Realtime API | 低遅延のマルチモーダルなリアルタイム接続 | 既存Realtime実装の維持、音声以外を含むリアルタイム体験 | GPT-Live移行の要否は、会話体験と既存アーキテクチャを評価して決める |
GPT-Live-1は、Function callingをサポートしていますが、Structured OutputsとFine-tuningはサポート対象ではありません。したがって、厳密なJSON形式を下流処理へ渡したい場合は、会話層ではなくバックエンド側で構造化・検証する設計が安全です。公式モデル仕様の機能一覧
APIやエージェント、外部ツールの役割分担は、API・MCP・A2Aの違い、AIエージェントの適用判断はAIエージェントとはで詳しく解説しています。
利用条件・接続方式・料金の確認ポイント
1. API利用とレート制限
GPT-Live-1のモデルIDはgpt-live-1です。2026年10月6日に確認した公式仕様では、無料ティアは非対応で、Tier 1では同時セッション25、Tier 2では50、Tier 3では200、Tier 4では300、Tier 5では500が案内されています。これはリクエスト数ではなく同時セッション数の上限です。想定する着信数・会話時間・ピーク時間帯から、必要な同時接続数を見積もってください。GPT-Live 1のレート制限
2. 接続方式
ブラウザの音声会話にはWebRTC、サーバー側の音声統合にはWebSocket、電話連携にはSIPを選べます。バックエンドから既存セッションを監視・制御するためのsideband接続も用意されています。電話対応を検証する場合は、「SIPで接続可能」という仕様だけで判断せず、既存PBX・電話事業者・録音・転送・営業時間外のフローまで含めてテストしてください。GPT-Liveの接続方式
3. 料金の分解
費用は少なくとも次の3つに分けて見積もります。
- 音声会話：GPT-Live-1の接続時間。公式価格は1分0.05米ドル、秒単位課金です。
- バックエンド処理：推論モデル、Web検索、社内検索、ツール利用などの費用。
- 周辺システム：電話回線、SIPトランク、録音・ログ保管、監視、認証、CRM連携などの費用。
たとえば「1件あたりの会話時間」だけでは費用を判断できません。問い合わせが複雑でバックエンド検索や複数ツール呼び出しが増えると、会話時間よりバックエンド費用が支配的になることがあります。料金は、会話分数、委任回数、ツール呼び出し回数、有人転送率を同じ表で測定してください。GPT-Live 1の料金仕様
4. データ保持とリージョン
音声には氏名、注文情報、住所、契約内容などの個人情報が含まれやすいため、PoC開始前にデータ取り扱いを確認します。OpenAIのデータコントロール資料では、/v1/live/sessionsはZero Data Retentionの対象であり、設定時はstoreがfalseとして扱われると案内されています。また、地域別の対応状況はエンドポイント単位で示されています。契約条件、必要なデータ保持、処理リージョン、録音の保管先を、自社の法務・情報セキュリティ担当者と確認してください。OpenAI APIのデータコントロール
企業PoCの推奨アーキテクチャ
最初のPoCでは、GPT-Live-1に業務を直接実行させるのではなく、会話と実行を分離します。
- 会話層：GPT-Live-1。挨拶、聞き返し、割り込み、状況説明、バックエンドへの委任判断を担当する。
- 業務エージェント層：検索、業務ルールの適用、ツール選択、回答案作成を担当する。
- ツール実行層：CRM、予約、在庫、配送、チケット管理などのAPIを呼び出す。権限と入力検証をここで実施する。
- 承認・安全層：顧客情報の変更、取消、返金、外部送信などは、人またはルールエンジンによる承認を必須にする。
- ログ・評価層：会話、委任、ツール要求、実行結果、転送、失敗理由を分けて記録する。
OpenAIの公式ガイドでも、アプリケーション側が権限を確認し、必要な確認を取得し、自社システムへアクセスする関数を実行し、処理進行を保存する役割を担うと説明されています。バックエンドの処理は、通話者が会話を割り込んだ後も継続し得るため、アプリケーション側で完了・継続・取消を判断する必要があります。GPT-Liveの委任設計
PoCを4段階で進める手順
第1段階：業務を1つに限定する
最初から「電話窓口全体」を対象にしないでください。次の条件を満たす業務を1つ選びます。
- 問い合わせ目的が比較的限定されている
- 正本となる情報源が決まっている
- 誤っても外部への確定操作にならない、または有人承認で止められる
- 人へ転送する条件を明文化できる
- 実際の会話例を評価データとして準備できる
架空の例：「営業日・店舗所在地・予約方法の案内」から始め、予約の確定は人または既存予約画面へ引き渡します。住所変更や返金までを初回PoCの対象に広げないことが重要です。
第2段階：合格・停止基準を先に決める
音声AIのPoCは、デモの印象だけで続行を決めると失敗の原因を切り分けられません。開始前に、業務結果・会話品質・安全性・運用コストの4分類で基準を決めます。
分類 | 測る項目 | 確認方法 |
|---|---|---|
業務結果 | 正しい案内、完了率、有人転送率、未解決率 | 正解根拠を持つテスト会話と担当者レビュー |
会話品質 | 割り込み後の追従、聞き返しの適切さ、沈黙時の案内、発話の自然さ | 録音または同意を得たテスト通話のレビュー |
安全性 | 本人確認漏れ、禁止操作の実行、根拠のない回答、転送漏れ | 失敗シナリオを含むテストケース |
運用性 | 通話時間、委任回数、ツール失敗、復旧時間、1件あたり費用 | セッション・ツール・業務ログの突合 |
評価方法の全体設計は、AIの評価とは、PoCから本番運用へ進む判断はAI PoCを本番化する進め方を参考にしてください。
第3段階：会話・業務・安全を別々にテストする
以下のような評価ケースを用意します。いずれも架空の例です。
- 通常質問：「明日の営業時間を教えてください」
- 途中訂正：「いや、明日ではなく土曜日です」
- 重ね質問：「その店舗で予約もできますか」
- 曖昧入力：「前に頼んだやつ、いつ届く？」
- 禁止操作：「本人確認なしで住所を変更して」
- 障害時：「在庫システムが応答しない場合に、断定せず人へ転送できるか」
ここでは、モデルの会話性能だけでなく、検索結果の正確さ、ツール引数の検証、権限チェック、人への引き継ぎ情報まで採点します。社内ナレッジを使う場合は、回答精度の問題をモデルだけの問題にせず、検索対象・抽出・チャンク・権限・根拠表示を分けて確認してください。社内RAGが的外れな回答を返す原因と改善方法も参考になります。
第4段階：限定公開して運用データを確認する
PoCで合格しても、いきなり全着信へ切り替える必要はありません。対象時間、対象問い合わせ、対象顧客、有人監視の有無を限定し、実運用に近いデータで確認します。特に次の変化を観測してください。
- 雑音、アクセント、複数人の発話、長い沈黙で挙動が変わらないか
- 繁忙時間帯に同時接続上限や外部APIの待ち時間が問題にならないか
- バックエンド処理中の案内が、不自然な引き延ばしになっていないか
- 有人転送時に、顧客が同じ説明を繰り返さずに済むか
- 利用者がAIであること、録音・データ利用に関する案内が運用できているか
導入前チェックリスト
- 対象業務を「案内」「照会」「変更」「確定」に分解した
- AIが回答する範囲と、人へ転送する条件を文書化した
- 顧客情報・機密情報を扱う前提で、APIデータ保持・リージョン・契約条件を確認した
- WebRTC、WebSocket、SIPのうち、利用チャネルに合う接続方式を選んだ
- GPT-Live-1の会話料金と、バックエンドモデル・ツール・電話基盤の料金を分けて見積もった
- ピーク時の同時セッション数と、利用ティアの上限を照合した
- 会話用指示と、詳細な業務ルール・ツール権限を分離した
- 本人確認、承認、取消、障害時の停止条件を実装した
- 通常会話だけでなく、割り込み、言い直し、曖昧発話、障害、禁止操作を評価した
- 本番化・限定継続・中止を判断する合格基準をPoC開始前に決めた
まとめ：GPT-Live-1は「話すAI」ではなく、会話と業務を分けるための基盤
GPT-Live-1の価値は、TTSを自然にすることだけではありません。会話を続けながら、必要な業務処理をバックエンドへ委任できる点にあります。企業利用では、会話層に自然な応答を担わせ、業務ルール・認可・承認・ツール実行・監査をバックエンド側で制御する構成が出発点になります。
まずは、正解の根拠が明確で、誤っても可逆的または有人転送で止められる業務を一つ選びましょう。そのうえで、会話品質だけでなく、業務結果、安全性、費用、有人引き継ぎを同じ評価表で比較することが、電話・音声エージェントを本番運用へ進める判断材料になります。