CC Switch の Provider 切替は、1台のPCで公式サービス、サードパーティ API、ローカルモデルを使う際に、複数クライアントを手で変更して漏れが出る問題を解決します。まず1つの Provider を動かし、その後にローカル接口と予備経路を段階的に追加します。
まず単一 Provider を作る
CC Switch で Claude Code または Codex などの対象ツールを選び、Provider を1つ追加して、Base URL、API key、モデルを1組だけ設定します。保存後、端末とクライアントを完全に再起動し、単純な要求を1回実行して新 Provider から返ることを確認します。
この成功前に、プロキシ、同期、複数モデル別名、fallback を同時に有効化しないでください。変数が多すぎると切り分けられません。
ローカル OpenAI-compatible API を接続する
Ollama、LM Studio、vLLM などを接続できるかは、クライアント互換の接口を提供するか、Provider 設定が独自 Base URL とモデル名を許すかに依存します。次を確認します。
- サービスが現在のPCから到達できるアドレスで待ち受けていること。
- モデル名がサービスの公開名と一致すること。
- ローカルサービスが key を必要とするか、ローカル要求だけを受けるか。
- コンテキスト、並列性、VRAM が実タスクに十分であること。
ローカル API の選択と接続は Codex でローカルモデル API を使うガイド、LM Studio の詳細は LM Studio OpenAI 互換 APIを参照してください。
複数 Provider 切替の実用戦略
- 日常コーディング：安定し、費用が予測可能な Provider を優先する。
- 長いタスクや重要レビュー：暗黙の自動置換に頼らず、強いモデルへ手動で切り替える。
- ローカルモデル：機密性、オフライン、低リスクの定型手順に使う。
- 障害時：Provider の健全性と上限を確認してから切替え、連続再試行で枠を消費しない。
複数上流の優先度と fallback を1つの endpoint に統一したい場合は、CC Switch と 9Routerを組み合わせます。CC Switch はクライアントを、9Router は要求ルーティングを管理します。
まとめ
重要なのは入力できるアドレス数ではなく、切替のたびに反映を確認できることです。検証可能な単一設定を維持し、クライアントを再起動してモデル名を確認してから、ローカルモデルと複数 Provider に広げると失敗しにくくなります。
Provider 項目に含める内容
各 Provider には、用途、endpoint、モデル名規則、認証方式、検証日を明確に記録します。「予備」「新 API」だけでは数週間後にコードレビュー向きか、ツール呼び出しに対応するか、上限が残っているか分かりません。
| 項目 | 目的 |
|---|---|
| 表示名 | 公式、チーム、ローカル、テスト Provider を区別する |
| Base URL | 互換 API のルートアドレスを記録する |
| モデル名 | クライアント別名とサービス名の混同を防ぐ |
| key の出所 | 保管場所またはアカウントだけを記録し、リポジトリに書かない |
| 利用目的 | 日常開発、長いタスク、オフラインテストなど |
切替前後に検証すること
切替前に現在の Provider とモデルを記録し、ファイルを変更しないテストタスクを保存します。切替後は、期待したモデルから返るか、ツール呼び出しが使えるか、プロジェクト権限が正しいか、失敗時に明確なエラーが見えるかを確認します。新 Provider が非互換でも既知の正常設定へすぐ戻れます。
ローカル OpenAI-compatible サービスでは Base URL だけでなく待受アドレスも確認します。同じPCだけで使うなら、可能なら loopback にバインドし、LAN へ意図せず公開しないでください。他デバイスに許可する場合は、認証とファイアウォールを別途検討します。
モデル名と能力が合わないリスク
API 互換は能力の同一性を意味しません。チャット要求を受けても、ツール呼び出し、画像、長いコンテキスト、クライアントが必要とするストリーミングに対応しないサービスがあります。「OpenAI compatible」と書かれているだけで全作業を移さず、対象ワークフローをテストしてください。
出力が極端に短い、ツール呼び出し形式が壊れる、コンテキストがすぐ溢れる場合は、key だけでなくモデル能力、サービス版、コンテキスト上限を確認します。ローカル vLLM のメモリと KV cache は vLLM KV Cache の切り分けを参照してください。
コストと可観測性
Provider 切替にもコスト境界が必要です。各タスク種別の既定 Provider、失敗時の自動再試行、呼び出しログの保存期間を記録します。ローカルモデルでは実行時間、電力、人の保守も判断に含めます。API 単価だけの比較では不十分です。
FAQ：切替後も古いモデルが使われるのはなぜですか？
古い端末が開いたまま、プロジェクト環境変数による上書き、モデル別名の未更新、セッションのキャッシュが原因になりがちです。新しいセッションを作り、クライアントを再起動して要求ログを確認してください。
FAQ：すべての API key を取り込めますか？
実際に必要で信頼するアカウントだけを取り込みます。管理ツールと同期フォルダーは価値の高い標的です。同期を有効にする前に、暗号化、アクセス制御、無効化方法を確認してください。