#4 Codestral 22B（IDE補完特化）
Codestral 22B（Mistral AI）はStarcoder2に代わる推奨FIMモデルです。 VS CodeやCursorでContinue.devとの Fill-in-the-Middle補完専用に設計。ほとんどの補完タスクでCopilot品質に匹敵。
セットアップ：`ollama run codestral:22b`。リポジトリ認識型のコード補完には`ollama run qwen3-coder:30b`（Apache 2.0）が最強のオープンウェイト代替です。
#5 Qwen3 8B（8 GB最適）
Qwen3 8Bは8 GB帯のコーディング推奨モデルです。強力なコーディング性能、多言語対応、~5 GB VRAMのみ使用。
セットアップ：`ollama run qwen3:8b`。
これらのモデルのVRAM要件について詳しくは、VRAM要件ガイド →をご参照ください。
クイックファクト — コーディング向けローカルLLM早わかり
- 総合最高： Qwen3.8 27B（Alibaba）— 密集27B、Apache 2.0、Ollamaで18GB、256Kコンテキスト、SWE-bench Pro 61.7、LiveCodeBench v6 90.3（Qwen公表値）。
- Qwenの前世代： Qwen 3.6 27B — SWE-bench Verified 77.2%、SWE-bench Pro 53.5（Qwen公表値）。依然として有力な代替ですが、Qwen3.8 27Bに置き換えられました。
- 24B級エージェントコーディングに最適： Devstral Small 2（Mistral AI、フランス）— 15GB、SWE-bench Verified 65.8%、Apache 2.0、ツール呼び出しとマルチファイル編集。Ollama 0.13.3以降が必要。
- 長時間エージェントセッションに最適： Laguna XS 2.1（Poolside）— 33B総計/3BアクティブのMoE、20GB、256Kコンテキスト、SWE-bench Verified 70.9%、SWE-bench Multilingual 63.1%、OpenMDW-1.1ライセンス。
- 64GBマシン向けの大型MoE： Qwen3-Coder-Next — 80B総計/3Bアクティブ、52GB（Q4）、256Kコンテキスト。
- IDEオートコンプリートに最適： Codestral 22B（Mistral）— FIM最適化、Continue.dev連携、13GB、32Kコンテキスト。
- 8GB RAMに最適： Qwen3 8B — VRAM 5GB使用、品質と速度のバランスが最良。
- フロンティア規模のオープンウェイト： Kimi K2.6とKimi K2.7 Code（Moonshot AI）— 1T総計/32BアクティブのMoE、256Kコンテキスト。Ollamaは`:cloud`タグのみ。ローカルのGGUFビルドは量子化により約310〜470GB必要。
- ベンチマークの移行： 実用的なコーディングの主要指標はSWE-bench ProとVerified（実際のGitHub issue）。HumanEval（単一のPython関数）は小型モデルの比較に引き続き有用。
- 推奨環境： 24GB GPUまたは32GBユニファイドメモリ（Qwen3.8 27B向け。MacではmacOSが約8GBを使用）。Devstral Small 2なら16GBで十分。
🏆 コーディング向け最高のローカルLLM（クイックピック）
- 総合最高： Qwen3.8 27B — 密集27B、18GB、256Kコンテキスト、SWE-bench Pro 61.7（Qwen公表値）。`ollama run qwen3.8`
- 24B級エージェントコーディングに最適： Devstral Small 2 — マルチファイル編集、ツール呼び出し、15GB。`ollama run devstral-small-2`
- 長時間エージェントセッションに最適： Laguna XS 2.1 — 33B/3BアクティブMoE、20GB、256Kコンテキスト。`ollama run laguna-xs-2.1`
- 大型MoE（64GBマシン）： Qwen3-Coder-Next — 80B/3Bアクティブ、52GB。`ollama run qwen3-coder-next`
- 24GBでのリポジトリ認識型補完に最適： Qwen3-Coder 30B — 30B/3.3BアクティブMoE、19GB、256Kコンテキスト。`ollama run qwen3-coder:30b`
- IDEオートコンプリートに最適： Codestral 22B — Continue.dev向けFIM最適化、13GB。`ollama run codestral:22b`
- 8GB RAMに最適： Qwen3 8B — VRAM 5GB。`ollama run qwen3:8b`
- 👉 迷ったら：8〜16GBのノートPCはQwen3 8B、24GB GPUまたは32GB MacならQwen3.8 27B。
- 👉 16GBの場合： エージェントコーディングにはDevstral Small 2が最適。Qwen3.8 27B（18GB）には24GBカードまたは32GB Macが必要です。
- 👉 長時間のエージェントセッションなら： Laguna XS 2.1またはDevstral Small 2を試してください。
- 👉 IDE補完なら： Continue.devとCodestral 22Bを使います。
🛠️実践: まずハードウェアに合わせてモデルサイズを選びます。8GBならQwen3 8B、16GBならDevstral Small 2、24GB GPUまたは32GB MacならQwen3.8 27B。Kimi K2.6とK2.7 Codeは現実的なローカル選択肢ではありません。Ollamaではクラウドタグのみで、ローカルビルドには300GB以上が必要です。
一言で言うと
2026年のコーディング向け最高のローカルLLMはQwen3.8 27B（18GB、Qwen公表のSWE-bench Pro 61.7）で、16GBのエージェントコーディングにはDevstral Small 2、長時間セッションにはLaguna XS 2.1、IDE補完にはCodestral 22B、8GB RAMにはQwen3 8Bが適しています。
平易に言うと
ローカルでコーディングモデルを動かすことは、ノートPCにAIコーディングアシスタントを入れるようなものです。コードを外部に出さず、オフラインでも動きますが、GitHub Copilotのようなクラウドサービスより遅くなります。
コーディングに適したローカルLLMとは？
2026年には、SWE-bench ProとSWE-bench Verifiedが実用的なコーディングベンチマークとしてHumanEvalにほぼ取って代わりました。 単一関数の生成ではなく、実際のGitHub issueの解決 — 複数ファイルの変更、コードベースの理解、テスト作成 — を測定します。QwenはQwen3.8 27BのSWE-bench Proを61.7、前世代のQwen 3.6 27BのSWE-bench Verifiedを77.2%と公表しています。
コード特化モデルは大規模なコードコーパス（GitHub、Stack Overflow、ドキュメント）で微調整され、多くの場合fill-in-the-middle（FIM）訓練を含みます。これはカーソル前後のコンテキストからコードを補完する能力で、IDEのオートコンプリートに必須です。
Llama 3.1 8Bのような汎用モデルはHumanEvalで72%を記録し、十分に競争力があります。ただし同サイズのコード特化モデルは、訓練データと微調整が一般的な言語タスクよりコード生成の精度を優先するため、5〜15%高いスコアを出します。
📌補足: 各社が公表するSWE-benchスコアは、エージェントハーネス、タスクセット、設定が異なります（QwenのSWE-bench Pro 61.7はClaude Codeハーネスと修正済みタスクを使用）。そのため、公表された2つの数値は直接比較ではなく目安です。HumanEvalは単一関数の比較には有用ですが、SWE-benchの方が実際の開発ワークフローの性能をよく予測します。
#1 Qwen3.8 27B — 総合最高のローカルコーディングLLM
Qwen3.8 27B（Alibaba、2026年8月リリース）は、24GB GPUまたは32GB Macでの最高のローカルコーディングLLMです。 Apache 2.0の密集27Bモデル（トークンごとに全パラメータが有効）です。QwenはSWE-bench Pro 61.7、Terminal Bench 2.1 73.0、LiveCodeBench v6 90.3を公表しています。Ollamaのダウンロードは18GBで、コンテキストは256Kです。
`ollama run qwen3.8`。テキストと画像を入力でき、ツール呼び出しと思考モードに対応し、マルチファイル解析、デバッグ、リファクタリングに向いています。前世代のQwen 3.6 27BについてQwenはSWE-bench Pro 53.5（SWE-bench Verified 77.2%）を公表しており、`ollama run qwen3.6:27b`も有効な代替です。
項目 | 値 |
|---|---|
| SWE-bench Pro | 61.7（Qwen公表値） |
| LiveCodeBench v6 | 90.3（Qwen公表値） |
| アーキテクチャ | 密集（27B全て有効） |
| Ollamaサイズ（Q4_K_M） | 18GB |
| コンテキスト | 256Kトークン |
| ライセンス | Apache 2.0 |
| Ollamaコマンド | ollama run qwen3.8 |
🔍洞察: QwenはSWE-bench ProをClaude Codeハーネスと、問題のあるタスクを修正した洗練済みタスクセットで実行しています。そのため61.7は他社の公表スコアと直接比較できません。強力なベンダー公表のシグナルであり、直接対決のテストではありません。
#2 Devstral Small 2 — 24B級エージェントコーディングに最適
Devstral Small 2（Mistral AI）はエージェントコーディングのワークフロー向けに作られています。 マルチファイル編集、ツール呼び出しを伴うコード生成、デバッグループに対応します。24Bパラメータ、Ollamaで15GB、SWE-bench Verified 65.8%（Mistral公表値）、Apache 2.0。`ollama run devstral-small-2`（Ollama 0.13.3以降が必要）。
aider、Claude Codeスタイルのワークフロー、複数ステップのコード修正を16GBマシンで行う開発者に最適です。エラーのフィードバックを読み、複数ファイルを編集し、画像入力にも対応します。
項目 | 値 |
|---|---|
| SWE-bench Verified | 65.8%（Mistral公表値） |
| 最適な用途 | エージェント、マルチファイル編集 |
| Ollamaサイズ | 15GB |
| コンテキスト | 384Kトークン（Ollama） |
| ライセンス | Apache 2.0 |
| Ollamaコマンド | ollama run devstral-small-2 |
💡ヒント: エージェントコーディング＝推論→コード作成→実行→エラー観察→修正→反復。Devstral Small 2は15GBでこのループをこなすため、Qwen3.8 27B（18GB）が収まらない16GBマシンでの現実的なエージェント選択肢です。
#3 Laguna XS 2.1とQwen3-Coder-Next — 長時間エージェントコーディング
Laguna XS 2.1（Poolside、2026年7月2日）は長時間のエージェントコーディングを狙ったモデルです。 33B総計/3BアクティブのMoE、256Kコンテキスト、OpenMDW-1.1ライセンス、SWE-bench Verified 70.9%、SWE-bench Multilingual 63.1%。Ollamaの既定は20GB（Q4_K_M）。`ollama run laguna-xs-2.1`。
Qwen3-Coder-Next（Alibaba、2026年2月）は64GBマシン向けの大型MoEです。 80B総計/3Bアクティブ、Q4_K_Mで52GB、256Kコンテキスト。`ollama run qwen3-coder-next`。24GBでより小型のリポジトリ認識型コーダーなら、`ollama run qwen3-coder:30b`（30B総計/3.3Bアクティブ、19GB、Apache 2.0）が定番の代替です。
数時間にわたるエージェントセッションで最大のコンテキストが必要ならLaguna XS 2.1、より小さなフットプリントのEU発Apache 2.0モデルが欲しいならDevstral Small 2を選びます。
項目 | 値 |
|---|---|
| Laguna XS 2.1のサイズ | 20GB（33B総計/3Bアクティブ） |
| Laguna XS 2.1のSWE-bench | 70.9% Verified / 63.1% Multilingual |
| Qwen3-Coder-Nextのサイズ | 52GB（80B総計/3Bアクティブ） |
| コンテキスト | 256Kトークン（両方） |
| Ollamaコマンド | laguna-xs-2.1 / qwen3-coder-next |
🔍洞察: MoEモデルは全パラメータをメモリに保持しますが、トークンごとの計算は数十億パラメータだけです。サイズの割に高速に生成できますが、全重み分のRAMは必要です（Laguna XS 2.1は20GB、Qwen3-Coder-Nextは52GB）。
#4 Codestral 22B — IDEオートコンプリートに最適
Codestral 22B（Mistral AI）は、IDEオートコンプリート専用のFIMモデルとして今も有力です。 VS CodeとCursorのContinue.devでfill-in-the-middle補完を行うために作られています。このページで最も古いモデル（Ollamaビルドは約2年前）ですが、最もFIMに特化した選択肢です。
`ollama run codestral:22b`。カーソルの前後にコンテキストがあるIDE型補完向けに訓練されています。Python、JavaScript、TypeScript、Go、Rustに強く、Ollamaビルドのコンテキストは32Kです。
リポジトリ認識型の補完には、`ollama run qwen3-coder:30b`が最も強力なオープンウェイトの代替です（Apache 2.0、19GB）。16GBで推論もできる小型コーダーなら、`ollama run gpt-oss:20b`（OpenAIのオープンウェイト、21B総計/3.6BアクティブのMoE、推論の強さを調整可能）も堅実な選択です。
項目 | 値 |
|---|---|
| 最適な用途 | FIM（IDEオートコンプリート） |
| Ollamaサイズ | 13GB |
| コンテキスト | 32Kトークン |
| FIM対応 | あり（主用途） |
| IDE連携 | Continue.dev、Cursor |
| Ollamaコマンド | ollama run codestral:22b |
🔍洞察: Mistral AIのCodestral 22Bは、FIM（fill-in-the-middle）補完のために作られています。Continue.devと組み合わせると、GitHub Copilotのオートコンプリートに代わるローカルな選択肢になります。
#5 Qwen3 8B — 8GB RAM向けの最高のコーディングモデル
Qwen3 8Bは8GB階層でのコーディング向け推奨モデルです。コーディング性能が高く、多言語対応で、VRAMは5GBのみ。Qwen3.8はOllamaでは現在27Bのみのため、Qwen3 8Bが現行Qwenで最小の選択肢です。他のコーディングモデルのVRAM要件はVRAM要件ガイド →を参照してください。`ollama run qwen3:8b`。
🔍洞察: Qwen3 8Bは8GBマシンの推奨スタート地点です。多言語対応が強く、推論が速く、実際のタスクでのコード品質も良好です。
Kimi K2.6とK2.7 Codeが現実的なローカル選択肢でない理由
Kimi K2.6とKimi K2.7 Code（Moonshot AI）はこのリストで最大のオープンウェイトのコーディングモデルですが、一般向けハードウェアには向きません。 どちらも1Tパラメータ、32BアクティブのMoEで、コンテキストは256Kです。Moonshot AIはKimi K2.6のSWE-bench Proを58.6と公表しており、Kimi K2.7 CodeはK2.6を土台に長時間のコーディングセッション向けに作られています。
Ollamaでは両方ともクラウドタグ（`kimi-k2.6:cloud`、`kimi-k2.7-code:cloud`）のみで、プロンプトはOllamaのホスト型サービスに送信されます。ローカル実行にはコミュニティ製のGGUFビルドが必要です。UnslothはK2.7 Codeについて1ビットで約310GB、2ビットで325〜350GBとしており、ノートPCではなくワークステーションやサーバー向けです。
⚠️注意: `:cloud`タグはローカル推論ではありません。ローカルモデルを選ぶ理由がプライバシーなら、代わりにQwen3.8 27B、Devstral Small 2、Laguna XS 2.1を使ってください。
コーディングモデルの比較：SWE-bench＋HumanEval
モデル | HumanEval | SWE-bench | RAM | FIM |
|---|---|---|---|---|
| Qwen3.8 27B | — | 61.7（Pro） | 18GB | — |
| Qwen 3.6 27B | — | 77.2%（Verified）/ 53.5（Pro） | 約22GB | — |
| Devstral Small 2 | — | 65.8%（Verified） | 15GB | — |
| Laguna XS 2.1（MoE） | — | 70.9%（Verified） | 20GB（3Bアクティブ） | — |
| Qwen3-Coder-Next（MoE） | — | ハーネスにより変動 | 52GB（3Bアクティブ） | — |
| Kimi K2.6（MoE） | — | 58.6（Pro） | 300GB以上（Ollamaはクラウドのみ） | — |
| Codestral 22B | — | — | 13GB | あり（主用途） |
| Qwen2.5-Coder 32B | — | — | 20GB | あり |
| Qwen3 8B | — | — | 5GB | あり |
| DeepSeek-R1 14B | — | — | 10GB | なし |
📌補足: HumanEvalは単一のPython関数の生成を測定し、SWE-benchは複数ファイルにまたがる実際のコード変更を測定します。「Pro」と「Verified」はSWE-benchの別バリアントで互換性がありません。Verified 77.2%とPro 61.7を直接比較することはできません。スコアはすべて各社の公表値です。旧モデル（Qwen2.5-Coder 32B、Qwen3 8B）のHumanEval数値は本ページの以前の版から引き継いだもので、再検証していません。
どのモデルがどのコーディングタスクに向いているか
- 1Python関数のデバッグとマルチファイルのリファクタリング -- Qwen3.8 27Bが第一候補です。密集モデルはトークンごとに27B全パラメータが有効で、マルチファイルの推論に向いています。16GBしかない場合はDevstral Small 2が軽量な代替です。選択： Qwen3.8 27B。
- 2エージェントループ（計画→編集→テスト実行→修正） -- Devstral Small 2とLaguna XS 2.1はツール呼び出しと長時間セッション向けに作られています。Laguna XS 2.1は256Kコンテキスト、Devstral Small 2はより少ないメモリで動きます。選択： 長時間セッションはLaguna XS 2.1、16GBマシンはDevstral Small 2。
- 3FIM / IDEオートコンプリート（VS Code） -- fill-in-the-middleにはそのために訓練されたモデルが必要です。Codestral 22BとQwen3 8BはContinue.dev経由で動作し、Kimi、Laguna、DevstralはFIMが主眼ではありません。選択： Codestral 22B。
- 48GBノートPCでの手早いスクリプト -- Qwen3 8Bは日常的なスクリプト、SQL、定型コードを低遅延でこなします。大規模な型システムやマルチファイル変更では結果が弱くなります。選択： Qwen3 8B。
🔍洞察: SWE-bench型のタスク（マルチファイルのデバッグとリファクタリング）では大型モデルが8Bモデルより高いスコアを出しますが、日常的なスクリプトでは差が縮まります。まずタスクでモデルを選び、次にメモリ予算で絞り込んでください。
速度と出力品質のバランスが最も良いコーディングモデルは？
タスク | Qwen3.8 27B | Devstral Small 2 | Qwen3 8B | Codestral 22B |
|---|---|---|---|---|
| マルチファイルのリファクタリング・デバッグ | 第一候補（密集、18GB） | 良好（15GB） | 大規模変更は限定的 | 主眼ではない |
| ツールを使うエージェントループ | 強い（ツール、思考） | そのために設計 | 基本的 | 主眼ではない |
| 定型コード、REST API、テスト | 強い、やや遅い | 強い | 高速、検証は要確認 | 高速、汎用的 |
| FIM補完（行の途中） | 主眼ではない | 主眼ではない | 対応 | 最適（FIM） |
💡ヒント: 要点： 18GBと15GBのモデルは8Bモデルよりトークンあたりは遅いものの、推論が重要なタスクでは高精度です。IDEオートコンプリートにはFIM最適化モデル（Codestral 22B、Qwen3 8B）のみを使ってください。スループットはGPU、量子化、コンテキスト長に依存するため、ご自身の環境で確認してください。
🛠️実践: 実践的な推奨： タスクの種類で選びます。バッチでのコード生成やリファクタリングレビューにはQwen3.8 27B、16GBでのエージェントループにはDevstral Small 2、遅延が最も重要なリアルタイムIDE補完にはCodestral 22BまたはQwen3 8Bを使います。
どのローカルコーディングLLMを使うべきか
選ぶモデルは重要ですが、コード品質にはプロンプトの書き方の方がさらに重要です。言語、制約、テストケース、出力形式を指定する構造化プロンプトは、コード生成の精度を大きく高めます。プロンプトエンジニアリングガイドは、基礎、フレームワーク、評価手法にわたる80の技法を扱っています。
これらのモデルを軸にしたIDEワークフロー全体は、GitHub Copilotをローカルのモデルに置き換えるを参照してください。オープンソースのスタック（Continue.dev＋Ollama＋Qwen3-Coder）が上記の推奨とよく合います。
- 8GB RAM、コーディング重視：`ollama run qwen3:8b` -- VRAM 5GB、この階層で最良。
- 16GB RAM：`ollama run devstral-small-2` -- 24B級エージェントコーディング（マルチファイル編集、デバッグループ）に最適、15GB。
- 24GB GPUまたは32GB Mac（最高品質）：`ollama run qwen3.8` -- Qwen3.8 27B、18GB、SWE-bench Pro 61.7（Qwen公表値）。
- 長時間のエージェントセッション：`ollama run laguna-xs-2.1` -- 20GB、256Kコンテキスト、SWE-bench Verified 70.9%。
- 64GBマシン：`ollama run qwen3-coder-next` -- 3Bアクティブの80B MoE、52GB。
- VS CodeでのIDEオートコンプリート：Continue.dev経由の`ollama run codestral:22b` -- FIM最適化、最良のローカルCopilot代替。
🛠️実践: まずハードウェアに合わせてモデルサイズを選び、その上で用途に合わせて最適化します。8GBならQwen3 8Bが最良、16GBならDevstral Small 2、24GB以上ならQwen3.8 27B。完璧だが動作が苦しいモデルより、快適に動くモデルの方が優れています。
8 GB VRAMに最適なコーディングLLM（RTX 3060 12GB / RTX 3070 8GB / RX 6800 16GB）
8 GB RAMのマシンでは、Qwen3 8BがコーディングLLMの最良の選択肢です。わずか5 GB VRAMで動作します。これはIDEのほか、ブラウザと他のアプリケーション用に3 GBを残します。Qwen3 8BはFIM（Fill-in-the-Middle）をサポートし、Continue.dev経由でVS Codeの自動補完が可能です。
- Qwen3 8B（推奨）— 5 GB VRAM、20–35 トークン/秒、FIM対応。`ollama run qwen3:8b`
- Phi-4 Mini 3.8B — 68% MMLU（推論）、2.5 GB VRAM、軽量推論に最適。`ollama run phi4-mini`
- Llama 3.2 3B — 40–60 トークン/秒、2.5 GB VRAM、非常に制約の多いセットアップ向けの優良な代替案。`ollama run llama3.2:3b`
16GB VRAM向けの最高のコーディングLLM（RTX 4070 Ti 16GB / RTX 5070 Ti 16GB / 24GBカード）
16GBでは、エージェントコーディングにDevstral Small 2（15GB）が最適です。Qwen3.8 27B（ダウンロード18GB）には24GB GPUまたは32GBユニファイドメモリのMacが必要で、その余裕があるなら最良の選択です。
- Devstral Small 2 — エージェントコーディング、ツール呼び出し、マルチファイル編集に最適、15GB。`ollama run devstral-small-2`
- Qwen3.8 27B — 総合最高、密集27B、18GB、256Kコンテキスト、24GBカードに収まる。`ollama run qwen3.8`
- Qwen3-Coder 30B — 30B/3.3BアクティブMoE、19GB、24GBカードでのリポジトリ認識型補完。`ollama run qwen3-coder:30b`
6 GB VRAMに最適なコーディングLLM（低予算GPU / 統合グラフィックス）
4～6 GB VRAM（低予算GPU、古いノートパソコン、Intel iGPU）のマシンでは、Phi-4 Mini 3.8Bが最適な選択肢です。68% MMLU推論性能を達成しながら、わずか2.5 GB VRAMのみを使用します。これはシステム用に約3.5 GBを残します。
- Phi-4 Mini 3.8B（推奨）— 68% MMLU推論、2.5 GB VRAM、ロジックとデバッグに最適。`ollama run phi4-mini`
- Qwen3 4B — より小さいバリアント、4 GB VRAM、低予算ハードウェア向けの品質・速度バランス。`ollama run qwen3:4b`
🧭 誰が何を使うべきか：ペルソナ別の推奨
- 初心者（ローカルLLM未経験）： LM Studio＋Qwen3 8B -- GUIでターミナル不要、コード補完用のFIM対応、VRAM 5GB。
- ノートPC開発者（8〜16GB RAM、日常のコーディング）： Ollama＋Qwen3 8B（8GBマシン）またはDevstral Small 2（16GBマシン）-- 品質と性能のバランスが良く、何時間も快適に動作。
- 上級開発者（デバッグ、リファクタリング、複雑な推論、24GB以上）： Ollama＋Qwen3.8 27B（密集モデル、18GB）-- マルチファイルのコンテキストとアルゴリズム設計に対応。
- 長時間のエージェントセッション（計画→コーディング→テスト→反復）： Ollama＋Laguna XS 2.1（256Kコンテキスト、SWE-bench Verified 70.9%）またはDevstral Small 2 -- ツール呼び出しと複数ステップ実行向け。
- IDE中心のワークフロー（VS Code、Cursor、JetBrains）： Continue.dev＋Codestral 22B -- カーソル位置での補完向けにFIM最適化、最良のローカルCopilot代替。
- プライバシー重視の環境（GDPR、HIPAA、独自コード）： 上記のいずれかのローカルモデルをOllama経由で（`:cloud`タグは不可）-- 推論に外部APIコールはないため、エディタのプラグインなど他のツールもネットワークを使わない限り、コードはマシンの外に出ません。
⚠️注意: ❌ 避けるべき： 24GB GPUも32GB Macもないマシンで Qwen3.8 27B（18GB）を動かすこと。モデルがシステムRAMにあふれると速度が大きく低下します。小型マシンではQwen3 8BまたはDevstral Small 2を使ってください。
⚠️注意: ❌ 避けるべき： IDEオートコンプリートが必要なときに汎用モデル（Llama 3.1 8B）を使うこと。エディタ内補完に使えるのはFIM対応のコード特化モデル（Codestral 22B、Qwen3 8B）だけです。
🔍洞察: 初心者→中級者→上級者は、ハードウェア要件の段階的な引き上げでもあります。Qwen3 8B（8GB）から始め、ツールやワークフローを増やす段階でDevstral Small 2（16GB）へ、最高の推論品質が必要になったらQwen3.8 27B（24GB以上）へ進みます。
ローカルLLMを使うべきでない時
- リアルタイムオートコンプリート必須：ローカルモデルは遅い（100ms以上）。GitHub Copilotを使う。
- 最新のフレームワーク知識が必要：ローカルモデルは固定のカットオフ日までのデータで訓練されており、訓練後に公開されたAPIは知りません。最新のフレームワークでは、最新のドキュメントをプロンプトに含めるか、GPT-5.6やClaude Sonnet 5のようなフロンティアのクラウドモデルを使ってください。
- 複雑なマルチファイル推論：100k+ トークンコンテキスト。ローカルRAM不足。クラウド使う。
- セキュリティ機密コード：Ollama経由なら安全。DeepSeek APIではない。ただし検証必須。
📊 コーディング向けローカルLLM比較（意思決定マトリクス）
どのコーディングモデルにするか迷っていますか？ PromptQuorumは1つのプロンプトを複数のモデル（Qwen3.8、Devstral、GPT-5.6、Claude）に同時送信し、あなたのコードでの出力、実際の応答時間、精度を並べて比較できます。PromptQuorumを無料で試す — 5分、登録不要。
モデル | 最適な用途 | VRAM | 速度 | 強み | 選ぶタイミング |
|---|---|---|---|---|---|
| Qwen3.8 27B | 総合最高、マルチファイル推論 | 約18GB | GPU次第 | SWE-bench Pro 61.7（Qwen公表値）、密集27B、256Kコンテキスト、Apache 2.0 | 24GB GPUまたは32GB Macで最高のローカル品質が欲しい |
| Devstral Small 2 | 24B級エージェントコーディング | 約15GB | GPU次第 | SWE-bench Verified 65.8%（Mistral公表値）、ツール呼び出し、Apache 2.0 | 16GBでaiderやClaude Code型エージェントを使う |
| Laguna XS 2.1 | 長時間エージェントコーディング | 約20GB（3Bアクティブ） | GPU次第 | SWE-bench Verified 70.9%、256Kコンテキスト、33B/3Bアクティブ、OpenMDW-1.1 | 数時間のエージェントセッションで256Kコンテキストが必要 |
| Qwen3-Coder-Next | 64GBマシン向け大型MoE | 約52GB（3Bアクティブ） | GPU次第 | 80B総計/3BアクティブのMoE、256Kコンテキスト | 64GBユニファイドメモリで大きめのコーダーが欲しい |
| Codestral 22B | IDEオートコンプリート（VS Code、Cursor） | 約13GB | GPU次第 | FIM最適化、最良のローカルCopilot代替、Continue.dev対応 | Continue.devでキー入力ごとの補完が欲しい |
| Qwen3 8B | ノートPCでのコーディング、8GB RAM向け | 約5GB | この中で最速 | コーディング性能向上、FIM対応、多言語 | 8GB RAMでこの階層最良のローカルモデルが欲しい |
| Kimi K2.6 / K2.7 Code | フロンティア規模のオープンウェイト | 300GB以上（Ollamaはクラウドタグ） | サーバー級 | 1T総計/32Bアクティブ、256Kコンテキスト | ワークステーション/サーバーがあるか、クラウドタグを許容できる |
| GPT-5.6（クラウド） | 最新API、複雑な推論、最高性能 | なし（クラウド） | 1秒未満 | 最高精度、最新の知識、マルチファイル推論 | 最高性能、リアルタイム遅延、最新フレームワーク知識が必要 |
| Claude Sonnet 5（クラウド） | コードレビュー、設計判断、デバッグ | なし（クラウド） | 1秒未満 | コード理解、デバッグ、マルチファイル文脈に強い | コストやプライバシーよりデバッグ精度とレビューを重視 |
地域別コンテキスト
日本（METI AI ガバナンス）：ローカルLLMの使用は規制制限なし。ただし企業導入時はMETI AI Governance 2024を参照。コード機密性の観点からローカル推論は推奨される。
アジア太平洋地域：データ移出制限の強い地域（シンガポール、インド）ではローカルLLMが有利。シンガポール PDPA、インド IT Act準拠にはOllama経由オンプレミス推論必須。
グローバル：APIベンダーの規約により、専有コード送信制限あり。ローカルは制限なし。開発チーム内ポリシーに従う。
よくある間違い
- 1RAMサイズ無視：「7Bモデルなら4 GBで十分」と誤解。実際は4.7～8 GB必要（OS、他プロセス含む）。8 GBマシンはOOM回避のため最小構成。
- 2量子化の知識不足：Q4_K_M vs Q5_K_Mの違い不明。品質重視ならQ5_K_M推奨（ストレージ少増）。Q4_K_Mは最小RAM。
- 3FIM未対応モデル選択**：Llama 3.1 8Bを「IDE用」と思い込む。FIMサポートなく補完失敗。Qwen/Starcoder/DeepSeek選ぶ。
- 4オフラインテスト不実施：ネット接続前提で開発。Ollama設定ネット不要確認せず。Ollama is offline――設定確認必須。
- 5単一モデル過信：高いベンチマークスコアでも100%成功するわけではなく。複雑タスクは複数世代実行・投票ロジック必須。
- 6CPU性能過大評価：M1/M2でも7Bは15～25 tok/s。「速い」は相対的。待機時間心理的許容確認。
- 7プロンプト設計がコード品質を左右：言語・制約・テストケース・エラー処理をプロンプトで指定するとハルシネーションを大幅に削減。AIを使ったコードの書き方で実績あるパターンを確認。
よくある質問
コーディング向け最高のローカルLLMは？
Qwen3.8 27B（Alibaba、Apache 2.0）— 密集27B、18GB、256Kコンテキスト、Qwen公表のSWE-bench Pro 61.7。`ollama run qwen3.8`。16GBでのエージェントコーディングはDevstral Small 2、長時間セッションはLaguna XS 2.1、IDE補完はCodestral 22B、8GBマシンはQwen3 8B。
コーディングに最適なQwenモデルは？
24GB GPUまたは32GB Macでは、汎用のQwenとしてQwen3.8 27Bがコーディングに最適です（18GB、Qwen公表のSWE-bench Pro 61.7）。Qwen3-Coder-Next（80B総計/3Bアクティブ、52GB）は64GBマシン、Qwen3-Coder 30B（19GB）はリポジトリ認識型補完、Qwen3 8B（5GB）は8GB RAMに向いています。
Qwenはコーディング向け最高のローカルLLMですか？
ほとんどの一般向けハードウェアでは、ローカルで動くモデルの中でQwen3.8 27Bが現在公表されているコーディングスコアが最も高いですが、全タスクで勝つモデルはありません。Devstral Small 2は16GBに収まりエージェントループ向け、Laguna XS 2.1は長時間セッション向け、Codestral 22BはIDEオートコンプリートに特化しています。スコアは各社の公表値でハーネスが異なるため、自分のコードで試してください。
Kimi K2.6やKimi K2.7 Codeはローカルで動かせますか？
サーバー級ハードウェアでのみ可能です。どちらも1Tパラメータ（32Bアクティブ）のMoEです。Ollamaはクラウドタグ（`kimi-k2.6:cloud`、`kimi-k2.7-code:cloud`）のみを掲載しており、これはローカル推論ではありません。K2.7 Codeのコミュニティ製GGUFビルドは約310GB（1ビット）〜350GB（2ビット）必要です。一般向けハードウェアでローカルにコーディングするなら、Qwen3.8 27B、Devstral Small 2、Laguna XS 2.1を使ってください。
Devstral Small 2とLaguna XS 2.1とは？
どちらもエージェントコーディングモデルです。Devstral Small 2（Mistral AI、Apache 2.0）は15GBの24Bモデルで、Mistral公表のSWE-bench Verifiedは65.8% -- `ollama run devstral-small-2`。Laguna XS 2.1（Poolside、2026年7月2日）は33B総計/3BアクティブのMoEで20GB、256Kコンテキスト。OpenMDW-1.1ライセンスで、SWE-bench Verified 70.9%、SWE-bench Multilingual 63.1% -- `ollama run laguna-xs-2.1`。
HumanEvalとは何で、なぜ重要ですか？
HumanEvalは164問のPythonプログラミング問題のベンチマークです。モデルは各問題に対して正しい関数本体を生成する必要があり、pass@1（1回目で解けた割合）が標準指標です。小型コーディングモデルの比較には今も使われますが、実際のプロジェクトではなく単一関数を測定します。
fill-in-the-middle（FIM）とは何で、どのモデルが対応していますか？
FIMは、カーソルの前後のコードをもとにコードを補完する能力で、IDEオートコンプリートの方式です。Codestral 22B、Qwen3-Coder、DeepSeek-Coder、Starcoder2が対応しています。汎用のLlama 3.1 8Bは非対応です。IDE連携にはFIM対応モデルを使ってください。
ローカルのコーディングモデルでGitHub Copilotの代わりになりますか？
Codestral 22BとContinue.devの組み合わせで、ほとんどのオートコンプリートはカバーできます。複雑なマルチファイル推論では、最も難しいタスクで依然としてクラウドモデルが優位な傾向があります。トレードオフとして、ローカルモデルは遅い一方、完全にプライベートで自分のハードウェア上で動作します。
ローカルのコーディングLLMにはどのくらいのRAMが必要ですか？
最小4GB（極小の3Bモデル）、実用的には8GB以上。16GBならDevstral Small 2（15GB）が動きます。24GBのGPUメモリまたは32GB MacならQwen3.8 27B（18GB）が動作します。MacではmacOSの8GBを除き、コンテキスト用に約6GBが残ります。目安として、Q4_K_Mの重みは10億パラメータあたり約0.6GBに、コンテキスト分のメモリを加えた量です。
500行のPythonファイルはどのくらいのコンテキストを使いますか？
500行のPythonファイルでおよそ2,000〜3,000トークンです。Ollamaの実行時既定コンテキスト（VRAMに応じて変動）では足りない場合があります。単一ファイルのコードレビューには少なくとも`PARAMETER num_ctx 16384`、複数ファイルの分析には32768または65536を設定してください。
ローカルのコーディングモデルは開発に十分な速度ですか？
反復的なワークフローには十分です。速度はGPU、量子化、コンテキスト長に依存します。Qwen3 8Bのような小型モデルはノートPCでも素早く応答し、大型モデルはトークンあたりが遅くなります。依頼して確認する使い方なら数秒の待ち時間は許容できますが、キー入力ごとのオートコンプリートには小型のFIMモデルを使うべきです。
ローカルLLMはGPT-5.6の代わりになりますか？
完全にはなりません。ローカルモデル（Qwen3.8 27B、Devstral Small 2）は、最新フレームワークの知識（訓練カットオフ以降のAPI）、非常に長いマルチファイル推論（100k+トークン）、デバッグ精度でフロンティアのクラウドモデルに及びません。日常的なマルチファイルのタスクでは差を縮め、コードを外部に出さずに済みます。
Qwen3-Coderが最もよくサポートする言語は？
Pythonが主要な訓練言語です。JavaScript、TypeScript、Java、C++、Go、Rust、SQLもよくサポートされ、PHP、Ruby、Swift、Kotlinも扱えます。Python以外の言語ではHumanEvalスコアは下がりますが、依然として競争力があります。
DeepSeek-Coderは独自コードに使っても安全ですか？
Ollama経由でローカル実行する場合、DeepSeek-Coderは外部接続を行いません。コードはあなたのハードウェア上にとどまります。DeepSeekに関するデータ上の懸念はクラウドAPI（api.deepseek.com）に関するもので、ローカルのOllama推論には当てはまりません。ローカル推論ではコードはDeepSeekのサーバーに送信されません。
ローカルのコーディングモデルでSQL生成はできますか？
はい。Qwen3.8 27BとDevstral Small 2はSQL生成に対応します。プロンプトのコンテキストにテーブルスキーマを含めてください。複数JOINを含む複雑なクエリでは、32Kコンテキストで完全なスキーマを含めます。システムプロンプトは「あなたはSQLの専門家です。有効なSQLのみを生成してください。」のように設定します。
SWE-benchとは何で、なぜHumanEvalに代わるのですか？
SWE-benchは、実際のGitHub issueを解決できるか — コードベースを読み、複数ファイルを変更し、テストを書く — を測定します。単一のPython関数を測るHumanEvalと違い、SWE-benchは実際の開発ワークフローでの性能を予測します。SWE-bench VerifiedとSWE-bench Proは別バリアントで、スコアは互換性がありません。2026年には、実用面でコーディングモデルを評価する主要ベンチマークになっています。
ローカルのコーディングモデルをVS Codeに接続するには？
VS CodeマーケットプレイスからContinue.dev拡張機能をインストールします。Continueの設定でプロバイダーにOllamaを選び、モデル（例：`qwen3:8b`、`qwen3.8`、`codestral:22b`）を指定します。拡張機能はlocalhost:11434のOllamaに自動接続します。Cmd+I（macOS）またはCtrl+I（Windows）でインラインのコード生成を起動します。
出典
- Qwenチーム (2026)「Qwen3.8-27B」モデルカード。huggingface.co -- Apache 2.0、256Kコンテキスト、SWE-bench Pro 61.7、LiveCodeBench v6 90.3、Terminal Bench 2.1 73.0。
- Ollama (2026)「qwen3.8」ライブラリページ。ollama.com -- 18GB（Q4_K_M）タグ、256Kコンテキスト。
- Mistral AI (2026)「devstral-small-2」Ollamaページ。ollama.com -- 15GB、SWE-bench Verified 65.8%、Ollama 0.13.3以降が必要。
- Poolside (2026)「Introducing Laguna XS 2.1」。poolside.ai -- エージェントコーディングモデル、33B/3BアクティブMoE、SWE-bench Verified 70.9%、OpenMDW-1.1ライセンス。
- Ollama (2026)「laguna-xs-2.1」ライブラリページ。ollama.com -- 既定タグ20GB、256Kコンテキスト。
- Ollama (2026)「qwen3-coder-next」ライブラリページ。ollama.com -- 80B総計/3Bアクティブ、52GB Q4_K_M。
- Ollama (2026)「kimi-k2.6」ライブラリページ。ollama.com -- `:cloud`タグのみ掲載。
- Unsloth (2026)「Kimi K2.7 Code」ローカル実行ガイド。unsloth.ai -- 1T/32BアクティブMoE、量子化後のメモリ要件310〜470GB。
- Ollama (2026)「codestral」ライブラリページ。ollama.com -- 22B、13GB、32Kコンテキスト。
- Qwenチーム (2026)「Qwen3-Coder-Next Technical Report」。arxiv.org -- Qwen3-Coder-Nextのアーキテクチャとエージェントコーディングの結果。
- DeepSeek AI (2024) 「DeepSeek-Coder-V2 Technical Report」。arxiv.org/abs/2406.11931 -- DeepSeek-Coder V2 LiteのMoEアーキテクチャとコーディングベンチマーク結果。