この記事は tk3.biz のブログ からの転載です。
はじめに
ここまでの記事で、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 枚レビュー体制を実際の開発で回し続けて、ローカル分の打率がどう動くかを見ていきます。この記事の判断も、その数字次第で変わります。