ベテランエンジニアがローカルLLMでコーディングエージェントの夢を追い、挫折した記録
本記事は、サーバー運用管理と古いシステム保守を行うベテランエンジニアが、AIコーディングエージェントの実現を目指して検証を行った記録である。筆者は、GitHub CopilotやClaude Codeなど複数のクラウドAIサービスに月額約9,000円を費やしており、これらのサービスは「業務で実際に使っていて、代替手段がない」ために維持している。その上で、コスト削減と機密性の確保、そして「自分でコントロールしたい」というロマンから、ローカルLLMによるコーディングエージェントの実現に挑戦した。
検証環境はMac mini (M1, 2020, 16GB)であり、LM StudioやOllamaを用いてQwen2.5-CoderやGemma 4 E4Bなどのモデルを試した。しかし、エージェントモードでの検証は「全滅」に終わった。具体的には、ファイル作成やツール呼び出しの自律的な実行において、モデルが途中で詰まったり、タイムアウトしたりする問題が頻発した。また、速度面でも、Copilotのようなリアルタイムな補完速度には遠く及ばず、速度とコード品質のトレードオフに直面した。
失敗の原因として、ローカルモデルがClaudeなどのクラウドモデルに最適化されたシステムプロンプトやTool Calling形式と非互換である「土俵の違い」が指摘された。さらに、Mac miniの処理速度では、複数回のAPIリクエストを伴うエージェント動作が安定しないというアーキテクチャ上の問題が重なった。
結果として、筆者は「自律的なエージェント」という夢を諦め、「関数レベルの仕様を落とし込んで特定の関数を書かせる」というChat用途に目的を絞り直した。最終的に、Gemma 4 E4BをローカルのコーディングChatとして採用し、以下の役割分担を確立した。①インライン補完：GitHub Copilot Pro、②コーディングChat：Continue + Gemma 4 E4B（ローカル）、③エージェント：Claude Code、④設計相談：Claude Pro。筆者は、ローカルLLMの出番を「関数レベルのChat」に限定することで、追加コストゼロで機密性の高い関数の雛形作成に活用するという現実的な落としどころを見出した。今後は、新しいPCの購入による速度改善を期待し、エージェントの再検証を続ける意向を示している。
背景
近年、AI技術の進化に伴い、コーディング支援ツール（AIコーディングエージェント）への期待が高まっている。特に、クラウドサービスに依存せず、機密性の高いコードをローカル環境で扱いたいというニーズが、ローカルLLMの検証を促した。本記事は、その技術的な課題と、実用的な利用方法を模索する過程を記している。
重要用語解説
- ローカルLLM: ローカル環境（自身のPCなど）で動作する大規模言語モデル。機密性の高いデータやインターネット接続が不安定な環境での利用に適している。
- コーディングエージェント: 単なるコード補完に留まらず、指示に基づき、複数のファイル作成、実行、デバッグといった一連の作業を自律的に行うAIシステム。
- Tool Calling: LLMが、外部のツールやAPIを呼び出す必要があると判断し、そのためのJSON形式の指示を生成する機能。エージェント機能の根幹をなす技術の一つ。
今後の影響
本検証結果は、ローカルLLMが「自律的なエージェント」として実用レベルに達するには、計算資源（高性能GPUなど）と、クラウドサービスとの連携におけるプロンプト・アーキテクチャの互換性改善が不可欠であることを示唆している。今後は、役割を明確に分担したハイブリッドなAI活用モデルが主流となる可能性が高い。