「Codex 裏技」を検証 — サブエージェントのモデル指定は codex-router なしでできる

codex-router というツールで Codex のサブエージェントを DeepSeek V4-Flash に置き換えれば開発費が激減する、という投稿が X で拡散している。

【速報】「Codex裏技」によりClaude解約者が続出中でヤバすぎる！！

DeepSeek V4-Flash等の格安モデルをCodexのサブエージェントとして爆速稼働させ、コストを劇的にカット可能に

・設定ツール『codex-router』を入れるだけの「3分」超簡単セットアップ ・メイン／サブモデルの切り替えや複数並列活用でAI開発費を最小化 ・高額サブスク不要！低コスト＆ハイパフォーマンスな環境が即完成

先に結論を書くと、ツールもモデルも実在し、やろうとしていること自体は妥当だ。ただし「裏技」ではない。サブエージェントに別モデルを割り当てるのは Codex の公式機能で、外部ツールなしに設定ファイルだけでできる。そして「高額サブスク不要」は、どちらの方法でも成立しない。

codex-router と DeepSeek V4-Flash は実在するか

まず、名前が出ているものを確認した。

codex-router とは何か。 Codex の openai_base_url をローカルで動くルータープロセスに向け、LiteLLM 経由で他社モデルを Codex から使えるようにする、コミュニティ製のツールだ。README には次のように明記されている。

Codex Router is an independent community project. It is not affiliated with or endorsed by OpenAI, Anthropic, Moonshot AI, DeepSeek, OpenRouter, opencode, or the referenced opencodex project.

OpenAI 公式ではない。拡散投稿にはその区別が書かれていないので、まずここを押さえておきたい。

「裏技」ではない — Codex 純正のサブエージェント・モデル指定

サブエージェントごとのモデル指定は、かつて OpenAI/codex の Issue #11701 として要望されていた機能だ。この Issue は 2026年2月19日に completed でクローズされており、現在は公式ドキュメントに載っている。

Codex のサブエージェント（Swarm）そのものの解説は OpenAI Codex の SubAgent（Swarm）が変える AI コーディングの未来 に譲る。ここでは**「別モデルを割り当てる」のに必要な最小の設定だけ**を示す。いずれも追加インストールなしで書ける。

設定構文は Codex 公式ドキュメント（Advanced Configuration / Subagents）の記載に基づくもので、筆者が実際に DeepSeek を繋いで動作確認したものではない。また [agents] が使えるかは Codex のバージョンに依存する。自分の環境で確認してほしい。

config.toml に外部プロバイダを登録する

~/.codex/config.toml に書く。

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

env_key に指定した環境変数を Codex が実行時に読み、Bearer トークンとして送る。予約済みのプロバイダ ID（openai、ollama、lmstudio）は再定義できない。

[agents] でサブエージェントの既定を指定する

同じ config.toml に書く。

[agents]
enabled = true
max_concurrent_threads_per_session = 4   # 旧名 max_threads も別名として有効
default_subagent_model = "..."           # プロバイダ側のモデル名を指定する
default_subagent_reasoning_effort = "low"

~/.codex/agents/*.toml でエージェントごとに上書きする

~/.codex/agents/（個人用）または .codex/agents/（プロジェクト用）に、エージェント1つにつき1ファイルの TOML を置く。name、description、developer_instructions が必須だ。

name = "explorer-cheap"
description = "コードベースの探索専用。読むだけで書かない。"
developer_instructions = """
渡されたパス配下だけを読む。変更は一切しない。
見つけた事実を file:line 付きで報告する。
"""
model = "..."                    # プロバイダ側のモデル名
model_reasoning_effort = "low"

カスタムエージェントのファイルで model を指定した場合、その値が優先される。指定がなければ、明示的な spawn 時の値 → [agents] の既定値 → 親の値、の順で解決される。

ここは注意が必要だ。 公式ドキュメントが custom agent ファイルで指定できるキーとして明示しているのは model や model_reasoning_effort などで、model_provider（＝サブエージェントだけ別プロバイダに向ける）が同じように効くかは、ドキュメントの記述からは確定できなかった。「サブエージェントだけ別プロバイダ」を厳密にやりたい場合は、ここが検証ポイントになる。 後述するルーターは、外部モデルを Codex のネイティブなモデル一覧にマージすることで、この段差を埋めている。

なお、これは Codex の話である。Claude Code には同等の仕組みがない。この違いをどう扱うかは記事の後半で改めて扱う。

codex-router が実際に足すもの

では、ルーターを入れる意味がないかというと、そうでもない。README を読むと、純正の設定だけでは得られないものが並んでいる。

• モデル一覧の統合 — 外部モデルを Codex のネイティブなモデルカタログにマージし、通常のモデルピッカーに GPT モデルと並べて表示する
• 認証情報の分離 — README によれば、呼び出し元を認証したうえで LiteLLM にはランダムな内部キーだけを渡し、最終段でプロバイダの認証情報を注入する。全リスナーは 127.0.0.1 にバインドされる
• 既存 CLI の OAuth セッション再利用 — Kimi Code CLI や Grok CLI に既にログインしていれば、その認証情報を使える
• 画像ブリッジ — テキスト専用モデルにスクリーンショットを貼ったときの処理。有効化済みの視覚対応モデルに画像を読ませ、その結果をテキストとして差し込む
• トレイ UI — macOS / Windows / Linux 向けの常駐パネルで、使用量やクォータを表示する

同種の「LLM ルーターでコストを下げる」アプローチは以前にも扱っている（ClawRouter、OpenRouter によるモデル一元管理）。対象ツールは違うが、判断の枠組みは共通だ。

構成はこうだ。Codex の openai_base_url を 127.0.0.1:4102 に向け、そこから LiteLLM（:4100）が Responses API を各社のプロトコルへ変換する。Codex 側のエージェントループ、ツール、権限、MCP サーバー、会話状態はそのまま Codex が持ち、ルーターはモデル推論とプロトコル変換だけを担う。

codex-router 導入で受け入れるもの

便利さの裏側も同じ README に書いてある。侵襲的な挙動を作者自身が文書化している点は、評価してよい（していないプロジェクトより判断材料が多い）。そのうえで、導入前に把握しておきたい点を挙げる。

通過するトラフィックの範囲

これが最も重要な差分だ。 openai_base_url はグローバル設定なので、サブエージェント分だけでなく、Codex が送るリクエストはすべてこのローカルプロセスを経由する。メインの会話も、そこに載るソースコードのコンテキストもだ。

純正の経路なら「サブエージェントのトラフィックだけが外部プロバイダへ出る」で済むが、ルーターを挟むと信頼境界そのものが動く。機能が1つ増えるという話ではない。

インストール方法

案内されている手順は次のとおりで、リモートのスクリプトをそのままシェルに流し込む形式だ。

curl -fsSL https://raw.githubusercontent.com/duolahypercho/codex-router/main/install.sh \
  | sh -s -- --target codex --guided

参照先はタグやリリースではなく main なので、実行した時点の内容が固定されない。チェックサム検証も手順に含まれていない。

前提パッケージと常駐サービス

Node.js 22.19 以上（24 LTS 推奨）、uv または Python 3.10 以上、Git が必要。加えて、モデル一覧の反映には Codex の完全終了と再起動が要る（Codex は model_catalog_json を起動時にしか読まない）。これらが未導入の環境で「3分」は厳しい。

インストール時にユーザーごとのバックグラウンドサービスが登録される。

元に戻せるか

README には disable（Codex 統合とサービスの解除）と uninstall が用意されている。ただし uninstall はチェックアウト、ログ、バックアップ、内部キー、プロバイダの認証情報を意図的に残すと明記されている。認証や復旧データを不用意に壊さないための設計だが、「完全に消える」わけではない点は把握しておきたい。

ネイティブスラッグでの再公開

「OpenAI ログインなしで使う」モードでは、外部モデルをネイティブの GPT スラッグ名で再公開する。README によれば、これは一部の Codex 画面がサーバー配信の allowlist を通ったスラッグしか表示しないためだという。この挙動が OpenAI の利用規約とどう関係するかは、筆者には判断できない。業務環境で使うなら、規約を自分で確認してほしい。

スター数についても一言。3週間で1,000超という増加は速いが、スター数はコードの品質も安全性も保証しない。むしろプロジェクト自体がまだ3週間という点のほうが、成熟度の判断材料としては重要だ。MIT ライセンスなので当然ながら無保証である。

コストは本当に下がるのか — DeepSeek V4-Flash と Claude の料金比較

X 投稿が「Claude 解約」を見出しにしているので、Claude 側の価格と並べる。いずれも 100万トークンあたりの API 料金（USD）。

出力トークンで見ると、DeepSeek V4-Flash は Opus 5 の約 1/89、Sonnet 5 の約 1/54、Haiku 4.5 の約 1/18 だ。桁が違う。

ただしこの差がそのまま請求額の差になるわけではない。

効く場面：サブエージェントの仕事は、探索・読解・抽出が中心になりやすい。入力トークンが多く、出力が少なく、難しい推論をあまり要求しない。ここを安いモデルに寄せて、計画・検証・統合だけを高性能モデルに残す構成は、マルチエージェント設計の定石として各所で紹介されている。DeepSeek V4-Flash はキャッシュヒット時の入力単価がさらに下がるとされているので、同じコンテキストを繰り返し読ませる用途では効果が大きくなる。

効かない場面：安いモデルの精度が足りずにやり直しが増えれば、往復回数が増えて総額は減らない。1回の実行あたりの単価ではなく、タスク1件を完了させるまでの総額で比べる必要がある。

そもそも安いモデルに逃げる前に、投げているトークン量そのものを減らせないかを先に潰すほうが効くことも多い。plan モード強制によるコスト削減 はその方向の話だ。

そして「高額サブスク不要」という部分。これは誤解を招く。 外部モデルを使うには各プロバイダと個別に契約し、API キーを取得する必要がある。従量課金はそのまま発生する。README にも、プロバイダによっては特定の有料プランが必須だと明記されている箇所がある。たとえば Command Code の Provider API は Provider プラン以上が必要で、Go プランではログインできても API アクセスが拒否される。サブスクが消えるのではなく、支払先が変わるだけだ。

「Claude 解約者が続出」は検証できない

投稿の見出しになっている部分だが、これを裏付ける情報は見つからなかった。解約率のような数字は各社が公開していないので、そもそも外部から検証できる種類の主張ではない。

投稿の他の部分——ツールとモデルの実在、サブエージェントへのモデル割り当て——は事実として確認できる。検証できないのは、この見出しだけだ。煽り文句と検証可能な中身が同じ投稿に同居しているので、切り分けて読みたい。

解約か併用か — Claude Code と Codex のモデルルーティングの差

「Claude 解約」という見出しは、乗り換えるか否かという二択を前提にしている。ただ、実際に検討すべきなのは併用の設計だ。ここは投稿が触れていない部分なので、補っておきたい。

Claude Code 側にできること・できないこと

per-subagent の外部プロバイダ振り分けは、Claude Code には存在しない。 サブエージェントに指定できるモデルは Claude のティア（opus / sonnet / haiku / fable）に限定されている。

紛らわしいのが ANTHROPIC_BASE_URL の存在だが、公式ドキュメント上のこれは LLM ゲートウェイ用である。用途は認証の集約・使用量トラッキング・レート制限で、向き先は Amazon Bedrock / Google Cloud / Microsoft Foundry / Anthropic API という Claude を配信するバックエンドだ。ANTHROPIC_BEDROCK_BASE_URL などのプロバイダ別変数も同様で、Codex の [model_providers.<id>] のような「任意の他社モデルを登録する」仕組みとは別物になる。ANTHROPIC_DEFAULT_OPUS_MODEL 等も Claude のバージョン固定用だ。

つまり Codex にあって Claude Code にないのは、モデルルーティングの粒度と自由度である。ここは事実として差がある。

この制約を Claude Code 側から見た検討は ローカルモデルに何を任せるか — Claude Code の開発ループに小さいモデルを混ぜる設計 に書いた。そちらの結論は「subagent 単位の振り分けはできないので、ツール化が本命」だが、これは Claude Code の機構の話であって、本記事の Codex の話と矛盾するものではない。製品によって打てる手が違う、というだけだ。

ただし「だから併用が有利」は直結しない

ここで議論が2つ混ざりやすい。

• コスト：高ボリューム・低判断の仕事を安いモデルに流す → Codex のほうがやりやすい
• 品質：出力の正しさを上げる → これは別の話

品質が上がるとすれば、それはモデルが増えたからではなく、独立した検証が入るからだ。ここを取り違えると効かない。

効く使い方：モデルファミリが違えば失敗モードも違う。片方が見落とすバグをもう片方が拾う。仕様の解釈違いも表に出る。実質的には、敵対的レビューを別系統で回すということになる。

効かない使い方：同じタスクを同じプロンプトで両方に投げて「両方 OK なら安心」とするパターン。合意は検証ではない。 2つのモデルが同じ誤りに合意すると、根拠のない確信だけが増える。単一のモデルが「自信がない」と言ってくれるほうがまだましだ。

見落としやすいコスト

併用は harness が2つになるということでもある。権限モデルが2つ、コンテキストの置き場が2つ、設定ファイルが2セット。受け渡しは基本的にファイル経由になる。

この境界を埋めるための道具は既にある。Matt Pocock 氏が公開している mattpocock/skills の /handoff スキル（skills/productivity/handoff/）は、Claude Code のセッション文脈を「別のエージェントが引き継げる構造化 Markdown」に圧縮することに特化している。目標・現状・未決定事項などを書き出し、既存の PRD やコミットの内容は繰り返さずパスや URL で参照するだけに留める設計だ。

このスキルを使って「Claude Code で計画し、複数の Codex に並列投入する」ワークフローは /handoff スキルが海外でバズった理由 で扱った。分業に承認ゲートを挟む設計は 「計画するAI」と「書くAI」を分ける開発手法 が詳しい。

裏を返せば、こういう道具が必要になること自体が併用のコストである。同一 harness 内なら共有されている文脈を、わざわざファイルに落として詰め直す工程が挟まる。ここは併用の便益から差し引いておきたい。

用途で置き場を分ける

以上を踏まえると、併用の設計はこう整理できる。

3行目が肝心だ。委譲してよいのは証拠の圧縮であって、証拠からの結論ではない。読解や抽出を安いモデルに任せるのはよいが、その結果から「合格」を判断させるところまで渡すと、コストは下がっても品質は下がる。

効果は測らないと分からない

最後に。併用で本当に品質が上がるかは、ワークロードごとに違う。そしてこの種の「体感で良くなった」は当てにならない。METR が2025年7月に公開したランダム化比較試験では、AI ツールを使えた条件のほうが19%遅かったにもかかわらず、当人たちは「20%速くなった」と感じていた。体感と実測は逆方向にずれることがある。

判断するなら、切り替え前後で 同じタスクを完了させるまでの総額と、レビューで差し戻った回数を比べるのが確実だ。単価でも体感でもなく。

codex-router を導入する前に確認する5点

安いモデルをサブエージェントに割り当てる構成自体は妥当なので、試すなら順番を守るのがよい。

1. まず純正の設定で試す。 [model_providers] と [agents] で足りるなら、常駐サービスも curl | sh も不要だ
2. 足りないものを特定してからルーターを検討する。 モデルピッカーへの統合、認証情報の分離、複数 CLI の OAuth 再利用が本当に必要かを先に確かめる
3. トラフィックの範囲を理解する。 ルーターを挟むと、サブエージェントだけでなく全リクエストがそのプロセスを通る
4. コストは総額で測る。 単価ではなく、タスク1件を完了させるまでの請求額を切り替え前後で比べる
5. タスクを選ぶ。 探索・読解・抽出は安いモデルに、設計判断と最終検証は高性能モデルに残す

まとめ

• codex-router も DeepSeek V4-Flash も実在する。やろうとしている構成も妥当
• ただしサブエージェントへのモデル割り当ては Codex 純正の機能で、設定ファイルだけで書ける。「裏技」ではない
• ルーターが足すのはモデル一覧の統合・認証情報の分離・トレイ UI。その代わり、Codex の全リクエストがサードパーティ製のローカルプロセスを通る構成を受け入れることになる。OpenAI 公式ではない
• 「高額サブスク不要」は誤解を招く。各プロバイダとの契約と従量課金は残る
• 「Claude 解約者が続出」は、外部から検証できる種類の主張ではない
• モデルルーティングの自由度は確かに Codex が上。ただし「だから併用が有利」は直結しない。品質が上がるのはモデルが増えたからではなく、独立した検証が入るからであって、合意は検証ではない

やりたいことが「サブエージェントを安いモデルで回す」なら、まず設定ファイルを2つ書くところから始めればいい。それで足りなかったときに、初めてルーターを検討する順番になる。

そして「Claude を解約するか否か」という二択も、たぶん問いの立て方が違う。決めるべきはどこに独立した第二意見が欲しくて、どこは安い処理能力があれば足りるのかであって、ツールの本数ではない。

同じようにバイラル投稿を一次情報で検証した記事に、「AI時代にテックリードは死ぬ」を検証 と 「Claudeだけで6500万ドル」バイラル投稿の真相 がある。