Ollama×VSCodeでローカルLLM開発環境を無料構築

Ollama、Continue、そして qwen2.5-coder を組み合わせたローカルAIコーディング環境は、月額課金もAPIキーも不要で、コードを外に出さずに手元のPCだけで立ち上げられる構成です。
8GB RAMのノートPCでいきなり32Bモデルを選んで補完が数十秒固まった失敗を踏まえると、先にスペックを確認してからモデルを決める順序が、快適さを左右する分かれ目になるでしょう。
最低要件は8GB RAMとここ5年以内のCPUで、GPUがあれば補完速度はCPUの3〜8tok/sから40〜80tok/sへ跳ね上がるため、最初の早見表で自分の枠に合うモデルを見極めておく流れにしています。
もっとも、ローカルLLMは単一関数の生成やタブ補完には強い一方で、複数ファイルをまたぐ設計や難しいバグ探しはまだクラウドが優位なので、補完とチャットの役割分担まで含めて現実的に使い分けましょう。

ローカルLLM開発環境で実現できること

まず完成形を思い浮かべると、この環境の価値がつかみやすいです。
VSCodeのエディタでタブを押せばローカルモデルが続きのコードを提案し、サイドパネルでは「この関数をリファクタして」とそのまま頼める。
しかも、その一連のやり取りがネット接続なしで動きます。

クラウド型AIコーディングとの根本的な違い

違いの核心は、推論がどこで起きるかです。
CursorやCopilotのようなクラウド型は、補完や対話のためにコードを外部サーバーへ送って処理しますが、Ollama構成はモデルが手元のPC上で動くので、コードが外へ出ません。
機密コードを扱うときに安心感が違うし、Wi-Fiを切った状態でもタブ補完が普通に効くので、「本当に外部通信していない」ことを体で理解できます。

コスト面も明快です。
クラウド型は月額サブスクか従量課金が続きますが、ローカル構成は初期のハード以外にトークン課金がありません。
長時間回すほど、あるいは補完とチャットを何度も使うほど、この差は効いてきます。
社内コードを貼るときの小さな抵抗が消えるのも、実務では見過ごせない利点でしょう。

この記事で作る環境の全体像(3つの部品)

構成はシンプルで、Ollama、Continue、コードモデルの3点です。
OllamaはLLMをローカルで動かす実行エンジン、ContinueはVSCodeとOllamaをつなぐ拡張、qwen2.5-coderのようなモデルは実際に推論を担う中身になります。
この分業を先に押さえておくと、後の設定で迷いません。

フレッシュな状態からでも約30分で動作環境まで持っていけます。
WindowsならOllamaSetup.exeを入れるだけで管理者権限は不要、macOSはアプリのドラッグかHomebrew、Linuxはinstall.shの1行で始められる。
GPUは必須ではありません。
CPUだけでも動きますが、7Bモデルで3〜8トークン/秒、500語なら20〜60秒ほどかかるので、快適さを求めるならGPUやApple Siliconが効いてきます。

モデル選びはメモリ枠で決まります。
Q4量子化なら8GBで7B級、16GBで13〜14B級、24GB以上で32B級が目安で、qwen2.5-coderやstarcoder2、deepseek-coderのようなFIM対応モデルを選ぶとタブ補完が生きます。
汎用チャットモデルでは補完にならないので、チャット用と補完用を分ける発想がポイントです。
Macの18GB M3 Proで14B級が快適に動く、という感触もここでつかめます。

向いている人・向いていない人

向いているのは、コードを外に出せない人、課金を避けたい人、オフラインで使いたい人、そして補完と単一ファイル作業が中心の人です。
実際、クラウドの補完が便利でも、社内コードを貼るたびに小さな引っかかりが残るなら、ローカル完結に切り替えたほうが気持ちよく作業できます。
まずは手元で回してみましょう。

向いていないのは、最高品質の複数ファイル横断推論を常時求める人です。
その領域ではクラウドのほうが強く、ローカルは単独で全部を背負うより、補完や日常作業を任せて難問だけクラウドへ回すハイブリッドが現実的になります。
用途を分けると、無理がありません。

必要なものとPCスペックの目安

Ollama、Continue、コードモデルの3点がそろえば、月額課金やAPIキーなしでローカル完結のAIコーディング環境を組めます。
着手前に見るべき軸は、RAM、VRAM、CPU世代の3つです。
最低限の目安を押さえれば、「うちのPCで動くのか」という不安はかなり早く消えるでしょう。

最低要件と推奨スペック

8GB RAM とここ5年以内の Intel/AMD/Apple Silicon CPU があれば、まず起動して試す土台になります。
GPU は必須ではありませんが、VSCode とネット接続は初回のモデル取得に必要です。
特に初心者は、先にこの線を超えているかだけ確認すればよく、ここを満たしていればローカルAI補完の入り口には立てます。

GPUの有無で変わる体感速度

CPUのみで 7B モデルを回すと、速度は約3〜8トークン/秒です。
500語の応答に20〜60秒かかる計算になり、補完用途では待ち時間が作業の流れを切ります。
GPUがあれば40〜80トークン/秒まで伸び、数秒で返るので、実用性がまるで違ってくるのです。
16GB の Mac で 14B 級を動かしたときに思ったより滑らかだったのに、同僚の 16GB Windows 機では同じモデルが重かった、という差もここにあります。
Apple Silicon の M1〜M4 は Unified Memory で CPU と GPU が RAM を共有するため、18GB の MacBook Pro M3 Pro でも 14B 級が快適に動きます。
メモリ総量が同じでも、使い方の効率で体感が変わるわけです。

量子化(Q4_K_M)とは何か

Q4_K_M は既定の量子化で、7B モデルを約4.5GBに圧縮し、FP16 比で 70% 削減できます。
品質低下は 1〜3% 程度に収まるため、最初に選ぶ形式として扱いやすいです。
重い FP16 モデルを選んでメモリが逼迫したあとでも、Q4_K_M に切り替えるだけでサイズが一気に下がり、普通に動く場面が多い。
必要な VRAM は、ざっくり「モデルファイルサイズ + 1〜1.5GB」の余裕で見積もれます。
これで自分の 8GB、16GB、24GB でどこまで狙えるかを逆算できるようになります。
8GB なら 7B 級、16GB なら 13〜14B 級、24GB 以上なら 32B 級が見えてくる。
まずは Q4_K_M を基準にして、そこから余裕を足して考えましょう。

Ollamaのインストールとモデルの導入

Ollamaは、最初のインストールとモデル導入までを一気に済ませると、ローカルLLMの土台がすぐ整います。
OSごとの入れ方は手順が短く、基本コマンドも ollama serve、ollama pull、ollama run、ollama list の4つだけです。
ここを通過すれば、起動確認から次のVSCode連携まで迷いにくくなります。

OS別インストール手順

Windowsでは OllamaSetup.exe を実行するだけで入り、管理者権限を求められないのが扱いやすいところです。
macOSは .dmg を開いてアプリを Applications へドラッグする方法が最短で、Homebrew で brew install ollama と入れる流れもあります。
Linuxは curl -fsSL https://ollama.com/install.sh | sh の1行で完了し、どのOSでも数分で導入まで進めます。
インストール後は ollama list で状態を見て、ollama serve を起動の起点にすると流れが整理しやすいでしょう。

最初のモデルをpullして起動確認

最初の一手は ollama pull qwen2.5-coder:1.5b から始めると段取りが安定します。
こちらは autocomplete 用の軽いモデルで、約1GB前後と小さく、先に通しで動作確認を済ませるのに向いています。
次に ollama pull qwen2.5-coder:7b を引けば、チャットや生成に回しやすい本命のモデルがそろいます。
大きいモデルは数GB規模になるので、先に1.5bで流れを確認してから進めると、DL待ちの心理的な負担がかなり減ります。

ollama run qwen2.5-coder:7b を打つと対話プロンプトが立ち上がるので、短い質問を投げてコードが返るかを見ればモデル側の準備はOKです。
ここで応答が返ってくれば、serve、pull、run、list の4つで導入から確認まで完結したことになります。
次はVSCode連携に進みましょう。
おすすめです。

GPUが認識されているか確認する

OllamaはGPUを自動検出するため、NVIDIA なら CUDA、Apple なら Metal、AMD の Linux なら ROCm を意識して個別設定を詰める必要がありません。
モデルを入れて run するだけでGPUが使われるので、ローカル実行の敷居が下がります。
手元の環境に合わせて最適化を考え込まなくてよい点が、初回導入でいちばん効きます。

GPU確認の見方はシンプルで、ollama run qwen2.5-coder:7b で応答速度が素直に出るかを見れば足ります。
特にMacでは、インストール直後にそのままMetal経由で動く感触がわかりやすいはずです。
まず軽い1.5bで導線を通し、次に7bで対話の質を確かめる。
この順番で進めてみてください。

コーディング向けモデルの選び方

RAM/VRAM別おすすめモデル早見表

コーディング向けモデルは、まず自分のVRAMから逆算すると選びやすくなります。
Q4では8GBなら7B級、16GBなら13〜14B級、24GB以上なら32B級が目安で、実際の必要VRAMはモデルサイズに加えて1〜1.5GBほど見ておくと判断しやすいです。
ここを外すと、起動はできても生成が鈍い、あるいは載るモデルが小さすぎる、というズレが起きます。

qwen2.5-coderはこの切り分けが分かりやすいモデルです。
1.5bはタブ補完用の軽量枠、7bは8GB級の万能枠、32bは24GB+で本領を発揮する上位枠と考えると迷いません。
32B級はHumanEval 92.7%前後でGPT-4o級に肉薄するだけあって、単一ファイルではクラウドに近い手応えが出ます。
ただし、複数ファイルにまたがる依頼では文脈の取りこぼしも出たため、広い修正を任せ切るなら過信は禁物です。

チャット用と補完用は役割で分ける

チャットと補完を同じモデルで兼ねさせるより、役割を分けたほうが安定します。
8GB環境なら、チャットはLlama系8Bかqwen2.5-coder:7b、補完はqwen2.5-coder:1.5bという二本立てが定番です。
説明や相談は少し重くても困りにくいのに対し、補完は一文字ごとの応答速度がそのまま体感に直結するからです。

実際、補完用に7bを割り当てたときは一文字打つたびに待たされましたが、1.5bへ変えるとタイピングに追従する速度まで上がりました。
ここで初めて、補完は軽量モデル一択だと腑に落ちます。
チャット用に少し賢いモデルを置き、補完用は遅延の少なさを最優先にする。
この分業がいちばん扱いやすいでしょう。

reasoning系のR1のようなモデルは、思考分のレイテンシが乗るぶん同パラメータ比で2〜3倍遅くなりやすく、日常の補完には向きません。
難バグを腰を据えて追う場面では頼れますが、普段の入力支援は軽量コードモデルで回すほうが快適です。
おすすめです。

FIM対応かどうかが補完の分かれ目

タブ補完で外してはいけない条件は、FIM（Fill-In-the-Middle）対応かどうかです。
qwen2.5-coder、starcoder2、deepseek-coderはここに対応しており、途中に差し込む補完を素直に出せます。
汎用チャットモデルはこの前提を満たさないため、補完に使うと「補完が出ない」という失敗の主因になります。

FIMは、コードの先頭と末尾を見たうえで間を埋める発想です。
変数名、引数、既存の行文脈をまたいで埋めるので、チャットのように最後の応答だけ整えれば済む世界とは違います。
だからこそ、モデル名だけで選ばず、FIM対応かどうかを先に確認しておくのが近道です。
補完を気持ちよく使いたいなら、この条件は外せません。

VSCode拡張Continueの設定手順

ContinueはVSCodeの拡張マーケットプレイスから入れて、サイドバーに現れるContinueのパネルから設定を進めます。
最初に見るべき場所は config.yaml だ。
ここでOllamaのチャット用モデルと補完用モデルを分けて登録すると、会話とタブ補完がそれぞれ別の役割で動き始めます。

Continueのインストールとconfig.yamlの場所

Continueを追加したら、VSCodeの左側にContinueのパネルが出ます。
そこから設定へ進み、config.yaml を開いてモデル名を記述する流れです。
この段階で大切なのは、Continueがモデルを自動で探しに行く前提ではないことです。
config で参照するモデルは先に ollama pull 済みでなければならず、タグまで正確に書きます。
たとえば qwen2.5-coder:1.5b のように末尾まで指定しないと、補完側だけが無反応になることがあります。
最初に chat だけ書いて保存し、タブを押しても何も出ず、あとから autocomplete の割り当て漏れに気づく流れは典型的です。

チャットモデルと補完モデルを登録する

config.yaml では provider: ollama を明示し、chat と autocomplete に役割を割り当てます。
たとえば chat に qwen2.5-coder:7b、autocomplete に qwen2.5-coder:1.5b を置く二本立てにすると、会話は腰のあるモデル、補完は軽めのモデルという分担が作れます。
役割を分ける理由はシンプルで、チャットは長めの文脈処理が要り、補完は反応の速さが効くからです。
補完は autocomplete のオプションでさらに詰められます。
debounceDelay を入れると入力直後の追従タイミングを整えられ、maxPromptTokens と contextLength で扱う文脈量を制御できます。
長いファイルで補完精度を保ちつつ、メモリ消費を暴れさせないためのつまみだと考えるとわかりやすいでしょう。
設定を書き分けて保存した瞬間、エディタでタブを押すと続きが薄く浮かぶ。
あの「動いた」感は、ローカルLLM接続ならではです。

タブ補完とチャットの動作確認

動作確認は、まずタブ補完から始めると見えやすいです。
autocomplete に 1.5b を明示的に入れる前は反応がなく、chat モデルだけでは補完が出ませんでした。
役割の指定漏れが原因だったわけで、autocomplete に qwen2.5-coder:1.5b を足した途端、薄い候補が出始めます。
その後でチャット欄を開き、短い質問を投げて応答が返るかを見ます。
補完とチャットが別々に動く状態になっていれば、設定はほぼ完成です。
ここまで通せば、VSCode上でローカルモデルを相棒にしてコードを書く土台が整います。
おすすめです。

よくあるトラブルと対処

導入直後につまずく原因は、たいてい型がはっきりしています。
model not found はタグの指定違い、補完が出ないならFIM非対応、動作が重いならモデルサイズや量子化の見直しが先です。
応答が返らないときは、設定をいじる前に ollama serve と接続先、そしてモデル名の実在確認へ戻るのが近道でしょう。

model not found / タグ不一致

model not found の多くは、モデル名そのものではなくタグの不一致で起きます。
qwen2.5-coder のように省略すると見つからないことがあり、qwen2.5-coder:1.5b のように正確なタグで指定し、ollama list で実際に入っている名前と突き合わせるだけで解消するケースが目立ちます。
名前が似ていても別物です。
そこを曖昧にすると、原因切り分けに時間を取られます。

タブ補完が出ない(FIM問題)

タブ補完が一向に出ないときは、補完用に割り当てたモデルがFIM非対応である可能性が高いです。
補完にチャット用モデルを入れてしまうと、設定は正しそうに見えても補完だけが沈黙します。
補完モデルを qwen2.5-coder:1.5b のようなFIM対応ビルドに切り替えると、症状・原因・対処が一気につながるはずです。
補完が出ない設定を疑い続けた回り道は、FIMの存在を知っていれば一発で避けられたはずだ、と痛感します。

動作が重い・固まるとき

極端に遅い、あるいは固まるなら、モデルがRAMやVRAMの上限を超えているサインです。
8GB機で32bを動かそうとしてスワップに落ちると、入力しても返答までの間が異常に伸び、体感ではフリーズに近くなります。
こういう場面では、32bから7bへ落とす、あるいは量子化をQ4_K_Mへ軽くするだけで見違えるほど扱いやすくなります。
背伸びせず自分の枠に収めるほうが、結局は速いのです。
メモリが厳しいなら、同時に走らせるモデル数を減らし、補完とチャットで同じ軽量モデルを共用し、コンテキスト長も短くしてみてください。

応答がまったく返らないときは、ollama serve かアプリ自体が起動しているかを先に確認します。
そこが動いていなければ、どれだけモデル設定を見直しても進みません。
さらに ollama list でモデルが入っているかを見れば、起動しているのに返らないのか、そもそもモデルが存在しないのかをすぐ分けられます。
初歩の確認に立ち返るのが、案外いちばん早いです。

ローカルとクラウドの現実的な使い分け

ローカルLLMは、毎日の補完や単一ファイルの生成、既存コードの説明、リネーム級のリファクタでかなり頼れます。
32B級なら、体感ではクラウド上位の85〜90%程度まで届く場面があり、日常作業の大半はそこで回せます。
だからこそ、全部をクラウドに投げる必要はありません。

ローカルが得意なこと・苦手なこと

タブ補完が速く返ってくるだけでも、作業の流れは驚くほど変わります。
関数1本の雛形を作る、既存の処理を読み解いて説明させる、名前を整えながら小さくリファクタする、といった用途ではローカルの強さが際立ちます。
移動中やネットが不安定な場面でも止まらないので、作業の土台をローカルに置いておく価値は想像以上に大きいです。

ただし、ローカルは万能ではありません。
複数ファイルをまたぐ設計判断や、コード全体の因果を追う必要がある微妙なバグ検出では、32B級でもクラウド上位に追いつかない場面が残ります。
ここは無理に粘るより、得意な領域を見切って使うほうが実戦的です。

クラウドに回すべきタスクの見極め

複数ファイル横断の推論が必要なときは、最初からクラウドに回したほうが早いことが多いです。
巨大なコンテキストを読ませて、設計意図と実装のズレを見つける作業は、まだ大規模クラウドモデルが強い。
微妙な不具合の再現条件を詰める場面も同じで、局所的な補完より全体像の把握がものを言います。

見極めの軸はシンプルです。
1ファイルで閉じるか、複数ファイルにまたがるか。
説明や補完で済むか、設計判断が要るか。
前者はローカル、後者はCursor、Copilot、Claudeに回す。
この切り分けだけで迷いは減ります。

無理なく続くハイブリッド運用

実際には、日常の8割をローカル補完で回し、設計が絡む難所だけクラウドに投げる運用がいちばん続きます。
普段は軽く速く、難問だけ外部の強いモデルを使う。
この分担に落ち着くと、課金の総額もプライバシー不安も下がり、作業中に「どちらを使うか」で悩む時間まで減ります。

コストの見方も。
ローカルは初期ハード投資のあとトークン課金が発生せず、クラウドは月額のサブスクか従量課金が積み上がります。
回す量が多い人ほどローカル比率を上げる価値が出るので、まずはローカルを基軸にして、足りないところだけクラウドへ送る形にしてみてください。

結局のところ、ローカルとクラウドは対立関係ではなく、役割分担です。
補完・単一ファイル・説明・オフラインはローカルで受け持ち、難問と大規模文脈だけクラウドに渡す。
この運用にすると、速さも安さも守りながら、詰まりにくい開発環境になります。
試してみてください。