DeepSeek（画面上の表示はV4 Pro 0813）、Kimi、Grokを外部ルーティング経由で試しました。目的は、CodexのSol/ultraとLuna/max以外の選択肢を確かめることです。日常の実装やレビューを任せられる接続経路があるかを見ました。なお、表示名の正確な外部モデルIDや性能順位を確定する検証ではありません。
結論は「別の構成へ戻った」ではありません。外部モデルを試しても、1本目で決めたCodex内の構成を変えなかったという結果でした。モデルの能力に不満があったからではなく、連携の素直さ、サブスクリプションの利用量、増えた管理コストを合わせて判断したためです。
外部モデルを試した結果、構成は変えなかった
DeepSeekとKimiは自分のCodex設定では会話履歴のデータ形式エラーが出て、subagent実行まで進まなかった。Grokは動いた。今回は性能ベンチマークをしていないため、モデルの能力順位は判断していない。いまの個人開発ではCodexアプリ内のSol/ultraとLuna/maxを使い分けるほうが管理しやすいと判断した。
Vercelで使った経路は、正式にはAI Gateway
今回使ったVercelの経路は、公式には「Vercel AI Gateway」と呼ばれるサービスです。複数のモデルやプロバイダーを一つのAPIから扱い、モデルの切り替え、ルーティング、フォールバック、利用量の確認をまとめるためのゲートウェイです。
これはOpenRouterと同じサービスではありません。どちらも複数モデルへつなぐ発想は似ています。今回、OpenRouterそのものを使ったわけではなく、Codex側の設定を便宜上「OpenRouterに似た設定」と表現しています。記事ではVercelの経路をAI Gateway、Codex側で試した外部モデル接続を別のものとして書き分けます。サービス名を混ぜると、どこで起きた問題なのか分からなくなるからです。
AI Gatewayを使うと、同じ入力をモデルだけ変えて比較しやすくなります。ただし、呼び出せることと、Codexのsubagentとして会話履歴やツール呼び出しまで自然につながることは別の条件です。
比較したかったのは性能順位ではなく、つながり方
今回の検証では、ベンチマークの順位や一問ごとの正答率を測っていません。個人開発の運用へ組み込めるかを、次の観点で見ました。
- Codexからsubagentとして呼び出せるか
- 会話履歴、ツール呼び出し、結果の受け渡しが崩れないか
- モデルやプロバイダーを増やした分だけ、設定と確認の手間が増えないか
外部モデルを同じ画面で呼べても、履歴の形式が合わずに毎回手で貼り直すなら、実働の速さは失われます。比較対象はモデル単体ではなく、モデルを仕事の流れへ接続した状態でした。
DeepSeekとKimiは、自分の設定ではsubagentまで進まなかった
画面上でDeepSeek V4 Pro 0813と表示された接続先とKimiは、Codex側に外部モデルを登録する設定までは試しました。ただ、subagentとして会話を開始すると、会話履歴のデータ形式エラーが出て、実際の作業を任せるところまで進みませんでした。表示名の正確なモデルIDや、エラーの再現条件までは確認していないため、ここでは自分の設定で起きた事実だけを記録します。
Grokとの違いは、接続可否として切り分けた
一方、Grokは同じ目的の設定でsubagentとして動きました。この差から分かったのは、モデルの賢さの順位ではなく、接続先が期待する履歴形式やツール仕様の差です。この結果は私の設定で観測したもので、DeepSeekやKimiが一般にCodexで使えないという意味ではありません。
| 接続先 | 試した経路 | 自分の環境での結果 | 判断への影響 |
|---|---|---|---|
| DeepSeek（表示名: V4 Pro 0813） | AI GatewayとCodex側の外部モデル設定 | 履歴のデータ形式エラーでsubagent実行まで進まず | 性能比較ではなく接続仕様の切り分けが先になった |
| Kimi | AI GatewayとCodex側の外部モデル設定 | 履歴のデータ形式エラーでsubagent実行まで進まず | 同じく運用へ組み込めなかった |
| Grok | AI GatewayとCodex側の外部モデル設定 | subagentとして動作 | 接続できるモデルがあることを確認した |
ここで「Grokだけを採用する」という結論にもできました。でも、それでは検証の目的がモデルの追加に置き換わります。動いた後に、既存の運用より何が良くなるのかまで確かめる必要がありました。
Grokが動いても、モデル数を増やす理由にはならなかった
Grokはsubagentとして動きましたが、DeepSeekやKimiの性能は今回の検証では判定していません。問題は、性能が足りるかどうかを測る前に、モデルを追加するとプロバイダーごとの設定、履歴形式、ツール呼び出し、利用量、エラー時の切り分けを覚える必要があることです。
外部モデルを増やす効果が出るのは、特定の作業で明確な差があり、その差が接続・監視・レビューの手間を上回るときです。今回の個人開発では、まずCodex内で困っている作業を減らすことのほうが優先でした。
Codexアプリ内のSolとLunaが一番素直だった
1本目で決めたSol/ultraとLuna/maxの分担は、Codexアプリの中で完結します。Sol/ultraでプロジェクト設計や厳密レビューを行い、決まった作業をLuna/maxへ渡す。モデルの切り替え、会話の続き、作業結果の確認が同じ環境にあります。
前の記事で整理したLuna/maxとSol/ultraの使い分けは、この連携の素直さを前提にしています。外部経路を試したことで、どのモデルが一番賢いかより、指揮と実働を一つの作業環境で続けられることの価値がはっきりしました。
Codexのサブスク利用量で足りる範囲を先に固定した
もう一つの理由は、現在の作業量ならCodexのサブスクリプションで足りていることです。ここでいう「足りる」は、すべてのモデルを使い放題という意味ではありません。設計が必要な仕事をSol/ultraへ絞り、定型実装やテストをLuna/maxへ寄せた結果、外部プロバイダーを追加しなくても作業が回っています。
利用量が足りないからといって、すぐ別サービスを足すのではなく、まず何に推論を使っているかを見直します。以前の比較で確認した利用枠と手戻りも含め、必要な作業へ枠を配るほうが、いまの自分には分かりやすい方法でした。
管理コストまで含めて、構成は変えないと決めた
今回の判断を表にすると、能力ではなく運用の差が中心です。
| 判断軸 | 外部モデルの検証 | Codex内の構成 |
|---|---|---|
| モデルを試す自由度 | 複数プロバイダーを切り替えやすい | SolとLunaの役割を固定しやすい |
| subagent連携 | モデルごとに履歴・ツールの相性を確認する | 同じアプリ内で会話と作業を続ける |
| 利用量の管理 | サービスやプロバイダーごとに確認する | Codexの利用量としてまとめて見る |
| いまの採用判断 | 明確な得意分野が見つかるまで保留 | 現在の基本運用として継続 |
他モデルを否定したいわけではありません。DeepSeek、Kimi、Grokを試したことで、外部モデルを追加するなら「何が改善するのか」を先に決める必要があると分かりました。現時点では、管理コストまで含めると、Sol/ultraとLuna/maxの構成が最もコスパがよいという判断です。
今後、特定モデルでレビュー品質や長いコンテキスト処理に明確な差が出れば、外部モデルを再検討します。ただ、今回の検証結果は「別モデルへ乗り換える」ではなく、「いまの構成を変えない理由が増えた」と記録しておきます。
Vercel AI Gatewayの確認先
外部モデルを試すときは、呼び出しに成功したかだけで終わらせず、会話履歴、ツール、利用量、エラー対応まで自分の作業に組み込めるかを確認します。今回の検証では、その確認をした結果として、Codex内の構成を続けることにしました。
