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

OpenClaw の概要と、最初に強化すべき理由

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

このガイドの前提となる事実は2つあります。1つ目は、OpenClaw が利用者自身による強化を前提に設計されていることです。OpenClaw のセキュリティモデルでは、安全なデフォルトではなく、厳格なツールポリシー、サンドボックス、適切な権限設定を運用者が担います。2つ目は、このプロジェクトですでに重大なセキュリティ事象が発生していることです。2026年3月には、4日間で9件のセキュリティ問題が公開されました。その中には、深刻度が10点満点中9.9の重大な権限昇格の脆弱性 CVE-2026-32922 も含まれます。どちらの事実も、OpenClaw を避けるべきだという意味ではありません。手を抜いた方法で実行してはならず、このガイドが示す慎重な方法で運用すべきだという意味です。慎重に運用するには、エージェントが確認なしで実行できる範囲を事前に決めることも含まれます。これは Claude Code が権限モードで明示している選択です。目の前にないサーバーには、監視しているノートパソコンより厳しい設定が必要です。

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

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

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

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

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

OpenClaw のインストール

OpenClaw は npm パッケージとして配布されているため、サーバーに Node.js がない場合は、最初にインストールします。パッケージはグローバルにインストールします。これにより、openclaw バイナリがすべてのユーザーの PATH に追加されます。その後、初回のオンボーディングを実行します。

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

openclaw ユーザーでオンボーディングを実行すると、エージェントの設定は root のホームディレクトリではなく、そのユーザーのホームディレクトリである /opt/openclaw に保存されます。このプロジェクトには、同じインストールを 1 行で実行する curl -fsSL https://openclaw.ai/install.sh | bash インストーラーも用意されています。オンボーディングでは --install-daemon フラグを省略してください。このフラグを指定すると OpenClaw 独自のサービスが登録されますが、以下で作成する強化済みの 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 リポジトリのいずれにも残さないでください。漏えいした疑いがある場合は、キーをローテーションしてください。