ローカルLLMでバイブコーディングはどこまで実用的か？ VRAM 16GB環境での検証

Page content

クレジット変更とローカルLLMへの回帰の動機

2026年6月1日から、GitHub Copilotのクレジットの扱いが大きく変更された。

この仕様変更がどのような影響をもたらすかというと、いわゆる「バイブコーディング」スタイルでアプリ開発を行っている開発者にとって、かなり死活問題になるレベルの変更だ。実際にこの新しいクレジットルールのもとでアプリ開発を進めてみたところ、非常にシンプルな小規模アプリを開発しているだけでも、たった1日でクレジット枠をすべて使いきってしまうことが判った。

しかも、クレジットを使い切った時点でアプリケーションが完成して動く状態になっていればまだ納得もいくが、実際にはアプリは完成していない。途中で力尽きて作業が中断されてしまうという、非常に消化不良な状況に陥る。

クラウドサービスのクレジット枠を気にしながら、残量を計算しつつ恐る恐るコーディングエージェントを使うというのは、バイブコーディング本来の「勢いに任せてアイデアを形にする」楽しさや快適さを大きく損なってしまう。それならば、いっそのことクラウドサービスに一切頼らずに、自分の手元のPCで動作する「ローカルLLM」を使ってどこまでバイブコーディングができるのか、その実用性を調べてみようと思い立った。

具体的には、「VRAM 16GBで動くローカルLLMでバイブコーディングするなら、どのモデルが一番マシなのか」という限界点と実用的なモデルの絞り込みを検証した。

実験の準備とお題の選定

今回の検証にあたり、ローカルLLMの性能を測るためのお題として 「ターミナル上（CUI）で動く簡易テトリス」 をPythonで開発することにした。

通常、AIモデルのコーディング能力テストでは、競技プログラミングのような「標準入力を受け取って特定のアルゴリズムで処理して標準出力する」といった一方向の処理が使われることが多い。しかし、バイブコーディングの快適性やエージェントの柔軟性を評価するには、それでは不十分だ。端末上でリアルタイムにキー入力を受け付け、描画を更新し、ゲームの状態を管理し続けるといったインタラクティブな処理が必要なプログラムのほうが、はるかにコード設計やエラーハンドリングの難易度が高く、エージェントの実力を測るのに適している。

開発環境のセットアップとして、 Pythonのパッケージおよび環境管理には uv を使用し、セットアップ済みの状態で AI に処理を依頼している。

今回検証したAIモデルのラインナップは以下の通りである。

  • Gemma4-12B
  • QWen3.6-27B-Q3
  • QWen3.5-27B-Q4
  • QWen3.5-27B-Q3
  • QWen3.5-9B-Q8
  • QWen2.5-Coder-14B

Qwen ばっかりなのは、あまり気にしないで欲しい。

また、これらのモデルと組み合わせて使用するAIエージェントツールとして、以下の3つを用意した。

  • aider
  • opencode
  • cline

なお、時間の都合もあり、これらのモデルとエージェントのすべての組み合わせパターンを網羅して確認したわけではない。

特にAIエージェントに関しては、ほぼ上から順に試していったのだが、結果としてほとんど cline ばかりを使うことになった。今回の検証目的である「インタラクティブにコードを修正しながら対話的に進めるバイブコーディング」という用途において、aider と opencode の2つは、作業の進め方やインターフェースの思想があまり向いていないように感じられたためだ。その結果、本検証の大部分は cline と各モデルの組み合わせで行っている。

実験方法

そこそこ実用的でストレスの少ないバイブコーディング環境を目指すため、今回の実験では「AIの重みとKVキャッシュはすべてGPUのVRAM上に載せられること」を前提とした。

CPUに一部の処理をオフロードすると、トークン生成速度が極端に低下し、バイブコーディングのテンポが完全に崩れてしまうからだ。この「VRAM上にすべて載せる」という前提を置いた結果、選択するモデルによっては、動作させるためにコンテキストウィンドウサイズをかなり厳しく制限せざるを得なくなった。

プロンプトの与え方としては、最初に「端末上で動くテトリスをPythonで作りたい」といった最小限のフワッとした情報だけを指示した。

そこから先は、出力されたコードを実行し、実際の挙動やエラー画面を見せながら「右キーで右に動くようにして」「ラインが揃ったら消えるようにして」というように、細かい仕様を順次追加で与えていく対話的なアプローチをとった。

実験結果とモデルごとの挙動

今回の簡易テトリス開発というお題において、最終的に「まともに動くコード」を完成させられたのは、 QWen3.6-27B-Q3 と QWen3.5-27B-Q3 の2つのモデルだけだった。

ここで「まともに動く」と言っているのは、あくまでテトリスとしての基本的な部分だ。複雑な回転法則（SRS）やホールド機能、スコア計算、ネクスト表示といった細かいルールまでは実装させていない。クリア基準としたのは、「テトリミノ（ブロック）が自動で落下し、左右移動や回転ができ、最下部に到達したら固定され、横1行がすべてブロックで揃ったらそのラインが消去される」という、テトリスを構成するうえで最低限必要となる超基本ルールまでだ。

このレベルの実装であれば、プログラミングを自主的に勉強したことのある人なら、おそらく人生で一度は自力で作ったことがあるのではないかと思えるような、ごく基本的な処理といえる。

しかし、驚くべきことに、これほど基本的な処理であるにもかかわらず、他のモデル（QWen3.5-9B-Q8 や QWen2.5-Coder-14B など）では、さっぱりと完成させることができなかった。

うまくいかないモデルでは、ゲームループのタイマー処理とキー入力待ち処理が衝突してフリーズするコードを生成したり、ブロックの衝突判定に論理的なバグがあってテトリミノが画面外へ突き抜けていったりといった不具合が発生した。それらの問題について、コンソールに出力されたエラーや実際の挙動をプロンプトでフィードバックし、何度も「ここを修正して」と指示を出しても、修正するたびに別の場所が壊れるといったイタチごっこになり、一向に改善する見通しが立たなかった。

意外だったのは、 Gemma4-12B でクリアできなかったことだ。比較的新しく、前評判も高いモデルだったので、この程度の規模ならクリアできるだろうと予想していたのだが、うまく機能しなかった。

また、見事に基本動作をクリアした QWen3.6-27B-Q3 および QWen3.5-27B-Q3 だが、これらを使って開発している最中も、決してストレスフリーで快適に進められたわけではない。ローカル環境での推論処理にはそれなりの時間がかかり、指示を出すたびに応答をかなりの時間待たされることになった。

今回の検証は、たった1ファイルの非常に小規模なコードベースが対象だ。

それにもかかわらず、これほど待たされるとなると、実務で扱うような、多数のファイルが相互に関連し合う現実の複雑なコードベースでローカルLLMによるバイブコーディングを行うのは、現時点ではまず現実的とは言えないだろう。

パラメータサイズとVRAM容量の壁

今回の検証で最も驚かされたのは、QWen3.6-27B や QWen3.5-27B といった27Bクラスのモデルが、VRAM 16GBの制約から「Q3（3ビット量子化）」というかなり極端な量子化モデルを使用していたにもかかわらず、他のパラメータサイズが小さいモデルで、量子化の緩いモデル（Q8量子化の9Bなど）よりも圧倒的に優れた結果を残した点だ。

これまでの経験から量子化のビット数を3ビット程度まで下げると、大幅に性能が低下するとイメージだった。しかし、それでもなお、9Bや12B、14Bといった元のパラメータ数が小さいモデルよりも安定して動作するコードを生成できた。

この結果から導き出される結論は明白だ。

やはり LLMは量子化精度よりも、基礎となるパラメータのデカさが何よりも性能に影響する ということだ。賢さの絶対値は、パラメータ数という物理的な規模に大きく依存している。

そうなると、ローカルLLMを個人の開発環境で実用的に動かすにあたって、デスクトップPCのグラフィックボード（dGPU）に搭載されている VRAMのサイズ制約が非常に厳しい壁 として立ちはだかることになる。

現在、AppleのMac（Apple Silicon搭載モデル）や、NVIDIAの DGX SparkやRTX Sparkなどでは、CPUとGPU、そしてシステムRAMが超広帯域のインターフェースで直結された統合メモリ（ユニファイドメモリ）アーキテクチャを採用している。これにより、VRAM容量の制限や帯域不足の問題をクリアし、大容量のLLMを高速に動作させることを可能にしている。

しかし、これらのユニファイドメモリ方式のハードウェアには、大きなデメリットもある。メモリがプロセッサと一体化しているため、後からメモリだけを増設したり、グラフィックボードだけを最新のものに交換したりすることが実質的に不可能であるという点だ。最初に高額な大容量メモリモデルを購入するしかなく、ユーザー側での自由なアップグレードパスが閉ざされてしまう。

自作PCや一般的なデスクトップPCのように、安価なシステムRAM（メインメモリ）を大量に積み、必要に応じてビデオカードを差し替えるというスタイルで、ローカルLLMの高速処理ができないものだろうか。

将来的にシステムRAMの規格が「DDR6」などに進化し、単体の転送速度が向上したとしても、dGPUとの物理的な接続インターフェース（PCIeなど）のボトルネックが改善され、必要な通信帯域が劇的に確保されない限り、一般的なPCパーツの組み合わせでコストパフォーマンス良く実用的なローカルLLM処理を実現するのは難しいのが現状だ。

ハードウェアメーカーには、この接続方式や帯域幅における技術的なブレークスルーをぜひ期待したいところだ。

定量的スコアと実験結果の比較

今回の検証から得られた体感的な結果と、客観的なベンチマークスコアとの整合性を確認するため、AIモデルのパフォーマンス比較サイトである「Artificial Analysis」のデータを確認してみた。

参考にしたのは、コーディング能力を測定する指標（Coding Index）のスコアをまとめている以下のページだ。

このサイトの情報を見ると、以下のような興味深い事実が示されている。

  • Qwen3.6-27B は、パラメータ数がはるかに大きい gpt-oss-120B よりもコーディング能力のスコアが高い。
  • Qwen3.6-27B の Coding Index スコアは「36.5」である。
  • Qwen3.5-27B のスコアは「34.9」である。
  • Qwen3.5-9B のスコアは「25.3」である。

今回の実験で、簡易テトリスという基本動作の実装をクリアできたのは、スコア「34.9」以上のモデル（QWen3.5-27B および QWen3.6-27B）だけであり、スコア「25.3」の Qwen3.5-9B では全く歯が立たなかった。

これらの定量的なベンチマークスコアと、今回の手元での実験結果を照らし合わせると、ひとつの推測が成り立つ。

コーディングエージェントとして破綻せずにバイブコーディングを行うためには、この Artificial Analysis の Coding Index において スコアが最低でも 30 以上は必要である ということだ。

そして、この「スコア30以上」の領域に属しているモデルの顔ぶれを見てみると、Claude 3.5 Sonnet、Claude 4 Sonnet、GPT-5、Gemini 2.5 Pro など、最近まで第一線でクラウド型のコーディングエージェントとして利用されていた、あるいは現在利用されている商用の超高性能AIたちが並んでいる。このラインナップを見ても、実用性の境界線がスコア30付近にあるという認識は、概ね間違っていないだろう。

ローカルLLMバイブコーディングの今後とハードウェアの現実解

今回の検証をまとめると、QWen3.6-27Bクラスの優秀なオープンモデルを、量子化の劣化を抑えた状態（Q4やQ8、あるいはFP16など）で、かつ高速に動かせる環境さえ用意できれば、クラウドサービスに毎月のトークン制限やクレジット消費を怯えることなく、完全ローカルで快適なバイブコーディングを実行することが十分に可能になる、と言える。

では、その環境を一般個人が構築するための、現状における「最も現実的なハードウェアの解」は何になるだろうか。

結論から言えば、それは RTX 5090 を導入することだ。

いやいや、流石にグラフィックボード1枚の値段としては高すぎだから。。。

とても気軽に「ローカルでバイブコーディングしたいから買おう」と言えるような金額ではない。

もう少しコストパフォーマンスを重視し、用途を「LLMの推論処理」に限定するならば、別の選択肢として AMD Radeon AI PRO R9700 が挙がるかもしれない。

このカードは、NVIDIAのRTX 5090と比較した場合、価格および消費電力がおおむね半分程度で済む。その代わり、純粋な演算性能も3分の1程度に低下する。

画像生成や動画編集、一般的なディープラーニングの学習といった「LLM以外のAI利用」を目的にする場合、ソフトウェア側の対応状況も含めてRadeonを選択するのはまだまだハードルが高いというのが実情だ。しかし、今回のターゲットである「ローカルでテキストベースのLLM（Qwenなど）を動かす」という目的に特化して割り切るのであれば、VRAM容量の確保という点も含め、ほぼ問題なく動くレベルの選択肢にはなり得る。

知らんけど。

いずれにせよ、クラウドのクレジット制限に縛られない完全ローカルな開発環境は非常に魅力的だ。今後のハードウェアの低価格化と、さらなる軽量・高性能モデルの登場に期待しつつ、手元のVRAMでやりくりする工夫を続けていきたい。