OpenCodexプロジェクト分析 — Codex・Claude Code用マルチLLMプロキシ

OpenCodexはCodexのResponses APIリクエストを各LLMプロバイダーのプロトコルに変換する軽量なローカルプロキシだ。Codex CLI、App、SDKおよびClaude CodeでAnthropic、Google、xAI、Kimi、DeepSeek、GLM、Qwen、Ollamaなどを使用できるようにする。ストリーミング、ツール呼び出し、推論トークン、画像入力が双方向に変換される。

1. はじめに

要件

Node.js 18以上
BunランタイムはnpmのDependencyとしてバンドルされ、Nodeランチャーを通じて実行されるため、別途インストール不要
注意:npmがライフサイクルスクリプトをブロックした状態でインストールすると、"bundled Bun runtime is missing"エラーが発生する。この場合、スクリプトを許可して再インストールするか、Bunを直接インストールする必要がある
sudo npm install -gの代わりにnvm/fnmなどユーザー所有のNode環境を推奨

インストールと実行

# 1. グローバルインストール(Bunランタイムを自動バンドル)
npm install -g @bitkyc08/opencodex

# 2. 対話型初期化(設定ファイル作成 + Codex設定注入 + 自動起動shimインストール案内)
ocx init

# 3. プロキシ開始
ocx start

以降、Codexを普段通り使用すればリクエストがopencodexを経由する。

codex "Write a hello world in Rust"

ダッシュボードはhttp://localhost:10100でアクセスできる。

削除と復元

ocx stop        # プロキシ停止、バックグラウンドサービス停止、Codex設定を復元
ocx uninstall   # 残存設定のクリーンアップ(npm削除前に実行推奨)
npm uninstall -g @bitkyc08/opencodex

サポートプラットフォーム

OS	状態	サービスマネージャー
macOS (arm64/x64)	サポート	launchd
Linux (x64/arm64)	サポート	systemd
Windows (x64)	サポート(WSL不要)	Task Scheduler

2. 長所

番号	項目	説明
1	モデルの自由度	Anthropic、Google、xAI、Kimi、Ollama Cloud、Groq、OpenRouter、Azure、DeepSeek、GLMおよびOpenAI自体を含め、40以上の組み込みプロバイダーをサポートする。同じCodexワークフロー内でモデルを切り替えられる
2	アダプターベースの変換	Anthropic Messages、Google Gemini、Azure、OpenAI Responsesパススルー、OpenAI互換Chat Completionsの5つのアダプターでほとんどのエンドポイントを吸収する
3	インストール・設定の簡素化	プロキシチェーンを自分で構成する必要がなく、`ocx init`の対話型設定で完了する。xAI、Anthropic、KimiはOAuthログインをサポートし、APIキーなしで接続可能
4	バイナリ無修正	Codexアプリのバイナリをパッチせず、Codex設定ファイルとモデルカタログにプロバイダーを注入する方式である。`ocx stop`で元の設定が復元される
5	統合ダッシュボード	プロバイダー、APIキー、モデル別名(alias)、ログ、アカウント管理をWebダッシュボードで処理する
6	モデルルーティングルール	`provider/model`形式で明示的に指定するか、prefixを省略した場合はモデル名パターンで自動マッチングする(`claude-` → Anthropic、`gpt-` → OpenAI)
7	Codex App統合	ルーティングされたモデルがCodex Appのモデル選択器にネイティブモデルと共に表示され、モデル別のreasoning effort調整が可能
8	ChatGPTアカウントプール	複数のChatGPT/Codexアカウントを登録し、5時間・週次・30日クォータを更新し、新規セッションを使用量が最も低いアカウントにルーティングする。既存スレッドは開始したアカウントに固定される
9	バックグラウンドサービス	システムサービスとして登録され起動時に自動実行され、停止時に残存設定・ゾンビプロセスを残さないよう設計されている

3. 短所とリスク

番号	項目	説明
1	利用規約リスク	OAuth・サブスクリプションアカウントの連携が技術的に可能であっても、当該プロバイダーがサードパーティプロキシ経由を許可しているという意味ではない。プロジェクトの文書自体がアカウント制限・停止の可能性を警告している。特にアカウントプール機能は使用量回避と解釈される余地がある
2	追加レイヤーの複雑性	Codexの上にプロキシレイヤーが一つ増えることで、設定判断とデバッグポイントが増える
3	機能互換性の遅延	独自のAPI変換レイヤーであるため、CodexやClaude Codeの最新機能が即座に反映されない場合がある
4	プロジェクトの成熟度	公式ツールに比べエコシステムが小さく、リリース周期が非常に短い(週単位のpreviewタグが多数)。安定性と長期メンテナンスについては検証が必要
5	常時実行への依存	Node環境と`ocx`デーモンの常時稼働が前提となる。Codex単独使用に比べリソースを多く使用する
6	ローカル資格情報の集中	複数プロバイダーのAPIキーとOAuthトークンがローカル設定(`~/.opencodex/config.json`)に集まる。端末侵害時の被害範囲が拡大する

4. 名前が似た別プロジェクト

「OpenCodex」という名前を使うプロジェクトが複数存在する。機能を混同しないよう区別が必要だ。

プロジェクト	正体	本文書の対象との関係
lidge-jun/opencodex	本文書の対象。Codex/Claude Code用の汎用プロバイダー・プロキシ	—
AITabby/opencodex	Codex Desktop用のローカルゲートウェイ。Vision Bridge、Computer Useエンジン、音声コンパニオン(OpenCodexBar)を保有	別のプロジェクト。Vision Bridge・音声機能はこちらの機能であり、lidge-jun版の機能ではない
RyensX/OpenCodex	Codex Desktopミドルウェア。ブラウザリモートアクセスに特化	別のプロジェクト。リモートアクセス機能はこちらの機能である
Open Codex (codingmoh)	完全ローカル実行のCLIアシスタント。APIキー不要、phi-4-miniなどのローカルモデルをサポート	別のプロジェクト

5. 競合・代替ツール

ツール	説明	違い
OpenCode (SST)	オープンソースのターミナルAIコーディングエージェント	プロキシではなく独立したエージェント。複数プロバイダーを自体サポートするため、OpenCodeユーザーにはopencodexの実益が少ない
Claude Code	Anthropicのターミナルコーディングアシスタント	Claudeエコシステムに特化。opencodexはClaude Code側のプロキシとしても動作する
Cursor	AIネイティブなコードエディタ	IDE内蔵型の体験中心
GitHub Copilot	IDEプラグイン型コーディングアシスタント	プロバイダー選択の幅が限定的
Aider / Cline / Windsurf	それぞれ異なるアプローチのコーディングエージェント	ワークフローと特化領域が異なる

6. Codexとの比較

項目	Codex単独	Codex + OpenCodex
使用可能モデル	OpenAI系のみ	40以上のプロバイダー
設定難易度	低い	中程度
コスト最適化	限定的	低価格モデルルーティングで有利
カスタマイズ	限定的	高い
運用リスク	低い	プロキシ障害点の追加、プロバイダー利用規約リスク
適合ユーザー	すぐに使いたい一般ユーザー	モデル実験・コスト最適化を重視するパワーユーザー

7. 総合評価

技術的な設計は合理的である。バイナリパッチの代わりに設定注入方式を採用し、ocx stop一行で復元される構造は、このカテゴリのツールにおいて最も重要な安全装置だ。アダプターを5種類に抽象化した点も、プロバイダー拡張コストを下げている。

しかし、導入判断において技術的な便利さより優先される変数は利用規約リスクである。APIキーベースの連携とサブスクリプションアカウント(OAuth)ベースの連携は性質が全く異なり、特に複数ChatGPTアカウントのプーリングは、プロバイダーの観点から使用量ポリシーの回避と判断される可能性がある。業務用環境であれば、APIキーベースのプロバイダーのみを登録し、アカウントプール機能は使用しない構成が安全である。

週単位でpreviewリリースが続く開発速度は機能拡張の面ではポジティブだが、プロダクション依存対象とするにはまだ早い。個人の開発環境での実験的導入が現在の適正なレベルである。