これらの要件は、API またはプロバイダーの認証情報を使ってゲートウェイ経由で接続する場合に適用されます。ChatGPT ワークスペースのリクエストを転送するゲートウェイについては、ゲートウェイ経由での ChatGPT サインインを参照してください。
この接続方式では、ゲートウェイは、エンドポイント、ストリーミング、会話の継続、ツール呼び出し、認証、ルーティング、原因の特定に役立つエラーの各項目について、以下に示す Responses API の動作を維持する必要があります。
ゲートウェイの導入手順はゲートウェイの展開を、開発者のマシンの設定手順は API またはプロバイダーの認証情報の使用を参照してください。
リクエストとエンドポイント
ゲートウェイ用のプロバイダーには wire_api = "responses" を設定します。たとえば、ベース URL が https://gateway.example.com/v1 の場合、ゲートウェイは POST /v1/responses を受け付け、クライアントが使用するリクエストとレスポンスのフィールドを保持する必要があります。Chat Completions や Anthropic Messages のエンドポイントが動作しても、Responses API との互換性は確認できません。
ヘルスチェックやモデル一覧の取得に使うエンドポイントは、運用を補助するためのもので、必須ではありません。これらを使っても、Codex での会話の動作やツールへの対応は確認できません。
ストリーミング
回答全体をバッファリングせず、サーバー送信イベント（SSE）を受信するたびに転送します。正常終了を示す最後の response.completed イベントを含め、イベントの種類とペイロードを保持してください。クライアントがレスポンスの失敗と接続の停滞を区別できるよう、エラーや失敗を示すイベントも転送します。
ゲートウェイに加え、ロードバランサーやリバースプロキシも経由した状態で、ストリームが最後まで届くことを確認してください。テキストの回答が届いても、ストリームの完了を確認できなければ不十分です。
会話の継続
後続のターンで再送される会話の入力を保持してください。ゲートウェイは、次のターンに必要な過去のメッセージ、ツール呼び出し、ツールの実行結果を受け付ける必要があります。
WebSocket または差分転送を有効にする場合は、その方式で previous_response_id が正しく機能することも確認してください。ステートレスな HTTP 接続で Responses API を使用する場合は、入力を再送すれば、この仕組みを使わずに会話を継続できます。
ツール
関数呼び出しの項目と、それぞれに対応する function_call_output 項目を保持してください。呼び出しと結果を対応付ける識別子も必要です。Codex が呼び出しを受け取り、ツールを実行し、その結果を送信して最終回答を受け取るまでの一連の処理が機能する必要があります。
テキストのリクエストが成功しても、この一連の処理が機能するかどうかは確認できません。有効にする予定のモデルとクライアント機能を実際にテストしてください。ゲートウェイがリクエストのフィールドを受け付けても、上流のモデルが対応する機能を実装しているとは限りません。
認証とヘッダー
ゲートウェイは、デプロイ時に選択したクライアント認証方式に対応する必要があります。env_key またはコマンドで取得する Bearer トークンを使用します。カスタムヘッダーで認証情報を送信する場合は env_http_headers を使用します。ヘッダーに含めるシークレットは環境変数で指定し、設定に直接書き込まないでください。設定方法と認証情報ヘルパーの仕様については、カスタムプロバイダーのリファレンスを参照してください。
開発者の認証は、ゲートウェイが上流プロバイダーに対して行う認証とは分けてください。管理者キーと上流プロバイダーの認証情報はゲートウェイで保管します。ルーティングや利用者の特定に必要なヘッダーを保持し、認証情報の有効期限切れ、更新、取り消し時の動作をテストしてください。
モデルのルーティングとメタデータ
Codex に公開する各モデル名へのリクエストは、意図した上流モデルにルーティングされる必要があります。モデルが自分をどのモデルだと説明するかに頼らず、ゲートウェイの記録で実際のルーティング先を確認してください。
デプロイしたバージョンの Codex が認識する名前を使用するか、カスタムエイリアスに対応するカタログを用意してください。モデルの提供状況と移行に関するメタデータも確認してください。どの移行先モデルへのリクエストもゲートウェイを経由する必要があります。組織が管理するエイリアスに移行先がない場合は、カタログ内の該当エントリの upgrade を null に設定します。クライアントはカタログのメタデータに基づいて動作しますが、メタデータによってモデルに機能が追加されたり、ゲートウェイにルートが作成されたりすることはありません。コンテキストの上限、推論オプション、ツールについては、実際に使用する上流モデルとプロバイダーで確認してください。Codex に組み込まれたプロバイダー連携機能によるメタデータの調整は、汎用ゲートウェイ経由の接続には自動で適用されません。
Codex が認識するモデル名
デプロイしたバージョンの Codex が認識するモデル名を、そのままゲートウェイのエイリアスと Codex の model に指定してください。上流プロバイダーがそのモデルに対応し、組織が利用を承認していることも確認します。
codex --version でバージョンを確認し、それに対応する rust-v<version> タグを Codex モデルカタログで選択してください。カスタムビルドの場合はビルド元のコミットを使用し、デスクトップ版の場合は同梱の CLI バージョンに合わせます。各エントリの slug の値を調べると、そのバージョンが認識するモデル名を確認できます。ゲートウェイを経由することでモデルの機能が変わる場合は、モデル名が認識されていても、その違いを反映したカタログメタデータを用意してください。
エラー
クライアントの認証エラー、モデルのルートが見つからない場合、レート制限、上流での障害を区別できるようにしてください。すべての失敗を一律に 500 レスポンスとして返さないでください。トークン、プロバイダーの認証情報、リクエストに含まれる機密情報を開示せずに、どの層で失敗したかを特定できるだけの情報を返します。
データとツールの境界
モデルとの通信は次の経路を通ります。
Codex client -> LLM gateway -> model providerクライアントは開発者の認証情報を使ってゲートウェイの認証を受けます。ゲートウェイは上流プロバイダー用の認証情報を使ってモデルにアクセスします。モデルへのリクエストに含まれるプロンプト、ソースコードの抜粋、ツールの引数や実行結果は、ゲートウェイを通過する可能性があります。これを踏まえ、ログの記録、データの保持、機密情報のマスキング、アクセス、エクスポートに関する制御を設定してください。
Codex による接続がすべてモデルゲートウェイを経由するわけではありません。ローカルコマンドはクライアントの実行環境で実行されます。MCP サーバーやプラグインサービスへの接続、ブラウザやアプリとのやり取り、その他の有効なサービスでは、別のネットワーク経路や認証情報が使われることがあります。モデルプロバイダーを設定しても、これらの利用に必要な権限は付与されず、それぞれのネットワーク制御の代わりにもなりません。これらの境界については、エージェントの承認とセキュリティおよび MCP を参照してください。
互換性検証のチェックリスト
デプロイするクライアント、ゲートウェイ、モデルの組み合わせごとに、以下の項目を検証し、その結果を記録してください。
- Responses API のリクエストとレスポンスのフィールドが保持されること
- SSE が逐次配信され、ストリームの正常終了を確認できること
- 再送した入力を使って後続のターンに進めること
- 選択した転送方式で
previous_response_idを使用する場合は、その動作 - 関数呼び出し、対応する実行結果の送信、最終回答の受信までの動作
- モデルのルーティング先が正しく、メタデータがモデルと一致すること
- 各リクエストの利用者を特定でき、利用者ごとに認証情報を更新・失効できること
- 認証、ルーティング、レート制限、上流での障害をエラーから判別できること
- 診断情報の機密部分がマスキングされ、意図したログ記録ポリシーが適用されること
設定を配布する前に、展開時のテスト手順に従って、これらの検証結果を記録してください。