GPT-Live-1 APIの断線復旧はどう行う？2026 音声Agent実践

公式Live APIガイドがブラウザー側の前提として示しているのは、マイク利用に必要なHTTPSまたはlocalhostです。つまり、接続条件を満たしていても、GPT-Live-1 APIの断線復旧はWebSocketを張り直し、音声を全部再送するだけでは完了しません。音声ストリーム、会話状態、未完了のツール呼び出し、ユーザーに表示した進捗を分けて保存し、再接続後に状態を確認してから処理を再開してください。

すでにGPT-Live-1の基本的な音声ストリーミングを組み込んだものの、回線切り替え後に会話を続けられない開発者向けの記事です。音声Agentを業務システムや通知処理につなぐプロダクトエンジニア、クラウド上で長時間稼働させる小規模チームにも適しています。

まず、復旧対象を4つの状態に分けます

「音声が聞こえない」という症状だけでは、どこまで復旧できたのか判断できません。少なくとも次の状態を別々に監視します。

• 音声層：マイク入力、音声チャンク、再生バッファー、送信順序
• 会話層：Liveセッション、会話履歴、システム指示、要約
• ツール層：モデルが要求した処理、業務システムの実行結果、冪等キー
• 画面層：ユーザーに見せた発話、処理中表示、失敗や保留の案内

たとえば、Wi-Fiからモバイル回線へ切り替えた後に音声が戻っても、モデル側のセッションが失われていれば、ユーザーの意図を保持した会話とはいえません。逆に会話が残っていても、決済や通知の実行結果を失えば、画面だけ復旧した危険な状態になります。

OpenAIのGPT-Live-1公式モデル情報はモデルの位置付けを確認する資料です。一方、断線後の復元動作や復旧時間まで保証する資料ではありません。そこは自分の構成で故障注入を行い、復旧条件を決める必要があります。

注意：音声再生の再開を「復旧成功」と記録しないでください。会話ID、最後に確定したイベント、ツール処理の状態が確認できるまで、UIには「接続中」または「確認中」と表示します。

GPT-Live-1 APIの断線復旧で、音声だけを再送してはいけない理由

音声チャンクには連番と確認境界を持たせる

クライアント側では、入力音声を送るたびに次の情報をローカルまたは自分のバックエンドへ記録します。

• セッションID
• 音声チャンクの連番
• 収録開始時刻と終了時刻
• サーバーが受領済みと確認した境界
• まだ確認されていない送信待ちデータ

再接続時に再送できるのは、受領確認前の短い範囲だけです。すでにモデルが処理した音声を無条件で再送すると、同じ発話が二重に解釈される可能性があります。発話の途中で切れた音声は、ユーザーに「もう一度話してください」と求めて破棄するほうが、誤った注文や操作を防げる場合もあります。

ブラウザー実装では、HTTPSまたはlocalhost、マイク権限、ページのバックグラウンド化、出力デバイスの切り替えを別々に記録します。Live APIの公式ガイドが示すブラウザー要件を満たしていない環境では、再接続ロジック以前に入力が止まるためです。

ブラウザーが切り替わったときの判断

ブラウザーをバックグラウンドに移した後に音声が出ない場合、次の順で切り分けます。

1. マイク権限が維持されているか確認します。
2. AudioContextや再生キューが停止していないか確認します。
3. Liveセッションの接続状態をバックエンドへ問い合わせます。
4. 未確認の音声だけを再送するか、発話を破棄して再入力を求めます。
5. 画面上の会話履歴とモデル側の履歴が一致しているか確認します。

音声デバイスを抜き差ししたケースでは、接続を再開しても再生キューが古い出力先を参照していることがあります。そのため、音声ストリームの再開と出力デバイスの再初期化を同じ成功フラグで扱わないでください。

会話セッションは再作成するのではなく、状態を照合します

Live会話管理ガイドを参照しながら、バックエンドに「現在のセッション」と「ユーザーに見せた会話」を分けて持たせます。保存対象は、会話全体の音声データではなく、再開に必要な最小状態に絞ります。

• 現在のセッション識別子
• 最後に確定した会話イベント
• システム指示のバージョン
• ユーザーの目的を表す短い要約
• 保留中のツール呼び出し
• ユーザーへの未通知結果

再接続したクライアントは、最初に「接続成功」と判定せず、状態照会を行います。セッションが存在し、最後のイベント位置が一致し、保留中の処理が識別できる場合だけ会話を再開します。状態が不明、期限切れ、別クライアントからの重複接続で競合している場合は、新規会話として扱わず、要約を提示してユーザーに確認を求めます。

GPT-Live-1 APIの断線後に会話を続ける設計

復旧メッセージは、クライアントが保持する会話履歴をそのまま再送する方式より、バックエンドが管理する要約と確定イベントを基準にします。これにより、ブラウザーが休眠して古い状態を持っていても、サーバー側の最新状態を優先できます。

Live APIのセッション設計では、会話の状態を扱うための考え方が整理されています。ただし、業務上の完了状態や再実行の可否は、利用する業務システム側で別途定義してください。

ツール呼び出しの重複をどう防ぐか

リアルタイム音声Agentでは、次の2つの中間状態が特に危険です。

• モデルはツールを要求したが、クライアントが要求イベントを受信する前に切断した
• クライアントは結果を受信したが、業務システム側の確定応答を受ける前に切断した

このため、ツール呼び出しごとに、モデルの要求IDとは別に業務処理用の冪等キーを作ります。照会は同じキーで再実行しても問題が起きにくい一方、予約、課金、送信通知、アカウント変更などは、実行済みか不明なら自動再実行しない設計が安全です。

Live delegationの公式資料も、モデルに任せる処理とアプリケーション側で管理する処理を分けて考える材料になります。音声で「送って」と依頼されたことと、実際に通知システムが送信済みであることは、同じ事実ではありません。

経験則：ツール結果が不明な状態で「処理は完了しました」と発話させないでください。「確認できないため保留しています。履歴から再確認できます」と伝え、必要なら担当者へ引き継ぎます。

第1段階：復旧フローを実装する

次の順番で処理すると、音声、会話、業務処理の状態が混ざりにくくなります。

1. 接続断を検知し、音声入力とツールの自動実行を一時停止します。
2. クライアントからセッションID、最後の確定イベント、未確認の音声範囲を送ります。
3. バックエンドがセッション、会話要約、保留中のツール処理を照会します。
4. 再接続先のセッション状態とクライアント側の状態を照合します。
5. 状態が一致した場合だけ、未確認音声の再送または新しい発話の入力を許可します。
6. ツール処理が保留中なら、冪等キーで照会し、実行済み・未実行・不明を確定します。
7. UIへ「会話再開」「処理保留」「再入力が必要」のいずれかを表示します。
8. 状態が復旧できない場合は、新規セッションを作り、要約を読み上げてユーザーの確認を取ります。

GPT-Live-1のプロンプト設計については、公式のLive promptingガイドも確認できます。復旧時にモデルへ渡す指示には、「ツール結果が不明な場合は完了と断定しない」「ユーザーに再確認を求める」といった失敗時の振る舞いを明記します。

故障注入で確認するためのチェックリスト

正常な通話だけでは、断線復旧の品質は判断できません。次の項目を実際の開発環境で確認してください。

• [ ] 音声入力の途中で通信経路を切り替え、未確認チャンクだけが扱われる
• [ ] ブラウザーをバックグラウンドに移し、復帰後にマイク権限と再生キューを確認できる
• [ ] マイクを外し、入力停止を接続断と誤認しない
• [ ] Liveセッションを失わせ、要約からユーザーの意図を復元できる
• [ ] サーバープロセスを再起動し、セッション情報が消えた場合の案内を確認する
• [ ] ツール要求の直後に切断し、処理が二重実行されない
• [ ] ツール結果の受信直後に切断し、確定前の処理を完了扱いしない
• [ ] 通知や高い影響を持つ操作で、人工的な引き継ぎが可能になっている
• [ ] 復旧失敗時に、画面と音声の両方で現在の状態を説明できる
• [ ] ログからセッションID、要求ID、冪等キーを追跡できる

開発環境を長時間動かす場合は、kvmbootのヘルプセンターにある運用情報も確認し、APIキーをブラウザーへ直接埋め込まず、信頼できるサーバー側で管理してください。クラウド上のMac環境を使う場合も、プロセス再起動、ログ保存、資格情報の分離を先に決めると、障害調査時に状態を追いやすくなります。

現在の構成をそのまま使うか、Mac環境へ移すか

ローカルの開発用PCだけで運用すると、ブラウザーを閉じたときにセッション管理プロセスも止まりやすく、回線切り替えと端末スリープの影響を同時に受けます。共有サーバーではマイク権限や音声デバイスの再現が難しく、チーム内で同じ復旧テストを繰り返せないこともあります。

一方、Macをレンタルして開発用の音声Agent環境を分離すれば、ブラウザー操作、ログ収集、サービス再起動、資格情報の隔離を同じ構成で検証しやすくなります。長期の高負荷運用や物理オーディオ機器が必要なケースでは自前環境が適しますが、短期のGPT-Live-1 API開発、断線復旧の検証、デモ用の一時環境なら、kvmbootのMacレンタル環境を使って故障注入から始めるほうが、実機購入より判断を早められます。