Claude Proプランを使い始めてすぐ気になったのが、時間制限でした。
月額課金なので追加費用はかからないのですが、開発作業やドキュメント作成等をしていると、まさに必要というタイミングで制限に引っかかってしまいます。プラン上仕方ないと言えばそれまでなのですが、Claudeのトークン消費に合わせて作業を調整しなければならないのが地味にストレスでした。
そこで試してみたのが「ローカルLLMとの連携」でした。クラウド上ではなくローカルで動くAIエージェントも近年進化してきているという情報を見かけたことがあり、以前から気になっていたからです。
今回は導入直後の体験談をまとめてみたいと思います。
なぜLM Studioか
ローカルLLMのツールはいくつかありますが、LM StudioはMCPサーバーが公式サポートされており、接続の手間が少なそうということから選んでみました。実際GUIも用意されており、セットアップに詰まることはありませんでした。
トークン節約の仕組み
Claudeと連携させながら使い方を模索していたところ、重要なのは「コンテキスト回避」とのことでした。
Claudeが直接ファイルを読むとファイル全体がコンテキストウィンドウに入ります。1,352行のTypeScriptファイルなら約14,000トークン。これをLM Studioに委譲すると、Claudeが受け取るのはMCPツール呼び出しの結果（数百トークン）だけになります。元のファイル内容はClaudeのコンテキストに一切入りません。
Claude（オーケストレーター）
│
├── 設計・意思決定・ツール連携 ──── Claude API（トークン消費）
│
└── ファイル要約・レビュー・定型作業 ── LM Studio MCP（ローカル・無料）
ファイルの読み込みを「代行」させることで、Claude側のコンテキストを大幅に節約できます。
環境
- Claude Proプラン / Cowork（claude-sonnet-4-6）
- LM Studio v0.3.x（ローカルサーバー）
- モデル：
qwen/qwen3-vl-8b（今回の計測に使用） - MacBook Air M3
構築手順
Step 1: LM StudioをMCPサーバーとして起動する
lms server start --port 1234
GUIの「Local Server」タブから起動することもできます。
Step 2: LM Studio MCPをCoworkに接続する
Coworkの設定からLM Studio MCPプラグインを有効化します。これで mcp__lm-studio__ask ツールが使えるようになります。
Step 3: CLAUDE.mdに委譲ルールを書く
これが一番重要でした。CLAUDE.mdに「何をLM Studioに任せるか」を明示することで、ClaudeがMCPツールを自動的に使い分けるようになります。
## LM Studio連携ルール（トークン節約）
LM Studio MCP（`mcp__lm-studio__ask`）が利用可能な場合、
以下のタスクはローカルモデルに委譲する。
### 委譲するタスク
- コードの要約・説明・ドキュメント生成
- コードレビューの初期スクリーニング（大ファイルは特に有効）
- ボイラープレートコード・テストスタブの生成
- フォーマット変換（JSON→YAML、命名規則の統一など）
- CLAUDE.mdや仕様書の要約・要点抽出
### Claudeが直接処理するタスク
- アーキテクチャ設計・技術選定の意思決定
- 複数ファイルにまたがるリファクタリング
- ツール連携が必要な作業（Notion・GitHubなど）
- LM Studioの出力結果のQAと最終判断
実際に計測してみました
今回のセッションでLM Studioに実際にリクエストを投げて計測しました。
計測① CLAUDE.md要約タスク
モデル: qwen/qwen3-vl-8b
入力: 189 tokens
出力: 177 tokens
速度: 18.8 tok/s | TTFT: 24.1s
コスト: $0（ローカル実行）
同じタスクをClaude Sonnet 4.6で処理すると約$0.003（≈¥0.5）かかります。1回では小さいですが、こうした読み込みが積み重なることで時間制限が早まるのだと思います。
計測② コードレビュー
モデル: qwen/qwen3-vl-8b
入力: 262 tokens
出力: 399 tokens（バグ5件を指摘）
速度: 16.5 tok/s | TTFT: 4.3s
コスト: $0
小タスクでは節約効果は限定的です。MCPツール呼び出し自体に約250トークンのオーバーヘッドがあるため、入力が小さいとむしろ誤差の範囲になります。効果が大きいのは、大きなファイルを読み込む場面です。
ここで参考として紹介したいのが houtini-lm という類似ツールのベンチマークデータです。houtini-lmはClaude Codeから重い処理をローカルLLMへ委譲するためのMCPサーバーで、コンテキスト回避の仕組みは本構成と同じです。実際のTypeScriptファイルで計測した結果が以下になります。
| 方式 | 消費トークン | 節約率 |
|---|---|---|
| Claude直接(1352行) | 14,466 tok | - |
| LM Studio委譲 | 769 tok | 95% |
ファイル全体をClaudeが読む代わりに、LM Studioが要約した結果（769トークン）だけがClaudeのコンテキストに入るため、これだけの差が生まれます。自分ではまだ大規模ファイルでの体系的な計測ができていませんが、同じ原理なので近い効果が期待できると考えています。
運用してわかったこと
最初はとにかくトークンを節約したく、CLAUDE.mdへ「基本的にすべてのタスクをLM Studioに委譲する」と書いていました。
しかし、使用を徹底させるのが難しく、MCPツール呼び出し自体に約250トークンのオーバーヘッドがあるため、作業によっては委託するのが効果的でない場面もあることが分かってきました。
そこで以下のようにCLAUDE.mdのルールを見直しました。（2026年6月に更新）
### 運用で判明した改善ポイント
- temperature: 0.1 でコードタスクの安定性が向上
- system プロンプトに役割（例：「シニアJavaエンジニア」）を指定すると品質が上がる
- 単純な質問・コミットメッセージ生成は委譲のMCPオーバーヘッド（~250tok）が
節約を上回るため直接Claudeで処理する
- 大ファイル処理（300行以上）は委譲による節約効果が最も高い
temperatureとは回答のランダム性を操作する数値で、デフォルトが0.7のため、引き下げることでコードレビューの安定性を向上させられるようです。また、systemプロンプトに役割を書くことで指摘の粒度を上げられるよう設定してみました。
残課題
色々と試行錯誤を重ねていますが、現状の使い方ではまだ完成形とは言えないと感じています。
現時点で体感としては約20%程度節約できているかな...といった程度で、まだ数字として積み上げられていない部分があります。(LM Studio使用ごとにトークン節約報告をさせているので、メンタル的なメリットはある気がします...笑)
実計測データの蓄積：今後は作業の種類・ファイルサイズ・モデルの組み合わせをもう少し体系的に計測して、どんな場面で効果が出やすいかを把握したいと思っています。
節約性能をさらに上げる工夫：現在のCLAUDE.mdルールでは委譲するかどうかをClaudeの判断に委ねている部分が多く、意図した通りに動かないケースもあります。houtini-lmのような専用MCPサーバーでタスク分類を自動化する方法や、モデルをもっと小さくして速度と節約効果を両立させる方法も試してみたいと考えています。
おわりに
Claude Proプランでトークン制限が気になっている方には、試す価値がある構成だと思います。設定の核心はCLAUDE.mdに数行追記するだけで、導入コストはほぼゼロです。
大きなファイルを多く扱う開発作業ほど効果が出やすいようで、ローカルLLMの品質は上がり続けているので、委譲できるタスクの範囲はこれからさらに広がっていくはずです。