Hyper-VゲストでローカルLLMを4回失敗して、ホストWindowsのOllamaに逃がした話
Hyper-V のゲスト Windows でローカルLLMを回したかった。Ollama を入れて、モデルを入れて、GPU を見に行って、だめで、またやり直して。気づいたら 4 回失敗していました。
そもそも、ゲストの中で全部やろうとしていた
やりたかったことは単純です。
Hyper-V のゲスト Windows に開発環境を置いて、その中でローカルLLMも動かす。many-ai-cli から Claude Code や Codex を起動して、モデルピッカーで Ollama Local を選んだら、そのまま手元の LLM が返事をする。
うまくいけば、かなり気持ちいい構成です。開発環境はゲストに閉じる。ホスト側は汚さない。失敗したら仮想マシンごと戻せる。
でも、現実はそうきれいにいかなかった。
Ollama は入る。モデルも入る。API もそれっぽく返る。けれど、GPU まわりで詰まる。ドライバなのか、仮想化なのか、Windows の機嫌なのか、ひとつ直したつもりで別のところが怪しくなる。
これを 4 回やった。正直、参った。
そこで、考え方をひっくり返した
途中で、ふと気づきました。
ローカルLLMを「ゲストの中で動かす」必要は、本当にあるのか。
欲しいのは、ゲスト Windows の中から LLM を使えることです。Ollama のプロセスがどこで動いているかは、実はそんなに重要ではない。
だったら、GPU を持っているホスト Windows で Ollama を動かせばいい。ゲストは、その API に HTTP でつなぐだけにする。
つまりこうです。
・ホスト Windows: Ollama とモデルを持つ。GPU で推論する
・ゲスト Windows: many-ai-cli と開発環境を持つ
・ゲストからホストの Ollama API に接続する
これなら、GPU をゲストに渡す話をしなくていい。Ollama はホストの普通の Windows アプリとして動く。ゲストはただのクライアントになる。
これは効いた。
localhost を信じすぎていた
many-ai-cli 側にも、ひとつ問題がありました。
Ollama Local は、もともと `localhost:11434` を見に行く前提でした。普通にホスト OS 上で使うなら、それで正しい。Ollama も Hub も同じマシンにいるからです。
でも、Hyper-V ゲストの中で many-ai-cli を動かしていると、`localhost` はゲスト自身を指します。ホスト Windows ではない。
ここでだいぶ混乱します。
ホスト側では Ollama が元気に動いている。ブラウザや PowerShell から叩けば返る。なのにゲストの many-ai-cli から見ると、Ollama がいないことになる。
「ローカル」と言っているけど、誰から見たローカルなのか。ここを間違えると、ずっと違う住所を見に行く。
many-ai-cli 側には、接続先を持たせた
そこで、many-ai-cli に `ollama.base_url` という設定を足しました。
考え方は単純です。
ollama:
base_url: "http://<host-ip>:11434"この値を、2か所で同じように使います。
・モデル一覧を取るときは `<base_url>/api/tags` を見る
・Claude Code や Codex を Ollama route で起動するときは、子プロセスに `<base_url>` を渡す
Codex は OpenAI 互換 API として見るので、内部では `/v1` を足します。Claude Code は Anthropic 互換 API として見るので、`/v1` は足しません。
このあたりを設定ファイルに寄せたことで、ゲストからホストの Ollama を自然に使えるようになりました。モデルピッカーにもホスト側の pull 済みモデルが出る。起動した Codex も、ゲスト内の空っぽの localhost ではなく、ホスト側の Ollama に向かう。
地味だけど、これでやっとつながった。
Firewall はちゃんと絞る
この構成でいちばん気をつけるのは、Ollama API を外へ開けすぎないことです。
ホスト Windows 側の Ollama は、ゲストから届くように待ち受けを広げる必要があります。ただし、インターネットに出すものではない。
やることは、だいたいこのあたりです。
・Ollama をホストのネットワークインターフェイスで待ち受ける
・Windows ファイアウォール で Hyper-V のゲスト側ネットワークだけ許可する
・ルーターのポート転送はしない
・ゲスト側から疎通確認して、many-ai-cli の `ollama.base_url` を設定する
ここは「動けばいい」で雑にしないほうがいいです。LLM の API は、手元の道具として使うぶんには便利だけど、外から誰でも叩ける場所に置くものではない。
ゲストで全部やる、を諦めたら楽になった
最初は、ゲストの中でローカルLLMまで完結させるのがきれいだと思っていました。
でも、今回の感覚だと、開発環境と推論環境は分けたほうが楽でした。ゲストは壊しても戻せる作業場。ホストは GPU を持っている推論係。間は HTTP API でつなぐ。
分けると、考えることも分かれます。
・開発環境を整える話
・GPU で推論する話
・API の向き先をそろえる話
ごちゃっと一つに押し込むより、ずっと見通しがよかった。
学んだことは、このくらいです。
・`localhost` は、いま動いている側から見た自分自身
・GPU を仮想マシンに持ち込むより、API 越しに借りるほうが早いことがある
・設定値は、モデル一覧取得と実行時 env の両方で同じものを使わないとズレる
・ネットワーク越しにするなら、Firewall の範囲は必ず絞る
4回失敗したあとに書くと、妙に身にしみます。
締め
今回は、Hyper-V ゲストでローカルLLMを動かすのをいったん諦めました。
諦めたというより、置き場所を変えた。LLM はホスト Windows の GPU に任せる。ゲストは API を叩く。many-ai-cli は、その接続先を設定できるようにする。
こういう「全部ここでやる」をやめる判断、個人開発でもけっこう大事だなと思いました。
また似たところで詰まったら、まず「本当に同じ箱に入れる必要があるのか」を疑うところから始めます。小さく。動く形から。
次回記事
※ ヘッダー画像は AI（画像生成）で作成しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。
