⚡runlocal.cc
GPUを診断 →
← ブログに戻る
Issue #102026年5月21日

Stop trying to use Cline locally. r/LocalLLaMA's real answer for daily-driving Qwen3.6 27B + MTP.

Cloud agents fall apart on local models. Three scaffold-first tools the community is actually shipping with — SmallCode, PI Coding Agent, and little-coder — plus a decision matrix by VRAM.

思い違いをしていた

今週は別の記事を書きかけていました。Google Trends を見れば結論は明らかだったからです。直近12ヶ月で Cline 平均 62、Aider 27、Continue.dev 3。ランキングは明快、対比記事の構成も決まっている、と。

ところが r/LocalLLaMA で「Qwen3.6 27B + ローカル実機」の話題を直近30日で集計してみると、まったく違う景色が見えてきました:

  • Cline: 1件、スコア 2
  • Aider: 1件、スコア 21
  • Continue.dev: 0件
  • SmallCode: 1件、スコア 792
  • PI Coding Agent: 1件、スコア 256
  • little-coder: 1件、スコア 21（技術的に最も深い投稿）

Trends は嘘をついていました。「クラウドコーディングエージェント」のオーディエンスと「実際にローカルモデルを動かしている」オーディエンスはほぼ重なりません。先週の llama.cpp に MTP がマージされた件 で生成速度は 2× になりました。次の問い — その上で何を動かすか — は、SEO 結果が示すのとは別の答えがあります。

なぜクラウドエージェントはローカルで崩壊するのか

この記事を書き直すきっかけになった 792 upvote のスレッドは、冒頭の一文がすべてを物語っています:

"I was frustrated that every coding agent (OpenCode, Cursor, Claude Code) assumes you're running GPT-5.4 or Claude Opus. If you try them with a local model like Gemma or Qwen they fall apart."

— r/LocalLLaMA 1tgecrq

このスレッドが指摘し、コメント欄でも全員に同意された4つの失敗モード:

  1. ツールコール連鎖が壊れる — 3回以上の連続呼び出しで小さなモデルは一貫性を失う
  2. コンテキストが溢れる — クラウドエージェントはファイル丸ごとプロンプトに突っ込む
  3. 多段タスクが崩壊する — あるステップの出力が次のステップの入力契約に合わない
  4. エラーから回復しない — クラウドエージェントは「モデル自身が直してくれる」前提

MTP は Qwen3.6 27B を速くしました。Claude Opus にしたわけではありません。ローカルコーディングの問題はもはや速度ではなく、スキャフォールドのパラダイムミスマッチです。修正策は、小さなモデルのために ボトムアップで 設計されたツール — Cline をローカル向けに無理やり後付けしたものではなく。

スキャフォールドファーストな3つのツール

1. SmallCode — バイラルになった新顔

  • アンカー: r/LocalLLaMA 1tgecrq — 792 upvote / 350 コメント、5月18日
  • 主張: Gemma 4 4B（アクティブパラメータ）で 87/100 のベンチマーク合格、OpenCode の 14B モデル 75% を上回る
  • コアトリック:
    • 複合ツール (Compound tools) — 1つのツールで find+read+edit+verify を完結。モデルに4連続呼び出しをさせない
    • 改善ループ — コード生成のたびに即座にコンパイル/lint し、エラーを自動でフィードバック
    • 失敗時に分解 — 2回目のリトライで「同じことを繰り返す」のではなくタスクを細かく分割
    • 自動エスカレーション — どうしても必要な1つのタスクだけ Claude/OpenAI に渡す、95% はローカルのまま
    • コードグラフ — シンボル単位のインデックス、grep で断片を投げる代わりにグラフを歩く
  • インストール: npm install -g smallcode → LM Studio / Ollama を指定
  • 欠けているもの: LSP なし、マルチセッションなし、デスクトップアプリなし

2. PI Coding Agent + plan-first スキル

  • アンカー: r/LocalLLaMA 1stjwg5 — 256 upvote / 106 コメント
  • 主張: Qwen3.6 35B-A3B Q4_K_XL で実際のプロダクションタスクに耐えた
  • 鍵となるアンロック: 1枚の plan-first スキルファイルが、モデルを5フェーズのループに強制する:
    1. プロジェクトをサイレントに分析
    2. 最大5つの確認質問を1ラウンドだけ
    3. 依存順に並んだ具体的タスクを TODO.md に書く
    4. ユーザー承認まで改訂ループ
    5. 1タスクずつ実行し、完了したら [x] をマーク
  • なぜこれが効くか: 小さなモデルはコードは書けるが、200行の計画を頭の中に保持できない。スキルファイルが計画を外部化し、モデルは一度に1タスクだけ扱えばよくなる。
  • スキルファイルはスレッド本文にそのまま貼ってあります。 コピペで動きます。

3. little-coder + タスク形状ルーティング

  • アンカー: r/LocalLLaMA 1st4cqq — 21 upvote、しかし本グループで最も技術的に深い投稿
  • 構成: RTX 5090 (Frodo) + RTX Pro 6000 96GB (Gandalf)、Frodo に Qwen3.6 35B-A3B、Gandalf に Qwen3-Coder-Next 80B (vLLM 経由)
  • 主張: 実際の Go コード10タスクで 9/10 合格、コスト $0、所要 1489秒
  • 転換点: 著者は最初「Aider 風のハーネス」を使い 3/10 しか取れませんでした。little-coder + ルーティング に切り替えたところ、単一モデルで 8/10、ルーティングで 9/10 に。
  • ルーティングポリシー:
一般的な Go モジュール作業    → Qwen3.6 + little-coder
SQL / ストア / マイグレーション → Qwen3.6 + little-coder
コンパイル / import の局所失敗 → ローカル Gandalf (Qwen3-Coder-Next) で修復
タイマー / 並行性バグ          → フロンティアモデルへエスカレーション or 専用 playbook
  • モデル外の決定論的修復: goimports、gofmt、go mod tidy、go test -timeout。これらはモデルにやらせない。
  • 本質的な一文: 「正しい抽象化は『最良のモデルを選ぶ』ではない。『タスク形状と失敗モードでルーティングする』だ。」

ハードウェア別決定マトリクス

環境 推奨スタック
8〜12GB VRAM SmallCode + Gemma 4 4B (Q4)
24GB VRAM (3090/4090) PI Coding Agent + Qwen3.6 27B + MTP + plan-first スキル
32GB+ 単体 (5090) PI Coding Agent + Qwen3.6 35B-A3B + MTP、もしくは SmallCode
デュアル GPU (24+24, 32+96) little-coder + ルーティング (Qwen3.6 35B-A3B + Qwen3-Coder-Next 80B)
Mac M3/M4 36GB+ SmallCode または PI Coding Agent (LM Studio で GGUF + MTP)
6GB 以下 エージェントを諦め、1〜3B モデルでインライン補完に留める

実行前に runlocal.dev カリキュレーター で量子化込みの VRAM 余裕を確認してください。

旧勢力の最後の砦

  • Aider — インターネット全体ではいまだに最も名前を聞きますが、2026年5月の r/LocalLLaMA では 負けたベースライン として登場します。1st4cqq 曰く: 「以前の Aider 風ハーネスは同じタスクで 3/10 しか取れなかった」。死んではいませんが、いまやスキャフォールドファースト系ツールの比較対象です。
  • Cline — 検索ボリュームは高いが、ローカル LLM 圏での存在感は低い。Cline を使っているコミュニティは裏で Claude Sonnet / GPT-5.4 を動かしています。流れに逆らわないこと。
  • Continue.dev — インライン補完拡張としてはまだ有効。エージェントモードはローカル LLM ユーザーが時間を使う場所ではありません。Trends は下降、r/LocalLLaMA もそれを反映しています。

Japan corner: Kiro + Hermes

日本語圏のローカルコーディング界隈は、別系統のスタックに収束しつつあります: Kiro CLI + Hermes Agent + Ollama。Hermes が「どのタスクでどのモデルが発火するか」のルーティング問題を担当します。根底の洞察は同じ（スキャフォールドファーストはクラウドエージェントの後付けに勝つ）、構成要素が違うだけです。Hermes のルーティングパターンは独立した1号として深掘り予定です — サイドバーで済ませる話ではありません。

今週末のアクションプラン

  1. 24GB+ カード: PI Coding Agent + Qwen3.6 27B (MTP GGUF) をインストール、スレッド の plan-first スキルファイルをコピペ、バックログから実チケットを1つ流してみる。
  2. 8GB カード: npm install -g smallcode + Ollama 経由で Gemma 4 4B、SmallCode から指して小さなリファクタを実行。
  3. デュアル GPU: little-coder をクローンし、自分のリポのコピーで著者の10タスク eval を走らせる。
  4. VRAM 余裕を確認: runlocal.dev カリキュレーター → 自分のカードを選ぶ → MTP オーバーヘッド込みで量子化が収まるか確認。
  5. デイリードライバーを共有: 1ti2ga0 (48GB デイリードライバースレッド、現在 153 コメント) に投稿してみる。

今週を超えてなぜ重要か

2026年前半の物語は「どのクラウドエージェントが勝ったか」ではありませんでした。それは 小さなモデルでクラウドエージェントのパラダイムが敗北した話 です。MTP がローカルを速くし、スキャフォールドファースト系ツールがローカルを 使える ものにしました。この2つを足したものが、いま r/LocalLLaMA のデイリードライバー層が実際に動かしているものです。

向こう60日の注目点:

  • SmallCode が LSP とマルチセッションを足すか — 足せば 8GB ユーザーが OpenCode を完全に捨てられる
  • 誰かが 正準スキルライブラリ (plan-first + test-first + refactor + debug) を公開するか — PI Coding Agent ユーザーが毎回車輪を再発明する状況が解消される
  • little-coder のルーティングポリシーが独立ライブラリとして抽出されるか — 他のエージェントが採用できるようになる

このイシューから1つだけやるとしたら: いまの自分のローカルエージェントに plan-first スキルファイルを貼り付けてください。10分でできる、もっともレバレッジの高い変更です。

次号: 正準スキルライブラリ — ローカル LLM コーディングエージェントが標準搭載すべきもの、そして自分で書くべきもの。

← 全ての記事