GPT-Live とは — 全二重が音声AIの設計前提を書き換える

「話し終わるのを待つ」をやめたモデル

2026年7月8日（日本時間7月9日）、OpenAIが GPT-Live を公開しました。 ChatGPTの音声機能を置き換える新世代の音声モデルで、最大の特徴は全二重（full-duplex）——つまり聞きながら同時に話せることです。

文字にすると些細な差に見えます。実際に使うと、体験の質が段違いに変わります。 こちらが考え込んで黙っている間に急かしてこない。長い説明の途中で「ええ」「なるほど」と挟んでくる。 こちらが割り込むと、言い終わるのを待たずに引っ込む。 これまでの音声AIが持っていた「トランシーバー感」が消えます。

そしてこの差は、UIの磨き込みではなくモデルの動作構造そのものの変更から来ています。 本記事では、GPT-Liveが何を変えたのかを「半二重の壁」「2層アーキテクチャ」「API未提供という現実」の3点で整理します。

音声AIモデルの系譜でどこに位置するか

半二重の壁 — なぜ「自然な会話」にならなかったのか

従来の音声AIが不自然だった原因は、レイテンシの大きさだけではありません。「いつ話し始めてよいか」の判定を、会話とは別のコンポーネントに丸投げしていたことにあります。

VADがボトルネックだった

半二重の音声エージェントは、おおむね次の順序で動きます。

1. VAD（Voice Activity Detection）が「無音が◯◯ミリ秒続いた」と判定する
2. ターン終了（End of Turn）と見なして、入力を確定する
3. モデルが応答を生成し始める
4. 音声を再生し切るまで、入力は事実上無視される

ここには構造的な欠陥が2つあります。ひとつは2の判定が音響情報しか見ていないこと。 「えーと……」という間と、文が終わった後の間を区別できないので、 無音しきい値を短くすれば食い気味に割り込み、長くすれば全体がもっさりします。 もうひとつは4で入出力が排他になること。話している間は聞いていないので、相づちも即時の引き下がりも原理的に不可能です。

つまり従来モデルの「不自然さ」は、レイテンシを削れば解ける問題ではなかったわけです。ターンという単位そのものが、会話の実態に合っていなかったのです。

全二重は「毎時刻の判断」に変える

GPT-Liveは、入力ストリームを処理しながら出力ストリームを生成し、毎秒複数回、相互作用の判断を下し続ける設計だとされています。 各時刻でモデルが選ぶのは「次の単語」だけではなく、話す／黙る／相づちを打つ／引っ込むという振る舞いそのものです。

graph TB
  subgraph HD["半二重（従来）"]
    direction LR
    A1["🎤 ユーザー発話"] --> V1["VAD<br/>無音◯◯ms検出"]
    V1 --> T1["ターン確定"]
    T1 --> G1["応答生成"]
    G1 --> S1["🔊 再生<br/>（この間は聞けない）"]
  end
  subgraph FD["全二重（GPT-Live）"]
    direction LR
    A2["🎤 入力ストリーム<br/>（常時）"] --> M2["モデル<br/>毎時刻の判断"]
    M2 --> D1["話す"]
    M2 --> D2["黙る"]
    M2 --> D3["相づち"]
    M2 --> D4["引っ込む"]
    D1 --> S2["🔊 出力ストリーム<br/>（常時）"]
    D3 --> S2
  end

2層アーキテクチャ — 会話を止めずに賢くなる方法

ここで当然の疑問が出ます。毎秒複数回判断するような軽い処理で、難しい質問に答えられるのか？

答えは「その場では答えない」です。GPT-Liveは2層構造を取ります。

発表時点で、バックグラウンドの委譲先は GPT-5.5 です。 推論の強度は Instant（GPT-5.5 Instant） と Medium / High（GPT-5.5 Thinking） から選べます。

sequenceDiagram
  participant U as 👤 ユーザー
  participant L as 対話層<br/>（GPT-Live）
  participant B as 委譲層<br/>（GPT-5.5 Thinking）
  U->>L: 込み入った質問
  L->>B: バックグラウンドで委譲
  L-->>U: 「調べますね、少しかかります」
  U->>L: 「あ、あと条件が一つあって」
  L-->>U: 「はい、それも含めます」
  B-->>L: 推論結果
  L-->>U: 結果を会話に合流させて説明

ここが実務的に効きます。半二重では「重い処理＝長い沈黙」でした。 沈黙が3秒続けばユーザーは接続が切れたと思い、話しかけ、被って壊れる。 全二重なら待ち時間そのものが会話の一部として消化される。 「今調べています」と言いながら、その最中の追加条件も受け付けられます。

モデルとプラン

提供先は ChatGPT の iOS / Android / Web（chatgpt.com）で、グローバルに展開されています。 会話に関連するトピックをビジュアルカードとして画面に出す機能も同時に入りました。 一方で、公開時点ではビデオ・画面共有には未対応（近日対応予定）です。

開発者にとっての現実 — APIはまだ無い

ここが本記事でいちばん実務的な話です。2026年8月5日時点で、GPT-LiveのAPIは提供されていません。OpenAI Developersは「GPT-Live-1 と GPT-Live-1 mini を近日APIに提供する」と告知し、 通知登録フォームを用意しているだけの状態です。

したがって「GPT-Liveで音声エージェントを作る」という計画は、 今日の時点では着手できません。 一方で、全二重を前提とした体験設計を今から進めておく価値は十分あります。 API化された瞬間に効くのは、モデル差し替えのコードではなく会話設計側の蓄積だからです。

Realtime APIで全二重に寄せる

Realtime APIは構造的には半二重ですが、ターン検出を音響VADからsemantic VAD（意味を見てターン終了を判定する方式）に切り替え、 割り込み挙動を明示的に設定すると、体感はかなり近づきます。

// Realtime API: semantic VAD + 割り込み許可で「食い気味／もっさり」を減らす
const r = await fetch('https://api.openai.com/v1/realtime/client_secrets', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    session: {
      type: 'realtime',
      model: 'gpt-realtime',
      audio: {
        input: {
          // 音響的な無音しきい値ではなく「意味的に話し終わったか」で判定する
          turn_detection: {
            type: 'semantic_vad',
            eagerness: 'medium',      // low: 待つ / high: 食い気味
            interrupt_response: true, // 生成中でもユーザー発話で中断する
            create_response: true,
          },
          // 環境ノイズでVADが誤発火するのを抑える
          noise_reduction: { type: 'near_field' },
        },
      },
    },
  }),
});

そのうえで、「重い処理は別モデルに投げ、投げている間も喋り続ける」という 委譲層の考え方をアプリ側で実装します。 GPT-Liveの2層構造は、要するにこれをモデル内部でやっているだけなので、 アプリ層で真似ても効果は出ます。

// 委譲パターンをアプリ層で実装する（擬似コード）
// ポイント: 重い処理を await で待たず、先に「つなぎの発話」を返す
async function onToolCall(call: ToolCall, session: RealtimeSession) {
  if (isHeavy(call)) {
    // 1. 会話を止めない。先に相手へ状況を返す
    session.say('少し調べますね。' + estimateWait(call));

    // 2. 重い推論は投げっぱなしにする（await しない）
    runReasoning(call).then((result) => {
      // 3. 終わったら会話に合流させる
      session.injectContext(result);
      session.say(summarize(result));
    });

    // 4. ツール結果は即座に「受理」だけ返す
    return { status: 'in_progress' };
  }
  return await runFast(call);
}

評価指標も書き換わる

全二重に移ると、これまで音声AIの品質を語るときの主指標だった「発話終了から最初の音声が出るまでの時間」が意味を失います。 そもそも発話終了を待っていないので、測る対象が消えるのです。

自前で音声エージェントを評価しているなら、ここは早めに手を入れる価値があります。TTFAだけを最適化していると、全二重時代には無意味な数字を追うことになります。

冷静な評価

興奮を割り引いておくべき点も挙げます。

• APIが無い: プロダクトに組み込む計画は立てられません。「soon」の粒度は数週間とも言われますが、コミットではありません。
• 数値が無い: 公式レイテンシもベンチマーク表も未公開です。「体験が良い」ことと「測れて再現できる」ことは別です。
• マルチモーダルは未完: ビデオ・画面共有が未対応の段階で、「目も耳もあるアシスタント」には届いていません。
• 全二重が常に正解ではない: 書き起こし、字幕、同時通訳、あるいはテキスト応答を保持したいチャットUIでは、従来のパイプラインや専用モデルの方が扱いやすいままです。

まとめ

GPT-Liveの本質は「速くなった音声AI」ではありません。会話をターンの列として扱う前提を捨てたことです。 ターンという関門が消えた結果、相づち・沈黙の尊重・自然な割り込みという、 レイテンシ削減では届かなかった領域が扱えるようになりました。

そして、重い推論をバックグラウンドのGPT-5.5に委譲する2層構造は、 「速さと賢さのトレードオフ」を層の分離で解いた設計です。 この考え方はモデルの外——自分たちのアプリケーション層でも再現できます。

APIが来るまで待つ理由はありません。全二重を前提にした会話設計と評価指標に、 今のうちに寄せておくのが最も筋の良い準備です。