ローカル LLM に開発を任せるかの判断材料——貸与 PC 32GB での 4 モデル実測から
はじめに
この稿は、Claude Code の使用量を減らしたい現場の方への答えです。問いは、ローカル LLM に作業の一部を任せるか、何を測るか、です。
2026 年 10 月 14 日、Zenn に 1 本の実測記事が公開されました。スマサテの上田さんが、貸与 PC で 4 モデルを試しています。目的は、Claude Code の使用量を抑えることでした。結論から先に書きます。単発の質問は使えます。開発の代わりには、まだ早いという結果です。
実測の材料と範囲
材料は「開発しながら同じ PC でローカル LLM を動かしてみた話」です。Zenn で 2026 年 10 月 14 日公開、検証期間は 2026 年 9〜10 月です。
環境は次の通りです。
- PC は MacBook Pro（Apple M5・メモリ 32GB）で、エンジニアに貸与されたものである
- モデルの実行は Ollama（Bonsai のみ PrismML 版 llama.cpp）、ファイルの操作は opencode 経由である
- 開発環境の Docker に 16GB を取り、モデルは残り 10GB に収まるものを選んでいる
試したモデルは 4 つです。MiniCPM5-2B・Qwen3.5 9B・Gemma4 E4B・Ternary Bonsai 2 27B です。量子化は Q4_K_M、Bonsai のみ PTQ1_0 です。
数値の範囲に注意してください。1 台・4 モデル・1 セットの量子化・日本語の業務文書に結び付いた結果で、他のマシンや量子化には外挿できません。
単発の質問と、開発の作業は別に測る
14 項目の作業を ○・△・× で判定しています。合計は次の通りです。Qwen3.5 9B は ○10・△2・×1、Bonsai 2 27B は ○10・△4、Gemma4 E4B は ○8・△3・×1、MiniCPM5-2B は ○8・△1・×5 です。Qwen3.5 の 1 件と Gemma4 の 2 件は、10 分を超えたため未計測です。単発の質問だけを見れば、Qwen3.5 9B と Bonsai 2 27B は実用に届きます。
次に、開発に近い作業を試しています。既存のテストが失敗するバグを 1 か所仕込み、失敗したテストと期待値・実際の値を渡して直してもらいました。バグは、賃料帯の比較演算子を逆向きにしたものです。
- MiniCPM5-2B は 35 秒で失敗し、存在しないパスを読もうとして終わった
- Qwen3.5 9B は 311 秒で成功し、テストとコードを読んで条件を書き直している
- Gemma4 E4B は 228 秒で失敗し、バグを残したまま「意図通りに適用されることを期待します」と答えた
- Bonsai 2 27B は 414 秒で成功し、テストデータで原因を確かめてから 1 文字だけ修正した
- Claude Code（Claude Opus 5.5）は 18 秒で成功し、1 文字だけ修正した
単発で ○ が付くモデルでも、テストを直す作業では 2 つが失敗します。直せた 2 つも 5〜7 分で、Claude Code は 18 秒です。質問の品質と開発の品質は、別に測るべきです。
速度は、モデル選びの前にマシンで決まる
生成速度は 4 モデルで、毎秒 71・21・36.6・14〜15 トークンでした。
自宅の Windows PC（GeForce RTX 3080）では、同じモデルが明らかに速くなりました。M5 のメモリの帯域は約 150GB/秒、RTX 3080 は約 760GB/秒です。速度の差は、おおむねこの比に沿いました。M5 では 10 分超で打ち切った作業が、RTX 3080 では Qwen3.5 9B が 49 秒、Gemma4 E4B が 24 秒で済んでいます。足を引っ張るのは、モデルの賢さではなくメモリの帯域です。
済んだかは、モデルの申告ではなくテストで確認する
バグ修正の実験で、気になった点があります。Gemma4 E4B はバグを直せていないのに、直したように答えています。任せた作業が済んだかは、モデルの申告では確認できません。テストの再実行が証明になります。
なお、Claude Code は git の差分から原因を特定しており、ローカルモデルは git を使っていません。18 秒と 5〜7 分の差には、道具の使い方も含まれます。
キャッシュ切れの確認は、ローカル化の前に済む
2026 年 10 月 13 日公開の別の Zenn 記事に、使用量を減らす別の手段が出ています。定額プランの範囲では、常駐エージェントを 1 時間以上空けるとプロンプトキャッシュ（90% オフ）が切れます。再開時の消費は中央値 328,010 トークン（35 回）でした。切れる 5 分前にコンパクトを起こす Mods を作ると、87% 減っています。
ローカルに移す前に、キャッシュの切れ方を確認する価値があります。ただし要約は情報を落とすため、削減と品質は同時に測るべきです。
社内で移行を決める前に、規則に書いておくこと
この実測を判断材料に使うなら、規則に書いておく項目が 5 つあります。
- 測る対象を分ける。単発の質問と開発作業は、別の基準で測る
- 境界を書く。どこまでローカルに任せ、どこからクラウドに残すかを、作業の種類で決める
- 完了の確認はテストで行う。モデルの申告を、完了とみなさない
- マシンの制約を記録する。メモリ 32GB では、開発環境とモデルは取り合いになる
- 数値の範囲を添える。1 台・4 モデル・固定の量子化で得た数字であることを残す
上田さんの会社では、貸与 PC は MacBook Pro・Air・ThinkPad X1 Carbon から選べ、メモリはすべて 32GB です。AI ツールは申請すれば業務で使えます。現在は Claude Code・GitHub Copilot・ChatGPT です。同じ制約の現場では、ローカル LLM が開発の本流に入るのはまだ先です。
参考情報
- 上田「開発しながら同じ PC でローカル LLM を動かしてみた話」、Zenn、2026 年 10 月 14 日公開。本稿の実測数字の一次資料である
- i_ichi の記事（Zenn、2026 年 10 月 13 日公開）。題名は「常駐エージェントがキャッシュ切れで中央値 32.8 万トークンを浪費していたので…」である。キャッシュ切れの数字の一次資料である
本稿は AI の支援を受けて執筆されました。事実の確認と内容の責任は筆者にあります。