この記事は AIHubMix が作成しました。2026-11-03 時点の公式ドキュメントに基づく比較であり、実機検証、性能ベンチマーク、信頼性試験、セキュリティ監査は行っていません。クライアント、プロバイダー、リリースが異なれば、記載された対応機能も同じように動くとは限りません。Claude Code Router の README には AIHubMix がスポンサーとして掲載されています。この関係は開示しますが、技術的な評価の根拠にはしていません。
TL;DR
- 複数の Agent でモデルやアカウントの経路を共有したいなら、まず Magpie を候補にします。
- 接続先と MCP、スキル、プロジェクト設定をデスクトップでまとめたいなら、CC Switch を候補にします。設定切り替えだけでなくルーティングも備えています。
- リクエスト条件、認証情報プール、経路ログを明示的に管理したいなら Claude Code Router、アカウントを背後に持つ互換プロキシが必要なら CLIProxyAPI を候補にします。
- これはドキュメント上の重点を基にした編集上の提案です。性能や安全性の順位ではありません。最終的には、実際に使う構成で応答、ツール呼び出し、復旧、設定の復元を確認します。
最初に決めるのは「どの設定を誰が管理するか」
導入後に説明できるようにしたいのは、どのモデルが応答し、どの認証情報を使い、失敗時にどこへ進み、どう元へ戻すかです。モデル一覧の長さよりも、この責任分界を先に決めます。
Claude Code、Codex、Gemini CLI は、ファイルやシェルへのアクセス、承認ルール、会話ループなどの実行環境を担います。モデルは応答を生成し、プロバイダーはそのモデルへのアクセスを提供します。接続先を変えても、Claude Code が Codex になるわけではなく、Agent の権限もそれだけでは置き換わりません。
接続先管理では、次の操作を分けて考えます。
- 設定切り替え：エンドポイント、キー、モデルを変更します。
- ルーティング：Agent と接続先の間にゲートウェイを置き、経路選択や形式変換を行います。
- モデル集約：複数のモデルを同じ選択肢に並べます。これ自体はフォールバックではありません。
- アカウントプール：認証情報やアカウントにリクエストを振り分けます。ラウンドロビンだけでは失敗からの復旧を保証しません。
- フォールバック：所定の失敗条件に応じて、別の設定済み接続先を試します。
プロトコルの境界も残ります。OpenAI Chat Completions と Responses は別の API で、Anthropic Messages や Gemini にも固有の構造があります。形式変換への対応だけで、ツール呼び出し、reasoning フィールド、画像、ストリーミングがすべて同等になるとは判断できません。
また、互換 base URL を受け付けることと、Agent の設定をネイティブに管理できることは別です。対応機能はクライアント、プロバイダー、リリースごとに確認する必要があります。
検討の出発点を絞る
何を検証するかを決めるための一覧であり、独占的な機能や性能の順位ではありません。
| ツール | 主な検討の起点 | 先に確認する点 |
|---|---|---|
| Magpie | 共有ゲートウェイ | 代替先の有無 |
| CC Switch | デスクトップ管理 | 集約に復旧機能なし |
| CCR | 経路のルール | 各ルールの検証 |
| CLIProxyAPI | アカウント型プロキシ | UI・統計は別構成 |
CCR は Claude Code Router の略です。各製品の機能は重なっています。Magpie のフォールバックには別の利用可能な接続先が必要で、CC Switch の Aggregation はフェイルオーバーを提供しません。CCR のルールは検証が必要で、CLIProxyAPI のデスクトップ画面と統計は別コンポーネントです。対応範囲は Agent とプロバイダーで異なります。
4製品の違いを、管理対象から読む
Magpie：複数の Agent に共通のゲートウェイを置く
Magpie は、Agent のネイティブな設定管理とローカルゲートウェイを組み合わせています。文書上の連携対象には Claude Code、Codex、Gemini CLI、OpenCode、Cline、Cursor CLI などがあります。ほかの互換クライアントもエンドポイントへ接続できますが、それだけで専用の設定連携があるとは限りません。
ゲートウェイは OpenAI Chat、OpenAI Responses、Anthropic Messages、Gemini の形式を変換します。接続先として API キー型サービス、互換カスタムエンドポイント、ローカルモデルサーバー、対応するサブスクリプションアカウントを扱い、プロファイルでは複数の Agent の設定をまとめます。
中心となるのが、複数のモデルやプロバイダーを1つの選択肢にするルーティンググループです。
-
order：先頭のメンバーを使い、応答できなくなったら次を試します。 -
rotate：ターンごとにメンバーを変えます。 -
usage：使用量が最も少ないメンバーを優先します。 -
smart：利用枠が残る対象サブスクリプションのうち、リセットが近いものを優先します。 -
pace：リセットまでの時間に対する週次の残容量を基に選びます。
グループは入れ子にできます。会話を同じアカウントへ維持する方針は、プロンプトキャッシュを活用するためのものですが、任意のプロバイダー変更でキャッシュが引き継がれる証明ではありません。任意の intent routing は選択したモデルに新しいターンを読ませる機能であり、常に費用を削減するとは確認されていません。
フォールバックには、利用可能な別の行き先が必要です。アカウントが1つでルーティンググループもなければ、エラーは Agent に返ります。
Library では指示、MCP サーバー、スキル、サブエージェントを管理します。使用量、残枠、費用、セッションの表示も文書化されており、ルーターだけの製品ではありません。
CC Switch：デスクトップの設定管理と経路制御をまとめる
CC Switch は、プロバイダーに加えて MCP、スキル、プロンプト、プロジェクト、セッション、使用量、バックアップ、同期を扱います。Claude Code、Claude Desktop、Codex、Gemini CLI、OpenCode などが記載されていますが、クライアントごとの対応範囲は同一ではありません。
接続方式は3つに分かれます。
- Direct：Agent が選択したプロバイダーへ直接接続します。プロジェクトは、切り替え時に無関係な hooks、plugins、MCP 設定、コメントを保持すると説明しています。
- Routing：ローカルで転送し、Anthropic Messages、OpenAI Chat Completions、OpenAI Responses、Gemini Native を変換します。ツール別のフェイルオーバーキュー、サーキットブレーカー、プロバイダーのヘルス監視も備えます。
- Aggregation：Claude Code と Codex のモデル選択欄へ複数プロバイダーのモデルを並べ、選ばれたモデルの提供元へ送ります。Aggregation にフェイルオーバーはありません。
Aggregation では Claude の公式サブスクリプションを使えません。公式ログイン型のプロバイダーは原則 Routing に入れられず、Codex の OpenAI Official が文書上の例外です。詳細はユーザーマニュアルのクライアント別・モード別の条件を確認します。
同期も復元手段のすべてではありません。データの既定保存先は ~/.cc-switch で、SQLite と関連ファイルを使います。WebDAV/S3 互換同期があっても、一部の端末設定、状態、元の設定のバックアップはローカルに残ります。
Claude Code Router：ルール、認証情報プール、経路ログを管理する
Claude Code Router（CCR）は、複数 Agent 向けのゲートウェイ兼コントロールプレーンとして説明されています。Claude Code だけでなく、Codex、OpenCode、Pi、Kimi CLI、Grok CLI なども README に記載されています。
重点は、ヘッダーや本文の条件、プレフィックス、リクエスト書き換え、リトライ、順序付きフォールバックモデルといった明示的なポリシーです。認証情報プール、キーローテーション、Agent プロファイル、モデル上書き、環境設定も扱います。
ログにはリクエストとレスポンスの詳細、解決されたプロバイダー・モデル・認証情報、ステータス、レイテンシー、トークン、推定費用、ツール呼び出し、トレースが文書化されています。経路を調べる材料にはなりますが、タスク品質が向上する証拠ではなく、推定費用も請求書ではありません。
デスクトップ版、ブラウザー管理 UI を持つ npm CLI、Docker の選択肢があります。npm CLI は Node.js 22 以降が必要です。プロバイダーガイドはプロトコル、カスタム接続先、認証情報プールを説明し、接続テストが上流へリクエストを送ることも警告しています。有料の利用量やリクエスト枠を消費し得るため、無償の疎通確認だと考えないようにします。
条件とログから経路を説明したい場合に候補になります。ただし、ルールや復旧経路を増やすほど、検証する組み合わせも増えます。
CLIProxyAPI：アカウントを背後に持つ互換エンドポイントを用意する
CLIProxyAPI は、Responses を含む OpenAI 互換、Interactions を含む Gemini 互換、Claude 互換のインターフェースをクライアントや SDK へ提供します。
README には Codex と Claude Code の OAuth、Gemini アカウントへのアクセス、複数プロバイダー向けのラウンドロビンによる複数アカウント分散、設定した OpenAI 互換接続先、再利用可能な Go SDK が記載されています。互換エンドポイントを提供することは、コアが各 Agent のプロファイルをネイティブに編集するという意味ではありません。
周辺機能は別コンポーネントとして数えます。GUI 設定、更新、トレイ操作、サービスの起動・停止には、README が別のデスクトップ用コンパニオン EasyCLIProxyAPI を推奨しています。また、v6.10.0 以降、CLIProxyAPI と CPAMC は使用量統計を内蔵しておらず、別の統計・管理プロジェクトが案内されています。
これは、リトライやフォールバック、復旧制御がないという結論ではありません。選んだリリースの設定を確認します。一方、ラウンドロビン分散だけでモデルをまたぐフォールバックを保証するとも判断できません。
ハマりどころ
ローカルゲートウェイなので、すべてローカルで完結すると思ってしまう
Magpie のマスキングは既定で無効です。有効にすると、検出した機密値をローカルで置換してから送信し、返信のツール引数などで元に戻します。ただし、見逃しや誤検出があり、モデルはマスクされた元の値を確認できません。有効なマスキングが実行できない場合、README は HTTP 503 で送信を止めると説明しています。
プライバシードキュメントでは、既存の Agent のサインインを読み取るアカウント検出についても説明されています。この検出は無効化できます。
リリースビルドの毎日のテレメトリーには、ランダム識別子、バージョン、システム、製品利用に関する識別子が含まれると説明されています。プライバシー設定または DO_NOT_TRACK=1 で停止できますが、パートナーリンクのクリックとパートナー一覧の取得の集計は独立しています。README は、この集計では識別子やアドレスを保持しないとしています。ローカルゲートウェイという名称を、ほかのネットワーク通信がない保証として扱わないことが重要です。
接続確認が成功したので、モデルも使えると思ってしまう
CC Switch のプロバイダーカードの接続確認は到達性の確認であり、API キーやモデルの有効性を検証するものではありません。
一方、CCR の接続テストは上流へのリクエストを伴い、利用量やリクエスト枠を消費し得ます。「接続確認」という同じ言葉でも、確認内容と費用の境界を分けて読みます。
切り替えたのに、実行中のクライアントへ反映されない
CC Switch は Claude Code のホット切り替えを文書化していますが、Codex、Gemini CLI、Grok Build の Direct での変更は通常再起動が必要です。Routing でもモデルが変わると再起動が必要な場合があります。Codex の集約モデル一覧を変更した場合は、対象のデーモン、アプリケーション、エディター環境を再起動します。作業中のタスクとは分けて計画します。
OAuth でログインできるので、どのクライアントでも使えると思ってしまう
技術的なログイン対応と、プロバイダーが許可する利用方法は別です。CC Switch は公式クライアント以外でのサブスクリプション利用について明示的に注意しています。現在の規約と組織のルールを確認します。管理ツールを導入しても、利用権が増えたり制限が消えたりするわけではありません。
設定を戻せない、ログや同期に何が残るか説明できない
同じ Agent 設定を複数の管理ツールに自動書き換えさせず、元のファイルと直接接続へ戻す手順を確保します。これは運用上の予防策であり、製品の不具合を実証した指摘ではありません。
本比較では保存時暗号化を検証していません。本番の認証情報を入れる前に、ファイル権限、アカウント検出、バックアップと同期の対象、リクエストログの内容を確認します。リモートアクセスを有効にする場合は、認証と公開範囲を別に確認します。ローカルの初期設定だけを安全性の保証にしないようにします。
導入前の受け入れ確認案
以下は読者向けの確認手順案であり、本記事で実施した試験結果ではありません。
- 元の状態を保存します。 使い捨てのリポジトリと低権限のテスト用認証情報を使い、Agent の設定をバックアップします。設定を管理するツールを1つに決めます。
- まず1経路を確認します。 1つの Agent と1つのプロバイダーを接続し、通常の応答と実際に解決されたプロバイダー・モデルを確認します。接続確認の表示だけでは完了にしません。
- Agent としての動作を確認します。 無害なファイルの読み取りと小さな変更の提案を依頼します。書き込みを許可する前に、ツール呼び出しと結果の往復、ストリーミングの完了を確認します。
- 必要な場合だけ代替経路を追加します。 安全なローカルモックまたは許可されたテスト環境で、想定する失敗条件と代替先の選択を確認します。有料の利用枠を意図的に使い切る方法は避けます。
- 副作用を確認します。 リトライや復旧によって、副作用のあるツール操作が繰り返されないことを確認します。これは受け入れ条件であり、観測済みの製品不具合ではありません。
- 撤去を試します。 管理ツールを停止し、文書化された設定復元または直接接続への復帰を確認します。必要な再起動を行い、使用量の推定値をプロバイダーの記録と照合します。
まとめ
- Magpie は共通ゲートウェイとモデル・アカウント経路、CC Switch はデスクトップの設定・ワークスペース管理を起点に検討します。両者の機能は重なっています。
- CCR は条件、認証情報プール、ログによる経路の説明、CLIProxyAPI はアカウントを背後に持つ互換プロキシを起点に検討します。周辺コンポーネントの管理も数えます。
- 集約、分散、フォールバックを同じ機能として扱わず、対応プロトコルとネイティブ連携も分けて確認します。
- 推奨は文書上の重点からの提案です。性能、信頼性、安全性の優劣を測定した結果ではありません。1つの Agent と公式プロバイダーで要件を満たすなら、ゲートウェイを増やさない選択もあります。
まずは使い捨てのリポジトリで上記の受け入れ確認を行い、経路と復元手順を説明できる最小構成を選んでください。
参考
公式資料の確認日：2026年11月3日。
- Magpie README（Magpie プロジェクト）— 連携、ルーティンググループ、Library、プライバシー動作。
- CC Switch README（CC Switch プロジェクト）— 接続モード、クライアント別対応、再起動、保存先。
- Claude Code Router README（Claude Code Router プロジェクト）— Agent、ルール、認証情報、デプロイ。
- CLIProxyAPI README（CLIProxyAPI プロジェクト）— 互換インターフェース、アカウント、コンパニオン、統計の境界。
- CCR provider guide（Claude Code Router）— プロトコル、プール、接続テストの利用量。