Cline でローカル LLM を動かして無料・オフラインで AI コーディングする（Ollama 連携）

Clineとは、エディタや CLI から使える自律型の AI コーディングエージェントである。本記事では VS Code 拡張として Ollama 上のローカルモデルにつなぐ構成を扱う。

クラウド API の従量課金を避けながら AI コーディングを試す方法があります。Cline と Ollama を組み合わせ、クラウドの API ではなく手元の PC で動くモデルを呼ぶやり方です。ローカルモデルだけを使う構成なら、API 課金を避け、書いているコードも外部の推論 API へ送らずに処理できます。ただし Cline には Web 取得や MCP 連携、クラウドモデルへの切り替えといった機能もあり、設定しだいでは外部への通信が発生します。ここでは、推論をローカルに限定するための条件と、実用上のモデル選びを順に整理します。

Cline をローカル LLM で動かすとは何か

Cline は、エディタや CLI から使える AI コーディングエージェントです。VS Code・Cursor・Windsurf などの IDE 拡張に加え、JetBrains 系のプラグイン、CLI、SDK といった複数の形で提供されています（本記事では VS Code 拡張を使う構成を扱います）。ライセンスは Apache 2.0、本体そのものは無料です。ここで言う「エージェント」とは、こちらの指示を受けてみずから手を動かすタイプの AI のこと。コードの補完候補を出すだけのツールとは役割が違います。

ファイルを読む、書き換える、ターミナルでコマンドを実行する、その結果を見て次の作業に進む。こうした反復的なタスクを、Cline は一連の流れとしてこなします。本記事で扱う VS Code 拡張では、ファイル編集やコマンド実行などの操作を承認しながら進められます。

そして本題のローカル LLM 連携。Cline は OpenAI や Anthropic といったクラウド API に接続できるだけでなく、Ollama や LM Studio を経由したローカルモデルにもつなげます。LLM（大規模言語モデル、文章やコードを生成する AI の本体）を手元の PC で動かし、そこへ Cline をつなげば、モデル推論のリクエストはローカルの Ollama へ向かいます。ただし、Web 取得や MCP 連携、クラウドモデルへの切り替えなどを使う場合は、別途外部通信が発生し得ます。

Cline が「エージェント」と呼ばれる理由（承認フローとツール使用）

普通のコード補完は、入力中の数行に対して続きを提案するだけでした。Cline はそこから一歩踏み込みます。たとえば「このバグを直して」と頼むと、関連ファイルをみずから読み、原因の見当をつけ、修正の差分を提案する。実行が必要ならコマンドの実行許可を求めてくる。この「ファイルを読む・書く・コマンドを動かす」という一連の動作が、エージェントの言う「ツール使用」です。

本記事で扱う VS Code 拡張では、標準設定で承認フローが間に入ります。Cline は変更を即座に適用せず、差分を見せて確認を取り、こちらが OK を出して初めて反映する。標準のままなら、意図しない変更を適用前に止めやすい仕組みです。ただし Cline には Auto Approve（自動承認）があり、許可した種類の操作は承認なしで実行できます。操作をまとめて自動承認する設定にすれば、ファイル変更やコマンド実行まで自動で進む。業務コードや機密リポジトリで使うなら、自動承認の範囲は慎重に絞ってください。なお、Cline CLI は公式リファレンス上、既定で Act モードかつ Auto Approve が有効とされています。コマンドラインでは --auto-approve <boolean> で自動承認を設定でき、TUI では Shift+Tab で Auto Approve All を切り替えられます。CLI を利用する場合は、業務コードや機密リポジトリで実行する前に、自動承認の状態と許可範囲を確認してください。逆に、モデルが的外れな提案を連発すると承認待ちで作業が止まりがちになる点は、後半のモデル選びの話につながります。

クラウド接続とローカル接続の違い

クラウド接続では、Cline はインターネット越しにクラウド上のモデルへリクエストを送ります。有料の従量課金 API や有料モデルを使う場合は、利用量に応じて料金が増えることがあります。無料モデルや無料枠、定額枠が用意される場合もありますが、送信内容が外部の推論サーバーを通る点はローカル接続との大きな違いです。

ローカル接続はこの構図が変わります。モデルの本体が手元の PC にあるので、推論（AI が答えを生成する処理）も PC 内で完結する。外部の API に課金リクエストを投げないため、推論のたびにクラウド LLM の API 従量課金が発生することはありません（電力やハードウェア、外部サービスを併用する場合の費用は別です）。コードの中身も、外部の推論 API へは送られない構成になります。ただし「完全にオフラインで何も通信しない」とまでは言い切れない点に注意が必要。拡張機能の更新確認など、Cline 自体がネットワークにアクセスする場面はあり得ます。あくまで「AI の推論部分が外部に出ない」という理解が正確です。

ローカル LLM 接続で得られる3つの利点

ローカルモデルにつなぐ価値は、大きく3つに整理できます。クラウド LLM の API 従量課金を避けられること、コードが外部の推論 API へ送られないこと、そしてネット環境に左右されにくくなること。順番に中身を見ていきます。

ただし最初に釘を刺しておくと、3つとも「無条件のメリット」ではありません。特にプライバシー面は、使い方しだいで前提が崩れます。後の注意点とあわせて、条件つきで理解するのが安全です。

クラウド LLM の API 従量課金を避けられる効果（反復実行とトークン消費の関係）

多くのクラウド LLM API は、入力・出力トークン（AI が文章を処理する最小単位、おおむね単語の一部に相当）の量に応じて利用料金が増える仕組みです（無料枠や定額枠を設けるサービスもあります）。ここが Cline と相性の問題を生みます。エージェント型の Cline は、ファイルを読んでは考え、コマンドを実行しては結果を読み、と何度もモデルを呼び出す。一回の依頼で内部的に何往復もする設計です。

つまりトークン消費がかさみやすい。クラウド API だと、複雑なタスクを任せるほど料金メーターが回ります。試行錯誤を繰り返す学習段階では、これが地味に重くのしかかってくるもの。ローカルモデルだけで推論する構成なら、反復実行のたびにクラウド LLM の API 従量課金が増える心配はありません。もちろん、PC の電力消費やハードウェア費用、外部サービスを併用する場合の料金は別です。

コードが手元から出ない条件と、その注意点

業務で書くコードには、社外に出せないものが含まれます。社内システムのロジック、認証まわりの実装、契約上の守秘対象。こうしたコードをクラウド AI に貼り付けるのは、組織のルール上はばかられる場面も多いはず。

ローカルモデルなら、推論が PC 内で完結するため、コードが外部の推論 API へ送られません。手元のマシンだけで AI の助けを借りられる。これは機密性の高いコードを扱う人にとって、課金ゼロ以上に大きな利点でしょう。

ただし、ここは断定を避けて条件つきで押さえてください。「コードが外部に出ない」のは、Cline の推論先をローカル Ollama 上のモデルに限定し、ブラウザ機能、クラウドモデル、Ollama の cloud model、外部通信を行う MCP サーバーやその他の外部連携を使わない範囲に限られます。MCP はローカルで起動する構成でも、そのサーバー自体が外部 API やクラウドサービスへ通信する場合があるため、「ローカル MCP だから外部送信がない」とは限りません。Cline の設定でクラウドモデルへ切り替えた瞬間、送信先は外部のサーバーへ変わります。「ローカル＝常に安全」ではなく、「ローカルモデルに限定し、ブラウザ機能、クラウド推論、外部通信を行う MCP や同期・保存機能を使わない範囲で、推論に用いるコードを外部へ送らずに処理できる」というのが正確な線引きです。なお、Cline のテレメトリーは設定で無効化できます。公式説明ではコードやファイル内容、会話内容、認証情報は収集対象ではなく、利用機能やエラーなどの匿名イベントに限られるとされていますが、厳密な閉域運用ではテレメトリー設定に加えて、ブラウザ機能・MCP 接続・クラウドモデルや Ollama の cloud model の利用有無もあわせて確認してください。また、組織で管理された環境では、通常の匿名テレメトリーとは別に、会話履歴を外部ストレージへ保存する Prompt Storage などの管理機能が有効になっていないかも確認しておくと安全です。Prompt Storage が有効な場合、Cline が読み書きしたコードやコマンド出力を含む会話履歴が、構成されたクラウドストレージへ同期され得ます。

クラウドの最上位モデルと比べたとき、ローカルモデルの実力は実際どうなのか。ここは導入の判断を左右する大きな関心事です。ただ、その話に踏み込む前に、まず接続の設定を済ませておきます。手順そのものは、身構えるほど複雑ではありません。

Cline を Ollama につなぐ設定手順

つなぎ方は3ステップに整理できます。Ollama 側でモデルを用意し、VS Code に Cline を入れ、Cline の設定で接続先を Ollama に向ける。この流れで動き始めます。

手順1：Ollama を入れてコード特化モデルを取得する

まず推論を担う Ollama を用意します。Ollama はローカルで LLM を動かす実行環境で、インストール後はバックグラウンドのサービスとして既定の localhost:11434 で待ち受けます。続けて ollama pull モデル名 でコード特化のモデルを取得しておきます。どのモデルを選ぶかは後半の実力差の話に直結するため、ここでは「コーディング向けの中規模モデルを1つ落としておく」とだけ押さえれば十分です。

手順2：VS Code に Cline 拡張を入れる

次に VS Code の拡張機能から Cline を導入します。拡張パネルで Cline を検索してインストールすると、サイドバーに Cline のパネルが追加されます。本体は Apache 2.0 で無料のため、この段階で料金は発生しません。

手順3：Cline の API 設定で接続先を Ollama に向ける

仕上げが接続設定です。Cline の API 設定でプロバイダに Ollama を選び、Base URL に http://localhost:11434 を指定して、使うローカルモデルを選びます。Ollama の REST API 自体は /api/chat などのエンドポイントを提供していますが、Cline の Base URL 欄には公式手順どおり /api なしのアドレスを指定します。あわせて Context Window を十分に確保します。Ollama の Cline 統合ページ（Ollama 側のドキュメント）では少なくとも 32K tokens が推奨され、Ollama の Context length ガイドでは agents や coding tools の用途に少なくとも 64K tokens を推奨しています（Cline の公式ドキュメント自体は具体的なトークン数を定めていません）。メモリに余裕があるなら 64K 以上を起点にし、厳しい場合は 32K から試すのが現実的です。コンテキストを増やすほど必要な RAM / VRAM も増える点には注意してください。これでクラウド API ではなく、手元の Ollama 上で動くモデルへ推論リクエストを送れるようになります。Cline には「Plan（計画）と Act（実行）で別モデルを使う」設定もあり、計画は重いモデル・実行は軽いモデル、あるいは難所だけクラウド、といった割り当ても組めます。設定値の正確な名称や場所はバージョンで変わるため、最新は公式ドキュメントで確認してください。

ローカルモデル選びで注意したいこと：エージェント用途は要求が高い

ここが、この記事で一番伝えたい部分です。Cline は単純な質問応答よりモデルへの要求が高く、ローカルモデルを選ぶときはこの点を踏まえておく必要があります。

理由はシンプル。Cline は単純な質問応答ツールではありません。ファイルを読み、差分を考え、コマンドを実行し、その結果を読んでまた次の手を打つ。この一連の流れを、決まった形式の指示（ツール使用）と長い文脈の保持でこなしています。つまりモデルには「指示された手順を正確に守り、構造化された出力を崩さずに返す」という、会話とは別種の能力が要求されるわけです。

小型モデルでは、タスクが複雑になるほどツール呼び出し形式の崩れや、複数ステップへの追従失敗が起きる場合があります。そうなると Cline 側は正しい応答を待ち続け、承認フローが空回りすることもあります。一方で、タスクを小さく区切る、Cline のコンパクトプロンプト機能（Use Compact Prompt）を使う、コンテキストを膨らませすぎないといった工夫で扱いやすくなる場合もあります。成功率はモデルサイズだけでなく、タスク規模やコンテキスト管理、プロンプト構成にも左右されます。

なぜツール使用に「実力あるモデル」が要るのか

会話や短い要約、簡単なコード片の生成であれば、用途によっては数B クラスの小型モデルでも実用になる場合があります。

ところが agentic な動作、つまり自律的に手順を踏んでタスクを完遂させる動きは話が別です。モデルは「いまどのファイルを編集中か」「さっき何を実行したか」「次に何をすべきか」を、長い文脈の中で取りこぼさず追い続けなければなりません。さらに Cline が要求する形式どおりにツールを呼び出す精度も要る。この二つを両立できるかどうかが、実用と空回りの分かれ目になります。

一般的に、ツール使用や指示遵守の安定性はモデルの規模と学習の質に比例する傾向があります。会話ベンチでは高得点でも、エージェント用途では崩れるモデルも珍しくありません。だからこそ、コーディングエージェント用には「コードに特化し、かつツール使用を想定して鍛えられたモデル」を選ぶ必要があるのです。

候補モデルと VRAM の目安（Devstral Small 2 / Qwen3 Coder 30B）

では具体的にどのモデルが候補になるのか。よく挙がるのが、Mistral の Devstral Small 2 と、Alibaba の Qwen3-Coder 30B 系です。

Devstral Small 2 は 24B のエージェント向けモデルで、ライセンスは Apache 2.0。Ollama の配布ページではデフォルトタグが約 15GB です。Mistral 公式発表では、コーディングエージェントの実力を測る SWE-bench Verified で 68.0% を記録したとされています。一方、Ollama の配布ページでは 65.8% と掲載されており、評価条件や掲載時点により数値が異なる可能性があります。SWE-bench Verified とは、実在する GitHub の課題をモデルが自力で解けるかを検証する指標です。ただしこの数値はモデル自体の能力を示すもので、Cline 上での実際の安定性や、量子化したローカル版の速度を保証するものではありません。

一方、Ollama で配布されている qwen3-coder:30b は、公式ページ上で 30B total / 3.3B activated の MoE（混合エキスパート）モデルとして案内されています。名前こそ 30B ですが、毎回 30B すべてを計算するわけではなく、一部だけを使う構造です。配布ページには Q4_K_M 版が 19GB、コンテキスト長が 256K と表示されています。Devstral Small 2 とは構造も実行のされ方も違うため、「同じ 24〜30B 級」とひとくくりにして、同じ速度感・同じメモリ感で比べることはできません。

これらを Ollama で取得するコマンドはシンプルです。エージェント向けの候補として ollama pull devstral-small-2、別候補として ollama pull qwen3-coder:30b を実行します。なお devstral-small-2 は Ollama 0.13.3 以降が必要なので、古い場合は先に Ollama 本体を更新してください。必要メモリや実行速度は、量子化形式・コンテキスト長・GPU / RAM 構成によって変わります。

気になるのが、これらを動かすためのマシン要件。ただし「何 GB あれば動く」を一律には言えません。必要メモリは、実際に使う量子化済みモデルのファイルサイズ、コンテキスト長、MoE か dense かといった構造で変わるからです。Cline の公式案内も、ローカル推論の目安をモデル規模に応じた RAM の幅で示すにとどめ、特定の最低サイズを必須条件とはしていません。量子化（モデルの重みを圧縮して必要メモリを減らす手法）を強めれば省メモリになりますが精度は下がり気味、弱めれば精度は保てるがメモリを食う、という関係です。

実際には、手元の RAM / VRAM と許容できる速度の範囲で、コード用途に向いたモデルから試すのが起点になります。GPU VRAM に完全には収まらなくても、RAM へのオフロードで動作する構成はありますが、オフロードが増えるほど応答速度は低下しやすくなります。逆に VRAM に余裕があれば、より大きい・精度の高いモデルや長いコンテキストに手が届きます。まずは載るサイズのモデルで小さなタスクを動かし、速度と精度のバランスを見ながらサイズを上下させて調整するのが堅実です。

正確なベンチマーク値や最新の推奨モデルは入れ替わりが速いため、導入前に各モデルの公式情報で最新の数値を確認してほしいところ。ベンチの数字は環境や測定条件で変わります。鵜呑みにせず、自身の用途で小さく試すのが結局は早道です。

実用的に動かすためのマシン要件と運用のコツ

ローカルとクラウド、結局どちらを選べばいいのか。性能差を正直に整理しておきます。

トップのクラウドモデル（Claude など）は、難度の高い自律タスクや大規模なコードベースの理解で依然として強い傾向があります（ただし優劣はモデルと評価条件によります）。ローカルモデルは年々追い上げているものの、最上位のクラウドモデルと同じ完成度を全タスクで期待するのは、現時点では無理があります。ここを誤解したまま導入すると「思ったより賢くない」という評価になりがちです。最初から性能の線引きを理解しておくほうが、満足度は高くなります。

用途で割り切るのが現実的な答えです。下の表に、判断材料を並べました。

コストを抑えたい人、機密性の高いコードを扱う人、通信が不安定な環境で作業する人にはローカルが向きます。一方、込み入ったリファクタリングや大規模な設計判断を任せたいなら、クラウドの最上位モデルに分があるのが正直なところ。

おすすめは、両方を場面で使い分けるハイブリッド運用です。日常の小さな編集や学習目的の試行はローカルで回し、ここぞという難所だけクラウドに切り替える。Cline は設定でプロバイダを切り替えられるので、この使い分けがしやすい設計になっています。

運用面のコツも見ておきます。コンテキスト長（モデルが一度に扱える文章量）が短いと、長いファイルや複数ファイルにまたがるタスクで文脈が途切れます。コーディング用途では、ある程度長いコンテキストを扱えるモデルを選ぶと作業が安定する。量子化のレベルも効きます。圧縮を強めれば省メモリですが精度は下がり気味、弱めれば精度は保てるがメモリを食う。VRAM と相談しながら落としどころを探るのが現実的な進め方です。

よくある質問

Q. Cline は本当に無料で使えますか？

Cline 本体は Apache 2.0 ライセンスで利用できます。有料のクラウド API や有料クラウドモデルに接続すると、利用条件に応じた料金が発生します。一方、Ollama 経由で手元のローカルモデルだけを推論に使う構成なら、クラウド LLM の API 従量課金は発生しません。電力やハードウェア、外部サービスを併用する場合の費用は別途考える必要があります。

Q. ローカルモデルなら本当にオフラインで動きますか？

ローカルモデルを使い、外部の検索機能などを呼び出さない構成であれば、推論は PC 内で完結しオフラインでも動作します。ただし Cline 拡張の更新確認やクラウドモデルへの切り替え時には通信が発生します。「常に完全オフライン」ではなく条件つきと理解してください。

Q. どのくらいの VRAM が必要ですか？

一律の最低 VRAM はありません。必要メモリは、使う量子化モデルのファイルサイズとコンテキスト長、MoE か dense かといった構造で変わります。会話用途よりは要求が高めで、VRAM・メモリに余裕があるほど大きいモデルや長いコンテキストを扱えます。まずは手持ちの RAM / VRAM で無理なく動かせるサイズから試すのが安全です。GPU VRAM に完全には収まらなくても動作する構成はありますが、その場合は応答速度が大きく落ちることがあります。

Q. クラウドの Claude や GPT と比べて精度はどうですか？

難度の高い自律タスクでは、現時点でクラウドの最上位モデルに分があります。ローカルの中規模モデルは日常的な編集や学習用途では実用域に届きますが、最上位と同等を全タスクで期待するのは難しいのが実情。用途で使い分けるのが現実的です。

Q. ローカルとクラウドを併用できますか？

できます。Cline は API 設定でプロバイダを切り替えられるため、普段はローカル、難所だけクラウド、という運用が可能です。Plan と Act で別モデルを割り当てれば、計画はクラウド・実行はローカルといった組み合わせも組めます。

まとめ

課金を気にせず、コードを手元に置いたまま AI コーディングを試したいなら、Cline と Ollama の組み合わせが入口になります。設定手順どおりに Base URL とモデルを指定すれば、Cline をローカルモデルへ接続して動かせます。ここまでは難しくありません。

つまずきやすいのはモデル選びのほうです。Cline はツール使用と反復実行を伴うため、複雑なタスクでは小型モデルが手順追従に失敗する場合があります。本格的な編集や複数ステップの作業をローカルで試すなら、Devstral Small 2 のようなエージェント向けモデルは有力な候補です。ただし必要なメモリや速度は量子化やコンテキスト長で大きく変わるため、まずは手元の環境に収まるモデルで小さなタスクから試すのが安全です。

最上位のクラウドモデルと張り合おうとせず、用途で割り切るのが賢い使い方。日常の小さな編集や学習はローカルで回し、難度の高いタスクだけクラウドに切り替えるハイブリッド運用が、コストと実力のバランスを取りやすい着地点になります。

まず Ollama を入れてコード特化の中規模モデルを一つ取得し、Cline から小さなタスクを一件投げてみる。承認フローの挙動と応答速度を体感するところから始めると、手元のマシンで何ができるかが具体的につかめます。

参考資料

• Cline 公式: GitHub リポジトリ（Apache 2.0）
• Cline 公式: ローカルモデル（Ollama）接続ドキュメント
• Ollama 公式サイト
• Ollama 公式: Context length ガイド（coding tools 64K 推奨の出典）
• Ollama 公式: モデルライブラリ
• SWE-bench 公式サイト
• Cline 公式: Auto Approve（承認動作・CLI 既定の出典）
• Cline 公式: テレメトリー / Prompt Storage
• Ollama 公式: Cline 統合（Context Window 32K 推奨の出典）
• Cline 公式: MCP（外部 API・サービス連携、ローカル/リモート両対応）