エージェント型コーディングにローカルLLMを活用する

 (blog.alexewerlof.com)
10 ポイント 投稿者 GN⁺ 3 시간 전 | 3件のコメント | WhatsAppで共有
  • クラウドのフラッグシップモデルが急速に値上がりする中、コスト負担なくコーディング作業を続けられるローカルモデル活用法を整理
  • ローカルモデルはSOTAモデルの性能には及ばないが、価格対性能と**決定論的ハーネス(deterministic harness)**の強化によって品質を最大6倍まで引き上げられる
  • コーディング用途ではGemma 4が一般作業とコード生成のバランスに優れ、Tools Use・Vision・Reasoning対応によりVS Code連携に適している
  • LM Studioでモデルサーバーを立ち上げ、VS Code Copilot・Piのカスタムエンドポイントへ接続する一連の設定手順を提供
  • ハードウェアが不足する場合はOpenRouterの無料モデルを代替として利用でき、ローカルモデルはオフライン性・プライバシー面で依然優位

価格上昇の背景

  • GitHub Copilotはクレジットモデルから従量課金へ移行し、従来の無料モデルももはや無料ではなくなった
  • GitHubはトークリセラーであるため、値上げの影響をより強く感じやすい。フラッグシップモデルは、性能向上の速度が価格上昇の速度に追いつかないままリリースされている
    • Google Flash 3.5はFlash 2.5比で3倍高い
    • GPT 5.5はGPT 5比で3倍高い
    • Claudeはすでに高すぎたため、むしろ価格が引き下げられた

ローカルモデルの現実と強み

  • ローカルモデルはClaude・GPT・GeminiのようなSOTAモデルの性能には及ばないが、いくつかの**ニュアンス(nuance)**がある
    • 価格性能比: クラウドモデルは、性能向上に対してコストが指数関数的に増える
    • 決定論的ハーネス: より良いツーリングや指示によって、弱いモデルの品質を最大6倍まで改善できる
    • ベンチマークの罠: モデルを単一の数値に換算するのは難しく、各AIラボは自社に有利なベンチマークに注力するため、自分のワークロードで直接評価する必要がある
    • 地政学的効果: 米国のラボが無料公開するものは最高水準ではない。gpt-oss-20bは古すぎ、Anthropicはオープンウェイトを公開していない。Gemma 4だけが唯一まともに検討できるモデルであり、Qwen・Kimi・GLMなど中国ラボの有能なモデル公開に注目すべき
  • 「brain rot」現象という観点では、弱いモデルはユーザーの介入がより必要なため、脳の健康に良い
    • 自転車に乗るように遅いが、健康には良い。知的労働では「遅いことが速い(slow is fast)」
    • 目標は思考を機械に丸投げする自動化の最大化ではない。短期的な速さのために将来の**自分の価値(relevance)**を犠牲にしてはいけない
    • 弱いモデルを扱う技法は大きなモデルにも適用できる。弱いモデルを扱うのはハードモードで遊ぶようなもので、身につければ大きな道具をより効果的に使える

モデル選定 — Gemma 4

  • コーディング用途では中国系モデルがHuggingfaceリーダーボード上位を占めており、Qwen・DeepSeek・Kimi・Llama・Gemmaなどがある
  • Gemma 4は複数バージョンで構成される
    • E2B: 「E」はedgeを意味する。2Bパラメータで大半のハードウェアで動作するが、幻覚やタスク未完了のリスクが高い
    • E4B: E2Bの2倍サイズ。ダウンロードや設定の負担が軽く、入門用として推奨
    • 12B: デコーダなしで画像をネイティブに理解し、フロントエンドやビジュアルコーディングでより高速。音声もネイティブ対応だが、コーディングワークロードでは重要度が低い
    • 26B A4B: 26Bパラメータのうち4Bだけが有効化されるMoE(mixture of experts)アーキテクチャ。E4Bより賢く、8〜12GB VRAMのGPUに適している（著者の推奨モデル）
    • 31B: Google最大のオープンウェイトモデル。MoEではないため大量のVRAMが必要。AMD APUでは速度が1〜2 TPSで実用不能レベル
    • QAT派生版（例: E4B QAT）はメモリ消費を抑えつつ、ほぼ同等の品質を維持する。Unslothが追加最適化を進めている

ローカルモデル実行に必要な構成要素

  • ローカルモデルの実行にはハーネス・モデル・ランタイム・モデルマネージャーが必要
    • ハーネス(Harness): VS Code Copilot、Copilot CLI、Piなど。モデル（確率的要素）の周囲を包む決定論的な構成要素（従来型コード）
    • モデル: 深層ニューラルネットワークの重みファイル。量子化(quantization)（Q8、Q4など）は画像解像度に似た概念で、形式はGGUF・MLXなどに分かれる

  • ランタイム（推論エンジン）

    • Llama.cpp: 最も人気のあるオープンソースランタイムで、GGUF・MLXを読み込める。MetaのLlamaモデルとは無関係で、LM Studioが内部的に使用している
    • MLX: Apple製ランタイム。M1・M2などのMacで使う
    • ONNX Runtime: transformers.jsベースで、WebGPU経由のブラウザ実行やiOS・Androidモバイルも対応
    • vLLM: UC Berkeley発のオープンソースで、主に高性能サーバー向け。設定難易度は高い

  • モデルマネージャー

    • Ollama: ターミナルCLIとして始まり、軽量GUIが追加された。Llama.cppを包むGoラッパー。オープンソース
    • LM Studio: 無料だがオープンソースではない。SDK(Python/TypeScript)とREST APIを提供し、ローカルモデル特有の機能（動的ロードなど）を制御できる
    • Jan: 無料かつオープンソースのLM Studio類似代替だが、機能はやや少ない
    • OpenAI互換API対応が重要機能であり、多くのAIアプリケーションがこの事実上の標準で動作する

LM Studioサーバー設定

  • 「Developer」ボタンからトグルでサーバーを起動。他マシンやコンテナで動かす場合はServe on Local Network、Webアプリからアクセスする場合はEnable CORSを設定
  • LM Studioはリクエスト時点でモデルを読み込むJIT(Just In Time)ローディングを使用する。TTL設定でメモリ保持時間を制御できる
    • コールドスタート(Cold start): モデル未ロード時は初回リクエストに約10〜30秒の追加が必要で、AWS Lambdaのコールドスタートに似ている。**TTFT(Time To First Token)**指標に影響する
    • 短いコンテキストウィンドウ: デフォルト設定ではコンテキストウィンドウがわずか4kのことがあり、手動拡張が必要。VS Code Copilotの大半のモデルは200〜400kを持つ

  • コンテキスト長とメモリ設定

    • コンテキスト長ごとのVRAM要件: 262144（最大） = 25.74GB、4096（デフォルト） = 18.16GB、150000（著者推奨） = 22.45GB
    • コーディング用途ではシステムプロンプトが20〜40kトークンを占めるため、最低100kトークンを読み込める必要がある
    • コンテキストが大きすぎるとトークン生成速度が低下する。ハーネスがコンテキストを自動圧縮する点が最適
    • すべてのモデルレイヤーをGPUで実行するのが理想で、「GPU Offload」スライダーは最大化推奨。CPUレイヤー実行はApple Silicon(UMA)以外ではCPU-GPU間のデータコピーが必要

  • KVキャッシュ量子化のテクニック

    • K Cache Quantization TypeをQ8_0、V Cache Quantization TypeをQ4_0に設定
    • キーを値より高い解像度で維持する方式。この設定によりGPUメモリ要件を標準の28.75GBから22.45GBへ削減できる
    • 設定の保存は必須。保存しないと次回モデル読み込み時にデフォルトへ戻る
    • VS Code Copilotにはカスタムコンテキストウィンドウ要求の概念がなく、LM StudioがREST API呼び出し時に設定を記憶しておく必要がある
  • TPSが10未満だとコーディング用途では耐えがたく、モデル待ちに多くの時間を費やすことになる

Copilotカスタムエンドポイント接続

  • 最新のVS Code（執筆時点で1.122.1）が必要。モデルセレクター → 歯車 → 「Add Models」 → 「Custom Endpoint」の順で追加
    • 名前を付け（例: 「Local LM Studio」）、API Keyを入力（未設定ならEnter）、推論API形式を選ぶ
    • 3種類のAPIのうち、Chat Completionsだけが問題なく動作する
  • JSON設定でurl、maxInputTokens、maxOutputTokensなどを手動指定
    • thinkingオプションを正しく設定する（Gemma 4対応）
    • supportsReasoningEffort配列はモデルごとに異なり、26B版はE4Bより細かな制御に対応
    • 4BはmaxInputTokens 64000/maxOutputTokens 16000、26B MoEは100000/50000を設定
  • 最初のプロンプトではCopilotが巨大なシステムプロンプトとツール定義を送るため、初回の対話に2〜5分の遅延が発生する。モデル読み込み30秒、プロンプト入力処理に約5分
    • セッションごとに1回だけ発生し、LM Studioがプロンプトキャッシュを適用する。Piはシステムプロンプトが小さいためこの問題がない

  • 簡易テストと環境

    • AGENTS.mdやSKILLなしでワンショットプロンプトからスネークゲームを生成し、Gemma 4 26B A4Bの性能を実演
    • 使用環境: Lenovo Thinkpad L16 Gen 2、AMD Ryzen 7 PRO 250 APU、64GB DDR5(5,600MT/s)、Aurora Linux。32GBでも十分と判断

Pi設定

  • ローカルLM Studioサーバー接続が簡単で、contextWindow設定がLM Studioの構成方式によりよく合う
  • baseUrlをhttp://host.containers.internal:1234/v1、apiをopenai-completionsに指定
    • 4BはcontextWindow 64000/maxTokens 16000、26B MoEは150000/50000に設定し、thinkingLevelMapの対応付けを指定

ローカルモデルの長所と短所

  • 長所: オフライン動作、高いプライバシー、ハードウェア・ワークフロー・モデル・設定次第で高速応答
  • 短所
    • オープンウェイトモデルはフラッグシップのクローズドモデルほど賢くないが、適切なガードレール（lint・テスト・AGENTS.md）を備えたハーネスによってコーディング精度を大きく高められる
    • 同一マシンでLLMを動かすと、ハードウェア負荷による速度低下が発生する
    • コールドスタート、初回プロンプト入力処理（キャッシュミス）、高い初期ハードウェア投資コスト
  • LM Studioに慣れればGUIなしでLlama.cppを直接使うことも可能。ほとんどのハーネスはカスタムエンドポイントをサポートしており、ローカルLLMと連携できる

OpenRouter無料モデルの代替案

  • OpenRouterは、単一のエンドポイント・アカウントで数百のモデルを公開する統合API・ルーティングサービス
  • Copilot・Zed・PiはいずれもOpenRouterをネイティブサポートしており、APIトークンを発行するだけで接続できる
    • コスト暴走を防ぐため、月1ドル上限のカスタムガードレールを作成し、無料モデルだけを許可リストに追加
    • 新しいAPIキー作成時はmax creditを0に設定することを推奨
  • 短所: プロンプトやデータが学習に使われる可能性がある（ZDR設定あり）、インターネット接続が必要、OpenRouterが無料モデル提供を中止する可能性がある
  • 長所: ローカルでのダウンロードや設定が不要で、利用中もコンピュータが重くならない

  • 2026-06-09 更新

    • Deepseek V4 Proを採用。Claude Opus 4.8にほぼ匹敵する性能で、5倍のコンテキストウィンドウ、価格は約17〜86分の1
    • PiとOpenRouterの価格に約3倍の差があったが、これはOpenRouterがより高価なエンドポイント（GMICloud）へリクエストを送っていたため
    • Deepseekのアカウントを直接作成して複雑な作業に活用。単純作業・動作理解・プライバシー重視の場面では、ローカルモデルが依然として第一候補

関連記事

3件のコメント

 
click 3 시간 전

結局、ローカルモデルを使っていたものの、deepseek v4 pro に落ち着いたという結論になりましたね。
作業のたびに毎回モデルを切り替えて使うのも簡単ではないので、単純な作業にはローカルを使うという方針も難しいと感じました
 
kirinonakar 1 시간 전

あえて local でなくても、opencode、ollama、cursor など安価なサブスクリプションの代替手段は多くあります。
 
kurthong 2 시간 전

大規模LLM時代に合わせて、私はプラグインを作って使っています。GN SHOWでも一度紹介したことがありますが、このように自分に合うように作って使うのも一つの方法だと思います。

https://github.com/hang-in/tunaLlama