外部モデルを Codex に接続する

このガイドでは、ホスト型のサードパーティモデルを統合する次の 2 つの方法を説明します。

最初に理解しておくべき重要な制限が 1 つあります。

このガイドは、Codex CLI、Codex IDE 拡張機能、および同じ config.toml を読み込むデスクトップクライアントを含む、ローカルで実行される Codex クライアントを対象としています。現在、Codex クラウドチャットでは、この設定を使用してカスタムモデルに切り替えることはできません。

始める前に

Codex CLI をインストールまたは更新する

npm install -g @openai/codex@latest
codex --version

初回インストール後、Codex を少なくとも一度実行してください。

codex

これにより、ユーザー設定ディレクトリが初期化されます。

Codex 設定ファイルの場所

macOS および Linux：

~/.codex/config.toml

Windows：

%USERPROFILE%\.codex\config.toml

変更する前にファイルをバックアップしてください。

macOS / Linux：

mkdir -p ~/.codex/backup
cp ~/.codex/config.toml \
  ~/.codex/backup/config.toml.$(date +%Y%m%d-%H%M%S) \
  2>/dev/null || true

PowerShell：

$codexDir = Join-Path $HOME ".codex"
$backupDir = Join-Path $codexDir "backup"
New-Item -ItemType Directory -Force -Path $backupDir | Out-Null

$configFile = Join-Path $codexDir "config.toml"
if (Test-Path $configFile) {
  $timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
  Copy-Item $configFile (Join-Path $backupDir "config.toml.$timestamp")
}

プロバイダー、MCP、モデルゲートウェイはそれぞれ異なるものです

これらの概念は、それぞれ異なる問題を解決します。

• model_provider は、Codex がモデルリクエストを送信する宛先を決定します。
• MCP は、GitHub、ブラウザー、データベースなどのツールやコンテキストを追加します。
• モデルゲートウェイは、Codex とアップストリームモデルの間で、プロトコル変換、認証、ルーティング、ログ記録、レート制限などを処理します。

基盤となるモデルを変更するには、MCP ではなくプロバイダーを設定してください。

API key を保護する

実際の API key を Git リポジトリにコミットしたり、完全なキーをスクリーンショット、ログ、サポートチケットに表示したりしないでください。

手動で設定するプロバイダーでは、環境変数の使用を推奨します。

[model_providers.example]
env_key = "EXAMPLE_API_KEY"

CC Switch はプロバイダー設定をローカルに保存し、プロバイダーを切り替える際にローカルの Codex 設定を変更します。これはサードパーティ製のオープンソースツールであり、OpenAI 製品ではありません。公式の CC Switch Web サイトまたは GitHub リポジトリからのみインストールし、ローカルデータベース、設定、バックアップを保護してください。

1. CC Switch でサードパーティモデルを接続する

ほとんどのサードパーティモデルでは、CC Switch のほうが簡単です。プロバイダー、API key、モデル一覧、ローカルルーティングを管理でき、互換性のないアップストリームプロトコルも変換できます。

1.1 CC Switch が解決する問題

最新の Codex クライアントは Responses API リクエストを送信しますが、多くのサードパーティサービスが公開しているのは次のいずれかです。

• OpenAI Chat Completions。
• Anthropic Messages。
• Codex の既定の一覧にないモデル ID。
• ベンダー固有の推論パラメーターまたはストリーミングイベント形式。

CC Switch は、次のようにリクエストパスを変換できます。

Codex
  │  Responses API
  ▼
CC Switch local route
  │  Converts the protocol and model name when required
  ▼
Third-party model API
  │
  ▼
CC Switch converts JSON, SSE, reasoning data, and tool calls back to Responses
  │
  ▼
Codex

Responses をネイティブにサポートするプロバイダーには、Chat プロトコルの変換は不要です。Chat Completions または Anthropic Messages のプロバイダーにはローカルルーティングが必要です。

1.2 CC Switch をインストールする

公式の配布チャネルのみを使用してください。

• CC Switch 公式 Web サイト
• CC Switch GitHub リポジトリ
• CC Switch Releases

macOS では Homebrew を推奨します。

brew install --cask cc-switch

更新するには、次を実行します。

brew upgrade --cask cc-switch

Windows では、Releases から .msi インストーラーまたはポータブルアーカイブをダウンロードしてください。

Linux では、Releases から .deb、.rpm、または AppImage パッケージをダウンロードしてください。ラベルはバージョンによって多少変わる場合があるため、最新の安定版を使用し、アプリケーションに表示される選択肢を正式な情報として扱ってください。

1.3 前提条件

次のものを準備してください。

1. Codex がインストール済みで、少なくとも一度起動されていること。
2. CC Switch がインストール済みで、正常に起動すること。
3. 対象のモデルサービス用の API key があること。
4. プロバイダーのドキュメントで Base URL、モデル ID、アップストリームプロトコルを確認済みであること。
5. Codex の公式アカウント機能が必要な場合は、最初に公式ログインを一度完了しておくこと。

現在の Codex のログイン状態を確認します。

codex login status

必要に応じてサインインします。

codex login

デバイスコードによるログインも利用できます。

codex login --device-auth

1.4 任意：サードパーティプロバイダーの使用中も公式ログインを維持する

これは主に、モデルリクエストをサードパーティプロバイダーに送信しながら、デスクトップ機能、公式プラグイン、リモートコントロール機能を維持したい場合に便利です。公式アカウント機能を利用しない CLI 専用ユーザーは、この手順を省略できます。

推奨される順序は次のとおりです。

1. CC Switch の Codex パネルで OpenAI Official を選択します。
2. Codex を起動し、公式アカウントでサインインします。
3. CC Switch で Settings → General → Codex App Enhancements を開きます。
4. Keep official login when switching third-party providers を有効にします。
5. サードパーティプロバイダーを追加するか、そのプロバイダーに切り替えます。

このオプションを有効にすると、CC Switch は次の情報の維持を試みます。

• 公式ログイン状態用の ~/.codex/auth.json。
• 有効なサードパーティプロバイダー、モデル、エンドポイント、認証設定用の ~/.codex/config.toml。

auth.json には機密性の高いログインデータが含まれています。共有したり、バージョン管理にコミットしたりしないでください。

1.5 サードパーティプロバイダーを追加する

CC Switch を開き、最上位の Codex パネルに切り替えて、右上隅の追加ボタンをクリックします。

組み込みプリセットを優先する

プリセットが用意されている場合はそれを使用し、API key と必要なアカウント固有の値だけを入力してください。通常、プリセットでは次の項目が設定されます。

• Base URL。
• 既定のモデル。
• アップストリームプロトコル。
• ローカルルーティングが必要かどうか。
• モデルマッピング。
• 選択された推論パラメーター。

プリセットの一覧は CC Switch の進化に伴って変わります。長期運用するドキュメントに、ベンダーの現行モデル ID をハードコードしないでください。アプリケーション内の一覧とプロバイダーの公式ドキュメントを使用してください。

カスタムプロバイダーを作成する

プリセットがない場合はカスタム設定を選択し、次の情報を指定します。

最も重要な設定は Upstream Format です。

プロバイダーが「OpenAI 互換」をうたっているという理由だけで Responses を選択しないでください。OpenAI 互換 API の多くは Chat Completions だけを実装しています。

1.6 Base URL を正しく入力する

既定では、CC Switch が Base URL に適切な API パスを追加します。ほとんどの場合、/chat/completions や /responses を自分で重ねて入力するのではなく、プロバイダーのドキュメントに記載された API ルートを入力してください。

たとえば、プロバイダーのドキュメントに次のように記載されている場合、

POST https://api.example.com/v1/chat/completions

次のように入力する必要がある場合があります。

https://api.example.com

または、プリセットとプロバイダーのドキュメントによっては、次のように入力します。

https://api.example.com/v1

Base URL に /v1 を含めるかどうかは、プロバイダーと CC Switch のプリセットによって異なります。組み込みの接続確認機能またはルーティングログを使用して、最終的なリクエスト URL を確認してください。

プロバイダーが標準外の完全なエンドポイントパスを必要とする場合に限り、Full URL Mode を使用してください。

1.7 Needs Local Routing とモデルマッピングを設定する

プロバイダーが Chat Completions、Anthropic Messages、または Codex が既定で認識しないモデル名を使用する場合は、Needs Local Routing を有効にしてください。

Chat 向けプリセットでは通常、自動的に有効になります。カスタムプロバイダーの場合は、このオプションを確認してください。

有効にすると、モデルマッピング表を利用できるようになります。一般的なフィールドは次のとおりです。

重要な点は次のとおりです。

• プロバイダーのドキュメントにある正確なモデル ID を使用してください。
• コンテキストウィンドウを推測しないでください。
• モデル一覧を変更した後は Codex を再起動してください。
• CC Switch は、これらのマッピングから Codex のモデルカタログを生成します。
• リレーによってドメインまたはモデル名が変更される場合、推論機能の自動検出が誤る可能性があるため、詳細設定で確認してください。

1.8 ローカルルーティングと Codex takeover を有効にする

CC Switch で次を開きます。

Settings → Routing → Local Routing

続いて、次の操作を行います。

1. ローカルルーティングのメインスイッチを有効にします。
2. Routing Enabled で Codex を有効にします。
3. プロバイダーの Needs Local Routing 設定を確認します。
4. プロバイダーの使用中は CC Switch を実行したままにします。

一般的な既定のローカルルートは次のとおりです。

http://127.0.0.1:15721

takeover 後、稼働中の Codex 設定は CC Switch のローカルルートを指します。その後、CC Switch が現在選択されているアップストリームプロバイダーにリクエストを転送します。

Chat Completions アップストリームの場合、一般的なフローは次のとおりです。

Codex POST /responses
  → CC Switch converts it to POST /chat/completions
  → the provider returns JSON or SSE
  → CC Switch rebuilds Responses JSON or SSE
  → Codex continues the tool-call loop

1.9 プロバイダーを切り替えて Codex を再起動する

CC Switch の Codex プロバイダー一覧に戻り、設定したプロバイダーを選択して有効にします。

次の理由により、切り替え後は Codex を完全に再起動してください。

• Codex は起動時に config.toml を読み込みます。
• /model メニューは通常、起動時にカタログを読み込みます。
• IDE 拡張機能またはデスクトップクライアントが以前のプロバイダーをキャッシュしている場合があります。
• 既存のセッションに古いモデルメタデータが残っている場合があります。

CLI ユーザーは、新しいプロセスを起動するだけで構いません。

codex

1.10 統合を検証する

Codex 内で次を実行します。

/status

有効なモデル、プロバイダー、権限、コンテキスト情報を確認します。

モデルセレクターを開きます。

/model

設定レイヤーを確認します。

/debug-config

次の項目も確認してください。

• CC Switch で有効になっている Codex プロバイダー。
• CC Switch のローカルルーティングログまたは統計。
• プロバイダーのダッシュボードにあるリクエスト履歴と残高の変化。
• ~/.codex/config.toml が現在ローカルルートを指しているかどうか。

単純な挨拶だけで設定を検証しないでください。少なくとも 1 つのエージェント機能テストを実行してください。

1. Codex に現在のプロジェクト内のファイル一覧を表示するよう依頼します。
2. 1 つのファイルを読み取り、要約するよう依頼します。
3. 小さなファイルを変更するよう依頼します。
4. テストを実行するよう依頼します。
5. 簡単な失敗を意図的に残し、テスト結果を利用してプロジェクトの修正を継続できることを確認します。

テキスト生成に成功しても、ツール呼び出しや複数ターンのエージェントワークフローとの互換性が証明されたことにはなりません。

1.11 OpenAI の公式プロバイダーに戻す

CC Switch で OpenAI Official を選択し、Codex を再起動します。

ログイン状態を確認します。

codex login status

必要に応じて、もう一度サインインします。

codex login

公式ログイン状態とサードパーティモデルへのリクエストを併用する必要がある場合は、Keep official login when switching third-party providers が引き続き有効であることを確認してください。

1.12 制限事項と運用上の考慮事項

CC Switch は設定を簡素化しますが、アップストリーム側の制限を解消するものではありません。

• Chat または Messages を変換するには、CC Switch を実行したままにする必要があります。
• プロトコル変換ですべてのベンダー固有機能を再現できるとは限りません。
• チャットはできても、ツール呼び出しを安定して実行できないモデルがあります。
• Web Search、画像入力、WebSockets、レスポンス保存を利用できない場合があります。
• アップストリームプロバイダーのレート制限、課金、データ保持ポリシーは引き続き適用されます。
• API リレーによってリクエストとレスポンスがさらに変更される場合があります。
• CC Switch、Codex、またはプロバイダーのアップグレード後は、設定を再テストする必要があります。

CC Switch はローカルのデスクトップ開発に最適です。サーバー、CI、または長時間実行するヘッドレス自動処理では、ネイティブ Responses プロバイダーまたはセルフホスト型ゲートウェイを推奨します。

2. カスタムモデルプロバイダーでホスト型 API に接続する

サービスが Codex に必要な Responses API をネイティブにサポートしている場合に限り、プロバイダーを直接設定してください。

サービスが /chat/completions または Anthropic Messages のみを公開している場合は、セクション 1 の CC Switch ワークフローを使用してください。wire_api = "chat" で不一致を解決しようとしないでください。

2.1 必要な API 機能

Codex との直接統合に適したプロバイダーは、少なくとも次の機能をサポートする必要があります。

• POST /responses。
• Responses JSON オブジェクト。
• Responses SSE ストリーミングイベント。
• 関数またはツールの呼び出し。
• JSON Schema のツールパラメーター。
• ツール結果が返された後の処理継続。
• 複数ターンのリクエスト、または previous_response_id と同等の機能。
• 十分なコンテキストウィンドウと、長時間のリクエストを安定して処理する能力。
• 文書化された認証、レート制限、エラーレスポンス。

通常のテキスト生成だけでは、信頼できる Codex エージェントとして十分ではありません。

2.2 汎用設定

ユーザーレベルの設定を編集します。

~/.codex/config.toml

次を追加します。

model_provider = "third_party"
model = "provider-model-id"

# Set this only when the model explicitly supports it.
model_reasoning_effort = "high"

# Optional: use the real value published by the provider when no catalog exists.
# model_context_window = 131072

[model_providers.third_party]
name = "My Responses-compatible Provider"
base_url = "https://provider.example.com/v1"
env_key = "THIRD_PARTY_API_KEY"
wire_api = "responses"
request_max_retries = 4
stream_max_retries = 5
stream_idle_timeout_ms = 300000

次の予約済みプロバイダー ID は使用しないでください。

openai
ollama
lmstudio

代わりに、third_party や company_gateway などのカスタム ID を使用してください。

2.3 設定フィールド

base_url に /v1 を含めるかどうかは、プロバイダーのドキュメントによって異なります。一般的な最終エンドポイントは次のとおりです。

https://provider.example.com/v1/responses

2.4 API key を設定する

現在の bash / zsh セッション：

export THIRD_PARTY_API_KEY="your API key"

fish：

set -gx THIRD_PARTY_API_KEY "your API key"

現在の PowerShell セッション：

$env:THIRD_PARTY_API_KEY = "your API key"

現在の Windows ユーザー用に永続化する：

[Environment]::SetEnvironmentVariable(
  "THIRD_PARTY_API_KEY",
  "your API key",
  [EnvironmentVariableTarget]::User
)

永続的な環境変数を設定した後は、ターミナル、IDE、またはデスクトップクライアントを再起動してください。

2.5 最初に Responses エンドポイントをテストする

Codex を起動する前に、プロバイダーを直接呼び出します。

export PROVIDER_BASE_URL="https://provider.example.com/v1"

curl "$PROVIDER_BASE_URL/responses" \
  -H "Authorization: Bearer $THIRD_PARTY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "provider-model-id",
    "input": "Reply with exactly: PROVIDER_OK",
    "stream": false
  }'

次の点を確認してください。

• エンドポイントが 404 を返さないこと。
• レスポンスが Chat Completions の choices 配列だけではなく、Responses 形式の構造になっていること。
• モデル ID が受け付けられること。
• 認証が正しいこと。
• エラーに有用な診断情報が含まれていること。

続いて、次の項目を個別にテストします。

• stream: true。
• ツール呼び出し。
• ツール結果を受け取った後の処理継続。
• 複数ターン。
• 長いコンテキスト。
• 同時実行とレート制限。

2.6 Codex 設定を検証する

strict mode で起動します。

codex --strict-config

--strict-config は不明な設定キーをエラーとして扱うため、古いガイドからコピーされたフィールドを特定するのに役立ちます。

Codex 内で次を実行します。

/status

設定ソースを確認するには、次を実行します。

/debug-config

既定の設定を変更せず、1 回の実行に限ってプロバイダーとモデルを上書きします。

codex \
  -c 'model_provider="third_party"' \
  -m 'provider-model-id'

2.7 モデルカタログと Unknown model

Codex モデルカタログには、次の情報を記述できます。

• コンテキストウィンドウのサイズ。
• サポートされる推論レベル。
• 入力モダリティ。
• ツール呼び出し機能。
• 切り詰め動作。
• クライアントの最小バージョン。

プロバイダーが Codex 互換のモデルカタログを提供している場合は、ローカルに保存して次を設定します。

model_catalog_json = "~/.codex/provider-models.json"

カタログが存在しない場合は、実際の値を確認してからコンテキストウィンドウを設定してください。

model_context_window = 131072

警告を消すためだけに、無関係なモデルのメタデータをコピーしないでください。機能やコンテキストのメタデータが正しくないと、早すぎる切り詰め、アップストリームの上限エラー、ツール呼び出しの失敗につながる可能性があります。

2.8 完全な互換性チェックリスト

本番環境で使用する前に、次の項目をテストしてください。

• 非ストリーミングの /responses テキスト。
• Responses SSE ストリーミング。
• 1 回のツール呼び出し。
• 複数の連続または並列ツール呼び出し。
• JSON Schema パラメーター。
• ツール結果を受け取った後の処理継続。
• 長いコンテキストと自動コンパクション。
• 推論パラメーター。
• 画像またはその他の入力モダリティ。
• レート制限と再試行動作。
• プロキシが SSE をバッファリングするかどうか。
• プロバイダーがツールフィールドを削除または書き換えるかどうか。
• データ保持、ログ記録、プライバシーポリシー。

2.9 プロバイダー設定を配置する場所

model_provider、model_providers、プロバイダー認証は、次のユーザーレベルファイルに配置します。

~/.codex/config.toml

次のリポジトリレベルファイルには配置しないでください。

<project>/.codex/config.toml

Codex は、モデルリクエストを別の宛先に転送したり、プロバイダー認証を変更したりできるプロジェクトローカルのフィールドを無視します。これにより、信頼できないクローン済みリポジトリが、リクエストを別のサーバーへ密かに転送することを防ぎます。

3. プロファイルで複数のサードパーティプロバイダーを管理する

CC Switch ユーザーは通常、アプリケーション内でプロバイダーを切り替えられるため、Codex プロファイルは必要ありません。

プロファイルは、複数のネイティブ Responses プロバイダーを手動で設定する場合に便利です。プロバイダー定義は基本設定に保持し、プロバイダーとモデルの選択には個別のプロファイルファイルを使用します。

基本の ~/.codex/config.toml：

[model_providers.provider_a]
name = "Provider A"
base_url = "https://api.provider-a.example/v1"
env_key = "PROVIDER_A_API_KEY"
wire_api = "responses"

[model_providers.provider_b]
name = "Provider B"
base_url = "https://api.provider-b.example/v1"
env_key = "PROVIDER_B_API_KEY"
wire_api = "responses"

次を作成します。

~/.codex/fast.config.toml

model_provider = "provider_a"
model = "provider-a-fast-model"
model_reasoning_effort = "medium"

別のプロファイルを作成します。

~/.codex/quality.config.toml

model_provider = "provider_b"
model = "provider-b-quality-model"
model_reasoning_effort = "high"

Codex の起動時にプロファイルを選択します。

codex --profile fast
codex --profile quality

非対話モード：

codex exec --profile quality "Review the current changes"

プロファイルファイルは次の場所にあります。

$CODEX_HOME/<profile-name>.config.toml

既定の CODEX_HOME は ~/.codex です。

最近の Codex バージョンでは個別のプロファイルファイルが使用され、従来の [profiles.<name>] テーブルは読み込まれなくなりました。従来の各プロファイルを、それぞれ専用の <name>.config.toml ファイルに移行してください。

4. カスタムヘッダーと高度な認証

4.1 標準の bearer token

ほとんどのサードパーティサービスでは、次の設定を使用できます。

[model_providers.third_party]
env_key = "THIRD_PARTY_API_KEY"

Codex は環境からキーを読み取り、プロバイダーの bearer 認証を適用します。

4.2 カスタム API-key ヘッダー

一部のサービスでは次の形式が必要です。

x-api-key: <key>

env_http_headers を使用します。

model_provider = "custom_header_provider"
model = "provider-model-id"

[model_providers.custom_header_provider]
name = "Custom Header Provider"
base_url = "https://provider.example.com/v1"
wire_api = "responses"
env_http_headers = { "x-api-key" = "VENDOR_API_KEY" }

値 VENDOR_API_KEY は環境変数名であり、シークレットそのものではありません。

export VENDOR_API_KEY="your API key"

4.3 静的ヘッダーとクエリパラメーター

機密情報ではない静的ヘッダーを追加します。

http_headers = { "X-Client-Name" = "codex", "X-Environment" = "development" }

クエリパラメーターを追加します。

query_params = { "api-version" = "2026-08-01" }

実際のシークレットを http_headers に記述しないでください。

4.4 コマンドベースの認証

エンタープライズ環境では、キーチェーン、クラウド認証情報ヘルパー、または社内コマンドから短期トークンを取得する場合があります。

[model_providers.corporate]
name = "Corporate Gateway"
base_url = "https://gateway.example.com/v1"
wire_api = "responses"

[model_providers.corporate.auth]
command = "/usr/local/bin/fetch-codex-token"
args = ["--audience", "codex"]
timeout_ms = 5000
refresh_interval_ms = 300000

コマンドは標準出力にトークンだけを出力する必要があります。

次の認証方法を併用しないでください。

• [model_providers.<id>.auth]。
• env_key。
• experimental_bearer_token。
• requires_openai_auth。

4.5 プロキシ経由で OpenAI 認証を再利用する

プロキシが引き続き OpenAI モデルにアクセスし、Codex が OpenAI の公式認証を使用する必要がある場合に限り、次を設定してください。

requires_openai_auth = true

これは通常のサードパーティモデルの API key には適切な設定ではありません。有効にすると、Codex はプロバイダーの env_key を無視します。

5. トラブルシューティング

5.1 CC Switch でプロバイダーを変更しても、Codex が以前のモデルを使用する

各項目を確認してください。

1. 目的の Codex プロバイダーが CC Switch で有効になっていること。
2. ローカルルーティングのメインスイッチがオンになっていること。
3. Routing Enabled で Codex が有効になっていること。
4. Chat または Messages プロバイダーで Needs Local Routing が有効になっていること。
5. CC Switch が引き続き実行されていること。
6. Codex、IDE、またはデスクトップクライアントが完全に再起動されていること。
7. /debug-config に想定どおりの設定ソースが表示されていること。

モデルマッピングを変更した後は Codex を再起動し、/model メニューがカタログを再読み込みできるようにしてください。

5.2 404、400、または /responses エンドポイントが存在しない

一般的な原因は次のとおりです。

• Chat Completions プロバイダーをネイティブ Responses プロバイダーとして扱っている。
• /v1 を誤って追加または削除している。
• /chat/completions を 2 回追加している。
• 標準外のエンドポイントに対して Full URL Mode を有効にしていない。
• ローカルルーティングが Codex を takeover していない。
• サードパーティゲートウェイの Responses 実装が不完全である。

CC Switch ユーザーは Upstream Format とルーティングログを確認してください。直接プロバイダーを設定しているユーザーは、<base_url>/responses を curl で呼び出してください。

5.3 401 Unauthorized または 403 Forbidden

次の点を確認してください。

• API key が有効かどうか。
• 正しいリージョン、プロジェクト、プランのキーかどうか。
• アカウントに十分な残高と権限があるかどうか。
• サービスが bearer token と x-api-key のどちらを要求しているか。
• 環境変数名が env_key と完全に一致しているかどうか。
• CC Switch に正しいキーが保存されているかどうか。
• プロキシが認証ヘッダーを削除していないかどうか。

完全なキーを共有ログに出力しないでください。

bash / zsh：

printenv THIRD_PARTY_API_KEY

PowerShell：

$env:THIRD_PARTY_API_KEY

5.4 /model にモデルが表示されない

次の点を確認してください。

• CC Switch の Model Mapping に正確なアップストリームモデル ID が含まれているかどうか。
• プロバイダーが保存され、有効になっているかどうか。
• Codex が再起動されているかどうか。
• 手動設定したプロバイダーに有効な model_catalog_json があるかどうか。
• カタログの JSON が有効かどうか。
• プロバイダーがモデルの名前を変更したか、提供を終了していないか。

5.5 テキストは生成できるが、Codex がファイルの読み取り、コードの編集、コマンドの実行を行えない

考えられる原因は次のとおりです。

• モデルのツール呼び出し能力が低い。
• アップストリームが関数呼び出しを実装していない。
• リレーがツール呼び出し ID を削除している。
• ストリーミングされたツール呼び出しの断片が正しく再構築されていない。
• JSON Schema が書き換えられている。
• 次のターンでツール結果が返されていない。
• モデルのコンテキストが短すぎる。
• モデルカタログが機能を誤って示している。

単純なチャットプロンプトではなく、実際の「読み取り → 編集 → テスト実行 → 失敗の確認 → 修正」のループをテストしてください。

5.6 ストリーミングが頻繁に切断される

CC Switch ユーザーは、最初にローカルルーティングログとアップストリームのレスポンスを確認してください。一般的な原因は次のとおりです。

• アップストリームでのキュー待ち、または推論に時間がかかっている。
• ゲートウェイが SSE を速やかに送信しない。
• CDN、リバースプロキシ、または企業ネットワークでバッファリングされている。
• アップストリームイベントが標準外である。
• 特定の CC Switch またはプロバイダーのバージョンに互換性の問題がある。

直接プロバイダーを設定している場合は、次の値を増やすことができます。

request_max_retries = 4
stream_max_retries = 5
stream_idle_timeout_ms = 600000

タイムアウトを長くすると、ネットワークや推論の遅さに起因する問題を軽減できますが、誤ったプロトコル実装を修復することはできません。

5.7 wire_api = "chat" が原因で Codex を起動できない

この値は古いガイドに記載されています。現在の Codex 設定でサポートされるのは次の値だけです。

wire_api = "responses"

アップストリームが Chat Completions のみを公開している場合は、CC Switch を使用してください。

その他の廃止されたフィールドを確認するには、次を実行します。

codex --strict-config

5.8 プロジェクト設定を編集してもプロバイダーが変わらない

プロバイダー設定は次の場所に配置します。

~/.codex/config.toml

プロジェクトレベルの .codex/config.toml では、model_provider や model_providers を含め、リクエストの転送先やプロバイダー認証を変更するフィールドを上書きできません。

5.9 ターミナルでは動作するが、IDE 拡張機能が API key を見つけられない

GUI アプリケーションは、既存のターミナルで一時的にエクスポートされた変数を継承しないことがよくあります。

次の方法があります。

• 変数が設定されているターミナルから IDE を起動する。
• オペレーティングシステムのユーザー環境に変数を永続化する。
• IDE を完全に終了してから再度開く。
• CC Switch を使用してローカルプロバイダー設定を管理する。

5.10 切り替え後に公式ログインまたは公式機能が動作しなくなる

次の点を確認してください。

• OpenAI Official が再度選択されているかどうか。
• Keep official login when switching third-party providers が有効になっているかどうか。
• 古いワークフローによって ~/.codex/auth.json が上書きされていないかどうか。
• codex login status が成功するかどうか。

必要に応じて、もう一度サインインします。

codex login

アクセストークンを含む auth.json ファイルを共有したり、手動で編集したりしないでください。

5.11 Web Search、画像、その他の高度な機能が動作しない

テキストとツール呼び出しをサポートするプロバイダーでも、Codex のすべての機能を実装しているとは限りません。

カスタムプロバイダーは、既定では独立した Web Search のサポートを示しません。プロバイダー、モデル、エンドポイントが実際にサポートしている場合に限り、次を設定してください。

supports_standalone_web_search = true

誤って有効にすると、アップストリームが処理できないリクエストを Codex が送信するだけです。画像入力、WebSockets、レスポンス保存、その他の高度な機能は個別に検証してください。

6. 統合方法を選択する

すべての統合を次の 3 段階で検証してください。

1. 接続性： テキストを安定して返すこと。
2. ツールの使用： ファイルを読み取り、コマンドを実行し、ツール結果を受け取った後も処理を継続できること。
3. タスクの完了： 編集、テスト、修復のループを完了できること。

次の項目も確認してください。

• サードパーティの料金。
• レート制限。
• ソースコードとプロンプトがログに記録されるかどうか。
• データの保存リージョン。
• チームまたはエンタープライズのコンプライアンス要件。
• モデルのアップグレード時に回帰テストが必要かどうか。

サードパーティの API key を使用する場合、利用料金はそのプロバイダーまたはリレーから請求されます。ChatGPT Plus、Pro、または Codex サブスクリプションに含まれる利用枠が自動的に消費されたり、共有されたりすることはありません。

参考資料

• Codex 設定の基本
• Codex の詳細設定
• Codex 設定リファレンス
• Codex の認証
• Codex 開発者向けコマンド
• Codex のモデル
• CC Switch GitHub
• CC Switch ユーザーマニュアル
• CC Switch：プロバイダーの追加
• CC Switch：Codex の公式ログインを維持する