WSLからホストのローカルLLMを使う方法を調べて、やめた WSLからホストのローカルLLMを使う方法を調べて、やめた

はじめに

ここまでの記事で、Windows 機に ローカルLLM環境を作り、 ターミナルから常用できるようにし、 dev-orchestra のレビュアーに組み込みました。

次に思いつくのは当然これです。WSL 側の開発でも、このレビュアーを使いたい。

結論から言うと、やめました。できないからではなく、 引き合わないと判断したからです。

やらなかった話なので手順書ではありません。 同じことを考えた人が、同じ調査をやり直さずに済むように書いています。

現状の確認

まず事実を測りました。

llama-server の待受 : 127.0.0.1:8080   ← ループバックのみ
WSL (kizuna4) の IP : 172.22.59.21
デフォルトゲートウェイ: 172.22.48.1
.wslconfig           : なし（= 既定の NAT モード）

この時点で WSL からは届きません。 127.0.0.1 に束縛されているので、 別ホスト扱いの WSL からの接続は受け付けません。

もう一点。NAT モードなので、WSL から見たホストは localhost ではなく ゲートウェイの 172.22.48.1 です。しかもこの IP は WSL を再起動すると変わります。

ホストのコマンドは呼べる

「WSL から Windows のコマンドは実行できるのか」を先に確かめました。できます。

$ powershell.exe -NoProfile -Command 'Write-Output interop-ok'
interop-ok

$ ls /mnt/c/Projects/local-llm/bin/
local-llm.cmd  local-llm.py

WSL interop が有効で、/mnt/c 越しにホストのファイルも見えています。 つまり経路は 2 つあることになります。

A案: HTTP で繋ぐ

--host 0.0.0.0 で待ち受けさせ、WSL から HTTP で叩きます。 WSL 側に既存の CLI を置けば、アダプタはほぼそのまま動きます。

技術的にはこれが素直です。WSL から見ればただのリモート API で、 文字コードもパスも関係しません。速度面でも有利です。

問題は 2 つありました。

1 つ目は IP が変わること。 ゲートウェイの IP は WSL 再起動で変わるので、 毎回解決する仕組みが要ります。.wslconfig でミラーモードにすれば localhost で届くようになりますが、今度はネットワーク構成全体を変えることになります。 LLM を使いたいだけで、WSL のネットワークモードを変えるのは釣り合いません。

2 つ目が本命で、0.0.0.0 の意味です。 これは同一 LAN 上の誰からでも 叩ける状態です。llama-server に認証はありません。

自宅の固定 LAN だけで使うなら許容範囲でしょう。 ただしこの機体はミニPCとはいえ持ち出す可能性があります。 カフェや客先の Wi-Fi に繋いだ瞬間、同じネットワークにいる全員に 無認証の LLM エンドポイントを開くことになります。

「持ち出すときだけ止める」運用は、忘れたときに気づけないのが怖いところです。 静かに開いているだけで、エラーも何も出ません。

B案: interop でホストのコマンドを呼ぶ

WSL 側のアダプタが /mnt/c/Projects/local-llm/bin/local-llm.cmd を直接起動します。 ネットワーク設定は一切不要で、ホストは 127.0.0.1 のまま。外に開きません。

安全性の問題は消えます。が、別の問題が来ます。

この一連の作業で、Windows 境界をまたぐたびに想定外を踏んできました。

踏んだ罠	内容
.cmd の文字コード	REM に日本語を書いたら、cmd.exe が壊れたバイト列をコマンドとして解釈した
Store 版 Python	%APPDATA% のパス文字列は同じなのに実際の読み書き先が違う。同じファイルが 0 バイトと 705 バイトに見えた
パイプ時の cp932	stdin/stdout がパイプだと UTF-8 にならず、日本語が壊れる（レビューで指摘されて修正）

B案は、この境界に 19,000 トークンの差分を stdin で流すという話です。 3 回連続で足をすくわれた場所に、いちばん大きな荷物を通すことになります。

動かないとは言いません。ただ、動かないときの原因究明が高くつくのは目に見えています。 しかも失敗の出方が毎回「静かに壊れる」でした。

見送った理由

整理するとこうなります。

	差し出すもの
A案	安全性	持ち出し先で無認証のまま開く
B案	信頼性	既に 3 回踏んだ境界に、最大の荷物を通す

そして、得られるものを見直しました。

• ローカル LLM のレビュアーとしての打率は、直近の実測で 6 件中 1 件
• 残り 5 件は却下で、うち複数は「推測を欠陥として提起する」類
• WSL 側には既に Claude と Codex のレビュアーが普通に使える

つまり、リスクを負って繋ぐ先が、まだ 3 枚目の補助でしかないわけです。 打率が商用モデルと肩を並べているなら話は別ですが、現状はそうではありません。

「できるからやる」と「やる価値があるからやる」は違う、というだけの話でした。

やるとしたらの条件

将来やるなら、どちらかが変わったときだと思っています。

A案が通る条件 — 持ち出さない据え置き機にする、 あるいは llama-server の手前に認証付きのリバースプロキシを置く。 後者は構成が一段増えるので、それに見合う頻度で使うようになってからです。

B案が通る条件 — ローカル LLM の打率が上がって、 境界の面倒を引き受ける価値が出てくる。

どちらも「今はまだ」であって、「永久にない」ではありません。

まとめ

• WSL から Windows ホストのコマンドは実行できる（interop は動く）
• ホストの LLM に届く経路は HTTP と interop の 2 つ。どちらも実現可能
• ただし A は認証なしで LAN に開く、B は境界をまたぐ不安定さを引き受ける
• 得られるのは「打率 1/6 の 3 枚目のレビュアー」。釣り合わないので見送った

調べた結果が「やらない」でも、調べた価値はありました。 やらない理由が言語化できていれば、条件が変わったときに判断し直せます。 なんとなく手を出さなかった場合、半年後にまた同じところから調べ直すことになります。

次は、3 枚レビュー体制を実際の開発で回し続けて、 ローカル分の打率がどう動くかを見ていきます。 この記事の判断も、その数字次第で変わります。