注意

これを構築をして、動作はしているし、構築は成功。
ただし、調整が必要な状態。

つまり、ダメ！！使えない！！！

構築をしてみたいだけの方は、試してみるのは良いかも。

概要

現場への開発提案のため、試しに作ってみる
Ollamaやcline、MCPなど聞いたことはあっても、初めて触る
ローカルLLMなので、クローズドで動作する
最新ドキュメント確認にネット接続はするが、コードは送られないのは素敵。

構成: Cline + Ollama + Context7 MCP(2026年7月時点の情報)

ゴール

VSCode内でチャット・ファイル編集・新規ファイル追加ができる(Claude on VSCode相当の体験)
モデルはローカルLLM(低スペックMacBookで動作)
ライブラリのバージョンにマッチした最新ドキュメントを参照して作業する(古い学習データに頼らない)
タブ補完は不要(GitHub Copilotが担当)

なぜこの構成か

コンポーネント	役割	選定理由
Cline (VSCode拡張)	チャット / マルチファイル編集 / 新規作成 / ターミナル実行	2026年半ば時点で最も活発にメンテされているローカルLLM対応エージェント。タブ補完機能を持たないためCopilotと競合しない
Ollama	ローカルLLMの実行基盤	シングルバイナリで管理が楽。Apple Siliconのユニファイドメモリと相性が良い
Context7 MCP	バージョン一致ドキュメントの注入	「Next.js 15の書き方を聞いたのにPages Router時代のコードが返る」問題を解消。プロンプトに最新の公式ドキュメントを取り込む

注意: Continue.devは選ばない。 2026年6月にCursorに買収され、v2.0.0を最後にリポジトリはread-only(メンテ終了)。動作はするが今後の更新がないため、新規構築ならClineが推奨。

Step 0. 前提条件

macOS(Apple Silicon推奨。Intelでも可だが遅い)
VSCode 最新版
Homebrew
Node.js 18以上(Context7 MCPの実行に必要)

# Node.jsが未導入なら
brew install node
node -v   # v18以上を確認

Step 1. Ollamaのインストール

brew install ollama

またはGUI版を https://ollama.com/download からインストール。

Homebrew(CLI)版: ollama serve をターミナルで起動しておくか、brew services start ollama で常駐化
GUI(.app)版: メニューバーアプリがサーバーを自動管理する。GUI版使用時に ollama serve を手動実行するとポート競合を起こすので注意

サービス管理コマンド一覧(Homebrew版)

コマンド	動作
`brew services start ollama`	起動 + ログイン時の自動起動を登録(常駐化)
`brew services stop ollama`	停止 + 自動起動の登録も解除
`brew services restart ollama`	再起動(設定変更後や挙動が怪しいときに)
`brew services run ollama`	今回だけ起動(自動起動は登録しない)
`brew services kill ollama`	今回だけ停止(自動起動の登録は残す)
`brew services list`	全サービスの稼働状況を確認(`started` なら稼働中)
`brew services info ollama`	ollamaの詳細ステータスを確認

普段使いは start / stop の2つで足ります。「今日だけ使いたい / 今日だけ止めたい」ときに run / kill を使うと、自動起動の設定を触らずに済みます。

動作確認:

curl http://localhost:11434
# "Ollama is running" が返ればOK

Step 2. モデルの選定とダウンロード

低スペック端末ではRAM容量が最大の制約。Apple SiliconはRAMがGPUと共有(ユニファイドメモリ)なので、RAM別の目安は以下の通り。

モデル確認はこちら
https://ollama.com/library

搭載RAM	推奨モデル	Q4量子化時の使用メモリ	備考
8GB	`qwen2.5-coder:3b`	約2GB	品質は割り切り。単一ファイルの小タスク向け
16GB	`qwen2.5-coder:7b`	約4.5GB	低スペック機のバランス最良。まずこれ
24GB以上	`qwen2.5-coder:14b` など	約9GB〜	品質向上。エージェント作業の成功率が上がる

# 16GB機の推奨(ダウンロード約4.7GB)
ollama pull qwen2.5-coder:7b

# 動作テスト
ollama run qwen2.5-coder:7b "TypeScriptで文字列を反転する関数を書いて"
# /bye で終了

Step 3.【最重要】コンテキストウィンドウの拡張

Ollamaのデフォルトコンテキストは約2K〜4Kトークンしかなく、Clineのようなエージェントは数回のツール呼び出しで即座に溢れて、無限ループや無言の失敗を起こします。ほぼ全員がハマる罠なので必ず設定してください。

Modelfileを作成してコンテキストを拡張したカスタムモデルを登録します:

mkdir -p ~/ollama-models && cd ~/ollama-models

cat > Modelfile.qwen-cline << 'EOF'
FROM qwen2.5-coder:7b
PARAMETER num_ctx 16384
EOF

ollama create qwen2.5-coder-cline -f Modelfile.qwen-cline
ollama list   # qwen2.5-coder-cline が増えていればOK

エージェント作業には 16K(16384)が下限の目安
コンテキストを増やすほどKVキャッシュがRAMを食うので、8GB機では 8192 に抑えるなど調整
メモリ不足でスワップが多発する場合は num_ctx を下げるか、より小さいモデルへ

補足: KVキャッシュとは

KV = Key-Value。LLMが推論中に使う「読んだ内容の作業メモ」のこと。LLMは1トークン生成するたびに過去の全文脈を参照するが、毎回ゼロから計算し直すと極端に遅いため、一度計算した各トークンの中間結果(KeyとValueのベクトル)をメモリに貯めて使い回す。これがKVキャッシュ。

メモリ消費の構造は以下の通り:

項目	性質
モデル本体	固定費(7B Q4なら約4.5GB)
KVキャッシュ	変動費。num_ctxに比例して増える(16Kで数GB規模になることも)

つまり「num_ctxを増やす=机を広げるほど、机自体が部屋(RAM)を圧迫する」。合計がRAMを超えるとスワップが発生して急激に遅くなるため、num_ctxはRAMとの相談で決める。

Step 4. Clineのインストールと接続

VSCodeの拡張機能マーケットプレイスで 「Cline」 を検索してインストール
サイドバーのClineアイコンをクリック
3-1. 以下を設定:
- API Provider: Ollama
- Base URL: http://localhost:11434(デフォルトのままでOK)
- Model Context Window: 16384(num_ctxで設定した値へ必ず変更)
- Model: qwen2.5-coder-cline(Step 3で作ったカスタムモデルを選ぶこと。元の qwen2.5-coder:7b を選ぶとコンテキスト拡張が効かない)

3-2. CLINEを開き、bring my own API key を選択

3-3.スクショの設定に変更
*Model Context Window は必ず先ほど設定したnum_ctx の値にしてください

これで、チャット・複数ファイルの編集・新規ファイル追加・ターミナルコマンド実行(各ステップ承認制)がローカルLLMで動きます。

Copilotとの棲み分け

Clineはタブ補完機能自体を持たないため、Copilotの補完と一切競合しません。設定不要でそのまま共存できます。

インライン補完 → Copilot
チャット / 設計相談 / マルチファイル編集 / リファクタ → Cline(ローカルLLM)

Step 5. Context7 MCPの導入(バージョン一致ドキュメント)

ここが「古いドキュメントではなくバージョンマッチした情報で作業する」ための核心部分です。

Context7は、質問に応じてライブラリの最新かつバージョン指定のドキュメントとコード例を取得し、LLMのコンテキストに注入するMCPサーバーです。「Next.js 14のmiddlewareの書き方は?」のようにバージョンを書けば、そのバージョンに対応したドキュメントが自動でマッチされます。

5-1. インストール(Cline MCPマーケットプレイス経由が最も簡単)

Clineパネルを開く
ハンバーガーメニュー(☰)→ MCP Servers セクション
Marketplaceタブで Context7 を検索
Install をクリック

5-2. 手動設定する場合

MCP Servers → Edit Configuration で以下を追記:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

APIキーなしでも基本機能は動作します。レート制限を上げたい場合は https://context7.com/dashboard で無料APIキーを取得し、argsに "--api-key", "YOUR_API_KEY" を追加。

5-3. 自動発動ルールの設定(推奨)

毎回「use context7」と書くのは面倒なので、プロジェクトルートに .clinerules ファイルを作って自動発動させます:

# .clinerules

外部ライブラリやフレームワークに関するコード生成・設定手順・APIドキュメントが
必要な場合は、必ずContext7 MCPツール(resolve-library-id → get-library-docs)を
使って最新のドキュメントを取得してから回答すること。
Next.js、React、TypeScript等のフレームワークAPIについて、学習データの記憶だけで
コードを書かないこと。プロジェクトのpackage.jsonに記載されたバージョンに
一致するドキュメントを優先すること。

5-4. 使い方の例

package.jsonを確認して、このプロジェクトのNext.jsバージョンに合った
Server Actionsの実装でフォーム送信を作って。use context7

Clineが resolve-library-id でライブラリIDを解決 → get-library-docs で該当バージョンのドキュメントを取得 → それを根拠にコードを書く、という流れになります。

トークン節約の注意: Context7の1回のドキュメント取得はデフォルト5000トークンをコンテキストに載せます。低スペック機ではコンテキストが貴重なので、変化の速いライブラリ(Next.js、Tailwind v4など)に絞って使い、安定したAPI(lodashなど)では発動させない運用が現実的です。

Step 6. 動作確認チェックリスト

curl http://localhost:11434 → Ollama応答あり
Clineでチャット:「このプロジェクトの構成を説明して」→ ファイルを読んで回答する
編集タスク:「utils.tsにkebab-case変換関数を追加して」→ diffが提示され、承認で反映される
新規作成:「Buttonコンポーネントを components/ に新規作成して」→ ファイルが作られる
Context7:「Tailwind CSS v4のtheme設定方法を教えて。use context7」→ MCPツール呼び出しが走り、v4の書き方(CSS-first設定)で回答する
Copilotのタブ補完が今まで通り動く

低スペック機での運用のコツ

タスクは小さく切る。 8〜16GB機の7Bモデルでは、マルチファイルにまたがる大規模なエージェントタスクは精度が落ちる。「このファイルにバリデーションを追加してテストも更新」程度の単一〜少数ファイルのタスクが適正サイズ
エージェントの暴走はモデルサイズが原因のことが多い。 編集が明後日の方向に行く場合、ツールの問題ではなくモデルが小さすぎる可能性が高い。タスクを分割するか、重要な作業だけClaude CodeなどクラウドLLMに切り替える(ClineはプロバイダーをタスクごとにOllama⇔Anthropicで切り替え可能)
メモリ圧迫時: ollama ps で常駐モデルを確認し、OLLAMA_KEEP_ALIVE=5m(デフォルト)で自動アンロードに任せる。Premiere Proなど重いアプリとの同時使用は避ける
速度が遅い場合: num_ctxを下げる、3Bモデルに落とす、他アプリを閉じてメモリを空ける

トラブルシューティング

症状	原因と対処
Clineが途中で無限ループ/沈黙する	num_ctx未設定が9割。Step 3のカスタムモデルを使っているか確認
ポート11434で競合エラー	GUI版Ollama起動中に `ollama serve` を手動実行している。どちらか一方に
Context7がツールを呼ばない	`.clinerules` の設定を確認、またはプロンプト末尾に明示的に `use context7` を付ける
npx実行でMCPが起動しない	Node.js 18以上か確認。ダメなら `bunx` に置き換えると解決することが多い
応答が極端に遅い	Activity Monitorでスワップ確認。モデルサイズかnum_ctxを下げる

付録: Ollamaのよく使うコマンド一覧

モデルの取得・確認

コマンド	動作
`ollama pull <model>`	モデルをダウンロード(例: `ollama pull qwen2.5-coder:7b`)
`ollama list`	インストール済みモデルの一覧(サイズ・更新日も表示)
`ollama show <model>`	モデルの詳細(パラメータ数、コンテキスト長、量子化、Modelfile内容)
`ollama pull <model>` (再実行)	モデルの更新(新バージョンがあれば差分ダウンロード)

実行・対話

コマンド	動作
`ollama run <model>`	ターミナルで対話開始(未DLなら自動でpullしてから起動)
`ollama run <model> "質問文"`	ワンショット実行(対話に入らず1回だけ回答)
`/bye`	対話モードの終了(対話中に入力)
`/clear`	対話の文脈をリセット(対話中に入力)

稼働状況・メモリ管理

コマンド	動作
`ollama ps`	現在メモリにロードされているモデルと使用量、残り常駐時間を表示
`ollama stop <model>`	ロード中のモデルを即座にメモリからアンロード
`curl http://localhost:11434`	サーバー死活確認("Ollama is running" が返ればOK)

カスタムモデル・削除

コマンド	動作
`ollama create <名前> -f <Modelfile>`	Modelfileからカスタムモデルを作成(num_ctx変更など)
`ollama cp <元> <新名>`	モデルの複製
`ollama rm <model>`	モデルの削除(ディスクから消える。カスタムモデルの元モデルは残す必要あり)

補足

モデルの実体は ~/.ollama/models/ に保存される。ディスク使用量は du -sh ~/.ollama/models で確認
ロードされたモデルはデフォルトで最終使用から5分後に自動アンロードされる(OLLAMA_KEEP_ALIVE で変更可)。すぐメモリを空けたいときは ollama stop
サーバー自体の起動/停止は Step 1 の brew services コマンド一覧を参照