ローカルAIでコードを直接編集する方法：ツール・モデル・ハードウェア実践ガイド

🛠️ クライン: 最も直接的なエントリーの選択肢

• Cline は、プロジェクト ファイルの読み取り、コード ベースの検索、パッチの適用、ファイルの作成、ターミナル コマンドの実行を行うことができます。 「ログインシステムにリメンバーミー機能を追加してテストを実行する」といったタスクに直面した場合、フロントエンド、認証ロジック、APIを順番にチェックし、テスト結果に基づいて修正を続けることができます。
• Plan モードは、最初に問題を調査して解決策を設計するのに適しており、その後 Act モードで実際にそれらを実装します。エージェントが分析のみでファイルを変更しない場合は、最初にエージェントがまだ計画モードであるかどうか、および「プロジェクト ファイルの編集」権限がオンになっているかどうかを確認します。
• 自動承認により、エージェントは継続的に動作できますが、同時にファイル変更や端末コマンドのリスクも増大します。初めて使用するときは手動による承認を維持し、モデルの動作が安定した後、安全な操作を徐々に公開する必要があります。
• Cline CLI は、たとえば次のようにプロジェクト ディレクトリから実行できます。cline "プロジェクトをチェックして、失敗したテストを修正してください"。同じエージェント機能セットを保持しながら、Codex または Claude Code の端末エクスペリエンスに近くなります。

🧰 Roo Code: より柔軟な権限と役割

• Roo Codeは、機能を読み取り、編集、コマンド、および MCP に分割しており、読み取り、書き込み、シェルの実行、および外部ツールの呼び出しをローカル モデルで完了できます。
• クラインの基本性能に非常に近いです。そのまま使用したい場合は、最初に Cline を選択できます。より詳細なモード、権限、ロールの設定が必要な場合は、通常、Roo Code の方が便利です。
• どちらも小規模なテストから始めて、モデルがツールを安定して呼び出すことを確認してから、実際のリポジトリに入れて複数のファイルの変更を処理するのに適しています。

🧠 Continue：完全ローカルのCopilot代替

• チャット モードは会話に使用され、プラン モードはプロジェクトの読み取りと分析を行い、エージェント モードにはファイルの作成、ファイルの変更、ターミナル コマンドの実行のための完全なツールが備わっています。
• 異なるタスクを異なるモデルに割り当てることができます。軽量モデルはオートコンプリートを担当し、大規模モデルはエージェントを担当し、埋め込みモデルはコード取得用に個別に構成されます。
• 一部の Ollama モデルにはツールの呼び出しをサポートする注釈が付けられていますが、エージェントは依然としてツールを使用できない場合があります。この時点で、モデルの機能ステートメント、プロバイダーの構成、およびそれが正しく有効になっているかどうかを確認する必要があります。tool_use。

🧩 VS Code 標準Agent: アクセスの成功は実行の安定を意味するものではありません

• ローカル モデルは VS Code のチャットおよびエージェント ワークフローに参加できますが、ツールの呼び出し、推論、および視覚的な機能は特定のモデルに依存します。正常にチャットできることは、ファイル編集を呼び出すことを証明するものではありません。
• 修正が必要な場合login.ts最後に、このモデルはファイルの変更を行わずに置換コードを出力するだけであり、現在の構成は依然として単なるチャット アシスタントです。
• ローカル BYOK モデルがエージェント スタイルの変更に使用される場合、VS Code のネイティブ タブ補完は自動的に置き換えられません。補完をローカルに保持したい場合は、ローカルのオートコンプリート モデルに接続できる Continue などの拡張機能が必要です。

🧪 Codex + Ollama

• 最初に使用するnpm install -g @openai/codexCodex CLI をインストールして実行するollama launch codex、渡すこともできますcodex --ossローカル モデルを選択します。
• プロジェクトディレクトリで起動したCodexは、リポジトリを直接操作するため、エディタを自由に選べます。GUIを使いたい場合は、ollama launch codex-appでCodex AppをOllamaに接続できます。
• このタイプのエージェントは、ツールの指示、プロジェクト コード、コマンド出力、および履歴操作を引き続き実行します。実際の使用は約 64K コンテキストから開始する必要があります。

🧭 Claude Code + Ollama

• 走るollama launch claudeClaude Code Agent シェルを Ollama に接続するか、次を使用します。claude --model qwen3.5ローカルのオープンモデルを指定します。
• エージェント プログラムとモデル ソースは別のものです。 Claude Code のプロジェクト操作機能を使用することは、必ずしも Anthropic のクラウド Claude モデルを呼び出すことを意味するわけではありません。
• ファイルのコンテンツ、ツール定義、および複数回のデバッグに対応するために、少なくとも約 64K のコンテキストを構成することも適切です。

🌐 OpenCode、Copilot CLI、および Cline CLI

• ollama launch opencodeオープンターミナルワークフローに適しています。ollama launch copilotCopilot CLI で Ollama が提供するモデルを使用します。
• ターミナル エージェントは、Linux、SSH、およびサーバー環境に特に適しています。正しいプロジェクト ディレクトリを入力している限り、エディタとは独立してリポジトリを読み取り、ファイルを変更し、テストを実行できます。
• ツールを選択するときに名前だけを見るのではなく、ファイルの読み取り、ファイルの編集またはパッチの適用、ターミナル、ツール呼び出し、およびエージェント ループも備えているかどうかを確認してください。

📏 パラメータと実際のエージェントの機能

• 3B ～ 4B は高度なコード補完に近く、複雑なエージェント タスクには適していません。 7B ～ 9B は単一ファイルの変更、小さな関数の記述、単純なバグの処理が可能ですが、長いループの安定性は平均的です。
• 14B 付近では、明確な生産性の値が得られ始めます。 24B から 30B はローカル コーディング エージェントにとって重要なレベルであり、コード ベースの理解、複数ファイルの変更、デバッグ、リファクタリング、テスト サイクルを真剣に処理できます。
• モデルがコードを記述できるからといって、それがエージェントになれるわけではありません。実際のタスクでは、適切なツールの選択、パラメーターの入力、ツール出力の分析、長期目標の維持、いつ停止するかを判断することも必要となるため、エージェント コーディング能力は単一のコード ベンチマーク スコアよりも重要です。

📚 コンテキストウィンドウは公称最大値のみを確認することはできません

• エージェント コンテキストには、システム プロンプト、ツール定義、ユーザー要件、プロジェクト ファイル、端末出力、Git Diff、および以前の操作記録も含まれます。通常のチャットには 8K で十分かもしれませんが、コーディング エージェントの現実的な開始点として 32K を使用する方が信頼性が高くなります。
• Cline および Roo Codeは 32K から開始できます。 Codex、Claude Code、OpenCode などの長いループのターミナル エージェントは、64K 以降に適しています。大規模なリポジトリや大規模なリファクタリングの場合は、さらに追加することを検討してください。
• モデルが 256K をサポートしているからといって、直接 256K をサポートする必要があるというわけではありません。num_ctx262144 に設定します。コンテキストが大きくなるほど、より多くの KV キャッシュが占有されるため、メモリ オーバーフロー、メモリ不足、速度低下、および最初のトークンの待機時間が長くなる可能性があります。

🗜️ Q4、Q5、Q6、Q8 の選択方法

• Q4 は圧縮率が高く、ファイルが小さくなり、VRAM要件が低くなり、動作が高速になりますが、精度が若干失われます。 Q8 は元のモデルの機能に近くなり、メモリとVRAMの使用量も大幅に増加します。
• 通常のローカル コーディング エージェントは Q4_K_M から開始できます。通常、完全なモデルと適切なコンテキストをハードウェアに安定してロードできることは、高精度の量子化を追求するが頻繁にオーバーフローすることよりも重要です。

🎮 グラフィックスメモリが第一位にランクされる理由

• 通常、すべてのモデル パラメーターが GPU に入力されると速度が最高になります。VRAMが不足している場合、一部のパラメータはシステム メモリに転送されます。引き続き実行できますが、CPU と GPU 間のデータ交換により、エージェント サイクルが大幅に遅くなります。
• 純粋な CPU 操作が完全に不可能というわけではありませんが、エージェントは 1 つのタスクに対してモデルを連続して複数回要求します。各ステップで数十秒待機すると、プロセスのデバッグ、テスト、修正が困難になる可能性があります。
• Qwen3-Coder 30B Q4 ファイルは約 19GB ですが、これは 24GB VRAMの残り 5GB が固定されているという意味ではありません。 KV キャッシュ、ランタイム、コンテキストはすべて追加のリソースを占有するため、32 GB または 48 GB のVRAMがより快適になります。

💾 メモリ、SSD、CPUの優先順位

• Windows、VS Code、ブラウザー、Docker、Node.js、データベース、Ollama、開発サーバーがモデルと同時にリソースを占有するため、64GB メモリは長期開発に適しています。
• モデル ファイルの一般的な容量は、6GB、15GB、19GB から数十 GB までの範囲です。複数のモデルをインストールすると、簡単に数百 GB を占有する可能性があります。 SSD は少なくとも 1TB で、長期使用には 2TB NVMe の方が適しています。
• もちろん CPU は重要ですが、予算が限られている場合は、CPU を少し強化するために 24 GB のVRAMを 16 GB に減らす価値は通常ありません。ローカルの大規模モデルの場合、GPU メモリの優先度が高くなります。

🍎 Apple Silicon用ユニファイドメモリの選び方

• Mac は CPU と GPU が共有するユニファイド メモリを使用しており、「システム メモリ + 独立したVRAM」という PC のアルゴリズムを直接適用することはできません。 16GB は小型モデルに適しており、32GB は Devstral 24B Q4 などのモデルを本格的に試すことができます。
• 64GB ユニファイド メモリは 24B ～ 35B のローカル コーディング エージェントに適しており、128GB はより大きなモデルやより長いコンテキストに対応できます。ローカル AI のみを実行し、大規模なゲームに焦点を当てていない場合、大規模なユニファイド メモリを備えた Mac には明らかな利点があります。
• 実際のリファレンスは、16K コンテキストの場合は約 8GB のVRAM、32K の場合は約 16GB のVRAM、24GB を超えるVRAMの場合は 64K を試してください。特定の占有率は、モデルのアーキテクチャと量子化方法によって異なります。

1️⃣ ランナーをインストールし、適切なモデルをダウンロードします

• まず Ollama をインストールしてから、ハードウェアごとにモデルを選択します。 24GBのビデオメモリを試すことができますollama pull qwen3-coder:30bまたはollama pull devstral-small-2:24b;ビデオメモリが少ない場合は、次のようにすることができます。ollama pull qwen3.5:9b開始します。
• グラフィカル インターフェイスの方が使い慣れている場合は、LM Studio を使用してモデルを検索、ダウンロード、ロードすることもできます。 Ollama の自動化と統合の範囲は、コーディング エージェントが主に使用される場合に便利です。

2️⃣ Cline をインストールし、Ollama に接続します

• VS Code 拡張機能ストアに Cline をインストールし、設定に入り、API プロバイダーを Ollama に設定します。
• 通常、このマシンのデフォルトのアドレスは次のとおりです。http://localhost:11434、ダウンロードしたモデルを選択し、エージェントの適切なコンテキスト長を設定します。
• 初めて自動ターミナル権限を開くのではなく、プロジェクトの読み取り、ワークスペース ファイルの編集、安全なコマンドの実行を最初に許可してください。

3️⃣ 最小限のテストでエージェント リンクを確認する

• 作成するtest.txtそして書きますhello、エージェントは変更されたコンテンツに応答するのではなく、ファイルを直接変更する必要があります。hello world。
• ファイルが実際に変更されている場合は、編集ツールが呼び出されたことを意味します。 「hello world に変更する必要があります」のみが出力される場合は、現在のモード、権限、モデル、またはツールの設定にまだ問題があります。
• 2番目のステップはそれを作成することですhello.py、スクリプトを実行して出力を確認します。作成、実行、結果の読み込みが順番に完了できた場合のみ、ファイルツール、ターミナルツール、ツール呼び出しがすべて接続されたことになります。

4️⃣ 次に、実際のソフトウェアタスクを入力します

• 最初はテストまたはビルド手順のある中小規模プロジェクトを選び、AgentにTypeScriptのコンパイルエラーを修正させます。その後npm run buildを実行し、失敗する場合は修正を続けます。
• 目標、変更が許可される範囲、実行する必要がある検証コマンド、および停止条件を明確に示すと、単に「修正を手伝ってください」と言うよりも安定した結果を得ることが容易になります。

🐛 バグ修正とコンパイルエラーの自動処理

• Web ページを更新するとログイン ステータスが消えるという問題に直面した場合、エージェントは認証コードを検索し、localStorage とトークンのロジックを確認し、関連ファイルを変更してテストを実行できます。
• npm run buildで複数のエラーが出た場合、Agentはエラーを読み、対象ファイルを特定して修正し、ビルドが通るまで繰り返せます。結果が明確に判定できる作業は、Agentの価値を発揮しやすい分野です。

🧱 関数の追加と複数のファイルの変更

• ブログに記事収集機能を追加する場合、エージェントは単独の機能を生成するのではなく、データベース、API、バックエンド、フロントエンド、スタイル、テストを同時に処理できます。
• 要件には、エージェントが主観的な判断ではなく実際の結果に基づいてタスクを終了できるように、データ構造、ユーザー フロー、互換性要件、および受け入れコマンドを明確に記載する必要があります。

♻️ リファクタリング・依存関係の更新・テストループ

• プロジェクトに信頼性の高いテスト保護がある場合、エージェントは 2,000 行の Python ファイルを分割するときに、依存関係の分析、モジュールの作成、関数の移動、インポートの調整、継続的なテストの実行を行うことができます。
• Reactなどの依存関係を更新する場合は、package.jsonの変更、依存パッケージのインストール、旧APIの修正を行い、ビルドとテストで互換性を確認できます。

🔍 未知のリポジトリを理解し、ゼロからプロジェクトを作る

• 不慣れなプロジェクトに参加した後、エージェントに起動方法、ログイン入り口、データベースの初期化場所、リクエスト リンクを調べてもらうことができます。 Repository searches and cross-file correlations are often less time-consuming than reading file-by-file.
• 個人の会計 Web サイトを最初から作成する場合、エージェントはディレクトリ、フロントエンドとバックエンド、データベース、API を生成し、実際に起動してエラーを修正できますが、それでもアーキテクチャの手動決定とセキュリティ境界のチェックが必要です。

❌ モデルのTool Callingが安定していない

• モデルはedit_file、read_file、Terminalなどから正しいツールを選び、ファイルパスや引数も正確に指定する必要があります。自然言語しか出力できなければ、コードの提案にとどまります。
• 小規模なモデルは、多数のツール定義、プロジェクト ファイル、履歴会話、複雑な要件に直面すると混乱する傾向があります。 Even if the 3B or 7B model nominally supports the tool, it may still fall back to ordinary text answers during long tasks.

🔧 モード・権限・Provider設定が正しくない

• 通常、チャット モードとプラン モードでは実際の変更は実行されないため、エージェント、アクト、またはコード モードに切り替える必要があります。モデルがどれほどスマートであっても、編集権限がオフになっているとファイルに書き込むことができません。
• Ollamaのアドレス、モデル名、コンテキスト、ツール能力の宣言を確認します。連携方法によってはtool_useを明示しないと、利用可能なツールがモデルへ渡りません。
• 最初の診断に複雑なリポジトリを使わないでください。test.txtのhelloテストなら、「モデル能力の問題」と「プロジェクト理解の問題」をすぐに切り分けられます。

🔁 エージェントが複雑なタスクを繰り返したり、目標から逸脱したりする

• ローカル 9B モデルは、間違ったファイルを見つけたり、同じ操作を繰り返したり、1 つのバグを修正して別のバグを導入したり、長いループで元の目標を忘れたりする可能性があります。完全なツールがあるからといって、インテリジェンスのレベルが最強のクラウド モデルに達するわけではありません。
• 通常、大きなタスクを検証可能な小さなタスクに分割し、一度に変更できるディレクトリとファイルの数を制限し、各段階でテストを実行することを要求する方が、「プロジェクト全体を一度にリファクタリングする」よりも安定します。
• コンテキストに無関係なログが蓄積され始めた場合は、コンテキスト ウィンドウを盲目的に最大まで拡張するよりも、フォーカスされたタスクを再度開く方が効果的です。