【完全ガイド】ローカルLLMでバイブコーディング入門 ～使い放題AIコーディングの始め方とコツ ZooCode(旧RooCode)使用～

こんにちはRcatです。
最近ローカルバイブコーディングを進めておりまして、その結果きちんと設定を考えて使いこなせれば、非常に実用的な域に達していると考えています。
今回は環境構築から設定、使用時のコツなど今まで試行錯誤してきたすべてを公開しようと思います。

はじめに

利用規約

情報や作品の活用時は事前に利用規約をご確認ください。

コメントについて

利用規約のガイドラインを確認の上コメントしてください。
則っていないコメントは削除します。

概要

バイブコーディングとは

バイブコーディングは、AI支援ツールを活用してプログラミングを行う手法の一種です。開発者は自然言語で意図や要件を記述し、AIがそれを実現するコードを生成します。「雰囲気」や「直感」を信じてAIに任せる部分が多いことが特徴であり、特にプロトタイピングや迅速な実装などに効果的です。ただし、生成されたコードの品質保証やセキュリティレビューは開発者の責任で行う必要があります。

本来の意味では上記の通りですが、ローカルではさすがに雰囲気や直感とまではいきません。
そういった内容はこの後コツとして紹介していきます。

ZooCode(旧RooCodeとは)

ZooCode（旧Roo Code、旧RooCline）は、VS Code拡張機能としてのAIコーディングアシスタントです。
元々はRooClineとして開発され、その後Roo Codeにリブランドされ、さらにZooCodeへと改名されました。Claude CodeやGitHub Copilotのような対話型AIコード生成ツールで、エディタ内で自然言語による指示に応じてコードの生成、編集、デバッグなどをサポートします。ローカルLLMとの連携にも対応しており、プライバシーを重視した開発環境を構築できます。

ZooCodeはRooCodeの公式なフォークで、RooCodeの開発チームがRoomoteというVS Codeの枠から飛び出たエージェントの開発に向かったため、公式に後を引き継いだコミュニティから出ているものとなります。
今から使うならZooCodeの方にしておきましょう。

完全丸投げはOpenHandsで

ZooCodeはペアプログラミング向けですが、丸投げしたい方はこちらの方がおすすめです

ローカルバイブコーディングを始めるのに必要なもの

まずは、ローカルバイブコーディングを始めるには何が要るのか、紹介します。

追記: Bonsai2の登場でGPUは12GBからエントリー可能になりました。

物理的なもの

• 高性能なコンピューター
  AIは莫大な演算能力が要ります。初めてChatGPTが出現して数年、やっと我々のパソコンでも実用レベルに進化しましたが、それでもそこらの一般PCではまだ難しいのが実情です。

  • "とりあえず動けばいい"、"とりあえず体験したい"場合
    メモリを積んでればOK。64GB積んでれば大丈夫でしょう。積んでなくてもSSD直読みできるエンジンもあるので、最悪16Gでも動く可能性はある。
    CPUの性能によっては、高性能APUに匹敵するパフォーマンスを得られる可能性あり。

  • 実用レベルの速度で扱う場合
    PCのどこに性能を振るかで価格はだいぶ変わる。

    • 高性能GPUはまたAPU搭載PC

      • GPU
        VRAM32GB以上のものが望ましいが、Bonsai2なら12GBから動きます。
        GPUは演算能力は高いですが、VRAMが少ないので高価になります。
        30～100万前後

        • RTX5090 32GB GDDR7
          理想的だがもう買えない。70万って何。

        • ARC Pro B70 32GB GDDR6
          今新品で買うならこれか?

        • RTX3090 24GB
          ギリギリライン。中古で。

      • 高性能APU
        メモリ転送速度がとにかく早いもの。チップ本体も高性能であることが必要だが、それ以前にメモリ帯域が要る。
        30～70万前後

        • EVO-X2
          Ryzen AI Max+395 + LPDDR5x 8000MHz
          Rcatはこのマシンを使用している

        • MAC Mini
          Apple M4

        • DGX Spark
          Blackwell

ソフト的なもの

• 推論エンジン
  この後紹介するローカルLLMの実行環境です

• AIエージェントフレームワーク
  LLMを自立可能なエージェントとして動かすためのフレームワークです。

  • ZooCode (VSCode)
    今回はZooCodeというAIエージェント拡張機能を使いバイブコーディングします。
    VS Codeの拡張機能で検索するとすぐ出ます。

ローカルLLMを実行する環境

代表的なバックエンド

ローカルLLMを実行するための主要なバックエンドは以下の通りです：

• llama.cpp: C++で実装された軽量なLLM推論エンジン。Quantization（量子化）技術により、消費メモリを削減しながらモデルを実行可能

• Ollama: llama.cppなどを内部で活用した、使いやすいローカルLLM実行フレームワーク

• LM Studio: グラフィカルインターフェースを提供するローカルLLMアプリケーション。開発者向けツールとしても利用可能

• vLLM: 大規模なLLM推論に特化したエンジン。高スループットなテキスト生成を実現

• ExLlamaV2: CUDA対応の高速LLM推論ライブラリ。高精度な量子化をサポート

よく出てくるものをいくつか紹介します

Ollama

Ollamaは最も初心者向けの実行環境で、ローカルLLMを調べたら大体一番上に出るかと思います。
特徴はこんな感じ

• 簡単インストール: インストーラーを実行するだけ。設定や環境構築の知識は不要

• すぐ使える: インストール直後にチャットインターフェースでLLMと対話可能

• 簡単なモデル選択: チャット画面にお勧めモデルが出てるので即使える

• マルチプラットフォーム対応: macOS、Linux、Windowsに対応

ただし初心者向けのメリットはデメリットでもあります。
簡単に使える=設定が少ない=調整が効かない
インストールが簡単=汎用ビルド=パフォーマンス最悪
モデルが簡単に選べる=細かく選べない

個人的にはあり得ないほどパフォーマンスが出ないことを確認しているのでお勧めしません。
特に性能が低いPCの場合はマジで止めた方がいいです。

LM Studio

LM Studioは、llama.cppをベースにGUIを追加したローカルLLMを実行・テストするためのグラフィカルアプリケーションです。

• 簡単インストール: インストーラーを実行するだけ。

• GUI搭載: 画面で操作できるため、初心者でも使用可能。設定もすべてGUIになっているためやりやすい

• モデル検索とダウンロード: 内蔵のモデルリポジトリからHugging Face経由でモデルを取得するため、量子化バリエーションも選べる。

Ollamaより設定が豊富で複雑になりますが、その分応用が効きます。
私としては、初心者でも頑張ってこちらを使うのをお勧めします。
ちゃんと使い方はこの後解説します

llama.cpp

llama.cppは、C++製の軽量LLM推論エンジンです。
OllamaやLM Studioでも内部的にはこちらを使用しているため、外装を取っ払ったエンジンのみであるこちらはパフォーマンスが最高です。

• 超軽量: C++の単一ファイルセットで構成され、最小限のリソースで動作。

• 最新技術やモデルの対応: 一日10件以上の新機能や改善などが行われており、新しい技術やモデルへの対応が早い

• 最高のカスタマイズ性: LM Studioでも対応していなかったり、デフォルト値で固定になっているようなオプションも自在に変更できる。追加モデル不要の投機デコードは強力。

• CLIで動作: 画面無しが基本なので、サーバー用途で使いやすい。

• 様々なバックエンド: 有名なCUDAやROCm、METALはもちろん、超汎用Vulkanやニッチな中国系バックエンドに対応。

• ネイティブビルド: 自分でコンパイルする必要があるが、自分のマシンに最適化されたビルドにできるため、最高のパフォーマンスが出る

CUI慣れてます! Linuxやってます! Visual Studio入ってます!って人はこれ一択。ローカルLLMは結局パフォーマンス出せないとやっていけないので、できるのであればこれが一番いい。

と言いつつパフォーマンスは動かしてみたらCUDAは意外と僅差でした。ROCmとかじゃなければLMの方でもいいかも?

↓おすすめ記事

ローカルLLM環境を作る（LM Studio）

本記事では、カスタマイズ性と使いやすさのバランスに優れているLM Studioを用います。
初心者から中級者までカバーでき、パフォーマンスも申し分ありません。

ダウンロード

公式ページからインストーラーを落としてきてインストールします。
特に難しいことはないのでポチポチするだけ。

起動

勝手に起動するか、デスクトップのショートカットをクリックして立ち上げます。
初回は色々出ますが、すべて辞退して進みましょう。

この画面になればOK
※AI関連は開発が激しいので数か月もすれば変わるかも

モデルを選ぶ

左側のバーのうち、上に固まっている項目の一番下のロボットを虫眼鏡で見ているマークを押してモデルを選びます。

ローカルバイブで使うならちょうど下記で出ているQwen3.6 35B A3Bを選びます。

注意すべきはサイズと量子化です。
まずモデルサイズがVRAMの70%程度で収まるサイズのものを選びます。
この時点で3090などは収まるけど空きがほぼない状態で、後述のコンテキストを伸ばせなくなります。

た・だ・し 速度が落ちてもいいなら無視してかまいません。あと、GPUを使ってない人も無視。CPUなら最悪メモリオーバーしても行けるハズ。

量子化はデータのビット数下げることで精度を犠牲にしてサイズを下げる技術です。F16→Q8→Q4とビット数に応じて小さくなります。
Q4がサイズと精度的に現実的と言われています。余裕のある人はQ8選んでOK。

別のモデルだと、Gemma4 26B A4Bなら18GBなので、3090などでも入りますね。

その他のモデルについて

下の方の顔のアイコンになっているのは有志のモデルです。
特に、unslothのモデルは他と比べ物にならないほど量子化のバリエーションが多いです。
1bitとか置いてるのこの方くらいなのでは??
経験上3Bitから下は明らかに劣化を感じます。試すくらいなら3Bitはあり。
2Bit以下は会話すら成り立たないことがほとんど。

Bit数以外にも、量子化の手法が違うモデルがunslothでは多くアップロードされています。
Q4であればIQ4NLがQ4KMより小さいのでおすすめ。

自分で好きなモデルを選ぶ目安

• 能力の高いものを選ぶ
  例えばこちらのチャットボットアリーナには商用からオープンソースまで幅広いモデルの対戦スコアが載っています。Qwen3.6はまだなのですが、Gemma4は載っていて、gpt5.3より上らしいですよ?
  とはいえ、単発チャットの話なので、長文でのエージェントはどうかわかりません。
  https://huggingface.co/spaces/lmarena-ai/arena-leaderboard

• 演算能力が追い付くものを選ぶ
  個人のPCでは、いいもの持っててもパラメータ10Bまでが快適の限界。特にGPU無しの場合は5B前後が限度。低スぺPC?2Bなら動きますよ。

  • パラメータ(nB)とは
    モデルのサイズです。人間に例えると脳細胞の数です。つまりそのまま知能に直結します。
    ですが、No勉の野生の人間と英才教育を受けたサルならワンちゃんサルのほうが賢いかも?という感じで、AIの場合は英才教育が発展中なので、小さいモデルが勝つということが起きてます。厳密には構造も改良されてたりするんですが細かいことは置いておきます。

  • MoEを活用する
    MoEは全体は巨大でも、演算時は少ないパラメータを使うモデル。
    知識を蓄えつつ高速処理が可能で、ローカルではまずこれを選ぶ。
    35B-A3など、"An"がついているのがわかりやすい。
    演算速度はほぼAの後ろの数値のサイズ並み。さすがに全体が巨大だと落ちますが…。
    ちなみに、何も書いてないgpt-oss20Bも実はA3.6MoE。

  • 安定性が欲しい場合は密モデル
    MoEでないモデルはすべて密(Dense)モデルです。
    Qwen3.6の例だと、35B-A3と27Bが居るんですが、スコアは27Bが上です。
    常に脳をフル稼働なので、一部だけのA3より強いんですね。その代わり演算コストが爆上がりして、まず普段使いたいとは思いません。
    MoEではどうしようもなくなった時のバックアップ用でしょうか。

お勧めモデル

今選ぶなら下記が無難です。個人的にはQwenかな。

• 低リソース

  • Bonsai2 (27B Q2)
    VRAM12GBから動くモデル。ベースがQwen3.8 27Bなので性能が高い。

• おすすめ
  MoEでパフォーマンスが出やすいうえに高性能
  CPUでもシステムメモリさえ積んでればそこそこ使えるハズ。

  • Qwen3.6 35B-A3 Q8

  • Gemma4 26B-A4 Q8

• 難タスク用バックアップ

  • Qwen3.8 27B Q4

  • Gemma4 31B Q4

• チャレンジャー

  • Laguna S2.1 (118B-A8) Q4
    合計60GB程度で動く。他と1段違うレベルの性能。ただし日本語ちょっと苦手。

  • Qwen 3.8 Flash Next (171B-A6) Q3-Q4
    Claude級の化け物モデル。圧倒的な性能なので使えるならこれを使いたい。80GB前後

上記の性能序列は大体以下

• Qwen3.8 Flash Next
  ⇕ここに大きな溝

• LagunaS2.1

• Qwen3.8 27B
  ⇕そこそこの溝

• Bonsai2
  ⇕ここに大きな溝

• Qwen3.6 35B-A3
  ⇕ここに大きな溝

• Gemma4 26B-A4

• どれも無理

  • Qwen3.5 9B Q4
    本当に簡単なことなら遂行できます程度。VRAM6Gでも入らないことはない。CPU演算でもギリ許せるか?
    MoEじゃないので、35B-A3よりパフォーマンスは劣る。

• 実用的じゃなくていいから体験したい

  • Gemma4 E4B Q4
    メモリすらないなら。体験くらいはできると思われ。

Ryzen7 9700X(CPU)でQwen3.5 9B Q8を走らせたパフォーマンス。
10tokenを下回ると人間が読むより遅い。メモリが足引っ張ってるのでほぼ理論値です。物理的にこれ以上無理。

モデルを読み込む

モデルをダウンロードしたらさっそく読み込みましょう

チャット画面に行き、一番上のモデル選択を押す

下のパラメータを手動で設定をONにしてモデルを選ぶ

詳細設定が開くので設定を行います

• コンテキスト長
  モデルが扱える最大トークン数（文字数みたいなもの）。入出力合わせての値。
  バイブコーディングなら最低64k。128kあると捗る。
  1トークン何文字かはモデル依存で、大体英語は1単語1トークン。日本語は単語だったり1文字だったりする。
  ちなみにGemma4は"東京都千代田区秋葉原"を"東京都,千,代,田,区,秋,葉,原"と分割する。

• GPUオフロード
  AIモデルは層構造なので、何層GPUで計算しますか?ということ。もちろん全層です。
  VRAMが足りなければあえてGPUに全部入れないという手もありますが、VRAMとシステムRAMの転送速度の差がエグ過ぎて急激にパフォーマンス落ちます。
  GPUがない人は無視&0

• バッチサイズ
  入力された文字を一括計算するサイズ。GPUが高性能なら2048～4096みたいに増やすと早くなることがある。そうでないなら512とかでいい。
  ちなみに並列リクエストかける場合はプレフィルでほかの人のデコードが固まるので小さくした方がいい。

• MaxConcurrent Preductions
  並列実行数。コンテキストはこの数必要になるので、128kとかだと馬鹿にできなくなる。一人で使うんだから1でよい。

• Flash Attention
  絶対ON。ないと長文に対してメモリと計算が二乗になる。バイブコーディングでそれは死ぬ。

• K,Vキャッシュ量子化
  入力された文章の関係性を計算したベクトルデータ。コンテキスト長によって肥大化する。128k確保のためQ8とかにしてよい。Q4でもよいかもしれないが、長文を扱うバイブコーディングではちょっと心配。
  Q8やQ4はF16より計算負荷が重いため、APUなどではパフォーマンスが低下する可能性がある。
  実際にRadeon8060SではQ4はF16より遅くなる。

コンテキスト長とVRAM

Qwen3.5 9Bの例ですが、このように128kまで伸ばすと7G近いメモリ消費の差が出ます。最後のは16Gで収まらないので、KVを量子化しないといけないですね。
なお、増え方はモデルにより異なります。

ローカルLLMでチャットする

モデルが読み込めたら何かメッセージを送ってみましょう。
問いかけに対してちゃんとした返事が返ってくれば成功です。

サーバーモードで読み込む

次に、チャットの一個下のコンソールマークを押します。
ここではサーバーの設定が可能です。また、モデルの自動アンロードはここで読み込む場合だけ設定できたりします。

さっきチャットしたのでモデルが読み込まれてますね。
一旦Ejectしてアンロードしてみましょう。

まずはサーバー設定です。下記のようにします。
ローカルネットとCORSのチェックを入れればあとはデフォルトでOK。
この状態で右のLoad Modelを押します。

さっきとほぼ同じですが、ここの時だけTTL設定が出ます。
これは使ってないときはモデルを破棄してメモリを開放しますという設定。LLM専用ならいらないですが、他でも使ってる方は入れとくといいかも。

なお、使用中に頻繁にアンロードするとキャッシュを破棄する影響で無駄に問いかけ後の計算時間がかかるようになるので、継続利用中はアンロードしない程度の時間にします。

最後に左のボタンを押してサーバーを開始します。

下半分のログ部分について
ここにはエンジンであるllama.cppのログが出ます。
例えば、チャットが終わった後に見に来るとこんなログがあるはずです。
これがパフォーマンスとなります。

（おまけ）おおよそのパフォーマンスを予測する

LLMのパフォーマンスはほぼデコードが支配的で、さらにそれはメモリが支配的になっていることがほとんどです（だからメモリ高騰してるんですね）。
なので、そのあたりをGeminiに丸投げするだけで実はそこそこいい感じのパフォーマンスを見積もれます。

まずはこんな感じで投げます。今回はCPUという前提にしてみました。
モデルはQwen3.6 9B Q4です。

メモリスペックはタスクマネージャーのここ見てください

まずメモリの転送速度を計算します。ここが間違ってると後が間違うので確認が要ります

次にデコードです。モデルサイズとメモリ帯域から計算されます。
ちなみにこれ合ってます。

ローカルAIエージェントを使ってバイブコーディングする

さて、やっとメインディッシュです。

ZooCode(旧RooCode)のインストール

VS Codeを好きなところで立ち上げ、拡張機能を検索します。
今回使うのはZooCodeというAIエージェントです。

インストール後はサイドバーに出てくるのでこんな感じ。
私はセカンダリに持って行ったので右にありますが、多分左にあるはず。

ZooCode初期設定

右上の歯車ボタンを押します
設定プロファイル右側の+ボタンを押して新規作成。

APIプロバイダをLM Studioに設定。
モデルをさっき読み込んだモデルに設定。

出てこないときはサーバーがRunになっていない可能性があります。きちんとONになっているか見てきましょう。
また、モデルがきちんとロードされているかもチェック。

詳細でToDoが有効かどうかは見ておきましょう。これ結構大事。
あとはデフォでOK。

次にコンテキストの設定。
もし性能に懸念があるときはこの辺を全部下げておいた方が無難です。

コンテキスト圧縮
これは履歴が長くなってきたときに、要約して短くする機能。
低性能なマシンでは逆にタイムアウトになりかねないので無効化。10分以内に終わらないと切れることがあります。
そうでない場合で128kコンテキストを用意できていないなら有効化。
128kあれば、自分でタイミング見て実行できるので自動ではしなくていいかも。

なお、コンテキストを64k確保できてない場合はOFFにしてください。ファイルを複数読むと積みます。

ファイル読む→超過で圧縮かかる→ファイル情報失う→ファイル読む→超過で・・・の無限ループが完成します!

圧縮しない場合は過去の履歴が少しずつ消えていきますので、最初の方のことを忘れます。またキャッシュが効かなくなるので超時間かかるようになります。

自動承認
これはアクションを起こす際に人間に確認を取らず進めるための機能。ファイル読み込みをいちいち確認されたら進まないので、下記は自動でOK。

ただし、実行だけは何をしていいかちゃんと決めておきます。
間違ってもdelとかgit commitとか入れちゃだめです

モードの説明

設定が終わったら保存して戻ります。
次に左下のArchitectのところを押します。これがモードで、使い分けが必要です。
モードはシステムプロンプトが違ったり、ツールの使用制限が違ったりします。

• Architect
  設計モード。相談しながら仕様を決めたり分析を依頼するときに使う。

• Code
  コーディングモード。コードを書かせるときに使う。

• Ask
  質問モード。コードを解析して仕様を確認したりするときに使う。

• Debug
  デバッグモード。エラー時やレビュー時に使う。

• ☆Orchestrator☆
  司令塔モード。与えられたタスクを上記のモードに適切に振り分けたサブタスクを作成して自律的にこなす。
  一言指示すれば、Askでプロジェクトの状態を確認して、Architectモードで設計して、それをもとにCodeモードで実装して、Debugモードでチェックしてといったことをしてくれる。

モードには実行権限があるため、例えばArchitectモードでは*.mdファイル以外は生成できないなどの制約があります。
こういった使い分けで暴走を防ぐわけですね。

OrchestratorモードはローカルLLMと相性抜群!

Orchestratorモードは、独立サブタスクを作成します。
サブタスクとは、OrchestratorのAIが自分に対して別の指示を別のモードで投げることで仮想的にリーダーと部下を演じるやり方です。

何より、サブタスクは新規なので履歴がリセットされます。コンテキストが限られるローカルではかなりのアドバンテージとなります。

わかりやすいように図にしてみました。
モードチェンジでは会話が継続するため、長いコンテキスト長が必要です。
しかし、サブタスクでは会話が独立しているため、比較的短いコンテキストで完遂できます。

要約機能を使えばモードチェンジでも可能ですが、要約にも時間がかかりますので、サブタスクで終わったら破棄してしまうのが効率がいいです。

とりあえずバイブコーディングを実行してみる

では早速試してみましょう。
モードはOrchestratorに設定して、次の指示を投げてみます。
「JavaScriptでオセロ作って」

指示をしたらまずはArchitectでサブタスクができました。
設計をしているようです。

次にCodeモードのサブタスクができました。
フォルダを作ってほしいそうでコマンドが来ました。mdくらい自動承認でよかったかな?
でも実はフォルダは作らなくても書き込みツールが自動で作るんですよね。

その後コードを生成していきます。書き込みは自動にしてないので毎回承認です。今回みたいなまっさらなら自動でもいいんですけどね。

これがOrchestratorによるバイブコーディングです。簡単なふわっとした指示を投げるときや、逆にもういろいろ決まってるので、plan.md読んで進めてといった丸投げ可能タスクで効果を発揮します。

出来上がったのがこちら。約3分でできました。
まぁ動かなかったんですけどねw さすがに9Bじゃこんなもんか。

見た目はしっかりできているので、3分でこの見た目だけ作ってくれただけでも結構すごいですよね。自分でできます?

3回ほど改修かけてもらったんですが、ついぞ動きませんでした。駒を置けるかどうかの判定で落ちてますwおい

ちょっと悔しいのでQwen3.6 35B-A3 Q8 MTPで行きます。
こっちはなんとHTML1ファイルだけできましたw

こっちが作ったのは動きました。地味に次置けるとこ提示する機能付いてるのすごw
末尾でコード配布しますね。

バイブコーディング（ローカル）のポイント

上記で見ていただいた通り、モデルのサイズが小さい場合、簡単なゲームでも実装をしくじります。
まぁオセロはそこそこ複雑な部類だと思うので仕方ないとは思いますが。五目並べにした方がよかったですかね?

「おい、使えないじゃないか」と思われるかもしれませんが、これは完全に使い方（指示の仕方）が悪いです。あと、AIに期待しすぎです。最初に言ったように商用とは人間とサルの差があります。
最近やっと実用にこぎつけ始めたことを忘れないでください。

具体的に指示する

ローカルでは300億(30B)前後が限界なのに対して、商用モデルは1兆を超えていると言われています。
オーダー二桁違えばそりゃ化け物ですよ。ですので、指示が足りなくてもいろいろ汲んでくれてやってくれるんですね。

しかし、汲み切れないなら最初からちゃんと指示すればいいだけのこと。

先ほどは「JavaScriptでオセロ作って」でしたが、詳細は何も伝えてないのでAIが勝手に考えた結果、リッチな仕様をやろうとして失敗していました。
具体的にこちらで指示を行い、身の丈に合ったものを作らせればこうはならなかったと推測されます。

設計モードで詰める

いきなりOrchestratorモードで投げるのではなく、最初は設計モードで話し合いを進めていくのがおすすめです。
「オセロを作りたいんだけど、仕様を話し合いたい」とでもいえば話が進むでしょう。
できるだけ簡単になるように、AIが提案してくるリッチな仕様をすべてRejectします。モデルの性能によっては提案してくるくせに実装できないので…。
設計はmarkdown(*.md)で保存させます。ファイルに保存させれば、別のモードで読ませるだけで済みます。
また、投げる前に自分で設計書を確認して書き換えることも可能です。

完了したら、新しいタスクでOrchestratorモードを開始するか、事前に圧縮を掛けてから開始します。

手動圧縮は、タスクを広げてコンテキストバー右の⇕マークです。

モデルを変える

ZooCodeは、モードごとにプロバイダ設定を変えられます。
なので、最も知能が必要なCodeモードだけ重いモデルに投げて、それ以外を軽量モデルで処理するといったことが可能です。
これで処理時間を短縮しつつ成功率を挙げることができます。
LM Studioなら使わないモデルを即アンロードできたはずなので、実用的なやり方のはずです。

普段は35B-A3でコードだけ27Bとか。

思考モデルを使う

今どき当たり前ですが、回答前に思考過程を挟んでから出力するモデルを選ぶと精度が上がります。

LM Studioだとモデルを選ぶ際に書いてあります。
Reasoningのとこですね。また、ToolUseは必須なのでこれがないとZooCodeは動きません。

定期的に履歴を圧縮する

あるタスクが完了したらその時点でその会話は破棄するか、Orchestratorのメインの会話なら圧縮してしまうのがおすすめ。
特に圧縮なら安定性を確保しつつ、今までの会話もそこそこ覚えているので、仕様の追加や確認といった話が進めやすいです。

ハイブリッドで使う

知能が足りなければ外部から得ればいいのです。
つまり商用モデルから知識を得るんですね。具体的にはこうします。

1. Geminiなどに対して機能の相談を持ち掛け

2. 機能の詳細が決まったらテンプレートとして使えるクラスレベルのコードを落としてもらう

3. md形式で会話をまとめてもらいコピー

4. ローカルにplansフォルダを作成してそこに入れる

5. ローカルLLMにそれを参考に作るように命じる

これで商用モデルの知能で難しいコードの部分を補いつつ、ローカルで自立エージェントによる支援を受けられます。

AIをアシスタントとして使う

コーディングに耐えうるモデルでなくとも、使い道はあります。そもそも、すべて自分でやっていたのを一部任せられるだけでもだいぶ楽になります。

AIに調査丸投げ

さて、機能を追加したいが自分の手に負えないものってないですか?ありますよね。OSSとか。
例えばZooCode。OSSなので自分で手を加えることができるんですが、TSはやらないので手を付けられません。
こういうの丸投げできるのがAIエージェントのいいところ。

目的の処理がどの辺に書いてあって、どう関連してるのかといった理解に必要な事前調査を任せられます。
コード理解しないと手を付けられませんが、これが一番厄介なんですよね。

しかしAIは違います。長文を高速で理解しすらすら読み進めていく力があります。
こういった補助の目的でもローカルLLMは強力な味方です。

ここで問題になってくるのが、コンテキスト長です。
例えば、「認証処理どうなってる?」と聞いた場合、AIはフォルダを漁って、それっぽいファイルを見つけて読んで違えば探しなおして読んで…を繰り返します。
ローカルでこんなことをすれば即コンテキストオーバー。
ここで登場するのがコードベースです。

神ツール!? コードベース

コードベースとは

ZooCodeの機能で、ソースコードを意味を持ったベクトルに変換し、その意味で検索可能にするものです。

たとえば「認証処理」という言葉で検索すると、それっぽい実装をしているソースコードがある場所の一覧が返ってきます。
AIはそれを見て、このファイルにあるぞ!というのを効率的に見つけます。

これにより、無駄な読み込みを行わずに済むため、狭いコンテキストでも調査タスクが可能になります。
ローカルでは導入しない手はありません。商用でも無駄なトークンを削減できるので、やはり採用したいところでしょう。

コードベースの導入方法

コードベースを使うには2種類の追加が必要です。
どちらもローカルでホスト可能ですので安心してください。

• 埋め込みモデル
  LLMの一種で、文章を意味のあるベクトルに変換するモデル

• ベクトルデータベース
  埋め込みモデルが生成したベクトルとそのコードを保持するデータベース。
  ZooCodeではqdrantが使われている。

埋め込みモデルの用意

"embed"が名前に含まれるのは大抵この埋め込みモデルと呼ばれるものです。
実は現時点だと、LM StudioDL時点で下記がすでに入ってたりします。

読み込むとわかるんですが、種類がllmじゃなくてembdになっています。

というわけで実はこれで準備完了だったりします。楽ですね。
このモデルは軽量ですが、もし処理能力に余裕があるのであれば、コード特化のモデルなどを探して選んでもOKです。

ベクトルデータベース

DBのホストは難しいので、Dockerを使います。
Dockerが何かはこっちで簡単に解説してるので確認してください

Dockerをインストールしたら、DockerHubに入って

qdrantを検索して右のRunボタンを押す

設定が出てくるので下記を入力
名前:任意
ports:6333/6334
volume:任意のフォルダ, /qdrant/storage
※任意のフォルダはこのデータベースのデータを保存するところなので新規フォルダを作ります。

これでOK

Linuxや知識のある人はこっちのほうが楽。
"docker-compose.yaml"という名前で下記を保存してください。

services:
  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant-db
    ports:
      - "6333:6333"
    volumes:
      - ./qdrant_data:/qdrant/storage
    restart: unless-stopped

あとはこのフォルダでコマンドプロンプトを起動して下記を打つだけ。

docker compose up -d

コードベースの設定方法

qdrantと埋め込みモデルのホストが完了したら、設定していきます。
右下のDBマーク（円柱）をクリックして設定を出す。

• プロバイダ
  OpenAI互換 ※ここにはLM Studioという設定はありませんので、これを設定。

• ベースURL
  上記

• APIキー
  適当でいい(nekoなど)

• モデル
  LM Studioで読み込んだモデル名をコピーして貼り付け

• モデルディメンション
  モデルの次元数。選んだモデルに合わせて変えること。

• Qdrant URL
  上記

保存すればインデックスが始まります。
なお、ファイル数とモデルの処理能力によって数時間かかることがあります。
完了すると、ZooCodeは適宜コードベースを検索するようになります。

ベクトルデータベースの導入が初心者にはちょっと難しいかもですが、それだけの価値があります。ぜひ導入しましょう。

トラブルとコツ

AGENTS.mdを活用

AGENTS.mdは、今回のようなAIエージェントに対しての指示が書き込まれたファイルです。
毎回同じ指示を出さないといけないと感じたらここに書いてしまいましょう。

例えば、Pythonを実行するときにvenvから実行しないといけないのを何度も言うのが面倒なのでこんなこと書いてます。

仮想環境内のPythonを実行する
殆どの場合仮想環境
```
venv\Scripts\python.exe <script.py>
```

あとはテストについてなのですが、ガチのCICD向けのを書いてくる傾向があります。
でもそれ、ちゃんとテストの中身が正しいか精査しないといけないのと、ガチなのは読み解くだけで時間かかるので、個人のローカルバイブには向かないんですね。なのでこうします。
これならCLI上で動いたかどうかすぐわかるのでお勧め。

### 基本方針
テストではモックなどを使わず実環境で動作させる
不明なバックエンドやAPIはユーザーに確認すること
テストの書き方は実際に使って中身をprintする方式
CICDではないため、実行してログ表示ですぐわかるやり方が望ましい
テストモジュールやアサーションは使わない

あとはあんまり違反しないですがこういうのも

## 言語
指示がない限り日本語とする
ただし思考過程のような見せるメッセージでない場合はこの限りではない

理想的なのはフレームワークに依存しないように、ZooCodeに限ったような話は書かないことですが、ローカルではそうも言ってられません。
例えばこの後紹介する書き込みに失敗する件はかなり苦労しました。
なので指示をいれてしまいます。

### 書き込み失敗時
範囲を絞ったり、数回に分けて書き込むなど違うアプローチを検討する

## apply_diff 呼び出しコツ
<ここの内容は特典>

動かないコードができます

あるあるです。モデルの知能に見合わない作業はできません。

• 難易度は適切か?
  30B級でも複雑なロジックが絡むものは難しいです。さっきのオセロとか。
  逆にステップやスコープが広くても、やってることは単純なら意外といけます。
  フロントとバックエンドを別言語で作るけど通信は全部HTTPなので難しくないですとか。

• 指示は明確か?
  ふわっとした指示だとAIが迷います。質問してくれればいいですが、勝手にリッチな仕様にして自分でハードル上げてコケることがよくあります。
  仕事はできるけど、ちゃんと指示しないと使えない部下程度に考えましょう。

• 改修ではないか?
  実は、改修って苦手です。
  AIに丸投げしてOOができましたというのをよく見かけますが、それって新規ですか?改修ですか?って突っ込みたいところ。できたものに改修を加えられてこそ真に評価できます。
  120B級のモデルでも、改修となると急に理解が追い付かずに引っ掻き回した挙句動かないなんてこともあります。
  どうしても改修を任せたいなら、事前の計画を入念に立てましょう。

書き込みに失敗します

これ、ローカルAIが一番しくじるところなんです。
ツール呼び出し機能によってファイルの読み込みや検索、書き込みができますが、書き込みが一番難易度が高い。
新規作成は簡単ですが、置換が一番厄介で30B級モデルでもそこそこ失敗率が高いです。
一桁Bなんて、1行の書き換えですらできないことの方が多い。

理由は完全一致した部分を置換するからなので、置換範囲を一字一句間違えずに生成できないと落ちるという。
また、文字を置換するのに文字を出すので、ツールで使っている記号が被るとうまく認識されない場合もあるようです。

ZooCodeは3回失敗すると一時停止するので、失敗の内容によって軌道修正の指示を投げます

• 範囲を絞る
  本当に必要な範囲を最小限で書き換えさせる

• 一回で一か所
  ツールは一気に書き換え可能だが、一か所ずつにするように指示する

• フォーマッターを通してからファイルを読み直す
  変なスペースが原因だったりすることもあるので、フォーマッターを掛けてから読み直させるとうまくいくことがあります。

• コンテキスト圧縮をする
  前に読んだファイルが履歴上にあって悪さをしている可能性もあります。
  履歴を再構築して影響を抑えます。
  特に、ローカルLLMは履歴に引っ張られる傾向が強いので、過去に読んだファイルは圧縮して抹消しちゃうのが吉。

書き込み失敗率を下げる

最初から失敗しないのがいいです。だったら、何で失敗したのかを分析して事前に成功例を指示すればいいんです。
私はAGENTS.mdに過去の失敗理由と改善策のまとめを入れることでかなり改善しました。

なので、失敗しだしたらチャンスです。軌道修正させて書き込みがうまくいったら、その場でなんで失敗してどうしたらうまくいったのかを発言させてメモしておきましょう。それが今後の財産となります。

繰り返しに陥って進まなくなります

ローカルLLMでは途中で同じ言葉を無限に繰り返し初めて進まなくなることがあります。
初期のChatGPTやGeminiでもありましたが、最近はもう見ないですね。

対策としては次のような方法があります

• モデルを変える
  同じモデルでは、同じ文脈で再試行した際に同じところでまた繰り返す可能性が高いです。量子化の違いやチューニング違いなどでもチャンスはあるので変えてみましょう。

• パラメータを設定する
  ｍinpや繰り返しペナルティなどの設定が効きます。ただし、繰り返しペナルティとバイブコーディングは相性が悪いので上げ過ぎないように。
  例えば変数宣言の"let"がペナルティで使えなくなってバラバラに宣言されるなど…。
  ただこの辺はLM Studioではかえられそうにないので、llama.cppを用いた場合になりますね。

• モデルを大きくする/高ビット量子化/Denseを選ぶ
  小さいモデルほど繰り返しに陥りやすいです。また、経験則ですが低ビット量子化も耐性が低いです。30B級やQ8などを選びたいところ。
  MoEはDenseに比べて発生率が高いです。パフォーマンスはいいんですがどうしてもこういったデメリットを持ち合わせています。
  多めのアクティブパラメータを持っていたり、全体が大きいと安定します。

• コンテキストを短くする
  繰り返しは履歴が長くなってくるほど発生率が上がります。128kの空間を用意していたとしても、限界まで使わずに切り上げたほうが無難です。そのためのOrchestratorモードでもあります。サブタスクで繰り返してしまって失敗しても、親に戻って失敗したのでもう一回といえばリスタートできるんですね。

• コンテキスト圧縮を使う
  これ結構強力。
  履歴を短くすることで、繰り返す文脈ではなくなりつつコンテキストも短くなるので、ほぼ確実に繰り返しが改善する。
  ただし一時しのぎなので、頻発するならモデルを変えたい。

知っておきたい

コンテキスト圧縮機能は実は小さいモデルでいい

ほかのタスクと違い、圧縮機能はLLMの大得意な要約です。なので、巨大なモデルを使う必要って実はありません。
コンテキストが長かったとしても、繰り返さず要約完了できることが多いです。
私はQwen3.5 9B Q8で要約してたりします。RTX5070Tiに入るので爆速なんですよね。長文要約は大量のプレフィル&少量デコードなので、演算能力がものを言います。iGPUでは不利なタスクです。
メインのタスクは30Bが入るiGPUの統合大容量メモリ。
要約はRTXの高速少量VRAMでって感じ。

GPUとiGPUどっちがいい?

無限の予算があるならGPUにしてください。
そうでない大多数の方は下記を基準に決めます。

• 単発の長文を入力
  GPUにしましょう。長文の理解は計算能力がものを言います。
  ただし、VRAMが高価なので巨大モデルを動かすには2枚必要かもしれません。32Gでも厳しい場面があるというのを忘れずに。

• 少しずつ履歴を積み重ねていく
  iGPUにしましょう。積み重ねた履歴はキャッシュが効くため、文章理解の時間が分散されあまり待ち時間が気にならなくなります。
  統合メモリなら大容量を持てるので、巨大なモデルの複数運用も可能で応用の幅がひろがります。

最強は?

• GPU数枚挿し
  金に物を言わせる最強スペック。これを揃えるくらいならクラウドAPIのほうが余裕で安いぞw

• iGPU & ミドルGPU
  基本のコーディングはiGPUで巨大モデルを。コンテキスト要約などをVRAM16GB程度のGPUで高速で行うことで効率化。

• iGPUオンリー
  巨大モデルがホストできるので、大は小を兼ねます。

• CPU
  一般的なメモリだとデコードがとにかく遅い。ハイエンドなDDR5を2チャンネル積んでればなくない?。
  まぁ30B級が動くなら無理して劣化モデルをGPUに収めるよりはマシ。

• ミドルGPU
  30B級が載らないのは厳しい。3Bit量子化なら乗るが劣化の度合い的にあまりお勧めできない。

プレフィルとデコード（メモリ帯域とデコード速度）

パフォーマンスを貼ったとき、上下に2行あるのは気づいたでしょうか?
上はプレフィルで、入力した文書をAIが理解（関係を計算してKVキャッシュを作る）する速度です。
下がデコードで、実際に文字が生成される速度です。

上はバッチサイズが効いてくるので高速ですが、下は1トークンずつしか計算できないので遅くなります。
これはメモリの転送速度がもろに効いてくるからです。
1トークンを出力するには、今までの履歴すべてとモデルの全パラメータを計算しないといけません。

なので9BのQ8だと9GB+KV数GBを転送して1トークン。
さっきの例だと大体10Gくらいなので800GB/s程度だと上記の80t/sと合います。
実際に上のは5070Ti(896GB/s)で行った結果なのでほぼあってます。

というわけで、デコードを早くしたい場合はモデルの量子化をして小さくしつつ、MoEなどのアクティブパラメータが少ないモデルで転送量を減らすというのが根本的な解決策です。

CPUでのパフォーマンスを貼りましたが、これはDDR5 3600MT x 4枚差しの結果です。
57.6 GB/s程度の速度らしいので、10Gちょいが5回。完全にあってますね。

まとめ

いかがでしたか?
言えばAIがアプリを作ってくれるのって、クラウドの専売特許ってわけじゃないんですよ。
もちろん、相応の設備が必要かつ商用並みに完全自律で難しいことをやれるわけではありませんが、従量課金もいらず、常に安定して使い放題なローカル環境には独自の魅力があります。

これからお金かけて設備をというのはあまりお勧めしませんが、もしリソースがあるのであれば試してみたいところですね。もちろん浪漫を求める方にも!

正直、半年前までのモデルではこんなことありえなかったので、年末にはもっと強力なモデルが出てるんでしょうね。
そのころには強力な投機デコードや1Bit LLMあるいは拡散モデルなんかも実用になってきていると嬉しいですね。

ローカル的には1Bitや拡散モデル辺りが実用レベルで出てきてくれるとありがたい。

リンク集

感想投稿フォーム

コメントは公開で恥ずかしい!! Rcatだけに送りたい人向け

メンバーシップの説明

ミニPCにLinuxをインストール

特典