RTX 4060 8GBでローカルAIコーディングエージェントを動かす — Ollama + オープンソースLLM実践ベンチマーク

RTX 4060 8GBでローカルAIコーディングエージェントを動かす — Ollama + オープンソースLLM実践ベンチマーク

Ollama + オープンソースLLM実践ベンチマーク — セキュリティ分析、ブログ作成、ツール呼び出しまで

緒論

クラウドAIサービスの費用が負担になるとき、ローカルGPUでコーディングエージェントを動かせたらどうだろうか？RTX 4060 8GBという最も一般的なミドルレンジGPUで、オープンソースLLM 3種類を実戦タスクでテストしました。Ollama v0.30.6を使用し、Qwen 3.5 4B、Qwen 3.6 35B、Gemma4 12Bを同一条件で比較しました。

結論から言うと — コーディング補助は可能。文章作成は不可能。 そして、その境界線は思ったよりも明確です。

1. テスト環境

テストモデル3種類：

Qwen 3.6は35Bモデルですが、MoE構造のためアクティブパラメータは3Bレベルです。8GB VRAMに合わせるには、2-bitの極限量子化が必要でした。

2. セキュリティ脆弱性分析 — コーディングは可能

Express.jsのコードに5つのセキュリティ脆弱性を意図的に挿入し、各モデルに「すべて見つけて修正コードを提示せよ」と要求しました。

SQLインジェクション2件、パス・トラバーサル、トークン偽造は、3モデルすべてが正確に検出しました。攻撃シナリオ(' OR '1'='1、../../etc/passwd)も具体的で、修正コード(パラメータバインディング、JWT変換、path.resolve検証)も実戦投入可能なレベルでした。

ただし、「トークンなしでもnext()が呼び出され、認証なしで通過する」という5番目の脆弱性は、3モデルすべてが見落としました。 これはコードの流れ全体を追跡して初めて見える微妙なバグであり、12B以下のモデルの限界を示しています。

3. Thinkingモード — スマートだが欲張りすぎる

Qwen 3.5と3.6は推論モデルであるため、すべての応答で「thinking」プロセスを最初に生成します。これが問題です。

コンテキスト4096トークンでは、モデルはthinkingばかりで実際の回答を出力できずに停止してしまいました。8192に増やすと解消され、16384では短いコーディング問題(O(n²)→O(n)最適化)を1.4秒で77トークンで正確に解きました。

核心となる公式はこうです：

• Thinkingに十分な紙(コンテキスト)を与えれば、正確で速い
• 紙が不足すると、考えるばかりで時間が過ぎてしまう

/no_thinkタグでthinkingをオフにしようとしましたが、GGUF環境では機能しませんでした。Ollama CLIの--nothinkフラグも空の応答を返すだけでした。

4. ブログ作成 — ここが壁

同じモデルたちに今日のベンチマークデータを与え、韓国語のブログ記事を書いてもらうよう依頼しました。結果は悲惨なものでした。

• Gemma4: 韓国語のプロンプトに対し中国語で応答。内容もテストデータではなく一般的なOllamaガイド
• Qwen 3.6: 韓国語で書いたもののExpress.jsコードチュートリアルに話題が逸脱
• Qwen 3.5: やはり中国語。しかも同じ内容を繰り返し出力するループに陥る

プロンプトを強化してみました。「必ず韓国語のみで」、「以下のデータをそのまま使用せよ」、「存在しない情報の追加禁止」。結果は多少改善されましたが、本質的には同じでした。Qwen 3.6が392トークンのメモを書き出したのが最善でした。

コーディングで4/5の正答率だったモデルが、なぜブログ作成で全滅するのか？ 2つの原因が考えられます：

1. 2-bit量子化により言語識別能力が低下した。 韓国語と中国語のトークン確率が似てしまい、混同する。
2. 「正解のある問題」と「創作」は異なる能力である。 コード分析はパターンマッチングに近いが、与えられたデータを読み込み、構造化された文章にまとめることは、はるかに高い指示遵守能力を要求する。

5. ツール呼び出し — Gemma4のみ可能

Ollamaモデルのcapabilitiesフィールドを確認すると：

• Gemma4 12B: completion, tools, thinking, vision
• Qwen 3.5/3.6: completionのみ

Gemma4に「YAML検証Pythonスクリプトを作成して実行せよ」と要求すると、96秒で58行のスクリプトを生成し、run_pythonのtool_callまで成功しました。テストフィクスチャ4つを自動生成し、yaml.safe_loadでパース検証まで行う完成度でした。

ただし、これはシングルターンでの成功です。実行 → エラー → 修正 → 再実行のマルチターンエージェントループは、コンテキストの蓄積により8192トークンを圧迫することになり、安定した運用は困難です。

6. 結論 — インターンは可能、シニアは不可能

「ファイル一つ、関数一つ、明確な指示」 — この範囲内であれば、ローカルLLMはコストゼロのコーディングインターンとして利用できます。上位エージェント(Opus, Sonnet)がタスクを細かく分割して投げ、結果を検証する構造であれば、実戦投入も可能です。

ただし、現在の限界はGPUではなく量子化です。8GB VRAMに35Bを詰め込むには2-bitまで削る必要があり、その瞬間に繰り返し崩壊、言語混同、創作不能が伴います。同じモデルが24GB GPUで4-bitで動作するなら、今日失敗したブログ作成も可能になるかもしれません。

RTX 4060はPoCを検証するのに十分でした。頭脳は機能するが体がついてこない — それを定量的に証明した一日でした。