ローカルエージェントの Windows WSL 導入チュートリアル: Ollama、Codex OSS および権限制御

Windows にローカルエージェントをデプロイする場合、通常、最も安心できる構造は、モデルサービス、Docker、ターミナル、コーディングツールを Windows、WSL、および複数の仮想環境に分散させるのではなく、それらを同じ WSL2 Ubuntu ディストリビューションに配置することです。

1
2
3
4
5
6


Windows
└─ WSL2 Ubuntu
   ├─ Ollama：本地模型服务
   ├─ 本地模型：聊天、代码、Embedding
   ├─ Codex OSS：Agent 客户端
   └─ 项目目录：代码、Git、测试命令

このように、Ollama とエージェントは WSL の localhost を通じて直接通信し、パス、権限、ログはすべて Linux 環境にあります。 Windows 側は、Windows ターミナル、VS Code リモート WSL、またはエクスプローラーを使用してプロジェクトに引き続きアクセスできます。

まず結論から話しましょう

利用可能な最小ルートは次のとおりです。

1
2
3
4
5
6


安装 WSL2 Ubuntu
-> 在 Ubuntu 安装 Ollama 和一个小模型
-> 在 Ubuntu 内验证 ollama run
-> 用 codex --oss --local-provider ollama 启动 Agent
-> 先执行只读任务
-> 再逐步允许修改、测试和工具调用

最初からローカルエージェントに完全な権限を与えたり、最大のモデルを最初に追求したりしないでください。複雑なエージェント、リモートポート、およびマルチエージェントオーケストレーションを最初に扱うよりも、安定して実行できるモデル検証プロセスを最初に使用することが重要です。

ステップ 1: WSL2 と Ubuntu をインストールする

Windows 上の管理者 PowerShell で実行します。

1

wsl --install

再起動後、デフォルトで Ubuntu がインストールされます。初めて Ubuntu を開いたときは、プロンプトに従って Linux ユーザー名とパスワードを作成します。

ディストリビューションが WSL2 を使用していることを確認します。

1

wsl -l -v

古いディストリビューションがまだバージョン 1 である場合は、次のように変換できます。

1

wsl --set-version Ubuntu 2

Ubuntu を入力します。

1

wsl

後続のコマンドのほとんどは、PowerShell ではなく Ubuntu ターミナルで実行されます。

ステップ 2: Ubuntu 基本環境を準備する

WSL に入ったら、まずシステムを更新します。

1
2
3


sudo apt update
sudo apt upgrade -y
sudo apt install -y curl git ca-certificates

環境を確認します:

1
2
3


uname -a
pwd
git --version

プロジェクトを Linux ファイルシステムに配置することをお勧めします。次に例を示します。

1
2


mkdir -p ~/projects
cd ~/projects

/mnt/c/... では、高頻度の Git、Node.js、Python 仮想環境および大規模な依存関係を実行しないでください。一部の開発タスクではファイルシステム間のアクセスが遅くなり、権限やファイルリスニングの違いが発生する可能性が高くなります。 Windows からプロジェクトを開く必要がある場合は、VS Code のリモート WSL 機能を使用できます。

ステップ 3: WSL 内で Ollama をインストールして検証する

Ollama Linux のインストール方法に従います。

1

curl -fsSL https://ollama.com/install.sh | sh

まず、現在のターミナルでサービスを開始します。

1

ollama serve

別の WSL ターミナルを開き、モデルをダウンロードしてテストします。

1
2


ollama pull qwen3:8b
ollama run qwen3:8b

モデルの選択は、GPU メモリまたは CPU/メモリによって決定する必要があります。使用可能な GPU がない場合は、より小さいモデルを使用して最初にプロセスを検証します。「大きなモデルファイルをダウンロードできる」ことを「このマシンはスムーズな推論を実行できる」と誤解しないでください。

サービスとモデルのステータスを確認します。

1
2


ollama ls
ollama ps

ollama run 自体が安定して出力できない場合は、機種、ビデオメモリ、ドライバ、メモリの問題を解決してからエージェントに接続してください。

ステップ 4: WSL GPU が実際に利用可能かどうかを確認する

NVIDIA GPU を使用している場合は、WSL 内で実行します。

1

nvidia-smi

グラフィックスカードを表示できるということは、Ollama が GPU を使用したことを意味するわけではありませんが、少なくとも WSL がドライバーを認識していることを証明しています。モデルを開始した後、次を実行します。

1
2


ollama ps
nvidia-smi

モデルが GPU を使用しているかどうか、およびビデオメモリが増加しているかどうかを観察します。

nvidia-smi が存在しない場合、またはエラーが報告された場合は、まず NVIDIA ドライバー、WSL バージョン、および Windows の GPU サポートを確認してください。急いで Ubuntu にデスクトップ Linux ドライバーを繰り返しインストールしないでください。 WSL の GPU サポートには独自のドライバーリンクがあります。

ステップ 5: Codex にローカルの Ollama を使用させる

Codex は、ローカルプロバイダーとして Ollama または LM Studio のオプションを備えた OSS モードを提供します。 Codex がインストールされ、WSL 内で実行可能になったら、プロジェクトディレクトリに移動します。

1

cd ~/projects/your-project

初めて読み取り専用権限で開始することをお勧めします。

1

codex --oss --local-provider ollama --sandbox read-only

まず、ファイルを変更しないタスクを与えます。

1

阅读当前仓库的 README 和目录结构，说明启动、测试和构建命令。不要修改任何文件。

ローカルモデルがウェアハウスを理解でき、答えが安定していることを確認したら、必要に応じてワークスペースの書き込み権限を使用します。ローカルモデルだからといって、Git、テスト、権限を無視しないでください。

Ollama をデフォルトのローカルプロバイダーとして使用する場合は、ユーザーレベルの Codex 構成に ~/.codex/config.toml を追加します。

1

oss_provider = "ollama"

次に、次のコマンドを使用します。

1

codex --oss

プロバイダー関連の構成は、プロジェクト内の .codex/config.toml ではなく、ユーザーレベルの構成に配置する必要があることに注意してください。プロジェクト構成では、マシンのモデルプロバイダーを密かに変更しないでください。

ステップ 6: 常駐サービスが必要な場合に systemd を有効にする

WSL Ubuntu の新規インストールでは通常、デフォルトで systemd がすでに使用されています。最初のチェック:

1

systemctl status

現在のディストリビューションで systemd が有効になっていない場合は、次を編集します。

1

sudo nano /etc/wsl.conf

参加してください:

1
2


[boot]
systemd=true

次に、Windows PowerShell に戻ります。

1

wsl --shutdown

Ubuntuに再起動した後、systemctl statusを再度確認してください。

Ollama を常駐サービスにするかどうかは、インストール方法とバックエンド API が必要かどうかによって異なります。初めて学習を開始するときは、ollama serve ターミナルを保持してログを確認するのが最も簡単です。安定していることが確認できたら、systemd を使用してサービスを管理します。

WSL 内のパス、ポート、および API

デフォルトでは、Ollama サービスは以下を使用します。

1

http://localhost:11434

エージェント、スクリプト、および Ollama がすべて同じ WSL ディストリビューション内にある場合、このローカルアドレスが最初に使用されるため、最初に LAN ポートを開く必要はありません。

テストAPI:

1

curl http://localhost:11434/api/tags

Windows プログラム、携帯電話、またはローカルエリアネットワーク上のその他のデバイスで呼び出す必要がある場合は、ネットワーク公開方法、リバースプロキシ、および認証を個別に設計する必要があります。公開されたローカルモデルポートをパブリックネットワークに直接マッピングしないでください。

推奨されるリソースの評価

ハードウェアの状況	推奨される開始方法
専用グラフィックスなし、8GB ～ 16GB メモリ	小さなモデル、読み取り専用の分析、要約、および単純なスクリプト
8GBビデオメモリ	7B/8B 量子化モデル、シングルユーザーの短期から中程度のコンテキスト
12GB～16GBのビデオメモリ	8B の方が快適です。注意してより大きな定量モデルを試すことができます
24GB以上のビデオメモリ	より大きなモデル、より長いコンテキスト、またはより複雑なローカルエージェントタスクを検討してください。

モデルが大きいほど、エージェントの信頼性が高いというわけではありません。ローカルエージェントの場合、コマンド実行の安定性、コンテキスト、ツール呼び出し機能、タスク分割方法も結果に影響します。

最も陥りやすい罠

1. Windows と WSL はそれぞれ Ollama のセットを実行します

これにより、エージェントが実際にどのサービスに接続しているかを判断することが困難になります。初期展開では、WSL 内で Ollama のセットを 1 つだけ実行し、すべてのテストを同じ WSL 端末で完了することをお勧めします。

2. `/mnt/c` ですべての開発タスクを実行します。

アクセス可能ですが、インストール、ファイルのリスニング、Git のパフォーマンス、Linux 権限の動作によっては理想的ではない可能性があります。 ~/projects 内のアクティブなプロジェクトに優先順位を付けます。

3. ローカルモデルなので最初からファイルを書き込むことが可能

まず --sandbox read-only を使用して、モデルがタスクを理解しているかどうかを確認します。変更フェーズに入ったら、差分を確認し、テストを実行し、Git を使用してフォールバックポイントを保持する前に、計画について説明させる必要もあります。

4. ポートを開いた後は認証は行われません。

ローカル API に LAN アクセスが許可されると、それは単なる「自分のコンピュータ上のサービス」ではなくなります。ファイアウォールソースを最小限に制限し、必要に応じてリバースプロキシ層で認証と HTTPS を追加します。

5. インストールが成功すると、自動的にバックグラウンドで実行されると考えます。

WSL が閉じられるか、ディストリビューションが停止されると、フォアグラウンドプロセスは終了します。長期的なAPIが必要な場合は、まずsystemd、サービスの状態、Windows/WSLの運用ポリシーを確認してください。

要約する

Windows WSL はローカルエージェントを展開します。最も信頼性の高い最初のバージョンは次のとおりです。

1
2
3
4
5


WSL2 Ubuntu
-> Ollama 跑通小模型
-> Codex OSS 模式只读分析仓库
-> Git 和测试验证
-> 再增加写权限、服务常驻和局域网 API

モデル、エージェント、コードを同じ WSL 環境に維持すると、パス、ポート、権限の問題を半分以下に減らすことができます。 Docker、マルチモデルルーティング、RAG、またはリモートアクセスを検討する前に、最小限のプロセスが安定するまで待ってください。

参照: