WindowsでローカルAIコーディングを始める方法｜Bionic・Ollamaの選び方

先に結論：コーディングの入口は3通りに分ける

ローカルAIコーディングは、チャットでコードを説明させるだけなのか、ローカルフォルダを読ませて編集まで行うのか、エディタやスクリプトからAPIで呼ぶのかで必要な構成が変わります。アプリ名を先に決めるより、作業の深さとコードの送信先を先に決めるほうが迷いにくくなります。

最初の課題は、公開またはコピーした小さなプロジェクトの1ファイルだけにします。読み取り、提案、差分確認、テストの順に進め、削除・上書き・外部送信を伴う作業は後回しにしてください。

• WindowsローカルAIエージェント比較 - Bionic、Ollama、AnythingLLM、Hermesの役割を先に比較する
• ローカルAIのAPI入門 - エディタやスクリプトへつなぐ前提を確認する
• GGUFモデルの選び方 - agentの前にモデル単体を動かす順番を見る

モデル・runtime・agentを混同しない

「ローカルモデル」と「ローカルで完結するコーディング作業」は同じ意味ではありません。モデルがPCで推論していても、拡張機能の設定、web検索、MCP、cloud fallback、ログやGitHub連携が別の経路を持つ場合があります。

• ローカルAIのプライバシーと通信経路 - 入力・保存・provider・toolを分けて確認する
• MCPとは - 外部ツールやコードへ権限を広げる前に読む
• ローカルAIエージェントのPC負荷 - 長文contextとtool loopの負荷を確認する

LM Studio BionicでCode Projectを始める

LM Studioの公式Bionic docsでは、Code Projectを選んだローカルフォルダをworking directoryとして扱い、ファイル、検索、Git、shellなどのtoolsを使う流れが説明されています。通常のLM Studio chatでコードを貼り付ける方法とは、ファイルへ触れる範囲が異なります。

1. まずGitの作業ツリーを確認し、必要なら元リポジトリのコピーか専用branchを用意する。
2. Bionicでは変更してよいフォルダだけをCode Projectのworking directoryに選ぶ。秘密鍵、.env、顧客データを同じ範囲へ置かない。
3. 最初のsessionでは「読む・構成を説明する」だけを依頼し、対象ファイルと推測を確認する。
4. 次に1つの小さな変更を依頼し、Git diff、テスト、lintを人が確認してから次の作業へ進む。

Bionicはlocal modelだけでなく、公式docsが案内するlocal、remote、cloudの選択肢を持ちます。Code Projectを作ったことだけで推論先や通信が自動的にlocalになるとは考えず、sessionごとのmodel表示、料金、入力範囲、保存と連携を確認してください。

• Bionic公式ガイド - Code Project、local/cloud、ファイル・Git・shellの説明を見る
• Projects and Sessions - working directoryとsessionの分け方を確認する
• Bionicのlocal/cloud境界 - LM Studio本体とBionicの実行場所を整理する

OllamaとPiでターミナル型のcoding agentを試す

Ollamaの公式Pi integrationは、Piをminimal and extensible coding agentとして扱い、`ollama launch pi`で必要なセットアップとOllama providerの設定を行う流れを示しています。Piのcore toolsにはread、write、edit、bashが含まれるため、チャットの回答を見るだけでなく、ファイルやコマンドの権限を最初から狭く考えます。

ollama launch pi
ollama launch pi --config

上のコマンドはOllama公式docsにある入口です。実行する前に、Piが使うproviderとmodel、localかcloudか、作業ディレクトリ、追加extensionの権限を確認してください。公式例にはcloud modelの指定もあるため、「Ollamaを使う＝すべてlocal」とは限りません。

• Ollama Pi公式docs - 起動、model指定、core tools、extensionを確認する
• Ollama公式FAQ - local/cloud、localhost、VS Code連携、GPU表示を見る
• Ollamaのlocal/cloud比較 - モデル実行場所とcloud fallbackを分ける

VS Codeや自作スクリプトからAPIで使う

チャット画面ではなくVS Codeや自作スクリプトから呼びたい場合は、agentを新しく入れる前にruntimeのAPIを確認します。LM StudioとOllamaにはAPIの入口がありますが、OpenAI互換という名前だけでendpoint、tool calling、streaming、認証、context、エラー形式が同じになるわけではありません。

1. LM StudioまたはOllamaで、モデル単体の短い応答を確認する。
2. APIのbase URL、path、model ID、認証、localhost公開範囲を公式docsと実際の設定で照合する。
3. エディタ拡張やスクリプト側で、送信するファイル、履歴、ログ、fallback先を確認する。
4. 読み取り専用の質問から始め、編集・shell・MCPは一つずつ追加する。

Ollamaの公式FAQはVS CodeなどにOllamaを利用するpluginがあると案内していますが、個別extensionの仕様までは一律ではありません。拡張機能の説明、model provider、データ送信先をその拡張機能の公式資料で確認し、既存のAPI記事と接続トラブル記事を使って切り分けます。

• LM Studio REST API - native RESTと互換APIの違いを見る
• LM Studio tool use - tool callingの対応条件を確認する
• ローカルAI APIサーバー入門 - base URL、model ID、互換APIを初心者向けに整理する

安全なコーディング作業の順番

• 対象リポジトリをコピーまたはbranchで分離し、AIが変更してよい範囲を決める。
• 最初はコードの説明、検索、テスト案など読み取り中心の依頼にする。
• 変更は1テーマに絞り、差分を読んで不要なファイル変更がないか確認する。
• テスト、lint、buildを人が実行し、AIの「成功しました」という文だけで判断しない。
• API key、.env、秘密鍵、顧客データ、未公開コードをproviderやweb toolへ渡さない。
• 削除、上書き、shell、外部投稿、課金APIは明示確認を挟む。

ローカルAIを選んでも、ファイル操作やshellを許可した瞬間に失敗時の影響範囲が広がります。コード生成の品質だけでなく、戻せること、差分が読めること、実行ログが残ることを優先してください。

• ローカルLLMの安全性とprivacy - ログ、provider、MCP、権限の確認へ進む
• ローカルAIのよくあるトラブル - 重い・止まる・接続できない時の一般的な切り分け
• Hermes Desktopの始め方 - 別のagent操作環境とproviderの境界を比較する

PC負荷とモデル選びはコーディング作業単位で考える

コーディングでは、質問1回の生成速度だけでなく、リポジトリの読み込み、context、ファイル検索、tool call、再試行、テスト結果の読み込みが重なります。モデルサイズだけで動作可否を決めず、メモリ、VRAM、ストレージ空き容量、同時起動アプリ、許容できる待ち時間を合わせて見ます。

最初のモデルは「一番大きいモデル」ではなく、短いコード説明と小さな修正を最後まで確認できるものを選びます。同じ課題、同じファイル、同じ実行条件で比較し、速度・メモリ・差分品質を別々に記録してください。

• ローカルAIのモデルサイズ早見表 - モデルサイズとメモリの関係を見る
• メモリ8GB・16GB・32GBの目安 - agentのcontextと同時アプリも含めて考える
• agentのPC負荷ガイド - tool loopとKV cacheを分解する

うまくいかないときの最初の分岐

再インストールを繰り返す前に、モデル単体、runtime、agent、API、作業フォルダのどの層で失敗しているかを一つずつ確認します。接続エラーはHermesやAPIの記事、モデルロードの問題はLM Studio/Ollamaのトラブル記事へ分けてください。

• LM Studio・Ollamaの違い - GUI型とAPI/runtime型を比較する
• OllamaのGPU確認 - CPU/GPUの見え方を確認する
• LM Studio接続トラブル - server、port、model IDを切り分ける