ゲートウェイへの接続

ゲートウェイ担当チームが指定するプロバイダー設定と認証方式を使って、Codex を組織のモデルゲートウェイに接続します。ゲートウェイは、モデルへのリクエストを Amazon Bedrock などのバックエンドに転送します。

既存の設定の確認

管理者がテストした Codex クライアントを、テスト時と同じバージョンでインストールします。組織が設定を管理している場合は、そのクライアントを開き、管理者から案内された手順に従ってサインインしてください。その場合、以下のプロバイダー設定例はスキップできます。

• CLI では、選択中のプロファイルを確認し、codex doctor を実行します。起動後、/status で使用中のモデルとプロバイダーを確認します。
• macOS アプリでは、~/.codex/config.toml または組織が配布する管理対象の設定を確認します。
• Windows アプリでは、%USERPROFILE%\.codex\config.toml または組織が配布するシステム設定を確認します。

目的のゲートウェイプロバイダーとモデルがすでに有効になっている場合は、管理者からサインイン手順の案内があれば、その手順を済ませてから接続の確認に進んでください。管理対象のマシンにプロバイダー設定を重ねて追加しないでください。設定が管理者の案内と異なる場合は、ローカルファイルを編集する前に、どの設定レイヤーで指定すべきかを管理者に確認してください。

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

手動で設定する場合は、ChatGPT ワークスペースへのサインインとゲートウェイ認証のどちらが必要か、または両方が必要かを確認してください。

Codex を自分で設定する場合は、ゲートウェイ担当チームから次の情報を入手してください。

• API パスを含むゲートウェイの HTTPS ベース URL（例：https://gateway.example.com/v1）
• 使用するモデル名とプロバイダー ID
• 認証方式（ネイティブのゲートウェイ OAuth、スコープを限定した API キーとその環境変数、またはインストール済みの認証情報ヘルパー）
• OAuth を使う場合は、認可 URL、トークン URL、パブリッククライアント ID、および必要なスコープ。ゲートウェイが Cookie またはカスタムヘッダーを使用する場合は、その名前
• モデルカタログが必要な場合は、その URL、またはカタログファイルとそのローカル絶対パス

プロバイダーの設定

config.toml を開きます。ファイルの場所は、macOS または Linux では ~/.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"
requires_openai_auth = false

次に、ゲートウェイ担当チームが指定する認証設定を追加します。

enterprise-gateway はプロバイダー ID の例です。model_provider と、対応するプロバイダーテーブルおよび認証テーブルには、同じ ID を使用します。この例では、初回の接続テスト用にウェブ検索を無効にしています。有効にする前に、管理者がウェブ検索の対応状況を確認してください。

モデルカタログの設定

選択したモデルの機能情報と指示を Codex がどのように取得するか、ゲートウェイ担当チームに確認してください。

• 組み込みのモデル名： 使用中の Codex に同梱されているモデル名をゲートウェイがそのまま受け付け、対応するモデルにリクエストを転送する場合は、model にその名前を指定します。Codex には、そのモデルのメタデータがすでに含まれています。
• カタログのエンドポイント： ゲートウェイが Codex と互換性のあるメタデータを配信している場合は、カタログの完全な URL を使用します。Codex のカタログレスポンスを返す実装であれば、/v1/models エンドポイントを使用できます。カスタムエイリアスを使用する場合、モデル ID を列挙するだけのレスポンスでは不十分です。
• カタログファイル： ゲートウェイがカスタムエイリアスを使用し、管理者がカタログファイルを配布している場合は、ローカルの models.json を使う設定例に従ってください。ネイティブのゲートウェイ OAuth だけで認証し、カスタムメタデータが必要な場合は、ローカルファイルを使用します。

API キーまたはヘルパーで認証する場合、管理者からカタログ URL が提供されていれば、既存の [model_providers.enterprise-gateway] テーブルに追加してください。

model_catalog_url = "https://gateway.example.com/codex/models.json"

有効な model_catalog_json 設定があれば削除してください。この設定は URL より優先されます。管理者は、リモートカタログの設定でエンドポイントの要件を確認できます。

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

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

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

認証方式の選択

ブラウザでサインインする場合はネイティブのゲートウェイ OAuth、スコープを限定した認証情報を使う場合は API キー、組織から認証用のコマンドが提供されている場合は認証情報ヘルパーを使用します。

[model_providers.enterprise-gateway.gateway_oauth]
authorization_url = "https://login.example.com/oauth/authorize"
token_url = "https://login.example.com/oauth/token"
client_id = "YOUR_PUBLIC_CLIENT_ID"
# redirect_port = 43127

delivery = { kind = "cookie", name = "auth-openid" }

delivery = { kind = "header", name = "X-Gateway-Token", scheme = "Bearer" }

ssh -L 43127:127.0.0.1:43127 user@remote

env_key = "CODEX_GATEWAY_API_KEY"

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

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

ChatGPT サインインの有効化（推奨）

組織が ChatGPT ワークスペースを使用している場合、ユーザーはサインインすることで、OpenAI 公式プラグインなど、利用資格のある機能にアクセスできます。ワークスペースの管理設定が適用され、モデルへのリクエストは引き続きゲートウェイが処理します。利用できる機能の比較を参照してください。

手動で設定する場合は、サインインする前に、既存の [model_providers.enterprise-gateway] テーブルを次のように更新します。

1. requires_openai_auth = true を設定し、base_url はゲートウェイの URL のままにします。env_key、experimental_bearer_token、プロバイダーの auth の設定があればすべて削除し、Codex が主認証にユーザーの OpenAI 認証情報を使用するようにします。
2. ゲートウェイの認証情報は別に送信します。ネイティブのゲートウェイ OAuth の場合は、ゲートウェイが受け付ける Cookie またはカスタムヘッダーを gateway_oauth.delivery に設定します。API キーまたは認証情報ヘルパーの場合は、カスタム認証ヘッダーを使用します。Authorization は OpenAI 認証情報専用としてください。

管理者が指定した ChatGPT ワークスペースにサインインします。ゲートウェイへのサインインを求められた場合は、その手順も済ませてから接続を確認してください。

管理者は、管理対象のプロバイダー設定を配布し、認証情報が正しく転送されることを確認できます。

ゲートウェイでの認証情報の処理

ゲートウェイはモデルへのリクエストごとに 2 つの認証情報を受け取ります。たとえば、Codex がゲートウェイの OAuth トークンを Cookie で送信すると、リクエストは次のようになります。

POST /backend-api/codex/responses
Authorization: Bearer <ChatGPT token>
ChatGPT-Account-ID: <workspace ID, when available>
Cookie: auth-openid=<gateway token>

ゲートウェイの認証情報を検証し、それを含む Cookie またはカスタムヘッダーを取り除きます。ログでは、認証情報とリクエストに含まれる機密データをマスクしてください。上流へのリクエストに使う認証情報は、次のいずれかを選びます。

• ユーザーの認証情報を転送し、OpenAI で直接推論を実行する（推奨）。 OpenAI は利用量をそのユーザーに紐付けて記録し、ユーザーの推論設定を適用できます。この経路では、ゲートウェイは /models と /responses へのリクエストを https://chatgpt.com/backend-api/codex にプロキシする必要があります。Authorization はそのまま転送し、ChatGPT-Account-ID ヘッダーがある場合は、そのヘッダーも変更せずに転送してください。
• ゲートウェイが推論プロバイダーに対して認証を行う。 そのプロバイダー用にゲートウェイに設定した認証情報を使用します。上流へのリクエストには、ユーザーの OpenAI トークンも ChatGPT-Account-ID ヘッダーも含めないでください。

次の図は、OpenAI で推論を実行する場合の推奨経路を示しています。

ChatGPT サインインとゲートウェイキーを併用する仕組み

ChatGPT サインインとゲートウェイ OAuth を併用する仕組み

ルーティングヘッダーの追加（任意）

管理者が指定したルーティング設定を使用してください。ゲートウェイの運用担当者は、これらの設定を配布し、選択された経路をゲートウェイのログで確認できます。

このゲートウェイを経由するのは、モデルプロバイダーへのリクエストだけです。音声セッションは別の経路を使用します。ワークスペースへのサインイン、MCP サーバー、プラグインも、別のネットワーク経路を使用する場合があります。

クライアントの起動

ChatGPT サインインを使用する場合は、クライアントを起動し、管理対象の設定を配布しているワークスペースにサインインします。ネイティブのゲートウェイ OAuth を使用する場合は、案内に従って組織のゲートウェイへのサインインも完了してください。その後、接続を確認します。

プロバイダーをローカルで設定した場合は、使用するクライアントに応じて次の手順を実行します。

CLI の設定

macOS または Linux では、CLI はデフォルトで ~/.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 サーバーとプラグインは個別に設定してください。モデルゲートウェイの認証情報では、ツールや接続先システムへのアクセスは許可されません。

接続の確認

管理者が案内したプロバイダー ID とモデルのエイリアスを使用してください。プロバイダー ID は設定済みの接続を識別し、モデルのエイリアスはその接続を経由してリクエストを送る先のモデルを識別します。ChatGPT サインインとゲートウェイ認証はそれぞれアクセスを制御し、両方が必要な場合もあります。

設定を変更したら、クライアントを再起動してください。CLI では codex を起動し、/status で使用中のモデルとプロバイダーを確認します。デスクトップアプリでは、選択中のモデルと設定を確認します。

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

Reply with exactly: gateway-ok

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

接続のトラブルシューティング

サポートを依頼する際は、クライアントのバージョン、OS、使用予定のプロバイダーとモデルのエイリアス、認証方式、失敗した手順を伝えてください。ゲートウェイの管理者が該当のリクエストを特定できるように、エラーメッセージとリクエストの送信時刻も添えてください。送信する内容から、トークン、Cookie、認可ヘッダー、機密情報を含むプロンプトを取り除いてください。認証情報ファイルや、シークレットを含む設定のダンプは送信しないでください。

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

ゲートウェイ担当チームに、Codex のプロバイダー設定と承認済みのモデルエイリアスを確認してください。担当チームがこれから Codex 用の経路を有効にする場合は、管理者向けの移行チェックリストを共有してください。

関連ドキュメント

• Codex CLI
• MCP サーバー
• プラグイン