CodexにDeepSeek V4、GLM 5.1、K2.6を接続する方法｜プロトコル変換と2つの解決策

CodexでDeepSeek、GLM、Kimiのような第三者大規模モデルのAPI Keyを直接入力したい場合、おそらく思っているようには動作しないだろう。

問題は、入力したKeyが無効であるとか、アカウントが使えないということではない。プロトコルが完全に一致しておらず、正常に通信できないことが原因だ。

現在の新版 Codex CLI / Codex App のAPI Keyモードを例にとると、デフォルトの通信経路はOpenAI Responses APIになっている。一方、多くの第三者モデルが主に提供しているのはOpenAI互換のChat Completionsだ。

双方はメッセージ構造、ストリーミング応答、推論（reasoning）フィールド、ツール呼び出し（tool call）の表現方法に違いがあるため、「Base URLを変えてKeyを入力すればすぐ動く」と単純には考えられない。

したがって、第三者モデルを接続する際に本当に解決すべきことは「API Keyを入力すること」ではなく、以下の点だ。

Codexが送信するリクエストを第三者モデルが理解できるようにし、第三者モデルが返す内容をCodexが認識できる形式に変換することだ。

現在知られている一般的な手法は主に2つある。

• CC-Switch：ローカルプロキシとプロトコル変換を用いる方法。
• Codex++：Codexデスクトップアプリの強化と設定注入に特化した方法。

いずれもCodexに第三者モデルを接続するのに役立つが、問題を解決するポイントが異なる。前者は主にプロキシ層でプロトコルを変換し、後者は主にCodexデスクトップアプリの設定とUI層で強化を行う。

単に第三者モデルを接続したいなら、まずCC-Switchを検討すべきだ。Codexデスクトップ版を主に使用し、プラグインエントリやUIの強化も希望する場合は、Codex++を見てみよう。

1. CC-Switchルート：低侵入の設定切替方案

1.1 CC-Switchとは

CC-Switchは、複数のAIコーディングツールの設定センター兼ローカルルーティングプロキシに近い存在だ。もともとはClaude Code用に開発されたが、その後Codex、Gemini CLI、OpenCode、OpenClawといったツールにも拡張された。

余談だが、このオープンソースプロジェクトはAI時代に作られた非常に優れた製品の一つで、AIの波に乗り人気を博し、現在Star数は9万に近づいている。批判的な声もあるが、作者が真剣にメンテナンスしており、体験も良好なことは否定できない。

Codexのシナリオでは、主に以下の2つのことを行う。

• 設定切替：異なるコーディングツールの設定を統合管理し、ワンクリックでプリセットの切替、テンプレートのインポート、プロバイダーの切替をサポートする。
• ローカルプロキシ：ローカルマシンでHTTPサービスを起動し、Codexからのリクエストをプロトコル変換・ルーティング分配して、第三者モデルに転送する。

核心となるポイントは一つだ。Codex自体は変更せず、設定だけを変え、プロキシを起動するという点だ。

1.2 インストールと設定

設定の前に、Codexが現在API Key / ローカル設定ルートを使用していることを確認することを推奨する。ChatGPTログインルートと混在すると、リクエストパスが不明確になり、エラーの原因判別が困難になる。また、Codexを少なくとも1回実行し、設定ファイルを初期化しておくと、後のルーティング設定がしやすい。

• CC-SwitchのGitHubリポジトリ [1] を開き、インストーラをダウンロードしてインストールする。
• CC-Switchを起動し、右上の + をクリックしてプロバイダーを追加する。ここではDeepSeekを例にする。

• 基本的にはAPI Keyを入力するだけで良い。ローカルルーティングマッピングが必要な場合は、Needs Local Routing が有効になっていることを確認する。通常はデフォルトで有効な状態だ。

• メインページに戻り、左上の歯車アイコンをクリックして設定に入り、「ルーティング」を開く。下図のように、ローカルルーティングボタンを有効にする。このとき下部に表示される総リクエスト数は 0 だが、この数字でCodexが実際にCC-Switchを経由したかどうかを判断できる。

• Codexを再起動し、メッセージを送信して、正常に返信が得られるか確認する。

• CC-Switchのルーティング設定画面に戻り、リクエスト記録が表示されれば、設定が有効になっていることを示す。

以上で、CC-Switchルートは動作するようになる。

2. Codex++ルート：より深い強化方案

2.1 Codex++とは

Codex++は汎用的なプロトコル変換プロキシではなく、Codexデスクトップアプリの外部強化ランチャーに近い。

BigPizzaV3/CodexPlusPlus [2] を例にとると、Codex Appのオリジナルインストールファイルは変更せず、外部ランチャーを使用してCodexを起動し、Chromium DevTools Protocol（CDP）を介して実行時にCodexのレンダリングプロセスに強化スクリプトを注入する。プロバイダー設定は独立した管理ツールから ~/.codex/config.toml に書き込まれる。

したがって、CC-Switchとは重点が異なる。

• CC-Switchは主にリクエストの転送方法とプロトコル変換を解決する。
• Codex++は主にデスクトップアプリの強化方法、設定の注入方法、プラグインエントリの使用方法に関心を持つ。

ここで注意すべき点として、別の独立プロジェクト b-nnett/codex-plusplus [3] が存在する。これは app.asar を修正してLoaderを注入するもので、本記事で説明するBigPizzaV3版とはアーキテクチャが全く異なる。以下で述べるCodex++は、特に断りのない限りBigPizzaV3版を指す。

2.2 インストールと設定

• BigPizzaV3/CodexPlusPlus [4] を開き、対応するOSのインストーラをダウンロードする。
• インストール後、デスクトップに2つのエントリが現れる： Codex++ と Codex++管理ツール 。管理ツールはプロバイダーの設定に使用し、 Codex++ はオリジナルのCodexアイコンの代わりに起動するために使用する。

Codex++ ランチャーを先に実行する必要がある。そうすることでCDPを介してCodexに強化スクリプトを注入できる。直接オリジナルのCodexアイコンをクリックするとこのステップをスキップし、強化機能は有効にならない。

• Codex++管理ツール を起動し、プロバイダー設定を選択して、プロバイダーを追加する。DeepSeekを例にする。

  • 接続モード：「ピュアAPI」を選択する。
  • Base URL：Codex++の内蔵プリセットまたはインターフェースの指示に従って入力を優先する。DeepSeek公式ドキュメントが現在示しているOpenAI互換のBase URLは https://api.deepseek.com だ。ツールがOpenAIスタイルの /v1 を要求する場合は、 https://api.deepseek.com/v1 と入力する。
  • API Key：あなたのKeyを入力する。
  • アップストリームプロトコル： Chat Completions を選択する。

• 設定完了後、 Codex++ アイコンからCodexを起動する。Codexがすでに実行中の場合は、一度終了してから起動するか、右上の再起動ボタンをクリックする。直接オリジナルのCodexデスクトップアイコンを開くと、強化スクリプトは介入せず、元のCodexが動作する。

• 最終的なページの表示は以下の通りだ。

2.3 Codex++が行うこと

Codex++の強化スクリプトは主に3つのことを行う。

第一は第三者設定の書き込みだ。すべてのリクエストを横取りして書き換えるのではなく、カスタムプロバイダーをCodexのネイティブ設定（例えば ~/.codex/config.toml）に書き込み、Codex自体にこのプロバイダーを通じて第三者サービスにアクセスさせる。簡単に言えば、ネットワーク層で強制的にリクエストを横取りするのではなく、「Codexの経路を設定してやる」ようなものだ。

第二はCodex Appへのエントリ追加だ。Codex++からCodexを起動すると、CDPを使用して強化スクリプトが注入され、トップメニューバーにCodex++のステータスと設定エントリが追加される。プロバイダーの追加や設定の切替といった実際の操作は、依然として独立した「Codex++管理ツール」で行われ、Codexのオリジナルウィンドウ内で直接設定されるわけではない。

第三はデスクトップアプリの強化機能の追加だ。例えばAPI Keyモードでは、CodexのオリジナルプラグインエントリはChatGPTへのログインが必要だと表示されることがある。Codex++で起動するとこのエントリがロック解除され、さらにセッション削除、Markdownエクスポート、Timeline、プロバイダー同期などの強化機能が追加される。

3. 接続原理：Codexは結局何を接続しているのか

上記の2つのルートは一見異なるように見えるが、実際に詰まりやすいポイントは同じだ。Codexが発するモデルリクエストを、第三者サービスが受け止められるかどうかだ。

API Keyモードを例にとると、Codexはおおよそ以下のように動作する。

ユーザー入力
-> Codex Agentがタスクを編成
-> ~/.codex/config.toml を読み込む
-> model_provider に基づき対応するプロバイダーを見つける
-> base_url、API Key、wire_api などの設定を取り出す
-> モデルサービスにリクエストを送信
-> モデルが結果を返す
-> Codexがレスポンスを解析
-> ツール呼び出し、ファイル編集、コマンド実行などのアクションを継続する

ここで最も重要なのはいくつかの設定項目だ。

• model_provider：現在使用するモデルプロバイダー。
• base_url：リクエストの送信先。OpenAIでも、第三者の中継、ローカルプロキシ、または自社内部のモデルゲートウェイでも良い。
• env_key：API Keyをどの環境変数から読み取るか。Keyを設定ファイルに直接書き込むことを避ける。
• wire_api：Codexがモデルサービスとの通信にどのプロトコルを使用するか。例えば responses や chat など。

最後の wire_api が非常に重要だ。

通常のチャットインターフェースが一文を返せるからといって、CodexのAgentフローをサポートできるとは限らない。Codexは単に質問をモデルに送って答えを表示するだけでなく、ストリーミングレスポンス、ツール呼び出し、推論、状態フィールドを解析し、さらにファイルの読み取り、コードの修正、コマンドの実行を続ける必要がある。

したがって、第三者モデルを接続できるかどうかは、「OpenAI互換であるかどうか」だけでなく、Chat Completionsと互換性があるのか、それともCodexが現在使用するResponsesリンクを完全に受け止められるかどうかで判断する必要がある。

3.1 なぜBase URLだけを変えてはいけないのか

Codexは現在、OpenAI Responses APIの使用を好む傾向にあるが、多くの第三者モデルが提供するのはChat Completities APIだ。両者は同じものではない。

Responses APIはエージェントシナリオに適しており、より多くの状態やイベント構造に関与する。Chat Completities APIは従来の対話インターフェースに近く、核心は messages リストとモデルの返信だ。通常のチャットツールでは messages を送信できれば十分だが、Codexはツール呼び出し、ストリーミングイベント、コンテキスト、推論、タスク状態などの内容を処理する必要がある。

そのため、第三者モデルをCodexに接続する際、本当に面倒な点は「リクエストが送信できない」ことではなく、「リクエストとレスポンスが双方で正しく理解できるかどうか」だ。

3.2 CC-Switchの原理：プロキシ層での変換

CC-Switchのローカルプロキシが行うのはプロトコル変換だ。

• Codexから来たResponsesリクエストをChat Completionsに変換し、上流に転送する。
• 上流から返されたSSEストリーミングレスポンスをResponsesとして再パッケージし、Codexにプッシュする。
• 推論コンテンツ、ツール呼び出し、 previous_response_id などの状態フィールドを処理する。

まさに中間に変換層があるため、第三者モデルが安定して動作するかどうかは、モデル自体だけでなく、プロバイダーの互換性とプロキシの実装にも依存する。

もし上流自体がResponses APIをサポートしていれば、プロキシはChat Completionsへの変換レイヤーを省略でき、主に認証注入、使用量追跡、ヘルスチェックなどの作業を担う。

3.3 Codex++の原理：デスクトップアプリでの強化

Codex++はよりCodex Appデスクトップアプリの強化 ＋ プロバイダー設定の書き込み/同期に重点を置いている。CC-Switchのようにすべてのリクエストをローカルプロキシ層に集約してプロトコル変換を行うのではなく、ランチャーを介してCodexを起動し、CDPを使用して強化スクリプトを注入することで、Codex Appに追加のメニュー、設定エントリ、プラグインエントリ、プロバイダー切替機能を持たせる。

簡単に言えば、 CC-Switchは主に「リクエストのルーティング方法とプロトコル変換方法」を解決し、Codex++は主に「Codexデスクトップアプリの強化方法、および第三者プロバイダーのより便利な書き込みと切替方法」を解決する。

4. 選択ガイド：CC-SwitchかCodex++か

結論を先に言えば、大多数のユーザーはCC-Switchを選択すれば十分だ。これも私がデフォルトルートとしてより推奨する方法だ。

4.1 ニーズによる選択

• 主にCodex CLIを使用し、同時にClaude Code / Gemini CLIも実行する：CC-Switchを選択。
• Codexデスクトップ版のみを使用し、プラグインエントリやUIの強化も希望する：Codex++を選択。
• Codexのインストールファイルを一切変更したくない：CC-Switchを優先。
• プロトコル変換とローカルルーティングがすぐに使えることが望ましい：CC-Switchを優先。
• デスクトップアプリの強化、プラグインエントリ、スクリプト注入をいじりたい：Codex++を検討。

4.2 機能の互換性

第三者モデルを接続した後、Codexのすべての機能が完全に代替できるとは限らない。現実的な状況は以下の通りだ。

完全に利用不可能、または同等の代替が困難：

• Image Gen：OpenAIの対応する画像生成能力に依存しており、第三者のテキストモデルでは直接代替できない。
• Computer Use：Responses API内蔵のcomputer actionタイプ、ローカルランタイム、スクリーンショットのフィードバックループに依存している。Chat Completionsプロトコルおよび通常の第三者モデルは同等の能力を通常提供できず、プロトコル変換層でも補うことは困難だ。

劣化はあるが利用可能：

• 通常のSkills / プラグイン：Codex++のページ強化と組み合わせることで、一部のシナリオでは使用可能だが、安定性はバージョンによる。
• ツール呼び出し：基本的なコード編集、ファイルの読み書き、コマンド実行は通常実行できるが、複雑なツール呼び出しや長時間のタスクでは、フォーマットや互換性の問題が発生する可能性がある。

概ね正常に動作：

• コード作成
• デバッグとリファクタリング
• ファイルの読み書き
• プロジェクト管理
• マルチターン対話
• タスクプランニング

4.3 より合理的な使用方法

• 軽量なコードQ&A、テキストタスク、簡単なスクリプト：DeepSeekなどのコストの低いモデルには、明確な価格優位性がある。
• 複雑なエンジニアリングプロジェクト：まずより強力なGPTで計画を立て、その後、第三者モデルで簡単なサブタスクを処理する。
• もしGPT Plus / Proの利用枠が十分にあるなら：ネイティブ体験が依然として最も安定しており、必ずしも余計な設定を行う必要はない。