ローカルLLMでコーディングする——Ollama＋Cline/Continueで、どこまでできるか

自分のPCで動かすモデルに、コードを書かせる。それ自体は数年前からできたが、できたのは補完——書きかけの行の続きを埋める、という範囲だった。「リポジトリを読んで、複数のファイルを直して、テストを走らせる」というエージェント的な使い方は、ローカルには重すぎた。

そこが2025年末から2026年にかけて動いた。この記事は、いま実際にどこまでできて、どこで詰まるかを、一次情報だけで整理する。結論を先に言うと——動く。ただし「設定を1つ変えないと、黙って壊れる」という関門がある。

1. 何が変わったか——オープンモデルが「エージェント型」に届いた

変化を一番はっきり示すのは、モデル開発元自身が「エージェント型コーディング」を売りに書くようになったことだ。

Qwen の公式モデルカードには、「Qwen Code や CLINE といったほとんどのプラットフォームをサポートし、専用に設計されたfunction call形式を備える」と、エディタ拡張の名前が名指しで書かれている（Qwen3-Coder-30B-A3B-Instruct model card）。モデル側が特定のコーディングエージェントを想定して作られている、ということだ。

Mistral AI も同じ方向にいる。2025年12月9日に発表した Devstral 2 は「エージェント型コーディング」を明示した専用モデルで、小さい方の Devstral Small 2（24B）を Apache 2.0 で公開した（Introducing: Devstral 2 and Mistral Vibe CLI）。

2. 道具は2種類ある——ContinueとClineは別物

ここを混同したまま始めると、期待と結果がずれる。どちらもVS Codeの拡張で、どちらもOllamaに繋がるが、設計思想がまるで違う。

Continue の「役割ごとに別モデル」という設計は、ローカルと相性がいい。補完には小さくて速いモデル、チャットには大きいモデル、と使い分けられるからだ。公式のOllamaガイドも、補完用に qwen2.5-coder:1.5b や starcoder2:3b という軽量モデルを名指しで挙げている（Continue — Ollama guide）。

3. 最初の落とし穴——コンテキスト長がVRAMで決まる

ここが本記事で一番重要な章だ。ここを知らないと、「セットアップは成功したのに、エージェントが途中で意味不明な動きをする」という状態にはまる。しかもエラーは出ない。

原因は Ollama の既定のコンテキスト長にある。固定値ではなく、VRAMの量で自動的に決まる（Ollama — Context length）。

一般的なゲーミングPC（VRAM 8〜16GB）は、いちばん上の行に落ちる。つまり4k。エージェントはシステムプロンプトとファイル内容とツール呼び出しの往復でここを軽く超えるので、会話の頭から静かに切り落とされていく。指示を忘れる、同じ操作を繰り返す、途中で目的を見失う——原因はモデルの頭の悪さではなく、入り口で文脈が捨てられていることだ。

Ollama 公式は、この用途について「ウェブ検索やコーディングツールのような負荷の高い作業には、コンテキストを少なくとも64000トークンに設定する」と明記している。設定はサーバ起動時の環境変数で行う。

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

アプリ版を使っているなら、設定画面のスライダーでも変えられる。

Cline 側にも同じ問題への対処がある。公式ドキュメントは「Use Compact Prompt を有効にする」と「タスクを絞る（コンテキストが小さいほど応答が速い）」を推奨している（Cline — Running models locally）。エージェントのシステムプロンプト自体が長いので、そこを縮める設定が用意されているということだ。

4. モデルを選ぶ——VRAM別の現実解

まとめ記事の推奨はあてにしないほうがいい。調べた範囲では、2025年半ばのモデルを「2026年のおすすめ」として挙げているものや、480Bモデルのスコアを30Bモデルの欄に書いているものがあった。ここでは開発元の発表だけを並べる。

出典：Qwen3.6-35B-A3B モデルカード（Terminal-Bench 2.0 は51.5、QwenClawBench は52.6）／Mistral AI 公式発表（2025年12月9日）。スコアは各社が自社で計測したもので、第三者による横並び計測ではない。

注目すべきは Qwen3.6-35B-A3B の「活性3B」だ。35Bのうち実際に毎回動くのは3B分で、これがMoE（Mixture of Experts）の効きどころになる。大きいモデルの賢さと、小さいモデルの速さを同時に狙う構造で、ローカル向きの設計といえる。

ダウンロードサイズと必要スペック

Ollama のライブラリでは、qwen3.6 に 27b（18GB）と 35b（23GB）が並ぶ。Mac向けの -mlx 付きタグもある。

Cline 公式が示しているメモリの目安はこうだ——小さいモデルなら 16〜32GB、中規模のコーディングモデルなら 32〜64GB、大きいモデルとより大きなコンテキストなら 64GB以上。

Mistral は Devstral Small 2 について「コンシューマ向けGPU、さらにはCPUのみの構成でも動く」と書いている。ただし「動く」と「エージェントとして実用的な速さで動く」は別だという点は、頭に置いておいたほうがいい。

5. セットアップ——最短の手順

① Ollama を入れて、コンテキストを設定する

順番が大事だ。モデルを入れる前にコンテキスト長を決める。

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

インストール手順そのものはOllama完全ガイドで扱っているので、そちらを参照してほしい。

② モデルを取得する

ollama pull qwen3.6:27b

VRAMが厳しいなら Devstral Small 2 を選ぶ。どちらもエージェント型を想定して作られたモデルという点が、汎用チャットモデルとの違いになる。

③ GPUに載っているか確認する

ollama ps

この確認を飛ばさないこと。CPU側へ追い出されていると、体感がまったく別物になる。「ローカルLLMは遅くて使えない」という感想の多くは、実はここが原因だ。

④ 拡張機能を繋ぐ

Cline も Continue も、プロバイダに Ollama を選んで http://localhost:11434 を指定する。Cline 公式の注意は「プロンプトを送る前に Ollama が起動していることを確認する」という素朴なもので、特別な設定は要らない。

Cline を使うなら、あわせてUse Compact Prompt を有効にする。

6. クラウドとの差は、実は測りにくくなっている

ここは正直に書いておきたい。「ローカルモデルはクラウドの何％まで来た」という比較を、いまきれいに出すことはできない。理由はベンチマークが揃わなくなったからだ。

オープンモデル側は SWE-bench Verified を出す。Qwen3.6-35B-A3B が 73.4、Devstral Small 2 が 68.0%。一方、フロンティア側はこの指標から離れつつある。

実際、Anthropic の Claude Opus 5 発表にはSWE-bench Verified の数値が載っていない。挙げられているのは Frontier-Bench v0.1、CursorBench 3.2、AA Coding Agent Index、FrontierCode 1.1 で、しかも絶対値ではなく相対的な言い方が多い（「Opus 4.8 の性能を2倍以上に」「Fable 5 のピークスコアの0.5%以内」など）。

それでも言える差

数字が揃わなくても、構造的に差が出る場所ははっきりしている。

「複数ファイルにまたがる推論」で差が出やすいのには理由がある。そこはコンテキストを大量に使い、判断を何十回も積み重ねる工程だからだ。1回の判断の精度差が、往復のたびに掛け算で効いてくる。単一ファイルの手直しでは気にならない差が、リポジトリ規模の作業では体感になる。

7. 「ローカルは無料」は本当か

APIの請求が来ないのは事実だが、無料ではない。コストの形が変わっているだけだ。

だから「どちらが安いか」は、比較する条件で逆転する。すでに24GB級のGPUを持っているなら、ローカルは追加費用ほぼゼロで回る。持っていないなら、そのGPU代でサブスクリプションが何年ぶんも買える。「毎日大量に回すか」「もう機材があるか」の2点で答えが変わる、と考えたほうが正確だ。

8. 使い分けの結論

いちばん現実的なのは併用だ。Continue の補完をローカルの小さいモデルに任せて常時走らせ、まとまった作業はクラウドのエージェントに渡す。補完は回数が多くて1回が軽いのでローカル向き、エージェントは回数が少なくて1回が重いのでクラウド向き——負荷の形がちょうど逆になっている。

まとめ

FAQ

Q1. VRAM 8GB のGPUでもエージェント型は使えますか？

厳しい。モデル本体が載っても、コンテキストを伸ばす余地が残らないからだ。Ollama の既定はVRAM 24GiB未満で4kになり、そこを64000へ伸ばすと必要メモリが増える——8GBではその両立が難しい。Continue の補完用途に絞るか、補完だけローカルにしてエージェントはクラウド、という併用が現実的だ。

Q2. Cline と Continue、どちらから始めるべきですか？

ローカルLLMが初めてなら Continue。要求スペックが低く、うまく動かないときの切り分けも簡単だからだ。補完が快適に動くところまで確認してからエージェント型に進むと、問題がモデルなのか設定なのかを分けて考えられる。

Q3. Mac でも動きますか？

動く。統合メモリがそのままVRAM相当として使えるので、むしろ大きなモデルを載せやすい。Ollama のライブラリには qwen3.6 の -mlx 付きタグ（Apple Silicon向け）も用意されている。ただしコンテキスト長の既定はメモリ量で決まる規則が同じように効くので、確認は必要だ。

Q4. どのモデルが「いちばん賢い」ですか？

公表スコアだけで言えば、この記事で挙げた中では Qwen3.6-35B-A3B の SWE-bench Verified 73.4 が最も高い。ただし各社の自社計測であり、第三者による横並びではない。ライセンス（Devstral Small 2 と Qwen3.6 はどちらも Apache 2.0）や、手元のVRAMに載るかのほうが、実務では効いてくる。

Q5. なぜ「エラーが出ずに壊れる」のですか？

コンテキスト長を超えた分はエラーではなく切り捨てとして処理されるからだ。モデルは「渡された範囲」で正常に応答する。結果として指示を忘れる・同じ操作を繰り返す・目的を見失うという形で現れ、モデルの能力不足に見えてしまう。設定を疑うべき症状だと知っているかどうかで、切り分けの速さがまるで変わる。

Q6. 量子化はどれを選べばいいですか？

迷うなら Q4_K_M 相当から始めるのが無難だ。フォーマットの違い（GGUF / GPTQ / AWQ）と選び方は量子化フォーマット完全ガイドにまとめてある。コーディング用途では「モデルを大きくして強く量子化する」より「少し小さいモデルで量子化を緩める」ほうが安定しやすい——ツール呼び出しの形式を正確に守る必要があるためだ。

Q7. 会社のコードに使っても大丈夫ですか？

ローカルで完結する限り、コードは外に出ない——これがローカルLLM最大の利点だ。ただし拡張機能側の設定を確認すること。プロバイダをOllamaに向けていても、テレメトリや別機能が外部通信する可能性はある。そして「規程で許されるか」は技術とは別の問題なので、社内規程を先に確認してほしい。

関連記事

• Ollama完全ガイド——インストールと基本コマンド
• ローカルLLMのおすすめモデル徹底比較——用途・サイズ別の選び方
• ローカルLLMに必要なPCスペック——VRAM・GPU早見
• 量子化フォーマット完全ガイド——GGUF/GPTQ/AWQの選び方
• ローカルLLMとクラウドLLMの違い——性能差と選び方