OpenClawをVPSで安全に実行する方法

OpenClaw の概要と、最初に堅牢化する理由

OpenClaw はセルフホスト型の AI エージェントです。自分のサーバーで実行し、大規模言語モデルに接続すると、シェルコマンドの実行、ブラウザーの操作、ファイルの読み書き、チャットアプリから送信したメッセージへの応答を行えます。この広い権限範囲こそがツールの目的であり、同時にリスクでもあります。任意のコマンドを実行できるエージェントの安全性は、実行先のサーバーと、その周囲に設定した制限に左右されます。

このガイドの前提となる事実は 2 つあります。1 つ目は、OpenClaw が利用者自身による堅牢化を前提に設計されていることです。セキュリティモデルでは、安全なデフォルトではなく、厳格なツールポリシー、サンドボックス、慎重な権限設定の責任を運用者に求めています。2 つ目は、このプロジェクトですでに深刻なセキュリティ問題が発生していることです。National Vulnerability Database には、2026 年 3 月だけで OpenClaw の CVE が 199 件登録されており、そのうち 46 件は 3 月 4 日から 7 日までの 4 日間に公開されています（件数は 2026 年 10 月 13 日に確認）。同月の脆弱性には、深刻度が 10 点中 9.9 の重大な権限昇格脆弱性 CVE-2026-32922 も含まれます。この脆弱性は version 2026.3.11 で修正されています。どちらの事実も、OpenClaw を避けるべきだという意味ではありません。安易な構成で実行してはならず、このガイドの手順に従って慎重に構成すべきだという意味です。慎重な構成では、エージェントが確認なしに実行できる範囲を事前に決めることも重要です。Claude Code では権限モードとして明示的に設定できます。目の前で監視しているラップトップよりも、直接操作しないサーバーのほうが厳しい設定に適しています。

幸いな点もあります。OpenClaw は安全性に関わる選択をすでに 1 つ行っています。すべてを制御する単一プロセスである gateway は、デフォルトで loopback address を待ち受けます。そのため、意図的に外部公開しない限り、インターネットから到達できません。以下で行う作業の大半は、この状態を維持し、問題が発生した場合の影響範囲を制限することです。

OpenClaw専用の非特権ユーザーを作成する

エージェントを root として実行しないでください。OpenClaw を root として実行すると、バグ、誤った指示、または上記のような CVE のいずれが原因でも、問題が発生した場合の被害に上限がありません。ログインシェルと sudo を持たない専用のシステムユーザーを作成し、そのユーザーでエージェントを実行します。

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

OpenClaw が所有するすべてのものは /opt/openclaw 配下に置き、そのアカウントが所有します。これは最も重要な手順です。非特権ユーザーとしてサービスを実行するで説明した原則と同じで、エージェントの実行ユーザーが、エージェントによる破壊の上限になります。

OpenClaw のインストール

OpenClaw は npm package として配布されています。サーバーに Node.js がない場合は、先にインストールしてください。プロジェクトでは Node 24.16 以降、または 26.1 以降が必要です。package を global にインストールすると、すべてのユーザーの PATH に openclaw binary が配置されます。その後、初回のみ onboarding を実行します。

sudo npm install -g openclaw@latest --allow-scripts=openclaw
sudo -u openclaw openclaw onboard

--allow-scripts=openclaw flag が必要なのは、npm 12 では package install scripts がデフォルトでブロックされ、OpenClaw が独自の install script を実行する必要があるためです。このオプションがない npm 11.15 以前では、flag を省略してください。openclaw user として onboarding を実行すると、エージェントの設定は root のホームディレクトリではなく、そのユーザーのホームディレクトリ /opt/openclaw に保存されます。プロジェクトには curl -fsSL https://openclaw.ai/install.sh | bash installer も用意されており、同じインストールを 1 行で実行できます。onboarding では --install-daemon flag を省略してください。この flag を指定すると OpenClaw 独自の service が登録されますが、以下で作成する堅牢化済みの systemd unit のほうが厳格です。

ループバック上にゲートウェイを置き、ファイアウォールの内側で運用する

ゲートウェイはデフォルトで 127.0.0.1 にバインドします。ここから変更しないでください。このポートをインターネットに公開する理由はほとんどありません。公開すると、コマンドを実行するプロセスへのリモートからの足掛かりを、発見した人に与えることになります。

意図せず何も公開しないよう、サーバーの前段にデフォルト拒否のファイアウォールを配置します。

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

ここでは、2 つの落とし穴を避けてください。IPv4 だけを対象にしたファイアウォールでは、同じサービスが IPv6 上で完全に公開されたままになることがあります。これは、多くの人が遭遇する IPv6 ファイアウォールの抜け穴です。また、ノート PC からゲートウェイへ接続する必要がある場合も、ポートを開放しないでください。VPN または SSH トンネル経由で接続し、エージェントがオープンなインターネット上で待ち受けないようにします。

シークレットを分離する

OpenClaw には、接続する言語モデルの API key が必要です。この key は料金を発生させる可能性があり、agent を通じてユーザーの代理で操作できるため、password と同様に扱ってください。unit file や repository には保存しないでください。OpenClaw user だけが読み取れる file に保存します。

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

systemd unit は EnvironmentFile でその file を読み込むため、key が command line、log、shell history に残ることなく process に渡されます。この方法はサーバー上のすべての secret に適用できます。self-hosted Vaultwarden の hardening 作業では、暗号化方式ではなく admin token と backup file が対象になります。保存中の secret を誰が読み取れるかを実際に決めるのは、file の permission だからです。

強化した systemd サービスとして実行する

agent を systemd の下で実行すると、自動再起動、journalctl による整理されたログ、そして最も重要な機能として、プロセスが侵害された場合でもアクセス可能な範囲を狭めるカーネルレベルのサンドボックス設定を利用できます。agent で特に重要なのは、新たな権限を取得できないようにする NoNewPrivileges、書き込みを許可した場所を除いてファイルシステムを読み取り専用にする ProtectSystem=strict、agent 専用の隔離された一時ディレクトリを用意する PrivateTmp、ホームディレクトリを読み取れないようにする ProtectHome です。

ここで完全な強化済み unit を生成し、/etc/systemd/system/openclaw.service にコピーします。

この unit は、agent を制御する長時間実行プロセスである openclaw gateway を起動します。which openclaw の結果がサーバー上の別のパスを示す場合は、ExecStart をそのパスに合わせて変更してください。これらのディレクティブと daemon-reload、enable --now の詳細な手順は、systemd サービスとしてプログラムを実行する にあります。unit を貼り付けた後の手順は次のとおりです。

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

入口も強化する

エージェント用サーバーの安全性は、その周囲のサーバー環境と同程度です。仕上げとして、さらに2つの対策を追加します。VPS の SSH を強化するに従って、SSH を鍵認証のみに変更し、root ログインを無効にします。これにより、サーバーの管理に使用するアカウントがブルートフォース攻撃を受けるのを防げます。次に、Fail2banを追加し、公開ポートを手当たり次第にスキャンする攻撃元を遮断します。どちらも OpenClaw を直接変更するものではありませんが、攻撃者が OpenClaw に到達するために利用する経路を遮断できます。

意図を持って最新状態を維持する

2026年3月の開示は、最新状態を維持すべき理由を明確に示しています。エージェントの権限昇格バグは、一般的な Web アプリケーションのバグよりはるかに深刻です。エージェントはすでにコマンドを実行できるためです。プロジェクトのリリースを監視し、セキュリティ更新を速やかに適用してください。OpenClaw のアップグレードは先延ばしにするものではなく、通常の保守作業として扱います。

実際に何を強化しているのかを理解するには、OpenClaw 型エージェントのアーキテクチャで構成要素を確認できます。また、VPS 上で独自の AI エージェントを構築するでは、エージェントに共通する全体像を説明しています。別のエージェントも併用する場合は、1 台の VPS 上にある 2 つの Claude Code セッションは相互に作業を引き渡せることに注意してください。そのため、それぞれに専用のアカウントと制限を設定し、自分のアカウントや制限を継承させないでください。

FAQ

OpenClaw をパブリック VPS で実行しても安全ですか？

適切に強化すれば可能です。OpenClaw は設計上強力で、シェルコマンドを実行し、ブラウザーを制御します。そのため、設定を誤ると実際に危険です。プロジェクトではすでに重大な CVE（2026 年 3 月の CVE-2026-32922）も発生しています。OpenClaw のセキュリティモデルでは、運用者が制限を追加することを前提としています。非特権ユーザーで実行し、ゲートウェイは loopback で待ち受けさせたまま default-deny のファイアウォールの背後に置き、API キーを分離し、強化した systemd サービスとして実行してください。

OpenClaw のゲートウェイをインターネットに公開すべきですか？

いいえ。ゲートウェイはデフォルトで loopback に bind するため、その設定を維持してください。ゲートウェイはエージェントを制御する単一のプロセスです。公開すると、コマンドを実行するプロセスへのリモート経路になります。リモートから接続する必要がある場合は、ポートを開放せず、VPN または SSH トンネルを使用してください。

OpenClaw はどのユーザーで実行すべきですか？

ログインシェルと sudo 権限を持たない専用の system user で実行してください。root は使用しないでください。エージェントが侵害された場合、そのユーザーアカウントが被害の上限になります。そのため、そのアカウントには /opt/openclaw のようなディレクトリ配下にある自身のファイルだけを所有させ、それ以外は所有させないでください。

OpenClaw の API キーを安全に管理するにはどうすればよいですか？

OpenClaw ユーザーだけが読み取れるファイル（mode 600）に保存し、systemd の EnvironmentFile を使用してサービスに読み込ませてください。キーを unit ファイル、shell の履歴、git リポジトリのいずれにも残さないでください。漏えいした疑いがある場合は、キーをローテーションしてください。