ローカルLLM時代への準備検討を開始する ― Ollama＋Gemma 4＋MCPで2027年に備える

ローカルLLMを本気で検討すべき時期に入ってきた。クラウドAIの技術解放が一段落し、知名度が上がるにつれて、各サービスは投資フェーズから回収フェーズへ舵を切りつつある。実験的に触っていた頃は気にならなかった「使い方」と「コスト」が、いまは真正面から課題として立ち上がってきた。先行する各AIの選別・選択が進むこの時期に、選択肢のひとつとしてローカルLLMをどこまで実務へ組み込めるのか。2027年を見据えた検討を、ここから始める。

この記事の結論（2026年7月時点の現在地）

• ローカルLLM単体では「AIに作業を任せる」構成にはならない。OllamaはMCPを話さないため、両者を仲介するクライアントが必須になる。
• 推論エンジンの第一候補はGemma 4（2026年4月2日公開・Apache 2.0）。E4B変種ならVRAM 8GBクラスから動く。
• クライアント側の情勢は動いた。Roo Codeは2026年5月15日に終了しており、いま選ぶなら本線はCline。
• 検証すべきは「生成速度」ではなく「エージェントループが完走するか」。ここが未検証のため、本記事は検討段階の記録として置く。

なぜ2027年に向けてローカルLLMを検討するのか

動機は「クラウドAIをやめたいから」ではない。むしろ逆で、クラウドAIを使い続けるために、降ろせる作業を切り分けたいという発想である。検討の軸は四つに整理できる。

• コスト構造：クラウドAIは従量課金で、使うほど比例して増える。ローカルLLMはGPUの初期投資と電力に置き換わり、使用量が増えても単価が上がらない。
• 機密性：社外に出しにくいソースコードや顧客データを扱う作業は、そもそも外部APIに投げる前提を置きたくない。
• 可用性：API障害、レート制限、モデルの世代交代による挙動変化。手元で完結する経路をひとつ持っておく意味は大きい。
• 役割分担：ローカルLLMは全面置き換えではなく「下ごしらえ担当」として見る。整形・分類・一次調査・定型コードの叩き台までをローカルで済ませ、判断を要する部分をクラウドに残す。

ローカルLLMを実務に組み込む3層アーキテクチャ

「ローカルのOllamaでモデルを動かしながら、MCP経由でAndroid StudioやPython環境などのローカルシステムを操作する」という構成は、次の3層に分解できる。

最初に押さえる前提 ― OllamaはMCPを話さない

ここを誤解すると設計を丸ごとやり直すことになる。Ollamaが提供するのは、OpenAI互換のエンドポイント（http://localhost:11434/v1）と、Ollama独自形式のツール呼び出し（tool_calls）である。これはMCP準拠ではない。したがって「OllamaにMCPを設定する」という操作は存在しない。

MCPサーバーを使うには、(1) MCPクライアント機能を持つツール（Cline、Continue.dev、LM Studio、Goose など）をOllamaに向けるか、(2) MCPHostやollama-mcp-bridgeのような変換ブリッジを挟むか、のどちらかになる。ローカルLLMを「手足付き」で動かす設計は、この仲介層をどう置くかで決まる。

推論エンジンの候補：Gemma 4

Gemma 4は2026年4月2日にApache 2.0で公開された、Google DeepMindの第4世代オープンウェイトモデルである。Gemini 3と同系の研究成果から蒸留されており、ローカルLLM用途としては現時点で扱いやすい選択肢に入る。

• 変種はE2B・E4B（実効2B／4B、コンテキスト128K）と、26B MoE・31B Dense（コンテキスト256K）。
• Ollamaは0.22以降が必要。ollama pull gemma4 で既定のE4B（約9.6GB）が取得できる。
• 2026年5月5日に投入されたMulti-Token Prediction（投機的デコード）により、デコード側スループットは最大3倍程度まで伸びるとされる。

VRAMの目安

出発点はQ4_K_Mでよい。加えて、コンテキストウィンドウ（KVキャッシュ）用にVRAMを2〜4GB空けておくこと。ローカルLLMで詰まる原因は、モデルが載らないことより、長い会話でKVキャッシュが膨らんで落ちることのほうが多い。

クライアント選定 ― 2026年前半に前提が変わった

ここが今回の検討で最も更新が必要だった箇所である。ネット上の解説記事は「Cline と Roo Code の二択」で書かれたものが多いが、その前提はすでに崩れている。

• Roo Codeは2026年4月21日に終了を発表し、2026年5月15日にVS Code拡張のサービスを終了した。Roo Code CloudとRouterも停止し、リポジトリは読み取り専用でアーカイブされている。
• 理由は技術的な行き詰まりではなく方針転換で、「IDEはコーディングの未来ではない」としてクラウドエージェントへ軸足を移した。
• コミュニティフォークとしてZoo Code、Kilo Codeが後を継いでおり、移行先として案内されたのがClineである。

つまり、いまからローカルLLM＋MCPの環境を組むなら、まずCline一本で考えるのが合理的である。フォーク系は、動く構成が固まってから比較対象に加えればよい。

MCPサーバーは2つあれば足りる

Python実行とAndroidプロジェクト操作を目的にするなら、必要な「手足」は2種類だけである。ファイルを読み書きするfilesystem系と、コマンドを実行するshell（terminal）系。多くのMCPサーバーはバックグラウンドでNode.jsまたはPythonを動かすため、Node.jsのLTS版とPythonの安定版を先に入れておく。

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:/Users/<ユーザー名>/Projects/AndroidApp_Project"
      ]
    }
  }
}

filesystemに渡すパスは、最初はプロジェクト1フォルダだけに絞る。許可範囲を広げるのは、ループが安定して回ることを確認してからでよい。コマンド実行系はクライアント側の機能として持っている場合があるため、Clineの設定を確認したうえで、足りなければ別途MCPサーバーを追加する。

想定している開発ループ

Android Studioのボタンを直接押させるわけではない。狙いは開発工程そのものを任せることで、流れは次のようになる。

1. 指示を出す。例：「ログイン画面にバリデーションを追加し、gradleビルドが通るまで修正を繰り返すこと」。
2. Gemma 4がプロンプトを解析し、ファイルを読む必要があると判断してfilesystem MCPの利用を要求する。
3. クライアントが実際にファイルを読み、内容をモデルへ戻す。
4. モデルが修正内容を出力し、クライアントが書き込む。
5. クライアントが python run_test.py や gradlew assembleDebug をターミナルで実行する。
6. エラーが出ればログを読み取り、2に戻る。通れば完了。

クラウドAIでは当たり前に回るこのループが、ローカルLLMでどこまで完走するか。それが今回の検討の核心である。

ローカルLLMのコストをどう見るか

「月額いくら浮くか」で判断すると、たいてい見誤る。比較すべき項目を並べておく。

• 初期投資：VRAM 16GB級で常用ラインに入り、24GB級で選択肢が広がる。ここが最大の固定費。
• 電力：推論中は継続的に消費する。長時間のエージェントループを回すなら無視できない。
• 時間コスト：ローカルLLMは生成が遅く、失敗によるやり直しも増える。人間の待ち時間は隠れコストになる。
• 自律性の閾値：エージェントループはローカルモデルにとって最も厳しい負荷である。一定規模（20B台後半クラス＋24GB前後のVRAM）を超えないと安定しにくい、という見方が一般的になってきている。

結論として現実解は併用になる。定型作業と機密性の高い処理をローカルLLMへ降ろし、判断と設計はクラウドAIに残す。この線引きを決めるための材料集めが、いまの段階の目的である。

動作検証の計画

公開前に通す検証項目を、順序つきで固定しておく。

1. Ollama 0.22以降を導入し、ollama pull gemma4 が完了すること。
2. ollama run gemma4 で日本語の応答品質と体感速度を確認すること。
3. 500エラー発生で　→　 irm https://ollama.com/install.ps1 | iex
4. 環境変数を正しく設定してOllamaを完全に再起動する　→ Get-Process | Where-Object {$_.ProcessName -like “ollama“} | Stop-Process -Force
   → これでもだめなら、GPU　起因かも 4GB VRAMなら ollama run llama3.2:3b　　→ これで起動した・
5. VS Code＋Clineで、API Providerを Ollama、Model IDを gemma4 として接続が通ること。← VRAMが多量にあれば
6. filesystem MCPを1フォルダだけ許可し、読み取りが成立すること。
   → Windowsでは、
   

MCP設定ファイルの起動：ollama runのラムボンランナーから、MCP設定ファイルを直接起動します。
   PSコマンドで   > ollama run llama3.2:3b
   

VS Codeをインストールする
公式サイト：https://code.visualstudio.com/
VS Codeを開いて
Ctrl + Shift + X     を押す
検索欄で  Cline　  入れて　Installをクリックする

ollama pull qwen3-coder　×　18GBもある　
ollama pull qwen3:4b     ◎　　←　 これもだめそう　8GBくらい必要そう
> ollama pull qwen2.5:1.5b

左のClineアイコンをクリックし開き 「Bring my own API Key」APIでcontinueを押し Providerを　Ol←

JDKのアップデート： ollama runのラムボンランナーは、オリジナルのLlamaと互換性がないように設計されています。つまり、古いバージョンのJDKを使用することはできません。 recentなバージョンのJDK を使用してください。
llamapの置き換え： ollama runは、Java program のコンパイルとリンキングを扱うためのコマンド llamap を提供しますが、これも modernな Java version では使用できません。代わりに javac コマンドを使用する必要があります。
JDKの設定ファイルの検索： cp オプションは古いバージョンの JDK にあり、modern な JDK に使用できないため、 modernな JDK では使用できません。代わりに -class-pathオプションまたは実際の JDK の lib directory を指定する必要があります。

1. コマンド実行を経由して「実行 → エラー読み取り → 自己修正」のループが完走すること。
2. 同じ課題をクラウドAIにも投げ、所要時間と成功率を並べて比較すること。

関門は5番である。ここを通過できた時点で、本記事を実測値つきで更新する。

まとめ ― 2027年に向けた現在位置

ローカルLLMは「安く済ませる手段」ではなく、「どの作業を手元に置くか」を決めるための道具である。2026年7月時点で、推論エンジン（Gemma 4）とクライアント（Cline）とMCPサーバー（filesystem／shell）という3層の見取り図は描けた。一方で、Roo Codeの終了のように前提が半年で入れ替わる領域でもある。だからこそ構成を固定するより、検証手順を先に固めておくほうが実務では効く。ローカルLLMの検討は、ここから実機での確認フェーズに入る。

関連記事

• 2026年夏版 最新AIはこう使え ― MCPからClaude Coworkへ、実務を「任せる」ための環境が変わった
• Claude MCP 連携ガイド 総合インデックス ─ WordPress・Buffer・スマートホームまで実践記録

参考リンク

• Ollama 公式サイト
• Google Gemma 公式ドキュメント
• Model Context Protocol 公式サイト
• MCPサーバー公式リポジトリ（GitHub）
• Cline 公式サイト