ローカルLLMでエージェント・コーディング活用ガイド 10選
自分用メモとして書きました。ローカルLLMをAider/Roo Code/OpenCodeなどのコーディングエージェントで使う際のノウハウ集。
1. Aider / Roo Code / OpenCode — ローカルモデル対応コーディングエージェントの選び方
ローカルLLMでエージェント・コーディングをやるなら、現実的な選択肢はこの3つ。
Aiderはもっとも成熟しており、ローカルモデルとの互換性が高い。--model ollama/model-nameや--model openai/model-nameでOpenAI互換APIを指定できるので、llama.cppやvLLMのサーバーに直接接続可能。diff形式の出力を要求するため、モデルの指示追従能力が重要になる。
Roo Code（旧Cline fork）はVS Code拡張で、GUIベースで使いやすい。OpenAI互換APIエンドポイントを設定すればローカルモデルが使える。ただしtool callingに依存する部分があり、モデル側のtool calling精度が結果を左右する。
OpenCodeはターミナルベースの新興ツールで、軽量かつカスタマイズ性が高い。設定ファイルでローカルエンドポイントを指定する形。まだ発展途上だが、Aiderより設定がシンプルという声もある。
いずれもOpenAI互換APIを喋れるローカル推論サーバーが前提。まずはAiderから試すのが無難。
⚠️ この記事の情報は2026年3月時点のものです。 AI/LLM分野は変化が極めて速いため、モデル名・推奨設定・ベンチマーク値などは記事作成時点から変わっている可能性があります。最新情報は各公式ドキュメント等で確認してください。
2. Qwen3.5-27B がコーディング用途のスイートスポット
24GB VRAM（RTX 3090/4090）でエージェント・コーディングをやるなら、Qwen3.5-27Bの4-bit量子化（Q4_K_M） が現時点での最適解。コミュニティでも「coding sweet spot」として頻繁に言及されている。
理由はシンプルで、コード生成品質・指示追従能力・VRAM消費のバランスが最も良い。Aiderのベンチマークでも、ローカルモデルの中ではトップクラスのスコアを出している。diff形式の出力やtool callingへの対応も比較的安定している。
DeepSeek-Coder-V3やCodestral系も候補に挙がるが、27Bクラスのサイズで総合力を見るとQwen3.5-27Bに軍配が上がるという意見が多い。特にエージェント用途（ファイル編集、コマンド実行、マルチステップ推論）での安定性が評価されている。
48GB以上のVRAMがあるなら72Bクラスも検討できるが、速度とのトレードオフを考えると27Bで十分というのが大方の意見。
3. Thinking vs Non-Thinking — コーディングではThinkingモード + temp=0.6
Qwen3.5系やDeepSeek系でサポートされている「Thinkingモード」（内部でChain-of-Thoughtを展開する機能）は、コーディングタスクで明確に効果がある。
特にエージェント・コーディングでは、モデルが「このファイルのどこを変更すべきか」「変更の影響範囲はどこか」といった推論ステップを踏む必要があるため、Thinkingモードの恩恵が大きい。Non-Thinkingモードだと単純なコード補完は速いが、マルチファイル編集やリファクタリングで判断ミスが増える。
推奨設定はtemperature=0.6。Thinkingモードではtop_pとtemperatureの設定が出力品質に大きく影響し、temp=0.6がコーディングタスクで最も安定するという報告が複数ある。temp=0だと多様性がなさすぎてループに陥りやすく、temp=1.0だと不安定になる。
llama.cppで設定する場合は--temp 0.6、vLLMならtemperature=0.6をAPIリクエストに含める。Aiderは--model-settingsで指定可能。
4. Tool Calling の信頼性問題 — ローカルモデル最大の壁
エージェント・コーディングで最もハマるのがtool calling（関数呼び出し）の信頼性。Claude/GPTなどのAPI提供モデルはtool callingが安定しているが、ローカルモデルでは出力フォーマットが崩れる、引数が欠落する、存在しないtoolを呼ぶ、といった問題が頻発する。
対策として有効なのは以下の3つ：
- tool callingに強いモデルを選ぶ：Qwen3.5系はtool calling対応が比較的まとも。Llama系はtool callingが弱い傾向がある
-
推論バックエンドの設定を詰める：llama.cppの
--jinjaフラグでチャットテンプレートを正しく適用する。テンプレートのミスマッチがtool calling崩壊の最大要因 - tool callingを使わないワークフローを選ぶ：Aiderのdiff形式はtool callingではなくテキスト出力ベースなので、tool calling品質に依存しない。Roo Codeよりこの点でAiderが有利
「tool callingが壊れるならAiderに逃げろ」というのは割と正しいアドバイス。
5. llama.cpp vs vLLM — エージェント・コーディング用途での比較
ローカル推論バックエンドの二大選択肢。エージェント・コーディング用途での使い分けはこう：
llama.cpp（llama-server）
- CPU+GPUのハイブリッド推論ができるため、VRAMが足りないモデルでも動かせる
- GGUFフォーマット対応。Hugging Faceに大量の量子化済みモデルがある
-
--jinjaフラグでチャットテンプレートを正しく適用すればtool callingも動く - シングルユーザー用途なら十分な速度
- 設定項目が多く、最適化に知識が要る
vLLM
- GPUフル活用で高速。特にlong contextでの推論速度が優位
- PagedAttentionによる効率的なメモリ管理
- OpenAI互換APIサーバーが標準装備で、tool callingの実装もこなれている
- ただしGPUメモリに全モデルが載る必要がある（CPU offloadは限定的）
- セットアップがllama.cppより重い（CUDA依存）
結論として、24GB GPU 1枚でQ4_K_Mの27Bモデルを動かすなら、llama.cppの方が手軽。48GB以上のVRAMがあるか、複数GPUがあるならvLLMの速度メリットが活きる。エージェント・コーディングは長いコンテキストを何度もやり取りするので、推論速度の差が体感に直結する。
6. コンテキストウィンドウ管理 — エージェントの最大の敵
エージェント・コーディングではコンテキストウィンドウが急速に消費される。ファイルの内容、ツール呼び出しの結果、エラーメッセージ、修正履歴……これらが積み重なり、あっという間にコンテキスト上限に達する。
ローカルモデルは実質的なコンテキスト品質が公称値より短い。Qwen3.5-27Bは公称128Kトークンだが、コーディングタスクで品質を維持できるのは体感で16K〜32K程度。それ以上になると、ファイルの冒頭の指示を忘れたり、同じ変更を繰り返したりする。
対策：
- タスクを小さく分割する。1回のセッションで1つの機能変更に絞る
-
Aiderの
/clearコマンドでコンテキストをリセットしてから次のタスクへ -
必要なファイルだけをコンテキストに含める。Aiderの
/addで最小限のファイルを指定 - 要約・圧縮機能を活用する。一部のツールはコンテキストの自動要約機能を持つ
「ローカルモデルでのエージェント・コーディングは短距離走の連続」と思った方がいい。長いセッションは品質劣化の元。
7. Claude Code の代替としてのローカルLLM構成
Claude Codeは強力だが、APIコストが高い。月に数百ドル使うユーザーもいる。ローカルLLMで同等のワークフローを構築するアプローチが注目されている。
現実的な構成パターン：
- Aider + Qwen3.5-27B（フル・ローカル）：コスト0で動くが、Claude Codeの70〜80%程度の品質という評価。単純な機能追加やバグ修正なら十分実用的
-
ルーティング構成（ローカル + API）：簡単なタスクはローカルモデルで処理し、難しいタスクだけClaude APIに投げる。Aiderは
--model切り替えが容易なので実装しやすい - Roo Code + ローカルモデル：VS Code内で完結する。Claude Codeと同じ「ファイル編集 + コマンド実行」のワークフローが可能
正直なところ、複雑なリファクタリングやアーキテクチャ設計ではまだAPIモデルとの差が大きい。ローカルLLMが得意なのは、スコープが明確な変更（関数追加、バグ修正、テスト作成）。使い分けが現実的。
8. Qwen3.5-9B でエージェント・コーディングはどこまでできるか
VRAMが16GB以下（RTX 4060 Ti 16GBなど）の場合、27Bモデルは厳しい。そこでQwen3.5-9Bが候補になる。
結論から言うと、単機能の変更やテスト作成なら使える。マルチファイル編集やリファクタリングは厳しい。
9BモデルでAiderを使った場合の体感：
- 関数の追加・修正：実用的。指示が明確ならほぼ正しいコードを生成する
- バグ修正：条件付きで実用的。エラーメッセージを含めてコンテキストに入れれば対応できる
- リファクタリング：非推奨。複数ファイルにまたがる変更で整合性が崩れやすい
- diff形式の出力：不安定。フォーマットを守れずAiderのパースが失敗することがある
9Bモデルを使うなら、Thinkingモードを有効にしてtemp=0.6で使うこと。Non-Thinkingだとtool callingやdiff出力の精度がさらに落ちる。また量子化はQ6_K以上を推奨。9Bモデルは量子化の影響を受けやすい。
9. よくある落とし穴 — モデルがファイルを削除する問題
ローカルLLMでエージェント・コーディングを始めると、ほぼ確実にぶつかるのが 「モデルが勝手にファイルを削除する」問題。
典型的なパターン：
- リファクタリングを依頼したら、古いファイルを削除して新しいファイルに統合しようとする
- 「不要なコード」と判断したファイルを消す
- テストの修正を依頼したら、失敗するテストケースごと削除する
これはローカルモデルに限らずLLM全般の傾向だが、ローカルモデルでは指示追従が弱い分、発生頻度が高い。
必須の対策：
-
Gitで必ずコミットしてからエージェントを実行する。何が起きても
git checkoutで戻せる -
Aiderの
--auto-commitsを有効にする。変更ごとに自動コミットされるので、粒度細かく戻せる - 変更前にdiffを確認する習慣をつける。Aiderは変更前にdiffを表示するので、削除を含む変更は拒否できる
-
「ファイルを削除するな」と明示的に指示する。システムプロンプトやAiderの設定ファイル（
.aider.conf.yml）に追記
「LLMは作るのは得意だが、消すのも得意すぎる」という教訓。Gitなしでエージェント・コーディングをやるのは自殺行為。
10. IDE統合 — VS Code / Neovim / JetBrainsでローカルモデルを使う
エージェント・コーディングはターミナルだけでなく、IDE内で完結させた方が効率が良い場合も多い。
VS Code
- Roo Code（旧Cline fork）：最も機能が充実。ファイル編集、ターミナル操作、ブラウザ操作まで対応。OpenAI互換APIでローカルモデル接続
- Continue：コード補完 + チャットのハイブリッド。ローカルモデル対応が充実しており、Ollama/llama.cpp/vLLMすべて接続可能
- Copilot互換設定：llama.cppサーバーをCopilotのエンドポイントとして設定するハック。補完専用だがレイテンシが低い
Neovim
- avante.nvim：VS CodeのCopilot Chat相当の機能をNeovimで実現。OpenAI互換APIでローカル接続可能
- codecompanion.nvim：チャット + インラインアシスト。Ollama直接接続対応
JetBrains
- Continue（JetBrains版）：VS Code版と同等の機能。ローカルモデルサポートも同じ
- JetBrains純正のAI Assistantはローカルモデル非対応なので注意
どのIDEでも共通するのは、「OpenAI互換APIサーバーを立てておけばだいたい繋がる」ということ。llama.cppの--host 0.0.0.0 --port 8080で起動しておけば、ほぼすべてのツールから接続できる。