OpenAI「GPT-Live」の全二重音声 — 3段パイプラインのどこが置き換わるか

聞きながら同時に話す。GPT-Liveの全二重アーキテクチャは、音声認識→LLM→音声合成という3段パイプラインが前提にしてきた「相手の発話が終わってから処理を始める」という順番そのものを崩す。2026年7月8日、OpenAIがChatGPTアプリの音声モードとして公開したこのモデルは、音声アプリを組む側の設計図を書き換える。

何が起きたのか
どの層が置き換わるのか
難しい質問は裏に投げる
置き換えられる側を、手元で測った
開発者としての実践ポイント
よくある疑問
まとめ
参考

何が起きたのか

OpenAIの発表によれば、GPT-Liveは「聞くこと」と「話すこと」を同時に行うフルデュプレックス（全二重）の音声モデルだ。従来のAdvanced Voice Modeはトランシーバーに近い。片方が話し終えるまでもう片方は黙る、ターン制のやり取りだった。GPT-Liveは電話の通話に近い。相手が話している最中に相づちを打ち、割り込み、自分が考えている間は黙る。

公開されたデモでは、”mhmm” や “yeah” といった短い相づちを会話の途中で挟む挙動が目立つ。Xでは相づちのデモに「会話している感が一線を越えた」という驚きの声が多いらしい。筆者が触った範囲でも、返答の前に一拍おく「間」が入るだけで、機械と話している感覚がかなり薄れる。

提供は2形態。有料プラン（Go / Plus / Pro）の既定となる GPT-Live-1 と、無料枠で使える GPT-Live-1 mini。iOS / Android / ChatGPT.com でグローバル展開されている。ただし開発者向けの公開APIはlaunch時点で存在しない。後日、サインアップフォーム経由でAPI提供が予定されているとされる。今はプログラムから呼べず、ChatGPTアプリの音声モードで試すだけだ。

どの層が置き換わるのか

音声アプリを作った経験があるなら、頭の中に3つのプロセスが直列に並んだ図があるはずだ。マイク入力を貯めて、無音を検知して発話の終わりを判定し、音声認識で文字に起こし、LLMに投げ、返ってきたテキストを音声合成で読み上げる。筆者が以前ローカルのWhisperで文字起こしアプリを組んだときも、この「無音を待つ」ステップが体感のレスポンスを決めていた。

# 従来のターン制パイプライン（3プロセスが直列）
audio = mic.record_until_silence()   # 発話の終わりを待つ
text  = whisper.transcribe(audio)    # 音声認識（ASR）
reply = llm.chat(text)               # 応答生成（LLM）
speaker.play(tts.synthesize(reply))  # 音声合成（TTS）

このコードの1行目に、ターン制の限界が詰まっている。record_until_silence() は相手が黙るまで次に進めない。相づちも割り込みも構造上入れられない。全二重モデルはこの3段を1つのモデルに畳み込む。音声を入力しながら音声を出力する双方向のストリームが常時流れ、無音待ちのステップが消える。

4段のどこが消えるかを分けて見ると、変化の中身がはっきりする。無音検知（VAD）は発話境界の判定を丸ごとモデルへ渡すので、無音待ちの数百ミリ秒が要らなくなる。音声認識（ASR）と音声合成（TTS）は別プロセスとして呼ぶ手間が消え、テキストを経由しない音声から音声への変換に畳まれる。LLMの応答生成だけは残り、重い部分が裏のフロンティアモデルへ抜ける。筆者がWhisperで組んだアプリでは、録音を止める判定を甘くすると語尾が切れ、厳しくすると沈黙が伸びた。この綱引きがまるごと無くなるのが全二重の効き目だ。

ターン制で一番やっかいなのが割り込み（barge-in）の処理だ。合成音声を再生している最中にユーザーが話し始めたら、再生を止め、認識をやり直し、状態をリセットする分岐を自前で書く必要がある。この分岐がバグの温床になりやすい。全二重では入出力が同時に走るので、割り込みがモデルの通常動作として吸収される。ここが実装者にとって一番大きい変化だ。

擬似コードで書くと、割り込みを扱う自前実装は状態機械になる。話している状態と聞いている状態を持ち、マイクのフレームごとに切り替える。

# ターン制で割り込みを扱う自前実装（分岐がバグの温床）
state = "speaking"
while stream.active():
    frame = mic.read_frame()
    if state == "speaking" and vad.is_speech(frame):
        speaker.stop()          # 再生を止める
        asr.reset()             # 認識バッファを捨てる
        pending_reply = None    # 生成中の応答を破棄
        state = "listening"     # 状態を巻き戻す
    elif state == "listening" and vad.is_silence(frame):
        reply = llm.chat(asr.flush())
        speaker.play(tts.synthesize(reply))
        state = "speaking"

この十数行に、実際は無数の分岐が隠れる。再生を止めた瞬間、バッファに残った合成音声をどう捨てるか。割り込みが数フレームのノイズだったとき状態を戻すか。委譲中の応答を破棄したら裏の処理をどうキャンセルするか。全二重モデルはこの状態管理をモデル内部へ吸い込むので、実装者のコードから状態機械そのものが消える。

観点	ターン制3段パイプライン	全二重モデル
発話終了の検知	無音検知で明示的に判定	モデルが常時聞き続ける
相づち	構造上入れられない	会話の途中で挟む
割り込み	再生停止と再認識を自前で分岐	通常動作として吸収
置き換わる層	ASR / LLM / TTS が別プロセス	1モデルに畳み込み

難しい質問は裏に投げる

全二重モデルだけで難しい推論まで抱えると、応答は速いが賢さが足りなくなる。GPT-Liveはここを分業で解いている。OpenAIの発表によれば、複雑な質問は背後のフロンティアモデルへ委譲し、launch時点では GPT-5.5 をバックグラウンドで使う。委譲している最中も、前面のモデルは黙り込まず話し続ける。

この設計は、開発者から見ると2階建てだ。1階が会話のテンポと相づちを担う軽い音声モデル、2階が重い推論を担うフロンティアモデル。ユーザーが体感する「速さ」と「賢さ」を別レイヤーに分けている。裏で重い処理が走る間、表のモデルが「うーん、そうですね」と時間を稼ぐ構図を想像すると分かりやすい。

「考えている間は黙る」という挙動も、この分業から見ると意味が変わる。裏のGPT-5.5が答えを組み立てている数百ミリ秒、表のモデルは無理に喋らず間を作る。人間が難しい質問に「えーと」と詰まるあの間が、UXの部品として設計に組み込まれている。音声アシスタントを触っていて一番「作り物っぽい」と感じるのは、返答が速すぎて機械的なときだ。あえて黙る設計は、その違和感を消しにいっている。

この間つなぎがどれだけ時間を稼げるかは、裏のGPT-5.5が答えを組む時間で決まる。数百ミリ秒で返る質問なら短い相づち一つで足りる。数秒かかる質問だと間が持たず、沈黙が露呈する。自作で真似るなら、この「間つなぎで隠せる上限」を実機で測っておかないと、重い質問のたびに会話が固まる。

音声アプリを自前で組むときも、この分業は真似できる考え方だ。応答の即時性と回答の質は、同じモデルに背負わせず別プロセスに分けたほうが破綻しにくい。

2階建てを自作で真似るなら、境界の置き方が設計の勘所になる。1階の軽い音声モデルには相づちと「考え中」の間つなぎだけを持たせ、判断を伴う生成は載せない。2階へ投げる条件は質問の長さや語彙で切らず、即答できるかどうかで分ける。委譲した瞬間に1階が黙ると不自然になるので、2階の返答が届くまで1階が短い相づちで場を持たせる非同期の受け渡しにしておく。裏の処理を途中で止める口を最初から用意しておけば、ユーザーが話題を変えたときも破綻しない。

置き換えられる側を、手元で測った

GPT-Live そのものは手元で動かせない。置き換えられる側の3段パイプラインなら、筆者の環境に実物がある。自作の MCP サーバ（faster-whisper large-v3・GPU）で1段目を測った。

素材は自作TTSで生成した日本語の音声2本。同じプロセスで3回続けて投げている。

実行	音声の長さ	文字起こしに要した時間	結果
1回目（モデルロード込み）	4.6秒	4.0秒	諦めたら、そこで試合終了ですよ。
2回目	2.1秒	1.0秒	真実はいつも一つ
3回目（1回目と同じ素材）温まった後	4.6秒	1.0秒	諦めたら、そこで試合終了ですよ。

温まった状態なら、4.6秒の発話を1.0秒で文字に落とせる。プロセスを立て直した直後は別で、別の測定ではモデルのロードに引きずられて同じ素材に30.2秒かかった。

この1.0秒が、3段パイプラインの1段目だけの値になる。ここへ推論と音声合成が乗る。発話が終わってから返答が鳴り始めるまでの間は、少なくともこの積み上げになる。

全二重が変えるのはここだ。発話が終わるのを待ってから1段目を始める構造そのものが無くなる。狙いは1.0秒を待たずに済む構造へ移すことで、1段目を速くする方向とは別のレバーになる。

手元のパイプラインを持っている人が測るなら、段ごとに秒を出しておきたい。どの段が支配的かで、乗り換える価値が変わる。筆者の場合は1段目が1.0秒で、ここは律速ではなかった。

未検証: GPT-Live は API を持っていないので、全二重側の実測はしていない。上の数字は置き換えられる側だけの値になる。

開発者としての実践ポイント

今すぐAPIから呼ぶ設計を前提にしない。公開APIはlaunch時点で無く、当面はChatGPTアプリの音声モードで挙動を確認する段階だ。
自前の音声パイプラインを持っているなら、record_until_silence() 相当の「無音待ち」がレスポンスの上限を決めている点を測っておく。全二重に置き換わったとき何が消えるかが見える。
即時応答と重い推論を1つのモデルに載せず、テンポ担当と推論担当の2階建てで分ける。GPT-Liveの委譲構造がそのまま参考になる。
無料の GPT-Live-1 mini で会話の質感を、有料の GPT-Live-1 で賢さの差を、それぞれ実機で触って比較しておく。無料枠でも相づちや間の取り方は確認できるので、まず mini から始めれば費用ゼロで設計判断の材料が集まる。

従来型パイプラインの実例として、ローカルWhisperで作る文字起こしアプリを組んでおくと、全二重で何が省かれるのかを自分の手で比べられる。