OpenClaw を VPS で 24 時間運用する：安全なセットアップ

ノート PC だと、ふたを閉じた瞬間に OpenClaw は黙ります。WhatsApp のメッセージは溜まり、予定したジョブはあなたが戻るまで待ちます。サーバーなら返事を続けます。ただし問題があって、ゲートウェイはチャットウィジェットではありません。各チャネルの認証情報を持ち、サンドボックスを有効にしない限りツールをホスト上で直接実行します。常時稼働のマシンに移すなら、セキュリティモデルも一緒に移さなければ意味がありません。

このガイドでは、新しい Ubuntu 24.04 の VPS でそれを約 20 分で行います。

最終確認：2026-10-04、OpenClaw 2026.9.8（npm）、Node 24.21 LTS、Ubuntu 24.04。

必要なもの

• Linux VPS。私たちは自社の AI-Agent プラン（4 vCPU、4 GB RAM、40 GB ディスク、月額 10 ドル）を使っています。OpenClaw のドキュメントには 6 GB RAM とありますが、これは Docker イメージをソースからビルドする場合の話で、npm パッケージにビルドは不要です。
• モデルプロバイダーの API キーと、接続したいチャットアカウント。
• ノート PC の SSH 鍵。まだなければ：SSH 鍵によるログイン。

ここでは NAT プランで十分、むしろ向いているくらいです。ゲートウェイには開いた受信ポートがまったく要りません。WhatsApp、Discord、Telegram（既定はロングポーリング）は外向きに接続し、ダッシュボードには SSH でアクセスします。専用 IPv4 が必要なのは、使いたいチャネルが Webhook で配信する場合か、公開リバースプロキシを置く予定がある場合だけです。

1. root ではないユーザー

OpenClaw はゲートウェイを所有するユーザーとしてツールを実行します。そのユーザーが root なら、混乱した、あるいはプロンプトインジェクションで操られたモデルが実行すると決めたコマンドもすべて root で動きます。OpenClaw のドキュメントは、ゲートウェイを root で動かすことを危険かつサポート対象外としています。sudo 権限のない専用ユーザーを作りましょう。

# root で実行
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys   # 注文時に登録した鍵
loginctl enable-linger claw

最後の行は見た目以上に重要です。OpenClaw は systemd のユーザーサービスを入れるので、lingering がないとログアウトした時点でサービスが止まります。サーバーで一番よくある「昨日は動いていたのに」の原因がこれです。

2. Node 24 と OpenClaw

OpenClaw 2026.9.8 は Node >=24.16.0 <25 または >=26.1.0 を要求します。Ubuntu 標準の nodejs パッケージは古いので、NodeSource から 24 LTS を入れます。

# root で実行
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v          # v24.16.0 以降
npm install -g openclaw@latest
openclaw --version

公式のワンライナー（curl -fsSL https://openclaw.ai/install.sh | bash）でも動き、Node も一緒に入れてくれます。サーバーでは明示的な 2 ステップのほうが好みです。何がどこに入るかが見えますし、実行ファイルはエージェントが書き込めるホームディレクトリではなく /usr/bin に置かれます。

3. エージェント用ユーザーでオンボーディング

su ではなく、claw として SSH でログインしてください。サービスに必要な systemd のユーザーマネージャーは、本物のログインでしか起動しません。

# ノート PC から（NAT プラン：-p <SSH ポート> を追加）
ssh claw@<server>

openclaw onboard --install-daemon
openclaw gateway status

ウィザードがモデルへのアクセスを確認し、~/.openclaw/openclaw.json を書き、ゲートウェイトークンを生成してサービスを入れます。systemctl --user がバスについてエラーを出したら、export XDG_RUNTIME_DIR=/run/user/$(id -u) を設定してやり直してください。

次にファイルを締めます。OpenClaw 自身の推奨は、状態ディレクトリに 700、設定ファイルに 600 です。

chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep

openclaw security audit --fix は安全な範囲の修正を適用します。ファイル権限の厳格化と、開いたグループポリシーの許可リストへの置き換えです。待ち受けアドレスを変えたりファイアウォールを設定したりはしないので、ネットワークへの露出は引き続きあなたの担当です。

4. ゲートウェイは loopback に置く

ゲートウェイは WebSocket API とダッシュボードを 1 つのポート 18789 で提供し、既定で 127.0.0.1 にバインドされます。そのままにしてください。それを明示した最小構成はこちらです。

// ~/.openclaw/openclaw.json
{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
  },
}

トークンは openssl rand -hex 32 か openclaw doctor --generate-gateway-token で生成します。ゲートウェイは空のトークンやサンプル値を拒否し、監査は 24 文字未満で警告します。

やってはいけないこと：bind を "lan" にしてポートを開けること。ドキュメントははっきり書いています。認証なしで 0.0.0.0 にゲートウェイを公開しない、トークンがあってもポートを広く転送しない。そのトークンを手にした人は、あなたのサーバーでコマンドを実行できるプロセスのオペレーターになります。

ファイアウォールでは SSH だけを許可し、ほかは何も通しません。

# root で実行
ufw allow OpenSSH
ufw enable
ufw status verbose

当社の NAT プランでは、管理画面に外部 SSH ポートが表示されますが、サーバー内部の sshd は引き続き 22 番で待ち受けています。外部ポート番号ではなく OpenSSH（22 番）を許可してください。そうしないと ufw enable で締め出されます。詳しくは UFW ガイド を参照してください。

5. SSH でダッシュボードに入る

ノート PC からトンネルを開き、開いたままにしておきます。

ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# NAT プラン：ssh -N -p <SSH ポート> -L 18789:127.0.0.1:18789 claw@<host>

http://127.0.0.1:18789/ を開き、ゲートウェイトークンを貼り付けます。Ubuntu の既定の sshd はローカル転送を許可しています。設定を強化している場合、-L を許可しつつリモート転送をブロックする設定が AllowTcpForwarding local です。トンネルが administratively prohibited で失敗したら、この行を確認してください。

tailnet でもかまいません。Tailscale Serve はゲートウェイを loopback に置いたままアクセスを管理します。どちらも問題ありません。公開ポートはだめです。

6. ペアリング、サンドボックス、誰が話しかけられるか

チャットチャネルはもう 1 つの入口です。既定では、DM を受けるチャネルは見知らぬ送信者にまずペアリングを求めます。承認はサーバーから行います。

openclaw pairing approve <channel> <code>

グループではメンションを必須にして、ルーム内のすべてのメッセージにエージェントが反応しないようにしましょう。OpenClaw の強化ベースラインでは、チャネルごとに dmPolicy: "pairing" と groups: { "*": { requireMention: true } } を設定します。

正直な注意点が 2 つあります。1 つ目：ペアリングが決めるのは誰がターンを起動できるかであって、何がモデルのコンテキストに入るかではありません。転送されたメッセージや取得した Web ページが、あなた自身が起動したターンを誘導することはありえます。2 つ目：サンドボックスを有効にするまで、メインセッションのツールはホスト上で動きます（agents.defaults.sandbox.mode: "non-main" は自分のメインセッション以外をすべてサンドボックス化します）。サンドボックスは既定でオフで、既定のバックエンドは Docker なので、有効にする前に Docker を入れてください：VPS への Docker 導入。信頼できない人がボットと同じチャネルにいるなら、別のゲートウェイを、できれば別のサーバーで用意しましょう。

7. 更新とバックアップ

openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify

~/.openclaw には設定、チャネルの認証情報（WhatsApp のセッションを含む）、モデルの認証プロファイル、セッションの記録が入っています。失えばすべてペアリングし直し、漏れれば WhatsApp で他人があなたになりすませます。バックアップを取り、コピーはサーバーの外に置いてください。scp でダウンロードするか、暗号化付きの restic を使います。

チェックリスト

EQVPS の役割

Node のプロセスを動かせる事業者はたくさんあります。私たちが加えるのは、KYC 不要の暗号資産決済、loopback だけで待ち受けるゲートウェイに合う NAT プラン、そしてエージェントが自分のサーバーを管理できる MCP サーバー です。OpenClaw をそこにつなぐなら、先に MCP ガードレール を読んでください。サーバーを注文できるトークンは、ゲートウェイトークンと同じくらい慎重に扱う価値があります。VPS でエージェントを動かす全体像は AI エージェントのガイド にまとめています。

私たちの意見：この 20 分が、アシスタントと、チャット画面付きの開きっぱなしの shell との差です。ほかを飛ばしても、手順 1、4、5 だけはやってください。