Windows で WSL + Ollama を使って Hermes Agent をローカル導入し、Telegram に接続する

Windows 上でできるだけ手軽に Hermes Agent を動かしたいなら、比較的やりやすい流れは次の通りです。

• ホスト OS はそのまま Windows を使う
• WSL 内で Ubuntu を動かす
• Ollama でローカルモデルを提供する
• Hermes Agent からローカル Ollama のエンドポイントへ直接つなぐ

この方法の利点は、環境を比較的きれいに保ちやすく、コマンドも Linux 方式でそろえやすいことです。別に Linux マシンを用意しなくても始められます。

全体の流れ

この構成は 4 ステップに分けられます。

1. WSL を有効化して Ubuntu を入れる
2. Ubuntu 内で Python、Node.js、Git などの基本環境を入れる
3. Ollama を入れてローカルモデルを取得する
4. Hermes Agent を入れ、Telegram を接続する

まず Hermes Agent を動かすことだけが目的なら、実質的には 3 ステップ目まででかなり近いところまで行けます。

1. WSL と Ubuntu をインストールする

管理者権限の PowerShell で次を実行します。

1

wsl --install

インストールが終わったら PC を再起動し、そのあと Ubuntu を入れます。

1

wsl --install -d Ubuntu

以降のコマンドは、WSL の Ubuntu 側で実行していきます。

2. Ubuntu を更新し、基本環境を入れる

まずシステムを更新します。

1
2

sudo apt update
sudo apt upgrade -y

そのあと Python、展開ツール、Node.js、Git を入れます。

Python をインストール

1

sudo apt install python3-pip python3-venv -y

zstd をインストール

1

sudo apt install -y zstd

Node.js をインストール

1
2

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Git をインストール

1
2

sudo apt update
sudo apt install -y git

入れ終わったら、軽く確認しておくと安心です。

1
2
3

node -v
npm -v
git --version

3. Ollama を入れて Gemma 4 を取得する

Ollama のインストール:

1

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

Hermes Agent 用にローカルモデルを用意するなら、まずは Gemma 4 から始めるのが無難です。

たとえば:

1

ollama run gemma4:e4b

もしマシンのリソースが弱ければ:

1

ollama run gemma4:e2b

より大きい版としては:

1
2

ollama run gemma4:26b
ollama run gemma4:31b

一般的な Windows + WSL 環境では、gemma4:e4b が現実的な出発点になりやすいです。

4. Hermes Agent をインストールして設定する

インストールコマンド:

1

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

インストール後、Ollama のローカルエンドポイントを指定します。

1

http://127.0.0.1:11434

モデル名には実際に使うものを入れます。たとえば:

1

gemma4:e4b

インストーラから shell の再読み込みを求められたら:

1

source ~/.bashrc

Hermes Agent のよく使うコマンド

普段よく使うのは次のあたりです。

起動

1

hermes

再設定

1

hermes setup

チャットゲートウェイ設定

1

hermes setup gateway

更新

1

hermes update

Telegram 接続の基本手順

Hermes Agent で Telegram の送受信をしたいなら、まずは次を実行します。

1

hermes setup gateway

そのうえで Telegram 側で次の 2 つを用意します。

• BotFather で bot を作成する
• @userinfobot で自分の User ID を確認する

これらを揃えたら、Hermes Agent のゲートウェイ設定に入力していきます。

この構成が向いている人

この方法は、次のような人に向いています。

• メイン環境が Windows
• 別に Linux マシンを用意したくない
• まずはローカル Agent を動かし、その後チャット連携を広げたい
• できるだけクラウド API ではなくローカルモデルを使いたい

最初から本格的な本番環境を組むのではなく、まずローカルで Agent を試したい人には十分実用的です。

注意点

• WSL はあくまで互換レイヤーなので、極端なケースではネイティブ Linux と完全に同じとは限りません
• 大きなモデルが快適に動くかどうかは、RAM、VRAM、CPU / GPU に依存します
• gemma4:e4b は現実的な出発点ですが、最終的な体感はマシン性能次第です
• Hermes Agent のチャット連携は拡張機能なので、まずローカルモデル経路を通してから Telegram を足すほうが安定しやすいです

元記事

この投稿は次のページをもとに整理・リライトしています。

• X超哥博客：太简单了！Hermes Agent 本地部署（无需API）接入 Telegram + 微信

WSL で Ollama と Codex OSS をローカル Agent として接続する

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

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

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

最も陥りやすい罠

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、またはリモート アクセスを検討する前に、最小限のプロセスが安定するまで待ってください。

参照:

• Microsoft Learn: WSL のインストール
• Microsoft Learn: WSL systemd
• Ollama Linux ドキュメント
• Codex OSS ローカル プロバイダー
• Codex 用ローカル大規模モデル API の使用チュートリアル

まとめ

Windows 上でなるべく素直に Hermes Agent をローカル導入するなら、流れは次の順番がやりやすいです。

WSL -> Ubuntu -> Ollama -> Gemma 4 -> Hermes Agent -> Telegram

最初にローカルモデルを確実に動かし、そのあとでゲートウェイ接続を追加すると成功率が上がります。多くのユーザーにとって、最初から部品を積みすぎるよりもこのほうが切り分けしやすく、後から拡張もしやすいです。

代替 backend：Qwen3.6、llama.cpp、ローカル API

Ollama は導入が容易です。GGUF 量子化、GPU offload、context、chat template を直接制御したい場合は llama.cpp を使います。特定の第三者量子化リポジトリに固定せず、信頼できる model card からハードウェアに合う Qwen3.6 GGUF を取得し checksum を記録します。

1
2
3
4
5

sudo apt update
sudo apt install -y git cmake build-essential
git clone https://github.com/ggml-org/llama.cpp.git
cmake -S llama.cpp -B llama.cpp/build -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j

8K context から開始し、実際のモデルパスへ置き換えます。--n-gpu-layers 99 は最大 offload を要求するだけで、VRAM を保証しません。OOM ではレイヤー数または量子化サイズを下げます。

1
2
3
4
5
6

./llama.cpp/build/bin/llama-server \
  --model ~/models/qwen3.6-model.gguf \
  --n-gpu-layers 99 \
  --ctx-size 8192 \
  --host 127.0.0.1 \
  --port 8080

1
2

curl http://127.0.0.1:8080/v1/models
curl http://127.0.0.1:8080/health

hermes setup の custom endpoint を http://127.0.0.1:8080/v1 にし、モデル名には /v1/models の ID、API Key にはローカルのダミー値を設定します。会話、tool call、ファイル権限の順に確認します。文章は返るのに tool call が失敗し続ける場合、ポートよりモデル能力または chat template の不一致が疑われます。

thinking は model card と現在の llama.cpp が対応する引数で制御します。モデル、context、GPU layers、template は一度に一項目だけ変更し、最後に動いたコマンドを残します。127.0.0.1 だけで待ち受け、遠隔利用には reverse proxy の認証と TLS を追加してください。