ゲートウェイ経由で ChatGPT にサインインする

この構成を使うメリット

すでにモデルゲートウェイを導入し、API Platform で Codex を使用している場合は、ゲートウェイを維持したまま ChatGPT でサインイン に移行できます。これにより、モデルゲートウェイを維持しつつ、対象となる ChatGPT ワークスペースの機能や管理機能（例：音声モード）を利用できます。サインイン方法の比較は、機能の提供状況をご覧ください。

設定方法

既存のコマンドベースの認証では、ゲートウェイキーを Authorization に設定します。ChatGPT でサインインすると、このヘッダーには ChatGPT トークンが入ります。別途必要となるゲートウェイ認証情報の提供方法を選択してください。

方法 A： 小さな起動ヘルパーを通じて、既存の認証情報取得コマンドを再利用します。同じゲートウェイキーを別のヘッダーで送信します。
方法 B： Codex がネイティブ OAuth を通じてゲートウェイ認証情報を取得するようにします。

選択したプロバイダー設定を、管理対象の設定でワークスペースのクラウド管理下にある requirements.toml に追加します。これらの要件は、ユーザーが ChatGPT でサインインした後に適用されます。他のサインイン方法を制限するものではありません。ゲートウェイの Codex 互換ベース URL は、/models と /responses を https://chatgpt.com/backend-api/codex にプロキシする必要があります。

方法 A：ヘルパーで認証情報取得コマンドを再利用する

既存の認証情報取得コマンドはそのまま使用します。小さなヘルパーが Codex の起動前にそのコマンドを実行し、出力を GATEWAY_KEY としてエクスポートします。これは現在使用しているものと同じゲートウェイキーで、送信に使うヘッダーだけが変わります。

たとえば、既存の API/プロバイダー設定に次の内容が含まれているとします。

# config.toml — existing API/provider setup
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/v1"
requires_openai_auth = false

[model_providers.enterprise_gateway.auth]
command = "/usr/local/bin/fetch-gateway-token"

ChatGPT でサインインするには、そのプロバイダーを次の管理対象の設定に置き換えます。auth ブロックは削除してください。コマンドベースのプロバイダー認証は requires_openai_auth = true と併用できません。

# requirements.toml
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.
env_http_headers = { "X-Gateway-Key" = "GATEWAY_KEY" } # Send the same gateway key separately.

CLI では、次のシェル関数のような起動ヘルパーを使用します。コマンドと引数は、既存の auth ブロックのものに置き換えてください。

codex_with_gateway() (
  set -eu
  GATEWAY_KEY=$(/usr/local/bin/fetch-gateway-token)
  test -n "$GATEWAY_KEY"
  export GATEWAY_KEY
  exec codex "$@"
)

codex_with_gateway

ゲートウェイで X-Gateway-Key を受け入れてキーを検証し、リクエストをバックエンドへ転送する前にそのヘッダーを削除するように設定します。クライアントからのリクエストには、次の情報が含まれるようになります。

Authorization: Bearer <ChatGPT token>
ChatGPT-Account-ID: <workspace ID, when available>
X-Gateway-Key: <same gateway key returned by your command>

ヘルパーは起動ごとに1回実行されます。Codex はヘルパーを再実行せず、このヘッダーも更新しません。キーの有効期限が切れたら、新しいキーを取得して再起動してください。デスクトップでは、起動時の連携処理でアプリのプロセスに GATEWAY_KEY を渡す必要があります。ゲートウェイへのサインインとトークンの更新を Codex に管理させる場合は、方法 B を選択してください。

図ではリクエストヘッダーと起動ヘルパーを省略して示しています。Authorization: Bearer <ChatGPT token> を使用し、上の例にあるヘルパーの空キーのチェックを残してください。GATEWAY_KEY が空の場合、Codex は X-Gateway-Key を省略します。

方法 A：起動ヘルパーを通じて認証情報取得コマンドを再利用します。同じゲートウェイキーを Authorization から X-Gateway-Key に移し、ChatGPT のサインインによって Authorization を提供します。

方法 A の実行時：ゲートウェイは X-Gateway-Key を検証して削除し、ChatGPT の Authorization と、アカウント ID があればその ID を変更せずに Codex バックエンドへ転送します。

方法 B：ネイティブのゲートウェイ OAuth を使用する

この方法では、コマンドと起動ヘルパーを、Codex が管理するゲートウェイへのサインインに置き換えます。ゲートウェイには OAuth 認可サーバーが必要です。PKCE を使用した認可コードフローをサポートするパブリッククライアントを登録し、例の URL とクライアント ID を置き換えてください。既存のプロバイダーの auth ブロックを削除し、次の管理対象の設定を使用します。

# requirements.toml
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.

[model_providers.enterprise_gateway.gateway_oauth] # Add gateway OAuth.
authorization_url = "https://login.example.com/oauth/authorize"
token_url = "https://login.example.com/oauth/token"
client_id = "YOUR_PUBLIC_CLIENT_ID"
delivery = { kind = "cookie", name = "auth-openid" } # Add gateway auth as a cookie.
# redirect_port = 43127

Codex はデフォルトで空いているループバックポートを使用します。ID プロバイダーが固定のリダイレクト URI を要求する場合は、redirect_port を設定し、この例では http://127.0.0.1:43127/callback を登録してください。

方法 B：API key によるゲートウェイ認証をネイティブのゲートウェイ OAuth に置き換え、ChatGPT のサインインと併用します。

方法 B の実行時：ゲートウェイは自身の OAuth Cookie を処理し、ChatGPT の認証情報を Codex バックエンドへ転送します。

ルーティングヘッダーを追加する（任意）

どちらの方法でも、Codex からゲートウェイへカスタムルーティングヘッダーを送信できます。たとえば、クラウド管理下にある enterprise_gateway プロバイダーの設定に、次のヘッダーを追加します。設定先は同じ requirements.toml です。

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

Codex はモデルプロバイダーへのリクエストにヘッダーを付けて送信し、ゲートウェイがルーティングルールを適用します。Codex プロセスの環境から読み取る値には env_http_headers を使用してください。リクエストをテストし、ゲートウェイが両方のヘッダーを受信して意図した経路を選択することを確認します。その他のヘッダーオプションについては、カスタムモデルプロバイダーをご覧ください。

認証情報の経路を分けて扱う

Codex は、ChatGPT の Authorization ヘッダー、存在する場合は ChatGPT-Account-ID ヘッダー、およびゲートウェイのヘッダーまたは Cookie を送信します。ゲートウェイで自身の認証情報を検証して削除した後、ChatGPT のヘッダーを変更せずに転送してください。

注意事項と制限

管理対象のモデルプロバイダー要件に対応した Codex ビルドを使用してください。方法 B では、ネイティブのゲートウェイ OAuth への対応も必要です。古いビルドでは、未対応のフィールドが無視または拒否されることがあります。
この経路の対象は、選択したモデルプロバイダーを通るリクエストです。ChatGPT のサインイン、MCP、プラグイン、その他のアプリ接続は、異なる経路を使用する場合があります。
ゲートウェイからは、リクエストデータと両方の認証情報が見えます。ログではこれらをマスキングし、ゲートウェイの認証情報を上流へ転送しないでください。
ネイティブのゲートウェイ OAuth には、ブラウザーと到達可能なループバックコールバックが必要です。デバイスコードへのフォールバックはありません。リフレッシュトークンがない場合、アクセストークンの有効期限が切れるたびに、ユーザーはブラウザーでサインインし直す必要があります。
汎用的な OpenAI の /v1/models レスポンスだけでは不十分です。Codex は models 配列を想定しています。モデル一覧、プロンプト、および導入環境で使用する各機能をテストしてください。

ゲートウェイ経由の音声

この設定は Codex のモデルプロバイダーへのリクエストをルーティングするもので、ChatGPT Voiceを有効にするものではありません。WebRTC の音声セッションでは、通話の作成とサイドバンド接続で別々の経路を使用します。experimental_realtime_webrtc_call_base_url は、~/.codex/config.toml 内の実験的な設定で、通話作成用の HTTP ベース URL のみを変更します。サイドバンド接続、メディア、通常のモデルリクエストの送信先は変更しません。この上書き設定を使用する前に、OpenAI と連携して通話の送信先と認証情報の扱いを確認し、その後、音声セッション全体をテストしてください。

API/プロバイダーの認証情報の経路については、ゲートウェイの互換性とゲートウェイの導入をご覧ください。これらの管理対象の設定については、管理対象の設定と設定リファレンスをご覧ください。

最近の検索

おすすめの検索

ドキュメントナビゲーション