9Router と CC Switch はどちらも Claude Code や Codex の設定で登場しますが、代替関係ではありません。簡単に言えば、9Router は「要求をどのモデルへ送るか」を扱い、CC Switch は「複数の AI ツールで設定をどう保存・切替するか」を扱います。
| 要件 | 向くツール |
|---|---|
| 複数 Provider、モデル優先度、失敗時の自動切替 | 9Router |
| Claude Code、Codex、MCP、Skills の一元管理 | CC Switch |
| ローカル OpenAI-compatible endpoint | 9Router |
| GUI でのアカウント、設定、ワークスペース同期の切替 | CC Switch |
9Router：モデル呼び出しを1か所に集約する
9Router は AI コーディングツールの前に置くルーティング層です。クライアントは1つの endpoint を呼び、9Router が Provider、モデル、Combo を選び、上流失敗時には fallback できます。モデルをよく比較する人、key を集中管理したい人、複数クライアントで同じルールを使いたい人に向きます。
設定とエラー切り分けは 9Router Claude Code 設定ガイドを参照してください。
CC Switch：複数ツールの設定摩擦を減らす
CC Switch は複数の AI CLI 向け設定ワークスペースです。Provider、MCP、Prompts、Skills、プロキシ、セッションの管理に焦点を当て、分散した設定ファイルを手編集する手間を減らします。Claude Code、Codex、Gemini CLI などを切り替える場合に便利です。
機能範囲は CC Switch / CCSwitch 使用ガイドで確認できます。
一緒に使えるか
使えます。一般的には、CC Switch で Claude Code、Codex、MCP のローカル設定を管理し、これらのモデル要求を 9Router に向け、上流 Provider と fallback は 9Router に任せます。役割を分ければ、ツール切替で API key をコピーする必要がなく、モデル切替でも各クライアントを編集せずに済みます。
ただし、最初からすべてのプロキシ、同期、fallback ルールを有効にしないでください。まず1つのクライアントが 9Router 経由で1つのモデルを安定して呼べることを確認し、その後 CC Switch で設定を管理し、最後に複数 Provider を追加します。
選び方
- モデル呼び出しと耐障害性を統一したい：まず 9Router。
- 複数 CLI、MCP、設定の管理が主な課題：まず CC Switch。
- 両方の課題がある：併用し、クライアント設定とモデルルーティングの担当を明確にする。
まとめ
9Router は要求経路を、CC Switch は設定のライフサイクルを扱います。この境界を理解すれば、ルーティング障害をクライアント設定の障害と取り違えずに済みます。
機能表ではなく実際の作業フローで判断する
毎日 Claude Code と Codex を切り替え、クラウド Provider とローカルモデルを1つずつ使う場合を考えます。モデルを変えるたびに2つのツールで Base URL、モデル名、key を直すなら、先に 9Router を導入します。アドレスは固定でも MCP、Skills、プロンプト、複数 CLI の設定がずれるなら、先に CC Switch を導入します。
両方を入れても自動的に効率化されるわけではありません。合意がないと、CC Switch の設定を手動環境変数が上書きし、9Router にさらに別ルールがある状態になります。導入前に設定の種類ごとに唯一の担当を決めてください。
| 設定対象 | 推奨担当 | 検証方法 |
|---|---|---|
| 上流 API key、モデル fallback | 9Router | ルーティングログとヘルスチェック |
| Claude Code/Codex の現在の Provider | CC Switch またはクライアント設定 | 再起動後の最小要求 |
| MCP server のコマンドと環境 | CC Switch またはプロジェクト設定 | ツールを個別に呼ぶ |
| プロジェクト規則、テストコマンド、権限説明 | リポジトリファイル | レビューと CI |
3つの典型的な選択
公式アカウントだけを使う
カスタム endpoint も複数 Provider も不要なら、まず公式クライアントだけで十分です。両ツールは保守面を増やすことがあります。MCP の一元管理やツール横断同期が必要になってから CC Switch を導入します。
複数モデルの評価またはコスト管理
この場合は 9Router を優先します。一般タスクには安定した既定モデルを指定し、明確なログと手動の上位モデル切替経路を残します。各クライアントが独立してモデルを選び、請求が説明不能になるのを防げます。
複数人で共有する AI コーディング環境
key、ルーティング方針、プロジェクト MCP、個人設定を最初に分けます。チーム共有の内容はバージョン管理とレビューを行い、個人アカウント、セッション、ローカルパスを全員へ直接同期しないでください。CC Switch の同期は個人デバイス管理には役立ちますが、チームの秘密情報管理システムではありません。
併用時の導入順序
- クライアント1つと Provider 1つだけを導入し、再現可能な要求を完了する。
- モデル呼び出しを 9Router へ移し、元の設定をロールバック記録として残す。
- CC Switch でそのクライアントを管理し、書込みと再起動後の結果が一致することを確認する。
- MCP、同期、複数 Provider を追加し、各層の復旧方法を記録する。
FAQ：CC Switch は 9Router の fallback を置き換えられますか？
Provider の切替は支援できますが、専用の要求ルーティング・fallback 層と同じではありません。要求ごとの自動上流選択、ルーティングログ、互換 endpoint が必要ならルーターを使います。
FAQ：9Router は MCP を管理できますか？
主眼はモデル要求のルーティングです。MCP の起動コマンド、ツール権限、プロジェクト設定は、クライアント、管理ツール、またはリポジトリ設定で扱うべきです。