CLIProxyAPI：Codex、Claude Code、Gemini CLI を統一 API として包み込む

Sun, 24 May 2026 10:03:33 +0800

CLIProxyAPI は、かなり「現場の工夫」らしさがあるプロジェクトです。新しい大規模モデルを作るものでも、単なる API 転送サービスでもありません。もともとインタラクティブで、CLI 中心で、OAuth ログインに依存しがちな AI ツール群を、統一 API サービスとして再パッケージします。

対応対象には Gemini CLI、OpenAI Codex、Claude Code、Amp CLI、AI Studio Build、そして上流の OpenAI 互換サービスが含まれます。つまり、解きたい問題はこうです。

手元に CLI ツール、サブスクリプションアカウント、OAuth ログイン状態がある。これらの能力を、普通の API を呼ぶように自分のクライアント、スクリプト、IDE、社内サービスへ接続できないか？

CLIProxyAPI の答えは「できる」です。間にプロキシ層を置き、異なる出自の CLI 能力を OpenAI、Gemini、Claude、Codex 互換インターフェイスへ変換します。

本当に解決する痛点

多くの AI コーディングツールは強力ですが、標準の使い方は自動化に向いていません。

たとえば：

Gemini CLI はアカウントログインで使えるが、プログラム側は HTTP API を呼びたい。
Claude Code は対話型コーディングに向いているが、他のクライアントへ接続するとプロトコル差にぶつかる。
Codex CLI は OAuth ログインと Responses 形式の能力を持つが、上位ツールが必ずしも会話方法を知っているわけではない。
チームには複数アカウントがあり、ローテーション、負荷分散、異常アカウントの除外、クォータ確認が必要になる。
一部のツールには OpenAI 形式だけを見せたいが、実際のバックエンドは Gemini、Claude、Codex かもしれない。

CLIProxyAPI の位置づけは、これらのツールとクライアントの間に入る「プロトコル適配層」です。

複雑な側、つまり OAuth、CLI ログイン、複数アカウント、異なるプロトコル、異なる provider を背後に隠します。前面には OpenAI Chat Completions、OpenAI Responses、Gemini、Claude Messages、Codex 関連エンドポイントのような、比較的なじみのあるインターフェイスを出します。

機能の概要

公式 README とドキュメントを見ると、CLIProxyAPI の主な機能は次の通りです。

CLI モデル向けに OpenAI、Gemini、Claude、Codex 互換 API エンドポイントを提供する。
OAuth ログイン経由で OpenAI Codex と Claude Code を接続する。
ストリーミング、非ストリーミング応答、一部シナリオでの WebSocket をサポートする。
関数呼び出し、ツール呼び出し、マルチモーダル入力をサポートする。
Gemini、OpenAI、Claude の複数アカウントローテーションと負荷分散をサポートする。
Gemini AI Studio API Key をサポートする。
AI Studio Build、Gemini CLI、Claude Code、OpenAI Codex のアカウントプールをサポートする。
設定により OpenRouter などの OpenAI 互換上流へ接続できる。
Go SDK を提供し、自分のサービスへプロキシ機能を組み込める。

この種のプロジェクトで一番価値があるのは、「対応モデル名が多い」ことではありません。アカウントログイン、プロトコル変換、リクエストルーティングという細かく面倒な作業をまとめてくれることです。

向いているユーザー

CLIProxyAPI は次のような人に向いています。

第一に、AI コーディングをかなり使い込んでいる人です。すでに Codex、Claude Code、Gemini CLI を使っていて、それらを Cursor、Cline、RooCode、Amp、社内スクリプト、自作ワークフローへ接続したい場合です。

第二に、複数アカウントプールを持つ人です。複数の Gemini、OpenAI、Claude のログイン状態があり、手動切り替えではなく、自動ローテーション、均等利用、異常アカウントの素早い調査をしたい場合です。

第三に、チーム内ゲートウェイを作る人です。各クライアントが Gemini、Claude、Codex をそれぞれ個別に適配するのではなく、中間層で統一 API として公開したい場合です。

第四に、プロトコルを触るのが好きな人です。Responses、Chat Completions、Claude Messages、Gemini v1beta などのインターフェイスを相互変換したい、あるいは同じクライアントから異なるバックエンドを切り替えたい場合です。

個人がたまに AI に質問するだけ、または公式 App でチャットするだけなら、CLIProxyAPI のデプロイとメンテナンスは重く感じるはずです。

普通の API 中継との違い

普通の API 中継サービスは、おおむね次の形です。

`1`	`クライアント -> 中継 API -> 上流モデル API`

CLIProxyAPI の経路は、むしろこうです。

`1`	`クライアント -> CLIProxyAPI -> CLI / OAuth ログイン状態 / 複数アカウントプール -> モデルサービス`

違いは、API Key の転送だけを扱うわけではないことです。CLI ツール、OAuth アカウント、プロトコル面、モデル別名も扱います。

たとえば Codex や Claude Code のようなツールは、「API Key を1つ渡せば安定して呼べる」伝統的なサービスではありません。CLIProxyAPI はログイン状態と呼び出しロジックを包み込み、外部クライアントが通常の API のようにアクセスできるようにします。

これが魅力であり、同時に複雑さでもあります。

使うときに誤解しやすい点

第一に、統一された /v1/... だけですべてのプロトコル差が消えるとは考えないことです。

CLIProxyAPI のドキュメントでは、特定バックエンドのリクエストとレスポンス形状が必要な場合、provider-specific なパスを優先するよう説明されています。たとえば messages 形式なら /api/provider/{provider}/v1/messages、Gemini のモデルパスなら /api/provider/{provider}/v1beta/models/...、chat-completions 形式なら /api/provider/{provider}/v1/chat/completions です。

統一入口は便利ですが、異なるプロトコルの意味論は消えません。ツール呼び出し、ストリーミング応答、マルチモーダル入力、システムメッセージ処理は、バックエンドごとに細部が変わる可能性があります。

第二に、モデル名は唯一のバックエンドを意味しません。

複数バックエンドが同じクライアント表示用モデル名を公開している場合、パスだけでは実際に推論するバックエンドを固定できないことがあります。厳密に固定したいなら、一意の alias や prefix を使うか、複数バックエンドに同じモデル名を出させないようにします。

第三に、複数アカウントローテーションは無限クォータではありません。

ローテーションはアカウントプールをより均等に使うだけで、上流サービスの本当の制限を回避するものではありません。異常アカウント、クォータ枯渇、リスク制御、OAuth 失効は個別に監視が必要です。

第四に、メンテナンス不要の魔法箱ではありません。

日常ワークフローに入れるなら、設定、ログ、上流アカウント状態、バージョンアップ、クライアント互換性、セキュリティ境界を気にする必要があります。

管理と監視はどうするか

公式 README では、v6.10.0 以降、CLIProxyAPI と CPAMC にはデータ統計機能が同梱されなくなったと説明されています。利用量統計が必要な場合は、独立したプロジェクトを組み合わせます。

CPA Usage Keeper：CLIProxyAPI のデータを同期し、SQLite に保存し、集計 API とダッシュボードを提供する。
CLIProxyAPI Usage Dashboard：ローカル優先の利用量・クォータ看板。アカウント、モデル、時間窓、Codex の残りクォータを表示できる。
CPA-Manager：より完整な管理センター。リクエスト監視、費用見積もり、アカウントプール巡回、異常アカウント特定、整理提案を扱う。

これは、CLIProxyAPI の中心が「プロキシとプロトコル層」であり、一体型の商用管理バックエンドではないことを示しています。チームで使うなら、ログ、監視、アカウントプール管理を最初から考えておく方がよいです。

ほどよい試し方

試すなら、次の順番が安全です。

公式ドキュメントの Quick Start で起動する。
まず Gemini CLI や Codex など、provider を1つだけ接続し、基本リクエストが通ることを確認する。
次にストリーミング応答、ツール呼び出し、マルチモーダル入力のようなリスクの高い機能を試す。
クライアントが実際にどの endpoint を使っているか確認し、プロトコルパスを混ぜない。
最後に複数アカウントローテーション、管理パネル、利用量統計を追加する。

最初から Gemini、Codex、Claude、OpenRouter、複数アカウント、全クライアントを一気に接続しない方がよいです。エラーが出たときに、認証、プロトコル、モデル名、上流アカウントのどれが原因か分からなくなります。

セキュリティ境界も考える

CLIProxyAPI はアカウントログイン状態、API Key、OAuth 関連資格情報、リクエスト内容に触れます。自分のマシンだけで動かすならリスクは比較的制御しやすいですが、インターネットやチーム内ネットワークに公開するなら、認証、アクセス制御、ログのマスキング、ネットワーク分離をきちんと扱う必要があります。

特に管理エンドポイントは、ローカルホストまたは信頼できる内部ネットワークに限定するのが望ましいです。手間を省くために管理インターフェイスを直接公開してはいけません。

まとめ

CLIProxyAPI の価値は、複数の CLI、複数のアカウント、複数のプロトコルに散らばった AI 能力を、プログラム可能な API 層へまとめることにあります。

重度の AI コーディングユーザー、複数アカウントユーザー、チーム内ゲートウェイの用途に向いています。一方で、「すぐ使えて完全にメンテナンス不要」を求める軽量ユーザーにはあまり向きません。

Codex、Claude Code、Gemini CLI を触っていて、それらを自分のクライアントや自動化ワークフローに接続したいなら、CLIProxyAPI は真面目に見る価値があります。ただし一度きりの小道具ではなく、インフラとして扱うべきです。

参考資料：

Gemini CLI on KnightLiブログ