ゲートウェイに接続する

組織から提供されたゲートウェイ URL、モデルエイリアス、認証情報またはトークンリゾルバーを使って、Codex を LLM ゲートウェイに接続します。

既存の構成を確認する

設定を追加する前に、管理者がすでに Codex を構成しているかどうかを確認してください。

• CLI では、選択されているプロファイルを確認し、codex doctor を実行します。起動後に、 /status を使って有効なモデルとプロバイダーを確認します。
• macOS アプリでは、~/.codex/config.toml または組織から配布された管理対象の構成を確認します。
• Windows アプリでは、%USERPROFILE%\.codex\config.toml または組織から配布されたシステム構成を確認します。

想定しているゲートウェイのプロバイダーとモデルがすでに有効な場合は、 接続を確認するに進んでください。

ゲートウェイの接続情報を入手する

Codex CLI または組織が承認したデスクトップアプリをインストールします。自分で Codex を構成するには、ゲートウェイ担当チームから次の値を入手してください。

• API パスを含む HTTPS ゲートウェイのベース URL。例：https://gateway.example.com/v1。
• 使用するモデル名とプロバイダー ID。
• スコープが限定されたゲートウェイの認証情報とその環境変数、またはインストール済みのトークンリゾルバーとその構成。
• 必要なモデルカタログファイルと、そのローカルの絶対パス。

プロバイダーを構成する

macOS または Linux では config.toml を ~/.codex/config.toml で開き、 Windows では %USERPROFILE%\.codex\config.toml で開きます。

この例を既存の構成に統合し、URL とモデルを管理者から提供された値に置き換えます。既存のキーやテーブルを重複して定義しないでください。この例では gpt-6-sol を使用しています。カスタムカタログなしで使用するのは、使用中の 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"
env_key = "CODEX_GATEWAY_API_KEY"

管理者からモデルカタログが提供された場合は、ローカルに保存し、 ファイルの絶対パスを使って、最初の TOML テーブルより前に model_catalog_json を追加します。 カスタムエイリアスには、一致するカタログメタデータが必要です。例：

model_catalog_json = "/etc/codex/gateway-models.json"

管理者からセットで提供されたモデル名とカタログを使用してください。 指定した場所にファイルが存在しない場合は、カタログパスを追加しないでください。

enterprise-gateway はプロバイダー ID の例です。 model_provider、[model_providers.<id>]、[model_providers.<id>.auth] では同じ ID を使用してください。 この例では、初回の接続テストのためにウェブ検索を無効にしています。有効にする前に、管理者が機能への対応状況を確認する必要があります。

組織のシークレット配布の仕組みを使って、Codex を起動するプロセスの環境で、ゲートウェイの認証情報を CODEX_GATEWAY_API_KEY として利用できるようにしてください。認証情報を TOML やリポジトリに保存しないでください。ターミナルで設定した変数は、デスクトップから起動したアプリでは利用できない場合があります。

カスタム認証ヘッダーを使用する

ゲートウェイが bearer トークンの代わりに X-API-Key などのヘッダーを必要とする場合は、 プロバイダーテーブルの env_key を次の内容に置き換えます。

env_http_headers = { "X-API-Key" = "CODEX_GATEWAY_API_KEY" }

管理者から提供されたヘッダー名を正確に使用してください。Codex は指定された環境変数から値を読み取ります。認証情報は構成ファイルに含めないでください。 model_providers.<id>.env_http_headers については、構成リファレンスをご覧ください。

組織の認証情報ヘルパーを使用する

管理者がコマンドベースの認証を提供している場合は、env_key の代わりに、管理者がインストールしたヘルパーと構成を使用してください。両方の仕組みを設定しないでください。 ヘルパーはマシン上に存在する必要があります。Codex はヘルパーをインストールしません。たとえば、 例の env_key 設定を次のテーブルに置き換え、管理者から提供されたリゾルバーのパスと引数を使用します。

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

カスタムプロバイダー認証リファレンスでは、 コマンド、引数、タイムアウト、更新間隔、トークン出力の仕様を定義しています。ヘルパーでトークンを取得できなくなった場合は、 サインインを更新する方法を管理者に確認してください。

ヘルパーの実行ファイルとカタログファイルには、解決済みの絶対パスを使用してください。

CLI を構成する

CLI は、macOS または Linux ではデフォルトで ~/.codex/config.toml を読み取ります。 プロバイダーの設定を保存したら、codex を実行します。WSL 内では、CODEX_HOME が別の場所を指していない限り、Linux の構成とパスを使用してください。

macOS アプリを構成する

macOS アプリは同じ ~/.codex/config.toml を読み取ります。プロバイダーの設定を保存したら、アプリを再起動します。認証情報に環境変数を使用する場合は、 アプリのプロセスから利用できることを確認してください。

Windows アプリを構成する

プロバイダーの設定を %USERPROFILE%\.codex\config.toml に配置し、 アプリを再起動します。コマンドベースの認証では、管理者がインストールしたリゾルバーを使用してください。たとえば、Unix の認証テーブルを次の内容に置き換えます。

[model_providers.enterprise-gateway.auth]
command = 'C:\Program Files\OpenAI\Codex\fetch-codex-gateway-token.exe'
args = ["print-token"]
timeout_ms = 30000
refresh_interval_ms = 300000

Windows の TOML では、単一引用符で囲まれたリテラル文字列はバックスラッシュを保持します。 Unix のカタログパスも置き換えてください。たとえば、 'C:\ProgramData\OpenAI\Codex\models.json' のように、管理者から提供された実際のパスを使用します。

MCP serverとプラグインは別途構成してください。モデルゲートウェイの認証情報では、 ツールや接続先システムへのアクセスは認可されません。

接続を確認する

構成を変更したら、クライアントを再起動します。CLI では codex を起動し、 /status を使って有効なモデルとプロバイダーを確認します。デスクトップアプリでは、 選択されているモデルと構成を確認します。

新しいタスクで次のプロンプトを送信します。

Reply with exactly: gateway-ok

想定される応答は gateway-ok です。応答だけでは、どの経路で処理されたかは証明できません。 ゲートウェイにユーザー、モデルエイリアス、意図した上流への経路が記録されたことを管理者に確認してもらってください。モデルに名前を尋ねてモデルを特定しないでください。

これで初回の接続を確認できます。管理者は、ストリーミング、ツール、後続のターンに関する 展開時のチェックも完了する必要があります。

接続の問題を解決する

サポートを求める際は、トークンと機密性の高いプロンプトを取り除いたエラーメッセージを添えてください。

既存のゲートウェイデプロイを使用する

組織がすでに別のコーディングツールでゲートウェイを使用している場合は、 そのネットワーク経路、ログ記録、プロバイダーへのアクセスを再利用できる可能性があります。 ゲートウェイ担当チームと協力して、Codex の接続を構成し、テストしてください。

1. 既存のゲートウェイ URL、認証情報の仕組み、必須ヘッダー、 モデルの経路、構成の配布方法を確認します。
2. ゲートウェイが Codex に必要な API の動作に対応していることの確認と、 Codex のモデルの経路の設定をゲートウェイ担当チームに依頼します。
3. スコープが限定されたゲートウェイの認証情報または認証情報ヘルパー、モデル名、 必要なモデルカタログをゲートウェイ担当チームから入手します。
4. それらの値を使って Codex を構成します。
5. 使用予定の CLI またはデスクトップアプリで接続を確認 します。ゲートウェイ担当チームに ストリーミング、ツール、後続のやり取りのチェックを完了してもらいます。
6. パイロット運用に合格したら、 ゲートウェイ経由で Codex をデプロイするに従って、 ほかの開発者に構成を配布します。

管理者向けの移行チェックリストと構成の対応関係については、 既存のゲートウェイデプロイを再利用するをご覧ください。

関連ドキュメント

• Codex CLI
• MCP server
• プラグイン