Claude Code とローカル LLM を繋ぐ 5 通りの経路 — CodeRouter の存在意義を整理した話

2026年4月27日 22:44

TL;DR: Claude Code をローカル LLM に向けるとき、選択肢は 5 通り ある (実は 7 通り、内 2 つは動かない)。LM Studio 0.4.12 が Anthropic 互換 /v1/messages を公式サポートしたことで、Claude Code → LM Studio 直結が現実的に動くようになり、CodeRouter なしの選択肢が初めて成立した。これを受けて自分のプロダクト (CodeRouter) の存在意義を経路ごとに整理してみた話。結論: 「Anthropic 翻訳」だけが価値だった頃は終わり、これからの主軸は (1) ローカル LLM 同士で fallback できる (LM Studio 落ちたら Ollama に自動で流す)、(2) ANTHROPIC_BASE_URL を固定したまま裏で backend / モデルを切り替えられる、(3) 観測 / output filter / capability gate でモデル固有のクセを吸収する、の 3 つに重心移動。

背景 — LM Studio 0.4.12 が変えた風景

ガチで動かしてみたら 3 連敗した話 (v1.8.1) → 自分が作った診断ツールに自分が騙された話 (v1.8.2) → Ollama で詰んだ Qwen3.6 を llama.cpp で動かしたら... (v1.8.3) → 結論には賞味期限がある (v1.8.4)という 4 連作で、Qwen3 系のローカル動作環境が backend ごとに違うことを書いてきた。

その締めくくりで触れた LM Studio 0.4.12 の /v1/messages 公式サポートが、実は CodeRouter という自分のプロダクトの存在意義を直接揺さぶる出来事だった。

私が CodeRouter を作った主要な動機の一つは：

Claude Code は Anthropic API しか喋らない。Ollama / llama.cpp / vLLM 等の OpenAI-only backend を Claude Code から使うには Anthropic ↔ OpenAI 翻訳が必要。これを CodeRouter がやる。

ところが LM Studio が /v1/messages 公式サポート を出したことで、Claude Code → LM Studio 直結 が成立する。少なくとも LM Studio に限れば、私の CodeRouter は『翻訳』の価値を提供できない。

これを正直に整理する記事です。

5 通り (実質 7 通り) の経路

Claude Code がローカル LLM (Qwen3.5 / Qwen3.6 / Gemma 4 等) に到達する経路を網羅すると、こうなる：

Path A: CodeRouter 経由 (4 通り、すべて動く)

Path B: CodeRouter なしの直結 (3 通り、内 2 つは動かない)

サマリ表

┌──────────────────────────────────────────────────────────────┐
│  Backend     │ CR なし直結 │ CR 経由           │ CR の必要性  │
├──────────────────────────────────────────────────────────────┤
│  Ollama      │  ❌ 不可    │ openai_compat     │  必須         │
│  llama.cpp   │  ❌ 不可    │ openai_compat     │  必須         │
│  LM Studio   │  ✅ 可      │ openai_compat or  │  任意 (付加価値) │
│              │  (0.4.12+) │ anthropic         │              │
└──────────────────────────────────────────────────────────────┘

CodeRouter の役割を 4 つに分解

LM Studio 直結が選択肢として成立したことで、CodeRouter の価値は 「Anthropic 翻訳」だけ ではないことが明確になった。

価値 1: Anthropic 互換 shim (依然として必須な経路あり)

Ollama / llama.cpp / vLLM / MLX-LM など、Anthropic endpoint を持たない backend を Claude Code から使うなら、CodeRouter 必須。LM Studio に限ればこの価値は失われる (LM Studio 0.4.12+ が自前で /v1/messages 持つから)。

ただし、コミュニティで一番人気の Ollama を使う限りは引き続き必須。

価値 2: Fallback chain — ローカル LLM 同士でも fallback できる

直結だと「LM Studio が落ちたら手詰まり」。CodeRouter なら ローカル同士で次に流す 設計が可能：

- name: coding
  providers:
    - lmstudio-qwen3-6-35b-a3b-anthropic   # 1st: LM Studio (Anthropic 互換)
    - lmstudio-qwen3-5-9b-anthropic         # 2nd: LM Studio (軽量モデル)
    - ollama-qwen-coder-14b                 # 3rd: Ollama (別 backend、安定運用枯れ)
    - llamacpp-qwen3-6-35b-a3b              # 4th: llama.cpp 直叩き
    - openrouter-free                       # 5th: cloud free (最終的に外に逃がす)
    - anthropic-direct                      # 6th: paid (opt-in)

LM Studio が止まる場面の例:

メモリ圧迫 → モデル load 失敗
GUI を閉じてしまった
Mac が sleep → server 再起動忘れ
アップデート中 (LM Studio 0.4.12 → 0.4.13 で再起動)

これらは「localhost で動かしてる以上、ぼーっとしてると止まる」の世界。ローカル LLM 同士で fallback できるのが、直結との決定的な差です。Claude Code 使ってる最中に LM Studio が落ちても、気付かないうちに Ollama に流れて作業継続できる。

cloud だけが fallback の出口じゃなく、ローカル → ローカル → cloud → paid という 4 段の防御線を 1 本のエンドポイントで担保するのが router の本質。

価値 3: エンドポイント書き換え不要 + 用途別モデル切替

⚠️ 先に メモリ上のモデル切替コストは CodeRouter があっても無くても変わらない事実を明記しておく:LM Studio で Qwen3.5 9B から Qwen3.6 35B-A3B に切り替えるには、必ず メモリ上で eject + load が走る (~22GB GGUF を読み込み直す物理的なコスト、30-60 秒)
LM Studio の 「Just-in-time Model Loading」設定 を ON にしておくと、リクエストに "model": "qwen3.6-35b-a3b" が来た時点で 自動で eject + load してくれる (latency は同じだが、手動 GUI 操作は不要)
メモリ余裕があれば 複数モデル同時 keep も可 (M3 Max 64GB なら 9B + 35B-A3B 同時 keep ~30GB、起動時 swap なし)

CodeRouter があってもなくても、この物理コストは消えません。

CodeRouter の本領は、クライアント側 (Claude Code) の ANTHROPIC_BASE_URL を固定したまま、リクエストごとに送出する model 名 + backend を切り替えられる こと:

# Claude Code は固定 (一度設定したら触らない)
export ANTHROPIC_BASE_URL=http://localhost:8088
export ANTHROPIC_API_KEY=dummy

# CodeRouter 側で用途別 chain を切替
coderouter serve --port 8088 --mode coding    # Qwen3.6 35B-A3B → fallback chain
coderouter serve --port 8088 --mode general   # Gemma 4 e4b → fallback chain
coderouter serve --port 8088 --mode reasoning # Qwen3.5 35B-A3B → fallback chain

mode_aliases で短縮形 (fast / cheap / vision / think 等) も使える。Claude Code 起動を維持したまま、リクエスト単位で profile 切替も可能：

# 1 リクエストだけ別 profile を使う
curl -H 'X-CodeRouter-Mode: reasoning' \
     -H 'anthropic-version: 2023-06-01' \
     http://localhost:8088/v1/messages -d '...'

直結との差はこんな感じ：

つまり CodeRouter が解消するのは 「クライアント設定の安定性」と「適切な model 名の送出」。LM Studio の memory swap の物理コストは依然として残る。それでも:

Claude Code を再起動しなくて済む
複数 backend や cloud と並列に並べられる
mode 1 つで chain が切り替わる

という運用上のメリットは大きい。

価値 4: Observability + Capability gates + Output filters

/dashboard / coderouter stats TUI で metric 観測 (provider 別 latency / 成功率 / token 消費)
claude_code_suitability startup チェック (Llama-3.3-70B 系を coding profile に入れると warn)
output_filters: [strip_thinking, strip_stop_markers] でモデル固有のリーク除去
capability-degraded ログで翻訳のロスを可視化 (reasoning / reasoning_content が strip されたタイミング等)

これらは backend の種類に関係なく価値がある。

どの経路を選ぶべきか — 判断フローチャート

ローカル LLM だけで十分？
│
├─ YES、LM Studio 1 台のみで完結
│   │
│   └─ ✅ Claude Code → LM Studio 直結 (B2)
│      設定: ANTHROPIC_BASE_URL=http://localhost:1234
│      CodeRouter 不要、最もシンプル
│
└─ NO、いずれかに該当:
    │
    ├─ Ollama / llama.cpp / vLLM / MLX-LM を使いたい
    │   └─ ✅ CodeRouter 必須 (Anthropic 翻訳)
    │
    ├─ ローカルが落ちたら cloud (NIM / OpenRouter free / Anthropic) にフォールバックしたい
    │   └─ ✅ CodeRouter 必須 (chain)
    │
    ├─ 用途別に複数モデル切り替えたい (coding / general / reasoning / multi)
    │   └─ ✅ CodeRouter 必須 (mode_aliases + profiles)
    │
    └─ ダッシュボード / 各 backend の挙動可視化 / output filter したい
        └─ ✅ CodeRouter が便利

個別の利用シナリオ別

A. 「LM Studio 1 台でいい、ローカルだけ」

→ CodeRouter 不要

# Claude Code 起動時 (LM Studio 0.4.12+ が起動済み前提)
ANTHROPIC_BASE_URL=http://localhost:1234 \
ANTHROPIC_API_KEY=dummy \
  claude

最小 setup。GPU メモリ余裕あれば LM Studio で複数モデル keep + Just-in-time loading で動的切替も可。

B. 「メインは LM Studio、落ちたら cloud free」

→ CodeRouter 推奨

# ~/.coderouter/providers.yaml
- name: lmstudio-qwen3-6-35b-a3b-anthropic
  kind: anthropic
  base_url: http://localhost:1234
  ...
- name: openrouter-free
  ...

profiles:
  - name: default
    providers:
      - lmstudio-qwen3-6-35b-a3b-anthropic
      - openrouter-free        # 落ちたらこちら

CodeRouter が kind: anthropic で LM Studio に passthrough し、失敗時に OpenRouter にフォールバック。

B'. 「LM Studio + Ollama を冗長化、ローカル同士で fallback」

→ CodeRouter 必須 (これが LM Studio 直結だと絶対できない)

profiles:
  - name: default
    providers:
      - lmstudio-qwen3-6-35b-a3b-anthropic   # 1st: LM Studio
      - ollama-qwen-coder-14b                 # 2nd: Ollama (別 backend)
      - llamacpp-qwen3-6-35b-a3b              # 3rd: llama.cpp 直叩き
      - openrouter-free                       # 4th: 最終的に外

LM Studio をうっかり閉じても Ollama に自動フォールバック、Ollama の Qwen3.6 が詰んでも llama.cpp 直叩きが拾う、最後の手段で cloud free。localhost:8088 だけ Claude Code に向けておけば、裏で 3 種類のローカル backend が冗長化される。

これは「ローカルで作業中に何かが止まっても気付かないまま継続」を実現する経路で、直結 (LM Studio 1 本だけ) では絶対できない冗長性。

C. 「Ollama を使いたい (旧資産 + 既存 setup)」

→ CodeRouter 必須

Ollama に Anthropic endpoint がないので、CodeRouter の Anthropic shim 経由でしか繋がらない。

D. 「Ollama + LM Studio + cloud を全部組み合わせたい」

→ CodeRouter 必須 + 全機能フル活用

複数 backend を fallback chain に並べる + mode 別に primary 切替 + dashboard で挙動観測。これが CodeRouter の最も濃い使い方。

メタな話 — プロダクトの存在意義は変化する

CodeRouter を v1.0 で出した時 (2026-04-20)、想定していた主要価値は「Anthropic 互換翻訳」だった。Claude Code が世に出回り始めて、ANTHROPIC_BASE_URL を切替えてもローカル backend が動かない という痛みが広く存在していた。それを CodeRouter が翻訳することで埋める。

しかし 7 日後の今 (2026-04-27)、LM Studio 0.4.12 が公式に /v1/messages をサポートしたことで、「翻訳」だけが CodeRouter の価値だったわけではない ことが明らかになった。残った 3 つの価値 (fallback / mode routing / observability) は LM Studio が自分で出すものではない、router 固有の役割。

これは OSS プロダクト全般に起きる現象で、自分の作ったツールの存在意義は 環境の進化によって絶え間なく再定義される。1 年前に必要だったツールが、今は別の形で要らなくなり、また別の場面で必要とされる。

CodeRouter v1.9 以降は、「翻訳」ではなく「routing」「fallback」「observability」を主軸に価値を再定義 する方向で進めます。Anthropic 翻訳は引き続き提供するけれど、それは「他の backend が追いついていない間の橋渡し」というポジションに移行する。

これを書きながら：

自分が作ったプロダクトの『要らない時』を正直に書けるのは、健全な OSS の証拠かもしれない。

と思った。「LM Studio 直結で済む人にも CodeRouter を勧めない」ことが、長期的にはコミュニティへの誠実さに繋がるはず。

CodeRouter v1.9 以降の方向性 (考え中)

LM Studio 0.4.12 の登場を受けて、CodeRouter の v1.9 以降の方向性を再考中:

1. 「翻訳」価値が薄れる経路向けに、Anthropic passthrough を最小オーバーヘッドに

kind: anthropic 経路は v0.4-A 以来安定しているが、ほぼ何もせずに passthrough するコードが走っている。これを「透過モード」として最適化、metrics だけ取って即 forward する path に整える価値あり。

2. Fallback chain の質を上げる

複数 backend のヘルスチェック、自動 priority 調整、cache hit 率に基づく provider 切替 (Anthropic prompt caching が backend 横断で効くようになるなら)、等。

3. 「直結を使ってる人向けの観測ツール」として CodeRouter を分離する余地

coderouter stats --proxy=passthrough のような mode で、直結経路の latency や error 率だけ観測する透過 proxy として動く形態。これは CodeRouter ではなく別ツール (coderouter-observe 的な) のほうが綺麗かもしれない。

4. LM Studio と平和共存する examples / docs を整備

docs/lmstudio-direct.md (新規予定) で「LM Studio 直結」と「CodeRouter 経由」の両方のセットアップを同列に紹介する。CodeRouter を 押し付けない ドキュメントにする。

まとめ

Claude Code → ローカル LLM は実質 5 通りの経路: CR 経由 4 種類 + 直結 1 種類 (LM Studio 0.4.12+ のみ)
Ollama / llama.cpp 経由は CodeRouter 必須 (Anthropic shim)
LM Studio 経由は CodeRouter 任意: 単機で済むなら直結が最シンプル、複数 backend / fallback / 観測が要るなら CR
CodeRouter の真の価値は 3 つに収斂:
- ローカル LLM 同士で fallback できる — LM Studio 落ちても Ollama に流れる、ローカル裏方の冗長化
- ANTHROPIC_BASE_URL を固定したまま裏で backend / モデルを切り替えられる — Claude Code 側を触らずに --mode だけで完結
- 観測 / output filter / capability gate — モデル固有のクセを吸収
プロダクトの存在意義は OSS / 競合 / 上流の進化で絶え間なく再定義される — 自分のツールが「要らない時」を正直に書けるのが健全さの指標

v1.8.1: ガチで動かしてみたら 3 連敗した話
v1.8.2: 自分が作った診断ツールに自分が騙された話
v1.8.3: Ollama で詰んだ Qwen3.6 を llama.cpp で動かしたら...
v1.8.4: 結論には賞味期限がある — LM Studio 0.4.12 で Qwen3.5 が静かに動くようになっていた話
本記事: 経路分析 + CodeRouter の役割再定義 (v1.9 prep)

質問・感想は GitHub Issues または X (@zephel01) までどうぞ。

CodeRouter プロジェクトを使ってる方も、検討してる方も、自分の構成にとって CodeRouter は必要か を改めて考えるきっかけになれば幸いです。直結で済むならそれが一番シンプル、それでも複数 backend / fallback / 観測が要るなら CodeRouter、というシンプルな判断軸を提供できるのが私の願いです。

（執筆日: 2026 年 4 月 27 日 / 関連バージョン: CodeRouter v1.8.4 + LM Studio 0.4.12）

いいなと思ったら応援しよう！

サーバー代とコーヒー代になります☕ 役に立ったら応援よろしくお願いします！