MAX プランから Pro プランへ — Claude Code の節約術 (Ollama 分業設計)

Claude Code Pro の月額枠を使い切って手が止まる、という本業エンジニア向けの記事です。

筆者は Claude Code を日常運用していて、複数の SaaS / ブログを並列開発している過程で「単純作業まで Claude に投げると枠がもたない」問題に何度もぶつかりました。本記事では、ローカル LLM (Ollama + Qwen2.5-Coder) を VS Code 拡張 Continue 経由で併用し、複雑なタスクは Claude / 軽作業はローカル という分業を設計した実構成を、実機ベンチ結果と判断基準付きで共有します。

この記事でわかること:

• Claude Code とローカル LLM を併用すべき場面と、しなくていい場面
• Qwen2.5-Coder 7B / 14B の M4 Pro 実機ベンチ (速度・品質)
• どのタスクをどちらに振るかの判断フローチャート
• VS Code 拡張 Continue の役割分配 (config.yaml 実例)
• 7B モデルが refactor で混入させた実バグの例

なぜ Max → Pro のためにローカル LLM 分業を考えたのか

Claude Code はとても賢い。Sonnet/Opus クラスのモデルは、複数ファイルにまたがる設計判断や、微妙なバグの根本原因の特定で、他のローカルモデルとは一線を画す。

ただし、賢いモデルは高い。Pro 枠 (月 $20) を 1 週間で使い切る本業エンジニアは少なくない。Max でも追い打ちをかけられる。

ここで気付くのは、自分が Claude に投げているタスクの全部が「Claude じゃないとできない」わけではないという事実です。

具体的には:

• ✅ Claude じゃないと厳しい: 設計判断、複数ファイル横断 refactor、デバッグ、要件の解釈
• ⚠️ ローカル LLM でも十分かもしれない: ユニットテストの雛形、JSDoc 追記、import の整理、型注釈の補完
• ❌ Claude に投げるのが過剰: タイポ修正、変数名の機械変換

下の 2 群を Claude から剥がしてローカル LLM に振り替えれば、Claude の枠は「Claude じゃないとできないタスク」だけに集中 できる。これが本記事の前提です。

採用したスタック

ローカル LLM のスタックは以下です。

レイヤー	採用ツール	役割
ランタイム	Ollama	macOS でローカルモデルを動かす
モデル	Qwen2.5-Coder 7B / 14B	コード特化、ARM64 で Metal GPU 利用
エディタ統合	Continue (VS Code 拡張)	Cmd+I / Cmd+L で AI を呼ぶ UI
モデル保管	外部 Samsung SSD (APFS)	内蔵ストレージ節約 (合計 13.5GB)

Ollama 単体のセットアップは

に分けてあります。Continue の設定詳細は

Continue (VS Code 拡張) を Ollama で完全無料運用 — Cursor の代替を月額 ¥0 で作る

VS Code 拡張 Continue を Ollama 接続で完全無料運用する手順。Cursor との 80% 互換比較表とロール分配の config.yaml 付き。

→

を参照してください。本記事は 役割分担と判断基準 に集中します。

実機ベンチ: M4 Pro 48GB での 7B / 14B 速度と品質

Claude Code を補助する以上、ローカル LLM 側が「使い物になるか」を実機で測る必要があります。サンプル関数 calculateMonthlyRevenue（subscriber 配列とプラン別単価から月次売上を集計する 18 行の TypeScript）を題材に、4 シナリオで計測しました。

シナリオ	モデル	実時間	速度 (tok/s)	品質判定
Vitest テスト 3 ケース生成	7B	11s	47	△ アサーション 1 件不正 (> の境界条件を誤解)
JSDoc + @example 付与	14B	29s	25	◎ 完璧
ヘルパー関数抽出 refactor	7B	4s	48	✗ バグ混入 (型整合性失敗)
同 refactor	14B	9s	25	◎ 元の分岐を維持

7B は速いが、ロジック保存が必要な refactor で型/分岐の整合性を見落とす事例を確認しました。具体的には、元のコードがプラン別の判定 (if (plan === 'standard')) を明示的に書き分けていたところを、7B は以下のように「短く美しく」書き換えてしまいました。

// 7B が生成した refactor (バグ入り)
function calculateRevenue(subscriber: typeof subscribers[0]): void {
  if (subscriber.activeSince > asOfDate) return;
  byPlan[subscriber.plan] += prices[subscriber.plan];
  //                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
  //  prices には 'free' キーがないので NaN が混入する
}

prices: { standard: number; premium: number } という型定義に対して subscriber.plan は 'free' | 'standard' | 'premium' を取りうる。元のコードはこれを明示的に分岐で除外していたが、7B は型情報を見落として「短い書き換え」を選んだ結果、free プランのサブスクが来たときに byPlan.free += undefined で NaN が入るバグになりました。

14B は同じプロンプトで以下のように元の分岐を維持しました。

// 14B が生成した refactor (バグなし)
function calculateRevenue(subscriber: typeof subscribers[number]): void {
  if (subscriber.activeSince > asOfDate) return;
  if (subscriber.plan === 'standard') byPlan.standard += prices.standard;
  else if (subscriber.plan === 'premium') byPlan.premium += prices.premium;
}

この 1 サンプルからの教訓は明確です。7B は速いが、ロジック保存系のタスクでは品質を 14B に任せた方が事故が少ない。

役割分担の判断フローチャート

ベンチ結果を受けて、筆者は以下の判断フローで「どこに投げるか」を決めています。

タスクを観察
   │
   ├─ 設計判断 / 仕様の解釈が要る？
   │    └─ YES → Claude Code (賢さの差が大きい)
   │
   ├─ 複数ファイルにまたがる？
   │    └─ YES → Claude Code (文脈の保持が重要)
   │
   ├─ ロジックの整合性が壊れたら困る？ (refactor / バグ修正)
   │    └─ YES → Claude Code か、最低でも Qwen 14B
   │
   ├─ 単一ファイル内の機械的変換？
   │    └─ YES → Qwen 14B (Continue の Cmd+I)
   │
   └─ 雛形生成 (テスト・JSDoc) で誤りは目視レビュー前提？
        └─ YES → Qwen 7B (Continue のチャット)

要点は、「失敗したときにどれだけ困るか」で振り先を決める ことです。テストの雛形なら間違いがあっても目で見つかる。refactor のロジックバグは見つからずに本番に行く。だから refactor は安易に 7B に投げてはいけない。

Continue 側のロール分配

Continue の ~/.continue/config.yaml で、上の判断をエディタ側にも仕込みます。具体的には Cmd+I (インライン編集) のデフォルトモデルを 14B に固定し、機械的な diff 適用 (Apply ボタン) のみ 7B に任せる構成です。

models:
  # 14B: refactor / 複雑な編集 → edit (Cmd+I のデフォルト)
  - name: Qwen2.5-Coder 14B (quality)
    provider: ollama
    model: qwen2.5-coder:14b
    roles:
      - chat
      - edit       # Cmd+I で動く、refactor 用途で安全側に倒す

  # 7B: 機械的 apply 専任、チャットでは選択可
  - name: Qwen2.5-Coder 7B (fast)
    provider: ollama
    model: qwen2.5-coder:7b
    roles:
      - chat
      - apply      # 提案された diff の適用、速度優先

これで「うっかり 7B に refactor を任せてバグが入る」事故を、設定ファイル側で予防できます。チャットパネル (Cmd+L) では両方ドロップダウンから選択可能なので、「軽い質問は 7B、込み入った会話は 14B」と手動切替もできます。

削減できる枠の目安

「Claude Code の枠を何割減らせるか」は使い方次第なので約束はできませんが、筆者の体感ベースで内訳を出すと以下です。

Claude に出していたタスク	ローカルへの振り替え可否	振り替え後の対応
ユニットテストの雛形書き	◎	Qwen 7B (要レビュー)
関数の JSDoc 追加	◎	Qwen 14B
import 整理 / 型注釈補完	◎	Qwen 7B
単一関数のリーダブル化	○	Qwen 14B (要 typecheck)
複数ファイル refactor	△	Claude 維持
バグ調査・原因特定	×	Claude 維持
設計判断・命名議論	×	Claude 維持

仮説としては、Claude に投げていたタスクのうち上 3 項目をローカルに剥がせるだけで、Pro 枠の消費ペースは下がるはずです。実運用 1 ヶ月後の実測値が出たら別記事で追記します。

始めるための具体的な手順

要約すると、以下の順で 30 分くらいで終わります。

1. Ollama をインストール (curl -fsSL https://ollama.com/install.sh | sh、ARM64 ネイティブ確定)
2. モデル保管先を外部 SSD に向ける (環境変数 OLLAMA_MODELS)
3. Qwen2.5-Coder 7B と 14B を pull (合計 13.5GB)
4. VS Code に Continue 拡張をインストール (Continue.continue)
5. ~/.continue/config.yaml を本記事のロール分配で書く
6. VS Code を Reload Window

各ステップの詳細は冒頭で参照した 2 本の関連記事に分けてあります。

注意点 (運用してわかったこと)

• 外部 SSD は常時接続前提: 抜くと ollama list がモデルを見失います。ノマド派は内蔵ストレージで運用する選択肢も検討してください
• メモリは 14.6GB 常駐: 7B と 14B の両方を立ち上げ続けると、48GB 機でも他作業に余裕がない瞬間があります。32GB 以下の機種では 14B 単独運用を推奨
• Cmd+I の応答は Claude より遅い: 14B は 25 tok/s なので、長い refactor は数十秒待つ覚悟。Claude の API 速度には敵いません
• 品質はあくまで Claude < Qwen 14B: ローカル LLM は「Claude の代替」ではなく「Claude の補助」と割り切る方が事故が起きにくいです

まとめ

Claude Code の枠は有限で、ローカル LLM の実行は無料です。**両方を「賢さで振り分ける」**設計にすれば、月額予算内で動かせる開発の総量を伸ばせる余地があります。今回の構成は M4 Pro 48GB が前提ですが、24GB 機でも 7B + 14B 単独切替で同じ思想は実現できます。

この節約術は「Claude をやめる」ことではなく「Claude を一番賢い場所だけに使う」設計です。試して合わなければ Continue を無効化するだけで元に戻せるので、気になった方は週末に 30 分で組んでみてください。

関連記事

Ollama を Mac の外部 SSD で動かす — Apple Silicon でローカル LLM を立てる手順

モデルファイルを内蔵から外部 SSD に逃がす環境変数設定、Rosetta brew 回避、起動運用までを手順化。

→

Continue (VS Code 拡張) を Ollama で完全無料運用 — Cursor の代替を月額 ¥0 で作る

VS Code 拡張 Continue を Ollama 接続で完全無料運用する手順と、Cursor との 80% 互換比較。

→