Claude Code Router（CCR）は、Claude CodeやCodexなど複数のAIコーディングエージェントを、ローカルで動く1つの窓口に束ねるモデルゲートウェイです。AIコーディングエージェントを2つ以上使っていると、必ず同じ面倒にぶつかります。Claude Codeには環境変数でベースURLとキーを、Codexには別の設定ファイルを、OpenCodeにはまた別の書式で——と、同じ「どのモデルを使うか」という1つの決定を、エージェントの数だけ書き分けることになる。乗り換えるたびに全部を直す羽目にもなります。musistudio/claude-code-router（★36,263・MIT）は、この決定をエージェントの外側に取り出して一箇所に集約します。
なお、そもそも「AIにコードを書かせる」という開発スタイル全体の始め方・ツールの選び方・実践的なワークフローについては、当サイトのVibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026にまとめてあります。本記事はその中でも「複数のエージェントを併用しはじめた後に出てくる、接続先の管理」という一段あとの問題を扱います。
- ・何をするか：Claude Code・Codex・OpenCodeなど9種のエージェントを、ローカルの1エンドポイント（既定 127.0.0.1:3456）に向けさせ、その裏でプロバイダ・モデル・資格情報を一元管理する。
- ・OpenAI互換だけではない：入口のパスを見て5つのプロトコル方言（Anthropic Messages / OpenAI Chat Completions / OpenAI Responses / Gemini generateContent / Gemini interactions）を判定する実装になっている。
- ・いま大きく変わった直後：npmでの初版は2025-06-10、v3.0.0のデスクトップ配布は2026-06-25。GitHub Releasesにある18本はすべてv3系で、最新の3.0.17は2026-07-28公開。
- ・既定は安全側：フォールバックは既定で
mode: "off"・retryCount: 1。「勝手に別モデルへ逃げる」挙動は自分で有効化して初めて動く。 - ・ライセンスはMIT（LICENSE本文で確認。Copyright (c) 2025 musistudio）。本記事の数値はすべて2026-07-29時点・v3.0.17のソースとレジストリで確認した。
① 何ができる：Claude Code・Codex・OpenCodeなど9種のエージェントを、ローカルの1エンドポイント（既定 127.0.0.1:3456）に向けさせ、その裏でプロバイダ・モデル・資格情報・ログを一元管理する。② 何を解決する：エージェントごとにベースURL・APIキー・モデル名を書き分ける手間と、乗り換えのたびにその全部を直す作業。どのリクエストがどのモデルへ流れたか追えない状態も含む。③ 何を代替できる：各エージェントの設定ファイルを手で書き換える運用。ただしエージェントが1つしかないなら、その設定を直接書くほうが構成要素は少なく済む。
Claude Code Routerとは——9種のエージェントを1つのローカル窓口に束ねる
Claude Code Router（以下CCR）は、名前こそ「Claude Code」を冠していますが、v3系の実体はClaude Code専用ツールではありません。公式READMEが対応エージェントとして名前を挙げているのは次の9種です。
・Claude Code（CLI・アプリ）
・Claude Design（アプリ）
・Codex（CLI・アプリ）
・Grok CLI（CLI）
・Kimi CLI（CLI）
・Kilo Code（CLI）
・OpenCode（CLI・アプリ）
・Pi（CLI）
・ZCode（アプリ）
これに加えて「互換APIクライアント」も受け付けます。位置づけとしては、エージェントとプロバイダの間に挟まる層です。
「汎用プロキシ」ではなくエージェントごとの組み込みを持つ
ここが、単なるリバースプロキシやOpenAI互換ゲートウェイとの分かれ目です。リポジトリを実際に展開すると、packages/core/src/agents/ の下にエージェント別のディレクトリが並んでいます。
・claude-code/ — 環境変数の組み立て（environment.ts）
・claude-app/ — アプリ連携・CDP・ゲートウェイ経路・起動処理
・codex/ — アプリ起動、CLIミドルウェア実行時処理、モデルカタログ
・opencode/ / kilo/ / pi/ / zcode/ — それぞれのプロファイル設定・モデルカタログ
・local-providers/ — claude-code.ts / codex.ts / grok.ts / kimi.ts / opencode.ts
つまりCCRは、「どのエージェントも同じHTTPを喋るから同じ扱いでよい」とは考えていません。エージェントごとに設定ファイルの置き場所も、モデル名の書式も、起動方法も違うという前提で、それぞれに合わせた組み込みを持っています。READMEにある「Agent Config でエージェントを選び、モデルを選んでプロファイルを適用する」という操作が成立するのは、この作り込みがあるからです。
local-providers/ は少し性格が違い、すでにローカルにインストール済みのCLIから資格情報を取り込むための実装です。grok.ts の冒頭を見ると node:fs の existsSync / readFileSync とホームディレクトリのパス解決を読み込んでおり、ローカルのファイルから設定を読み出す構造になっていることが確認できます。READMEが「local login import where supported（対応しているものはローカルのログイン情報を取り込める）」と書いているのはこの部分にあたります。
監視・課金・ボット連携まで抱えている
packages/core/src/ 直下のモジュール構成を見ると、CCRが「ルーティングだけの薄い層」ではないことが分かります。実際に存在するのは以下です。
agents / config / contracts / entrypoints / gateway / mcp / media / models / observability / platform / plugins / profiles / providers / proxy / routing / runtime / storage / usage / web
observability（可観測性）と usage（利用量）が独立したモジュールとして存在する点は、READMEの「リクエストの詳細・解決されたプロバイダとモデルと資格情報・ステータス・遅延・トークン・推定コスト・ツール呼び出し・エージェントのトレースを見られる」という説明と対応しています。またREADMEには AgentClaw として、Slack・Discord・Telegram・LINE・Feishu・DingTalk・WeCom などを経由したエージェント中継の記載があり、ソース側にも agents/bot-gateway/ が存在します。
v1のCLIからv3のデスクトップアプリへ——17か月で36,263スターに至る道のり
CCRを「いま」評価するうえで外せないのが、ごく最近に性格が変わったという事実です。レジストリの実データを並べると、その変化がはっきり出ます。
時系列にすると次のようになります。
・2025-02-25 — GitHubリポジトリ作成
・2025-06-10 — npm @musistudio/claude-code-router v1.0.0 公開
・2026-01-04 — v2.0.0 公開
・2026-06-25 — GitHub Releases に v3.0.0（デスクトップアプリ配布の開始）
・2026-07-06 — npm 側の 3.0.0 公開
・2026-07-28 — 最新 v3.0.17（GitHub Releases・npm とも同日）
ここで目を引くのは、GitHub Releasesに存在する18本のリリースがすべてv3系だという点です。v1・v2の時代にはGitHub Releasesが使われておらず、配布はnpm経由のCLIだけでした。npm側には85バージョンが積み上がっています。GitHub Releasesが始まったのは、配布物がnpmパッケージだけでなくOS別のデスクトップアプリ本体（Windows向け .exe、Linux向け .AppImage、macOS向けの Apple Silicon / Intel 各 .dmg）になったからです。
つまり、★36,263という数字の大半はCLIルーターとしての17か月で積み上がったもので、READMEのトップに出てくるデスクトップアプリの画面はこの1か月ほどの姿です。「Claude Code Router」という名前で検索して古い解説記事にたどり着くと、ccr code を叩くCLIツールの説明が出てくることがありますが、v3のデスクトップアプリとは操作体系が異なります。導入時は自分が見ている情報がどのメジャーバージョンのものかを確認してください。
現在の最新は 3.0.17（2026-07-28）。npmで入れた場合は
ccr --version ではなく、パッケージ名が @musistudio/claude-code-router であることも合わせて確認する。リポジトリのルート package.json は claude-code-router-monorepo という名前のワークスペース（packages/*）になっており、cli / core / electron / ui の4パッケージで構成されている。なお開発の勢いという点では、2026-07-02から07-28までの約4週間で v3.0.6 から v3.0.17 まで12本が公開されています。一方でGitHubのOpen Issuesは2026-07-29時点で1,038件です。この2つの数字は「活発に更新されている」ことと「未処理の報告も相応に積み上がっている」ことを同時に示しており、どちらか一方だけを見て評価を決めない方が無難です。
インストールと起動——デスクトップ・CLI・Dockerの3経路
CCRの導入経路は3つあり、必要な前提と入口のポートが異なります。
| 経路 | 前提 | 管理画面 | ゲートウェイ | 向いている場面 |
|---|---|---|---|---|
| デスクトップアプリ | 各OS向け配布物をダウンロード | アプリ内の画面 | 127.0.0.1:3456 | 手元のマシンで日常的に使う。公式が推奨する経路 |
| npm CLI | Node.js 22以降 | 127.0.0.1:3458（ブラウザ） | 127.0.0.1:3456 | Electronを入れたくない・サーバー上で動かす |
| Docker Compose | Docker | 127.0.0.1:3458 経由 | 同左経由 | 隔離環境で動かす・チームで共有する |
CLIで入れて起動する
Electronを避けたい場合はnpm版が最短です。CCRの管理画面はブラウザで開きます。
# Node.js 22以降が必要
npm install -g @musistudio/claude-code-router
# 管理UIつきで起動（ブラウザで http://127.0.0.1:3458 を開く）
ccr ui
管理画面が開いたら、READMEが示す順序——Providers（プロバイダ登録）→ Server（起動）→ Agent Profiles（エージェントへの割り当て）——で設定します。プロバイダ登録では、組み込みプリセットを選ぶか、独自のエンドポイントを入力し、APIキーとプロトコルとモデルを指定します。
Dockerで動かす
リポジトリには docker-compose.yml と Dockerfile、docker/ ディレクトリが同梱されています。
docker compose up -d --build
この場合、管理UIとゲートウェイの経路はいずれも既定で http://127.0.0.1:3458 を通ります。リモートに公開する前に公式のDockerデプロイガイドを読むことがREADMEで明示的に促されている点には従ってください。CCRはAPIキーと資格情報プールを保持する層なので、無防備に外部公開すると鍵の持ち出し口になります。
起動できているかを自分で確認する
設定がうまくいかないとき、まず切り分けるべきは「CCRが待ち受けているか」と「エージェントがそこを向いているか」の2点です。
# ゲートウェイ(3456)と管理UI(3458)が待ち受けているか
lsof -nP -iTCP:3456 -sTCP:LISTEN
lsof -nP -iTCP:3458 -sTCP:LISTEN
# Claude Code がどこを向いているか（CCR経由なら127.0.0.1:3456系になる）
echo "${ANTHROPIC_BASE_URL:-(未設定)}"
lsof の行が出るのに応答が返らない場合はプロバイダ側の設定、そもそも行が出ない場合はCCR自体が起動していない、ANTHROPIC_BASE_URL が空ならエージェントがCCRを経由していない——と切り分けられます。
npm run build:app:mac / npm run build:app:win で release-local/ に出力される（事前に npm ci）。ただしWindows版のパッケージングはWindows x64上で実行する必要がある——better-sqlite3 がElectron用のネイティブモジュールを同梱するため。公式のリリースワークフローも、macOSはmacOSランナー、WindowsはWindowsランナーでビルドしている。ルーティングの中身——5つのプロトコル方言と失敗の4分類
CCRを「OpenAI互換のプロキシ」と説明する記述を見かけますが、実装はもう少し広い範囲を扱っています。packages/core/src/routing/protocol-endpoints.ts は、リクエストの入口パスを見てプロトコルを判定する関数を持っており、判定されるのは次の5種類です。
・anthropic_messages — /v1/messages（末尾一致も許容）
・openai_chat_completions — /v1/chat/completions
・openai_responses — /v1/responses
・gemini_generate_content — /v1beta/models/{モデル}:generateContent または :streamGenerateContent
・gemini_interactions — /v1beta/interactions
同じファイルには、ゲートウェイのルーティングを適用するかどうかを決める判定もあります。HTTPメソッドがPOSTでない場合は対象外で、上記5種のいずれにも当てはまらないパスもルーティングされません。エージェント側が想定外のパスを叩いている場合、CCRは黙って素通しする側に倒れます。
24のプロバイダプリセット
packages/core/src/providers/presets/ には、24種のプロバイダプリセットが同梱されています。
anthropic / openai / gemini / openrouter / deepseek / mistral / moonshot / kimi-coding / siliconflow / minimax / nvidia / bailian / claudeapi / zhipu-cn-coding / zhipu-cn-general / zai-global-coding / zai-global-general / qiniu-ai / runapi / teamorouter / infistar-ai / code0 / fenno / unity2
プリセットは「ここから選べば設定が埋まる」という入口であって、上限ではありません。READMEが言うとおり独自の互換エンドポイントも登録できます。またプロキシの既定転送先（DEFAULT_PROXY_TARGETS）としては、api.anthropic.com / api.openai.com / generativelanguage.googleapis.com / openrouter.ai / api.deepseek.com / api.mistral.ai の6ホストが定義されています。
失敗をどう分類するか
エージェント運用で一番効いてくるのが、失敗したときにどう振る舞うかです。routing/failure-classifier.ts は、HTTPステータスコードを4つに分類しています。
・429 → rate-limit
・408 / 409 → retryable
・500以上 → server
・それ以外の4xx → client
そして切り替えるかどうかの判定は、フォールバックのモードによって変わります。model-chain モードではステータスが400以上ならすべてフォールバック対象になりますが、それ以外のモードでは retryable・rate-limit・server の3つだけが対象です。
実務上の意味はこうです。APIキーが間違っている（401）・リクエストが不正（400）といった「こちら側の誤り」は、既定の分類では client に落ち、フォールバックの対象になりません。これは合理的な設計です——鍵が間違っているのに次のモデルへ流しても同じように失敗するだけで、失敗の原因が隠れてしまいます。逆に「キーを間違えたまま全プロバイダを順に試してほしい」という運用をしたい場合は、model-chain モードを選ぶ必要があります。
ルーティング規則そのものをスクリプトで書ける
routing/ 配下には route-script-runtime.ts / route-script-worker.ts / route-script-worker-protocol.ts / route-script-context.ts といったファイル群があり、ルーティング規則をワーカー上で実行されるスクリプトとして書ける構造になっています。既定設定にも CUSTOM_ROUTER_PATH という項目が用意されています。ほかにも policy-engine.ts（ポリシー判定）・rewrite.ts（リクエスト書き換え）・model-resolution.ts（モデル解決）・model-registry.ts・execution-plan.ts（実行計画）・config-compiler.ts（設定のコンパイル）が並び、条件分岐つきのルーティングを扱う前提の構成になっています。
Claude Code / Codex ほか] -->|POST| B{入口パスで
プロトコル判定} B -->|5種のいずれか| C[ルーティング規則
条件・書き換え・モデル解決] B -->|該当なし| Z[ゲートウェイ経路の対象外] C --> D[選ばれたプロバイダへ送信] D -->|2xx| E[応答をエージェントへ返す] D -->|429 / 408 / 409 / 5xx| F{フォールバック設定} D -->|その他の4xx| G[エラーをそのまま返す] F -->|mode: off 既定| G F -->|有効かつ候補あり| H[次の候補モデルへ] H --> D
既定値の実際——フォールバックは「オフ」から始まる
READMEは「リトライ・資格情報プール・キーのローテーション・順序つきフォールバックでリクエストを動かし続ける」と説明しています。これは機能として正しいのですが、そのまま入れただけでは動きません。packages/core/src/config/default-config.ts の初期値を読むと、次のようになっています。
・PORT: 3456 / HOST: "127.0.0.1" — 既定ではローカルホストのみの待ち受け
・fallback: { mode: "off", models: [], retryCount: 1 } — フォールバックは無効、候補モデルは空、リトライ回数は1
・API_TIMEOUT_MS: 600000 — タイムアウトは10分
・Providers: [] — プロバイダは未登録
・APIKEY: "" / APIKEYS: [] — CCR自体のアクセスキーは未設定
・Router.builtInRules — claude-code と codex の組み込みルールのみ enabled: true
・autoStart: false — 自動起動はオフ
読み取れることが3つあります。
第一に、フォールバックとリトライは自分で設計するものです。「入れておけば落ちなくなる」ものではなく、候補モデルの順序を自分で並べて初めて意味を持ちます。前節の失敗分類も、この設定を有効にして初めて効いてきます。
第二に、タイムアウトが10分と長めに取られています。コーディングエージェントは長い応答を生成しうるため妥当な既定値ですが、プロバイダ側が無反応になったときに10分待つ可能性があるということでもあります。短く切りたい場合は明示的に変更が必要です。
第三に、待ち受けは既定でローカルホストのみで、CCR自身のアクセスキーも空です。裏を返せば、HOST を広げて外部から到達できるようにするなら、READMEにある「有効期限とリクエスト・トークン・画像の上限を設定できるCCRクライアントキー」を合わせて設定しないと、手元の全プロバイダのキーを無認証で使わせる口を開けることになります。Dockerでリモートに置く場合はとくに注意してください。
OmniRoute・agentsviewとの違い——どれを選ぶか
「複数のAIツールを1つのエンドポイントに束ねる」という説明だけを聞くと、似たツールが複数思い浮かびます。役割の重心が違うので、整理しておきます。
| ツール | 重心 | 束ねる対象 | 主な判断軸 |
|---|---|---|---|
| Claude Code Router | エージェント側の制御 | 9種のエージェントのプロファイル・接続先 | 複数のコーディングエージェントを併用していて、どれがどのモデルを使うかを一箇所で決めたい |
| OmniRoute | プロバイダ側の広さ | 多数のプロバイダ・無料枠 | とにかく多くのプロバイダや無料枠へ1本で到達したい |
| agentsview | 事後の可視化 | エージェントの実行履歴・コスト | 走らせた後の履歴とコストを振り返りたい |
CCRの特徴は、プロバイダの数ではなく、エージェント側にどれだけ踏み込んでいるかにあります。同梱プリセットは24種で、これは「数を競う」タイプの設計ではありません。代わりに、エージェントごとのプロファイル・モデル上書き・スコープ・起動エントリ・複数インスタンス運用といった、エージェント側の設定を肩代わりする機能に厚みがあります。プロバイダの網羅性を重視するなら、当サイトで扱ったOmniRoute解説｜237プロバイダを1エンドポイントに束ねる無料AIゲートウェイとLiteLLM比較のようなアプローチのほうが目的に合います。
一方で、CCRの observability / usage モジュールが提供するのは通過するリクエストのログです。「エージェントが何をしたか」という実行履歴そのものを後から掘り返したいなら、agentsview徹底解説｜AIコーディングエージェントの履歴・コストをローカル可視化するOSSのような、エージェントのセッション履歴を対象にしたツールのほうが噛み合います。両者は競合というより見ている層が違います。
また、CCRが対応エージェントとして名前を挙げているKimi Code CLIとは｜Moonshot純正のAIコーディングエージェントをターミナルで動かすのような個別のCLIは、CCRを通さず単体でも動きます。CCRが要るのは「複数を併用していて、切り替えの手間が実際に発生している」場合です。エージェントが1つだけなら、そのエージェントの設定を直接書くほうが構成要素は少なく済みます。
逆に、モデル側をローカルに寄せたい場合は選択肢が変わります。Nanocoder徹底解説｜Ollamaで完全オフライン動作するローカルコーディングエージェントを実測のようにローカルモデル前提で動くエージェントを使えば、そもそも外部プロバイダの鍵を束ねる必要自体が薄くなります。CCRは「外部プロバイダを複数使う」ことを前提にした道具です。
導入前に確認しておきたい点
実際に入れる前に、READMEとソースから確認できた注意点を挙げます。
ライセンスは MIT
LICENSE ファイルの本文は MIT License、Copyright (c) 2025 musistudio です。ルートの package.json の license フィールドも MIT、GitHub APIが返す spdx_id も MIT で一致しています。商用利用に制限のある fair-code 系ライセンスではありません。ただしCCRは接続を仲介する層にすぎず、実際に呼び出す各プロバイダの利用規約と料金はそれぞれに従います。
資格情報の取り込みが何を読むか把握しておく
前述のとおり agents/local-providers/ は、ローカルにインストール済みのCLIから設定を読み出す実装を持ちます。便利な機能ですが、手元の複数のAI CLIの認証情報が1つのアプリに集まるということでもあります。CCRのデータをどこに保存しているか（packages/core/src/storage/）、管理画面をどのアドレスで公開しているかは、導入時に把握しておく価値があります。
READMEのスポンサー表記を情報として切り分ける
CCRのREADMEは冒頭にKimi（Moonshot AI）のスポンサーバナーを掲げており、モデルの性能に関する記述もそこに含まれています。これはスポンサーによる宣伝文であって、CCRの機能説明ではありません。CCR自体の事実として確認できるのは、providers/presets/ に kimi-coding と moonshot のプリセットが実在すること、READMEがKimiを組み込みプリセットとして扱っていること、までです。モデルの性能そのものは、CCRのリポジトリではなく提供元の一次情報で確認してください。なおREADMEおよびスポンサー一覧のリンクの一部にはアフィリエイト用のクエリが付いています。
未処理のIssueと更新頻度
2026-07-29時点でOpen Issuesは1,038件、フォークは3,033、Watchは134です。直近4週間で12本のリリースが出ている一方、報告の残数も相応にあります。導入前に、自分の使うエージェントとプロバイダの組み合わせについて既存のIssueを検索しておくと、既知の問題を踏まずに済みます。
まとめ——Claude Code Routerは誰のための道具か
Claude Code Routerは、「AIコーディングエージェントを複数使いはじめた人」に向いた道具です。要点を整理します。
・問題の切り出し方が特徴的：モデルの選択という決定をエージェントの外に出し、ローカルの1エンドポイント（既定 127.0.0.1:3456）に集約する
・汎用プロキシではない：agents/ 配下にエージェント別の組み込みを持ち、5つのプロトコル方言を入口パスで判定する
・プロバイダ数を競う設計ではない：同梱プリセットは24種。厚みがあるのはエージェント側のプロファイル管理とログ
・性格が変わった直後：npm初版は2025-06-10だが、デスクトップ配布のv3.0.0は2026-06-25。古い記事のCLI手順とは操作体系が異なる
・既定は保守的：フォールバックは off、候補モデルは空、待ち受けはローカルホストのみ。「落ちなくなる」機能は自分で組む必要がある
・ライセンスはMIT、更新は活発（直近4週間で12リリース）だが、Open Issuesは1,038件（2026-07-29時点）
エージェントが1つしかないなら、そのエージェントの設定を直接書くほうが単純です。2つ以上を併用していて、切り替えのたびに同じ設定を書き直している自覚があるなら、その手間を引き受けてくれる層として検討する価値があります。
参照ソース
・musistudio/claude-code-router — 公式リポジトリ（MIT）。README・LICENSE・packages/core/src/ 配下の実装を2026-07-29時点のv3.0.17で確認
・npm: @musistudio/claude-code-router — バージョン履歴（v1.0.0＝2025-06-10、v2.0.0＝2026-01-04、3.0.0＝2026-07-06、最新3.0.17＝2026-07-28、計85バージョン）
・claude-code-router Releases — デスクトップアプリの配布物とリリース日（18本すべてv3系、v3.0.0＝2026-06-25）
・Claude Code Router 公式ドキュメント（ccrdesk.top） — インストール・プロバイダ設定・CLI・Dockerデプロイ・トラブルシューティング
