Claude CodeをローカルLLMで軽くする実践構成

なぜ今、「Claude Code＋ローカルLLM」という構成なのか

Claude Codeを毎日使っていると、ある種の摩擦が見えてくる。コードレビューの説明、リファクタリングの方針確認、ちょっとしたデバッグの相談——どれもClaudeに投げれば答えは返ってくるが、そのたびにAPIトークンが消費され、クラウドへの待ち時間が積み上がる。

解決の方向は二つある。一つは出力を圧縮すること。もう一つは、軽いタスクをローカルモデルに移管すること。この記事では両方を同時に実装する構成を示す。LM Studio 0.4.0のヘッドレスCLIでGemma 4をバックグラウンドサーバーとして立ち上げ、Claude Codeの出力をCavemanプラグインで絞り込む設計だ。

LM Studio 0.4.0のヘッドレスCLIで何が変わったか

Running Gemma 4 locally with LM Studio's new headless CLI and Claude Codeが報告する通り、LM Studio 0.4.0からGUIなしでlmsコマンドを使ってモデルのダウンロード・ロード・サービングが完結する。「llmster」と呼ばれる内部サーバーがバックグラウンドで起動し、OpenAI互換のREST APIを提供する。

lms CLIの主要コマンドと動作

操作の流れは単純だ。lms getでモデルを取得し、lms loadでメモリに展開、lms server startでAPIサーバーを起動する。lms psを叩けば現在ロード中のモデルと消費メモリが一覧で確認できる。google/gemma-4-26b-a4bをロードした状態では、メモリ使用量17.99GB、コンテキスト長48,000トークン、並列リクエスト数2という表示になる。

内部では「continuous batching（連続バッチ処理）」が動いており、同一モデルへの複数リクエストを並列処理できる。会話履歴を保持する/v1/chatエンドポイントも新設されたため、Claude Codeからのマルチターン呼び出しにも素直に対応できる。

Gemma 4のモデル選択——26B MoEか31B denseか

Gemma 4には4種類のバリアントがある。ローカル運用で現実的な選択肢は二つに絞られる。

google/gemma-4-26b-a4bはMixture-of-Experts（MoE）構成で、128の専門家サブネットワークを持ち、推論時には1トークンあたり実効3.8Bパラメータ分だけが動く。MMLU Proで82.6%、AIME 2026で88.3%。Q4_K_M量子化でサイズは17.99GBに収まる。

14インチMacBook Pro M4 Pro（48GBユニファイドメモリ）での実測値は、生成速度51.35トークン/秒、最初のトークンが出るまでの時間（TTFT）1.551秒。コーディング支援の用途なら十分実用に耐える速度だ。

一方、Gemma 4 31B denseはMMLU Pro 85.2%、AIME 2026で89.2%と精度で上回るが、メモリ要件も上がる。48GB搭載機なら選択肢に入るが、32GB機では26B MoEを優先すべきだ。「Eモデル」（E2B・E4B）はPer-Layer Embeddingsによる音声認識・翻訳特化型なので、コーディング用途には向かない。

Cavemanでトークン出力を最大87%削減する

ローカルLLMへの移管と並行して、Claude Code側の出力を絞り込むのがCavemanだ。Julius Brusseeが公開したCaveman: Why use many token when few token do trickは、Claude Codeのプラグインとして動作し、AIの「口」だけを小さくする。思考（reasoning）トークンには手を付けないため、回答の質を落とさずに出力の冗長さだけを削る設計だ。

インストールと使い方

インストールはnpx skills add JuliusBrussee/caveman一行で完了する。セッション中は/cavemanでモードを有効化し、stop cavemanで解除する。強度はLite・Full・Ultraの3段階。/caveman fullがデフォルトで、最も積極的な圧縮を求めるなら/caveman ultraを使う。設定はセッション終了まで維持される。

ベンチマークの実態

公開されているベンチマークは具体的だ。「Implement React error boundary」ではノーマルモードで3454トークンの出力が、Cavemanで456トークンに落ちた（87%削減）。「Set up PostgreSQL connection pool」は2347トークンが380トークンへ（84%削減）。「Explain React re-render bug」は1180トークンが159トークンへ（87%削減）。

削減効果が小さいケースもある。「Refactor callback to async/await」は387トークンが301トークンで22%削減にとどまった。タスクによってばらつきがあり、平均65%削減（1214→294トークン）という数字が実態に近い。

理論的な裏付けとして、2026年3月公開の論文「Brevity Constraints Reverse Performance Hierarchies in Language Models」が引用されている。簡潔な応答に制約をかけると精度が26ポイント改善し、パフォーマンスの序列が逆転したという内容だ。「短く答えさせると賢くなる」という直感に反する結果が、Cavemanの設計根拠になっている。

役割分担の設計——どのタスクをどこに振るか

二つのツールを組み合わせたとき、実際の役割分担はどう設計すればいいか。

ローカルのGemma 4に向いているのは、プライバシー要件の高いコードの確認、応答速度を優先したい反復的な質問、オフライン環境での作業だ。51トークン/秒という速度は、コードの説明やリファクタリング候補の列挙には十分機能する。一方、複雑なアーキテクチャ設計や長文の仕様策定はClaude Codeに残す。ここでCavemanを有効にすれば、Claudeの出力が圧縮されてAPIコストが下がる。

具体的な運用の流れはこうなる。lms server startでGemma 4をバックグラウンド起動しておき、ルーティンの質問はlms chatかOpenAI互換エンドポイントに流す。Claude Codeを開いたら/caveman fullを叩いてセッションを開始し、重要な設計判断だけClaudeに任せる。この二段構えで、クラウドAPIへの依存を構造的に減らせる。

一点注意がある。Gemma 4 26B-A4Bのコンテキスト長は最大256Kトークンだが、ローカルメモリに乗せる際は48,000トークンで動作する。大規模なコードベース全体を一度に渡すような使い方は、メモリとコンテキスト設定を確認してから行うべきだ。

まとめ

LM Studio 0.4.0のlms CLIとGemma 4 26B-A4Bを組み合わせれば、GUIなしでローカル推論サーバーが立ち上がる。そこにCavemanを加えてClaudeの出力を平均65%圧縮する。この二段構えが、クラウド依存を減らしながら開発速度を維持する現時点での現実解だ。まずlms get google/gemma-4-26b-a4bとnpx skills add JuliusBrussee/cavemanの二行を自分の環境で試すところから始めてほしい。