Claude Code、Codex、Gemini CLIはエージェントです。リクエストに応答するモデルと、そのモデルを提供するプロバイダーは別々に選択できます。複数のツールでこれらの選択を管理する際に、Magpie、CC Switch、Claude Code Router、CLIProxyAPIなどのソフトウェアが役立ちます。
先に結論を述べると、複数のエージェントで共有するゲートウェイならMagpie、機能を統合したデスクトップ設定ワークスペースならCC Switch、明示的なリクエストルーティングルールならClaude Code Router、アカウント連携型の互換プロキシならCLIProxyAPIを候補にしてください。これらは強みが重なり合っており、4つの排他的なカテゴリに分かれるわけではありません。CC Switchにはルーティング機能があり、Magpieにはワークスペース機能があり、Claude Code RouterはClaude Code以外にも対応しています。
重要なのは、どの製品が最も多くの機能を備えているかではありません。エージェントのセットアップのどの部分を製品に任せたいかです。
対象範囲：2026年11月3日時点で公式ドキュメントを確認。本比較はドキュメントに基づくものであり、実機ベンチマーク、信頼性テスト、セキュリティ監査ではありません。記載されている対応状況は、すべてのエージェント、プロバイダー、リリースで同じ動作が得られることを示すものではありません。本比較はAIHubMixが作成しました。Claude Code RouterのREADMEには、スポンサーの1つとしてAIHubMixが記載されています。この記載はここで開示しており、技術的な根拠として扱うものではありません。
まず、エージェントと接続先を区別する
エージェントは、ファイルアクセス、シェルツール、承認ルール、会話ループといった作業環境を提供します。モデルは応答を生成します。プロバイダーは、エンドポイント、API キー、または対応している場合はアカウントログインを通じて、そのモデルへのアクセスを提供します。
接続先のモデルを変えても、Claude CodeがCodexに変わるわけではありません。また、APIから応答が返ったからといって、すべてのツール呼び出し、画像、reasoningフィールド、長時間にわたる会話が同じように動作するとは限りません。
そのため、この比較では既存のコーディングエージェントを制御するソフトウェアに焦点を当てます。ホスト型のモデルサービスやアプリケーションバックエンド用のゲートウェイは隣接する課題を解決するものであり、ローカルエージェントの設定を管理するツールとは限りません。
混同しやすい操作は5つあります。
- 設定の切り替えは、エージェントが使用するエンドポイント、キー、モデルを変更します。
- ローカルルーティングは、エージェントと接続先の間にゲートウェイを置きます。ゲートウェイは接続先を選択したり、API形式を変換したりできます。
- モデル集約は、複数のプロバイダーのモデルを1つの選択リストにまとめます。それ自体にフォールバック機能があるわけではありません。
- アカウントプーリングは、複数の認証情報またはアカウントから選択します。ラウンドロビンは振り分け方式であり、失敗したすべてのリクエストが復旧することを保証するものではありません。
- フォールバックは、条件に該当するエラーが発生した後、設定済みの別の接続先を試します。適用範囲や条件は実装によって異なります。
必要な操作を決めてから、製品を選びましょう。
候補を素早く絞り込む
まずこの表で検討を始める製品を選び、詳しい制限事項を以下で確認してください。
| ツール | こんな場合に検討 | 最初に確認する点 |
|---|---|---|
| Magpie | 共有ゲートウェイ | 代替の接続先 |
| CC Switch | デスクトップワークスペース | 集約≠フェイルオーバー |
| CCR | ルーティングルール | 各ポリシー分岐 |
| CLIProxyAPI | アカウント連携型プロキシ | UIと統計は別コンポーネント |
CCRはClaude Code Routerの略です。ここでの候補は編集上の分類であり、排他的な機能区分でも、実測に基づく順位でもありません。Magpieのフォールバックには利用可能な別の接続先が必要です。CC Switchの集約にはフェイルオーバー機能がありません。CCRのルールは検証が必要です。CLIProxyAPIのデスクトップ用コンパニオンと統計機能は別コンポーネントです。対応範囲はエージェントとプロバイダーによって異なります。
Magpie：複数のエージェントを1つのモデルゲートウェイにまとめる
Magpieは、エージェント設定のネイティブ管理機能と共有ローカルゲートウェイを組み合わせています。ドキュメントに記載されている連携先には、Claude Code、Codex、Gemini CLI、OpenCode、Cline、Cursor CLIなどがあります。インターフェースには検出されたインストール済みツールが表示されます。また、互換性のあるベース URLを受け付けるクライアントもゲートウェイを利用できますが、専用のネイティブ連携があることとは異なります。
ゲートウェイは、OpenAI Chat、OpenAI Responses、Anthropic Messages、Geminiの各形式を変換します。接続先には、APIキーを使うサービス、互換性のあるカスタムエンドポイント、ローカルモデルサーバー、対応するサブスクリプションアカウントなどを指定できます。プロファイルを使うと、複数のエージェントの設定を1つの名前で保存できます。
特徴的なのはルーティンググループです。複数のモデルやプロバイダーを、エージェントからは1つの選択肢として見せられます。ドキュメントに記載されているモードは次のとおりです。
order：最初のメンバーが応答できなくなるまで使い、その後、次のメンバーを試します。rotate：ターンごとに別のメンバーへ切り替えます。usage：使用量が最も少ないメンバーを優先します。smart：クォータに余裕がある利用可能なサブスクリプションの中から、リセット時刻が最も近いものを優先します。pace：週ごとの残り利用可能量とリセットまでの時間に応じて選択します。
グループはネストできます。またMagpieは、プロンプトキャッシュを維持する価値がある場合、応答したアカウントに会話を継続させる仕組みについても説明しています。これはルーティングポリシーであり、任意のプロバイダー間の切り替えでキャッシュ状態が維持されることを証明するものではありません。オプションのインテントルーティングでは、ユーザーが選択したモデルで新しいターンを読み取りますが、常にコストが下がることはドキュメントで確認できません。
単純ですが重要なフォールバックの条件があります。別に利用可能な接続先が必要です。READMEには、ルーティンググループのないアカウントが1つだけの場合、フェイルオーバー先がなく、エラーがエージェントに返されると明記されています。
Magpieはルーターだけではありません。Libraryでは、指示、MCPサーバー、スキル、サブエージェントを管理できます。使用量、クォータ、コスト、セッションの表示機能もドキュメントに記載されています。デスクトップ、ターミナル、ブラウザー、CLIの各インターフェースがあり、対応環境としてmacOS、Windows、Linux、Docker、Termuxが挙げられています。
プライバシー制御については、別途判断が必要です
Magpieのマスキング機能はデフォルトではオフです。有効にすると、対応する機密情報をローカルで検出し、送信前にプレースホルダーに置き換えて、ツールの引数を含む応答内で元に戻します。検出を誤る可能性があり、マスキングされた値の元の内容をモデルが確認することはできません。有効にしたマスキングが実行できない場合、READMEによると、リクエストを保留してHTTP 503を返します。
すべてのシークレットが検出される保証ではありません。アカウント検出の挙動を含め、プライバシーに関するドキュメントを確認してください。Magpieは既存のエージェントへのサインイン情報を読み取ることができ、検出機能は無効にできます。
READMEには、ランダムな識別子、バージョン、システム情報、製品使用状況の識別子を含むリリースビルドのテレメトリーを毎日送信することも記載されています。プライバシー設定またはDO_NOT_TRACK=1で、このテレメトリーを無効にできます。パートナーリンクのクリックとパートナーリストの取得は、これらの制御とは別に計測されます。READMEによると、これらの回数は識別子やアドレスを保持しません。したがって、「ローカルゲートウェイ」は「ほかのネットワーク通信がない」という意味ではありません。
Magpieを候補にする場合：複数のエージェントでプロバイダー、モデル、アカウントのルーティング方法を共有したい場合です。その代わり、メニューからモデルを選ぶだけでなく、ルーティングポリシー、認証情報へのアクセス、プライバシー設定に責任を持つ必要があります。
CC Switch：リクエストのルーティングもできるデスクトップワークスペース
CC Switchを単なる設定切り替えツールと呼ぶと、ドキュメントに記載された機能の範囲を過小評価することになります。プロバイダー管理に加えて、MCP、スキル、プロンプトライブラリ、プロジェクト設定、セッション、使用量の追跡、バックアップ、同期にも対応しています。対応クライアントにはClaude Code、Claude Desktop、Codex、Gemini CLI、OpenCodeなどがありますが、機能の対応状況はクライアントごとに異なります。
3つの接続モードを見ると、比較のポイントがよく分かります。
Directは、エージェントを選択したプロバイダーに直接接続します。切り替え時には接続関連のフィールドが変更されますが、プロジェクトによると、無関係なフック、プラグイン、MCP設定、コメントは保持されます。
Routingは、リクエストをCC Switch経由でローカルに転送します。Anthropic Messages、OpenAI Chat Completions、OpenAI Responses、Gemini Nativeの各形式を変換でき、ツールごとのフェイルオーバーキュー、サーキットブレーカー、プロバイダーのヘルスモニタリングに対応しています。
Aggregationは、Claude CodeとCodexにおいて、複数のプロバイダーのモデルをクライアントのモデル選択リストにまとめます。リクエストは選択したモデルのプロバイダーに送られます。集約にはフェイルオーバー機能がありません。また、Claude公式サブスクリプションは集約で利用できないなど、プロバイダーにも制限があります。公式ログインを使うプロバイダーは通常Routingを利用できませんが、例外としてCodexのOpenAI Officialがドキュメントに記載されています。
このため、CC Switchはシンプルな設定切り替えにもローカルルーティングにも有力な選択肢です。デスクトップワークスペースを重視している点は、候補に挙げる編集上の理由であり、ほかの製品にライブラリやセッション表示機能がないことを示すものではありません。
プリセットの数より、実用上の制限が重要
CC Switchのドキュメントによると、Claude Codeではホットスイッチに対応しています。Codex、Gemini CLI、Grok Buildでは、プロバイダーをDirectで切り替える際に通常、再起動が必要です。Routingでもモデルを変更すると再起動が必要な場合があります。Codexの集約リストを変更した場合は、該当するデーモン、アプリケーション、またはエディター環境を再起動する必要があります。作業中のタスクを避けて切り替える計画を立ててください。
FAQにあるもう1つの重要な違いは、プロバイダーカードの接続確認が調べるのは到達可能性であり、APIキーやモデルが機能するかどうかではない点です。チェックマークが緑色でも、エンドツーエンドの受け入れテストを通過したことにはなりません。
データはデフォルトで~/.cc-switchに保存され、SQLiteデータベースと関連ファイルが含まれます。READMEには、初回の書き換え前に元の設定をバックアップする機能、自動バックアップ、WebDAV/S3互換の同期が記載されています。一部のデバイス設定、状態、元の設定のバックアップはローカルに残り、クラウド同期の対象外です。アプリを同期すれば、復元可能な状態がすべて転送されるとは限りません。
公式アプリは、macOS、Windows、LinuxのGUIデスクトップを対象としています。エージェント別の正確な機能対応表とモードの制限については、ユーザーマニュアルを確認してください。
CC Switchを候補にする場合：プロバイダーの切り替えを、MCP、スキル、プロンプト、プロジェクトを含む幅広いデスクトップ作業の一部として扱いたい場合です。再利用可能なヘッドレスプロキシだけが必要なら、デスクトップ版と機能が同等だと決めつけず、その要件を別途評価してください。
Claude Code Router：ルーティングの判断を明示する
Claude Code Router（CCR）は現在、マルチエージェント向けのゲートウェイ兼コントロールプレーンとして紹介されています。READMEでは、Claude Codeに加え、Codex、OpenCode、Pi、Kimi CLI、Grok CLIなどのクライアントが挙げられています。
ドキュメントに記載された機能では、リクエストポリシーが中心に据えられています。ヘッダーやリクエストボディに対する条件、プレフィックス、リクエストの書き換え、再試行、優先順位付きのフォールバックモデルを設定できます。認証情報プールやキーのローテーションに加え、エージェントプロファイル、モデルの上書き、環境設定も備えています。
「別のプロバイダーを選ぶ」だけでは要件が曖昧すぎる場合、この組み合わせが役立ちます。特定のリクエスト条件に応じて特定のアップストリームを選び、そのルールに一致した理由を確認したい場合などです。
CCRでは、リクエストとレスポンスの詳細、解決されたプロバイダー／モデル／認証情報、ステータス、レイテンシ、トークン、推定コスト、ツール呼び出し、トレースを確認できます。コストの推定値は、アップストリームからの請求額ではありません。ログによってポリシーを検証できますが、そのポリシーがタスクの品質を高めることまで証明されるわけではありません。
macOS、Windows、Linux向けのデスクトップ版、ブラウザー管理UIを備えたnpm CLI、Dockerによるデプロイが提供されています。npm CLIにはNode.js 22以降が必要です。プロバイダーガイドでは、カスタムエンドポイント、プロトコルの選択、認証情報プールについて説明されています。また、接続テストではアップストリームへのリクエストが送信され、使用量やリクエスト上限を消費する可能性があると警告されています。
CCRを候補に入れたいのは、次のような場合です。明示的なルーティングルールと、解決されたルートの説明が必要な場合です。トレードオフは、維持管理が必要なポリシーです。条件やフォールバック経路を増やすと、検証すべき組み合わせも増えます。結果が自動的によくなるわけではありません。
CLIProxyAPI：アカウントと互換プロキシを起点にする
CLIProxyAPIは、プロキシサーバーを基本とする設計です。Responsesを含むOpenAI互換インターフェース、Interactionsを含むGemini互換インターフェース、そしてClaude互換インターフェースをクライアントやSDKに提供します。
READMEには、CodexとClaude CodeのOAuthサポート、Geminiアカウントへのアクセス、一部プロバイダーにおける複数アカウントのラウンドロビン負荷分散が記載されています。設定済みのOpenAI互換アップストリームも受け付けており、再利用可能なGo SDKも提供しています。
アカウントや認証情報を使う互換エンドポイントが主な要件であれば、出発点として役立ちます。ただし、コアプロジェクトがすべてのエージェントのプロファイルをネイティブに編集できることを示すものではありません。
パッケージ構成に関する次の2点が、選択に影響します。
- READMEでは、グラフィカルな設定、更新、トレイ操作、サービスの起動／停止には、別のデスクトップ用コンパニオンであるEasyCLIProxyAPIを推奨しています。
- v6.10.0以降、CLIProxyAPIとCPAMCには使用状況の統計機能が同梱されなくなりました。READMEでは、統計と管理を担う別プロジェクトが案内されています。
保守にかかる手間を見積もる際は、プロキシ、デスクトップ用コンパニオン、分析サービスを別々のコンポーネントとして考えてください。CLIProxyAPIに再試行や復旧制御がないと決めつけず、選択したリリースの設定を確認しましょう。同様に、アカウントのラウンドロビン分散を、モデルをまたいだフォールバックポリシーが保証されているものと取り違えないでください。
CLIProxyAPIを候補に入れたいのは、次のような場合です。アカウントを使うプロキシが必要で、周辺の管理コンポーネントは個別に選ぶことに抵抗がない場合です。
実際のプロジェクトを接続する前に
これらのツールは、認証情報、ソースコードのコンテキスト、エージェントが実行するアクションに近い位置で動作します。ローカルプロセスであっても、信頼境界の一部です。
まず、APIキーとサブスクリプションログインを区別してください。OAuthフローに対応するソフトウェアだからといって、プロバイダーがあらゆるクライアントでの利用を許可しているとは限りません。CC Switchは、公式クライアント以外でのサブスクリプション利用について明示的に警告しています。プロバイダーの最新の利用規約と組織のルールを確認してください。管理ツールを使っても、利用資格が新たに得られたり、制限がなくなったりするわけではありません。
次に、各設定ファイルをどのツールが管理するかを決めましょう。運用上の予防策として、複数の管理ツールが同じエージェント設定を自動的に書き換える状態は避けてください。元のファイルをバックアップし、直接接続に戻す方法を把握しておきましょう。これは、これらの製品に実証済みの不具合があるという主張ではありません。
さらに、認証情報とログの扱いを確認してください。この比較では、保存時の暗号化を検証していません。本番環境の認証情報を取り込む前に、権限、バックアップ／同期の対象範囲、アカウント検出、リクエストログの内容を確認してください。リモートアクセスを有効にする場合は、ローカル環境のデフォルト設定をセキュリティ保証と見なさず、認証と公開範囲の設定を確認しましょう。
最後に、プロトコル名だけでなく、実際の動作をテストしてください。OpenAIのChat CompletionsとResponsesは別々のAPIであり、Anthropic MessagesとGeminiにもそれぞれ独自の構造があります。変換に対応しているという説明は、すべてのツール、推論フィールド、画像で動作が損なわれないことを保証するものではありません。
簡単な受け入れテスト
以下は読者向けに提案するテストであり、この記事で実施したテストではありません。
- 使い捨てのリポジトリと権限を絞ったテスト用認証情報を使います。元のエージェント設定を保存してください。
- エージェントを1つのプロバイダーに接続します。通常の応答を確認し、実際に選択されたプロバイダー／モデルを調べます。
- 無害なファイルを読み、小さな変更を提案するよう依頼します。書き込みを許可する前に、ツール呼び出しと結果の一連の流れが最後まで完了すること、ストリーミングが完了することを確認してください。
- 必要な場合に限り、2つ目のルートを追加します。安全なローカルモック、または許可を得たテスト環境で、想定した障害条件と、ドキュメントに記載された代替先が選択されるかを確認します。有料クォータを意図的に使い切るのは避けてください。
- 再試行や復旧によって、ワークフロー内の副作用を伴うツール操作が繰り返されないことを確認します。これは受け入れ基準であり、確認済みの製品バグではありません。
- 管理ツールを停止し、ドキュメントに記載された直接接続への復帰手順または復元手順を確認します。再起動が必要かどうかを調べたうえで、使用量の推定値とプロバイダーの記録を照合します。
このテストに合格する、最もシンプルな構成を選びましょう。公式プロバイダーを使ったエージェント1つでニーズを満たせるなら、ローカルゲートウェイを追加しても何も解決しない可能性があります。
結論：勝者ではなく、管理者を選ぶ
複数エージェント間でモデルとアカウントを共有してルーティングするなら、まずMagpieを検討しましょう。デスクトップでの設定とワークスペース管理なら、まずCC Switchを検討しましょう。明示的なリクエストポリシーとルートの確認なら、まずCCRを検討しましょう。再利用可能なアカウント連携型プロキシなら、付属コンポーネントも考慮したうえで、まずCLIProxyAPIを検討しましょう。
これらの推奨は、各製品のドキュメント上の重点を示すものであり、実測した優位性を示すものではありません。適切な構成とは、どのモデルがリクエストを処理したか、どの認証情報が使われたか、障害時に何が起きるか、変更をどう元に戻すかを説明できるものです。
よくある質問
CC Switchは単なる設定切り替えツールですか？
いいえ。Direct、Routing、Aggregationの各モードに対応しており、ローカルでの形式変換や、ツールごとのフェイルオーバーキューもドキュメントに記載されています。利用できる機能はクライアントとプロバイダーによって異なります。
Aggregationを使えば自動的にフォールバックされますか？
いいえ。CC Switchでは、Aggregationとフェイルオーバーは明確に区別されています。モデルをまとめて選べることは、障害復旧ポリシーがあることを意味しません。
Magpieではすべてのリクエストがローカルにとどまりますか？
いいえ。ゲートウェイはローカルで動作しますが、リモートプロバイダーを使った推論では、リクエストがアップストリームに送信されます。READMEには、テレメトリーの制御と、パートナーイベントを別途カウントする仕組みも記載されています。任意のマスキング機能はデフォルトでオフになっており、値を見逃したり、誤って分類したりする可能性があります。
モデルを切り替えると、エージェントのツールや権限も変わりますか？
それだけでは変わりません。エージェントのツール環境と権限ルールは引き続きエージェント側が管理します。また、新しいモデルでそれらのツールがどう扱われるかも、引き続き検証が必要です。
どのクライアントでも、サブスクリプションログインをAPIキーの代わりに使えますか？
そうとは限りません。技術的なログイン対応、利用できるモデル、アカウントの利用資格、プロバイダーの許可は、それぞれ別の問題です。最新の利用規約と組織のポリシーを確認してください。
最速、または最も安全な製品はどれですか？
この比較では判断できません。公式ドキュメントを参照しており、独立した性能ベンチマーク、信頼性測定、セキュリティ監査は実施していません。
出典
2026年11月3日に確認した公式資料：
- Magpie README — ゲートウェイ、エージェント、グループ、Library、プライバシー関連の動作。
- CC Switch README — 接続モード、エージェントごとの対応状況、再起動、ストレージ。
- Claude Code Router README — エージェントプロファイル、ルーティング、認証情報、デプロイ。
- CLIProxyAPI README — 互換インターフェース、アカウント、コンパニオンソフトウェア、統計機能の範囲。
- CCR provider guide — アップストリームのプロトコル、カスタムプロバイダー、認証情報プール、テストリクエストのコスト。
