第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カスタマイズとタスク分割による具体的な対策を解説します。