Codex で DeepSeek を使う：Responses プロトコル、CC Switch ルーティング、検証方法

Codex で DeepSeek を使用したい場合、通常、最初の反応は ~/.codex/config.toml を変更することです。

1
2


model = "deepseek-chat"
base_url = "https://api.deepseek.com"

この考え方は、一部の古いバージョンや一般的な OpenAI SDK シナリオには当てはまりますが、現在の Codex CLI に適用すると、簡単に根本的な問題に遭遇します。Codex のカスタムモデルサプライヤーは OpenAI Responses プロトコルを使用し、DeepSeek 公式インターフェイスは主に OpenAI 互換の Chat Completions 呼び出しメソッドを提供します。

私の現在のマシンはcodex-cli 0.111.0です。 codex --help では、構成エントリ --config、--model、および --profile がサポートされていることがわかります。 OpenAI 公式 Codex 構成リファレンスも非常に明確です。model_providers.<id>.wire_api は現在 responses のみをサポートしており、省略された場合のデフォルトは responses です。。

DeepSeek 公式ドキュメントで指定されている呼び出しパスは https://api.deepseek.com/chat/completions で、例も client.chat.completions.create(...) です。したがって、問題は、OpenAI SDK から DeepSeek を呼び出せないことではなく、Codex によって送信されるリクエストセマンティクスと、DeepSeek のネイティブインターフェイスによって理解されるセマンティクスがまったく同じではないということです。

このため、base_url を https://api.deepseek.com に直接変更した後、次の現象が発生する可能性があります。

リクエストのパスが一致しません。直接 404 または戻り形式が正しくありません。
複数ラウンドのダイアログ、ツールの呼び出し、およびパッチの生成中に解析が失敗しました。
tool_calls シーケンス、メッセージ構造、ストリーミングイベントの形式が一致しません。
モデルは文を返信できるようですが、Codex が実際に動作するようになると、エラーを報告し始めます。

より安定したアプローチは、Codex と DeepSeek の間に「翻訳レイヤー」を置くことです。一般的なルートは 2 つあります。方法 1: CC スイッチを使用した DeepSeek ローカルルーティング

ローカルゲートウェイの役割は、単に転送するだけではなく、Codex Response リクエストを DeepSeek が処理できるチャットコンプリーションに変換し、通常の JSON、SSE ストリーム、推論コンテンツ、およびツールコールを Codex が解析できる Response イベントに変換して戻すことです。

CC Switch は、3.16 からこの明確な公式プロジェクトパスを提供します。操作の順序は次のとおりです。

公式リリースから CC Switch の現在のバージョンをインストールします。
上部の Codex ページに切り替えて、新しいプロバイダーを追加します。
組み込みの DeepSeek プリセットを選択し、DeepSeek API キーを入力します。
自動的に有効になるデフォルトの Needs Local Routing をそのままにしておきます。
設定の [ルーティング] ページでローカルルーティングを有効にし、Codex のテイクオーバーを有効にします。
完全に終了し、Codex を再起動すると、モデルディレクトリが再ロードされます。

ルーティングが有効になっている場合、公式ガイドで指定される Codex のローカルアドレスは通常次のようになります。

1

http://127.0.0.1:15721/v1

このポートを固定真実として書き込まないでください。 CC スイッチの現在のインターフェイスと生成されたユーザーレベル ~/.codex/config.toml を参照してください。 CC Switch は、モデルディレクトリと認証フィールドを管理します。古いチュートリアルで TOML を手動でコピーすると、現在のバージョンと競合しやすくなります。

Codex に入ったら、まず `/model` を使用して DeepSeek プリセットが表示されるかどうかを確認し、最小限のリクエストを送信します。次に、[CC スイッチルーティング] ページでリクエストまたはログの数を確認します。リクエストが実際にローカルにルーティングされた場合にのみ、他のプロバイダーが悪用されていないことを証明できます。実際の環境記録

この記事を確認したところ、ローカルでの実行結果は次のようになりました。

1

codex-cli 0.111.0

`codex --help` `--config`、`--model`、および `--profile` も表示されます。現在のマシンには CC スイッチがインストールされておらず、DeepSeek キーが構成されていないため、この記事はエンドツーエンドの DeepSeek 生成テストが完了したとは主張しません。上記のインターフェイス手順は、CC Switch プロジェクトドキュメントからのものです。読者自身の同意により、Codex バージョン、CC Switch バージョン、リクエストログ、およびツール呼び出し結果を保存する必要があります。方法 2: オンラインブリッジングに OpenRouter BYOK を使用する

ローカル変換レイヤーを実行したくない場合は、BYOK を使用して OpenRouter の Responses API ベータ版を評価できます。 BYOK は上流サプライヤーのキーを OpenRouter にバインドし、OpenRouter がルーティングを担当します。 OpenRouter API キーは依然として Codex アクセスに使用されます。

OpenRouter は現在、Responses API をベータとしてマークしており、これがステートレスな実装であることに注意しています。インターフェイスの機能と Codex に必要なイベントは今後も変更される可能性があるため、このルートを長期的な作業に使用するかどうかを決定する前に検証する必要があります。

ここで最もよく間違って記述されるのは、環境変数です。 Codex は OpenRouter にアクセスするため、env_key は通常、DEEPSEEK_API_KEY ではなく、OPENROUTER_API_KEY である必要があります。 DeepSeek キーは、OpenRouter の BYOK またはプロバイダーキーの設定に追加する必要があります。

構成例:

1
2
3
4
5
6
7
8
9


[profiles.deepseek-openrouter]
model = "deepseek/deepseek-chat"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"
wire_api = "responses"

起動方法:

1
2


export OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

パワーシェル:

1
2


$env:OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

次に、OpenRouter バックエンドに DeepSeek プロバイダーキーを追加し、この BYOK キーの使用を許可する OpenRouter API キーを制限します。モデル ID は、OpenRouter の現在のモデルディレクトリに基づいている必要があります。 DeepSeek の正式なモデル名を直接コピーして、それが利用可能であると仮定することはできません。

Codex を開始する前に、Responses エンドポイント自体を確認します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


$headers = @{
  Authorization = "Bearer $env:OPENROUTER_API_KEY"
  "Content-Type" = "application/json"
}

$body = @{
  model = "从 OpenRouter 模型目录复制的 DeepSeek ID"
  input = "只回复 READY"
  max_output_tokens = 16
} | ConvertTo-Json -Depth 6

Invoke-RestMethod `
  -Uri https://openrouter.ai/api/v1/responses `
  -Method Post `
  -Headers $headers `
  -Body $body

このリクエストは成功しました。これは、基本的な応答呼び出しが利用可能であることを証明するだけです。ファイルの読み取り、パッチ、ストリーミング応答、ツール呼び出しもステージングリポジトリで検証して、Codex ワークフローを満たしているかどうかを判断する必要があります。

このパスにより、ローカルゲートウェイのメンテナンスの必要がなくなりますが、オンラインの中間層が追加され、Responses はまだベータ版です。トラブルシューティングの際は、Codex、OpenRouter、および上流の DeepSeek のエラー情報を個別に保存してください。モデル名 deepseek-chat を引き続き使用しますか?

2026年5月のDeepSeek公式ドキュメントの説明では、推奨モデル名としてdeepseek-v4-flashとdeepseek-v4-proが登場しており、deepseek-chatとdeepseek-reasoner互換エイリアスは2026年7月24日以降に廃止されることが示唆されています。

したがって、新しい構成でのテストを優先することをお勧めします。

1

model = "deepseek-v4-flash"

OpenRouter を使用する場合は、OpenRouter モデルの命名に従ってそれを記述する必要があります。次に例を示します。

1

model = "deepseek/deepseek-chat"

実際に使用可能な名前は、使用しているゲートウェイまたは OpenRouter モデルページによって異なります。モデル名が間違っている場合、通常、エラーは `model not found`、404 として表示されるか、プロバイダーが対応するエンドポイントを見つけることができません。 DeepSeek 公式のbase_url を直接変更することが推奨されないのはなぜですか?

もちろん、次のように書いてみることもできます。

1
2
3
4
5
6
7
8


[profiles.deepseek-direct]
model = "deepseek-v4-flash"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"

ただし、これはデバッグ実験に似ており、安定したソリューションとしては適していません。 Codex は Responses プロトコルに従ってカスタムプロバイダーと通信し、公式の DeepSeek 例では `/chat/completions` を使用するためです。将来、DeepSeek または Codex が互換性レイヤーを完成させれば、この直接接続が簡単になる可能性があります。それまでは、ブリッジ層の信頼性が高くなります。構成を変更した後も OpenAI を使用する場合はどうすればよいですか?

まず設定ファイルの場所を確認します。グローバル構成は次の場所にある必要があります。

1

~/.codex/config.toml

プロジェクトの .codex/config.toml は、model_provider や model_providers などのマシンレベルのプロバイダー構成には適していません。 OpenAI 公式ドキュメントでは、プロジェクトレベルの構成ではこれらのローカルプロバイダーや認証関連のフィールドはカバーされないことも注意しています。

codex logout を一般的なトラブルシューティングの最初のステップとして扱わないでください。公式ログインステータスとサードパーティプロバイダーの設定は別の問題です。性急に撤退しても復旧コストが増大するだけです。まず、使用中のプロファイル model_provider、モデルディレクトリ、およびローカルルーティングログを確認します。

一時パラメータを使用して簡単な検証を行うこともできます。

1

codex --profile deepseek-openrouter

または:

1

codex -c model_provider=openrouter -c model="实际模型 ID"

これが有効になると、構成自体が読み取り可能であることを意味します。有効にならない場合は、まずプロファイル名、TOML 構文、および環境変数が現在のシェルでのみ有効かどうかを確認してください。トラブルシューティングのチェックリスト

401: キーが間違っているか、env_key が間違った環境変数を指しています。
404: base_url またはモデル名が間違っているか、応答リクエストがチャット完了のみをサポートするアドレスに送信されている可能性があります。
tool_calls、パッチ、ストリーミング解析エラー: プロトコルブリッジが不完全である可能性があります。
引き続きデフォルトの OpenAI モデルが表示されます。ユーザーレベルの構成、プロファイル、および /model の結果を確認します。最初にログイン状態を削除しないでください。
PowerShell で環境変数を設定した後に開かれる新しいウィンドウが失敗する: $env:... これは、現在のセッションに対してのみ有効です。長期間保存する必要がある場合は、ユーザー環境変数を変更してください。

- OpenRouter BYOK は独自の DeepSeek キーを取り除きません。OpenRouter バックグラウンドプロバイダーキーがバインドされているかどうか、現在の OpenRouter API キーの使用が許可されているかどうか、およびフォールバックが有効になっているかどうかを確認します。結論

Codex に DeepSeek を使用させます。 config.toml を変更できないわけではありませんが、base_url を変更するだけで、すべてが自動的に互換性を持つことを期待することはできません。

現在確認できる方法は次の 2 つです。

CC スイッチのローカルルーティングを使用して、応答とチャット完了を変換します。
OpenRouter Responses API ベータ版を使用し、独自の DeepSeek キーへの BYOK ルーティングと組み合わせます。

どちらの方法も、達成基準として「文を返す」ことだけに依存することはできません。少なくとも、モデルの選択、ストリーミング出力、ファイルの変更、ツール呼び出し、エラー回復、およびキーが実際に予期されたプロバイダーに送信されることを確認してください。

参考文献:

より安定したアプローチは、Codex と DeepSeek の間に「翻訳レイヤー」を置くことです。一般的なルートは 2 つあります。 方法 1: CC スイッチを使用した DeepSeek ローカル ルーティング

より安定したアプローチは、Codex と DeepSeek の間に「翻訳レイヤー」を置くことです。一般的なルートは 2 つあります。方法 1: CC スイッチを使用した DeepSeek ローカルルーティング