2026年 OpenClaw：Windows／Linux への導入とリモート macOS ゲートウェイ接続 — PowerShell と WSL2 の二系統、企業 HTTPS プロキシと Node 版固定の Runbook（再現排錯と FAQ）

2. 意思決定マトリクス：PowerShell・WSL2・Linux

エンジニア一人につき OpenClaw クライアントの主環境を一つに決め、Wiki に残し、.nvmrc または package.json の engines で Node を揃えます。オンボーディングや端末監査では下表をそのままチェックリストにしてください。

3. 7 ステップ展開（再現可能）

ステップ 1 — 目標 Node ラインを固定する

OpenClaw 2026.x は多くのリリースノートで Node 22 LTS を追従します。.nvmrc に 22.x、CLI を使うワークスペースの engines.node をコミットします。

ステップ 2 — 選んだシェルにだけ Node を入れる

Windows PowerShell（fnm 例）：

winget install Schniz.fnm
fnm install 22
fnm use 22
node -v

WSL2 / Ubuntu：

curl -fsSL https://fnm.vercel.app/install | bash
source ~/.bashrc
fnm install 22 && fnm use 22
node -v

ステップ 3 — プロキシ変数とバイパス一覧

大文字の変数名で統一します（ホスト／ポートは置換）：

export HTTPS_PROXY=http://proxy.corp.example:8080
export HTTP_PROXY=http://proxy.corp.example:8080
export NO_PROXY=localhost,127.0.0.1,::1,.corp.example,169.254.0.0/16

Windows では setx またはシステムのプロキシ設定で永続化し、ターミナルを開き直します。

ステップ 4 — 企業 CA チェーンを信頼させる

発行チェーンを PEM で書き出し、Linux/WSL2 の Node では NODE_EXTRA_CA_FILES=/path/to/corp-ca-bundle.pem を OpenClaw と同じプロファイルに載せます。ネイティブ Windows Node は Trusted Root／中間にインポートしてシェル再起動後、npm ping や最小の https.get で確認します。

ステップ 5 — OpenClaw CLI を入れ版を記録する

Artifactory 等の内部ミラーがある場合はそちらのパッケージ名に従います。サポート票には openclaw --version、Node、OS ビルドを必ず添付します。これだけで「謎切断」の半分は切り分けできます。

ステップ 6 — macOS ゲートウェイへトンネル規律を一つにする

SSH -L は CLI と同じ環境で張ります。例：ssh -N -L 18787:127.0.0.1:18787 user@mac-host（ポートは実設定に合わせる）。Tailscale Serve 運用なら、Mac 上の localhost ヘルスが緑であることをクライアント公開の前に確認します。

ステップ 7 — そのシェルから curl で検証する

curl -v http://127.0.0.1:18787/health（ドキュメントのパスに置換）と、Mac 上の 127.0.0.1 への curl を突き合わせます。ここがズレる場合はバインドアドレス、ポート競合、もう一方のサブシステムでトンネルを作った誤りがほとんどです。

4. 引用しやすい数値とポリシーノブ

5. FAQ と症状別トラブルシュート

PowerShell と WSL2 のどちらに入れるべき？

セクション 2 の表を参照してください。誤答は「固定なしで両方」です。セキュリティが Windows 信頼ストア一本なら PowerShell 既定、bash 自動化が主なら WSL2 にコミットしトンネルも同じ場所で張ります。

ブラウザは通るのに npm/pnpm だけ TLS エラー

ブラウザは OS ストアを使い、Node は自動では追従しません。ランタイム向けに CA を直し、診断以外で strict-ssl=false を残さないでください。

PowerShell では curl が通るが WSL2 では通らない

転送を Windows で張り、プロセスは WSL2 にある（またはその逆）パターンです。OpenClaw を動かすサブシステム側でトンネルを作り直すか、Windows ビルドの WSL ホスト転送ドキュメントに沿ってアドレスを合わせます。

トンネル越しに HTTP 502 や真っ白 UI

まず Mac の localhost で curl が通るか確認します。Mac 単体で失敗ならゲートウェイと launchd ログ。Mac で成功なら -L の順序、ローカルポート衝突、ループバックが HTTP なのに HTTPS 前提だった誤りを疑います。

6. 物理 Mac ゲートウェイを Apple Silicon に置く理由

本 Runbook のクライアント側対応は全体の半分に過ぎません。OpenClaw ゲートウェイを macOS で動かすと、並列エージェント負荷に Apple Silicon の統合メモリ帯域が効き、launchd と相性のよい 7×24 運用、CI と同型の Unix ツールチェーンをそのまま使えます。Mac mini クラスはアイドル時 約 4W 前後と言われ、SSH 転送とヘルスプローブを常時張る説明コストがタワー PC より低くなります。

Gatekeeper・SIP・FileVault が重なり、長寿命トークンを載せるゲートウェイでは、典型の Windows ラップトップ SOE よりドライバインストール系の脅威面が小さくなりがちです。セクション 3 の経路を「退屈に安定」させたいなら、ゲートウェイは静音で効率のよい Apple ハードに置き、Windows／Linux は統制されたクライアントに限定するのが筋です。

分散チームでゲートウェイを標準化するなら、2026 年時点で Mac mini M4 は遅延と電力コストのバランスが取りやすい選択肢です。ZoneMac で物理 macOS ノードを確認し、本稿の手順を本番相当のホストに載せ替えてください。