01. 三つの痛み：Node ドリフト、18789、分裂したシェル

1）Node 22 未満：OpenClaw は Node.js 22+ を前提にします。WSL と PowerShell で別バイナリが PATH にいると、doctor は片方だけ成功します。

2）ポート 18789：他プロセスや古いゲートウェイが掴んでいるのに、WSL の localhost 転送で見え方がズレることがあります。

3）設定の二重化：/home と C:\Users で秘密鍵や env が一致しません。詳しくはコマンドエラー FAQ。

プロキシ・AV・VPN 変更後は doctor を再実行し、マスクした成功ログをベースライン保存してください。

企業ネットワークでは TLS インスペクション付きプロキシ が npm/Git を挟み、リアルタイム AV が巨大な展開を遅らせ、GPO が特定インターフェースのリスンを禁じることがあります。OpenClaw の欠陥ではありませんが工数を食います。ゲートウェイを 127.0.0.1 のみに留めるか 0.0.0.0 で意図的に公開するかを文書化し、インストールガイドのセキュリティ方針と揃えてください。

openclaw doctor は離陸前チェックリストとして扱い、Hyper-V／vSwitch 更新、ルート証明書ローテ、社内 VPN 切替のたびに再実行します。マスク済み成功出力の差分は三ヶ月後の手掛かりになります。

オンボーディング資料では警告と起動を止めるブロッカーを分け、見た目の警告に時間を溶かさないようにします。

ドメインアカウントとローミングプロファイルではログイン前後でホームパスが変わり、doctor に断続的な権限エラーが出ることがあります—バイナリ破損ではありません。

観測性の観点では、ゲートウェイの bind アドレス、親子プロセス関係、WSL と Windows の二重起動の有無をメトリクス化しておくと、インシデント後の因果整理が速くなります。付箋メモより、マスク済み doctor 出力を週次でアーカイブする方が監査やサポートにも通りやすいです。

02. 比較表：WSL2・ネイティブ・クラウド Mac リハーサル

観点	WSL2	ネイティブ	クラウド Mac
Linux 本番との一致	高い	やや低い	macOS ワークフローに最適
18789 の切り分け	Linux と Windows の二層	単一 OS	WSL ほど複雑でない
ファイルと設定の見通し	Windows ドライブと分離しやすい	単一 OS で分かりやすい	テナントごとにリセットしやすい
Apple エコシステム適合	ゲートウェイ中心なら十分	ゲートウェイ中心なら十分	Keychain／Xcode 文脈に強い
コスト感	低 CAPEX、高認知負荷	Node が揃えば最速	試算記事参照

Apple 固有の検証が続くなら日割りの落とし穴を先に読み、時間枠をカレンダーに載せてください。

「クラウド Mac」列は Windows を否定するものではなく、デスクトップセッションやブラウザ証明書、拡張機能の自動化といった検証軸を足すものです。リリースカレンダーにリハーサルを書き込み、突発的な「誰かの Mac を借りる」運用を減らします。

複数プロダクト線にはチームごとの主プラットフォームラベルを付け、OS 信仰論争を減らします。

03. 前提：Node 22+、パス、ツールチェーン

パッケージ導入前に、実際に使うシェルで Node.js 22+ を満たすこと。CI コンテナだけ新しくても意味がありません。npm/pnpm を揃え、モデル API への外向き通信は検証済み VPN パスと同一に。split-tunnel では「doctor は成功・ランタイム呼び出し失敗」が典型です。

WSL2 はカーネル更新、systemd はディストリの推奨に従う。ネイティブ Windows は VC++ 再頒布可能パッケージと長いパスのポリシーを確認。OpenClaw 設定は選んだランタイムの home ツリーに一本化し、闇 symlink は避けます。

HDD では初回展開が無言で長引きゲートウェイが死んだように見えます。SSD/メモリを runbook に明記。社内 TLS は先に curl や openssl s_client で切り分けます。

対象シェルで Node ≥22 を確認し、npm/pnpm 方針を統一します。インストールガイドが正本です。

node -v
which node

04. ゲートウェイまでの 5 ステップ

アクティブシェルで Node 22+ を確認し、v20 以下なら先にランタイム更新。
WSL2 かネイティブを決定：Ubuntu WSL は localhost 挙動を理解した上で、ネイティブは PowerShell 前提を揃える—比較目的の二重起動は禁止。
ガイド通りに CLI を導入し、途中でパッケージマネージャを混在させない。
openclaw doctor を実行し依存関係・権限を直す。謎はコマンドエラー FAQ と突き合わせる。
18789 を解放または変更しゲートウェイ起動、ループバックと必要なら LAN でプローブ。ポート変更はクライアント・プロキシ・FW を同一チケットで更新。

openclaw doctor
ss -lntp | grep 18789 || true
netstat -ano | findstr 18789

同一トークンで WSL と Windows に二重起動しないでください。ログロックがネット障害に見えます。runbook にアンチパターンとして明文化します。

成功後は Node 完全バージョン文字列・bind アドレス・PID・マスク済み設定抜粋をエビデンスパックとして保存します。

Blue/Green では node_modules サイズを記録し、低速ディスクでは展開中に無応答に見えることを共有します。

05. 指標と doctor の神話

指標 1：初回 doctor 失敗の約 38–52% が Node 22 未満または PATH 競合。
指標 2：18789 チケットはチェックリスト無しで 45–90 分、有りで多くは 15 分以内。
指標 3：実行面を 1 つに統一すると「環境が違う」エスカレが約 25–35% 減る傾向。

神話： doctor 合格＝WAN 到達ではなくループバックのみの場合がある。WSL と Windows の Node は自動では共有されない。ポート変更はクライアントと文書を同時に—コマンドエラー FAQ を参照。

doctor 合格でも外部到達やクライアント設定まで保証しません。料金とリモートは料金とリモートガイド。

運用指標として doctor 再実行回数・初回ヘルスチェック成功までの時間・18789 系チケット比率を追うと、上の三指標を補強できます。

06. Windows の限界と macOS 日割り

ゲートウェイとブラウザ自動化の大半は Windows で足りますが、キーチェーン署名や一部 Safari 文脈は macOS が本番に近いです。短い 日割りネイティブ macOS でリハーサルし、SSH/VNC FAQ で帯域を計画してください。

日常は Windows の 5 ステップと Node 22+ を維持し、Mac 列が勝ち続けるスプリントはコスト試算で説明を揃えましょう。

マイルストーンの締めに三問：再起動後も doctor は緑か？ポート記載は実リスナーと一致か？同一トークンの WSL/Windows 二重ゲートウェイはないか？

財務との対話では、Windows ゲートウェイを既存ハード上の Opex、短い macOS 日割りをApple リスクのカレンダー型 capex 代替と位置付けると、OS 宗教戦争を避けられます。

2026 OpenClaw on Windows：
WSL2 vs ネイティブ PowerShell—ゲートウェイ `18789`、`openclaw doctor`、Node.js 22+

目次