Codex リアルタイム音声

接続前の準備§

1. リアルタイム音声に対応した Codex クライアントを用意し、マイクへのアクセスを許可します。音声の入口や実験的な設定の対応状況は、クライアントのバージョンによって異なります。
2. GPT-Load で Codex サブスクリプショングループを作成し、OAuth 認証または認証情報のインポートを行います。上流アカウントに実際の音声利用権限が必要です。テキストのリクエストが成功しても、音声の権限があるとは限りません。
3. アクセスキーを作成し、その Codex グループを許可します。プロトコルを絞り込む場合は codex-live（音声）と openai-responses（テキスト）の両方を許可し、モデルも絞り込む場合はクライアントが要求する音声モデルを許可します。

音声モデルをグループのモデル一覧に追加する必要はありません。クライアントが指定したモデルはそのまま上流に渡され、未指定時は gpt-live-1-codex が使われます。通常の OpenAI API キーではなく、Codex サブスクリプションチャネルを利用します。

サブスクリプションアカウントの認証とインポート →

音声モードの選択§

「システム設定 → 接続とタイムアウト → リアルタイム音声」で既定のモードを設定します。Codex グループの「詳細設定／実行時パラメータ」で継承または上書きでき、グループごとに異なるモードを使用できます。

どちらの有効モードでも、GPT-Load が認証、アカウント選択、セッション作成、制御 WebSocket の中継を行います。上流アカウントのトークンはクライアントに渡しません。違いはメディア経路のみで、直接接続ではサーバーの送信プロキシがクライアントの音声通信を代行することはできません。

Codex クライアントの設定§

GPT-Load のホームでアクセスキーと Codex を選び、生成された設定をコピーする方法を推奨します。以下は完全な設定例です。アドレスをクライアントから到達できるゲートウェイのアドレスに、YOUR_TEXT_MODEL を公開済みのテキストモデルに置き換えてください。

model = "YOUR_TEXT_MODEL"
model_provider = "gpt-load"

experimental_realtime_webrtc_call_base_url = "http://127.0.0.1:3001/v1"
experimental_realtime_ws_base_url = "http://127.0.0.1:3001/v1"

[model_providers.gpt-load]
name = "OpenAI"
base_url = "http://127.0.0.1:3001/v1"
model_catalog_url = "http://127.0.0.1:3001/v1/models"
env_key = "GPT_LOAD_API_KEY"
wire_api = "responses"
supports_websockets = true

[features]
api_key_model_discovery = true
realtime_conversation = true

export GPT_LOAD_API_KEY="YOUR_ACCESS_KEY"
codex

既存の設定に統合する際は、同名の TOML セクションを重複させないでください。2 つの experimental_realtime_* はトップレベルの設定なので、すべての [section] より前に置きます。リモート環境では HTTPS を使い、クライアントプロセスに GPT_LOAD_API_KEY を引き継がせてください。

これらは実験的な音声設定です。現在の管理画面が生成する内容を基準にしてください。保存後にクライアントを再起動し、音声の入口からセッションを開始します。supports_websockets はテキストの Responses WebSocket を制御する設定で、音声の有効化とは別です。音声には専用の接続設定と realtime_conversation も必要です。

Codex 公式設定リファレンス →

ゲートウェイ中継のデプロイ§

この節は「ゲートウェイ中継」を選ぶ場合だけ必要です。すべての中継グループがサーバーのメディアアドレスと UDP 範囲を共有するため、グループごとにポートを開く必要はありません。

1. 実行するバージョンと同じ docker-compose.voice.yml をダウンロードし、メインの docker-compose.yml と同じ場所に置きます。
2. クライアントから到達できるサーバーのメディア IP を .env に設定します。ドメイン名、コンテナ内部のアドレス、例示用 IP は使わないでください。

CODEX_LIVE_PUBLIC_IP=YOUR_PUBLIC_IP
CODEX_LIVE_UDP_PORT_MIN=50000
CODEX_LIVE_UDP_PORT_MAX=50127

音声 Compose 設定を見る（ダウンロード時に使用バージョンを選択）→

3. クラウドのセキュリティグループ、OS のファイアウォール、NAT マッピングで同じ UDP 範囲を許可し、2 つの Compose ファイルを使って起動します。

docker compose -f docker-compose.yml -f docker-compose.voice.yml up -d

4. システム設定または Codex グループ設定で「ゲートウェイ中継」を選び、保存後に新しい音声セッションを開始します。今後コンテナを更新するときも、両方の Compose ファイルを指定してください。

ネイティブプロセスでも同じ環境変数を使い、同じ UDP ポートを許可します。メディアの環境変数を変更したら再起動が必要です。複雑な NAT 環境では CODEX_LIVE_ICE_SERVERS で STUN/TURN を設定できます。形式は環境変数リファレンスを参照してください。

HTTP リバースプロキシは接続の確立と制御接続を担当するため、WebSocket Upgrade の転送が必要です。メディア UDP は自動的には中継しません。既存の TLS とアクセス制御を維持したまま、Nginx のプロキシ location 内に以下を追加できます。

proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;
proxy_read_timeout 3600s;

音声の環境変数 →

セッションと費用§

セッション作成には全体の重み付きスケジューリングと再試行予算を使用します。明確な 403／429 の拒否では候補を切り替えられ、401 では認証情報を更新して再試行できます。結果が不明なタイムアウトや接続成功後の切断では、別アカウントで通話を自動再作成しません。音声の受付失敗で、そのアカウントのテキスト機能がブラックリスト入りすることはありません。

確立後はアカウントとメディア経路が固定されます。制御 WebSocket への接続が必要で、直接接続の作成後 30 秒以内に接続しない場合、または制御切断後 30 秒以内に再接続しない場合はセッションを終了処理します。アクセスキーの変更・無効化や権限の取り消しも、対象の通話を終了させます。

通話終了時に 1 件のログを記録します。現在、音声費用は見積もらず、アクセスキーの音声コストにも計上しませんが、既存のコスト上限は新しい通話の受付に影響します。未価格設定であることは、上流の利用が無料という意味ではありません。

上流での切断に失敗すると 502 を返します。サーバーが切断を再試行する間、セッションは終了待ちとなり同時接続枠を占有します。この間、制御接続を再接続することはできません。ログの「未完了」は、上流で停止したことの確認ではありません。

接続確認とトラブルシューティング§

まずテキストのリクエストを確認し、短い音声通話で双方向の音声を確認します。自分で切断した後、リクエストログを確認してください。モデル一覧の取得や接続作成 API の成功だけでは、メディア経路が通じているとは判断できません。