LM StudioとOpenCodeでつくるローカルAI開発環境 ― Windows 11とRTX 2080 8GBから始める
ローカルLLMを試すだけなら、最近はそれほど手間がかからなくなりました。モデルをダウンロードしてチャットするだけなら、GUIを備えたLM Studioで十分です。
もう一歩進めて、AIに既存のソースコードを読ませ、修正案を作らせたり、テストコマンドを実行させたりしたい場合は、OpenCodeを組み合わせる方法があります。LM Studioがモデルを実行し、OpenCodeが開発作業を担当する構成です。
今回は、Windows 11にLM StudioとOpenCodeを入れ、GeForce RTX 2080（VRAM 8GB）を利用する手順を整理しました。まずはWindowsだけで接続を確認し、必要になった段階でWSL2やDockerへ広げる方針です。
確認日：2026年10月30日
以下は公式資料を確認して作成した構築・検証手順です。この構成での実機動作や処理速度は、まだ測定していません。モデルやアプリの更新によって画面・設定項目が変わる可能性があります。
1. LM StudioとOpenCodeは何が違うのか
最初に役割を分けておきます。
| ソフトウェア | 役割 | 主な作業 |
|---|---|---|
| LM Studio | ローカルLLMの管理・実行 | モデルの検索、ダウンロード、GPU設定、チャット、ローカルAPI公開 |
| OpenCode | AIを利用する開発エージェント | ファイルの調査、コード編集、コマンド実行、テスト結果の確認 |
LM Studioで動かしたモデルは、通常はそのままではPC内のソースコードを自由に編集しません。チャットでコードを生成しても、ファイルへの反映は別の作業です。
OpenCodeは、その間をつなぎます。たとえば「このPythonプロジェクトのエラー原因を調べ、修正後にpytestを実行してください」と指示すると、モデルからのツール呼び出し要求に従ってファイルやコマンドを操作します。ただし、修正の品質はモデルの能力にも左右されます。必ず正しいコードができるわけではありません。
図1 OpenCodeが開発作業を管理し、LM StudioのローカルAPIを通じてLLMを使います。GPUは主にLM Studio側の推論で使用します。
この構成では、OpenCodeとLM Studioの間はローカルHTTP APIで接続します。標準的なLM Studioの接続先は http://127.0.0.1:1234/v1 です。
2. 今回使用するPC
想定している環境は次のとおりです。
| 項目 | 構成 |
|---|---|
| OS | Windows 11 |
| CPU | Intel Core i5-14600KF |
| メモリ | 64GB |
| GPU | NVIDIA GeForce RTX 2080 |
| GPUメモリ | 8GB |
| LLM実行 | LM Studio（Windows版） |
| 開発エージェント | OpenCode V2 |
| 開発ツール | PowerShell、Git、Python、必要に応じてVS Code |
LM Studioの公式要件では、Windows x64環境にAVX2対応CPUが必要で、16GB以上のRAMと4GB以上の専用GPUメモリが推奨されています。今回のPCは、この条件を満たします。
ただし、注意したいのはGPUメモリです。64GBのシステムメモリがあっても、RTX 2080のVRAMが64GBになるわけではありません。VRAMに収まらない処理をCPU側へ分担すると、実行できるモデルが増える一方、速度が落ちる場合があります。
モデルを選ぶときの考え方
最初から大きなモデルを読み込むより、4B程度のモデルで接続を確認する方が扱いやすいでしょう。
| モデルの候補 | 使い道 | このPCでの位置付け |
|---|---|---|
| Qwen3.5 4Bの4bit量子化版 | チャット、簡単なコード修正、ツール呼び出し | 最初の候補 |
| Qwen2.5 7B Instructの4bit量子化版 | モデル間の品質・ツール動作比較 | 次に比較する候補 |
| 9B前後の4bit量子化版 | より複雑な指示の比較 | メモリに注意 |
| 14B以上 | 大きなコードの解析など | CPU併用や低速化を想定 |
LM Studioのモデル一覧には、Qwen3.5 4Bの配布容量の目安として約3.75GBという例が掲載されています。ただし、モデルファイルの容量と実行時のVRAM消費量は同じではありません。推論時にはKVキャッシュや作業領域も必要です。
図2 コンテキスト長を増やすほどメモリ負荷が高くなります。色の比率は説明用の模式図です。
OpenCodeでは、会話だけでなく、ファイルの中身、ツールの実行結果、編集履歴などもコンテキストに入ります。そのため、短いチャットでは問題のない設定でも、開発作業を続けると重くなることがあります。
今回はまず 16K（16,384トークン） で動作確認し、問題がなければ32K、必要に応じて64Kを試します。64Kが設定できたとしても、8GB VRAMで快適に動くとは限りません。長いコンテキストが必要な作業では、応答速度とGPUメモリ使用量の測定が欠かせません。
3. Windows 11へLM Studioをインストールする
まず、GPUが認識されていることを確認します。PowerShellで次を実行します。
nvidia-smi
GPU名、ドライバーバージョン、VRAM使用量などが表示されれば、次へ進みます。
LM Studioは公式サイトからWindows版をインストールします。
起動したら、モデル検索画面（Discover）から Qwen3.5 4B を探します。WindowsとNVIDIA GPUの組み合わせでは、まずGGUF形式の4bit量子化モデルを選びます。配布されている量子化形式はモデルによって異なります。
ダウンロードできたら、Chat画面でモデルを読み込みます。最初の読み込みでは次の値を目安にします。
| 設定項目 | 最初の目安 |
|---|---|
| モデル | Qwen3.5 4B GGUF |
| 量子化 | Q4系 |
| GPU Offload | 自動設定または最大値を試す |
| Context Length | 16,384 |
| 同時実行 | まず1セッション |
LM Studioには読み込み前のメモリ推定機能があります。設定変更時には推定容量を確認し、VRAMに余裕があるかを見てください。いきなり64Kのコンテキストで始める必要はありません。
モデルの読み込み後、Chat画面で簡単な質問をします。
Pythonで2つの数値を加算する関数を作成してください。型ヒントと日本語のdocstringも付けてください。
応答が返れば、LM Studio単体での基本動作は確認できました。この段階では、OpenCodeによるファイル編集の動作確認はまだ終わっていません。
4. LM StudioのローカルAPIを起動する
次はOpenCodeから接続できる状態にします。
LM StudioのDeveloper画面でローカルサーバーを起動します。標準のポートは 1234 です。外部ネットワークに公開する必要はないため、まずはローカルホストのままで利用します。
CLIを使う場合は、LM Studioを一度起動したあとにPowerShellで次のように実行できます。
# LM StudioのCLIが利用できるか確認
lms --help
# ダウンロード済みモデルを確認
lms ls
# 読み込み済みモデルを確認
lms ps
# ローカルAPIをポート1234で開始
lms server start --port 1234
サーバーが起動したら、別のPowerShellでモデル一覧を取得します。
Invoke-RestMethod `
-Uri "http://127.0.0.1:1234/v1/models" |
ConvertTo-Json -Depth 6
ここでモデルIDを含むJSONが返ってくれば、APIの接続確認ができています。エラーになる場合は、LM Studioでサーバーが起動しているか、モデルがロードされているか、ポートが1234になっているかを確認します。
lms コマンドからモデルを読み込む場合は、lms ls で表示された実際のモデルキーを使います。
# 次の文字列は実際のモデルキーに置き換えてください
$modelKey = "モデル一覧で確認したキー"
# 16Kコンテキストでメモリを事前推定
lms load $modelKey --estimate-only --context-length 16384
APIサーバーを
0.0.0.0で待ち受けるとLAN上からアクセスできる場合があります。最初は変更せず、Windows内の127.0.0.1で確認する方が安全です。
図3 GPU確認からモデルのダウンロード、API起動、OpenCode接続までの流れです。
5. OpenCode V2をインストールする
OpenCodeにはバージョン系列の違いがあり、V1とV2ではインストール方法や設定ファイルの書式が異なります。ここではOpenCode V2を使います。
Windows版はデスクトップアプリとCLIがあります。LM Studioと接続してソースコードを調査・修正する用途では、PowerShellから操作できるCLIが使いやすいでしょう。
CLIを使う場合はNode.jsをインストールし、PowerShellで次を実行します。
node --version
npm --version
# OpenCode V2のCLI
npm install -g @opencode/cli
# インストール確認
opencode --version
V2用のパッケージは @opencode/cli です。V1系で使用する別パッケージと混同しないようにしてください。
LM Studioのモデルを選択する
作業用ディレクトリを作り、OpenCodeを起動します。
New-Item -ItemType Directory -Force "$HOME\llm-dev"
Set-Location "$HOME\llm-dev"
opencode
OpenCodeを起動したら、モデル選択画面を開きます。
/models
OpenCode V2は既定のローカルアドレスにあるLM Studioを自動検出できます。LM Studioのモデルが表示されたら、それを選びます。モデル名を手入力して推測するより、表示された候補から選ぶ方が確実です。
一覧に出ない場合は、まずLM Studio側のAPIが http://127.0.0.1:1234/v1/models で取得できるかを確認します。
6. OpenCodeの権限を設定する
接続できたら、すぐに大きなプロジェクトを操作させるのではなく、ファイル編集とコマンド実行に承認が必要な設定へ変更しておきます。
作業ディレクトリに opencode.jsonc を作成し、以下の内容を保存します。
{
"$schema": "https://opencode.ai/config.json",
"default_agent": "plan",
"permissions": [
{ "action": "shell", "resource": "*", "effect": "ask" },
{ "action": "edit", "resource": "*", "effect": "ask" },
{ "action": "external_directory", "resource": "*", "effect": "deny" },
{ "action": "webfetch", "resource": "*", "effect": "deny" },
{ "action": "websearch", "resource": "*", "effect": "deny" },
{ "action": "shell", "resource": "git push *", "effect": "deny" },
{ "action": "read", "resource": "*.env", "effect": "deny" }
]
}
この設定では、一般的なシェルコマンドと編集の実行時に承認を求めます。プロジェクト外へのファイルアクセスとOpenCodeのWeb取得ツールも制限します。
V2では permissions と shell を使います。 V1の permission と bash を混ぜると意図した設定になりません。
ここで設定しているのはOpenCodeのツール権限です。承認したシェルコマンドによる外部通信まで完全に防げるわけではありません。秘密情報を含むプロジェクトでは、権限設定だけに依存せず、別のテスト用ディレクトリやWindows側の通信制限も組み合わせます。
7. Pythonプロジェクトでファイル修正を試す
ここからがOpenCodeの動作確認です。最初は小さなPythonプロジェクトを用意し、編集とテスト実行の一連の流れを確認します。
PowerShellで以下を実行します。
Set-Location "$HOME\llm-dev"
git init
# Python実行環境
py -m venv .venv
# PowerShellの実行ポリシーを変更しなくても利用できる書き方
.\.venv\Scripts\python.exe -m pip install pytest ruff mypy
# OpenCodeを起動
opencode
Planでコードを調べる
最初はPlanエージェントで、次のように依頼します。
このプロジェクトの構成を調べてください。Pythonで2つの数値を加算する関数と、そのpytestテストを作るための計画を考えてください。まだファイルは変更しないでください。
Planは主に調査や計画に用いるエージェントです。OpenCodeの計画ファイルについては書き込みが行われる場合があり、シェルコマンドも権限設定の対象になります。
Buildでファイルを作成する
内容を確認したらBuildエージェントへ切り替え、次を指示します。
先ほどの計画に沿って、型ヒントと日本語docstringを付けた加算関数を作成してください。pytestによる正常系・異常系のテストも作り、ruff、mypy、pytestを実行してください。ファイル編集とコマンド実行は確認を取ってから行ってください。
OpenCodeがファイルの書き込みやコマンド実行を要求したら、その対象を確認して承認します。
処理が終わったら、PowerShellから自分でもテストします。
.\.venv\Scripts\python.exe -m pytest -q
.\.venv\Scripts\python.exe -m ruff check .
.\.venv\Scripts\python.exe -m mypy .
git status --short
AIが「テストは成功しました」と返すことと、テストが実際に成功していることは別です。コマンドの終了コードやテスト結果を確認することが大切です。
図4 調査から差分確認までを一巡させ、失敗した場合は原因調査へ戻します。
8. FortranやDockerで使う場合
Pythonでのテストが成功したら、Fortran 2018、Rust、Dockerを使うプロジェクトでも同じ考え方を利用できます。
| 開発対象 | OpenCodeに依頼する内容 | 最後に確認する項目 |
|---|---|---|
| Python | 型ヒント、バグ修正、テスト追加 | ruff、mypy、pytest |
| Fortran 2018 | 処理の追跡、ルーチン修正、並列化案の検討 | fpm test、数値結果の比較 |
| Rust | APIやエラー処理の修正 | cargo test、cargo clippy |
| Docker Compose | 設定内容や起動エラーの調査 | docker compose config、起動ログ |
| 数値シミュレーション | 境界処理の点検、回帰テストの整備 | 保存則、境界条件、基準解との照合 |
特に数値シミュレーションでは、テストが通っても物理的に正しい計算になっているとは限りません。水量保存や境界条件など、モデル固有の検証を別に用意しておきます。
プロジェクト共通の開発ルールは、ルートディレクトリに AGENTS.md を置いて指定できます。
# 開発ルール
- 既存コードを先に調査し、原因が分かるまでは修正しない
- 不明な仕様を推測で補わない
- 変更は最小限にする
- Pythonの変更後はruff、mypy、pytestを実行する
- Fortranの変更後はfpm testと数値比較を実行する
- 数値計算では保存則と境界条件を確認する
- git pushを無断で実行しない
- 修正ファイル、理由、未実施のテストを最後に報告する
ただし、AGENTS.md はAIへの指示をまとめたファイルです。操作を機械的に禁止する設定ではないので、重要な制限は opencode.jsonc の権限設定にも入れておきます。
9. WSL2へ広げる場合
今回は両方をWindows 11上で動かす前提ですが、既にWSL2 Ubuntu 24.04で開発している場合、次の分担も考えられます。
- Windows 11：LM Studio、GPU推論
- WSL2 Ubuntu：OpenCode、Python、Fortran、Rust、Docker Compose
OpenCodeはWSL2のファイルシステム内で実行し、Windows側のLM StudioへHTTPで接続します。ただし、WSL2のネットワークが既定のNAT構成かミラーモードかによって、接続先アドレスが変わります。
最初の検証段階では、Windows側のOpenCodeとLM Studioを同一ホストの 127.0.0.1 で接続する方が分かりやすくなります。Windows上で動作した後、WSL2側の通信とファイル操作を順番に確認すれば、問題を切り分けやすくなります。
10. RTX 2080 8GBで確認したい点
「起動した」「返事が来た」だけでは、開発環境として使えるかは分かりません。次の条件を記録して比較すると、モデルの違いを判断しやすくなります。
| ケース | モデル | コンテキスト | 確認内容 |
|---|---|---|---|
| C01 | Qwen3.5 4B（Q4系） | 16K | API接続、ファイル検索、簡単な編集 |
| C02 | Qwen3.5 4B（Q4系） | 32K | コード読込量と速度の変化 |
| C03 | Qwen2.5 7B Instruct（Q4系） | 16K | ツール呼び出しと修正品質の比較 |
| C04 | Qwen3.5 4B（Q4系） | 64K | メモリに収まるか、速度はどうか |
比較時には別のPowerShellで nvidia-smi -l 1 を実行すると、GPU使用率やVRAM使用量を継続して観察できます。LM Studio側のGPU Offloadやメモリ推定も併せて確認します。
記録項目としては、モデル名、量子化形式、コンテキスト長、VRAMの最大使用量、処理時間、ツール呼び出しの成否、pytestの結果などが考えられます。品質面では、ソースを正しく修正できたか、不要なファイルまで変更していないかも評価したいところです。
よくある問題
| 症状 | 確認箇所 |
|---|---|
OpenCodeの /models に表示されない |
LM Studioのサーバー状態、ポート1234、モデルのロード |
| チャットはできるが編集を行わない | Tool Calling対応、モデルの選択、権限設定 |
| 応答が遅い | GPU Offload、VRAM、コンテキスト長、CPUへの処理分担 |
| 設定を読み込まない | OpenCode V1/V2の混在、opencode.jsonc の置き場所 |
| テストが通らない | 実行したコマンド、依存関係、テストケース、変更差分 |
また、ローカルモデルを選んだだけで、OpenCodeを含むすべての通信が自動的に遮断されるわけではありません。外部検索や拡張機能を利用する場合は通信内容に注意し、必要に応じてファイアウォールで制限します。
11. まとめ
LM StudioとOpenCodeは、役割が重ならないため組み合わせやすい構成です。LM Studioはモデルの選択やGPUメモリの調整をGUIから行いやすく、OpenCodeはファイル編集とテストを含む開発作業を担当します。
今回のRTX 2080 8GBでは、大きなモデルを最初から使うより、Qwen3.5 4Bの4bit量子化モデルでAPI接続とツール呼び出しを確認するのが現実的です。その上で、7Bモデルや長めのコンテキストを比較すれば、このPCで無理なく使える範囲が見えてきます。
実用段階では、AIに修正を任せきりにせず、差分とテスト結果を確認する習慣が重要になります。特に数値計算のプログラムでは、ビルド成功だけでなく、保存則や計算精度まで確認する必要があります。
次は、この環境を使って実際のPythonプロジェクトを修正し、OpenCodeのツール実行とGPU負荷を測定する形に進めるとよいでしょう。