Claude CodeやCodexのサブスクリプションを毎月更新するとき、こんな計算をしたことはないでしょうか。Plus会員は月20ドル。あまり使わないと損に感じるし、たくさん使うと足りなくなる。公式APIを従量課金で使うと、請求額に上限がなく不安。サブスクリプションをまとめるためにゲートウェイを自前で立てようにも、VPSやOAuthの設定が必要です。中継業者を使えば安く済むものの、APIキーを他人に預けることになり、返ってくるのが本当に目的のモデルかどうかは、相手を信じるしかありません。

実際に選べる3つの方法を並べて比較しました。CLIProxyAPIを使って手持ちのCLIサブスクリプションを互換APIに変換し、自前で運用する方法。OpenRouterのような商用中継サービスを使って従量課金で転送する方法。そして、モデル提供元の公式APIに直接接続する方法です。先に結論を言うと、最適なゲートウェイは一つではありません。利用量に合ったコストモデルを選ぶことが大切です。利用量が多く、サブスクリプションの枠内で安定して使えるなら、自前でサブスクリプションを集約する方法が最も割安になりやすいでしょう。利用量が少なければ、従量課金が手軽です。その中間なら、VPSを運用する手間をかけられるかどうかで判断できます。

まず対象を明確にしておきます。この記事で扱うのは、Claude CodeやCodexのようなAIコーディングエージェント向けのAPI接続方法です。汎用的な大規模言語モデル用ゲートウェイ全般を比較するものではありません。CLIProxyAPIが集約するのは、各種CLIツールのサブスクリプション認証情報です。プロジェクトのドキュメントによると、上流としてCodex、Claude Code、Gemini CLI、Grokなどに対応し、OpenAI/Gemini/Claude/Codex互換のインターフェースを提供します。そのため、汎用ゲートウェイと比較してもあまり意味はありません。

まずコストの前提をそろえる

最初は機能一覧から比較しようとしましたが、機能の多さでは「どこにお金がかかるのか」が分かりません。そこで比較軸を、コスト構造、導入の手間、データの流れに切り替えました。選定時に実際の落とし穴になりやすいのは、この3点です。

バージョン情報によっても結論が変わります。CLIProxyAPIはリリース頻度が高いため、最初はGitHubのリリースページにあるバージョン番号だけを見れば十分だと思っていました。しかし、Docker Hubのイメージタグとも照合する必要があります。両方がv8.0.27（2026-10-12リリース）を示して初めて確認できたと言えます。片方だけを見ると、古いページのキャッシュを見ている可能性があります。以下のバージョン情報は、すべて2026-10-14時点のものです。導入前にDocker Hubのタグも確認する習慣をつけておくとよいでしょう。

自前運用：サブスクリプション＋VPSで、コストは比較的固定

自前運用は「無料API」と考えるのではなく、固定費ベースで見積もるのが適切です。月20ドルからのサブスクリプションに、月5〜10ドル程度のVPSを加える例では、月々の支出は比較的固定されます。利用量が増えるほどコストを分散できるため、毎日エージェントを高負荷で使う人には、通常この方法が最も安くなります。

その代わり、OAuthデバイスコードの認証フロー、VPSの継続的な管理、上流サブスクリプションの不正利用対策リスクという3つを自分で引き受ける必要があります。10月初旬にVPSへデプロイした際、OAuthの段階でCloudflareの403やリージョン関連のタイムアウトが発生しました。最終的にはゲートウェイ自体の問題ではなく、サブスクリプション側またはネットワーク環境の問題だと確認できました。そのときの手順は別の記事にまとめています。OAuth以外のDockerやクライアント設定は、そのまま参考にできます：CodexをCLIProxyAPIでリバースプロキシする方法。とはいえ、自前運用では経路上のどこかに問題が起きれば、夜中に起きて対処するのも自分です。

損益分岐点をざっくり見積もる

どれくらい使えば、自前運用のほうが従量課金より安くなるのでしょうか。前提を明記したうえで、概算してみます。正確な見積もりではありません。

• 自前運用の固定費：月20ドルのサブスクリプション＋月5ドルのエントリー向けVPS ≈ 月25ドルが上限。利用量にかかわらず同じ料金です。
• 公式APIの従量課金：Sonnet 5.5相当（入力100万トークンあたり2ドル／出力100万トークンあたり10ドル、第三者による整理価格）を例にすると、入力100万トークン＋出力20万トークンを1日で使う場合、約4ドル／日。1か月では120ドル近くになります。

損益分岐点は分かりやすいでしょう。毎日100万トークン規模を使うヘビーユーザーなら、青天井の費用を固定月額に抑えられます。反対に、週に数回ターミナルを開く程度なら、従量課金は月数ドルで済む可能性があり、自前運用では使っていないVPSの月額費用が余計にかかります。自分の使い方に当てはめて判断してください。

インストールを検証：v8.0.27で一度で成功

今回は隔離したテストマシン（Ubuntu 26.04、1コア／メモリ1.9G）で、インストールを最初からやり直しました。latestではなく、v8.0.27に固定しています。

docker pull eceasy/cli-proxy-api:v8.0.27   # 292MB，发布页显示 2026-10-12 发布

最小構成なら、設定は3行だけで済みます。上流を設定していなくても起動できます。

# config.yaml
config-version: 8
server:
  port: 8317

docker run -d --name cpa-test --restart unless-stopped \
  -p 8317:8317 \
  -v ./config.yaml:/CLIProxyAPI/config.yaml \
  -v ./auths:/root/.cli-proxy-api \
  eceasy/cli-proxy-api:v8.0.27

起動ログでバージョン、Commit、ビルド時刻（v8.0.27 / bf93416 / 2026-10-12）を確認でき、GitHub mainの情報とも一致しました。/ は200を返し、互換エンドポイントを3つ表示します。上流未設定の状態で /v1/models が空のリストを返すのも正常です。エラーではありません。

実際に検証して分かった、チュートリアルで明記しておきたい点が2つあります。

1. 最小構成では認証がデフォルトで無効です。access.api-keys を設定しないと、誰でもゲートウェイを呼び出せます。閉じたネットワーク内で試すだけなら問題ありませんが、ポートをインターネットに公開するなら、まずAPIキーを設定してください。
2. コンテナからホストに接続するとき、127.0.0.1を指定してはいけません。最初、モックの上流を http://127.0.0.1:18888 に設定したところ、ゲートウェイからconnection refusedが返りました。コンテナ内のlocalhostはコンテナ自身を指すためです。ホスト側のDockerブリッジアドレス（通常は172.17.0.1）か、--network host を使ってください。ゲートウェイのエラーは分かりやすく、500レスポンスにdial失敗の原因がそのまま表示されるので、トラブルシューティングは簡単です。

また、私のテスト設定では /health エンドポイントが存在せず、404になりました。ヘルスチェック用のスクリプトを書くとき、汎用テンプレートをそのまま使わないようにしてください。

ゲートウェイ自体の遅延は？実測で約4ms

「自前運用にすると遅くなるのでは」というのは、選定時によくある疑問です。実際に測定しました。方法は、同じマシン上に最初のチャンクまでの遅延を50msに固定したモックOpenAI上流を立て、「モックに直接接続」と「ゲートウェイ経由でモックに接続」をそれぞれ20回ずつ、ストリーミングで比較しました。

経路	成功率	初回トークン遅延の中央値	初回トークン遅延 p95	総所要時間の中央値
モック上流に直接接続	20/20	52.4ms	52.9ms	104.2ms
CLIProxyAPIゲートウェイ経由	20/20	56.5ms	57.3ms	108.7ms

ゲートウェイ自体が追加する遅延は約4msで、p95と中央値も近く、オーバーヘッドは安定しています。この結論は、今回のテスト条件に限られます。同一マシン、低負荷、モック上流という条件では、自前ゲートウェイがボトルネックにはなりません。実際に感じる「遅さ」は、多くの場合、モデルの推論や上流までのネットワークによるもので、プロキシを1段挟むこと自体が原因ではありません。ただし、高並行時や複雑なネットワーク環境での性能は、今回測定していません。

参考として、手元にある商用中継サービス（OpenAI互換）を経由し、実モデルの呼び出しも10回測定しました（gpt-6-luna。中継業者側のモデル識別子で、モデルフィンガープリントは未検証）。10回すべて成功し、初回トークン遅延の中央値は1240ms、p95は1996ms、総所要時間の中央値は1745msでした。初回トークン遅延は主にモデル推論で決まります。これも、上記の結論を裏づけています。エンドツーエンドの体感では、ゲートウェイによる4msの差は無視できる程度です。

デプロイ自体は難しくありません。コンテナを起動したら、エージェントからOpenAI互換のURLでサービスにアクセスできます。具体的なエンドポイントや認証方式は、利用するバージョンのドキュメントを確認してください。以下は、呼び出し側でよくある設定例です。アドレスは自分のサービスに置き換えてください。

from openai import OpenAI

client = OpenAI(
    base_url="https://your-api.example/v1",
    api_key="YOUR_API_KEY",
)

ゼロから構築したくない場合に備えて、当時検証したデプロイスクリプトを一括デプロイ用リポジトリにまとめました。setup.sh を実行し、APIキーを設定すればサービスを起動できます。手間を省きたい人は、そのまま使えます。

kuangyongjie/cliproxyapi-codex-deploy

OpenRouter：運用の手間を抑えて従量課金

OpenRouterのコスト構造は、自前運用とは対照的です。モデルのトークン料金はプロバイダーの価格がそのまま適用され、上乗せはありません。プラットフォームの手数料はチャージ時に発生し、クレジットカードでは5.5%（最低0.80ドル）、暗号資産では5%です。この手数料率は、2026-10時点の独立した3つの情報源（betterclaw.io、leanroute.dev、calculatorai.app）で照合し、数値が一致することを確認しました。最終的には公式料金ページを確認してください。この記事では2026-10-14時点で確認しています。また、BYOKモードもあります。自分の公式APIキーを紐づけると、月あたりlist-priceで25,000ドル分まではプラットフォーム手数料がかからず、超過分には5%がかかります（同様に、最新情報は公式ページで確認してください）。

3つの方法の中で、導入が最も簡単です。登録してチャージし、OpenAI SDKの base_url をOpenRouterに向けて、モデルを選べば使えます。公式ドキュメントでも、OpenAI互換エンドポイントとdrop-in置き換えが案内されており、既存コードをほとんど変更せずに利用できます。

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="YOUR_OPENROUTER_API_KEY",
)

response = client.chat.completions.create(
    model="YOUR_MODEL",
    messages=[{"role": "user", "content": "Hello"}],
)

運用の手間を省ける一方で、リクエストはOpenRouterを経由してから上流のプロバイダーに届きます。プラットフォームはデフォルトではpromptやcompletionを保存せず、メタデータのみを保持します。ログはオプトインで有効化できます。これはプラットフォーム側のデフォルトのログ方針です。リクエストは最終的に上流のプロバイダーにも届くため、そのプロバイダー独自のデータポリシーも適用されます。データに敏感なチームが確認すべきなのは、「保存されるかどうか」だけではなく、リクエストがどの事業者を経由するかです。この点は、どの商用中継サービスを使う場合も同じです。

商用中継のリスクは具体的に説明し、根拠と判断を分けて考える必要があります。ある調査では、再販型の中継サービスでモデルフィンガープリントが一致しない事例が指摘されています。ただし、私は原文を独自に検証できていないため、ここでは特定の中国語圏の中継業者名は挙げません。より確実なのは、まず少額で試し、実際に返されるモデルフィンガープリントとサービスの挙動を確認し、合わなければ乗り換えることです。価格だけを説明し、検証方法に触れない推奨には注意してください。

公式API：直結を基準にする

公式APIは従量課金で、モデル提供元に直接接続するため、データの経路が最短です。他の2つの方法を比較する際の基準にもなります。「X%安い」という宣伝は、いずれもここでの価格を基準にしています。

OpenAIとAnthropicの具体的な料金は、第三者がまとめた2026-10時点の情報を引用しています。初期比較には使えますが、料金ページは頻繁に更新されます。導入前には必ず公式料金ページとAnthropicの料金ページを確認してください。変わる可能性のある価格を、長期的に変わらない数字としてコストモデルに組み込まないようにしましょう。

安定性は、実測値を待たずともアーキテクチャからある程度考えられます。自前サービスにはVPSという単一障害点が一つ増え、問題が起きれば自分で修復します。商用プラットフォームにはルーティングやフォールバックがありますが、機能するかどうかはモデルや障害の種類によります。公式APIはモデル提供元が直接サービスを提供します。選び方を3つにまとめると、利用量が多く、VPSを管理でき、サブスクリプションの不正利用対策リスクを許容できるなら自前運用。利用量が少ない、または運用を避けたいならOpenRouter。データの経路や直結に厳しい要件があるなら公式APIです。この記事では3つの方法の実稼働率を比較していません。アーキテクチャの分析を稼働率の保証と混同しないでください。

範囲と制限

今回は2点を実測しました。ゲートウェイ自体のオーバーヘッド（同一マシン、モック上流、N=20、+4ms）と、商用中継に直接接続した場合の実際の応答（手元の中継サービス、gpt-6-luna、N=10）です。測定していないものは、OpenRouterと公式APIのオンライン遅延（対応するAPIキーがないため）、OAuthサブスクリプション上流を使ったエンドツーエンドの挙動（ブラウザーでデバイスログインを完了する必要があるため）、および24時間を超える長時間の安定性です。ゲートウェイのオーバーヘッドに関する結論はモック上流での測定に基づきます。示せるのは「ゲートウェイ自体は遅くない」という点であり、「利用する上流も遅くない」ということではありません。

CLIProxyAPIのバージョン、OpenRouterの手数料、公式APIの料金はいずれも変更される可能性があります。ここでは2026-10-14時点で確認した情報を掲載しています。実際に導入する際は、プロジェクトのリリースページ、Docker Hubのタグ、公式の料金ページを改めて確認してください。

まとめ：選び方は3つ

• 自前で集約する：毎日エージェントを使って集中的にコーディングし、CLIサブスクリプションをすでに持っていて、基本的なLinux運用ができ、コストを固定したい人向け。
• OpenRouterを使う：利用量が少ない、または変動が大きい人。サーバーの運用を避けたい人や、複数のモデルを頻繁に切り替えて試す人にも向いています。
• 公式APIを使う：データの経路にコンプライアンス要件があり、予算に余裕があり、利用量による料金変動を気にしない人向け。

関連リンク：CLIProxyAPIプロジェクト · 一括デプロイ用リポジトリ · OpenRouterクイックスタート · OpenRouter料金