GTX1060 3GB の古いWin機でローカルAI環境を作る話【第3回:VS Code + Cline で全自動コーディング環境完成】
前回までのあらすじ
前回は、Unsloth Studio をインストールし、CUDA 13 / Pascal 問題を CUDA_VISIBLE_DEVICES="-1" で回避し、最終的には llama-server を直接動かすという形で Qwen3.5-9B をローカルで動かすところまで辿り着きました。今回はいよいよ、これを VS Code の Cline 拡張機能に接続して、自動コーディングエージェントを完成させます。ここでもまた、いくつかの罠が待っています。
VS Code != Visual Studio という最初の罠
「VS Code を起動して」と書いた瞬間に、スタートメニューから Visual Studio 2022 を開いてしまう、というのは、エンジニアならあるあるです。両者はまったく別の製品です。Visual Studio 2022 は Microsoft のフル統合開発環境で、主に .NET や C++ の本格開発に使われます。一方、Visual Studio Code (VS Code) は軽量なコードエディタで、Web 開発や Python、TypeScript などで広く使われています。Cline 拡張機能は VS Code 専用で、Visual Studio 2022 では動きません。
もし VS Code が入っていなければ、code.visualstudio.com から「Download for Windows」をクリックしてインストーラを取得します。サイズは 100MB 程度。インストール時のオプションでは「PATH への追加」と「Code で開く」のコンテキストメニュー追加にチェックを入れておくと、後で便利です。Visual Studio 2022 と共存可能なので、すでに 2022 が入っていても問題ありません。
Cline 拡張機能のインストール
VS Code を起動したら、左サイドバーの拡張機能アイコン (四角が 4 つのマーク) をクリックし、検索ボックスに「Cline」と入力します。ここでも罠があって、検索結果には似たような名前の拡張機能が大量に並びます。Cline Chinese、Cline 中文版、Cline Pro、Cline Max、Bao Cline、Cline Nightly、などなど。
本家は「Cline」(Identifier: saoudrizwan.claude-dev) です。作者欄が「Cline」、青地に黒のロボット顔みたいなアイコン。これをインストールしてください。ダウンロード数が数百万単位で、レビュー数も多いので、判別は難しくないはずです。
インストールが完了すると、左サイドバーに新しいロボット顔アイコンが追加されます。これをクリックすると Cline のパネルが画面左に展開されます。
設定画面が見つからない問題
ここで多くの人がハマるのが、API 設定画面の所在です。拡張機能の歯車アイコンをクリックすると、VS Code 標準の Settings 画面が「Cline 用フィルタ付き」で開かれますが、ここには何も表示されません (No Settings Found)。これは Cline の設定が VS Code 標準の仕組みを使わず、独自の UI で管理されているためです。
正解は、Cline パネルの上部右にある歯車アイコンをクリックすることです。これで Cline 専用の設定画面が出てきて、API Provider のドロップダウン、Base URL、API Key、Model ID の入力欄が並びます。
設定値は以下のようにします。API Provider は「OpenAI Compatible」を選択。Base URL は前回起動した llama-server のアドレス、すなわち http://127.0.0.1:8080/v1 (末尾の /v1 を忘れない)。API Key は何でも構いません、私は dummy と入れました。ローカルなので認証は不要です。Model ID は unsloth/Qwen3.5-9B-GGUF:Q4_K_XL を入力。これで「Done」をクリック。
初タスクで早速エラー、コンテキスト不足
設定完了後、適当な空フォルダ (例: C:\test\cline-hello) を VS Code で開いて、Cline チャットに「hello.ts ファイルを作って、console.log で何か出力するコードを書いて」と投げてみました。
期待感を持って送信ボタンを押した直後、赤いエラーが返ってきました。「400 request (11639 tokens) exceeds the available context size (8192 tokens), try increasing it」。
これは Cline 固有の問題です。Cline は内部で巨大なシステムプロンプトを送ります。ツール定義、ファイル操作のルール、プロジェクトコンテキスト、MCP サーバの情報など、ユーザの一言タスクでも 11,000 トークン以上消費するのが普通です。前回の起動コマンドで -c 8192 (8K) を指定していましたが、Cline には全く足りません。
llama-server を一度停止 (Ctrl+C) して、-c 32768 (32K) に変更して再起動します。これで Cline のシステムプロンプト 11K + 会話履歴 + 出力余裕、すべて収まるようになります。RAM 使用量は KV キャッシュ分で 2GB ほど増えますが、32GB あれば余裕です。
代償として、CPU 推論で 32K コンテキストを処理するため、応答開始までの待ち時間が 8K の時より 30〜50% 増加します。これは仕方ない部分です。
初めての全自動コーディング体験
-c 32768 で llama-server を再起動した後、Cline の画面に表示されていた「Retry」ボタンをクリック。今度はエラーなく、Cline が動き始めました。「Thinking...」と表示されてから、しばらく待つ。長い。本当に長い。CPU で 11K トークンのプロンプト評価をしているので、最初の応答開始まで 1〜2 分かかります。
そしてついに、画面に動きが出ました。Cline が計画を立て、ファイル作成を提案し、Approve ボタンが表示されます。Approve を押すと、エディタに新しいファイル hello.ts が現れ、中に「console.log("Hello from Qwen 9B local on Windows!");」が書き込まれていく。最後に「Task Completed」と緑のチェックマーク。コストは $0.0000。
全体で 2〜5 分かかりました。クラウドの Claude Sonnet なら 5 秒で終わるタスクですが、これがすべてローカルで、API 課金ゼロで動いている、というのは感慨深いものがあります。タスクマネージャを開けば、Qwen が CPU の全コアを使って動いているのが見える。古い GTX 1060 を載せたマシンでも、ちゃんと AI コーディング環境として機能しています。
速度の現実と運用Tips
正直に言うと、この環境はインタラクティブな使い方には向きません。Cline で「ファイルをちょっと修正して」を 10 回連続でやろうとすると、合計で 30 分かかります。リアルタイム性が必要な仕事には、素直にクラウドの Claude Sonnet を使ったほうが幸せです。
ではどう使うか。私が考えている運用は、いくつかあります。一つは夜間バッチ処理。寝る前に「このファイルとこのファイルにテストを追加して」と複数のタスクを Cline に投げておき、朝起きたら結果を確認する。CPU が一晩稼働するだけなので、電気代も知れています。
もう一つは、社外秘データを扱う作業の専用環境にする運用。クライアントのソースコードを外に出せないケースで、ローカルで完結する AI コーディングは強力な選択肢です。速度より秘密保持を優先する場面。
そして個人的に一番有効だと思っているのは、クラウドとローカルのハイブリッド戦略です。仕様設計や複雑な多段推論はクラウドの Claude Sonnet に任せる。テストケースの設計もクラウドで生成してもらう。これらが揃ったら、「テストを通すように実装する」というローカル LLM が得意な明確なタスクに分解して、Cline 経由でローカル Qwen3.5 に投げる。実装が完了したらクラウドでレビュー、というサイクルです。
このやり方なら、クラウド API の課金は最小化しつつ、品質も確保できます。Cline の .clinerules 機能を使えば、プロジェクト固有のルールを Qwen に守らせることもできます。
速度を改善したい場合の選択肢
それでも「もう少し速く動かしたい」場合、いくつかの手があります。一番効くのは、モデルサイズを下げる方法です。Qwen3.5-4B-GGUF UD-Q4_K_XL に切り替えると、推論が 3〜4 倍速くなります。コーディング品質は微減しますが、Cline の日常タスクなら 4B でも十分実用範囲です。
Cline の設定で、使っていない MCP サーバや Browser tool を OFF にすれば、システムプロンプトが減って多少軽くなります。コンテキスト長を 32K から 16K に下げる手もありますが、長い会話で溢れるリスクがあるので、新規タスクごとに「Start New Task」する運用が前提です。
そして真の解決は、GPU の更新です。RTX 4060 8GB 程度を載せれば、9B Q4 を GPU 推論で 50〜80 tok/s で回せます。CPU 推論の 10〜20 倍速。Cline で「ファイル修正」が 10 秒で終わるレベルになります。本気でローカル AI コーディング環境を運用するなら、ここに投資する価値はあります。
連載のまとめ
3 回にわたって、GTX 1060 3GB の古い Win 機で Qwen3.5-9B のローカル AI コーディング環境を構築した記録をお届けしました。第 1 回でローカル LLM の意義と現実、第 2 回で Unsloth Studio の格闘と llama-server 直結への辿り着き、第 3 回で VS Code + Cline 接続の完成。
通しで読むと「結構大変」と感じるかもしれません。実際大変でした。ハマりポイントは正直に書いたつもりです。ただ、最終的にローカルで AI コーディングが動いた瞬間の達成感は、なかなか他では味わえないものがあります。
古いマシンを抱えている人、API 課金に疲れた人、社外秘データの取り扱いで悩んでいる人、そして純粋に技術的な好奇心がある人。誰にとっても、一度この環境を作ってみる経験は無駄にはなりません。クラウド AI を使い続けるにしても、ローカルで何ができて何ができないかを知ったうえで判断するのと、知らずに使うのとでは、向き合い方が変わります。
最後に。これは確かに 2026 年現在の技術スナップショットです。CUDA のサポート状況、モデルの最新版、Cline の挙動、すべて半年もすれば変わっているでしょう。それでも、「古い PC でローカル AI を動かす」という基本的な楽しみは、変わらず残っていくと思います。お読みいただきありがとうございました。実際に手を動かしてみる方、頑張ってください。動かなくて困った時は、私の note にコメントを残してもらえれば、できる範囲でお答えします。