第1回：ローカルLLM開発の現実：なぜVRAM16GBが“快適ライン”になるのか
サブタイトル：脱「バイブコーディング」。Ollama × Roo Code × GitHub Spec Kitで構築するセキュアなエージェント環境
はじめに
ローカルLLMで開発を進めると、次のようなことが起こります。
- 実装済みのソースコードが突然0バイトになる
- READMEにポエムのような文章を書き始める
- 修正が無限ループする
これは大げさに聞こえるかもしれませんが、ローカルLLMを自律エージェントとして扱うと実際に起こりうる問題です。
生成AIの進化によって、開発の進め方は大きく変わりました。一方で、私たちSES（システムエンジニアリングサービス）を主軸とする現場では、いまなお最優先すべきなのはセキュリティと品質です。
本記事は、次のような課題を感じている人を想定しています。
- 顧客コードをクラウドへ送れないので、AIエージェントの活用をためらっている
- Cursorのような体験を、ローカル環境で再現したい
- ローカルLLMを試したが、遅すぎて実用に届かなかった
この連載では、実際の検証を通じてたどり着いた「現場で動くローカル開発環境」と、その運用ノウハウを3回に分けて整理していきます。
1. なぜ今、仕様駆動開発（SDD）なのか
AIを使った開発は、「なんとなく動くものを作る」段階から、より厳密な進め方へ移りつつあります。
バイブコーディングからの脱却
チャットベースの開発では、AIの出力に頼りすぎることで、次のような問題が起こりやすくなります。
- 意図しない実装が混ざる
- ロジックに不整合が出る
- 修正が何度も往復する
そこで重要になるのが、仕様駆動開発（Spec-Driven Development）です。
私たちはこの考え方を実際の運用に落とし込むために、GitHub Spec Kitを採用しました。
Spec Kitを使うことで、AIにいきなりコードを書かせるのではなく、次の順序を明確にできます。
仕様 → 設計 → タスク分割 → 実装
Spec Kitを採用した理由
Spec Kitの強みは、仕様を単なるメモではなく、開発の基準として扱える点にあります。
- 何を作るのかを先に決める
- どう作るのかを後から詰める
- 実装を小さなタスクに分解する
ローカルLLMは曖昧な指示に弱いため、最初に仕様を固定しておく設計と相性が良いです。
この点が、Spec Kitを取り入れた大きな理由でした。
第2回では、このSpec Kitをどう運用に落とし込んだかを詳しく紹介します。
2. なぜローカル完結にこだわるのか
クラウドAPIではなく、あえてローカルLLMを選んだのには、いくつか理由があります。
データ主権を確保しやすい
ローカル環境で完結させることで、外部へのデータ送信リスクを大幅に低減できます。
ただし、これは「リスクゼロ」という意味ではありません。
ログの管理、マルウェア対策、人的ミスなど、運用上のリスクは別途残ります。
コスト構造が読みやすい
クラウドAPIでは、トークン消費や試行回数がそのままコストに反映されます。
特にAIエージェントは、修正や再試行を繰り返しやすいため、想定よりコストが膨らみがちです。
一方ローカル環境では、主なコストは次の2つです。
- 初期投資（GPUなどのハードウェア）
- 電気代
そのため、納得いくまで試せるのが大きな利点です。
3. 推論エンジンの選定：LM Studio と Ollama
ローカルLLMの実行環境として、今回は Ollama を採用しました。
| 特徴 | LM Studio | Ollama |
|---|---|---|
| インターフェース | GUI中心 | CLI/API中心 |
| 用途 | 単体利用・検証 | 外部ツール連携 |
| 特徴 | モデル探索がしやすい | サーバー用途に向いている |
Ollamaを選んだ理由
Ollamaを選んだ理由はシンプルです。
- APIとして扱いやすい
- エージェントと連携しやすい
- 常駐プロセスとして運用しやすい
単体で会話するだけならGUI型のツールも便利ですが、今回は「開発エージェントの土台」として使いたかったため、Ollamaのほうが適していました。
4. エージェントの選定：Roo Code
今回採用したのは、VS Code拡張の Roo Code です。
Roo Codeのポイントは、単なる会話相手ではなく、実際にファイルを書き換えたり、ターミナルを実行したりできることです。
つまり、チャットボットというより、開発を実行するエージェントとして使えます。
Spec Kitで定義した仕様・設計・タスクを読み込み、環境構築から実装まで進めるには、このタイプのツールが必要になります。
5. ハードウェアの現実：VRAM 16GBは“快適ライン”
ローカルLLM運用で、最も重要になるのがGPUのVRAMです。
結論
VRAM 16GB前後が、開発用途における快適な実用ラインだと考えています。
もちろん、8GBや12GBでも動作は可能です。
ただし、エージェントとして継続運用する場合は、速度と安定性に差が出やすくなります。
12GB以下で起こりやすいこと
- コンテキストが増えるとVRAMを圧迫しやすい
- RAMへのオフロードが発生しやすい
- 推論速度が大きく低下することがある
環境によって差はありますが、場合によっては 1〜2 tokens/sec まで落ちることもあり、実装作業のテンポが崩れやすくなります。
16GBで見えてくること
- 7B〜14Bクラスのモデルを比較的安定して扱いやすい
- コンテキストをある程度維持しやすい
- 実用的な応答速度を確保しやすい
もちろん、モデルや量子化方式、コンテキスト長によって結果は変わります。
それでも、実務での体感としては、16GBがひとつの目安になると感じました。
6. なぜ「暴走」が起きるのか
ローカルLLMに自律的な権限を与えると、次のような問題が発生することがあります。
- ファイルを意図せず上書きする
- 関係ないファイルを編集する
- ディレクトリ構造を壊す
これは単なる気まぐれではなく、コンテキスト破綻やタスク境界の曖昧さによって、意図しないツール実行が起こることが主な原因です。
次回は、この問題をどう制御するかを扱います。
おわりに
ここまでで、ローカルLLMを開発に使うための土台は整いました。
ただし、実際に運用を始めると、
- AIが指示を忘れる
- 関係ない修正を始める
- 作業がループする
といった、ローカル特有の課題に直面します。
次回は、AIの暴走をどう制御するかをテーマに、TOMLカスタマイズとタスク分割による具体的な対策を解説します。