新規PC開封からOpenClawをWSL2で全自動起動
&メインPCとNodeペアリングまでの完全手順

2026-03-21 | AI・開発環境

2台のノートPCがネットワークで接続されているイメージ

この記事をシェア

新PC到着。さて、どこから始める?

Lenovo Yoga Pro 7i Gen 10(16インチ、32GB RAM、16コア)が届いた。真っ新なWindowsマシン。これをメインPC(ThinkPad X1 Carbon 2018)のOpenClaw Gatewayに接続するNodeとして完全自動起動させるまでの全工程を記録する。

ゴールはシンプル。Windowsにログインするだけで、WSL2の中のOpenClawノードが自動的に起動し、メインPCのGatewayに接続される状態。ターミナルを一切開かなくていい。再起動テストもパスした実際の手順を、ハマりポイントも含めてすべて公開する。

📋 今回の環境
  • メインPC(Gateway): ThinkPad X1 Carbon 2018 / WSL2 Ubuntu / Tailscale IP: 100.126.146.111
  • 新PC(Node): Lenovo Yoga Pro 7i Gen 10 / WSL2 Ubuntu 24.04 / Tailscale IP: 100.113.171.121
  • 接続方式: Tailscale VPN経由(インターネット不要、LAN不要)

Step 1: WSL2基本セットアップ

まずWSL2を有効化してUbuntu 24.04をインストール。その後、開発に必要な基本パッケージを一括で入れる。

sudo apt update -y
sudo apt install -y build-essential curl wget unzip jq htop tree

build-essentialはネイティブnpmパッケージのコンパイルに必要。後でopenclaw installで詰まるので最初から入れておく。

Step 2: Node.js(nvm経由)

Node.jsはnvmで管理する。システム直インストールだとバージョン管理が面倒だし、openclaw自体もnvmと相性がいい。

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.nvm/nvm.sh
nvm install --lts

インストール後の確認:

node -v   # → v24.14.0
npm -v    # → 11.9.0

nvmの初期化は~/.bashrcに自動追記されるが、現在のセッションには反映されていないのでsource ~/.nvm/nvm.shを忘れずに。

Step 3: Docker

Dockerも開発環境には必須。公式リポジトリから入れる手順が少々長いが、これが一番確実。

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update -y
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER

sudo usermod -aG docker $USERの後、一度ログアウト&再ログインかWSLを再起動しないとグループが反映されない点に注意。

Step 4: GitHub CLI + SSH鍵設定

GitHub CLIをインストールして、SSH鍵をGitHubに登録する。

sudo apt install gh -y

# SSH鍵生成(マシン名をコメントに入れておくと後で分かりやすい)
ssh-keygen -t ed25519 -C "s-noguchi@yogapro7i-10gen" \
  -f ~/.ssh/id_ed25519 -N ""

# GitHub認証(ブラウザが開く)
gh auth login  # SSH選択 → ブラウザで認証

# GitHubのホストキーを登録
ssh-keyscan github.com >> ~/.ssh/known_hosts

# 接続確認
ssh -T git@github.com  # → Hi xim2jp!

# Git global設定
git config --global user.name "Shinichi Noguchi"
git config --global user.email "shinichi@noguchi.jp.net"

Step 5: プロジェクトのクローン

SSHで認証が通ったので、必要なリポジトリを一気にクローン。

git clone git@github.com:officetrueone/community-dx.git
git clone git@github.com:OfficeTrueone/seosites.git
git clone git@github.com:OfficeTrueone/web.git
git clone git@github.com:xim2jp/asahigaoka.git
git clone git@github.com:xim2jp/korot-production.git

Step 6: OpenClawインストール&Nodeペアリング

TailscaleVPN経由でGatewayとNodeが接続されるネットワーク構成

Tailscale VPN経由でGatewayとNodeを安全に接続する

💡 Tailscaleとは?

Tailscaleは、WireGuardベースのメッシュVPNサービスです。面倒なVPN設定なしで、インストールするだけで複数のPCやスマホが同じプライベートネットワークに参加できます。NAT越えも自動で、自宅のWSL2にも外出先から安全にアクセス可能。今回のように別々のPCをTailscale経由で接続するのは、最も王道な使い方です。

👉 詳しいセットアップ手順は別記事で解説しています:
外にいるスマホから家にあるWindowsのWSL2にSSHしてrootをとるまで

ここからがOpenClaw固有の設定。新PC側でopenclaw本体をインストールし、メインPC側でGatewayの待ち受け設定を変更する。

6-1. 新PC側: OpenClawインストール

npm install -g openclaw

6-2. メインPC側: GatewayのBindを変更

デフォルトではGatewayはlocalhostのみで待ち受けている。新PCからのTailscale経由接続を受け付けるためにlan(全インターフェース)に変更する。

# メインPC(ThinkPad)側で実行
openclaw config set gateway.bind lan
openclaw gateway restart

6-3. 新PC側: Nodeとして起動

メインPCのGatewayトークンを指定してNodeを起動する。TailscaleのIPアドレスを使うのがポイント。

OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 \
OPENCLAW_GATEWAY_TOKEN=<gateway-token> \
openclaw node run \
  --host 100.126.146.111 \
  --port 18789 \
  --display-name "YogaPro7i"
⚠️ OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 について
Tailscale内の通信は平文WebSocketを使う。OpenClawのセキュリティチェックがこれをブロックするので、環境変数で許可する必要がある。Tailscaleは暗号化済みトンネルなので実質的なリスクはない。

6-4. メインPC側: ペアリング承認

# メインPC側で実行
openclaw devices list      # → pending状態のリクエストを確認
openclaw devices approve <requestId>
openclaw nodes status      # → Connected: 1

これで2台が繋がった。ただしまだ手動起動の状態。次のステップで全自動化する。

Step 7: 全自動起動設定

systemdユーザーサービスの設定とping待ちの仕組み

systemdユーザーサービスでGatewayへの接続を自動化する

自動起動は3段構えで実装する。

  1. Windows起動時: VBSスクリプトでWSL2をバックグラウンド起動
  2. WSL2起動時: systemdでSSH・Dockerが自動起動
  3. ネットワーク接続後: systemdユーザーサービスでOpenClawノードが自動接続

7-1. SSH自動起動

sudo systemctl enable ssh

7-2. OpenClawノードのsystemdユーザーサービス化

まずnodeopenclawのフルパスを確認する。

which node     # → /home/s-noguchi/.nvm/versions/node/v24.14.0/bin/node
which openclaw # → /home/s-noguchi/.nvm/versions/node/v24.14.0/bin/openclaw

サービスファイルを作成する。

mkdir -p ~/.config/systemd/user
# ~/.config/systemd/user/openclaw-node.service
[Unit]
Description=OpenClaw Node Host (YogaPro7i)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
# Tailscale(Gateway)が応答するまで最大60秒待つ
ExecStartPre=/bin/bash -c "for i in $(seq 1 30); do \
  ping -c1 -W2 100.126.146.111 >/dev/null 2>&1 && exit 0; \
  sleep 2; \
done; exit 1"
ExecStart=/home/s-noguchi/.nvm/versions/node/v24.14.0/bin/node \
  /home/s-noguchi/.nvm/versions/node/v24.14.0/bin/openclaw \
  node run \
  --host 100.126.146.111 \
  --port 18789 \
  --display-name YogaPro7i
Environment=OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1
Environment=OPENCLAW_GATEWAY_TOKEN=<your-gateway-token>
Environment=HOME=/home/s-noguchi
Restart=always
RestartSec=10

[Install]
WantedBy=default.target

サービスを有効化して起動する。

systemctl --user daemon-reload
systemctl --user enable openclaw-node.service
systemctl --user start openclaw-node.service

# ログアウトしてもサービスが継続するようにLingerを有効化
sudo loginctl enable-linger $USER

ステータス確認:

systemctl --user status openclaw-node.service
# → Active: active (running)

7-3. WSL2のWindows自動起動(ターミナル非表示)

PowerShellとVBSスクリプトでWSL2をWindows起動時にバックグラウンド起動する

VBSスクリプトでターミナルウィンドウを出さずにWSL2を起動する

スタートアップフォルダにVBSスクリプトを配置する。PowerShellで実行する。

$startup = "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"
Set-Content "$startup\wsl-autostart.vbs" `
  'CreateObject("WScript.Shell").Run "wsl -d Ubuntu", 0, False'

これでwsl -d Ubuntuがウィンドウなし(0)・非同期(False)で実行される。Windowsログイン直後にWSL2がバックグラウンドで起動する。

✅ なぜVBSなのか?
タスクスケジューラ(schtasks)でWSL2を起動すると、コマンドプロンプトのウィンドウが一瞬表示される。VBSのWScript.Shell.Runに第2引数0(ウィンドウ非表示)を指定することで完全にバックグラウンド化できる。

ハマりポイント6選

今回の作業で実際に引っかかったポイントをまとめる。同じ環境を構築する人の参考になれば。

❌ その1: Tailscale起動前にOpenClawノードが動いて接続失敗

症状: システム起動後、OpenClawノードのサービスは起動しているのにGatewayに繋がらない。

原因: WSL2のsystemdがネットワークの起動を「完了」と判断するタイミングが早すぎて、Tailscaleが未起動の状態でOpenClawが接続を試みる。

解決: ExecStartPreにpingループを仕込み、GatewayのTailscale IPに応答が来るまで待機させる。

ExecStartPre=/bin/bash -c "for i in $(seq 1 30); do \
  ping -c1 -W2 100.126.146.111 >/dev/null 2>&1 && exit 0; \
  sleep 2; \
done; exit 1"

❌ その2: 平文WebSocketがセキュリティブロックされる

症状: openclaw node runを実行するとセキュリティエラーで接続拒否。

解決: OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1を環境変数に追加。Tailscaleはすでに暗号化トンネルなので二重暗号化は不要。

❌ その3: Lingerを有効化しないとログアウトでサービスが止まる

症状: ログイン中はサービスが動いているが、ログアウトするとOpenClawノードが切断される。

原因: systemdのユーザーサービスはデフォルトでユーザーセッションに紐付いており、ログアウトと同時に停止する。

解決:

sudo loginctl enable-linger $USER

❌ その4: schtasksでWSL2を起動するとターミナルウィンドウが出る

症状: タスクスケジューラでwsl -d Ubuntuを実行すると、コマンドプロンプトウィンドウが一瞬表示される。

解決: VBSスクリプト経由でWScript.Shell.Runの第2引数に0(ウィンドウ非表示モード)を指定する。

❌ その5: Gateway bind設定の罠 — loopback / tailnet / lan の違い

これは一番ハマったポイント。OpenClaw Gatewayにはgateway.bindという設定があり、どのネットワークインターフェースでWebSocket接続を待ち受けるかを制御している。

bind設定 待ち受けアドレス 接続できる相手
loopback(デフォルト) 127.0.0.1:18789 同じマシン内のみ
tailnet 100.x.x.x:18789(Tailscale IPのみ) Tailscale経由のみ
lan 0.0.0.0:18789(全インターフェース) localhost + LAN + Tailscale すべて

最初はloopback(デフォルト)だったので、Yoga側からTailscale経由で繋がらなかった。そこでtailnetに変更したところ、今度はメインPC自身のサブエージェント127.0.0.1で接続する)が繋がらなくなった。

この構造を図にするとこうなる:

■ bind=loopback の場合
  ThinkPad (localhost)  → Gateway :18789  ✅ 接続OK
  YogaPro7i (Tailscale) → Gateway :18789  ❌ 接続拒否

■ bind=tailnet の場合  
  ThinkPad (localhost)  → Gateway :18789  ❌ 接続拒否
  YogaPro7i (Tailscale) → Gateway :18789  ✅ 接続OK

■ bind=lan の場合(正解)
  ThinkPad (localhost)  → Gateway :18789  ✅ 接続OK
  YogaPro7i (Tailscale) → Gateway :18789  ✅ 接続OK
  openclaw CLIコマンド  → Gateway :18789  ✅ 接続OK

結論: Node接続とローカルCLIの両方を使うなら、lan一択。Tailscaleネットワーク自体がWireGuardで暗号化されているので、セキュリティ的にも問題はない。Gateway認証トークンもあるため、LAN内の他のマシンが勝手に接続することもできない。

# Gateway bindをlanに変更
openclaw config set gateway.bind lan
openclaw gateway restart

❌ その6: openclaw nodes status がタイムアウトする

bindlanに変更した後でも、openclaw nodes statusコマンドがタイムアウトする現象が発生した。

$ timeout 5 openclaw nodes status
# → (5秒後にタイムアウト、何も表示されない)

# しかしHTTPは通る
$ curl -s http://127.0.0.1:18789/
# → <!doctype html>... (正常応答)

# Yoga側からも通る
$ curl -s http://100.126.146.111:18789/
# → <!doctype html>... (正常応答)

原因: CLIコマンドはWebSocket(ws://)で接続するが、Gateway再起動直後にWebSocketのハンドシェイクが不安定になることがある。HTTP(REST API)は正常に応答しているので、Gateway自体は動いている。

切り分け方法:

  1. ss -tlnp | grep 18789 でGatewayがリッスンしているか確認
  2. curl http://127.0.0.1:18789/ でHTTP応答を確認
  3. Yoga側からcurl http://<Gateway IP>:18789/ でネットワーク疎通を確認
  4. Yoga側でjournalctl --user -u openclaw-node.service でNode側のエラーログを確認

ポイント: 「CLIが動かない ≠ Gatewayが動いていない」。実際にはSlack連携やノード接続が正常に動いているのに、CLIだけがタイムアウトするケースがある。慌ててGatewayを再起動するのではなく、まず上記の切り分けを行うこと。

結果: 再起動テスト合格

新PCのWindowsを再起動し、ログインするだけで以下が自動的に完了することを確認した。

  1. WSL2がバックグラウンド起動(ターミナルウィンドウなし)
  2. SSH・Docker・Tailscaleがsystemdで自動起動
  3. OpenClawノードがGatewayのpingを待ってから接続
  4. メインPC側でConnected: 1が確認できる
# メインPC側で確認
openclaw nodes status
# → Total: 1 | Connected: 1
# → YogaPro7i  connected  100.113.171.121

まとめ

新PCを開封してからOpenClaw Nodeとして完全自動起動させるまでの全工程を解説した。要点を整理すると:

  • nvmでNode.jsを管理すると後のバージョンアップも楽
  • GatewayのBindはlan一択 — loopbackだとNode接続不可、tailnetだとローカルCLI不可
  • Tailscaleが起動する前にNodeが接続を試みる問題はExecStartPreのping待ちで解決
  • loginctl enable-lingerでユーザーサービスをセッション非依存にする
  • VBSスクリプトでWindows起動時のWSL2自動起動をターミナルなしで実現

これで普段使いのメインPCに加え、新PCのリソースもOpenClaw経由で自動的に活用できるようになった。Yoga Pro 7i Gen 10は32GB RAM・16コアなので、AIエージェントの並列実行環境として大きな戦力になりそうだ。

OpenClaw Nodesの活用方法については中古PC3台とOpenClaw Nodesで「AI開発部隊」を本気で運用してみたも参考にしてほしい。

この記事が役に立ったらシェアしてください

WSL2でのOpenClaw Node自動起動設定の参考になれば嬉しいです!

カテゴリ

AI・開発環境

公開日

2026-03-21

お気軽にご相談ください

記事に関するご質問や、AI・IT技術導入のご相談など、お気軽にお問い合わせください。