ゲートウェイの展開

ゲートウェイ管理者は、モデルのルーティングを設定し、試験導入に参加するユーザー 1 人にアクセスを許可します。開発者に設定を配布する前に、サポート対象のクライアントごとに接続をテストしてください。ゲートウェイの認証には、ゲートウェイ標準の OAuth、API キー、または認証情報ヘルパーを使用します。ゲートウェイ認証と ChatGPT ワークスペースへのサインインを併用する方法は、ゲートウェイ経由での ChatGPT サインインを参照してください。

前提条件

開発者に Codex を展開する前に、次のものがそろっていることを確認してください。

• 配布予定のベース URL と完全に一致する URL で HTTPS リクエストを受け付けるゲートウェイ
• ゲートウェイが保持する上流プロバイダーの認証情報
• 対象の上流モデルに対応付けた、承認済みの Codex 用モデルエイリアス
• テスト済みの認証方式（ゲートウェイ標準の OAuth、スコープを限定したゲートウェイ API キー、または認証情報ヘルパー）
• OAuth の場合は、登録済みのパブリッククライアント、承認済みのテストユーザー、ゲートウェイで OAuth アクセストークンを検証する機能
• API キーまたはヘルパーを使う場合は、シークレットを配布する仕組み、またはテスト済みのヘルパー
• 設定、必要なヘルパー、カタログファイルを配布する手段

ゲートウェイの要件

Codex を接続する前に、使用するゲートウェイ製品が次の要件を満たすことを確認してください。

• POST /v1/responses で Codex からの Responses API リクエストを受け付けます。
• SSE イベントをバッファリングせずにストリーミングし、最後に response.completed を送信します。
• 再送された入力を使って、同じ会話の続きを処理できます。
• previous_response_id を保持するのは、WebSocket または増分転送が有効な場合に限ります。
• 関数呼び出しと、それに対応する function_call_output 項目を保持します。
• Codex 用の各モデルエイリアスを、対応する上流モデルにルーティングします。
• ユーザーを個別に認証し、エラー時には原因を特定できる情報を返します。

ヘルスチェック用エンドポイントがあるだけでは、ゲートウェイが要件を満たすことは確認できません。/v1/models や Chat Completions のレスポンスが返る場合や、プレーンテキストの応答が 1 件得られた場合も同様です。詳しい仕様はゲートウェイの互換性要件を参照してください。

ゲートウェイの展開手順

ゲートウェイのデプロイ後、開発者の環境で動作を確認するまでに、次の 5 つの手順を順に実施します。

1. モデル名を選び、ルートを検証します。
2. 認証方式を選択します。
3. ゲートウェイ経由で Codex をテストします。
4. 設定を配布します。
5. 開発者のマシンで動作を検証します。

モデル名とルートの選定

Codex の model に、ゲートウェイで使用するモデル名を設定します。その名前へのリクエストを承認済みの上流モデルにルーティングするよう、ゲートウェイを設定してください。

カスタムモデル名用のモデルカタログ

ローカルカタログを作成する場合は、models.json の例をもとにしてください。

ゲートウェイが Codex の認識できないモデル名を使用する場合は、モデルカタログを用意してください。カタログには、その名前で Codex が使用する指示、推論オプション、コンテキストの上限、利用可能なツール機能を定義します。一致するエントリがない場合、リクエストが目的の上流モデルに届いても、Codex は汎用設定を使用することがあります。

モデルのメタデータを一元的に更新するには、リモートカタログをホストし、model_providers.<id>.model_catalog_url で指定します。ローカルファイルとして配布する場合は model_catalog_json で指定します。ゲートウェイ標準の OAuth のみで認証する場合は、ローカルカタログを使用してください。OAuth だけではリモートカタログの自動検出は有効になりません。両方の設定の詳細は設定リファレンスを参照してください。

クラウドまたはゲートウェイのプロバイダーから、使用する Codex のバージョンと互換性のあるカタログのエンドポイントまたはファイルを入手してください。承認済みの各エイリアスと、対応するモデルのメタデータが含まれていることを確認します。カタログの実装については、ゲートウェイとクラウド向けのモデルカタログの実装を参照してください。

リモートカタログの提供

プロバイダーが提供する HTTPS のカタログエンドポイントを使用します。選択したプロバイダーの config.toml テーブルにエンドポイントの完全な URL を記載して配布してください。

model = "company-coding-model"
model_provider = "enterprise-gateway"
web_search = "disabled"

[model_providers.enterprise-gateway]
name = "Organization Gateway"
base_url = "https://gateway.example.com/v1"
model_catalog_url = "https://gateway.example.com/codex/models"
wire_api = "responses"
env_key = "CODEX_GATEWAY_API_KEY"

Codex のプロセスから CODEX_GATEWAY_API_KEY を参照できるようにしてください。推論リクエストをゲートウェイ経由で送るには、別途 base_url を設定します。省略すると、Codex は現在の認証モードに対応するデフォルトの OpenAI エンドポイントを使用します。

カタログの自動検出には、API キーによる認証、コマンドを使った認証、または Codex バックエンドによる認証が必要です。ゲートウェイ標準の OAuth またはカスタムヘッダーだけでは自動検出は実行されません。

承認済みモデルに変更がある場合は、プロバイダーと調整してカタログを更新してください。クライアントの設定を変更した後は、クライアントを再起動します。

有効な model_catalog_json 設定は、requirements.toml で強制しているものも含めてすべて削除してください。この設定はリモート URL より優先されるため、リモートカタログが取得されなくなります。

ローカルカタログの配布

model_catalog_json を使用すると、起動時にプロバイダーが提供したファイルを読み込めます。ローカルのカスタムカタログは、Codex に同梱されているカタログを置き換えます。

ゲートウェイのエイリアス、カタログの slug、Codex の model をすべて company-coding-model に設定します。配布する Codex 設定の最初の TOML テーブルより前に次の設定を追加し、ファイルの実際の絶対パスを指定してください。

model = "company-coding-model"
model_catalog_json = "/absolute/path/to/gateway-models.json"

Codex は起動時にカタログを読み込むため、カタログを変更した後は CLI またはデスクトップアプリを再起動してください。

モデルルートの検証

モデルごとに実際の Responses リクエストを送り、ゲートウェイの記録と照合してルートを検証します。/v1/models のレスポンスはモデル名の確認には役立ちますが、モデルが必要なリクエストやツールの動作に対応していることまでは確認できません。

モデルのルーティングとツールの利用許可は別々に設定します。MCP 接続、プラグインの配布、それぞれのポリシーは個別に設定してください。

認証方式の選定

ゲートウェイ標準の OAuth

1. PKCE を使う認可コードフローに対応した OAuth パブリッククライアントを登録し、サインインを許可するユーザーまたはグループを承認します。
2. 選択した Cookie またはカスタムヘッダーで渡される発行済みアクセストークンを検証するよう、ゲートウェイを設定します。ユーザーの ID ごとに、承認済みモデル、レート制限、予算を適用してください。
3. ゲートウェイ標準の OAuth の手順に従って、認可 URL、トークン URL、パブリッククライアント ID、スコープ、リソース（指定する場合）、トークンの受け渡し設定、固定のリダイレクトポート（使用する場合）を確認します。対応するループバックリダイレクト URI を ID プロバイダーに登録してください。
4. 展開予定の CLI またはデスクトップアプリで、テストユーザーを使ってブラウザーでのサインイン、トークンの更新、アクセス権の取り消しをテストします。リモートで CLI を使用する場合も含め、ブラウザーからコールバック先に到達できることを確認してください。

ユーザーは個別にサインインします。認証用に配布するのは OAuth 設定のみで、クライアントシークレット、ゲートウェイ API キー、ヘルパーの実行ファイルは配布しません。上流プロバイダーの認証情報はゲートウェイで保持してください。

API キーまたは認証情報ヘルパー

1. 利用状況を開発者別に把握し、アクセス権を個別に取り消せるように、スコープを限定したゲートウェイ認証情報を開発者ごとに 1 つ発行します。
2. 認証情報ごとに、承認済みモデル、レート制限、予算、有効期限、更新期間を設定します。
3. シークレットマネージャーまたはインストール済みの認証情報ヘルパーを通じて認証情報を配布します。上流プロバイダーやゲートウェイ管理者の認証情報は、開発者のマシンに置かないでください。
4. ヘルパーを使う場合は、コマンドを使った認証の仕様に従い、配布前にトークンの取得と更新をテストしてください。
5. 認証情報の更新方法と、サポートが必要な場合の問い合わせ先を開発者に伝えます。

ゲートウェイ経由での Codex のテスト

配布を始める前に、プロバイダーの設定に従い、他のユーザーから分離したテストユーザー 1 人に、配布予定のプロバイダー設定ブロックと認証方式を設定してください。

ゲートウェイがモデルカタログを提供する場合は、Codex と互換性のある models 配列を返すことを確認します。ユーザーの認証情報で OpenAI の推論を利用する場合は、ゲートウェイが必要な ChatGPT ヘッダーを Codex バックエンドに転送することを確認してください。

試験導入で使用するクライアントのバージョン、OS、プロバイダー ID、モデルエイリアス、認証方式を記録します。サポート予定の CLI やデスクトップアプリのそれぞれで、次の項目を確認してください。ゲートウェイ認証のみで利用する方法と、ChatGPT サインインを併用する方法の両方を提供する場合は、それぞれ個別にテストします。

自動承認を有効にしている場合は、使い捨てのテスト用フォルダーで、適用予定のポリシーのもとでレビューが必要になるツール操作を要求します。ゲートウェイがレビューリクエストを処理し、クライアントが承認または却下の判断を反映することを確認してください。承認が不要な読み取り専用のツール呼び出しでは、この処理をテストできません。対応していないワークフローがあれば、試験導入の対象を広げる前に記録してください。

今回の展開で既存ユーザーのプロバイダーを変更する場合は、サポート対象のクライアントごとに、新しい会話と変更前に作成した会話をテストします。既存の会話を表示できるか、続けられるか、分岐できるかをそれぞれ記録し、実行できない操作についてはユーザーに復旧手順を案内してください。デフォルトのプロバイダーを変更すれば会話履歴も移行されるとは限りません。

すべての確認項目に合格したら、開発者に共有する設定値と手順を用意します。

設定の配布

すべてのマシンで同じ接続経路を使用するために、ゲートウェイのベース URL、プロバイダー ID、承認済みのモデルエイリアス、認証設定を配布します。

配布する設定

ゲートウェイ標準の OAuth を使う場合は、プロバイダーテーブルと [model_providers.<id>.gateway_oauth] テーブルを配布します。接続ガイドに記載されたテーブルに、先ほど確認した登録情報を設定してください。ゲートウェイの認証に OAuth のみを使う場合は、requires_openai_auth = false のままにし、env_key、experimental_bearer_token、コマンドを使った認証用の auth テーブルは省略してください。

認証情報ヘルパーを使う場合は、選択した設定レイヤーを通じて次の config.toml ブロックを配布します。使用するバージョンの Codex が認識できるモデルを指定するか、前述の手順で対応するカタログを用意してください。トークンリゾルバーは、コマンドのパスとして指定した場所にインストールします。

model = "gpt-6-sol"
model_provider = "enterprise-gateway"
web_search = "disabled"

[model_providers.enterprise-gateway]
name = "Organization Gateway"
base_url = "https://gateway.example.com/v1"
wire_api = "responses"

[model_providers.enterprise-gateway.auth]
command = "/usr/local/bin/fetch-codex-gateway-token"
args = ["print-token"]
timeout_ms = 30000
refresh_interval_ms = 300000

有効期間の短い静的なテストキーを使う場合は、auth ブロックを削除し、env_key = "CODEX_GATEWAY_API_KEY" を [model_providers.enterprise-gateway] 内に記述して、その環境変数の値を TOML の外で設定します。env_key とコマンドを使った認証は併用しないでください。

デフォルト設定と強制設定の配布

ユーザーが ChatGPT で Codex にサインインしない場合は、自社のサーバーからチーム設定を配布できます。Codex は、モデルリクエストのルーティング方法とは独立して、これらの設定を取得します。

設定の優先順位を確認し、デフォルト設定の配布先を選んでください。強制設定と macOS の MDM ペイロードについては、管理対象の設定を参照してください。

macOS または Linux でホスト全体のデフォルト設定を指定するには、/etc/codex/config.toml を使用します。Windows では config.toml を %ProgramData%\OpenAI\Codex\ に配置します。これらのデフォルト値はユーザー設定やプロファイル設定で上書きできます。サポートされる強制設定とファイルの配置先は、上記のリンク先を参照してください。

設定で参照するヘルパーの実行ファイルとローカルカタログファイルは、別途配布してください。

リモートカタログの URL を強制するには、requirements.toml の [model_providers.<id>] にプロバイダー定義全体を記述します。強制したプロバイダー定義は、通常の設定にある対応するプロバイダーテーブルを丸ごと置き換えます。base_url、認証設定、その他の必須フィールドも含めてください。プロバイダーの選択も強制する必要がある場合は、model_provider を強制設定に追加します。

model_catalog_json はローカルの JSON ファイルを指定します。requirements.toml でこの設定を強制するとパスは固定されますが、ファイル自体は配布されません。Codex の起動前に、指定した絶対パスにカタログを配置してください。

Windows のパスは、環境変数を展開した絶対パスで TOML に記述します。Codex は %ProgramData% を model_catalog_json やプロバイダーの認証設定の command 値の中では展開しません。次のパスは、実際にその場所にファイルを配置した場合にのみ使用してください。

model_catalog_json = 'C:\ProgramData\OpenAI\Codex\models.json'

[model_providers.enterprise-gateway.auth]
command = 'C:\ProgramData\OpenAI\Codex\fetch-gateway-token.cmd'
args = ["print-token"]

WSL 内で実行する CLI は、Linux のパスと Linux 側の CODEX_HOME を参照します。Windows 側の設定は自動的には引き継がれません。

ルーティング用ヘッダーの配布

ゲートウェイが設定やツールに応じてリクエストのルートを選択する場合は、一元管理している requirements.toml のプロバイダー定義に、ゲートウェイが必要とするヘッダーを追加します。次の例では、ルーティング設定の ID を指定し、クライアントが Codex であることを伝えます。

[model_providers.enterprise-gateway.http_headers]
x-portkey-config = "<gateway-routing-config-id>"
x-portkey-metadata = '{"tool_id":"codex"}'

クライアントの環境から取得するヘッダー値には env_http_headers を使用します。テストリクエストを送り、選択されたルートをゲートウェイのログで確認してください。ヘッダーの設定項目については、カスタムモデルプロバイダーを参照してください。

開発者への設定値の共有

開発者には、試験導入で検証したセットアップ手順を 1 つ案内してください。設定を一元配布する場合も、次の情報を含めます。

管理対象のマシンを使う開発者には、既存の設定の確認を案内します。手動で設定する開発者には、プロバイダーの設定を案内してください。

今回の展開でプロバイダーを変更する場合は、既存の会話を扱うための検証済みの手順も含めます。試験導入で問題が見つかった場合に備え、展開担当者が以前の正常に動作していた設定を利用できるようにしてください。

手動設定では設定値を強制できません。また、プロジェクト内の .codex/config.toml では、プロバイダーや認証のルーティングを制御するセキュリティ上重要なキーを上書きできません。

開発者のマシンでの検証

配布した設定が開発者のマシンに反映されたことを、次の手順で確認します。

1. 承認済みのクライアントと、必要なヘルパーやカタログファイルがインストールされていることを確認します。Codex を再起動し、開発者向けの手順に従って必要なサインインをすべて完了します。
2. 想定したプロバイダーとモデルが選択されていることを確認します。CLI では /status を使います。実際の設定が案内された内容と異なる場合は、/debug-config で各設定レイヤーを確認してください。
3. ゲートウェイへの接続に記載された簡単な接続テストを実行します。
4. 同じスレッドで追加の質問を 1 回行い、会話を継続できることを確認します。続いて、その開発者のリクエストがゲートウェイのログに記録されていることを確認します。

サポート対象のクライアントと認証方式のすべての組み合わせで試験導入の検証に合格してから、利用できる開発者を増やしてください。クライアント、ゲートウェイ、ポリシーの更新後に同じ検証を行えるよう、テストに使用した設定と結果を展開手順とともに保管します。

展開時のトラブルシューティング

症状に応じて、設定、認証情報、ゲートウェイのどこを確認すべきか切り分けます。

既存のゲートウェイ環境の再利用

組織で既にゲートウェイ経由で Claude Code を使用している場合は、ゲートウェイ製品、ネットワーク経路、ログ記録の仕組み、Bedrock へのアクセスを再利用できる場合があります。稼働中の環境を維持したまま、Codex 用の Responses ルート、認証情報、モデルエイリアス、config.toml を追加してください。Claude クライアントの設定と /v1/messages の仕様では Codex は設定できません。

安全に移行するために、次の手順を順に実施してください。

1. 現在の Claude の接続に使っているゲートウェイ URL、認証情報の取得元、必須ヘッダー、モデルエイリアス、Bedrock プロファイルのマッピング、設定の一元配布に使っている経路を洗い出します。
2. 既存のルートと並行して、Codex 用の Responses ルートと Codex のモデルエイリアスを追加します。
3. ゲートウェイ標準の OAuth、API キー、認証情報ヘルパーのいずれかを選び、テストユーザー 1 人にアクセスを許可します。静的な認証情報の場合は env_key を通じて Codex から参照できるようにします。ヘルパーの場合は、コマンドを使った Codex のトークンリゾルバーの仕様に従って実装し、テストしてください。
4. プロバイダーの設定に従い、手順 3 で選んだ認証方式を使って、その開発者の環境を設定します。設定を一元配布する場合は、ゲートウェイの展開で説明している Codex のパスと設定の優先順位に合わせてペイロードを調整してください。
5. 開発者が実際に使う CLI またはデスクトップアプリで簡単な接続テストを行います。続いて、ゲートウェイ経由での Codex のテストに従い、ストリーミング、会話の継続、ツール呼び出し、エラー、ログ記録、エイリアスのルーティングをすべて検証します。
6. 試験導入で検証に合格したら、残りの開発者に設定を配布します。

モデルカタログのリファレンス

ローカルの models.json ファイルの作成

まず、Codex を実行するマシンでゲートウェイのプロバイダーを設定し、選択します。

次のカタログを models.json として、Codex を実行するマシンに保存してください。gateway-model は、ゲートウェイが受け付けるモデル ID と完全に一致する値に置き換えます。表示名は、ユーザーがモデルを選択する画面に表示されます。

{
  "models": [
    {
      "slug": "gateway-model",
      "display_name": "Gateway model",
      "base_instructions": "Help the user with their coding tasks.",
      "supported_reasoning_levels": [],
      "shell_type": "shell_command",
      "visibility": "list",
      "supported_in_api": true,
      "priority": 0,
      "support_verbosity": false,
      "truncation_policy": { "mode": "tokens", "limit": 10000 },
      "experimental_supported_tools": []
    }
  ]
}

より多くのエントリを含む例は、Codex のモデルカタログを参照してください。

model_catalog_json の値を config.toml でこのファイルの絶対パスに設定します。Codex を再起動し、Gateway model を選択してリクエストを送信します。ゲートウェイが slug に設定したモデル ID を受け取ったことを確認してください。

同梱モデルのエイリアスを作成する場合は、使用する Codex バージョンのカタログから、そのモデルのエントリ全体をコピーし、slug と display_name を変更します。エイリアスに移行先のモデルがない場合は、upgrade を null に設定します。これで、モデルのコンテキストウィンドウ、推論オプション、ツール設定を引き継げます。

クライアントへのカタログの提供

ここからは、Codex Models 形式を実装する開発者向けの説明です。この形式はモデルカタログを定義し、モデル選択画面で使われます。ゲートウェイやクラウドサービスなどの推論プロバイダーを開発する場合は、この仕様に従ってください。Codex デスクトップアプリと CLI がプロバイダーのモデルを検出し、各モデルの指示と機能設定を使用できるようになります。

組織の管理者がモデルカタログを管理する方法については、model_catalog_url の設定手順を参照してください。

この形式に対応するには、認証を必要とするカタログエンドポイントを実装します。リクエスト元の Codex バージョンに対応する最新のデフォルト設定を上流プロバイダーから取得し、独自の設定で上書きして、できあがったカタログを返します。

カタログエンドポイントの実装

デフォルトのカタログエンドポイントは、プロバイダーのベース URL 配下の /models です。ベース URL は base_url で指定します。たとえば base_url = "https://gateway.example.com/v1" の場合、Codex は次のリクエストを送信します。

GET /v1/models?client_version=0.162.1
Authorization: Bearer <PROVIDER_ACCESS_TOKEN>

デフォルトの自動検出は、コマンドを使った認証と、ChatGPT などを使う Codex バックエンド認証に対応しています。カスタムプロバイダーでコマンドを使わずに API キーで認証する場合は、model_providers.<id>.model_catalog_url を明示的に設定してリモートカタログの自動検出を有効にしてください。API キーだけでは、デフォルトのパスで自動検出は実行されません。

model_catalog_url には、https://gateway.example.com/codex/models のようにカタログの完全な URL を指定します。デフォルトの /v1/models エンドポイントも指定できます。Codex は /models を追加せず、指定した URL をそのまま使用します。API キーによる自動検出を使う場合は、features.api_key_model_discovery をデフォルトの有効状態にしておいてください。カスタムヘッダーだけでは自動検出は有効になりません。

Codex は、選択したプロバイダーの認証情報と設定済みのヘッダーを送信します。URL には client_version と、プロバイダーに設定した query_params が追加されます。カタログは、これらの認証情報を受け取る権限のあるサービスでホストしてください。

呼び出し元を認証し、それに対応する上流のデフォルト設定を取得します。独自の設定で上書きし、ModelsResponse の JSON 全体をそのまま返してください。各エントリの slug には、空でない一意の値を指定します。model_catalog_url を明示的に指定した場合、Codex はリダイレクトと 1 MiB を超えるレスポンスを拒否します。推論リクエストに対しても、引き続きモデルのアクセス制御を適用してください。

このエンドポイントを使うクライアントからは、有効な model_catalog_json 設定をすべて削除してください。ローカルファイルが優先されると、リモートカタログは取得されません。

クライアントのスキーマとの整合

カタログへのリクエストから client_version クエリパラメーターを読み取ります。Codex は、プレリリースを表す接尾辞を取り除いた CLI バージョンを major.minor.patch 形式で送信します。デスクトップクライアントの場合は、同梱の CLI のバージョンです。

Codex の公開リポジトリで、対応する rust-v<version> タグを使用してください。カスタムビルドの場合は、ビルドに使ったソースのコミットを指定します。以下のリンクは rust-v0.162.1 を指しています。使用するクライアントと一致するリビジョンを選んでください。

• スキーマは、ModelsResponse と ModelInfo のレスポンス型で確認してください。
• 完全な例は、同梱の models.json を参照してください。このファイルには実際のカタログデータが含まれており、JSON Schema 文書とは異なります。

同梱ファイルはリリース時点のスナップショットです。カタログを生成する前に、最新のデフォルト設定を取得してください。

上流の最新のデフォルト設定の取得

OpenAI モデルを提供するクラウドプロバイダーは、OpenAI からデフォルト設定を取得します。ゲートウェイはクラウドまたは上流のプロバイダーからカタログを読み込み、デプロイ済みモデルの設定と、アカウントやリージョンごとの利用可否を引き継ぎます。各段階でリクエスト元の Codex バージョンを渡し、エンドポイントごとに個別に認証してください。

OpenAI から直接デフォルト設定を取得するには、同じ client_version を指定して Codex のモデル用エンドポイントを呼び出します。OpenAI API キーを使う場合は次のようにします。

curl --fail --silent --show-error \
  'https://chatgpt.com/backend-api/codex/models?client_version=0.162.1' \
  -H "Authorization: Bearer $OPENAI_API_KEY"

ChatGPT と連携する場合は、呼び出し元の ChatGPT アクセストークンを使用し、該当する場合は ChatGPT-Account-ID ヘッダーも指定してください。上流のエンドポイントへのアクセスを許可された認証情報を使用します。ゲートウェイ独自の API キーでは OpenAI に対して認証できません。

トップレベルの models 配列を含め、レスポンス全体を解析してください。このエンドポイントは、指示、推論のデフォルト設定、ツール設定、コンテキストの上限、サービスティアなど、Codex 用のメタデータを返します。公開の /v1/models エンドポイントでは、このカタログは提供されません。

Codex のバージョンに変更がなくても、これらのデフォルト設定を更新してください。カタログの内容は呼び出し元のアクセス権によって異なる場合があります。リクエストには対象の上流アカウントの権限だけを使い、キャッシュはレスポンスのキャッシュ制御に従ってください。独自の上書き設定は別に管理し、最新のデフォルト設定にも再適用できるようにします。

プロバイダー独自の設定の適用

対象バージョンのレスポンス構造を保ったまま、次のようにフィールド値を変更します。

• 呼び出し元が利用できるモデルに絞り込みます。各 slug をサポート対象の推論ルートに対応付け、display_name、description、priority を必要に応じて調整します。エイリアスに移行先のモデルがない場合は、upgrade を null に設定します。
• 推論オプション、コンテキストの上限、入力モダリティ、サービスティアには、モデルとルートの両方がサポートする値を指定します。デフォルト値も対応する選択肢の中から選んでください。サービスティアがないルートでは、service_tiers と additional_speed_tiers を空にし、default_service_tier を null に設定します。
• 代わりの設定をテスト済みの場合を除き、上流の指示とツール設定を維持してください。メタデータを変更しても、モデルの機能は増えず、推論へのアクセス権も付与されません。

ゲートウェイのモデルエイリアスについては、モデルのメタデータを提供する方法を参照してください。作成したカタログは、サポート対象の Codex バージョンごとにテストします。

Rust の公開型の利用

クライアントのスキーマと同じ公開 Git タグまたはコミットのクレートを使用してください。

• codex-protocol が提供する codex_protocol::openai_models::{ModelsResponse, ModelInfo} を使用します。serde_json::from_slice::<ModelsResponse>() でレスポンスを解析し、catalog.models を編集して、serde_json::to_vec() でラッパー全体をシリアライズしてください。モデルへの指示に関する互換性フィールドは、ラッパーが処理します。
• codex-models-manager::bundled_models_response() を使うと、そのリビジョンに同梱された静的なカタログを ModelsResponse として読み込めます。この関数は上流の最新のデフォルト設定を取得しません。

関連ドキュメント

• プロバイダーの設定
• MCP
• プラグイン
• 管理対象の設定