著者注：magpie と CC Switch は、どちらもローカルの Agent 設定ファイルを書き換えます。この記事では、アーキテクチャ、リリース頻度、機能、対象ユーザーの違いを比較し、設定の書き込みをどちらか一方に任せる必要がある理由を説明します。
~/.claude/settings.json は最近、少し厄介な立場に置かれています。CC Switch は1年以上にわたり、プロバイダーを切り替える際に接続に関するフィールドだけを変更し、それ以外の内容はそのまま残してきました。一方、magpie もこのファイルに書き込み、接続先を 127.0.0.1:3425 に変更します。2つのプログラムが同じファイルに書き込むため、最後に書き込んだほうが優先され、先に行われた変更は通知なく上書きされます。そのため、この設定ファイルへの書き込みは、同時に1つのプログラムにしか任せられません。
2つのプロジェクトでは、リリースのペースも大きく異なります。2026-10-28時点で、magpie のリリースリポジトリは2026-09-23の作成以来、リリース番号の累計が1000を超えています。2026-10-27の1日だけでも、GitHub API で確認できるリリースは87件ありました。一方、CC Switch は v3.19.0（2026-07-30）から v4.0.21（2026-10-26）までの3か月間に、正式版を30回リリースしており、それぞれに中国語のリリースノートが付いています。magpie は英語でカササギのことですが、このカササギは1日に何十回もバージョン更新を知らせているわけです。
コミュニティでも magpie の評価は分かれています。linux.do には2026-10-10、「magpie は使っていてかなり混乱する。CC Switch に慣れているなら乗り換えはおすすめしない」というタイトルの投稿がありました。翌日には「なぜみんな magpie を推しているのか。ダウンロードしてみたけれど、特に優れているとは感じない」という投稿もありました。CC Switch が取って代わられるのではないかと心配する人もいますが、私たちの結論は、取って代わられることはないものの、magpie に移ったユーザーは確かにいる、というものです。
この記事はインストール手順の解説ではありません。どちらが全面的に優れているかを決めるのでもなく、2つのアプローチの違いを整理し、どちらを使い続けるかを判断する手助けをします。
Magpie VS CC Switchのリリースペース：1日数十パッケージ vs 3か月で30バージョン
両者の違いが最もよく表れているのが、リリースペースです。まずはここから見ていきましょう。magpieのバージョン番号は0.1.xのままですが、パッチ番号は急速に増えています。2026-10-03 13:00から10-04 14:00までの25時間で、v0.1.756からv0.1.859まで、ちょうど100バージョンがリリースされました。2026-10-28時点の最新版はv0.1.1801です。GitHubのAPIではリリース履歴を最大1000件までしか取得できず、それ以前の記録は確認できません。リリースの総数はさらに増え続けていることがわかります。
このリリース番号の性質には注意が必要です。番号は自動ビルドによって生成されるパッチ番号で、ほぼすべてのコミットでパッケージが作られます。1000回の機能アップデートが行われたわけではありません。この頻度からは、メンテナンスが活発で問題の修正が速いことがわかります。一方で、0.1.xはまだ頻繁に試行錯誤を重ねている段階でもあり、バージョン番号自体が、高い安定性を期待すべきではないことを示しています。
| 指標（2026-10-28時点） | magpie | CC Switch |
|---|---|---|
| リポジトリ作成日 | 2026-09-23 | 2025-08-04 |
| 最新バージョン | v0.1.1801 | v4.0.21（2026-10-26） |
| リリースペース | 1日最大87件を確認、累計1000件以上 | 3か月で正式版30件 |
| GitHubスター数 | 約2.38万 | 約14.9万 |
| 対応ツール | READMEに68のAgentを掲載 | 12ツール、それぞれに専用プリセットあり |
| メンテナンス方針 | 外部からのPRは受け付けず、メンテナーのみ作成可能 | issue / PRによる協力を受け付け |
スター約14.9万と1日100パッケージという数字を並べると、2つのプロジェクトが異なる段階にあることがわかります。CC Switchにはすでに膨大なユーザー層があり、magpieはまだ急速なイテレーションを続けています。どちらがより熱心かという話ではなく、チームのペースやリスクに対する考え方の違いです。CC Switchの作者によると、4.0のリファクタリング時に過去のissueを500件以上クローズしました。magpieは1か月余りでスター数が約2.38万に達しましたが、人気と安定性は分けて考える必要があります。
もう1つ注意点があります。APIYIのドキュメントサイトにあるCC Switchのページ（docs.apiyi.comのシナリオ別チュートリアル）には、現在もv3.12.0と5ツールと記載されており、公式リポジトリの12ツール、v4.0.21という情報より古くなっています。バージョンはGitHubで確認してください。
Magpie VS CC Switch の主な違い：設定ファイルを書き換えるか、ローカルゲートウェイを経由するか
両者の最も根本的な違いはアプローチにあります。CC Switch は Agent 中心、magpie はゲートウェイ中心です。
CC Switch は切り替え時に、各ツールの設定ファイルにある接続先アドレス、キー、モデルなどの接続フィールドだけを置き換えます。プラグイン、Hook、MCP、自分で追加した設定やコメントはそのまま保持され、初回の書き換え前には元のファイルが自動的にバックアップされます。Claude Code、Codex、Gemini CLI では「切り替え型」を採用し、同時に有効になるプロバイダーは1つだけです。OpenCode、OpenClaw、Hermes、Pi では「共存型」を採用し、複数のプロバイダーをツール自身の設定に同時に書き込みます。CC Switch にもローカルルーティング機能がありますが、手動で有効にする必要があります。有効にすると、Anthropic Messages、OpenAI Chat Completions、OpenAI Responses、Gemini Native の間でプロトコルを変換でき、フェイルオーバーキューやサーキットブレーカーも利用できます。
一方、magpie はまず各 Agent の接続先を 127.0.0.1:3425 に統一し、APIキーを magpie 内で一元管理したうえで、ゲートウェイから上流へリクエストを転送します。ゲートウェイは4種類のプロトコル間の相互変換に対応し、ストリーミング出力、ツール呼び出し、推論内容も変換できます。magpie も Agent 自身の設定の重要なフィールドを書き換えます。README には「magpie edits the one key that matters in the agent’s own config」と記載されており、アトミック書き込みを採用して、コメント、順序、書式を保持します。設定ファイルを書き換えたくない場合は、OPENAI_BASE_URL、ANTHROPIC_BASE_URL、GOOGLE_GEMINI_BASE_URL をローカルゲートウェイに向け、キーに magpie と入力するだけでも利用できます。
| 比較項目 | magpie | CC Switch |
|---|---|---|
| 位置づけ | ローカルゲートウェイ + 切り替えツール | デスクトップ設定マネージャー + オプションのローカルルーティング |
| 切り替え方式 | リクエストを 127.0.0.1:3425 に経由させてから送信 |
各ツールの設定にある接続フィールドを書き換え |
| アカウントの耐障害性 | ルーティンググループの5つのモード + 複数アカウントのフェイルオーバー + Daily warm-up | フェイルオーバーキュー + サーキットブレーカー + ヘルス監視 |
| 日常管理 | Library：指示、MCP、skills、subagent を一元管理 | MCP パネル + Skills + プロンプトライブラリ + セッションマネージャー |
| セッション | 一覧に各セッションの費用を表示し、ワンクリックでターミナルで再開 | 構造化された内容への解析、ターンごとの要約、エクスポートと復元コマンド |
| 実行環境 | デスクトップ、TUI、CLI、Web UI、Docker、Termux | デスクトップ + トレイ |
magpie の強み：ルーティング、耐障害性、移行
magpie がユーザーを引きつける主なポイントは次のとおりです。
- 移行コストが低い：プロバイダー画面の Import 機能を使えば、CC Switch のプロバイダーを直接インポートでき、数分で移行が完了します。CC Switch にとって最も直接的な脅威となるポイントです。
- ルーティンググループ：
group/daily-codingのように、グループを1つのモデルとして Agent に渡せます。グループ内では smart、order、rotate、usage、pace の5つのモードに対応しています。キャッシュを活用できるセッションは、最初に応答したアカウントに維持されます。 - サブスクリプションをプロバイダーとして利用：ログイン済みの Claude、ChatGPT、Copilot などのサブスクリプションをプロバイダーとして、ほかの Agent から利用できます。この機能はプライバシー設定でオフにできます。
- プライバシーマスク：キー、トークン、メールアドレスなどをローカル環境でプレースホルダーに置き換えてから送信します。この機能はデフォルトでオフです。有効にした場合、マスクされるべき情報がマスクされなかったときは、リクエストに対して直接 503 を返し、元の内容は送信しません。
- ローカルネットワークでの共有とデプロイ：クライアントごとに独立したゲートウェイキーを割り当て、費用の上限を設定できます。Docker を使って NAS 上で動かすことも可能です。
CC Switch の強み：日常管理のきめ細かさ
CC Switch は、日常的な管理機能がより充実しています。
- MCP の統合パネル：ツールごとにチェックを入れて同期でき、各ツールから既存の設定をインポートできます。
- Skills 管理：GitHub や ZIP からワンクリックでインストールでき、一括更新にも対応しています。
- プロンプトライブラリ：有効化すると CLAUDE.md / AGENTS.md に書き込みます。その前に、ファイル内の既存の内容をプロンプトライブラリに保存します。
- セッションマネージャー：各ターンを1行の要約に折りたたみ、失敗したステップを赤く表示します。再開用のコマンドをコピーして会話を続けることもできます。
- プロジェクトスナップショット：プロバイダー、MCP、Skills、プロンプトをプロジェクトごとにまとめて切り替えられます。
v4.0.21 では、複数の Claude 公式サブスクリプションアカウントを切り替える機能も追加されました。ログインは公式の手順で行い、トークンは Claude Code 自体の保存場所にのみ保存されます。CC Switch はトークンを記録・アップロードせず、利用枠に応じた自動ローテーションも行わないことを明言しています。この設計は比較的慎重で、magpie とは対照的なアプローチです。
ツールはリクエストを転送するだけ：Magpie と CC Switch で使うモデルとキー
どちらのツールを選んでも、リクエストを転送する役割を担うだけで、モデルとキーは別途用意する必要があります。スムーズに利用できるかどうかは、安定して使える claude-opus-5-5 の APIキーがあるかどうかにかかっています。APIYI（apiyi.com）は Anthropic 互換と OpenAI 互換の両方のエンドポイントを提供しており、どちらのツールからも直接接続できます。
| 接続項目 | 設定値 | 説明 |
|---|---|---|
| Anthropic 互換 URL | https://api.apiyi.com |
/v1 なし。Claude Code に適しています |
| OpenAI 互換 URL | https://api.apiyi.com/v1 |
Codex などの OpenAI プロトコル対応ツールに適しています |
| モデル名 | claude-opus-5-5 |
thinking 版の claude-opus-5-5-thinking も同価格 |
| 料金（100万トークンあたり） | 入力 $4 / 出力 $20 / キャッシュ読み取り $0.2 | 2026年10月28日時点。モデルと料金はプラットフォームのモデル一覧をご確認ください |
| エンドポイントとグループ | chat、messages；ClaudeCode、Default、SVIP などのグループ | 用途に合わせてグループを選択してください |
注意したいのは、両ツールが同じ Agent 設定を読み込むことです。CC Switch は APIキーを ~/.claude/settings.json に書き込み、magpie はゲートウェイに保存しますが、どちらも最終的には同じ接続先のアカウントにつながります。そのため、APIキーの変更は APIYI コンソールで一度行うだけで済み、残高や使用量も同じ場所で確認できます。2つのツールでそれぞれ設定する必要はありません。
Magpie VS CC Switch：利用シーン別に見る、使い続ける人と乗り換える人
CC Switch を使い続けたい人
主に Claude Code を使っていて、プロバイダーは1〜2社。安定性を重視し、アップグレードのたびにトラブルを調べたくない人には、CC Switch が向いています。変更する範囲が小さく、バックアップ機能も充実しているため、問題が起きても設定ファイルを直接開いて原因を確認できます。MCP、Skills、プロンプトをよく整理する人や、過去のセッションを振り返りたい人にも、CC Switch の画面や操作方法のほうがなじみやすいでしょう。
10月10日の投稿主は、次のようにはっきり述べています。「プロバイダーがひとまとめになっていて、わざわざこれに乗り換える必要はまったくない。ごちゃごちゃしているし、さらに面倒なのは、このソフト経由でモデルを選択すると、CLI でモデルを切り替えられなくなること」。同じ投稿には「今のところ CCS を圧倒するような独自機能は感じられない」という声もありました。こうしたユーザーが求めているのはプロバイダーのワンクリック切り替えであり、CC Switch ですでにそのニーズを満たせています。
magpie に乗り換えたい人
Codex、Gemini CLI、OpenCode、Pi など複数のエージェントを併用し、複数のサブスクリプションやキーを持っている人には、ゲートウェイ方式を採用する magpie が向いています。利用枠を使い切ったら自動で切り替えたい人や、コストを一覧できるダッシュボードが必要な人にも適しています。同日、投稿には「午後に ccswitcg から magpie に切り替えたばかり。ようやく中継先を一つひとつ試して使えるか確認しなくて済むようになった」という声がありました。10月11日の投稿でも、支持者から「magpie は追加も切り替えも ccs より便利で、強力なルーティングルールもある」との意見が出ています。また、CC Switch を Codex app で使うと、モデルを正常に表示・切り替えできないという指摘もありました。
magpie に対する否定的なフィードバックは、分けて考える必要があります。magpie を導入した後、Claude のキャッシュが効かなくなったように見え、費用が上がったという報告がありました。また、投稿内には、中間レイヤーでプロンプトが検閲され、リクエストが拒否されたのではないかという声もあります。この2件はいずれも単発の報告で、再現手順は示されていません。これらを根拠に、magpie にそのような問題があると断定することはできません。この記事の情報源は、プロジェクト公式の説明、第三者による単発の報告、まだ結論が出ていない内容の3種類に分かれます。それぞれを区別してご覧ください。
Magpie VS CC Switch：5つのタイプ別おすすめ
| あなたの使い方 | おすすめ | 理由 |
|---|---|---|
| Claude Codeだけを使い、プロバイダーは1〜2社。安定性を重視 | CC Switch | 変更が少なく、バックアップもある。3か月で正式版30件とリリースのペースも安定 |
| 複数のAgent・アカウントを使い、自動障害対応とコストの可視化が必要 | magpie | ルーティンググループ + フェイルオーバー + 使用量統計 |
| MCP、Skills、プロンプト、セッションの振り返りに課題がある | CC Switch | 管理画面がより細かく、セッションの解析も充実 |
| LAN内で共有したい、NASで動かしたい、非対応のAgent向けにプロトコルを変換したい | magpie | ゲートウェイ機能があり、Dockerでもデプロイ可能 |
| 両方使いたい | 設定を書き込むのは一方だけにする | 次の節を参照 |
💡 選び方のヒント：どちらにするか迷ったら、同じAPIキーを使って、それぞれ半日ずつ試してみるのもよいでしょう。CC Switchの接続手順はAPIYIのチュートリアル
docs.apiyi.com/scenarios/programming/cc-switch、magpieの統合ゲートウェイへの接続手順はhelp.apiyi.com/magpie-unify-claude-code-codex-pi-hermes-api-gateway.htmlを参照してください。手順に沿って設定できるので、最初から自分で調べる必要はありません。
同時インストールの注意点：settings.jsonを管理できるのは1つのプログラムだけ
ここで冒頭の疑問に戻ります。magpieとCC Switchは、~/.claude/settings.jsonや~/.codex/config.tomlなど、同じ設定ファイルを書き換えます。両方を同時に実行していると、一方でプロバイダーを切り替えた際に、もう一方の設定が通知なしに上書きされます。その結果、Claude Codeが実際にどのプロバイダーを使うかは、最後に書き込んだツールによって決まります。
両者を共存させるには、どちらが設定ファイルを管理するか決めておく必要があります。一方が書き込みを担当し、もう一方は読み取り専用にするか、使い終わったら終了します。例えば、MCPとプロンプトの管理はCC Switchに任せ、プロバイダーの切り替えはすべてmagpieに任せる、またはその逆にする方法があります。2つのプログラムがそれぞれ継続的に書き込む運用は避けてください。移行する場合は、magpieのImport機能でCC Switchのプロバイダーをインポートし、問題がないことを確認してから古いツールを終了すると、両方から同時に書き込まれる事態を避けられます。
リスクやアカウント停止は自己責任：MagpieとCC Switchはどちらも事前にバックアップを
以下の点をあらかじめ確認してください。
- どちらもサードパーティー製のオープンソースツール（ともにMITライセンス）で、ローカルのAgentの設定ファイルを書き換えます。インストール前に
~/.claude/settings.jsonや~/.codex/config.tomlなどを手動でバックアップし、ツール付属のバックアップ機能だけに頼らないでください。 - サブスクリプションを公式クライアント以外で使う場合、規約上のリスクがあります：Claude、ChatGPT、Copilotのサブスクリプションを公式クライアント以外で使用すると、提供元のサービス利用規約に違反する可能性があります。CC Switch自身のドキュメントにも同様の注意書きがあります。magpieの「サブスクリプションをプロバイダーとして使う」機能は、Settings → Privacyで無効にできます。
- 結果は自己責任です：設定の上書き、利用枠の損失、アカウントに関するリスクなどの結果は、ご自身の責任となります。この記事は、いずれのツールの利用も保証するものではありません。まずはサブアカウントや重要度の低いプロジェクトで試すことをおすすめします。
よくある質問 FAQ
Q1：Magpie と CC Switch は同時にインストールできますか？
同時にインストールできますが、同時に設定を書き込むことはできません。どちらも同じ `~/.claude/settings.json` を書き換えるため、一方を書き込み担当に決め、もう一方は読み取り専用にするか終了してください。
Q2：magpie は1か月余りで1,000以上のバージョンが公開されていますが、不安定なのでしょうか？
これらの多くは自動ビルドによって付けられたパッチ番号で、頻繁にメンテナンスされ、修正も素早く行われていることを示しています。ただし、0.1.x はまだ試行錯誤の段階にあるため、安定性を重視する方はしばらく様子を見ることをおすすめします。
Q3：magpie によってキャッシュが無効になり、料金が上がることはありますか？
現時点では一部のユーザーから報告があっただけで、再現手順も明らかになっていないため、結論は出せません。心配な場合は、切り替え前後の使用量ダッシュボードを比較して確認できます。
Q4：ツールを変更したら、APIキーを再申請する必要がありますか？
必要ありません。どちらのツールもリクエストを転送するだけなので、APIキーはそのまま使えます。APIYI apiyi.com のコンソールで管理している同じAPIキーを、CC Switch または magpie に入力して利用できます。
Q5：claude-opus-5-5 にはどのアドレスを入力すればよいですか？
Claude Code は Anthropic プロトコルを使うため、`/v1` が付かないアドレスを入力します。Codex などの OpenAI プロトコル対応ツールには、`/v1` が付くアドレスを入力してください。2026-10-28 時点の料金は、100万トークンあたり入力 $4、出力 $20、キャッシュ読み取り $0.2 です。詳細は apiyi.com のモデル一覧を確認してください。
Q6：magpie は CC Switch に取って代わりますか？
いいえ。両者は役割が異なります。CC Switch は Agent の設定を管理・切り替えするツールで、magpie はすべてのリクエストをまずローカルのゲートウェイに通すツールです。主に影響を受けるのは、CC Switch ユーザーのうち「ワンクリックでプロバイダーを切り替える機能だけが必要」という方です。
Magpie VS CC Switch の主なポイント
- アプローチの違い：CC Switch は設定ファイルを書き換え、magpie はリクエストをローカルゲートウェイ
127.0.0.1:3425経由で送ります。 - リリースペースの違い：2026年10月28日時点で、magpie のリリース番号は累計1000を超え、CC Switch は3か月で30の正式版を公開しています。
- それぞれの強み：magpie はルーティング、耐障害性、プロトコル変換に優れ、CC Switch は MCP、Skills、セッション管理を得意としています。
- 同時に書き込みはできない：両ツールは同じ settings.json を書き換えるため、書き込み権限を持てるのは一方だけです。
- ネガティブなフィードバックの多くは単発の報告：キャッシュや検閲などに関する報告には再現手順が示されておらず、結論として扱うことはできません。
- APIキーの管理は一度で済む：APIYI のコンソールで一括変更できます。両ツールが読み取る Agent 設定は同じです。
まとめ
magpie と CC Switch の違いは、基本的にはアプローチの違いです。magpie はゲートウェイを中心に素早く改良を重ね、CC Switch は Agent の設定を中心に着実に機能を磨いています。magpie は「ワンクリックでプロバイダーを切り替えたい」というユーザーの一部を引きつける一方、CC Switch は日常的な管理機能のきめ細かさで優れています。コミュニティでの議論はしばらく続きそうですが、個人ユーザーにとって選択はそれほど複雑ではありません。
~/.claude/settings.json を同時に管理できるプログラムは一つだけです。上記の5種類の利用シーンを参考にツールを一つ選び、長く使えばよいでしょう。両方を行き来する必要はありません。
モデルと APIキーは APIYI（apiyi.com）で準備できます。同じ APIキーで claude-opus-5-5 に接続できるため、どちらのツールを選んでもすぐに利用できます。
📚 参考資料
- magpie GitHubリポジトリ：ローカル統合AIゲートウェイ・モデル切り替えツール
- リンク：
github.com/yetone/magpie -
説明：READMEには68のエージェント一覧とゲートウェイの説明が掲載されています。中国語版はREADME.zh-CN.mdです。
-
magpie公式ドキュメント：機能と設定の説明
- リンク：
usemagpie.ai/docs -
説明：ルーティンググループ、プライバシーマスキング、LAN内共有などの機能を詳しく説明しています。
-
CC Switch GitHubリポジトリ：クロスプラットフォーム対応のオールインワン管理ツール
- リンク：
github.com/farion1231/cc-switch -
説明：リリースノートと修正履歴を掲載しています。バージョン情報はこちらをご確認ください。
-
CC Switch公式サイト：製品紹介とダウンロード
- リンク：
ccswitch.io - 説明：対応ツールの一覧と使い方を掲載しています。
著者：APIYI技術チーム
技術に関するお問い合わせ：APIYIのサイトトップページからお気軽にお問い合わせください。接続に関する詳しい資料は、docs.apiyi.comのドキュメントセンターをご覧ください。
