この記事は「CPUだけのローカルLLMコーディング」シリーズの第2弾です。
前回: 【第1弾・用語集】https://labo.mond.jp/articles/localllm-terms.html
（Qiita版: https://qiita.com/cuculhart/items/d0dbc8b41f27af504f71）
「ローカルLLMは遅いし精度も足りない。Web版のClaude/GPTに比べたら使い物にならない」
その通りだと思います — Web版と同じ使い方を期待するなら。
ただ、世の中には「ソースコードを外部サービスに送れない」現場が存在します。契約上送れない、内部ルールで禁止されている、あるいは単純に自分のコードを誰かの学習データにしたくない。そういう場所で「じゃあAI支援は諦めるしかないか」と言うのは、実は選択肢が1つ減っているだけです。
この記事は、GPUなし・CPUだけの普通のPCで、ローカルLLMのコーディングエージェントがどこまで実用になるかを実際に測った記録です。良い結果も悪い結果も全部書きます。
実験条件（全部公開）
| 項目 | 値 |
|---|---|
| CPU | AMD Ryzen 5 4500U（6コア・SMTなし・ノートPC向けの古めのCPU） |
| GPU | なし（統合GPUだが推論はCPUのみ） |
| メモリ | 32GB（計測時の空き ~22GB） |
| 実行環境 | Ollama 0.40.2 + 自作IDE「Teaspoon IDE」 |
| 制限 | CPUスレッドは推論に4のみ（OSとIDEに2コア残す） |
測ったものは2つ。速度（トークン生成の速さ）と、実タスクの成功率（ファイル操作→編集→テスト実行を自律で回せるか）。
先に結論: 「遅いが動く」領域は実在する
| モデル | 生成速度 | エージェント実タスク | 判定 |
|---|---|---|---|
| gemma4:e4b | 7.4-8.0 tok/s | T0〜T3 全タスク形式崩れなし・完走 | ◎ 使える |
| qwen3.5:9b | 4.5 tok/s | 完走できるが遅い | △ 限定的 |
| qwen3.5:4b | 7.7-8.0 tok/s | 単純タスクは○・判断が絡むと破綻 | △ 補助用途 |
| gpt-oss:20b | 6.4-6.8 tok/s | ツール呼び出しが構造上出せない | × 非互換 |
| gemma4:12b | 6.9 → 3.1 に悪化 | （速度で失格・ループ未実施） | × |
ここから分かる現実:
- 最高速度で 8 tok/s。Web版APIの数十トークン/秒に比べると確かに遅い
- エージェントが「1ターン考える」だけで 30秒〜2分半。1つのタスク完走に 3〜7分
- それでも、ファイルを読んで原因を診断し、正しい修正をして、テストを回して確認する、という一連の作業が最後まで走り切るモデルが存在する
「チャットのようにサクサク」ではありません。ただ、「待っている間に別の仕事をしている」「送れないコードの相談相手がいる」という形なら、すでに実用です。
反直感的だった発見
実験前の予想を並べると、ことごとく裏切られました:
-
「ファイルサイズが大きい = 賢い」は成り立たない。gemma4:e4b（9.6GB）は gemma4:12b（8.0GB）よりファイルが大きいのに、速くて正確でした。e4b は効率化のための特殊な構造を持つモデルで、「e4b は軽量版だから弱い」という予想は完全に間違いだった
-
「パラメータ数が多い = 良い」も成り立たない。9B モデルは 4B モデルより正確でしたが、遅くて実用ラインを割っていました。4B は速いが正しさに難。速い×正しいの交点が e4b だった
-
「モデルの弱さ」に見えた現象の半分はアプリ側のバグだった。「何度も同じファイルを読み直す」「読んだはずの内容を忘れる」という症状は、ツール側がモデルに履歴を正しく渡していなかった設計欠陥でした。修正したら同じモデルが最短経路で完走しました
セキュリティ観点で「使える」の意味
Web版AIにコードを送れない現場でローカルLLMが「使える」とは:
- 送るデータがゼロになる: ソースコード・設計・顧客情報・失敗したテスト結果 — すべてこのPCの中だけで完結する。APIキー管理・プロキシ・課金ログ・学習転用の懸念がそもそも存在しない
- 速度はトレードオフとして割り切れる: 「送れない仕事を手伝ってもらえる」の対価として 8 tok/s を受け入れるか、という計算
- 監督は残る: 完全に任せっぱなしにはしない（小さいモデルは指示範囲外を書き換えることがある — 実測済み）。「人がレビューする前提の助手」として使う
正直な限界
- Web版と同じ感覚で「頼んで数秒で差分が返ってくる」体験はない
- 10行程度の単発コード生成でも数十秒かかる
- 自律ループを回すと CPU が張り付く（推論スレッドを絞る設定は必須）
- 4B級のモデルは幻視・誤読が多く、監督なしには信用できない
まとめ
ローカルLLMは「Web版の代用品」ではありません。**「外部に出せない仕事のための、遅いけれど実在する助手」**です。
重要なのはモデル選定と、それを囲むツール（ハーネス）の設計です。今回の実験では gemma4:e4b + 適切なハーネスで、CPUのみの環境でも自律的なコーディングタスクが完走することを確認しました。
その「ハーネス設計がいかに成功率を左右するか」 — むしろ自分のハーネスのバグが「モデルの弱さ」に見えていた — が次の記事の話です。
続きはこちら（全数字・全ログ公開）
- 第3弾: 「モデルが弱い」と思ったら自分のアプリのバグだった
https://labo.mond.jp/articles/localllm-harness-bug.html - シリーズ一覧（全6本）
https://labo.mond.jp/ - 計測の生データ・タスク定義・全実行ログ（GitHub）
https://github.com/cuculhart/ai-editor-lab/tree/main/experiments/localllm - Teaspoon IDE（計測に使った自作IDE / FSL-1.1-MIT）
https://github.com/cuculhart/teaspoon-ide