先に結論

RTX 4060 (8GB) で Claude Code や Cursor を「ローカルLLMで置き換えられないか」と、2026年5月のいま改めて考えてみた。

去年なら答えは単純だった。「8GB じゃモデルが小さすぎて話にならない」。だが今年は違う。8GB に収まる現行モデル — Qwen3.5-9B — は、もう実用的なコーディング相棒として成立している。コード補完も、単発のコード生成も、普通にこなす。

それでも、Claude Code の代わりにはならなかった。理由は「8GB が狭いから」ではない。Claude Code 級の自律コーディングエージェントを担うモデルが、2026年に 27B〜80B クラスへ大型化したからだ。8GB に収まる 9B はよくできた「アシスタント」だが、「エージェント」の階層は一段上の VRAM へ移った。

ここから引き出したい主張はひとつだ。2026年、8GB の正解は、Claude Code の劣化版を作ろうとするのをやめ、「アシスタント層」を取り切ることにある。 これは妥協でも敗北宣言でもない。Qwen3.5-9B はアシスタントとしては本当に優秀で、一方エージェントの真似は構造的に勝てない土俵だ。負ける土俵を降り、勝てる土俵を取り切る — それが 2026年の 8GB の戦い方になる。

この記事は、なぜそう言えるのかを、公開ベンチマークと VRAM の実情から追いかける。自前のベンチ数値は出さない。モデルカードの数字とメモリの大きさで、輪郭は描ける。

2026年5月、8GBで「いま動かすなら」何か

去年このテーマを書くなら、主役は Qwen2.5-Coder-7B だった。だがそれは2024年末のモデルだ。2026年の「いま動かしたいモデル」としては、さすがに古い。

ややこしいのは、8GB に載るサイズの専用コーダーモデルが、その後アップデートされなかったことだ。コード特化の系列は Qwen3-Coder へ進み、最新の Qwen3-Coder-Next は 80B-A3B (総 80B / アクティブ 3B) の MoE になった。性能は高いが、MoE は総パラメータ分のメモリを要求するので、8GB には載らない。小型 dense コーダーの席は、2024年で止まったまま空いている。

なので「2026年5月、8GB でいま動かすなら」の現実的な答えは、専用コーダーではなく汎用モデルになる。

モデル	量子化	ファイルサイズ	8GBでの扱い
Qwen3.5-9B	Q4_K_M	約 5.7 GB	32Kコンテキストまで GPU 常駐可
Qwen3.5-4B	Q4_K_M	約 2.5 GB	余裕、ただし能力は一段下
Qwen3.6-35B-A3B	Q4_K_M	約 19 GB	8GB論外 (16〜24GB級)
Qwen3-Coder-Next 80B-A3B	Q4_K_M	約 45 GB+	8GB論外

Qwen3.5-9B が、2026年5月に 8GB で動かす実質的な第一候補だ。汎用モデルだが、コーディングは強い。以降はこの 9B の上で話を進める。

9Bはもう「おもちゃ」ではない

Qwen3.5-9B を「8GB で仕方なく動かす妥協モデル」と思うと、見誤る。公開ベンチマーク (Qwen 公式モデルカードの掲載値) の数字はかなり強い。

LiveCodeBench v6 (コード生成): 65.6
GPQA Diamond (推論): 81.7

コード生成の LiveCodeBench v6 で 65.6。フロンティア級 (gpt-oss-120b で 82.7) には届かないが、65.6 は「実用的なアシスタント」として十分なレンジに入っている。推論の GPQA Diamond 81.7 も、9B クラスとしては高い。1年前に 8GB で動かしていたモデルとは、もう別物の水準にある。

補完、関数単位の生成、エラーの説明と修正、コードレビュー — 1ファイルの中で完結する仕事なら、8GB のローカルでこなせる。ここは去年から明確に進歩した部分だ。

ひとつ注意するなら量子化だ。汎用チャットなら Q4_K_M で困らないが、コード生成は量子化劣化に敏感で、括弧の対応や型の整合は精度が落ちると崩れ始める。8GB の予算内なら Q4_K_M で 32K を取るのが現実的な妥協点で、コンテキストを 16K まで割り切れるなら Q5_K_M に上げて精度を拾う手もある。このあたりは「どのファイルを読ませるか」「どこまで一度に書かせるか」という自分の使い方と相談して決めることになる。

VRAMは「動かす」壁ではなくなった

去年このテーマを書いたとき、私は「8GB だと長いコンテキストで KVキャッシュが溢れる」のを壁だと考えていた。コンテキストを伸ばすほど KVキャッシュが膨らみ、モデル本体と足して VRAM を食い尽くす、と。

2026年、その心配はかなり薄れた。理由は Qwen3.5 のアーキテクチャにある。Qwen3.5 は Gated DeltaNet (線形アテンション) と Gated Attention (通常のアテンション) を 3:1 で混ぜたハイブリッド構成を採る。通常アテンションの層だけがコンテキスト長に比例する KVキャッシュを持ち、線形アテンションの層は固定サイズの状態しか持たない。つまり層の約4分の3は、コンテキストを伸ばしても VRAM が増えない。

結果として、Qwen3.5-9B は Q4_K_M (約 5.7GB) で 32K コンテキストを張っても、合計 7GB 弱に収まる。8GB の内側だ。去年「長文コンテキストで詰む」と書いた壁は、ハイブリッドアテンションの普及で大きく崩れた。

# Qwen3.5-9B を 8GB で、32Kコンテキストで動かす
llama-server -m qwen3.5-9b-q4_k_m.gguf \
  -ngl 99 -c 32768 -fa --port 8080
# 合計 7GB 弱、8GBに収まる

「8GB だから動かせない」は、2026年にはもう正しくない。動く。問題はその先にある。

では Claude Code との差はどこへ行ったのか

8GB で現行モデルが動き、補完も生成も実用。なのに Claude Code の代わりにならない。差はどこに移ったのか。

答えは agentic coding — 複数ファイルを横断し、ツールを呼び、テストを回し、失敗から自分で立て直す、あの一連の能力だ。そして 2026年、この能力を本気で担うモデルは、はっきり大型化した。

Qwen3-Coder-Next (80B-A3B): SWE-Agent スキャフォールドで SWE-bench Verified 70%超。エージェント特化の学習を大規模に積んでいる。
Qwen3.6-27B (dense) / Qwen3.6-35B-A3B: 「agentic coding」を看板に掲げる現行コーダー系。動かすなら 16〜24GB 級の VRAM が要る。

agentic coding を看板にするモデルは、軒並み 27B 以上だ。8GB の 9B はこの土俵に立っていない。Qwen3.5-9B 自身もツール呼び出しや agentic タスクを一応こなすし、Qwen は Claude Code 連携の例も出している。だが「一応こなす」と「Claude Code を置き換える」の間には、はっきり層がある。

なぜ agentic だけが大型化を要求するのか。補完や単発生成は、文脈から次のパターンを補間する仕事で、1ターンで閉じる。対して agentic coding は、状態を持ち越す仕事だ。「テストが落ちた → 原因はこのファイル → ここを直す → もう一度回す」を何ターンも、最初の方針を見失わずに積み上げる。1ターンの正しさを多ターンの一貫性に変換する能力 — これがモデル規模と agentic 特化学習に強く依存する。9B が単発のコード生成で 65.6 を取れても、10ターン先まで計画を保持し続けられるかは別問題で、ここで小型モデルは崩れやすい。Qwen3-Coder-Next が「エージェントのターン数をスケールさせて長期タスクを解く」と説明し、そのために 80B 規模を積んでいるのは、この多ターン一貫性のコストを物語っている。

去年の壁は「8GB にモデルが載らない」だった。今年の壁は「載るサイズのモデルが、エージェントの本戦に出ていない」に変わった。エージェントの本戦は 16〜24GB の階層へ引っ越した。

「アシスタント」と「エージェント」は2026年に別物になった

ここを混同すると判断を誤る。2026年、ローカルLLMの用途は2層に割れている。

アシスタント層 (8GB / Qwen3.5-9B で届く): 補完、関数生成、リファクタの下書き、エラー解説、軽いツール呼び出し。人間が運転席に座り、モデルは助手席。1ファイル〜数ファイルの範囲で、人間がレビューする前提なら、9B は十分戦力になる。

エージェント層 (16〜24GB+ / Claude Code・Qwen3-Coder-Next が担う): issue を渡したら複数ファイルを自分で読み、修正し、テストを回し、落ちたら直す。人間は監督席。長い計画と多ターンの一貫性が要る。ここは 27B 以上、あるいは API の世界だ。

8GB の 9B を「弱いエージェント」として使おうとすると失望する。だが「強いアシスタント」として使えば、その評価は逆転する。同じモデルでも、どちらの層の道具として見るかで結論が変わる。

8GBの戦い方 — アシスタント層を取り切る

では具体的に、どう「取り切る」か。2026年5月時点の、個人スケールの戦い方はこうなる。

補完・生成はローカルに全振りする。 Qwen3.5-9B をローカルに常駐させ、補完・関数生成・コード説明・エラー解説を全部こちらに寄せる。月額もレイテンシもほぼゼロで、9B の実力なら実用に足りる。ここを API から剥がし切ること自体が「取り切る」の中身だ。1日数百〜数千回叩く補完を無料化できる効果は小さくない。

「狭い自動化」はアシスタント層の延長として取り込む。 スコープを「1ファイル完結」「ツールは read/edit/test の3つ」まで絞った定型タスクなら、9B でもループは回る。これを『Claude Code の小型版』と呼ぶと期待を見誤るが、『アシスタントに定型作業まで任せた』と捉えれば、これは取り切るべき自分の陣地だ。9B の長コンテキストが安いぶん、ここは去年より広げやすい。

エージェント本戦は、潔く API か大きい箱に出す。 複数ファイルにまたがる自律的な修正は Claude Code など API に投げる。ローカルで完結させたいなら 8GB を諦めて 16〜24GB 級へ上げ、Qwen3.6-35B-A3B 級を狙う。これは身も蓋もないが、勝てない勝負で粘らないことも戦略のうちだ。タスクの種類で線を引く — 去年書いた「API と Local の使い分け」の 2026年版は、この「線の引き直し」に尽きる。

残った疑問

正直な留保をひとつ書いておく。8GB の立ち位置は「進歩しているのに、追いつけない」形をしている。Qwen3.5-9B は1年前の 8GB モデルより明らかに賢くなった。にもかかわらず Claude Code に追いつかないのは、8GB が良くなる速度より、「コーディングエージェント」と呼ばれるものの要求水準が上がる速度のほうが速いからだ。ゴールポストは動き続けている。

だが、動くゴールポストを追いかけるのは、定義からして負け続ける戦い方だ。追いつくのを待つのも、8GB で劣化エージェントを組んで満足するのも、どちらも筋が悪い。2026年の答えは、待つことでも真似ることでもなく、いま 8GB で確実に勝てる場所 — アシスタント層 — を取り切ることにある。Qwen3.5-9B はそこでなら、API に課金する前の戦力として十分に立つ。

開いたままの問いは、8GB にいつか agentic 級が降りてくるのか、それとも agentic は構造的に大型モデルの仕事なのか、だ。ハイブリッドアテンションが KVキャッシュの壁を崩したように、「小型モデルでの長期計画」を崩す何かが出れば、この線引きは動く。それが出るまでは — あるいは出ないとしても — 私は 8GB を、迷わずアシスタントとして使い倒すほうに賭ける。それが、いま手元のハードで勝てる賭けだ。