OpenAI GPT-Live-1 と GPT-6 Astra 公開後、開発者はどう使うか？リアルタイム音声、AI Agent、API 実践

一言で言うと：同じ週に二つの名前が着地し、多くは「また一つ強い ChatGPT」と見る——開発者が本当に詰まるのはモデル名ではなく、音声層、推論層、本機の実行面を一つに結んでよいかだ。 以下ではリアルタイム音声、Agent バックエンド、API の三本に分け、つなぎ方のあと請求と隔離を見る。

先に二つを分ける：話すモデルと仕事をするモデル

2026 年 9 月、OpenAI は積木を連続で出した。3 日から GPT-6 Astra の配布が始まり、10 日に GPT-Live-1 が API に入った。以前の記事は「いつ来るか」を扱い、Astra の安全懸念 は「入れたあと爆風半径がどれだけ広がるか」を扱う。本記事は第三の問い：もう来た。開発者はどう繋ぐか。

公式は役割をはっきり切っている。GPT-Live-1 は全二重の音声フロントエンド：聞く、話す、割り込みを処理し、いつ仕事をバックエンドへ渡すかを決める。Astra（または Terra / Luna）が推論、資料検索、ツール呼び出しの層だ。Realtime API は音声・推論・ツールを一つのモデルに載せた。GPT-Live は会話とタスクを分け、バックエンドが動いているあいだもセッションは続く。

GPT-Live-1：リアルタイム音声層のつなぎ方

GPT-Live-1 は先に ChatGPT に現れ、9 月 10 日に API へ入った。同時に聞いて話せる。公式評価の Full Duplex Bench では GPT-Realtime-2.1 より約 30 ポイント高い。Astra（中程度の推論）と組んだとき、端から端までの音声 Agent を測る Tau3 で首位になった。Speak の初期評価では、学習者が割り込まれる回数が古いターン制より約 80% 減ったという。

開発者が本当に選ぶのは接続の仕方であり、「より上手に話す Chat Completions」を探すことではない。

• WebRTC：ブラウザ音声。マイクとスピーカーはメディアトラック、JSON イベントはデータチャネル。ブラウザは SDP だけ出し、プロジェクトキーはサーバーに置く。
• WebSocket：サーバー側の音声統合。一本の接続に音声と制御イベントを載せる。
• 電話 / SIP：既存の通話を取り込む。LiveKit、Twilio、Telnyx、Daily/Pipecat があるなら公式パートナー経由。

レート制限は同時セッションであり、トークンではない。Free は使えない。Tier 1 は 25 本、Tier 5 は 500 本。音声層は 1 分 0.05 ドル、秒単位で、分へ切り上げない。知識カットオフは 2025 年 7 月 31 日。いまは画像を受けず、Structured Outputs も微調整もない。

セッションを作ったら session.started でチャネルが揃ったことを確認してから口を開く。傍路監視や指示のホット更新が要るときは、サーバー側の sideband WebSocket を足す。音声は主接続のまま。書き起こし、キーワードバイアス、ターン検出は内蔵なので、STT を重ねなくてよい。

GPT-6 Astra：Agent バックエンドのつなぎ方

Astra はテキスト推論の旗艦で、モデル ID は gpt-6-astra。Responses / Chat Completions / Bedrock を使い、Live セッションそのものには乗らない。企業 ChatGPT ワークスペースは既定オフで、管理者が入れる。API は入力 100 万トークンあたり約 10 ドル、出力 100 万あたり約 50 ドル。条件を満たす顧客は Zero Data Retention を使える。

音声製品に載せるなら、Astra は委譲の設定にだけ出す。同じ会話を奪う並行のチャット補完を立てない。公式は二通りの委譲を示している。

セッション作成時にモードを決める。途中で変えると immutable_field_update になり、新しく開くしかない。Responses 委譲は function と web_search、それにバックエンドモデル側の reasoning / text / max_output_tokens を使える。カスタム関数は自分のサーバーが実行し、権限と確認もそこで行う。さらに低い遅延が要るなら、プロジェクトで Fast が開いていれば delegation.responses.service_tier を priority にする。

Astra の安全境界は「音声に載せた」だけでは緩まない。公開版は高度な攻撃タスクを拒む。企業ワークスペースは既定オフ。高権限 Agent を日常のマシンへ掛ける代償は、Astra の安全懸念 と 権限を渡す判断 を見てほしい。

三つの実装組み合わせ：先に場面、あとでモデル

公式自身も書いている。シフト調整や照会は安いバックエンド、複雑な苦情は Astra へ上げる。「音声製品 = 最初から最後まで Astra」を既定にしない。

組み合わせ C になって初めて、AI Agent に必要なインフラの層 に沿って身元、ディスク、ログを分ける。24 時間常駐のコーディング Agent も音声セッションと .env を共有しない。24 時間 AI Coding Agent のデプロイ を見てほしい。

API 実践：WebRTC + Responses 委譲

最小の使える経路はこうだ。ブラウザがマイクを取る → HTTPS サーバーがプロジェクトキーで Live セッションを作り SDP を交換する → メディアトラックが音を出す → データチャネルが書き起こしと委譲イベントを受ける。下は公式 Session 設定の Astra 版だ。文書の例は既定で gpt-5.6-terra と書いてあり、旗艦の音声 Agent なら Astra に替える。

/** @type {import("openai/resources/live/live").SessionConfig} */
export const session = {
  model: "gpt-live-1",
  instructions: "あなたはカスタマーサポートの音声アシスタントです。挨拶、確認、進捗は自分で話す。注文照会、予約変更、返金は必ずバックエンドへ委譲する。",
  delegation: {
    type: "responses",
    responses: {
      model: "gpt-6-astra",
      instructions: "認可済みの注文照会と日程変更だけを扱う。書き込み操作は先に関数を通し、アプリの確認後に続ける。",
      tools: [
        { type: "web_search" },
        {
          type: "function",
          name: "lookup_order",
          description: "注文番号で読み取り専用の状態を照会する",
          parameters: {
            type: "object",
            properties: { order_id: { type: "string" } },
            required: ["order_id"]
          }
        }
      ],
      tool_choice: "auto",
      parallel_tool_calls: true
    }
  }
};

サーバー側はプロジェクトキーで POST /v1/live/sessions を呼び、ブラウザの SDP offer を answer に替え、RTCPeerConnection へ返す。キーも Session 設定もこのサーバーから出さない。関数を本当に実行するときは、入れ子の response.output_item.done から call_id / name / arguments を読み、認可した操作のあと結果を Responses item として足し戻す。端末スナップショットの response.output: [] は、待ちの関数呼び出しがないことにはならない。

# 擬似コード：信頼できるサーバーで SDP を交換する。OPENAI_API_KEY をブラウザへ渡さない
import os, requests

def create_live_session(sdp_offer: str, session_config: dict) -> str:
    r = requests.post(
        "https://api.openai.com/v1/live/sessions",
        headers={
            "Authorization": f"Bearer {os.environ['OPENAI_API_KEY']}",
            "Content-Type": "application/sdp",
        },
        params={"model": "gpt-live-1"},
        data=sdp_offer,
        timeout=20,
    )
    r.raise_for_status()
    return r.text  # SDP answer → ブラウザの setRemoteDescription へ返す

セッション中は session.update でバックエンドモデル、指示、ツールをホット更新でき、再接続は要らない。delegation を null にすると Client モードへ切り、すでに走っている Responses セッションを戻せない。傍路の見守りは session.instructions.append（delegation_id: null）で会話を引き戻せる。これは Live モデルだけに効き、Astra の指示は変えず、走っている委譲も止めない。

請求、レート制限、隔離

音声と推論は二枚の請求だ。トークン単価の比べ方は トークン料金の対照 を見てほしい。ここでは Live と Astra を結んだときに漏れやすい分だけ記す。

隔離の一覧は安全記事と同じだが、音声製品には「セッションが常駐する」が一本足される。

1. キーはサーバーだけ。 ブラウザは SDP を送り、音声を再生する。
2. 書き込みツールは既定で人の確認。 照会は自動でよい。返金、在庫変更、コード投入は自分の確認を通す。
3. Agent の身元と日常デスクトップを分ける。 高権限関数、Git トークン、本番 .env は独立した Cloud Mac ノードへ。主力マシンは記録の審査とマージだけ。
4. ログは三文に答えられること。 どの Live セッションか、どの委譲か、何が変わったか。答えられなければ監査はない。
5. 企業ワークスペースは既定オフのまま。 要るとき管理者が入れる。個人サブスクでも Astra を本番リポジトリへ一度に繋がない。

正しい読み方：GPT-Live-1 が下げるのは話すコストであり、爆風半径ではない。よくある誤読は「音声層が高いから最初から最後まで Astra、一回の委譲で済ませる」。より安定した手は、組み合わせ B で量、組み合わせ C で難所、そしてノート PC で書き込み操作を走らせないことだ。

よくある質問

GPT-Live-1 と GPT-6 Astra は同じモデルか？
違う。Live-1 は全二重の音声フロントエンド。Astra はテキスト推論とツールのバックエンド。公式は二つを組ませることを勧めており、一つのモデルに両方をやらせない。

Realtime API からすぐ GPT-Live-1 へ移すべきか？
ブラウザと新しい音声製品は先に移す。すでに安定した Realtime パイプラインは、遅延と割り込みを対照してからでよい。委譲モードの変更は新しいセッションが必要で、ホットスワップはできない。

音声セッションに Astra のトークン請求が一緒に入るか？
一つの請求に混ざらない。音声層は秒単位で、約 1 分 0.05 ドル。Astra とツールはそれぞれの Responses 単価で別計算。

API キーをフロントのページに直接置いてよいか？
いけない。プロジェクトキーは信頼できるサーバーに置く。ブラウザは SDP だけ送り、サーバーが POST /v1/live/sessions でアンサーを取り替える。