Continue×Ollamaで作るローカルAIコード補完

ContinueとOllamaは、VSCodeで無料かつローカル完結のAI補完環境を組むための二つの要である。
Continueがエディタ側のUIとしてふるまい、Ollamaがでモデルを動かす実行基盤になるため、コードを端末の外へ出さずに補完を回せます。
8GB VRAMのノートで14Bを入れて補完が数秒詰まった経験から、補完用は1.5B、チャット用は7Bに分ける2モデル構成へ切り替えると、応答はサブ秒まで改善しました。
設定は古いconfig.jsonではなく~/.continue/config.yamlにrolesを割り当て、provider: ollamaとapiBase、そしてpull済みタグと完全一致するmodel名を揃えることが動作の鍵になります。

Continue×Ollamaで実現するローカルAIコード補完の全体像

Continue×Ollamaの組み合わせは、VSCodeやJetBrains上の操作感をそのまま保ちながら、推論そのものはローカルのOllamaに任せる構成です。
Continueはタブ補完とチャットのUIを出すクライアントで、Ollamaは に立つ実行エンジンになるため、役割がきれいに分かれます。
外部にコードを送らずに済むので、クラウドAIを通しにくい現場でも導入しやすいでしょう。

ContinueとOllamaはどう役割分担するのか

Continueは拡張機能としてエディタに入り、カーソル周辺の補完や会話の画面を提供しますが、自分ではLLMを動かしません。
実際の推論はOllamaへHTTPで投げ、戻ってきた応答をそのまま編集体験に載せるだけです。
ここを押さえると、Continueは「頭脳」ではなく「操作盤」だと分かります。
Ollama側は既定で にAPIサーバを立てるので、同じ端末内で完結しやすい構造です。

設定でつまずきやすいのは、モデル名と接続先を正しく合わせる部分です。
ContinueのapiBaseがこのローカルアドレスを向き、Ollamaのタグと一致したモデルを指定すると、補完もチャットも同じ土台で動きます。
社内規定が厳しい案件でクラウドAI補完が通らなかったとき、この構成に切り替えたことで審査を通せた経験がある。
仕組みが単純だからこそ、説明責任を果たしやすいのです。

Copilotとの違い:コスト・プライバシー・オフライン

Copilotは毎回のようにコード片をクラウドへ送るのに対し、Continue×Ollamaではコードが端末外に出ません。
この差はNDA案件や閉域網の現場で効きます。
初回にモデルを落としてしまえば、機内モードでも補完が続くし、移動中に認証切れでCopilotが沈黙した場面でも、ローカル構成だけは止まりませんでした。
使える場面の広さが違うのです。

費用面も分かりやすいです。
ContinueもOllamaもモデルも無料で、月額0円、従量課金もありません。
精度はCopilotがなお先行しますが、DeepSeek-Coder-V2級なら提案の約80〜90%は再現でき、残りをチャットで詰める運用が実務的です。
速度より統制を優先したい現場では、十分におすすめできます。

補完(タブ)とチャットの2つの使い方

使い方は二系統です。
タブ補完はカーソル位置の続きを埋める用途で、入力速度を底上げします。
チャット/編集はサイドパネルで、コード生成、リファクタ、説明を頼むための窓口になる。
前者は瞬発力、後者は判断補助という分担です。

この2機能は、同じモデルで揃えるより別モデルで最適化したほうが扱いやすいです。
補完にはFIM対応のbase系、チャットには指示追従が得意なモデルを割り当てると、不要な説明文の混入を避けながら、提案の質も上げやすくなります。
DeepSeek-Coder-V2級の提案を土台にしつつ、最後の設計判断はチャットで詰める。
この流れが現実的でしょう。
モデルを分けて使うと、ローカル構成の強みがいちばん生きます。

導入前に確認するPCスペックと必要ソフト

導入前に見るべきなのは、モデル名より先にVRAMと常駐モデル数です。
補完だけなら8GBが実用ラインで、qwen2.5-coder:7bはファイル約4.7GB、KVキャッシュを足しても8GBに収まりやすいので、まずここを基準に考えると判断しやすくなります。
14Bクラスはファイル約8.5〜9GB、KVキャッシュ込みで10〜11GB VRAMが目安で、さらに上を狙うなら24GB級GPUや32GB以上のApple Silicon Macが見えてきます。

GPU/VRAMとRAMのざっくり目安

補完用モデルを選ぶときは、単純な重さだけでなく「どこまでを常駐させるか」で見るのが現実的です。
7B級は8GB前後で収まりやすく、日常の補完には十分な出発点になりますが、14Bになると一段上の余裕が要ります。
GPUレスでもCPUで動かせますが、その場合は1.5B〜3Bの小型FIMモデルに寄せ、量子化とnum_ctx縮小で体感を整えるのが筋です。
ミニPCで1.5B+q4_K_Mに割り切った構成が実用に足りた経験もあり、下限を知っておくとモデル選定がぶれません。

チャット用と補完用の2モデルを同時に動かす負荷

見落としやすいのは、チャット用と補完用を別々に置くとVRAMは合算で食う点です。
7B+1.5Bなら合計7GB弱で済む場面もありますが、16GB Macの統合メモリで常駐モデル数を増やしたところ他アプリと競合してスワップしたことがあり、余白を削りすぎると作業全体が鈍ります。
だからこそ、補完はqwen2.5-coder:1.5b、チャットはqwen2.5-coder:7bのように役割を分け、他の常駐アプリも含めて足し算で見るのが安全です。
おすすめです。

OS別の準備(macOS/Windows/Linux)

必要ソフトは3つだけで、Ollama本体、VSCode、Continue拡張が揃えば運用を始められます。
ContinueはVSCode向けのオープンソース拡張で、推論は持たず、Ollamaが立てる にHTTPでつなぐ構成です。
macOSはHomebrewか公式インストーラ、Windowsは公式インストーラ、Linuxはインストールスクリプトで入れられ、導入後は ollama コマンドが通るかを見ます。

Continueの設定は ~/.continue/config.yaml が現行で、models にチャット用と補完用を並べて roles を割り当てます。
既定の役割は [chat,edit,apply,summarize] なので、補完側はFIM対応かつbase系を選ぶのがコツです。
instruct版を混ぜると説明文が補完に入りやすく、qwen2.5-coder/codellama/deepseek-coder/starcoder2/codegemma などの系統から役割に合うものを選ぶと安定します。

速度と安定性は、OLLAMA_KEEP_ALIVE=30m でコールドスタートを避け、num_ctx や maxPromptTokens を絞り、q4_K_M 量子化を使うと整えやすいです。
補完が出ないならタグ一致と競合拡張を疑い、説明文が混じるならbase版へ切り替えます。
読み直しが増えるならVRAM不足でモデルが相互にアンロードされているので、ログは ~/.continue/logs/core.log で切り分けると見通しが立ちます。

Ollamaの導入とコーディングモデルの選び方

Ollamaは、コーディング用モデルをまず手元で単体起動できる状態にしてから、Continue側の設定へ進めるのがいちばん事故が少ないです。
補完と会話を同じモデルで兼ねると、タブ補完に説明文が混ざったり、応答が重くなったりしやすいので、補完用とチャット用を分ける2モデル構成が基本になります。
最初の1台目は軽い補完用、2台目は会話や確認用と割り切ると、作業の流れが安定します。

ollama pullで補完用・チャット用モデルを入れる

Ollama導入後は、モデルを ollama pull で取得します。
補完用には qwen2.5-coder:1.5b、チャット用には qwen2.5-coder:7b を入れるのが定番で、前者はサブ秒応答を狙いやすく、後者は対話の理解力が上がるぶん設定確認に向いています。
まずこの2つを揃えておけば、補完と会話の役割分担が明確になり、どこで遅くなったのかも切り分けやすくなります。
ollama pull qwen2.5-coder:1.5b ollama pull qwen2.5-coder:7b

補完に汎用チャットモデルを流用すると、カーソル前後を埋めるより先に文章として整えようとするため、Tab を押した瞬間に解説が返る珍現象が起きます。
mistral を補完に割り当ててこの失敗を踏んだが、base 版へ替えた途端に挙動が素直になり、補完は補完として働くようになりました。
作業の流れを壊すのはモデルの性能不足ではなく、役割の不一致であることが多いのです。

起動確認はここで済ませます。
ollama run qwen2.5-coder:1.5b で対話が返るか、ブラウザか curl で `` が応答するかを見ればよく、単体で動くことを確かめてから Continue 側へ進みましょう。

VRAM別のモデル早見(1.5B〜32B)

VRAMが増えるほど、補完の追従性と会話の安定感は上がります。
qwen2.5-coder:32b は HumanEval 92.7% と高精度ですが約24GB必要で、24〜32GB環境では qwen3-coder:30b が上位選択になります。
MoE・アクティブ約3.3B・19GB Q4_K_M・256Kコンテキストという構成は、重さを抑えながら長いコード文脈を扱えるのが強みです。
同じ7Bでも量子化を q8_0 から q4_K_M に落とすと、体感ははっきり軽くなります。
精度の差をゼロにはできないものの、補完の待ち時間が短くなるほうが日常の手触りには効く。
快適さはここで決まる、と言ってよいでしょう。

FIM対応とbase/instructの決定的な違い

タブ補完で最初に見るべきなのは、FIM（fill-in-the-middle）に対応しているかどうかです。
カーソル前後を埋めるには、途中だけを自然に差し込む学習が必要で、qwen2.5-coder、codellama、deepseek-coder、starcoder2、codegemma 系がその条件を満たします。
逆に llama3 系や mistral のような汎用チャットモデルは、補完に使うと前後文脈をコードとして埋めるより、説明や提案を書き始めやすい。
次に見るのが base か instruct かです。
タブ補完には base、できれば :code バリアントを使うのが正解で、instruct 版は会話用に調教されているぶん、補完のはずが prose を吐きやすい。
qwen2.5-coder:1.5b は Ollama 上で既に FIM 対応ビルドとして扱えるので、補完用の起点にしやすいでしょう。
会話は 7b、補完は 1.5b と割り切ると、役割がぶれません。

Continue拡張のインストールとconfig.yaml設定手順

Continue拡張をVSCodeに入れる

VSCodeの拡張マーケットで「Continue」を検索し、発行元がContinue.devの拡張を入れます。
類似名の非公式拡張が紛れやすいので、名前だけで選ばず発行元まで見るのが安全です。
ここを外すと、設定を書いても画面が思った通りに開かない、というつまずきが起きやすいでしょう。

拡張を入れたら、設定の受け皿がどこかを先に押さえておきます。
Continueの現行の設定ファイルは ~/.continue/config.yaml で、Windowsではユーザーフォルダ配下のContinueディレクトリになります。
旧 config.json は非推奨で、残っていても一部は自動移行されますが、新規に書くならyaml一択です。

config.yamlに2モデルをrolesで書く

config.yaml では、補完用とチャット用を2エントリで並べて書き、roles で役割を分けます。
roles には chat/autocomplete/edit/apply/embed/rerank/summarize を指定でき、何も書かない場合の既定は [chat, edit, apply, summarize] です。
補完を確実に使いたいなら、補完用モデルに autocomplete を明示しておくのが要点になります。

各エントリで外せないのは3点です。
provider: ollama、apiBase:、そして model に ollama pull 済みのタグを完全一致で書くことです。
特に model の末尾タグは事故が起きやすく、7b のつもりで書き忘れて :latest 扱いになり、意図しないモデルが読まれたことがあります。
ollama list に出た表記をそのまま貼る、これがいちばん確実です。

最小構成の設定サンプルと反映確認

最小構成は、チャット用に7B、補完用に1.5Bを置く形で十分です。
models に2本並べ、片方は chat、もう片方は autocomplete を持たせます。
保存しただけでは反映されないことがあり、拡張を入れ替えた直後はVSCodeの再読み込みで直る場合があります。
小さな詰まりですが、ここで止まると設定自体を疑ってしまうので先に覚えておくと楽です。

models:
  - name: chat-model
    provider: ollama

    model: llama3:7b
    roles:
      - chat
  - name: autocomplete-model
    provider: ollama

    model: qwen2.5-coder:1.5b
    roles:
      - autocomplete

保存後はVSCodeを再読み込みし、コード中でTabを押して補完が出るかを確かめます。
サイドパネルでチャットが返るかも同時に見ておくと、chat と autocomplete の割り当てが両方通っているか判断しやすいです。
動けば、その場で使い始められます。

補完精度とレスポンスを高めるチューニング

補完が遅いときは、まずモデルが眠っていないか、次に読み込ませすぎていないかを見るのが近道です。
Ollama の keep_alive でコールドスタートを消し、num_ctx と maxPromptTokens を絞って読む量を減らし、最後に量子化と autocompleteOptions で発火の重さを整える流れが扱いやすいでしょう。
設定の順番を間違えなければ、体感はすぐ変わります。

keep_aliveでコールドスタートを消す

Ollama は既定でモデルを5分でメモリから降ろすため、昼休み明けの初回補完で2〜3秒ほど詰まることがあります。
そこで OLLAMA_KEEP_ALIVE=30m を入れると、モデルが常駐したままになり、久々の補完でも待ち時間が目立たなくなるのです。
無期限に置きたいなら -1、すぐ降ろしたい用途なら 0 ですが、補完の快適さを優先する場面では 30m が扱いやすい設定だと思います。

コンテキスト量と量子化で速度を稼ぐ

遅延の主因は、送っている文脈が多すぎることです。
num_ctx と autocomplete の maxPromptTokens を欲張って上げると、モデルは読む量が増えて反応が鈍くなりますし、実際に上げすぎた後で下げ直すと軽さが戻るのがはっきり分かります。
補完は長い前提知識より速さが価値になる場面が多いので、まずは小さくして試すのが筋でしょう。

量子化も体感に直結します。
同じモデルでも q8_0 のような高精度量子化は重く、q4_K_M に落とすだけで速度と省メモリの両方を取りやすくなります。
精度低下が小さいなら、補完の既定は q4_K_M に寄せる方が運用しやすい。
補完は1.5B、チャットは7Bに分ける設計も、速さ優先の流れに合います。

autocompleteOptionsで補完の挙動を整える

Continue 側の autocompleteOptions では、debounceDelay でタイプ停止から発火までの待ち時間を伸ばしたり、prefixPercentage と maxSuffixPercentage でカーソル前後に含める文脈比率を調整できます。
入力のたびに重く感じるなら、発火を少し遅らせるだけで無駄な呼び出しが減り、補完の息切れがかなり抑えられるはずです。
前後文脈を詰めすぎないことも効きます。

過発火で引っかかるなら debounceDelay を少し長めにし、反応速度と負荷の釣り合いを取るとよいでしょう。
精度が要る作業だけ大型モデルへ手動切替にして、それ以外は軽い設定で回す。
そう決めてしまうと、補完に求める役割がぶれません。
速さは設定で作れるので、まずはそこから整えてみてください。

動かない・遅いときのトラブルシューティング

まずは症状を切り分けると、止まっているのか、補完は出るが中身が壊れているのか、ただ遅いだけなのかが見えてきます。
Continue の補完はモデル設定、拡張の競合、Ollama の起動状態がずれるとすぐ崩れるため、見た目の現象だけで判断しないほうが早いです。
ログまで追えば、タグの typo や接続失敗はかなりの確率でその場で特定できます。

補完が全く出ない/反応しない

最初に見るのは config.yaml の model です。
ここが ollama list に出ているタグと完全一致していないと、Continue は呼び出し先を見つけられません。
model not found が ~/.continue/logs/core.log に出ていたケースでは、原因は単純なタグの typo でした。
たった1文字の違いでも補完は沈黙するので、ここは真っ先に潰しましょう。

次に、Copilot など別の補完拡張が同時に動いていないか確認します。
補完系はフックの奪い合いが起きやすく、片方を無効化するだけで急に安定することがあります。
さらに `` に応答が返るかを見て、Ollama サーバ自体が起動しているかも確かめてください。
設定が合っていても、サービスが落ちていれば当然何も返ってこないです。

補完が説明文になる・的外れになる

この症状は、補完用に instruct 版を掴んでいるときに起きやすいです。
コードの続きを埋めるはずが、会話調の説明や前置きが混ざるなら、base の :code バリアントへ切り替えるのが近道でしょう。
FIM は「続きを自然文で説明する」より、「必要なトークンだけを埋める」ほうが得意だからです。

config.yaml のモデル名を直しただけで直らない場合もあります。
そのときは VSCode の開発者ツールを開いて Console を見て、Continue のコアログ ~/.continue/logs/core.log も併読すると流れが追えます。
モデル名不一致と接続失敗が同時に出ていることもあるため、片方だけ見て判断しないほうがいいですね。

遅い・モデルが何度も読み込み直される

補完のたびに読み込み直されるなら、VRAM のやりくりでチャット用と補完用が互いをアンロードしている可能性が高いです。
2モデル常駐で VRAM が振動していた環境では、補完が断続的になり、数回に1回しか返らない状態でした。
補完用だけを常駐させる構成に切り替えたところ、体感が一気に安定しました。
原因は派手ではないのに、影響は大きいのです。

この手の遅さは、モデルを小型化する、片方だけ常駐にする、keep_alive の考え方を見直す、という順で詰めると整理しやすいです。
model の :latest ズレや apiBase のポート違い、拡張のバージョン不整合も同じく遅延や再読み込みの温床になります。
症状、原因、対処を上から順に切るなら、次の表がそのまま使えます。

ログの確認が最短ルートになる場面は多いです。
Console と core.log を先に開いてから設定を直すと、無駄な試行錯誤をかなり減らせます。
調子が崩れたら、まずそこから見てください。