コーディングに最適なローカルLLM:Devstral、 Qwen3-Coder
2026年、コーディングに最適なローカルLLMはどれかという問いは、もはや答えを求めない修辞的な問いではありません。Devstral、Qwen3-Coder、そして新世代のQwen 3.5 / 3.8は、エージェントによるタスクも含め、クラウドのアシスタントと本格的に競い合うようになっています。このガイドでは、利用可能なコード向けオープンウェイトモデルについて、必要なVRAMと実際の生成品質を比較し、お使いのGPUに応じた明確なおすすめを示します。抽象的なランキングではなく、手元のマシンに合わせた具体的な情報を提供します。
#2026年にローカルLLMをコード作成に使う理由
AIアシスタントを使ったコーディングは、今や日常的になっています。しかし、自社独自のコード、秘密情報、内部パス、あるいは知的財産そのものをクラウドサービスに送ることは、NDA下のフリーランス、RGPDの対象となる企業、そして自分で管理したい個人開発者にとって、依然として問題です。
朗報です。2025年以降、コーディング向けのオープンウェイトモデルは、性能差をかなり縮めてきました。Devstralは最上位のクラウドモデルに匹敵するSWE-benchスコアを達成し、Qwen3-CoderはリファクタリングでClaudeと互角に渡り合います。RTX 3060で動かすQwen 3.5 9Bでさえ、日常的に役立つ作業をこなせます。必要なハードウェアの導入費用は下がり、品質は向上しました。
#適切な選定基準
Devstral か Qwen3-Coder か、選択は決まりました。ローカルコパイロットキットは30分でそれを稼働させます(第2章)、ビデオメモリに適合しているか確認し(第5章)、仕様表を鵜呑みにするのではなく、実際にマシンを計測します(第18章)。
- 永久に利用できるオンラインスペース
- PDF + ファイル
- 生涯アップデート
ランキングに載るベンチマークの結果だけでは、すべては分かりません。実際に使ううえで重要なのは、次の点です。
- 生成コードの品質
- 単に「それらしく見える」コードではなく、コンパイルできてテストにも合格するパッチを書く能力です。HumanEvalやMBPPはその能力の目安になりますが、SWE-bench Verifiedのほうが実際のタスクをよく反映しています。
- Fill-in-the-Middle (FIM) のサポート
- IDEでの自動補完に不可欠です。すべてのモデルが対応しているわけではありません。Devstralはこの点が弱く、純粋なFIM用途では、2026年もqwen2.5-coder:7b-baseが基準となるモデルです。
- コンテキストウィンドウ
- 2000行のファイルやプロジェクト全体を理解するには、最低でも32kトークンを見込んでください。Qwen3-Coderは最大256k、Devstralは最大128kに対応します。
- 推論速度
- 30Bの密なモデルは、RTX 4090で毎秒15~25トークンを生成します。Qwen3-Coder 30B-A3BのようなMoEモデルは、同等の品質で毎秒60~80トークンを生成します。この差は、キーボードで作業するときの使い心地を大きく変えます。
- ライセンス
- Apache 2.0とMITなら、商用利用でも問題ありません。Codestral(非商用)や旧版のCode Llama(制約の多いMetaライセンス)には注意してください。
- 対応言語
- 優れたモデルの大半は、Python、JS/TS、Go、Rust、Java、C/C++に適切に対応しています。PHP、Ruby、Swiftについては、言語別のベンチマークを確認してください。
#Devstral:エージェント型処理に特化したモデル(Mistral AI)
Devstral は Mistral のコードモデルで、エージェント的な作業、つまり Aider、OpenHands、SWE-agent などのエージェントがコードを反復し、テストを実行し、出力を読み取り、修正を行う作業のために特化して訓練されています。SWE-bench Verified では、Devstral Small はオープンウェイトモデルの中で上位にランクインしており、1 年前には到達不可能だった順位です。
- 推奨されるバリエーション
- Devstral Small(~24B、デンス)。Apache 2.0。Hugging FaceおよびOllamaで利用可能です。
- Q4_K_M での VRAM
- 約14GBです。RTX 4080 16GBやMac Mシリーズ24GBなら余裕を持って収まります。12GBでもコンテキストを短くすれば使用できますが、余裕はほとんどありません。
- コンテキストウィンドウ
- 128kトークン。中規模のリポジトリを読み込むには十分すぎる容量です。
- 強み
- バグレポートを読み、コードを調べ、パッチを書き、テストが通るようにする、といった複数段階のエージェントワークフローに非常に適しています。
- 弱点
- FIM(行単位の自動補完)向けには設計されていません。Continue.dev でこのモデルを補完に使いたい場合は、補完の部分だけ qwen2.5-coder:7b-base に切り替えてください。
#Qwen3-Coder、万能ツール(アリババ)
Qwen3-Coder は Alibaba の Coder ファミリーの 2025 年世代で、Mixture-of-Experts(MoE)アーキテクチャを採用しています。2026 年のコード生成向けオープンウェイトモデルの中で、あらゆる形式を含めて最先端だと多くの人が考えているモデルです。Apache 2.0 ライセンスで提供されています。
- 一般向けバージョン
- Qwen3-Coder 30B-A3B : 総パラメータ数は300億ですが、トークンごとにアクティブになるのは30億のみです。具体的には、14〜22Bのdenseモデル相当の品質を、3Bの速度で実現します。
- Q4_K_M での VRAM
- 30B-A3B には約 18 GB が必要です。RTX 4090 の 24 GB メモリ、または Mac M-Pro/M-Max の 24〜32 GB メモリにぎりぎり収まります。
- 最先端のモデルバリエーション
- Qwen3-Coder 480B-A35B。コードに関してはClaudeまたはGPT-5のレベルですが、Mac Studio Ultra 256-512GBまたはH100を搭載したマルチGPUセットアップに限定されています。
- コンテキスト
- 標準で256kトークンに対応し、さらに拡張可能です。文字どおり、リポジトリ全体をそのまま貼り付けられます。
- 強み
- 複数ファイルにまたがるリファクタリングに優れ、「ニッチな」言語(Elixir、Zig、OCaml)も得意です。AIエージェントとしてのタスク遂行にも非常に優れ、MoEによって並外れた速さを実現しています。
- 弱点
- 30B-A3BもMoEモデルです。VRAMに余裕がない場合、9Bのデンスモデルより多くのメモリを必要とすることが響きます。12 GBなら、Qwen 3.5 9Bを使うのがよいでしょう(必要に応じてQ8で)。
#Qwen 3.5、控えめな構成でも頼れる選択肢
Qwen 3.5ファミリー(2B、4B、9B)は、2026年において控えめなスペックの環境で最も汎用性の高い選択肢です。Apache 2.0ライセンス、大きなコンテキスト(最大256k)、中規模モデルでのマルチモーダル対応を備え、4〜12GBのVRAMに収まるよう複数のサイズが用意されています。インライン自動補完(FIM)だけについては、qwen2.5-coder:7b-baseを別枠として扱います。この用途では、依然として基準となるモデルです。
- Qwen 3.5 4B
- Q4でのVRAM使用量は約3.4 GB(ollama run qwen3.5:4b)。RTX 3060 8 GB、RTX 4060、メモリ16 GBのMacBook Air Mシリーズに最適です。新たな標準の小型モデルで、コーディングに関するチャットではまずまずの性能を発揮します。
- Qwen 3.5 9B
- Q4でのVRAM使用量は約6.6 GB(ollama run qwen3.5:9b)。2026年の8 GB環境ならこれ:256kのコンテキスト、画像理解、4Bを大きく上回る品質。8〜12 GBのカードで日常的に使う定番モデルです。
- Qwen 3.5 9B Q8
- VRAMは約11 GB(ollama run qwen3.5:9b-q8_0)。この容量帯で最高の品質を得られ、VRAM 12 GB(RTX 3060 12 GB、RTX 4070)にちょうど収まります。
- 自動補完(FIM)
- Qwen2.5-Coder 7Bのベースモデルは、2026年もFIMの代表格です:ollama run qwen2.5-coder:7b-base(約4.7 GB)。VS CodeのtabAutocomplete(Continue.dev、Tabby)用に引き続き使うモデルとして残しておくこと。
#注目すべき代替候補
- gpt-oss 20B (OpenAI)
- OpenAI のオープンウェイトモデル。MXFP4 で量子化されており、非常に高速で、コンテキスト長は 131k です。VRAM は約 14 GB(ollama run gpt-oss:20b)。コードに強く、応答が速い汎用モデルを求めるなら、16 GB の環境でバランスのよい選択肢です。
- GLM 4.7 Flash (Zhipu AI)
- MoE 30B-A3B、MITライセンス、Q4で約19 GB(ollama run glm-4.7-flash)。技術的なチャット、デバッグ、エージェント用途で非常に高い性能を発揮します。フランス語とコードを併用する場合に適しており、説明は自然なフランス語で出力されます。
- Mistral Small 24B
- 汎用の密モデルで、Q4では約14 GBです(ollama run mistral-small)。フランス語が得意で、16 GB構成のマシンでドキュメント作成や説明の補助に役立ちます。
- Codestral 22B (Mistral)
- 技術面では問題ありませんが、Mistralの非本番利用ライセンスのため、業務環境では使用できません。厳密に個人利用または研究に限る場合を除き、候補から外してください。
- DeepSeek-Coder V2, Code Llama, StarCoder 2
- これらの2023〜2024年のベースモデルは、ここまでに挙げたどのモデルよりも品質が劣ります。選ぶ必要はありません。Qwen 3.5 9BやGranite 4.2 8Bなら、より少ないVRAMで、より良い結果が得られます。
#GPUに応じてどのモデルを選ぶか
利用可能なVRAMに応じた実用的な推奨です。ここで挙げるモデルはQ4_K_Mで量子化されており、この方式はコーディング用途で品質とメモリ使用量の最もよいバランスを実現します。
- 8 GB(RTX 3060 8 GB、4060、5050、5060)
- Qwen 3.5 9B(256k コンテキスト、画像対応)。自動補完や技術的なチャットには、すでに十分実用的です。純粋な FIM 用途には qwen2.5-coder:7b-base を追加してください。コンテキストは 16〜32k。
- 12GB(RTX 3060 12GB、4070、5070)
- 日常的に使うモデルにはQwen 3.5 9BのQ8版(11GB)、またはGemma 4 12B(7.6GB、マルチモーダル)。DevstralのQ4版も、コンテキストを短くすればメモリに収まります。
- 16 GB (RTX 4080、4070 Ti Super、5070 Ti、5080)
- エージェント用途には Devstral 24B、汎用用途には gpt-oss 20B または Mistral Small 24B、FIM には qwen2.5-coder:7b-base。これが、本当に選択肢が広がる最初の構成です。
- 24 GB (RTX 3090, 4090, RX 7900 XTX)
- 普段使いにはQwen3-Coder 30B-A3B(コード用)またはQwen 3.8 27B(汎用、Copilotに最も近いモデル)を使います。エージェントとしての利用にはDevstralを予備に、エージェント用にはGLM 4.7 Flashを使います。日常的な利用でローカルモデルがクラウドに匹敵する構成です。
- 32GB (RTX 5090) または Mac Mシリーズ 36〜48GB
- Q8 の Qwen3-Coder 30B-A3B(32 GB)、または Qwen 3.6 35B-A3B(23 GB、高速な MoE、このメモリ容量帯での堅実な選択肢)。非常に快適に使え、コンテキストは 128k トークン以上です。妥協せず、最高を目指します。
- Mac Studio Ultra 128GB+
- Qwen3-Coder 30B-A3BをQ8で品質を十分に保ち、256kのコンテキストをフルに使って動かす構成です。APIレベルを目指すなら、Qwen3-Coderのフロンティアモデル(480B-A35B)も選択肢になります。これは、データセンターを除けば、フロンティア級のコードモデルをローカルで動かす唯一の手の届く方法です。
#VS Codeにすべてを接続する
最も簡単な方法は次のとおりです。Ollamaは http://localhost:11434 で待ち受け、Continue.dev(VS Code拡張機能)はこのエンドポイントと標準で通信できます。以下は、自動補完用のqwen2.5-coder:7b-base(高速、FIM)とチャット用のQwen3-Coder(高性能)を組み合わせた最小構成です。
エージェント型のワークフロー(複数ファイルのリファクタリング、バグ修正)では、CLIで使うAiderが、特にDevstralとの組み合わせで力を発揮します。
#使いこなしのコツとよくある落とし穴
- Ollamaのデフォルトのコンテキストが短すぎる
- Ollamaのデフォルトのコンテキスト上限は2048トークンです。コードを扱うには、あまりにも少なすぎます。ModelfileまたはContinue.devのパラメータでnum_ctxを設定し、最低でも16kまたは32kまで引き上げてください。
- FIMとチャット — 混同しないでください
- DevstralとQwen3-CoderはFIM向けに最適化されていません。これらを自動補完に使うと、不自然な結果になります(関数の途中にチャット風の応答が入るなど)。tabAutocompleteには、常にFIMに適したモデル(qwen2.5-coder:7b-base)を使ってください。
- 過度な量子化
- コード生成では、Q3以下の量子化で品質が明らかに低下します(構文の誤り、存在しない識別子など)。最低でもQ4_K_Mを使用してください。VRAMに余裕があればQ5_K_Mを使用してください。
- 数分後に性能が急激に低下する
- Ollamaは、使用されていないモデルを5分後にメモリから解放します。断続的にコードを書く場合は、OLLAMA_KEEP_ALIVE=1hを設定してOllamaを起動し、モデルをロードした状態に保ってください。
- 常に英語で応答するモデル
- Continue.devまたはModelfileにシステムプロンプトを追加してください。「常にフランス語で回答し、コードとコメントは英語で書いてください。」Qwen 3.5 / 3.8とDevstralは、この指示に問題なく従います。
- 考えすぎるQwen 3.8 27B
- デフォルトの推論設定では、Qwen 3.8 27Bは簡単なタスクでも考えすぎて、応答までの待ち時間が長くなる傾向があります。日常的なコーディングでは、推論の強度をlowに設定するか、thinkingをオフにしてください。通常のタスクでは目立った性能低下なしに、応答が速くなります。
#さらに詳しく
コード用のモデルを選択し、そのモデルが正常に動作しています。さらに進めるためのヒントです:
- Continue.dev によるローカル Copilot
- Ollamaを使ってVS CodeでContinue.devを設定するための詳しいガイドです。自動補完用とチャット用のモデルを別々に設定する方法や、ショートカットも扱います。
- Claude CodeとCursorでOllamaを使用する
- DevstralまたはQwen3-CoderをCursorまたはClaude CodeにOpenAI互換エンドポイント(Ollama)を介して接続し、クラウドなしで高機能なIDEを活用します。
- 量子化の選択(Q4、Q5、Q8、FP16)
- コードモデルでQ4_K_MからQ5_K_Mに切り替えると何を失い、何を得られるのか、また、量子化のビット数を上げるのがどのような場合に有益なのかを正確に理解するために。
ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。