「Claude Codeは便利だけど、社内の都合でAnthropicと直接契約できない」「OpenAIのアカウントは既にあるから、それを流用してClaude Codeの体験を試したい」 — こうした相談は法人案件でとても多いです。

ここで出てくる選択肢のひとつが Claude Code Router です。Claude Codeのインターフェース(あの黒画面の会話体験)はそのまま使いつつ、裏で動かすLLMをOpenAIやGoogle Geminiやローカルモデルに差し替えられるルーティングツール。本記事ではその役割と使い方を整理します。

Claude Code RouterはAnthropic互換のプロキシ

Claude Codeは、内部的にはAnthropicのAPIエンドポイントに対してリクエストを送って応答を受け取る仕組みになっています。エンドポイントの宛先は環境変数 ANTHROPIC_BASE_URL で変えられる。

このしくみを利用して、「Anthropicのリクエスト形式をいったん受けて、別のLLMプロバイダーのAPIに翻訳して投げる」プロキシサーバー を立てるのが Claude Code Router の役割です。具体的な実装で有名なのはGitHubにある musistudio/claude-code-router というOSSプロジェクト。

[Claude Code] → [Claude Code Router(ローカルサーバー)] → [OpenAI / Gemini / Ollama / その他]

Claude Codeから見ると「いつものAnthropic API」に見える。実際はローカルのRouterが受け取って、設定したプロバイダー先に振り分けています。

「インターフェースはClaude Codeのまま、エンジンだけ別物にできる」と捉えるとイメージしやすいです。

どんな時に使うのか

Claude Code Routerが効くケースは、主に3つあります。

第一に、社内のAI契約がAnthropic以外の時。すでにOpenAIやAzure OpenAIで企業契約していて、新規ベンダーを追加する稟議が重い、というよくあるパターン。RouterでOpenAI経由に流せば、Claude Codeの体験は維持しつつ、契約は既存のままでいけます。

第二に、ローカルモデルで完全閉域運用したい時。Ollamaなどローカルでモデルを動かす環境を構築して、Routerを噛ませると、Claude Codeから完全にローカル運用ができます。社外にトークン1つ出したくない要件に対応できる構成です。

第三に、コストの比較・切り替えをしたい時。1日あたりOpenAIとAnthropic両方で同じ作業を走らせて、応答品質とコストを比較する、といった検証もRouterがあると一発で切り替えられます。

私の関与した案件では、「Anthropicと契約はしたいが、ある期間だけGemini経由で動かしたい(GeminiのプロモーションでAPIクレジットがあるから)」というニーズで使われたことがあります。

設定はnpm installから1ファイル編集まで

Claude Code Routerの導入は、ざっくり3ステップです。

# 1. Router本体をインストール
npm install -g @musistudio/claude-code-router

# 2. 設定ファイルを作成
mkdir -p ~/.claude-code-router
cat > ~/.claude-code-router/config.json << 'EOF'
{
  "providers": {
    "openai": {
      "api_key": "sk-...",
      "base_url": "https://api.openai.com/v1",
      "models": ["gpt-4o", "gpt-4o-mini"]
    }
  },
  "routing": {
    "default": "openai/gpt-4o"
  }
}
EOF

# 3. Routerを起動
claude-code-router start

Routerは普段はlocalhostでサーバーを動かします。あとはClaude Code側で環境変数 ANTHROPIC_BASE_URL=http://localhost:11434 のように Router のURLを向ければ、Claude Codeのリクエストがすべてそこ経由になります。

設定ファイルでは、プロバイダー別の認証情報と、どのモデルにどう振り分けるかを書きます。「コーディング系の質問はGPT-4o、雑談系はGPT-4o-miniに」のような細かい分岐も書けるので、慣れてくると自分専用のルーティング戦略が組めます。

私が初めて触ったとき、設定ファイルの記法に多少クセがあって、起動エラーで30分悩みました。最初はOSSのREADMEに付いているサンプル設定をそのままコピーして動かすところから始めるのが安全です。

向き不向き

便利なツールですが、何でもRouter経由にすればいいわけではない、というのが半年運用しての実感です。

Routerが向く場面

  • 既存のOpenAI/Azureアカウントを流用したい
  • ローカルLLM(Ollama, vLLM)と組み合わせて閉域運用
  • 複数プロバイダーをコストや性能で使い分けたい
  • Anthropicに新規契約せず、Claude Codeの体験だけ試したい

Routerが向かない場面

  • そもそもAnthropicと契約できるなら、ネイティブのほうが体験は最適化されている
  • 重要な業務クリティカル系。OSSのRouterが間に入ることでデバッグ難易度が上がる
  • Anthropicが独自に提供する機能(extended thinking等)は、別プロバイダー経由だと利用できない

「契約面の理由で他社LLMが必須」というシチュエーション以外では、ネイティブのAnthropic接続のほうが安定すると感じます。

法人で使うときの注意点

法人運用でRouterを噛ませる場合、追加で気をつけることが3つあります。

第一に、APIキーの管理場所。Router設定ファイルにAPIキーを平文で書く構造なので、~/.claude-code-router/config.json のパーミッションと、リポジトリへの誤コミット防止を最初に固めます。.gitignore への登録も忘れずに。

第二に、ログの取り扱い。Routerは中継するすべてのリクエスト/レスポンスをログに残せます。社内データがログに出る前提で、ログの保管場所・保管期間・アクセス権限を決めておくのが安全です。

第三に、運用責任者。OSSのRouterに不具合が起きた時に、誰が修正PRを出すのか、あるいは別のRouterに乗り換えるのかを、導入時に決めておきます。本家リポジトリのメンテナンス頻度も事前にチェックしておいたほうが安心です。

私が支援した案件では、Routerを社内のDocker環境に閉じ込めて、その内側でClaude Codeを使うメンバーが認証する、という構成にしました。Router自体はOSSでも、運用面で守りを固めれば法人利用に耐えます。

まとめ

  • Claude Code RouterはAnthropic互換のプロキシで、別プロバイダーのLLMをClaude Codeから使えるようにする
  • 用途は「既存契約の流用」「ローカル閉域運用」「複数プロバイダーのコスト比較」
  • 設定は ~/.claude-code-router/config.json にプロバイダー別の情報を書く形
  • Anthropic独自機能は使えないので、契約可能なら基本はネイティブが安定
  • 法人運用ではAPIキー管理・ログ取扱・運用責任者の3点を最初に決める